Генеративният ИИ променя част от разработката на вградени системи — но не определящата част. Какво се измести, какво се изостри и какво получавате като възложител.
Генеративният ИИ днес може да произвежда стандартни драйвери, прости автомати на състоянията и boilerplate код в SystemVerilog, VHDL, C или Python. Това е реално, полезно и намали труда за определени рутинни задачи.
От това възниква оправдан въпрос: какво още добавя опитен разработчик на вградени системи и FPGA в тази среда?
Отговорът е конкретен.
ИИ е бърз изпълнител. Произвежда това, което му е възложено — не това, което е необходимо. Заявка към ИИ «напиши ми UART драйвер» дава UART драйвер. Но не онзи, който действително работи с този часовников домейн, това разпределение на изводи, това времево поведение и тази обработка на грешки в целевата среда.
Същинската инженерна работа не е генерирането на код. Тя е написването на точна спецификация: какво точно трябва да се случва, при какви условия, с какви толеранси, с какво поведение при грешка, в какъв температурен диапазон, в какъв жизнен цикъл.
По-добрият ИИ не променя това. Напротив: колкото по-мощни стават инструментите, толкова по-решаващо е да бъдат правилно инструктирани.
ИИ не добавя изисквания, за които възложителят не е помислил. Не измисля специални случаи. Доставя точно това, което е в спецификацията — и нищо отвъд. Което не е специфицирано, липсва в резултата.
Така рискът се измества изцяло към самата спецификация. Неопитна спецификация описва правилно поисканото от клиента и пропуска всичко, което съставителят никога не е преживял: рядката повреда на сензор при определени температурни градиенти, поведението при едновременен brown-out и блокиране на шината I²C, watchdog reset по време на flash запис, електромагнитното свързване по дълги сензорни кабели, поведението при рестарт след неволен reset по време на критична операция за запис.
Такива точки не са изисквания на клиента. Това са изисквания, които опитен разработчик добавя, защото знае, че иначе никъде няма да фигурират. Затова спецификацията е винаги и каталог на рисковете — и нейната дълбочина е пропорционална на опита на този, който я съставя.
При проверка на безопасността на инфузионен апарат, на която бях привлечен от производител на медицински изделия, се прояви значима за безопасността повреда, възникнала от едновременното появяване на две отделни грешки: хардуерна неизправност на чип памет и погрешна проверочна процедура за точно този чип. Всяка грешка поотделно беше управляема. Едва комбинацията породи неоткритото неизправно състояние.
Именно този комбинаторен анализ трябва да се добави активно в спецификацията. От изискването «провери паметта» инструмент генерира проверочна процедура. От опита следва допълнителното изискване, че и отказът на самата проверочна процедура не бива да води до тихо неизправно състояние. Никой инструмент не формулира това второ изискване сам.
Към това се добавят близките до хардуера капани, които не са в технически листове, а в главите на разработчиците, които вече ги преследваха веднъж:
За повечето задачи има няколко решения, които по същество работят. Но само малко от тях изпълняват изискванията за безопасност, надеждност и срок на експлоатация, които конкретният продукт изисква.
Система с ИИ избира това, което е било често в обучителните данни. Опитен разработчик избира това, което в значима за безопасността система не води до катастрофа. Това решение за избор не е детайл на реализация. То е същинският инженеринг.
При щета законодателят изисква доказателство, че продуктът към момента на пускане на пазара е съответствал на нивото на техниката. Това е централното условие производителят да може да се изключи от отговорността за продукта. С новата европейска Директива за отговорност за дефектни продукти и националния закон за транспониране, който я следва, това доказателствено бреме се изостря изрично за софтуер и продукти с интегриран софтуер.
Нивото на техниката не е статично състояние. То е това, което между специалисти се счита за обичайно — и в момента се променя ускорено, защото нови инструменти и методи в кратки цикли повишават пазарния стандарт.
От това следва: който днес разработва вградена система, трябва да познава и да прилага актуално по-мощните методи. Който не го прави, създава за възложителя си конкретен риск от отговорност. Това именно изисква разработчик, който владее както утвърдените, така и новите инструменти и може да направи правилния избор.
Използвам инструменти на ИИ там, където измеримо пестят време, без да създават рискове: първа чернова на boilerplate, генериране на testbench-ове, документация, проверка на четивност.
Не ги използвам като заместител на:
Резултатът: по-малко усилия за рутинна работа, постоянно високо качество в задачите, които действително носят проекта, и документиран процес на разработка, отговарящ на актуалното ниво на техниката.
Възлагате на разработчик с над 35 години опит във FPGA и вградени системи, който познава актуалните инструменти и може да преценява границите им. Не получавате нито «проект, генериран от ИИ», нито «проект без ИИ». Получавате работеща система, за която конкретно лице поема отговорност — и която при щета може да се докаже като разработена в съответствие с нивото на техниката.
Ако имате вграден проект, който изисква именно тази дълбочина, да говорим директно. Първи разговор и груба оценка са безплатни и без ангажимент.