Simulointi on perusedellytys monimutkaisen järjestelmän onnistuneelle suunnittelulle, kehittämiselle ja testaamiselle. Yhdistämällä Wind Riverin Simicsin kaltainen tietokoneen simulointiohjelmisto fyysisen järjestelmän ja ympäristön simulaatioon voidaan koko järjestelmän kattavia testejä ajaa täysin automaattisesti niin usein kuin halutaan.

Tietokoneiden vakiintuneet simulointitekniikat, kuten virtuaaliset alustat, kykenevät täysin testaamaan koko tietokonejärjestelmän prosessoreineen ja ajamaan täydellisen koodin. Haasteena on kuitenkin se, että tietokonejärjestelmä itsessään on vain yksi osa laajempaa kokonaisjärjestelmää, joka pitää testata. Mukana voi olla valtava määrä muita komponentteja, verkkoja, antureita ja ohjelmistoja sen reaalimaailman lisäksi, jossa tai jonka kanssa vuorovaikutuksessa järjestelmä toimii.

Jos tarkastellaan esimerkiksi teollisen tuotantolaitoksen, junan tai tunnelinporauskaluston ohjausjärjestelmiä, ne eivät ole eristettyjä järjestelmiä, vaan laajemman kokonaisuuden osajärjestelmiä. Jotta päästäisiin tavoitteeseen, jota monet testaajat ovat pitäneet utopistisena, on kyettävä simuloimaan sekä ohjaustietokonetta, sen tueksi rakennettua järjestelmää että koko ulkopuolista maailmaa sen ympärillä. Tässä yhteydessä tarvitaan todennäköisesti yhden simuloinnin sijasta moniosaista simulointiprosessia useista eri kohteista, jotka kaikki kommunikoivat keskenään.

Kuva 1. Simuloitava kokonaisjärjestelmä.

Kuva 1 esittää, kuinka simuloitava kokonaisjärjestelmä jakautuu tietokonelohkoon, ohjattavaan järjestelmään ja ympäristöön. Ohjausohjelmistoa ajavan tietokoneen simulointiohjelmisto, tässä tapauksessa Wind Riverin Simics, on liitetty järjestelmän ja sen ympäristön ohjelmallisiin simulaattoreihin.

Joskus järjestelmä ympäristöineen on sisällytetty samaa malliin, esimerkiksi tehdasmalliin PIL-testauksessa (Processor-In-the-Loop), mutta useimmiten ne on erotettu eri simulaattoreille, jotka ovat eri työryhmien tai jopa eri yritysten vastuulla. On myös melko yleistä, että kukin osa on rakennettu erillisistä simulaattoreista erillisille osajärjestelmille.

Minkä tahansa tietokonejärjestelmän simulaatiorakennelman keskeinen ominaisuus on kyky suorittaa todellisen kohteen binääriset operaatiot muuttamattomina. Kaikki simulaattorit eivät tähän kykene, joten testaajan täytyy valita huolellisesti kaikki työkalunsa, sillä monet nykyiset simulointiohjelmistot perustuvat erilaisiin rakennekerrosten (shim) tai API-simulaatioiden muotoihin, jotta ohjelmisto toimisi moitteettomasti.

Muuttamattomien binäärioperaatioiden avulla ohjelmisto käännetään, linkitetään, integroidaan ja ajetaan aivan kuten reaalijärjestelmässäkin. Tämä parantaa simulaation käytettävyyttä järjestelmän useiden elinkaarijaksojen yli. Kuten yllä on esitetty, tulo- ja lähtöarvot siirretään läpi simuloitavan järjestelmän simulaattorin jäljittelemille tulo- ja lähtölaitteille. Arvot tavoittavat kohdeohjelmiston laiteajurien kautta aivan kuten tulee tapahtumaan reaalijärjestelmässäkin sitten, kun se on rakennettu.

Tällä tavoin koko integroitu ohjelmistopino voidaan testata virtuaalisessa reaaliympäristössä. Tämän ansiosta on mahdollista suorittaa automaattinen testaus ja jatkuva integraatio jopa järjestelmille, jotka ovat vahvasti sulautettuja ja kytkettyjä ympäristöönsä.

Jos ympäristö muuttuu, kaikki on testattava uudelleen. Ariane-kantoraketin tuhoutuminen vuonna 1996 antoi ankaran opetuksen siitä, kuinka tärkeä ympäristön merkitys on. Ariane 5 -raketin laukaisu epäonnistui ohjelmistovirheen vuoksi. Raketin ohjaamiseen käytettävä ohjelmisto oli ollut käytössä jo aiemmassa Ariane 4 -raketissa. Uudella raketilla oli kuitenkin aivan erilainen lentorata, minkä vuoksi ohjelmisto kaatui. Ohjelmiston kehitystiimi sai kovan opetuksen siitä, ettei korkealaatuisinkaan ohjelmisto ole täysin luotettava, ellei sitä ole testattu juuri siinä ympäristössä, jossa sitä tullaan lopullisesti käyttämään.

Ohjelmiston pienenkin osan käyttöympäristössä tapahtuvat muutokset voivat olla yhtä merkittäviä kuin muutokset itse ohjelmistossa. Joskus voi tuntua siltä, että testaamiseen kuluu liikaa aikaa, mutta se on ainoa tehokas tapa turvallisesti vähentää riskejä ja niihin liittyviä kustannuksia. Kun simulointia kohdistetaan myös laitteiston testaukseen, voidaan suorittaa enemmän testejä entistä nopeammin ja säästää aikaa sekä sallia enemmän what if -tyyppistä testausta.

Näin ollen ratkaisevan tärkeää on rakentaa integroitu simulointi kuvan 1 mukaisesti, ja siihen on monia tapoja. Kun työskennellään käyttäen Wind Riverin Simics-ohjelmistoa simulointikehyksenä, muut simulaattorit voidaan pitää erillään Simicsistä tai joissakin tapauksissa ajettuina Simicsin sisällä, kuten kuvasta 2 nähdään. On myös mahdollista sulauttaa Simics toiseen simulaattoriin. Simulaattorit voidaan levittää useille koneille tai ajettavaksi samalla koneella. Kaikki riippuu tilanteesta ja erilaisten simulointitekniikoiden vaatimuksista.

Kuva 2. Vaihtoehtoisia tapoja, kuinka useat simulaattorit voivat toimia yhdessä.

Kun käytetään useita simulaattoreita, jotkut ratkaisut ovat päästä-päähän-tyyppisiä, vaikka isäntä-renki-rakenteet ovatkin paljon yleisempiä, sillä ne voidaan yleensä helpommin liittää jälkikäteen olemassa oleviin simulaattoreihin. Niin kauan kuin valittavalla simulaattorilla on kaikki tarvittavat ominaisuudet ja liitännät, järjestelmän integrointi voidaan suorittaa.

Simics-ohjelmisto on onnistuttu integroimaan viime vuosina lukuisiin eri simulaattoreihin käyttämällä kaikkia rakennemuotoja, jotka nähdään kuvassa 2. Kaikkein yleisimmin käytössä on ratkaisu, jossa simulaattoreita ajetaan rinnakkain ja ne kommunikoivat keskenään verkkoliitäntöjen tai jaetun muistin kautta. Tällöin yksi simulaattori toimii isäntänä ja pyytää muita simulaattoreita toimimaan spesifioitujen toimintajaksojen aikana. Käytännössä mukana olevat simulaattorit ohjataan yleensä ajamaan itsenäisiä ohjelmia, mikä vaatii joskus jopa niiden omien erityisten isäntien käyttöä ohjelmien ajamiseen.

Kun otetaan huomioon tämä ilmeinen monimutkaisuus simuloinnin integroinnissa, on tärkeää tehdä asiat mahdollisimman helpoiksi simulointirakennelman loppukäyttäjälle. Tämän saavuttamiseksi rakennetaan simulointiasetelmalle yleensä jonkinlainen etulohko, joka huolehtii simulaattorien käynnistämisestä.

Kuten kuvasta 3 nähdään, etulohko käynnistää integroidut simulaattorit ja liittää ne toisiinsa. Kun simulaattorit ovat toiminnassa, käyttöliittymä voidaan tarjota käyttäjälle tai pitää piilossa. Etulohko voi olla niinkin yksinkertainen kuin komentojonotiedosto, joka käynnistää kaikki simulaattorit yhden konfiguraation perusteella. Toisaalta se voi yhtä hyvin olla täysimittainen räätälöity graafinen sovellus, joka huolehtii simuloinnin ajamisesta, kerää tulokset ja antaa käyttäjälle mahdollisuuden järjestelmän konfigurointiin.

Kuva 3. Etulohkoa hyödyntävä lähestymistapa useiden simulaattoreiden käyttämiseksi.

Sovellusten simuloinnin vaatimukset koettelevat edelleen simulointitekniikoiden rajoja. Hyvä esimerkki on IoT-sovellus. Siinä tietoverkosta riippuvaisen sovelluksen monimutkaisuus ja monimuotoisuus voi olla kauaskantoista. Mukana voi olla runsaasti pieniä verkkosolmuja, jotka kytkeytyvät toisiinsa ja verkon yhdyskäytäviin hyödyntämällä langatonta mesh-verkkotekniikkaa.

Yhdyskäytävät puolestaan kytkeytyvät hallintapalvelimeen tai pilveen. Pienet solmut voivat olla esimerkiksi lämpöantureita, sähkömittareita, kameroita, valokytkimiä tai erilaisia toimilaitteita kuten termostaatteja, valaisimia ja ovilukkoja.

Kuva 4. Integroitu IoT-simulaatio.

Kuvan 4 mukaisessa simulaattorissa laajan verkon luominen voi olla erittäin helppoa. Tarvitaan vain kirjoitettu ohjelma, joka virtuaalisesti asentaa ja levittää solmut yli tarvittavan virtuaalitilan ja sen jälkeen mallintaa solmujen väliset langattomat yhteydet. Kukin solmu, yhdyskäytävä tai palvelin ajaa samaa ohjelmistopinoa kuin se tekisi myös reaalimaailmassa, ja ympäröivän maailman simulaattorit kytkeytyvät antureihin ja toimilaitteisiin sekä simuloivat langattoman verkon fyysisiä reaalitoimintoja.

Satojen fyysisten kohteiden manuaalisen käsittelyn sijasta hallintaan tarvitaan vain yksi komentorivi tai ohjelma. Simulointiratkaisua käyttämällä voidaan simuloida laitteiston jokainen solmu sekä niihin kuuluvat suorittimet, muistit, ajastimet, ledit, radio-osat ja kaikki muu tarvittava.

Jokainen anturisolmu liittyy tyypillisesti ympäröivän maailman simulaatioon, joten niillä on aina jotain dataa lähetettävänä yhdyskäytävään ja palvelimeen. Järjestelmän testaus edellyttää simuloidun radioverkon olosuhteiden vaihtelua. Simulaattorissa on tavanomaista asettaa määrättyjä signaalivoimakkuuksia eri solmuparien välille ja noudattaa toimintasääntöjä, jotka satunnaisesti hukkaavat datapaketteja, kun signaalin taso heikkenee riittävän alas.

Konfiguraatiota voidaan vaihdella testauksen aikana solmujen käyttäytymisen tarkistamiseksi olosuhteiden vaihdellessa. Tällainen tilanne voi käytännössä syntyä esimerkiksi silloin, kun juna kulkiessaan katkaisee suoran näköyhteyden kahden solmun väliltä ja keskeyttää radioviestinnän joksikin aikaa. Mikä parasta, tällaiset testit ovat tarkasti kontrolloitavia ja toistettavia, toisin kun reaalimaailmassa, missä radioyhteyksiin vaikuttaminen on parhaimmillaankin vaikeaa.

Kuva 5. Useiden erilaisten konfiguraatioiden simulointi.

Tällä tavoin voidaan luoda useita virtuaaliympäristöjä, joissa IoT-sovelluksia voidaan testata paljon suuremmalla testimatriisilla kuin fyysisessä laboratoriossa. Kuva 5 esittää, kuinka voidaan simuloida erilaisia verkkorakenteita, jotka on tarkoitettu eri skenaarioihin.

Kokonaisen IoT-järjestelmän simulointi antaa mahdollisuuden testata kaikki ohjelmiston osa-alueet mukaan lukien langattomat viestintäpinot ja tavat, joilla ne käsittelevät verkko-ongelmia, anturien ja toimilaitteiden koodeja sekä toimivat ympäristön kanssa. Samalla saadaan testattua solmujen lepotila- ja herätystoiminnot sekä niiden kyky vähentää energiankulutusta.

Muita testattavia ohjelmistotoimintoja ovat esimerkiksi raportointifunktiot antureilta yhdyskäytäviin ja palvelimeen sekä verkkosolmujen middleware-ohjelmistot, jotka hallitsevat verkkosolmuja ja niiden ohjelmapäivityksiä OTA-päivitykset mukaan lukien. Testattavissa ovat myös yhdyskäytävien ja solmujen tietoturvaominaisuudet sekä mahdollisuudet datanhallintajärjestelmän skaalaamiseen, kun solmujen lukumäärää kasvatetaan.