Virtuaalinen konelaboratorio ja semanttinen mallinnus konejärjestelmän suunnittelun tukena, Loppuraportti, Semogen II -hanke

Transkriptio

1 TAMPEREEN TEKNILLINEN YLIOPISTO, SMART SIMULATORS -TUTKIMUSRYHMÄ Virtuaalinen konelaboratorio ja semanttinen mallinnus konejärjestelmän suunnittelun tukena, Loppuraportti, Semogen II -hanke Loppuraportti Semogen II hanke

2 ESIPUHE Tämä on Virtuaalinen konelaboratorio ja semanttinen mallinnus konejärjestelmän suunnittelun tukena Semogen II -hankkeen loppuraportti. Kaksiosaisen Semogen-hankeperheen punaisena lankana oli semanttisen mallinnuksen ja virtuaalisten konelaboratorioiden tuotantomenetelmien tutkimus konejärjestelmien tuoteprosessien tukena. Semogen II -hankkeessa tutkittiin konejärjestelmän semanttisia kuvausmenetelmiä, mallien automaattista generointia ja älykkäitä piirteitä sekä niiden soveltamista virtuaalilaboratorioprototyypin kehitykseen. Työn pohjana oli Semogen-hankekonsortion tuki sekä teollisuuden älykkäiden ja virtuaalisten konelaboratorioiden tuotantomenetelmien kehitys semanttisen kuvauksen avulla - Semogen I -hankkeen tutkimusaineisto (Smart Simulators, 2011). Hankekonsortion muodostivat: AEL, Cargotec Finland Oy, Etteplan Design Center Oy, Sandvik Mining and Construction Oy, Tampereen teknillinen yliopisto sekä Vertex Systems Oy. Hanke haluaa kiittää yrityskonsortion rahoitus- ja asiantuntijapanoksesta sekä Teknologiateollisuuden 100-vuotissäätiötä hankkeen päärahoituksesta. Hankkeen yrityskumppanien asiantuntijoiden panos on tukenut merkittävällä tavalla hanketta. Lämmin kiitos hankkeen ohjausryhmälle: puheenjohtaja, Veijo Niemelä Vertex Systems Oy, Harry Nordman AEL, Hannu Santahuhta Cargotec Finland Oy, Pekka Anttonen Sandvik Mining and Construction Oy, Mikko Gratschew ja Sampsa Guenat Etteplan Design Center Oy, Seppo Pohjolainen TTY/Matematiikan laitos/intelligent Information Systems Laboratory ja Kari T. Koskinen TTY/Hydrauliikan ja automatiikan laitos. Lämmin kiitos myös työpajoihin osallistuneille lukuisille yrityskumppaneiden ja tutkimusosapuolten asiantuntijoille. Hankkeen tutkimusosapuolena toimi TTY:n Smart Simulators -tutkimusryhmä, joka on TTY:n poikkitieteellinen tutkimusryhmä. Tähän hankkeeseen osallistui edustajia kahdelta laitokselta: TTY/Matematiikan laitos/intelligent Information Systems Laboratory professori, hankkeen johtaja Seppo Pohjolainen, dosentti Ossi Nykänen, projektipäällikkö Pekka Ranta, tutkija Jaakko Salonen ja tutkimusapulainen Juha Nurmi; TTY/Hydrauliikan ja automatiikan laitos professori Kari T. Koskinen, tutkija Markus Rokala, tutkija Vänni Alarotu, tutkija Jussi Aaltonen, tutkimusapulainen Tuomas Salomaa ja tutkimusapulainen Matti Helminen. Loppuraportin ovat toimittaneet Ossi Nykänen, Kari T. Koskinen, Pekka Ranta, Jaakko Salonen, Jussi Aaltonen, Juha Nurmi, Matti Helminen, Vänni Alarotu, Tuomas Salomaa sekä Seppo Pohjolainen. Hankkeen wiki-sivu löytyy osoitteesta: 1

3 TIIVISTELMÄ Semogen II hankkeessa ( Virtuaalinen konelaboratorio ja semanttinen mallinnus konejärjestelmän suunnittelun tukena ) tutkittiin semanttisen mallinnuksen menetelmien ja virtuaalisen konelaboratorion mahdollisuuksia tukea konejärjestelmän yhteistoiminnallista suunnitteluprosessia. Hanke pohjautui semanttiseen mallinnukseen, jolla ymmärretään linkittyneen, formaalin ja koneluettavan informaation menetelmien hyödyntämiseen konejärjestelmätuotteiden suunnittelussa. Konejärjestelmän suunnitteluparadigma nojautuu Systems Engineering teoriaan, joka voidaan määritellä monitieteiseksi suunnittelun ja tuotekehityksen hallintaprosessiksi, jolla kehitetään verifioituja elinkaaren ja asiakasvaatimukset huomioivia järjestelmäratkaisuja. Semanttisen mallinnuksen menetelmät edellyttävät vahvan kiinnityksen prosesseihin, joten keskeistä on kehittää teknologioiden rinnalla semanttisia prosesseja. Hankkeessa määritettiin konejärjestelmän semanttisen suunnitteluprosessin malli, joka perustuu yleisesti tunnettuun VDI malliin. Semanttisen suunnitteluprosessimallin ero muihin suunnittelun prosessimalleihin on että se on kehitetty nimenomaisesti mikrotason suunnittelu- ja tuotekehitysprosessin malliksi eikä suunnittelun hallintaprosessin malliksi. Semanttinen suunnitteluprosessi vie myös mallipohjaisen suunnittelun metodologian askeleen edelle muita prosessimalleja liittämällä kuhunkin prosessin askeleeseen tietyt käsitteelliset ja matemaattiset mallit. Hankeen tapaustutkimukset perustuivat viiteen skenaarioon: tuotetiedon (CAD/PDM-tiedon) linkityksen kehittämiseen, konejärjestelmän verkkosuunnitteluun (CANOpen), korjaus- ja muutospyyntöjen hallintaan, nimikkeiden linkitykseen sekä toimintokeskeiseen suunnitteluun. Näitä läpäisevinä teemoina toimivat semanttinen ja datalähtöinen tuotetiedon prosessointi, virtuaalinen konelaboratorio, yhteistoiminnallinen asianhallinta sekä selainpohjaisten teknologioitten hyödyntäminen. Hankkeen tulosten perusteella voidaan todeta, että datalähtöistä (CAD) ja semanttisesti rikastutettua informaatiota voidaan varsin automaattisesti prosessoida. Keskeinen tulos on, että tekninen arkkitehtuuri ja informaation prosessoinnin putkilinja voidaan rakentaa nojautuen avoimiin web-teknologiastandardeihin. Näin datalähtöistä informaatiota voidaan prosessoida hyödynnettäväksi virtuaalisissa konelaboratorioissa että tuotteen elinkaaritiedon koosteissa siten, että muutokset on hyvin ajantasaisesti hallittavissa. CAD järjestelmällä tuotettu ja semanttisesti rikastutettu tuoteinformaatio voitiin PDM-ohjelmasta siirtää RDFmuodossa ohjelmistokomponenttien prosessoitavaksi. Hankkeessa luotiin myös semanttisten datalehtien malli, jonka avulla konejärjestelmän laaja toimittajaverkosto voisi toimittaa yhteensopivaa, rikkaasti kuvailtua ja päivitettyä tuoteinformaatiota tilaajien käyttöön. Hankkeessa hyödynnettiin asianhallintajärjestelmiä (issue tracking) teknologioita yhteistoiminnallisen suunnitteluprosessin tukena. Selainpohjaisten ratkaisujen avulla voidaan luoda näkymiä suunnitteluprosessin tilaan ja sen hallintaan. Suurin haaste liittyy vallitseviin toimintamalleihin. Suunnitteluaineisto ei ole riittävästi kuvailtua ja se on tietylle rajattua tietylle sovellusalueelle, jolloin koneluettavuus ja linkitykset eivät ole riittäviä moniteknisen konejärjestelmän suunnitteluratkaisuja tukevien tietomallien toteutukseen. Esimerkkinä toimii nimikkeiden, viitetunnusten, komponenttiparametrien, luokittelujen ja tuoterakenteiden välinen yhteensopimattomuus puomijärjestelmätasolla. Lisäksi suunnitteluaineiston tiedostorajapinnat eivät ole yhteensopivia, jolloin informaation sovitus edellyttää tiedon muokkausta. Tämä luo selkeän tarpeen semanttisen suunnitteluprosessin määrittämiseen, koska ilman johdettua prosessin hallintaa tämä ei ole mahdollista. Semogen I hankkeessa kuvatut semanttinen prosessimalli soveltuu myös suunnitteluratkaisuihin. Verkostomainen toimintatapa edellyttää koko toimittajaverkoston yhteistä mallia, jotta tuoteinformaatio virtaa saumattomasti läpi tuotteen elinkaarenhallintaprosessien. Tässä keskiössä toimivat semanttiset datalehdet, joiden avulla voidaan tuotetiedot ja jopa konfiguraatiotiedot välittää saumattomasti yrityksen 2

4 tuotetietojärjestelmään. Tätä toimintatapaa tukee myös yhteistoiminnallinen asianhallintateknologioiden hyödyntäminen. Konejärjestelmien yhteissuunnittelua edistää vaatimusmäärityksiin perustuvat toiminnot, jotka luovat yhteisen perustan monitekniselle konejärjestelmälle. Toimintoketjut on mahdollista semantisoida siten, että yhteydet moniteknisiin osa-alueisiin voidaan esittää ja prosessoida. Semogen II -hankkeen kartoitusten ja empiiristen tulosten nojalla voidaan todeta, että konejärjestelmän suunnittelun tukeminen virtuaalisen konelaboratorion ja semanttisen mallinnuksen avulla on tietenkin haastavaa, mutta täysin mahdollista sekä periaatteessa että käytännössä. Tulosten jalkauttaminen yrityksiin edellyttää sitoutumista yhteissuunnittelua kannustavaan työkulttuuriin ja suunnittelutiedon koneluettavuuden kehittämistä. Ensimmäisten käytännön suunnittelua tehostavien askelten ottaminen ei kuitenkaan ole kohtuuttoman vaikeaa, vaan edellyttää lähinnä informaatioarkkitehtuurin hallintaan liittyvien vaatimusten ja tehtävien sisällyttämistä nykyiseen Systems engineering -ajatteluun. Yksinkertaisimmillaan tämä tarkoittaa nykyisten suunnitteluohjelmistojen käyttötapojen uudelleenmiettimistä ja suunnittelun osa-alueiden haitallisten "siilojen" purkamista aidon yhteissuunnittelun eduksi. Semogen lähestymistavalla on selkeä yhteys laajempaan paradigman muutokseen kohti asiakaslähtöistä tuotteen elinkaaren hallintaa, verkostomaista yhteistyötä, mallipohjaista suunnittelua sekä älykkäitä kontekstitietoisia ratkaisuja. Tätä ajattelutapaa edustaa teoreettinen Engineering Intelligence Ecosystem viitekehys, joka kokoaa osa-alueet. 3

5 SISÄLLYSLUETTELO Esipuhe... 1 Tiivistelmä Johdanto Systems engineering malli konejärjestelmän semanttisessa suunnitteluprosessissa Konejärjestelmän suunnittelusta Mekatronisen konejärjestelmän suunnitteluprosessi Systems engineering ja yhteistoiminnallinen suunnittelu Suunnittelumalleja Semanttinen mallinnus ja linkitetty data suunnitteluinformaation integroinnissa Virtuaaliympäristöt suunnittelun tukena Asiantuntijahaastattelu Vaatimukset skenaarioille Konejärjestelmän suunnittelu semanttisenmallinnuksen menetelmien tuella Tekninen arkkitehtuuri Semanttinen datalehti Semanttinen CANopen-verkkosuunnittelu Semanttinen asianhallinta konejärjestelmän suunnittelussa Semanttinen ja linkittynyt nimikkeiden hallinta Esimerkkiaineisto Aineiston semanttinen mallinnus Tulokset ja pohdintaa Toimintokeskeinen, semanttinen suunnittelu Lopuksi Lähteet Liite 1: Hankkeeseen liittyvät julkaisut Liite 2: Sanasto ja termit

6 1. JOHDANTO Tuotetiedon elinkaaren hallinta, mallipohjainen suunnittelu, virtualisointi ja yhteistoiminnalliset ympäristöt ovat tunnistettu keskeisiksi menetelmiksi teollisuuden modernisoinnissa kohtia asiakaskeskeisiä ja ketteriä ratkaisuja. Suurina ajureina menetelmissä toimivat muuttuvien toimintaympäristöjen hallinta, asiakaskeskeiset toimintamallit, massaräätälöinti, kustannusten hallinta ja läpimenoaikojen lyhentäminen. Lisäintressejä tuovat virheiden vähentäminen, informaation uudelleen käyttö, varhainen prototypointi sekä asiakkaan osallistaminen. Nämä menetelmät edellyttävät teknologioiden, osaamisen ja prosessien kehittämistä. Semogen -tutkimushankkeissa on lähestytty problematiikkaa semanttisen mallinnuksen (linkittynyt, formaali ja koneluettava informaatio), systems engineering -periaatteiden (mallipohjainen suunnittelu ja tuotteen elinkaaren hallinta), simulointimallien generoinnin (automaattinen simulointimallien tuottaminen suunnittelutiedon avulla) ja virtuaalisen konelaboratoriteknologian (virtuaalinen ja simuloitu konejärjestelmä) avulla. Hankeen tavoitteina on tutkia semanttisen mallinnuksen mahdollisuuksia tukea konejärjestelmän mallipohjaista suunnittelua, virtuaaliprototypointia sekä yhteistoiminallisia prosesseja. Semanttisella mallinnuksella tarkoitetaan tässä tietyn sovelluksen (rajatun) tietosisällön jäsentämistä ja kuvailua ohjelmallisesti tulkittavassa, valitun tehtävän kannalta hyödyllisessä muodossa. Käytännön ratkaisut pohjautuvat yleensä standarditeknologioiden, valmisohjelmistojen ja sovellusalueen yleisesti tunnettujen teknisten sanastojen (esim. standardinimikkeet) käyttöön. Kun semanttisen mallinnuksen periaatteet ja valittuihin tehtäviin liittyvät tekniikat yhdistetään, voidaan puhua esim. semanttisesta laskennasta. Semogen I hankkeessa ( Teollisuuden älykkäiden ja virtuaalisten konelaboratorioiden tuotantomenetelmien kehitys semanttisen kuvauksen avulla ) tutkittiin menetelmiä, malleja ja teknologioita, joiden avulla tuotantoprosessia voidaan kehittää puoliautomaattiseksi. Käsillä oleva loppuraportti liittyy Semogen-hankeperheen toiseen vaiheeseen, Semogen2-hankkeeseen. Virtuaalinen konelaboratorio ja semanttinen mallinnus konejärjestelmän suunnittelun tukena. Hanke jatkoi Semogen-työtä kohdentamalla tarkastelun fokusta ensimmäisessä hankevaiheessa havaittuihin "kipupisteisiin" sekä konejärjestelmän moniteknisen yhteissuunnittelun tukemiseen. Tämä edellyttää yhteistä työtilaa, tässä tapauksessa virtuaalista konelaboratoriota. Kasvokkain tehtävän yhteistyön ohella virtuaalisuus tarjoaa uusien välineiden ohella myös ajasta ja paikasta riippumattomia työmahdollisuuksia. Tiedon jatkuva saatavuus, prototypointi ja jatkuva arviointi mahdollistavat ketterän suunnittelun. Sähköiseen, semanttisesti jäsentyneeseen muotoon karttunutta aineistoa on myös mahdollista uudelleen käyttää tulevissa hankkeissa. Suomalainen koneenrakennus on merkittävässä osassa tarkasteltaessa vientiteollisuuttamme. Eräs merkittävä ajattelumalli koneenrakennusteollisuuden prosesseja kehitettäessä on Systems Engineering, jonka avulla voidaan lisätä esimerkiksi suunnitteluprosessien mallipohjaisuutta, kokonaisvaltaisuutta ja yhteistoiminallisuutta sekä lisäksi pienentää ns. sähläyskustannuksia. Systems Engineering ajattelu on tunnettu jo pitkään, mutta sen soveltaminen teollisuudessa vielä vähäistä. Syynä tähän on useita mm. mallinnustyökalujen yhteensopimattomuus, siiloutuminen, asenteet jne. Semogen2 hankkeessa kehitetty semanttinen suunnitteluprosessi perustuu ajatteluun, jossa tieto on yhteensopivaa ja kaikille toimijoille voidaan tuottaa kokonaisnäkemys. Tätä tavoitellaan hyödyntämällä semanttista mallinnusta systemaattisesti System Engineering mallin mukaisissa suunnitteluprosesseissa. Semogen II -hankkeen tulokset osoittavat tapoja kehittää suunnittelu- ja tuotantomenetelmiä, esittelevät uudentyyppisiä linkitettyjä työkaluja konseptisuunnitteluun ja suunnitteluprosessin hallintaan sekä tarjoavat läpileikkauksen moniteknisten suunnittelujärjestelmien ja CAD/PDM-välineiden kehitysmahdollisuuksista. 5

7 Työn merkittävänä osana kehitettiin suunnitteluinformaatiota ja työvaiheita linkittävä semanttinen malli, jonka mahdollistaa uudenlaisen tavan tarkastella, kehittää ja prosessoida suunnittelu- ja tuotantoprosessin tietosisältöä. Konkreettisuudestaan huolimatta, semanttisella mallilla ei ole yksinkertaista esitystapaa, vaan se "on" sovelluksen hyödyllisten piirteiden ja tietosisällön looginen kuvaus, jota käytetään erilaisten kyselyja ohjelmointirajapintojen välityksellä (vrt. monimutkainen relaatiotietokanta). Intuitiivisen käsityksen luomiseksi, semanttista mallia voidaan kuitenkin yrittää visualisoida eri tavoin. Loppuraportin kansikuva esittää visualisoinnin, jonka näkökulmana on mallin kytkeytyvyyden, modulaarisuuden sekä laajuuden tarkastelu graafimallin pohjalta. Mallissa esiintyvät resurssit (mm. nimikkeet, komponentit ja luokittelujärjestelmien käsitteet) on visualisoitu graafin solmuina (kuvassa: väritetyt pallot). Näiden solmujen väliset semanttiset kytkökset on esitetty graafin kaarina (kuvassa: palloja yhdistävät viivat). Solmujen väritys ja sijainti kuvaavat mallin laskennallista modularisuutta, joka usein noudattelee mallin datan jakautumista eri suunnittelualueille tai tietolähteille. Ne solmut, joilla on keskenään määrällisesti eniten semanttisia kytköksiä kuvautuvat samaan ryhmään samalla värikoodilla. Myös solmujen suhteellinen sijoittelu kuvaa niiden keskinäistä kytkeytyvyyttä. Kuva 1.1. Semanttisen mallin visualisointi, jossa koneen linkittynyttä, koneluettavaa ja formaalia mallia voidaan tarkastella kytkeytyvyyden, modulaarisuuden ja laajuuden näkökulmista. Projektin tapaustutkimuksen näkökulmasta semanttinen mallinnus tarkoittaa esimerkiksi työkoneen puomin ja sen suunnitteluprosessin käsitteellistä jäsentämistä (ml. käsitteiden yksikäsitteinen nimeäminen ja käsitteiden suhteiden kuvaus) sekä hydrauliikkasuunnittelun suunnitteluaineiston rikastamista (ml. komponenttirakenteen esitys ja simulointimallien parametrien tyypitys sekä edelleen käsitteellinen kytkös tuoterakenteeseen viitetunnusten perusteella). Hyvässä suunnittelussa semanttinen kuvailutieto (esimerkiksi 6

8 komponenttien tyypitys ja kytkökset) tunnistetaan ja tallennetaan osana ensisijaista suunnittelutehtävää, mikä tyypillisesti edellyttää ohjeistusta ja työvälinekehitystä, kuten CAD-ohjelmistojen makropalettien käyttöä. Semanttisella mallinnuksella tavoitellaan tässä mm. tietojen viitattavuutta, koko suunnitteluratkaisun näkökulmasta johdonmukaista tietojen tyypitystä sekä edelleen yhdisteltävyyttä ja haettavuutta. Näitä voidaan loppukäyttäjille (esim. suunnittelija) näkyvien sovellusten tasolla hyödyntää esim. tietojen semanttisessa haussa ja ohjelmallisessa yhdistelyssä (ml. visualisointi ja simulointimallien aihioiden generointi), suunnittelutiedon ja prosessin validoinnissa (ml. tietojen viite-eheyden tarkistus ja puoliautomaattinen suunnittelutietojen arvoalueiden tarkistus) sekä suunnitteluprosessin kokonaiskuvan hahmottamisessa (ml. riippuvuuksien ja suunnitteluvaiheiden statustiedon esittäminen). Tuotantojärjestelmien tasolla tämä edellyttää paitsi (nykyisten) PDM-järjestelmien kehitystyötä (tuloksena "semanttinen PDM"), myös suunnitteluprosessien systemaattista hallintaa (toimintaohjeet ja työkulttuuri). Raportin rakenne on seuraava: Luvussa 2 kuvataan systems engineering mallin kehystämänä konejärjestelmän yhteistoiminnallisen ja semanttisesti rikastutetun suunnitteluprosessin käsitteet ja menetelmät. Luku 3 kuvaa tapaustutkimuksen mukaiset työkoneen puomijärjestelmään kiinnitetyt skenaariot (tapauspohjaiset tutkimuskäsikirjoitukset), joita hyödynnettiin konkreettisina semanttisen suunnitteluprosessin tapauksina. Valitut skenaariot liittyvät tuotetiedon (CAD/PDM-tiedon) linkityksen kehittämiseen, konejärjestelmän verkkosuunnitteluun (CANOpen)-, korjaus- ja muutospyyntöjen hallintaan, nimikkeiden linkitykseen sekä toimintokeskeiseen suunnitteluun. Näihin kaikkiin liittyy konejärjestelmän suunnittelu, virtuaalinen konelaboratorio sekä semanttisen mallinnuksen menetelmät. Tapausten avulla on mahdollista arvioida semanttisen mallinnusmenetelmän soveltuvuutta konejärjestelmien suunnittelun tukena. Luku 4 kuvaa semanttisen mallinnuksen menetelmien soveltamisesta teollisuudessa, koska menetelmät ja mallit ovat varsin uusia. Luku 5 vetää yhteen hankkeen tuloksia. Hankkeeseen liittyvät julkaisut sekä aihepiiriin liittyvä sanasto ja termit löytyvät raportin liitteinä (liitteet 1 ja 2). Tähän raporttiin johtanutta tutkimus- ja kehitystyötä tehtiin tutkimusryhmän toimesta yhdessä ja erikseen, aiheesta ja sen yksityiskohdista riippuen myös erilaisissa aliryhmäkokoonpanoissa. Työn linjauksista ja tuloksista keskusteltiin yhteisissä ohjausryhmäkokouksissa, työpajoissa, työryhmäkokouksissa sekä mm. opinnäytetöiden ohjauspalavereissa. Työn tuloksena syntyi konferenssijulkaisu, standardointiehdotus sekä diplomitöitä (jotka tätä kirjoittaessa ovat loppusuoralla). Koodinoidun työn ansiosta loppuraporttiin oli mahdollista poimia aineistoa myös projektin puitteissa tuotetusta materiaalista, "päällekkäisen" kirjoitustyön määrää samalla tehokkaasti vähentäen. Loppuraportti ja hankkeen tulosaineisto ovat saatavilla avoimesti tutkimusryhmän wiki-sivustolta. Tämä raportti ja sen kuvaus on sijoitettu omalle sivulle ( Hankkeen tapaustutkimukseen liittyvä puomin nosto -demonstraatio on myös kuvattu erikseen ( Myös hankkeeseen liittyviä materiaaleja ja työkaluja on koottu yhteen ( 7

9 2. SYSTEMS ENGINEERING MALLI KONEJÄRJESTELMÄN SEMANTTISESSA SUUNNITTELUPROSESSISSA 2.1. Konejärjestelmän suunnittelusta Termi mekatroniikka on otettiin 1980-luvulla käyttöön kuvaamaan järjestelmiä, joissa konetekninen mekanismi (meka) yhdistyy saumattomasti elektroniikkaan (troniikka). Tekniikan kehittyessä eteenpäin ja ohjelmistosisällön noustessa merkitsevämmäksi osaksi kuin elektroniikka, jossa ohjelmistoja käytettiin, alettiin puhumaan sulautetuista järjestelmistä ja myöhemmin kyber-fyysisistä järjestelmistä. Tekninen kehitys on tuonut uusia haasteita konejärjestelmien suunnitteluun koska itse konejärjestelmän suunnitteluprosessin rinnalle on täytynyt liittää myös ohjelmisto- ja elektroniikkajärjestelmien suunnitteluprosessit. Konejärjestelmien suunnittelun hallintaprosesseista tunnetuin on Verein Deutscher Ingenieure (VDI) järjestön tuottamana VDI 2221, joka on puhtaasti konejärjestelmien suunnitteluprosessin hallintaan keksittyvä standardi. Ilmailu- ja puolustusvälineteollisuudessa kehitetty ja myöhemmin autoteollisuudenkin käyttöönottama systems engineering lähestymistapa liitettiin myöhemmin mekatronisten järjestelmien suunnittelun hallintaan standardissa VDI Systems engineering lähestymisestä suunnitteluprosessin tai - projektin hallinnassa on myös muita standardeja ja standardin kaltaisia julkaisuja (esim. ISO/IEC 15288, ISO/IEC 26702, IEEE 1220). VDI on tuottanut myös mekatronisille järjestelmille standardin VDI 2422, joka antaa menetelmiä elektroniikkaa ja ohjelmistokomponentteja sisältävien järjestelmien suunnitteluun. Huomionarvoinen seikka, joka koskee kaikkia em. prosesseja, on että ne eivät ole varsinaisia konejärjestelmien suunnitteluprosesseja, jotka antaisivat selkeät mikrotason askelmerkit työnkululle, vaan ne ennemminkin ohjeistavat makrotasolla suunnittelu- ja tuotekehitysprosessin hallintaprosesseja Mekatronisen konejärjestelmän suunnitteluprosessi Yleisesti mekatronisten konejärjestelmien tuotekehityksessä on käytetty VDI 2221:n lähestymistapaa, joka jakautuu putouksena eteneviin tehtävänasetteluun, luonnosteluun, kehittämiseen ja viimeistelyyn. Malli kuitenkin hyvin harvoin toteutuu putouksenomaisena teollisuudessa vaan toteutuva suunnitteluprosessi on iteratiivinen. (Airila, 1999; Nurmi, 2013) 8

10 Kuva Semogen II -hankkeessa kehitetty semanttinen suunnitteluprosessimalli, jonka rakenne perustuu VDI 2221:een Tiedon ja mallien näkökulmasta suunnitteluprosessi etenee niin, että abstraktista ja luonnostason tiedosta edetään kohti konkreettista ja yksityiskohtaista suunnittelutietoa. Alussa on abstrakteja koneen ominaisuuksia - käyttötapaukset ja toiminnot - sekä luonnostason suunnitelmia, joita lähdetään tarkentamaan. Lopullinen konkreettisin ja yksityiskohtaisin lopputulos on rakennettu kone ja siihen liittyvä dokumentaatio (Lehtonen, Juuti, Oja, Suistoranta, Pulkkinen, Riitahuhta, 2011; Nurmi, 2013). Semanttisen suunnitteluprosessimallin ero muihin suunnittelun prosessimalleihin on että se on kehitetty nimenomaisesti mikrotason suunnittelu- ja tuotekehitysprosessin malliksi eikä suunnittelun hallintaprosessin malliksi. Semanttinen suunnitteluprosessi vie myös mallipohjaisen suunnittelun metodologian askeleen edelle muita prosessimalleja liittämällä kuhunkin prosessin askeleeseen tietyt käsitteelliset ja matemaattiset mallit. 9

11 Kuvassa on erilaisia malleja koneesta sijoitettuna niiden konkreettisuuden ja tarkkuuden mukaan. Suunnitteluprosessissa suunnittelutieto jalostuu kuvan vasemmasta ylänurkasta kohti oikeaa alanurkkaa. (Nurmi, 2013) Kuva Suunnitteluprosessissa syntyy erilaisia malleja suunniteltavasta koneesta. Suunnittelu etenee abstraktista konkreettiseen ja tarkempaan malliin koneesta. Kuvassa on erilaisia malleja koneesta sijoitettuna niiden konkreettisuuden ja tarkkuuden mukaan. Suunnitteluprosessissa suunnittelutieto jalostuu kuvan vasemmasta ylänurkasta kohti oikeaa alanurkkaa. (Nurmi, 2013) Kuvan mukaisesti voidaan VDI 2221:n vaiheet tehtävästä toimivaan koneeseen ajatella kulkevan vasemmasta ylänurkasta oikeaan alanurkkaa. Suunnittelutyössä lopputuloksena on dokumentaatio ja mallit lopullisen tuote- ja valmistusdokumentaation tasolla. (Ibid.) 2.2 Systems engineering ja yhteistoiminnallinen suunnittelu Systems engineering on standardoitu suunnittelun ja tuotekehityksen hallintaprosessi, joka tarjoaa järjestelmällisen lähestymistavan monimutkaisiin ongelmiin. Systems engineering koostuu kahdesta osaalueesta: 1. Tekninen osa-alue, jossa tapahtuu varsinainen suunnittelu ja tuotekehitys sekä 2. prosessin hallinta osa-alue. Kokonaisuudessaan systems engineering voidaan määritellä monitieteiseksi suunnittelun ja tuotekehityksen hallintaprosessiksi, jolla kehitetään verifioituja elinkaaren ja asiakasvaatimukset huomioivia järjestelmäratkaisuja. (Anon, 2001). Systems engineering prosessi voidaan jakaa kolmeen päätehtävään (kuva 2.2.1): Kehityksen vaiheistus, joka hallinnoi suunnitteluprosessia, tarjoaa lähtökohdat suunnittelutoimille ja ja toimii linkkinä teknisen hallintaprosessin ja hankintaprosessin välillä. Systems engineering prosessi, joka sisältää suunnittelun ongelmanratkaisun ja vaatimuksienhallinnan. Tarjoaa jäsennellyn, mutta joustavan prosessin, joka muuntaa vaatimusmäärittelyt suunnittelulähtökohtien kautta järjestelmäarkkitehtuuriksi ja ratkaisuiksi. Sen tehtävä on myös varmistaa asiakasvaatimusten täyttyminen ja vaatimusten jäljitettävyys. Elinkaaren hallintaprosessi, joka varmistaa että kehitettävät ratkaisut tyydyttävät asetetut vaatimukset kaikissa järjestelmän elinkaaren vaiheissa. Pyrkii huomioimaan monikäyttöisyysvaatimukset ja sitä kautta vähentämään tulevaisuuden uudelleen suunnittelu- ja uudelleen rakennustyön tarpeita. 10

12 Kuva Systems engineering prosessin osa-alueet (Anon, 2001) Suunnittelu- ja tuotekehitystyössä kuljetaan yleensä läpi tietyt vaiheet: Konseptitaso, missä kehitetään järjestelmäkonsepti Järjestelmätaso, missä kehitetään järjestelmä, joka täyttää suorituskykyvaatimukset Alijärjestelmä- ja komponenttitaso, jossa kehitetään järjestelmän osat ja komponentit Prosessi kulkee rekursiivisesti tuottaen jokaiselle tasolle omat lähtökohdat ja vaatimukset. Mitä syvemmällä järjestelmän teknisessä rakenteessa ollaan, sitä detaljoidumpia ovat myös lähtökohdat ja vaatimukset. Kuva esittää lähtökohtien ja vaatimusten väliset suhteet. Kuvasta nähdään myös prosessin etenemisperiaate: Minkään tason kehitystyötä ei viedä eteenpäin ennen kuin ylempien tasojen asettamat lähtökohdat ja vaatimukset ovat valmiita, muuttumattomia. Kuva Suunnittelulähtökohtien ja vaatimusten väliset suhteet (Anon, 2001) 11

13 Kuva osoittaa suunnittelutehtävän keskeisen haasteen erinomaisesti: Riippuvuuksistaan johtuen, käsitesuunnittelun, vaatimustenhallinnan ja eri tarkkuusasteilla tapahtuvan suunnittelun aito iterointi on huomattavan vaikeaa. Semogen2-hankkeen näkökulmasta ratkaisun siemen löytyy Systems engineering - ajattelun laajentamisesta (semanttisen) informaatioarkkitehtuurin vaatimuksilla ja tehtävillä. Tämä ei tietenkään poista joustavan suunnittelu haasteisiin lähtökohtaisesti vaikuttavia riippuvuuksia sinänsä. Se kuitenkin tarjoaa menetelmän riippuvuuksien systemaattiseen kuvaamisen ja ymmärtämiseen osana suunnittelua sekä osoittaa keinon kehittää konkreettisia välineitä käytännön neuvottelu- ja suunnittelutehtävien tueksi. Systems engineering -prosessi on kokonaisvaltainen iteratiivinen ja rekursiivinen top-down ongelmanratkaisuprosessi, joka: muuntaa tarpeet ja vaatimukset järjestelmä- ja prosessikuvauksiksi, tuottaa päätöksenteontuki informaation, sekä tuottaa lähtökohdat seuraaville prosessiaskeleille Kuvassa näytetään systems engineering -prosessin perusaskeleet. Nämä askeleet ovat: 1) vaatimusten analysointi, 2) toiminnan analysointi ja kohdentaminen, sekä 3) synteesi. Perusaskeleita tuetaan järjestelmäanalyysityömenetelmillä sekä verifikaatiolla, joka mahdollistaa järjestelmätason iteraation. Kuva Systems engineering -prosessin askeleet (Anon, 2001) Systems engineering -prosessissa järjestelmälle kehitetään erilaisia arkkitehtuureja, jotka kuvaavat järjestelmän ja sen alijärjestelmien toimintaa tai rakennetta korkeammilla abstraktiotasoilla. Arkkitehtuurit jaetaan usein esimerkiksi toiminnalliseen, fyysiseen ja järjestelmäarkkitehtuuriin. Toiminnallinen arkkitehtuuri kuvaa toiminnalliset ja suorituskykyvaatimukset. Fyysinen arkkitehtuuri kuvaa järjestelmärakenteen jaettuna osiin ja alijärjestelmiin. Järjestelmäarkkitehtuuri kuvaa tuotteet, jotka tarvitaan tukemaan järjestelmää sisältäen prosessit ja järjestelmät, jotka tarvitaan kehittämiseen, tuotantoon, käyttöönottoon, käyttöön, tukeen ja käytöstä poistamiseen. Elinkaarenhallintaprosessi tulee ottaa huomioon kehitysprosessin aikana. Kuvassa on esitetty keskeisimmät järjestelmän elinkaareen liittyvät osa-alueet. Ne ovat: kehittäminen, valmistus/tuotanto, 12

14 käyttöönotto, käyttö, tuki, käytöstä poisto, koulutus ja verifiointi. Nämä osa-alueet kattavat koko elinkaaren kehdosta hautaan ja ne korostavat järjestelmän käytön ja käyttäjän tarpeita, mikä on oleellista nimenomaan elinkaarenhallinnan näkökulmasta Suunnittelumalleja Kuva Elinkaaren hallinnan osa-alueet (Anon, 2001) Luvussa esitellään lyhyesti käsitteet bottom-up, top-down ja iterointi, jotka esiintyvät monissa suunnittelumalleissa. Nämä ovat siten myös keskeisiä käsitteitä semanttisessa suunnitteluprosessissa. Informaatiota voidaan prosessoida hahmottomalla kokonaisuus yläkäsitemallista kohti yksityiskohtaisempia alakäsitemalleja tai sitten lähtemällä alikäsitemalleista ja etenemällä kohti yläkäsitemallia. Top-down (ylhäältä alas) ja bottom-up (alhaalta ylös) lähestymistavoilla tarkoitetaan vaihtoehtoisia tapoja hahmottaa konejärjestelmää. (Nurmi, 2013) Iteroinnilla taas tarkoitetaan konejärjestelmän suunnitteluratkaisujen testaamista koko suunnittelun ajan sekä mahdollisuutta palata suunnittelemaan uudelleen jo tehtyä työtä. Tällöin voidaan varmistaa valittujen suunnitteluratkaisujen vievän suunnittelua oikeaan suuntaan. Koska mekatronisessa suunnittelussa usein lukitaan suunnittelun varhaisessa vaiheessa tiettyjä teknologiavalintoja ja jaetaan suunnittelu näiden teknologiavalintojen mukaan, niin tämän seurauksena suunnitteluprosessissa on rajoitetut mahdollisuudet parannella varhaisia suunnitteluvalintoja. Lisäksi on tunnistettu mahdollisuus parantaa tätä tilannetta luomalla moniteknistä konejärjestelmää varten teorioita, malleja ja työkaluja, jotka hallitsevat mallinnuksen, analysoinnin, yhdistämisen, simuloinnin ja prototypoinnin. Toivottava lopputulos olisi sellainen kehitysstrategia, joka olisi hahmotettavissa suunnittelun konseption ja yläkäsitteiden avulla. (Ibid.) Tutkimuksen kannalta on mielekästä testata, miten Semogen-hankkeen semanttisella suunnitteluprosessilla voitaisiin vastata näihin tunnistettuihin tarpeisiin. Toisaalta yhteissuunnittelu vaatii tietoja yhdisteleviä ylätason malleja, jotka pitää tuottaa myös koneluettavaan muotoon, koska tällaisten ylätason mallien avulla suunnittelutieto yhdistyy myös ohjelmistoja varten. (Ibid.) 13

15 2.4. Semanttinen mallinnus ja linkitetty data suunnitteluinformaation integroinnissa Semanttisuus on semanttisen webin teknologioiden näkökulmasta tiedon merkityksen kuvailua koneluettavaksi. Tiedon semanttinen mallinnus pyrkii mallintamaan tiedon linkitetysti, koneluettavasti ja formaalisti. Keskeinen päämäärä tiedon semanttiselle mallinnukselle on tuottaa loppukäyttäjälle älykkäämpiä ja parempia sovelluksia, jotka ratkaisevat käyttäjän ongelmia entistä paremmin (Allemang, 2008). Älykkäästi toimivasta ohjelmasta esimerkkinä voidaan käyttää esimerkiksi internetin hakukonetta, joka antaa hyvin intuitiivisia vastauksia käyttäjän tekemän haun perusteella suuresta tulkitusta tietomassasta. Semogenhankkeessa vastaavasti koneen tuotantomenetelmiä kehitetään lisäämällä suunnittelutiedon koneluettavuutta semanttisella mallinnuksella, jolloin saadaan konejärjestelmän yhtenäinen ja linkittynyt kokonaismalli, johon älykäs virtuaalinen konelaboratorio pohjautuu (Ranta, 2011). Itse teknistä suunnitteluprosessia voidaan helpottaa suuresti semanttisen mallinnuksen keinoin ja automatisoida tietokoneelle esimerkiksi ihmiselle työläs suunnittelutiedon eheyden tarkastelu (Nykänen, 2011). Suunnittelutiedon tallennus yhtenäiseen muotoon on hankala ongelma, koska eri ohjelmistojen valmistajilla ei ole liiketoiminnan näkökulmasta tarvetta tarjota yhtenäisiä ohjelmistorajapintoja tai tallennusformaatteja. Lisäksi tiedon mallinnustavasta sopiminen on hyvin haastava ongelma. (Nurmi, 2013) Semogen II -hankkeessa on myös tutkittu ja testattu erästä yksinkertaista tapaa lähteä ratkaisemaan suunnittelutietojen julkaisun, hallinnan, löytämisen ja yhdistelynongelmaa. Lähestymistapana on ollut mallintaa ja julkaista aivan suunnittelun keskeisin komponentti-, laite- tai järjestelmätiedon sisältävä datalehtitieto koneluettavasti. Datalehtien tietoa käytetään suunnittelussa tiedonvaihtoon suunnittelijoiden ja muiden prosessin jäsenten välillä. Tieto on kuitenkin yleensä tallennettu lähinnä tulostusta ja katselua varten PDF-tiedostoihin. Ratkaisuna on ollut tarjota datalehden sisältämä tieto myös siten, että tietokoneohjelmat voivat hyödyntää mahdollisimman hyvin datalehden sisältämän tiedon. (Ibid.) Linkitetyllä datalla (linked data, myös: yhdistetty tieto tai linkitetty tieto) tarkoitetaan rakenteisen tiedon julkaisemiseen ja ristiinviittauksiin liittyvien hyvien käytänteiden joukkoa. Palvelut, jotka yhdessä noudattavat näitä käytänteitä osallistuvat siten globaalin data-avaruuden, datan webin (web of data) rakentamiseen. Erityisesti linkitetty data tarjoaa puitteet, joilla webiin voidaan luoda tyypitettyjä linkkejä eri lähteistä tulevien tietoyksiköiden välille. Esimerkiksi eri organisaatioiden ylläpitämien tietokantojen tietoja voidaan liittää yhteen yhdistetyn tiedon käytännöin. Teknisestä näkökulmasta yhdistetyn tiedon katsotaan olevan tietoa koneluettavassa muodossa. (Bizer, Heath, Berners-Lee, 2009). Berners-Lee on esitellyt linkitetyn datan periaatteiksi seuraavat (Berners-Lee, 2009): URI 1 -tunnisteita käytetään asioiden nimeämiseen HTTP URI -tunnisteita käytetään siten, että nimien viittaama tieto on noudettavissa Kun URI-tunnisteen mukainen resurssi noudetaan, informaatio tulee tarjoa käyttäen standardeja (RDF 2, SPARQL 3 ) 1 URI (Uniform Resource Identifier). Tietyn resurssin (tiedosto, tieto, lausuma) yksikäsitteinen tunniste. 2 RDF (Resource Description Framework) on W3C:n standardoima kuvailukieli tiedon vaihtoon sovellusten välillä 3 SPARQL (SPARQL Protocol and RDF Query Language) on RDF:ksi mallinnetulle tiedolle tarkoitetu kyselykieli (vrt. SQL-kyselykieli relaatiotietokannoissa) 14

16 Mukaan on syytä sisällyttää linkkejä muihin URI-tunnisteisiin, jotta lisää aiheeseen liittyvää tietoa voidaan löytää Nämä periaatteet tarjoavat perussäännöt linkitetyn tiedon julkaisulle ja yhdistelylle webinfrastruktuurissa. Linkitetyn datan periaatteiden soveltaminen suunnittelutiedon ja nimikkeiden hallinnassa mahdollistaa alustariippumattoman suunnitteluinformaation hallinnan ja integroinnin. Käyttämällä suunnittelunimikkeiden yksilöintiin URI-tunnisteita voidaan nimikkeisiin viitata yksikäsitteisesti myös muista kuin niitä hallinnoivasta järjestelmästä käsin. Toteuttamalla nimikkeiden- ja suunnittelutiedon hallintajärjestelmiin URI-tunnisteita vastaavat HTTP-liitynnät pidetään lisäksi huoli siitä, että ajantasainen, nimikettä tai resurssia vastaava metatieto, on aina ulkoisten järjestelmin noudettavissa. Jos informaatio lisäksi tarjotaan tunnettuja standardeja käyttäen esim. RDF-muodossa tai SPARQL-rajapinnan kautta, voidaan pitää huoli siitä, että rajapintoihin liittyminen on teknisesti vaivatonta ja kustannustehokasta erityisesti sovelluskohtaisten räätälöintien ja erityyppisten data-adapterien kehityksen tarve vähenee. URI-tunnisteiden käyttö laajalti nimikkeiden ja yleisesti eri suunnitteluresurssien nimeämiseen tarjoaa mahdollisuuden myös tunnisteiden välisiä yhteyksiä kuvaavien linkkien ja metatietojen koodaamiseen. Kuva Suunnitteluinformaation jäsennys ja yhdistyvyys linkitetyn datan mallilla semanttisissa PDM/PLM-järjestelmissä 15

17 Kuvassa esitetään arkkitehtuuritason esimerkki linkitettyä dataa soveltavan nimikkeiden- ja tuotteiden elinkaaritiedon hallintajärjestelmistä (Semanttiset PDM/PLM-järjestelmät) sekä niiden välisestä informaation integroinnista. Esimerkkitilanteessa kaksi erillistä toimijaa ylläpitävät omia tuotetietojärjestelmiään. Käytännön suunnittelutyöhön ja -tiedon hallintaan käytetään toimialakohtaisia sovelluksia (yrityskohtaiset hydrauliikka-, sähkö-, mekaniikka-, ja verkkosuunnittelusovellukset). Tuotetiedonhallintajärjestelmä kerää yhteen toimialakohtaisilla sovelluksilla toteutettua suunnittelutietoa ja tarjoaa nimike- ja tuotetiedonhallintaan liittyvät yleiset hallintajärjestelmät. Esimerkin semanttisista tuotetiedon hallintajärjestelmistä suunnitteluinformaatio voidaan edelleen julkaista yhdistetyn tiedon mukaisesti RDF-formaatissa, joka kuvaa kunkin järjestelmän osalta linkittyneenä, semanttisena mallina sinne toteutetut suunnittelutiedot. Kuvan esimerkissä on esitetty molempiin järjestelmiin yksinkertaiset kolmeosaiset kokoonpanot (kahdesta pääkomponentista koostuva Pora, sekä puomista ja ohjausjärjestelmästä koostuva Puomilaite). Molempien kokoonpanojen osalta on kuvattu niiden hierarkkinen rakenne. Huomionarvioista on myös, että sovellettaessa RDF-kuvailukieltä osana yhdistettyä tietorakennetta voidaan rakennekuvauksesta tehdä rikas ja tyypitetty. Tässä tapauksessa hierarkkinen rakenne on kuvattu kokoonpanotermein (esimerkiksi Puomi on osa kokoonpanoa nimeltä Puomilaite), mutta myös muita tyypitettyä viittauksia rakenteiden välille voidaan vapaasta muodostaa. Esimerkiksi järjestelmän toiminnallinen rakenne voidaan kuvata hierarkkisen rakenteen rinnalle. Yhdistetyn tiedon mukainen tiedon mallinnus sallii viittauksien kuvaamisen myös järjestelmien välillä. Nimike- ja tuotetietorakenteiden ei tarvitse rajoittua ainoastaan yhden toimijan järjestelmään, vaan myös muiden toimijoiden kuvaamiin resursseihin voidaan viitata. Kuvan esimerkissä Pora on liitetty osaksi toisessa järjestelmässä kuvattua Puomia, jolloin niiden yhdessä kuvaama tietomalli muodostaa yhden, hajautetusti järjestelmien välille jäsennetyn kokoonpanon. Tilanne voisi kuvata esimerkiksi tapausta, jossa puomilaitteen valmistaja on alihankkinut poran suunnittelun. Kuva Suunnitteluinformaation jakautuminen tietomallissa eri organisaatioiden hallinnoimiin nimiavaruuksiin Yhdistetyn tiedon tietomalli mahdollistaa suunnittelutiedon pilkkomisen nimiavaruuksia hyödyntämällä myös useammille tasoille. Edellä kuvattua suunnittelutapausta jatkaen, esimerkiksi poralaitteen käyttämään sylinteriin voitaisiin linkittää tieto käytetyn sylinterin mallista ja viittaus sen tarkempiin tietoihin sylinterin valmistajalta tai komponenttitoimittajalta (kts. kuva 2.4.2). Kuvassa sylinterin tarkka komponenttidata voisi antaa rakenteellisessa mielessä tietoa esimerkiksi sylinterin tarkasta kokoonpanorakenteesta (koostuu osista Mäntä ja Putki). Vastaavalla nimeämisellä suunnitteluinformaatiota voidaan liittää osaksi myös muuta tietoa. Nimiketietoa voidaan rikastaa esimerkiksi liittämällä niihin luokittelu- ja tyyppitietoa sekä standardeja sekä 16

18 niiden kautta tunnettuja ominaisuuksia. Komponentteihin voitaisiin liittää myös esim. mittatietoja tai muita teknisiä ominaisuuksia, kuten ominaisarvokäyriä tai simulointimalleja. Tuloksena syntyy nimike- ja viitetunnustietoa huomattavasti rikkaampi järjestelmämalli, joka mahdollistaa uusien käyttötapauksien toteuttamisen. Näitä käyttötapauksia on pohdittu tarkemmin luvuissa 3.2 ja Virtuaaliympäristöt suunnittelun tukena Virtuaalinen konelaboratorio (VML, Virtual Machine Laboratory) on konejärjestelmän simulointia, diagnostiikkaa, dokumentaatiota, toimintoja ja laitteen rakennetta visualisoiva ohjelmisto. Sitä voidaan hyödyntää konejärjestelmien opetuksessa, yhteistoiminnallisessa suunnittelussa, kehityksessä ja prototypoinneissa. Matemaattisiin malleihin perustava reaaliaikasimulaatio ohjaa laitteen vuorovaikutusta ja realistista käyttäytymistä käyttötarkoituksen mukaisesti. TTY:n Smart Simulators-tutkimusryhmä on rakentanut useita virtuaalisia konelaboratorioita sekä koulutusettä tutkimuskäyttöön (Palonen et al., 2007; Helminen et al., 2011; Salonen et al., 2011; Ranta et al., 2012). Kaupallisista tuotteista esimerkiksi Dassault Group:n rakentaman Dassault Systems järjestelmän voidaan katsoa toteuttavan VML:n ominaisuuksia. Dassault Systemes on tuotteen elinkaaren hallintajärjestelmä, jonka avulla voidaan tarkastella konelaitteen koko elinkaarta virtuaaliympäristössä. Dassault systems tarjoaa 3D-näkymiä esimerkiksi suunnittelun, tuotannon, markkinoinnin, huollon ja lopulta laitteen kierrätyksen tarpeisiin Asiantuntijahaastattelu Ennen kuin Semogen II -hankkeessa ryhdyttiin toteuttamaan käyttötapauskohtaista VML-näkymiä demonstraatiokartoituksiin, tehtiin kartoitus siitä, millainen suunnittelua tukeva virtuaalinen konelaboratorio oikeastaan kuuluisi olla. Vaatimusten ja käyttötapausten selvitys on keskeinen peruslähtökohta jokaiselle ohjelmistoprojektille. Vaikka VML-näkymät ohjelmoidaan pääasiassa tutkimusryhmän tutkimuskäyttöön eikä niinkään tuotteeksi, silti oikeiden tunnistettujen käyttötapausten toteuttaminen, sekä ylipäätään vaatimusten listaaminen luo kehykset ja konkretiaa hankkeessa tehtävälle tutkimukselle. Hankkeessa VML:n ominaisuuksien kehittäminen on osa iteratiivisen top-down suunnitteluprosessin tukemista. (Nurmi, 2013) VML:n vaatimuksien kartoittamiseksi käytetään tutkimusmenetelmänä kyselylomaketta ja sen kvantifiointia. Kyselyn toteutus perustuu kvalitatiivisten tutkimusmenetelmien ja kvantifioinnin metodeihin. Kyselylomakkeella kerätään palautetta ehdotettuihin mahdollisiin käyttötapauksiin sekä uusia ideoita ja käyttötapauksia. Saadut vastaukset litteroidaan ja kvantifioidaan. Tässä litteroinnilla tarkoitetaan vastaajien tuottamien vastausten kirjoittamista puhtaaksi sähköiseen muotoon. Työpajoissa pohjustetaan keskustelua VML:stä yleisinformaatiota antavalla esityksellä ja samalla rajattiin keskustelua VML:stä koneensuunnittelun alueelle. (Ibid.) Analysoitujen kyselyissä ideoitujen käyttötapausten perusteella on mahdollista tehdä johtopäätöksiä siitä, millainen on VML suunnittelun tukena, mitä tietoja se vaatii, ja mitkä VML:n yleisistä ominaisuuksista ovat keskeisiä suunnittelun tukena toimivalle VML-ohjelmistolle. (Ibid.) Keskeisimmät johtopäätökset ovat: VML:n keskeisin tarkoitus on kommunikoinnin ja projektin koordinoinnin avustaminen. Suurin osa kyselyissä ideoiduista käyttötapauksista vaatii konkreettista ja tarkkaa suunnittelutietoa, joka vastaa todellista konetta. Erityisesti vaaditaan yhteistoiminnallisia näkymiä ja suunnitteluaineiston onnistunutta visualisointia. 17

19 Suurin ongelma suunnittelussa, jota tulisi ratkoa VML-ohjelmistolla, on tiedonsiirtämisessä ihmiseltä toiselle. Eri työtehtävissä olevat ihmiset haluavat nähdä toimialojaan yhdistäviä näkymiä. Mittausten tekeminen ja simulaation hallinta (hidastus tai toisto) on toissijaista. Noin puolet käyttötapauksista edellyttää dynaamista reaaliaikasimulaatiota tai ohjauskontrolleja laitteeseen. Toisaalta noin puolet käyttötapauksista on mahdollisia toteuttaa VML:ään ilman ohjattavaa liikkuvaa laitetta eli myös ilman simulointia. Useat käyttötapaukset vaativat sellaisen tiedon tuottamista, jota ei tällä hetkellä kirjata ylös. (Ibid.) VML:llä voidaan parantaa suunnitteluprosessia luomalla mekatronisen laitteen teknologiarajat ylittäviä myös abstraktia ja luonnostason suunnittelutietoa hyödyntäviä näkymiä. Tällöin voidaan auttaa teollisuutta saavuttamaan tahtotila hallita suunnittelutietämystä näiltäkin osa-alueilta. Lopulta suunnittelun kulttuuri, työvälineet ja prosessi omaksuvat tämän kokonaisvaltaisuuden. (Ibid.) Pitää huomioida, että tällä hetkellä suunnittelussa ei kuvailla tietoa abstrakteilla käsitteillä suunnitteluohjelmissa. Tällaisen tiedon kuvailu saattaa olla vieras ajatus. Kuitenkin teollisuuskumppanit korostivat työpajoissa tarvetta tunnistaa ja toteuttaa kokonaisia käyttötapauksia. He olivat myös yhtä mieltä siitä, että prosessin hallintaan vaaditaan kokonaisvaltaisempia malleja - kuten teknologiarajat ylittäviä toimintoketjukuvauksia - suunnittelualueiden lokeroimisen sijaan. (Ibid.) Esimerkiksi yhdyskuntasuunnitteluun verrattuna mekatronisesta suunnittelusta puuttuu yhteisen toimivan kokonaisuuden suunnittelunäkymä ja sen malli, jonka ympärillä yhteissuunnittelun tulisi tapahtua. Siksi tutkimusprototyypissä keskitytään ratkaisemaan yhteissuunnittelun vaatiman yhteisen työpöydän tarve, jossa tieto näytetään kaikille yhdessä samalla tavalla. Lisäksi pyritään löytämään tapoja suunnitella ja tarkastella suunnittelutyön tuloksia yhdessä vaatimusten sekä toimintojen toteutumisen näkökulmasta. (Ibid.) Tutkimusprototyypin halutaan avustavan yhteissuunnittelua hallitsemaan paremmin oikeiden suunnittelukysymysten muodostaminen, yksittäisten suunnitteluratkaisujen mielekäs yhdistyminen kokonaisuuden saavuttamiseksi, suunnittelutiedon näkyväksi tuonti, jatkuvasti käytävä keskustelu suunnittelun seuraavista askelista ja yhteisen toimivan kokonaisuuden suunnittelun ylläpito. (Ibid.) 2.5. Vaatimukset skenaarioille Mekatronisessa suunnittelussa tietokoneavusteinen suunnittelu eli CAD (englanniksi computer-aided design) tapahtuu pääosin teknologia-aloittain eri suunnitteluohjelmilla. Esimerkiksi seuraavien teknologia-alojen CAD-ohjelmat toimivat erillään toisistaan: mekaniikkasuunnittelu, sähkösuunnittelu ja hydrauliikkasuunnittelu. Ikävä kyllä CAD-ohjelmistot eivät tue suunnittelutiedon siirtämistä suunnittelijalta toiselle tietokoneavusteisesti. Näin ollen suunnittelutieto siiloutuu eri suunnittelun osa-alueiden sisälle jo ohjelmistojen tasolla. (Nurmi, 2013) Tuotetiedon hallintaohjelmistot eli PDM-ohjelmistot (englanniksi product data management) yrittävät ratkaista mekatronisen suunnittelutiedon hallinnan ongelmia. Eri suunnitteluohjelmat tallentavat tuotetun suunnittelutiedon dokumentteina PDM-järjestelmään. PDM-järjestelmissä on tiettyä suunnitteluprosessia varten suunnitellut paikat tiedostoille ja mahdollisuus lisätä metatietoja tiedoston lisäämisen lisäksi. Näin tiedolle voidaan tuottaa erilaisia näkymiä ja hakuja esimerkiksi käyttäjien käyttöoikeuksien mukaan. Tiedostoille on käytössä luokitteluita, joiden mukaan tiedostot lisätään ja esitetään. Tiedostoja voi muokata, joten työnkulkua voidaan tarkastella ja suunnitella PDM:ssä. Yhteissuunnittelun kannalta PDM tarjoaa yhteisen paikan suunnittelutiedostojen tallennukseen ja tarkasteluun. (Ibid.) 18

20 Kuitenkin PDM-järjestelmät hallitsevat karkeasti ottaen tiedostotasolla tuotetiedonhallintaa. Ne kertovat eri tiedostojen luokituksia ja suhteita toisiinsa sekä hyödyntävät tiedostojen mukana lisättyä metatietoa. Varsinainen täsmällinen suunnittelutieto on kuitenkin tiedostojen sisällä. Jotta VML voi hyödyntää täsmällistä suunnittelutietoa (esimerkiksi komponentti kaaviossa), täytyy suunnittelutieto mallintaa sekä hallita luokitellusta ja linkitetysti muodossa metatietoineen. (Ibid.) On myös tärkeää tiedostaa, että varsinaisten mekatronisen suunnittelun tietokoneavusteisten työvälineiden lisäksi yrityksissä on usein käytössä muita yleisiä suunnittelua avustavia tietokoneohjelmia, kuten sähköposti, tikettijärjestelmä, wiki ja pikaviestimiä. Näitä välineitä ei kuitenkaan käytetä tuottamaan sellaista suunnittelutietoa, jota voitaisiin liittää osaksi muuta suunnitteludokumentaatiota. Koska tämän tieto on usein myös oleellista suunnittelussa, tutkimusprototyypissä pyritään liittämään VML-järjestelmään myös sellaisten suunnittelua tukevien tietokoneohjelmien tietoa, joiden tietoa ei tällä hetkellä liitetä PDM-järjestelmiin. (Ibid.) 19

21 3. KONEJÄRJESTELMÄN SUUNNITTELU SEMANTTISENMALLINNUKSEN MENETELMIEN TUELLA Hankkeen tutkimusmenetelmänä käytettiin tapaustutkimusta, jossa hyödynnettiin aitoja kallioporauslaitteen suunnitteluaineistoja ja suunnitteluohjelmistoja (mekaniikka, CAN-väylä, hydrauliikka, viitetunnuslista, tuotetieto). Tapaus rajautui puomin nosto-teknologioihin. Näiden ympärille rakennettiin putkilinjasto, jossa sovittimien ja rikastusvaiheiden avulla saatiin suunnittelutieto virtaamaan kokonaismalliksi. Lisäksi luonnollista suunnitteluprosessia mallinnettiin asiantuntijayhteistyönä. Näin suunnitteluprosessiin voidaan implementoida semanttisen mallinnuksen vaiheita, jonka tavoitteena on määrittää semanttinen prosessi. Kuva 3.1. Semogen II hankkeen visiokuva, jossa keskeisenä kehyksenä toimii systems engineering mallin mukainen konejärjestelmätuotteen vaiheistettu suunnitteluprosessi. Tähän linkittyy mallipohjainen suunnitteluprosessi käsitteellisen (semanttisen) että fysikaalisen (matemaattinen) mallinnuksen menetelmin. Prosesseja tuetaan datalähtöisen semanttisen tuotetiedon hallintaratkaisujen (formaali, linkittynyt, koneluettava tieto), automatisoitujen tiedonkäsittelyratkaisujen (semanttinen prosessori) sekä yhteistoiminnallisten asianhallintaratkaisujen ja virtuaalisen konelaboratorion avulla. Suunnittelutiimillä on näin ajantasainen ja todelliseen suunnittelutietoon perustuva tieto käytössään. Kuva 3.1. esittää Semogen II -hankkeen vision: Systeemisuunnittelun vaiheiden tukena on tuote- ja suunnittelutiedon tasolla kytkettyjä, eritasoisia semanttisia malleja, mallipohjaisen suunnittelun hengessä. Tietovarastona toimii semanttinen PDM, mikä mahdollistaa virtuaalisten konelaboratorioiden puoliautomaattisen generoinnin, informaation ja työvaiheiden validoinnin, tietojen haun, tiedon projisoinnin sekä suunnitteluartefaktien simuloinnin. Moniteknisellä suunnittelutiimillä on näin ajantasainen ja todelliseen suunnittelutietoon perustuva tieto käytössään. Vision kirkastaminen ja tapaustutkimuksen suuntaaminen perustuivat työpajoihin, joita järjestettiin seuraavasti: 20

22 Yhteinen työpaja (Vertex): PDM-koulutus ja tuotetietopäivät Yhteinen työpaja (Sandvik): Tapaustutkimuksen aineisto Yhteinen työpaja (Etteplan): Tuotteen elinkaarenhallinta ja jälkimarkkinointi Yhteinen työapaja (TTY): Konejärjestelmän semanttinen suunnitteluprosessi AEL-työpaja. Visio, konkreettiset tavoitteet ja käyttötapaukset Etteplan-työpaja: Visio, konkreettiset tavoitteet ja käyttötapaukset Sandvik-työpaja: Visio, konkreettiset tavoitteet ja käyttötapaukset Vertex-työpaja: Visio, konkreettiset tavoitteet ja käyttötapaukset Cargotec-työpaja: Visio, konkreettiset tavoitteet ja käyttötapaukset Yhteinen työpaja (Sandvik):Suunnittelun toimintaprosessit, moniteknisen suunnitteluinformaation prosessointi, yhteissuunnittelun tukeminen Yhteisten työpajojen ohella järjestettiin siis myös kumppanikohtaisia työpajavierailuja. Nämä osoittautuivat erittäin hedelmällisiksi ja tarjosivat mahdollisuuden keskustella työn osa-alueista melko yksityiskohtaisesti. Toimialueen tasolla tarkasteltuna, työpajavierailuissa todettiin suunnitteluprosesseihin liittyen mm. seuraavaa: 1. Iteratiivinen suunnitteluprosessi koettiin toimivana. Vaatimusmäärittely ja etenkin sketsausvaihe jää usein dokumentoimatta. Sketsaukset toteutetaan vihkoihin, tekstinkäsittelydokumentteihin ja palaverimuistioihin hyvin yleisellä tasolla. Esim. puolustusvälineteollisuudessa on vaatimustenhallintaratkaisuja, jotka juoksevat prosessin mukana. 2. Ohjelmistosuunnittelussa vaatimukset ovat usein paremmin huomioituna. Miten saadaan yhtenäinen toimintatapa eri teknologia-alueiden suunnitteluun? Usein ei tiedetä mihin vaatimukseen suunnitteluratkaisu perustuu. Lisäksi vaatimuksia tulkitaan insinöörimäisesti, että miten tämä vaikuttaa kehitettävään ja olemassa olevaan omaan tekniseen ratkaisuun. Laajempaa, syvällisempää ja yhteisvaikutuksia kartoittavaan tapaan ei usein pyritä. Tämä aiheuttaa ongelmia, kun halutaan palata jonkin ratkaisun taustalle. 3. Suunnitteluratkaisujen perusteet jäävät usein kirjaamatta tai ainakaan ne eivät ole koneluettavassa muodossa. Käsitesuunnittelun välineitä ei ole oikein olemassa. Issue track ja backlog -ratkaisut ovat saaneet positiivisen vastaanoton ja ns. Kanban -lähestymistä on hyödynnetty. Haasteena on toimintakulttuurin muutos. Miten suunnittelijat motivoidaan tuottamaan informaatiota? 4. Informaation prosessointi on aito ongelma, koska tuotetietoa on paljon. Tuotteiden elinkaaren hallinta on iso haaste. Asiakkaalle on toimitettu jälkikäteen optioita ja rakennettu yksilökohtaisia sovellutuksia, jolloin kokonaisuuden hallinta on iso haaste. Vanhojen laitteiden hallinta on vaikeaa, koska tuoteinformaatiota puuttuu. 5. Yksilöiden ja yksiköiden välillä on isoja eroja. Toiset mieltävät informaation hallinnan keskeiseksi osaksi oman työn helpotusta esimerkiksi dokumentoimalla suunnitteluratkaisuja ja perusteita oman työn tukena. Muisti ei riitä asioiden hallintaan. Suunnittelulta odotetaan ketteryyttä ja keskittymistä olennaiseen. Välineiden pitää olla todella helppokäyttöisiä, jotta suunnittelija voi keskittyä ydinasiaan. Tiedon uudelleen käytettävyys toimii vahvana periaatteena. 6. Aikaisempia suunnitteluratkaisuja modifioimalla on saatu aikaan uusia ratkaisuja. Vanha laite toimii kollektiivisena muistina. Tämä on toisaalta iso haastekin, koska semanttisen mallinnuksen kannalta 21

23 iso osa informaatiota puuttuu. Näin tiedon uudelleen käyttö koneellisessa muodossa on usein haasteellista. Mikään väline ei voi tuottaa puuttuvaa sisältöä. 7. Informaation puutteista ja käsiteltävyysongelmista aiheutuu merkittävää informaation uudelleen tuottamista ja haasteita tuotetiedon hallinnassa. Suunnitteluohjelmistojen valmistajalla ja suunnittelutoimistolla on selkeä suunta kehittää ratkaisuja koneluettavuutta kohti. Myös tietojen hyvä linkitys on oleellista. Näin informaatio ei henkilöidy, vaan se on prosessina hallittavissa. 8. Uuden toimintatavan jalkautus vaatii koulutusta. "Hyvä konejärjestelmän suunnittelumenetelmä". Lähestymistapana tulee olla konkreettisuus ja toiminnallisuus. Perusasioista lähtien tulee edetä, koska esimerkiksi tuotetiedon hallinta ei ole välttämättä riittävästi ymmärretty. 9. Kohderyhmä ovat suunnittelijat. Toinen kohderyhmä ovat asentajat, jotka voivat tuottaa elinkaaritietoa sekä ymmärtää tuotetiedon merkitys. Suunnitteluprosessi vaikuttaa saksalaiselta mallilta, jossa on paljon henkilöitä vastaamassa tietystä alueesta. Miten päästäisiin lean-pohjaiseen tapaan? Miten saataisiin ketteryyttä lisää. Isot projektimallit eivät ole tätä päivää. 10. Suunnitteluprosessi vaikuttaa myös johtamistapaan. Nykyään tarkastelu keskittyy pääosin kehittelyyn ja suunnitteluun. Vaatimukset ja sketsaus eivät kuulu tarkasteluihin. - Vaatimusten määritys on olennainen. Pitäisi olla mukana sekä toiminnallinen että rakennetieto. - Työnkierron (vaiheiden) merkitys on tärkeää. - Suunnittelija ei aina tiedä mitä PDM:ään tulisi laittaa. Ei tiedetä mihin oman suunnittelutyön tuloksia tullaan myöhemmin käyttämään. Vastaavasti teemasta linkitetty semanttinen tieto esitettiin mm. seuraavia havaintoja: 1. Linkitetty tieto ISO-standardin mukaisesta sanastosta, semanttinen mallinnus toimialan ontologiasta, näiden yhteys tuotetietoon (nimike) ja nimikkeen rikastaminen semanttisen datalehden avulla sekä viitetunnusinformaatio koettiin merkityksellisenä. Linkitetyn tiedon hallinta edellyttäisi erityisesti sisällön tuottamisen muutosta. Usein informaatio esim. komponenttivalmistajalla on suljetussa muodossa, jolloin informaation uudelleen käytettävyys on todella haastavaa. Voi vain kuvitella kuinka paljon huolto- ja kunnossapitoprosessit kehittyisivät, jos organisaatiolla olisi yhtenäiseen linkitettyyn tietoon perustuvat toimintamallit. Suurena ongelmana on tiedon henkilöityminen, koska tietoa joudutaan kysymään liikaa avainhenkilöiltä, ja jos henkilö vaihtuu paljon tietoa häviää. 2. Semanttinen datalehti avaisi mahdollisuuden uudenkaltaiseen liiketoimintaan, jossa alihankkijat ja toimittajat tarjoaisivat koneellisesti käsiteltävän informaation suunnittelijoiden ja tuoteorganisaation käyttöön. Vaikka toimittaja vaihtuisi olisi vaadittavan alijärjestelmän / komponentin vaatimukset, perustelu sekä linkitykset valmiina. Simulointimallin automaattinen generointi semanttisen datalehden parametritietojen perusteella vaikutti järkevältä. 3. PDM:n koettiin olennaisena linkityksenä. Nimiketietoa tulee rikastaa. Hyvä kysymys on, että mitä ja kuinka paljon informaatiota sijoitetaan PDM:ään. PDM:stä voi tulla helposti liian kompleksinen järjestelmä. Pitäisi puhua enemmänkin PLM:stä Toisaalta PDM:n ominaisuuksista hyödynnetään vain murto-osaa. Semanttisen mallin hyödyt korostuvat ketteryydessä, prosessien sähläyskustannusten vähentämisessä, suunnittelutiedon uudelleen käytössä, moniteknisen informaation tarkastelussa, virtuaaliprototypoinnissa. 4. Miten suunnittelijat saadaan omaksumaan toimintamalli, koska jokaiselle tulee lisätyötä? Hyöty on selkeästi organisaation tasolla. Suunnittelutavan jalkautus vaatii koulutusta, johdon ja henkilöstön sitoutumista, prosessien muokkausta. Voisiko datalehti käsittää myös alijärjestelmän, ettei pelkän komponentit? Laiterakenteen modulaarisuus on olennaista. Tästä tulisi luoda moduulit, komponentit ja vaatimukset. 5. Informaation luotettavuus on myös ongelma. Usein tieto vahvistetaan kollegoilta. Kontekstitietoa pitää saada lisää. Linkitystä kannata ei liittää makrotyyppiin vaan kuvaukseen. 22

24 Esim. hissisuunnittelussa on toteutettu pseudokomponentti, joka kertoo välikerroksena komponenttivaihtoehdot tiettyyn konstruktioon asti. Äitikomponentit, jonka lapsilla konstruktio voidaan toteuttaa. PLM:ään pitää saada mukaan virtuaalirakenne, joka päivittyy suunnittelun edetessä. Koska rajatun projektin puitteissa ei ollut mahdollista toisintaa kokonaista suunnittelu- ja tuotantoprosessia, päädyttiin tapaustutkimuksen jäsentämisessä skenaariopohjaiseen työskentelyyn. Tässä kantavana ajatuksena oli tunnistaa prosessin keskeisiä osa-alueita yksityiskohtaisemman tarkastelun tueksi. Työpajojen havaintojen perusteella hankkeen visiota oli mahdollista merkittävästi kirkastaa, ja siten konkretisoida Semogen II hankkeen työtä. Työpajojen tulosten perusteella hankkeen tapaustutkimuksen keskeiseksi rajaukseksi valittiin suunnittelu- ja tuotantoprosessin näkökulma. Työn konkretisoimiseksi työtavaksi valikoitui tapaustutkimus, johon valittiin työkoneen puomijärjestelmän suunnitteluun liittyvät viisi skenaariota. Valitut skenaariot liittyvät tuotetiedon (CAD/PDM-tiedon) linkityksen kehittämiseen, konejärjestelmän verkkosuunnitteluun (CANOpen), korjaus- ja muutospyyntöjen hallintaan, nimikkeiden linkitykseen sekä toimintokeskeiseen suunnitteluun. Tässä keskiössä on työvaiheiden, työkalujen ja tietosisällön linkitys sekä prosessin "puuttuvien" osien täydentäminen sopivilla valmisohjelmistoilla (erityisesti konseptisuunnittelu ja muutostenhallinta) Tekninen arkkitehtuuri Toteutettu suunnitteluinformaation käsittely tapahtuu kuvassa yksinkertaistetusti esitetyllä tavalla. Suunnitteluohjelmissa tuotetaan suunnittelutietoa, joka tallennetaan PDM-järjestelmään. Kun projektin putkilinja suoritetaan, niin PDM:stä luetaan projekti XML-muodossa. Sitten XML-muotoinen tieto käännetään semanttiseksi malliksi eli tässä tapauksessa RDF/XML:ksi (W3C, 2004). Tämä semanttinen tietomalli linkittää yhteen kaiken suunnittelutiedon ja erilliset suunnitteludokumentit. Semanttiseen tietomalliin päätellään lisää yhteyksiä OWL-ontologian avulla. Päätelty RDF/XML-tieto lisätään semanttisen datan sovelluskehys Callimachukseen, jonne on mahdollista luoda datalähtöisiä näkymäpohjia koneen suunnittelutiedosta. Nämä Callimachuksen näkymät yhdessä jatkokehitetyn Semoplayerin kanssa luovat VML:n koostesovelluksena. (Nurmi, 2013) Callimachuksen vastuulla on semanttisen datan hallinta, kyselyrajapinnat ja semanttisen mallin mukainen navigointi. Semogen:n ensimmäisen osan toteutuksesta jatkokehitetty Semoplayer taas hoitaa suunnitteludokumenttien jakelun sekä simulaation tilan jakelun WebSocket-rajapinnan kautta. Semoplayer:n vastuulla on myös joystick-ohjauskontrollit laitteeseen ja dynaamisten muutosten esittäminen suunnittelukaavioissa sekä 3D-malleissa. (Ibid.) 23

25 Kuva Suunnitteluinformaation käsittely suunnitteluohjelmista semanttiseen malliin ja sitä kautta VML-järjestelmään. Suunnitteluohjelmilla tuotettu tieto tallentuu PDM-järjestelmään, josta se siirretään putkilinjaan XML-muodossa. Tämä muoto muunnetaan semanttisen tietomallin RDF/XML-formaatiin, joka yhdistelee suunnitteluaineiston. Jatkokehitetty Semoplayer ja semanttisen datan sovelluskehys muodostavat yhdessä VML:n koostenäkymät suunnittelutietoon. (Ibid.) 3.2. Semanttinen datalehti Semanttinen datalehti (semantic datasheet) on dokumentti, joka kuvaa komponentin tai koneen tekniset ominaisuudet myös koneluettavasti. Semanttisen datalehden avulla voidaan julkaista älykkäästi erilaisia tietokonesovelluksia varten komponentin teknisen ominaisuudet samalla kuin ihmisluettava datalehti julkaistaan. (Nurmi, 2013) Semogen-hankkeissa on tutkittu ja testattu tätä yksinkertaista tapaa ratkaista suunnittelutietojen julkaisun, hallinnan, löytämisen ja yhdistelynongelmaa. Lähestymistapana on ollut mallintaa ja julkaista aivan suunnittelunkeskeisin komponentti-, laite- tai järjestelmätiedon sisältävä datalehtitieto koneluettavasti. (Ibid.) Datalehtien tietoa käytetään suunnittelussa tiedonvaihtoon suunnittelijoiden ja muiden prosessin jäsenten välillä. Tieto on kuitenkin yleensä tallennettu lähinnä tulostusta ja katselua varten PDF-tiedostoihin. Ratkaisuna on ollut tarjota datalehden sisältämä tieto myös siten, että tietokoneohjelmat voivat sitä mahdollisimman hyvin. Kuvassa on havainnollistus semanttisen datalehden ihmisluettavasta ja koneluettavasta puolesta toteutettuna semanttisessa Callimachus-sovelluskehyksessä. Kuvan oikealla puolella on esitys koneluettavan datalehden tietomallista RDF:n mukaisessa kolmikkojäsennyksessä (subjekti, predikaatti, objekti). Kaikki lehden tiedot on liitetty komponenttiin po1234. Datalehti sisältää tietoja semanttista kuvailutiedoista (predikaatit etuliitteillä rdf ja rdfs), datalehden käyttö- ja muokkausoikeuksista (calli), yleisistä datalehtitiedoista kuten hinnasta ja esimerkkikuvasta (default1) sekä hydraulisille komponenteille yhteiset ominaisuudet (hdvdp). Hydraulisista ominaisuuksista on kuvattu mm. laitteen virtaus-, nopeus- ja paineominaisuuksia (floatat1500, maxflow, peakpressure, nominalpressure, maxspeed). Lisäksi datalehti sisältää yksityiskohtaisempaa numeerista dataa laitteen hyötysuhteesta (volumetricefficiency, mechanicalefficiency, overalefficiency). Kuvassa vasemmalla puolella on esitetty nämä samat datalehden koneluettavat tiedot HTMLverkkosivuna. Laitteesta näkyville on nostettu nimi, hinta ja yleiskuvaus. Datalehteen linkitetty laitekuva on 24

26 esitetty sivulla upotettuna ja tämän lisäksi sivulle on liitetty linkit laitteeseen linkitettyihin lisätietoihin, kuten valmistajan kotisivulle (homepage), laitteen hydrauliseen symboliin (symbol), koneluettavaan datatiedostoon (data) sekä Matlab/Simulink-pohjaiseen simulointimalliin (mfile). Sivulla on lisäksi esitetty runsaasti laitteeseen liittyviä teknisiä ominaisuuksia. Yksityiskohtaisempaa numeerista dataa on lisäksi visualisoitu automaattisesti datalehdestä generoidulla paine-hyötusuhde -kuvaajien visualisoinnilla. Kuva Semanttisen datalehden katselunäkymä ihmisille ja koneluettava semanttinen tieto. Kaikki tämä tieto on säilöttävissä yhteen dokumenttiin. Näkymät ja semanttisen datan hallinta on toteutettu Callimachussovelluskehyksellä. (Ibid.) Vastaavalla tavalla kun verkkosivu on generoitu, voitaisiin datalehdestä generoida automatisoidusti myös PDF-muotoinen esitys. Nykyaikaiset PDF-dokumenttiformaatit mahdollistavat myös koneluettavien metatietojen upottamisen (Adobe XMP). Tämä mahdollistaisi semanttisten datalehtien jakelun suunnittelijoille tutulla tavalla ja tulostusystävällisessä formaatissa, mutta kuitenkin säilyttäisi koneluettavuuteen liittyvät sovellusmahdollisuudet. Semanttisien datalehtien käyttöönotolla voidaan nähdä monenlaisia potentiaalisia hyötyä. Erityisesti: 1) Komponenttien teknisten tietojen automatisoitu käyttö tietojärjestelmissä. Koneluettavaa datalehtitietoa voidaan helposti siirtää ja uudelleen käyttää eri järjestelmissä (PDM/PLM, ERP ja suunnitteluohjelmistot). Näin toimimalla vältytään virhealttiilta käsityöltä, jossa esimerkiksi suunnittelija tarpeen niin vaatiessa syöttää käsin datalehtiin jo koodattua tietoa eri järjestelmiin. 2) Komponenttien semanttinen haku. Koneluettavien datalehtien käyttöönotto mahdollistaisi komponentteihin liittyvän semanttisen haun toteuttamisen, jossa komponentteja voitaisiin etsiä ja 25

27 valita niiden datalehdissä kuvattujen piirteiden perusteella. Semanttisen haun käyttötapauksia ovat esimerkiksi sopivan komponentin valinta yrityksen käyttämien komponenttitoimittajien tarjonnasta teknisten ominaisuuksien, kuten painon, suorituskyvyn ja liitäntätyyppien perusteella. 3) Komponenttien teknisten tietojen liittäminen osaksi järjestelmän semanttista kokonaismallia. Koneluettavien datalehtien tiedot voidaan helposti liittää osaksi järjestelmän semanttista kokonaismallia, mikä edelleen mahdollistaa koko järjestelmää kattavien kyselyjen ja laskennan tekemisen. Esimerkiksi järjestelmän kokonaispaino voitaisiin laskea kokoonpanojen ja niihin liitettyjen datalehtien tietojen perusteella. 4) Valmistaja-, toimiala- ja sovelluskohtaisten resurssien liittäminen ja hyödyntäminen. Esittämässämme mallissa koneluettavat datalehdet perustuvat linkitetyn datan malliin. Tällä periaatteella datalehtien kautta voidaan luoda liitynnät myös muihin komponenttiin liittyviin, valmistaja- ja sovelluskohtaisiin resursseihin. Esimerkiksi komponentteihin liittyviä standardeja tai sertifikaatteja voidaan liittää tällä tavoin osaksi datalehden tietoa. Vastaavasti komponenttiin liittyviä yleisiä tai sovelluskohtaisia simulointimalleja (esim. Matlab/Simulink) voidaan liittää datalehden kautta osaksi järjestelmän mallia. 5) Datalehtien hyödyntäminen skeemana. Datalehtiä voitaisiin hyödyntää laitteen suunnittelussa myös laitekohtaisen tiedon skeemana. Datalehdellä voitaisiin kuvata esimerkiksi laitteeseen liittyvät vaaditut konfiguroinnit ja niiden sallitut arvot. Tällä tavoin suunnittelutietoa voitaisiin validoida suhteessa laitteiden tunnettuihin vaatimuksiin ja saada hyvissä ajoin selville suunnittelutiedosta puuttuvat piirteet Semanttinen CANopen-verkkosuunnittelu Tutkimusaineisto koostuu CANopen väyläsuunnitteluaineistosta, sekä sähkökaaviosuunnitelmista. CANopen-väylän suunnittelu on tehty procanopen-ohjelmalla väyläkohtaisesti eri projekteihin. Esimerkkiaineistomme sisältää kolme eri väylää eli kolme eri procanopen projektia. Sähkösuunnitteluaineisto on tehty Vertex ED-ohjelmistolla ja sisältää kaavion CANopen-laitteiden, sekä analogilaitteiden kytkennöistä. Aineiston varastointiin on käytetty Vertex PDM -ohjelmistoa. (Helminen, 2013) ProCANopen-sovellus tuottaa suoraan helposti luettavia CANopen-standardin mukaisia DCF-tiedostoja. Tiedoston formaatti on määritelty tarkemmin CiA-306 standardissa (CiA, 2005). Näistä voimme lukea CANopen-laitteen asetukset suoraan osaksi semanttista mallia. Nämä asetukset pitävät sisällään laitteen NodeID-tunnisteen CANopen verkossa, verkon numeron, sekä laitteen kommunikointiin liittyvät asetukset. Myös kaikki CANopen-laitteiden keskinäinen PDO-viestiliikenne on kuvattu DCF-tiedostoissa ja luetaan myös semanttiseen malliin. PDO-viesteillä välitetään suurin osa reaaliaikaisesta tiedonsiirrosta CANopenlaitteen ollessa päällä. Esimerkiksi venttiilin ohjaus tai anturin asento välittyvät PDO-viestien avulla. Nyt voimme semanttisessa mallissa tarkastella mitkä viestit välittyvät millekin laitteelle. Tämä voidaan myös visualisoida virtuaalisessa konelaboratoriossa. Myös CANopen-standardit saadaan linkitettyä laitteen tietoihin. Jos standardit olisivat koneluettavassa muodossa voisimme valitoida DCF-tiedostojen sisällön niitä vastaan. Esimerkin vuoksi olemme tehneet yksinkertaisen koneluettavan version CiA-406 standardin (CiA, 2006) osasta joka määrittelee CANopen-anturien tyypit. Nyt kun standardi linkitetään semanttisessa mallissa aineistoon saadaan aineistossa numerokoodilla kuvatulle anturityypille selväkielinen vastine. (Helminen, 2013) Vertex ED-ohjelmasta saamme export-toiminnon avulla SVG-muotoisen kuvan sähkökaaviosta, johon on tallennettu rikastettua tietoa laitteista ja niiden kytköksistä toisiinsa. Tämä voidaan myös lukea osaksi semanttista mallia. Näin semanttiseen malliin muodostuu laitteen CANopen-verkon topologia, mutta myös yksityiskohtaiset tiedot laitteiden konfigraatiosta. Aineiston linkittäminen semanttiseen vaatii laitteiden 26

28 tunnistamista sähkökuvista. Tunnistamista varten on Vertex ED-ohjelmaan generoitu lista olemassa CANopen laitteista ja niiden tunnisteista. Käyttäjä voi valita ohjelman avulla kaaviosta laitteen ja liittää siihen tunnisteen kuten kuvassa on esitetty. Kun laitteen tunniste on tallennettu osaksi sähkökuvaa onnistuu kuvassa olevan tiedon lukeminen osaksi semanttista mallia. Näin malliin saadaan laitteiden kytkentähierarkia talteen. Tästä voidaan edelleen generoida uusia näkymiä tai hyödyntää tietoa vianetsinnässä. (Helminen, 2013) Kuva Yksikäsitteisen laitteen tunnistetiedon lisääminen Vertex ED-ohjelmassa osaksi sähkökaaviota. Vertex PDM toimii tiedostovarastona. Se generoi uusille nimikkeille yksikäsitteiset tunnisteet automaattisesti. Nimikkeillä tarkoitetaan komponentteja tai kokoonpanoja, joita voivat olla esimerkiksi puomi, sylinteri tai venttiili. Näiden tunnisteiden avulla voimme linkittää aineistoa eri lähteistä yhteen semanttiseen malliin. PDM:ään voidaan myös luoda hierarkkisia rakenteita, joilla komponenteista voidaan koostaa kokoonpanoja eli liittää nimikkeitä kuulumaan toisiin nimikkeisiin. (Helminen, 2013) Olemme hyödyntäneet tätä ja luoneet puomimallin, jossa myös CANopen komponentit ovat mukana. Lukemalla tämä hierarkia semanttiseen malliin saadaan tieto siitä mihin kokoonpanoon kyseinen CANopen-komponentti kuuluu. Semogen:n semanttinen suunnitteluprosessi CANopen:n osalta asettaa suunnitteluaineistolle tiettyjä vaatimuksia. Suunnitteluaineisto on hajallaan ja tehty useassa ohjelmassa. Se on pystyttävä yhdistämään semanttiseen malliin. Jotta yhdistäminen olisi mahdollista on aineistossa olevat komponentit tai nimikkeet pystyttävä yksikäsitteisesti tunnistamaan. Eri ohjelmat käyttävät eri tunnistetyyppejä. Vertex PDM käyttää nimikekoodia esim. VX , procanopen Node- ja NetID:tä esim. 12 ja 3 ja Vertex ED viitetunnusta esim. Y12. CANopen-laitteiden osalta ongelma on projektissa ratkaistu lisäämällä Node- ja NetID Vertex ED-ohjelman avulla sähkökaavioon kuvan osoittamalla tavalla, sekä lisäämällä Vertex PDM tunniste (RefDesignator) osaksi procanopenin DCF-tiedostoja kuvan esimerkin osoittamalla tavalla. Näin kaikista kolmesta lähteestä saatua tietoa voidaan luotettavasti yhdistää kuvassa esitettyjen semanttisen prosessin vaiheiden mukaisesti. (Helminen, 2013) 27

29 [DeviceComissioning] NodeID=12 NodeName=B_SWING_V Baudrate=500 NetNumber=6 NetworkName=SMG_BMB RefDesignator=VX Kuva Katkelma DCF-tiedostosta Datan yhdistämisestä syntyneeseen semanttiseen malliin voidaan luoda useita näkymiä ja generoida edelleen uutta dataa. Projektissa CANopeniin liittyviä näkymiä ovat semanttinen datalehti, CAN-kaavio sekä simulointimallin generointi, kuten kuvassa on esitetty. Yhdistetyt aineistot luovat lisäarvoa toisilleen. Semanttinen datalehti esittää komponenttiin liittyvää tietoa ja sallii tiedon muokkaamisen. CANopen komponentin tapauksessa CANopen-konfigurointitiedon (procanopen) lisäksi datalehdessä voi näkyä esimerkiksi komponentin mekaanisia, sähköisiä tai hydraulisia tietoja. Generoitu CAN-kaavio voi sisältää CANopen-konfigurointitiedon lisäksi topologiatietoa sähkökaaviosta tai komponenttien hierarkiatietoa PDM-järjestelmästä. Simulointimalli taas on yhdistelmä osittain sähkökaaviosta ja osittain CANopenkonfiguraatiotiedosta. (Helminen, 2013) Kuva Semanttisen prosessin vaiheet 28

30 Datan yhdistäminen toteutettiin Semogen II -projektissa Python-sovellusten avulla. Sovellukset on esitelty tarkemmin hankkeen aineistoja koostavalla Semogen 2 Tools -sivustolla. Sovelluksia ajettiin Eclipseohjelmointiympäristössä ja niiden avulla koottiin eri lähteissä olevaa tietoa osaksi RDF-muodossa olevaa semanttista mallia. Tarkempaa tietoa CANopen aineistosta ja sen käytöstä osana virtuaalista konelaboratoriota on käsitelty erillisessä julkaisussa (Helminen, 2013). Semogen II hankkeessa tuotettiin koneluettava semanttinen malli PDM-järjestelmässä olevasta CANopen suunnitteluaineistosta ja sähkösuunnitteluaineistosta. Mallin koostaminen hajallaan olevasta aineistosta vaati yhteinäiset yksikäsitteiset tunnisteet aineistossa esiintyville nimikkeille. Tunnistetietoja lisättiin sähkökaavioihin Vertex ED -ohjelman avulla, sekä käsin myös CANopen aineistoon. Malli koostettiin Python-skriptien avulla Eclipse-kehitysalustalla. Mallista voitiin edelleen generoida esimerkiksi simulointimallipohja ja erilaisia näkymiä tietoon, kuten datalehti ja CAN -diagrammi. Tulevaisuudessa koneluettavuutta voitaisiin parantaa muilla alueilla esimerkiksi sopimalla yhteisiä formaatteja sähkökaavioiden tai mekaniikkamallien esitykseen. CANopen on jo nykyään hyvin pitkällä koneluettavuudessa, mm. standardoitujen tiedostoformaattien ansiosta. Tästä kiitos Can in Automation organisaatiolle (CiA, 2012). CANopen -puolella kehitystä voisi jatkaa tekemällä myös standardeista koneluettavia, jolloin semanttista mallinnusta voitaisiin hyödyntää osana suunnitteluprosessia esimerkiksi validoimalla suunnitteluaineistoa standardeja vastaan ja tarkistamalla eri lähteistä tulevien suunnitteluaineistojen yhteneväisyys automaattisesti. Myös ohjelmoitavan logiikan EDS-tiedostot voitaisiin koostaa standardin mukaisista palikoista, kun tiedetään laitteen tyypin mukaan mitä standardeja kyseinen laite toteuttaa. (Helminen, 2013) 3.4. Semanttinen asianhallinta konejärjestelmän suunnittelussa Konejärjestelmän suunnitteluun liittyy runsaasti erilaisia asianhallinnan tarpeita. Systems Engineering - tyyppisessä suunnittelutyössä asianhallinnan menettelyt tulevat tarpeellisiksi 1) konseptisuunnittelussa, 2) vaatimusmäärittelyssä, 3) järjestelmän arkkitehtuurimäärittelyssä ja toteutuksessa, 4) teknisen analysoinnissa ja teknologiajohtamisessa sekä 5) järjestelmän verifioinnissa ja validoinnissa (vrt. Kasser, 2010). Voidaan olettaa, että systemaattisesti toteutettu asianhallinta tehostaa suunnittelutyötä ja näin ollen mahdollistaa mm. V-mallin mukaisen suunnittelutyön kustannustehokkaan ja joustavan läpiviennin. Semanttisessa asianhallinnassa tavoitteena on jäsentää konejärjestelmän suunnitteluun liittyvää informaatiota asiakeskeisesti siten, että asiat ja niiden väliset liitynnät muuhun suunnitteluinformaatioon on täsmällisesti ja merkityksellisesti kuvattu. Semanttisen asianhallinnan keinoin voidaan toteuttaa esimerkiksi konejärjestelmän vaatimusten hallintaa tai suunnitteluun liittyvien työtehtävien projektinhallintaa. Tässä tapaustutkimuksessa toteutimme semanttisen asianhallinnan keinoin esimerkin semanttisesta vaatimusten hallinnan. Tapaustutkimuksen kohteena olevasta, kuvitteellisesta TBx-puomilaitteesta jäsennettiin asiantuntijaryhmällä mahdollisia, tällaiseen puomilaitteeseen liittyviä vaatimuksia. Vaatimukset kuvattiin edelleen Trac-asianhallintajärjestelmään (kts. kuva 3.4.1). Vaatimustietoon liitettiin Tracjärjestelmässä lokaalisti yksikäsitteinen tunniste (Ticket) sekä yleisiä metatietoja, kuten vaatimuksen kuvaus (Summary), vaatimukseen liittyvä vastuusuunnittelija (Owner), vaatimuksen toteutuvuus suunnittelun nykyhetkellä (Status), sekä tieto siitä, mitkä suunnittelun näkökulmat ovat johtaneet vaatimuksen syntymiseen (Keywords). 29

31 Kuva Yhteenveto Trac-järjestelmään kuvatuista puomilaitteen vaatimuksista Osa kuvatuista vaatimuksista esittää laitteeseen liittyviä, yleisen tason vaatimuksia. Esimerkiksi turvallisuuden ja ylläpidettävyyden näkökulmasta katsottiin merkitykselliseksi kuvata vaatimus puomin mekaanisesta lukitettavuudesta. Tällainen ylätason vaatimus johtaa edelleen useampiin, yksityiskohtaisempiin alemman tason vaatimuksiin, joista viime kädessä voidaan yksityiskohtaisia, teknisiä vaatimuksia toteutettavalle laitteelle. Esimerkiksi kuvassa luetelluista vaatimuksista numero 12 voitaisiin asiakasprojektissa tulkita alisteiseksi vaatimukselle 5. Vastaavalla periaatteella vaatimuksia voitaisiin edelleen jäsentää hierarkkisiksi vaatimustiedon tehokkaan hallinnan saavuttamiseksi. 30

32 Yksittäiseen vaatimukseen voidaan liittää yksityiskohtaista, suunnitteluun liittyvää tietoa. Kuvassa on esimerkkinä esitetty yksityiskohtaiset tiedot puomin mekaanisen lukittavuuden vaatimuksesta (vaatimus nro. 20). Kuva Vaatimuksen yksityiskohtaiset tiedot (vasemmalla) sekä visualisointi vaatimukseen linkitetystä puomi-komponentista PDM-järjestelmästä (oikealla) Trac-järjestelmään kuvatuista vaatimustiedoista saadaan edelleen generoitua semanttinen malli. Tämän mallin kautta vaatimuksia voidaan tarkastella erilaisista näkökulmista. Kuvassa on esitetty visualisointi, jossa yksittäiset vaatimukset ja niiden riippuvuudet eri vaatimuskategorioihin on visualisoitu. 31

33 Kuva Visualisointi yksittäisten vaatimusten liittyvyydestä eri vaatimuskategorioihin Esitetyllä semanttisella asianhallinnalla voidaan saavuttaa seuraavia hyötyjä: Suunnitteluprojektin valmiuden seuranta Ketterämpi muutostenhallinta Parempi yleiskuva suunnittelutiedon linkittyvyydestä vaatimuksiin ja työtehtäviin Mahdollistaa muuttuvien vaatimuksien systemaattisen dokumentoinnin ja vaivattoman konekäsiteltävyyden sekä uudelleenkäytettävyyden 3.5. Semanttinen ja linkittynyt nimikkeiden hallinta Teollinen tuotanto edellyttää jokaiselle komponentille nimikkeen, jonka mukaan kyseistä komponenttia hallinnoidaan. Näin ollen hyvin toteutettu nimikkeiden hallinta on keskeinen osa toimivaa tuotekehitystä. Käsitettä nimike käytetään yleisesti kuvaamaan mitä tahansa tuotteeseen liittyvää yksilöitävää resurssia. Nimike voidaan liittää esimerkiksi mihin tahansa tuotteeseen liittyvään fyysiseen resurssiin, palveluun, toimintoon tai vaikkapa sidosryhmään (vrt. Variantum, 2012). Fyysisen resurssin nimikkeellä voidaan viitata esimerkiksi kokoonpanoon, osiin, komponentteihin, materiaaleihin, työvälineisiin tai pakkauksiin (Ibid.). Myös tuotteisiin liittyvien abstraktien tuoteperheiden ominaisuuksien kuvailua voidaan käsittää kuuluvan osaksi nimikkeiden hallintaan. Nimikkeiden hallinta kattaa lähtökohtaisesti ainakin sen osan suunnittelutiedosta, joka on välttämätöntä yksilöidä PDM- ja PLM-järjestelmissä. Suunnittelutiedon yksilöinnissä käytetään nimikkeiden rinnalla usein myös muita, suunnitteluala- ja sovelluskohtaisia yksilöintimenettelyjä, erityisesti viitetunnuksia. Viitetunnus (toisinaan myös yksikkötunnus) on tunniste, joka nimeää yksikäsitteisesti tarkastelun kohteena olevan resurssin järjestelmän sisällä. Esimerkiksi järjestelmään liittyviä tietokantakohteita, komponentteja, liittimiä, dokumentteja tai signaaleja voidaan nimetä yksikäsitteisesti viitetunnuksilla. Viitetunnuksen nimeämistehtävästä riippuen se 32

34 voidaan kuvata joko yksitasoisesti tai hierarkkisesti, jolloin viitetunnus voi koodata myös kohteen sijaintia järjestelmässä (engl. position). Viitetunnuksia ja niissä sovellettavia koodausmenettelyjä on kuvattu laajalti erityisesti kansainvälisissä IEC- ja ISO-standardeissa (IEC 2009a, IEC 2009b, ISO 2012) sekä niiden suomenkielisissä vastineissa SFS-EN , SFS-EN ja SFS-EN (SFS 2010, SFS 2009, SFS, 2002). Semanttisessa ja linkittyneessä nimikkeiden hallinnassa nimikkeistön hallintaa toteutetaan siten, että järjestelmän eri nimikkeet ja niihin liittyvät metatiedot liitetään osaksi linkittynyttä semanttista kokonaismallia. Tyypillisesti nimikkeillä saadaan kuvattua yksi näkökulma järjestelmän rakenteiseta mallista. Semanttisessa nimikkeidenhallinnassa tätä kuvailua voidaan edelleen rikastaa paitsi rakenteen osalta niin myös tuomalla nimikkeisiin linkityksiä järjestelmän toiminnallisiin malleihin, kuten toimintoketjuihin. Semanttinen nimikkeiden hallinta mahdollistaa lisäksi mielivaltaisten rikkaan nimiketietojen kuvailun. Tällä tavoin esimerkiksi viitetunnus-järjestelmässä perinteisesti numero- ja kirjainkoodein kuvatut tiedot positioista ja järjestelmän sekä tuoteperheen arkkitehtuurin eri näkökulmista voidaan mielivaltaisen tarkasti kuvata osaksi semanttista mallia Esimerkkiaineisto Taulukossa esitetään yksi mahdollinen tapa toteuttaa nimikkeiden hallintaa. Taulukossa esitetään tapausesimerkkinä käytetyn puomin nimikkeistöä käsin kerätyssä taulukossa. Taulukon esimerkkidatassa nimikkeiden koodaus perustuu PDM.n kautta keskitetysti luotuihin ja hallinnoituihin nimikekoodeihin (esim. anturi koodilla VX ). Nämä koodit pohjautuvat Vertex PDM-järjestelmän juokseviin numerointeihin, jotka on noudettu eri käyttöön tarkoitetuista sarjoituksista. Käytännön suunnittelutyössä tiettyjä komponenttipositioita saatetaan lisäksi kuvata käsin nimetyillä, hierarkkisiin positioihin viittaavilla viitetunnuksilla. 33

35 Taulukko Tapaustutkimusaineiston nimikkeiden hierarkkinen tunnistaminen ja luokittelu Sijainti PDM-nimike Viitetunnus Nimikkeen otsikko 1. - RIG Rig assembly 1.1. VX CARRIER Carrier assembly VX SMGBBB smg-bbb canbus CABIN Cabin assembly VX SMGHMI smg-hmi canbus Nimikkeen luokitteet (Semogen) Nimikkeen luokite (ecl@ss) 1.3. VX BM1 Boom assembly Boom crane VX BM1SMGBOOM smg-boom canbus VX BM1SWINGBOOM lift-swingboom mechanicbody VX BM1ZOOMBOOM zoom-boom mechanicbody VX BM1LIFT lift-joint revolutejoint Revolving joint (bearing, unclassified) VX cylinder hydrauliccylinder Differential cylinder (hydraulics) VX BM1Y32 valve canopenvalve Spool valve (standard, hydraulics) VX BM1BG33 sensor anglesensor, canopenrotaryencoder Absolute encoder VX BM1SWING swing-joint revolutejoint Revolving joint (bearing, unclassified) VX cylinder hydrauliccylinder Differential cylinder (hydraulics) VX BM1Y42 valve canopenvalve Spool valve (standard, hydraulics) VX BM1BG43 sensor anglesensor, canopenrotaryencoder VX BM1ZOOM zoom-joint prismaticjoint Absolute encoder VX cylinder hydrauliccylinder Differential cylinder (hydraulics) VX BM1Y52 valve canopenvalve Spool valve (standard, hydraulics) VX BM1B53 sensor linearsensor, canopenlinearencoder Potentiometric distance sensor Taulukon esimerkkiin on nostettu esille rinnakkain sekä PDM:ssä hallinnoitu nimike että sitä vastaava, position yksilöivä viitetunnus, joista molemmat yksilöivät suoraan komponentin instanssin. Riippuen tavasta, jolla PDM-järjestelmää käytetään, saattaa PDM-nimike joko vastata yksilöinnissä yksi-yhteen nimikkeeseen liittyvää erillistä viitetunnusta. Vaihtoehtoisesti PDM-järjestelmään saatetaan kuvata nimikkeet kutakin suunniteltua kokoonpanoa kohden vain kertaalleen. Tässä tilanteessa nimike vastaakin ainoastaan järjestelmässä komponentin tyyppiä ja komponentin instanssin tarkkaan yksilöintiin tarvitaan lisäksi sen viitetunnus. Huomionarvoista on myös, että myös kokoonpanoille luodaan usein niitä vastaavat nimikekoodit. Vastaavasti myös kokoonpanoista ja komponenteista koostuviin järjestelmiin liitetään yksikäsitteiset nimikekoodit. Taulukoiduille nimikkeille on koottu myös muuta lisätietoa. Kullekin nimikkeelle on annettu selkokielinen, ei-yksilöivä otsikko. Komponentit on lisäksi tyypitetty Semogen-tapaustutkimuksessa käytetyn luokittelujärjestelmän mukaisesti. Jotta nimikkeet saadaan liitettyä osaksi tunnettuja kolmannen osapuolen luokittelujärjestelmiä, on nimikkeille lisäksi annettu esimerkinomaisesti myös ecl@ss 7.1 BASIC - järjestelmän mukaiset luokitteet (koodi ja otsikko). Vastaavalla tavalla voitaisiin kuvata liityntöjä myös 34

36 muihin standardeihin ja luokittelujärjestelmiin (esim. ISO-standardit ja suunnittelualakohtaiset standardit kuten CAN in Automation [CiA] -standardit) Aineiston semanttinen mallinnus Edellä kuvatun taulukon mukainen aineisto sovitettiin edelleen Vertex PDM -järjestelmään, josta tuotettiin semanttinen malli. Vertex PDM -järjestelmään perustettiin kutakin komponenttia vastaava nimike hakemalla koodit järjestelmän tarjoamista sarjoituksista. Aineiston kokoonpano hierarkia mallinnettiin myös PDM:n tarjoamilla välineillä. Kuvailutiedoista nimikkeiden selkokielinen otsikko liitettiin PDM:ssä kuvaus-kenttään (description). Myös nimikkeiden luokittelu toteutettiin Vertex PDM-järjestelmään. Vertex PDM mahdollistaa luokittelujärjestelmien asiakaskohtaisen räätälöinnin muokkaamalla VXCLASSIFICATIONnimikkeeseen liitettyä luokittelutietoa. Tätä räätälöintimahdollisuutta hyödynnettiin siten, että järjestelmään tuotiin semanttiseen malliin pohjautuva luokittelujärjestelmä. Tällä tavoin suunnittelija pystyy poimimaan Vertex PDM -järjestelmän tuttua käyttöliittymää hyödyntäen nimikkeelle tyypityksen (kuva ) kuitenkin siten, että tämän tyypitystiedon avulla nimikkeistö voidaan liittää semanttisen mallin mukaiseen tyypitysjärjestelmään. Kuva Nimikkeiden hierarkkinen jäsennys ja luokittelu Vertex PDM -järjestelmässä 35

37 Jotta PDM-järjestelmään tuotettu nimiketieto saataisiin liitettyä osaksi semanttista mallia, toteutimme vientirajapintoja hyödyntäviä adaptereja. Jotta eri PDM-järjestelmistä saatavaa tietoa voitaisiin yhdistellä, generoitiin kullekin nimikkeelle globaali, yksilöivä tunniste. Yksilöivä tunniste muodostettiin PDM:n koodisarjoista haetusta nimikkeestä (esim. VX ) sekä PDM-järjestelmän URL-osoitteesta (esim. Esimerkiksi puomille numero 1 voitiin tapaustutkimusaineistossa johtaa tällä tavoin globaalisti yksikäsitteinen tunniste Näihin yksikäsitteisiin tunnisteisiin pohjautuen tiedon yhdistäminen muuhun semanttiseen malliin onnistuu triviaalisti yhdistelemällä yksittäiset adapterin generoimat tiedostot RDF:n graafimallin mukaisesti yhteen. Vastaavalla tavalla kuin nimikkeillä, myös järjestelmään viedyn luokittelujärjestelmän alkioille voidaan myös luoda globaalisti yksikäsitteiset tunnisteet. Kuvassa esitetty hydraulisylinterin luokitteluvalinta asettaa PDM:ssä ks. nimikkeen luokituksen arvoksi component hydrauliccomponent hydrauliccylinder. RDF-tietomallissa tämä arvo voidaan liittää predikaatilla subjektiin jolloin valittu, järjestelmäkohtainen luokittelu voidaan jäljittää Semogenin yleisempään hydraulisylinteri käsitteeseen. Näin ollen, vaikka PDMjärjestelmän käyttämä luokittelu olisi kokonaan tai osittain yrityskohtainen, voitaisiin se silti yhdistellä yleisemmin tunnettuun luokittelujärjestelmään. Kuvassa on esitetty yksi mahdollinen visualisointi edellä kuvatun sylinterin semanttisesta mallista. Kuvassa vasemmalla nähdään luokittelujärjestelmän kautta nimikkeeseen periytyvät tyypitykset (mm. perintähierarkia component - hydrauliccomponent - hydrauliccylinder). Myös liittyvyys isäntänimikkeeseen VX on nähtävissä. Nimikkeeseen liitetyt metatiedot ovat myös esillä kuvassa oikeassa reunassa. Nimikkeeseen on lisäksi liitetty näkyville myös vaihtoehtoinen, samaa nimikettä kuvaava URL-osoite, jota suunnittelijat voivat käyttää jakaessaan hyperlinkin PDM:n nimikesivulle. Näin menetellessä semanttisen mallin avulla voidaan jäljittää sovelluksissa esimerkiksi kuvauskentissä esiintyvien hyperlinkkien liittyvyys suoraan nimikkeisiin. Kuva Visualisointi yksittäisen nimikkeen semanttisesta mallista Protégé:n OntoGraf-näkymällä 36

38 Vastaavasti kuin kuvassa, voitaisiin semanttista nimikemallia rikastaa mielivaltaisen laajasti erilaisilla lisätiedoilla. Erityisesti taulukossa esitetyt viitetunnus ja voitaisiin liittää muiden tietojen tavoin osaksi semanttista mallia. Nykyisessä mallissa esitetty nimikerakenne kattaa lähinnä nimikkeiden rakenteelliset, kuten kokoonpanoon sitoutuvat liittyvyydet. Perusteltua olisi kuitenkin myös laajentaa tätä semanttista nimikemallia kattamaan myös järjestelmän toiminnallista mallia ja nimikkeiden liittyvyyttä toisiinsa myös tämän rakenteen kautta. Esimerkiksi tässä käsitellyssä puomiaineistossa voitaisiin semanttiseen nimikemalliin liittää myös puomin liikutukseen, kuten nostoon liittyvät nimikkeet Tulokset ja pohdintaa Työn tuloksena syntyi PDM-järjestelmästä haettuihin tietoihin pohjautuva semanttinen ja linkittynyt nimikemalli. Malli kuvaa rikkaasti PDM-järjestelmiin syötetyt nimikkeet ja niihin liitetyt tiedot. Lisäksi malli yhdistyy PDM:stä haettujen luokittelujen kautta semanttisessa mallissa kuvattuun yleiseen Semogenluokittelujärjestelmään. Koska nimikkeille luodaan globaalisti yksikäsitteiset tunnisteet, voidaan nimikkeisiin liittää mielivaltaisesti yhteyksiä mihin tahansa suunnittelutietoon. Yhdistelyn mahdollisuus ei rajoitu ainoastaan muista järjestelmistä tulevaan suunnittelutietoon, vaan mitä tahansa nimikkeisiin liittyvää tietoa voidaan tällä tavalla liittää osaksi semanttista kokonaismallia. Esimerkiksi suunnittelutyöhön liittyvän prosessin, tehtävienhallinnan tai turvallisuussuunnittelun tietoa voidaan tällä tavoin liittää nimikkeisiin. Vastaavalla menettelyllä voitaisiin nimikkeeseen liittää tietoa sen elinkaaren mistä tahansa vaiheesta, kuten kunnossapidon ja huollon ajalta. Semanttisen nimikkeiden hallinnan tärkeimpänä tehtävänä voidaan pitää eri tekniikoilla ja eri suunnittelualoilla toteutettujen suunnittelutietojen yhdistämistä laitteen rakenteiseksi ja toiminnalliseksi kokonaismalliksi. Onnistunut nimikkeistön hallinta mahdollistaa suunnittelutietojen validointia ja estää virheiden pääsyä tuotantoon ja huoltoon. Projektin johdolle tässä työssä syntyvä semanttinen tuoterakenne paljastaa ideaalitilanteessa aina kattavasti totuuden tuotteen valmiusasteesta. Jos tuotteen valmiusastetta arvioidaan yksittäisten suunnittelualojen työn valmiutena, jää huomioimatta, että valmis tuote on paitsi suunniteltu loppuun niin myös liitetty saumattomasti kohdeympäristöönsä. Juuri tämänkaltaista tarkastelua voidaan edistää semanttisella nimikkeistönhallinnalla, jossa kokonaiskuva tietojen linkittyvyydestä saadaan parhaassa tapauksessa tosiaikaisesti Toimintokeskeinen, semanttinen suunnittelu Vaatimusten toteutumisen seuranta tuodaan osaksi VML-järjestelmää lukemalla korjaus- ja muutospyyntöjen hallintajärjestelmästä tiedot semanttiseen malliin. Kuten muutkin semanttisen mallin tiedot, myös vaatimusten toteuttamiseen tähtäävä tikettijono on silloin näkyvillä VML:ssä. Luonnollisesti vaatimusten määrittelystä seuraa koneen toimintojen luonnostelu, joka sekin halutaan koneluettavaksi mukaan semanttiseen malliin ja edelleen VML-järjestelmään näkyville. (Nurmi, 2013) Toimintomallien hallintaan on testattu ratkaisuksi työkalua, jolla toiminnot voidaan suunnitella ja lukea osaksi semanttista mallia. Tällöin nekin ovat mukana VML:ssä ja muodostavat mahdollisuuden navigoida suunnitteluaineistoa toimintojen näkökulmasta. Ilmaiseen Freemind-käsitekarttaeditoriin lisättiin sovitinohjelma, joka generoi käsitekarttana luodun toimintomallin RDF:ksi. Näin editoria voi käyttää suunnittelun ylätason mallina toimivien toimintoketjujen suunnittelussa. Kuvassa on esimerkki toimintojen suunnittelusta editorilla. Tallennettu käsitekartta muunnetaan sovittimen avulla RDF:ksi, kun putkilinjassa määritellyt generoinnit suoritetaan. RDF-muodossa tallennettu semanttinen tietomalli lisätään Callimachus-järjestelmään, jossa on määritelty osa VML:n näkymien generoinnista vastaavasta toteutuksesta. Kuvassa näkyy VML:n valikko, jossa on suunnittelussa määritellyt toiminnot laitteelle. (Ibid.) 37

39 Toimintomalliin linkittyy koko projektin suunnittelutieto. Samalla se on vaihtoehtoinen tapa mallintaa konetta järjestelmäkuvauksen rinnalla. VML:ssä on mahdollista tarkastella suunnittelutietoa navigoimalla sitä toimintojen näkökulmasta. Järjestelmän toiminnot kuvaava käsitekarttaeditorista generoitu semanttinen RDF-malli. Toimintojen malli mallintaa toiminnot osakohtaisesti ja mahdollistaa monihaaraisentapahtumaketjun. OWL-mallinen ontologia kuvaa, millainen on semanttinen toimintomalli. (Ibid.) Kuva Freemind-käsitekarttaeditorilla voi suunnitella toimintoja Suunnittelussa ylätason mallina toimiva toimintomalli on myös semanttisessa mallissa eri suunnittelutietoa yhdistelevä ylätason malli. Jotta käsitekartan tieto saadaan osaksi semanttista mallia, ohjelmointiin Freemind-editoria varten sopiva sovitinohjelma. (Ibid.) 38

40 Kuva Koneen suunnitteluinformaation selailu toimintojen avulla. Valikko on generoitu virtuaaliseen konelaboratorioon semanttisesta mallista. (Ibid.) Kuvassa on toimintomalli avattuna ontologioiden luontiin ja hallintaan tarkoitetulla Protégésovelluksella. Kuten kuvasta näkyy, niin toimintomalli linkittää eri järjestelmiä yhteen. (Ibid.) Ajatuksena on, että heti suunnittelun alkuvaiheessa tehdään luonnostason toimintomalli, jota koko suunnittelun ajan tarkennetaan lähemmäs täsmällistä toteutusta tietyillä teknisillä ratkaisuilla. Näin suunnittelulla on koko ajan käytössä ylätason tietomalli, johon voidaan liittää kaikki laitteeseen tulevat järjestelmät ja selittää niiden tehtävä laitteessa. Tämän avulla suunnittelua voidaan tarkastella VML:ssä yhteissuunnittelun mukaisesti kaikkia suunnittelun osa-alueita koskevan toimintojen ratkaisemisongelman näkökulmasta. (Ibid.) 39

41 Kuva Yksittäistä toimintoketjua kuvaava semanttinen malli visualisoituna Protégé-ohjelmassa. Kuvasta nähdään, millaiset askeleet toimintoketjussa on. Askeliin on linkittynyt järjestelmät, jotka toteuttavat tietyn toiminnon laitteessa. (Ibid.) Keskeisimmät hyödyt saadaan siitä, että heti luonnosvaiheessa suunnittelutiedolle on yhdistävä malli: laitteen toiminnot. Koko suunnitteluprosessia ja -tietoa voidaan tarkastella toimintojen toteutumisen näkökulmasta. Suunnitteluratkaisuja voidaan validoida sen perusteella, miten ne vievät laitteen toimintoja eteenpäin tarkentamalla toimintojen toteutustapoja. Kaikki suunnittelutieto saadaan sidotuksi toimintojen toteuttamista varten. Samalla syntyy dokumentaatio siitä, miten laitteen toiminnot on suunniteltu ja miten laite itse asiassa toimii. Tätä tietoa voidaan hyödyntää esimerkiksi laitetta huollettaessa. (Ibid.) 40