Miten tuotantolaitteiden data saadaan hyötykäyttöön?

Tuotantolaitteiden data saadaan hyötykäyttöön lukemalla se olemassa olevista järjestelmistä. Useimmissa tehtaissa mittaukset ovat jo olemassa koneiden ohjauslogiikassa (PLC), valvomojärjestelmässä (SCADA), tuotannonohjauksessa (MES) tai laitevalmistajan pilvessä. Ne vain jäävät sinne, vaikka siirtoon riittäisi tavallinen rajapinta eikä tehdasverkkoa tarvitsisi avata. Uutta dataa tarvitaan vasta, jos ratkaiseva mittaus puuttuu kokonaan.

Missä tuotantodata on ja miksi se ei päädy käyttöön?

Tuotantodata on yleensä hajallaan useassa järjestelmässä, ja jokaisella on oma omistajansa. Se ei päädy käyttöön, koska järjestelmät on tehty ohjaamaan tuotantoa, ei jakamaan tietoa. Kun kukaan ei vastaa datan siirtämisestä eteenpäin, se jää paikkaan, jossa se syntyi.

Tyypillinen tilanne on tämä: tuotantopäällikkö näkee aamupalaverissa eilisen tuotantomäärän MES:stä, mutta syy hitaaseen vuoroon on SCADAn hälytyslokissa, jota kukaan ei avannut. Sama ongelma kuin CRM-datassa, joka ei yksin riitä: yksittäinen järjestelmä näyttää oman osansa, ja havainto syntyy vasta yhdistämällä.

OPC UA, MQTT, API vai CSV: mikä rajapinta sopii mihinkin?

Uudemmissa laitteissa ja SCADA-järjestelmissä OPC UA on yleensä helpoin reitti, MQTT sopii, kun mittauspisteitä on paljon ja ne ovat hajallaan, ja laitevalmistajan API on ainoa vaihtoehto, kun data on jo valmistajan pilvessä. CSV-vienti ei ole huono valinta, jos data tarvitaan kerran vuorossa eikä sekunnissa. Teollisessa IoT:ssä (IIoT, Industrial IoT) valinta tehdään sen mukaan, mitä laitteet jo tukevat.

Vanhoissa linjoissa vastaus on usein yhdistelmä: uudemmat koneet luetaan OPC UA:lla, vanhimmasta saadaan ajastettu tiedostovienti ja tilaukset MES:stä. Rajapintaa valitessa punnitaan samoja asioita kuin silloin, kun valitaan no-code-työkalun ja räätälöidyn integraation välillä: mitä kriittisempi käyttö, sitä tärkeämpää on, että katkos huomataan eikä data katoa hiljaa.

Miten tuotantodata saadaan käyttöön avaamatta tehdasverkkoa?

Tuotantodata saadaan käyttöön turvallisesti, kun koneilta vain luetaan tietoa, yhteys avataan tehtaan sisältä ulospäin ja ohjausverkko pidetään erillään toimistoverkosta. Analytiikka ja tekoäly eivät koskaan muuta PLC:n arvoja eivätkä ohjaa koneita. Näillä kolmella periaatteella OT-vastaavan ei tarvitse avata palomuuriin yhtään sisääntulevaa porttia.

Käytännössä se tarkoittaa:

• Vain lukuoikeus. OPC UA -palvelimelle tehdään oma käyttäjä, joka voi lukea valitut tagit mutta ei muuttaa mitään.
• Yhteys ulospäin. Tehtaan reunalle sijoitettu välityspalvelin (edge gateway tai DMZ-verkon palvelin) lukee datan ja lähettää sen pilveen. Pilvestä ei oteta yhteyttä tehtaaseen.
• Verkon segmentointi. Ohjausverkko, välityskerros ja toimistoverkko ovat eri vyöhykkeillä. Vyöhykejako on myös IEC 62443 -standardisarjan keskeinen periaate.
• Lokitus ja omistaja. Jokainen yhteys jättää jäljen, ja jokaisella liittymällä on nimetty vastuuhenkilö.

Myös laki asettaa vaatimuksia. Kyberturvallisuuslain (NIS2-direktiivin toimeenpano) velvoitteet tulivat voimaan 8.4.2025, ja ne koskevat myös osaa valmistavasta teollisuudesta. Uusi tiedonsiirtoyhteys tehtaalta pilveen on siis riskienhallinnan asia, ei pelkästään IT:n tekninen kysymys.

Toteutamme tietoturvalliset integraatiot tehtaan ja pilven välille Microsoft Azuren päälle, jolloin data pysyy valitulla EU-alueella ja jokainen siirto näkyy lokissa.

Milloin olemassa oleva data riittää ja milloin ei?

Olemassa oleva data riittää, kun se mittaa oikeaa asiaa riittävän tiheästi ja sen voi yhdistää tilaukseen, erään tai vuoroon. Se ei riitä, jos ratkaisevaa ilmiötä ei mitata ollenkaan. Ennen kuin harkitset uusia antureita, tarkista neljä asiaa:

1. Näytteenottoväli. Historiatietokanta tallentaa usein vain muutokset tai minuutin keskiarvon. Laakerin värähtely vaatii tiheämmän mittauksen, energiankulutus tai linjan käyntiaste ei.
2. Aikaleimat. Jos PLC:n ja MES:n kellot ovat eri ajassa, mittauksia ei voi luotettavasti yhdistää tiettyyn erään.
3. Konteksti. Lämpötilalukema ilman tietoa siitä, mitä tuotetta linjalla ajettiin, kertoo vähän. Konteksti tulee yleensä MES:stä tai ERP:stä.
4. Puuttuva mittaus. Jos laatuvirhe syntyy kosteudesta, jota kukaan ei mittaa, mikään integraatio ei sitä korjaa.

Metsä Boardin esimerkissä pelkkä anturidata ei vielä riittänyt vastaukseen. Kuljetusten anturit kertoivat sijainnin ja olosuhteet, mutta rikkoutumisen paikka reitillä löytyi vasta, kun tiedot yhdistettiin varastointipisteissä kirjattuihin vauriomerkintöihin. Katso miten anturidata ja vauriokirjaukset yhdistettiin.

Rajalinja on selvä: otamme käyttöön datan, jota laitteet jo tuottavat. Jos tarkistuksessa selviää, että ratkaiseva mittaus puuttuu, anturin hankinta on erillinen päätös. Tilanteista, joissa tekoäly myös ohjaa laitetta, voit lukea fyysistä tekoälyä käsittelevästä artikkelista.

Mistä tuotantodatan hyödyntäminen kannattaa aloittaa?

Älä aloita koko tehtaan datasta, vaan yhdestä kysymyksestä, johon data voisi vastata. Hyvä ensimmäinen kohde on toistuva tilanne, jossa joku nyt kokoaa tietoa käsin tai huomaa ongelman liian myöhään. Operatiivinen tekoäly (operational AI) tuo arvoa vasta, kun data on yhdistetty ja joku toimii sen perusteella.

1. Valitse yksi kysymys, johon haet vastausta datasta. Esimerkiksi: miksi vuoron tuotantomäärä jäi tavoitteesta, tai milloin kone pitää huoltaa.
2. Listaa tarvittavat tagit. Usein riittää 10-30 mittausta, ei tuhansia.
3. Avaa yksi yhteys, jolla vain luetaan tietoa. Yksi linja tai kone, yksi rajapinta.
4. Yhdistä tilaus- ja erätietoon. Tämä on se kohta, jossa mittaus muuttuu havainnoksi.

Kun ensimmäinen kohde toimii, samaa yhteyttä voi laajentaa linja kerrallaan.

---

Empirica Finland on suomalainen operatiivisen tekoälyn ja automaation toteuttaja, joka rakentaa automaatiot yrityksen järjestelmien sekä laitteiden ja antureiden tuottamasta datasta ja vastaa automaatioiden jatkuvasta toiminnasta. Empirica on Claude Partner Network -jäsen ja Microsoft-kumppani.

← Takaisin pääsivulle