Kaivurit, metsäkoneet ja traktorit ovat nykyään pyörillä kulkevia ohjelmistoja, joissa on koodia ohjaamosta hydrauliikan venttiileihin. Silti perinteinen teollinen tuotekehitys polkee monesti paikallaan, sillä tiedonhallinnassa luotetaan yhä erillisiin dokumentteihin, loputtomiin palavereihin ja muutaman avainhenkilön muistiin.
Tuotekehityksen siiloutuminen näkyy suoraan viivästyksinä. Asiakkaat vaativat laitteilta autonomiaa, etähallintaa ja dataa, ja samaan aikaan tuotekehityksen pitäisi sujua aiempaa nopeammin.
“Koneen laatu ratkaisee yhä paljon, mutta entistä tärkeämpää on nopeus, jolla uusia ominaisuuksia tuodaan markkinoille ja se, kuinka nopeasti ne saadaan käyttöön”, Goforen palvelualuejohtaja Petri Ingalsuo kiteyttää.
Ingalsuon mukaan asiakkaat ovat heränneet tilanteeseen. Kentällä olevilta laitteilta odotetaan ominaisuuksia, joita niissä ei alun perin ollut, jolloin ohjelmistojen päivitettävyyttä on yksinkertaisesti parannettava. Hidas tuotekehitys ei ole enää pelkkä insinöörien murhe, vaan yrityksen kasvun ja kilpailukyvyn suora mittari.
Mallipohjainen toimintatapa kattaa sekä MBD:n että MBSE:n
Yksi tapa vastata haasteeseen on mallipohjainen kehittäminen. Siihen liittyvät termit menevät toisinaan sekaisin.
Model Based Design (MBD) on suunnittelutapa, jossa koneen toiminta mallinnetaan ja simuloidaan virtuaalisesti. Koneen toimintaa voidaan testata sen avulla simulaattorissa ennen fyysistä konetta.
Model Based Systems Engineering (MBSE) ei ole yhden tiimin työkalu, vaan ikään kuin sateenvarjo kaiken yllä. Se kokoaa vaatimukset, testit ja tulokset yhteen jäljitettäväksi ketjuksi.
“MBSE on kerros, joka liittää eri alojen vaatimukset, testit ja tulokset yhteen konetason kokonaisuudeksi. Kun jokainen vaatimus, testi ja tulos on kytketty toisiinsa, vaatimusten täyttäminen on jotain, jonka voi avata ja tarkastaa. Ei vain jotain, joka kootaan dokumenteista ja muistista,” Goforen MBSE-palveluista vastaava Otto Heikkonen toteaa.
Hän havainnollistaa asiaa yksinkertaisella, kuvitteellisella esimerkillä: kaivinkoneeseen kehitetään uusi pihtikasetti, joka tarttuu putkeen. Pihtikasetille asetetaan kolme vaatimusta: pihdin on saatava ote putkesta, kasetin on lukkiuduttava koneen liitäntään ja ohjaajan on pystyttävä hallitsemaan otetta ohjaimesta. Jokaiselle vaatimukselle tehdään oma testinsä.
Kun mekaniikka, hydrauliikka, ohjausohjelmisto ja koko kone testataan yhdessä simulaatiossa, putki putoaakin otteesta. Jokainen osa läpäisi oman testinsä, mutta kokonaisuus ei toimi.
Koska testitulos on linkitetty takaisin vaatimukseen, syy löytyy linkkejä pitkin: vaatimus pihdin otteesta on kirjattu, mutta se ei määrittele, kuinka suurella voimalla putkesta on pidettävä kiinni. Vaatimusta tarkennetaan hyväksymiskriteerillä ja toteutus korjataan. Kun sama testi ajetaan uudestaan, tulos on hyväksytty ja linkki näyttää, mitä vaatimusta tulos todentaa.
“Tässä on MBSE:n ydin. Ilman linkkejä tämä olisi vain hyvää testausta. Linkkien kanssa tuloksesta pääsee siihen vaatimukseen, minkä perusteella toteutus on rakennettu, ja korjaus todennetaan samalla testillä”, Heikkonen kuvaa.
Digitaalinen säie yhdistää hajallaan olevat testitulokset
Perinteisesti tuotekehityksessä mekaniikka, elektroniikka ja ohjelmistot on suunniteltu ja testattu erikseen.
“Jokainen tiimi todentaa oman osuutensa ja saa testinsä läpi: mekaniikka, elektroniikka, hydrauliikka, ohjelmisto. Todentamatta jää kone kokonaisuutena. Ensimmäinen testi, jossa kaikki ajetaan yhdessä, tehdään usein vasta prototyypillä ja silloin korjaus tarkoittaa jo rakennetun muuttamista”, Heikkonen sanoo.
Sama toistuu prototyypeissä. Mekaniikka on valmis, mutta ohjelmisto on jäänyt jälkeen.
“On tavallista, että ohjelmisto valmistuu vasta kuukausien päästä prototyypistä. Siinä ajassa mekaniikkakin on saattanut kehittyä eteenpäin, mikä tarkoittaa ylimääräistä kierrosta suunnittelussa ja protokoneissa”, Ingalsuo jatkaa.
Digitaalinen säie on lanka, joka yhdistää siilot. Se on tapa pitää tuotetieto kasassa: sen ansiosta yhteydet vaatimuksista testeihin ja tuloksiin pysyvät tallessa, eikä niitä tarvitse kaivella esiin jälkikäteen. Kun eri alojen osat ajetaan yhdessä simulaatiossa, kokonaisuuden ongelmat voivat paljastua jo ennen prototyyppiä ja ketju kertoo, mistä vaatimuksesta ne johtuvat.
Tekoäly luonnostelee, ihminen vastaa päätöksistä
Miksi tuotekehityksen haasteita ei ole korjattu jo aikoja sitten? Koska se edellyttää vanhojen vuosien varrella kertyneiden dokumenttien purkamista uusiksi vaatimuksiksi. Tämä on raskas työ, johon kaikilla ei ole aikaa.
Nyt tekoäly tuotekehityksessä on madaltanut kynnystä. Se voi perata tuhansien sivujen speksit ja tehdä raakaluonnokset vaatimuksista ja testeistä.
“Tekoäly auttaa siirtymän työläimmässä osassa: nykyiset työkalut lukevat olemassa olevat speksit, ohjeet ja testisuunnitelmat ja luonnostelevat niistä testattavia vaatimuksia sekä alustavan arkkitehtuurikuvauksen”, Heikkonen sanoo.
“Tulos voi olla paikoin väärä. Siksi se on luonnos, ei päätös. Ehdotus, jonka kanssa insinööri voi olla eri mieltä, on parempi lähtökohta kuin tyhjä sivu. Jokaisen vaatimuksen, jokaisen rajapinnan ja jokaisen linkin hyväksyy edelleen ihminen.”
Ingalsuo odottaa tekoälyn seuraavaa aaltoa, jolloin se löytää ristiriidat jo alkuvaiheessa ja hyödyntää kenttädataa uuden suunnittelussa. Siinä tekoäly voisi nostaa vaatimusten ristiriidat suunnittelijoiden eteen jo alkuvaiheessa ja tuoda kenttädatan uuden suunnittelun tueksi. Työkaluista täytyy tehdä kiinteä osa arkea eikä vain irrallisia kokeiluja.
Digital Product Lifecycle ja digitaalinen kaksonen – tavoitteena yhtenäinen tuotetieto
Yksittäistä tuotekehitysprojektia isompi kysymys on, mitä koneesta tiedetään koko sen eliniän ajan. Työkone palvelee kentällä helposti parikymmentä vuotta, ja valmistajalta odotetaan päivityksiä ja tukea yhä pidemmälle laitteen elinkaaressa
Goforen Digital Product Lifecycle -ajattelun tavoite on, että tuote syntyy ensin virtuaalisena ja sen tieto kulkee mukana koko elinkaaren ajan. Mallipohjainen toimintatapa rakentaa tälle pohjan: digitaalinen säie alkaa tallennetuista linkeistä vaatimuksesta testiin ja tulokseen.
”Kaikki digitaalinen tieto, mitä tuotteesta on olemassa ja mitä sen elinkaaren aikana kertyy, nivotaan yhteen. Tämän ansiosta eri elinkaaren vaiheissa tarvittavat digitaaliset kaksoset voidaan luoda automaattisesti”, Ingalsuo sanoo.
Digitaalinen kaksonen on koneen virtuaalinen vastine. Tuotekehitysvaiheessa simuloitava virtuaalikone, jota ajetaan jo ennen fyysisten osien valmistamista, on alalla jo arkipäivää. Sen sijaan koko elinkaaren mittainen kaksonen, joka päivittyy kenttädatalla, on alan seuraava suunta.
Goforen näkemys on, että tulevaisuuden kone- ja laitebisnes nojaa juuri tähän katkeamattomaan digitaaliseen elinkaareen ja datavirtaan. Kun digitaalinen kaksonen ja data elävät vielä myynnin jälkeenkin, valmistaja voi tarjota asiakkaan laitteelle ennakoivaa huoltoa ja päivityksiä sekä luoda uutta palveluliiketoimintaa.
Miten teollinen tuotekehitys voi aloittaa siirtymän kohti uutta?
Kone- ja laiteteollisuuden yritysten lähtötasot vaihtelevat suuresti. Ensimmäinen askel on kuitenkin kaikille sama.
“Valitkaa yksi alijärjestelmä: mieluiten sellainen, jossa mekaniikka, hydrauliikka ja ohjelmisto kohtaavat. Kirjoittakaa sen vaatimukset testattavaan muotoon, tehkää jokaiselle testi ja linkittäkää tulokset takaisin vaatimuksiin niillä työkaluilla, joita teillä jo on. Ottakaa työn alle toinen alijärjestelmä vasta, kun ensimmäinen toimii näin päästä päähän”, Heikkonen sanoo.
“Kyse on ensin toimintatavasta, ei työkaluhankinnasta. Kun uusi toimintatapa on löytänyt muotonsa, sen skaalaaminen laajemmalle on tehokkaampaa.”
Heikkonen kannustaa miettimään investoinnin kokoa omien lukujen kautta. Paljonko yksi protovaiheen virhe maksaa päivinä tai viikkoina? Entä paljonko auditoinnin selvittely vie työaikaa?
Gofore rakentaa simulaattoreita konevalmistajille osana päivittäistä liiketoimintaansa. MBSE:n ydin on kuitenkin malli, ei simulointi: eri alojen yhteinen kuvaus koneesta. Simulaatio on yksi tapa testata kokonaisuutta jo ennen fyysistä konetta. Se on hyödyllinen tapa, mutta ei edellytys MBSE:lle.
Ensimmäisen askeleen Gofore pitää tarkoituksella pienenä, koska pieni askel on ennustettava: yksi alijärjestelmä toteutetaan asiakkaan omilla työkaluilla ja laajennus tehdään vasta, kun ensimmäinen alijärjestelmä toimii ja on osoittanut hyötynsä asiakkaan omilla mittareilla
”Ei koko norsua tarvitse syödä kerralla. On monia tapoja aloittaa, ja jostain on aloitettava ennemmin kuin myöhemmin”, Ingalsuo sanoo.
Varaa keskustelu Goforen asiantuntijoiden kanssa ja selvitä, miten Model Based Design, Model Based Systems Engineering ja tekoäly voisivat vauhdittaa juuri teidän tuotekehitystänne!
