Nykylaitteet sisältävät useita erilaisia antureita, jotka ovat monimutkaisia raudan ja sulautetun ohjelmiston yhdistelmiä. Erityisesti ohjelmiston testaaminen on suuri haaste suunnittelijoille.

Joskus aiemmin lämpötila-anturi oli vain piilastu, jonka resistanssi muuttui lämpötilan muuttuessa. Kyse oli puhtaasta analogiapiiristä, jossa ei ole logiikkaelementtiä. Kun sovellusprosessorin piti tietää vallitseva lämpötila, sen piti mitata anturin lähdön jännite, muuntaa signaali analogisesta digitaalisesti, jotta se pystyisi laskemaan lämpötila-arvon.

Nyt järjestelmäsuunnittelijat voivat käyttää lämpötila-anturia, joka antaa suoraan digitaalisen informaation. "Älykkäät" digitaaliset anturit tuovat monenlaisia etuja käyttäjille, kuten paremman tarkkuuden ja piirille sisäänrakennetun lämpötilan kompensoinnin, diagnostiikan ja virheentunnistusta, konfiguroitavia suotimia ja ohjelmoitavia keskeytyksiä. Digitaalinen anturi voi myös hyödyntää algoritmeja tuottaakseen arvoja, joita ei voi suoraan mitata - kuten sisäilman laatu, jolla voidaan kuvata vaikkapa syttyvien orgaanisten yhdisteiden määrää ilmassa. Ja koska mittaussignaali digitoidaan anturissa, sovellusprosessorin rasitus pienenee suuresti, mikä yksinkertaistaa suunnittelua ja pienentää järjestelmän tehonkulutusta.

Digitaalinen anturi ei kuitenkaan enää ole analogisen edeltäjänsä tapainen yksinkertainen komponentti, koska sillä ajetaan sulautettua ohjelmistoa. Ja ohjelmisto tuo aina mukanaan riskin. Anturipiirin suorituskyky voidaan karakterisoida hyvin tarkkaan ja dokumentoida tuotteen datalehdessä. Isäksi standardiprosessit kuten autoteollisuuden PPAP (Production Part Approval Process) mahdollistavat tuotantopiirien laadun kvantifioinnin verifioitavalla tavalla. Tämän ansiosta järjestelmäsuunnittelija voi olla hyvin vakuuttunut anturin odotetusta suorituskyvystä tiedetyissä toimintaolosuhteissa.

Mutta miten suunnittelija voi päästä samaan luottamukseen anturin sulautetun ohjelmiston suhteen?

Sulautetun ohjelmiston aiheuttaman vian riski on todellinen. Euroopan Avaruusjärjestö ESA raportoi marraskuussa 2016 alustavista tuloksista, joiden mukaan Schiaparalli-luotaimen epäonnistunut laskeutuminen Marsin pinnalle johtui moduulin ohjausohjelmistoon tulleesta viasta, joka puolestaan johtui odottamattomasta anturi-informaatiosta, joka kesti vain sekunnin ajan. Avaruusmatkojen kalleuden takia on syytä olettaa, ettei kovinkaan moni sulautettu järjestelmä joudu yhtä ankaran testaamisen kohteeksi kuin Schiaparelli-moduulin koodi, mutta silti ohjelmistossa oli bugi laukaisun hetkellä.

Kovin moni suunnittelija ei tietenkään joudu varautumaan siihen, että heidän suunnittelemansa laite kestää avaruusaluksen edellyttämiä olosuhteita. Useimpien täytyy kuitenkin saavuttaa määritelty laatutaso ja tietty odotuselinaika. Tämä edellyttää jonkinlaisen verifiointimenetelmän sulautetun ohjelmiston virheen todennäköisyydelle. Menetelmän täytyy sopia budjettiin, suunnitteluresursseihin ja kehitysaikaan, joka suunnittelijaa rasittaa.

Tässä artikkelissa kuvaamme tapoja, joilla anturivalmistaja voi tukea suunnittelijaa näihin vaatimuksiin vastaamisessa anturipiirin sisälle sulautetun verifiointiohjelmiston avulla.

Tehtävä- ja turvallisuuskriittiset anturiratkaisut

Joitakin anturityyppejä käytetään monimutkaisissa mittaussovelluksissa, joissa taattu luotettavuus on keskeisen tärkeää. Esimerkiksi ams:n tarjoamista tällaisista antureista ovat:

• Virtausanturit (ks. kuva 1), joita käytetään vesimittareissa: vesilaitoksen asiakkaalle lähettämä lasku riippuu anturin mittaustuloksen tarkuudesta.

Kuva 1: TDC-GP30 -ultraäänivirtausmuunnin.

• Kaasuanturit (ks. kuva 2): talon asukkaiden turvallisuus ja jopa henki voi riippua anturin kyvystä mitata luotettavasti jätteiden vaarallisia pitoisuuksia.

Kuva 2: CCS811-kaasuanturiratkaisu.

• Bioanturi (ks. kuva 3): puettavan sykemittarin optiset mittaukset vaikuttavat lääkärin mahdollisuuksiin diagnostisoida oikein potilaan terveydentilaa.

Kuva 3: AS7000-bioanturi.

Kaikissa näissä sovelluksissa digitaalinen anturi yhdistää mittauksia - laitetasolla - ja datanprosessointia ohjelmistossa. Laitevirheen mahdollisuus ja ala voidaan kuvata piirin toimintaparametrien sisällä ja dokumentoida datalehdessä.

Anturin ohjelmiston virhemahdollisuuden kuvaaminen onnistuu parhaiten, jos ongelma pilkotaan kahdeksi osaksi.

Lähes jokainen digitaalinen anturi koostuu seuraavista pääelementeistä (ks. kuva 4):

• Analogiaetupää, joka tekee raakadatan keruun
• Ajurikoodi, joka osoittaa laitteistoon
• Algoritmit, jotka prosessoivat ja analysoivat dataa
• Logiikka, joka siirtää datan itse sovellukselle

Kuva 4: tyypillisen anturiratkaisun arkkitehtuuri.

Tämä tarkoittaa, että jokainen digitaalinen anturi sisältää erilaisia vaatimuksia täyttäviä ohjelmistokomponentteja:

• Jotkut elementit liittyvät spesifeihin laitekomponentteihin
• Joillakin elementeillä on kriittinen ajoitus
• Jotkut elementit kykenevät tehokkaaseen laskentaan
• Joillakin oodinosilla ei ole erityisvaatimuksia

Koodikannan eri osista voi löytyä erilaisia vikoja, ja testausrutiinit täytyy räätälöidä kattamaan kaikki eri vikatyypit (ks. kuva 5). Esimerkiksi:

• Algoritmeissa testien tulisi etsiä pyöristysvirheitä ja allekirjoitusvirheitä, sekä puskurien ylivuotoja
• Laitteisiin viittaavissa komponenteissa on tärkeä testata, että ohjelmisto vastaa oikein keskeytyksiin, jotka johtuvat aikarajoituksen (time-out) kulumisesta umpeen
• Liitännässä muihin järjestelmiin, kuten isäntäohjaimeen tai sovellusprosessoriin ohjelmiston pitää suoriutua keskeytysten ylikuormasta

Nämä kategoriat otetaan ams:llä huomioon anturien ohjelmistojen testausohjelmassa: koodi suunnitellaan siten, että se voidaan pilkkoa osiin testattavaksi. Lisäksi pienemmät osiot eivät vaadi monia liitäntöjä koodin muihin osiin, vaan ovat mahdollisimman riippumattomia kutsukoodista.

Kuva 5: Piirin firmware-ohjelmisto (ROM-koodi) ams:n anturiratkaisun integroidulla mikro-ohjaimella.

Algoritmikoodin testaaminen on hyvin suoraviivaista: annetuilla syötearvoilla testeri tietää täsmällisesti, mitä lähtöjä odottaa. Ja koska tämän koodinosan ei tarvitse tietää, mistä data tulee, se ei ole riippuvainen anturilaitteistosta.

Ajuriin testaaminen sen sijaan - esimerkiksi sen verifioiminen, että anturi viittaa rekistereihin oikein - vaatii laitteiston simulointia.

Yhtä kaikki, koodinosien tehokas testaaminen löytää bugeja, kuten ylivuotoja, puskurien ulkopuolella oleviin tapahtumiin viittaamista ja ketjujen vääriä päätösolosuhteita. Nämä testit eivät kuitenkaan riitä verifioimaan koko anturijärjestelmän toiminnallisuutta.

Enemmän kuin osiensa summa

Yli kaksi vuosituhatta sitten Aristoteles löysi jo totuuden, jonka mukaan kokonaisuus on enemmän kuin osiensa summa. Tämä totuus todellakin pätee sulautettuun ohjelmistoon. Kun jokainen ohjelmiston osio on testattu erikseen, on ehdottoman tärkeää verifioida, että kaikki osiot toimivat oikein yhdessä (ks. kuva 6).

Erityisesti testausinsinöörin pitää varmistua siitä, että ohjelmisto toimii oikein kaikissa niissä laiteympäristöissä, joissa sitä saatetaan käyttää. Esimerkiksi älypuhelin on paljon erillistä anturilaitetta vaativampi ympäristö, koska kännykkä tyypillisesti laukaisee paljon enemmän keskeytyksiä anturille. Stressitestejä vaaditaan sen takia tarkistamaan, että anturipiirin erilaiset liitännät kestävät keskeytysylikuormia ilman, että yhtään datatavua kadotetaan.

Järjestelmätestauksen pitää myös varmistaa järjestelmän sekventiaalisuus. Esimerkiksi käynnistys- ja laskentarutiinit voidaan verifioida erillisesti. Järjestelmätestaajan täytyy kuitenkin kutsua näitä rutiineja oikeassa järjestyksessä tai anturi pettää.

Kuva 6: ams:n geneerinen testauskehys.

Lopulta ohjelmiston toiminta täytyy verifioida myös epätavallisissa olosuhteissa. Schiaparelli-moduuli vikaantui, kun se kohtasi erityisen odottamattoman anturi-informaatiotilan, eikä tietenkään ole mahdollista testata kaikkia mahdollisia äärimmäisiä olosuhteita, joihin anturi voisi joutua. Ams:n suorittamat ohjelmistotarkistukset tähtäävät verifioimaan suorituskykyä hyvin laajasti epästandardeissa olosuhteissa. Anturiohjelmistoa testataan esimerkiksi rutiininomaisesti tilanteissa, joissa anturiin kohdistetaan keinotekoisesti erittäin voimakas virta, jotta nähdään miten anturi kestää epätavallisia heittelyitä teholähteen syöttövirrassa.

Miten varmistaa anturiohjelmiston eheys?

Ohjelmiston testausohjelman teoreettinen tavoite mille tahansa anturipiirille on antaa käyttäjälle 100-prosenttinen varmuus siitä, että anturijärjestelmä toimii oikein kaikkina aikoina, kaikissa sovelluksissa ja kaikissa toimintaolosuhteissa. Tämä on lopulta se, mitä käyttäjä ihannetilanteessa haluaisi.

Käytännössä, kuten Marsiin laskeutuneen moduulin esimerkki osoittaa, ei tietenkään ole olemassa 100-prosenttisia takeita. Miten käyttäjä voi sitten arvioida sen todennäköisyyden, jolla anturipiirin pettäminen on johtunut ohjelmistovirheestä?

Tähän kysymykseen on vaikea vastata täsmällisesti. Autoelektroniikan alueella on olemassa järjestelmille turvastandardi ISO 26262. Se muodostaa kehyksen, jossa järjestelmän vikaantumisastetta voidaan ennustaa siinä sovelluksessa, johon se on tarkoitettu. Standardi asettaa ankaran prosessin vikatilojen analysoinnille ja vikaantumisasteen mittaamiselle kussakin tilassa.

Mitä ankarampi testausprosessi on, sitä pidemmän aikaa se vie ja sitä enemmän se maksaa. ISO 26262 -tyyppinen validointiprosessi ei yleensä sovi kulutuselektroniikan tuotteille kustannusten eikä ajan takia. Hyvämaineisilla kulutuselektroniikan valmistajilla täytyy silti olla vahva luottamus käyttämänsä anturipiirin laatuun ja luotettavuuteen.

Jotta kaikki asiakkaat voisivat arvioida ams:n anturien sulautetun ohjelmiston laadun luotettavuutta, yhtiö on kehittänyt oman ohjelmistojen laatuvaatimusten standardinsa (Software Quality Requirements). Standardi määrittelee laatutasot ja -vaatimukset kaikille ams:n ohjelmistotuotteille, ja se asettaa standardin myös kehitystyölle ja testausprosessille.

Jotta standardinmukaisuus voidaan verifioida, ams arvioi valittuja ohjelmistoprojekteja standardin mukaisesti. Asiakkaan vaatimuksesta ams selostaa standardin yksityiskohdat ja kuvaa sen määrittelemän ohjelmistokehitysprosessin. Valitun laatutason mukaisesti standardi edellyttää, että kehittäjä noudattaa seuraavanlaisia parhaita käytäntöjä:

• Vaatimusten hallinta
• Staattinen koodin analyysi
• Sisäinen koodin arviointi
• Koodin yksikkötestit
• Järjestelmätestit toiminnallisen eheyden verifioimiseksi
• Asiakkaalle näytettävien lokitiedostojen ja testiraporttien generointi
• Testeillä saavutettava koodin kattavuuden minimiprosentti
• Lähdekoodin ja testien kunnollinen dokumentointi

Tällä tavoin ams pystyy osoittamaan, että digitaalisen anturipiirin sulautettu ohjelmisto pystyy kestävään (robustiin), ennustettavaan suorituskykyyn, minkä ansiosta järjestelmäsuunnittelija voi hyötyä digitaalisen anturin käyttämisestä seuraavista toiminnallisista ja suorituskykyeduista ilman, että siitä aiheutuu riskiä isäntäjärjestelmälle.

Yhteenveto

Digitaalisen anturipiirin laitteiston toiminta voidaan täsmällisesti karakterisoida ja dokumentoida tuotteen datalehdessä. Piirin oikea toiminta riippuu kuitenkin myös sen sulautetusta ohjelmistosta, joka toteuttaa erilaisia toimintoja ajureista algoritmeihin ja liitäntöihin.

Bugit tai viran ohjelmistossa voivat heikentää tai estää hyvän laitteen suorituskyvyn kokonaan, mutta toisin kuin laitteen kohdalla, piirin ohjelmiston toimintoja ei ole täysin dokumentoitu datalehdissä. Kuin suunnitteluinsinööri voi arvioida anturipiirin ohjelmiston suorituskykyä, eheyttä ja luotettavuutta?

Tässä artikkelissa pyrittiin esittämään, miten järjestelmäsuunnittelija voi arvioida anturipiirien ohjelmiston järjestelmälle asettamaa riskiä, ja miten anturipiirin valmistajan käyttämiä menetelmiä voidaan käyttää verifioimaan ohjelmiston laatua. Kuvasimme anturiohjelmiston tyypilliset toiminnot, ja tavat joilla se voi pettää. Sen jälkeen kuvasimme koodin osien testauksen arvon sekä kokonaisjärjestelmän testaamisen merkityksen.

Lopulta kuvasimme ams:n kehittämää sisäistä ohjelmistolaadun standardia, jota sen anturipiirien käyttäjät voivat hyödyntää arvioidessaan niitä prosesseja, joilla ams verifioi asiakkaille toimitettavien anturipiirien ohjelmiston laatua.