A generatív MI a beágyazott fejlesztés egy részét megváltoztatja — de nem a meghatározó részét. Mi tolódott el, mi élesedett, és mit kap megbízóként.
A generatív MI ma már képes szabványos meghajtókat, egyszerű állapotgépeket és boilerplate kódot előállítani SystemVerilog, VHDL, C vagy Python nyelven. Ez valós, hasznos, és csökkentette egyes rutinfeladatok ráfordítását.
Ebből jogos kérdés adódik: mit ad még egy tapasztalt beágyazott és FPGA-fejlesztő ebben a környezetben?
A válasz konkrét.
Az MI gyors végrehajtó. Azt állítja elő, amit kérnek tőle — nem azt, ami szükséges. Egy MI-tól «írj nekem egy UART meghajtót» kérni UART meghajtót ad. De nem azt, ami ezzel az órajeltartománnyal, ezzel a tűkiosztással, ezzel az időzítési viselkedéssel és ezzel a hibakezeléssel a célkörnyezetben valóban működik.
A tényleges mérnöki munka nem a kódgenerálás. Pontos specifikáció írása: mi pontosan történjen, milyen feltételek mellett, milyen tűréssel, milyen viselkedéssel hibaesetén, milyen hőmérsékleti tartományban, milyen élettartam alatt.
Jobb MI ezen mit sem változtat. Sőt: minél erősebbek lesznek az eszközök, annál meghatározóbb a helyes utasításuk.
Az MI nem egészíti ki olyan követelményekkel, amelyekre a megbízó nem gondolt. Nem talál ki különleges eseteket. Pontosan azt szállítja, ami a specifikációban van — és semmi azon túl. Ami nincs specifikálva, az hiányzik az eredményből.
Ezzel a kockázat teljes egészében magára a specifikációra tolódik. A tapasztalatlan specifikáció helyesen írja le, amit az ügyfél kért, és mindazt elnézi, amit a szerző soha nem élt át: a ritka érzékelőhibát bizonyos hőmérsékleti gradienseknél, az egyidejű brown-out és I²C buszzár alatti viselkedést, a watchdog-resetet flash íráskor, az elektromágneses csatolást hosszú érzékelőkábeleken, az újraindulási viselkedést szándékolatlan reset után, kritikus íráskor.
Az ilyen pontok nem ügyfélkövetelmények. Olyan követelmények, amelyeket a tapasztalt fejlesztő hozzáad, mert tudja, hogy különben sehol nem szerepelnének. Egy specifikáció ezért egyúttal mindig kockázati katalógus is — és mélysége arányos a szerzője tapasztalatával.
Egy infúziós készülék biztonsági vizsgálatánál, amelyhez orvostechnikai gyártó hívott meg, biztonsági szempontból fontos hiba mutatkozott meg, amely két egyedi hiba egyidejű előfordulásából állt elő: egy memóriaáramkör hardveres meghibásodásából és az ezen áramkörre vonatkozó hibás ellenőrző rutinból. Mindegyik hiba külön-külön kezelhető volt. Csak a kombináció hozta létre a fel nem ismert hibás állapotot.
Pontosan ezt a kombinációs megfontolást kell egy specifikációba aktívan felvenni. Az «ellenőrizd a memóriát» követelményből egy eszköz ellenőrző rutint generál. A tapasztalatból az a további követelmény adódik, hogy magának az ellenőrző rutinnak a meghibásodása se vezethessen néma hibás állapothoz. Ezt a második követelményt egyetlen eszköz sem fogalmazza meg magától.
Ehhez társulnak a hardverközeli buktatók, amelyek nem az adatlapokon, hanem azon fejlesztők fejében állnak, akik már egyszer üldözték őket:
A legtöbb feladatra több olyan megoldás létezik, amely alapvetően működik. De csak néhány teljesíti a biztonsági, megbízhatósági és élettartam-követelményeket, amelyeket a konkrét termék igényel.
Egy MI-rendszer azt választja, ami a tanítóanyagában gyakori volt. A tapasztalt fejlesztő azt választja, ami a biztonság szempontjából releváns rendszerben nem vezet katasztrófához. Ez a választási döntés nem implementációs részlet. Ez a tényleges mérnöki munka.
Kártesemény esetén a jogalkotó bizonyítást követel arra, hogy a termék a forgalomba hozatal időpontjában megfelelt a technika állásának. Ez a központi feltétele annak, hogy a gyártó a termékfelelősség alól kiérvelhesse magát. Az új EU termékfelelősségi irányelvvel és az azt követő nemzeti átültető törvénnyel ez a bizonyítási teher kifejezetten szigorodik a szoftverekre és szoftverbe integrált termékekre.
A technika állása nem statikus állapot. Az, ami a szakemberek körében szokásosnak számít — és jelenleg gyorsuló ütemben változik, mert új eszközök és módszerek rövid ciklusokban emelik a piaci szabványt.
Ebből következik: aki ma beágyazott rendszert fejleszt, ismernie és alkalmaznia kell a jelenleg erőteljesebb módszereket. Aki ezt nem teszi, megbízójának konkrét felelősségi kockázatot teremt. Ez éppenséggel olyan fejlesztőt kíván, aki mind a bevett, mind az új eszközöket uralja, és a helyes választást meg tudja hozni.
MI-eszközöket ott használok, ahol mérhetően időt takarítanak meg kockázat létrehozása nélkül: boilerplate első vázlata, testbench-generálás, dokumentáció, olvashatósági ellenőrzés.
Nem használom őket helyettesítőként az alábbiakra:
Az eredmény: kevesebb ráfordítás a rutinmunkára, állandóan magas minőség a projektet ténylegesen vivő feladatokon, valamint dokumentált fejlesztési folyamat, amely megfelel a technika jelenlegi állásának.
Olyan fejlesztőt bíz meg, aki több mint 35 év FPGA- és beágyazott tapasztalatot hoz, ismeri az aktuális eszközöket, és meg tudja ítélni azok határait. Nem «MI által generált projektet» kap, és nem is «MI-mentes projektet». Működő rendszert kap, amelyért egy konkrét személy vállalja a felelősséget — és amely kártesemény esetén bizonyíthatóan a technika állásának megfelelően készült.
Ha pontosan ilyen mélységet kívánó beágyazott projektje van, beszéljünk róla közvetlenül. Első beszélgetés és durva becslés ingyenes és kötelezettség nélküli.