Generativ AI ændrer en del af den indlejrede udvikling — men ikke den afgørende del. Hvad der er forskudt, hvad der er skærpet, og hvad De som ordregiver får.
Generativ AI kan i dag producere standarddrivere, simple tilstandsmaskiner og boilerplate-kode i SystemVerilog, VHDL, C eller Python. Det er reelt, det er nyttigt, og det har reduceret indsatsen for visse rutineopgaver.
Heraf opstår et legitimt spørgsmål: hvad bidrager en erfaren udvikler inden for indlejret og FPGA stadig med i denne sammenhæng?
Svaret er konkret.
En AI er en hurtig udfører. Den producerer det, den får besked om — ikke det, der er nødvendigt. At bede en AI «skriv en UART-driver til mig» giver en UART-driver. Men ikke den, der faktisk fungerer med dette klokdomæne, denne pin-tildeling, denne timing-adfærd og denne fejlhåndtering i målmiljøet.
Den egentlige ingeniørmæssige ydelse er ikke at generere kode. Den er at skrive en præcis specifikation: hvad skal præcist ske, under hvilke betingelser, med hvilke tolerancer, med hvilken adfærd ved fejl, i hvilket temperaturområde, over hvilken levetid.
Bedre AI ændrer intet ved dette. Tværtimod: jo mere kraftfulde værktøjerne bliver, desto mere afgørende bliver det at instruere dem korrekt.
En AI tilføjer ikke krav, som ordregiveren ikke har tænkt på. Den opfinder ikke specialtilfælde. Den leverer præcis det, der står i specifikationen — og intet derudover. Det, der ikke er specificeret, mangler i resultatet.
Dermed forskydes risikoen fuldstændigt til selve specifikationen. En uerfaren specifikation beskriver korrekt, hvad kunden har bedt om, og overser alt det, forfatteren aldrig har oplevet: det sjældne sensorudfald ved bestemte temperaturgradienter, adfærden ved samtidig brown-out og I²C-buslås, en watchdog-reset under en flash-skrivesekvens, den elektromagnetiske kobling på lange sensorledninger, adfærden ved genstart efter en utilsigtet reset under en kritisk skriveoperation.
Sådanne punkter er ikke kundekrav. De er krav, som en erfaren udvikler tilføjer, fordi han ved, at de ellers ikke ville stå nogen steder. En specifikation er derfor altid også et risikokatalog — og dens dybde er proportional med erfaringen hos den, der skriver den.
Ved en sikkerhedsundersøgelse af et infusionsapparat, hvortil jeg blev tilkaldt af en producent af medicinsk udstyr, viste der sig en sikkerhedsrelevant fejl, som opstod af samtidig optræden af to enkeltfejl: hardwarefejl i en hukommelseskreds og en fejlbehæftet kontrolrutine for præcis denne kreds. Hver fejl for sig var håndterbar. Først kombinationen producerede den ikke-erkendte fejltilstand.
Det er netop denne kombinationsanalyse, der aktivt skal tilføjes i en specifikation. Ud fra kravet «kontroller hukommelsen» genererer et værktøj en kontrolrutine. Af erfaringen følger det yderligere krav, at også kontrolrutinens egen fejlning ikke må føre til en stille fejltilstand. Intet værktøj formulerer dette andet krav af sig selv.
Hertil kommer de hardwarenære faldgruber, der ikke står i datablade, men i hovedet på udviklere, der allerede har jagtet dem én gang:
Til de fleste opgaver findes der flere løsninger, der grundlæggende fungerer. Men kun få af dem opfylder kravene til sikkerhed, pålidelighed og levetid, som det konkrete produkt har brug for.
Et AI-system vælger det, der var hyppigt i dets træningsdata. En erfaren udvikler vælger det, der ikke fører til katastrofe i et sikkerhedsrelevant system. Denne udvælgelsesbeslutning er ikke et implementeringsdetalje. Den er den egentlige ingeniørkunst.
Ved skadetilfælde kræver lovgiveren beviset på, at produktet ved markedsføringen svarede til teknikkens stade. Det er den centrale forudsætning for, at en producent kan argumentere sig ud af produktansvaret. Med det nye EU-produktansvarsdirektiv og den efterfølgende nationale gennemførelseslov skærpes denne bevisbyrde udtrykkeligt for software og softwareintegrerede produkter.
Teknikkens stade er ikke en statisk tilstand. Den er det, der blandt fagfolk anses for sædvanligt — og den ændrer sig nu accelereret, fordi nye værktøjer og metoder hæver markedsstandarden i korte cyklusser.
Heraf følger: den, der i dag udvikler et indlejret system, må kende og anvende de aktuelt mere kraftfulde metoder. Den, der ikke gør det, skaber for sin ordregiver en konkret ansvarsrisiko. Det forudsætter netop en udvikler, der behersker både de etablerede og de nye værktøjer og kan træffe det rigtige valg.
Jeg bruger AI-værktøjer dér, hvor de mærkbart sparer tid uden at skabe risici: første udkast af boilerplate, generering af testbænke, dokumentation, læsbarhedskontrol.
Jeg bruger dem ikke som erstatning for:
Resultatet: mindre indsats for rutinearbejde, vedvarende høj kvalitet i de opgaver, der faktisk bærer projektet, og en dokumenteret udviklingsproces, der svarer til teknikkens aktuelle stade.
De bestiller en udvikler med over 35 års erfaring inden for FPGA og indlejret, som kender de aktuelle værktøjer og kan vurdere deres grænser. De får hverken et «AI-genereret projekt» eller et «AI-frit projekt». De får et fungerende system, som en konkret person påtager sig ansvaret for — og som ved skadetilfælde påviseligt er udviklet i overensstemmelse med teknikkens stade.
Hvis De har et indlejret projekt, der kræver netop denne dybde, lad os tale direkte om det. Indledende samtale og grov vurdering er gratis og uforpligtende.