Vai REST API vienmēr ir piemērots rūpniecībai? Kad labāk izvēlēties rindas, brokerus un uz notikumiem balstītu saziņu?

Jautājums par to, vai REST API ir piemērots rūpniecībai, šodien vairs nav strīds par vēlamo integrācijas stilu, bet gan lēmums par to, kur projektā tiks uzņemtas izmaksas, aizkaves un operatīvā atbildība. Rūpnieciskā vidē komunikācijas saskarne ļoti ātri pārstāj būt tikai “tehniskais slānis” un sāk ietekmēt procesa nepārtrauktību, darbību atkārtojamību, audita iespējas un reaģēšanas veidu avāriju gadījumā. REST labi darbojas tur, kur sagaidām vienkāršu izsaukumu, nepārprotamu atbildi un skaidru pieprasījuma stāvokļa kontroli. Problēmas sākas brīdī, kad sistēmai jādarbojas arī tad, ja kāds no dalībniekiem īslaicīgi nav pieejams, kad ziņojumi jāpiegādā ar saņemšanas apstiprinājumu vai kad vienam notikumam jāizraisa sekas vairākās neatkarīgās jomās. Tad izvēle starp sinhronu pieprasījumu un rindu, brokeri vai notikumu vadītu komunikāciju vairs nav tehniski neitrāla.

Tas ir īpaši svarīgi tieši tagad, jo arvien vairāk rūpniecisko projektu vienā atkarību ķēdē apvieno vadību, uzturēšanu, kvalitātes sistēmas, ražošanas atskaites un ārējos pakalpojumus. Ja arhitektūra tiek balstīta tikai uz sinhroniem izsaukumiem, komanda bieži saņem sistēmu, kas šķietami ir vienkārša, bet kļūst trausla, pieaugot integrāciju skaitam, nestabila tīkla apstākļos vai tad, ja nepieciešama stingra notikumu izsekojamība. Šāda lēmuma izmaksas neatklājas funkciju demonstrācijas posmā, bet vēlāk: procesos, kurus bloķē nepieejams komponents, sarežģītā incidenta gaitas atjaunošanā, manuālā stāvokļu saskaņošanā starp sistēmām un strīdos par to, vai operācija tika izpildīta vai tikai uzdota. Produkta īpašniekam un projekta vadītājam praktiskais kritērijs ir vienkāršs: jāizšķir, vai konkrētajai datu apmaiņai ir raksturs “jautājums–atbilde šeit un tagad” vai drīzāk “reģistrē faktu un nodrošini tā turpmāku apstrādi arī traucējumu gadījumā”. No šīs atbildes ir atkarīga ne tikai tehnoloģija, bet arī atbildības modelis starp komandām.

Praksē to labi var redzēt mašīnu sistēmās, kur viena operatora darbība vai viens procesa notikums ir jāreģistrē, jānodod un jāapstiprina vairākās vietās. Ja uzraudzības lietotne secīgi nosūta sinhronus pieprasījumus vairākiem pakalpojumiem un gaida pilnu atbilžu kopumu, tad īslaicīga problēma vienā elementā var apturēt visu secību, lai gan daļai biznesa seku būtu jāiestājas neatkarīgi. Savukārt brokeris vai rinda ļauj nodalīt informācijas pieņemšanas brīdi no tās apstrādes brīža, saglabāt notikuma pēdu un vieglāk kontrolēt atkārtotu izpildi pēc kļūdas. Tas nenozīmē, ka notikumu vadīta komunikācija vienmēr ir labāka: ja nepieciešams tūlītējs lēmums, kas bloķē turpmāku mašīnas darbību, vai operatoram nekavējoties jāsaņem saistoša atbilde, asinhrons modelis bez labi izstrādātiem starpstāvokļiem var palielināt nenoteiktību. Tāpēc jau projekta sākumā ir vērts mērīt ne tikai atbildes laiku, bet arī pazaudēto vai dublēto ziņojumu skaitu, atšķirīgu stāvokļu saskaņošanas laiku un iespēju pēc incidenta atjaunot notikumu secību.

Šis jautājums dabiski sasaucas ar riska novērtēšanu saskaņā ar ISO 12100 rūpnieciskajos projektos, jo komunikācijas veida izvēle ietekmē kļūdas sekas, noviržu atklājamību un iespēju ieviest efektīvus riska mazināšanas pasākumus. Ja caur saskarni tiek īstenotas funkcijas, kuru kļūdaina izpilde var izraisīt neparedzētu iedarbināšanu, bīstamu stāvokļa maiņu vai kontroles zudumu pār enerģiju, jautājums vairs nav tikai IT jomā, bet pāriet uz mašīnas sistēmas projektēšanu un aizsardzības pasākumu izvērtēšanu. Šajā vietā parādās arī robeža, no kuras jāizskata saistītie jautājumi, tostarp aizsardzība pret negaidītu iedarbināšanu un praktiska riska novērtēšana pēc pieņemtās metodikas. Citiem vārdiem sakot: lēmums par REST, rindu vai brokeri būtu jāpieņem nevis pēc integrācijas demonstrācijas, bet tad, kad komanda spēj nosaukt kļūdaina vai aizkavēta ziņojuma sekas procesam, drošībai un darbību izsekojamībai.

Kur visbiežāk pieaug izmaksas vai risks

Lielākā daļa kļūdaino lēmumu nerodas no “nepareizas tehnoloģijas” izvēles, bet gan no tā, ka REST API tiek izmantots uzdevumiem, kuriem tas nav paredzēts. Rūpniecībā izmaksas pieaug tad, ja pieprasījuma–atbildes saskarnei jānodrošina komunikācija, kas ir jutīga pret īslaicīgu nepieejamību, notikumu secību vai nepieciešamību pēc uzticama izpildes apstiprinājuma. Ja sistēmai tikai jānolasa ierīces pašreizējais stāvoklis vai jāpieņem komanda, kuras neizpildi var viegli pamanīt un atkārtot bez blaknēm, REST var būt pietiekams. Taču, ja rezultāts ir atkarīgs no tā, vai ziņojums tika piegādāts tieši vienu reizi, pareizajā secībā un ar iespēju pēc incidenta atjaunot vēsturi, REST ierobežojumu apiešanas izmaksas ātri pārsniedz šķietamo ieviešanas vienkāršību. Praksē tas nozīmē papildu atkārtošanas loģiku, pašu veidotus buferēšanas mehānismus, atšķirīgu stāvokļu saskaņošanu un sarežģītāku atbildības noteikšanu, ja ierīce operāciju izpildīja vēlāk, nekā bija gaidīts, vai izpildīja to divreiz.

Projektēšanas posmā problēma parasti izskatās nevainīga: komanda pieņem, ka tīkls ir stabils, pakalpojumi ir pastāvīgi pieejami un abās integrācijas pusēs sistēmas stāvoklis ir viennozīmīgs. Rūpnieciskā vidē šādi pieņēmumi reti saglabājas ilgi. Rodas sakaru pārtraukumi, ierīces restartēšana, starpsistēmas atjaunināšana, bet dažkārt vienkārši pārslodze ražošanas maiņas laikā. Tad arhitektūra, kas balstīta tikai uz sinhroniem izsaukumiem, sāk pārlikt risku uz lietotnēm un operatoriem. Projekta izmaksas pieaug ne tikai programmēšanas labojumu dēļ, bet arī atjaunošanas testu, papildu ekspluatācijas procedūru un strīdu dēļ par to, kurai pusei “vajadzēja zināt”, ka pieprasījums nav izpildīts. Praktiskais lēmuma kritērijs ir vienkāršs: ja saņēmēja nepieejamība nedrīkst apturēt sūtītāju un ziņojums ir droši jāsaglabā un jāapstrādā vēlāk, nopietni jāapsver rinda, brokeris vai notikumpamatota komunikācija tīra REST vietā.

Labs piemērs ir uzraudzības sistēmas integrācija ar līniju, kurā viena sistēma uzdod receptes maiņu, bet vairākām citām šī maiņa ir jāpieņem, jāapstiprina un jāpiemēro pareizajā cikla brīdī. Ar REST ir viegli izveidot izsaukumu “iestatīt parametrus”, taču grūtāk ir nodrošināt, ka visi iesaistītie elementi ir saņēmuši vienu un to pašu informāciju, ka vecāks ziņojums nepārrakstīs jaunāku un ka pēc avārijas būs iespējams noteikt, kurš kuru komandu ir redzējis. Notikumu brokeris vai rinda šo problēmu sakārto citādi: ziņojums kļūst par noturīgu faktu sistēmā, kuru var izsekot, apstrādāt atkārtoti un neatkarīgi saņemt vairākiem adresātiem. Tā nav tikai tehniska izvēle. No tās ir atkarīgs, vai partijas reklamācijas, dīkstāves vai incidenta gadījumā būs iespējams pierādīt sistēmas lēmumu gaitu un līdz ar to arī noteikt līgumisko, operatīvo vai iekšējo atbildību. Tur, kur svarīga ir izsekojamība, ir vērts mērīt ne tikai atbildes aizkavi, bet arī to ziņojumu skaitu, kuri jānosūta atkārtoti, stāvokļa saskaņošanas laiku pēc avārijas un iespēju atjaunot notikumu secību bez manuālas rekonstrukcijas no vairākiem žurnāliem.

Šis jautājums pāriet riska novērtēšanas saskaņā ar ISO 12100 jomā brīdī, kad kļūdains vai novēlots ziņojums var mainīt mašīnas, procesa vai aizsarglīdzekļa darbību. Šādā gadījumā vairs nepietiek ar jautājumu par integrācijas ērtumu; jānovērtē sekas, atklājamība un iespēja ierobežot sekas, kas atbilst ISO 12100 pazīstamajai praksei. Ja komunikācija attiecas uz ar drošību saistītām funkcijām, bloķēšanām, palaišanas nosacījumiem vai enerģijas stāvokļa apstiprinājumiem, projektēšanas atbildības robeža pārvietojas no lietotnes līmeņa uz visas mašīnas sistēmas līmeni. Līdzīgi arī izpildmehānismu sistēmās, tostarp hidrauliskajās, kļūdains pieņēmums par savlaicīgu informācijas piegādi var nonākt pretrunā ar aizsarglīdzekļu un drošu stāvokļu projektēšanas principiem, kas dabiski ved pie jautājumiem, kas saistīti ar LVS EN ISO 4413. Citiem vārdiem, rindas un brokeri nav “labāki pēc definīcijas”, taču tie kļūst par pareizo izvēli tur, kur projektam jāiztur sakaru atteice, nezaudējot kontroli, vēsturi un atbildību par veiktajām darbībām.

Kā šai tēmai pieiet praksē

Praksē jautājums nav par to, vai REST API ir labs vai slikts, bet gan par to, vai tas atbilst kļūdas, aizkaves un atbildes trūkuma sekām konkrētajā rūpnieciskajā procesā. Ja komunikācija galvenokārt kalpo datu nolasīšanai, administratīvu darbību ierosināšanai vai integrācijai ar biznesa sistēmām, pieprasījuma–atbildes interfeiss mēdz būt vienkāršākais un lētākais risinājums. Problēma sākas tad, kad projektā ir paredzēta nepārtraukta informācijas apmaiņa, neraugoties uz vienas puses īslaicīgu nepieejamību, vajadzība pēc sakārtotas notikumu apstrādes vai pienākums atjaunot, kas, kad un uz kāda pamata izraisīja noteiktu stāvokļa maiņu. Šādā situācijā REST izvēle kā noklusētais mehānisms bieži samazina sākotnējās ieviešanas izmaksas, bet palielina avāriju apstrādes, stāvokļa saskaņošanas pēc pārtraukuma un incidenta izmeklēšanas izmaksas. Tas ir brīdis, kad rindas, brokeri un notikumpamatota komunikācija vairs nav “arhitektūras papildinājums”, bet kļūst par instrumentu projektēšanas riska un operatīvās atbildības ierobežošanai.

Komandai un vadītājam tas nozīmē nepieciešamību pieņemt arhitektūras lēmumu, balstoties uz vairākām izmērāmām procesa īpašībām, nevis izpildītāja vēlmēm. Vislietderīgākais kritērijs ir vienkāršs: jānosaka, kam jānotiek ar ziņojumu, ja saņēmējs nosūtīšanas brīdī neatbild. Ja pareizā atbilde ir “nekas kritisks, operāciju var droši atkārtot vai noraidīt”, REST parasti ir pietiekams. Savukārt, ja ziņojums ir jāsaglabā, jāpiegādā pēc darba atsākšanas, jāapstrādā tikai vienu reizi vai pierādāmā secībā, tad sinhronā arhitektūra sāk neatbilst procesa prasībām. To ir vērts nofiksēt jau pieņēmumu posmā kā pieņemšanas kritērijus: pieļaujamais partnera nepieejamības laiks, atkārtošanas veids, deduplikācijas noteikumi, iespēja izsekot notikumu korelācijai un veids, kā atjaunot stāvokli pēc avārijas. Bez šādām vienošanām projekts šķietami sākas ātrāk, taču vēlāk atgriežas dārgu integrācijas izmaiņu, strīdu par atbildības robežām un grūti novēršamu ekspluatācijas neatbilstību veidā.

Labs piemērs ir līnija vai šūna, kurā virsvadības sistēma nodod uzdevumus, bet kontrolieri un darba vietas ziņo par izpildi, brāķi, bloķēšanām vai pārejām starp darba režīmiem. Ja katrs notikums tiek nekavējoties “aptaujāts” ar REST palīdzību, tad pat īslaicīga savienojuma zuduma gadījumā ļoti ātri rodas neatbilstība starp faktisko stāvokli un to, kas redzams lietotnē. No ražošanas viedokļa tas beidzas ar manuālu saskaņošanu, no kvalitātes viedokļa – ar robu partijas vēsturē, bet no tehniskās uzturēšanas viedokļa – ar nenoteiktību, vai konkrētā komanda tika izpildīta vai tikai nosūtīta. Brokeris ar noturīgu ziņojumu saglabāšanu neatrisina visu, taču tas sakārto atbildību: sūtītājs notikumu nodeva, starpsistēma to saglabāja, saņēmējs to apstiprināja vai neapstiprināja. Tā ir būtiska atšķirība, analizējot dīkstāves cēloņus un noskaidrojot, vai kļūda radās procesa loģikas, tīkla atteices vai operatora kļūdainas darbību secības dēļ. Tieši tāpēc lēmums par komunikācijas modeli ietekmē ne tikai ieviešanas izmaksas, bet arī palaišanas, servisa un audita laiku.

Šis jautājums pāriet praktiskas riska novērtēšanas saskaņā ar ISO 12100 jomā brīdī, kad ziņojums vairs nav tikai informācija, bet kļūst par nosacījumu mašīnas, procesa vai aizsardzības līdzekļa darbībai. Ja no pareizas stāvokļa nodošanas ir atkarīga iedarbināšana, darba atsākšana pēc apstādināšanas, secības atbloķēšana vai droša enerģijas stāvokļa apstiprināšana, tad integrācijas lēmums kļūst par daļu no projektēšanas lēmuma ar lielāku nozīmi. Šādā gadījumā jānovērtē ne tikai komunikācijas pieejamība, bet arī tās zuduma, aizkaves, dublēšanās un kļūdainas interpretācijas sekas; te dabiski parādās metodoloģija, kas zināma no ISO 12100. Savukārt tur, kur komunikācija skar nosacījumus negaidītas iedarbināšanas novēršanai, informācijas slāni nedrīkst uzskatīt par aizstājēju risinājumiem, kas paredzēti enerģijas atslēgšanai un droša stāvokļa nodrošināšanai. Tā ir robeža, pie kuras šī tēma jau saskaras ar aizsardzības pret negaidītu iedarbināšanu analīzi un plašāk – ar mašīnas sistēmas projektēšanu, kas pārsniedz tikai funkcionalitātes jautājumu. Citiem vārdiem, REST ir piemērots rūpniecībai tad, ja process apzināti pieņem tā ierobežojumus; ja tas tā nav, piemērotāki kļūst rindas un notikumu komunikācijas mehānismi, jo tie labāk atbilst nepārtrauktības, izsekojamības un atteiču seku kontroles prasībām.

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

Visbiežākā kļūda ieviešanas laikā ir tā, ka REST API vai notikumu komunikācijas izvēli uztver kā tīri tehnisku lēmumu, lai gan rūpniecībā tas ir lēmums ar operacionālām un organizatoriskām sekām. REST nepārstāj darboties tikai tāpēc, ka tas nonāk ražošanas vidē, taču ļoti ātri atklāj savus ierobežojumus tur, kur sistēmai jāspēj absorbēt sakaru pārtraukumus, nevienmērīgu slodzi, pakalpojumu īslaicīgu nepieejamību un nepieciešamību vēlāk atjaunot notikumu gaitu. Ja arhitektūra paredz, ka katrai atbildei jāienāk nekavējoties un ar pirmo mēģinājumu, projekts kļūst trausls. Sekas parasti ir paredzamas: pieaug integrācijas izmaksas, vairojas apiešanas mehānismi, un atbildība par procesa kļūdaino stāvokli izplūst starp sistēmu piegādātājiem. Savukārt rindas un brokeri problēmu neatrisina automātiski; tie ievieš savus riskus, piemēram, aizkavētu apstrādi, ziņojumu dublēšanos, nepieciešamību sakārtot secību un sarežģītāku uzraudzību. Tāpēc jautājums nav par to, vai REST vienmēr ir piemērots rūpniecībai, bet gan par to, vai konkrētais process pieļauj šīs komunikācijas formas īpašības, nepārnesot risku uz ražošanu, tehnisko uzturēšanu un atbilstību.

Projektēšanas posmā ir vērts pieņemt vienkāršu vērtēšanas kritēriju: kas tieši notiks ar procesu, ja ziņojums nenonāks, nonāks divreiz vai nonāks par vēlu. Ja sekas ir tikai novēlota datu atjaunošana atskaišu sistēmā, REST var būt pietiekams. Taču, ja atbildes trūkums bloķē secību, piespiež veikt manuālu iejaukšanos, izraisa operācijas izpildes vēstures zudumu vai apgrūtina noskaidrot, kurš un uz kāda pamata pieņēma lēmumu, tad sinhronā arhitektūra sāk radīt izmaksas jau palaišanas posmā. Šādā situācijā uz rindām vai brokeri balstīta komunikācija parasti labāk sakārto atbildību: sūtītājs apstiprina nodošanu, saņēmējs apstrādā savā tempā, bet komandai ir iespēja novērot uzkrājumus, atkārtotus mēģinājumus un kļūdas. Projekta vadītājam tas nozīmē nepieciešamību mērīt ne tikai pakalpojuma pieejamību, bet arī tādus rādītājus kā ziņojuma gaidīšanas laiks rindā, atkārtotu mēģinājumu īpatsvars, neapstrādāto ziņojumu skaits un laiks, kas vajadzīgs notikumu vēstures atjaunošanai pēc incidenta.

Praksē problēma īpaši skaidri parādās tur, kur viena integrācija vienlaikus sāk pildīt vairākas lomas. Piemēram: virsvadības sistēma nosūta uzdevumu darba vietai, saņem izpildes apstiprinājumu un vienlaikus reģistrē stāvokli, no kura atkarīga turpmāka līnijas iedarbināšana. Kamēr runa ir par biznesa datu apmaiņu, dažu sekunžu aizkave var būt pieņemama. Taču, ja tas pats komunikācijas ceļš sāk ietekmēt izpildes lēmumu procesā, tas vairs nav neitrāls IT papildinājums. Tad nepareiza mehānisma izvēle ietekmē ne tikai dīkstāves izmaksas, bet arī atbildību par to, vai sistēma paredzami reaģē uz savienojuma zudumu, pakalpojuma restartu vai ziņojuma dublikātu. Tas ir brīdis, kad tēma dabiski pāriet mašīnas sistēmas projektēšanas jomā, kas pārsniedz tikai funkcionalitāti: ir jāizlemj, kuras atteices sekas drīkst pieļaut un kuras jānodala no integrācijas slāņa.

Robeža kļūst vēl svarīgāka brīdī, kad komunikācija sāk skart nosacījumus, kas saistīti ar funkcionālo drošību vai riska novērtējumu. Ja droša stāvokļa nosacījuma izpilde, atļauja atsākt darbu, bīstamās enerģijas izzušanas apstiprinājums vai cita aizsargfunkcija ir atkarīga no pareizas datu apmaiņas, ar labu integrācijas praksi vien nepietiek. Tad skaidri jānosaka, vai attiecīgais elements paliek tikai informatīvajā slānī vai jau ietilpst tādu vadības sistēmu elementu projektēšanas tvērumā, kuri atbild par drošības funkcijām. Šajā brīdī parādās būtiskie jautājumi no LVS EN ISO 13849-1 jomas un praktiska riska novērtējuma saskaņā ar ISO 12100, taču tikai pēc funkcijas un bojājuma seku definēšanas. Komandai tas nozīmē pienākumu nodalīt to, ko var apstrādāt ar rindu, brokeri vai REST, no tā, ko nedrīkst balstīt tikai uz vispārēja lietojuma komunikāciju. Ja šī robeža netiek noteikta jau sākumā, izmaksas vēlāk atgriežas projekta izmaiņu, strīdu pieņemšanas laikā un grūti aizstāvamas atbildības par pieņemtajiem lēmumiem veidā.