Ģeneratīvais MI maina daļu iebūvēto sistēmu izstrādes — taču ne izšķirošo daļu. Kas ir pārvietojies, kas ir saasinājies, un ko jūs kā pasūtītājs saņemat.
Ģeneratīvais MI šodien spēj radīt standarta draiverus, vienkāršus stāvokļu automātus un boilerplate kodu valodās SystemVerilog, VHDL, C vai Python. Tas ir reāli, noderīgi un ir samazinājis darbu noteiktiem rutīnas uzdevumiem.
No tā rodas pamatots jautājums: ko vēl sniedz pieredzējis iebūvēto sistēmu un FPGA izstrādātājs šajā vidē?
Atbilde ir konkrēta.
MI ir ātrs izpildītājs. Tas ražo to, kas tam tiek uzdots — nevis to, kas ir nepieciešams. Lūgt MI «uzraksti man UART draiveri» dod UART draiveri. Bet ne to, kas patiesi darbojas ar šo pulksteņa domēnu, šo izvadu piešķiršanu, šo laika uzvedību un šo kļūdu apstrādi mērķa vidē.
Patiesais inženiera darbs nav koda ģenerēšana. Tas ir precīzas specifikācijas rakstīšana: kas tieši notiks, ar kādiem nosacījumiem, ar kādām pielaidēm, ar kādu uzvedību kļūdas gadījumā, kādā temperatūras diapazonā, cik ilgu kalpošanas laiku.
Labāks MI to nemaina. Gluži otrādi: jo jaudīgāki kļūst rīki, jo izšķirošāk ir tos pareizi instruēt.
MI nepievieno prasības, par kurām pasūtītājs nav domājis. Tas neizgudro īpašos gadījumus. Tas piegādā tieši to, kas ir specifikācijā — un neko vairāk. Kas nav specificēts, trūkst rezultātā.
Tādējādi risks pilnībā pārvietojas uz pašu specifikāciju. Nepieredzējusi specifikācija pareizi apraksta to, ko klients lūdza, un nepamana visu, ko sastādītājs nekad nav piedzīvojis: reto sensora atteici noteiktos temperatūras gradientos, uzvedību vienlaicīga brown-out un I²C kopnes bloķēšanas laikā, watchdog reset zibatmiņas rakstīšanas secības laikā, elektromagnētisko savienošanos garās sensoru kabeļos, uzvedību pārstartēšanā pēc nejauša reseta kritiskas rakstīšanas operācijas laikā.
Šādi punkti nav klienta prasības. Tās ir prasības, kuras pieredzējis izstrādātājs pievieno, zinot, ka citādi tās nekur nebūtu. Tāpēc specifikācija vienmēr ir arī risku katalogs — un tā dziļums ir proporcionāls tās sastādītāja pieredzei.
Veicot drošības izpēti infūzijas ierīcei, uz kuru mani uzaicināja medicīnas ierīču ražotājs, parādījās drošībai nozīmīga atteice, kas radās no divu atsevišķu kļūdu vienlaicīgas parādīšanās: atmiņas mikroshēmas aparatūras atteices un kļūdainas pārbaudes rutīnas tieši šai mikroshēmai. Katra kļūda atsevišķi bija pārvaldāma. Tikai kombinācija radīja neatklātu kļūdas stāvokli.
Tieši šī kombinētā analīze ir aktīvi jāpievieno specifikācijā. No prasības «pārbaudi atmiņu» rīks ģenerē pārbaudes rutīnu. No pieredzes izriet papildu prasība, ka arī pašas pārbaudes rutīnas atteice nedrīkst novest pie klusa kļūdas stāvokļa. Neviens rīks šo otro prasību pats neformulē.
Tam pievienojas aparatūrai tuvas lamatas, kas nav datu lapās, bet izstrādātāju galvās, kuri tās jau vienreiz ir vajājuši:
Lielākajai daļai uzdevumu ir vairāki risinājumi, kas principā darbojas. Bet tikai daži no tiem atbilst drošības, uzticamības un kalpošanas laika prasībām, kuras konkrētais produkts prasa.
MI sistēma izvēlas to, kas tās apmācības datos bija biežs. Pieredzējis izstrādātājs izvēlas to, kas drošībai nozīmīgā sistēmā nenoved pie katastrofas. Šis izvēles lēmums nav implementācijas detaļa. Tas ir patiesais inženierija.
Bojājuma gadījumā likumdevējs prasa pierādījumu, ka produkts laižot tirgū atbilda tehnikas līmenim. Tas ir centrālais nosacījums, lai ražotājs varētu izsoļāties no produkta atbildības. Ar jauno Eiropas Direktīvu par atbildību par produktiem ar trūkumiem un tai sekojošo nacionālo transponēšanas likumu šī pierādīšanas slogs tiek skaidri pastiprināts attiecībā uz programmatūru un programmatūras integrētajiem produktiem.
Tehnikas līmenis nav statisks stāvoklis. Tas ir tas, ko speciālistu vidū uzskata par parastu — un pašlaik mainās paātrinātā tempā, jo jauni rīki un metodes īsos ciklos paaugstina tirgus standartu.
No tā izriet: kas šodien izstrādā iebūvētu sistēmu, jāzina un jālieto pašreiz jaudīgākās metodes. Kas to nedara, savam pasūtītājam rada konkrētu atbildības risku. Tas tieši pieprasa izstrādātāju, kurš pārvalda gan iedibinātos, gan jaunos rīkus un var izdarīt pareizo izvēli.
Lietoju MI rīkus tur, kur tie izmērāmi taupa laiku, neradot riskus: boilerplate pirmais melnraksts, testbench ģenerēšana, dokumentācija, lasāmības pārbaude.
Nelietoju tos kā aizvietojumu šādiem:
Rezultāts: mazāk darba rutīnas darbam, pastāvīgi augsta kvalitāte uzdevumos, kas projektu patiesi nes, un dokumentēts izstrādes process, kas atbilst pašreizējam tehnikas līmenim.
Pilnvarojat izstrādātāju ar vairāk nekā 35 gadu pieredzi FPGA un iebūvētajos, kurš pārzina pašreizējos rīkus un spēj novērtēt to robežas. Jūs nesaņemat ne «MI ģenerētu projektu» ne «MI brīvu projektu». Jūs saņemat funkcionējošu sistēmu, par kuru konkrēta persona uzņemas atbildību — un kura bojājuma gadījumā ir pierādāmi izstrādāta saskaņā ar tehnikas līmeni.
Ja jums ir iebūvētais projekts, kas pieprasa tieši šādu dziļumu, parunāsim par to tieši. Pirmā saruna un aptuvena novērtēšana ir bezmaksas un nesaistošas.