Generativni UI spreminja del razvoja vgrajenih sistemov — ne pa odločilnega dela. Kaj se je premaknilo, kaj se je zaostrilo in kaj kot naročnik prejmete.
Generativni UI lahko danes proizvaja standardne gonilnike, preproste avtomate stanj in boilerplate kodo v SystemVerilog, VHDL, C ali Python. To je resnično, koristno in je zmanjšalo trud za določene rutinske naloge.
Iz tega izhaja upravičeno vprašanje: kaj še doprinaša izkušen razvijalec vgrajenih sistemov in FPGA v tem okolju?
Odgovor je konkreten.
UI je hiter izvajalec. Proizvaja, kar mu naročite — ne tega, kar je potrebno. Zahteva UI «napiši mi UART gonilnik» da UART gonilnik. Ne pa tistega, ki resnično deluje s to urino domeno, to razporeditvijo priključkov, tem časovnim obnašanjem in to obravnavo napak v ciljnem okolju.
Pravo inženirsko delo ni generiranje kode. Je zapis natančne specifikacije: kaj točno naj se zgodi, pod katerimi pogoji, s katerimi tolerancami, s kakšnim obnašanjem ob napaki, v katerem temperaturnem območju, v kakšni življenjski dobi.
Boljši UI tega ne spremeni. Nasprotno: čim močnejša postanejo orodja, tem bolj odločilno je, da jih pravilno usmerjate.
UI ne dodaja zahtev, na katere naročnik ni pomislil. Ne izumlja posebnih primerov. Dostavlja točno to, kar je v specifikaciji — in nič več. Kar ni specificirano, manjka v rezultatu.
Tako se tveganje v celoti prenese na samo specifikacijo. Neizkušena specifikacija pravilno opisuje, kar je stranka zahtevala, in spregleda vse, česar avtor ni nikoli doživel: redko odpoved senzorja pri določenih temperaturnih gradientih, obnašanje pri istočasnem brown-outu in zaklepanju vodila I²C, watchdog reset med zaporedjem zapisovanja flash, elektromagnetno sklopitev na dolgih senzorskih kablih, obnašanje pri ponovnem zagonu po nenamernem resetu med kritično operacijo zapisovanja.
Take točke niso zahteve stranke. So zahteve, ki jih izkušen razvijalec doda, ker ve, da sicer nikjer ne bi bile zapisane. Specifikacija je zato vedno tudi katalog tveganj — in njegova globina je sorazmerna izkušnjam tistega, ki jo sestavi.
Pri varnostni preiskavi infuzijske naprave, na katero me je povabil proizvajalec medicinskih pripomočkov, se je pojavila varnostno pomembna napaka, ki je nastala iz sočasnega pojava dveh posameznih napak: strojne odpovedi pomnilniškega vezja in napačne kontrolne rutine prav za to vezje. Vsaka napaka posebej je bila obvladljiva. Šele kombinacija je proizvedla nezaznano napačno stanje.
Prav to kombinacijsko analizo je treba aktivno dodati v specifikacijo. Iz zahteve «preveri pomnilnik» orodje generira kontrolno rutino. Iz izkušenj sledi dodatna zahteva, da tudi odpoved same kontrolne rutine ne sme voditi v tiho napačno stanje. Nobeno orodje te druge zahteve ne formulira samo od sebe.
K temu se pridružijo strojno blizu pasti, ki ne stojijo v podatkovnih listih, ampak v glavah razvijalcev, ki so jih že morali enkrat loviti:
Za večino nalog obstaja več rešitev, ki načeloma delujejo. Vendar le malo izmed njih izpolnjuje zahteve glede varnosti, zanesljivosti in življenjske dobe, ki jih zahteva konkreten izdelek.
Sistem UI izbere tisto, kar se je v njegovih učnih podatkih pogosto pojavljalo. Izkušen razvijalec izbere tisto, kar v varnostno pomembnem sistemu ne vodi v katastrofo. Ta odločitev izbire ni implementacijska podrobnost. Je pravo inženirstvo.
V primeru škode zakonodajalec zahteva dokaz, da je izdelek v trenutku dajanja na trg ustrezal stanju tehnike. To je osrednji pogoj, da se proizvajalec lahko izgovori iz odgovornosti za izdelek. Z novo evropsko Direktivo o odgovornosti za izdelke z napako in nacionalnim zakonom o prenosu, ki iz nje izhaja, se to dokazno breme izrecno zaostruje za programsko opremo in produkte z integrirano programsko opremo.
Stanje tehnike ni statično stanje. Je tisto, kar med strokovnjaki velja za običajno — in se trenutno spreminja pospešeno, ker nova orodja in metode v kratkih ciklih dvigujejo tržni standard.
Iz tega sledi: kdor danes razvija vgrajen sistem, mora poznati in uporabljati trenutno zmogljivejše metode. Kdor tega ne počne, ustvari za svojega naročnika konkretno tveganje odgovornosti. To zahteva natanko razvijalca, ki obvlada tako uveljavljena kot nova orodja in zna narediti pravo izbiro.
Orodja UI uporabljam tam, kjer merljivo prihranijo čas brez ustvarjanja tveganj: prvi osnutek boilerplate, generiranje testbenchev, dokumentacija, preverjanje berljivosti.
Ne uporabljam jih kot nadomestilo za:
Rezultat: manj truda za rutinsko delo, dosledno visoka kakovost pri nalogah, ki dejansko nosijo projekt, in dokumentiran razvojni proces, ki ustreza trenutnemu stanju tehnike.
Naročate razvijalca z več kot 35-letnimi izkušnjami v FPGA in vgrajenih sistemih, ki pozna trenutna orodja in zna oceniti njihove meje. Ne prejmete niti «projekta, ki ga je generiral UI», niti «projekta brez UI». Prejmete delujoč sistem, za katerega konkretna oseba prevzame odgovornost — in ki se v primeru škode lahko dokaže kot razvit po stanju tehnike.
Če imate vgrajeni projekt, ki zahteva natanko to globino, govorimo o tem neposredno. Prvi pogovor in groba ocena sta brezplačna in nezavezujoča.