Generatywna SI zmienia część rozwoju systemów wbudowanych — ale nie tę decydującą. Co się przesunęło, co się zaostrzyło i co Państwo jako zleceniodawca otrzymują.
Generatywna SI potrafi dziś wytwarzać standardowe sterowniki, proste automaty stanu i kod boilerplate w SystemVerilog, VHDL, C lub Python. To realne, użyteczne i zmniejsza nakład pracy dla niektórych zadań rutynowych.
Powstaje uzasadnione pytanie: co jeszcze wnosi doświadczony deweloper systemów wbudowanych i FPGA w tym otoczeniu?
Odpowiedź jest konkretna.
SI to szybki wykonawca. Wytwarza to, co zostało jej polecone — nie to, co konieczne. Polecenie SI «napisz mi sterownik UART» daje sterownik UART. Ale nie taki, który rzeczywiście działa z tą domeną zegarową, tym przypisaniem wyprowadzeń, tym zachowaniem czasowym i tą obsługą błędów w środowisku docelowym.
Właściwa praca inżynierska to nie generowanie kodu. To pisanie precyzyjnej specyfikacji: co dokładnie ma się dziać, w jakich warunkach, z jakimi tolerancjami, z jakim zachowaniem w przypadku błędu, w jakim zakresie temperatur, przez jaki czas eksploatacji.
Lepsza SI niczego w tym nie zmienia. Wręcz przeciwnie: im potężniejsze stają się narzędzia, tym bardziej decydujące staje się ich poprawne instruowanie.
SI nie dodaje wymagań, o których zleceniodawca nie pomyślał. Nie wymyśla przypadków szczególnych. Dostarcza dokładnie to, co jest w specyfikacji — i nic ponad to. To, czego nie wyspecyfikowano, brakuje w wyniku.
Tym samym ryzyko przenosi się w całości na samą specyfikację. Niedoświadczona specyfikacja opisuje poprawnie to, czego klient zażądał, i pomija wszystko, czego autor nigdy nie doświadczył: rzadką awarię czujnika przy określonych gradientach temperatury, zachowanie podczas jednoczesnego brown-out i zablokowania magistrali I²C, reset watchdoga podczas sekwencji zapisu flash, sprzężenie elektromagnetyczne na długich przewodach czujników, zachowanie po restarcie po nieumyślnym resecie podczas krytycznej operacji zapisu.
Takie punkty nie są wymaganiami klienta. Są wymaganiami, które doświadczony deweloper dodaje, wiedząc, że w przeciwnym razie nie znalazłyby się nigdzie. Dlatego specyfikacja jest zawsze również katalogiem ryzyka — a jego głębokość jest proporcjonalna do doświadczenia jej autora.
W trakcie analizy bezpieczeństwa pompy infuzyjnej, do której zostałem wezwany przez producenta wyrobów medycznych, ujawniła się usterka istotna dla bezpieczeństwa, która powstała z jednoczesnego wystąpienia dwóch pojedynczych błędów: awarii sprzętowej układu pamięci i wadliwej procedury weryfikacyjnej dla właśnie tego układu. Każdy błąd z osobna był do opanowania. Dopiero połączenie wytworzyło niewykryty stan błędu.
Właśnie ta analiza kombinacji musi zostać aktywnie dodana do specyfikacji. Z wymagania «sprawdzaj pamięć» narzędzie generuje procedurę sprawdzającą. Z doświadczenia wynika dodatkowe wymaganie, by również awaria samej procedury sprawdzającej nie prowadziła do cichego stanu błędu. Żadne narzędzie nie formułuje tego drugiego wymagania samodzielnie.
Do tego dochodzą pułapki bliskie sprzętowi, które nie figurują w kartach katalogowych, lecz w głowach deweloperów, którzy już je raz tropili:
Dla większości zadań istnieje wiele rozwiązań, które zasadniczo działają. Lecz tylko nieliczne z nich spełniają wymagania bezpieczeństwa, niezawodności i czasu eksploatacji, których wymaga konkretny produkt.
System SI wybiera to, co często występowało w jego danych treningowych. Doświadczony deweloper wybiera to, co w systemie istotnym dla bezpieczeństwa nie prowadzi do katastrofy. Ta decyzja wyboru nie jest szczegółem implementacyjnym. To właściwa inżynieria.
W przypadku szkody ustawodawca wymaga dowodu, że produkt w chwili wprowadzenia na rynek odpowiadał stanowi techniki. Jest to centralny warunek umożliwiający producentowi uniknięcie odpowiedzialności za produkt. Wraz z nową dyrektywą UE w sprawie odpowiedzialności za produkt i wynikającą z niej krajową ustawą wdrażającą ten ciężar dowodu jest wyraźnie zaostrzany dla oprogramowania i produktów zintegrowanych z oprogramowaniem.
Stan techniki nie jest stanem statycznym. Jest tym, co wśród fachowców uchodzi za zwyczajowe — i obecnie zmienia się przyspieszono, ponieważ nowe narzędzia i metody w krótkich cyklach podnoszą standard rynkowy.
Wynika z tego: kto dziś rozwija system wbudowany, musi znać i stosować obecnie sprawniejsze metody. Kto tego nie robi, tworzy dla swojego zleceniodawcy konkretne ryzyko odpowiedzialności. To wymaga właśnie dewelopera, który opanował zarówno ustalone, jak i nowe narzędzia i potrafi dokonać właściwego wyboru.
Używam narzędzi SI tam, gdzie wymiernie oszczędzają czas, nie tworząc ryzyka: wstępny szkic boilerplate, generowanie testbenchy, dokumentacja, kontrola czytelności.
Nie używam ich jako zastępstwa dla:
Wynik: mniejszy nakład na pracę rutynową, niezmiennie wysoka jakość w zadaniach, które rzeczywiście niosą projekt, i udokumentowany proces rozwoju zgodny z aktualnym stanem techniki.
Zlecają Państwo pracę deweloperowi z ponad 35-letnim doświadczeniem w FPGA i systemach wbudowanych, który zna aktualne narzędzia i potrafi ocenić ich granice. Nie otrzymują Państwo ani «projektu wygenerowanego przez SI», ani «projektu wolnego od SI». Otrzymują Państwo działający system, za który konkretna osoba bierze odpowiedzialność — i który w przypadku szkody jest dowodliwie rozwijany zgodnie ze stanem techniki.
Jeśli mają Państwo projekt wbudowany, który wymaga właśnie tej głębi, omówmy to bezpośrednio. Pierwsza rozmowa i wstępna ocena są bezpłatne i niezobowiązujące.