Vikaantumisen ennustaminen teollisuudessa ja vaadittava datan määrä

Teimme vuosi sitten teollisuusyritykselle vikaantumisen ennustamiseen liittyvän proof-of-conceptin (POC). Tehtävänämme oli osoittaa, että analytiikan menetelmin voimme ennakoida tuotteiden vikaantumista tuotantoprosessissa. Löytämällä vialliset tuotteet hyvissä ajoin tuotantoprosessin alkuvaiheessa, säästettäisiin isoja summia rahaa ja aikaa sekä parannettaisiin laatua.

Löysimme vikaantumista implikoivat eli ennustavat tekijät ja POC onnistui. Osoitimme, että tiedon louhinnan menetelmin vikaantuvat tuotteet voidaan löytää ennakkoon ja varmistaa, että tuotantoputkesta tulee priimaa.

Mutta se miksi kirjoitan aiheesta, liittyy mallinnuksessa tarvittavaan dataan. Sillä sitä tarvittiin yllättävän vähän.

Ymmärtääksesi maailmaa, sinun ei tarvitse mallintaa koko maailmaa

Asiakkaan tuotantoprosessit generoivat dataa kymmeniä teratavuja vuodessa. Mitattavia muuttujia oli n. 100. Se on siis jo sitä big dataa. Selvitimme asiakkaan pyynnöstä eri vaihtoehtoja tallentaa tätä määrää. Käytiin läpi hadoopit ja erilaiset appliance-ratkaisut eli suoraan tehtaalta toimitettavat palvelinkaapit järeään käyttöön (esim. Netezza, Teradata, Microsoft Parallel DW…). Hintalappu näiden osalta huimasi, varsinkin kun nyt tehtiin vasta poc:ia ja varsinaista todistettua business casea ei ollut. Sitähän oltiin vasta hahmottamassa.

Tuumailimme hieman ja päädyimme rakentamaan poc-ympäristön ihan perinteisen SQL Serverin päälle. Nykäisimme kevyet muutamat kymmenet gigat dataa sinne ja aloimme mallintamaan. Mallinnuksessa käytimme RapidMineria.

Mallinnus tehtiin iteratiivisesti, dataa muokaten, vaihtaen muuttujia, vähentäen ja lisäten dataa. Pääsimme koko ajan parempiin ja parempiin tuloksiin. Aina vain tarkemmaksi ja tarkemmaksi. Eli löysimme vikaantuneita tuotteita tarkemmin ja toisaalta vikaosumia tuli vähemmän.

Lopulta olimme tyytyväisiä. Noin 5 htp työ oli pikainen rykäisy mutta tarkkuus ei enää tuosta parantunut.

Ja millaisella datamäärällä tuosta kaikeasta kymmenistä teratavuista lopulta tarvitsimme meidän tarkimmassa mallinnuksessa?

Alle 0,5 gigatavua.

Mallimme tarkkuus ei parantunut merkittävästi vaikka dataa olisi ollut 10 gigaa tai 50 gigaa. Alle 0,5 giga edusti siis riittävästi koko todellisuutta. Lisäksi tuotantoprosessissa kertyvistä 100:sta sensoritiedosta ja muuttujasta, lopulta vikaantumista ennusti alle 15.

Tarvittava datamäärä suhteessa saatavilla olevaan dataan

Tarvittava datamäärä suhteessa saatavilla olevaan dataan

Less is more – älä hölmöile itseäsi rautakauppaan ennenkuin olet keskustellut asiantuntijan kanssa

Ja opetus tässä tapauksessa: olisi ollut pöljää rahan haaskausta lähteä rakentamaan raskasta appliance/big data arkkitehtuuria. Pelkästään hankinnoissa ja ympäristön pystyksessä olisi mennyt kuukausia.

Liian iso massa olisi myös tehnyt mallinnuksen erittäin vaikeaksi. Jo nyt RapidMiner luukutti 12h putkeen ja murskasi lukuja vaikka dataa oli aika vähän.

Tämä ei ollut poikkeustapaus. Useimmissa niin teollisuuden mallinnushankkeissa kuin asiakaskäyttäytymisen mallintamisessa, lopullinen mallintamiseen tarvittava datasetti on aika pieni. Joskus jopa vain muutamia tuhansia rivejä, vaikka koko populaatio olisi miljoonia.

Ja näinhän toimii nyt ajankohtaiset vaaligallupitkin. Ei TNS Gallupin tarvitse haastatella miljoonaa suomalaista tietääkseen mitä 5 miljoonaa suomalaista on mieltä. Usein otokseksi riittää jo muutama tuhat, kunhan se edustaa koko kansaa mahdollisimman kattavasti.

Ja mikä parasta: riippuen mallinnustavasta, saamme tulokseksi yksinkertaisen kertolaskun (regressiokaava), joka on yksinkertaistettuna tyyliä: IF muuttuja x > 50 AND muuttuja y < 100 THEN… Tämän kaavan voimme upottaa asiakkaan toiminnanohjausjärjestelmään ja näin meillä on implementoituna reaaliaikainen vikaantumisen ennustamisprosessi, joka ei tarvitse edes mitään analytiikkasoftaa tuotantokäytössä.

Kun lähdet tekemään prediktiivistä analytiikkaa, muista nämä:

  • Älä hölmöile ja lähde rautakauppaan kun kohtaat analytiikkahaasteen, kysy ensin neuvoa asiantuntijalta. Huom: softamyyjä on harvoin tällainen asiantuntija.
  • Less is more (useimmiten). Lisäksi iteratiivisuus ja ketteryys on mahdollista kun dataa on vähemmän. Ja nämä ovat tärkeimpiä ominaisuuksia alussa kuin äärimmilleen viety tarkkuus.
  • Mallinnuksen tuloksena saatavat kaavat voidaan usein upottaa tuotannon järjestelmiin eikä tuotantokäytössä edes tarvita analytiikkasoftaa.
  • teollisuuden vikaantumisen ennustaminen tai ennakoiva huolto ei tarkoita aina massiivista jättihanketta. Me todistimme business casen olemassaolon ja mallinnuksen toimivuuden noin 5 päivässä.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

Yhteydenotto

Mikäli olet kiinnostunut yrityskohtaisista palveluista tai sinulla kysyttävää palvelujemme sisällöstä, niin ota yhteyttä oheisella lomakkeella tai soita Mikalle numeroon 040 845 8432.

Please leave this field empty.