Generativní UI mění část vývoje vestavných systémů — ne však tu rozhodující. Co se posunulo, co se vyhrotilo a co jako zadavatel získáte.
Generativní UI dokáže dnes vytvářet standardní ovladače, jednoduché stavové automaty a boilerplate kód v SystemVerilog, VHDL, C nebo Python. Je to skutečné, je to užitečné a snížilo to úsilí pro některé rutinní úkoly.
Z toho vyplývá oprávněná otázka: co ještě v tomto prostředí přináší zkušený vývojář vestavných systémů a FPGA?
Odpověď je konkrétní.
UI je rychlý vykonavatel. Produkuje to, co je jí zadáno — ne to, co je třeba. Požádat UI o «napiš mi UART ovladač» dá UART ovladač. Ne však ten, který skutečně pracuje s touto hodinovou doménou, tímto přiřazením vývodů, tímto časovým chováním a touto obsluhou chyb v cílovém prostředí.
Vlastní inženýrský výkon není generování kódu. Je to napsání přesné specifikace: co přesně se má stát, za jakých podmínek, s jakými tolerancemi, s jakým chováním při chybě, v jakém teplotním rozsahu, po jakou životnost.
Lepší UI na tom nic nemění. Naopak: čím výkonnější se nástroje stávají, tím rozhodnější je je správně instruovat.
UI nedoplňuje požadavky, na které zadavatel nemyslel. Nevymýšlí zvláštní případy. Dodává přesně to, co je ve specifikaci — a nic navíc. Co není specifikováno, chybí ve výsledku.
Tím se riziko přenáší zcela na samotnou specifikaci. Nezkušená specifikace správně popisuje, co zákazník požadoval, a přehlíží vše, co autor nikdy nezažil: vzácné selhání senzoru při určitých teplotních gradientech, chování při současném brown-outu a zablokování sběrnice I²C, reset watchdogu během zápisové sekvence flash, elektromagnetickou vazbu na dlouhých kabelech senzorů, chování při restartu po nezamýšleném resetu během kritické zápisové operace.
Takové body nejsou požadavky zákazníka. Jsou to požadavky, které zkušený vývojář doplňuje, neboť ví, že jinak by nikde nefigurovaly. Specifikace je proto vždy také katalog rizik — a jeho hloubka je úměrná zkušenosti toho, kdo ji sepisuje.
Při bezpečnostním šetření infuzního zařízení, k němuž mě výrobce zdravotnických prostředků přizval, se projevila bezpečnostně významná porucha, která vznikla současným výskytem dvou jednotlivých závad: hardwarového selhání paměťového obvodu a chybné kontrolní rutiny právě pro tento obvod. Každá závada sama o sobě byla zvládnutelná. Teprve kombinace vyvolala nezjištěný chybový stav.
Právě tato kombinační analýza musí být ve specifikaci aktivně doplněna. Z požadavku «zkontroluj paměť» nástroj vygeneruje kontrolní rutinu. Ze zkušenosti plyne další požadavek, že selhání samotné kontrolní rutiny nesmí vést k tichému chybovému stavu. Žádný nástroj tento druhý požadavek sám neformuluje.
K tomu se přidávají úskalí blízká hardwaru, jež nestojí v datasheetech, nýbrž v hlavách vývojářů, kteří je už jednou museli pronásledovat:
Pro většinu úkolů existuje více řešení, která zásadně fungují. Ale jen několik z nich splňuje požadavky na bezpečnost, spolehlivost a životnost, které konkrétní produkt potřebuje.
Systém UI vybírá to, co se v jeho trénovacích datech vyskytovalo často. Zkušený vývojář vybírá to, co v bezpečnostně významném systému nevede ke katastrofě. Toto rozhodnutí o výběru není implementační detail. Je to vlastní inženýrství.
V případě škody zákonodárce vyžaduje důkaz, že produkt v okamžiku uvedení na trh odpovídal stavu techniky. To je ústřední podmínka, aby se výrobce mohl vyargumentovat z odpovědnosti za výrobek. S novou evropskou směrnicí o odpovědnosti za vadné výrobky a navazujícím národním prováděcím zákonem se toto důkazní břemeno výslovně zostřuje pro software a softwarově integrované produkty.
Stav techniky není statický stav. Je to to, co je mezi odborníky považováno za obvyklé — a v současnosti se mění zrychleně, neboť nové nástroje a metody v krátkých cyklech zvyšují tržní standard.
Z toho plyne: kdo dnes vyvíjí vestavný systém, musí znát a nasazovat aktuálně výkonnější metody. Kdo tak nečiní, vytváří pro svého zadavatele konkrétní riziko odpovědnosti. To právě vyžaduje vývojáře, který ovládá jak zavedené, tak nové nástroje a dokáže učinit správnou volbu.
Používám nástroje UI tam, kde měřitelně šetří čas, aniž by vytvářely riziko: první návrh boilerplate, generování testbenchů, dokumentace, kontrola čitelnosti.
Nepoužívám je jako náhradu za:
Výsledek: méně úsilí na rutinní práci, vytrvale vysokou kvalitu v úkolech, jež skutečně nesou projekt, a zdokumentovaný vývojový proces, který odpovídá aktuálnímu stavu techniky.
Pověřujete vývojáře s více než 35 lety zkušeností v FPGA a vestavných systémech, který zná aktuální nástroje a umí posoudit jejich meze. Nedostáváte ani «projekt vygenerovaný UI», ani «projekt bez UI». Dostáváte funkční systém, za který konkrétní osoba přebírá odpovědnost — a který lze v případě škody prokázat jako vyvinutý podle stavu techniky.
Máte-li vestavný projekt, jenž vyžaduje právě tuto hloubku, promluvme si o něm přímo. První rozhovor a hrubé zhodnocení jsou zdarma a nezávazné.