MQTT, OPC UA vai suora viestintä PLC:n kanssa – miten valita tiedonsiirtomalli teollisuusprojektiin?

Valinta MQTT:n, OPC UA:n ja suoran PLC-kommunikoinnin välillä ei ole enää pelkästään tekninen päätös. Nykyisin se vaikuttaa samanaikaisesti järjestelmäarkkitehtuuriin, käyttöönoton kustannuksiin, toimittajien vastuunjakoon ja vastaanottovaiheen etenemisnopeuteen. Käytännössä kyse ei ole siitä, mikä protokolla on ”parempi”, vaan siitä, mikä tiedonvaihtomalli vastaa hankkeen todellista tehtävää: tarvitaanko yksinkertainen signaalien integrointi yhdestä koneesta, linjan valvonta, tiedonvaihto ylemmän tason järjestelmien kanssa vai hajautettu ohjaus, jota kehitetään edelleen tulevina vuosina. Tässä vaiheessa tehty virhe ei yleensä näy heti laboratoriossa, vaan vasta myöhemmin: käyttöönotossa, validoinnissa, PLC-toimittajan vaihtuessa tai silloin, kun kunnossapito yrittää selvittää häiriön syytä ja käy ilmi, että tiedot ovat epäjohdonmukaisia, viivästyneitä tai vailla asiayhteyttä.

Projektin näkökulmasta vaarallisinta on omaksua viestintämalli ”tottumuksesta”. Suora kommunikointi PLC:n kanssa houkuttelee usein, koska se antaa nopean pääsyn rekistereihin ja lyhentää monesti käyttöönoton ensimmäistä vaihetta. Tällainen valinta kuitenkin sitoo ylemmän tason sovelluksen helposti tiettyyn ohjaimeen, muistiosoitteistoon ja valmistajan toteutustapaan. Ohjelmaversion vaihtuessa, laitteiston migraatiossa tai linjan laajennuksessa kustannus palaa takaisin muutostöinä, regressiotestauksena ja kiistoina siitä, kuka vastaa prosessidatasta. MQTT puolestaan toimii hyvin siellä, missä korostuvat kevyt tiedonjakelu ja lähettäjien erottaminen vastaanottajista, mutta se edellyttää tietoista määrittelyä datan semantiikalle, toimituslaadulle ja välityspalvelimen ylläpitoperiaatteille. OPC UA valitaan usein kompromissiksi yhteentoimivuuden ja tiedon rakenteisuuden välillä, mutta sekään ei ratkaise ongelmia itsestään: jos tietomalli on huono, muodollisesti oikea kommunikointi johtaa silti vääriin operatiivisiin päätöksiin.

Käytännöllinen päätöskriteeri on yksinkertainen, vaikka se usein sivuutetaan: ensin on määritettävä, koskeeko kyseinen tiedonvaihto informaatiota, ohjausta vai toimintoa, jolla on vaikutusta koneen käyttöturvallisuuteen. Jos kanavaa käytetään ainoastaan valvontaan, raportointiin tai reseptien siirtämiseen hallitussa tilassa, ratkaisuja voidaan vertailla ylläpidettävyyden, skaalautuvuuden ja integraation kannalta. Jos kuitenkin samaa reittiä pitkin kulkevat komennot, jotka vaikuttavat liikkeeseen, työsekvenssiin, lukituksiin tai laitteen valmiustilaan, aihe ei ole enää pelkästään tietotekninen. Tällöin on arvioitava viiveen ja tiedonsiirron luotettavuuden lisäksi myös käyttäytymisen ennakoitavuus yhteyden katketessa, järjestelmän uudelleenkäynnistyksen jälkeen, ohjelmistoversion vaihtuessa ja silloin, kun ulkoinen järjestelmä tulkitsee tilan väärin. Tässä vaiheessa kysymys siirtyy luontevasti suunnittelupäätösten käytännön riskianalyysiin ja joskus myös suojautumiseen odottamattomalta käynnistymiseltä.

Tyypillinen esimerkki tuotantolaitoksista etenee usein samalla tavalla: aluksi tavoitteena on vain lukea koneelta tietoja visualisointiin tai raportointijärjestelmään, joten tiimi päättää toteuttaa nopean yhteyden suoraan PLC:hen. Muutaman kuukauden kuluttua sama kanava alkaa palvella asetusarvojen kirjoitusta, hälytysten kuittauksia ja myöhemmin myös etähuollon komentoja. Muodollisesti järjestelmä edelleen ”toimii”, mutta arkkitehtuuri ei enää vastaa todellista vastuunjakoa. Ei ole enää selvää, mikä kerros on koneen tilatiedon ensisijainen lähde, kuka vastaa muutosten valtuutuksesta ja miten voidaan osoittaa, ettei ulkoinen kommunikointi muodosta reittiä tahattomaan käynnistymiseen. Tässä kohtaa esiin nousevat kysymykset paitsi protokollasta myös toimintojen jaosta ohjaus-, valvonta- ja turvallisuuskerroksen välillä sekä suorassa PLC-kommunikoinnissa myös seurauksista koneen sähköiselle tasolle ja kytkennöille.

Tämän valinnan normatiivinen ja vaatimustenmukaisuuteen liittyvä merkitys tulee esiin silloin, kun tiedonvaihtomalli vaikuttaa koneen käyttäytymiseen normaali- ja häiriötilanteissa. Kaikki integraatiot eivät heti kuulu turvallisuustoimintoja koskevien vaatimusten piiriin, mutta jokainen on arvioitava virheen seurausten kannalta, samoin kuin yhteyden menetyksen ja virheellisen toimintasekvenssin osalta. Jos ulkoisen rajapinnan kautta voidaan muuttaa koneen tilaa, vapauttaa lukitus, käynnistää jakso uudelleen tai ohittaa paikallisesti suunniteltu logiikka, viestintäratkaisu on sidottava riskianalyysiin ja soveltuvissa tapauksissa myös odottamattoman käynnistymisen estämistä koskeviin vaatimuksiin. Siksi tästä on päätettävä jo lähtöoletusten ja arkkitehtuurin vaiheessa, ei vasta käyttöönotossa. Juuri silloin voidaan vielä määrittää mitattavat kriteerit: kuka omistaa tietomallin, mikä on yhteyden menetyksen hyväksyttävä seuraus, kuinka monta integraatiopistettä on ylläpidettävä PLC:n vaihdon jälkeen ja miten osoitetaan, ettei kommunikointi siirrä vastuuta järjestelmän suunnitellun laajuuden ulkopuolelle.

Missä kustannukset tai riskit kasvavat useimmiten

Suurin osa ongelmista ei johdu itse valinnasta MQTT:n, OPC UA:n ja suoran PLC-yhteyden välillä, vaan siitä, että viestinnän rooli koneen tai laitoksen arkkitehtuurissa määritellään väärin. Projekti alkaa kallistua siinä vaiheessa, kun alun perin aputiedon vaihtoon tarkoitettu kanava alkaa välittää operatiivisia päätöksiä, joista riippuvat prosessin jatkuvuus, laitteen tila tai operaattorin toiminta. Käytännössä tämä tarkoittaa, että tiimi ottaa käyttöön näennäisesti halvemman ja nopeamman ratkaisun, ja joutuu myöhemmin lisäämään kiertoteitä: ylimääräisiä laitesignaaleja, paikallisia lukituksia, poikkeuksia ohjainlogiikkaan sekä erillisiä kuittaus- ja tilanpalautusmekanismeja yhteyden katkeamisen varalle. Juuri nämä myöhäisessä vaiheessa tehdyt korjaukset synnyttävät kustannuksia, viivästyksiä ja kiistoja vastuista integraattorin, ohjelmistotoimittajan ja loppukäyttäjän välillä. Käytännöllinen arviointikriteeri on yksinkertainen: on määritettävä, pitääkö järjestelmän yhteyden katketessa vain ”lakata raportoimasta”, vai voiko se siirtyä vaaralliseen, teknologisesti virheelliseen tai tuotannon kannalta kalliiseen tilaan.

Suoraan PLC:hen perustuvissa malleissa riski kasvaa yleensä silloin, kun rajapinta alkaa riippua tietystä valmistajasta, ohjelmistoversiosta ja ohjaimen muistirakenteesta. Käyttöönoton vaiheessa tämä toimii usein hyvin, mutta kustannukset tulevat esiin ohjainta vaihdettaessa, linjaa modernisoitaessa tai liitettäessä mukaan uusi ylemmän tason järjestelmä. Jokainen tällainen muutos edellyttää tietojen uudelleenmäärittelyä, tyyppien, osoitteiden, käyttöoikeuksien ja siirtovirheen jälkeisen toiminnan varmistamista. Tuotteen omistajan näkökulmasta tämä on olennaista, koska ylläpidosta tulee ennakoimatonta: dokumentaatio vanhenee nopeasti, osaaminen jää toimittajalle ja vastuu tietojen oikeellisuudesta hajautuu. Jos tiimi ei pysty nimeämään tietomallin omistajaa eikä menettelyä sen muuttamiseksi PLC-päivityksen jälkeen, tulevien integraatioiden kustannus on jo sisäänrakennettu projektiin, vaikka sitä ei vielä tänään näkyisi.

MQTT:n ja OPC UA:n kohdalla yleisin virhe on toisenlainen: oletetaan, että viestintäkerros ratkaisee itsestään tietojen semantiikan ja päätösten luotettavuuden. MQTT siirtää hyvin tapahtumia ja telemetriatietoa, mutta ilman huolellisesti määriteltyjä aiheita, toimituslaatua, säilytystä ja lähteen tunnistamista on helppo päätyä tilanteeseen, jossa vastaanottaja saa muodollisesti oikeaa mutta käytännössä hyödytöntä tai prosessin kannalta myöhässä olevaa tietoa. OPC UA puolestaan jäsentää tietomallia ja helpottaa yhteentoimivuutta, mutta sen käyttöönoton laajuus aliarvioidaan usein, jos laitteille ei ole valmisteltu yhtenäistä objektien, tilojen ja menetelmien rakennetta. Käytännön esimerkki tulee esiin resepteissä, erien kuittauksessa tai syklin etäjatkamisessa: jos ei ole yksiselitteisesti määritelty, mikä osapuoli kuittaa komennon vastaanoton, mikä toteutuksen ja mikä vain kirjauksen rekisteriin, ensimmäisen häiriön jälkeen on vaikea osoittaa, syntyikö virhe sovelluskerroksessa, viestintäkerroksessa vai koneen logiikassa. Hyvä päätöksenteon kriteeri ei tässä ole protokollan ”nykyaikaisuus”, vaan se, voidaanko tila, komennon lähde, voimassaolon ehdot ja toiminnan palautustapa häiriön jälkeen kuvata yksiselitteisesti.

Erillinen kustannusten lähde on käyttövaatimusten sekoittaminen turvallisuus- ja vaatimustenmukaisuusvaatimuksiin. Jos MQTT:n, OPC UA:n tai suoran PLC-pääsyn kautta voidaan vaikuttaa koneen liikkeeseen, lukitusten vapauttamiseen, käynnistyssekvenssiin tai suojausmerkityksellisiin parametreihin, kyse ei ole enää pelkästään tietotekniikasta. Tässä kohtaa aihe siirtyy luontevasti suunnittelupäätösten käytännön riskianalyysiin: arvioitavana ei ole itse protokolla, vaan virheellisen komennon, tiedon vanhentumisen, asetusten luvattoman muuttamisen ja paikallisen sekä ulkoisen tilan epäjohdonmukaisuuden seuraukset. Toimilaitteisiin perustuvissa järjestelmissä, myös hydraulisissa, viestintäratkaisu voi vaikuttaa siihen, miten pysäytys-, kuormanpoisto-, liikkeenestotoiminnot ja turvallinen työn jatkaminen toteutetaan, joten se voi liittyä vaatimustenmukaisuuden arvioinnissa sovellettaviin suunnitteluvaatimuksiin. Jos ulkoinen rajapinta alkaa vaikuttaa suojaustoimintoihin tai käyttäytymiseen, jonka operaattori kokee osaksi suojausta, sitä on käsiteltävä turvallisuusarkkitehtuurin osana eikä vain kätevänä integraatiolisänä.

Projektinhallinnan näkökulmasta turvallisin päätös on sellainen, joka voidaan perustella paitsi teknisesti myös organisatorisesti. Siksi ennen tiedonvaihtomallin valintaa kannattaa määrittää muutama mitattava kriteeri: aika, joka tarvitaan oikean toiminnan palauttamiseen yhteyden katkeamisen jälkeen, niiden kohtien määrä, joissa tietomääritystä on ylläpidettävä, tietomallin versiointitapa, regressiotestauksen laajuus PLC-muutoksen jälkeen sekä näyttö siitä, ettei ulkoinen viestintä ohita paikallisia suojausmekanismeja. Kun vastaukset näihin kysymyksiin ovat epäselviä, projekti on yleensä jo alueella, jossa itse viestintäratkaisun pitäisi kuulua muodollisemman riskinarvioinnin piiriin ja joissakin sovelluksissa myös olla yhteensovitettu toimilaitteita ja lukituskeinoja koskevien suunnitteluvaatimusten kanssa. Tämä on se hetki, jolloin valinta MQTT:n, OPC UA:n ja suoran viestinnän välillä lakkaa olemasta tekninen mieltymyskysymys ja muuttuu päätökseksi ylläpitokustannuksista, vastuun rajoista ja koko ratkaisun virheensietokyvystä.

Miten aihetta kannattaa lähestyä käytännössä

Käytännössä valinta MQTT:n, OPC UA:n ja suoran PLC-kommunikoinnin välillä kannattaa aloittaa ei teknologiasta vaan kysymyksestä, mitä operatiivista vaikutusta tiedonvaihdolla halutaan saada aikaan ja kuka vastaa sen lopputuloksesta. Jos dataa käytetään vain valvontaan, raportointiin tai ylempien järjestelmien syötteeksi, etusijalla ovat integraation muutoskestävyys ja selkeä tietomalli. Jos taas toisessa päässä on komentoja, jotka vaikuttavat syklin kulkuun, resepteihin, käyttötiloihin tai käynnistyksen ehtoihin, päätös ei ole enää pelkästään IT-kysymys. Tällöin viestintätapa vaikuttaa jo vastuunjakoon integraattorin, koneen valmistajan, kunnossapidon ja prosessin omistajan välillä. Tällä on suoria seurauksia projektiin: vastaanottotestien laajuus on erilainen, muutosten dokumentointi on erilainen, ohjainohjelman muutosten jälkeisen regressiotestauksen mittakaava on erilainen ja käyttöönoton jälkeiset ylläpitokustannukset ovat erilaiset.

Hyvä päätöksentekokriteeri on se, missä koneen tilaa ja toiminnan sallivaa logiikkaa koskevan ”totuuden lähteen” tulee sijaita. Suora kommunikointi PLC:n kanssa voi olla perusteltua silloin, kun tärkeintä on toteutuspolun yksinkertaisuus, välikäsien vähäinen määrä ja ohjaimen toiminnan täysi ennakoitavuus. Hintana on yleensä ratkaisun vahva sitoutuminen tiettyyn PLC-ohjelmaan, dataosoitteeseen ja yhden toimittajan käytäntöihin. OPC UA on järkevä valinta, kun projekti vaatii vakaamman tietomallin, sovelluskerroksen parempaa erottamista ohjainohjelmasta ja signaalien semantiikan parempaa selkeyttä. MQTT toimii ennen kaikkea silloin, kun dataa pitää jakaa useille vastaanottajille yksittäisen järjestelmä–ohjain-suhteen ulkopuolella ja kun välillinen viestintämalli on hyväksyttävä. Tämä ei kuitenkaan ole neutraali valinta: mitä enemmän on välikerroksia, välittäjiä, muuntimia ja mappauksia, sitä suurempi on virhepinta-ala ja sitä vaikeampi on osoittaa, ettei integraatiopuolen muutos riko paikalliselle ohjaukselle asetettuja lähtöoletuksia.

Tyypillinen suunnitteluvirhe on se, että tiimi valitsee käyttöönoton vaiheessa integraation kannalta kätevän mallin ja huomaa vasta myöhemmin ylläpidon kustannukset. Käytännön esimerkki: ylemmän tason järjestelmän on tallennettava reseptejä ja vaihdettava useiden asemien käyttötiloja. Jos tämä tehdään kirjoittamalla suoraan PLC:n muistialueille, ratkaisu on aluksi nopea, mutta jokainen ohjaimen tietorakenteen muutos käynnistää testit rajapinnan molemmilla puolilla, ja vastuu reseptien eheydestä alkaa hämärtyä. Jos sama tapaus perustuu OPC UA -puolella yksiselitteisesti määriteltyihin objekteihin ja tiloihin, koneohjelman muutos on helpompi erottaa ylemmän tason järjestelmän muutoksesta, mutta tietomalli ja sen versiointi on pidettävä hallinnassa. MQTT:n käyttö tällaisessa skenaariossa on puolestaan järkevää vasta silloin, kun dataa todella täytyy jakaa useille järjestelmille ja kun viiveiden hallinta, toimituksen kuittaus sekä tilan palautus yhteyden katkeamisen jälkeen on kuvattu ja varmistettu testeissä. Muussa tapauksessa tiimi hankkii itselleen joustavuutta, jota se ei hyödynnä, ja jää lisäksi ylimääräisten vikapisteiden kanssa.

Tässä kohtaa aihe siirtyy luontevasti suunnittelupäätösten käytännön riskianalyysiin. Jos viestintäkanava voi muuttaa koneen tilaa, vapauttaa sekvenssin, käynnistää toiminnan uudelleen yhteyden katkeamisen jälkeen tai vaikuttaa epäsuorasti toimilaitteisiin, on arvioitava paitsi tiedonsiirron luotettavuus, myös virheellisen tai myöhästyneen komennon seuraukset. Osassa sovelluksia tämä liittyy jo odottamattoman käynnistymisen estämistä koskeviin vaatimuksiin, koska teknisesti oikein toteutettu integraatiokaan ei saa luoda ohitusreittiä paikallisille estotoimenpiteille tai energian katkaisumenettelyille. Tällaisessa laajuudessa viestintäratkaisun valinta on sovitettava yhteen ohjausarkkitehtuurin, sähköisen kerroksen ja ohjelmistomuutosten hallintaperiaatteiden kanssa, eikä sitä pidä tehdä erillisenä integraatiopäätöksenä. Johtamisen näkökulmasta tämä tarkoittaa yksinkertaista sääntöä: tiedonvaihtomalli on oikea vain silloin, kun voidaan osoittaa, kuka hyväksyy muutoksen, miten turvallinen tila palautetaan vian jälkeen ja mitä KPI-mittareita käyttöönoton jälkeen seurataan, esimerkiksi toiminnan palautusaikaa, muutosten jälkeisten häiriöiden määrää sekä niiden kohtien lukumäärää, joissa datamappausta ylläpidetään.

Mihin käyttöönotossa kannattaa kiinnittää huomiota

Käyttöönotossa suurinta riskiä ei aiheuta itse valinta MQTT:n, OPC UA:n ja suoran PLC-kommunikoinnin välillä, vaan piilevät oletukset, jotka tiimi hyväksyy ilman muodollista vahvistusta. Projektikäytännössä kalleimpia ovat tilanteet, joissa tiedonvaihtomalli valitaan toiminnallisuuden demonstrointia varten eikä todellista käyttöä, ylläpitoa ja muutoksiin liittyvää vastuunjakoa varten. MQTT otetaan joskus käyttöön oletuksella, että sillä siirretään yksinkertaisesti dataa ylemmän tason järjestelmiin, mutta muutaman kuukauden kuluttua sen kautta aletaan välittää operatiivisia komentoja. OPC UA valitaan ”yleisratkaisuna”, mutta ilman että sovitaan, mitä palveluja, tietomalleja ja käyttöoikeusmekanismeja todella käytetään. Suora kommunikointi PLC:n kanssa näyttää lyhyimmältä reitiltä siihen asti, kunnes käy ilmi, että jokainen uusi datan vastaanottaja vaatii erillisen mappauksen, regressiotestit ja yhteensovittamisen ohjaintoimittajan kanssa. Johtajalle tästä seuraa yksinkertainen johtopäätös: käyttöönoton kustannus ei pääty yhteyden avaamiseen, vaan ulottuu koko muutosten, vikojen ja teknisten vastaanottojen elinkaareen.

Tärkein päätöksenteon kysymys ei siis saisi olla ”mitä pystymme ottamaan käyttöön nopeimmin”, vaan ”missä päättyy vastuu datan merkityksestä ja sen käytön seurauksista”. Jos tiedonsiirto palvelee ainoastaan prosessin seurantaa, arviointikriteerit ovat toiset kuin silloin, kun sama yhteys vaikuttaa resepteihin, käyttöparametreihin, lukituksiin tai ohjaussekvensseihin. Tässä kohtaa aihe siirtyy luontevasti suunnittelupäätösten käytännön riskianalyysiin: on arvioitava paitsi yhteyden katkeamisen todennäköisyys myös se, voiko virheellinen arvo, viivästynyt päivitys tai muuttujan epäselvä mäppäys aiheuttaa koneen tai linjan virheellisen toiminnan. Jos vastaus on kyllä, viestintäarkkitehtuuri ei ole enää pelkkä integraatiokysymys. Siitä tulee ohjaustoimintoon, järjestelmän vastaanottoon ja alijärjestelmien yhdistämisestä vastaavan integraattorin vastuuseen vaikuttava tekijä. Tällöin on perusteltua tarkastella myös koneen ja linjan käyttöturvallisuuteen kohdistuvia vaikutuksia.

Käytännössä tämä näkyy hyvin yksinkertaisessa tilanteessa: ylemmän tason järjestelmän on luettava tilat useista ohjaimista, ja projektin käyttöönoton jälkeen käyttäjä pyytää lisäksi etämuutosta asetusarvoihin. Suorassa PLC-yhteydessä tämä johtaa usein uusien rekisterien, poikkeusten ja tietystä valmistajasta riippuvien kiertoteiden lisäämiseen. MQTT:ssä ongelmana on usein yksiselitteisyyden katoaminen: viesti saapuu perille, mutta ilman tarkasti määriteltyä kontekstia vastaanottaja ei tiedä, onko arvo ajantasainen, vahvistettu ja mistä käyttötilasta se on peräisin. OPC UA:ssa ansa ei ole itse protokolla, vaan liian optimistinen oletus siitä, että laitteen tietomalli vastaa sitä, mitä ylemmän tason sovellus edellyttää. Siksi käytännöllisen arviointikriteerin tulisi kattaa kolme asiaa: kuka omistaa datan semantiikan, miten arvojen kelpoisuus ja ajantasaisuus vahvistetaan sekä millainen muutosmenettely on käyttöönoton jälkeen. Jos tiimi vastaa yhteenkään näistä kysymyksistä yleisellä tasolla tai toimittajasta riippuvaisesti, se tarkoittaa, että tulevien muutosten kustannus on juuri siirretty ylläpitovaiheeseen.

Erillinen ansa on fyysisten ja asennukseen liittyvien vaikutusten aliarviointi. Hankkeissa, joissa tiedonvaihtomallin valinta vaikuttaa välilaitteiden sijoitukseen, lisäsyöttöihin, kaapelireititykseen tai verkkojen erotteluun, aihe alkaa koskea koneen sähköisen kerroksen ja liitäntöjen suunnittelua. Tämä koskee erityisesti ratkaisuja, joissa on lisätty viestintäyhdyskäytäviä, teollisuustietokoneita tai kytkimiä; dokumentaatiossa ne näyttävät harmittomilta, mutta ohjauskaapissa ne merkitsevät tilantarvetta, jäähdytystä, suojauksia, huoltoa ja uusia vikapisteitä. Tällöin viestintää koskevaa päätöstä ei voi irrottaa toteutussuunnitelmasta. Tiimin pitäisi pystyä osoittamaan, mitä tapahtuu välilaitteen sähkökatkon jälkeen, miten viestinnän tila palautetaan ja synnyttääkö siirtokerroksen vika operaattorille tai ylemmän tason järjestelmälle epäselvän kuvan koneen tilasta. Tällaiset ratkaisut olisi hyvä huomioida jo koneiden suunnittelun ja rakentamisen vaiheessa.

Viittaus vaatimustenmukaisuusvaatimuksiin tulee ajankohtaiseksi vasta silloin, kun tiedonvaihtokanava vaikuttaa ohjaustoimintoon, koneen käyttötapaan tai toimittajien välisiin vastuurajoihin. Tällaisessa laajuudessa ei riitä, että todetaan protokollan olevan ”teollinen” tai yleisesti käytetty. On osoitettava, että valittu arkkitehtuuri on arvioitu ennakoitavissa olevien vikatilojen, käytönaikaisten muutosten ja alijärjestelmien välisten rajapintojen näkökulmasta, mikä käytännössä johtaa hankkeen hyväksytyn laajuuden mukaiseen järjestelmälliseen riskinarviointiin. Jos järjestelmä kootaan valmiista moduuleista, ohjaimista ja viestintäkerroksista, jotka tulevat eri toimijoilta, myös integraattorin vastuun muodollisen määrittelyn merkitys kasvaa. Yleensä juuri tässä vaiheessa kannattaa pysäyttää projekti ja tarkistaa tiedonvaihtokaavion lisäksi myös vastaanoton jälkeisten muutosten rajat, muutosten validointiperiaatteet sekä ylläpidon KPI-mittarit: viestinnän palauttamisaika, päivitysten jälkeisten häiriöiden määrä ja käsin mäppäystä vaativien rajapintojen lukumäärä. Tässä yhteydessä on syytä arvioida myös koneiden CE-merkintään ja vaatimustenmukaisuuden arviointiin liittyvät vaatimukset.