Jos olet sulautettujen ohjelmistojen tai IoT-laitteiden kehittäjä, olet todennäköisesti kuullut DevOpsista. Se on sarja lyhyisiin kehityssykleihin, toistuviin julkaisuihin ja nopeaan palautteeseen keskittyviä ohjelmistokehityskäytäntöjä, joissa kehitys ja toiminta liittyvät läheisesti toisiinsa. On aika ottaa siitä kaikki hyöty irti.
DevOps on ollut todellinen tehoisku lähes kaikessa muussa ohjelmistokehityksessä viimeisen vuosikymmenen aikana, erityisesti pilvessä, mobiilisovelluksissa ja peleissä. Toistaiseksi käyttöönotto on kuitenkin ollut hidasta sulautettujen ohjelmistojen ja IoT-laitteiden kehittäjien keskuudessa.
On täysi syy uskoa, että sulautettujen sovellusten kehittäjät hyötyvät yhtä paljon DevOpsista kuin muun tyyppiset kehittäjät, joten tässä artikkelissa esitän tärkeän osan DevOps-strategiasta sulautetun ja IoT-kehityksen osalta, ja esitän sen mukanaan tuomat hyödyt.
Ensiksi pitää todeta yksi asia: jokaisessa ohjelmistossa on virheitä. On olemassa akateemista tutkimusta, joka osoittaa, että jokaista tuhatta toimitettua koodiriviä kohden tuotetaan 50-100 bugia kehityksen aikana. Noin 5 prosenttia niistä on edelleen käytössä. Tämän tunnustaminen ja käyttöönoton ongelmiin valmistautuminen on DevOpsin kulmakivi. Tämä saavutetaan seuraamalla järjestelmällisesti ohjelmistoa käyttöönoton aikana.
Internet of Things- eli IoT-laitteiden ensisijainen tarkoitus on tarjota dataa ja näkemyksiä liiketoiminnan parantamiseksi esimerkiksi koneiden ennakoivan huollon kautta. Voimme soveltaa samaa ajattelua laiteohjelmistoon oppiaksemme, kuinka se toimii kentällä. Tämä vaatii niin kutsuttua laitepalautesilmukkaa (Device Feedback Loop), joka tarkoittaa DevOps-seurantaa laiteohjelmistoille ja tarjoaa mahdollisuuden raportoida kaikenlaisista laitteissa esiintyvistä ajonaikaisista ongelmista takaisin kehittäjille yhdessä tapahtuneen selittävien diagnostisten tietojen kanssa.
Virheistä, erityisesti kaatumisista ilmoittaminen on luultavasti ensimmäinen asia, joka tulee mieleen. Asiakkaiden raportoimia kaatumisia voi olla helvetillisen vaikea analysoida, koska vastaanotetusta palautteesta puuttuu usein tarpeeksi yksityiskohtia, jotta kehittäjät voisivat toistaa ongelman. Laitteen palautesilmukka voi varoittaa ohjelmistovian tapahtuessa ilman erillisiä käyttäjän toimia ja antaa tuotetiimille tarvittavat tiedot ongelman paikantamiseksi. Tämä mahdollistaa myös testauksen parantamisen, jotta samanlaiset ongelmat voidaan välttää tulevaisuudessa.
Poikkeavuuksien havaitseminen palautesilmukan avulla voi myös parantaa IoT-laitteiden turvallisuutta. Esimerkiksi satunnaiset kaatumiset voivat johtua haavoittuvuudesta, jota hyödynnetään osittain onnistuneissa hyökkäyksissä, joissa haittaohjelmia syötetään, mutta ne aiheuttavat vahingossa kaatumisen. Toisessa poikkeamatyypissä prosessori toimii normaalia enemmän, mikä voi johtua laitteen haitallisesta toiminnasta. Tällaisista poikkeavuuksista tiedon saaminen jo kentällä mahdollistaa haavoittuvuuden löytämisen ja korjaamisen paljon aikaisemmassa vaiheessa. Tämä pienentää vakavien ongelmien, kuten tietomurtojen riskiä.
Toinen tärkeä DevOps-käytäntö eli automaattinen testaus hyötyy myös laitteen palautesilmukasta. Kaatumisten ja muiden satun-naisten ongelmien analysointi on paljon helpompaa keräämällä automaattisesti yksityiskohtaista diagnostiikkadataa ja raportoimalla ongelmista keskitettyyn tiedonhallintajärjestelmään, johon kaikki kehittäjät pääsevät käsiksi.
Laitteen palautesilmukan toteuttaminen tyhjästä ei ole mikään triviaali prosessi, ja monia asioita on otettava huomioon. Uskon, että toimiva ratkaisu sisältää seuraavat:
Keskitetty tiedonhallinta helpottaa yhteistyötä ja diagnostiikkatietojen jakamista hajautettujen tiimien sisällä ilman fyysistä pääsyä laitteeseen.
Laitekehittäjien pitäisi pystyä laajentamaan ja konfiguroimaan monitorointia parhaaksi katsomallaan tavalla ilman, että heidän tarvitsee muuttaa pilvessä sijaitsevaa tiedonhallinta-järjestelmää.
Kerätyn datan täytyy kestää kaatumia, jopa mikro-ohjaimissa, joissa ei ole tavallista tiedostojärjestelmää, ja data pitäisi ladata automaattisesti uudelleenkäynnistyksen ja yhteyden muodostamisen jälkeen.
Monitoroinnin on oltava tehokasta, ja sen on oltava vietävä mahdollisimman vähän koodia ja prosessointitehoa.
Monitoroinnin tulee skaalautua suuriin laitekantoihin sopivalla tiedonhallinnalla ja automaattisella raporttien luokittelulla ja korostaa uusia, aiemmista raporteista poikkeavia tapahtumia.
Korkea tietoturvallisuus on välttämätöntä. Ratkaisu ei saa luoda uusia hyökkäyspintoja ja sen tulee noudattaa kyberturvallisuuden parhaita käytäntöjä.
Ongelmien tulee olla jäljitettävissä tiettyihin koodin versioihin ja tiettyihin tilanteisiin, jotta poikkeamia voidaan seurata korkean tason analytiikasta kooditason virheenkorjaukseen.
Diagnostiikkatietoja visuali-soivat työkalut, kuten ohjelmiston vianhaun seuranta eli trace, helpottavat koodin ongelmien ymmärtämistä. Näin voit tarjota ratkaisuja nopeammin.
Olemme haastatelleet 10 suuren OEM-yrityksen kehittäjiä ja päälliköitä, jotka kehittävät sulautettuja ohjelmistoja teollisiin ohjaus-järjestelmiin saadaksemme selville heidän ajatuksensa ja tarpeensa virheenkorjaukseen ja laitteen palautesilmukkaan liittyen.
Yleisimmät näissä haastatteluissa mainitut liiketoiminnalliset huolenaiheet olivat saatavuus, tietoturva ja turvallisuus. Teknisten haasteiden osalta he olivat enimmäkseen samaa mieltä siitä, että kaatumisten ja ohjelmistovikojen havaitseminen ja analysointi on ykkösprioriteetti - usein yhdessä tietoturva-arvioinnin kanssa.
Ohjelmiston huono laatu ei ole vain pieni haitta käyttäjille. Verkkoon liitetyt laitteet ovat usein rahantekokoneita kaupallisiin palveluihin tai teolliseen tuotantoon. Tämä tarkoittaa, että ohjelmisto-ongelmilla voi olla suuri vaikutus asiakastyytyväisyyteen. Jos asiakas näkee, että laitteesi aiheuttavat enemmän ongelmia kuin ne ratkaisevat, se vaikuttaa suoraan asiakkaiden uskollisuuteen, ja siten lopulta liikevaihtoon.
Ohjelmisto-ongelmat myös lisäävät kustannuksia. Asiakkaiden ongelmien debuggaaminen voi olla todella aikaa-vievää, ja sillä välin asiakastuen on käsiteltävä vihaisia asiakkaita, ja kehitystiimi työskentelee ympäri vuorokauden ongelman eristämiseksi. Tämä todennäköisesti viivästyttää uusien tuot-teiden kehitystä ja siten myös niistä saatavaa tuloa.
Lopuksi on vielä tietoturvaan liittyvät riskit, jotka voivat altistaa yrityksen ja sen asiakkaat kyberhyökkäyksille, palvelutasosopimussakoille tai jopa oikeudenkäynneille. Tietomurron keskimääräiseksi kustannukseksi on arvioitu lähes 4 miljoonaa dollaria.
Yhteenvetona voidaan todeta, että laitteen palautesilmukka voi optimoida IoT-toimintaa turvaamalla laitteen toiminnan, turvallisuuden ja luotettavuuden, vähentämällä riskejä ja parantamalla asiakastyytyväisyyttä. Se myös alentaa kustannuksia ja parantaa liiketoiminnan tuloja paremman asiakastyytyväisyyden ja nopeutetun tuotekehityksen ansiosta. Vaikka vikoja on vaikea välttää, on tärkeää, miten valmistaudut käsittelemään niitä.
Kirjoittaja Johan Kraft, Percepio
Artikkeli on ilmestynyt tuoreessa ETNdigi 2/2022 -lehdessä. Sitä pääset lukemaan täällä.
Toukokuun ajan voit myös osallistua kisaan, jossa voit äänestää lehden parasta artikkelia ja voittaa upean OnePlus Nord 2 -älypuhelimen. Lue lisää täällä.
Kun suurteholaskennan (HPC) työkuormat monimutkaistuvat, generatiivinen tekoäly sulautuu yhä tiiviimmin moderneihin järjestelmiin ja lisää kehittyneiden muistiratkaisujen tarvetta. Vastatakseen näihin muuttuviin vaatimuksiin ala kehittää uuden sukupolven muistiarkkitehtuureja, jotka maksimoivat kaistanleveyden, minimoivat latenssin ja parantavat energiatehokkuutta.
