Generatívna UI mení časť vývoja vstavaných systémov — nie však tú rozhodujúcu. Čo sa posunulo, čo sa vyostrilo a čo ako zadávateľ dostávate.
Generatívna UI dnes dokáže produkovať štandardné ovládače, jednoduché stavové automaty a boilerplate kód v SystemVerilog, VHDL, C alebo Pythone. Je to reálne, užitočné a znížilo to úsilie pri určitých rutinných úlohách.
Z toho vyplýva oprávnená otázka: čo ešte v tomto prostredí prináša skúsený vývojár vstavaných systémov a FPGA?
Odpoveď je konkrétna.
UI je rýchly vykonávateľ. Produkuje to, čo sa jej zadá — nie to, čo je potrebné. Požiadať UI o «napíš mi UART ovládač» dá UART ovládač. Nie však ten, ktorý skutočne pracuje s touto hodinovou doménou, týmto priradením vývodov, týmto časovým správaním a touto obsluhou chýb v cieľovom prostredí.
Vlastný inžiniersky výkon nie je generovanie kódu. Je ním napísanie presnej špecifikácie: čo presne sa má stať, za akých podmienok, s akými toleranciami, s akým správaním pri chybe, v akom rozsahu teplôt, počas akej životnosti.
Lepšia UI na tom nič nezmení. Naopak: čím výkonnejšie sa nástroje stávajú, tým rozhodnejšie je správne ich inštruovať.
UI nedopĺňa požiadavky, na ktoré zadávateľ nemyslel. Nevymýšľa zvláštne prípady. Dodáva presne to, čo je v špecifikácii — a nič nad to. Čo nie je špecifikované, chýba vo výsledku.
Tým sa riziko prenáša úplne na samotnú špecifikáciu. Neskúsená špecifikácia správne opisuje, čo si zákazník vyžiadal, a prehliada všetko, čo autor nikdy nezažil: zriedkavé zlyhanie senzora pri určitých teplotných gradientoch, správanie pri súčasnom brown-oute a zablokovaní zbernice I²C, reset watchdogu počas zápisovej sekvencie flash, elektromagnetickú väzbu na dlhých kábloch senzorov, správanie pri reštarte po neúmyselnom resete počas kritickej zápisovej operácie.
Takéto body nie sú požiadavky zákazníka. Sú to požiadavky, ktoré skúsený vývojár dopĺňa, lebo vie, že inak by sa nikde neuvádzali. Špecifikácia je preto vždy aj katalóg rizík — a jeho hĺbka je úmerná skúsenosti toho, kto ju zostavuje.
Pri bezpečnostnom vyšetrovaní infúzneho zariadenia, ku ktorému ma prizval výrobca zdravotníckych pomôcok, sa prejavila bezpečnostne významná porucha, ktorá vznikla súčasným výskytom dvoch jednotlivých závad: hardvérovým zlyhaním pamäťového obvodu a chybnou kontrolnou rutinou práve pre tento obvod. Každá závada osobitne bola zvládnuteľná. Až kombinácia vyvolala nezistený chybový stav.
Práve táto kombinačná analýza musí byť do špecifikácie aktívne doplnená. Z požiadavky «kontroluj pamäť» nástroj vygeneruje kontrolnú rutinu. Zo skúsenosti vyplýva ďalšia požiadavka, že zlyhanie samotnej kontrolnej rutiny nesmie viesť k tichému chybovému stavu. Žiadny nástroj túto druhú požiadavku sám neformuluje.
K tomu pribúdajú úskalia blízke hardvéru, ktoré nestoja v dátových listoch, ale v hlavách vývojárov, ktorí ich už raz museli prenasledovať:
Pre väčšinu úloh existuje viacero riešení, ktoré zásadne fungujú. Ale len niektoré z nich spĺňajú požiadavky na bezpečnosť, spoľahlivosť a životnosť, ktoré konkrétny produkt potrebuje.
Systém UI vyberá to, čo bolo v jeho trénovacích dátach časté. Skúsený vývojár vyberá to, čo v bezpečnostne významnom systéme nevedie ku katastrofe. Toto rozhodnutie o výbere nie je implementačný detail. Je to vlastné inžinierstvo.
V prípade škody zákonodarca vyžaduje dôkaz, že produkt v okamihu uvedenia na trh zodpovedal stavu techniky. To je ústredná podmienka, aby sa výrobca mohol vyargumentovať zo zodpovednosti za výrobok. S novou európskou smernicou o zodpovednosti za chybné výrobky a nadväzujúcim národným transpozičným zákonom sa toto bremeno dôkazu výslovne sprísňuje pre softvér a softvérovo integrované produkty.
Stav techniky nie je statický stav. Je to to, čo je medzi odborníkmi považované za obvyklé — a momentálne sa mení zrýchlene, lebo nové nástroje a metódy v krátkych cykloch zvyšujú trhový štandard.
Z toho vyplýva: kto dnes vyvíja vstavaný systém, musí poznať a nasadzovať aktuálne výkonnejšie metódy. Kto tak nekoná, vytvára pre svojho zadávateľa konkrétne riziko zodpovednosti. To si vyžaduje práve vývojára, ktorý ovláda zavedené aj nové nástroje a dokáže urobiť správnu voľbu.
Používam nástroje UI tam, kde merateľne šetria čas bez vytvárania rizík: prvý návrh boilerplate, generovanie testbenchov, dokumentácia, kontrola čitateľnosti.
Nepoužívam ich ako náhradu za:
Výsledok: menej úsilia pri rutinnej práci, trvalo vysoká kvalita pri úlohách, ktoré projekt skutočne nesú, a zdokumentovaný vývojový proces, ktorý zodpovedá súčasnému stavu techniky.
Poveríte vývojára s viac ako 35 rokmi skúseností vo FPGA a vstavaných systémoch, ktorý pozná aktuálne nástroje a vie posúdiť ich hranice. Nedostávate ani «projekt vygenerovaný UI», ani «projekt bez UI». Dostávate funkčný systém, za ktorý konkrétna osoba preberá zodpovednosť — a ktorý možno v prípade škody preukázať ako vyvinutý podľa stavu techniky.
Ak máte vstavaný projekt, ktorý vyžaduje práve túto hĺbku, hovorme o tom priamo. Prvý rozhovor a hrubé zhodnotenie sú bezplatné a nezáväzné.