Valmistautuminen ensimmäiseen predictive maintenance -projektiin

Projektin suunnittelu ja arvon määritys

Ennen projektin alkua täytyy tunnistaa, mitä ongelmaa ollaan ratkaisemassa. Kun ongelmaa valitaan, on tärkeää, että ratkaisu on tarpeeksi arvokas: joko ratkaisu tuo tarpeeksi säästöjä tai lisää tarpeeksi tuloja. Jos ratkaisu ei ole tarpeeksi arvokas, organisaatio tulee menettämään mielenkiinnon projektiin ensimmäisten vastoinkäymisten yhteydessä. Ja vastoinkäymisiä tulee aina. 

Mikä on tarpeeksi arvokas? Mallin suunnittelu ja teko maksaa. Mallin vienti tuotantoon maksaa. Käyttökokemusten hankkiminen ja niiden perusteella tehty myöhempi lisäkehitys maksaa. Pelkkä ratkaisun ylläpito maksaa. Ensimmäisen machine learning -projektin tapauksessa kaikki tämä maksaa vielä enemmän. Ilman hyviä perusteluja en ottaisi ensimmäiseksi machine learning -projektiksi ongelmaa, jonka ratkaisun teoreettinen hyöty on vain parikymmentä tuhatta euroa vuodessa. Hyvä perustelu voisi olla roadmap, joka tekee selväksi, miksi vähemmän arvokkaan ongelman ratkaisu auttaa ratkaisemaan paljon arvokkaampia ongelmia tulevaisuudessa. Useimpien organisaatioiden kohdalla itse suosisin enemmän nopeasti kasvaneita tuloja kuin roadmappia. Roadmapit ovat tulevaisuuden ennustamista ja mitä kauemmas ennustetaan, sitä enemmän on epävarmuutta. Lisäksi nopeat tulot vaikuttavat fokusoivan organisaatioiden tekemistä paremmin kuin roadmapit. 

Luonteva tapa lähteä liikkeelle on tehdä pienen budjetin tekninen proof of concept (PoC), jonka kesto voi olla pari viikkoa tai kuukausi. PoCiin valitsisin teknisiä ongelmia, joiden ratkaisu on kriittisen tärkeää ja joita organisaatiossa ei vielä osata ratkoa. Tällä pyritään välttymään tilanteelta, jossa jo alussa tunnistettu ongelma pysäyttää pitkälle edenneen projektin. Jos PoCin lopputulos ei ole lähellekään tyydyttävä, ei tässä vaiheessa ole vielä tuhlattu paljoa rahaa eikä aikaa. Jos lopputulos on vähintään riittävän hyvä, projektia voidaan jatkaa luottavaisemmin mielin.

PoC kannattaa suunnitella osaksi isompaa tavoitetta eikä itsenäiseksi kokeiluksi. Näin projekti ensiksikin jatkuu mahdollisimman sujuvasti onnistuneen PoCin jälkeen. Oman kokemukseni mukaan PoCien riski on, että onnistuneenkin kokeilun jälkeen tekeminen pysähtyy. Tuloksia arvioidaan eri tapaamisissa ja asioista keskustellaan loputtomiin. Lopulta momentum on kadonnut ja tekijät ovat tekemässä uusia projekteja. Toiseksi, jos PoC tehdään osaksi projektisuunnitelmaa, PoC on usein fokusoituneempi ja arvo on paremmin määritelty kuin itsenäisen PoCin tapauksessa.

Mitä kannattaa mallintaa?

Ensimmäiseksi projektiksi kannattaa valita helposti mallinnettava ongelma. Laitteessa voi olla satakin sensoria mittaamassa arvoja. Pyydä laitteen tuntevaa ammattilaista valitsemaan noin viisi sensoria, joiden mitta-arvot ennustavat parhaiten lähestyvää vikatilaa. Esimerkiksi laitteen lämpötila ja teho voivat olla tärkeitä. Varmista visualisoimalla, että valituissa arvoissa näkyi vikatilaa ennustava muutos ennen vikatilaa. 

Mallinnusta varten data jaetaan kahteen osaan: “normaali” ja “menossa vikatilaan”. Menossa vikatilaan on se osa datasta, joka visualisoinnissa käyttäytyi erikoisesti ennen vikatilaa. Normaali data ei ole menossa vikatilaan eikä vikatilassa. Tee yksinkertainen malli tunnistamaan, kuinka normaalissa tilassa laite on tietyllä ajanhetkellä. Malli voi olla myös luokittelija.

Mitä hyötyä on mallista, jos ihminenkin pystyy huomaamaan ongelman vain dataa katsomalla? Ihmisellä ei ole aikaa katsella dataa. Lisäksi datalle saattaa olla tehty kynnysarvo- eli threshold-hälytyksiä. Monesti vikatilan läheisyyden aiheuttamat poikkeamat datassa on vaikeaa saada kiinni yksinkertaisilla thresholdeilla. Esimerkiksi lämpötilan nousu voi olla indikaattori lähestyvästä vikatilasta. Toisaalta sama lämpötila voi olla osa normaalitilaa, jos ulkolämpötila on tietyn korkuinen ja moottorista otetaan tietyn verran tehoja ulos. Tälläisissä tilanteissa yksinkertainen malli voittaa thresholdin.

Fyysisten laitteiden osat kuluvat ja kerran treenatun mallin tarkkuus heikkenee ajan myötä. Lisäksi huollot ja vikatilojen jälkeiset korjaukset muuttavat fyysistä laitetta. On tapauskohtaista, paljonko tällaisilla muutoksilla on vaikutusta mallin ennusteiden tarkkuuteen. Omien kokemusteni mukaan mallit ovat kestäneet varsin hyvin fyysisen laitteen ikääntymistä ja kohtuullisesti remontteja. 

Lopuksi

Uuden asian tekeminen ensimmäistä kertaa on aina riskialtista. Usein riskejä voi kuitenkin pienentää ennestään tutuilla toimintamalleilla. Näitä toimintamalleja, kuten intensiivistä arvon määrittämistä ja iteratiivista tekemistä, olen tuonut esille tässä blogikirjoituksessa. Hyvällä projektinhallinnalla predictive maintenance -projekteista voi saada hyötyä kohtuullisella budjetilla.