Generatiivinen tekoäly muuttaa osan sulautetusta kehityksestä — mutta ei ratkaisevaa osaa. Mikä on siirtynyt, mikä on kärjistynyt, ja mitä toimeksiantajana saat.
Generatiivinen tekoäly pystyy nykyään tuottamaan vakioajureita, yksinkertaisia tila-automaatteja ja boilerplate-koodia SystemVerilogilla, VHDL:llä, C:llä tai Pythonilla. Tämä on todellista, hyödyllistä, ja se on vähentänyt joidenkin rutiinitehtävien työmäärää.
Tästä syntyy oikeutettu kysymys: mitä kokenut sulautettujen järjestelmien ja FPGA:n kehittäjä tuo enää tähän ympäristöön?
Vastaus on konkreettinen.
Tekoäly on nopea suorittaja. Se tuottaa sen, mitä siltä pyydetään — ei sitä, mitä tarvitaan. Pyytää tekoälyä «kirjoittamaan minulle UART-ajurin» antaa UART-ajurin. Mutta ei sitä, joka oikeasti toimii tällä kellotaajuusalueella, tällä nasta-asetuksella, tällä ajoituskäyttäytymisellä ja tällä virheenkäsittelyllä kohdeympäristössä.
Varsinainen insinöörityö ei ole koodin tuottaminen. Se on täsmällisen määrittelyn kirjoittaminen: mitä tarkalleen pitää tapahtua, millä ehdoilla, millä toleransseilla, millä käyttäytymisellä virhetilanteessa, millä lämpötila-alueella, millä elinkaarella.
Parempi tekoäly ei muuta tätä. Päinvastoin: mitä tehokkaammiksi työkalut tulevat, sitä ratkaisevammaksi muuttuu niiden oikea ohjeistaminen.
Tekoäly ei lisää vaatimuksia, joita asiakas ei ole ajatellut. Se ei keksi erikoistapauksia. Se toimittaa täsmälleen sen, mikä määrittelyssä on — eikä mitään yli sen. Se, mitä ei ole määritelty, puuttuu lopputuloksesta.
Näin riski siirtyy kokonaan itse määrittelyyn. Kokematon määrittely kuvaa oikein sen, mitä asiakas on pyytänyt, ja jättää huomiotta kaiken, mitä laatija ei ole koskaan kokenut: harvinaisen anturivian tietyillä lämpötilagradienteilla, käyttäytymisen samanaikaisessa brown-outissa ja I²C-väylälukossa, watchdog-resetin flashin kirjoitusvaiheen aikana, sähkömagneettisen kytkennän pitkillä anturijohdoilla, käyttäytymisen uudelleenkäynnistyksessä tahattoman resetin jälkeen kriittisen kirjoitusvaiheen aikana.
Tällaiset kohdat eivät ole asiakkaan vaatimuksia. Ne ovat vaatimuksia, jotka kokenut kehittäjä lisää, koska tietää, että muuten ne eivät esiintyisi missään. Määrittely on siten aina myös riskiluettelo — ja sen syvyys on suoraan suhteessa laatijansa kokemukseen.
Eräässä infuusiolaitteen turvallisuustutkimuksessa, johon lääkintätekniikan valmistaja kutsui minut, ilmeni turvallisuuden kannalta merkittävä vika, joka syntyi kahden yksittäisvian samanaikaisesta esiintymisestä: muistipiirin laitteistovirheestä ja juuri tätä piiriä koskevasta virheellisestä tarkistusrutiinista. Kumpikin vika erikseen oli hallittavissa. Vasta yhdistelmä tuotti havaitsemattoman vikatilan.
Juuri tämä yhdistelmätarkastelu on lisättävä määrittelyyn aktiivisesti. Vaatimuksesta «tarkista muisti» työkalu tuottaa tarkistusrutiinin. Kokemuksesta seuraa lisävaatimus, että myös itse tarkistusrutiinin epäonnistuminen ei saa johtaa hiljaiseen vikatilaan. Mikään työkalu ei muotoile tätä toista vaatimusta itsestään.
Tähän liittyvät laitteistoläheiset sudenkuopat, jotka eivät esiinny tietolehdissä vaan niiden kehittäjien päissä, jotka ovat niitä jo kerran jahdanneet:
Useimpiin tehtäviin on olemassa useita ratkaisuja, jotka periaatteessa toimivat. Mutta vain harvat niistä täyttävät turvallisuus-, luotettavuus- ja elinikävaatimukset, joita konkreettinen tuote vaatii.
Tekoälyjärjestelmä valitsee sen, mikä esiintyi sen koulutusaineistossa usein. Kokenut kehittäjä valitsee sen, mikä ei johda katastrofiin turvallisuuden kannalta merkityksellisessä järjestelmässä. Tämä valintapäätös ei ole toteutusyksityiskohta. Se on varsinaista insinöörityötä.
Vahinkotapauksessa lainsäätäjä vaatii näytön siitä, että tuote vastasi markkinoille saatettaessa tekniikan tasoa. Tämä on keskeinen edellytys sille, että valmistaja voi argumentoida itsensä ulos tuotevastuusta. Uudella EU:n tuotevastuudirektiivillä ja siitä seuraavalla kansallisella täytäntöönpanolailla tätä todistustaakkaa kiristetään nimenomaisesti ohjelmistojen ja ohjelmistointegroitujen tuotteiden osalta.
Tekniikan taso ei ole staattinen tila. Se on se, mitä ammattilaisten kesken pidetään tavanomaisena — ja se muuttuu tällä hetkellä kiihtyvällä tahdilla, koska uudet työkalut ja menetelmät nostavat markkinastandardia lyhyissä jaksoissa.
Tästä seuraa: jokaisen, joka tänään kehittää sulautettua järjestelmää, on tunnettava ja käytettävä nykyisin tehokkaampia menetelmiä. Joka ei näin tee, luo toimeksiantajalleen konkreettisen vastuuriskin. Se edellyttää nimenomaan kehittäjää, joka hallitsee sekä vakiintuneet että uudet työkalut ja osaa tehdä oikean valinnan.
Käytän tekoälytyökaluja siellä, missä ne säästävät mitattavissa olevaa aikaa luomatta riskejä: boilerplate-koodin ensimmäiset luonnokset, testipenkkien generointi, dokumentointi, luettavuustarkistus.
En käytä niitä korvaamaan:
Tulos: vähemmän työtä rutiinityöhön, jatkuvasti korkea laatu niissä tehtävissä, jotka todella kantavat projektia, ja dokumentoitu kehitysprosessi, joka vastaa nykyistä tekniikan tasoa.
Tilaat kehittäjän, jolla on yli 35 vuoden kokemus FPGA:sta ja sulautetuista, joka tuntee nykyiset työkalut ja osaa arvioida niiden rajat. Et saa «tekoälyn tuottamaa projektia» etkä «tekoälytöntä projektia». Saat toimivan järjestelmän, josta konkreettinen henkilö ottaa vastuun — ja jonka voi vahinkotapauksessa todistaa kehitetyksi tekniikan tason mukaisesti.
Jos sinulla on sulautettu projekti, joka vaatii juuri tätä syvyyttä, puhutaan siitä suoraan. Ensikeskustelu ja karkea arvio ovat maksuttomia ja sitoumuksetta.