TAMPEREEN TEKNILLINEN YLIOPISTO, SMART SIMULATORS -TUTKIMUSRYHMÄ

Virtuaalinen konelaboratorio ja semanttinen mallinnus konejärjestelmän suunnittelun tukena,

Loppuraportti, Semogen II -hanke

Loppuraportti

Semogen II –hanke

1

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: https://wiki.tut.fi/SmartSimulators/Semogen2

2

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 2221 -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ää RDF-

muodossa 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

3

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.

4

SISÄLLYSLUETTELO

Esipuhe .............................................................................................................................................................. 1

Tiivistelmä ......................................................................................................................................................... 2

1. Johdanto ......................................................................................................................................................... 5

2. Systems engineering –malli konejärjestelmän semanttisessa suunnitteluprosessissa ................................... 8

2.1. Konejärjestelmän suunnittelusta ............................................................................................................. 8

2.1.1. Mekatronisen konejärjestelmän suunnitteluprosessi ....................................................................... 8

2.2 Systems engineering ja yhteistoiminnallinen suunnittelu ...................................................................... 10

2.3. Suunnittelumalleja ................................................................................................................................ 13

2.4. Semanttinen mallinnus ja linkitetty data suunnitteluinformaation integroinnissa ................................ 14

2.5. Virtuaaliympäristöt suunnittelun tukena .............................................................................................. 17

2.5.1. Asiantuntijahaastattelu ................................................................................................................... 17

2.5. Vaatimukset skenaarioille..................................................................................................................... 18

3. Konejärjestelmän suunnittelu semanttisenmallinnuksen menetelmien tuella ............................................. 20

3.1. Tekninen arkkitehtuuri ......................................................................................................................... 23

3.2. Semanttinen datalehti ........................................................................................................................... 24

3.3. Semanttinen CANopen-verkkosuunnittelu ........................................................................................... 26

3.4. Semanttinen asianhallinta konejärjestelmän suunnittelussa ................................................................. 29

3.5. Semanttinen ja linkittynyt nimikkeiden hallinta ................................................................................... 32

3.5.1. Esimerkkiaineisto .......................................................................................................................... 33

3.5.2. Aineiston semanttinen mallinnus ................................................................................................... 35

3.5.3. Tulokset ja pohdintaa ..................................................................................................................... 37

3.6. Toimintokeskeinen, semanttinen suunnittelu ....................................................................................... 37

4. Lopuksi ........................................................................................................................................................ 41

Lähteet ............................................................................................................................................................. 45

Liite 1: Hankkeeseen liittyvät julkaisut ........................................................................................................... 47

Liite 2: Sanasto ja termit .................................................................................................................................. 48

5

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.

6

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 kysely-

ja 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

7

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 (http://wiki.tut.fi/SmartSimulators/Semogen2). Hankkeen

tapaustutkimukseen liittyvä puomin nosto -demonstraatio on myös kuvattu erikseen

(http://wiki.tut.fi/SmartSimulators/SemogenBoomLift). Myös hankkeeseen liittyviä materiaaleja ja työkaluja

on koottu yhteen (http://wiki.tut.fi/SmartSimulators/Semogen2Toolkit).

8

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 2206. 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.

2.1.1. 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)

9

Kuva 2.1.1.1. 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.

10

Kuvassa 2.1.1.2 on erilaisia malleja koneesta sijoitettuna niiden konkreettisuuden ja tarkkuuden mukaan.

Suunnitteluprosessissa suunnittelutieto jalostuu kuvan vasemmasta ylänurkasta kohti oikeaa alanurkkaa.

(Nurmi, 2013)

Kuva 2.1.1.2. Suunnitteluprosessissa syntyy erilaisia malleja suunniteltavasta koneesta. Suunnittelu etenee

abstraktista konkreettiseen ja tarkempaan malliin koneesta.

Kuvassa 2.1.1.2 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 osa-

alueesta: 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.

11

Kuva 2.2.1. 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 2.2.2 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 2.2.2. Suunnittelulähtökohtien ja vaatimusten väliset suhteet (Anon, 2001)

12

Kuva 2.2.2 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 2.2.3 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 2.2.3. 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 2.2.4 on esitetty

keskeisimmät järjestelmän elinkaareen liittyvät osa-alueet. Ne ovat: kehittäminen, valmistus/tuotanto,

13

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.

Kuva 2.2.4. Elinkaaren hallinnan osa-alueet (Anon, 2001)

2.3. Suunnittelumalleja

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.)

14

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. Semogen-

hankkeessa 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):

URI1-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

(RDF2, 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)

15

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 web-

infrastruktuurissa.

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 2.4.1. Suunnitteluinformaation jäsennys ja yhdistyvyys linkitetyn datan mallilla semanttisissa

PDM/PLM-järjestelmissä

16

Kuvassa 2.4.1 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 2.4.2. 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ä

17

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 3.5.

2.5. 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ä koulutus-

että 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.

2.5.1. 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.

18

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.)

19

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.)

20

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:

21

1.2.2012 Yhteinen työpaja (Vertex): PDM-koulutus ja tuotetietopäivät

8.2.2012 Yhteinen työpaja (Sandvik): Tapaustutkimuksen aineisto

10.2.2012 Yhteinen työpaja (Etteplan): Tuotteen elinkaarenhallinta ja jälkimarkkinointi

14.3.2012 Yhteinen työapaja (TTY): Konejärjestelmän semanttinen suunnitteluprosessi

29.5.2012 AEL-työpaja. Visio, konkreettiset tavoitteet ja käyttötapaukset

31.5.2012 Etteplan-työpaja: Visio, konkreettiset tavoitteet ja käyttötapaukset

31.5.2012 Sandvik-työpaja: Visio, konkreettiset tavoitteet ja käyttötapaukset

8.6.2012 Vertex-työpaja: Visio, konkreettiset tavoitteet ja käyttötapaukset

13.6.2012 Cargotec-työpaja: Visio, konkreettiset tavoitteet ja käyttötapaukset

2.11.2012 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

22

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.

23

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).

3.1. Tekninen arkkitehtuuri

Toteutettu suunnitteluinformaation käsittely tapahtuu kuvassa 3.1.1 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.)

24

Kuva 3.1.1. 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 3.2.1 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 3.2.1. vasemmalla puolella on esitetty nämä samat datalehden koneluettavat tiedot HTML-

verkkosivuna. Laitteesta näkyville on nostettu nimi, hinta ja yleiskuvaus. Datalehteen linkitetty laitekuva on

25

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 data-

tiedostoon (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 3.2.1. 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 Callimachus-

sovelluskehyksellä. (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

26

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.

3.3. 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 CANopen-

laitteen 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

27

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 3.3.1 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 3.3.1. 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. VX3000316, 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 3.3.1 osoittamalla tavalla, sekä lisäämällä Vertex PDM tunniste

(RefDesignator) osaksi proCAnopenin DCF-tiedostoja kuvan 3.3.2 esimerkin osoittamalla tavalla. Näin

kaikista kolmesta lähteestä saatua tietoa voidaan luotettavasti yhdistää kuvassa 3.3.3 esitettyjen semanttisen

prosessin vaiheiden mukaisesti. (Helminen, 2013)

28

Kuva 3.3.2. 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 3.3.3 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 CANopen-

konfiguraatiotiedosta. (Helminen, 2013)

Kuva 3.3.3. Semanttisen prosessin vaiheet

[DeviceComissioning]

NodeID=12

NodeName=B_SWING_V

Baudrate=500

NetNumber=6

NetworkName=SMG_BMB

RefDesignator=VX3000326

29

Datan yhdistäminen toteutettiin Semogen II -projektissa Python-sovellusten avulla. Sovellukset on esitelty

tarkemmin hankkeen aineistoja koostavalla Semogen 2 Tools -sivustolla. Sovelluksia ajettiin Eclipse-

ohjelmointiympä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 Trac-

jä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).

30

Kuva 3.4.1. 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 3.4.1 luetelluista vaatimuksista numero 12

voitaisiin asiakasprojektissa tulkita alisteiseksi vaatimukselle 5. Vastaavalla periaatteella vaatimuksia

voitaisiin edelleen jäsentää hierarkkisiksi vaatimustiedon tehokkaan hallinnan saavuttamiseksi.

31

Yksittäiseen vaatimukseen voidaan liittää yksityiskohtaista, suunnitteluun liittyvää tietoa. Kuvassa 3.4.2. on

esimerkkinä esitetty yksityiskohtaiset tiedot puomin mekaanisen lukittavuuden vaatimuksesta (vaatimus nro.

20).

Kuva 3.4.2. 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 3.4.3. on esitetty

visualisointi, jossa yksittäiset vaatimukset ja niiden riippuvuudet eri vaatimuskategorioihin on visualisoitu.

32

Kuva 3.4.3. 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

33

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 81346-1, SFS-EN 81346-2 ja SFS-EN 61346-3 (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.

3.5.1. Esimerkkiaineisto

Taulukossa 3.5.1.1. 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 VX3000330). 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.

34

Taulukko 3.5.1.1 Tapaustutkimusaineiston nimikkeiden hierarkkinen tunnistaminen ja luokittelu

Sijainti PDM-nimike Viitetunnus

Nimikkeen

otsikko

Nimikkeen luokitteet

(Semogen)

Nimikkeen luokite

(eCl@ss)

1. - RIG Rig assembly

1.1. VX3000314 CARRIER Carrier assembly

1.1.1. VX3000333 SMGBBB smg-bbb canBus

1.2. - CABIN Cabin assembly

1.2.1. VX3000336 SMGHMI smg-hmi canBus

1.3. VX3000315 BM1 Boom assembly 36-12-01-11

Boom crane

1.3.1. VX134568 BM1SMGBOOM smg-boom canBus

1.3.2. VX3000316 BM1SWINGBOOM lift-swing-

boom

mechanicBody

1.3.3. VX3000317 BM1ZOOMBOOM zoom-boom mechanicBody

1.3.4. VX3000318 BM1LIFT lift-joint revoluteJoint 23-05-14-90

Revolving joint (bearing, unclassified)

1.3.4.1. VX3000322 - cylinder hydraulicCylinder 27-30-02-01

Differential cylinder (hydraulics)

1.3.4.2. VX3000323 BM1Y32 valve canOpenValve 27-30-06-02

Spool valve (standard, hydraulics)

1.3.4.3. VX3000324 BM1BG33 sensor angleSensor,

canOpenRotaryEncoder

27-27-05-02

Absolute encoder

1.3.5. VX3000319 BM1SWING swing-joint revoluteJoint 23-05-14-90

Revolving joint (bearing, unclassified)

1.3.5.1. VX3000325 - cylinder hydraulicCylinder 27-30-02-01

Differential cylinder (hydraulics)

1.3.5.2. VX3000326 BM1Y42 valve canOpenValve 27-30-06-02

Spool valve (standard, hydraulics)

1.3.5.3. VX3000327 BM1BG43 sensor angleSensor,

canOpenRotaryEncoder

27-27-05-02

Absolute encoder

1.3.6. VX3000320 BM1ZOOM zoom-joint prismaticJoint

1.3.6.1. VX3000328 - cylinder hydraulicCylinder 27-30-02-01

Differential cylinder (hydraulics)

1.3.6.2. VX3000329 BM1Y52 valve canOpenValve 27-30-06-02

Spool valve (standard, hydraulics)

1.3.6.3. VX3000330 BM1B53 sensor linearSensor,

canOpenLinearEncoder

27-27-07-04

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

35

muihin standardeihin ja luokittelujärjestelmiin (esim. ISO-standardit ja suunnittelualakohtaiset standardit

kuten CAN in Automation [CiA] -standardit).

3.5.2. 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 VXCLASSIFICATION-

nimikkeeseen 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 3.5.2.1)

kuitenkin siten, että tämän tyypitystiedon avulla nimikkeistö voidaan liittää semanttisen mallin mukaiseen

tyypitysjärjestelmään.

Kuva 3.5.2.1. Nimikkeiden hierarkkinen jäsennys ja luokittelu Vertex PDM -järjestelmässä

36

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. VX3000315) sekä PDM-järjestelmän URL-osoitteesta (esim.

http://smartsimu.rd.tut.fi). Esimerkiksi puomille numero 1 voitiin tapaustutkimusaineistossa johtaa tällä

tavoin globaalisti yksikäsitteinen tunniste http://smartsimu.rd.tut.fi/items/VX3000315. 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 3.5.2.1 esitetty hydraulisylinterin luokitteluvalinta

asettaa PDM:ssä ks. nimikkeen luokituksen arvoksi component|hydraulicComponent|hydraulicCylinder.

RDF-tietomallissa tämä arvo voidaan liittää predikaatilla http://www.vertex.fi/semogen/pdmClassification

subjektiin http://www.tut.fi/projects/semogen/hydraulicCylinder, jolloin valittu, järjestelmäkohtainen

luokittelu voidaan jäljittää Semogenin yleisempään hydraulisylinteri käsitteeseen. Näin ollen, vaikka PDM-

järjestelmän käyttämä luokittelu olisi kokonaan tai osittain yrityskohtainen, voitaisiin se silti yhdistellä

yleisemmin tunnettuun luokittelujärjestelmään.

Kuvassa 3.5.2.2 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

VX3000318 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 3.5.2.2. Visualisointi yksittäisen nimikkeen semanttisesta mallista Protégé:n OntoGraf-näkymällä

37

Vastaavasti kuin kuvassa, voitaisiin semanttista nimikemallia rikastaa mielivaltaisen laajasti erilaisilla

lisätiedoilla. Erityisesti taulukossa 3.5.1.1. esitetyt viitetunnus ja eCl@ss-luokitteet 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.

3.5.3. 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 Semogen-

luokittelujä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.

3.6. 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 3.6.1 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 3.6.2 näkyy VML:n valikko, jossa on suunnittelussa määritellyt toiminnot laitteelle.

(Ibid.)

38

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 3.6.1. 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.)

39

Kuva 3.6.2. Koneen suunnitteluinformaation selailu toimintojen avulla. Valikko on generoitu virtuaaliseen

konelaboratorioon semanttisesta mallista. (Ibid.)

Kuvassa 3.6.3 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.)

40

Kuva 3.6.3. 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.)

41

4. LOPUKSI

Datan tallennus ja hallinta ovat eräitä suurimmista haasteista konejärjestelmän suunnitteluprosessin aikana.

Käytäntöjä sekä tallennusformaatteja on useita erilaisia eivätkä käytössä olevat formaatit ole keskenään aina

yhteensopivia eikä kaiken tiedon tallentaminen ole aina edes fyysisesti mahdollista. Osa suunnitteluprosessin

aikana käytetystä sekä syntyneestä datasta voi olla huonosti tallennettu ja vaikeasti jälkeenpäin löydettävissä.

Edellä mainitun kaltaista dataa ovat esimerkiksi paperilehtiöille tehdyt piirustukset, yksittäiset tiedostot

esimerkiksi laskentaohjelmistoilla tehdyistä mitoituslaskuista tai pelkkä suunnitteluhenkilöstön kokemuksen

myötä syntynyt hiljainen tieto. Yhtenä ongelmana suunnitteludatan tallentamisessa on myös datan erilaisuus

aina 3D-CAD -malleista ja koneen työpiirustuksista ohjausjärjestelmien koodeihin ja sähkökaavioihin.

Toisena ongelmana on myös se, että kaiken tiedon tallentamista ei aina nähdä tarpeellisena ja sitä voidaan

pitää myös jopa turhana toimenpiteenä. Suunnittelutiedon hallintaan käytetään nykyään erilaisia PDM- ja

PLM-ohjelmistoja mutta näiden ohjelmistojen kirjo sekä tallennusformaatit ja käyttötavat ovat yhtä

moninaiset kuin niiden käyttäjät ja ohjelmistojen tuottajat. Tämä pätee myös varsinaisten

suunnitteluohjelmistojen kohdalla. Samankaltaisen tiedon tallennuskäytännöt ja formaatit saattavat olla

erilaiset jopa yhden yrityksen sisällä.

Semanttisessa suunnitteluprosessissa projektien seuraaminen ja suunnittelu sekä ennen kaikkea

suunnittelutiedon tallentaminen suoritetaan tavoilla jotka mahdollistavat näiden tekemisen koneellisesti ja

koneluettavassa muodossa mahdollisimman yhteensopivassa ja helposti löydettävässä muodossa. Näin

toimittaessa tietojen jakaminen ja hallinnointi on suhteellisen helppoa. Koneen tai laitteen kaiken

suunnittelutiedon tallentaminen voidaan aloittaa jo prosessin alussa jolloin suunnittelutieto päivittyy

prosessin edetessä ja näitä tietoja on tällöin helppo hyödyntää, suunnitteluprosessin monissa eri vaiheissa ja

tehtävissä, koneen tai laitteen koko elinkaaren ajan sekä uusien projektien pohjana. Semanttinen

suunnitteluprosessi kattaa siis parhaimmillaan kokonaisuudessaan koko tuotteen eliniän aina seuraavaan

tuotesukupolveen asti.

Semanttisen suunnitteluprosessin menetelmiä voidaan soveltaa on tuotetiedon tallennus ja tarjonta jo

tavarantoimittaja- ja alihankkijatasolta lähtien sekä tiedon tallennustapojen yhtenäistäminen. Eräs tällaisista

työkaluista voisi olla aiemmin esitelty komponentin semanttinen datalehti tai näistä koostuva koneen tai

laitteen semanttinen datakirjasto tai -puu joita käytettäisiin semanttisissa PDM- järjestelmissä.

Suunnittelutyöhön kuuluu usein erilaisten tuotteiden ja näiden tietojen etsintä. Suunnittelijoilla on usein

ohjeistus käyttää samoja komponentteja suunnittelemissaan laitteissa joita on valittu jo aikaisempiin

projekteihin. Tähän on yleensä syynä komponenttien tilauskannan pitäminen mahdollisimman

yksinkertaisena. Aiemmin valittujen komponenttien etsiminen erilaisilla PDM- ohjelmistoilla voi tällä

hetkellä olla usein hyvin hankalaa näiden riittämättömän dokumentoinnin, riittävien hakutoimintojen

puutteen sekä tietokantojen päällekkäisyyksien takia. Yleisesti puutteellisen dokumentoinnin syitä voi olla

useita mutta yleisimpiä ovat huono tai eriävä ohjeistus komponenttien dokumentointiin sekä riittämättömät ja

epäkäytännölliset työkalut tämän tekemiseen. Riittämätön, virheellinen tai puutteellinen tuotetiedon

dokumentointi PDM- järjestelmään johtaa usein siihen, että suunnittelija ei pysty löytämään tarvitsemaansa

komponenttia jolloin hän luo uuden nimikkeen komponenttia varten tai etsii korvaavan komponentin, jolle

luo uuden nimikkeen. Tällöin järjestelmään syntyy samalle komponentille useita nimikkeitä tai

vaihtoehtoisesti varastonimikkeiden reaalimääräkin kasvaa.

Monitekninen suunnittelijaryhmä tarvitsee kommunikaation ja suunnitteluratkaisujen tueksi

yhteistoiminnallisen, suunnitteludatalähtöisen, ajantasaisen ja simuloidun ympäristön. Ympäristö tulee olla

myös globaalisti saavutettavissa, koska toimijaverkosto ei toimi välttämättä samassa paikassa ja ajassa.

Semogen I ja II –hankkeet osoittavat, että tällainen ympäristö voidaan rakentaa ja vieläpä siten, että käsityön

42

määrää voidaan merkittävästi vähentää. Semiautomaattisten tuotantoprosessien ja etenkin semanttisesti

rikastutetun tuotteen elinkaaritiedon avulla voidaan ympäristön rakentamista merkittävästi tukea. Systems

Engineering –menetelmässä ajantasaiset mallit, visualisoinnit ja monialainen suunnitteluratkaisujen

tarkastelu on keskeistä. Tämän tyyppisiä ratkaisuja on suunnitteluohjelmistoihin ja tuotteen

elinkaarenhallinnan tuotteisiin viime vuosina lisätty.

Tuotteiden haun helpottaminen suunnittelijoille yritysten omissa PDM- järjestelmissä lisäämällä

semantiikkaa järjestelmään sekä tietojen tallentamisen ohjeistus ja työkalujen kehitys tähän voivat parantaa

työtehoa ja nopeuttaa projektien etenemistä huomattavasti, kun suunnittelijoilla ei mene enää ylimääräistä

aikaa pelkästään komponenttien hakemiseen.

Tuotetietojen kattava dokumentointi lisää mahdollisuuksia myös komponentin eri parametrien tallentamiseen

joita voidaan hyödyntää erilaisissa mitoituslaskuissa sekä simulointimallien generoinnissa. Jos myös nämä

eri laskenta- ja simulointiohjelmilla tehdyt laskut tallennettaisiin myös semanttiseen PDM: ään niin näitä

voitaisiin hyödyntää myös tulevissa projekteissa. Semantiikan lisääminen PDM- järjestelmiin auttaisi myös

laitteiden ohjekirjojen sekä markkinointimateriaalin teossa koska materiaali olisi helposti löydettävissä.

Eräs hyvin käyttökelpoiseksi sovelluskohteeksi semanttiselle PDM:lle todettiin työpajassa aikaisemman

suunnittelu- ja projektiaineiston käyttö uusien projektien suunnittelun ja tarjouspyyntöjen laadinnan apuna.

Tiedon helppo löytyminen auttaisi myös tällaisessa tilanteessa ja semantiikan lisääminen myös erilaisiin

PLM- järjestelmiin voisi olla hyvin hyödyllistä.

Suunnittelutieto on yhä enemmän verkottunutta, joten koko tuoteratkaisujen ekosysteemin pitäisi perustua

yhteensopivuuteen ja yhteisesti sovittuihin toimintamalleihin. Semanttisten datalehtien käyttöönotto antaisi

lähtökohdat koneluettavien metatietojen siirtämisestä laitteista sekä niiden osakokoonpanoista ja

komponenteista. Koneluettavien metatietojen siirtäminen semanttisilla datalehdillä vähentäisi potentiaalisesti

merkittävästi komponentteihin teknisiin yksityiskohtiin liittyvien tietojen manuaalista käsittelyä, joka on

työlästä ja virhealtista. Parhaimmillaan semanttisien datalehtien käyttöönotto voisi toimia mahdollistajana

uudenlaiselle, simulointi- ja prototypointivetoiselle koneensuunnittelulle. Semanttiset datalehdet voisivat

sisältää myös tietoa komponentteihin liittyvistä tietovaatimuksista, toimien tällä tavalla pohjana tai "ajurina"

suunnittelutiedon liittämiselle yksittäisiin komponentteihin. Tämä mahdollistaisi ohjatummin mm.

suunnittelutiedon validoinnin ja virheiden havaitsemisen, mikä vähentäisi edelleen virheitä ja niihin liittyvää

korjaustyötä.

Ekosysteemin kannalta keskeistä on myös nimikekeskeisyys. Semanttisen nimikkeidenhallinnan osalta

keskeinen vaatimus on nimikkeiden globaalisti yksikäsitteisten tunnisteiden muodostaminen. Käytännössä

tämä onnistuu hyödyntämällä esim. PDM:n olemassaolevaa URL-arkkitehtuuria. Ideaalitilanteessa

nimikkeen globaalisti yksikäsitteinen tunniste (URI) viittaisi linkitetyn datan suunnitteluperiaatteiden

mukaisesti samaan URL-osoitteeseen, jota suunnittelijat käyttävät viestiessään nimikkeistä

43

Semogen II -hankkeen kartoitusten ja empiiristen tulosten nojalla voidaan todeta, että konejärjestelmän

suunnittelun tukeminen virtuaalisen konelaboratorion ja semanttisen mallinnuksen avulla on toki 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. Yksittäistä organisaatiota suuremmassa mittakaavassa

kyse on ajattelutavan muutoksesta toimialueen laajuudessa. Tässä työssä Semogen II -hankkeen tuloksilla on

paljon annettavaa.

TTY:n Smart Simulators -tutkimusryhmä on liittänyt Semogen-hankkeisiin liittyvän kokonaisuuden

Engineering Intelligence Ecosystem -tutkimusteeman alle:

”Engineering Intelligence (EI) is the ability for an engineering organization to orchestrate processes related

to collaborative engineering, product lifetime information, competencies, and intelligence of products and

services with semantically rich, context-aware and intelligent ICT-solutions." (Lanz, Nykänen, Aaltonen,

Ranta, Koskinen & Andersson, 2013)”

Kuva 4.1. Engineering Intelligence Ecosystem -mallin havainnollistus tuotteen elinkaaren hallinnan,

yhteistoiminnallisten ja asiakaslähtöisten prosessien sekä älykkäiden ratkaisujen perustana. Mallin keskiössä

toimii yhteistoiminnallinen ja tuotteen elinkaaritiedon saumaton semanttisesti rikastutettu informaatiovirta

(Ibid.)

Vapaasti kääntäen, käsitteellä Engineering Intelligence tarkoitetaan teknistä kehitystyötä tekevän

organisaation kyvykkyyttä organisoida yhteistoiminnallista suunnittelua, tuotteiden elinkaaren hallintaan

liittyvää informaatiota, kompetensseja sekä tuotteisiin ja palveluihin liittyvää tietämystä semanttisesti

44

rikkailla, kontekstitietoisilla sekä älykkäillä ICT-ratkaisuilla. Tämä EI-ekosysteemi luo kokonaiskehyksen

sekä Semogen I ja II -hankkeille.

Kuvasta voidaan edelleen nähdä, että tällainen kokonaisvaltainen lähestymistapa edellyttää sekä käsitteellisiä

että toiminnallisia muutoksia yritysten, oppilaitosten ja asiakkaiden toiminnassa. Kyseessä on laaja

vallitsevan paradigman muutos kohti asiakaslähtöistä, monialaista (siilojen murros), ketterää, älykästä ja

tilannesidonnaista paradigmaa. Semogen –hankkeitten aikana havaittiin, että paradigman muutos on

todellista. Isossa mittakaavassa kyse on nimenomaan strategisen tason ajattelutavan muutoksesta.

Laajamittainen EIE-ajattelu ei voi täysin toteutua ilman kohtuullisen suuren toimialuekohtaisen

yrityskonsortion -- löyhemmin rajattuna ekosysteemin -- katalysoivaa tukea. Semogen2-työ on ollut

keskeisenä osana rakentamassa kivijalkaa uudentyyppiselle strategiselle tutkimus- ja kehityssuunnalle, joka

tätä kirjoittaessa on jo poikinut uusia tutkimusaloitteita.

Liiketoiminnan näkökulmasta avainasemassa tietenkin ovat ekosysteemin toimijoiden todelliset

liiketoiminnalliset tarpeet, mikä viime kädessä edellyttää esim. jaettujen konelaboratorioiden ja semanttisen

mallinnuksen kaupallistamisen pelisääntöjen kehittämistä -- tai kehittymistä. Tästä näkökulmasta katsottuna

Semogen II -hankkeella on paljon annettavaa paitsi aihepiirin jäsennyksen ja teknisten tulosten, myös

tasapainoisen tutkimuskonsortion toiminnasta saatujen positiivisten kokemusten ansiosta.

45

LÄHTEET

Airila, M. (1999). Mekatroniikka, Hakapiano Oy., Helsinki, s. 69.

Anon (2001). Systems Engineering Fundamentals. Defense Acquisition University Press, Fort Belvoir,

Virginia.

Allemang, D., Hendler, J. (2008). Semantic Web for the Working Ontologist, Modeling in RDF, RDFS and

OWL, Morgan Kaufmann Publishers Inc., USA, s. 330.

Berners-Lee, T. (2009). Linked Data - Design Issue. Saatavilla: http://www.w3.org/DesignIssues/LinkedData

Bishop, R. (2006). Mechatronics: An Introduction. Taylor & Francis.

Bizer, C., Heath, T., Berners-Lee, T. (2009). Linked Data — The Story So Far. International Journal on

Semantic Web and Information Systems. 5 (3): 1–22. doi:10.4018/jswis.2009081901. ISSN 15526283.

CiA (2006). CiA-406 - Device profile for encoders. Saatavilla: http://www.can-

cia.org/index.php?id=specifications

CiA (2005). CiA-306 - Electronic data sheet specification. Saatavilla: http://www.can-

cia.org/index.php?id=specification

CiA (2012). CAN in Automation -verkkosivusto. Saatavilla: http://www.can-cia.org/

Helminen, M. (2013). Koneluettavan CANopen-suunnitteluaineiston monitekninen hyödyntäminen.

Diplomityö. Tampere. Tampereen teknillinen yliopisto, tietotekniikan laitos.´

Helminen, M., Palonen, T., Rokala, M., Ranta., P., Mäkelä, T., Koskinen, K. T. (2011). Virtual Machine

Laboratory based on M1-technology. In: Proceedings of the Twelfth Scandinavian International Conference

on Fluid Power, vol. 1, pp. 321-334. May 18-20, 2011, Tampere, Finland.

IEC (2009a). IEC 81346-1 ed1.0 - Industrial systems, installations and equipment and industrial products -

Structuring principles and reference designations - Part 1: Basic rules.

IEC (2009b). IEC 81346-2 ed1.0 - Industrial systems, installations and equipment and industrial products -

Structuring principles and reference designations - Part 2: Classification of objects and codes for classes.

ISO (2012). ISO/TS 81346-3:2012 - Industrial systems, installations and equipment and industrial products -

- Structuring principles and reference designations -- Part 3: Application rules for a reference designation

system.

Kasser, J. E. (2010). Seven systems engineering myths and the corresponding realities. In: Proceedings of

the Systems Engineering Test and Evaluation Conference, Adelaide, Australia, 2010.

Lanz M., Nykänen, O., Aaltonen J., Ranta, P. A., Koskinen, K. T., Andersson, P. H. (2013; to appear).

Engineering Intelligence - Product-Service Concepts and Requirements in Industry. ISAM 2013.

International Symposium on Assembly and Manufacturing. Xi’an Jiaotong University (XJTU), School of

Mechanical Engineering. China 2013.

Lehtonen, T., Juuti, T, Oja, H., Suistoranta, S., Pulkkinen, A., Riitahuhta, A (2011). A framework for

developing viable design methodologies for industry. International Conference on Engineering Design,

ICED11 1, 405–416.

46

Nurmi, J. (2013). Datalähtöinen virtuaalinen konelaboratorio mekatronisen koneen yhteissuunnittelun

tukena. Diplomityö. Tampere. Tampereen teknillinen yliopisto, matematiikan laitos.

Nykänen, O., Salonen., J., Markkula, M., Ranta, P., Rokala, M., Helminen, M., Alarotu, V., Nurmi, J.,

Palonen, T., Koskinen, K. T., Pohjolainen, S. (2011). What Do Information Reuse and Automated

Processing Require in Engineering Design? Journal of Industrial Engineering and Management 4, 669–698.

Palonen, T., Leino, T., Koskinen, K. T., Ranta, P., Punki, J. & Mäkelä, T. (2007). Learning environment for

training the forest machine mechanics. In: Vilenius, J. & Koskinen, K. T. (Eds.): The Tenth Scandinavian

Conference on Fluid Power, May 21-23, 2007, Tampere, Finland.

Ranta, P., Nykänen, O., Salonen, J., Pohjolainen, S., Koskinen, K. (2011). Teollisuuden älykkäiden ja

virtuaalisten konelaboratorioiden tuotantomenetelmienkehitys semanttisen kuvauksen avulla. (205 s.).

Tampereen teknillinen yliopisto. Saatavilla: https://wiki.tut.fi/pub/SmartSimulators/Semogen/Semogen1-

loppuraportti.pdf (viitattu 28.06.2012)

Salonen, J., Nykänen, O., Ranta, P., Nurmi, J., Helminen, M., Rokala, M., Palonen, T., Alarotu, V.,

Koskinen, K., Pohjolainen S. (2011). An Implementation of a Semantic, Web-Based Virtual Machine

Laboratory Prototyping Environment. In: The Semantic Web – ISWC 2011, Lecture Notes in Computer

Science, 2011, Vol. 7032/2011, pp. 221-236. Available online. DOI: http://dx.doi.org/10.1007/978-3-642-

25093-4_15

SFS (2002). SFS-IEC/TR 61346-3 - Teollisuuden järjestelmät, asennukset ja laitteet sekä teollisuustuotteet.

Jäsentelyn periaatteet ja viitetunnukset. Osa 3: Soveltamisohjeet.

SFS (2009). SFS-EN 81346-2 - Teollisuuden järjestelmät, asennukset ja laitteet sekä teollisuustuotteet.

Jäsentelyn periaatteet ja viitetunnukset. Osa 2: Kohteiden luokittelu ja luokkia vastaavat koodit.

SFS (2010). SFS-EN 81346-1 - Teollisuuden järjestelmät, asennukset ja laitteet sekä teollisuustuotteet.

Jäsentelyn periaatteet ja viitetunnukset. Osa 1: Perussäännöt.

Smart Simulators (2011). Semogen Boom Lift Demo. Smart Simulators Research Group Wiki. Saatavilla:

http://wiki.tut.fi/SmartSimulators/SemogenBoomLift (viitattu 21.1.2013)

Variantum Oy (2012). Nimikehallinta – Kuinka pidän nimikekannan kurissa? Saatavilla:

http://www.variantum.com/joomla/fi/sovellukset/nimikehallinta (viitattu 16.5.2013)

VDI 2206 - Entwicklungsmethodik für mechatronische Systeme (Design methodology for mechatronic

systems)

VDI 2221 - Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte (Systematic

Approach to the Design of Technical Systems and Products)

VDI 2422 - Entwicklungsmethodik für Geräte mit Steuerung durch Mikroelektronik (Systematical

development of devices controlled by microelectronics)

W3C (2004). RDF/XML Syntax Specification (Revised). Saatavilla: http://www.w3.org/TR/2004/REC-rdf-

syntax-grammar-20040210/ (viitattu 4.3.2013)

47

LIITE 1: HANKKEESEEN LIITTYVÄT JULKAISUT

Helminen, M. (2013). Koneluettavan CANopen-suunnitteluaineiston monitekninen hyödyntäminen.

Diplomityö. Tampere. Tampereen teknillinen yliopisto, tietotekniikan laitos.

Helminen, M., Salonen, J., Saha, H., Nykänen, O., Koskinen, K. T., Ranta, P., Pohjolainen, S. (2012). A

New Method and Format for Describing CANopen System Topology. 13th International CAN Conference

(iCC), Hambach Castle, Germany.

Nurmi, J. (2013). Datalähtöinen virtuaalinen konelaboratorio mekatronisen koneen yhteissuunnittelun

tukena. Diplomityö. Tampere. Tampereen teknillinen yliopisto, matematiikan laitos. Saatavilla:

http://urn.fi/URN:NBN:fi:tty-201305221149

Nykänen, O., Koskinen, K., Ranta, P., Salonen, S., Rokala, M., Helminen, M., Nurmi, J., Sairiala, H.,

Alarotu, V., Aaltonen, J., & Pohjolainen, S. (2012). Semantic Top-Down Modeling of Mechatronics Systems

for Sustainable Product Data and Lifecycle Management. Proceedings of Mechatronics 2012, Sept. 17-19,

Linz, Austria, pp. 792-799.

Saha, H., Nykänen, O., Helminen, M., Salonen, J. (Eds.). (2011). Nodelist.graphml Format Specification,

December 13, 2011. Saatavilla: http://wiki.tut.fi/SmartSimulators/NodelistGraphML

48

LIITE 2: SANASTO JA TERMIT

Automaattinen generointi (automatic generation). Automaattisella generoinnilla tarkoitetaan yleisesti

sellaista automaattisen tietojenkäsittelyn menetelmää, jossa tuloksena syöteaineistosta syntyy

jatkokäsittelyyn soveltuva, generoitu artefakti. Vastakohtana automaattiselle generoinnille käytetään usein

manuaalista tietojen käsittelyä.

CANopen. Korkeamman tason kommunikaatioprotokolla- ja laiteprofiilimääritysperhe pääasiassa CAN-

laitteille.

Controller Area Network (CAN). Koneissa, ajoneuvoissa ja teollisuuslaitteissa käytetty vikasietoinen

automaatioväylä. Määritelty ISO 11898 standardissa.

Datalähtöinen (data-driven). Ohjelmiston tietorakenne on erillään ohjelmiston toimintalogiikasta.

Device Configuration File (DCF). Kuten EDS, mutta sisältää myös CAN-laitteen verkkokohtaiset

asetukset, kuten node ID:n, siirtonopeuden ja konfiguroitujen parametrien arvot. Tarkoitettu

laitekonfiguraation tallentamiseen. Määritelty CiA-306 standardissa.

Electronic Data Sheet (EDS). CANopen-laitteen koneluettava datalehti. Tallennettu INI-tyyppiseen

tiedostoformaattiin, joka kuvaa laitteen parametrien oletusarvot. EDS:ää määrittää standardi CiA-306.

Engineering Intelligence (EI). Käsitteellä Engineering Intelligence tarkoittaa teknistä kehitystyötä tekevän

organisaation kyvykkyyttä organisoida yhteistoiminnallista suunnittelua, tuotteiden elinkaaren hallintaan

liittyvää informaatiota, kompetensseja sekä tuotteisiin ja palveluihin liittyvää tietämystä semanttisesti

rikkailla, kontekstitietoisilla sekä älykkäillä ICT-ratkaisuilla (Vrt. Lanz, Nykänen, Aaltonen, Ranta,

Koskinen, Andersson, 2013).

Extensible Markup Language (XML). W3C:n määrittelemä merkkauskieli, jolla voidaan tuottaa

samanaikaisesti sekä koneen että ihmisen luettavia dokumentteja tai tietorakenteita.

Kehitysjono (Backlog). Järjestetty lista vaatimuksista ja muutostoiveista, joiden avulla työtä vaiheistetaan ja

eri vaiheita priorisoidaan. Se on myös ainoa lähde tuotteeseen toteutettaville vaatimuksille ja muutoksille.

Katso myös: tuotteen kehitysjono.

Luokittelujärjestelmä (Classification system). Yleisesti säännöstö, jonka perusteella tieto jaetaan luokkiin.

Esimerkiksi Vertex PDM-järjestelmässä VXCLASSIFICATION-luokittelujärjestelmä.

Linkitetty data (linked data). Joukko rakenteisen tiedon julkaisemiseen ja ristiinviittauksiin liittyviä hyviä

käytäntöjä erityisesti Web-ympäristöissä.

Resource Description Framework (RDF). W3C:n standardoima kuvailukieli tiedon vaihtoon sovellusten

välillä. Voidaan esittää useilla formaateilla mm. RDF/XML muodossa XML-pohjaisena sarjallistuksena.

Ontologia (Ontology). Formaali esitys tiettyyn toimialaan liittyvästä tietämyksestä, joka on jäsennetty

käsitteiksi ja näiden käsitteiden välisiksi suhteiksi. Ontologiaperustaisesti voidaan toteuttaa semanttista

mallinnusta, jolloin tiettyyn toimialaan liittyvää tietämystä voidaan käsitellä koneellisesti. Ontologian

ilmaisuvoima ja mahdollisuudet mitä sen avulla voidaan tehdä riippuvat siitä, minkälaisen kielen perusteella

ontologia kuvataan. Ontologiakielet ovat formaaleja ja pohjautuvat usein logiikkaan (1. kertaluvun logiikka,

engl. first-order logic).

49

Ontologiapalvelin (Ontology Server). Yleisnimitys sellaisille palvelinsovelluksille, jotka mahdollistavat

ontologia-pohjaisen tiedon hallinnan.

Process Data Object (PDO). CANopen-viestikehys reaaliaikaiseen tiedonsiirtoon yleensä anturien ja

toimilaitteiden välillä. Siirrettävä tieto voi olla esimerkiksi pyörimisnopeus, jännite, taajuus, virta, paine, jne.

Scalable Vector Graphics (SVG). XML-pohjainen formaatti kaksiulotteisen vektorigrafiikan esittämiseen

laite- ja sovellusriippumattomasti. W3C:n standardoima formaatti.

Semanttinen datalehti (Semantic datasheet). Dokumentti (tai formaatti), joka kuvaa komponentin tai

järjestelmän tekniset ominaisuudet myös tietokoneen ymmärtämässä muodossa.

Semanttinen malli (Semantic model). Käsitteellinen malli tarkasteltavasta kohteesta, jossa malliin on

sisällytetty tietoa myös sen kuvaaman informaation merkityksestä. Yksinkertaisimmillaan semanttinen malli

on lyhyt käsitteellinen kuvaus. Laajemmin se voi kuvata täsmällisesti ja kattavasti kohteen siten, että

kuvauksen sisältö on koneellisesti käsiteltävissä. Ilman semanttista mallia kahden erillisen tietokannan

yhdistäminen vaatii ihmisen tulkintatyötä tiedon semantiikasta, ja tulkinnan mukaan laaditun

sovelluskerroksen käyttöä. Jos tietokantoihin liittyvät semanttiset mallit kuvataan koneluettavassa muodossa,

voidaan tietojen yhdistäminen ja tulkinta tehdä ilman ihmisen työpanosta.

Semanttinen mallinnusmenetelmä (Semantic modeling method). Yleisnimitys kaikille menetelmille,

joilla pyritään muodostamaan semanttinen malli tarkasteltavasta kohteesta. Esimerkiksi

hydraulisuunnitteluun liittyvää käsitteistöä voidaan kartoittaa ja mallintaa semanttisen mallinnuksen eri

menetelmillä.

SPARQL Protocol and RDF Query Language (SPARQL). RDF-tietomallien kyselykieli (vertaa: SQL-

kyselykieli relaatiotietokannoissa).

Skeema (Schema). Tietojenkäsittelyssä skeemalla tarkoitetaan yleisesti täsmällistä kuvausta tietojen

jäsennysrakenteesta. Esimerkiksi relaatiotietokannan sisältämien taulujen rakenne voidaan kuvata

tietokannan skeemassa. Esimerkiksi autotietotietokannassa autot-tauluun voidaan kuvata, että kaikkiin rivien

kuuluu pakollisina kentät malli ja merkki.

Simulointimalli (Simulation model). Konejärjestelmän täsmällinen kuvaus siinä muodossa, että sen

perusteella järjestelmää tai sen osia voidaan simuloida. Simulointimallin tarkkuus ja laajuus vaihtelevat

käyttötarkoituksen mukaan. Esimerkiksi mekatronisesta konejärjestelmästä voidaan toteuttaa

opetustarkoituksiin soveltuva simulointimalli käytettäväksi osana virtuaalista oppimisympäristöä.

Tikettipohjainen asianhallintajärjestelmä (Issue tracking system). Yleisnimitys sovellukselle, jolla tietoa

voidaan organisoida tikettipohjaisesti. Tiketeiksi voidaan käyttötarkoituksesta riippuen valita

organisoitavaksi esimerkiksi suunniteltavaan järjestelmään liittyviä käyttötapauksia, vaatimuksia,

suunnittelutoimenpiteitä tai havaittuja virheitä. Esimerkiksi mekatronisen konejärjestelmän vaatimus- ja

suunnittelutiedonhallintaan voidaan soveltaa tikettipohjaista asianhallintajärjestelmää.

Tuotteen kehitysjono (product backlog). Esittää järjestettyä listaa tuotteeseen suunnitelluista piirteistä.

Esimerkiksi asiakaslähtöisen konejärjestelmätuotteen elinkaaren hallintaan liittyvän tuoteinformaation,

prosessien, yhteistoiminnan, älykkyyden ja osaamisen linkittävä läpäisevä tutkimusala. Perustuu systems

engineering periaatteisiin.

Virtuaalinen konelaboratorio (Virtual machine laboratory). Virtuaalinen konelaboratorio tukee

konejärjestelmän suunnittelua, koulutusta ja tuotteen elinkaarenhallintaa dynaamisten simulointien,

50

virtuaalinäkymien, informaatiohakujen, moniteknisten informaationäkymien, järjestelmäinformaation sekä

työelämälähtöisten skenaarioiden avulla.

Web Ontology Language (OWL). Standardoitu ontologiakieli, jossa tietämyksen mallinnus pohjautuu

vahvasti olemassaolevan web-arkkitehtuurin hyödyntämiseen. Esimerkiksi mekatroninen konejärjestelmä ja

siihen liittyvää suunnittelutietoa voidaan mallintaa OWL-kielellä.

World Wide Web Consortium (W3C). Kansainvälinen yritysten ja yhteisöjen yhteenliittymä, joka ylläpitää

ja kehittää WWW:n standardeja ja suosituksia.