Keskeiset havainnot:
Teksti osoittaa, miten teollisuussovelluksen logiikka suunnitellaan niin, etteivät hetkellinen verkkoyhteyden katkeaminen, laitteiden uudelleenkäynnistys tai istunnon katkeaminen johda tilan yhdenmukaisuuden menetykseen, komentojen kahdentumiseen tai työn hallitsemattomaan jatkumiseen. Lukija näkee, miksi päätökset puskuroinnista, komentojen kuittauksesta, istunnon palauttamisesta ja tilamallista on tehtävä jo projektin alkuvaiheessa, koska ne vaikuttavat myöhemmin suoraan prosessin jatkuvuuteen, turvallisuuteen ja järjestelmän jäljitettävyyteen.
- Kyse on fyysisestä turvallisuudesta, ei vain IT-mukavuudesta: verkon katkeaminen ja ”vahvistamattomien” komentojen automaattinen uudelleenlähetys yhteyden palautuessa (esim. ”käynnistä sykli”) voivat aiheuttaa sen, että kone suorittaa toiminnon kahdesti tai väärällä hetkellä. Tämä on todellinen vaara ihmisille ja tuotantotilan prosessille.
- Kultainen sääntö uudelleenkäynnistykselle: Jos järjestelmä ei yhteyden uudelleenkäynnistyksen jälkeen pysty 100 %:n varmuudella yksiselitteisesti määrittämään, missä tilassa toimilaite on, se ei missään tapauksessa saa jatkaa toimintaa automaattisesti. Tällainen tilanne edellyttää aina operaattorin tietoista, nimenomaista vahvistusta.
- Päätökset on tehtävä alussa, muuten kustannukset kasvavat: sovelluksen toiminta yhteyden katketessa on suunniteltava osaksi arkkitehtuuria jo aivan projektin alussa. Jos tämä jätetään ”sovittavaksi käyttöönottovaiheessa”, seurauksena ovat kalliit korjaukset, henkilöstön tekemä virheiden manuaalinen paikkaaminen ja turhaantuneiden operaattorien vaaralliset lukitusten ohitukset.
Teollisen sovelluksen kyky kestää tilapäinen verkkokatkos, laitteiden uudelleenkäynnistys ja yhteyden menetys ei ole enää käyttömukavuutta parantava lisäominaisuus, vaan edellytys prosessin oikealle toiminnalle ja sille, että vastuu säilyy valmistajalla, integraattorilla tai loppukäyttäjällä. Teollisuusympäristössä yhteyden katkeaminen ei ole poikkeuksellinen tapahtuma: sitä esiintyy huoltotöiden, infrastruktuurin kytkentöjen, sähkökatkon jälkeisen käynnistyksen, päivitysten, verkon ylikuormituksen tai tavallisen reunalaitteen vian yhteydessä. Jos sovellus tällaisissa tilanteissa menettää tilansa eheyden, monistaa komentoja tai suorittaa yhteyden palautumisen jälkeen odottaneet toiminnot ilman kontekstin hallintaa, kyse ei ole enää vain IT-ongelmasta. Siitä tulee prosessin jatkuvuuden, toiminnallisen turvallisuuden, tuotantodatan laadun ja suunnitteluratkaisujen jäljitettävyyden kysymys.
Siksi asiasta on päätettävä jo projektin alussa, ei vasta ensimmäisen käyttöönoton jälkeen. Yhteyskatkoja kestävä arkkitehtuuri vaikuttaa siihen, miten koneen tilat mallinnetaan, millä periaatteilla dataa puskuroidaan, missä järjestyksessä komennot vahvistetaan, millä ehdoilla istunto muodostetaan uudelleen ja millä logiikalla toiminta palautetaan uudelleenkäynnistyksen jälkeen. Jos tiimi siirtää nämä päätökset myöhemmäksi, lopputuloksena on yleensä kalliita kiertoratkaisuja: poikkeusten paikallista lisäämistä, jonojen manuaalista puhdistamista, ylimääräisiä operaattorilukituksia tai valvontakerroksen laajentamista vain siksi, että laitteiden käyttäytyminen ei ole ennakoitavaa. Käytännöllinen arviointikriteeri on yksinkertainen: jokaisesta olennaisesta toiminnosta on pystyttävä vastaamaan yksiselitteisesti, mitä tapahtuu yhteyden katketessa, mitä tapahtuu uudelleenkäynnistyksen jälkeen ja kuka vahvistaa työn jatkamisen. Jos vastaus on ”se riippuu toteutuksesta” tai ”operaattori huomaa, että jokin on pielessä”, kyse ei vielä ole suunnittelupäätöksestä vaan riskin siirtämisestä käyttöön.
Tämä näkyy selvimmin sovelluksen ja koneen tai prosessin liikkeen rajapinnassa. Kuvitellaan järjestelmä, jossa käyttöpaneeli antaa käskyn käynnistää sykli, mutta ohjain toteuttaa sen viiveellä tilapäisen yhteyskatkon vuoksi. Jos sovellus viestinnän palautuessa lähettää komennon uudelleen, koska se ei saanut kuittausta, seurauksena voi olla toiminnon kaksinkertainen suoritus tai käynnistys olosuhteissa, jotka poikkeavat niistä, jotka operaattori näki komennon antaessaan. Tässä kohtaa viestinnän häiriönsietokyky alkaa liittyä suojaukseen odottamatonta käynnistymistä vastaan: jokainen uudelleenkäynnistys ei ole turvallisuusongelma, mutta jokainen uudelleenkäynnistys, joka voi muuttaa käynnistysolosuhteita ilman tietoista vahvistusta ja ilman laitteen tilan tarkistusta, edellyttää jo tämän tason analyysia. Sama koskee lukitsevia laitteita ja lukituksia: jos sovelluslogiikka kannustaa henkilöstöä kiertämään hankalia lukituksia verkkovian jälkeen, ongelma ei johdu yksin käyttäjän toiminnasta vaan suunnitteluratkaisusta.
Johtamisen ja vaatimustenmukaisuuden näkökulmasta olennaista ei siis ole se, ”tapahtuuko” yhteyskatkoja, vaan pystyykö suunnittelu osoittamaan turvallisen ja ennakoitavan käyttäytymisen tällaisissa rajatilanteissa. Tässä vaiheessa aihe siirtyy myös käytännön riskinarvioinnin alueelle: on erotettava toisistaan toiminnot, joissa viive tai osan historiatiedoista menetys on hyväksyttävää, ja toiminnot, joissa kontekstin menetys voi johtaa operaattorin virheelliseen päätökseen, tuotteen vaurioitumiseen tai vaaraan uudelleenkäynnistyksen yhteydessä. Kannattaa mitata ei abstraktia ”järjestelmän vakautta” vaan tunnuslukuja, jotka osoittavat suunnittelun seuraukset: epäselvien uudelleenkäynnistymisen jälkeisten jatkamistilanteiden määrä, niiden komentojen määrä, jotka vaativat tilan manuaalista yhteensovittamista, turvalliseen työn jatkamiseen tarvittava aika sekä tapaukset, joissa järjestelmä ei pysty osoittamaan, onko komento toteutettu. Vasta tätä taustaa vasten normatiiviset vaatimukset ja teknisiä toimenpiteitä koskevat päätökset ovat mielekkäitä: sähkökatkon jälkeisten käynnistysolosuhteiden analyysi, riskinarviointi yhteydenmenetysskenaarioille sekä lukitsevien ja valvovien ratkaisujen valinta siellä, missä pelkkä tietotekninen mekanismi ei anna riittävää varmuutta.
Missä kustannus tai riski kasvaa useimmiten
Teollisten sovellusten projekteissa, joissa varaudutaan tilapäiseen verkkokatkokseen, laitteiden uudelleenkäynnistykseen ja yhteyden menetykseen, kustannukset eivät useimmiten kasva itse teknisistä mekanismeista vaan virheellisistä oletuksista prosessin tilasta häiriön jälkeen. Jos tiimi olettaa, että yhteyden palauttamisen jälkeen järjestelmä ”palaa normaaliin toimintaan”, ennemmin tai myöhemmin seurauksena ovat tilojen manuaalinen yhteensovittaminen, ohjauslogiikan korjaukset, ylimääräiset vastaanottotestit tai vasta käyttöönoton jälkeen asetetut käytön rajoitukset. Kalleimpia ovat tilanteet, joissa sovellus ei pysty yksiselitteisesti vastaamaan, onko komento toteutettu, keskeytynyt, monistunut vai ainoastaan rekisteröity käyttöliittymän puolella. Kyse ei ole käyttömukavuudesta vaan vastuusta fyysisestä vaikutuksesta: käyttöliikkeestä, asetusarvon muutoksesta, venttiilin avautumisesta, hälytyksen kuittauksesta tai syklin jatkamisesta.
Projektien viivästymisten taustalla on usein myös vastuiden virheellinen jako käyttöliittymätason, välikerroksen sovelluksen ja koneen ohjauksen välillä. Jos päätös siitä, mitä uudelleenkäynnistyksen jälkeen tapahtuu, jätetään ”toteutusvaiheessa ratkaistavaksi”, lopputuloksena on yleensä epäyhtenäinen sääntöjoukko: paneeli näyttää viimeksi tunnetun tilan, ohjain käynnistää alustusmenettelyn ja ylemmän tason järjestelmä toistaa jonoon jääneet komennot ilman varmuutta siitä, ovatko ne edelleen perusteltuja. Käytännössä tämä on ratkaistava etukäteen ja yksiselitteisesti: mitkä toiminnot voidaan toistaa ilman sivuvaikutuksia, mitkä edellyttävät kohteen senhetkisten olosuhteiden vahvistamista ja mitkä on yhteyden katketessa vanhennettava ja siirrettävä turvalliseen tilaan. Hyvä päätöksentekokriteeri on yksinkertainen: jos toiminnon virheellinen jatkaminen voi muuttaa energiatilaa, toimilaitteen asentoa, tuotteen laatua tai ihmisten turvallisuusolosuhteita, ei voida tukeutua pelkästään sovelluksen viimeisimmän tilan muistiin.
Tämä näkyy hyvin esimerkissä sekvenssistä, joka ennen yhteyden katkeamista lähetti komennon suojuksen sulkemiseksi ja syklin käynnistämiseksi, mutta käyttöaseman uudelleenkäynnistyksen jälkeen palauttaa näytölle tilan ”valmis käyttöön”. Jos sovellus ei erottele tiloja ”komento vastaanotettu”, ”suoritus vahvistettu”, ”suoritus keskeytynyt” ja ”tila määrittämätön”, operaattorille muodostuu näennäisesti yhtenäinen mutta tosiasiassa puutteellinen kuva. Seurauksena voi olla tarpeettomia seisokkeja, koska käyttöhenkilöstö ei uskalla jatkaa prosessia, tai päinvastoin perusteeton käynnistys, koska käyttöliittymä ei osoita uudelleentarkistuksen tarvetta. Projektipäällikölle tämä merkitsee myöhemmin kallista syiden selvittämistä, testiskenaarioiden muuttamista ja tarvetta lisätä kiertomenettelyjä. Tuotteen omistajalle se tarkoittaa reklamaatioiden ja vastuunjaosta syntyvien kiistojen riskiä, erityisesti silloin, kun vaatimusdokumentaatio ei yksiselitteisesti määritä järjestelmän toimintaa sähkökatkon tai tiedonsiirtoyhteyden häiriön jälkeen. Siksi kannattaa mitata käytettävyyden lisäksi myös uudelleenkäynnistyksen jälkeisten määrittämättömien tilojen määrää, manuaalista yhteensovittamista vaativien toimintojen määrää sekä aikaa turvallisen käyttövalmiuden saavuttamiseen.
Erillinen kustannusluokka syntyy siitä, että tiedonsiirron häiriönsietokyky sekoitetaan toiminnalliseen turvallisuuteen. Se, että sovellus pystyy puskuroimaan tietoja, uusimaan lähetyksiä tai palauttamaan istunnon, ei vielä tarkoita, että kone käyttäytyy turvallisesti yhteyden menetyksen jälkeen. Kun häiriön vaikutus ulottuu liikkeeseen, varastoituneeseen energiaan, lukituksiin tai uudelleenkäynnistyksen ehtoihin liittyviin toimintoihin, asia siirtyy luontevasti käytännön riskinarvioinnin alueelle. Tällöin on arvioitava paitsi verkkohäiriön todennäköisyyttä ennen kaikkea virheellisen tilatiedon ja virheellisen uudelleenkäynnistyksen mahdollisia seurauksia. Jos järjestelmään kuuluu hydrauliikkaa, mukaan tulevat vaatimukset toimilaitteiden käyttäytymisestä sähkökatkon ja paineen alenemisen aikana; tällöin sovellustason päätökset eivät saa olla ristiriidassa hydraulijärjestelmiä koskevien suunnitteluperiaatteiden kanssa. Vastaavasti siellä, missä käyttövalmiuden palautuminen riippuu suojuksen sulkemisesta tai lukituksen vapauttamisesta, ongelma voi ulottua myös lukituslaitteiden ja suojalaitteiden ohittamisen kestävyyden alueelle, koska paine ”nopeaan uudelleenkäynnistykseen” synnyttää hyvin usein myöhemmin vaarallisia käyttökäytäntöjä.
Normatiivisiin viittauksiin on mielekästä siirtyä vasta tässä vaiheessa, kun tiedetään, mihin skenaarioon liittyy tekninen ja organisatorinen vaikutus. Jos yhteyden menetys tai uudelleenkäynnistys voivat muuttaa turvallisen käynnistyksen ehtoja, tämä on kuvattava riskianalyysissä eikä jätettävä ohjelmistovalmistajan tai ohjaintoimittajan oletuskäyttäytymisen varaan. Jos toimilaite voi sähkökatkon jälkeen siirtyä prosessin kannalta epäedulliseen tai vaaralliseen tilaan, on tarkistettava, edellyttävätkö kyseistä käyttöä ja väliainetta koskevat vaatimukset lisärakenteellisia toimenpiteitä sovelluslogiikasta riippumatta. Käytännöllinen raja-arvokriteeri on seuraava: kun tilan palauttamisen jälkeinen virhe voidaan poistaa ainoastaan operaattorin menettelyllä, kyse ei ole enää vain tietoteknisestä asiasta vaan myös suunnittelusta ja vaatimustenmukaisuudesta. Juuri tässä kohdassa päätös sovellusarkkitehtuurista lakkaa olemasta käyttöönoton mukavuuskysymys ja muuttuu osaksi vastuuta koko järjestelmän turvallisesta ja ennakoitavasta käyttäytymisestä. Tähän liittyvät myös normatiiviset vaatimukset ja teknisiä toimenpiteitä koskevat päätökset.
Miten aihetta kannattaa lähestyä käytännössä
Käytännössä teollisuussovelluksen kyky sietää lyhytaikaista verkkokatkosta, laitteiden uudelleenkäynnistystä ja yhteyden menetystä ei ala teknologian valinnasta vaan päätöksestä siitä, mitkä vikaantumisen seuraukset ovat hyväksyttäviä ja mitkä eivät. Tiimin tulisi aluksi erottaa toisistaan kolme asiaa: prosessin tila, ohjauksen tila ja operaattorille esitettävä tila. Tämä erottelu ratkaisee, palauttaako sovellus tiedonsiirron katkeamisen jälkeen vain näkymän vai saako se myös jatkaa ohjausta, komentojonoa tai teknologista sekvenssiä. Jos nämä kerrokset sulautetaan yhdeksi, projekti päättyy yleensä kalliiseen poikkeusten paikkaamiseen, manuaalisiin kiertomenettelyihin tai kiistaan vastuista käyttöönoton jälkeen. Johtamisen näkökulmasta olennainen asia on yksi: arkkitehtuuria koskevan nimenomaisen päätöksen puuttuminen ei pienennä riskiä, vaan siirtää sen vastaanottotestauksen, huollon ja vaatimustenmukaisuuden vaiheeseen. Siksi aihe vaatii ratkaisuja jo suunnittelun alkuvaiheessa.
Käytännössä tämä tarkoittaa, että jokaiselle kriittiselle tilanteelle on määriteltävä, mitä järjestelmän tulee häiriön jälkeen säilyttää ja mitä se ei saa säilyttää. Kyse ei ole yleisestä toteamuksesta ”toimii uudelleenyhdistämisen jälkeen”, vaan täsmällisistä säännöistä: mitkä tiedot palautetaan pysyvästä tallennuksesta, mitkä on vahvistettava laitteelta, mitkä komennot vanhenevat määräajan ylityttyä ja mitkä edellyttävät uutta valtuutusta tai operaattorin kuittausta. Hyvä päätöksentekokriteeri on yksinkertainen: jos uudelleenkäynnistyksen jälkeen ei voida yksiselitteisesti todeta, onko aiempi komento toteutettu, järjestelmä ei saa suorittaa sitä automaattisesti uudelleen. Sama koskee hälytyksiä, erälaskureita, käyttötiloja ja teknologisia lukituksia. Tällainen kirjaus voi vaikuttaa pieneltä suunnitteluyksityiskohdalta, mutta ilman sitä integraatiotestauksen kustannukset kasvavat, koska jokainen epäselvyys palaa vaikeasti toistettavana virheenä. Myös ratkaisun omistajan vastuu kasvaa, koska myöhemmin on pystyttävä osoittamaan, että toiminta yhteyden katketessa oli ennakoitavaa ja tarkoituksellista.
Tyypillinen esimerkki koskee sovellusta, joka lähettää ohjaimelle käskyn käynnistää jakson ja menettää sitten yhteyden ennen kuittauksen vastaanottamista. Jos sovellus yhteyden palautumisen jälkeen lähettää komennon ”varmuuden vuoksi” uudelleen, se voi käynnistää jakson toistamiseen. Jos taas oletetaan, että komento varmasti toteutui, prosessin tila voidaan palauttaa virheellisesti ja sallia seuraavat toiminnot väärässä järjestyksessä. Oikea lähestymistapa on suunnitella komennot ja vastaukset niin, että ne ovat ajallisesti erotettavissa ja yksilöitävissä, ja että uudelleenkäynnistyksen jälkeen laitteen todellinen tila voidaan tarkistaa ennen liiketoimintalogiikan jatkamista. Tässä yhteydessä kannattaa mitata järjestelmän käytettävyyden lisäksi myös epäselvien tilanpalautusten määrää, manuaalisten toimenpiteiden määrää uudelleenkäynnistyksen jälkeen sekä aikaa, joka tarvitaan toiminnan turvalliseen palauttamiseen. Nämä ovat mittareita, jotka osoittavat arkkitehtuurin todelliset kustannukset eivätkä pelkästään ohjelmoinnin helppoutta.
Raja riskianalyysiin tulee vastaan silloin, kun virheellinen tilan palautus voi muuttaa koneen, sekvenssin tai toimilaitteen käyttäytymistä. Tällöin kyse ei ole enää pelkästään tietoteknisestä asiasta, vaan siirrytään käytännön riskien arvioinnin alueelle, myös ISO/TR 14121-2:ssa käytetyn menetelmän merkityksessä. Jos sähkökatkon tai laitteen uudelleenkäynnistyksen jälkeen on mahdollista, että liike käynnistyy itsestään uudelleen, väliaine syötetään, toimilaite vapautuu tai siirrytään käyttötilaan ilman operaattorin tietoista hyväksyntää, kyse on myös suojautumisesta odottamatonta käynnistymistä vastaan, mikä edellyttää laajempaa tarkastelua kuin pelkkä sovelluslogiikka. Siellä, missä käytetään hydraulisia tai pneumaattisia käyttöjä, mukaan tulevat lisäksi rakenteelliset vaatimukset ja järjestelmän käyttäytyminen energian menetyksen jälkeen, joten päätöstä työn ”pehmeästä” jatkamisesta ei voida tehdä irrallaan koko asennuksen teknisistä olosuhteista. Vaatimustenmukaisuuden näkökulmasta turvallisinta on olla arvailematta prosessin tarkoitettua tilaa häiriön jälkeen, vaan määrittää etukäteen työn jatkamisen ehdot ja kohdistaa ne selkeästi eri vastuutahoille: sovellukselle, ohjaimelle, toimilaitteistolle ja operaattorille.
Mitä käyttöönotossa on syytä varoa
Eniten virheitä teollisten sovellusten käyttöönotossa, kun niiden pitäisi kestää lyhytaikainen verkkokatkos, laitteiden uudelleenkäynnistys ja yhteyden menetys, ei synny itse teknologiasta vaan vastuiden virheellisestä määrittelystä. Tiimi olettaa, että ”häiriönsietokyky” hoituu viestintäkerroksessa, pilvipalveluntarjoajan toimesta tai ohjaimessa, vaikka ongelma on prosessin tilan, laitteen tilan ja datan tilan välisessä suhteessa. Jos näitä kolmea tasoa ei eroteta toisistaan jo hyväksyntävaiheessa, projekti alkaa tuottaa näennäistä luotettavuutta: sovellus toimii uudelleenkäynnistyksen jälkeen, mutta kukaan ei pysty osoittamaan, palautuiko tila restartin jälkeen oikein, turvallisesti ja fyysistä todellisuutta vastaavasti. Tällä on suora vaikutus kustannuksiin, koska myöhemmät korjaukset edellyttävät yleensä muutoksia samanaikaisesti ohjauslogiikkaan, käyttöliittymään, tapahtumien rekisteröintiin ja käynnistysmenettelyihin. Sillä on vaikutusta myös vastuisiin, koska poikkeamatilanteessa on vaikea puolustaa ratkaisua, jossa ei ole yksiselitteisesti määritelty, kuka vahvistaa valmiuden työn jatkamiseen ja millä perusteella. Siksi aihe vaatii ratkaisuja jo projektin suunnittelun alkuvaiheessa.
Käytännössä vaarallisin ansa on käsitellä yhteyden menetystä tavallisena teknisenä vikana eikä järjestelmän erillisenä käyttötilana. Jos sovellus puskuroi toimintoja verkkokatkon aikana ja toistaa ne yhteyden palautumisen jälkeen tarkistamatta ajantasaista kontekstia, se voi suorittaa myöhästyneitä, jo luvattomia tai linjan todellisen tilan kanssa ristiriidassa olevia toimia. Vastaava ongelma ilmenee laitteen uudelleenkäynnistyksen jälkeen: aiemmin tallennettu looginen tila voi olla muodollisesti täydellinen, mutta fyysisesti vanhentunut, koska sillä välin toimilaitteen asento, väliaineen paine, käyttötilan asetus tai käyttöhenkilöstön tekemä toimenpide on muuttunut. Hyvä päätöksentekokriteeri on tässä yksinkertainen: jos järjestelmä aikoo tilan palauttamisen jälkeen tehdä minkä tahansa prosessiin vaikuttavan toimenpiteen, sen sallittavuus on ensin voitava varmistaa nykyisten signaalien perusteella eikä pelkästään ennen häiriötä tallennetun historian pohjalta. Jos tällaista varmistusta ei voida osoittaa, turvallisempi ratkaisu on siirtyä tilaan, joka edellyttää nimenomaista kuittausta tai uutta synkronointia. Tällaisissa rajatilanteissa koneiden ja tuotantolinjojen turvallisuusauditointi auttaa arvioimaan, onko käyttäytyminen turvallista ja ennakoitavaa.
Hyvä esimerkki on asema, joka menettää hetkellisen tiedonsiirtokatkoksen jälkeen yhteyden ylempään järjestelmään, mutta näkee paikallisesti edelleen osan tulosignaaleista. Ohjelman näkökulmasta on houkuttelevaa ”viedä sekvenssi loppuun” yhteyden palauduttua, jotta sykliaikaa ei menetettäisi. Ongelma alkaa silloin, jos operaattori on katkon aikana poistanut kappaleen, paineenpoistoventtiili on lauennut, paneeli on käynnistynyt uudelleen tai käyttö on siirtynyt toiseen tilaan. Sovelluslogiikassa kaikki voi näyttää johdonmukaiselta, ja silti vaiheen jatkaminen muodostuu teknologiseksi virheeksi tai vaaraksi. Siksi käyttöönotossa kannattaa arvioida paitsi kadonneiden viestien määrää tai istunnon palautumisaikaa myös sellaisia tunnuslukuja, jotka kuvaavat toiminnan laatua häiriön jälkeen: kuinka monta kertaa järjestelmä vaati manuaalista uudelleensynkronointia, kuinka monta toimintoa hylättiin vanhentuneina ja kuinka moni uudelleenkäynnistys päättyi siirtymiseen turvalliseen tilaan automaattisen jatkamisen sijaan. Nämä ovat parempia ratkaisun kypsyyden mittareita kuin pelkkä palvelun käytettävyys, koska ne paljastavat, onko häiriönsietokyky saavutettu prosessin hallinnan kustannuksella.
Raja, jossa tämä aihe lakkaa olemasta pelkästään sovellusarkkitehtuurin kysymys, tulee vastaan nopeammin kuin projektitiimit yleensä olettavat. Jos yhteyden menetys, ohjaimen uudelleenkäynnistys tai tehtäväjonon palauttaminen voi vaikuttaa koneen liikkeeseen, energian syöttöön tai toimilaitteen tilan muutokseen, siirtyy asia käytännön riskien arvioinnin puolelle. Tällaisessa kohdassa ei enää riitä perusteluksi, että ratkaisu ”toimii yleensä oikein”; tarvitaan poikkeamaskenaarioiden analyysiä, myös logiikalla, joka vastaa ISO/TR 14121-2:ssa käytettyä lähestymistapaa. Jos lisäksi sähkönsyötön tai yhteyden palautumisen jälkeen on mahdollista, että toiminto käynnistyy uudelleen itsestään, aihe liittyy myös suojautumiseen odottamattomalta käynnistymiseltä, ja sitä on tarkasteltava laajemmin käynnistysolosuhteiden sekä energian katkaisutilan yhteydessä. Siellä, missä järjestelmään kuuluu hydrauliikkaa tai pneumatiikkaa, ohjelmistopäätöstä ei voi erottaa asennuksen käyttäytymisestä energian katketessa; tällaisissa tapauksissa on tarkistettava myös koko järjestelmää koskevat rakenteelliset vaatimukset eikä vain sovelluskoodin oikeellisuutta. Tällaisia kysymyksiä käsitellään käytännössä esimerkiksi koneiden ja tuotantolinjojen turvallisuusauditoinnissa sekä osana koneiden CE-merkintää ja vaatimustenmukaisuuden arviointia.
Miten suunnitella teollisia sovelluksia, jotka kestävät tilapäiset verkkokatkokset, laitteiden uudelleenkäynnistykset ja yhteyden katkeamisen?
Koska se vaikuttaa koneen tilamalliin, komentojen kuittausperiaatteisiin, tietojen puskurointiin ja työn jatkamisen ehtoihin uudelleenkäynnistyksen jälkeen. Näiden päätösten lykkääminen johtaa yleensä kalliisiin kiertoratkaisuihin ja riskien siirtämiseen käytön aikaiselle toiminnalle.
On yksiselitteisesti määriteltävä, mitä tapahtuu yhteyden katketessa, mitä uudelleenkäynnistyksen jälkeen ja kuka vahvistaa työn jatkamisen. Jos vastaus riippuu pelkästään toteutuksesta tai käyttäjän toiminnasta, riskiä ei ole hallittu asianmukaisesti suunnittelulla.
Tilanteissa, joissa järjestelmä ei pysty osoittamaan, onko komento suoritettu, keskeytetty, toistettu vai ainoastaan rekisteröity käyttöliittymässä. Tämä koskee erityisesti toimintoja, joilla on fyysinen vaikutus, kuten käyttölaitteen liike, asetuksen muutos, venttiilin avaus tai syklin jatkaminen.
Ei aina, koska viestiyhteyden palautumisen jälkeen prosessin olosuhteet voivat jo olla toiset kuin käskyn antamishetkellä. Artikkelissa korostettiin, että jotkin toiminnot voidaan toistaa ilman sivuvaikutuksia, mutta toiset edellyttävät kohteen nykytilan varmistamista tai alasajoa turvalliseen tilaan.
On hyödyllistä mitata epäselvien uudelleenkäynnistysten määrää restartin jälkeen, niiden komentojen määrää, jotka edellyttävät tilan manuaalista yhteensovittamista, turvalliseen työn jatkamiseen tarvittavaa aikaa sekä tapauksia, joissa järjestelmä ei pysty osoittamaan, onko käsky toteutettu. Tällaiset mittarit kuvaavat todellista riskiä paremmin kuin yleinen arvio ”järjestelmän vakaudesta”.