Rūpnieciskas lietojumprogrammas projekts: kā sagatavot ievaddatus?

Ievaddatu sagatavošana rūpnieciskas lietotnes projektam mūsdienās vairs nav administratīvs posms, ko var “nokārtot pa ceļam”, bet gan lēmums, kas tieši ietekmē palaišanas termiņu, izmaiņu izmaksas un atbildības apjomu pēc ieviešanas. Ražošanas vidē lietotne reti darbojas izolēti: tai jāiekļaujas esošajā automatizācijā, kvalitātes procesos, ekspluatācijas uzturēšanā un nereti arī izsekojamības un atbilstības prasībās. Ja sākumā trūkst nepārprotama procesa apraksta, datu avotu, operacionālo izņēmumu un atbildības robežu starp iesaistītajām pusēm, komanda nevis projektē risinājumu, bet atjauno realitāti ar izmēģinājumu un kļūdu metodi. Tieši tad grafiks ieilgst nevis programmēšanas dēļ, bet sākotnējo pieņēmumu korekciju, papildu objekta apsekojumu, strīdu par apjomu un nepieciešamības dēļ pārstrādāt risinājumu pēc testiem objektā.

Lielākā kļūda parasti ir tā, ka par “ievaddatiem” uzskata tikai no lietotnes sagaidāmo funkciju sarakstu. Taču rūpnieciskā projektā tikpat svarīgi ir robežnosacījumi: kas un kurā brīdī ievada datus, kuri signāli nāk no vadības sistēmas, kas notiek sakaru zuduma gadījumā, kādas manuālās apiešanas ir pieļaujamas, kuri notikumi jāreģistrē un kuri operatora lēmumi ietekmē kvalitāti vai drošību. No biznesa viedokļa šī atšķirība ir izšķiroša, jo tieši šajos saskares punktos rodas visdārgākās izmaiņas. Ja lietotnei ir jāatbalsta ražošana, nevis tikai jāattēlo dati, tad neprecīzi definēti projekta ievaddati ļoti ātri pārvēršas par problēmu integratora, programmatūras izstrādātāja un ekspluatācijas uzturēšanas sadarbības organizēšanā. Katra no šīm pusēm redz citu procesa daļu, taču kļūdaina lēmuma sekas parasti uzņemas investors: dīkstāvju, papildu pieņemšanu un strīdu veidā par to, vai konkrētā funkcija bija “pašsaprotama” vai tomēr ārpus apjoma.

Praksē to labi var redzēt vienkāršā piemērā ar lietotni, kas uzrauga receptūras, ražošanas partijas vai kvalitātes notikumu reģistru. Ja komanda sāk darbu, iepriekš nenosakot, kuri dati ir primārie, kuri tikai atvasināti, kas drīkst tos labot un vai labojumam jāatstāj pēdas, problēma neatklājas maketa stadijā, bet tikai palaišanas laikā vai iekšējā audita gaitā. Pēkšņi izrādās, ka lietotne “darbojas”, bet uz tās pamata nav iespējams atjaunot partijas gaitu, izskaidrot novirzi vai pierādīt, kāpēc operators pieņēma konkrētu lēmumu. Tad ievaddatu sagatavošanas tēma dabiski pāriet produkta un procesa izsekojamības projektēšanā, bet dažkārt arī atbilstības budžeta plānošanā, jo jebkuras vēlīnas izmaiņas datu reģistrēšanas veidā prasa pārveidot loģiku, saskarnes un pieņemšanas testus.

Praktisks kritērijs situācijas novērtēšanai ir vienkāršs: pirms ieviešanas sākuma jāspēj katrai būtiskajai informācijai norādīt tās īpašnieku, avotu, rašanās brīdi, validācijas noteikumu un kļūdas sekas. Ja komanda to nespēj izdarīt bez minējumiem vai “pārbaudes objektā”, tad ievaddati nav gatavi un projekts trūkumus kompensēs visdārgākajā iespējamajā brīdī. Ir vērts mērīt ne tikai lietotnes nodošanas termiņu, bet arī apjoma izmaiņu skaitu pēc analīzes apstiprināšanas, jautājumu skaitu, kas bloķē ieviešanu, laiku, kas vajadzīgs starpdisciplinārai saskaņošanai, un labojumu skaitu, kas atklājas tikai testos ražošanā. Tie ir projekta sagatavošanas kvalitātes rādītāji, nevis tikai izpildītāja darba kvalitātes rādītāji.

Tikai šajā kontekstā kļūst skaidra atbilstības aspekta nozīme. Ja lietotne ietekmē mašīnas funkciju, tās lietošanas veidu, drošībai būtisku notikumu reģistru vai procesa parametru dokumentēšanu, tad ievaddatu definēšanas veids var ietekmēt arī atbilstības novērtējuma un tehniskās dokumentācijas apjomu. Tas ne vienmēr būs CE marķējuma jautājums, jo tas ir atkarīgs no pašas lietotnes lomas un sistēmas arhitektūras, taču šīs saiknes ignorēšana projekta sākumā gandrīz vienmēr palielina turpmāko saskaņojumu izmaksas. Tāpēc lēmums jāpieņem jau tagad: vai projekta ievaddatu sagatavošanu uzskatām par formalitāti pirms darbu pasūtīšanas, vai par inženiertehnisku posmu, kurā tiek sakārtota atbildība, samazināts izmaiņu risks un radīti priekšnoteikumi patiešām īsākai ieviešanai.

Kur visbiežāk pieaug izmaksas vai risks

Vislielākās izmaksas parasti nerodas pašā rūpnieciskās lietotnes programmēšanā, bet tur, kur ievaddati ir nepilnīgi, pretrunīgi vai apraksta tikai sagaidāmo biznesa rezultātu bez tehniskajiem nosacījumiem tā sasniegšanai. Ja sākumā nav zināms, kuri signāli ir patiesais avots, kādi ir procesa robežstāvokļi, kas apstiprina trauksmju noteikumus un kuri notikumi ir jāreģistrē, projekta komanda sāk pieņemt aizstājējlēmumus. Tieši tad pieaug apjoma izmaiņu skaits pēc analīzes apstiprināšanas, parādās jautājumi, kas bloķē ieviešanu, un ieilgst saskaņošana starp automatizāciju, ekspluatācijas uzturēšanu, kvalitāti un drošību. Projektam tas nozīmē ne tikai kavēšanos, bet arī atbildības pārbīdi: izpildītājs atbild par risinājumu, kura pieņēmumi bieži vien ir pieņemti netieši, nevis apzināti saskaņoti.

Otrs riska avots ir funkcionālo prasību jaukšana ar projektēšanas lēmumiem. Praksē tas izpaužas tā, ka pasūtītājs apraksta ekrānu, atskaiti vai vadības veidu, bet nedefinē darbības mērķi, robežnosacījumus un izņēmumus. Tad jebkuras vēlākas procesa izmaiņas izskatās kā “neliela korekcija”, lai gan patiesībā tās prasa loģikas pārbūvi, testēšanu un atkārtotu saskaņošanu. Labs novērtēšanas kritērijs ir vienkāršs: ja attiecībā uz konkrēto prasību nevar viennozīmīgi atbildēt, kurš pieņem lēmumu, uz kādu datu pamata, kādā laikā un ar kādu ietekmi uz procesu, tad tā vēl nav gatava ievaddatu bāze. Šeit tēma dabiski pāriet uz biežāk pieļautajām kļūdām rūpnieciskajos projektos, jo problēma neattiecas tikai uz dokumentāciju, bet arī uz pašu risinājuma definēšanas veidu.

Praktisks piemērs ir lietotne, kurai jāuzrauga līnijas pārregulēšana un jābloķē palaišana, ja receptūras parametri neatbilst. Ja projektēšanas ievade aprobežojas ar apgalvojumu, ka “sistēmai jāuzrauga pareizie iestatījumi”, risks ir gandrīz neizbēgams. Ir jānosaka, kuri parametri ir kritiski, no kurienes tie tiek iegūti, vai operators drīkst tos pārrakstīt, kā rīkoties sakaru zuduma gadījumā, kas tiek uzskatīts par atbilstības apstiprinājumu un vai bloķēšanai ir tikai procesa raksturs vai tā ietekmē mašīnas drošības funkciju. Bez šīm vienošanām noslēguma testi gandrīz vienmēr atklās strīdu par atbildību: ražošana sagaida elastību, kvalitātes puse pieprasa audita pēdu, bet uzturēšanas dienestam ir vajadzīga iespēja droši apiet bloķēšanu servisa režīmā. Tās nav izpildes detaļas, bet trūkstoši ievaddati, kas projekta beigās izmaksā visdārgāk.

Atsevišķa riska kategorija parādās tad, kad lietotne iejaucas mašīnas loģikā, darba secībā, trauksmju apstiprināšanas veidā vai drošībai un kvalitātei būtisku notikumu reģistrēšanā. Šādā gadījumā tēma vairs nav tikai IT jautājums. Ja projekts maina mašīnas lietošanas nosacījumus, reakcijas veidu uz kļūdu vai informācijas apjomu, kas nepieciešams atbilstības pierādīšanai, tas var nonākt projekta riska analīzes jomā un pēc tam arī mašīnas sagatavošanas atbilstības novērtēšanai un tehniskajai dokumentācijai. Ne visos gadījumos tas ietekmēs CE marķējumu, jo izšķiroša ir lietotnes faktiskā loma sistēmas arhitektūrā, taču kritērijs ir skaidrs: ja lietotnes kļūda var mainīt procesa uzvedību tādā veidā, kas ietekmē drošību, izstrādājumu vai dokumentēšanas pienākumus, šis jautājums ir jāizlemj pirms ieviešanas, nevis pēc pieņemšanas testiem.

No ieviešanas vadības skatpunkta visdārgākās nav atsevišķas tehniskas kļūdas, bet gan lēmumu trūkums brīdī, kad tiem bija jābūt pieņemtiem. Tāpēc ievaddatu kvalitāti ir vērts vērtēt nevis pēc apraksta apjoma, bet pēc spējas novērst strīdus vēl pirms programmēšanas darbu sākuma. Ja pēc sākotnējām darbnīcām joprojām nav viennozīmīgas atbildes, kuras prasības ir kritiskas, kuras ir tikai lietotāja vēlme, kas ir pakļauts validācijai un kāds izmaiņu apjoms iedarbina papildu riska analīzi vai atbilstības saskaņošanu, tad grafiks ir drošs tikai šķietami. Praksē tas nozīmē, ka izmaksas un atbildība ir vienkārši pārceltas uz posmu, kurā to korekcija būs vislēnākā un visdārgākā.

Kā šai tēmai pieiet praksē

Praksē ieviešanas laika saīsināšana nesākas ar ātrāku programmēšanu, bet gan ar to lēmumu skaita samazināšanu, kuri būs jāpieņem jau ieviešanas gaitā. Tāpēc rūpnieciskas lietotnes projekta ievaddatiem jābūt organizētiem nevis ap funkciju aprakstu, bet ap vietām, kur projekts var apstāties: atbildības robežām, darba apstākļiem, atkarībām no automatizācijas, ietekmi uz procesa drošību, validācijas prasībām un izmaiņu ieviešanas noteikumiem. Ja komanda saņem apjomīgu lietotāja gaidu aprakstu, bet nav izlemts, kurš apstiprina trauksmju loģiku, kuri signāli ir patiesības avots, kā izskatās avārijas darba režīms un ko drīkst mainīt bez atkārtotas seku izvērtēšanas, tad grafiks būs stabils tikai šķietami. Šādā situācijā izmaksas parādās vēlāk labojumu, strīdu pieņemšanas laikā un starp piegādātājiem izplūdušas atbildības veidā.

Tāpēc sākumā ir vērts pieņemt vienu vienkāršu ievadmateriāla kvalitātes novērtēšanas kritēriju: vai uz tā pamata var viennozīmīgi piesaistīt tehnisko lēmumu atbildīgajai personai, palaišanas nosacījumam un pārbaudes veidam. Šis kritērijs sakārto tēmu labāk nekā vispārīgs apgalvojums, ka “prasības ir aprakstītas”. Vadītājam tas nozīmē nepieciešamību pirms darbu pasūtīšanas noslēgt vairākus jautājumus: vai lietotne tikai vizualizē procesu vai arī vada tā uzvedību; vai tai ir ietekme uz izstrādājuma kvalitātes parametriem; vai tā tiks integrēta esošajā vadības sistēmā; vai uzturēšanas dienests pēc ieviešanas pārņems konfigurēšanu; un vai pēc palaišanas ir paredzētas izmaiņas. Ja atbildes uz šiem jautājumiem ir nosacītas vai izkaisītas pa saraksti, tad projektam vēl nav ievaddatu, bet tikai darba pieņēmumu kopums. Atšķirība ir būtiska, jo darba pieņēmumi parasti neiztur ražošanas ceha pārbaudi.

Labs piemērs ir lietotne, kurai jāapkopo dati no līnijas, jāattēlo iekārtu stāvoklis un jāļauj operatoram mainīt daļu iestatījumu. Pārdošanas posmā šādu apjomu nereti uztver kā “standarta operatora slāni”, taču ieviešanā izšķiroši svarīgi ir nošķirt, kuri iestatījumi ir tikai ekspluatācijas vajadzībām un kuri ietekmē procesa gaitu, izstrādājuma kvalitāti vai mašīnas darbību nestandarta stāvokļos. Ja tas netiek skaidri noteikts pirms ieviešanas, programmētājs sagatavos parametru rediģēšanas mehānismu, integrators to pieslēgs vadības ierīcei, un tikai pieņemšanas laikā radīsies jautājums, vai konkrētas vērtības maiņai ir vajadzīga bloķēšana, izmaiņu izsekojamība, papildu apstiprinājums vai atkārtota riska analīze. Tad problēma vairs nav tehniska. Tā kļūst par strīdu par atbildību: kurš atļāva funkciju izmantot, kuram bija jānovērtē tās ietekme uz drošību un kurš uzņemas sekas, ja pēc palaišanas izrādās, ka piešķirto tiesību apjoms bijis pārāk plašs.

Tāpēc praktiskai ievaddatu sagatavošanai būtu jānoslēdzas ar īsu, bet saistošu projekta lēmumu pieņemšanas loģikas aprakstu, nevis tikai ar ekrānu, atskaišu vai signālu sarakstu. Šādam aprakstam jānosaka, kurām funkcijām piemērojama funkcionālā pieņemšana, kurām nepieciešams gala lietotāja apstiprinājums un kuras prasa papildu saskaņošanu ar integratoru, ekspluatācijas uzturēšanas dienestu vai personu, kas atbild par atbilstību. Tas ir brīdis, kad tēma dabiski pāriet sadarbības organizēšanā starp programmatūras izstrādes uzņēmumu, integratoru un ekspluatācijas pusi, jo bez atbildības saskarņu noteikšanas pat korekti uzrakstīta lietotne var iestrēgt sistēmu saskares punktā. Savukārt, ja lietotne būtiski ietekmē mašīnas funkcijas no drošības viedokļa vai maina sistēmas paredzēto darbību, tas pats ievadmateriāls vairs nav tikai projekta dokuments, bet iegūst nozīmi arī turpmākajā atbilstības novērtēšanā un tehniskajā dokumentācijā.

Normatīvās atsauces ir vērts ieviest tikai tad, kad ir zināms, ka lietotne patiešām ietekmē drošības jomu, izstrādājuma atbilstību vai prasa formālu validāciju. Ne katra rūpnieciskā lietotne ietilps šajā tvērumā, taču to nedrīkst pieņemt bez pārbaudes. Kritērijs ir praktisks: ja funkcijas kļūda, nepareiza konfigurācija vai neatļauta parametra maiņa var mainīt mašīnas stāvokli, procesa norisi vai operatora lēmumu tādā veidā, kam ir nozīme drošībai, kvalitātei vai dokumentēšanas pienākumiem, tad projektam vajadzīga ne tikai prasību precizēšana, bet arī iepriekš veikta riska analīze un ietekmes uz atbilstību novērtējums. Tieši šeit visbiežāk izšķiras, vai ieviešana būs īsāka vai tikai ātrāk nonāks dārgu labojumu posmā.

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

Pat labi sagatavoti ievaddati nepaātrinās ieviešanu, ja komanda tos uztvers tikai kā funkciju aprakstu, nevis kā atbildības, izmaiņu un pieņemšanas robežnosacījumus. Rūpniecisko lietotņu projektos kavējumi reti rodas pašas programmēšanas dēļ; daudz biežāk tie ir saistīti ar to, ka palaišanas posmā izrādās — ievaddati nenosaka, kurš apstiprina procesa parametrus, kurš atbild par datu kvalitāti no iekārtām, kādā režīmā drīkst veikt izmaiņas un kas ir pieņemšanas pamats. Tad ieviešana sāk dzīvot pēc sava ritma: katra neskaidrība prasa papildu lēmumu, katrs lēmums rada strīda risku par apjomu, bet katrs labojums, kas veikts objektā, palielina izmaksas un atbildību abām pusēm. Ja mērķis ir saīsināt ieviešanas laiku, ievadmateriālam jābūt izmantojamam ne tikai projektētājam, bet arī integratoram, ekspluatācijas uzturēšanas dienestam, kvalitātes nodaļai un personām, kas atbild par atbilstību.

Īpaša piesardzība nepieciešama situācijā, kad lietotnei jādarbojas ar neviendabīgiem datiem no dažādām vadības ierīcēm, virsvadības sistēmām vai operatora manuāliem ievadiem. Tieši šeit visbiežāk parādās šķietamas pilnības slazds: signālu saraksts ir, ekrāni ir aprakstīti, bet nav viennozīmīgu noteikumu par prioritātēm, kļūmes stāvokļu nozīmi, datu derīguma laiku un sistēmas reakciju, ja atjauninājums netiek saņemts. Praksē tas noved pie kļūdām, kas formāli nav programmatūras atteice, bet gan nenoteikta darbības modeļa sekas. Projekta vadītājam tā ir būtiska atšķirība, jo tā ietekmē izmaiņu izmaksas un līgumisko atbildību. Labs novērtēšanas kritērijs ir vienkāršs: ja par galveno funkciju vienā teikumā nevar norādīt datu avotu, lēmuma īpašnieku, noraidīšanas nosacījumu un pareizas darbības apstiprināšanas veidu, tad ievaddati vēl nav pietiekami stipri, lai droši pārietu uz ieviešanu.

To labi var redzēt pēc lietotnes piemēra, kas aprēķina procesa iestatījumus un nodod tos izpildmehānismu sistēmai vai parāda operatoram kā pamatu lēmuma pieņemšanai. Ja sākumā nav noteikts, vai šīm vērtībām ir informatīvs, rekomendējošs vai vadības raksturs, ieviešanas komanda nezina, kādu testēšanas režīmu piemērot un kam ir tiesības apstiprināt novirzi no paredzētās darbības. Šāda neviennozīmība parasti atklājas tikai palaišanas laikā, kad tiek uzdots jautājums, vai ražošanu drīkst sākt, lai gan vēsturisko datu validācija nav pabeigta vai tiek izmantoti manuāli apiešanas risinājumi. Šādā brīdī termiņa saīsināšana ar “pagaidu” risinājumiem ir tikai šķietama: pieaug sūdzību, dīkstāves un galējos gadījumos arī atbildības par zaudējumiem, kas radušies nepareiza procesa lēmuma dēļ, risks. Tāpēc pirms ieviešanas ir vērts pieņemt izmērāmu kritēriju: vai katrai funkcijai, kas ietekmē procesa parametrus, ir viennozīmīgs pieņemšanas testa scenārijs kopā ar kļūdainu datu, datu trūkuma un darbības pēc sakaru atjaunošanas definīciju. Tas nav formālisms, bet gan nosacījums paredzamai palaišanai.

Tikai uz šī fona kļūst skaidrs, kurā brīdī jautājums vairs nav tikai ieviešanas organizācijas aspekts un sāk ietilpt riska analīzes un mašīnas sagatavošanas jomā turpmākai atbilstības novērtēšanai un tehniskajai dokumentācijai. Ja lietotne maina mašīnas darbības loģiku, ietekmē operatora lēmumus drošībai būtiskās situācijās vai kļūst par daļu no funkcijas, no kuras ir atkarīgs pieļaujamais procesa stāvoklis, nepietiek tikai ar “prasību precizēšanu”. Ir jāpārbauda, vai ievades materiāls ļauj pierādīt paredzēto darbību, lietošanas ierobežojumus un validācijas nosacījumus, jo pretējā gadījumā ieviešana var tehniski noslēgties, bet iestrēgt pie pieņemšanas, tehniskajā dokumentācijā vai vēlākā auditā. Praksē robeža ir skaidra: ja datu kļūda, nepareiza konfigurācija vai neautorizēta parametra maiņa var izraisīt sekas, kas ir būtiskas drošībai, izstrādājuma kvalitātei vai dokumentēšanas pienākumiem, projekts ir jāsasaista ar atsevišķu riska analīzi, nevis jānoslēdz tikai ar funkcionālajiem testiem. Tieši ieviešanas, riska analīzes un turpmāko prasību saistībā ar CE marķējumu saskares punktā visbiežāk rodas visdārgākās korekcijas, kas no grafika viedokļa izskatās pēc sīkuma, bet patiesībā atgriež projektu sākotnējo pieņēmumu stadijā.