Upload
dinhcong
View
234
Download
0
Embed Size (px)
Citation preview
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.