Kā projektēt rūpnieciskās lietojumprogrammas, kas ir noturīgas pret īslaicīgu tīkla nepieejamību, ierīču restartēšanu un savienojuma zudumu?

Rūpnieciskas lietojumprogrammas noturība pret īslaicīgu tīkla zudumu, ierīču restartu un savienojuma pārtraukumu mūsdienās vairs nav papildu ērtība lietotājam, bet gan priekšnoteikums procesa pareizai darbībai un atbildības saglabāšanai ražotāja, integratora vai gala lietotāja pusē. Rūpnieciskā vidē sakaru zudums nav izņēmuma situācija: tas rodas apkopes darbu laikā, infrastruktūras pārslēgšanas brīžos, palaižot sistēmu pēc elektroapgādes pārtraukuma, atjauninājumu laikā, tīkla pārslodzes dēļ vai vienkārši malas ierīces atteices gadījumā. Ja lietojumprogramma šādos apstākļos zaudē stāvokļu konsekvenci, dublē komandas vai pēc savienojuma atjaunošanas bez konteksta kontroles izpilda iepriekš neizpildītas darbības, problēma vairs nav tikai IT jautājums. Tā kļūst par procesa nepārtrauktības, funkcionālās drošības, ražošanas datu kvalitātes un projektēšanas lēmumu izsekojamības jautājumu.

Tāpēc šis jautājums jāizlemj projekta sākumā, nevis pēc pirmās palaišanas. Arhitektūra, kas ir noturīga pret sakaru pārtraukumiem, ietekmē to, kā tiek modelēti iekārtas stāvokļi, kādi ir datu buferēšanas principi, kādā secībā tiek apstiprinātas komandas, kādi ir sesijas atkārtotas izveides nosacījumi un kāda ir atgriešanās darbā loģika pēc restarta. Ja komanda šos lēmumus atliek, parasti tas beidzas ar dārgiem apiešanas risinājumiem: lokāli piemeklētiem izņēmumiem, manuālu rindu tīrīšanu, papildu operatora bloķēšanām vai uzraudzības slāņa paplašināšanu tikai tāpēc, lai kompensētu ierīču neprognozējamu uzvedību. Praktisks vērtēšanas kritērijs ir vienkāršs: par katru būtisku funkciju jāspēj nepārprotami atbildēt, kas notiks pēc savienojuma zuduma, kas notiks pēc restarta un kurš apstiprina darba atsākšanu. Ja atbilde ir “tas ir atkarīgs no implementācijas” vai “operators redzēs, ka kaut kas nav kārtībā”, tad tas vēl nav projektēšanas lēmums, bet gan riska pārlikšana uz ekspluatāciju.

Vislabāk tas redzams lietojumprogrammas saskarē ar iekārtas vai procesa kustību. Iedomāsimies sistēmu, kurā operatora panelis dod komandu sākt ciklu, bet kontrolieris to izpilda ar aizkavi īslaicīga savienojuma zuduma dēļ. Ja pēc komunikācijas atjaunošanas lietojumprogramma komandu nosūta atkārtoti, jo nav saņēmusi apstiprinājumu, var notikt darbības dubulta izpilde vai palaišana apstākļos, kas atšķiras no tiem, kurus operators redzēja komandas došanas brīdī. Šajā vietā komunikācijas noturības tēma sāk pāriet aizsardzības pret negaidītu iedarbināšanu jomā: ne katrs restarts ir drošības problēma, taču katrs restarts, kas var mainīt palaišanas apstākļus bez apzināta apstiprinājuma un bez ierīces stāvokļa pārbaudes, jau prasa analīzi šajā līmenī. Līdzīgi ir ar bloķēšanas ierīcēm un aizturēm: ja lietojumprogrammas loģika mudina personālu pēc tīkla atteices apiet apgrūtinošas bloķēšanas, tad problēma nav tikai lietotāja rīcībā, bet arī projektēšanas lēmumā.

No vadības un atbilstības viedokļa izšķirošais nav tas, vai sakaru pārtraukumi “gadās”, bet gan tas, vai projekts spēj pierādīt drošu un paredzamu uzvedību šādos robežstāvokļos. Tas ir arī īstais brīdis, kad tēma pāriet praktiskā riska novērtēšanā: jānodala funkcijas, kurām ir pieļaujama aizkave vai daļējs vēsturisko datu zudums, no funkcijām, kurās konteksta zudums var novest pie operatora kļūdaina lēmuma, izstrādājuma bojājuma vai apdraudējuma atkārtotas palaišanas laikā. Ir vērts mērīt nevis abstraktu “sistēmas stabilitāti”, bet rādītājus, kas parāda projektēšanas sekas: neviennozīmīgu atsākšanu skaitu pēc restarta, komandu skaitu, kurām nepieciešama manuāla stāvokļa saskaņošana, laiku, kas vajadzīgs drošai darba atsākšanai, un gadījumus, kuros sistēma nespēj pierādīt, vai komanda ir izpildīta. Tikai uz šāda fona jēgu iegūst normatīvās prasības un lēmumi par tehniskajiem pasākumiem: palaišanas apstākļu analīze pēc elektroapgādes zuduma, riska novērtējums sakaru zuduma scenārijiem un bloķēšanas un uzraudzības risinājumu izvēle tur, kur ar pašu IT mehānismu nepietiek, lai nodrošinātu vajadzīgo pārliecību.

Kur visbiežāk pieaug izmaksas vai risks

Rūpniecisko lietojumprogrammu projektos, kam jābūt noturīgiem pret īslaicīgu tīkla zudumu, ierīču restartu un savienojuma pārtraukumu, izmaksas visbiežāk nepieaug pašu tehnisko mehānismu dēļ, bet gan kļūdainu pieņēmumu dēļ par procesa stāvokli pēc traucējuma. Ja komanda pieņem, ka pēc savienojuma atjaunošanas sistēma “atgriezīsies normālā darbībā”, agrāk vai vēlāk nāksies maksāt par manuālu stāvokļu saskaņošanu, vadības loģikas labojumiem, papildu pieņemšanas testiem vai ekspluatācijas ierobežojumiem, kas noteikti jau pēc palaišanas. Visdārgākās ir situācijas, kurās lietojumprogramma nespēj nepārprotami atbildēt, vai komanda ir izpildīta, pārtraukta, dublēta vai tikai reģistrēta interfeisa pusē. Tā nav lietotāja ērtības problēma, bet atbildība par fizisko rezultātu: piedziņas kustību, iestatījuma maiņu, vārsta atvēršanu, trauksmes apstiprināšanu vai cikla atsākšanu.

Projektu kavējumus bieži izraisa arī nepareizi sadalīta atbildība starp operatora līmeni, starpprogrammatūru un iekārtas vadību. Ja lēmums par to, kam jānotiek pēc restartēšanas, tiek atlikts “uz ieviešanas posmu”, komanda parasti nonāk pie savstarpēji nesaskaņotiem noteikumiem: panelis rāda pēdējo zināmo stāvokli, kontrolleris palaiž inicializācijas procedūru, bet virsvadības sistēma atjauno neizpildītās komandas, nepārliecinoties, vai tās joprojām ir pamatotas. Praksē tas jāizlemj agrāk un skaidri: kuras darbības drīkst atkārtot bez blaknēm, kurām nepieciešams apstiprinājums par objekta aktuālajiem apstākļiem un kurām pēc sakaru zuduma ir jābeidzas un jāpāriet drošā stāvoklī. Labs lēmuma pieņemšanas kritērijs ir vienkāršs: ja kļūdaina darbības atsākšana var mainīt enerģijas stāvokli, izpildmehānisma pozīciju, izstrādājuma kvalitāti vai cilvēku drošības apstākļus, nedrīkst paļauties tikai uz lietotnes atmiņā saglabāto pēdējo stāvokli.

To labi var redzēt piemērā ar secību, kas pirms sakaru zuduma nosūtīja komandu aizvērt aizsargu un sākt ciklu, bet pēc operatora stacijas restartēšanas atjauno ekrānu “gatavs darbam”. Ja lietotne neatšķir stāvokļus “komanda pieņemta”, “izpilde apstiprināta”, “izpilde pārtraukta”, “nenoteikts stāvoklis”, operators saņem šķietami saskaņotu, bet patiesībā nepilnīgu ainu. Sekas var būt nevajadzīgas dīkstāves, jo personāls baidās atsākt procesu, vai arī pretēji — neatļauta palaišana, jo saskarne neparāda nepieciešamību veikt atkārtotu pārbaudi. Projekta vadītājam tas vēlāk nozīmē dārgu cēloņu izmeklēšanu, testēšanas scenāriju maiņu un nepieciešamību papildināt apiešanas procedūras. Produkta īpašniekam tas ir sūdzību un strīdu risks par atbildības robežām, īpaši tad, ja prasību dokumentācijā nav viennozīmīgi noteikta sistēmas rīcība pēc barošanas vai sakaru zuduma. Tāpēc ir vērts mērīt ne tikai pieejamību, bet arī nenoteikto stāvokļu skaitu pēc restartēšanas, to darbību skaitu, kurām nepieciešama manuāla saskaņošana, un laiku līdz drošas gatavības sasniegšanai.

Atsevišķa izmaksu kategorija ir komunikācijas noturības jaukšana ar funkcionālo drošību. Tas vien, ka lietotne spēj buferēt datus, atkārtot pārraidi vai atjaunot sesiju, vēl nenozīmē, ka iekārta pēc savienojuma zuduma rīkosies droši. Ja traucējuma ietekme skar funkcijas, kas saistītas ar kustību, uzkrāto enerģiju, bloķēšanu vai atkārtotas palaišanas nosacījumiem, tēma dabiski pāriet praktiskā riska novērtēšanā. Tad jāvērtē ne tikai tīkla atteices varbūtība, bet galvenokārt iespējamās sekas, ko rada kļūdaina informācija par stāvokli un kļūdaina darbības atsākšana. Ja sistēmā ir hidraulika, papildus jāņem vērā prasības attiecībā uz izpildmehānismu uzvedību barošanas zuduma un spiediena krituma gadījumā; šādās situācijās lietotnes līmeņa lēmumi nedrīkst būt pretrunā ar projektēšanas principiem, kas attiecas uz hidrauliskajām sistēmām. Savukārt tur, kur gatavības atjaunošana ir atkarīga no aizsarga aizvēršanas vai bloķēšanas atbrīvošanas, problēma var skart arī bloķēšanas ierīču un aizsardzības apiešanas novēršanas jomu, jo spiediens uz “ātru darba atsākšanu” ļoti bieži vēlāk rada bīstamu ekspluatācijas praksi.

Normatīvām atsaucēm ir jēga tikai šajā posmā, kad jau ir zināms, kurš scenārijs rada tehniskas un organizatoriskas sekas. Ja savienojuma zudums vai restartēšana var mainīt drošas palaišanas nosacījumus, tas jāapraksta riska analīzē, nevis jāatstāj kā programmatūras ražotāja vai kontrollera piegādātāja noklusētā uzvedība. Ja izpildsistēma pēc barošanas zuduma var nonākt procesam nelabvēlīgā vai bīstamā stāvoklī, jāpārbauda, vai prasības konkrētajam piedziņas un darba vides veidam neparedz papildu konstruktīvus pasākumus, kas ir neatkarīgi no lietotnes loģikas. Praktiska robežkritērija formulējums ir šāds: ja kļūdu pēc stāvokļa atjaunošanas var novērst tikai ar operatora procedūru, jautājums vairs nav tikai informācijas tehnoloģiju jomā, bet attiecas arī uz projektēšanu un atbilstību. Tieši šajā brīdī lēmums par lietotnes arhitektūru pārstāj būt ieviešanas ērtuma jautājums un kļūst par atbildības daļu par visas sistēmas drošu un paredzamu darbību.

Kā šai tēmai pieiet praksē

Praksē rūpnieciskas lietotnes noturība pret īslaicīgu tīkla zudumu, ierīču restartēšanu un savienojuma pārtraukumu nesākas ar tehnoloģijas izvēli, bet ar lēmumu par to, kuras atteices sekas ir pieļaujamas un kuras nav. Komandai sākumā jānodala trīs lietas: procesa stāvoklis, vadības stāvoklis un operatoram attēlotais stāvoklis. Šī atšķiršana nosaka, vai pēc sakaru pārtrūkšanas lietotnei ir tikai jāatjauno skats vai arī tai ir tiesības atsākt vadību, komandu rindu vai tehnoloģisko secību. Ja šie līmeņi tiek sapludināti vienā, projekts parasti beidzas ar dārgu izņēmumu pierakstīšanu, manuālām apiešanas procedūrām vai strīdu par atbildību pēc nodošanas ekspluatācijā. Vadītājam šeit būtisks ir viens secinājums: skaidra arhitektūras lēmuma trūkums risku nesamazina, bet tikai pārceļ to uz pieņemšanas, servisa un atbilstības posmu.

No operatīvā viedokļa tas nozīmē, ka katram kritiskajam scenārijam ir jānosaka, ko sistēmai pēc traucējuma drīkst saglabāt un ko tā nedrīkst saglabāt. Runa nav par vispārīgu lozungu “tai jādarbojas pēc atkārtotas pieslēgšanās”, bet gan par precīziem noteikumiem: kuri dati tiek atjaunoti no noturīgā ieraksta, kuri ir atkārtoti jāapstiprina no iekārtas, kuras komandas pēc noteikta laika zaudē spēku un kurām nepieciešama atkārtota autorizācija vai operatora apstiprinājums. Labs lēmuma pieņemšanas kritērijs ir vienkāršs: ja pēc restartēšanas nav iespējams viennozīmīgi noteikt, vai iepriekšējā komanda tika izpildīta, sistēma to nedrīkst izpildīt atkārtoti automātiski. Tas pats attiecas uz trauksmēm, partiju skaitītājiem, darba režīmiem un tehnoloģiskajām bloķēšanām. Šāds ieraksts var šķist nenozīmīga projektēšanas detaļa, taču bez tā pieaug integrācijas testu izmaksas, jo katra neskaidrība atgriežas kā kļūda, kuru ir grūti reproducēt. Pieaug arī risinājuma īpašnieka atbildība, jo vēlāk ir jāpierāda, ka uzvedība pēc sakaru zuduma bija paredzama un apzināti noteikta.

Tipisks piemērs ir lietotne, kas nosūta vadības ierīcei komandu sākt ciklu un pēc tam zaudē savienojumu, vēl pirms saņemts apstiprinājums. Ja pēc savienojuma atjaunošanas lietotne “drošības pēc” nosūta komandu vēlreiz, tā var palaist ciklu otro reizi. Savukārt, ja tā pieņem, ka komanda noteikti tika izpildīta, tā var kļūdaini atjaunot procesa stāvokli un pieļaut nākamās darbības nepareizā secībā. Pareiza pieeja ir projektēt komandas un atbildes tā, lai tās būtu atšķiramas laikā un identificējamas, un lai pēc restartēšanas pirms biznesa loģikas atsākšanas būtu iespējams pārbaudīt iekārtas faktisko stāvokli. Šeit ir vērts mērīt ne tikai sistēmas pieejamību, bet arī neskaidru stāvokļa atjaunošanas gadījumu skaitu, manuālo iejaukšanos skaitu pēc restartēšanas un laiku, kas nepieciešams drošai darba atjaunošanai. Tie ir rādītāji, kas parāda arhitektūras reālās izmaksas, nevis tikai programmēšanas ērtumu.

Robeža ar praktisku riska novērtēšanu parādās brīdī, kad kļūdaina stāvokļa atjaunošana var mainīt mašīnas, secības vai izpildmehānisma darbību. Šādā gadījumā tēma vairs nav tikai informācijas tehnoloģiju jautājums, bet nonāk praktiska riska novērtējuma jomā, arī ISO/TR 14121-2 izmantotās metodikas izpratnē. Ja pēc elektroapgādes zuduma vai iekārtas restartēšanas pastāv iespēja, ka kustība atsāksies pati no sevis, tiks padota vide, atbrīvots izpildmehānisms vai notiks pāreja darba režīmā bez apzinātas operatora piekrišanas, jautājums skar arī aizsardzību pret negaidītu palaišanu, un tas prasa plašāku skatījumu nekā tikai lietotnes loģika. Tur, kur tiek izmantotas hidrauliskās vai pneimatiskās piedziņas, papildus jāņem vērā konstrukcijas prasības un sistēmas uzvedība enerģijas zuduma gadījumā, tāpēc lēmumu par “mīkstu” darba atsākšanu nevar pieņemt atrauti no visas instalācijas tehniskajiem apstākļiem. No atbilstības viedokļa visdrošāk ir pēc traucējuma nevis minēt procesa nodomu, bet iepriekš noteikt darba atsākšanas nosacījumus un piesaistīt tos konkrētai atbildībai: lietotnei, vadības ierīcei, izpildmehānismam un operatoram.

Kam pievērst uzmanību ieviešanas laikā

Visvairāk kļūdu, ieviešot rūpnieciskas lietotnes, kas ir noturīgas pret īslaicīgu tīkla zudumu, iekārtu restartēšanu un savienojuma pārtraukumiem, nerodas pašas tehnoloģijas dēļ, bet gan nepareizi sadalītas atbildības dēļ. Komanda pieņem, ka “noturību” nodrošinās sakaru slānis, mākoņpakalpojuma sniedzējs vai vadības ierīce, lai gan problēma slēpjas attiecībās starp procesa stāvokli, iekārtas stāvokli un datu stāvokli. Ja šīs trīs kārtas netiek nodalītas jau pieņemšanas posmā, projekts sāk radīt šķietamu uzticamību: lietotne pēc atkārtotas palaišanas darbojas, bet neviens nespēj pierādīt, vai pēc restartēšanas tā atjaunoja pareizu, drošu un fiziskajai realitātei atbilstošu stāvokli. Tas tieši ietekmē izmaksas, jo vēlākie labojumi parasti prasa vienlaikus mainīt vadības loģiku, operatora saskarni, notikumu reģistrēšanu un palaišanas procedūras. Tas ietekmē arī atbildību, jo incidenta gadījumā ir grūti aizstāvēt risinājumu, kurā nav viennozīmīgi noteikts, kurš un uz kāda pamata apstiprina gatavību atsākt darbu.

Praksē bīstamākais slazds ir savienojuma zudumu uztvert kā parastu tehnisku kļūmi, nevis kā atsevišķu sistēmas darbības stāvokli. Ja lietotne pēc tīkla zuduma buferē darbības un pēc savienojuma atjaunošanas tās atskaņo, nepārbaudot aktuālo kontekstu, tā var izpildīt novēlotas, vairs neatļautas vai faktiskajam līnijas stāvoklim pretrunīgas darbības. Līdzīga problēma rodas pēc iekārtas restartēšanas: iepriekš saglabātais loģiskais stāvoklis formāli var būt pilnīgs, taču fiziski vairs neatbilst realitātei, jo pa to laiku ir mainījies izpildmehānisma stāvoklis, vides spiediens, darba režīma konfigurācija vai apkalpojošā personāla iejaukšanās. Labs lēmuma pieņemšanas kritērijs arī šeit ir vienkāršs: ja pēc stāvokļa atjaunošanas sistēmai ir jāveic jebkāda darbība, kas ietekmē procesu, vispirms jāspēj pārbaudīt tās pieļaujamību, balstoties uz aktuālajiem signāliem, nevis tikai uz vēsturi, kas saglabāta pirms traucējuma. Ja šādu pārbaudi nav iespējams pamatot, drošāks risinājums ir pāriet stāvoklī, kurā nepieciešams nepārprotams apstiprinājums vai atkārtota sinhronizācija.

Labs piemērs ir stacija, kas pēc īslaicīga sakaru pārtraukuma zaudē savienojumu ar virsvadības sistēmu, bet lokāli joprojām redz daļu ieejas signālu. No programmas viedokļa ir vilinoši pēc savienojuma atjaunošanas “pabeigt secību”, lai nezaudētu cikla laiku. Problēma sākas brīdī, kad pārtraukuma laikā operators ir izņēmis detaļu, ir nostrādājis atslogošanas vārsts, ir notikusi paneļa restartēšana vai piedziņa ir pārgājusi citā režīmā. Lietojumprogrammas loģikā viss var izskatīties saskaņoti, tomēr soļa atsākšana var kļūt par tehnoloģisku kļūdu vai radīt apdraudējumu. Tāpēc ieviešanas laikā ir vērts vērtēt ne tikai zaudēto ziņojumu skaitu vai sesijas atjaunošanas laiku, bet arī rādītājus, kas parāda sistēmas uzvedības kvalitāti pēc traucējuma: cik reižu sistēmai bija nepieciešama manuāla resinhronizācija, cik operāciju tika noraidītas kā vairs neaktuālas, cik restartu beidzās ar pāreju drošā stāvoklī, nevis ar automātisku atsākšanu. Tie ir labāki risinājuma brieduma rādītāji nekā tikai pakalpojuma pieejamība, jo tie atklāj, vai noturība nav panākta uz procesa kontroles rēķina.

Robeža, kur šī tēma pārstāj būt tikai lietojumprogrammas arhitektūras jautājums, parādās ātrāk, nekā projektu komandas parasti pieņem. Ja savienojuma zudums, kontrollera restartēšana vai uzdevumu rindas atjaunošana var ietekmēt mašīnas kustību, enerģijas padevi vai izpildmehānisma stāvokļa maiņu, šis jautājums praksē pāriet uz praktisku riska novērtējumu. Šādā situācijā vairs nepietiek ar argumentu, ka risinājums “parasti darbojas pareizi”; ir nepieciešama noviržu scenāriju analīze, arī loģikā, kas ir tuva pieejai, kura izmantota ISO/TR 14121-2. Ja turklāt pēc barošanas vai sakaru atjaunošanas pastāv iespēja funkciju atsākt automātiski, jautājums attiecas arī uz aizsardzību pret negaidītu iedarbināšanu un tas jāizskata plašākā kontekstā, saistībā ar palaišanas nosacījumiem un enerģijas atslēgšanas stāvokli. Tur, kur sistēma ietver hidrauliku vai pneimatiku, programmēšanas lēmumu nevar nošķirt no instalācijas uzvedības pēc enerģijas zuduma; šādos gadījumos jāpārbauda arī visai sistēmai piemērojamās konstrukcijas prasības, nevis tikai lietojumprogrammas koda pareizība.