Generativni UI mijenja dio razvoja ugrađenih sustava — ali ne i odlučujući. Što se pomaknulo, što se zaoštrilo i što kao naručitelj dobivate.
Generativni UI danas može proizvoditi standardne upravljače, jednostavne automate stanja i boilerplate kod u SystemVerilogu, VHDL-u, C-u ili Pythonu. To je stvarno, korisno i smanjilo je napor za određene rutinske zadatke.
Iz toga proizlazi opravdano pitanje: što još donosi iskusni razvijatelj ugrađenih sustava i FPGA u ovom okruženju?
Odgovor je konkretan.
UI je brz izvršitelj. Proizvodi ono što mu je naloženo — ne ono što je potrebno. Tražiti od UI-a «napiši mi UART upravljač» daje UART upravljač. Ali ne onaj koji stvarno radi s ovom domenom takta, ovim rasporedom pinova, ovim vremenskim ponašanjem i ovim rukovanjem greškama u ciljnom okruženju.
Pravi inženjerski rad nije generiranje koda. To je pisanje precizne specifikacije: što točno mora biti, pod kojim uvjetima, s kojim tolerancijama, s kojim ponašanjem u slučaju greške, u kojem temperaturnom rasponu, kroz koji vijek trajanja.
Bolji UI tu ništa ne mijenja. Naprotiv: što su alati moćniji, to je presudnije pravilno ih uputiti.
UI ne dodaje zahtjeve na koje naručitelj nije pomislio. Ne izmišlja posebne slučajeve. Isporučuje točno ono što je u specifikaciji — i ništa više. Što nije specificirano, nedostaje u rezultatu.
Time se rizik u potpunosti pomiče na samu specifikaciju. Neiskusna specifikacija ispravno opisuje ono što je kupac tražio i previđa sve što sastavljač nikad nije doživio: rijedak otkaz senzora kod određenih temperaturnih gradijenata, ponašanje pri istovremenom brown-outu i blokadi sabirnice I²C, watchdog reset tijekom sekvence pisanja u flash, elektromagnetsko spregivanje na dugim kablovima senzora, ponašanje pri ponovnom pokretanju nakon nenamjernog reseta tijekom kritične operacije pisanja.
Takve točke nisu zahtjevi kupca. To su zahtjevi koje iskusni razvijatelj dodaje, znajući da inače ne bi nigdje stajali. Stoga je specifikacija uvijek i katalog rizika — a njegova dubina razmjerna je iskustvu sastavljača.
U sigurnosnom istraživanju infuzijskog uređaja, na koje me pozvao proizvođač medicinskih proizvoda, pojavila se kvar značajan za sigurnost koji je nastao istovremenim pojavljivanjem dvaju pojedinačnih kvarova: hardverskog otkaza memorijskog čipa i pogrešne provjerne rutine baš za taj čip. Svaki kvar zasebno bio je upravljiv. Tek je kombinacija proizvela neotkriveno stanje kvara.
Upravo ovu kombinacijsku analizu treba aktivno dodati u specifikaciju. Iz zahtjeva «provjeri memoriju» alat generira provjernu rutinu. Iz iskustva slijedi dodatni zahtjev da ni otkaz same provjerne rutine ne smije voditi tihom stanju kvara. Nijedan alat ne formulira ovaj drugi zahtjev sam.
K tome se pridružuju zamke blizu hardvera, koje ne stoje u podatkovnim listovima, već u glavama razvijatelja koji su ih već jednom morali tjerati:
Za većinu zadataka postoji više rješenja koja u načelu rade. Ali samo nekoliko ispunjava zahtjeve sigurnosti, pouzdanosti i vijeka trajanja koje konkretni proizvod treba.
Sustav UI bira ono što je u njegovim podacima za obuku bilo često. Iskusni razvijatelj bira ono što u sigurnosno značajnom sustavu ne vodi katastrofi. Ova odluka odabira nije implementacijski detalj. To je pravi inženjering.
U slučaju štete zakonodavac zahtijeva dokaz da je proizvod u trenutku stavljanja na tržište odgovarao stanju tehnike. To je središnji uvjet da se proizvođač može izvući iz odgovornosti za proizvod. S novom europskom Direktivom o odgovornosti za neispravne proizvode i nacionalnim zakonom o prijenosu koji iz nje proizlazi ovaj se teret dokaza izričito pooštrava za softver i softverski integrirane proizvode.
Stanje tehnike nije statično stanje. To je ono što se među stručnjacima smatra uobičajenim — i trenutačno se mijenja ubrzano jer novi alati i metode u kratkim ciklusima podižu tržišni standard.
Iz toga slijedi: tko danas razvija ugrađeni sustav, mora poznavati i primjenjivati aktualno snažnije metode. Tko to ne čini, stvara za svog naručitelja konkretan rizik odgovornosti. To upravo pretpostavlja razvijatelja koji vlada i utvrđenim i novim alatima i može napraviti ispravan izbor.
Koristim alate UI tamo gdje mjerljivo štede vrijeme bez stvaranja rizika: prva skica boilerplatea, generiranje testbencheva, dokumentacija, provjera čitljivosti.
Ne koristim ih kao zamjenu za:
Rezultat: manje napora za rutinski rad, postojano visoka kvaliteta u zadacima koji projekt zaista nose, i dokumentirani razvojni proces koji odgovara trenutnom stanju tehnike.
Naručujete razvijatelja s više od 35 godina iskustva u FPGA i ugrađenim sustavima, koji poznaje aktualne alate i može prosuditi njihove granice. Ne dobivate ni «UI-generirani projekt» ni «projekt bez UI». Dobivate funkcionalan sustav za koji konkretna osoba preuzima odgovornost — i koji se u slučaju štete može dokazati kao razvijen prema stanju tehnike.
Ako imate ugrađeni projekt koji zahtijeva upravo ovu dubinu, razgovarajmo o tome izravno. Prvi razgovor i gruba procjena su besplatni i neobvezujući.