Pramoninės programos projektas: kaip parengti įvesties duomenis?

Šiandien pramoninės taikomosios programos projekto įvesties duomenų parengimas nebėra administracinis etapas, kurį galima „užbaigti pakeliui“ – tai sprendimas, tiesiogiai lemiantis paleidimo trukmę, pakeitimų kainą ir atsakomybės apimtį po įdiegimo. Gamybinėje aplinkoje programa retai veikia izoliuotai: ji turi būti integruota į esamą pramonės automatiką, kokybės procesus, techninę priežiūrą, o dažnai ir į atsekamumo bei atitikties reikalavimus. Jei pradžioje trūksta aiškaus proceso aprašo, duomenų šaltinių, veiklos išimčių ir atsakomybės ribų tarp šalių, komanda neprojektuoja sprendimo, o bando atkurti realią situaciją bandymų ir klaidų būdu. Būtent tada grafikas ilgėja ne dėl programavimo, o dėl prielaidų koregavimo, papildomų vizitų vietoje, ginčų dėl apimties ir būtinybės perdaryti sprendimą po bandymų objekte.

Didžiausia klaida paprastai yra ta, kad „įvesties duomenimis“ laikomas vien tik iš programos laukiamų funkcijų sąrašas. Tuo tarpu pramoniniame projekte ne mažiau svarbios yra ribinės sąlygos: kas ir kuriuo momentu įveda duomenis, kurie signalai gaunami iš valdymo sistemos, kas vyksta nutrūkus ryšiui, kokie rankiniai apėjimai yra leistini, kokie įvykiai turi būti registruojami ir kurie operatoriaus sprendimai turi pasekmių kokybei ar saugai. Verslo požiūriu šis skirtumas yra esminis, nes būtent šiose sandūrose atsiranda brangiausi pakeitimai. Jei programa turi padėti gamybai, o ne tik rodyti duomenis, netiksliai apibrėžta projektinė įvestis labai greitai virsta integratoriaus, programinės įrangos rangovo ir techninės priežiūros bendradarbiavimo organizavimo problema. Kiekviena iš šių šalių mato skirtingą proceso dalį, tačiau neteisingo sprendimo pasekmes paprastai prisiima investuotojas: prastovų, papildomų priėmimų ir ginčų forma dėl to, ar konkreti funkcija buvo „savaime suprantama“, ar vis dėlto nepateko į apimtį.

Praktikoje tai gerai matyti iš paprasto receptūrų, gamybos partijų ar kokybės įvykių registro priežiūros programos pavyzdžio. Jei komanda pradeda darbus nesutarusi, kurie duomenys yra pirminiai, kurie tik išvestiniai, kas gali juos koreguoti ir ar korekcija turi palikti pėdsaką, problema išryškėja ne maketo etape, o tik paleidimo metu arba per vidinį auditą. Staiga paaiškėja, kad programa „veikia“, tačiau pagal ją neįmanoma atkurti partijos eigos, paaiškinti nuokrypio arba parodyti, kodėl operatorius priėmė konkretų sprendimą. Tada įvesties duomenų parengimo tema natūraliai pereina į produkto ir proceso atsekamumo projektavimą, o kartais ir į atitikties biudžeto planavimą, nes kiekvienas vėlyvas duomenų registravimo būdo pakeitimas reikalauja perkurti logiką, sąsajas ir priėmimo bandymus.

Praktinis situacijos vertinimo kriterijus yra paprastas: prieš pradedant įgyvendinimą turi būti įmanoma kiekvienai svarbiausiai informacijai nurodyti jos savininką, šaltinį, atsiradimo momentą, validavimo taisyklę ir klaidos pasekmę. Jei komanda to negali padaryti nesiremdama spėjimais ar „patikrinimu objekte“, vadinasi, įvesties duomenys dar nėra parengti, o projektas spragas taisys brangiausiu įmanomu momentu. Verta matuoti ne tik programos pateikimo terminą, bet ir apimties pakeitimų skaičių po analizės patvirtinimo, klausimų, blokuojančių įgyvendinimą, skaičių, laiką, reikalingą tarpsritiniams suderinimams, bei pataisų, paaiškėjusių tik per bandymus gamyboje, skaičių. Tai yra projekto parengimo kokybės rodikliai, o ne vien rangovo darbo kokybės matas.

Tik šiame kontekste išryškėja atitikties klausimo svarba. Jei programa daro įtaką mašinos funkcijai, jos valdymo būdui, saugai reikšmingų įvykių registrui arba proceso parametrų dokumentavimui, tai įvesties duomenų apibrėžimo būdas gali turėti įtakos ir atitikties vertinimo bei techninės dokumentacijos apimčiai. Tai ne visada bus CE ženklinimo sritis, nes tai priklauso nuo pačios programos vaidmens ir sistemos architektūros, tačiau šio ryšio ignoravimas projekto pradžioje beveik visada padidina vėlesnių suderinimų kainą. Todėl sprendimą reikia priimti dabar: ar projektinės įvesties parengimą laikome formalumu prieš užsakant darbus, ar inžineriniu etapu, kuriame sutvarkoma atsakomybė, sumažinama pakeitimų rizika ir sukuriamos sąlygos iš tiesų trumpesniam diegimui.

Kur dažniausiai didėja kaina arba rizika

Didžiausios sąnaudos paprastai atsiranda ne pačiame pramoninės programos programavime, o ten, kur įvesties duomenys yra nepilni, nenuoseklūs arba aprašo tik laukiamą verslo rezultatą, neapibrėždami techninių sąlygų jam pasiekti. Jei pradžioje nėra aišku, kurie signalai yra patikimiausias duomenų šaltinis, kokios yra ribinės proceso būsenos, kas tvirtina aliarmų taisykles ir kokie įvykiai turi būti registruojami, projekto komanda pradeda priiminėti pakaitinius sprendimus. Būtent tada daugėja apimties pakeitimų po analizės patvirtinimo, atsiranda klausimų, blokuojančių įgyvendinimą, ir ilgėja derinimas tarp automatikos, techninės priežiūros, kokybės ir saugos sričių. Projektui tai reiškia ne tik vėlavimą, bet ir atsakomybės pasislinkimą: rangovas atsako už sprendimą, kurio prielaidos dažnai buvo priimtos numanomai, o ne sąmoningai suderintos.

Antrasis rizikos šaltinis – funkcinių reikalavimų painiojimas su projektiniais sprendimais. Praktikoje tai pasireiškia tuo, kad užsakovas aprašo ekraną, ataskaitą ar valdymo būdą, tačiau neapibrėžia veiklos tikslo, ribinių sąlygų ir išimčių. Tuomet kiekvienas vėlesnis proceso pakeitimas atrodo kaip „nedidelė korekcija“, nors iš tikrųjų reikalauja perkurti logiką, atlikti bandymus ir iš naujo suderinti sprendimus. Geras vertinimo kriterijus yra paprastas: jei dėl konkretaus reikalavimo neįmanoma vienareikšmiškai atsakyti, kas priima sprendimą, kokių duomenų pagrindu, per kiek laiko ir su kokiu poveikiu procesui, tai dar nėra parengti pradiniai duomenys. Šioje vietoje tema natūraliai pereina į dažniausiai pasitaikančių klaidų pramonės projektuose sritį, nes problema susijusi ne vien su dokumentacija, bet ir su pačiu sprendimo apibrėžimo būdu.

Praktinis pavyzdys – taikomoji programa, kuri turi prižiūrėti linijos perreguliavimą ir blokuoti paleidimą, jei receptūros parametrai neatitinka reikalavimų. Jeigu projektiniai pradiniai duomenys apsiriboja teiginiu, kad „sistema turi prižiūrėti teisingus nustatymus“, rizika tampa beveik neišvengiama. Reikia nuspręsti, kurie parametrai yra kritiniai, iš kur jie paimami, ar operatorius gali juos perrašyti, kaip elgtis nutrūkus ryšiui, kas laikoma atitikties patvirtinimu ir ar blokavimas yra tik procesinio pobūdžio, ar daro įtaką mašinos saugos funkcijai. Be šių susitarimų galutiniai bandymai beveik visada atskleidžia ginčą dėl atsakomybės: gamyba tikisi lankstumo, kokybės užtikrinimas reikalauja audito pėdsako, o techninės priežiūros tarnybai reikia galimybės saugiai apeiti sistemą serviso režimu. Tai nėra įgyvendinimo detalės, o trūkstami pradiniai duomenys, kurie projekto pabaigoje kainuoja daugiausia.

Atskira rizikos kategorija atsiranda tada, kai taikomoji programa įsikiša į mašinos logiką, darbo seką, aliarmų patvirtinimo būdą arba saugai ir kokybei reikšmingų įvykių registravimą. Tokiu atveju tema nustoja būti vien tik IT klausimu. Jei projektas keičia mašinos naudojimo sąlygas, reagavimo į klaidą būdą arba informacijos, reikalingos atitikčiai pagrįsti, apimtį, jis gali patekti į rizikos analizės projekte sritį, o vėliau ir į mašinos parengimą atitikties vertinimui bei techninei dokumentacijai. Ne kiekvienu atveju tai turės reikšmės CE ženklinimui, nes lemiama yra tikroji taikomosios programos vieta sistemos architektūroje, tačiau kriterijus aiškus: jeigu taikomosios programos klaida gali pakeisti proceso elgseną taip, kad tai paveiktų saugą, gaminį ar dokumentavimo pareigas, šį klausimą būtina išspręsti prieš įgyvendinimą, o ne po priėmimo bandymų.

Žvelgiant iš diegimo valdymo perspektyvos, brangiausiai kainuoja ne pavienės techninės klaidos, o sprendimų nebuvimas tuo metu, kai jie turėjo būti priimti. Todėl pradinių duomenų kokybę verta vertinti ne pagal aprašo apimtį, o pagal gebėjimą uždaryti ginčytinus klausimus dar prieš programavimo darbus. Jeigu po pradinių dirbtuvių vis dar nėra vienareikšmio atsakymo, kurie reikalavimai yra kritiniai, kurie tėra naudotojo pageidavimas, kas turi būti validuojama ir kokios apimties pakeitimai inicijuoja papildomą rizikos analizę ar atitikties suderinimus, tuomet grafikas yra saugus tik iš pažiūros. Praktikoje tai reiškia, kad sąnaudos ir atsakomybė buvo tik nukeltos į etapą, kuriame jų koregavimas bus lėčiausias ir brangiausias.

Kaip prie to prieiti praktiškai

Praktikoje diegimo trukmės trumpinimas prasideda ne nuo greitesnio programavimo, o nuo mažesnio skaičiaus sprendimų, kuriuos tektų priimti jau įgyvendinimo metu. Todėl pradiniai duomenys pramoninės taikomosios programos projektui turėtų būti organizuojami ne pagal funkcijų aprašymą, o pagal vietas, kuriose projektas gali sustoti: atsakomybės ribas, darbo sąlygas, priklausomybes nuo pramonės automatikos, poveikį proceso saugai, validavimo reikalavimus ir pakeitimų įvedimo taisykles. Jeigu komanda gauna išsamų naudotojo lūkesčių aprašą, tačiau nėra nuspręsta, kas tvirtina aliarmų logiką, kurie signalai yra pirminis tiesos šaltinis, kaip turi veikti avarinis režimas ir ką leidžiama keisti be pakartotinio pasekmių įvertinimo, grafikas bus stabilus tik tariamai. Tokioje situacijoje sąnaudos vėliau pasireiškia pataisomis, ginčais per priėmimą ir tarp tiekėjų išskaidyta atsakomybe.

Todėl pradžioje verta taikyti vieną paprastą įvesties medžiagos kokybės vertinimo kriterijų: ar jos pagrindu galima vienareikšmiškai priskirti techninį sprendimą atsakingam asmeniui, paleidimo sąlygai ir patikros būdui. Šis kriterijus padeda suvaldyti temą geriau nei bendras teiginys, kad „reikalavimai yra aprašyti“. Vadovui tai reiškia būtinybę uždaryti kelis klausimus dar prieš užsakant darbus: ar taikomoji programa tik vizualizuoja procesą, ar ir valdo jo elgseną; ar ji turi įtakos gaminio kokybiniams parametrams; ar bus integruojama su esama valdymo sistema; ar techninės priežiūros tarnyba po diegimo perims konfigūravimą; ir ar po paleidimo numatomi pakeitimai. Jeigu atsakymai į šiuos klausimus yra sąlyginiai arba išsibarstę susirašinėjime, projektas dar neturi pradinių duomenų – tik darbinių prielaidų rinkinį. Skirtumas esminis, nes darbinės prielaidos paprastai neatlaiko gamybos salės realybės patikros.

Geras pavyzdys – programa, kuri turi rinkti duomenis iš linijos, rodyti įrenginių būseną ir leisti operatoriui keisti dalį nustatymų. Pardavimo etape tokia apimtis neretai laikoma „standartiniu operatoriaus sluoksniu“, tačiau diegimui esminė yra aiški skirtis tarp nustatymų, kurie skirti tik eksploatavimui, ir tų, kurie daro įtaką proceso eigai, gaminio kokybei ar mašinos veiksenai nestandartinėmis būsenomis. Jei tai neišsprendžiama iki įgyvendinimo pradžios, programuotojas parengs parametrų redagavimo mechanizmą, integratorius prijungs jį prie valdiklio, o tik priėmimo metu iškils klausimas, ar konkrečios reikšmės keitimui reikia blokavimo, pakeitimų istorijos, papildomo patvirtinimo ar pakartotinės rizikos analizės. Tuomet problema nustoja būti vien techninė. Ji tampa atsakomybės ginču: kas leido naudoti šią funkciją, kas turėjo įvertinti jos poveikį saugai ir kas prisiima pasekmes, jei po paleidimo paaiškėja, kad teisių apimtis buvo per plati.

Dėl šios priežasties praktinis pradinių duomenų parengimas turėtų baigtis trumpu, bet įpareigojančiu projekto sprendimų logikos aprašu, o ne vien ekranų, ataskaitų ar signalų sąrašu. Toks aprašas turi aiškiai nustatyti, kurioms funkcijoms taikomas funkcinis priėmimas, kurioms būtinas galutinio naudotojo patvirtinimas, o kurios reikalauja papildomų suderinimų su integratoriumi, techninės priežiūros padaliniu ar už atitiktį atsakingu asmeniu. Būtent šiame etape tema natūraliai pereina į bendradarbiavimo tarp programinės įrangos kūrėjo, integratoriaus ir eksploatacijos organizavimą, nes neapibrėžus atsakomybės sąsajų net ir teisingai parašyta pramoninė programa gali įstrigti sistemų sandūroje. Jei programa daro reikšmingą poveikį mašinos funkcijoms saugos požiūriu arba keičia numatytą sistemos elgseną, ta pati pradinė medžiaga nustoja būti vien projektiniu dokumentu ir tampa svarbi tolesniam atitikties vertinimui ir techninei dokumentacijai.

Norminius dokumentus verta įtraukti tik tada, kai aišku, kad programa iš tiesų veikia saugos sritį, gaminio atitiktį arba reikalauja formalios validacijos. Ne kiekviena pramoninė programa pateks į šią sritį, tačiau to negalima manyti nepatikrinus. Kriterijus yra praktinis: jeigu funkcijos klaida, neteisinga konfigūracija arba neautorizuotas parametro pakeitimas gali pakeisti mašinos būseną, procesą ar operatoriaus sprendimą taip, kad tai turėtų reikšmės saugai, kokybei ar dokumentavimo pareigoms, projektui reikia ne tik tiksliau apibrėžtų reikalavimų, bet ir iš anksto atliktos rizikos analizės bei poveikio atitikčiai įvertinimo. Būtent čia dažniausiai paaiškėja, ar diegimas bus trumpesnis, ar tik greičiau pereis į brangių korekcijų etapą.

Į ką atkreipti dėmesį diegiant

Net ir gerai parengti pradiniai duomenys nesutrumpins diegimo, jei komanda juos traktuos tik kaip funkcijų aprašą, o ne kaip atsakomybės, pakeitimų ir priėmimo ribines sąlygas. Pramoninių programų projektuose vėlavimai retai kyla vien dėl programavimo; dažniau paaiškėja, kad paleidimo etape pradiniai duomenys neatsako į klausimus, kas tvirtina proceso parametrus, kas atsako už duomenų iš įrenginių kokybę, kokiu režimu leidžiama atlikti pakeitimus ir kas laikoma priėmimo pagrindu. Tuomet diegimas pradeda gyventi savu ritmu: kiekvienas neaiškumas reikalauja papildomo sprendimo, kiekvienas sprendimas didina ginčo dėl apimties riziką, o kiekviena korekcija, atlikta objekte, didina sąnaudas ir atsakomybę abiem pusėms. Jei tikslas yra sutrumpinti diegimo laiką, pradinė medžiaga turi būti tinkama naudoti ne tik projektuotojui, bet ir integratoriui, techninės priežiūros padaliniui, kokybės skyriui bei už atitiktį atsakingiems asmenims.

Ypatingo atsargumo reikia tada, kai programa turi veikti su nevienalyčiais duomenimis iš skirtingų valdiklių, aukštesnio lygio sistemų ar operatoriaus ranka įvedamų įrašų. Būtent čia dažniausiai pasitaiko tariamo išsamumo spąstai: signalų sąrašas yra, ekranai aprašyti, tačiau nėra vienareikšmių taisyklių dėl prioritetų, klaidų būsenų reikšmės, duomenų galiojimo trukmės ar sistemos reakcijos, kai duomenys neatnaujinami. Praktikoje tai lemia klaidas, kurios formaliai nėra programinės įrangos gedimas, o neapibrėžto veikimo modelio pasekmė. Projekto vadovui tai svarbus skirtumas, nes nuo jo priklauso pakeitimų kaina ir sutartinė atsakomybė. Geras vertinimo kriterijus yra paprastas: jeigu apie pagrindinę funkciją vienu sakiniu neįmanoma nurodyti duomenų šaltinio, sprendimo savininko, atmetimo sąlygos ir teisingo veikimo patvirtinimo būdo, vadinasi, pradiniai duomenys dar per silpni, kad būtų galima saugiai pereiti prie diegimo.

Tai aiškiai matyti iš programos, kuri apskaičiuoja proceso nustatymus ir perduoda juos vykdymo sistemai arba pateikia operatoriui kaip sprendimo pagrindą, pavyzdžio. Jeigu įvesties etape nenustatyta, ar reikšmės yra informacinės, rekomendacinės ar valdančiosios, diegimo komanda nežino, kokį bandymų režimą taikyti ir kas turi teisę patvirtinti nukrypimą nuo numatyto veikimo. Toks neapibrėžtumas paprastai išryškėja tik paleidimo metu, kai kyla klausimas, ar galima pradėti gamybą nepabaigus istorinių duomenų validavimo arba taikant rankinius apėjimus. Tuomet termino trumpinimas „laikinais“ sprendimais tėra tariamas: didėja pretenzijų, prastovų, o kraštutiniu atveju ir atsakomybės už žalą, atsiradusią dėl klaidingo proceso sprendimo, rizika. Todėl prieš diegimą verta nustatyti išmatuojamą kriterijų: ar kiekvienai funkcijai, darančiai įtaką proceso parametrams, yra aiškiai apibrėžtas priėmimo bandymo scenarijus kartu su klaidingų duomenų, duomenų nebuvimo ir veikimo atkūrus ryšį apibrėžimu. Tai ne formalumas, o nuspėjamo paleidimo sąlyga.

Tik šiame kontekste matyti, kada tema nustoja būti vien diegimo organizavimo klausimu ir pereina į rizikos analizės bei mašinos parengimo tolesniam atitikties vertinimui sritį. Jeigu programa keičia mašinos veikimo logiką, daro įtaką operatoriaus sprendimams saugai reikšmingose situacijose arba tampa funkcijos dalimi, nuo kurios priklauso leistina proceso būsena, vien „patikslinti reikalavimus“ nepakanka. Reikia patikrinti, ar pradinė medžiaga leidžia pagrįsti numatytą veikimą, naudojimo apribojimus ir validavimo sąlygas, nes priešingu atveju diegimas gali būti techniškai užbaigtas, bet įstrigti per priėmimą, techninėje dokumentacijoje arba vėlesnio audito metu. Praktikoje riba yra aiški: jeigu duomenų klaida, neteisinga konfigūracija arba neautorizuotas parametro pakeitimas gali sukelti pasekmių, reikšmingų saugai, gaminio kokybei ar dokumentavimo pareigoms, projektas turėtų būti susietas su atskira rizikos analize, o ne užbaigiamas vien funkciniais bandymais. Būtent diegimo, rizikos analizės ir būsimų reikalavimų, susijusių su CE ženklinimu, sandūroje dažniausiai atsiranda brangiausi pataisymai, kurie iš grafiko perspektyvos atrodo kaip smulkmena, tačiau iš tikrųjų grąžina projektą į pradinių prielaidų etapą.