FuSa eli Functional Safety viittaa käytäntöihin, tekniikoihin ja standardeihin, joilla pyritään varmistamaan, etteivät laitteet ole ihmisen kannalta vaarallisia. Nohau Solutionsin eilen järjestämässä FuSa-seminaarissa kävi hyvin ilmi, miten turvallisten laitteiden suunnittelusta on tulossa koko ajan vaativampaa.
Tuotekehitysyhtiö Huldin FuSa-expertti Anton Alexeev (kuvassa) nosti esiin turvallisuuden (safety) ja tietoturvan (security) eron. Teollisuuden OT-laitteet ovat toisaalta hyvin luotettavia, mutta toisaalta niitä on vaikeampi päivittää ja suojaus on vaikeampi toteuttaa.
Teollisuudessa on nähty haittaohjelmia, kuten Industroyer, Tritan ja taatusti tunnetuin Stuxnet, ja Ukrainan sähköverkko saatiin vuonna 2015 nurin Blackenergy-haitalla, mutta toisaalta ei ole tiedossa, että esimerkiksi verkkoon jatkuvasti liittyneisiin autoihin olisi päästy murtautumaan.
- Turvallisuus ja tietoturva ovat oikeastaan aina ristiriidassa. Jotenkin täytyy mahdollistaa esimerkiksi ohjelmistojen ja protokollien päivitys, Alexeev muistutti. Huldin ratkaisu on suunnittelumetodologia, jossa turvallisuus ja tietoturva on alusta asti integroitu mukaan samaan prosessiin.
- Suurin osa tietoturvallisuudesta ei liity turvallisuuteen vaan esimerkiksi käytettävyyteen. Tämän takia turvallisuus- ja tietoturvariskien arviointi - joihin viitataan termeillä HARA ja TARA - täytyy ottaa mukaan yhteiseen riskimatriisiin, Alexeev esitti.
Yksi erittäin haastava osa laitteiden kehitystä on niiden toiminnallinen testaaminen. QA-Systemsin toimitusjohtaja Matt Davis korosti, että FuSa on kovaa työtä.
- Sulautetun verifioinnissa pitää varmistaa, että koodi vastaa laatuvaatimuksia, tekee mitä sen pitää tehdä ja myös, ettei koodi tee sellaista, mitä se ei saa tehdä. Lopulta kyse on aina siitä, onko koodia testattu tarpeeksi, Davis evästi.
Testaustyökalujen pitää taipua sekä yksikköjen (koodilla toteutettujen toimintojen tai moduulien) että integroitujen moduulien testaukseen. Ja lopulta koko järjestelmän testaukseen. Simuloinnilla ei koskaan päästä täyteen varmuuteen, joten paras vaihtoehto olisi löytää testivektorit, jotka kattavat kaiken. Tämä on tietysti käytännössä mahdotonta.
QA-Systemsin ratkaisu on CANTATA-ympäristö, jossa testivektorit generoidaan suoraan lähdekoodista.