1. No category

Teollisuuden älykkäiden ja virtuaalisten
konelaboratorioiden tuotantomenetelmien
kehitys semanttisen kuvauksen avulla
Semogen-hanke
Loppuraportti
Tampereen teknillinen yliopisto
Smart Simulators –tutkimusryhmä
21.11.2011
1
Esipuhe ................................................................................................................................................. 4
Tiivistelmä ........................................................................................................................................... 6
Lyhenteet .............................................................................................................................................. 7
OSIO I .................................................................................................................................................. 8
Loppuraportti ....................................................................................................................................... 8
1. Johdanto ........................................................................................................................................... 9
2. Semanttinen suunnitteluprosessi .................................................................................................... 12
3. Konejärjestelmän suunnitteluaineiston semanttinen mallinnus ..................................................... 17
3.1. Yleiskatsaus aineistoon ja tutkimustapauksen rajaus.............................................................. 17
3.2. Hydrauliikkasuunnittelu .......................................................................................................... 20
3.2.1. Hydrauliikkasuunnitteluaineisto ...................................................................................... 20
3.2.2. Aineiston rikastaminen .................................................................................................... 20
3.2.3. Aineiston siirto ................................................................................................................. 21
3.2.4. Hydrauliikkasuunnitteluaineiston semanttinen mallinnus ............................................... 22
3.3 CAN-suunnittelu ...................................................................................................................... 24
3.3.1. CAN-aineisto ................................................................................................................... 24
3.3.2. CAN-aineiston semanttinen mallinnus ............................................................................ 24
3.4 3D-suunnittelu ......................................................................................................................... 26
3.4.2. 3D-aineiston rikastaminen ............................................................................................... 26
3.4.3. Automaattisen generoinnin haasteet 3D:ssä .................................................................... 27
3.4.4. Semogen 3D CAD-ohjelmistolaajennus .......................................................................... 29
3.4.5. Semanttinen malli ............................................................................................................ 30
3.5 Suunnittelutietojen integrointi.................................................................................................. 32
3.6 Simulointimalliaihiot ............................................................................................................... 34
3.6.1. Simulink-aihioista ja niiden generoinnista ....................................................................... 34
3.6.2. Simulointiohjelmistoista .................................................................................................. 35
3.6.3. Komponenttipohjaisen simulointimallin matematiikkaa ................................................. 36
4. Pilot-ympäristö ja sovellustapaus................................................................................................... 38
4.1. Pilot-ympäristö ........................................................................................................................ 38
4.1.1. Eclipse-kehitysympäristö (Semogen Manager) ............................................................... 39
4.1.2. Tiedonkäsittelyn putkilinja (Semogen Processor) ........................................................... 41
4.1.3. Semoplayer (Semogen Player) ......................................................................................... 42
4.2. Sovellustapaus ......................................................................................................................... 44
4.2.1. Käyttöliittymä .................................................................................................................. 44
2
5. Tiedotus ja liiketoimintahyödyt ..................................................................................................... 49
5.1. Tiedotus ................................................................................................................................... 49
5.2. Liiketoimintahyödyt ................................................................................................................ 50
5.3. Kaupallistamismalli ................................................................................................................ 52
6. Johtopäätökset ................................................................................................................................ 53
6.1.Viitekehys ................................................................................................................................ 53
6.2.Suunnittelumalleista ................................................................................................................. 54
6.3. Semanttinen mallinnuksen teknologiat ................................................................................... 55
6.4. Tuotetiedon hallinta ................................................................................................................ 56
6.5. Simulointipohjainen suunnittelu ............................................................................................. 57
6.6. Virtuaalisen konelaboratorion teknologiat .............................................................................. 57
6.7. Hyödyt, vaikuttavuus ja tulevaisuuden näkymät .................................................................... 58
6.8. Yhteenveto .............................................................................................................................. 59
Lähteet ................................................................................................................................................ 60
Julkaisut: ............................................................................................................................................ 62
3
Esipuhe
Tämä on Teollisuuden älykkäiden ja virtuaalisten konelaboratorioiden tuotantomenetelmien kehitys
semanttisen kuvauksen avulla - Semogen-hankkeen loppuraportti. Semogen-hankkeessa tutkittiin
konejärjestelmän semanttisia kuvausmenetelmiä, mallien automaattista generointia ja älykkäitä
piirteitä sekä niiden soveltamista virtuaalilaboratorioprototyypin kehitykseen. Hankkeen punaisena
lankana on virtuaalisten konelaboratorioiden tuotantomenetelmien tutkimus.
Tämä raportti jäsentää ja kuvaa Semogen-hankkeen tutkimustyön, tulokset sekä tulosaineistot. Se
perustuu kesäkuussa 2010 kootun selvitysraportin (Ranta et al., 2010), joulukuussa 2010 tuotetun
väliraportin (Nykänen et. al 2010) sekä vuoden 2011 tutkimustyöhön. Raportin tavoitteena on
kuvata hankkeen teoreettiset näkökulmat, tapaustutkimuksen toteutus, alueittaiset tulokset sekä
kiteyttää johtopäätökset. Raportti jakautuu kolmeen osioon seuraavasti: Osio I Loppuraportti, Osio
II väliraportti 12/2010 6/2010 ja Osio III selvitysraportti. Loppuraportissa pelkistetään, käsitellään
kohdattuja ongelmia ja niiden ratkaisuja sekä viitataan tarvittaessa muihin osioihin.
Hankekonsortion muodostivat AEL, Etteplan Design Center Oy, Sandvik Mining and Construction
Oy, Tampereen teknillinen yliopisto, Tuotekehitys Tamlink Oy sekä Vertex Systems Oy. Hanke
haluaa kiittää yrityskonsortion rahoitus- ja asiantuntijapanoksesta sekä Teknologiateollisuuden 100vuotissää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, Pauli
Lappalainen AEL, Pekka Anttonen Sandvik Mining and Construction Oy, Raimo Kivioja Etteplan
Design Center Oy, Juha Leppänen Tuotekehitys Tamlink Oy, Seppo Pohjolainen
TTY/Matematiikan laitos/Hypermedialaboratorio ja Kari T. Koskinen TTY/Hydrauliikan ja
automatiikan laitos. Hankkeen työpajoihin ovat osallistuneet: AEL: Pasi Kaskinen, Harry Nordman
ja Eeva Varhomaa, Sandvik Mining and Construction Oy: Pekka Anttonen, Heikki Saha, Tero
Alatala, Jussi Puura ja Mikko Valtee, Vertex Systems Oy: Manu Lammela, Jorma Salli ja Erkki
Laitinen, Etteplan Design Center Oy: Mikko Gratschew, Jari Tiittanen, Tomi Martikainen, Antti
Peltola sekä TKE Oy: Timo Kesti ja Patrik Nylund.
Hankkeen tutkimusosapuolten edustajat: TTY/Matematiikan laitos/Hypermedialaboratorio
professori, hankkeen johtaja Seppo Pohjolainen, dosentti Ossi Nykänen, projektipäällikkö Pekka
Ranta, tutkija Janne Punki, tutkija Jaakko Salonen, tutkimusapulainen Juha T. Nurmi ja
tutkimusapulainen Jukka-Pekka Humaloja. TTY/Hydrauliikan ja automatiikan laitos professori Kari
T. Koskinen, tutkija Timo Leino, tutkija Markus Rokala, tutkija Mikko Markkula, tutkija Tuija
Palonen, tutkija Vänni Alarotu ja tutkimusapulainen Matti Helminen.
Loppuraportin ovat toimittaneet: Pekka Ranta, Ossi Nykänen, Jaakko Salonen, Seppo Pohjolainen
ja Kari T.Koskinen.
Hankkeen wiki-sivu löytyy osoitteesta: https://wiki.tut.fi/SmartSimulators/Semogen
4
Tämän teoksen käyttöoikeutta koskee Creative Commons Nimeä 3.0 Muokkaamaton –lisenssi
<http://creativecommons.org/licenses/by/3.0/>.
5
Tiivistelmä
Teollisuuden älykkäiden ja virtuaalisten konelaboratorioiden tuotantomenetelmien kehitys
semanttisen kuvauksen avulla (Semogen)-hankkeessa tutkittiin menetelmiä, malleja ja
teknologioita, joiden avulla voidaan tuotantoprosessia kehittää semiautomaattiseksi. Tampereen
teknillisen yliopiston Smart Simulators -tutkimusryhmä on rakentanut virtuaalisia
konelaboratorioita työkoneasentajan osaamisen kehittämisen tueksi. Virtuaalinen konelaboratorio
luo mahdollisuuden "nähdä toimivan koneen sisälle", jotta konejärjestelmiä voidaan ymmärtää,
tarkastella, opiskella, diagnosoida, testata ja prototypoida. Se sisältää dynaamisia
reaaliaikasimuloituja mittaus- ja testaustyövälineitä ja rikkaita konejärjestelmänäkymiä.
Tuotantomenetelmien kehityksessä semanttinen mallinnus eli linkitetyn, koneluettavan ja rikastetun
tiedon formaali hyödyntäminen loi mielekkään viitekehyksen. Konejärjestelmien osalta tämä
tarkoittaa aitojen suunnitteludokumenttien informaation käsittelyä, yhdistämistä, rikastamista sekä
mallinnusta, jotta saadaan rakennetua konejärjestelmän yhtenäinen, linkittynyt ja koneluettava
kokonaismalli, jonka avulla voidaan virtuaalisia konelaboratorioita rakentaa. Teknologioiden ja
menetelmien lisäksi suunnitteluaineiston laatu ja tuotantoprosessi nousevat keskiöön.
Hankkeen tutkimusmenetelmänä käytettiin tapaustutkimusta, jossa hyödynnetiin aitoja
kallioporauslaitteen suunnitteluaineistoja ja suunnitteluohjelmistoja (mekaniikka, CANväylä,
hydrauliikka, viitetunnuslista, tuotetieto). Erityisen edustavaksi aineistoksi soveltui CANopenjärjestelmäkuvausaineisto, jossa koneluettavuus on sisäänrakennettuna. Tapaus rajautui puomin
nosto-teknologioihin. Näiden ympärille rakennettiin putkilinjasto, jossa sovittimien ja
rikastusvaiheiden avulla saatiin suunnittelutieto virtaamaan kokonaismalliksi. Lisäksi hankkeessa
mallinnettiin luonnollista suunnitteluprosessia asiantuntijayhteistyönä, jotta suunnitteluprosessiin
voidaan implementoida semanttisen mallinnuksen vaiheita (semanttinen prosessi).
Hankkeessa rakennettiin semanttisen mallinnuksen ja suunnitteluaineistoa käsittelevien
teknologioiden avulla selainpohjainen virtuaalisen konelaboratorion prototyyppi, jonka avulla
voidaan demonstroida reaaliaikasimuloituja tapahtumia, semanttista hakua, konejärjestelmän
linkityksiä sekä toimintaketjuja. Teknologiat vaikuttavat lupaavilta ajatellen tuotantomenetelmien
automatisointia. Luonnollisesti menetelmä-, malli- ja prototyyppikehityksen lisäksi tarvitaan
varsinaisen tuotantoprosessin määritys- ja teknologiavalintatoimenpiteet.
Hankkeen tulokset osoittavat, että malleja, menetelmiä ja teknologioita voidaan hyödyntää
konejärjestelmän suunnittelun tukena. Myös hankkeen teollisuuskumppanit tunnistivat uuden
avauksen merkityksen. Tämä mahdollistaa virtuaalisen tarkentuvan prototyypin kehittämisen sekä
luo uuden ulottuvuuden tuotteen elinkaaritiedon hyödyntämiseen ja hallintaan. Tulosaineistojen
implementoinnissa tulee huomioda teknisen tiedon hallinnan suunnittelijan (knowledge engineer)
tarve.
Hanke toteutettiin yhteistyönä yritysten kanssa ja rahoituksesta vastasivat sekä
Teknologiateollisuuden 100-vuotissäätiö sekä yritykset AEL, Etteplan Design Center Oy, Sandvik
Mining and Construction Oy sekä Vertex Systems Oy.
6
Lyhenteet
API
Application Programming Interface
CAD
Computer-Aided Design
CAN
Controller Area Network
DBC
CAN Database File
DCF
Device Configuration File
EDS
Electronic Data Sheet
HTML
Hypertext Markup Language
IDE
Integrated Development Environment
JavaScript
Selainten yleisesti tukema ohjelmointikieli
MDL
Simulink Simulation Model
OWL
Web Ontology Language
PDM
Product Data Management
PLC
Programmable Logic Controller
PLM
Product Lifecycle Management
RDF
Resource Description Framework
RDF/XML
RDF/XML Syntax Specification
RDFS
Resource Description Framework (RDF) Schema Specification
SemoPlayer
Hankkeessa toteutettu näytinsovellusprototyyppi
SKOS
Simple Knowledge Organization System
SPARQL
SPARQL Query Language for RDF
STEP
Standard for the Exchange of Product Model Data
SVG
Scalable Vector Graphics
URI
Uniform Resource Identifier
WebGL
Web-based Graphics Language
X3D
Extensible 3D, XML-pohjainen kuvauskieli 3D-grafiikalle
X3DOM
JavaScript-kirjasto X3D-mallien katseluun selaimessa
XML
Extensible Markup Language
XSLT
Extensible Stylesheet Language (XSL) Transformation
7
OSIO I
Loppuraportti
8
1. Johdanto
Kone- ja automaatiojärjestelmien osaamisen kehittäminen, suunnittelu, kunnossapito sekä T&Kprosessi vaativat fyysisten laitteiden ja prototyyppien rinnalle virtuaalisia näkymiä. Järjestelmän
toimintaa tulisi voida tarkastella järjestelmä-, alijärjestelmä-, komponentti- ja jopa osatasoilla sekä
näiden toiminnallisina ja rakenteellisina teknologiayhdistelminä. Tampereen teknillisen yliopiston
Smart Simulators -tutkimusryhmä on rakentanut teollisuuden, oppilaitosten sekä
kunnossapitoasiantuntijoiden yhteistyönä virtuaalisia konelaboratorioita liikkuvan työkoneasentajan
osaamisen kehittämisen tueksi. Virtuaalinen konelaboratorio luo mahdollisuuden "nähdä toimivan
koneen sisälle", jotta konejärjestelmiä voidaan ymmärtää, tarkastella, opiskella, diagnosoida, testata
ja prototypoida. Se sisältää dynaamisia reaaliaikasimuloituja työvälineitä ja näkymiä, kuten
visualisoidut kaaviot, 3D-näkymät, mittaus- ja testausvälineet sekä konejärjestelmän
muokkauseditorin toimintojen ja vikojen hallintaan. Lisäksi simuloitua aikaa voidaan hidastaa,
tapahtumia nauhoitta, tarkistella osaluettelon, kaavion ja 3D-näkymän yhteyksiä, tarkistella
moniteknisiä
toimintoketjuja
sekä
hallita
tehtäväkuvauksia.
Viimeisimmissä
konelaboratorioversioissa on hyödynnetty selainpohjaisia teknologioita, jolloin tulevaisuudessa
web-teknologiat tarjoavat mahdollisuuksia konejärjestelmien opiskeluun, tarkasteluun ja
analysointiin verkon välityksellä. Luonnollisesti simulointi- ja 3D-mallien jakelu verkon kautta on
haasteellista.
Virtuaalisten konelaboratorioiden kehitys on vaatinut runsaasti eri alojen ammattilaisia sekä erittäin
paljon käsityötä. Tämän vuoksi tuotantomenetelmien automatisoinnille, informaation uudelleen
käytölle, tuotantoprosessien tehokkuudelle sekä moniteknisen tiedon integroinnille ilmeni suuri
tarve. Tämä tarve toimi Semogen-hankkeen eli "Teollisuuden älykkäiden ja virtuaalisten
konelaboratorioiden tuotantomenetelmien kehitys semanttisen kuvauksen avulla" perustana.
Tuotantomenetelmien kehityksessä semanttinen mallinnus eli linkitetyn, koneluettavan ja rikastetun
tiedon formaali hyödyntäminen loi mielekkään viitekehyksen. Konejärjestelmien osalta tämä
tarkoittaa aitojen suunnitteludokumenttien informaation käsittelyä, yhdistämistä, rikastamista sekä
mallinnusta, jotta saadaan rakennettua konejärjestelmän yhtenäinen, linkittynyt ja koneluettava
kokonaismalli, jonka avulla voidaan virtuaalisia konelaboratorioita rakentaa.
Semanttinen mallinnus ei ole uusi ajatus, vaan semanttista mallinnusta ja laskentaa on tutkittu mm.
ohjelmistotekniikassa, lääketieteessä sekä webin standardeissa (W3C, 2006; W3C, 2009a; W3C,
W3C, 2009b; W3C, 2011). Näissä useiden tiedon kuvailukielten ja formaalien käsitemallien eli
ontologioiden, joka tarkoittaa valitun sovellusalueen kuvaavia käsitteitä ja käsitteiden välisiä
suhteita, hyötyjä on merkittävästi tunnistettu. Julkishallinnon puolella on tänä vuonna (6/2011)
astunut voimaan tietohallintolaki tietohallinnon yhteentoimivuudesta, jolla tarkoitetaan
lakiluonnoksen mukaan sitä, että tietojärjestelmät ovat teknisesti ja semanttisesti yhteentoimivia
muiden julkisen hallinnon viranomaisten tietojärjestelmien kanssa, silloin kuin ne käyttävät samoja
tietoja. Konejärjestelmän semanttinen mallinnus toimii analogiana julkishallinnon kanssa, koska
yhteensopivuus ja digitaalisesti saumaton tuoteprosessi ovat tavoitteena. Mikäli tietojärjestelmät
eivät ole yhteensopivia ja informaatiota tuotetaan moneen kertaan tuotteen elinkaaren aikana,
tuotantoprosessi ei ole tehokas. Tämä on todettu myös TEKES:n digitaalinen koneenrakennus –
ohjelmassa (DTP).
9
Kokonaisuudessaan semanttinen mallinnus ei riipu vain teknologioista, vaan myös
tuotantoprosessin laadusta. Koneensuunnittelussa suunnittelijat keskustelevat suunnittelupiirrosten
ja dokumenttien avulla, mutta koneluettavan ja semanttisesti eheän lähdeaineiston valossa, ihmisten
kommunikaatio ei riitä etenkään, kun osa tiedoista välittyy puheena, hiljaisina sopimuksina,
erillisissä ohjeissa sekä toimintakulttuurina. Suunnitteluprosessin järjestelmällisyys ja laatu luovat
perustan saumattomalle ja tuotteen elinkaaren aikaiselle tiedon hallinnalle.
Semogen-hanke edustaa uutta avausta lähestymistavoiltaan sekä teknologiavalinnoiltaan.Tätä
hanketta lähimpinä on Simantics-projekti, jossa luotiin moderni simuloinnin integrointiympäristö ja
välineitä semanttiseen mallikonfiguraatioiden määrittelyyn (Simantics, 2010). Lisäksi TiKoSu Tietokantakeskeinen koneenohjausjärjestelmän suunnittelu -hankkeessa on tarttumapintoja (VTT,
2011). Kansainvälisesti tarkastellen esimerkiksi konejärjestelmien yhteensopivuus ovat laajalti
kiinnostusta herättävä alue (AutomationML, PLC Open, CAN in Automation). Vaikuttaa siltä, että
alueen tutkimus ja kehitys on voimakkaasti kasvussa, koska hyödyntämispotentiaali alueella on
merkittävä.
Semogen-hanke
lähestyi
moniteknisen
suunnitteluaineiston
yhdistämisen
aihepiiriä
ruohonjuuritasolta käsin eli miten aitojen suunnitteluaineiston yhteensopivuus olisi mahdollista
rakentaa. Tämä konkretisointi luo vahvan maadoituksen todellisiin haasteisiin, jolloin myös haasteet
ja pullonkaulat voidaan tunnistaa. Ylätason vaihtoehtoisen mallin luominen vaatisi laajaa
neuvottelua ja erilaisia kompromissejä. Tähän hankkeen resurssit eivät riitä, joten edustavan
tapauksen avulla lähestyminen voidaan pohtia tulosten laajempaa siirrettävyyttä. Olennaista on, että
miten työvälineet, ohjelmistot ja toimintamallit saadaan keskustelemaan yhteisten rajapintojen
kautta. Suomalaisen koneenrakennuksen kannalta virtuaalinen prototypointi, suunnitteluaineistojen
semanttinen mallinnus sekä suunnitteluprosessien laadun kehittäminen luo mahdollisuuksia
keskittyä erilaisten asiakassegmenttien huomiointiin sekä suunnittelun tehokkuuden kehittämiseen.
Laajemmin tarkasteltuna Semogen-hankkeella on yhteyksiä virtuaaliprototypointiin, mekatronisiin
koneensuunnittelumalleihin, suunnittelutiimin moniteknisen osaamisen hallintaan ja tuotetiedon
elinkaaren hallintaan. Näitä ovat älykkäät varaosakirjat, mukautuvat huoltotoimenpideohjeet,
konfiguraation
muutosten
arviointi
ja
konejärjestelmän
tuotetiedon
hallinta.
Suunnitteluinformaation uudelleen käyttö, koneluettavuus, teknologiaintegrointi sekä validius ovat
vaikuttamassa sekä liiketoimintamallehin sekä vaadittavaan osaamiseen.
Tämä Semogen-hankkeen loppuraportti luo katsauksen todellisiin suunnitteluaineistoihin
perustuvan semanttisen mallinnusprosessin, työvälineiden, teknologioiden sekä menetelmien
mahdollisuuksista virtuaalisten konelaboratorioiden tuotantomenetelmistä mutta myös laajemmin
koneensuunnittelun tulevaisuuden mahdollisuuksista. Hankeyhteistyö teollisuuskumppanien kanssa
on mahdollistanut tutkimustulosten maadoittamisen käytäntöön. Loppuraportti jakautuu kolmeen
osioon. Osio 1 koostaa hankkeen tulokset yleisemmällä tarkastelutasolla sekä ohjaa lukijaa
tarkemman tiedon luo. Osio II kuvaa hankkeen väliraportin, jossa käsitellään yksityiskohtaisesti
semanttista mallinnusta ja prosessia, työvälineitä, mallinnusmenetelmiä, teknologioita sekä
aineistojen yhteensopivuutta. Tämä on kirjoitettu 12/2010. Osio III kertoo hankkeen
selvitysvaiheesta, jossa orientoiduttiin monitieteiseen alueeseen sekä tunnistettiin sovellustapauksia.
Liitteissä on kuvattu hankkeen tieteelliset julkaisut sekä viittauksen aineistoihin.
10
Hankekonsortio toivottaa lukijoille antoisia hetkiä. Loppuraportin lisäksi hankkeen tulosaineisto on
saatavilla avoimesti hankkeen web-sivuilta.
11
2. Semanttinen suunnitteluprosessi
Kirjoittaja: Ossi Nykänen
Suunnitteluprosessi tähtää annetun suunnittelutehtävän täyttämiseen sille osoitetut reunaehdot ja
resurssit huomioiden. Koneensuunnittelussa voidaan tyypillisesti tunnistaa seuraavat vaiheet
(Norton, 2006):










Identification of need
Background research
Goal statement
Task specifications
Synthesis
Analysis
Selection
Detailed design
Prototyping and testing
Production
Yksityiskohtaiset suunnittelukäytänteet ja ohjeet kuitenkin vaihtelevat eri toimialoilla. Vaiheiden
taustalla vaikuttavat vahvasti tehtävänanto, työkulttuuri sekä mm. suunnitteluinformaatiolle
asetettavat tieto- ja jatkokäyttötarpeet. Perinteisen suunnittelun hiljaisina olettamuksina --- ja siten
suunnittelijoille annettavien työtehtävien rajauksina --- näyttävät usein olevan valmistusvaiheen
tietotarpeiden korostaminen sekä lähtökohtainen olettamus (ihmis)suunnittelijoiden roolista
kaikenlaisessa tiedon tulkinnassa. Tällöin haasteiksi voivat muodostua muiden tehtävien
tietotarpeiden tyydyttäminen (esim. simulointi, dokumentointi, koulutus, huolto, yms.) sekä tiedon
koneellisen käsittelyn ongelmat (suunnitteluaineisto koostuu tyypillisesti ihmisen tulkintaa
vaativista piirroksista ja narratiivisista dokumenteista).
Semogen-hankkeen punaisena lankana on virtuaalisten konelaboratorioiden tuotantomenetelmien
tutkimus. Kun suunnittelutehtävään siten sisällytetään vaatimus linkitetyn ja uudelleenkäytettävän
tiedon tuottamisesta, nousee näkökulma yksittäistä suunnitteluprojektia yleisemmälle ja
toistettavalle tasolle. Kun tavoitteena on lisäksi suunnitteluinformaation koneluettavuus ja
automaattinen tietojen käsittely myös tiedon merkityksen tasolla, voidaan suunnitteluorganisaation
liiketoimintaprosessin, projektikäytänteitä ohjaavan metasuunnitteluprosessin ja yksittäisten
suunnitteluprosessien rinnalle nostaa semanttinen prosessi (Nykänen et al., to appear, ks.myös osio
II, Semogen-väliraportti).
Kuva 2.1. Intuitiivinen ja yksinkertaistettu esimerkki semanttisesta prosessista
Semanttisen prosessiajattelun perusidea on tunnistaa eri suunnittelutehtävien välisiä
informaatiorajapintoja (ks. kuva 2.1) siten, että tuotantomenetelmän edellyttämä tiedon
12
koneluettavuus ja jatkokäsiteltävyys toteutuvat paitsi tietorakenteiden, myös niiden
sovelluskohtaisen tulkinnan näkökulmasta. Kuva 2.2 esittää semanttisen prosessin käsitteelliset
rakenneosat. Tässä suunnitteluinformaatio virtaa prosessin eri aktiviteettien (A) välillä
käsittelyaskelien tehtävien (T) sovittamana. Eri suunnitteluaktiviteettien rajapintojen formaali
määritys perustuu sopimuksiin informaatiorajapinnat (C) ja informaatiotarpeet (R) mallintavista
skeemoista. Näin kunkin suunnitteluaktiviteetin edellyttämän informaatioon saatavuus on
mahdollista tarkistaa ja tietorakenteilla on yhteinen, koko suunnitteluprosessin läpäisevä tulkinta.
Tiedot eivät siten linkity toisiinsa vain tietorakenteiden tasolla, vaan myös linkityksen merkitys
konelaboratoriosovelluksen kannalta on tunnettu ja sama tieto voi esiintyä käsittelyn eri vaiheissa
eri rooleissa. (Semanttisen prosessin määrittelyä ja toteutusta on tarkasteltu lähemmin
väliraportissa.)
Kuva 2.2. Koneluettavaan tiedon hyödyntämiseen tähtäävän semanttisen prosessin stereotyyppinen rakenne
Semanttinen prosessiajattelu auttaa ymmärtämään, ohjeistamaan ja johtamaan mitä
(suunnittelu)tietoja projekteissa ylipäänsä tulisi kerätä ja hallinnoida. Se osaltaan osoittaa myös
välineitä ja konkreettisia vaatimuksia yksittäisen suunnitteluprojektin aktiviteettien
informaatiorajapinnoille. Tällöin esimerkiksi konelaboratorion generointitehtävän näkökulmasta
hydrauliikka-, 3D- ja simulointisuunnittelutehtävien tietojen tulisi linkittyä toisiinsa, ja sisältää
tarpeelliset tiedot simulointimallin generointia silmälläpitäen. Käytännöllisinä haasteina ovat
kuitenkin koneluettavan mallinnuksen sopivan tarkkuustason löytäminen sekä kompleksisuuden
hallinta.Tämä edellyttää tietämyksen ja informaation hallintaan keskittyvän informaatioarkkitehdin
tai -insinöörin (knowledge engineer) työroolin tunnistamista.
Hyvin konkreettisena havaintona voidaan todeta, että Semogen-hankkeessa informaation "master"järjestelmäksi muodostui semanttisen prosessin tarvitsevat tiedot kokoava version- ja
projektinhallintajärjestelmä (SVN ja Eclipse IDE), johon rakennettiin tapaustutkimusten
edellyttämät skeemat ja käsitemallit, ja jonne tietoa kuvatiin ja linkitettiin erinäisistä suunnittelun
perusjärjestelmistä (esim. CAD). Näin semanttinen prosessi näyttäytyi käytännössä putkilinjaston
määrittelynä, jota suoritettiin Apache Ant -prosessorilla. Tällä tavoin määriteltynä semanttisen
prosessin implementoiva putkilinjasto hoiti siten sekä informaatiorajapintojen tarkistuksen että
virtuaalisen konelaboratorion komponenttien (esim. simulointi- ja visualisointimallit) generoinnin
tehtävät. Generoidun konelaboratorion komponentteja suoritettiin erillisessä selainpohjaisessa
Semogen Player -sovelluksessa, mikä mahdollisti esim. koulutuksen ja virtuaaliprototypoinnin
tehtävien testauksen.
Semogen-projektissa selvitettiin myös nykyisten luonnollisten suunnitteluprosessien osa-alueita (ks.
osio II, Semogen-väliraportti). Tulosten analysoinnissa nousi esille kontekstisidonnaisuus. Eri
yritykset työskentelevät eri tavoin, eikä esim. jo kertaalleen tuotetun informaation jatkojalostamista
koneellisen käsittelyn edellyttämään muotoon ollut tyypillisesti otettu huomioon. Osasyynä tähän
13
oli mm. edellä mainitun "master"-suunnittelujärjestelmän puuttuminen, minkä seurauksena tietoja
tyypillisesti kertyi eri järjestelmiin eri muodoissa.
Semogen-projektiin valitun tapaustutkimuksen (ns. puomin nosto -tapaus) kautta tätä
ongelmakenttää oli kuitenkin mahdollista tarkemmin avata ja analysoida. Kun aihepiirin
suunnitteluprosesseja eri menetelmin (mm. class-responsibility-collaboration -tyyppisellä
analyysillä) iteroitiin sekä pienryhmä- että työpajatasolla, päädyttiin seuraavankaltaiseen
jäsennykseen. Hyvänä pidettävän "Semogen"-suunnitteluprosessin osaprosesseja ovat tällöin mm.
• Konseptisuunnittelu
• Suunn.ratkaisun tavoitteiden ja reunaehtojen määritys
• Teknologioiden ja peruskomponenttiratkaisujen valinta
• Virtuaaliprototypointi
• Järjestelmäsuunnittelu
• "Järjestelmäarkkitehtuurin" valinta
• Konfiguraatioiden ja laiterajapintojen määrittely
• Laitteen toiminnallinen kuvaus, vikaantumismallinnus, turvallisuusanalyysi
• Nimikkeiden hallinta (nimet, standarditermit, eheys, luominen ja ylläpito)
• Semanttinen yhtenäisarkkitehtuuri
• Ylätason käsitemallin ja viittausrakenteen (terminologia) suunnittelu
esiintymätiedolle
• Ensisijaisesti sovellettavien sanastojen valinta ja esiintymätiedon
nimeämiskäytännön määrittely
• Semanttisen putkilinjaston ja loppusovellusten
validointi/generointi/prosessointi/yms. määrittely
• 3D
• Mekaanisten osien 3D-visualisointi
• Mekaniikan simulointimallin alustus
• CAN / Sähkö- ja automaatiosuunnittelu
• Suunnittelukaavioden visualisointi
• Simulointimallin (ohjausjärjestelmä) generointi
• Osa kokonaisvaltaista ohjaussignaalin kulkua (toimintojen mallinnus)
• Hydrauliikka
• Kaavion visualisointi
• Hydr.komponenttien valinta ja toiminnallinen kuvaus
• (Yms. suunnittelun osa-alue)
• Koneluettava dokumentaatio
• Suunnittelutiedon rakenteiden iteratiivinen semanttinen rikastaminen
• Laitteen suunnittelutehtävien informaatiorajapintojen määrittely ja informaation
laaduntarkkailu
• Adapterien valinta ja tarvittaessa uusien kehitystyö
• Virtuaaliprototypointi
• Simulointi; menetelmän, parametrien ja komp.simulointimallien valinta
• Virtuaalilaboratorion komponenttien generointi ja integrointi
• Suunnitteluratkaisujen arviointi ja toimijoidenvälinen kommunikaatio ja
koulutuskäyttö
14
• Testien määrittely ja toteutus, laadunvalvonta
• Kehitys- ja tutkimuskäyttö, ml. hypoteesien testaus, analytiikka, näkymät ja
tunnusluvut
(Suunnittelun osaprosesseja, joita ei tarkasteltu lähemmin, olivat ohjelmistosuunnittelu, tuotanto,
huolto- ja kunnossapito, jälkimarkkinointi, myynti, osto/hankinta, tekijänoikeudet, dokumentaatio,
HR, yms.)
On merkillepantavaa, että suunnitteluprosessin uudenlainen jäsennys auttaa havaitsemaan
"perinteisen" suunnitteluprosessin haasteita ja raja-aitoja. Lyhyesti sanottuna informaatiolähtöisessä
suunitteluprosessin tulkinnassa pääsuunnittelijan ja informaatioarkkitehdin rooli korostuvat ja
tuotantomenetelmien eri suunnittelutehtäville asettamat tietotarpeet tulevat osaksi arkista
suunnittelutyötä. Onnistumisen edellytyksenä näyttäisi kuitenkin olevan suunnitteluprosessin
tarkoituksenmukainen jäsentäminen organisaation prosessikartalla.
Kuva 2.3. Integroitu semanttinen tuotantoprosessi
Kuva 2.3 havainnollistaa tilannetta yksinkertaisen prosessikaavion avulla. Ideana on tulkita
yksittäinen suunnitteluprosessi (kuvassa prosessi S3) kiinteästi osaksi laajempaa tuotannollista
näkökulmaa. Tällöin mittareiden ja informaatioarkkitehtuurin valinta palvelevat useita
suunnitteluprojekteja ja projektien tuloksia voidaan hyödyntää ja ottaa opiksi tulevissa hankkeissa
myös formaalin tiedon tasolla. Suunnitteluprosessien tuottaman informaation varassa voidaan paitsi
valmistaa tuotteita, myös esim. generoida konelaboratoriokomponentteja. Suunnittelutietoa voidaan
siten hyödyntää tuotannon jatkovaiheissa (esim. tekninen dokumentointi, koulutus ja markkinointi)
sekä suunnittelussa (esim. prototypointi ja testaus). Näin muodostuu positiivinen kierre, jossa
suunnittelutiedon rikastamisesta saadaan välitöntä hyötyä myös itse suunnitteluprosessin kuluessa,
mikä puolestaan kannustaa rikastamaan tietoa enemmän, ja siten auttaa myös seuraavien prosessien
tietotarpeiden tyydyttämisessä ja tiedon automaattisen käsittelyn tehostamisessa.
On kuitenkin huomattava, että mikäli suunnitteluprosessi tulkitaan ainutkertaiseksi "siiloksi" tai
saarekkeeksi irrallaan esim. prototypoinnin, testauksen, koulutuksen sekä teknisen kirjoittamisen
tehtävistä, ei hedelmällistä vuorovaikutusta eri osaprosessien välillä synny. Tällöin semanttisen
prosessin ja edelleen informaation koneellisen käsittelyn asettavat vaatimukset näyttäytyvät lähinnä
vaikeasti perusteltavissa olevana tarpeettomana lisätyönä.
15
Kenties tärkeimmät integroidun semanttisen tuotantoprosessin puolesta puhuvat tekijät liittyvät
tuotannon kokonaisanalyysiin sekä design as service –ajatteluun. Suunnitteluvaihe on tunnetusti
verraten lyhyt mutta kustannusvaikutuksiltaan kauaskantoinen vaihe monimutkaisen työkoneen
elinkaaressa. Suunnitteluinformaatiolle on kuitenkin runsaasti käyttöä myös varsinaisen
suunnitteluaktiviteetin päätyttyäkin. Mikäli suunnitteluinformaatio on huonosti jäsennettyä ja
hankalasti hyödynnettävissä, kertautuvat tiedon hyödyntämisen ja käsittelyn kustannukset
elinkaaren pituuden myötä eikä organisaation ole mahdollista helposti kytkeä tätä lähtökohtaisesti
arvokasta tietopääomaa uusien suunnittelu- ja tiedon jatkojalostustehtävien perustaksi. Kun tämä on
sisäistetty, voidaan semanttinen prosessiajattelu lopulta tulkinta vain "hyvän suunnittelun" ja
tiedonhallinnan menetelmänä.
16
3. Konejärjestelmän suunnitteluaineiston semanttinen mallinnus
3.1. Yleiskatsaus aineistoon ja tutkimustapauksen rajaus
Kirjoittanut Pekka Ranta
Semogen-hankkeen tavoitteena oli kehittää malleja, menetelmiä ja teknologioita virtuaalisen
konelaboratorion tuotantomenetelmien automatisointiin. Hankkeen tahtotilana oli hyödyntää aitoa
konejärjestelmän suunnitteluaineistoa tuotantomenetelmän perustana. Lisäksi tavoitteena oli
rakentaa konejärjestelmästä rikas ja tietokoneen käsiteltävä semanttinen malli sekä automaattisesti
generoitu dynaaminen reaaliaikasimulointmalli, joiden avulla virtuaalinen konelaboratorio
rakennetaan.
Virtuaalinen konelaboratorio sisältää dynaamiseen reaaliaikasimulointiin perustuvia työvälineitä:
kaavio- ja 3D–visualisointi, mittausvälineet, vikatilanteiden muokkaus, osaluettelo, toimintaketju
sekä kouluttajan tukivälineitä. Virtuaalisella konelaboratoriolla voidaan nähdä myös laajempia
käyttökohteita, kuten virtuaaliprototypointi ja älykkäät huolto- ja varaosakirjat. Kuvassa 3.1.1 on
havainnollistettu virtuaalista konelaboratoriota, joka mahdollistaa konejärjestelmien opiskelun
virtuaalikoneen, reaaliaikasimulointimallin, rikastetun kaavion, mittaus- ja ohjausvälineiden sekä
linkitetyn oppimateriaalin avulla.
Kuva 3.1.1. Virtuaalinen konelaboratorio, joka tarjoaa rikkaita näkymiä ja tarkoituksenmukaisia työvälineitä sekä
koulutus- että suunnittelukäyttöön. (SmartSimulators–tutkimusryhmä)
Esiselvitysvaiheessa pilot-ympäristö rajattiin koskemaan tunneliporauslaitteen Jumbon
puominnostotoimintoa (kuva 3.1.2). Tätä rajausta noudatettiin koko hankkeen ajan. Rajauksen
tukena olivat myös seuraavat käyttötapakuvaukset 1. Huoltoasentajakoulutus ja kouluttajan
työvälineet, 2. Virtuaalisen konelaboratorion generointi automaattisesti ja/tai semiautomaattisesti
suunnitteludokumenttien, -ohjelmistojen ja konelaboratorion semanttisten kuvausmenetelmien
avulla sekä 3. Poralaitteen (Jumbo) puomin konstruktiomuutos. Nämä ohjasivat osaltaan aineistojen
käsittelyä, menetelmien ja mallien kehitystä sekä pilot-ympäristön rakentamista. Nämä on kuvattu
tarkemmin väliraportin liitteessä 5.2.
17
Rajaus sisältää yksinkertaisen hydraulijärjestelmän, jonka tärkeimmät komponentit ovat CANohjattu suuntaventtiili, nostosylinteri ja pumppu. Lisäksi rajaukseen sisältyy nostotoimintoon
liittyvä CAN-järjestelmä, puomin 3D-mekaniikkamalli, tuotetietoa ja osaluettelo. Projektia varten
saatu materiaalia kattaa rajatun järjestelmän suunnittelumateriaalin lukuun ottamatta komponenttien
parametreja, komponenttien 3D-malleja ja ohjausjärjestelmää. Alkuperäinen aineisto on kuvattu
tarkemmin väliraportissa (luku 3.1, ml. taulukko 3.1.1).
Kuva 3.1.2. DTi-jumbo tunnelissa.
Tässä luvussa kuvaamme Semogen-hankkeessa käytettyyn suunnitteluaineistoon pohjautuvaa
semanttista mallinnusta. Aluksi kuvailemme aineiston rikastamista ja semanttista mallinnusta
sovellusaloittain (hydrauliikka, CAN-väyläjärjestelmä ja mekaniikka). Pohdimme edelleen myös
aineistojen integrointia. Sovellustapauksena integroidulle semanttiselle mallille esittelemme
simulointimalliin liittyvää työtä. Tässä loppuraportissa kuvaamme ainoastaan aineistotutkimukseen
liittyviä yleisiä haasteita sekä hankkeen ensimmäisen vaiheen lopussa tapahtuneet edistykset.
Aineistoon liittyvää mallinnusta käsitellään laajemmin väliraportissa erityisesti luvuissa 3.2, 3.3, 3.4
ja 3.5.
Merkittävä huomio hankkeen ensimmäisen vaiheen loppupuolella on ollut laitteen toiminnallisen
kuvauksen puuttuminen lähdeaineistoista. Tämä on osoittautunut haastavaksi löytää koneluettavassa
muodossa kuvauksia laitteen toiminnallisuuksista sekä siitä, mitkä osajärjestelmät ja niiden
komponentit osallistuvat kunkin toiminnallisuuden toteutumiseen. Laitteen toiminnallisuuden
kuvaaminen on tärkeää erityisesti virtuaalisen konelaboratorion opetuskäytön kannalta. Ilman
toiminnallisien rakenteiden kuvauksia, on konelaboratoriosta vaikeaa tai hankalaa luoda näkymiä
laitteen toimintaa kuvaavista toimintoketjuista. Toiminnallisen rakenteen kuvaaminen näyttäisi
18
myös lupaavalta lähestymistavalta yleisestikin aineistojen välisten ristiviittauksien pohtimiseen.
Näihin aineistojen integrointiin ja rikastamiseen liittyviin ongelmiin on paneuduttu erityisesti tämän
loppuraportin aliluvussa 3.5.
19
3.2. Hydrauliikkasuunnittelu
Kirjoittanut Markus Rokala, Vänni Alarotu ja Jaakko Salonen
Esimerkkitapauksena olleen puomin nosto-toiminnon suunnittelun yhtenä osa-alueena on
hydraulijärjestelmän suunnittelu. Hydrauliikkasuunnittelu koostuu järjestelmän vaatimuksien,
toiminnan ja rakenteen selvittämisestä, komponenttien mitoituksesta ja valinnasta sekä kaavion
piirrosta suunnitteluohjelmalla.
3.2.1. Hydrauliikkasuunnitteluaineisto
Alkuperäinen suunnitteluaineisto koostuu koneen hydraulikaavioista ja mahdollistaa koneen
fyysisen valmistamisen. Aineisto on kuitenkin tehty tavalla, joka ei tue tietojen löytymistä ja
linkittämistä semanttiseen malliin. Aineiston piirteitä on tarkemmin analysoitu väliraportissa (osio
II, Semogen väliraportti). Tiivistetysti suunnitteluaineistossa havaittiin seuraavia haasteita:




Kaavioiden komponentit on liitetty ainoastaan visuaalisesti toisiinsa, eikä lähdedatan
perusteella komponenttien semanttinen yhdistely ole triviaalia. Näin ollen kaaviossa
kuvattua hydraulipiiriä ei myöskään välttämättä voida luoda semanttiseen malliin ilman
lähdeaineiston muokkausta.
Myös tunnisteet on paikoin liitetty komponentteihin ainoastaan visuaalisesti
Eri kaavioiden välillä käytetty nimikkeistö voi vaihdella, jolloin ilman erillisiä koodilistoja
ei komponenttien välisiä yhtäläisyyksiä voida kaavioiden välillä välttämättä päätellä
Vastaavasti hydraulikomponentin yksilöiminen muista kuin hydrauliaineistoista vaatii
muunnostaulukon käyttöä tai käsityötä
Aineistoon liittyviin haasteisiin puututtiin hankkeessa rikastamalla lähdeaineistoa, sekä
määrittelemällä suunnittelijan tueksi vaatimuksia siitä, minkälainen hydrauliaineisto tarjoaa
konelaboratoriokäytössä parhaan mahdollisen uudelleenkäytettävyyden.
3.2.2. Aineiston rikastaminen
Aineiston rikastamisella tarkoitetaan hydraulikaavion piirtoa niin, että kaavio sisältää myöhemmin
putkilinjassa tarvittavan tiedon koneluettavassa muodossa. Käytännössä hydraulikaavion piirrossa
tulee ottaa huomioon seuraavat asiat:
Komponenttien väliset yhteydet piirretään aina määritellystä yhteyspisteestä toiseen
yhteyspisteeseen. Tällä tavoin komponenttien väliset yhteydet säilyvät, vaikka komponenttien
sijoittelu muuttuu. Jokaiselle komponentille annetaan nimi/tunniste, jonka avulla komponentit muut
tiedon on mahdollista löytää tietotietojärjestelmästä (PDM-järjestelmä). Lisäksi on hyvin oleellista,
että komponenttien nimi/muut tiedot liitetään komponenttiin, niin että komponentin ja nimen
välinen yhteys säilyy myös kaaviosta tehtävissä ulkoistuksissa (esim. SVG skaalautuva
vektorigrafiikka).
Semanttisesti rikkaan hydraulikaavion piirteitä ja sen tuontia SVG-muodossa on tarkemmin esitelty
väliraportissa (osio II, Semogen väliraportti). Aineiston rikastamista ja komponenttidatan
tallennusmahdollisuuksia on esitelty erikseen aihetta käsittelevässä artikkelissa (Markkula, Rokala,
Palonen, Alarotu, Helminen, Koskinen, Salonen, Nykänen, Ranta, Pohjolainen, 2011).
20
3.2.3. Aineiston siirto
Hydraulijärjestelmän suunnittelun jälkeen Vertex HD -hydraulikaaviota jatkojalostetaan teknisesti
seuraavan prosessin mukaisesti:



Hydraulikaaviot tuodaan Vertex HD -ohjelmistosta SVG-muodossa
SVG-muotoista hydraulikaaviota käsitellään edelleen, jotta se voidaan avata suoraan
virtuaalisessa konelaboratoriossa (XSL-muunnos)
Rinnakkaisessa muunnoksessa SVG-kaaviosta irrotetaan semanttinen informaatio RDFdokumentiksi
Lopputuotteina prosessista syntyvät konelaboratoriossa hyödynnettävä hydraulipiirin semanttinen
kuvaus (RDF) sekä visualisointi (SVG).
Aineistojen siirrossa haasteeksi osoittautui SVG-lähdeaineiston semanttinen rikkaus sekä siinä
käytettyjen piirtomerkkien valinta. SVG:hen tulevat piirtosymbolit pohjautuvat Vertex HDohjelmistossa määriteltyihin makroihin (komponenttiaihiot). Komponentteihin voidaan liittää
makrotasolla lisäinformaatiota runsaankinlaisesti: erityisesti komponentin nimi, tyyppitieto ja siihen
liittyvät portit voidaan kuvata ohjelmiston avulla siten, että ne säilyvät myös SVG-aineistoihin.
Makrotasoa tarkemmin kohdentuvan informaation lisääminen osoittautui kuitenkin mahdottomaksi.
Näin ollen komponenttiaihioon ei voida helposti kuvata niitä osia, joista komponentti koostuu. Näin
ollen esimerkiksi sylinterin piirtomerkkiin ei voida koodata tietoa siitä, mikä osa piirtosymbolista
vastaa sylinterin mäntää (kts. kuva 3.2.3.1). Kaaviokuvan animoinnin osalta vaikeuksia aiheuttaa
myös SVG-elementtien valinta: polyline-elementtiä käytetään usein myös suorakulmaisten
kappaleiden merkkaukseen, mikä tekee visualisoinnista hankalaa verrattuna siihen, että kappaleet
olisi semanttisesti kuvattu suorakulmioksi (SVG:n rect-elementti). Puutteellinen kuvailutarkkuus
johtaa siihen, että SVG-viennistä saatavia kaavioita ei voida suoraan hyödyntää hydrauliikan
dynaamiseen visualisointiin tai alikomponenttitason tietojen esittämiseen.
Kuva 3.2.3.1. Havainnollistus hydraulikaavion piirtosymbolien ja SVG-elementtien yhteyksistä
On syytä kuitenkin huomata, että merkittävältä osin SVG-kaavioihin koodattua semanttista tietoa
saadaan hyödynnettyä. Erityisestikin komponenttien tyypitys ja niiden väliset yhteydet saadaan
tehokkaasti mallinnettua. Dynaamisten visualisointien tuottaminen näyttäisi kuitenkin vaativan
edelleen käsityötä. Vaihtoehtoisesti SVG-vientiformaattia tulisi jatkossa jalostaa tukemaan
alikomponenttitason informaation koodaamista, jotta hydraulikaavion dynaamisia visualisointeja
voitaisiin generoida suoraan suunnitteluaineistoista.
21
Jotta visualisointi voitaisiin toteuttaa, komponentti täytyy kuvata järkevinä osakokonaisuuksina.
Esimerkkinä tästä on sylinteri (kuva 3.2.3.2.), joka on piirretty käyttäen suorakaidekappaleita.
Suorakaiteet on ryhmitelty järkevästi niiden dynamiikan kannalta. Simulaatioarvojen perusteella
voidaan muuttaa suorakaiteiden kokoa, siirtää niitä ja käyttää täytevärejä. Lopputuloksena on
simulaation tahdissa liikkuva sylinteri kaaviossa.
Kuva 3.2.3.2. Havainnollistus hydraulikaaviosta semanttisilla, animoitavilla piirtosymboleilla
3.2.4. Hydrauliikkasuunnitteluaineiston semanttinen mallinnus
Rikastetun hydraulikaavion perusteella voidaan generoida malli, joka kuvaa hydraulikaaviossa
esitetyn piirin sekä sen yhteydet muihin aineistoihin.
Kuva 3.2.1.4: Hydraulikaavion semanttisen mallin visualisointia Protégé-ohjelmistolla
22
Kuvassa 3.1.4. on esitetty visualisointi osasta hydraulikaavion semanttista mallia. Kuvan perusteella
voidaan tarkastella mallin piirteitä:




Malliin on kuvattu hydraulikaavio (boomlift-hd.svg) sekä siihen siihen liittyvät komponentit
(comp-3_16, comp-3_17, jne.)
Komponentit on liitetty niihin kuuluviin portteihin (port-2_8, port-2_13, jne.)
Portit yhdistyvät edelleen painelinjojen (pipe-1_40, pipe-1_43) avulla
Kaikki resurssit on liitetty osaksi yleisempää hydrauliikkaa kuvaavaa skeemaa
(hydraulicCircuitDiagram, hydraulicComponent, hydraulicPort, hydraulicPipe)
Semanttisen mallin tarkkuus riittää näin ollen varsin hyvin useisiin käyttötapauksiin. Skeeman
hyödyntäminen mahdollistaa semanttisen haun toteuttamisen. Vastaavasti hydraulipiirin täydellinen
kuvaaminen mm. porttien ja painelinjojen avulla mahdollistaa hydrauliikan simulointimallin
generoinnin. Koska kaaviosta tehty malli käyttää resurssien tunnistamiseen globaaleja nimikkeitä
(URI), voidaan mallia rikastaa lisäämällä viittauksia myös muihin hydraulikaavioihin sekä muihin
aineistoihin kuten CAN-verkkoihin ja mekaniikkamalleihin. Perehdymme näihin sovelluksiin
myöhemmissa aliluvuissa.
Hydraulikaavion osalta semanttisen mallin vaatima tiedon rikastaminen ei merkittävästi muuta
suunnittelun vaatimuksia. Komponenttien suunnitelmallinen nimeäminen ja eheiden yhteyksien
rakentaminen komponenttien välille on jo nykyään mahdollista ja toivottavaa. Näiden asioiden
tarkastaminen ja komponenttien rakenteeseen ja kaavion ulkoistukseen liittyvät vaatimukset on
mahdollista toteuttaa suunnitteluohjelman sisälle.
23
3.3 CAN-suunnittelu
Kirjoittanut Matti Helminen, Jaakko Salonen
3.3.1. CAN-aineisto
CAN-aineisto käsittää proCANopen-ohjelmalla luodut kolmen verkon CANopen-projektit.
Jokainen verkko on oma projektinsa. Yksi projekti sisältää aina nodelist.pco-tiedoston, joka vastaa
sisällöltään standardin mukaista nodelist.cpj-formaattia. Siinä on kerrottu mitkä solmut (nodet)
verkkoon kuuluvat. Solmuista on kerrottu ainoastaan DCF-tiedoston nimi. ProCANopen:n pco.ini
projektitiedostossa on puolestaan samat tiedot, mutta lisäksi on solmulle määritelty kuva. Solmut on
myös ryhmitelty grouppeihin, mutta näillä ei kuvata todellista topologiaa. Kussakin CANopen
projektissa jokaisella solmulla on oma DCF-tiedostonsa. Tiedosto sisältää tiedon solmun
vastaanottamista ja lähettämistä signaaleistä, sekä niiden mappauksen data-objekteihin. Jokaisella
erityyppisellä solmulla on oma EDS-tiedostonsa. EDS määrittelee pohjan DCF-tiedostoille eli
kuvaa solmun tarjoamat ominaisuudet rajapintoineen. DCF-tiedosto sisältää edellisen lisäksi kaikki
parametriarvot, jotka ovat solmukohtaisia. CAN-aineisto on kuvattu tarkemmin väliraportin luvussa
3.3.1 (Osio II, Semogen-väliraportti)
3.3.2. CAN-aineiston semanttinen mallinnus
Can-aineiston eli CANopen-projektien perusteella luodaan semanttinen malli laitteen CANopenväylistä ja CANopen-laitteista. Semanttisen mallin luontiin käytetään CANopen-projektin DCFtiedostoja ja ProCANopen-projektin nodelist.pco sekä pco.ini-tiedostoja. Näistä luodaan nyt
suoraan RDF-malli (Kuva 3.3.2.2) ilman välivaiheita, jotka väliraportin sivulla 23 on kuvattu. RDFmallista generoidaan edelleen SVG-muotoinen CAN-kaavio sekä simulointimalli. Generointi
tapahtuu Eclipse-ympäristössä ja on toteutettu python-ohjelmointikielellä. Generoinnin vaiheet on
esitetty kuvassa 3.3.2.1.
Kuva 3.3.2.1: CAN-aineiston generoinnin vaiheet
24
CANopen hallintaprosessi, sekä standardin mukainen nodelist.cpj eivät tue kuin yden CAN-verkon
mallinnusta kerrallaan. Sama rajoitus periytyy myös työkaluihin, kuten proCANopeniin.
Esimerkkiaineistona toimivaan puominohjausjärjestelmään kuuluu kolme erillistä CAN-verkkoa.
Liikennettä verkkojen välillä ei pystytä käytetyillä työkaluilla ja niiden käyttämillä formaateilla
kuvaamaan. CiA-302-7 standardiehdotuksen perustuvan reitittävän CANopen-laitteen
reititystaulusta voidaan kuitenkin lukea signaalien kulku verkkojen välillä. Esimerkiksi verkkojen
välillä siltana toimiva laite näkyy molempien verkkojen CANopen-projektissa, mutta tietoa siitä,
että kyseessä on yksi ja sama laite, ei ole suoraan kuvattu missään. CiA-302-7 määrittelee myös
reitittävän CANopen-laitteen node-id:n eri verkoissa, joten tämän perusteella olisi mahdollista
selvittää mitkä DCF-tiedostot kuvaavat samaa laitetta ja sitä kautta myös mitkä eri laitteet eri
CANopen projekteissa ovat itseasiassa sama fyysinen reitittävä laite. Myöskään minkäänlaista
verkkotopologiaa ei ole kuvattu, eikä sen kuvaamiseen ole standardia formaattia. Näitä ongelmia on
lähdetty ratkomaan projektin aikana syntyneessä standardiehdotuksessa, jossa kuvataan uusi XMLpohjainen CANopen nodelist.graphml-formaatti, jolla saadaan usean verkon verkkotopologia ja
kytkökset samaan tiedostoon. Nykyinen nodelist.cpj-formaatti kuvaa pelkästään verkon solmut, eikä
ollenkaan topologiaa.
Kuva 3.3.2.2: CAN-verkon semanttisen mallin visualisointia Protégé-ohjelmistolla
CAN-verkon visualisointiin käytetään samaa SVG-formaattia, kuin hydraulikaavion visualisointiin.
SVG-formaattia on laajennettu muutamilla attribuuteilla, joilla tunnistetaan kaaviossa olevat
komponentit. Tämä mahdollistaa linkitykset semanttisen mallin ja kaavion välillä. CAN-verkko
itsessään on kuvattuna myös semanttisessa mallissa, joten sitä voi visualisoida myös esimerkiksi
Protégé-ohjelmistolla, jolloin siitä saa erilaisia näkymiä, kuten kuvassa 3.3.2.2.
25
3.4 3D-suunnittelu
Kirjoittanut Tuija Palonen, Jaakko Salonen
Alkuperäinen lähdeaineisto oli laajuudessaan projektin tarpeisiin liian suuri, joten aineiston
rikastaminen aloitettiin yksinkertaistamalla puomista nostosylinterin toimintaa demonstroiva osuus.
Automaattista generointia helpotettiin yhdistämällä useampi jäykkä kappale yhdeksi kappaleeksi,
ns. kuorimalliksi. Tämän jälkeen kappaleet nimettiin ja niille lisättiin tunnistenumero osaluettelon
perusteella. Mallin sylinterit koottiin omiksi alikokoonpanoikseen. Jokaiselle dynaamiselle
kokoonpanolle lisättiin origo nivelpisteeseen. Mallin kappaleet myös ketjutettiin toisiinsa. 3Daineiston koostumusta on käsitelty myös väliraportin luvussa 3.4.1 (Osio II, Semogen-väliraportti)
Kuva 3.4.1.1. Alkuperäisen 3D-aineiston visualisointi suunnitteluohjelmistossa (SolidWorks). Virtuaalisen
konelaboratorion käyttöön mallia on yksinkertaistettava ja täydennettävä (rikastettava). Oikeassa laidassa
Semogen ohjelmistolaajennuksen (add in) työkalupalkki.
3.4.2. 3D-aineiston rikastaminen
Aineiston rikastaminen tapahtui käsityönä, ja jälkikäteen toteutettuna se oli työlästä, johtuen
ensisijaisesti nimien ja osanumeroiden vastuuden hakemisesta jälkikäteen osaluettelosta. Malli
olisikin hyvä rikastaa jo suunnitteluvaiheessa mikäli suunnittelussa käytetään kirjastoituja
komponentteja.
26
Jotta rikastamista ei tarvitsisi tehdä jälkikäteen, suunnittelijan on huomioitava seuraavat asiat:
1. Yksittäisen osan origo ja koordinaatisto
Tämä määrittää lokaalin koordinaatiston 3D:ssä
Suositeltavat sijoituskohdat:



Nivelpiste, jonka ympäri osa pyörii
Osan massakeskipiste
Nivelpiste, johon kinemaattisessa ketjussa seuraava osa kiinnittyy
Lokaalin koordinaatiston orientaatiovaatimukset:



Sama kuin globaalikoordinaatisto
Jos liikkuva osa on vinossa globaaliin koordinaatistoon nähden, osan koordinaatiston jokin
akseli osan liikkeen suuntaisesti
Vastattava simuloinnin koordinaatiston orientaatiota
2. Osien ja kokoonpanon nimeäminen
Nimien on oltava yksiselitteisiä
Samanlaiset osat nimettävä juoksevasti, esim. osannimi+nro tai osannumero_kirjain
Osat on nimettävä samoilla nimillä kuin simulointimallissa ja hydraulikaaviossa
Mikäli tämä ei ole mahdollista, osalle on annettava tunniste tai viite osanumeroon, jonka perusteella
se voidaan yhdistää kaavio tai simulointimallikomponenttiin.
3. Kinemaattinen ketju
Kokoonpanossa liikkuvat osat on sidottava toisiinsa kinemaattisessa liikejärjestyksessä. Mikäli osat
eivät liiku toisiensa suhteen, niistä voidaan tehdä alikokoonpano tai ryhmä.
3.4.3. Automaattisen generoinnin haasteet 3D:ssä
Projektissa tutkittiin eri siirtoformaatteja ja siirtoteitä 3D-mallille. Koska Semogen-playerin
käyttöliittymä suunniteltiin web-pohjaiseksi, yhtenäinen esitys vaati myös 3D-grafiikan esityksen
selaisemessa. Esitystavaksi valitiin WebGL-pohjainen grafiikkamoottori, X3DOM. Tämä
mahdollistaa 3D-grafiikan esittämisen sitä tukevassa selaimessa, kuten Firefox 5:ssa tai Google
Chromessa.
27
Grafiikkamoottorin natiivi tiedostoformaatti on X3D, joka täyttää seuraavat tiedostoformaatilta
vaaditut ominaisuudet:






Kappaleiden nimet
Kappaleiden tekstuurit
Nivelpisteiden esitys
Kokoonpanojen toteutus
Kokoonpanojen sidosten toteutus
Kappaleelle on mahdollista antaa useampia tekstuureja
Ensisijainen haaste on aineiston siirtoformaatti, jossa aineisto (3D-mallit) siirretään automaattisen
generoinnin käsiteltäviksi. Siirtoformaatilta vaadittavia asioita ovat:
1.
2.
3.
4.
5.
6.
Osien nimien säilyminen
Osien tekstuurien säilyminen
Nivelpisteiden säilyminen
Kokoonpanojen säilyminen
Kokoonpanojen sidosten säilyminen
Osan käsite: kappaleen aliosat rajataan eri teksturoinneilla, ei muotojen perusteella.
Kohdat 5 ja 6 ovat valinnaisia, sidokset voidaan lisätä myöhemmin käsin ja osa voidaan koostaa
muodoista lukuvaiheessa, mutta tämä vaikeuttaa osan kolmioverkon rakentamista automaattisessa
generoinnissa.
Siirtoformaatin valintaan luo haasteita myös se, ettei niiden lukemiseen tarkoitettuja kirjastoja ole
saatavilla avoimen lähdekoodin versioina. Avoimet formaattien ongelmana on myös standardien
puute, mikä on aiheuttanut sen, että esimerkiksi eri ohjelmasta tallennettu STEP-muotoinen malli ei
vastaa toisesta ohjelmasta tallennettua. XML-pohjaisiin siirtoformaatteihin, kuten X3D
(http://www.web3d.org/x3d/) ja Collada (https://collada.org/) on saatavilla lukijoita paremmin ja
niiden käyttöä Semogen-projektissa tutkittiin ja tähän löydettiin ratkaisuja. Valitettavasti
suunnitteluohjelmien tuki XML-pohjaisille siirtoformaateille on rajoittunutta.
Aineiston suuri resurssien (näytönohjaimen teho, koneen muisti) kulutus tuo haasteita
automaattiselle generoinnille. Aineiston resurssien kulutusta voidaan pienentää vähentämällä 3Dmallien sisältävien kolmioiden määrää. Tätä varten on olemassa valmiita algoritmeja, jotka toimivat
erilaisilla periaatteilla. Yksinkertaisimmat algoritmit yhdistävät tietyllä etäisyydellä olevat Vertexpisteet toisiinsa, kun taas monimutkaisemmat rakentavat koko verkon uudelleen optimoituna
(Hoppe, et al. 1993). Edelliset ovat tehokkaita kappaleille, joissa vertex-pisteiden väleissä ei ole
suuria eroja, mutta tuloksen ulkoasu on aina tarkastettava silmämääräisesti, jälkimmäiset taas ovat
hitaampia, mutta tulos on usein muototarkempi ja vähentää kolmioiden määrää koko mallin alalta
riippumatta vertex-pisteiden väleistä. 3D-mallien resurssien kulutusta voidaan myös pienentää
poistamalla kokoonpanosta ns. merkityksettömiä osia, kuten muttereita, aluslevyjä ja korvakkeita.
X3D-tiedostoformaatin suurimpia ongelmia oli se, ettei sille löydy valmiita kääntäjiä. Tästä syystä
suunnitelmana oli kääntää 3D-malli ensin Colladaksi, ja sen jälkeen muuntaa Blender-grafiikka
ohjelmassa X3D-formaattiin. Tässä toteutuksessa havaittiin seuraavat ongelmat, jotka johtivat
toteutustavan hylkäämiseen:
28
Mallin kääntäminen Collada-formaattiin oli erittäin hidasta, yksinkertaisen mallin kääntö saattoi
kestää jopa 12 tuntia Blender muutti mallin koordinaatistoa, jolloin se ei enää ollut yhtenevä
simulointimallin kanssa Yllämainittujen lisäksi työvaiheet suoritettiin manuaalisesti, eikä niissä
ollut automatisointimahdollisuuksia.
Ratkaisuna oli kehittää oma kääntäjä suoraan konelaboratoriossa käytettävälle X3D-formaatille,
mikä vaati joko scriptejä tukevan tai ohjelmointirajapinnan sisältävän CAD-ohjelmiston.
Solidworksin lisenssi sisältää mahdollisuuden käyttää Solidworks APIa, ohjelmiston omaa
rajapintaa. Solidworksille ohjelmoitiin oma X3D-kääntäjä, ohjelmointikielenä toimi C-Sharp (C#).
Kääntäjä toteutettiin COM-pohjaisena Add-in-sovelluksena, joka asennetaan erikseen Solidworksin
yhteyteen.
3.4.4. Semogen 3D CAD-ohjelmistolaajennus
Semogen ohjelmistolaajennus (Add-in) suunniteltiin palvelemaan semanttisen mallinnuksen
tarpeita. Add-in tuottaa myös strukturoitua tietoa SolidWorksissa käsiteltävästä CAD-mallista
semanttisen mallinnuksen tarpeisiin. Ohjelmistolaajennus tuottaa mallista seuraavat tiedot sekä
XML-dokumentissa että Matlabin m-file parametritiedostona:









Kappaleen nimi
Kappaleen translaatio
Kappaleen orientaatio
Kappaleen massakeskipiste
Kappaleen tunniste (id)
Kappaleen inertiamatriisi
Kappaleen massa
Kappaleen tyyppi: nivel / jäykkä kappale
Kappaleen skaala
Ohjelmistolaajennus käyttää Solidworks APIa, jonka avulla malli käydään kappaleittain läpi.
Jokaisesta kappaleesta kerätään tiedot ja tulostetaan haluttuun formaattiin. Käyttäjä voi nimetä ja
sijoittaa tuloksena olevan tiedoston tahtonsa mukaan.
Semogen ohjelmistolaajennuksen päätarkoituksena on 3D-mallin tuottaminen X3D-formaatissa.
Tätä varten malli käydään kappaleittain läpi. Jokainen kappale jaetaan pinnoiksi, jotka jaetaan vielä
erikseen kolmioiksi. Kolmioista tallennetaan verteksi ja reunatiedot. X3D-formaattia varten mallista
kerätään ja tulostetaan seuraavat tiedot:








Kappaleiden nimet
Kappaleiden sijainnit ja orientaatiot
Kappaleiden skaalat
Kappaleiden materiaalit ja niiden värit
Kappaleiden läpinäkyvyys
Kappaleiden kolmioiden kärkipisteiden indeksit
Kappaleiden kolmioiden kärkispisteiden koordinaatit
Kappaleiden kolmiot muodostavat kärkipisteet
29
Myöhemmin tarkoituksena on myös tuoda seuraavat tiedot:


Valot, sijainti ja suunta
Varjot
Semogen-ohjelmistolaajnneus on rakennettu modulaarisesti ja sitä voidaan laajentaa myös muiden
3D-tiedostoformaattien tuottamiseen. Ohjelmakoodi on myös yleistettävissä muille CADohjelmille, mikäli niiden rajapinta tukee C#-ohjelmointia, vaihtamalla rekisteröinnin ja mallin luvun
tekevät luokat.
Verrattaessa Semogen ohjelmistolaajennuksen
X3D-mallin kääntönopeutta Collada-mallin
kääntöön, päästään huomioitavasti parempiin tuloksiin. Testimallin kääntöön kului 6 minuuttia, eli
nopeus oli 120-kertainen Collada-mallin kääntöön tähden. Kääntöä varten ei tehty erityisiä
ratkaisua: mallin tiedot luetaan ohjelmistolaajennuksen omiin tietorakenteisiin ja kirjoitetaan
Microsoftin tarjoamalla XML-writer luokalla X3D-formaattiin.
3.4.5. Semanttinen malli
Semogen ohjelmistolaajennuksen kautta saadut tiedot voidaan integroida osaksi semanttista mallia
yksinkertaisella muunnoksella (XML:stä RDF:ään). Vaikka periaatteessa suuri osa tiedoista olisi
saatavilla suoraan X3D-tiedoston kautta, on erityisesti simulointimallin generoinnin ja mekaniikan
semanttisen haun takia perusteltua tuoda näitä tietoja myös semanttiseen malliin.
Kuva 3.4.5.1. Mekaniikan semanttisen mallin visualisointi Protégèlla
Testiaineiston osalta semanttista mallia on visualisoitu kuvassa 3.4.5.1. Kaikki mekaaniset
komponentit on tyypitetty mallissa samalla tavoin (mechanicalComponent). Kustakin
komponentista on lisätty attribuuttietoa erityisesti simulointimallin tarpeiden näkökulmasta (massa,
massakeskipiste, inertiamatriisi). Semanttista hakua ajatellen malli sisältää myös komponenttejen
tunnistetietoja (nimi, ID). Osien välistä hierarkkiaa tai kinemaattista ketjua ei tässä vaiheessa ole
30
mallinnettu, mutta jatkossa tämän mallinnuksen piirteen lisääminen voisi olla perusteltua.
Vastaavasti mallia voitaisiin rikastaa myös lisäämällä mekaniikkakomponenteille tyypitystietoa
hydrauliikkamallin tavoin.
31
3.5 Suunnittelutietojen integrointi
Kirjoittanut Jaakko Salonen ja Juha Nurmi
Tässä aliluvussa kuvataan lyhyesti suunnittelutietojen integrointiin liittyviä haasteita ja
ratkaisumalleja. Käsittely pohjautuu artikkeliin (Salonen, Nykänen, Ranta, Nurmi, Helminen,
Rokala, Palonen, Alarotu, Koskinen, Pohjolainen, 2011).
Lähdeaineiston perusteella vaikuttaa siltä, että suunnitteluaineistot on pyritty usein toteuttamaan
siten, että kukin aineistoista muodostaisi mahdollisimman eheän ja selvärajaisen kokonaisuuden.
Suunnitteluaineistojen välille tehtäviä viittauksia ei kuitenkaan voida kaikissa käyttötapauksissa
välttää. Näin ollen menettelyt, joilla eri aineistoja voidaan integroida tulevat tarpeiseen myös
useissa virtuaalisen konelaboratorion käyttötapauksissa.
Ensinnäkin yksittäinen fyysinen komponentti, kuten hydraulisylinteri voi esiintyä useissa
suunnitteluaineistoissa, mahdollisesti eri rooleissa (sylinteri mekaniikkakomponenttina, osana
can/sähköjärjestelmää, osana hydraulijärjestelmää). Toisaalta ristiviittauksia tarvitaan myös silloin,
kun halutaan kuvata koneen rakenteellisen mallin lisäksi sen toiminnallista mallia. Ristiviittauksia
voidaan tarvita myös muista syistä. Erityisesti simulointimallin generoinnin kannalta on tärkeää,
että kuvaus järjestelmästä on mahdollisimman täydellinen ja eheä.
Saamamme lähdeaineiston perusteella näyttäisi siltä, että yksi mahdollinen tapa ristiviittauksien
kuvaamiseen on ulkoisten viittaustaulukoiden käyttö. Käytännössä tällainen kuvaus voidaan
toteuttaa esimerkiksi Excel-taulukkona. Yksinkertaisimmassa tapauksessa taulukkoon merkittään
esimerkiksi riveittäin yksikäsitteiset komponentit ja sarakkeittain komponentin esiintymät eri
suunnitteluaineistoissa (ks. taulukko 3.5.1). Tarvittaessa tätä viittaustaulukkoa voidaan käyttää
lisäksi kuvaamaan myös muuta komponentteihin liittyvää suunnitteluinformaatiota, mitä ei muista
aineistoista ole saatavilla.
32
Kuva 3.5.1. Kuva ristiviittauksen visualisoinnista. Puomin nostoon liittyvä ohjausventtiili esiintyy
sekä CAN- (vasemmalla) että hydrauliikkasuunnitteluaineistoissa (oikealla).
Komponenttikuvien lähdetiedot sijoitettu lähdeluetteloon.
Ristiviittaustiedoston avulla suunnitteluaineistoja voidaan rikastaa viittaustaulukoiden tavoin myös
muilla lisätiedoilla. Esimerkiksi järjestelmän toiminnallinen malli voidaan kuvata aineistoa
rikastamalla tähän tiedostoon. On myös syytä huomata, että koska ristiviittaukset on tehtävä
semanttiseen malliin koneluettavassa muodossa, täytyy ne tehdä globaalisti yksikäsitteisiä
tunnisteita (URI) käyttäen. Teknisestä näkökulmasta nämä tunnisteet voidaan ylläpitää muusta
semanttisesta mallista erillisessä tiedossa (ristiviittaustiedostoon). Tämä toimintatapa mahdollistaa
sen, että ristiviittauksia voidaan tarpeen mukaan tuottaa joko käsin tai jatkossa erillisen työvälineen
tai ohjelmiston avulla. Jälkimmäinen vaihtoehto on jatkokehitystyön kannalta tärkeä, sillä teknisten
tunnisteiden käyttöä ei tuotantokäytössä voida suunnittelijoilta olettaa.
33
3.6 Simulointimalliaihiot
Kirjoittanut Markus Rokala, Jaakko Salonen ja Vänni Alarotu
Simulointimallin automaattinen generointi on merkittävä osa Semogen-hanketta. Simulointimalli
toimii esimerkkinä, miten eri suunnitteluaineistojen yhteensopivuutta voidaan hyödyntää.
Simulointimallin muodostaminen koostuu pelkistetysti datan keräämisestä lukuisista eri lähteistä
sekä datan syöttämisestä simulointiohjelmaan. Prosessi on nykyisellään käsityötä, mikä tekee siitä
hitaan ja virhealttiin. Prosessin kehittämiseksi simulointimallien automaattiselle generoinnille on
olemassa selkeä tarve.
3.6.1. Simulink-aihioista ja niiden generoinnista
Semogen-hankkeessa tarvittavista komponenteista (hydrauliikka-, mekaniikka- ja CANkomponentit) on rakennettu komponenttikohtaisia simulointimalleja Matlab/Simulink ohjelmistolla.
Komponenteille on tehty oma kirjasto Simulinkin kirjastorakenteeseen. Mallinnetut komponentit on
rajattu niin, että komponenteilla saadaan toteutettua tapaustutkimuksen kohteena ollut puomin
nosto. Mallinnetut komponentit on rajattu niin, että komponenteilla saadaan toteutettua
tapaustutukimuksen kohteena ollut puomin nosto. Kyseiseen toimintoon kuuluvat hydrauliikka-,
mekaniikka- ja CAN-komponenteista tehtiin matemaattinen malli Simulink-ohjelmistoa
hyödyntäen. Mallinnetut komponentit hydrauliikan osalta ovat pumppu, putki, 4/3-venttiili,
sylinteri, suodatin ja tankki. Mekaniikkakomponenteista mallinnettiin kiinteä alusta, jäykkä
kappale, sylinteri, sekä rotaatio ja translaationivel. CAN-komponenteista mallinnettiin joystick,
väylä ja ohjain. Lisäksi omiksi malleikseen on laitettu UDP-liikennöintiin tarvittavat komponentit.
Mallin muodostamiseen voi toki käyttää myös muita Simulink-kirjastoissa olevia komponentteja.
Väliraportissa (osio II, Semogen-väliraportti) esitetty tekstimuotoinen mallien yhdistäminen
todettiin hankalaksi toteuttaa ja nykyisellään simulointimalli muodostetaan Matlab-komentojen
avulla.
Simulointimalli koostetaan RDF-mallin perusteella simulointikirjastossa olevista komponenteista.
Simulointimallin generointia varten on siis ensin luotu käsin simulointikirjasto, joka käsittää
peruskomponentit kuten esimerkiksi pumpun ja sylinterin. Tämän jälkeen tiedot
simulointikirjastossa olevista komponenteista on luettu RDF-malliin ja linkitetty komponenttien
tyyppeihin. Näin tietyn tyyppiset komponentit saavat automaattisesti itselleen simulointimallin.
Myös hydraulikaavion tiedot luetaan RDF-malliin ja siinä olevat komponentit linkittyvät
komponenttien tyyppien kanssa ja sitä kautta myös simulointikirjaston komponenttien kanssa. Kun
kaikki tieto on RDF-mallissa pystytään siitä suoraan tuottamaan Matlab-koodi, joka koostaa malliin
ja hydraulikomponentit ja yhdistelee ne toisiinsa hydraulikaaviosta saatujen tietojen perusteella.
Automaattista generointia on kuvattu hydrauliikan osalta kuvassa 3.6.1.1. Samalla tavalla eri
suunnitteluohjelmistoista voidaan automaattisesti generoida simulointimalliin komponentteja eli
hydraulikaaviolle rinnakkaisena voisi kuvassa olla myös esimerkiksi mekaanisten osien ja CANaineiston kuvaus.
Simuloitavat komponentit tarvitsevat myös parametreja esimerkiksi sylinterin halkaisija, jotka tällä
hetkellä lisätään ajamalla käsin kirjoitettu Matlab-koodi, joka sisältää parametrien arvot. Jos
lähdeaineistona käytetään myös PDM-järjestelmää, voidaan komponenttien parametrit tuoda RDFmalliin ja generoida automaattisesti simulointimallin parametritiedostoksi. Tätä mahdollisuutta
kuvataan katkoviivoilla kuvassa 3.6.1.1.
34
Kuva 3.6.1.1. Esimerkki putkilinjasta, jolla simulointimalli voidaan automaattisesti koostaa lähtötietoina olevista
suunnitteludokumenteista
3.6.2. Simulointiohjelmistoista
Ohjelmistoja, joilla fyysisiä järjestelmiä voidaan matemaattisesti kuvata ja ratkaista järjestelmää
kuvaavat differentiaaliyhtälöt on saatavilla lukuisia, joten projektin alkuvaiheessa kartoitettiin
mahdollisia toteutusohjelmistoja. Erityisesti toiveena oli löytää avoimen lähdekoodin ohjelmisto
virtuaalisen konelaboratorion käyttöön. Kartoituksessa kiinnitettiin huomiota reaaliaikamallin
luomiseen, valmiisiin komponenttikirjastoihin ja niiden muokattavuuteen, liikennöintiin mallin ja
muun järjestelmän välillä sekä saatavuuteen. Vertailukohtana käytettiin Matlab/Simulinkohjelmistoa, jonka käyttö ja ominaisuudet olivat entuudestaan tunnettuja. Yhteenvetona voidaan
todeta, että kaupallisissa ohjelmistoissa ominaisuudet ovat yleensä riittävällä tasolla, joskin
ongelmaksi saattaa muodostua haluttujen ulostulojen saaminen simulointimallista. Avoimen
lähdekoodin ohjelmistojen ongelmina ovat puutteellinen dokumentaatio ja paikoin epästabiili
käyttäytyminen. Lisäksi komponenttikirjastot ovat hyvin suppeita.
Virtuaalinen konelaboratorio päätettiin toteuttaa Matlab/Simulink-ohjelmistolla. Matlab/Simulink
on yleisesti käytössä ja se tarjoaa selkeän ja yksinkertaisen visuaalisen työkalun mallien
rakentamiseen. Valmiiden komponenttien valikoima on laaja, mikä tukee moniteknisen laitteen
mallintamista ja simulointia. Komponenttimallit ovat kuitenkin osaksi liian suljettuja, joten
haluttuja suureita ei saada mallista ulos. Tämä aiheuttaa sen, että mallit joudutaan kuitenkin
tekemän itse. Simulointimallit voidaan kääntää eri alustoille. Haasteena on mallimuutosten
tekeminen, koska mallin kääntäminen vaatii aina Matlab/Simulink-ohjelmiston.
35
3.6.3. Komponenttipohjaisen simulointimallin matematiikkaa
Kirjoittanut Jukka-Pekka Humaloja, Jaakko Salonen
Simulointimallien mallinnuksen kannalta on tärkeää, että mallia voidaan täydentää ja hallita
modulaarisesti. Hankkeessa tutkittiin mahdollisuutta lisätä simulointimalliin lisäkomponentti tässä
tapauksessa puomin nostoon kuorman käyttäytyminen.
Matemaattinen malli on tapa kuvata todellisuutta yhtälöiden avulla. Ratkaisemalla mallia kuvaavat
yhtälöt tietyillä alkuarvoilla saadaan tietoa sekä mallin että mallinnettavan ilmiön käyttäytymisestä.
Tätä kutsutaan simuloinniksi. Komponenttipohjaiset simulointimallit ovat työkalu jatkuvien
ilmiöiden mallintamiseen ja simulointiin. Komponenttipohjaisuuden etuina ovat valmiit
komponenttikirjastot sekä mahdollisuus omien komponenttien tekemiseen. Jälkimmäinen
mahdollistaa mallinnustyön hajauttamisen useammalle henkilölle, mikä on hyödyllistä etenkin eri
tekniikan aloja yhdistävissä sovelluksissa.
Komponenttipohjaisten simulointimallien matematiikka -raportin (Humaloja, 2011) pääpaino on
simulointimallin valintaan ja ratkaisuun vaikuttavissa tekijöissä, joihin luodaan seuraavaksi lyhyt
katsaus. Laitekomponenttien simulointimalleja valittaessa on päätettävä, mitä komponentin
ominaisuuksia malliin sisällytetään ja miten niitä mallinnetaan. Useampien ominaisuuksien
mallintaminen tekee mallista realistisemman, mutta samalla malli saattaa saada piirteitä, jotka
vaikeuttavat sen ratkaisemista. Mallin yksinkertaistaminen luonnollisesti helpottaa ratkaisua, mutta
yksinkertaisempi malli ei välttämättä vastaa mallinnettavaa ilmiötä riittävän tarkasti.
Simulointimalli joudutaan yleensä ratkaisemaan numeerisesti. Mallia ratkaisemaan valitun
numeerisen menetelmän tulee pystyä käsittelemään mallin numeerista jäykkyyttä,epäjatkuvuuksia
ja epälineaarisuuksia, minkä lisäksi reaaliaikasovelluksissa ratkaisu täytyy saada laskettua riittävän
nopeasti. Rajoitettu laskenta-aika edellyttää käytännössä kiinteää askelpituuden ratkaisumenetelmän
käyttöä, mikä Simulink-ohjelmistoa käytettäessä johtaa eksplisiittisen ratkaisumenetelmän
valintaan. Simulink tarjoaa kylläkin yhden implisiittisen kiinteän askelpituuden
ratkaisumenetelmän, mutta kyseinen menetelmä ei pysty käsittelemään simulointimallin
singulariteettejä robustisti.
Komponenttipohjaisten simulointimallien osalta tutkittavaksi jää, miten malli tulisi jakaa
moduuleihin. Simulointiohjelmat tarjoavat joitakin suuntaviivoja moduulienrakentamiseen.
Esimerkiksi AMESim-ohjelmiston AMESet-työkalu ohjaa 1) hyvin dokumentoitujen, 2)
standardoitujen, 3) uudelleenkäytettävien ja 4) helposti ylläpidettävien alimallien rakentamista
(mm. Imagine S.A., 2004). Useimmissa simulointiohjelmistoissa valmiit kirjastot koostuvat
laitekomponenttien malleista, mikä antaisi viitteitä laitekomponenttipohjaisten moduulien suosiosta.
Modelica-ohjelmiston oppaissa on mainittu erilaisia mallinnuslähestymistapoja, jotka vaikuttavat
myös simulointimallin modulointiin. Lisäksi Modelican kotisivulla on koottu yhteen runsaasti
Modelicaan liittyviä julkaisuija (http://www.modelica.org/publications), joissa käsitellään muun
muassa Modelican komponenttikirjastoja. Modulaarista mallintamista on sovellettu
tapauskohtaisesti ja sitä onkin tehty kattavasti eri tekniikan alojen sovelluksina (mm. Zupancic,
1998; Sinha, Liang, Paredis, Khosla, 2001; Vyatkin, Hanisch, Pfeiffer, 2003; Burmester, Giese,
Gambuzza, Oberschelp; Sorensen, Stoustrup, 2008; Ozpineci, Tolbert, 2003; Crusca, Aldeen,
36
2003). Simulointiohjelmien ulkopuolelta lähestymistapoja modulointiin voisi etsiä esimerkiksi
modulaariarkkitehtuurin menetelmistä (Knoernschild, 2011).
Tulosten perusteella lisäkomponenttien integrointi on mahdollista.
37
4. Pilot-ympäristö ja sovellustapaus
Kirjoittajat: Juha Nurmi, Jaakko Salonen, Ossi Nykänen
Tässä luvussa kuvaamme hankkeessa suoritetun teknisen tapaustutkimuksen. Osana tätä
tapaustutkimusta määrittelimme ja toteutimme semanttiseen tiedonkäsittelyn pilot-ympäristön (osio
4.1). Pilot-ympäristöä koekäytettiin lisäksi hankkeen aineiston avulla rajatulla sovellustapauksella
(osio 4.2). Tarkastelu pohjautuu väliraportissa kuvattuihin tuloksiin (ks. Osio II). Semogenkehitysympäristön
rakenne
ja
putkilinjaston
toiminta
perustuvat
määrittelyja
selvitysdokumentteihin (Nykänen 2010a, Nykänen 2010b, ks. liitteet A ja B).
4.1. Pilot-ympäristö
Pilot-ympäristö koostuu käsitteellisesti kolmesta eri komponenttiin: Semogen Manager, Semogen
Processor ja Semogen Player. Semogen Managerin vastuulla on toteuttaa tiedonhallintaan ja
versiointiin liittyvät piirteet. Semogen Processor -komponentti vastaa tiedon käsittelyprosessien
toteuttamisesta, käsittelyaskelten toteuttamiseen liittyvien komponenttien hallinnasta ja tiedon
validoinnista. Semogen Playerin avulla tuotantoprosessissa syntyviä semanttisia malleja voidaan
edelleen tarkastella. Pilot-ympäristöä varten kustakin kolmesta komponentista on toteutettu
prototyyppi valituilla teknologioilla. Näiden komponenttien toteutusta on kuvattu aliluvuissa 4.1.1.,
4.1.2 ja 4.1.3.
Yleisesti ottaen konelaboratorioympäristössä on haluttu toteuttaa käyttäjälle mahdollisuus selata
semanttisessa muodossa olevaa suunnitteluaineistoa, tarkastella 2D- ja 3D-visualisointeja
järjestelmästä ja seurata simulaatiomallin tuottamia tapahtumien etenemistä järjestelmässä.
Konelaboratorioita voidaan käyttää suunnitteluvaiheen tukemiseen, koulutuksessa ja koneen
ylläpito- ja käyttöohjeena.
Konelaboratorioille on tunnistettu erilaisia käyttäjän kannalta tarpeellisia ominaisuuksia (Helminen,
Palonen, Rokala, Ranta, Mäkelä, Koskinen, 2011; myös Salonen, Nykänen, Ranta, Nurmi,
Helminen, Rokala, Palonen, Alarotu, Koskinen, Pohjolainen 2011):










Mahdollisuus
ketterään
suunnittelun
prototypointiin
muuttamalla
koneen
suunnittelutiedostoja.
Dynaaminen reaaliaikainen simulaatio koko koneelle tai sen osalle.
Koneen ohjauksen toiminnan simulointi.
Komponenttihaku sekä navigointi kaavioiden ja komponentin tietojen välillä semanttisen
mallin avulla.
Uuden suunnittelutiedon liittäminen osaksi järjestelmää ohjelmiston koodia muuttamatta.
Dynaamiset 2D- ja 3D-visualisoinnit koneen suunnittelukaavioista ja mekaniikkamalleista.
Mittausvälineet järjestelmässä tapahtuvan dynamiikan mittaamiseksi (paine, tilavuusvirta,
voima, asento).
Toimintoketjun kuvaus semanttiseen malliin ja toimintoketjun esittäminen käyttäjälle.
Simulaation toiminnan ajonaikainen muuttaminen (hidastus, kelaus, toisto).
Yhtenäinen käyttöliittymä.
38
Vertailuteknologiana toimivassa virtuaalisen konelaboratorion (virtuaalinen hakkuukone
toteutettuna M1-teknologioilla) toteutettiin näitä ominaisuuksia. Tässä eivät toteutuneet seuraavat
ominaisuudet:




ketterät muutokset suunnitteluaineistossa,
semanttista mallia hyödyntävä haku,
uuden suunnittelutiedon liittäminen osaksi järjestelmää ohjelmiston koodia muuttamatta
yhtenäinen käyttöliittymä.
Semogen-hankkeen pilot-ympäristössä kaikkien ominaisuuksien toteuttamiseen etsittiin menetelmiä
ja teknologioita.
M1-ympäristön jatkokehittämisen sijaan päädyttiin suunnittelemaan kokonaan uusi prototyyppi,
joka tukisi juuri semanttisen mallin avulla jäsenneltyä suunnitteluohjelmien tuottamaa
suunnitteluaineistoa. M1-ympäristöä ei ole suunniteltu tukemaan suunnitteluohjelmien tuottamaa
tietoa ja samalla teknologiat, joita voidaan käyttää konelaboratorion toteuttamiseen ovat kehittyneet.
Selainohjelmistojen nopea kehitys on tuonut selaimen päteväksi ohjelmointialustaksi ja helpottanut
katselimen luontia suunnitteluainoiston 3D-malleja ja 2D-kaavioita varten. Vuonna 2010 Firefox- ja
Google Chrome (Chromium) -selaimet sitoituivat kehittämään selaimensa 3D-grafiikan
suorituskykyiseen esittämiseen ja selaimet soveltuivat jo erinomaisesti SVG-kuvien katseluun sekä
vuorovaikutteisuuden luontiin niihin. Suunnnitteluaineistosta saatiin jo projektin alkuvaiheessa
generoitua selaimessa avautuvaa 2D- ja 3D-aineistoa. Vastaavasti M1:ssä niiden käyttäminen olisi
vaatinut paljon lisätyötä. Tästä syystä päätettiin tehdä selaimesta pääkäyttöliittymä ohjelmaan.
Semanttisen webin tekniikoita toteutetaan erityisesti toimimaan WWW-selaimissa ja WWWpalvelimissa. Projektissa tehdyt kokeilut kevyellä WWW-palvelimella, selaimen 3D-näyttimellä
sekä M1:ssä havaittu SVG:n käsittelyn helppous selaimessa rohkaisivat jatkamaan kokeilujen
perusteella toimiviksi havaittujen teknologioiden avulla konelaboratorion ominaisuuksien
toteuttamista.
4.1.1. Eclipse-kehitysympäristö (Semogen Manager)
Pilot-ympäristön prototypoinnissa tavoitteena on määritellä ja toteuttaa sellainen työympäristö,
jossa eri suunnitteluohjelmistoista saatava tieto voidaan koota yhteen ja edelleen viedä ulos
erilaisiin kohdesovelluksiin. Tavoitteena on, että ympäristö tukisi integroitumista moniin erilaisiin
suunnitteluohjelmistoihin. Ympäristön avulla semanttista tietoa voitaisiin myös rikastaa. Sen tulisi
tukea myös vientiominaisuuksien toteuttamista semanttisen tiedon viemiseksi erilaisiin
kohdejärjestelmien tukemiin formaatteihin.
Prototyyppi pilot-ympäristöstä on toteutettu Eclipse-sovelluskehyksen (http://www.eclipse.org/) ja
sen tarjoamien perustoiminnallisuuksien ja -työkalujen avulla (kuva 4.1.1.1). Eclipse on pitkälle
kehittynyt, vakaa, avoimen lähdekoodin sovelluskehys ja se perustuu joustavaan
laajennusmekanismiin. Erilaisten dokumenttin katselu, muokkaaminen ja käyttö on ympäristössä
hyvin tuettua. Laajennusten avulla sovelluskehystä voidaan laajentaa esim. Java, C/C++, Python ja
C#-kehitysympäristöksi. Myös XML-tekniikoiden (XML, XSLT) käyttö on hyvin tuettua.
Ryhmätyöominaisuuksia ja versionhallintaa varten kehys sisältää tuen CSV-versionhallintaan.
Myös muiden versionhallintajärjestelmien tuki on saatavissa laajennusten avulla.
39
Kuva 4.1.1.1. Eclipse-kehitysympäristön hyödyntäminen pilot-ympäristön
prototyypissä Semogen Manager ja Semogen Processor -toteutuksissa
Pilot-ympäristön nykyisessä prototyypissä mallinnettavat tiedot jäsennetään Eclipseen projekteiksi.
Kuhunkin projektiin sisällytetään siihen liittyvät resurssit. Projektien välille voidaan tarpeen
vaatiessa myös luoda riippuvuuksia, esimerkiksi useissa projekteissa tarvittavien työvälineiden
käsitteellistämiseksi. Yksittäinen projekti jaetaan edelleen käsitteellisesti useaan osa-alueeseen.
Näitä osa-alueita ovat aktiviteetit (activities), kirjastot (lib), tiedonkäsittelyputkilinjat
(pipelineprocessing) sekä näitä prosesseja tukevat työvälineet (tools). Sekä osa-alueet, että niiden
sisältämät resurssit jäsennetään projektiin kansioina. Tällä tavoin tietoja voidaan mm. siirtää ja
kopioida helposti projektien välillä pelkän resurssienhallinnankin avulla.
Aktiviteetit ovat projektiin liittyviä prosessin osia. Kussakin aktiviteetissa toteutetaan jokin
yksittäinen osa koko prosessia. Esimerkiksi hydrauliikan tai simulaation suunnittelu voidaan
jäsentää aktiviteeteiksi. Jokaiseen aktiviteettiin liittyy sekä tiedollisia vaatimuksia sekä erilaisia
resursseja.
Aktiviteettiin liittyvät tiedolliset vaatimukset (requirement) kuvaavat aktiviteetin edellyttämät
tiedotarpeet siihen tuotettavalta aineistolta. Esimerkiksi hydrauliikan suunnittelussa vaatimukseksi
voidaan kuvata, että hydraulikaavioissa kuvataan komponentteihin liittyvät tunnisteet ja
komponettien väliset yhteydet siten, että ne voidaan koneellisesti jäsentää kaaviosta.
Kuhunkin aktiviteettiin liittyviä resursseja voidaan tunnistaa ainakin kolme erilaista tyyppiä:
ulkoiset, generoidut ja käsin kuvatut resurssit. Aktiviteettiin liittyvät ulkoiset resurssit (external)
ovat perusjärjestelmien, kuten Vertex HD, käyttämiä resursseja. Pilot-ympäristö ei tue näiden
resurssien muokkaamista, vaan ne työstetään ympäristöstä ulkoisissa perusjärjestelmissä.
40
Generoidut resurssit (generated) ovat aineistoista automaattisesti tuotettuja, generoituja resursseja.
Generointi on voitu tehdä joko suunnitteluohjelmistojen tuontitoiminnolla tai pilot-ympäristön
tarjoamilla työvälineillä. Jos jonkin osa-alueen tuottaminen ei generointiprosessin avulla ole
mahdollista tai kannattavaa, voidaan lisäksi hyödyntää käsin kuvattuja resursseja (mappings). Käsin
kuvatut resurssit sisältävät täydennettyä tietoa mallista niiltä osin kuin tietoa ei ole muualta
saatavissa. Nämä resurssit voidaan tuottaa esimerkiksi pilot-ympäristössä sen tarjoamien editorien
avulla. Esimerkiksi hydraulikaavioon voidaan käsin kuvatuilla resursseilla täydentää tietoa siihen
liitettyjen komponenttien ominaisuuksista, esim. simuloinnin tarpeisiin.
Kirjastot (lib) täydentävät aktiviteetteihin liittyviä projektin resursseja. Kirjastoon voidaan
sisällyttää aktiviteettien tavoin ulkoisista järjestelmistä tuotuja ja käsin kuvattua. Ajatuksena on, että
kirjastoidut resurssit ovat käytettävissä useissa eri aktiviteeteissa - ts. kirjastoidut resurssit ovat
projektin sisällä uudelleenkäytettäviä. Esimerkiksi komponenttitoimittajalta saatavat tarkat
spesifikaatiot komponentin hydrauliikka ja simulointimallista voidaan liittää kirjastoon, jolloin
niihin voidaan viitata sekä hydrauliikan että simuloinnin suunnitteluaktiviteeteista. Kirjastointia
voidaan hyödyntää myös tiedon jakamiseen useiden projektien välillä määrittelemällä projekteille
näiden välinen riippuvuus.
4.1.2. Tiedonkäsittelyn putkilinja (Semogen Processor)
Generointiprosessit (pipeline-processing) kuvaavat prosessikohtaisesti vaiheittain ne toimenpiteet,
jotka kyseiseen generointiin liittyvät. Vaihekuvaukset sisältävät mm. tiedon siitä, mitkä syötetiedot
kuhunkin vaiheeseen liittyvät, mitä työvälineitä (tools) tarvitaan vaiheen suorittamiseen sekä minne
vaiheeseen liittyvät tulostiedot sijoitetaan. Syötetietojen tarkistus voidaan suorittaa vaihekohtaisesti,
jos siihen liittyvät tiedolliset vaatimukset on kuvattu.
Kuva 4.1.2.1. Visualisointi sovellustapauksessa käytetystä generointiputkilinjasta
Kuvassa 4.1.2.1 on visualisoitu sovellustapauksessa käytetty generointiputkilinja. Putkilinja
koostuu yksittäistä, nimetyistä osatehtävistä (askeleista) sekä näiden välille kuvatuista
riippuvuuksista. Putkilinjaan kuvatut tehtävät voidaan suorittaa joko kokonaisina tai askeleittain,
kuitenkin siten, että kutakin askelta vastaavat riippuvuudet tulevat suoritetuiksi.
41
4.1.3. Semoplayer (Semogen Player)
Pilot-ympäristön keskeinen osa on semanttista mallia käyttävä kevyt Semoplayer-ohjelmisto.
Semoplayerin ohjelmistoarkkitehtuuri ja komponentit suunniteltiin tukemaan nopeaa
konelaboratorion prototypointia. Näkymiä ja erilaisia käyttöliittymiä voidaan suunnitella erikseen
model-view-controller-mallin mukaisesti tekemättä muutoksia muualla ohjelmassa tai
asetustiedostoissa. Pilot-ympäristöä voidaan muuttaa ja sen osia voidaan vaihtaa tai lisätä ilman
suuria muutoksia itse kirjoitettuun ohjelmakoodiin. Semoplayeriin liitetyt ulkopuoliset kirjastot ovat
lisenssoitu avoimiksi ja itse Semoplayer julkaistaan ja lisenssoidaan avoimen lähdekoodin BSDlisenssillä.
Semoplayer-prototyypin ideana on toteuttaa kuvan 4.1.3.1 mukaista arkkitehtuuria mahdollisimman
paljon. Suunnitelmassa WWW-palvelin toteuttaa rajapinnan semanttiseen malliin. Simulaatio
päivittää semanttiseen malliin tietoja komponenttien tilasta WWW-palvelimen kautta. Selain on
yhteydessä WWW-palvelimeen ja voi sen kautta pyytää erilaisia simulaatioita ajettavaksi.
Selaimesta voidaan myös WWW-palvelimen rajanpinnan kautta tehdä kyselyitä ja muokkauksia
semanttiseen malliin.
Kuva 4.1.3.1. Konelaboratorion osa-alueet ja niiden väliset yhtymäkohdat viestinkulkuineen
Pääosin tämä malli toteutuu nyt kehitetyssä prototyypissä ja sen toteutuksen ongelmat on
tunnistettu. Vision tekninen toteuttaminen vaatii ratkaisun muutamiin ongelmiin. Ratkaisematta on,
miten simulaatio saadaan ajonaikana muutettavaksi, ja voidaanko tarjota usealle käyttäjälle eri
simulaatiota yhdeltä palvelimelta vai pitääkö simulaatio ajaa asiakaskoneella reaaliaikasimulaation
viiveen hallitsemiseksi ja laskennan hajauttamiseksi. Lisäksi semanttisia web-sovelluskehyksiä,
42
jotka toteuttaisivat semanttisen mallin päivitys- ja kyselyrajapinnan, ei ole tällä hetkellä olemassa.
Täytyy myös huomata, että tällä hetkellä suunnitteluohjelmat tukevat hyvin heikosti semanttista
mallinnusta ja niiden tuottama suunnitteluaineisto ei voida hyödyntää visualisoinnissa, koska
hankkeen tavoitteet ja käyttötarkoitukset ovat uusia. Parhaimmillaan järjestelmä lukisi
suunnitteluohjelmien tuottamia koneluettavia resursseja sellaisenaan ilman ihmisen suorittamia
korjauksia.
Semoplayer sisältää erittäin nopean, Tornado WWW-palvelimen (http://www.tornadoweb.org/).
Tornado vastaa hyvin tarpeisiin jaella ja koostaa WWW-selaimella katseltavia
käyttöliittymänäkymiä sekä vaatimukseen reaaliaikasimulaatiosta. Nopea vasteaika simulaation
kanssa saavutettiin käyttämällä Tornadon tukemaa WebSocket-protokollaa. Semoplayerissa on
semanttisen mallin kyselykieltä (SPARQL) käyttävä rajapinta, jonka avulla voidaan hakea tietoa
semanttisesta mallista. Semoplayerin selainpohjainen Ajax-mallinen käyttöliittymä on toteutettu
JavaScript-ohjelmointikielellä käyttäen useita valmiita vapaan lähdekoodin JavaScript-kirjastoja.
Lisätietoa Semoplayerista löytyy sitä käsittelevästä julkaisusta (Salonen, Nykänen, Ranta, Nurmi,
Helminen, Rokala, Palonen, Alarotu, Koskinen, Pohjolainen, 2011).
43
4.2. Sovellustapaus
Yhtenäinen käyttöliittymä on luotu selaimeen, jossa 2D- ja 3D-visualisoinnit toimivat rinnakkain.
2D-visualisoinnit ovat SVG-kuvia, joiden tiedot ovat yhteydessä semanttiseen malliin ja jotka
toimivat osana käyttöliittymää. 3D-visualisoinnit ovat X3D-malleja, jotka esitetään X3DOMnäyttimen avulla. X3DOM tarjoaa 3D-näyttimelle tarpeelliset ominaisuudet. 3D-maailmassa voi
liikkua, kappaleita voi valita ja korostaa sekä 3D-malli on linkitetty osaksi muuta käyttöliittymää ja
semanttista hakua.
Sekä M1:stä ja Semogen pilot-ympäristöä toteutettaessa havaittiin Simulink-ohjelman rajoitteet
luoda ajonaikana muutettavaa simulointimallia. Ensinnäkin simulointimallin muokkaaminen ja
kääntäminen vaatii käytännössä aina Matlab- ja Simulink-ohjelmistojen lisenssit sekä paikallisen
asennuksen. Kääntäminen muihin ympäristöihin kuin Windowsiin on käytännössä osoittautunut
myös hankalaksi, sillä osa simulointimalleissa käytetystä ohjelmistokoodista on alustariippuvaista.
Konelaboratorioiden jakelun ja opetuskäytön kannalta olisi eritiysesti toivoittavaa, että
simulointimalleja voitaisiin ajaa Linux- ja Unix-palvelimella. Käännettyihin Simulink-mallien
palvelinkäyttö on myös muutoin osoittautunut haastavaksi. Esimerkiksi simulointimallien käyttämät
portit (TCP, UDP) joudutaan kovakoodaamaan käännöstä varten, mikä käytännössä estää saman
simulaation usean kopion ajon rinnakkain palvelinympäristössä.
Konelaboratoriossa on tarve tarkastella erilaisia toimintojen kokonaisuuksia (esim. puomin nosto).
Näitä toimintoketjuja tai edes komponentin yksittäisiä toimintoja ei ole kuvattu
suunnitteluaineistossa. Siksi toimintoja ja toimintoketjuja kuvaava semanttinen tieto lisättiin
käsityönä osaksi semanttista mallia. Toimintoketju on mallinnettu tietokoneluettavaan muotoon
määrittelemällä sille malleja ja ontologioita.
Toiminnot mahdollistavat toisia toimintoja ja muodostavat toimintojen verkon. Toimintojen
verkossa kuljetut polut muodostavat lopulta toimintoketjun. Koska toimintoketjun jokainen
toiminto liittyy aina komponenttiin, voidaan toimintoja tarkastella myös komponenttien
vuorovaikutusketjuna.
4.2.1. Käyttöliittymä
Selaimeen toteutettu käyttöliittymä on vuorovaikutteinen käyttäjän näkymä suunnitteluaineistoon ja
semanttiseen malliin. Se pyrkii esittämään semanttisessa mallissa olevan suunnittelutiedon välisiä
yhteyksiä käyttäjälle. Esimerkiksi komponenttia voidaan tarkastella 2D- ja 3D-visualisoinnista ja
hakea siitä tietoja. Semanttinen haku mahdollistaa navigoinnin järjestelmän suunnitteluaineiston
avulla valitsemalla hiirellä haluttu komponentti tai valitsemalla komponentteja valmiiden
kategorioiden mukaan.
Seuraavaksi esitellään lyhyesti keskeisimmät käyttöliittymän toiminnot selainnäkymästä otettujen
kuvakaappausten avulla.
44
Kuva 4.2.1.1. Näkymä katselinohjelmiston käyttöliittymästä. Vasemmalla hydraulikaavio, oikealla puomin 3Dmalli. Hydraulikaaviosta on valittu ohjausventtiili (keltainen korostus) . Valitsemalla hiirellä komponentti 2D- tai
3D-visualisoinnista voidaan tulostaa semanttisesta mallista komponenttiin liittyvää tietoa (keskellä).
Esimerkiksi CAN-väylä ja siinä olevat CAN-komponentit on visualisoitu ja visualisointi voidaan
avata käyttöliittymässä (kuva 4.2.1.2). Haulla voidaan hakea kaikki CAN-komponentit listana ja
korostuksella kertoa, mikä komponentti on visualisoinnissa, kun hiiri viedään sen nimen päälle.
Taulukossa on signaalin tunniste, nimi sekä määränpää- ja lähtönodet listattuna.
45
Kuva 4.2.1.2. CAN-signaalien taulukkolistaus ja visualisoitu CAN-väylä. Komponenttikuvien lähdetiedot
sijoitettu lähdeluetteloon
Vastaavaa tarkastelua voidaan suorittaa hydrauliaineistolle (kuva 4.2.1.3). Katseltavan kaavion voi
valita malliin liittyvistä aineistoista.
Kuva 4.2.1.3. Hydrauliosat taulukoituina ja oikealla avattuna hydraulikaavio
Semanttiseen malliin rikastettua toimintoketjua voidaan tarkastella käyttöliittymässä graafina, jossa
käyttäjä saa edetä toimintoa edustava solmu kerrallaan eteenpäin. Jokainen toiminto liittyy
komponenttiin ja komponentti korostuu kaaviossa kun hiiri viedään graafin solmun päälle (kuva
4.2.1.4).
46
Kuva 4.2.1.4. Käyttäjä on edennyt neljä askelta graafissa, jolloin seuraava toiminto paljastuu ketjusta. Oikealla
hydraulikaaviossa korostettuna osa, johon toiminto liittyy.
Opetuskäytössä käytettävistä mittaustyövälineistä toteutettiin piirturi. Simulaatiolta tulevia arvoja
voidaan tarkastella ja tietyn valitun arvon käyttäytymistä voidaan seurata piirturissa ajan suhteen
(kuva 4.2.1.5).
47
Kuva 4.2.1.5. Simulaatiolta tulevat mittausarvot taulukoituina. Valittu arvo esitetään piirturissa.
48
5. Tiedotus ja liiketoimintahyödyt
Kirjoittanut Pekka Ranta
5.1. Tiedotus
Semogen-hanke edustaa uutta avausta, jonka tulokset liittyvät laajemminkin teollisuuden
virtuaaliympäristöjen hyödyntämiseen osaamisen kehittämisessä, tutkimus- ja tuotekehityksessä,
suunnittelussa ja laajemmin jälkimarkkinointipalveluissa. Hankeen tuloksista tulee tiedottaa
aktiviisesti. Tämä on myös rahoittajan kanta.
Hankkeen tiedotustavoitteiksi määriteltiin:






Viestiä sidosryhmille virtuaalisten konelaboratorioiden mahdollisuuksista sekä herättää
laajempi kiinnostus näiden mahdollisuuksiin.
Muodostaa kriittinen massa virtuaalisten konelaboratorioiden hyödyntäjistä.
Korostaa uutta avausta konejärjestelmien suunnitteluprosessien kehittämiseen
virtualisoinnin ja digitaalisen tuoteprosessin avulla.
Tuotantomenetelmien kehitys on edellytyksenä laajempaan ja kustannustehokkaaseen
levitykseen.
Tukea rahoittajan tahtotilaa innovaation kaupallistamiseen sekä levitykseen.
Tukea II vaiheen rahoitushakua sekä innovaation jatkokehittämistä.
Tiedotuksen keskeisinä kohderyhminä ovat koneenrakennussuunnittelijat
koulutusorganisaatioiden johto, rahoittajat ja yritysosapuolet.
ja
-johtajat,
Tiedotus on painottunut hankkeen loppuun. Hankkeen tiedotustoimenpiteet:








Hankkeesta on toimitettu lehdistötiedote suomalaisiin tiedotusvälineisiin 15.9.2011 TTY:n
tiedotuksen avulla.
Vertex Systems Oy:n asiakaslehdissä on esitelty kahteen otteeseen hanketta.
Konejärjestelmien järjestelmäsuunnittelun standardointiyhteisöä tavoitettiin CAN in
Automation -standardointiehdotuksen avulla.
Tiedeyhteisö on tavoitettu useissa konferenssi- ja lehtiartikkeleissa. Fluid Power
Hankkeesta on kerrottu useaan otteeseen konsortion henkilöstölle sekä työpajojen ja
tapaamisten avulla
Teknologiateollisuuden 100-vuotissäätiön hallitukselle on esitetty hanketta kahteen eri
otteeseen.
TEKES-edustajat ovat myös tietoisia hankkeesta. Suunnitteilla on TEKES-yhteissseminaari,
jossa myös Semogen-hankkeen tuloksia esitellään.
Hankkeen wiki-sivu. https://wiki.tut.fi/SmartSimulators/Semogen, josta löytyy hankekuvaus
sekä hankkeen tulosaineistot.
Hankkeen tulosten käyttöoikeuksissa on hyödynnetty avoimen lähdekoodin periaatteita. Kehitetyt
ohjelmistot julkaistaan BSD-lisenssoituna (Berkeley Software Distribution-licence), joka on vapaa
ohjelmistolisenssi ja yksi käytetyimmistä avoimen lähdekoodin lisensseistä. Hankkeen dokumentit
kuten tämä loppuraportti julkaistaan Creative Commons -lisenssein. Hankkeen tulosaineistot
jaellaan wiki-sivuston kautta.
49
5.2. Liiketoimintahyödyt
Yrityskumppanit toimivat aktiivisesti Semogen-hankkeessa. Keskeisinä työtapoina ovat
ohjausryhmätyö, raportoinnit, työpajat sekä tapaamiset. Hankkeessa kartoitettiin yritysosapuolten
näkemykset hankkeen hyödyistä. Ne jakautuivat neljän pääteeman alle:
Semanttisen prosessin osaamisen hyödyt







Osataan tuottaa suunnitteluprosesseja tehokkaammin ja pienemmin kustannuksin.
Kustannussäästöt esim. simulointimallien hyödyntämisestä suunnittelun tarpeisiin
Osataan jo suunnitteluvaiheessa ottaa huomioon liiketoiminnan muita prosesseja esim.
huoltoliiketoimintaa tukevia prosesseja, kuten älykkäitä koulutustuotteita, varaosakirjoja,
vianetsintäohjeita jne.
Malli mahdollistaa tulevaisuudessa tuotekehitysprosessien tehostamisen.
Suunnittelun ja teknisen informaation yhteistyön kehittyminen
Projektin hallinnointi - dokumentaation liittäminen virtuaaliympäristöön, esim. simulink
mallien käyttö osana määrittelydokumentaatiota
Kunnossapito - elinkaarenhallintatiedon integrointi ko. ympäristöön - huoltotiedon
lisääminen konemalliin, komponenttien kuormitusten esittäminen virtuaalikoneessa,
varaosavaihdon suunnittelu ja ohjeistaminen
Semogen-hanke sisältää kokonaan uudenlaista suunnittelun ja tuotehallinnan ajatusfilosofiaa
- sen toteutuksessa käytetään novelleja ohjelmistotyökaluja ja –rajapintoja.
Liiketoiminnalliset hyödyt










Hankkeessa syntyy prototyyppi prosessista, josta on jatkojalostettavissa yrityksemme
palvelutuotteiksi
R&D - Suoraviivaisempi ja tehokkaampi konejärjestelmien kehitystyö
Virtuaalinen konseptointi – teknologiaratkaisujen tehokas analysointi ja vertailu, esim.
puomirakenteet ja liittyvät ohjausjärjestelmät
Tuotekehitys - korkean tason toiminnallinen kuvaus konejärjestelmistä
Tuotanto - kokoonpanovaiheiden kuvaaminen tehdyn virtuaalimallin pohjalta, nykyisin
erikseen tehtävä ohjeistus
Kunnossapito - elinkaarenhallintatiedon integrointi ko. ympäristöön - huoltotiedon
lisääminen konemalliin, komponenttien kuormitusten esittäminen virtuaalikoneessa,
varaosavaihdon suunnittelu ja ohjeistaminen
Kokonaisprosessi suunnittelusta simulaatioon ja älykkäisiin lopputuotteisiin, joita
hyödynnetään
huoltoliiketoiminnassa.
Esimerkiksi
älykkäät
varaosakirjat,
koulutusmateriaalit ja huolto-ohjeet
Yrityksemme haluaa olla ensimmäisten joukossa, jotka luovat uusia liiketoimintamalleja
hyödyntämällä tätä mallia.
Semanttisen
mallin
hyödyntäminen
antaa
mahdollisuuksia
kehittää
uutta
palveluliiketoimintaa tekniseen informaatioon ja suunnitteluun.
Uudesta suunnitteluprosessista lisäarvoa asiakkaidemme huoltoliiketoiminnalle
50

Tuotanto - kokoonpanovaiheiden kuvaaminen tehdyn virtuaalimallin pohjalta, nykyisin
erikseen tehtävä ohjeistus
Koulutuksen ja osaamisen kehityksen hyödyt





Lisää mahdollisuuksia vianhaun koulutukseen, joka käytännössä on hyvin vaikea toteuttaa
Mahdollisuus itsenäiseen työskentelyyn, jolloin kouluttaja vapautuu paremmin muiden
ryhmien käyttöön
Uusi, mielenkiintoinen tapa opiskella hydrauliikkaa.
Operaattorien osaaminen- käyttökelpoisia komponentteja koulutussimulaattoreihin
Hanke antaa uusia ulottuvuuksia kehittää esim. verkkokursseja ja työkaluja osaamisen
testaamiseen.
Markkinointi ja imagohyödyt






Parantaa yrityksen brändiä ja yrityskuvaa
Uuden osaamisen avulla voimme erottua kilpailijoista ja saada uusia asiakkaita
Tuotekehitysprosessien tehostaminen parantaa asiakkaidemme kilpailukykyä ja se
mahdollistaa yrityksellemme uutta liiketoimintaa
Sisäinen markkinointi - uusien ajatusten esittäminen
Ulkoinen markkinointi - yksityiskohtaisesta mallista irrotettavissa edustavaa materiaalia
markkinoinnille, videota ja kuvakaappauksia
Ajateltaessa hankkeen tulosten hyödyntämistä ja sen jälkeen kaupallistamista, lienemme
tässä vaiheessa vielä koe- ja soveltamisympäristöjen käytössä. Tärkeintä nyt on saatujen
tulosten laaja-alaisempi levittäminen ja disseminaatio. Tämän kautta saadaan laajempaa
asiakaskokemusta ja koulutuksen kautta asiantuntijaosaamista. Vasta tämän jälkeen meillä
on oikeat ja realistiset mahdollisuudet esim. uusiin kaupallisiin suunnitteluohjelmistoihin.
Tästä syystä näenkin suurena vaarana, että hyvin alkanut kehitystyö keskeytyy liian aikaisin
kaupallistamisen näkökulmasta.
Voidaan todeta, että yrityskonsortio tunnistaa hankkeessa kaupallista potentiaalia. Semanttinen
prosessi ja virtuaalinen konelaboratorio ovat varsin uusia tutkimusalueita, joten perustutkimusvaihe
pitää huolellisesti toteuttaa. Tämän tiedon päälle on mahdollista kehittää soveltavaa tutkimusta.
51
5.3. Kaupallistamismalli
Hankkeen tavoitteisiin kirjattiin tuotantomenetelmien ja teknologioiden kaupallistaminen.
Hankkeen kuluessa vahvistui käsitys, että kyseessä on perustutkimus, jonka tulokset on mahdollista
kaupallistaa soveltavamman tutkimus- ja yrityskohtaisten projektien avulla. Ohjausryhmä totesi,
että kaupallistaminen siirretään seuraavaan vaiheeseen.
52
6. Johtopäätökset
Kirjoittanut Pekka Ranta, Kari T.Koskinen ja Seppo Pohjolainen
Semogen-tutkimushankkeen keskeinen haaste oli kehittää menetelmiä ja malleja käsityön
vähentämiseksi virtuaalisten konelaboratorioiden rakentamisessa. Esimerkiksi hydrauliikkakaavion
visualisointi konejärjestelmän toiminnan havainnollistamiseksi vaati asiantuntijalta suuren käsityön,
vaikka lähdeaineisto oli digitaalisena. Vastaava tilanne koski monia muita teknologia-alueita.
Lisäksi konejärjestelmän moniteknisten toimintaketjujen aineisto piti kokonaisuudessaan tuottaa
käsin puhumattakaan järjestelmän simulointimallista. Automatisoinnille oli selkeä tilaus. Nämä
haasteet ohjasivat etsimään ratkaisuja uusista lähestymistavoista, menetelmistä sekä näkökulmista.
6.1.Viitekehys
Hankkeen keskeinen oivallus liittyi informaation prosessoinnin teoreettisen viitekehyksen ja
edelleen semanttisen mallinnuksen hyödyntämiseen konejärjestelmän kokonaisvaltaisessa
mallinnuksessa. Hypermediassa nämä ovat luontaisia lähestymistapoja. Pelkällä viitekehyksellä tai
mallinnusmenetelmällä ei saavuteta läpimurtoa, jos ei ole syvällistä konejärjestelmien osaamista ja
suunnitteluaineistojen ymmärrystä. Tähän koneenrakennuksen - kuten hydrauliikan ja automatiikan
- tieteenalat tuovat vahvan perustan. Näiden moniteknisten tieteenalojen avulla voitiin rakentaa
mallinnusmenetelmä, jossa eri teknologioiden suunnitteluinformaatio virtaa sovittimien välityksellä
kohti konejärjestelmän linkittynyttä kokonaismallia eli koneellisesti käsiteltävää formaalia
semanttista mallia. Tätä kutsutaan putkilinjastoksi (pipeline). Semanttinen malli ja hankkeessa
kehitetyt mallinnus- ja simulointimenetelmät tukevat simulointimallin semiautomaattista
generointia. On huomioitava, että kaikkea mallinnuksessa tarvittavaa informaatiota tai algoritmeja
ei voida automaattisesti prosessoida, koska tämä edellyttää konejärjestelmän syvällistä
mallinnusosaamista. Lisäksi mallinnusmenetelmä tarjoaa ratkaisumallin suunnitteluinformaation
rikastamiseen loppukäyttäjien tarpeiden perusteella.
53
6.2.Suunnittelumalleista
Hankkeen alkuvaiheessa havaittiin, että suunnitteluaineiston eheydessä, rikkaudessa sekä erityisesti
koneen käsiteltävyydessä on kehittämistä. Suunnittelukäytäntöjen mallinnuksessa nousi esiin
havainto, että suunnittelijat suunnittelevat luonnollisesti tuotantoa varten ja tuottavat määrityksiä
muille suunnittelijoille. Tämä aineisto on pääosin digitaalista, mutta osa informaatiosta siirtyy
keskustelujen, muistioiden ja yhteisten käytäntöjen välityksellä. Semanttisen mallinnuksen kannalta
tilanteen tekee haasteelliseksi se, että kone ei pysty käsittelemään tällaista tietoa, koska se ei ole
tuotettu tarvittavalla formaatilla ja syntaksilla. Aikaisemmin teollisuudessa oli asiantuntijarooli normitarkastaja-, jonka vastuulla oli suunnittelutiedon eheyden, säännönmukaisuuksien ja
käytänteiden seuranta. Tämä rooli on siirtynyt suunnittelijoiden vastuulle. Moniteknisen tiedon
validoinnin, yhteensopivuuden sekä kattavuuden hallintaan tarvittaisiin uusi rooli –teknisen tiedon
hallinnan suunnittelija (knowledge engineer). Hänen roolinsa tukisi suunnittelua siten, että
monitekninen tieto olisi suunnittelunormiston mukaista sekä koneluettavaa. Luonnollisesti roolin
työtä tukisi mahdollisimman saumattomat rajapinnat eri suunnitteluohjelmien välillä.
Hankkeessa
mallinnettiin
suunnittelijoiden
työnkuvausten
perusteella
semanttinen
prosessimalliehdotus, jossa luonnolliseen suunnitteluprosessiin kiinnitettiin semanttisen
mallinnuksen vaatimuksia. Hankkeessa tunnistettiin seuraavat luonnolliset suunnitteluosa-alueet,
jotka tulisi huomioida semanttisessa prosessimallissa: konsepti-, mekaniikka-, hydrauliikka-, sähkö,
automaatio- ja ohjelmistosuunnittelu sekä virtuaaliprototypointi. Semanttinen prosessimalliehdotus
toimii eräänä lähtökohtana kehittyneempien suunnittelumenetelmien kehityksessä. Parhaimmillaan
semanttinen suunnitteluprosessi sovitettuna yrityksen omiin prosesseihin luo toimintamallin, joka
tarjoaa suunnittelutiimille yhtenäisen tavan tuottaa, tallentaa, kommentoida, jakaa sekä visualisoida
suunnitteluaineistoa suunnitteluvaiheen mukaisesti. Tämä mahdollistaisi moniteknisen järjestelmän
iteratiivisen ja holistisen tarkastelun ja suunnittelumallien virtuaalisen visualisoinnin sekä
prototypoinnin käyttäjäystävällisellä tavalla. Ohjelmistotuotannossa vastaavat ajatukset ovat
helpottaneet virheiden havaitsemista jo varhaisessa vaiheessa sekä vähentänyt kommunikaatioongelmia ja dokumentaation tarpeen määrää.
54
6.3. Semanttinen mallinnuksen teknologiat
Semanttisessa mallinnuksessa hyödynnettiin työvälineitä, ohjelmistoja sekä sovelluskehyksiä, jotka
on saatavilla varsin yleisesti. Nämä on listattu väliraportissa luvussa 3. .Hankkeen tulosten
perusteella voidaan suuntaa-antavasti todeta, että työvälineet, ohjelmistot ja sovelluskehykset
vaikuttavat lupaavilta. Virtuaalinen konelaboratorioprototyyppi saatiin lisäksi toimimaan
selainteknologioilla,
joka
tarjoaa
virtuaaliympäristön
jakamisen
yhteisöllisesti.
Selainteknologioiden avulla voitiin ajaa reaaliaikasimulointia sekä visualisoida simuloituja
signaaleja varsin pienellä aika-askeleella. Nämä teknologiat tuovat merkittäviä säästöjä
ohjelmistokoodin määrään sekä yhteensopivuuteen. Prototyypistä saatujen kokemusten perusteella,
voidaan todeta, että teknologiat vaikuttavat soveltuvan varsin hyvin virtuaalisen konelaboratorion
rakentamiseen. Haasteena on suunnitteluaineistojen rajapinnat, sillä mallien visualisointiin
tarvittavaan ohjelmistoon piti rakentaa informaation yhdistelyn, muokkauksen ja täydentämisen
ohjelmistoja. Täydellisessä maailmassa data virtaisi saumattomasti standardirajapintojen
välityksellä putkilinjastoa pitkin semanttiseen ja simulointimalliin. Visualisointitarpeiden mukaan
haetaan tarvittava informaatio, joka yhdistellään mielekkäiksi näkymiksi päätesovelluksessa.
Rajapinnat ovat olennainen osa ohjelmistoja. Hankkeen suurin resurssi kului
suunnittelutietoformaattien sekä niiden rajapintojen tutkimiseen ja ratkaisujen määrittämiseen.
Hankkeen alussa määritelty integroitu ohjelmistokehys ja semanttisen mallinnuksen työvälineet
osoittautuivat varsin toimiviksi.
55
6.4. Tuotetiedon hallinta
Tuotetieto ja digitaalinen tuoteprosessi näyttelee keskeistä osaa hankkeen isossa kuvassa. Mikäli
suunnitteluprosessissa muodostunut tuotetieto tallennetaan semanttisesti rikkaalla tavalla
tuotetietojärjestelmään (PDM tai PLM), voitaisiin tätä hyödyntää konkreettisten
suunnitteludokumenttien rinnalla. Tuotetietoon liittyvät nimikkeen hallintaprosessi ja nimikkeen
hallintajärjestelmät. Semanttisen mallinnuksen kannalta tämä tarkoittaisi järjestelmällistä
nimikkeiden hallintaa. Konkreettinen esimerkki liittyy hydrauliikan suuntaventtiiliin. Täsmälleen
samalla tuotetiedolla ja tunnisteella varustettu komponenttia hyödynnetään useassa toiminnossa.
Näin ollen pelkkä yksilöivä tunniste ei riitä, vaan edellytetään kokonaisvaltaisempaa nimeämistä ja
nimiketiedon hallintaa. Mikäli tätä ei toteuteta, ei moniteknistä komponenttitietoa sitoa muihin
teknologioihin, visualisointeihin tai näkymiin. Kokonaisvaltainen suunnittelutiedon hallinta
edellyttää järjestelmällisyyttä, prosessikuvauksia sekä tiedon hallinnan järjestelmiä sekä
informaation digitaalista jakelua tukevia rajapintoja.
Yksityiskohtaisemmin
ja
teknologia-alueittain
tarkasteltuna
tulokset
osoittivat
suunnitteluaineistoissa varsin suuria eroja. Erityisesti automaatiosuunnitteluun liittyvän
järjestelmäsuunnittelun CANopen (CiA) -standardeihin perustuvat aineistot ja ohjelmistot edustavat
suuntaa, joka tarjoaa semanttisesti hyödynnettävän lähdeaineiston. Hankkeessa kehitetty CiAstandardointiehdotus väyläsolmujen GraphML(XML)-pohjaisesta listaustiedostosta CANopenjärjestelmiin edustaa suuntaa, jonka kaltaisia suunnitteluaineistojen tulisi tulevaisuudessa olla.
Tässä ehdotuksessa on pystytty rakentamaan yhteys eri teknologioiden välillä. Lisäksi rakenteisiin
dokumentteihin
(XML,
SVG)
perustuvat
aineistot
vaikuttavat
asianmukaiselta
perussuunnalta.Semanttisessa mallissa hyödynnetään RDF-kuvauskehystä ja syntaksia.
Luonnollisesti suunnitteluaineistojen rajapintojen mahdollisimman hyvä yhteys RDF-perustaiseen
mallin prosessointiin toisi merkittäviä lisäarvoja. Näin voitaisiin välttyä ylimääräisten sovittimien
kehittämiseltä.Suunnitteluohjelmistoissa esim. Vertex ED, HD ja G4 on käytössä kuvailutiedon
lisäysmahdollisuus sekä asianmukaisia komponenttikirjastoja. Havaintojemme mukaan toimialalla
ei ole vielä vallitsevia suunnittelukäytäntöjä, jotka korostaisivat kuvailutiedon järjestelmällistä
käyttöä sekä tuotetiedon kirjastointiratkaisuja. Mikäli komponentit sekä niiden mallit ja tuotetieto
esimerkiksi simulointi-, 3D-, rakennemallit olisivat kirjastokomponenteina liitettävissä osaksi
suunnitteluratkaisuja, semanttinen prosessi helpottuisi merkittävästi.
56
6.5. Simulointipohjainen suunnittelu
Simulointiperustainen suunnittelu on teollisuuden eräs vahva trendi. Lentokoneteollisuuden
toimialalla koneeen ja järjestelmien simulointimalli rakennetaan suunnittelun alkuvaiheessa, ja
malli tarkentuu suunnittelun edetessä. Semogen-hankkeessa simulointimallin semiautomaattisessa
generointiin löytyi ratkaisuja, joiden avulla simulointimalleja voitiin kirjastoida sekä hyödyntää
semanttista mallia parametrisoinnin, yhteyksien kuvaamisen ja nimeämisen määritelyissä.
Simulointimalli rakennettiin modulaariseksi, jolloin matemaattisia malleja voitiin liittää
perusmalliin. Näin ollen simulointimalli on laajennettava, muokattava sekä hallittavissa. Täysin
automaattista generointia on erittäin haastava toteuttaa, koska suunnittelijoiden substanssiosaamisen
perusteella voidaan malleja verifioida.
6.6. Virtuaalisen konelaboratorion teknologiat
Sekä M1-teknologioilla rakennettu virtuaalinen konelaboratoriota sekä Semogen-hankkeen pilotympäristöä toteutettaessa havaittiin Simulink-ohjelman rajoitteet simulointimallin luonnissa.
Ensinnäkin, simulointimallin muokkaaminen ja kääntäminen vaatii aina Matlab- ja Simulinkohjelmistojen lisenssit sekä paikallisen asennuksen. Kääntäminen muihin ympäristöihin kuin
Windowsiin on käytännössä osoittautunut myös hankalaksi, sillä osa simulointimalleissa käytetystä
ohjelmistokoodista on alustariippuvaista. Konelaboratorioiden jakelun ja opetuskäytön kannalta
olisi erityisen toivottavaa, että simulointimalleja voitaisiin ajaa Linux- tai Unix-palvelimella.
Toiseksi, simuloinnista ei voida esittää kuin reaaliaikasimulaatiota. Tunnistettua tarvetta ajonaikana
muutettavasta simulointimallista, jossa voidaan esimerkiksi toistaa hidastettuna tietty toiminto, ei
voida helposti toteuttaa ohjelmistojen avulla.
Ohjelmistojen näkökulmasta hankkeessa kehitetttyä pilot-ympäristöä on mahdollista ajaa
palvelinkoneella, jolloin sitä voidaan käyttää selainohjelmien avulla verkon yli, mutta tällä hetkellä
Simulink-pohjainen simulaatio soveltuu tähän huonosti. Lisäksi hankkeessa kehitetyn pilotympäristön näytinohjelma Semoplayer ei ole tietoturvamielessä valmis ajettavaksi julkiseen
Internetiin näkyvänä palveluna. Lisäksi asiakas-palvelin-mallinen toteutus vaatisi simulaation
kääntämistä Linux- tai Unix-ympäristössä ajettavaksi. Semoplayerin muut osat ovat jo
käyttöjärjestelmäriippumattomia. Jos suunnitteluohjelmat tuottavat simulaation ja yhtenäisen
semanttisen mallin koneesta, suunnittelutyön aikana kokonaisuuksien hallinta korostuu. WWWpalvelin hyödyntää luotuja resursseja ja tarjoaa erilaisia näkymiä selaimeen, johon käyttöliittymä on
toteutettu. WWW-palvelin voi jakaa esimerkiksi suunnitteluryhmälle heidän suunnittelutyönsä
mukaista konelaboratorionäkymää, jota voidaan iteroida ja käyttää ketterän koneensuunnittelun
apuna.
57
6.7. Hyödyt, vaikuttavuus ja tulevaisuuden näkymät
Semogen-hankkeen tuloksilla on merkitystä teollisuuden moniteknisen tuotetiedon hallintaan,
tuotantoprosesseihin sekä elinkaaritiedon hallintaan. Lisäksi yhteys simulointiavusteiseen
tuotekehitykseen ja suunnitteluun on ilmeinen. Vaikuttaa siltä, että menetelmien ja teknologioiden
hyödyt korostuvat moniteknisten suunnitteluratkaisujen ajantasasaisessa tarkastelumahdollisuudessa
sekä simulointi- ja visualisointimahdollisuuksissa. Vaikutukset heijastuvat välillisesti alan
koulutukseen, suunnittelumenetelmiin, suunnitteluohjelmistojen ominaisuuksiin, suunnittelutiedon
kattavuuteeen ja eheyteen, rajapintoihin sekä tuotteen elinkaaritiedon käyttötapoihin. Valitettavasti
hankkeen
tulosten
vaikutusten
tieteellistä
vertailua
ja
vaikuttavuusarviota
nykysuunnitteluprosesseihin ei ollut mahdollista resurssihaasteiden vuoksi toteuttaa, joten hyöty ja
vaikuttavuusarviot perustuvat subjektiivisiin ja teollisuuskumppanien arvioihin
Teknologiateollisuuden 100-vuotissäätiön hallitus tunnisti hankkeen merkityksen tuotteiden t&k- ja
suunnitteluprosessin ”sähläyskustannusen” vähennysmahdollisuutena. Mikäli moniteknisen tiimin
jäsenet
keskittyvät
omaan
teknologia-alueeseen
puutteellisella
kokonaiskuvalla,
yhteensopimattomilla dokumenteilla, puutteellisella tuotedokumentti-informaatiolla sekä
vaihtelevilla suunnittelu- ja kommunikaatiokäytännöillä, heijastusvaikutukset suunnitteluprosessiin
kokonaishallintaan ovat ilmeiset. Lisäksi yhteisten suunnitteluratkaisujen ulkoistusten (esim.
prototyyppi tai simulaattori) avulla tehtyjen kokonaisarvion puute luo liian pitkän ”pimeän”
vaiheen, jolloin suunnitteluratkaisu joudutaan iteroimaan jopa perusteista asti. Kokeneet
suunnittelijat pystyvät hallitsemaan kompleksisia ratkaisuja pidempään ilman konkretisointia. Usein
suunnitteluun osallistuu eri kokemus- ja koulutustason osaajia, jolloin konkreetisten
yhteissuunnittelunäkymien tiheälle tarkastelulle on selkeä tarve.
Tuotetuen dokumentointiprosessia esim. varaosakirjat, koulutusaineistot ja osaluettelot voidaan
tukea merkittävästi, mikäli Semogen-tulosaineistojen menetelmiä ja periaatteita hyödynnetään.
Tämä vähentää merkittävästi informaation uudelleen kuvausta ja saumatonta etenemistä.
Parhaimmillaan tuotetuen dokumentaation rakentaminen etenisi suunnitteluprosessin rinnalla.
Vallitsevien käytäntöjen mukaan tämä tuotetaan usein jälkikäteen ja lähdeinformaatiota pitää
tuottaa uudestaan erilaiseen käyttötarkoitukseen. Mikäli t&k- sekä suunnitteluvaiheissa
huomioidaan myös tuotetuen tarve, voitaisiin kehittää samanaikaisesti fyysiset sekä
informaatiotuotteet.
Semogen-hankkeen tulosten perusteella voidaan karkeasti päätellä, että ensimmäisellä ja toisella
suunnitteluiteraatiolla Semogen-menetelmien, -mallien ja -teknologioiden soveltaminen lisää
suunnittelutaakkaa, mutta seuraavien iteraatioiden kohdalla merkitys vaiheittain korostuu, koska
koneluettavuus,
uudelleen
käytettävyys,
yhteensopivuus,
informaation
validius
ja
kommunikaatiomenetelmät tarjoavat lisäarvoja. Tuotteen elinkaaren hallinnassa em. ominaisuudet
voidaan
nähdä
välttämättöminä.
Tämä
luo
ketteryyttä
ja
automatisointija
räätälöintimahdollisuuksia.
Tulevaisuudessa voidaan tavoitella semanttiseen prosessiin liittyvää virtuaalista konelaboratoriota,
joka tarjoaa integroidun suunnittelunäkymän, mittaus- ja testausvälineitä, reaaliaikaisia
simulointimalleja, semanttisia hakuja, tehtävä- ja toimintaympäristöeditorin, lisätyn
virtuaalitodellisuuden havainnollistuksia sekä suunnittelutiedon eheyttä tarkastelevia validaattoreita
tuotteen elinkaaritiedon avulla. Tähän voidaan integroida kunnonvalvontainformaatioa ja
58
laajemminkin tuotetuki-informaatiota, jolloin suunnitteluratkaisuihin saadaan takaisinkytkentä sekä
tarkka ja yhteensopiva palaute, jolloin seuraava tuoteversio tai geneerisemmin tuoteperheversio
kehittyy.
6.8. Yhteenveto
Loppupäätelmänä voidaan todeta, että hankkeen tavoitteet on saavutettu pääosin. Lisäksi
määriteltyjä käyttötapakuvauksia on pystytty toteuttamaan. Hankkeen alkuperäinen yleistavoite
virtuaalisen konelaboratorion tuotantomenetelmien kehitys semanttisen mallin avulla on luonut
uusia mahdollisuuksia. Pilot-ympäristössä olevat koulutusominaisuudet eivät ole täysin vastaavia
kuin aiemmissa sovelluksissa, mutta periaatteet soveltuvat myös koulutussovellusten kehitykseen.
Semogen-hankkeen tulokset loivat perustan jatkohankkeille, josta on suunnitteilla ainakin Semogen
II Virtuaalinen konelaboratorio ja semanttinen mallinnus konejärjestelmän suunnittelun tukena.
59
Lähteet
AutomationML. Saatavilla http://www.automationml.org/
Burmester S., Giese H., Gambuzza A., Oberschelp O. (2004). Partitioning and modular code synthesis for reconfigurable mechatronic software components. Proceedings of European Simulation
and Modelling Conference (ESMc’2004), Paris, France, pp. 66-73.
Crusca, F., Aldeen, M. (2003). Simulink-based Modular Modeling of Power Systems for Faultdetection Studies. Proceedings of the 6th International Conference on Advances in Power System
Control, Operation and Management, APSCOM 2003, pp. 262-267.
CAN in Automation. Saatavilla www.can-cia.org)
Digitaalinen tuoteprosessi. TEKES. Saatavilla http://www.tekes.fi/ohjelmat/DTP/
Helminen, M., Palonen, T., Rokala, M., Ranta, P., Mäkelä, T., Koskinen, K. T. (2011). Virtual Machine Laboratory based on M1-technology. Proceedings of the Twelfth Scandinavian International
Conference on Fluid Power, vol. 1, pp. 321-334. May 18-20, 2011, Tampere, Finland.
Humaloja, J.-P. (2011). Komponenttipohjaisten simulointimallien matematiikka.
Imagine S.A. (2004). AMESet Version 4.2 Documentation.
Knoernschild,
K.
(2011).
http://www.kirkk.com/modularity/about/
Modular
Architecture.
Saatavilla:
Norton, R.L. (2006). Machine design: an integrated approach. Pearson/Prentice Hall.
Nykänen, O., Salonen, J., Markkula, M., Ranta, P., Rokala, M., Helminen, M., Alarotu, V., Nurmi,
J., Palonen, T., Koskinen, K., & Pohjolainen, S. (Accepted). What Do Information Reuse and Automated Processing Require in Engineering Design? 2011. Journal of Industrial Engi-neering and
Management.
Nykänen, O. (2010a). Semogen Semantic Process: Data Processing Aspect. Semogen project technical document. (Ks. liite A)
Nykänen, O. (2010b). Semogen Semantic Process: Asserting and Validating Information Requirements. Semogen project technical document. (Ks. liite B)
Ozpineci, B., Tolbert, L. (2003). Simulink Implementation of Induction Machine Model - A Modular
Approach. Proceedings of Electric Machines and Drives Conference, 2003 (IEMDC'03), pp. 728736.
PLC Open, Saatavilla http://www.plcopen.org/,
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. Lecture Notes in Computer Science, vol. 7032. Top
appear.
60
Simantics. (2010). Simatics Platform - Details about Simatics platform, the software architecture,
and its applications. WWW-sivu. Saatavilla: https://www.simantics.org/simantics/aboutsimantics/simantics-platform
Sinha, R., Liang, V.C., Paredis, C.J.J., Khosla, P. (2001). Modeling and Simulation Methods for
Design of Engineering Systems. Journal of Computing and Information Science in Engineering,
Vol. 1, Issue 1, March 2001.
Sorensen, K. K., Stoustrup, J. (2008). Modular modelling and simulation approach - applied to
refrigeration systems. IEEE International Conference on Control Applications, 2008. pp. 983-988.
VTT. (2011). TIKOSU - Tietokantakeskeinen koneenohjausjärjestelmän suunnittelu ja toteutus.
WWW-sivusto. Saatavilla: http://www.hermia.fi/fima/tutkimusprojektit/tikosu/
Vyatkin, V., Hanisch, H.-M., Pfeiffer, T. (2003). Object-oriented modular place/transition formalism for systematic modelingand validation of industrial automation systems. Proceedings of IEEE
International Conference on Industrial Informatics, 2003, pp. 224-232.
W3C. (2006). Ontology Driven Architectures and Potential Uses of the Semantic Web in Systems
and
Software
Engineering.
Editor's
Draft,
2006/02/11.
Saatavilla:
http://www.w3.org/2001/sw/BestPractices/SE/ODA/
W3C. (2009a). Semantic Web Applications in Neuromedicine (SWAN) Ontology. W3C Interest
Group Note 20 October 2009. Saatavilla: http://www.w3.org/TR/hcls-swan/
W3C. (2009b). Product Modelling using Semantic Web Technologies. W3C Incubator Group Report 08 October 2009. Saatavilla: http://www.w3.org/2005/Incubator/w3pm/XGR-w3pm20091008/
W3C. (2011). Describing Linked Datasets with the VoID Vocabulary. W3C Interest Group Note 03
March 2011. Saatavilla: http://www.w3.org/2001/sw/interest/void/
Zupancic, B. (1998). Modular hierarchical modelling with SIMCOS language. Math. comput.
simul., Vol. 46, pp. 67-76, 1998.
Komponenttikuvien alkuperäislähteet CAN-visualisoinnissa
Kuva 3.5.1 s. 29 ja kuva 4.2.1.2. s. 41.
BTL - Balluff Transsonares Längenmesssystem (Micropulse). Balluf. Saatavilla.
http://www.balluff.com/Balluff/de/ResourcesChannel/Technical+Reference/?menuLevel=2
CANopen I/O Node. Pirkan Elektroniikka Oy. Saatavilla:
http://www.tke.fi/downloads/2009_jan/PE552%20CANopen_IO%20V0005.0000.pdf
Electronic Pilot Module, EPM2. BoschRexroth. Saatavilla:
http://www.boschrexroth.com/borexmvz2/Category.jsp?ccat_id=30050&publication=NET&pagera
ction=switchpage&remindCcat=on&language=en-GB&page=20
61
Digsy Compact. Inter Control. Saatavilla.
http://www.intercontrol.de/automation/en/02_products/product.php?id=4&lang=en&company=4
Digsy CMV. Inter Control. Saatavilla.
http://www.intercontrol.de/automation/en/02_products/product.php?id=32&lang=en&company=4
Ohjauskäsinojat. Sandvik Mining and Construction Oy ja Pirkan elektroniikka.
RCC, Resolver as Absolute-Encoder in CANopen-Profile. LTN Servotechnik GmbH. Saatavilla:
http://www.ltn.de/global/pdf/TechnicalDataSheet-CANOpen-RCC%20Rev1.pdf
Julkaisut:
Nykänen, O., Salonen, J., Markkula, M., Ranta, P., Rokala, M., Helminen, M., Alarotu, V., Nurmi,
J., Palonen, T., Koskinen, K., & Pohjolainen, S. (2011). What Do Information Reuse and Automated
Processing Require in Engineering Design? 2011. Journal of Industrial Engineering and Management. Accepted.
Markkula, M., Rokala, M., Palonen,T., Alarotu V., Helminen, M., Koskinen, K. T., Ranta, P.,
Nykänen, O., Salonen, J. (2011). Utilization of the Hydraulic Engineering Design Information for
Semi-Automatic Simulation Model Generation. Proceedings of the Twelfth Scandinavian International Conference on Fluid Power, vol. 3, pp. 443-457. May 18-20, 2011, Tampere, Finland.
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. ISWC 2011: The 10th International Semantic Web
Conference. Accepted
Matti Helminen, Tuija Palonen, Markus Rokala, Pekka Ranta, Teemu Mäkelä, Kari T. Koskinen
(2011) Virtual Machine Laboratory based on M1-technology. Proceedings of the Twelfth Scandinavian International Conference on Fluid Power, vol. 1, pp. 321-334. May 18-20, 2011, Tampere,
Finland.
NodeList.GraphML -ehdotus Toimitettu elokuussa 2011 CAN in Automation TF-311standardointiryhmän arvioitavaksi. Saha, H., Nykänen, O. Salonen, J. Helminen, M.
New method for describing can network topology. Matti Helminen, Heikki Saha, Ossi Nykänen,
Jaakko Salonen, Kari Koskinen, Pekka Ranta & Seppo Pohjolainen. 13th international CAN Conference. Abstract submitted in 23rd of September.
62
Liitteet:
Nykänen, O. (2010a). Semogen Semantic Process: Data Processing Aspect. Semogen project
technical document. [Ks. liite A]
Nykänen, O. (2010b). Semogen Semantic Process: Asserting and Validating Information
Requirements. Semogen project technical document. [Ks. liite B]
1
Semogen Project Document: For internal project use only
Semogen Semantic Process: Asserting
and Validating Information
Requirements
ANALYSIS & SPECIFICATION FOR SEMOGEN WORK PACKAGE 2
Version 2010-10-01
Ossi Nykänen (ossi.nykanen@tut.fi)
Tampere University of Technology, Hypermedia Laboratory
Abstract. This document establishes methods for creating and transforming information in the semantic
process, and asserting and validating the related information requirements. We also consider the concrete
implementation technologies and enclose observations about the related modelling decisions.
Table of Contents
1. Introduction ................................................................................................................................................... 2
2. Fundamental Concepts and Methods ........................................................................................................... 2
2.1. Mappings between Domain (Information) Objects ............................................................................... 3
2.2. Methods for Object Creation and Information Transformations ........................................................... 5
3. Evaluation and Development Tool using Success Indicators......................................................................... 7
4. Information Requirements in Practice: Two Case Studies ............................................................................ 8
4.1. A Canonical Approach........................................................................................................................... 10
4.2. A Microformat Approach ("A Sidestep") .............................................................................................. 12
5. Definition of a Simple Success Indicator for Meeting Information Requirements ..................................... 14
6. Design Notes ................................................................................................................................................ 16
7. Conclusion ................................................................................................................................................... 18
References ....................................................................................................................................................... 18
1 (18)
Semogen Project Document: For internal project use only
1. Introduction
This document establishes methods for creating and transforming information in the semantic process, and
asserting and validating the related information requirements, as defined in [1].
In brief, we aim supporting designing and validating semantic processes from engineering point of view.
Methods proposed in this document may be used, for instance, for analysing a situation where an
established semantic process breaks, after adding more data or making modifications.
The main objective of this work is to explicate the notion and the techniques related to critical information
paths up to a level where useful implementations can be discussed. (Please note this document includes
currently unpublished work etc. analysis by the author.)
While moving towards specific data manipulation processes and information architectures, we meet the
opportunity to align our design and process concepts with well-known approaches of the field. For
purposes of our discussion, two generic approaches for working with data processing systems might be
indentified here1: The first is the OASIS Darwin Information Typing Architecture (DITA) [2] which aims
advancing a document creation and management via building content reuse into the authoring process.
The second is OASIS Web Services Business Process Execution Language (WSBPEL) [3] for enabling users to
describe business process activities as Web services and define how they can be connected to accomplish
specific tasks. Note that in principle (using suitable extensions etc.), the second approach might be
considered to provide generic service-oriented means to model any data processing applications. (The cost,
of course, is certain complexity of the approach.)
However, while we share some of the ideological foundation and certain technologies of these approaches,
we do not aim integrating directly to these concepts and/or technologies. In brief, we wish to analyse the
situation in a more abstract level, and hope to achieve more with respect to particular research topics. In
particular, we seek to establish means to analyse the data modelling, information requirements, and data
processing activities on the information (and later on the knowledge) level, providing new kinds of
methodological concepts and tools for the knowledge engineer.
2. Fundamental Concepts and Methods
Recall the abstract concepts of the semantic process and the critical information path [1]. In brief, data
processing activities are organised into a pipeline where data flows from one activity to another, according
to the structure of the pipeline (which itself is a set trees with overlapping root and possibly some other
nodes). This establishes the relative roles of providers and requestors to the activities which in turn sets the
requirement of critical information paths.
Figure 1 below (from [1]) illustrates the concept of a critical information path in a simple example where
the activity A5 provides requested information to the activities A6 and A7.
1
Note, however, that this document is an internal draft for the SemoGen project. A more complete presentation of
the context is to be presented in scientific publications.
2 (18)
Semogen Project Document: For internal project use only
Figure 1. Example of an operational interpretation of provider-requestor relationship (see [1])
We shall next analyse the concept of critical information paths in detail and suggest a method of modelling
them in a way that can be implemented in practice.
2.1. Mappings between Domain (Information) Objects
In order to simplify the discussion and make it more concrete, consider a linear semantic process of three
activities (see Figure 2):
Figure 2. Example of three sequential activities
Our task is now to establish a method of asserting and validating information requirements in the semantic
process.
Assuming we are interested in the information content of the data flow, and not just the text format of the
data interchange, we need to know about the domain (information) objects related to each activity. While
typically neglected in abstract schema design, this observation is critical when information content is
considered: The mere existence of information exchange protocol does not as such necessarily guarantee
that the actual information content is sufficient. Hence, we need to introduce a bookkeeping method for
the actual information content of the activities.
Considering Figure 2, we may conceptualise the situation as follows: Assume that the activity A3
acknowledges its domain objects D3, the activity A5 its domain objects D5, and the activity A7 its domain
objects D7. Note that technically, a set of domain objects is simply a set of identifiers (e.g. codified names
of individual entities that sufficient in identifying the individual entities within the domain for purposes of
some application).
The (semantic) properties of the domain objects of A3 (D3) are described using a suitable vocabulary, P3.
Likewise, the properties of the domain objects D5 are described using a vocabulary P5, and domain objects
of D7 using a vocabulary P7. Note that technically, definition of semantic properties includes two separate
things: a vocabulary of predicate names with a specific domain and range over a specific value space
(which might be modelled using a semantic schema), and a system of actual assertions about individuals of
the domain (e.g. a set of statements describing particular individuals).
3 (18)
Semogen Project Document: For internal project use only
Now, assuming the activities A3, A5 and A7 establish a data processing pipeline, some of the objects and
properties of A5 are due A3, and some objects and properties of A7 due A5 (see Figure 2). Thus, if the data
processing pipeline is working, (some) information from A3 is mapped (e.g. transformed) to A5 and (some)
information from A5 is mapped to A7.
We may now model this as follows (see also Figure 3 below):
{ (x, p(x)) | x  D3, p  P3} f35 { (y, q(y)) | y  D5, q  P5} f57 { (z, r(x)) | z  D7, r  P7}.
(1)
In other words, there are information mappings (transformations) that map both the objects and their
properties from one domain to another (here f35 and f57). Note that this mapping needs not to be
surjective, i.e. there might be objects in D5 that are not due a mapping from D3.
Note that the situation can be obviously simplified, by assuming that each activity uses a common
vocabulary (i.e. P3 = P5 = P7), or that there exists a global object index (i.e. D3 = D5 = D7). However, for
generality, we shall not make such of an assumption here. Note also that in practice, one of the following
must hold: The information transformations "understand" the semantics of the providing and the requesting
activities, or the providing and the requesting activities share semantic schemas.
Now, the example formulation (1) suggests a method for actually designing (information) transformations
between activities:
1. For each connected activity, identify the domain (information) objects for each domain (using
activity-specific domain definitions when necessary).
2. Identify the semantic properties of the objects within each domain (using domain-specific
vocabularies when necessary).
3. Define information transformations of objects and properties between domains.
We wish to emphasise that the step 1 is critically important when validating critical information paths. To
see this, assume that the domain D5 is supposed to include an (information) object yD5, whose properties
can be (partially) read and transformed from (D3, P5). In general, however, there is no guarantee that the
domain D3 actually identifies an object that can be mapped 1:1 to y without effectively creating a new
object. For instance, y might be only implicitly present in the relationships between the objects of D3 and
not explicitly identified. Thus, in order that the critical information path can be validated, it is the
responsibility of the activity A5 to assert the existence of such object y and the acceptable schema of
which the property declarations must follow.
4 (18)
Semogen Project Document: For internal project use only
Figure 3. A conceptual example of mapping individual data objects in a semantic data processing system
Figure 3 above provides a graphical presentation of the domain information objects (D) and information
mappings between them (f). In brief, the figure illustrates the idea of mapping objects from one domain to
another (e.g. from D1 to D3), and declaring new objects in a domain without mappings (all objects in D 1,
some objects in D5).
Finally, it is quite obvious that the domain information objects do not need to identified explicitly;
information transformations can simply map information from one data structure to another. However,
unless the existence of certain domain objects is known/asserted a priori, it is very difficult to see how the
information requirements of activities could be validated. For instance, unless A5 asserts explicitly "from
above" that D5 should include information about more than one objects categorised as "hydraulic
components" (etc.), it is unlikely that related information requirements could be mechanically validated.
2.2. Methods for Object Creation and Information Transformations
Because managing domain object indices and properties of complex applications can be quite expensive,
we consider few practical methods for both the domain object creation and the property transformations.
For simplicity, we present the methods using the example setting described earlier and assume
transforming data from A3 to A5 as depicted in the example in Figure 2 (the generalisations, however, are
straightforward).
The basic method of mapping information from one domain to another is using the method of information
transformations between objects with a priori identity (recall Figure 3 above):
Method 1 (Validated information transformations between objects with a priori identity):
1. Identify objects: Define D5 by enumerating its objects. Assume D3.
2. Assert required information schema: For each object in D5, assert which kind of properties they
should have. Note that this assertion may include not only the data format aspect, but also the
information content aspect (e.g. cardinalities and non-empty values).
5 (18)
Semogen Project Document: For internal project use only
3. Transform the provided information: Define transformation that associates objects in D5 with
properties derived from D3. (If there are several activities that information is requested from,
define at least one transformation for each.)
4. Enclose local information: Produce and enclose local information about the objects in D5. By "local
information" we mean here information that is created within the activity and is not to be
read/transformed from another activity, within the abstraction level of the data processing
pipeline. (In some cases local information may also complement the missing data that would be
ideally required from the previous activities in the pipeline.)
5. Validate required information: Validate the transformed information (organised according to the
providing activities and locally enclosed data) with respect to the required information schema. If
the data does not conform, report shortcomings and terminate. (If particular data are missing,
enclose heuristic suggestions about which activities should provide that data and go back to step 1,
or, go back to step 4 and enclose the missing data locally.)
6. Process activity data: Once all required information is available, perform the activity-specific (here
D5) data processing and provide the results to following activities (e.g. A7) when needed. 
Note that in step 5, validating the required information, we are not making the (quite strong) assumption
that it is always a priori known which of the preceding activities should provide the required information.
Reasons are highly practical: The requesting activity might in general not know this and it is easy to imagine
a scenario where it actually makes sense to shift the role of an activity owning a particular information
source from one activity to another.
Thus, the step 5 involves the analysis of such information ownership and obligation questions in a
recursive fashion. For instance, A5 might not wish to locally enclose certain information and requires A3 to
provide it. However, A3 might not wish to enclose it either, and delegates the task of providing the
required information to some previous activities (and then simply passes the provided information to A5
e.g. using identity mappings). Note that e.g. the ownership questions are not only technical, but also
related to e.g. policies.
In practice, assuming identity for objects within each domain a priori can be cumbersome. Thus, practical
methods are needed for (partly) automating the step 1 of the above Method 1.
Perhaps the simplest approach is to complement (manually etc.) enumerated lists of domain objects, is to
use domain (information) object creation rules:
If X  D3 and pj(xX) for some pj  P3, then create a new object y  D5 where y = f(X,{pj}).
(2)
In other words, some of the objects in D5 are created based on the (sets of) objects in D3. (Note that while
we could simply assume creation rules as mapping from individuals of D3, this might not allow e.g.
introducing new objects y  D5 based on relationships in D3.)
Note that in principle, the object creation rules and property transformations might be integrated. In
practice, however, it might make sense to perform these in two explicit steps, i.e. braking (1) into two
distinct phases (first introducing objects and then enclosing and transforming their properties). The reason
is that a single set of property transformations might be applied both to the objects enumerated and
created using rules. Having clear expectations about the existence of domain objects also helps
implementing information requirements schemas.
6 (18)
Semogen Project Document: For internal project use only
3. Evaluation and Development Tool using Success Indicators
It is relatively easy to imagine a semantic data process "given from above" that does the specified job.
However, in practice, we are dealing with a potentially very complex engineering problem: The more
complex the process, the bigger the challenge.
Since it is again easier to discuss these tasks in the context of a simple example, recall the example pipeline
from [1], depicted as Figure 4 below:
Figure 4. A simplified example of semantic data processing system (see [1])
Assume we are given a development draft of a semantic data processing pipeline. How to evaluate the
success of meeting the critical information path requirements? (To put this discussion in a context of a
simple example, consider, e.g., the tree of activities A1-A8 in Figure 4 above).
Ideally, we would like to have an evaluation and development tool that is capable of performing e.g. the
following tasks (starting from the simple ones):
1. Unsatisfied Requestors: Point out the requestor activities that are requesting information that is
not currently provided.
2. Underperforming Providers: Point out the provider activities that are not providing the information
they are obliged to provide.
3. Unused deliverables: Point out the provider activities that are providing information that nobody is
requesting.
4. Requirements distribution: Visualise the distribution of requirements and obligations in the
pipeline.
5. Simple success indicator: Provide a simple success indicator of meeting the critical information
path requirements of the whole system (e.g. "75% successful where the shortest successful path is
2 activities out of 4, and the first activity missing critical information is 'Data Enrichment for AfterSales Services'.").
The first task is straightforward: Associate required information schemas with requesting activities and
check which schemas do not validate.
7 (18)
Semogen Project Document: For internal project use only
The second task is a bit more difficult since it (in addition) requires identifying the activities which are
responsible for providing the currently missing information.
The third task again builds on top of the previous ones. It involves taking a "diff" of the provided and
requested information. Observing deliverables that are not used anywhere implies either that unnecessary
processing takes place, or it may point out that some information transformations are still missing (e.g. in
order to satisfy non-fulfilled information needs).
The fourth task points out a big picture of the situation. This should help determining if the efforts and
requirements are reasonably and rationally distributed in the process. For instance, it might happen that
certain monolithic activities are assumed to provide most of the information. In turn, this might suggest
identifying more (sub)structures in the process.
Finally, the fifth task aims providing a single, simple indicator that helps quickly getting rough feel what is
the success of the data processing, and which activity should be "fixed".
It turns out that implementing this kind of evaluation and development tool is not trivial. While it is easy to
point out which activity in the pipeline is the first to miss required information, it is difficult to say much
beyond this. Several challenges exist:



The first challenge is that all information is not available before successfully processing the whole
pipeline. To see this, assume e.g. that the information requirements of A5 are not satisfied in some
development draft of a pipeline (see Figure 4); it is now difficult to say if activities A6 and A7 would
provide all required information to A8.
The second challenge is that unless requestor activity explicitly asks input from specific provider
activities, it may be difficult to target requirements to specific activities. To see this, assume that A5
is missing required information; unless A5 gives specific requests to A2 and A3, both might be
identified as underperforming providers.
The third challenge is that analysing instance data and schemas is technically quite difficult in
practice. For instance, given certain transmitted instance data and a schema document, it may be
difficult to compute the maximal number of validation errors that evaluating a schema may
potentially yield.
In order to make this discussion more concrete, we shall next consider two case studies of an
implementation of information requirements in principle. (We will come back to the topic of a success
indicator after introducing a concrete technical context for the above discussion.)
4. Information Requirements in Practice: Two Case Studies
Consider the following implementation of the example process depicted in Figure 5 below:
8 (18)
Semogen Project Document: For internal project use only
Figure 5. Example of three related activities
In terms of (simplified) data processing, we may model this with the following semantic process project
(file) structure of XML data and tools (see [1]):
...
activities/
A2/
...
out/
objects.xml
data.xml
A3/
...
out/
objects.xml
data.xml
A5/
in/
objects.xml
data.xml
reqs/
critical.sch
out/
objects.xml?
data.xml?
In brief, the files A2/out/objects.xml and A3/out/objects.xml enumerate the domain objects of A2 and A3.
The files A2/out/data.xml and A3/out/data.xml represent the objects in terms of semantic properties. Note
that A2 and A3 output data unaware of each other.
The file A5/reqs/critical.sch is the schema that asserts the critical information requirements of A5. This
means that if the data provided to A5 (here A5/in/*, compiled from A2/out/* and A3/out/*) do not
conform to this schema, processing A5 as a data processing pipeline step is not possible.
Finally, the files A5/out/*? are the (anticipated) results of processing A5 as an Ant target. In other words,
these establish the output that results from "executing" A5 as a step in the data processing pipeline. Note
that computing A5/out/ includes two steps: First, declaring & creating the domain objects of A5, and then
declaring & creating the related data.
Now, it is instructional to consider what the files might look like in a simplified setting. To simplify the
discussion, we first assume that a standard format (a restricted form of RDF/XML, a specific XML syntax for
the Resource Description Framework) for encoding activity outputs is used. Strictly speaking, this would not
be necessary, and using a variety of (XML) data formats could be used.
9 (18)
Semogen Project Document: For internal project use only
4.1. A Canonical Approach
We shall next describe an approach of using a (proprietary) canonical form variant of RDF/XML, that we
call RDF/cXML, for encoding data. This allows dual interpretation of the data format: As structural XML
(semantic tree model) or as semantic RDF (semantic network model). The basic idea is that unlike in
RDF/XML, all structural patterns and abbreviations in encoding statements are not accepted. This allows
reading data in a well-defined manner effectively as XML, so that technologies such as XSLT and ISO
Schematron can be used. However, when necessary, the data can also be interpreted in RDF which allows
using, e.g., genuine semantic query and reasoning technologies.
For instance, the object list A2/out/objects.xml might look like this:
<!DOCTYPE rdf:RDF [<!ENTITY ex "http://www.tut.fi/hlab/semogen/example/">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.tut.fi/hlab/semogen/example/"
xmlns:sg="http://www.tut.fi/hlab/semogen#">
<sg:domain rdf:about="&ex;domain-A2">
<sg:has-object rdf:resource="&ex;A2#a1" />
<sg:has-object rdf:resource="&ex;A2#a2" />
</sg:domain>
</rdf:RDF>
In other words, the object list simply declares that two objects exist. Should we wish not to give an identity
to the domain itself, we could replace the attribute rdf:about with rdf:nodeID, providing a placeholder for a
temporary name (blank) for the domain. The adopted restricted RDF/cXML interpretation now suggests
that e.g. writing the semantically equivalent information using some other RDF/XML serialisation pattern is
not allowed. This allows safely reading A2/out/objects.xml in terms of DOM, XPath etc. parsing.
Note that we have separated the names of the example (prefix ex) from the names of the common
Semogen semantic vocabulary (prefix sg) in different namespaces. The basic idea is to introduce new
domain names for each application, using the common Semogen vocabulary as a semantic glue (here we
used a class sg:domain and a predicate sg:has-object).
Going forward with the example, the data file A2/out/data.xml might look like this:
<!DOCTYPE rdf:RDF [<!ENTITY ex "http://www.tut.fi/hlab/semogen/example/">
<!ENTITY sg "http://www.tut.fi/hlab/semogen#"> ]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dct="http://www.example.org/terms/"
xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:sg="http://www.tut.fi/hlab/semogen#"
xml:lang="en">
<rdf:Description rdf:about="&ex;A2#david-designer">
<rdf:type rdf:resource="http://www.w3.org/2000/10/swap/pim/contact#Person" />
<contact:fullName>David H. Designer</contact:fullName>
<contact:mailbox rdf:resource="mailto:dd@david-works-here.org" />
</rdf:Description>
<rdf:Description rdf:about="&ex;A2#a1">
<rdf:type rdf:resource="&sg;Motor" />
10 (18)
Semogen Project Document: For internal project use only
<rdfs:label xml:lang="fi">Moottori</rdfs:label>
<rdfs:label xml:lang="en">Motor</rdfs:label>
<sg:XPos>120.17</sg:XPos>
<sg:YPos>1.2</sg:YPos>
<dct:author rdf:resource="&ex;A2#david-designer" />
</rdf:Description>
<rdf:Description rdf:about="&ex;A2#a2">
<rdf:type rdf:resource="&sg;Crane" />
<rdfs:label xml:lang="fi">Puomi</rdfs:label>
<rdfs:label xml:lang="en">Crane</rdfs:label>
<sg:XPos>0.0</sg:XPos>
<sg:YPos>0.2</sg:YPos>
<sg:operated-by rdf:resource="&sg;a1" />
<dct:author rdf:resource="&ex;A2#david-designer" />
</rdf:Description>
</rdf:RDF>
Again, we assume the (canonical) RDF/cXML interpretation, which here means that there is exactly one
rdf:Description element per a described resource.
The example data include descriptions of the two domain objects identified before, and one additional
resource (the author). The reason why sg:david-designer was not identified as a domain object is a
modelling decision – perhaps this information is considered merely auxiliary, etc. and is not really critical in
completing A5. Another reason might be that a future version of the semantic processing pipeline might
use this information. (Thus, strictly speaking, the object &ex;A2#david-designer might be unused but
provided.)
Similar data are provided by A3.
Now, assuming the RDF/cXML format, the data in A5/in/* can be almost trivially transformed and
integrated from A2/out/* and A3/out/*. (Or not transformed at all and read directly from sources. This
would be less expensive but complicate the process of writing the information requirement schema.)
Now, we wish to assert that completing the A5 as an Ant target requires that descriptions of domain
objects are really provided, equipped with labels in Finnish and 2D coordinates. Assuming the RDF/cXML
format, we may assert the information requirements in ISO Schematron (a trivial example):
<schema xmlns="http://purl.oclc.org/dsdl/schematron"
queryBinding='xslt2' schemaVersion='ISO19757-3'>
<ns prefix="rdf" uri="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<ns prefix="sg" uri="http://www.tut.fi/hlab/semogen#" />
<title>A5 Information Requirements</title>
<pattern>
<rule context="/rdf:RDF">
<assert
test=".[rdf:Description]">Information objects are missing.</assert>
</rule>
<rule context="//rdf:Description">
<assert
test="rdfs:label[lang('en')]">English label is missing. </assert>
<assert
11 (18)
Semogen Project Document: For internal project use only
test="sg:XPos">Coordinate information is missing (Xpos). </assert>
<assert
test="sg:YPos">Coordinate information is missing (Ypos). </assert>
</rule>
</pattern>
</schema>
Note that this does not actually process the outcome of A5; it merely asserts the required information.
Note also that considering processing A5, integration of data provided by A2 and A3 might require, e.g.,
recognising that data originates from different domains. For instance, A2 and A3 might report coordinates
using different coordinate systems or scales. A more expressing information requirement schema might
also assert requirements for the coordinate systems, etc.
It is important to observe that the dual RDF/cXML interpretation also allows making semantic assertions
assuming the RDF interpretation. For instance, we might require that the data does not imply semantic
inconsistencies (e.g. empty classes in OWL, Web Ontology Language).
As a technical note, it might be observed that using a cleaning technology such as GRDDL (Gleaning
Resource Descriptions from Dialects of Languages) might effectively lead into the case described above.
However, this would be related to the delivered output of an activity, rather than accepted input of an
activity. (Hence, this would now be related to the implementation of A2 and A3.)
4.2. A Microformat Approach ("A Sidestep")
Another strategy for encoding the information provided by an activity, is to avoid extracting the
information already encoded in some legacy documents, and simply refer to these structures. We call this
the microformat approach.
In this case, information objects are not extracted into an explicit list of object but simply pointed out in
some existing data structure. In other words, instead of insisting using RDF/cXML also for object
descriptions, one could use some proprietary (XML) structure and point out the parsing of the objects.
Here is an example of this kind of an object list, A2/out/objects.xml:
<!DOCTYPE rdf:RDF [<!ENTITY ex "http://www.tut.fi/hlab/semogen/example/">
<!ENTITY sg "http://www.tut.fi/hlab/semogen#"> ]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.tut.fi/hlab/semogen/example/"
xmlns:sg="http://www.tut.fi/hlab/semogen#">
<sg:domain rdf:about="&ex;domain-A2">
<!-- object list -->
<sg:has-object rdf:resource="&ex;A2#a1" />
<sg:has-object rdf:resource="&ex;A2#a2" />
<!— namespace declarations -->
<sg:ns>
<sg:prefix rdf:resource="http://www.w3.org/2004/07/xpath-functions">fg</sg:prefix>
<sg:prefix rdf:resource="http://www.w3.org/2000/svg">svg</sg:prefix>
<sg:prefix rdf:resource="http://www.tut.fi/hlab/semogen#">sg</sg:prefix>
</sg:ns>
</sg:domain>
12 (18)
Semogen Project Document: For internal project use only
<!-- property mappings -->
<rdf:Description rdf:about="&ex;A2#a1">
<sg:selector>fn:doc('export.svg')//svg:rect[1]</sg:selector>
<sg:property>
<sg:propertyName>sg:XPos</sg:propertyName>
<sg:propertyValue>@x</sg:propertyValue>
</sg:property>
</rdf:Description>
<rdf:Description rdf:about="&ex;A2#a2">
<sg:selector>fn:doc('export.svg')//svg:rect[2]</sg:selector>
<sg:property>
<sg:propertyName>sg:YPos</sg:propertyName>
<sg:propertyValue>@y</sg:propertyValue>
</sg:property>
</rdf:Description>
</rdf:RDF>
The basic idea is that for each object, a selector provides a node from which the object properties can be
read, all using XPath 2.0 expressions. Rest of the definitions simply encode the information that is required
for achieving this.
Now, a trivial sample source data document A2/out/export.svg might look something like this:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="12cm" height="4cm" viewBox="0 0 1200 400"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<desc>Trivial legacy data example</desc>
<rect x="1" y="1" width="1198" height="398"
fill="none" stroke="blue" stroke-width="2"/>
<rect x="400" y="100" width="400" height="200"
fill="yellow" stroke="navy" stroke-width="10"
</svg>
/>
In other words, the domain (information) objects a1 and a2 are simply read from the rect elements. Of
course, a realistic example would be much more complex and might include application-specific
vocabularies.
In the case of the microformat approach, asserting the information requirements schema either requires a
mapping based on the property mappings, or an intermediate transformation step of source data into the
RDF/cXML format. (In which case, the previous case study and the previous schema may be applied as
such.)
Note that in practice, the microformat approach strategy can be technically also adopted in terms of the
implementation of the A2 activity. In other words, the processing that e.g. outputs the data A2 and e.g.
provides A2/out/data.xml in canonical RDF/cXML format, may in fact read data and transformed in the
above sense. This simply implies that the responsibility of interpreting the legacy data in which
microformats are used, is shifted from A5 to A2.
13 (18)
Semogen Project Document: For internal project use only
Since the microformat approach may be encapsulated by a design of activity roles, we shall adopt the first,
canonical approach. While this is potentially more expensive computationally, it yields simpler and clearer
modelling.
5. Definition of a Simple Success Indicator for Meeting Information
Requirements
Now, having outlined an approach for asserting information requirements, assume we would like to
establish a numeric success indicator.
Recall the example data processing pipeline from Figure 3. Intuitively, we may consider attaching
information requirements schema for every activity that acts as requestor in the process (in the example
A2-A8). In cases where requestor receives input from several providers (now A5 and A8) the requirements
cannot be uniquely addressed to a single provider.
Considering information requirement schemas in Schematron, a simple way to calculate required
information is to consider the number of fired rules (that include assertions), r, and the number of failed
rules f. We say that a rule fails if at least one of its assertion tests faila.
(According to the ISO Schematron standard, in the level of the markup, rules are marked using rule
elements and assertions using assert elements. Rules may, however, also include report elements that
means that every rule might not include an assert element. Note that this allows designing the granularity
of the failed rules – the strictest approach is to introduce a separate rule for every assert element. Note
also that while we present the basic definitions in the context of the concrete Schematron technology, the
definitions generalise into most schema systems. However, typical schema technologies do not by default
report their internal pattern matching/instantiating processes. This makes implementations more
challenging.)
We say that a schema rule fires when it matches the instance document. We say that a rule fails if it
includes a failing assertion. Now, let Rk denote the information requirements schema asserted by Ak. Let
INk denote the data that is provided to Ak, i.e. to be validated using Rk. Further, let r = r(INk, Rk) (with the
function signature r:N) denote the number of the fired rules (that include assertions) when validating
INk using Rk. Let f = f(INk, Rk) (with the function signature f:N) denote the number of the failed rules
when validating INk using Rk. Note that the functions thus depend both on the input data and on the
schemas.
If Rk actually sets some requirements that match INk, it follows that some rules fire and r(INk, Rk)>0. We
say that an information requirement schema is actual (with respect to INk) if it includes a rule that fires. If
none of the rules of Rk fire, r(INk, Rk)=0. Note that in general, asserting schemas that are not actual does
not seem useful and may indicate input and/or schema design error(s).
We say that the provided data INk fully conforms to (or fully succeeds) Rk if none of the rules fail, i.e. f(INk,
Rk)=0. If some assertions fail, we get f(INk, Rk)>0 and say that also INk fails. For purposes of computing also
the "near misses", we say that INk partially fails (or partially conforms) if f(INk, Rk)>0. Note that can INk fail
only when at least one rule has fired, i.e. f(INk, Rk)>0 only when r(INk, Rk)>0.
We may now define information requirements failure ratio F = F(INk, Rk) as follows:
14 (18)
Semogen Project Document: For internal project use only
(3)
In other words, INk fully conforms to Rk only if F(INk, Rk)=0, otherwise it partially fails with an information
requirements failure ratio f(INk, Rk)/r(INk, Rk).
It is easy to see that according to our definition of f and r, rf (because a failing rule is always due a firing
rule). Thus, it always holds that F1. So it always also holds that F[0,1]. When F=1, we say that INk fully
fails. (This may happen, e.g., with a schema that include only a single rule that fails.)
The information failure ratio captures the level of partial failing reasonably well. However, from the enduser perspective, the negative wording and the use of fractions might seem unnecessary complex. Thus, we
define the information requirements success indicator as percentage value (where C stands for
Conformance):
C = C(INk, Rk) = ( 1 - F(INk, Rk) ) * 100 %.
(4)
Intuitively, this definition is relatively clear: C(INk, Rk) is 100% when INk fully conforms to Rk and 0% when
it fully fails; otherwise it is something in between.
Let Ck denote the information requirements success indicator associated with activity Ak. Assuming
information requirements are actual, computing Ck typically that the parents of Ak fully conform,
computing several information requirements with failure levels (0) at a same time, is possible only for
activities in different branches of the semantic process. Thus the following case is possible:
A1 (C1=100%) --+--> A2 (C2<100%) --+
+--> A6 (C6=?) --+--> A8 (C8=?)
|
|
|
|
+--> A3 (C3<100%) --+--> A5 (C5=?) --+--> A7 (C7=?) --+
On the other hand, the following case is impossible:
A1 (C1=100%) --+--> A2 (C2=100%) --+
+--> A6 (C6=?) --+--> A8 (C8=?)
|
|
|
|
+--> A3 (C3<100%) --+--> A5 (C5>0%) --+--> A7 (C7=?) --+
The reason is simple: Ck can be computed only if Cj=100% for all of the providing activities Aj. In the above
case, there is no guarantee that C5 can be computed since it may lack information from A3.
Thus, given a development draft of a semantic data processing pipeline, what we can do is the following:
1. Start processing the pipeline from the outputs of the root activities that no other activity depends
on. (The root activities may also have information requirements, but for information that is simply
provided to them "from above", and which is not an output of any other activity.)
2. For an activity Ak to which the input can be computed, calculate the information requirements
success indicators Ck.
3. Continue the above step recursively, while considering the following conditions:
a. If all activities conform 100%, report that the all activities conform to the information
requirements, and quit: If the semantic process fails, it is not because of missing some
asserted information requirements.
b. If for some activity Aj we get Cj<100%, stop computing that branch (and all branches that
share that activity as a node) and report a partial conformance of (Aj, Cj).
15 (18)
Semogen Project Document: For internal project use only
c. When computing stops with some activities conforming <100%, report the non-conforming
activity that has the smallest depth, and total depth of the process structure (longest
branch in the set of trees), and quit.
Below is a conceptual example of this kind of output:
Start.
Evaluating the information requirements set by A1: Ok (100% conformance).
Computing output from A1: Done.
Evaluating the information requirements set by A2: Ok (100% conformance).
Computing output from A2: Done.
Evaluating the information requirements set by A3: Ok (100% conformance).
Computing output from A3: Done.
Evaluating the information requirements set by A5: Fail (75% conformance).
Computing output from A5: Unable to compute due missing input.
Evaluating the information requirements set by A6: Fail (no input).
Evaluating the information requirements set by A7: Fail (no input).
Evaluating the information requirements set by A8: Fail (no input).
Unable to complete the semantic process, quit.
Final report: From automatic data processing point of view, the semantic process breaks
in the activity A5 with 75% conformance, with a depth of 3/5 in the pipeline.
Stop.
The motivation of defining the information requirements success indicator originates from the fact that a
semantic process might include relatively few activities that transfer relatively large amounts of data. Thus,
the conformance indicator provides a simple measure to evaluate the success of fulfilling the information
needs of a particular activity, not just reporting failures in a "black and white" fashion.
Considering the discussion in Section 2 about explicitly identified domain objects, it should be observed
that the information requirements indicator can be complemented with other information. In particular,
assuming A5 requests data for specific domain objects, it might be possible to articulate which objects
and/or which properties in particular are missing, thus helping the job of a knowledge engineer to work for
a solution.
Note that adopting schema technology that does not (easily) allow defining a sensible measure for partial
conformance when evaluating activities, might effectively force using 1/0 conformance evaluation, simply
for technical reasons.
6. Design Notes
It should be obvious that successfully conforming to the information requirement schema does not
guarantee that the output of an activity can in fact be computed. The above definitions and success
indicator simply aim supporting the task of a knowledge engineering, providing a tool that with a proper
design should help analysing the situation when an established semantic process breaks, e.g., after adding
more data or making modifications. As a consequence, the above approach might be considered as a
method for monitoring data quality in the semantic process.
Another observation is that it seems unlikely that a complex semantic process is written from scratch.
Rather, a typical iterative design process might first focus into individual data processing steps, e.g.,
mapping data from A2 and A3 to A5. This suggests that the concrete design of a semantic data processing
16 (18)
Semogen Project Document: For internal project use only
pipeline should be modular. From technological perspective this might suggest that the data processing
from (A2, A3) to A5 should be first perceived as a self-sufficient task for easy testing and debugging. On the
other hand, e.g., using global indicators requires a "big picture" of the data processing pipeline. As a
consequence, both the bottom-up and the top-down design patterns should be acknowledged in the design
process. (As a technical note using Apache Ant, this suggests that the global buildfile is composed of several
smaller, to certain extent independent buildfiles that are called from the global one.)
Note that this discussion is also related to other schema design. In particular, the semantic information
modelling schemas (for instance, S1-S3 in Figure 4) that introduce and capture domain semantics can be
modelled from several design perspectives. Let us identify two such perspectives here:
1. Minimal pragmatic design, emphasising the local or short-term computing needs of the data
processing pipeline, typically from the perspective of local information transformations.
2. Verbose authentic design, emphasising the natural semantics of the domain, typically from the
perspective of related domain expert(s).
Note that these modelling perspectives represent the two ends of a modelling continuum (see Figure 6
below).
Figure 6. The modelling continuum of minimal pragmatic design and verbose authentic design
As such, neither of the perspectives is completely right or wrong. A design stance "close" to the minimal
pragmatic design introduces mainly semantic structures that are needed in actually programming
information transformations. On the other hand, a design stance "close" to the verbose authentic design
might typically introduce "additional" semantic (super)structures that explain data objects and put them in
proper semantic context within the domain. Thus, arguments for proper modelling should be sought from
the application context.
For instance, the objects of the domain D2 might be associated with semantic properties (e.g. classified
according to a general terminology adopted from a related standard, and equipped with particular
assertions about objects such as "is-a: moving part", "has-material: plastic") that are not strictly speaking
required in computing the outcome of the semantic data processing pipeline.
Indeed, from a very formal point of view, verbose authentic design may introduce optional parts in
schemas, i.e. structures that are not strictly speaking required in processing data. We claim, however, that
reasonable semantic verbosity should be favoured to ensure reasonably authentic modelling. The reason is
that the semantic process actually has three complementary use cases:
1. Semantic data processing pipeline use case
2. Semantic end-user applications use case
3. Semantic design process use case
17 (18)
Semogen Project Document: For internal project use only
The first is related to production and deployment; generating novel applications from semantically enriched
legacy data (e.g. virtual laboratories). The second is related to designing end-user applications that exploit
the semantic data in their function (e.g. semantic search view to highlight moving machine parts). The third
is related to the collaborative design and communication activities among designers (e.g. using common
terminology, rationalising activities, and enclosing design needs and information requirements).
This discussion points out that the information requirements can be set also from the perspective end-user
applications and design process. As a consequence, a component of a semantic model that is not strictly
speaking required for use case 1 and is thus "optional" might in fact be required for the uses cases 2 or 3.
7. Conclusion
In this document we have briefly identified and analysed the Semogen Semantic Process from the
information requirements perspective. This work provides a draft specification for implementing
information analysis and validation tools for the Semogen semantic process, and discusses the related
semantic modelling topics.
The work continues in analysing (verbose and authentic) semantic models and performing related data
processing case studies, in the context of the Ecplise/Ant implementation of the proposed Semogen
Semantic Process Environment.
References
1. Nykänen, O. 2010. Semogen Semantic Process: Data Processing Aspect (version 2010-09-16).
Internal Semogen project document for WP2, Tampere University of Technology, Hypermedia
Laboratory.
2. OASIS Darwin Information Typing Architecture (DITA) TC Home Page. OASIS. Available at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita (Referenced 2010-10-01)
3. OASIS Web Services Business Process Execution Language (WSBPEL) TC Home Page. OASIS.
Available
at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
(Referenced 2010-10-01)
18 (18)
Semogen Project Document: For internal project use only
Semogen Semantic Process: Data
Processing Aspect
ANALYSIS & SPECIFICATION FOR SEMOGEN WORK PACKAGE 2
Version 2010-08-20
Ossi Nykänen (ossi.nykanen@tut.fi)
Tampere University of Technology, Hypermedia Laboratory
Abstract. In this document we propose and analyse the Semogen Semantic Process from the mechanical
data processing perspective. In brief, we point out the overall process structure, illustrate the concept of
critical information paths, and outline the concrete components of a potential development environment.
Table of Contents
1. Introduction ................................................................................................................................................... 1
2. Basic Concepts ............................................................................................................................................... 2
3. Pipeline Data Processing and Critical Information Paths .............................................................................. 3
3.1. Abstract Information Needs ................................................................................................................... 4
3.2. Notes about Implementation ................................................................................................................. 4
3.3. A Case Study ........................................................................................................................................... 5
4. Recommendation for Systemic Implementation .......................................................................................... 7
4.1. Components of the Semogen Semantic Process Development Environment ....................................... 7
4.2. Suggestions of Specific Tools and Technologies ..................................................................................... 8
4.3. Relationship with Design and Application Systems.............................................................................. 10
5. Conclusion ................................................................................................................................................... 10
1. Introduction
This document specifies the data processing aspect of the Semogen Semantic Process. In brief, we analyse
and specify the various logical components of the Semogen Semantic Process with the objective of
mechanical processing of design information for well-defined applications, and suggest technologies and
tools for its implementation. The purpose of this document is to provide a specification basis for further
studies and experimental work. (In turn, this document provides a technical specification foundation for the
1 (10)
Semogen Project Document: For internal project use only
publication, abstract of which was presented to the Semogen advisory group in 10. June 2010. Please note
that as a consequence, this document includes currently unpublished work etc. analysis by the author.)
Note that as the title suggests, besides this mechanical data processing aspect, the Semogen Semantic
Process also includes the (Machine) Design Process Aspect that describes the machine design process and
provides informal instructions and tools for producing and managing technical information in a
combination of legacy and data processing formats. The Machine Design Process aspect is specified in
another document. Further, the exact semantic data formats and models of the Semogen Semantic
Process are to be specified, again in a separate document.
2. Basic Concepts
Let us begin by introducing the fundamental concepts of the Semogen Semantic Process by analysing a
simplified example. Throughout the example, we will assume the presence of a new technical designer role,
called knowledge engineer. The exact relationship of the knowledge engineer with the other designers and
engineers in specified elsewhere.
For the sake of the example, assume a design office or an engineering firm in the process of designing a
mobile drilling machine. The design system of the machine includes specific machine designers and other
designers and a variety of tools, and outputs (legacy) design data as a set of design documents in various
legacy formats (such as specific CAD file formats). Now, besides for manufacturing purposes, we would like
to exploit the design data in creating simulator applications and end-user documentation for purposes a
virtual machine laboratory application. Let us simplify the setting further by considering only the hydraulics
and the mechanical design of the system.
Figure 1. A simplified example of semantic data processing system
Figure 1 depicts an example of a simplified semantic data processing system related to our example
domain, relating the two main aspects of the semantic data processing system: semantic process and
semantic modelling. In brief, the example identifies seven activities (A1, A2, ..., A8), starting from
conceptual sketching of a particular artefact to be manufactured (e.g. a drilling machine), and ending to the
processes of simulation and documentation design of the virtual machine laboratory application, and of
course actual manufacturing (needs of which we ignore for now). The example also identifies three
2 (10)
Semogen Project Document: For internal project use only
schemas (S1, S2, and S3), referred from certain process activities. Note that due to the recursive nature of
processes, each activity might in itself be modelled as a process, with sub-activities.
The semantic process part (the darker round rectangles in the figure) appears as a feed-forward network
(or a tree) of activities, perhaps conducted by different actors. Two activities connected with an arrow
establish a directed relationship of information provider and information requestor. For instance, A5 is a
requestor for both A2 and A3, and provider for A6 and A7. Quite obviously, the modelling stance of the
process diagram dictates which information requirements are formally acknowledged – and validated. For
instance, while A1 seems not to appear a requestor of any information, its information needs are simply
not depicted in the process model.
Note that generally, one cannot assume that information received by an activity is always provided by it
since activities may in principle process data arbitrarily. For instance, unless A3 specifically includes a
subcomponent of an identity mapping, the information provided by A1 might not be as such available to
A5 (i.e. A5 only receives information A3 chooses to provide).
The semantic modelling part includes the hierarchical schemas which formally model the information that
is present in the process. In addition, schemas may be referenced by some activities of the semantic
process. This implies minimal information requirements, or necessary parts, for the schemas. For instance,
the process activities A1, A2, and A3 refer to the schema S1. In brief, this means that these activities are
based on a shared semantic schema and that schema provides a common ground for fulfilling the roles of
information requestor and provider between activities.
Designing process activities using shared schemas is very important since shared schemas establish agreed
data structures and semantics for transmitting data. The hierarchical structure of schemas allows importing
and including general-purpose schemas. For instance, S1 and S3 refer to S2. This might imply using shared
structures and names on the schema level (e.g. common names of specific classes and properties). Note
that the schemas may also include optional parts that are not strictly speaking required by the data
processing activities, but whose presence is appreciated, e.g. for informative purposes or for the sake of
completeness.
It is important to note that for simplicity, we have knowingly detached the semantic modelling from the
semantic process part, and hence artificially differentiating the "concrete" design activities from the "meta"
modelling activities. In practice, one might assume that the schemas are in fact iteratively designed in a
collaborative process with the actors drawn from the semantic process, perhaps with the help of a specific
knowledge engineer. Thus, a more complete process representation would in fact acknowledge the
creation of the schemas as well. (Indeed, this is a task of the Machine Design Process Aspect of the
Semogen Semantic Process.)
3. Pipeline Data Processing and Critical Information Paths
From the perspective of mechanic data processing, information in the critical information paths needs to be
formalised. Also, the role of the schemas becomes clear when we consider the meaning of the provider and
requestor relationship in detail.
3 (10)
Semogen Project Document: For internal project use only
3.1. Abstract Information Needs
Figure 2 presents an abstract information interpretation of a specific part of the previous example process
model, considering only the activities A5, A6, and A7. For the sake of the example, one may, e.g., imagine
that A6 aims producing a simulator for training how to identify a leakage problem in a hydraulics machine,
while A7 compiles maintenance documentation of the machine.
Figure 2. Example of an operational interpretation of provider-requestor relationship (logical information
perspective)
In brief, A5 provides information about two objects, device-1 and scenario-1, both equipped with several
properties (e.g. device-1 has the property of power having the value of 20). For efficiency, A5 provides only
information that A6 and A7 really need or use in the mechanical processing.
The figure highlights two interesting aspects of the semantic data processing system. First, for purposes of
data transmission, the information provider ad requestor roles are concrete, pointing out critical
information paths. For instance, unless A5 provides all the data requested by A7 (type, model, and power
of a Device entity, and setting of the scenario-1 object), the activity A7 cannot complete. Second, the
format and the semantics of the transmitted data are significant (e.g. the unit of power). In particular,
names of the properties used, common terminology, and data formats must be agreed before provider and
requestor can understand each other (and hence speaking about "semantics" is justified in the first place).
Hence, shared schemas are required. Further, it is worth observing that the requestor indeed needs to
know a great deal about the data; for instance, it either knows a generic way to request all objects or it a
priori knows which objects exists in the domain (e.g. device-1).
3.2. Notes about Implementation
Now the key question is how does A5 actually provide the needed information? Of course, from technical
point of view, there are several ways to implement the above logical structures – and encode the
information.
It turns out that this question is very difficult – in principle, it is easy to imagine a system of necessary
information items transmitted between activities but in practice, this requires carefully coordinated
activities where each activity has considerable knowledge about the common data structures involved. As a
consequence, system complexity is an issue.
4 (10)
Semogen Project Document: For internal project use only
Before actually trying to answer that question, few observations are in order. First, A5 does not certainly in
itself produce all information it provides (e.g. type and model of a particular device of interest) since it
presumably aims to exploit as much of the information requested as possible. In fact, much of the
information requested should be available in the original engineering (e.g. CAD) documents perhaps
produced in the earlier activities A2 and A3.
Second, when A5 actually does produce new information (e.g. the illustrative colour of a particular device
systematically used in simulations and documentation) it faces the problem of creating an information unit
or referring to an existing information unit it wishes to describe. Quite clearly, all activities face similar
problems and A5 might wish to simply use the information outputs the preceding steps have A1, A2, and A3
have introduced. This points out that a critical requirement for a semantic data processing system is that
the original data provide stable name identifiers that can be consistently referenced (or names from which
such identifiers can be mechanically generated).
In practice, it seems to make sense adapt or map the data required by the semantic processing from the
genuine (design and engineering) documents of legacy formats.
3.3. A Case Study
We shall next consider a push approach, where interesting data are retrieved from legacy design
documents in a "batch process". (Note that while a pull approach might be equally applicable and might be
favoured for, e.g., security reasons, it would in many cases require implementing completely new kinds of
tools.)
5 (10)
Semogen Project Document: For internal project use only
Figure 3. A design for implementing the information provider – requestor relationship using adapters and
standard data normalisation techniques
Figure 3 presents the idea of adapters, which effectively provide a way to normalise interesting data (e.g.
into a well-defined XML format with application-specific semantic vocabulary) from the original design
source documents, to be requested when needed.
In the example, the basic idea is that A5 has access to the semantic data M1 (already) adapted from the
original design documents. Activity A5 then complements M1 with an additional data component M2 (e.g.
including the colour information). Note that for practical purposes, it makes sense to organise the semantic
data managed by A5 into two modules, M1 and M2, simply because depending on the implementation, M1
might get "overwritten" when F1 is modified (when O1 is executed).
When the activity P6 needs the information, it requests it using a general-purpose query processor,
formulating an appropriate semantic query. (By a semantic query we mean here a query that can request
data not only based on data structures, but also based on data types.)
The relationship of information providers and requestors may be formalised by noticing that the
information requirements can (also) in fact be expressed in terms of an information requirement schema
(in the example the schema R1 posed by A6). However, in this setting, the design of the schema language
application needs to be strong enough to be able to dictate not only the structure and data types of the
models (which is generally the task of the information model schemas, i.e. S1, S2, and S3 in the example),
but also the actual information content transmitted. For instance, in addition of requiring that the model
includes objects with properties, say "type" and "model", one might typically also wish to require that at
least two such objects are in fact provided with sensible content.
6 (10)
Semogen Project Document: For internal project use only
At this point it is worth emphasising that the above design (Figure 3) is quite technology-agnostic. In other
words, it may be implemented using various ways. Strictly speaking, referring to XML (Extensible Markup
Language) is also unnecessary – many other formats are also sufficient for purposes of data normalisation
and transmitting.
Potential technologies for data normalisation and interfaces include (at least) XML, RDF (Resource
Description Format), and standards for transmitting relational data (such as ODBC, Open Database
Connectivity). In practice, these only provide the standard basis for communication. Thus, for purposes of
concrete applications, selecting and/or developing data structures and schemas are still needed. (The
specification of data modelling is not in the scope of this document and is described elsewhere.)
4. Recommendation for Systemic Implementation
While the above specification, analysis, and technical discussion of the semantic process might be helpful,
they do not alone suffice in pointing out a tool etc. setting for concrete work. We shall next describe an
approach for actually implementing the data processing perspective of the Semogen Semantic Process. The
basic idea is to "translate" the abstract concepts into a specific pattern of well-known technologies and
tools.
4.1. Components of the Semogen Semantic Process Development Environment
The realisation of a Semogen Semantic Process Development Environment will include the following main
components:
1. An integrated development environment (IDE), for managing data and interfacing with specific
tools and applications (including access to version control systems and collaboration tools).
2. Definition of Semantic Process Project with a common project structure that provides an identity
for resources related to a specific data processing application, in the IDE context.
3. Information requirements schema editor, for declaring the information needs of activities in a
well-formed manner (see e.g. R1 in Figure A6).
4. Based on the previous information, a critical information path analyser/validator application, for
supporting the production and mapping of high-quality information, to ensure that the information
requirements of each activity are fulfilled. (The analyser/validator may, e.g., report the malformed
or missing information items, the responsible activities, and produce an overall measure of the
success of the validation, e.g. as "Pipeline data processor can access 75% of the information
required by the activities.")
5. A pipeline data processor, for actually performing the data processing for, e.g., generator
applications.
6. Data representation technologies suitable for (normalised) syntactic and semantic descriptions.
7. Application-specific tools, such as adapters and simulation model generators.
8. Interface to target applications systems, such as access and possibility to generate data into the
Virtual Machine Laboratory Application.
9. Semantic information editor(s), for managing models and schemas, such as the shared information
model schemas.
We shall next briefly describe each in turn.
7 (10)
Semogen Project Document: For internal project use only
4.2. Suggestions of Specific Tools and Technologies
Without insisting a specific commercial document management system or similar, a relatively natural
choice for implementing items 1 and 2 above, is to consider using Eclipse (http://www.eclipse.org/) for
managing process information (see Figure 4).
Figure 4. Eclipse environment
As such, Eclipse provides the project concept, access to version control systems (e.g. SVN,
http://subversion.apache.org/), provides various developer tools and add-ons (and entire perspectives
etc.), and established common interfaces to other systems. Note that the Eclipse project concept in
practice also makes the significant ontological commitment of representing most data in terms of a (logical)
file system, i.e. as a structure of folders and files with special interpretation.
The question of a common project structure, is a subtle one and needs to be analysed in detail later.
However, an example of a decent project structure might look like this:
semantic-processes/
/* E.g. Eclipse (or SVN) root directory/repository */
semogen-pilot1/
/* A single example project */
informative-docs/ /* Informal docs, a snapshot of the original source, etc. */
pipeline-processing/
validate-inforeqs.ant
/* Information requirements validation script */
vmlab1-gen.ant /* Pipeline script for a virtual laboratory app1 generation */
vmlab2-gen.ant /* Pipeline script for a virtual laboratory app2 generation */
shared-schemas/
terms.skos
/* Thesaurus of the common terms */
jumbo.owl
/* Overall structure of the drilling machine */
simu.rdf
/* Simulation component library index */
bom.rdf
/* Bill of material, component names, parts catalogue, etc. */
lib/
simulink-library/ /* M-files etc. providing the basis of simulink generation */
2D-diagram-symbol-library/ /* Etc. */
...
tools/
/* Specific tools and tasks (e.g. simulink model generator) */
8 (10)
Semogen Project Document: For internal project use only
activities/
hydraulics-design/
requirements/
resources/
external/
/*
mappings/
/*
sem-desc/
/*
generated/ /*
vmlab1/
vmlab2/
mechanical-design/
...
...
/* Each process activity represented as a sub-directory. */
/* En example activity as a dir with a common structure */
/* Information requirement schemas of this activity */
E.g. externally edited rich CAD files, to be adapted/mapped */
Information mechanically adapted from the external data */
Manually added descriptions, on top of the mapped data */
Pipeline-generated content; a dir for each pipeline script */
Note that relationship with the semantic process is relatively straightforward. In particular, each modelled
activity that acts as a provider and/or requestor in the process, is modelled as a sub-directory in the
activities directory (see figures 1 and 3). As a consequence, the abstract model yields a particular file
structure of the project, and vice versa. Note that for simplicity, we have above assumed that the
information requirements definition simply includes the information requirements of all applications (here
vmlab1 and vmlab2). If more sophisticated modelling is needed, a more refined project structure is needed
as well.
At first, the information requirement schema editor is probably covered by a structured text editor (e.g.
several XML editor plug-ins are available for Eclipse). Of course, the choice strongly depends on the
adopted schema language – using a graphical editor would be preferable at some point.
The analyser/validator and pipeline processor tools can be implemented using an ant processor (again
available in Eclipse, see http://ant.apache.org/), with a combination of schema processors (e.g. for XML
Schema, RDF vocabularies, and Schematron) and scripts.
Suitable data representation technologies are XML and RDF vocabularies. For purposes of semantic data
processing, semantic relational models might be favoured, strengthened with semantic network models
when absolutely necessary.
Implementation of the adapters and model generators depends on the legacy data formats. However,
general-purpose data transformation and scripting applications seem reasonable (e.g. Ant, XSLT, Python,
etc.). When the legacy data cannot be easily parsed as such, export functionalities should be investigated
(the prime example here is the excellent SVG export of the Vertex tools). When everything else fails,
adopting Java/C#/C++ approaches might make sense.
At first the interface to the Virtual Machine Laboratory Application can simply be established simply by
copying/mirroring the appropriate subdirectories into the virtual environment subdirectories (including
the generated output of a data processing pipeline for a particular application), and refreshing/rebooting
the target environment when necessary. Later, a more powerful interface can be established, when
needed.
Semantic information editors, e.g. for the information model schemas, are selected according to the
schema language (e.g. Protege, open source XML Schema editors/validators, etc.).
9 (10)
Semogen Project Document: For internal project use only
4.3. Relationship with Design and Application Systems
It is worth emphasising that the Semogen Semantic Process Development Environment is meant as a tool
for the knowledge engineer and aims not including every component of the application context. In
particular, the actual (machine) design and target applications (and all of the related user roles) are not to
be replicated within the semantic process development environment.
Figure 5. Relationship of the Semogen Semantic Process Development Environment, design authoring
tools, and target applications
Figure 5 above depicts the basic design stance. In brief, the idea is that actual technical design is carried out
using the existing design tools (but perhaps following with specific guidelines, e.g., for good data quality
from the perspective of the semantic data processing). Design data are then stored to the Semogen
development environment. When final application data is available (e.g. produced by the generation
tools), it can be deployed to the target applications via a simple file interface.
This simple setting provides a concrete way to enrich data and generate applications. Note that using a
graphical IDE allows creating nice-looking toolbars of visual controls for executing, e.g., the
verification/validation, generation, and deployment tools.
5. Conclusion
In this document we have briefly identified and analysed the Semogen Semantic Process from the data
processing perspective. This work aims providing a basement and organisation for further activities,
including the related machine design process and semantic modelling activities, and experiments.
10 (10)
OSIO II
Väliraportti
Huom! Osion tiedot saattavat olla puutteellisia tai ristiriitaisia loppuraportin kanssa, koska
väliraportointivaiheessa kaikkea tietoa ei ollut käytettävissä.
1
| Semogen-väliraportti, joulukuu 2010 | 1 (44)
Teollisuuden älykkäiden ja virtuaalisten konelaboratorioiden tuotantomenetelmien kehitys
semanttisen kuvauksen avulla –Semogen hanke:
Semogen-väliraportti,
joulukuu 2010
Tampereen teknillinen yliopisto, Smart Simulators –ryhmä
Ossi Nykänen, toimittaja
Vänni Alarotu
Matti Helminen
Kari T. Koskinen
Mikko Markkula
Tuija Palonen
Seppo Pohjolainen
Pekka Ranta
Markus Rokala
Jaakko Salonen
Tiivistelmä. Tämä raportti jäsentää viipaleen hankkeen tutkimustyöstä joulukuulla 2010. Raportin
tarkoituksena on luoda katsaus selvitystyön pohjalta rakennettuihin ensimmäisiin malleihin ja
suoritettuihin käytännön kokeiluihin. Tapaustutkimuksen näkökulmasta työn keskeinen anti on
raportoida testiaineiston semanttisesta rikastamisesta ja "käsityönä" suoritetusta jatkojalostamisesta.
Nyt ensimmäisessä vaiheessa työtä on siis tehty aineiston varassa, jota ei ole alun perin tuotettu
semanttisen prosessin tarpeet silmällä pitäen. Alkuolettamusten mukaisesti, eräs tämän raportin
suuntaa-antavimmista havainnoista onkin se, että konkreettisen semanttisen projektin keskeinen
haaste on kompleksisuuden hallinta, erityisesti hyvälaatuisen teknisen suunnitteluinformaation
osalta. Niinpä esim. generoinnin haasteiden ratkaiseminen konkreettisissa suunnitteluprojekteissa
edellyttää teknisten menetelmien ohella myös henkilöresursointiin liittyvää panostusta.
Tuotantomenetelmien automatisointimahdollisuudet vaikuttavat lupaavilta.
Versio
v22 15.12.2010; vain Semogen –hankkeen sisäiseen käyttöön
Jakelu
Jakelu: Pauli Lappalainen AEL, Pasi Kaskinen AEL, Raimo Kivioja Etteplan, Mikko
Gratschew Etteplan, Kari Kovanen Etteplan, Jari Tiittanen Etteplan, Tomi
Martikainen Etteplan, Pekka Anttonen Sandvik Mining and Construction Oy, Heikki
Saha Sandvik Mining and Construction Oy, Jussi Puura Sandvik Mining and
Construction Oy, Veijo Niemelä Vertex Systems Oy, Manu Lammela Vertex Systems
Oy, Jorma Salli Vertex Systems Oy, Juha Leppänen Tuotekehitys Tamlink Oy, Kari
T. Koskinen TTY/Hydrauliikan ja automatiikan laitos, Seppo Pohjolainen
TTY/Matematiikan laitos/Hypermedialaboratorio, Ossi Nykänen TTY/Matematiikan
laitos/Hypermedialaboratorio,
Pekka
Ranta
TTY/Matematiikan
laitos/Hypermedialaboratorio ja Semogen –hankkeen tutkimushenkilöstö
| Semogen-väliraportti, joulukuu 2010 | 2 (44)
Sisällysluettelo
Lyhenteet ........................................................................................................................................................... 4
1. Johdanto......................................................................................................................................................... 5
2. Selvitykset ja mallit ....................................................................................................................................... 6
2.1. Systeeminen näkökulma ......................................................................................................................... 6
2.2. Selvitys luonnollisen suunnitteluprosessin osa-alueista ......................................................................... 8
2.2.1. Suunnitteluprosessin osa-alueet ....................................................................................................... 9
2.2.2. Suunnitteluprosessin välineet ja käytänteet ................................................................................... 10
2.3. Semanttinen prosessi suunnitteluprosessin osana................................................................................. 11
3. Tapaustutkimus............................................................................................................................................ 13
3.1. Yleiskatsaus aineistoon ja CASE-rajaus............................................................................................... 13
3.2. Hydrauliikkasuunnittelu ....................................................................................................................... 16
3.2.1. HD-aineisto.................................................................................................................................... 16
3.2.2. Rikastaminen ................................................................................................................................. 17
3.2.3. SVG-Export-toiminto .................................................................................................................... 18
3.2.4. HD-annotointi vs. ulkoisen tiedoston käyttö ................................................................................. 20
3.3. CAN...................................................................................................................................................... 21
3.3.1. CAN-aineisto ................................................................................................................................. 21
3.3.2. CAN-generointi ............................................................................................................................. 23
3.4. 3D ......................................................................................................................................................... 24
3.4.1. Aineisto.......................................................................................................................................... 24
3.4.2. Automaattisen generoinnin haasteet .............................................................................................. 25
3.5. Tietojen tuonti perusjärjestelmistä ja integrointi semanttiseen malliin ................................................ 26
3.5.1. Tietojen tuonti perusjärjestelmistä ................................................................................................. 26
3.5.2. Integrointi semanttiseen malliin .................................................................................................... 27
3.5.3. Sanastokartoitus ............................................................................................................................. 27
3.6. Pilot-ympäristön 1. prototyyppi ............................................................................................................ 31
3.7. Simulointimalliaihiot ............................................................................................................................ 34
3.7.1. Aihioiden yhdistämiseen ja parametrisointiin vaadittavat tiedot ................................................... 34
3.7.2. Simulink-aihiot ja generoinnin haasteita ....................................................................................... 34
3.7.3. Mallinnetut komponentit ............................................................................................................... 35
3.8. Case: nostotoiminto .............................................................................................................................. 35
3.8.1. Tavoite ........................................................................................................................................... 35
3.8.2. Tietojen tuonti perusjärjestelmästä RDF-kuvaukseen ................................................................... 36
3.8.3. Simulointimallien generointi aihioista RDF-kuvauksen perusteella ............................................. 37
| Semogen-väliraportti, joulukuu 2010 | 3 (44)
3.8.4. Tuotoksen lyhyt esittely, yleistettävyyden haasteita ..................................................................... 38
4. Tiedotus ja kaupallistaminen ....................................................................................................................... 40
4.1. Tiedotus ................................................................................................................................................ 40
4.2. Kaupallistaminen .................................................................................................................................. 42
5. Yhteenveto................................................................................................................................................... 42
Lähteet ............................................................................................................................................................. 43
| Semogen-väliraportti, joulukuu 2010 | 4 (44)
Lyhenteet
CAD
Computer-Aided Design
CAN
Controller Area Network
DBC
CAN Database File
DCF
Device Configuration File
EDS
Electronic Data Sheet
IDE
Integrated Development Environment
MDL
Simulink Simulation Model
OWL
Web Ontology Language
PDM
Product Data Management
PLC
Programmable Logic Controller
PLM
Product Lifecycle Management
RDF
Resource Description Framework
RDF/XML
RDF/XML Syntax Specification
RDFS
Resource Description Framework (RDF) Schema Specification
SKOS
Simple Knowledge Organization System
SPARQL
SPARQL Query Language for RDF
STEP
Standard for the Exchange of Product Model Data
SVG
Scalable Vector Graphics
URI
Uniform Resource Identifier
X3D
Extensible 3D
XML
Extensible Markup Language
XSLT
Extensible Stylesheet Language (XSL) Transformations
| Semogen-väliraportti, joulukuu 2010 | 5 (44)
1. Johdanto
Semogen -hankkeessa tutkitaan semanttisia kuvausmenetelmiä, mallien automaattista generointia ja
älykkäitä piirteitä sekä niitä sovelletaan virtuaalilaboratorioprototyypin kehitykseen. Hankkeen
punaisena lankana on virtuaalisten konelaboratorioiden tuotantomenetelmien tutkimus.
Tämä raportti jäsentää viipaleen hankkeen tutkimustyöstä joulukuulla 2010. Työ rakentuu kesällä
2010 kootun selvitysraportin (Ranta et al., 2010), jäsennettyjen tutkimusaineistojen, selvitysten ja
kokeilujen varaan. Raportin tarkoituksena on luoda katsaus selvitystyön pohjalta rakennettuihin
ensimmäisiin malleihin ja kokeiluihin. Raportti tarjoaa osaltaan myös puitteet pohdinnalle ja
tutkimuskysymysten täsmentämiselle.
Kun tutkimushanke käynnistyi, tutkimustyön pohjaksi asetettiin kolme suuntaa-antavaa
sovellusesimerkkiä: 1) Huoltoasentajakoulutus ja kouluttajan työvälineet, 2) Automaattinen
generointi ja 3) Jumbon puomin konstruktiomuutos. Nyt käsillä olevassa raportissa päähuomio
kohdistuu erityisesti automaattisen generoinnin sovellusesimerkkiin. Syy on se, että automaattinen
generointi on sovellusesimerkeistä monella tapaa haastavin, ja yhdessä empiirisen aineiston
jäsentämisen kanssa tarjoaa siten varsin konkreettisen tutkimusongelman eri näkökulmista
pureskeltavaksi: Konstruktiomuutos voidaan tässä tulkita erikoistapaukseksi generointitehtävästä,
huoltoasentajakoulutus puolestaan koko prosessin taustalla vaikuttavaksi käyttökontekstiksi.
Teknisen selvityksen ja kokeilujen ohella, eräs tämän raportin suuntaa-antavimmista havainnoista
on se, että konkreettisen projektin keskeinen haaste on kompleksisuuden hallinta, erityisesti
hyvälaatuisen teknisen suunnitteluinformaation osalta. Käytännön projektikulttuuri huomioiden,
tämä voi tarkoittaa/vaatia joko lisäresurssia pääsuunnittelijan roolille, tai kokonaan uuden
henkilöresurssin esittelyä suunnitteluprosessin osaksi: Pienen projektiryhmän näkökulmasta melko
konkreettinen tulos on havainto "teknisen tietämyksen pääsuunnittelijan" (knowledge engineer)
roolin tarpeellisuudesta.
Tämä väliraportti jakautuu pääpiirteissään viiteen osaan. Tätä johdantoa seuraavassa toisessa osassa
tarkastellaan tutkimusongelmaa systeemitasolla ja luonnehditaan ilmiötä kokonaisuutena. Raportin
kolmas osa keskittyy generoinnin tapaustutkimukseen ja jalostaa esiselvityksessä linjattuja
aineistoja ja menetelmiä tarkoituksena testata näitä käytännössä. Raportin neljäs osa kirjaa
havaintoja tiedotukseen ja kaupallistamiseen liittyen ja viides osa sisältää tiiviin yhteenvedon.
(Todettakoon vielä, että osiot 2 ja 3 sisältävät poimintoja projektiryhmän toistaiseksi
julkaisemattomista tuloksista. Niiden julkaisu tieteellisissä lehdissä/konferensseissa etenee projektin
julkaisusuunnitelman mukaisesti.)
Hankkeen yrityskumppanit ovat merkittävällä tavalla tukeneet työtä. Lämmin kiitos ohjausryhmän
jäsenten lisäksi AEL: Pasi Kaskinen, Harry Nordman, Eeva Varhomaa, Sandvik Mining and
Construction Oy: Pekka Anttonen, Heikki Saha, Jussi Puura ja Mikko Valtee, Vertex Systems Oy:
Manu Lammela, Jorma Salli ja Erkki Laitinen, Etteplan Design Center Oy: Mikko Gratschew, Jari
Tiittanen, Tomi Martikainen, Antti Peltola sekä TKE Oy: Timo Kesti ja Patrik Nylund aineistoista,
kommenteista ja näkemyksistä.
| Semogen-väliraportti, joulukuu 2010 | 6 (44)
2. Selvitykset ja mallit
2.1. Systeeminen näkökulma
Kenties luontevin tapa jäsentää koneensuunnitteluun ja tuotantoprosesseihin liittyviä (semanttisia)
malleja ja aktiviteettejä, on tarkastella aluksi ongelmakenttään sisältyviä eritasoisia prosesseja.
Tässä asiayhteydessä voidaan minimissään tunnistaa seuraavat, tavalla tai toisella toisiinsa liittyvät
prosessit:



Liiketoimintaprosessi
(Suunnitteluprojektien prosessien) metasuunnitteluprosessi
(Tietyn yksittäisen) suunnitteluprojektin prosessi
Liiketoimintaprosessi vaikuttaa organisaation tasolla, osoittaen yrityksen yleisen vision ja
pelisääntöjen ohella yksittäisten projektien yleiset puitteet, seurannan ja hyväksyttävän tuloksen
mittarit sekä tietenkin resursoinnin ja laskutuksen periaatteet. Liiketoimintaprosessi vaikuttaa
konkreettisesti myös esim. alihankintasopimusten yms. muodossa; koneensuunnittelussa tähän
liittyy esim. yhteistyö tiettyjen komponenttitoimittajien kanssa jne.
Metasuunnitteluprosessi liittyy tietyn suunnitteluprojektin prosessin suunnitteluun. Se tyypillisesti
käsittää projektien prosessimallin valinnan (esim. nelivaiheinen projekti jonka sisällä tietty määrä
iteratiivisia aktiviteettejä), tehtävien roolituksen periaatteet, palaveri- ja dokumentointikäytännöt
sekä välinevalinnat. Asiaan liittyy yleensä myös mm. seurannan mekanismien valintaa,
projektihenkilöstön kouluttamista, sekä aikaisemmista projekteista saatujen kokemusten
soveltamista. Vaikka metasuunnitteluprosessi voidaan pääasiallisesti tulkita organisaation sisäisenä
kehitystehtävänä, harjoitetaan metasuunnittelua käytännössä usein osana uusien asiakasprojektien
määrittelyä (ja siten osana tiettyjen suunnitteluprojektin prosesseja).
Tietyn yksittäisen suunnitteluprojektin prosessilla tarkoitetaan tässä tiettyä konkreettista hanketta,
joka tähtää esimerkiksi liikkuvan työkoneen suunnitteluun, toteutukseen sekä mm. aftermarkettoimintoihin, liiketoimintaprosessin rajausten mukaisesti. Yhteys metasuunnitteluun näkyy
esimerkiksi systemaattisina projektikäytäntöinä organisaation projektikannassa.
Semogen-hankkeessa esille nostettu semanttinen prosessi voidaan nyt tunnistaa osana sekä
metasuunnitteluprosessia, että tietyn yksittäisen suunnitteluprojektin prosessia: Se on osa
metasuunnittelua, joka tuo myös suunnitteluprojektien prosesseihin uusia konkreettisia piirteitä.
Ideatasolla semanttisessa prosessiajattelussa on kyse suunnitteluprojektin semanttisen tietosisällön
ja tietovirtojen (mekaaniseen, semanttiseen) mallintamisesta ja hallinnasta, valittujen
käyttötapausten ohjaamana. Automaattisen generoinnin sovellusesimerkin näkökulmasta
semanttinen prosessi korostaa informaation (mekaanista) uudelleenkäyttöä peräkkäisen
suunnitteluprosessin eri vaiheissa. Tämä paitsi asettaa tietyn suunnitteluprojektin prosessille
teknisiä vaatimuksia työtehtävien tuotosten osalta, korostaa se myös työtehtävien roolien ja
vastuiden merkitystä. Semanttinen prosessiajattelu näkyy siten melko konkreettisesti esim.
täsmennettyinä suunnittelukäytänteinä (esim. nimet ja viitattavuus), teknisinä välineinä (esim.
informaation muunnokset ja sovellusten generointi) sekä uusina informaation laaduntarkkailun ja
rikastamisen tehtävinä (esim. validointi, katveet, tietotarpeiden määrittely ja lisätiedon tuotanto).
Huomaa että kokonaan uuden tiedon tuottamisen sijaan kyse voi olla myös "vain" hiljaisen tiedon
ulkoistamisesta tai tiedon muokkauksesta esimerkiksi muistiinpanoista ja sähköposteista
| Semogen-väliraportti, joulukuu 2010 | 7 (44)
Tuotantomenetelmien näkökulmasta, keskeinen Semogen-tutkimuskysymys voidaan edellä esitetyn
valossa esittää nyt kaksiosaisena: Ensin melko abstraktina kysymyksenä (A) semanttisen prosessin
piirteistä ja minivaatimuksista osana metasuunnittelua, ja sitten huomattavan konkreettisena
kysymyksenä
(B)
semanttisen
prosessin
edellyttämistä
semanttisista
malleista,
informaatiorajapinnoista, välineistä ja työtehtävistä osana tietyn suunnitteluprojektin prosessia.
Haaste on molemmissa tapauksissa merkittävä: Metasuunnittelu lähtee perinteisesti ihmisten
suorittamien työtehtävien suunnittelusta (tavoitteet esim. projektien ja projektitiedon
toistettavuudelle/siirrettävyydelle on esitetty hyvin abstraktilla tasolla); konkreettisten
suunnitteluprojektien prosessin ohjaus puolestaan asiakkaalta suoraan laskutettavista työtehtävistä
(esim. informaation laatua koneellisen käsittelyn näkökulmasta ei perinteisesti mitata/vaadita).
Kuva 2.1.1. Semanttinen prosessi ja projektin tyypilliset tietojärjestelmät yhteyksineen
On ilmeistä että konkreettisen suunnitteluprojektin välineet (CAD, PDM, yms.) määrittelevät
merkittäviä reunaehtoja semanttisen prosessin toteutukselle. Asiaan liittyvien tietojärjestelmien
näkökulmasta, tietyn suunnitteluprojektin yhteydessä, voidaan tunnistaa toisaalta legacyjärjestelmien käyttöä melko vapaamuotoisesti ohjeistavia, ja toisaalta semanttista prosessia
formaalisti implementoivia toimenpiteitä (kuva 2.1.1). Näistä ensimmäinen ohjeistaa
suunnittelutyötä esim. kirjaamaan tarvittavat tiedot CAD-dokumentteihin ja jäsentämään
semanttiseen prosessointiin liittyviä työtehtäviä (kuvassa katkoviivalla merkitty palaute), toinen
puolestaan esim. mallintamaan, rikastamaan ja prosessoimaan semanttisen prosessin käsittämää
tietoa spesifien menetelmien ja tekniikoiden avulla, tavoitteena esim. tuottaa raakasisältöä
valittuihin sovelluksiin (kuvassa tummennetut järjestelmäkomponentit).
| Semogen-väliraportti, joulukuu 2010 | 8 (44)
Kuva 2.1.2. Esimerkki: Suunnitteluohjelmat, semanttinen prosessi ja kohdesovellukset (Nykänen,
2010)
Legacy-järjestelmien ja kohdesovellusten rajapinnan huomiointi on erityisen tärkeää
generointisovelluksen näkökulmasta. Periaatteessa neutraalein tapa hyödyntää semanttista
prosessiajattelua generointimielessä, on yksinkertaisesti tulkita semanttisen prosessi "toimenpiteinä"
esim. legacy-suunnitteluohjelmien ja kohdesovelluksen välillä (ks. kuva 2.1.2). Tämä mahdollistaa
järjestelmän käyttöönoton siten, että esim. vaikutukset (periaatteessa annettuihin) legacysovelluksiin jäävät vähäisiksi; minimissään siis hyvien käytäntöjen tasolla annetuiksi ohjeiksi.
Seuraavaksi pureudumme Semogen-tutkimuskysymyksen metasuunnittelun ongelmaan (A) kahta
reittiä pitkin. Ensin analysoidaan vallitsevan projektikulttuurin tyypillisiä piirteitä ja peilataan
semanttista prosessia osana eritasoisia suunnitteluprosesseja. Tietyn suunnitteluprojektin prosessin
konkretiaan (B) syvennytään tämän jälkeen tapaustutkimuksen keinoin luvussa 3.
2.2. Selvitys luonnollisen suunnitteluprosessin osa-alueista
Suunnitteluprosessin jäsentämiseksi sekä eri vaiheista saatavan tiedon selvittämiseksi käytiin
tekemässä haastattelututkimukset kolmessa, hieman eri roolissa toimivassa, yrityksessä: Sandvik
Mining and Construction Oy, Etteplan Design Center Oy ja Vertex Systems Oy. Näistä yrityksistä
Sandvik Mining and Construction kehittää, suunnittelee ja valmistaa koneita kaivos- ja
maansiirtotoimintaan. Sandvikin toimittamat koneet ovat hyviä esimerkkejä moderneista
moniteknisistä järjestelmistä, joissa yhdistyy käytännössä kaikki edellä mainitut suunnittelualueet.
Etteplan taas tarjoaa suunnittelu-, dokumentaatio- ja tuotetiedonhallintapalveluja muun muassa
Sandvikin kaltaisille yrityksille. Nämä suunnittelupalvelut kattavat kaikki luetellut
suunnittelualueet. Vertex Systems eroaa Sandvikista ja Etteplanista siten, että kyseinen yritys
pääasiassa kehittää ja toimittaa työkalut, eli ohjelmistot, joita Sandvikin ja Etteplanin kaltaiset
yritykset voivat käyttää suunnittelussa, tuotetiedon hallinnassa sekä dokumentoinnissa. Etteplan
Design Center Oy:ssa koneensuunnitteluprosessi mallinnettu ja tuotteistettu. He tarjoavat
konseptointi-, prototyyppi-, sovellus- ja ylläpitosuunnittelupalveluja sekä lujuuslaskentaa,
tuoteparantelua sekä tuotteistamistukea (Etteplan tuotesuunnittelupalvelut, 2010). Tätä palvelua
koneenrakennusyritykset voivat hyödyntää tarvitsemissaan osa-alueissa.
| Semogen-väliraportti, joulukuu 2010 | 9 (44)
2.2.1. Suunnitteluprosessin osa-alueet
Haastattelujen perusteella suunnitteluprosessi jaettiin karkeasti neljään suureen eri vaiheeseen.
Nämä eri vaiheet ovat esisuunnittelu tarjousvaiheen tukena, perussuunnittelu, valmistus/tuotantosuunitteluuunnittelu sekä huolto- ja kunnossapitosuunnittelu, jotka on tarkemmin esitelty
liitteessä A. Nämä osa-alueet ovat hyvin suuria kokonaisuuksia ja eroja niiden sisältämillä osioilla
esiintyy jopa henkilötasolla suunnittelualojen tasolta puhumattakaan. Riippuen suunniteltavasta
koneesta tai esimerkiksi projektin aikataulusta, voi eri osa-alueiden osioita esiintyä myös muissa
osa-alueissa.
Esisuunnittelussa tarjousvaiheen tukena selvitetään yleensä asiakkaan vaatimusmäärittelyn sekä
standardien ja suunnitteluohjeiden avulla reunaehdot koneen suunnittelulle. Tämä ensimmäinen
osa-alue tunnistetaan yleensä kaikkein tärkeimmäksi, koska mitä paremmin tämä suunnittelun vaihe
tehdään sitä vähemmän yllätyksiä projektin edetessä tulee vastaan. Esisuunnitteluun vaikuttavat
myös kiireiset aikatauluvaatimukset. Tässä vaiheessa ovat yleensä mukana mekaniikka-,
hydrauliikka-, automaatio- ja sähkösuunnittelijat sekä pääsuunnittelija/projektipäällikkö ohjaavassa
roolissa. Näiden suunnittelijoiden hiljaista tietoa sekä aikaisempien projektien tietoja käytetään
runsaasti hyväksi tässä vaiheessa.
Esisuunnittelussa saatujen pohjatietojen perusteella suunnittelijat voivat aloittaa koneen
perussuunnittelun, joka on toinen osa-alue, kuten liitteestä A voidaan nähdä. Perussuunnittelun osaalueessa
suunnitellaan
kone
valmiiksi
suunnitteluohjelmistojen
avulla.
Modernit
suunnitteluohjelmistot tekevät mahdolliseksi koneen tarkastelun kolmiulotteisen mallin avulla.
Koneen eri toimintoja ja toteutustapoja voidaan myös nykyohjelmistoilla simuloida melko tarkasti
tässä vaiheessa, ennen prototyypin valmistusta. Eri suunnittelijoiden toiminnot on esitetty
tarkemmin liitteessä A.
Kolmannessa osa-alueessa, valmistus-/tuotantosuunnittelussa, eri suunnittelijat muokkaavat
suunnitteluratkaisut lopulliseen muotoon koneen valmistusta varten. Tässä vaiheessa siis tuotetaan
valmistus- ja kokoonpanokuvat sekä erilaiset piirikaaviot ja muut valmistusohjeet. Valmistus/tuotantosuunittelussa tulee mukaan edellä mainittujen suunnittelijoiden lisäksi vielä osto- ja
tuotannon suunnittelu. Näiden tehtävänä on suunnitella koneen valmistuksessa käytettävien
valmiiden komponenttien hankinta sekä koneen tuotannon sovittaminen tuotantolinjalle muun
tuotannon joukkoon.
Viimeisessä suunnittelun osa-alueessa, huolto- ja kunnossapitosuunnittelussa, suunnittelijat
tuottavat materiaalia koneen dokumentaatioon. Tämän materiaalin avulla voidaan koneelle tuottaa
huolto- ja käyttöohjeet. Tässä vaiheessa suunnitteluun tulee mukaan myös After Market- toiminnan
suunnittelu, jossa kehitetään koneelle huolto-ohjelmat ja varaosapaketit. Tämä toiminta on yhä
suuremmassa roolissa nykyisten konevalmistajien liiketoiminnassa.
Suunnittelualojen välisiä yhteyksiä tarkasteltaessa mekaniikkasuunnittelijan rooli nousi keskeiseksi
tehdyissä haastatteluissa. Mekaniikkasuunnittelija suunnittelee koneen mekaanisen rakenteen sekä
mekanismit, joita käytetään esimerkiksi hydraulisilla toimilaitteilla. Mekaniikka- tai
hydrauliikkasuunnittelija valitsee koneessa käytettävät toimilaitteet ja hydrauliikkasuunnittelija
suunnittelee koneen hydrauliikkajärjestelmän siten, että mekanismien toiminnot voidaan toteuttaa
halutusti. Sähkösuunnittelija taas suunnittelee koneen sähköjärjestelmät siten, että toimilaitteita
ohjaavia venttiileitä voidaan ohjata ja automaatiosuunnittelija suunnittelee toimilaitteiden
ohjaukseen tarvittavat anturoinnit sekä ohjelmiston. Mekaniikkasuunnittelijan tehtäviin kuuluu
myös näiden osa-alueiden fyysisten komponenttien sovitus itse koneeseen. Jokaisen suunnittelijan
| Semogen-väliraportti, joulukuu 2010 | 10 (44)
oma osa-alue on kuitenkin yhtä tärkeä koneen toiminnan kannalta, koska ilman yhtä osa-aluetta
muut eivät voi toimia.
Tuotetiedonhallinta on tuotu liitteessä A melko uutena roolina mukaan suunnitteluprosessiin.
Nykyisin yrityksissä tiedon lisääminen esimerkiksi PDM-järjestelmään tapahtuu yksittäisten
suunnittelijoiden toimesta. Ohjeistuksena on yleensä käyttää jo valmiiksi järjestelmästä löytyviä
komponentteja koneen suunnittelussa. Tästä saatetaan kuitenkin joustaa muun muassa erilaisten
nimeämiskäytäntöjen vuoksi, jolloin suunnittelija ei välttämättä löydä hakemaansa komponenttia,
vaikka se on jo syötetty järjestelmään. Tällöin suunnittelija lisää järjestelmään komponentin
uudestaan hieman eri nimellä. Näin järjestelmään voi ajan kuluessa ilmestyä samalle komponentille
useita eri nimikkeitä (duplikaatteja) ja järjestelmän koko paisuu tarpeettomasti.
Tuotetiedonhallinnoijan tehtäväksi on haastattelujen perusteella ajateltu tämän päällekkäisen tiedon
vähentämistä ja eri tietojärjestelmien valvontaa. Joissakin yrityksissa tiedon oikeellisuudesta ja
validiuden tarkastelusta on vastannut normitarkastaja, jolla on yhteys tämän raportin "teknisen
tietämyksen pääsuunnittelijaan" (Johdanto).
2.2.2. Suunnitteluprosessin välineet ja käytänteet
Yrityksissä tehdyn haastattelututkimuksen avulla, voitiin kartoittaa kattavasti eri suunnitteluosaalueiden vaiheita. Haastattelujen perusteella havaittiin modernissa koneensuunnitteluprosessissa
saman koneen suunnitteluun osallistuvan useita eri alan asiantuntijoita. Näitä aloja ovat muun
muassa mekaniikka-, hydrauliikka/pneumatiikka-, automaatio-, sähkö- ja ohjelmistosuunnittelu.
Nämä
suunnittelun
osa-alueet
voivat
limittyä
hyvinkin
voimakkaasti
riippuen
suunnitteluorganisaation koosta, jolloin sama suunnittelija voi tehdä esimerkiksi mekaniikka- ja
hydrauliikkasuunnittelua.
Suunnittelijoilla on käytössään omaan alaansa liittyviä suunnitteluohjelmistoja kuten esimerkiksi
mekaniikkasuunnittelijan käyttämä 3D-CAD-ohjelmisto tai automaatiosuunnittelijan käyttämät
ohjelmistonkehitystyökalut. Eri suunnittelualojen ohjelmistoja yhdistää yrityksessä yleensä
PLM(Product Life Management) ja PDM(Product Data Management)-ohjelmisto, joihin n eri
suunnitteluohjelmistoilla tehdyt tiedostot tallennetaan ja joiden välityksellä tiedostoja voidaan jakaa
sekä hallinnoida.
Haastatteluissa tuli esille, että osa suunnittelussa syntyvästä ja suunnittelun pohjana käytettävästä
tiedosta ei ole välttämättä tallennettu mihinkään yhteiseen tietokantaan kaikkien saataville. Tämä
tieto
löytyy
yksittäisen
suunnittelijan
koneen
kovalevyltä,
suunnittteluohjelmasta
palaverimuistioista tai äärimmäisessä tapauksessa hiljaisena tietona suunnittelijan päästä. Nämä
tiedot välittyvät vain suullisesti esimerkiksi palavereissa. Usein myös yhteisesti saataville
tallennettu tieto on kyllä suunnittelijan saatavilla, mutta tallennuformaatti on sellainen, että
tietokone ei tätä pysty käsittelemään. Lisäksi tuotanto tekee usein muutoksia suunnitelmiin. Tämä
tieto pitäisi pystyä päivittämään myös suunnitteluaineistoon.
Suunnitteluprosessissa käytetyt välineet ovat vastaavia kuin tässä raportissa kuvattujen aineistojen
tuottaminen (viittaus luku 3). Haastatteluissa nousi esiin myös standardeja kuten konedirektiivin
mukainen viitetunnuslista (Y-tunnuslista), jolla yksilöidään nimi, sijainti ja selitys. Esimerkkinä
puomin venttiili +1BOO-Y26, joka tulkitaan + sijainti ykköspuomi, - laite Y=venttiili 26 liike
(nosto). Tämän tunnuslistan käyttö kannattaa tarkemmin selvittää. Konedirektiivien mukainen
suunnittelu korostuu koneenrakennuksessa. Tämä kehys luo lain vaatimukset.
| Semogen-väliraportti, joulukuu 2010 | 11 (44)
Suunnittelijoilla on myös haasteita käsitellä koko laitteen aineistoa. Useassa haastattelussa nousi
esiin toiminnallisten kokonaisuuksien jäsennystarve. Mikäli laitteesta voitaisiin jäsentää
moniteknisiä toiminnallisia kokonaisuuksia, suunnittelija voisi keskittyä tiettyyn kokonaisuuteen
kerrallaan. Tämä tukisi myös kommunikaatiota. Tällaista rakennetta ei suunnitteluaineistoihin tällä
hetkellä tuoteta. Virtuaalisen konelaboratorion näkökulmasta toiminnallinen kokonaisuus tarjoaisi
myös mielekkään jäsennyksen.
Suunnitteluprosessien analysoinnissa nousi esiin kontekstisidonnaisuus. Eri yritykset työskentelevät
eri tavoin. Yhtä ainoaa ”oikeata” mallia on erittäin haastava määrittää. Vaikuttaa siltä, että tahtotila
semanttisen prosessin periaatteisiin on kuitenkin tunnistettu. Tällä hetkellä ei ole yhtä
suunnittelujärjestelmää, jonka avulla voisi suunnitella, kommunikoida, dokumentoida ja hallita
monialaista suunnitteluprosessia siten, että aineistot olisivat yhteensopivia ja kaikki suunnittelutieto
(myös kokous- ja henkilöidenvälinen suora yhteys) olisi kattavasti käytössä.
2.3. Semanttinen prosessi suunnitteluprosessin osana
Kuten todettua, semanttinen prosessi voidaan intuitiivisesti ymmärtää pyrkimyksenä kuvata ja
hallinta esim. (tietyn konkreettisen) suunnitteluprojektin prosessin tietoja tiedon mekaanisen
käsittelyn näkökulmasta (ks. Nykänen 2010 ja kuva 2.3.1). Seuraavaksi tarkastellaan lyhyesti tämän
intuition jäsentämistä teoreettisen tarkastelun ja edelleen implementoinnin suhteen.
Kuva 2.3.1. Intuitiivinen ja yksinkertaistettu esimerkki semanttisesta prosessista
Semanttinen prosessi voidaan pelkistetysti esittää tietoa käsittelevän putkilinjaston tavoin, siten että
putkilinjaston yksittäisten käsittelyaskelten yhteyteen on liitetty skeematyyppistä tietoa. Putkilinja
voidaan edelleen käsittää käsittelyaskelten suhteen suunnattua graafina, jossa ei esiinny suljettuja
piirejä.
Kuva 2.3.2. Semanttisen prosessin osat (esimerkki)
Hyvin abstraktissa mielessä, semanttinen prosessi voidaan käsittää nelikkona <A, T, C, R>. Kuva
2.3.2 esittää yksinkertaista semanttista prosessia joka koostuu kolmesta esiehdoin merkitystä
aktiviteetista (A), kolmesta prosessointitehtävästä (T), kahdesta vaaditun informaatiorajapinnan
määrittelevästä skeemasta (R) sekä kolmesta kommunikaatioon liittyvästä (tässä hierarkkisesta)
| Semogen-väliraportti, joulukuu 2010 | 12 (44)
skeemasta (C). Sovelluksissa mallinnuksen tarkkuus riippuu sovellustarpeista sekä tarjolla olevasta
informaatiosta.
Kuva 2.3.3. Informaatio-objektien kuvaaminen aktiviteettien välillä (esimerkki)
Muodollisesti tarkasteltuna, semanttinen prosessi liittää kuhunkin aktiviteettiin joukon semanttisesti
kuvailtuja informaatio-objekteja (teknisesti semanttisin lausumin kuvailtuja resursseja; esim.
pumppu josta tiedetään tyyppi, teho, sekä paikka hydraulikaaviossa). Osa objekteista on tuotettu
aktiviteetissä itsessään, osa kuvattu edeltävissä aktiviteeteissa (ks. kuva 2.3.3). Esimerkiksi
simulointimallin
generoinnin
yhteydessä
simulointimalliin
voidaan
tuoda
tietoja
hydrauliikkakaavioon kirjatuista tiedoista. Näin generointi voi mekaanisesti hyödyntää jo
aikaisemmin tuotettua tietoa.
On merkillepantavaa, että tiedon mekaanisen prosessoinnin näkökulmasta tietojen kuvaaminen
kahden aktiviteetin (esim. Ai ja Aj) välillä onnistuu vain, mikäli kaksi esiehtoa toteutuu (vrt. kuva
2.3.1):
1. Aktiviteetin Aj edeltävältä aktiviteetiltä Ai tarvitsema informaatio on koodattu
asianmukaisella tavalla, sisältäen vaaditut tiedot halutuista informaatio-objekteista.
2. Aktiviteetin Aj tulkinta käytetystä kuvailusanastoista (semantiikka) on yhtäpitävä
aktiviteetin Ai kanssa.
Semanttisen prosessin edellyttämä skeematieto (R, C) tähtää juuri näiden nimenomaisten esiehtojen
mallintamiseen.
Tarkka skeematieto valitaan sovelluskohtaisesti. Tyypillisesti informaatiorajapinnan määrittelemä
skeematieto voidaan kuitenkin tulkita esim. validointikäyttötapauksen näkökulmasta,
kommunikaatioon liittyvä skeematieto puolestaan esim. mallinnuksessa käytettyjen sanastojen ja
nimistön kuvailukäyttötapauksen näkökulmasta (asiasanastot, käsitemallit, ontologiat, yms.).
Yhteys metasuunnitteluprosessin ja suunnitteluprojektien prosessien välillä on periaatteellisella
tasolla melko selvä. Metasuunnittelun tulee määritellä minimitaso informaatiorajapinnoille,
käytetyille nimikestandardeille (yms.) sekä ohjeistaa informaation laadun varmistava roolitus ja
mittarit. Konkreettisten suunnitteluprojektien prosessien tulee puolestaan määritellä
informaatiorajapinnat, valita tapauskohtaiset käsitemallit (tarvittaessa täydentää niitä), ottaa
käyttöön ja/tai implementoida validointi- ja generointityökalut sekä hallita informaatiota ja
huolehtia sen laadusta suhteessa esim. generoinnin käyttötapausten kanssa.
| Semogen-väliraportti, joulukuu 2010 | 13 (44)
Kuva 2.3.4. Roolit, tuotokset ja tehtävät semanttisessa prosessissa (esimerkki)
Käytännön työtehtävien näkökulmasta semanttisen prosessin implementointi tuottaa
suunnitteluprojektin prosessiin abstraktia mallia vastaavia tuotoksia ja edelleen tehtäviä ja vastuita.
Näitä ovat erityisesti käsitemallinnukseen sekä informaatiorajapintoihin (ja edelleen validointiin)
liittyvät skeemat. Kuvaan 2.3.4 on koottu pelkistetty esimerkki semanttisen prosessin tehtävistä ja
rooleista intuitiivista prosessimallia 2.3.1 mukaillen, kun tarkastelu on rajattu kahden aktiviteetin
määrittelyyn (A1, A2) ja näiden seuraaville aktiviteeteille tarjoamaan tietoon (O1, O2). On
merkillepantavaa, että koska legacy-perusjärjestelmistä (esim. CAD) ei käytännössä saada kaikkea
semanttisen prosessin edellyttämää tietoa, on odotettavissa että tietoja pitää täydentää
aktiviteettikohtaisesti. Yhdessä semanttisesti yhtenäisen käsitteistön kehitystehtävän kanssa, tämän
voidaan tulkita edellyttävän lisäresursointia ja/tai lisärooleja "perinteisiin" suunnittelutehtäviin
verrattuna.
On myös ilmeistä että systeemin kompleksisuus kasvaa melko nopeasti. Tämä korostaa
projektinhallinnan menetelmien (erit. systemaattinen vaatimusmäärittely, hyvin määritelty ja hallittu
informaatioarkkitehtuuri ja testauskäytännöt) ja välineiden käyttöönottoa (erit. jaettu versiointi).
Semanttisen prosessin perusidea ja toteutuksen pääpiirteet on teknisen tietojenkäsittelyn
näkökulmasta kuvattu lähteessä (Nykänen, 2010). Perusidea on implementoida yo. prosessi yleisesti
tunnettujen menetelmien (läh. XML ja RDF) ja välineiden avulla (esim. Eclipse, Apache Ant); tämä
mahdollistaa esimerkiksi teknisen projektin käsitteen määrittelemisen (jaetusti versioituna) tiettyjä
suunnitteluperiaatteita noudattavana hakemistorakenteena ja edelleen legacy-järjestelmien
integroinnin. Semanttisen mallinnuksen osalta yleisesti tunnettuja standarditeknologioita on tässä
kuitenkin tarkoituksenmukaista hieman täsmentää esim. semanttisten mallien ns. kanonisen
("yhdenmukaistetun") sarjallistuksen osalta; näin verkko-tietomallin mukaisesti esitettyä tietoa
voidaan tarvittaessa käsitellä myös puu-tietomalliin käsittelyyn suunnitelluilla työkaluilla. Tällä on
konkreettista merkitystä esim. skeema- ja prosessointiteknologioiden valinnan osalta.
3. Tapaustutkimus
3.1. Yleiskatsaus aineistoon ja CASE-rajaus
Esiselvitysvaiheessa (Ranta et al., 2010) projektin aloitus rajattiin koskemaan puominosto
toimintoa. Rajaus sisältää yksinkertaisen hydraulijärjestelmän, jonka tärkeimmät komponentit ovat
CAN-ohjattu suuntaventtiili, nostosylinteri ja pumppu. Lisäksi rajaukseen sisältyy nostotoimintoon
| Semogen-väliraportti, joulukuu 2010 | 14 (44)
liittyvä CAN-järjestelmä ja puomin 3D-malli. Projektia varten saatu materiaalia kattaa rajatun
järjestelmän suunnittelumateriaalin lukuun ottamatta komponenttien parametreja, komponenttien
3D-malleja ja ohjausjärjestelmää.
Esiselvitysvaiheen jälkeen saatu suunnitteluaineisto on laajentunut lähinnä CAN-väyläkuvauksen
osalta. Alla olevaan taulukkoon 3.1.1 on koottu kaikki saadut ohjelmistot ja tiedostot. Tiedostojen
sisältämä tieto on tutkittu ja selvitetty onko tallennettu tieto relevanttia ja käyttökelpoista projektin
kannalta. Lisäksi saatujen tiedostojen avulla projektissa on saatu kattava kuva konejärjestelmän
suunnittelussa syntyvistä dokumentaatiosta.
Taulukko 3.1.1. Yhteenveto aineistoista
Materiaali
Laajuus
Formaatti
Kuvaus
Vertex HD, ED ja 4G versiot 15, 17 ja 17+
exe
Suunnitteluohjelmisto
TKE:n CAN-aineiston
lukija
exe
Ohjelmisto
lukemiseen
tiedostoksi
Yleisesite Jumbosta
pdf ja mpg Vapaassa jaossa oleva esite DTi-sarjasta
signaalitietokannan
tallentamiseen xml-
DT1130i
käyttömanuaali
Kattaa
konejärjestelmän
Hydraulikaaviot
6
kappaletta: Vertex
koneikkorakenne, puomin ja pdf
toimilaitteet,
puomin
venttiilistö, 2 ohjaimet,
putkitukset
Puomin osaluettolo
Puomin
mekaniikka, pdf ja xml
hydrauliikka, sähköistys ja
anturointi
Sisältää
osanumeron,
kuvauksen
englanniksi, standardin tunnuksen ja
kappelemäärän.
Opetusmateriaalinen
tyyppinen
kuvauspuomista
Kattaa
puomin
powerpackin
ja doc
Yleistä tietoa TB100i-jumbon puomin
mekaniikasta
ja
hydrauliikasta.
Mekaanisten toimintojen nimet suomeksi
ja englanniksi.
Puomin hydrauliikan DT920i ja TB100i puomin xls
osaluettelo
hydraulikomponentit
Pumpun,
venttiiililohkon
ja
kuormanlaskuventtiilien
valmistajat,
tyyppikoodit ja kommentit.
3D-mallit
n 62 ja 22 Mt tiedostot. Sisältää
yksityiskohtaisesti puomin komponentit.
Ei tunnisteita tai nimiä.
Yksityiskohaiset
porapuomista
syöttölaiteesta
CANopen ja PLCopen Esittelee
CANopen
kuvaukset
PLCopen järjestelmiä
Venttiililohkon esite
Venttiililohkon
piirustus
koko pdf
ja
Käyttäjän manuaali englanniksi. Kuvaus
järjestelmästä ja sen toiminnoista ja
hallintalaitteista
Hd Kaavioissa olevat sanastot eroavat kielen
ja termien osalta. Yhteydet komponettien
välillä puuttuvat. Liitin-, putki-, ja
solenoiditunnukset
ovat,
mutta
ei
osanumerointia
tai
komponenttien
parametreja.
mallit stp
ja
ja pdf ja ppt
CANopen ja IEC 61131-3 järjestelmien
suunnittelu prosessin kuvaus
Bosch Rexrothin esite M4- pdf
12 venttiililohkosta
Kattava kuvaus venttiilin rakenteesta ja
ominaisuuksista
2D- 8 venttiilin venttiililohko dxf
2D-piirustuksena
Sisältää ulkoisia mittoja ja venttiililohkon
ulkoisen rakenteen
| Semogen-väliraportti, joulukuu 2010 | 15 (44)
Materiaali
Laajuus
Väyläkuvaus
Ohjaamo-,
puomiväylä
runko-,
CAN-sanasto
Sisältää tärkeimmät termit
Formaatti
Kuvaus
ja zip,
dcf, Esimerkki
kuvaus
väylärakenteesta.
bmp, eds, Sisältää solmutiedostot, väyläkuvauksen ja
dbc, ini
signaalitietokannan
xls
CAN-järjestelmän termistö ja datatyypit
CPD, EDS, DFC ja DBC tiedostoissa
Saatu aineisto kattaa hyvin tutkimushankkeessa määritellyn rajauksen eli Jumbon puomin ja
erityisesti nosto-toiminnon suunnitteluaineiston. Jo esiselvitys ja jatkotutkimukset ovat osoittaneet,
että vain harvat tiedostot saadusta suunnitteluaineistosta ovat käyttökelpoisia. Tästä syystä
materiaali on tarvinnut tuottaa itse ja tutkia mitkä tavat tallentaa informaatiota olisivat parhaita
tiedon jatkokäyttöä ajatellen.
Ohjelmistot
Vertex HD on osoittautunut käyttökelpoiseksi ohjelmaksi hydraulikaavion piirtämiseen ja etenkin
kaavioiden rikastamiseen suunnittelutiedolla. Siihen liittyvä svg-export on tärkeä
laajennusominaisuus, jonka avulla kaavion ja siinä olevan tiedon tallentaminen onnistuu projektin
kannalta parempaan tiedostomuotoon (svg). Kaikki kaavioon tallennettu tieto ei siirry svg-kuvaan,
mutta export-toiminto ei hukkaa tärkeätä tietoa.
Hydraulikaaviot
Saadut hydraulikaaviot eivät valitettavasti ole mahdollista suoraan käyttää toteutuksen
lähdemateriaalina. Tästä johtuen on alettu selvittämään yksinkertaisen hydraulijärjestelmän avulla
tiedon tallentamista ja tuomista hydraulikaaviosta. Haasteiden ratkettua alkuperäiset
hydraulikaaviot voidaan piirtää uudestaan käyttämällä uusia toteutustapoja.
Sähkö- ja väyläsuunnitteluaineisto
Sähkö- ja väyläsuunnitteluaineisto saatiin kolmen erillisenä pakettina osittain esiselvitysvaiheen
jälkeen. Väyläsuunnittelumateriaali on ajettu väylän todellisiin osiin eli runko-, ohjaamo- ja
puomiväylä. Kuvausta hyödynnetään myös oikean konejärjestelmän väyläsuunnittelussa.
Väyläpaketit sisältävät solmukohtaiset dcf-tiedostot ja ProCANopen-projektin EDS-tiedostot.
Lisäksi ProCANopen-projektista tallennetun signaalitietokannan (.dbc), solmulistauksen (.pco) ja
pco.ini-tiedoston.
Väyläsuunnittelu on toteutettu siten, että oikeista DCF-profiileista kootaan projektin kannalta
järkevä kokonaisjärjestelmä, joka tallennetaan eds-formaattiin. DCF-profiilien käsittelyyn käytetyn
ohjelman nimi on ProCANOpen ja eds-tiedostojen lukemiseen voidaan käyttää ilmaista CANeds
3.5 -ohjelmaa. Hankkeen kannalta erittäin positiivinen asia on, että kummatkin formaatit ovat
standardisoituneita tapoja käsitellä CAN-järjestelmiä ja lisäksi tiedostoformaatit ovat ASCIIpohjaisia sekä metatiedolla varustettua tietoa.
3D-mallit
Saadut 3D-mallit esittävät porapuomia ja syöttölaitetta (boom ja feedrail). Alkuperäiset mallit ovat
varsin yksityiskohtaisia. Mallit sisältävät mekaaniset osat, hydraulisylinterit ja poran ulkokuoret.
| Semogen-väliraportti, joulukuu 2010 | 16 (44)
Mallit sellaisenaan ovat liian yksityiskohtaiset käytettäväksi reaaliaikaympäristössä ja tunnisteet
puuttuvat.
3.2. Hydrauliikkasuunnittelu
3.2.1. HD-aineisto
Alkuperäiset Jumbon hydraulikaaviot olivat semanttisen mallinnuksen näkökulmasta puutteellisia,
koska näitä ei ole alunperin tuotettu tähän käyttötarkoitukseen.. Kuva 3.2.1 osoittaa mitä
hydraulikaavioiden puutteellinen semantiikka käytännössä tarkoittaa. Kaaviot vaikuttavat
silmämääräisesti eheiltä ja komponentit toisiinsa liitetyiltä. Tarkemmin katsomalla havaitaan
esimerkki hydraulikaaviossa ainoastaan letkuliitosten X1-X16 olevan fyysisesti liitetty
komponentteihin. Venttiililohkojen välissä olevia virtauskanavia ei ole yhdistetty lainkaan toisiinsa.
Vastaavasti letkutunnisteita ei ole fyysisesti kiinnitetty letkujen piirrosmerkkeihin. Myöskään
komponenttien nimiä ei ole kiinnitetty komponenttiin. Lisäksi termistössä on selvää vaihtelua
kaavioiden ja muiden dokumenttien välillä. Tässä venttiililohkon kaaviossa termit ovat kirjoitettu
englanniksi ja toimilaitteiden kaaviossa on käytetty suomea ja englantia. Sama kieli ei kuitenkaan
tarkoita, että termit olisivat yhteneviä. Esimerkiksi puomin jatkeesta havaitaan käytettäväksi muun
muassa seuraavia nimityksiä hydraulikaavioissa: Puomin zoom, Boom telescope ja Boom zoom.
| Semogen-väliraportti, joulukuu 2010 | 17 (44)
Kuva 3.2.1. Alkuperäisen hydraulikaavio
Alkuperäinen materiaali on erittäin laaja ja tarkka konejärjestelmän valmistusta ajatellen, mutta
tietojen löytäminen ja jäsentäminen ei ole koneellisesti mahdollista. Kuvatut haasteet ovat
pakottaneet keskittämään tutkimusta erityisesti hydraulikaavioissa olevan tiedon rikastamis-,
tallentamis- ja linkittämiskysymyksiin. Kaavioihin on lisättävä huomattavasti enemmän metatietoa,
yhdistettävä fyysisesti irrallaan olevat komponentit ja tehtävä niistä termistöltään yhtenevät. Tämän
jälkeen tiedostot ovat käytännössä käyttökelpoisia lähdemateriaaliksi. Venttiililohkot on järkevää
pitää omina makroinaan ja tuottaa simulointiaihiot lohkoittain.
3.2.2. Rikastaminen
Tutkimukset osoittavat, että Vertex HD-kaavioita voidaan tehdä semanttisesti kattaviksi. Näin
komponenttien liitokset, nimet ja muut tiedot on mahdollista linkittää jo hydraulikaaviossa.
Kaaviossa oleviin komponentteihin ja putkiin voidaan liittää myös komponentti- ja
referenssinumeroita. Näiden tunnisteiden pitäisi olla yksilöllisiä tunnisteita koko
suunnittelumateriaalissa, eikä ainoastaan kaaviotasolla. Vertex HD tukee myös taso-käsitettä eli
esimerkiksi oletuksena komponentit ovat tasolla yksi ja putket tasolla kolme ja komponenttinumerot
piirtyvät tasolle 11. Näin samasta kaaviosta on mahdollista tuottaa useita eri näkymiä.
| Semogen-väliraportti, joulukuu 2010 | 18 (44)
Lähes kaikelle kaaviossa oleville piirteille eli komponenteille, komponenttien IO-tunnisteille,
tunnisteiden teksteille, putkille ja komponenttinumeroille on mahdollista antaa yleisiä attribuutteja.
Vertex HD:n yleiset attribuutit ovat avain-arvo-pareja. Yleisillä attribuuteilla voidaan lisätä linkitys
ja parametritietoa hydraulikaavioon .Ne voivat siis olla esimerkiksi parametritietoa komponentista
(Area_A - 7e-3), tunnistetietoa (componentID - 1x2y3z) tai linkitystietoa Vertex HD:n ulkoiseen
materiaaliin (paremeterFile - cylinder.xml). Komponenttivalmistajat voisivat toimittaa alustavat
parametritiedot komponentistaan, joita konejärjestelmän suunnittelija rikastaisi ja tarkentaisi.
Uusimmassa testaamassamme Vertex HD:n versiossa yleiset attribuutit on lisäksi mahdollista
tallentaa komponentille jo makron luontivaiheessa. Näin makroon on valmiiksi tallennettuna
komponenttitietoa, jota koneensuunnittelijan ei välttämättä tarvitse enää muokata. Lisäksi
uusimmassa versiossa on mahdollista tehdä yleisistä attribuuteista listaus tekstitiedostoon, josta
käyttäjä valitsee haluamansa avain-arvo-parit komponentille.
Itse Vertex HD-tiedostoformaatti ei mahdollista tiedon lukemista, koska kyseessä on
binaariformaatti. Siksi erityisen iloinen havainto on, että yleiset attribuutit ja komponenttien väliset
suhteet tallentuvat Vertex HD-tiedostoon ja exportattuun SVG-kuvaan. SVG-muotoinen kuva on
XML-tiedosto, jota on mahdollista lukea ja käsitellä lukuisilla työkaluilla.
3.2.3. SVG-Export-toiminto
Vertex HD:n sisältämä svg-export toiminto mahdollistaa tiedon lukemisen Vertex HD:lla tehdystä
hydraulikaaviosta. Svg-kuvan etuna on, että se on mahdollista avata vaikka tekstieditorissa,
kuvankäsittely ohjelmassa tai selaimella. Toiminto ei ole vielä täydellinen, mutta suunta on
erinomainen. Tällä hetkellä osa komponenteista ei piirry svg-kuvaan täysin oikein ja itse svgtiedostomuoto on hieman xml-standardin vastainen. Tämä ei ole kuitenkaan ollut esti
tutkimustyölle. Rikastetusta hydraulikaaviosta saadaan tällä hetkellä siirtymään simulointimallin
generoimiseen vaadittavat tiedot eli komponenttien väliset liitokset, tunnisteet ja tarvittavat
parametrit. Vertex HD:ssa olevat tasot siirtyvät myös ja komponenteille tallentuu tunnisteet sekä
paikka kaaviossa. Kuvassa 3.2.2 on svg-exportattu hydraulikaavio, johon alkuperäisessä aineistossa
olleet puutteet on korjattu (kuva 3.2.1).
| Semogen-väliraportti, joulukuu 2010 | 19 (44)
Kuva 3.2.2. Esimerkki semanttisesti määritellystä hydraulikaaviosta
Kuvan 3.2.2 hydraulikaavio on tehty normaalisti Vertex HD:lla, käytetty svg-export-toimintoa ja
avattu firefox-selaimeen.Kuvasta 3.2.2 huomataan, että pumpun piirrosmerkin generointi ja
esittäminen selaimessa ei ole onnistunut täydellisesti. Tämä on kuitenkin pieni ongelma. Vertex
HD:ssa piirretty semantiikka on edelleen tallessa. Kaikki komponentit on kiinnitetty fyysisesti IOpisteiden avulla toisiinsa putkella ja lisäksi IO-pisteille ja komponenteille on annettu kuvaavat
nimet. Muutamalle komponentille ja putkelle on annettu esimerkiksi komponenttinumero, jotka
kiinnittyvät fyysisesti piirrosmerkkeihin. Alla (Kuva 3.2.3) on esitetty paineenrajoitusventtiilin
piirrosmerkki ja siihen liittyvä komponenttinumero tekstimuodossa.
<g vx:VxGroupId="MACRO_1_f19acd6c-c202-47af-9be0-7837ef04691a" vx:ELEM="3,3"
vx:ELEMID="3_3" vx:vmt_symbolid="203300589" vx:vmt_symboltype="1"
vx:vmt_vxtransform="|0.000000,-1.000000,256.700000|1.000000,0.000000,17.000000|" <strong>vx:vmt_fulldevlabel="Pressurereliefvalve"</strong>
vx:vmt_vxlayer="1" >
<polyline points="343.326,517.675 343.326,513.892 " stroke-width="0.35"
fill="none" stroke="rgb(0,36,170)" />
<polyline points="353.731,513.892 361.298,513.892 " stroke-width="0.35"
fill="none" stroke="rgb(0,36,170)" />
<circle cx="357.515" cy="512.946" r="0.945906" stroke-width="0.7" fill="none"
stroke="rgb(0,0,0)" />
<circle cx="357.515" cy="513.324" r="0.567544" stroke-width="0.7" fill="none"
stroke="rgb(0,0,0)" />
<polyline points="351.839,508.216 351.839,506.325 357.515,506.325
357.515,513.892 " stroke-width="0.35" fill="none" stroke="rgb(0,36,170)" />
<polyline points="342.38,513.892 334.813,513.892 " stroke-width="0.35"
fill="none" stroke="rgb(0,36,170)" />
<circle cx="338.597" cy="512.946" r="0.945906" stroke-width="0.7" fill="none"
stroke="rgb(0,0,0)" />
<circle cx="338.597" cy="513.324" r="0.567544" stroke-width="0.7" fill="none"
stroke="rgb(0,0,0)" />
<polyline points="353.731,519.567 353.731,508.216 342.38,508.216 342.38,519.567
353.731,519.567 " stroke-width="0.35" fill="none" stroke="rgb(0,36,170)" />
| Semogen-väliraportti, joulukuu 2010 | 20 (44)
<polyline points="348.056,519.567 348.056,523.351 338.597,523.351
338.597,513.892 " stroke-width="0.35" fill="none" stroke="rgb(0,36,170)" />
<polyline points="348.056,508.216 345.218,507.27 350.893,505.379 345.218,503.487
350.893,501.595 345.218,499.703 350.893,497.811 348.056,496.866 " strokewidth="0.35" fill="none" stroke="rgb(0,36,170)" />
<polyline points="353.731,517.675 349.947,518.243 349.947,517.108
353.731,517.675 343.326,517.675 " stroke-width="0.35" fill="none"
stroke="rgb(0,36,170)" />
</g>
<g *vx:ELEM="2,13" vx:ELEMID="2_13"* vx:vmt_subtype="CLABEL"
*vx:vmt_refelem="|3,3|"* vx:vmt_vxlayer="2" >
<text transform="matrix(2.72421 0 -0 3.40526 315.753 509.72)" fontfamily="Arial,'sans-serif'" font-size="1.39636" stroke-width="0.25"
fill="rgb(255,0,0)" stroke="none" >Port_P</text>
<g vx:ELEM="2,61" vx:ELEMID="2_61" <strong>vx:ExampleAttribute="Example
Value"</strong> vx:vmt_subtype="NORMAL" vx:vmt_refelem="|3,3|"
vx:vmt_vxlayer="11" >
<text transform="matrix(5.29707 0 -0 6.62134 352.844 545.193)" fontfamily="Arial,'sans-serif'" font-size="1.39636" stroke-width="0.35"
fill="rgb(0,36,170)" stroke="none" >2</text>
</g>
<g vx:ELEM="1,79" vx:ELEMID="1_79" vx:vmt_subtype="LINK"
*vx:vmt_linkends="|3,24|2,13|"* vx:vmt_netno="1" *vx:vmt_vxlayer="3"* >
<polyline points="312.111,513.892 342.38,513.892 " stroke-width="0.35"
fill="none" stroke="rgb(0,36,170)" />
</g>
Kuva 3.2.3. Listaus Vertex HD:sta svg-formaattiin viedystä kaaviosta
Kuvasta 3.2.3 voidaan poimia muutamia mielenkiintoisia kohtia tarkempaa tutustumista varten:






Komponentin nimi: vx:vmt_fulldevlabel="Pressurereliefvalve"
Paineenrajoitusventtiilin Port_P:n elementtitunniste ("2,13" on xmlstandardin vastainen): vx:ELEM="2,13" vx:ELEMID="2_13"
Komponenttinumeron ja Port_P:n fyysinen linkitys paineenrajoitusventtiilin
piirrosmerkkiin: vx:vmt_refelem="|3,3|"
Komponenttinumerolle annettu yleinen attribuutti:
vx:ExampleAttribute="Example Value"
Paineenrajoitusventtiilille tuleva putki: vx:vmt_subtype="LINK"
vx:vmt_linkends="|3,24|2,13|"
Piirtotason tunniste: vx:vmt_vxlayer="3"
3.2.4. HD-annotointi vs. ulkoisen tiedoston käyttö
Koska Vertex HD tukee yleisten attribuuttien käyttöä ja svg-export –toiminnallisuutta, olisi
simulointimallien generointiin vaadittavan tiedon tallentaminen mahdollista jo yksinomaan Vertex
HD-kaavioon. Lisäksi kaavioon voitaisiin tallentaa visualisointi ja toimintoinformaatiota.
Ongelmana on kuitenkin, että konejärjestelmän suunnittelija ei aina tiedä komponenttien tarkkoja
parametreja. Ainoastaan komponenttivalmistaja tietää komponenttien parametrit parhaiten ja tiedon
lisääminen Vertex HD-kaavioon suunnittelijan työpöydällä ei ole siksi järkevää. Yksi mahdollisuus
on, että komponenttivalmistaja toimittaa komponentin lisäksi myös rikastetun hydraulisymbolin
(Vertex makro) tuotteestaan. Symboliin olisi kirjattu tuotteen kuvaus, parametrit ja liityntäpinnit.
Kaiken tiedon tallentaminen makroon rajoittaa kuitenkin tiedon tuomista huomattavasti. Valinta
| Semogen-väliraportti, joulukuu 2010 | 21 (44)
tekee toimintatavasta ohjelmistoriippuvaisen, koska yleisesti kaavioiden piirto-ohjelmistoissa ei ole
mahdollisuutta tallentaa tarvittavaa tietoa.
Selvästi parempi tapa on tallentaa komponentin tiedot erilliseen dokumenttiin ja linkittää
dokumentti kaaviossa olevaan piirrossymboliin. Linkitys voidaan toteuttaa nyt yleisten attribuuttien
ja tulevaisuudessa esimerkiksi laiteinformaation avulla. Nykyisin tämä komponentin kuvaava
dokumentti on komponentin pdf-tiedosto, joka on mahdollista ladata komponenttivalmistajien
kotisivuilta. Samoin kuin hydraulikaavioiden tapauksessa, pdf-tiedostosta tiedon lukeminen
koneellisesti on melko vaikea operaatio. Komponenttien pdf-dokumenttien lähdemateriaali olisi
kiinnostava tutkimuskohde. Lähdemateriaalin ollessa kunnossa tiedoista voidaan koostaa
komponentin pdf-tiedoston lisäksi erillinen parametritiedosto tärkeimmistä parametreista.
3.3. CAN
3.3.1. CAN-aineisto
Aineisto koostuu ProCANopen -ohjelmalla luoduista tiedostoista. Tiedostot kuvaavat CAN-väylän
laitteet ja niiden väliset yhteydet (signaalit). Yksi ProCANopen -projekti sisältää yhden väylän
tiedot. Aineistossa on nyt kolme väylää (puomi:boom, ohjaus:hmi ja pääväylä:bbb), eli kolme
projektia. Yksittäinen projekti sisältää aina seuraavat tiedostot: PCO.ini, nodelist.pco, sekä jokaisen
väylällä olevan laitteen dcf ja eds tiedostot. Näistä voidaan ProCANopenin avulla generoida
signaalitietokanta (dbc).
Mahdollisia formaatteja dcf ja eds -tiedostojen tilalle olisivat XML-muotoiset xdc ja xdd -formaatit.
Ne sisältäisivät saman informaation, mutta tällä hetkellä eri ohjelmat jäsentävät niitä eri tavoin ja
hukkaavat osan informaatiosta, joten ne eivät vielä ole käyttökelpoisia formaatteja. Tästä johtuen on
viisainta käyttää vielä vanhoja ini-muotoisia dcf ja eds -tiedostoja lähdeaineistona.
Seuraavassa on esitelty lähdeformaatit lyhyesti.
PCO.ini
PCO.ini (ProCANopen projektitiedosto) on Vector ProCANopen -ohjelman käyttämä
tallennusformaatti. Se ei ole standardi, mutta silti yleisesti käytössä. PCO.ini sisältää yhden
ProCANopen -projektin ja on sen päätiedosto, pitäen sisällään yleiset asetukset ja listan muista
tiedostoista (DCF, EDS ja muu projektiin kuuluvat tiedostot, meidän tapauksessa
komponenttikuvat). Yksi projekti eli pco.ini kuvaa yhden väylän ja sen laitteet. Materiaalissamme
on kolme väylää, joten se sisältää myös kolme projektia. Projektit on eroteltu toisistaan sijoittamalla
ne eri hakemistoihin.
PCO.ini:n rakenne noudattaa standardia ini-formaattia, eli koostuu lohkoista: [lohko] ja
parametreista: parametri=arvo. Parametrit kuuluvat aina tiettyyn lohkoon.
Nodelist.pco
Nodelist.pco koostaa yhteen väylään liittyvät nodet. Tiedosto on rakenteeltaan ini-tiedosto. Tiedosto
sisältää jokaisen noden nodeid:n ja absoluuttisen polun joka noden DCF-tiedostoon. Tiedosto
noudatteleen suurin piirtein standardia ja hieman erinäköisiä toteutuksia on käytössä useammassa
ohjelmassa. Tietosisältö on näissä kuitenkin sama.
| Semogen-väliraportti, joulukuu 2010 | 22 (44)
Esimerkki nodelist-tiedostosta:
[Nodes]
2=C:\semogen\smg_boom\D002.DCF
12=C:\semogen\smg_boom\D012.DCF
13=C:\semogen\smg_boom\D013.DCF
DCF-tiedostot
Yksi DCF-tiedosto sisältää yhden noden eli can-väylässä olevan laitteen konfiguraatiotiedon. DCFtiedosto on rakenteeltaan ini-tiedosto, kuten PCO.ini:kin. Se sisältää laitteen nimen ja
yksityiskohtaisia tietoja, sekä laitteeseen liittyvät signaalit.
EDS-tiedostot
Myös EDS-tiedostot noudattavat ini-formaattia. EDS-tiedostot määrittävät laitekohtaiset
perusasetukset. Esimerkiksi kaikki samanlaiset anturit käyttävät samaa EDS-tiedostoa. Niiden
perusetella luodaan laitteelle DFC, jossa taas on kyseiselle laitteelle tarkoitetut asetukset. EDS
vastaa rakenteeltaan DCF-tiedostoa.
DBC-tiedostot
DBC-tiedostot ovat signaalitietokannan kuvaavia tiedostoja. Yksi DBC-tiedosto kuvaa yhden
väylän signaalit, eli yhden PCO.ini:n ja siihen liittyvien DFC-tiedostojen kuvaaman projektin
signaalit. DBC-tiedoston voi generoida ProCANopen -ohjelmalla PCO.ini ja DFC-tiedostoista.
DBC-formaatti ei ole avoin, vaan on Vectorin oma formaatti, joka on muodostunut de Facto
standardiksi. Formaatti on tekstipohjainen, mutta vaikeaselkoinen. Olemme saaneet formaattiin
lukijan TKE Oy:ltä, DBCreaderin, jolla on mahdollista lukea DBC-tiedostoja. Lukija on toteutettu
C#-kielellä ja lukee tiedot olion sisään. Lukijalta voi siis kysellä arvoja, jotka on ryhmitelty
hierarkisesti (Kuva 3.3.1.1). Olemme tehneet lukijan pohjalle työkalun, joka muuntaa DBCtiedoston xml-formaattiin, jossa on sama hierarkia kuin lukijassa.
| Semogen-väliraportti, joulukuu 2010 | 23 (44)
Kuva 3.3.1.1. DBC-formaatin rakenne
3.3.2. CAN-generointi
Olemme tehneet CAN-kaavion generoinnin yllä mainitun aineiston perusteella. Generointi vaatii
tällä hetkellä lähdeaineistokseen Nodelist.ini -tiedoston ja projektin dcf-tiedostot ja laitteiden kuvat
bmp-formaatissa. Generointi tuottaa svg-muotoisen kaavion CAN-väylästä. Generoinnin
putkilinjasto on esitelty kuvassa 3.3.2.2. Viiva esittää linkkiä tiedostojen välillä ja nuoli generaatioprosessia.
Kuva 3.3.2.2. CAN-kaavion generoinnin putkilinjasto
Generoinnin tuloksena syntyvässä svg-kuvassa ovat siis yhden väylän komponentit ja suora väylä
(Kuva 3.3.2.3). SVG-kuvaa voimme generoinnin yhteydessä rikastaa attribuutein, joihin
lähdeaineistosta poimitaan esimerkiksi komponentin ID ja nimi, jolloin kaaviota voidaan
myöhemmin käyttää pilotointiympäristön kanssa ja linkittää siihen tietoa. Lähdeaineisto ei sisällä
väylähierarkiaa eli reitittimiä ja topologiaa, mutta se ei ole välttämätöntä, jos generoinnin tuloksena
| Semogen-väliraportti, joulukuu 2010 | 24 (44)
saatuun aineistoon ei sitä tarvita. Myöskään mitään komponenttien sijoittelutietoja kaavioon ei
lähdeaineistossa ole, joten ne tulevat peräkkäin samalle väylälle.
Kuva 3.3.2.3. Generoitu CAN-kaavio
CAN-simulaation generoinnin näkökulmasta aineistossa ei ole ohjauslogiikkaa can-komponenteille,
mutta sieltä on luettavissa komponenttien tyyppi, tiedot, asetukset ja signaaliliikenne. Myöskään
signaalien reititystietoja eri väylien välillä ei ole. Signaalit reitittyvät väylällä olevan ohjaimen eli
PLC:n kautta pääväylään. Sama PLC-yksikkö siis voi olla useammassa väylässä ja on oikeasti sama
yksikkö. Lähdeaineistossa yksikkö voi olla eri nimellä eri väylissä, joten sitä on hankala yhdistää.
PLC-yksiköt tulisikin nimetä yhtenäisesti, jolloin voidaan tunnistaa niiden perusteella miten väylät
liittyvät toisiinsa.
Jatkokehityksen kannalta olemme miettineet keräävämme ensin kaiken tiedon lähdeaineistosta
RDF-formaattiin, josta voidaan sen jälkeen generoida CAN-kaaviot, simulointimalli,
hydraulikaaviot ja vaikkapa osaluettelo. RDF-formaatin käyttö mahdollistaisi myös CANinformaation integroinnin järjestelmän muuhun malliin, kuten hydrauliikkaan.
3.4. 3D
3.4.1. Aineisto
3D-aineistossa on toimitettu Jumbon porapuomin ja syöttökiskon 3D-mallit. Mallit toimitettiin
STEP-formaatissa. Porapuomin mallissa on 1705 osaa ja syöttökiskon mallissa 877 osaa. Mallien
ollessa näin suuria kokonaisuuksia, vaaditaan tehokas näytönohjain ja tietokone, jotta malleja
voidaan tarkastella ja käsitellä CAD-ohjelmassa. Kumpaakin malliin kaikki osat on sijoitettu
samaan tasoon ja osat on nimetty juoksevan numeron perusteella. Tällöin oleellinen osa aineistoa on
toimitettua mallia vastaava osaluettelo, joka onkin saatu porapuomista.
Aineiston rikastaminen
3D-mallit vaativat huomattavasti rikastamista, jotta niistä voitaisiin generoida automaattisesti
dynaaminen virtuaalimaailma. Rikastamisen vaiheet ovat seuraavat:






Osien nimeäminen osaluettelon osanumeroilla
Mallin jakaminen tasoihin osaluettelon kokoonpanojen perusteella
Mallin ylätason ryhmittely liikkuvien kokoonpanojen perusteella
Nivelpisteiden lisääminen dynaamisiin kokoonpanoihin.
Dynaamisten kokoonpanojen ketjuttaminen toisiinsa nähden.
Kokoonpanojen alkuasemien vastaavuus simulointimalliin nähden
Mallin rikastaminen tapahtuu käsityönä projektissa, mutta on asia, jota voidaan toteuttaa malliin jo
suunnitteluvaiheessa. 3D-mallien osien nimeäminen osaluetteloa vastaavasti helpottaa osaluettelon
| Semogen-väliraportti, joulukuu 2010 | 25 (44)
generointia myöhemmin ja selkeyttää tuotetiedon hallintaa. Lisäksi mallin jakaminen tasoihin ja
kokoonpanoihin parantaa kokonaismallin päivitettävyyttä.
Nivelpisteiden lisääminen
Nivelpisteiden lisääminen malliin on oleellinen osa mallin rikastamista, mikäli mallin halutaan
olevan dynaaminen virtuaalimaailmassa. CAD-ohjelmissa malli kääntyy keskipisteensä ympäri,
ellei toisin määrätä. Sama ominaisuus säilyy erilaisissa grafiikkamoottoreissa. Näin ollen jokaiselle
dynaamiselle kokoonpanolle on määrättävä oma 'pivot point', nivelpiste, jonka ympäri malli
kääntyy. Toisin sanoen, nivelpiste on kokoonpanonsa uusi origo. Nivelpisteiden on vastattava
mahdollisimman hyvin simulointimallin nivelpisteitä, jotta virtuaalimallin liike vastaisi oikeata.
Mikäli nivelpisteiden sijoittelussa on virheitä, kinemaattisesta ketjusta johtuen virhe kertautuu
puomin päätä kohden.
Ajatellaan esimerkkitapauksena hydraulisylinteriä, joka on kiinnitetty lenkeillä kummastakin
päästään x-akselin suuntaisesti.



Sylinterin rungon puolella nivelpisteen on oltava kiinnityslenkin keskellä kaikkien kolmen
pääakselin suhteen. Mikäli sijoittelussa on poikkeamia x tai y-akselin suhteen, sylinteri
pyörii epäkeskosti. Mikäli nivelpiste ei ole paikoillaan z-akselin suhteen, virhe näkyy
männänvarren liikkeessä
Sylinterin männänvarren nivelpisteen tulee olla samalla akselilla rungon nivelpisteen kanssa.
Muussa tapauksessa männänvarsi näyttää kelluvan sylinterin kääntyessä.
Männänvarren nivelpisteen on myös vastattava sijoittelultaan simulointimallin nivelpistettä
ja sylinterin alkuasema simulointimallin vastaavaa. Muussa tapauksessa sylinterin iskussa
näkyy asemavirhe: männänvarren kiinnitys menee sylinterin rungon sisälle tai koko
männänvarsi tulee ulos sylinteristä.
3.4.2. Automaattisen generoinnin haasteet
Ensisijainen haaste on aineiston siirtoformaatti, jossa aineisto (3D-mallit) siirretään automaattisen
generoinnin käsiteltäviksi. Siirtoformaatilta vaadittavia asioita ovat:
1.
2.
3.
4.
5.
6.
Osien nimien säilyminen
Osien tekstuurien säilyminen
Nivelpisteiden säilyminen
Kokoonpanojen säilyminen
Kokoonpanojen sidosten säilyminen
Osan käsite: kappaleen aliosat rajataan eri teksturoinneilla, ei muotojen perusteella.
Kohdat 5 ja 6 ovat valinnaisia, sidokset voidaan lisätä myöhemmin käsin ja osa voidaan koostaa
muodoista lukuvaiheessa, mutta tämä vaikeuttaa osan kolmioverkon rakentamista automaattisessa
generoinnissa.
Siirtoformaatin valintaan luo haasteita myös se, ettei niiden lukemiseen tarkoitettuja kirjastoja ole
saatavilla avoimen lähdekoodin versioina. Avoimet formaattien ongelmana on myös standardien
puute, mikä on aiheuttanut sen, että esimerkiksi eri ohjelmasta tallennettu STEP-muotoinen malli ei
vastaa toisesta ohjelmasta tallennettua. XML-pohjaisiin siirtoformaatteihin, kuten X3D
(http://www.web3d.org/x3d/) ja Collada (https://collada.org/) on saatavilla lukijoita paremmin ja
| Semogen-väliraportti, joulukuu 2010 | 26 (44)
niiden käyttöä Semogen-projektissa tutkitaan. Valitettavasti suunnitteluohjelmien tuki XMLpohjaisille siirtoformaateille on rajoittunutta.
Aineiston suuri resurssien (näytönohjaimen teho, koneen muisti) kulutus tuo haasteita
automaattiselle generoinnille. Aineiston resurssien kulutusta voidaan pienentää vähentämällä 3Dmallien sisältävien kolmioiden määrää. Tätä varten on olemassa valmiita algoritmeja, jotka toimivat
erilaisilla periaatteilla. Yksinkertaisimmat algoritmit yhdistävät tietyllä etäisyydellä olevat vertexpisteet toisiinsa, kun taas monimutkaisemmat rakentavat koko verkon uudelleen optimoituna
(Hoppe, et al. 1993). Edelliset ovat tehokkaita kappaleille, joissa vertex-pisteiden väleissä ei ole
suuria eroja, mutta tuloksen ulkoasu on aina tarkastettava silmämääräisesti, jälkimmäiset taas ovat
hitaampia, mutta tulos on usein muototarkempi ja vähentää kolmioiden määrää koko mallin alalta
riippumatta vertex-pisteiden väleistä. 3D-mallien resurssien kulutusta voidaan myös pienentää
poistamalla kokoonpanosta ns. merkityksettömiä osia, kuten muttereita, aluslevyjä ja korvakkeita.
Tutkimukset parhaan siirtoformaatin löytämiseksi jatkuvat, mutta siirtoformaatin valinnassa
varaudutaan kompromisseihin. Lisäksi tutkitaan erilaisia mahdollisia avoimen lähdekoodin lukijoita
eri siirtoformaateille ja valmiita algoritmeja 3D-verkon generointiin ja optimointiin.
3.5. Tietojen tuonti perusjärjestelmistä ja integrointi semanttiseen
malliin
Suunnittelijoiden perusjärjestelmillä (mm. Vertex HD, Vertex G4, SolidWorks) tuotettujen tietojen
tuonti koneellisesti käsiteltävässä muodossa on keskeinen osa järjestelmän semanttisen mallin
luontia. Pahimmillaan puutteet tietojen tuonnissa perusjärjestelmissä estää semanttisen prosessin
käyttöönoton. Käytännössäkin rajoitteet tietojen tuonnissa johtavat usein aineiston jälkikäsin
tehtävään, toisteiseen rikastamiseen.
Käsittelemme aluksi yleisesti tietojen tuontia perusjärjestelmistä. Tämän jälkeen pohdimme näiden
tietojen integrointia koko järjestelmän kattavaan semanttiseen malliin. Aliluvun lopuksi kuvataan
aineistojen mallinnukseen ja tuontiin liittyvä sanastokartoitus.
3.5.1. Tietojen tuonti perusjärjestelmistä
Tieto tuodaan perusjärjestelmistä niiden käyttämästä sisäisestä tallennusmuodosta yleisempään
formaattiin. Periaatteellisesti tiedon tuonti voidaan toteuttaa joko perusjärjestelmän tarjoamalla
vientiformaattituella tai toteuttamalla järjestelmän käyttämää formaattia tukeva lukijakomponentti.
Pyrkimyksenä molemmissa toimintatavoissa on tiedon jäsentäminen sovellusohjelmista
riippumattomassa formaatissa - ts. siten, että suunnitteluohjelmistoissa tuotettu tieto olisi
uudelleenkäytettävissä ja yhdisteltävissä käytetyistä sovellusohjelmistoista riippumatta. Tiedon
sarjallistukseen tässä tapauksessa soveltuu usein erityisesti XML. Mahdollisuuksien mukaan olisi
hyvä tukeutua myös muihin tunnettuihin avoimiin standardeihin.
Semanttisen mallin luomista varten järjestelmistä saatava tieto on jäsennettävä siten, että eri
lähteistä peräisin olevilla rakenteilla on toisiinsa nähden yksilölliset nimet, joihin voidaan mallien
välille luoda viittauksia. Esimerkiksi 3D-mallista tuotaville komponenteille on kyettävä luomaan
yksikäsitteiset tunnisteet siten, että useista eri malleista peräisin olevat komponentit voidaan
yhdistellä ilman päällekkäisyyksiä. Toisaalta mallin tasolla pitäisi mahdollistaa se, että yksittäinen
komponentti voi esiintyä useissa eri lähdeaineistoissa. Esimerkiksi komponentiksi, joka esiintyy
kahdessa eri 3D-mallista tulisi pystyä tunnistamaan samaksi komponentiksi. Vastaavasti nimistössä
ei saisi muodostua päällekkäisyyksiä toisistaan selvästi erillisistä nimikkeistä.
| Semogen-väliraportti, joulukuu 2010 | 27 (44)
3.5.2. Integrointi semanttiseen malliin
Jotta eri lähdeaineistoista tuotu tieto voidaan yhdistellä järjestelmätason malliksi, on se jäsennettävä
siten, että useista järjestelmistä peräisin oleva tieto voidaan mallin ja sen eri rakenteiden tasolla
yhdistellä. Perusjärjestelmistä tuotua tietoa voidaan rikastaa myös käsin niiltä osin kun
tuontirajapintojen toteuttaminen ei ole mahdollista tai kannattavaa. Ideana järjestelmän semanttisen
mallin kuvaamisessa on, että sen avulla järjestelmästä voidaan generoida erilaisia raportteja ja
aineistoja. Jotta generointityövälineiden toteuttaminen olisi tehokasta, tulisi kaikissa malleissa
käyttää yhteisesti hyväksyttyjä sanastoja ja nimikkeitä. Esimerkiksi erilaisten komponenttityyppien
(hydraulikomponentti, CAN-komponentti, jne.) tunnistamiseen tulisi olla tapa, joka on mallien
välillä yksikäsitteinen. Näin ollen tarvitaan siis mallien välillä jaettujen käsitemallien eli skeemojen
toteuttamista, ja aineistojen kuvaamista näihin yhteisesti määriteltyihin skeemoihin. Käsitemalli voi
yksinkertaisillaan olla hyvinkin pelkistetty. Tärkeää kuitenkin on, että sitä voitaisiin uusien
käyttötapauksien ja tarpeiden noustessa laajentaa joustavasti.
Tiedon semanttiseen mallinnukseen soveltuvat erityisesti semanttisen webin teknologiat, kuten
RDF (Carroll & Klyne, 2004) ja sen sanastot RDFS (Guha & Brickley, 2004) ja OWL (Schreiber &
Dean, 2004). Käyttämällä standardeja teknologioita semanttisessa mallinnuksessa vältytään
erityisesti formaatteihin liittyvien yksityiskohtien uudelleenmäärittelyiltä. Näille tekniikoille on
myös saatavilla valmiita, käyttökelpoisia sovelluskirjastoja. On kuitenkin syytä huomata, että mitä
ilmaisuvoimaisempaa kieltä tiedon esittämiseen käytetään, sitä vähemmän käyttöön soveltuvia,
standardien mukaisia kirjastoja on saatavilla. Tästäkin syystä ainakin alustavasti on perusteltua
jäsentää tietoa ilman RDFS- ja OWL-sanastoja. Koska XML on on lähdeaineistoista tuotaville
tiedoille merkittävä sarjallistusformaatti, on myös RDF:stä mielekästä pyrkiä hyödyntämään sen
XML-pohjaista sarjallistusmuotoa RDF/XML (Beckett, 2004). On syytä huomata, että RDF:n
XML:n pohjaisen sarjallistuksen käsittely XML-välinein on tyypillisesti haastavaa, koska
standardisarjallistus ei pakota jäsennystä normaalimuotoon, eikä formaatin käsittely siten ole
helppoa esim. XSL-muunnosten avulla (Clark, 2001; Kay, 2009). Tätä tarvetta silmälläpitäen
hankkeessa on määritelty erillinen, RDF:n kanoninen XML-sarjallistus (Nykänen, O. 2010b).
3.5.3. Sanastokartoitus
Hankkeen lähdeaineistojen analysoinnin yhteydessä kartoitimme myös aineistoissa esiintyviä
käsitteitä ja niiden välisiä yhteyksiä. Hypoteesi työssä on, että kartoittamalla lähdeaineistoihin
liittyviä käsitteitä ja sanastoja voidaan löytää järjestelmiin liittyviä keskeisiä käsitteitä sekä
tunnistaa eri aineistojen välisiä yhteyksiä integroidun semanttisen mallin luomiseksi. Kartoituksessa
syntyvää mallia voidaan hyödyntää myös mm. sanastojen visualisointiin.
Menetelmät ja mallinnus
Kartoituksessa mallinnettiin lähdeaineistojen perusteella toimialoihin liittyvät asiasanastot.
Mallinnusformaattina käytettiin pääasiassa RDF:ää laajentavaa SKOS:a (Simple Knowledge
Organization
System).
Sanastot
tuotettiin
käyttämällä
Protégé-ohjelmistoa
(http://protege.stanford.edu/)
ja
sen
SKOS
Editor
-laajennusta
(http://protegewiki.stanford.edu/wiki/SKOS_Editor). Aineistojen perusteella sanastot jaettiin
neljään pääsanastoon: mekaniikka-, sähkö/CAN-, hydrauliikka- sekä simulointisanastoon.
Sanastojen yhdistely sekä niihin liittyvät yläkäsitteet kuvattiin lisäksi erilliseen semogenontologiaan.
| Semogen-väliraportti, joulukuu 2010 | 28 (44)
Erityisesti formaalin ontologiamallinnuksen sijaan SKOS valittiin käyttöön sen tarjoaman
joustavuuden takia: SKOS-mallissa käsitteisiin ja niiden välisiin yhteyksiin liittyvää
epämääräisyyttä ja keskeneräisyyttä voidaan helpommin mallintaan. SKOS-attribuuteista
käsitteiden mallintamiseen käytettiin attribuutteja erityisesti käsitteiden nimikkeiden ja niiden
välisten yhteyden kuvaamiseen (ks. Isaac & Summers, 2009):




Käsitemallit skos:ConceptScheme)
Käsitteet (skos:Concept) ja niiden liitynnät käsitemalleihin ( skos:inScheme,
skos:topConceptOf)
Käsitteen ensisijainen nimi ( skos:prefLabel) sekä vaihtoehtoinen nimi (skos:altLabel)
Käsitteeseen liittyvät ylä- ja alakäsitteet ( skos:broader, skos:narrower)
Pohjasanaston rakentaminen toteutettiin askeleittain läpikäymällä aineistojan kussakin osa-alueessa
asiantuntijana toimivan tutkijan kanssa. Aineistojen läpikäynti tapahtui ensisijaisesti tutkimalla
aineistoa sitä tukevilla perusjärjestelmillä (Vertex HD, Vertex G4, Procanopen, jne.). Läpikäynnin
yhteydessä tarkasteltiin ja luotiin yhteyksiä tarpeen mukaan myös osa-alueeseen liittyviin
julkaisuihin ja standardeihin - käsitemalleja ei kuitenkaan toisinnettu näistä lähteistä, vaan pohjana
käsitteen luonnille toimi aina lähdeaineisto. On syytä kuitenkin huomata, että osa käsitteistä ei
esiintynyt lähdeaineistoissa eksplisiittisesti, vaan tunnistettiin läpikäynnin aikana implisiittisesti.
Esimerkiksi järjestelmän mekaniikkamallissa ei eksplisiittisesti käytetty termiä mekaaninen
komponentti, mutta käsite pystyttiin tunnistamaan aineiston pohjalta.
Tulokset ja pohdintaa
Kartoituksessa syntyi SKOS-käsitemalliin pohjautuva, viidestä eri käsitemallista koostuva
pohjasanasto (kts. Kuva 3.5.1). Käsitteistöön syntyi 36 sähkö/CAN-, 54 hydrauli-, 13 mekaniikkaja 31 simulointikäsitemalliin liittyvää käsitettä. Sanastoja yhdistelevään semogen-sanastoon liitettiin
lisäksi 8 käsitettä.
| Semogen-väliraportti, joulukuu 2010 | 29 (44)
Kuva 3.5.1. Visualisointi koostetusta käsitemallista
Simulointisanaston osalta käsitetietoa oli hyvinkin paljon saatavilla. Karkeasti ottaen malleista
saatava tieto voitiin jakaa 1) yleisempään simulointisanastoon, 2) Simulink-sanastoon sekä 3) mallitai toteuttajakohtaisiin sanastoihin. Haasteena sen kartoituksessa katsottiin erityisesti rajanvedon
formaalin mallinnuksen osalta. Näiden rajapintojen tunnistaminen sanastotyössä oli jonkin verran
haastavaa. Mitä hienojakoisemmin jaottelua tehdään, sen monimutkaisemmiksi sanastot muuttuvat.
Tarkoituksenmukaisin ratkaisu on lienee kompromissi tarkkuuden ja sovellettavuuden välillä.
Mallinnuksessa todettiin myös, että käsitteiden yksikäsitteinen nimeäminen oli haastavaa: kaikkien
termien osalta yksikäsitteistä nimeä ei pystytty tunnistamaan. Ulkoisista lähteistä hyödylliseksi
osoittautui Simulink-ohjelmistoon liittyvä dokumentaatio (The Mathworks Inc., 2010).
Hydrauliikan osalta kattavan ydinsanaston tekeminen edellytti kaavioiden lisäksi tutustumista paitsi
hydrauliikkaan liittyviin suosituksiin niin myös joiltain osin alaan liittyvän oppimateriaaliin.
Merkittävä osa kaavion tuottamiseen liittyvistä käsitteistä ei eksplisiittisesti esiinny kaaviossa, eikä
siten ole aineiston perusteella identifioitavissa. Monelta osin määrämuotoinen tieto kaavioihin
liittyvistä käsitteistä löytyi alaan liittyvistä online-oppimateriaaleista, erityisesti Foster Hydraulic
Wiki-sivustosta (Wikia, 2010). Näiden peruskäsitteiden tuntemus kuitenkin selvästi oletettiin
kaavion tulkitsijalta, mikä voi myöhemmin aineiston semanttisessa mallinnuksessa osoittautui
haasteeksi. Erityisen haastavaksi hydrauliikan osalta osoittautui käsitteiden välisten yhteyksien
| Semogen-väliraportti, joulukuu 2010 | 30 (44)
määrittely. Merkittävimmin sanastoa saatiinkin rikastettua asiantuntijan kanssa tehdyssä
vapaamuotoisessa, keskustelevassa läpikäynnissä.
Sähkö/CAN-sanastoissa aineistosta johtuen keskityttiin merkittävästi CAN:iin ja CANopeniin
liittyvien käsitteiden määrittelyyn (kts. kuva 3.5.2). Käytettävissä olleessa, proCanOpenohjelmistolla mallinnetussa mallissa oli simulointimallien tavoin ennemminkin ylimäärin
käyttökelpoista tietoa. Myös näiden osalta haasteeksi osoittautui rajaus. Myös CANopen mallit
sisälsivät
erittäin
paljon
toteutusteknisiin
yksityiskohtiin
liittyvää
tietoa,
jonka
uudelleenkäytettävyys ei integroidussa semanttisessa mallissa ole niin hyvää. CANopeniin littyvistä
standardeista (mm. CANopen, 2000; CANopen, 2005; CANopen, 2007) pystyttiin varmentamaan ja
täsmentämään jonkin veran käsitteistöä, mutta suomenkielisten termien löytäminen oli paikoin
hankalaa. Erittäin hyväksi lähteeksi osoittautui Heikki Sahan (2008) suomeksi kääntämä CANasiasanasto.
Kuva 3.5.2 Visualisointi CAN-käsitemallista
Mekaniikkaa kuvaavien käsitemallien rakentaminen aineistopohjaisesti osoittautui varsin
haastavaksi. Lähdeaineistona toimitettujen 3D Step-mallien läpikäynti ei ilman asiantuntija-apua
tarjonnut juuri lisäinformaatiota mekaniikkaan liittyen. Vasta 3D-mallinnusta ja
mekaniikkasuunnittelua tehneen asiantuntijan kanssa mallista kyettiin löytämään keskeisiä
mekaniikkaan liittyviä käsitteitä. Aineistojen pohjalta näyttäisi myös siltä, että vaikka
mallinnusohjelmistoissa tuki erityyppisille metatiedoilla on olemassa, ei nykykäytännössä 3D-
| Semogen-väliraportti, joulukuu 2010 | 31 (44)
malleihin upoteta juurikaan semanttista tietoa niissä kuvatuista rakenteista, mikä tietyllä tavalla
kuvaa vallitsevia tuotantoprosesseja.
Aineistojen pohjalta kyettiin tunnistamaan myös muutamia, kaikki mallinnusalueet yhdistäviä
käsitteitä. Kartoituksessa löydettiin kaksi malleja yhdistävää ylätason käsitettä, kokoonpano (engl.
assembly) ja komponentti (engl. component) sekä näihin liittyvät mallinnusaluekohtaiset
alakäsitteet. Kokoonpanon osalta yhdistävät alakäsitteet ovat CAN-väylä, hydraulikaavio,
mekaaninen kokoonpano. Komponenttien alakäsitteiksi tunnistettiin CAN-komponentti,
hydraulikomponentti sekä mekaanikkakomponentti. Peruskäsitteistä oli nimistössä esillä eri
kirjoitusmuodoissa ja mm. synonyymein, mikä korostaa käsitteiden keskeisyyttä. Mielenkiintoista
näissä käsitteistä on myös se, että ne tarjoavat formaalin käsitemallin eri malleista peräisin olevan
tiedon yhdistelylle ja integroinnille. Esimerkiksi hydraulikomponenttiin voi liittyä samaa
komponenttia kuvaavaa mekaaninen malli - toisin sanoen sama komponentti esiintyy järjestelmän
eri kuvauksissa eri rooleissa. Liittämällä näihin malleihin komponentin yksikäsitteisesti tunnistavan
tiedon, voidaan eri lähdemateriaaleista peräisin olevia malleja yhdistellä kokonaiseksi, järjestelmän
semanttiseksi malliksi.
Kokonaisuudessaan saatavien tietojen laatu näyttää vaihtelevan merkittävästi aineistoittain.
Kartoitus vaikuttaisi kuitenkin tarjoavan hyvän pohjan semanttisen mallin luonnille ja aineistojen
tuontiin ja integrointiin mallin mukaisesti. Kun aineistoihin liittyviä muunnoksia (adapterit, vientityökalut) lähdetään valitsemaan, voidaan kartoituksen pohjalta lähteä luomaan varsinaista formaalia
käsitemallia semanttiselle mallille. Alustava formaali käsitemalli, jonka varaan aineistot
muunnetaan on todennäköisesti kartoitusta huomattavasti suppeampi, mutta laajennettavissa tarpeen
mukaan. Kompleksisuuden kasvaessa semanttisessa mallissa, voi tarpeen olla ottaa käyttöön
erityisesti RDF-skeema-sanasto.
3.6. Pilot-ympäristön 1. prototyyppi
Pilot-ympäristön prototypoinnissa tavoitteena on määritellä ja toteuttaa sellainen työympäristö,
jossa eri perusjärjestelmistä saatava tieto voidaan koota yhteen ja edelleen viedä ulos erilaisiin
kohdejärjestelmään. Tavoitteena on, että ympäristö tukisi integroitumista moniin erilaisiin
kohdejärjestelmiin. Ympäristön avulla semanttista tietoa voitaisiin myös rikastaa. Sen tulisi tukea
myös
vientiominaisuuksien
toteuttamista
semanttisen
tiedon
viemiseksi
erilaisiin
kohdejärjestelmien tukemiin formaatteihin.
Ensimmäinen
prototyyppi
pilot-ympäristöstä
on
toteutettu
Eclipse-sovelluskehyksen
(http://www.eclipse.org/) ja sen tarjoamien perustoiminnallisuuksien ja -työkalujen avulla. Eclipse
on pitkälle kehittynyt, vakaa, avoimen lähdekoodin sovelluskehys ja se perustuu joustavaan
laajennus-mekanismiin. Erilaisten dokumenttin katselu, muokkaaminen ja käyttö on ympäristössä
hyvin tuettua. Laajennusten avulla sovelluskehystä voidaan laajentaa esim. Java, C/C++, Python ja
C#-kehitysympäristöksi. Myös XML-tekniikoiden (XML, XSLT) käyttö on hyvin tuettua.
Ryhmätyöominaisuuksia ja versionhallintaa varten kehys sisältää tuen CSV-versionhallintaan.
Myös muiden versionhallintajärjestelmien tuki on saatavissa laajennusten avulla.
Eclipse-ympäristön käyttö perustuu näkymiin (ks. kuva 3.6.1). Yksi näkymä tarjoaa tyypillisesti
välineet informaatiohierarkkian navigointiin, editorin avaamiseen sekä ominaisuksien katseluun
aktiivisessa editorissa (Springgay, 2001). Laajennukset voidaan toteuttaa tarjoamaan uusia,
laajennuskohtaisia näkymiä. Esimerkiksi resurssienkatselunäkymässä (kuvassa) voidaan navigoida
projektiin liittyviä hakemistoja ja tiedostoja, sekä avata näitä formaattikohtaisesti erilaisilla
editoreilla. Sisällöntuotantoa tukevia välineitä voidaan lisäksi tuoda esille editorikohtaisesti.
| Semogen-väliraportti, joulukuu 2010 | 32 (44)
Kuva 3.6.1. Eclipse-sovelluskehyksen hyödyntäminen pilot-ympäristön 1. prototyypissä
Pilotin ensimmäisessä prototyypissä mallinnettavat tiedot jäsennetään Eclipseen projekteiksi.
Kuhunkin projektiin sisällytetään siihen liittyvät resurssit. Projektien välille voidaan tarpeen
vaatiessa myös luoda riippuvuuksia, esimerkiksi useissa projekteissa tarvittavien työvälineiden
käsitteellistämiseksi. Yksittäinen projekti jaetaan edelleen käsitteellisesti useaan osa-alueeseen.
Näitä osa-alueita ovat aktiviteetit (activities), kirjastot (lib), tiedonkäsittelyputkilinjat (pipelineprocessing) sekä näitä prosesseja tukevat työvälineet (tools). Sekä osa-alueet, että niiden sisältämät
resurssit jäsennetään projektiin kansioina. Tällä tavoin tietoja voidaan mm. siirtää ja kopioida
helposti projektien välillä pelkän resurssienhallinnankin avulla.
Aktiviteetit ovat projektiin liittyviä prosessin osia. Kussakin aktiviteetissa toteutetaan jokin
yksittäinen osa koko prosessia. Esimerkiksi hydrauliikan tai simulaation suunnittelu voidaan
jäsentää aktiviteeteiksi. Jokaiseen aktiviteettiin liittyy sekä tiedollisia vaatimuksia sekä erilaisia
resursseja.
Aktiviteettiin liittyvät tiedolliset vaatimukset (requirement) kuvaavat aktiviteetin edellyttämät
tiedotarpeet siihen tuotettavalta aineistolta. Esimerkiksi hydrauliikan suunnittelussa vaatimukseksi
voidaan kuvata, että hydraulikaavioissa kuvataan komponentteihin liittyvät tunnisteet ja
komponettien väliset yhteydet siten, että ne voidaan koneellisesti jäsentää kaaviosta.
Kuhunkin aktiviteettiin liittyviä resursseja voidaan tunnistaa ainakin kolme erilaista tyyppiä:
ulkoiset, generoidut ja käsin kuvatut resurssit. Aktiviteettiin liittyvät ulkoiset resurssit (external)
ovat perusjärjestelmien, kuten Vertex HD, käyttämiä resursseja. Pilot-ympäristö ei tue näiden
resurssien muokkaamista, vaan ne työstetään ympäristöstä ulkoisissa perusjärjestelmissä.
Generoidut resurssit (generated) ovat aineistoista automaattisesti tuotettuja, generoituja resursseja.
Generointi on voitu tehdä joko perusjärjestelmien tuontitoiminnolla tai pilot-ympäristön tarjoamilla
työvälineillä. Jos jonkin osa-alueen tuottaminen ei generointiprosessin avulla ole mahdollista tai
kannattavaa, voidaan lisäksi hyödyntää käsin kuvattuja resursseja (mappings). Käsin kuvatut
| Semogen-väliraportti, joulukuu 2010 | 33 (44)
resurssit sisältävät täydennettyä tietoa mallista niiltä osin kuin tietoa ei ole muualta saatavissa.
Nämä resurssit voidaan tuottaa esimerkiksi pilot-ympäristössä sen tarjoamien editorien avulla.
Esimerkiksi hydraulikaavioon voidaan käsin kuvatuilla resursseilla täydentää tietoa siihen liitettyjen
komponenttien ominaisuuksista, esim. simuloinnin tarpeisiin.
Kirjastot (lib) täydentävät aktiviteetteihin liittyviä projektin resursseja. Kirjastoon voidaan
sisällyttää aktiviteettien tavoin ulkoisista järjestelmistä tuotuja ja käsin kuvattua. Ajatuksena on, että
kirjastoidut resurssit ovat käytettävissä useissa eri aktiviteeteissa - ts. kirjastoidut resurssit ovat
projektin sisällä uudelleenkäytettäviä. Esimerkiksi komponenttitoimittajalta saatavat tarkat
spesifikaatiot komponentin hydrauliikka ja simulointimallista voidaan liittää kirjastoon, jolloin
niihin voidaan viitata sekä hydrauliikan että simuloinnin suunnitteluaktiviteeteista. Kirjastointia
voidaan hyödyntää myös tiedon jakamiseen useiden projektien välillä määrittelemällä projekteille
näiden välinen riippuvuus.
Generointiprosessit (pipeline-processing) kuvaavat prosessikohtaisesti vaiheittain ne toimenpiteet,
jotka kyseiseen generointiin liittyvät. Vaihekuvaukset sisältävät mm. tiedon siitä, mitkä syötetiedot
kuhunkin vaiheeseen liittyvät, mitä työvälineitä (tools) tarvitaan vaiheen suorittamiseen sekä minne
vaiheeseen liittyvät tulostiedot sijoitetaan. Syötetietojen tarkistus voidaan suorittaa vaihekohtaisesti,
jos siihen liittyvät tiedolliset vaatimukset on kuvattu.
Pilot-ympäristön ensimmäisessä prototyypissä generointiprosessi toteutetaan käyttämällä Eclipseen
saatavia perustyövälineitä. Generointiprosessin vaiheistus kuvataan Apache Ant -työvälineellä
(http://ant.apache.org/). Apache Ant on pääasiassa tarkoitettu ohjelmistojen automaattisen
kokoonpanon hallintaan, mutta soveltuu hyvin myös prosessien kuvaukseen. Erityisestikin Ant
mahdollistaa prosessin vaiheittaisen kuvauksen helposti käsiteltävässä XML-muodossa (vrt.
Bailliez et al., 2010). Sen avulla voidaan myös joustavasti yhdistellä eri toteutustekniikoin
toteutettuja työvälineitä. Eclipse-ympäristö tarjoaa lisäksi Antin käyttöön graafisen käyttöliittymän
mm. generointiprosessien ajamiseen ja parametrisointiin.
Ympäristön ensimmäisessä prototyypissä on keskitytty ensimmäisten aineistojen generointiin ja
yksittäisten prosessiaskelten toteuttamiseen. Alustavasti ympäristöön on toteutettu työvälineitä,
jotka mahdollistavat hydraulikaavioiden generointia, järjestelmän hydraulimallin jäsennystä sekä
simulointimallin generointia. Tapaustutkimusta näiden työvälineiden ja prosessien osalta on
tarkemmin kuvattu aliluvuissa 3.7 ja 3.8.
Ympäristön ensimmäisen prototyypin perusteella näyttäisi siltä, että jos lähtökohtana on tietojen
haku ja jäsentäminen perusjärjestelmistä, on toimenpiteiden jako yksikäsitteisiin aktiviteetteihin
tärkeää. Aktiviteeteittain voidaan edelleen jäsentää tietoa perusjärjestelmistä omiksi
osakokonaisuuksiksi (esim. hydraulimalli). Perusjärjestelmistä tuotavan tiedon yhdistely on selvästi
oma osa-alueensa. Jotta tiedot saadaan yhdisteltyä semanttisen mallin tasolla, tarvitaan prosessiin
useita väliaskeleita. Esimerkiksi hydraulikaavioista ja 3D-malleista saatavan tiedon yhdistelyyn
tarvitaan ainakin yksi askel, joka yhdistelee eri kaavioihin liittyvät tunnisteet. Vastaavasti myös
yksittäisten hydraulikaavioiden yhdistely järjestelmän hydrauliikan kokonaismalliksi vaatii oman
askeleensa.
Alkuvaiheen selvityksessä otettiin sovellusesimerkiksi
generointi. Tämä käyttötapaus on ympäristön kannalta
huomata, että semanttisen mallinnuksen kannalta
kuvaaminen on kompleksisempaa, kuin yksittäisten
M1-järjestelmään soveltuvan aineiston
edelleen oleellinen. On kuitenkin syytä
monoliittisen järjestelmäkonfiguraation
toimialuemallien (esim. hydrauliikka)
| Semogen-väliraportti, joulukuu 2010 | 34 (44)
kuvaaminen. Ympäristön kehittämisen kannalta näiden yksittäisten mallien kuvaaminen ja
esittäminen ovatkin tärkeitä ja helpommin saavutettavia käyttötapauksia.
3.7. Simulointimalliaihiot
3.7.1. Aihioiden yhdistämiseen ja parametrisointiin vaadittavat tiedot
Hydraulijärjestelmän simulointimallin valmistaminen tai generointi on monimutkainen prosessi. Se
vaatii paljon lähtötietoja, jota usein on vaikea löytää.
Perustiedot mallin valmistamiseksi ovat:




Simulointikieli
Simulointiasetukset
Hydraulijärjestelmän konfiguraatio
Komponenttien parametrit
Simulointimalli tarvitsee myös yhdistää muihin järjestelmiin visualisoinnin ja hallittavuuden
mahdollistamiseksi. Lisäksi Simulointimallien generointi aihioista tarvitsee lisäksi seuraavat tiedot:



Tietoliikenneyhteydet muuhun järjestelmään
Aihioiden mahdolliset parametrit
Aihioiden porttitiedot yhdistämistä varten
Perinteisesti järjestelmän rakenne ja järjestelmään kuuluvat komponentit selviää hydraulikaaviosta.
Kaavio pitää tallentaa siten, että komponenttien väliset yhteydet tallentuvat helposti luettavaan
tiedostomuotoon. Komponenttien parametreja ei ole näin helposti saatavilla. Lisäksi tarvittavien
parametrien määrä riippuu toteutettavan simulointimallin ja simulointimalliaihioiden tarkkuudesta.
Siksi myös kirjastoitujen simulointimalliaihioiden perustiedot pitää olla tallennettuna koneen
ymmärtämässä muodossa. Simulointimalliaihion tarvitsemat parametritiedot pitää konejärjestelmän
hydrauli-insinöörin tallenttaa tai ne pitää löytyä komponenttivalmistajan komponentista antamista
tiedoista.
Myös CAN-järjestelmän simulointimallin generointiin liittyvät samat haasteet. CAN-solmuista on
tehtävä ensimmäiseksi simulointimalliaihiot, jotka pitää generointi vaiheessa parametrisoida ja
liittää toisiinsa. Hydraulijärjestelmistä on mahdollista löytää paljon valmiita simulointimalleja,
mutta CAN-järjestelmien lisähaasteena on valmiiden simulointimallien puute.
3.7.2. Simulink-aihiot ja generoinnin haasteita
Simulointimalliaihiot on toteutettu Simulinkillä (Kuva 3.7.1). Simulinkillä on mallinnettu aluksi
toimiva malli komponentista, jonka parametrit on parametrisoitu. Malli on tämän jälkeen tallennettu
normaalisti mdl-tiedostona. Tämän jälkeen mdl-tiedosto on avattu tekstinkäsittelyohjelmalla ja mdltiedostosta on poistettu simulointimallin otsikkotiedot. Tiedostoon jää näin ainoastaan kyseisen
komponentin tiedot ja tiedosto ei enää aukea Simulinkiin. Nämä vaiheet pitää toteuttaa kaikille eri
tyyppisille komponenteille. Lisäksi jokaisen simulointimalliaihion tiedot pitää kuvata xmltiedostoon, jotta tietokone pystyy ymmärtämään aihioiden sisällön. (Markkula, 2009)
| Semogen-väliraportti, joulukuu 2010 | 35 (44)
Kuva 3.7.1. Simulinkillä toteutettu simulointimalliaihio suuntaventtiilistä
Kuvan 3.7.1 suuntaventtiilin aihiosta pitää XML-kuvaukseen tallentaa porttien nimet ja numerot,
ohjaussignaalit, vikasignaalit, visualisointisignaalit ja tarvittavat parametrit. Kuvauksen perusteella
tietokone pystyy ymmärtämään aihiossa olevat ominaisuudet ja liittämään sen järjestelmän
simulointimalliin oikein. (Markkula, 2009)
Toteutusteknologiaksi aihioille valittiin Simulink, koska Matlab/Simulink on rikas kieli
simulointimallien toteuttamiseen. Lisäksi kokemus Simulinkin käytössä nopeutti ratkaisujen
löytämistä. Vaikka mdl-tiedostomuodon syntaksi on selkeä ja helppo, generointia ajatellen mdltiedostomuoto ei kuitenkaan ole hyvä. MDL-tiedoston jäsennystä varten pitää kehittää erityinen
työkalu ja jokainen poikkeus pitää ratkaista erillisellä ohjelmointikoodilla. Simulinkiä vastaavat
ilmaiset ScicosLab ja OpenModelica ovat tässä mielessä parempia. ScicosLab käyttää uusimmissa
versioissa XML-tiedostomuotoa simulointimallien tallentamiseen. Samoin OpenModelicalla on
mahdollista tallentaa tiedostot XML-pohjaisessa formaatissa. OpenModelican kaupalliseen versioon
Modelicaan on myös kehitetty ModelicaXML esitys. Kyseisten XML-tiedostomuotojen generointi
on huomattavasti jouhevampaa verrattuna MDL-tiedoston jäsentämiseen. Heikkoutena
ScicosLabissa on huono tuki reaaliaikasimuloinnille ja valmiiden simulointimallilohkojen puute.
Järjestelmä on kuitenkin siinä määrin lupaava, että sen käyttöä erityisesti hydromekaanisten
järjestelmien mallintamiseen on jatkossa syytä tutkia enemmän. OpenModelica ja Modelica
sisältävät ScicosLabiin verrattuna enemmän valmiita kirjastoja myös hydrauliikasta ja kiinteistä
kappaleista, joten sen soveltuvuus generointiin on jo nyt hyvä.
3.7.3. Mallinnetut komponentit
Nostotoiminto -casea varten mallinnettiin seuraavat hydraulikomponentit: pumppu,
paineenrajoitusventtiili, suuntaventtiili, sylinteri ja suodatin. Simulinkillä mallinnettujen
komponenttien tiedostot (mdl) avattiin tekstin käsittelyohjelmalla, jossa tiedostoista poistettiin
Simulinkin tekemät otsikkokentät. Ilman otsikkokenttiä tiedostoja ei enää voida avata Simulinkissä,
mutta generointi onnistuu helpommin. Yksinkertaisemmillaan generoinnissa vain luodaan uusi
Simulink-tiedosto (mdl), johon kirjoitetaan otsikkokentät ja sen perään kirjoitetaan (kopioidaan)
tarvittavien komponenttien simulointimalliaihiot. Aihiot täytyy tämän jälkeen vielä yhdistää ja
parametrisoida. Näitä haasteita käsitellään tarkemmin seuraavassa luvussa.
3.8. Case: nostotoiminto
3.8.1. Tavoite
Tässä aliluvussa esittelemme mallinnettavan järjestelmän puomin nostotoimintoon liittyvää
semanttisen
mallinnuksen
tapaustutkimusta.
Tavoitteena
on
käyttää
hyödyksi
hydrauliikkasuunnittelijan (hydrauli-insinööri) tuottamaa suunnittelumateriaalia. Ongelmana on
suunnittelumateriaalin epämääräisyys ja tiedon repaleisuus. Tietoa on tallennettu useisiin
| Semogen-väliraportti, joulukuu 2010 | 36 (44)
formaatteihin ja tietoja ei ole käytännössä linkitetty toisiinsa. Tästä johtuen pitää määritellä
uudestaan miten esimerkiksi hydraulikaavio piirretään, jotta tiedot olisivat käyttökelpoisia
simulointimallien generointiin. Simulointimallien generoinnilla ei tässä yhteydessä tarkoiteta
simulointimallien toteuttamista tyhjästä vaan käyttäen apuna aiemmin luotuja aihioita. Valmiiksi
kirjastoidut aihiot voidaan parametrisoida suunnittelu aineistossa olevan järjestelmätietojen
perusteella.
Esimerkkinä tietojen tuonnista perusjärjestelmistä ja tuodun tiedon käytöstä, tarkastelemme
kohdejärjestelmässä puomin nostotoimintaa kuvaavan hydraulikaavion sisältämän tiedon tuontia
Vertex HD-järjestelmästä. Luvussa 3.2 on esitetty Vertex HD:n mahdollisuudet esittää ja välittää
piirustuksiin tallennettua tietoa. Esimerkki tapauksena käytetään kuvassa 3.2.2 olevaa
hydraulikaaviota. Hydraulikaaviota suunniteltaessa ei ole ainoastaan keskitytty kaavion käyttöön
järjestelmän valmistamiseen. Kaaviota piirrettäessä on mietitty myös tiedon jatkokäyttö muihin
tarkoituksiin.
3.8.2. Tietojen tuonti perusjärjestelmästä RDF-kuvaukseen
Kaikki kaavion (Kuva 3.2.2) komponentit on fyysisesti kiinnitetty toisiinsa hydraulisilla
tilavuuksilla eli putkilla. Komponenttien symboleille on annettu yleisiä attribuutteja parametritiedon
välittämiseksi ja linkittämiseksi. Lisäksi komponenttien ulkoiset kytkennät on identifioitu ja
nimetty. Tämä mahdollistaa simulointimallien ulkoisten järjestelmien, kuten komponenttien
ohjauksen, vikasignaalien ja visualisointien, linkittämisen.
Luvussa 3.2 kuvatusta Vertex HD:n SVG-vientirajapinnasta saatavasta tiedostosta informaatio on
kerättävä talteen ja muunnettava RDF-muotoon. Tätä tarkoitusta varten toteutettiin erillinen
muunnoskomponentti SVG2RDF. Tämä XSL-muunnoksella toteutettu komponentti suodattaa ja
uudelleenjärjestelee SVG-formaattiin tuotuja tietoja siten, että tuloksena syntyy kanoninen
RDF/XML-dokumentti (ks. listaus 3.8.1).
Listaus 3.8.1. Esimerkki hydraulikaaviosta tuotetusta RDF/cXML-tiedostosta
| Semogen-väliraportti, joulukuu 2010 | 37 (44)
Vaikka muunnoksen tekeminen teknisesti onnistuu XSL-muunnoksella, RDF-metatietojen
kerääminen SVG:stä ei ole käsitteellisesti triviaali operaatio. Ensinnäkin RDF:n käyttöä varten on
määriteltävä tai valittava käytettävät käsitteet tuotavien tietojen kuvaamiseen. Muunnokseen liittyy
myös käytännöllisempiä ongelmia. Erityisesti vientiformaatin tapauksessa RDF asettaa erityisesti
yksilöivien tunnisteiden nimille vaatimuksia. Pohjana käytettävien käsitteiden valinnassa käytettiin
käsitemallien
kartoituksen
yhteydessä
tehtyä
SKOS-pohjaa
(nimiavaruus
http://www.tut.fi/projects/semogen/hydraulics#). SVG-vientirajapinnasta saatavat tiedot
kuvattiin kolmeen RDF-käsitteeseen:



Hydraulikomponenttien esiintymät (hydraulics#component)
Putket (hydraulics#pipe)
Portit eli komponenttien liittymäkohdat putkille (hydraulics#port)
Jotta yhteydet näiden käsitteiden esiintymien välille saataisiin kuvattua, täytyi käsitemallia rikastaa
edelleen muutamilla käsitteilä:


Viittaukset putken tulo- ja meno-liityntöihin, eli portteihin tai toisiin putkiin
(hydraulics#connectedFrom, hydraulics#connectedTo)
Viittaus komponentista sen sisältämään porttiin (hydraulics#hasPort) ja sen
käänteisviittaus (hydraulics#partOf)
Lisäksi muunnos toteutettiin mallintamaan lähdeaineistoon merkityt komponenttien kuvailevat
otsikkotiedot Dublin Core:n title-arvoina (dc:title).
Käytännöllinen haaste muunnoksen toteutuksessa oli tunnisteiden generointi mallin eri osille.
Lähtökohtaisesti RDF:ssä kaikki resurssit nimetään globaalisti yksikäsitteisten tunnisteiden eli
URI:ien (Uniform Resource Identifier) avulla. Vientirajapinnasta saatavat tunnisteet ovat kuitenkin
yksilöityjä ainoastaan kaavion tasolla: kaavioiden välillä tunnisteet eivät siis ole sellaisenaan
yhdisteltävissä.
Ratkaisuna yksilöinnin ongelmaan kaaviossa esiintyneet tunnisteet koodattiin RDF:n ns. tyhjinä
solmuina (engl. blank nodes). RDF määrittelee tyhjät solmut yksilöllisiksi tunnisteiksi, joilla ei
kuitenkaan ole URI-viittausta. Tyhjien solmujen tunnisteet ovat yksikäsitteisiä ainoastaan
paikallisesti, ja RDF-jäsentimet osaavat yhdistellä tällaisia malleja ilman, että päällekkäisyyksiä
syntyy. Käytännössä tämä yhdistely on toteutettu siten, että päällekkäisille tyhjien solmujen
tunnisteille generoidaan aina uudet yksikäsitteiset tunnisteet. On syytä huomata, että käyttämällä
tyhjiä solmuja ei ratkaista komponenttien globaalin yksikäsitteisen tunnisteen puutetta. Se kuitenkin
mahdollistaa RDF-jäsennyksen luomisen, ja tunnisteeseen liittyvä ongelma voidaan ainakin aluksi
ratkaista sovelluskohtaisesti.
3.8.3. Simulointimallien generointi aihioista RDF-kuvauksen perusteella
Seuraavana vaiheena simulaation generoinnissa on hydraulikaaviosta saatavien kuvailutietojen
yhdistely simulointimallien aihioihin.
Komponentteihin liittyvät aihiot on taltioitu tiedostoihin ja kirjastoitu komponenttien tunnisteiden
perusteella. Jotta aihiot voidaan liittää kaaviossa tunnistettuihin komponentteihin, liitetään kuhunkin
simulointikomponentin aihioon RDF-kuvailutietoja. Käytännössä kuvailutiedot jäsennetään yhteen
XML-tiedostoon per komponentti (ks. listaus 3.8.2). Käyttämällä RDF-yhdistelijäkomponenttia
(engl. aggregator) nämä RDF-tiedostot yhdistetään toisiinsa, jolloin aihioihin liittyvät kuvailutiedot
| Semogen-väliraportti, joulukuu 2010 | 38 (44)
saadaan liittymään hydraulikaaviosta tuotuun malliin. Kuvailutietoihin voidaan liittää myös muita
simulointimallin tietoja, kuten simulointiparametreja.
Listaus 3.8.2. Esimerkki aihioon liittyvistä kuvailutiedoista
Teknisesti yhdistely vaatii useiden RDF-käsitteiden tuomista malleihin. RDF2SVG-muunnoksessa
kullekin komponentille määritellään sovelluskohtainen, globaali yksikäsitteinen tunniste
(semogen:hasIdentifier) osoittamaan komponentin tunnisteen Vertex HD -järjestelmän sisällä.
Vastaavasti simulointimallin aihion kuvailutietoihin liitetään sama tunniste, jolloin
sovelluskohtainen tunniste yhdistelee hydraulikomponentin siihen liittyvään aihioon. Lisäksi
sovelluskohtaisella mekanismilla aihion kuvailutietoihin merkataan viittaus aihion sisältämään
tiedostoon.
Kun kuvailutiedot ollaan RDF:n avulla yhdistelty viittauksin simulointimallien aihioihin, voidaan
simulointimallin generointi toteuttaa. Tällainen sovelluskohtainen mallin generointikomponentti
(MDL generator) toteutettiin viimeiseksi komponentiksi mallin generoivaan tiedonkäsittelyn
putkilinjaan. MDL-generaattori toteutettiin Python-kielen ja sen RDFLib 3 -kirjaston
(http://www.rdflib.net/) avulla. Generaattorin toiminnan perusidea on, että se hakee SPARQLkyselyjä hyödyntäen RDF-mallista komponentit sekä niihin liittyvät aihiot ja yhteydet muihin
komponentteihin. Toteutustekniikaksi generaattoriin valikoitu Python sekä tällä toteutettu RDFLib
3. Vaikka RDFLib 3 -kirjasto on edelleen kehitystilassa, sisältää se kaikki generaattorin
toteuttamiseen tarvittavat piirteet, erityisesti SPARQL-kyselymoottorin.
3.8.4. Tuotoksen lyhyt esittely, yleistettävyyden haasteita
Simulaatiomallin lopullinen tuotantoprosessi saatiin aikaan vielä yhdistelemällä osa-prosessit
kokonaiseksi generointiprosessiksi Apache Ant -kokoonpanokuvauksella. Tällä tavoin määriteltyä
generointiprosessia voidaan siten ajaa joko kokonaan tai vaiheittain mm. Eclipse-pohjaisessa pilotympäristössä.
Generointiprosessin lopputuloksena syntyy osittainen simulaatiomalli hydraulikaavioon piirretystä
järjestelmästä. Generointiprosessissa syntyvä simulointimalli ei ole vielä valmis, vaan sen
viimeistely on tehtävä Simulinkillä käsin. Erityisestikään aihioiden välisiä yhteydet eivät vielä
| Semogen-väliraportti, joulukuu 2010 | 39 (44)
generoidu lopputulokseen. Sekä lopputuloksena syntyvää simulaatiota sekä generaation eri
vaihetuotteita on havainnollistettu kuvassa 3.8.2.
Tuotoksen esittely
Kuva 3.8.2. Generointiprosessin tiedostot
Generointiprosessin voidaan katsoa toimivan esimerkkinä siitä, että simulointimallien generointi on
automatisoitavissa.
Se
osoittaa
myös
komponenttikirjaston
merkityksen
erilaisia
generointiprosesseja tarkastellessa. Koko järjestelmän semanttinen mallinnus on kattava, mutta
usein tarpeettoman kallis ja vaivalloinen toimenpide. Aihiopohjaisella lähestymistavalla voidaan
kenties saavuttaa tyydyttävämpi kompromissi komponentin semanttiselle ja sovelluskohtaiselle
mallinnukselle ja niihin käytettäville resursseille. Lisäksi toteutetun prosessin perusteella
simulaation generointia voidaan jatkokehittää. Se toimii myös referenssinä muihin lähdeaineistoihin
pohjautuvaan semanttisen tiedon tuottamiseen.
Haasteet
Haasteet generoinnissa on ratkaistavissa, mutta kaikkia ratkaisumalleja ei voi suoraan yleistää.
Suunnittelutiedon saatavuus ei yksistään ratkaise ongelmia generointiprosessissa. Prosessi on
edelleen formaatti riippuvainen ja ihmisen työtä tarvitaan edelleen.
| Semogen-väliraportti, joulukuu 2010 | 40 (44)
Tietojen tuominen perusjärjestelmistä ja simulointimallin generointi vaativat erityisesti kyseisiin
tiedostomuotoihin ohjelmoituja ohjelmia. Samalla ohjelmalla ei voida lukea tietoja Vertex HD ja
Visio dokumenteista, koska tiedostomuodot eroavat paljon toisistaan. Vastaavasta syystä sama
ohjelma ei voi generoida Simulink ja ScicosLab simulointimalleja. Helpotusta ongelmaan tuo RDFvälitiedosto, johon tiedot kerätään ja jonka perusteella simulointimalli generoidaan. Näin ainoastaan
tiedon keruu ja simulointimallin kirjoittaminen ovat formaatti riippuvaisia ja uudelleen
ohjelmoitavia prosessin osia.
Toinen haaste on simulointimalliaihioiden saatavuus. Simulinkillä tuotetut aihiot vaativat Matlablisenssin ja ovat tästä syystä huonosti soveltuvia tähän tarkoitukseen. Sopivia ja vapaasti saatavia
olevia aihioita ei suoraan ole vielä saavilla. Ilmaiset simulointiohjelmat ScicosLab
(http://www.scicoslab.org/) ja OpenModelica (http://www.openmodelica.org/) ovat jo nyt
kehittyneitä ja tulevat monipuolistumaan tulevaisuudessa. Erityisesti OpenModelica vaikuttaa
sopivalta
hydromekaanisten
järjestelmien
mallintamiseen
ja
voisi
olla
ratkaisu
simulointimalliaihioiden tuottamiseen vapaasti saatavilla olevalla simulointikielellä.
Jatkotavoitteet
Luonnollinen jatkotavoite generointityölle on viedä mahdollisimman pitkälle simulaatiomallin
generointi. Erityisesti aihioiden välisten yhteyksien automaattinen generointi olisi kokeilemisen
arvioinen idea. Myös ulkoisten rajapintojen (UDP) generointi malliin pystyttäisiin ainakin jossain
määrin generoimaan, mikä vähentäisi huomattavasti simulaatioympäristön tuottamiseen liittyvää
käsityötä. Simulink-malleihin liittyy kuitenkin perustavanlaatuisia haasteita. Näin ollen
vaihtoehtoisesti tai tämän työn rinnalla voisi olla syytä kuitenkin paneutua myös vaihtoehtoisten
simulointiympäristöjen tutkimukseen. Luonnollisesti myös generoidun simulointimallin
(reaaliaikainen) visualisointi olisi kiinnostava jatkokehityskohde kaikissa toimintamalleissa.
Simulointimallin lisäksi voitaisiin lähteä kehittämään myös dynaamisen hydraulikaavion
generointia. Ideaalitapauksessa tämä tarkoittaisi sitä, että yhdessä simulointiaihioiden kanssa
yhdestä hydraulikaavioista voitaisiin generoida sekä simulointi, että simulointia hyödyntävä
kaavion dynaaminen esitys.
Tehty työ tarjoaa hyvät puitteet myös muiden osa-alueiden yhdistelyyn. Jos esimerkiksi CANaineisto tuotettaisiin RDF-muotoon, voitaisiin sitä yhdistellä simuloinnin ja hydrauliikan malleihin.
Näin ollen myös yksinkertaisen CAN-simulointimallin generointia osaksi hydrauliikan simulointia
voitaisiin jatkokehittää. Myös 3D-aineisto voitaisiin RDF:n avulla yhdistellä näihin malleihin ja
siten toteuttaa myös 3D-malliin liittyvää dynamiikkaa.
4. Tiedotus ja kaupallistaminen
4.1. Tiedotus
Hankkeen tiedottamisessa korostuu konelaboratorioiden tuotantomenetelmien ja -mallien
mahdollisuuksien viestiminen. Hanke liittyy vahvasti digitaaliseen tuoteprosessin ja
koneenrakennuksen teemoihin. Näillä alueilla semanttisen mallinnus ja virtuaalinen konelaboratorio
ovat uusia avauksia, joten tiedotuksen merkitys korostuu. Ohjausryhmä on tunnistanut haasteeksi
semanttisen mallinnuksen käsitteen sekä erilaisille kohderyhmille viestimisen. Koneensuunnittelu
on suurella osalle kohderyhmiä tuttua, joten tätä tarttumapintaa kannattaa hyödyntää. Tämä on
| Semogen-väliraportti, joulukuu 2010 | 41 (44)
luontevaa, koska hankkeessa kuvattu semanttinen prosessi tukeutuu rikkaasti kuvailtuun
suunnitteluaineistoon sekä selkeästi eteneviin vaiheisiin.
Hankkeeseen laadittiin tiedotussuunnitelma (Semogen –ohjausryhmän kokous 29.9.2010).
Tiedotuksen avulla pyritään tavoittamaan keskeisiä toimijoita ja sidosryhmiä, jotta
konelaboratorioiden hyödyntämiseen löytyy kriittinen massa.
Tiedotustavoitteet:
-Viestiä sidosryhmille virtuaalisten konelaboratorioiden mahdollisuuksista sekä
herättää laajempi kiinnostus näiden mahdollisuuksiin.
-Muodostaa kriittinen massa virtuaalisten konelaboratorioiden hyödyntäjistä.
-Korostaa uutta avausta konejärjestelmien suunnitteluprosessien kehittämiseen
virtualisoinnin ja digitaalisen tuoteprosessin avulla.
-Tuotantomenetelmien kehitys on edellytyksenä laajempaan ja kustannustehokkaaseen
levitykseen.
-Tukea rahoittajan tahtotilaa innovaation kaupallistamiseen sekä levitykseen.
-Tukea II vaiheen rahoitushakua sekä innovaation jatkokehittämistä.
Tiedotuksen keskeisinä kohderyhminä ovat koneenrakennussuunnittelijat ja -johtajat,
koulutusorganisaatioiden johto, rahoittajat ja yritysosapuolet. Hankkeesta tiedotetaan
tarkoituksenmukaisissa tiedotusvälineissä. Tarkempi kuvaus tiedotussuunnitelmassa (2010/9
ohjausryhmän kokouspöytäkirja). Tiedotussuunnitelma on kuvattu tarkemmin hankkeen
tiedotussuunnitelmassa.
Tutkimushankkeessa tieteelliset julkaisut toimivat keskeisenä foorumina ulospäin. Hankkeeseen
laadittiin julkaisusuunnitelma (Semogen –ohjausryhmän kokous 29.9.2010). Julkaisunäkökulmina
toimivat informaation prosessointi, suunnitteluprosessien ohjeistus, koneenrakennuksen
suunnitteluaineistojen hyödyntäminen, simulointimallien generointi, pilot –järjestelmä,
tuotantomenetelmien implementointi sekä tiedon visualisoinnit. Julkaisukanavina toimivat sekä
informaation prosessoinnin, mallinnuksen että koneenrakennuksen arvostetut ja referee -arvioitavat
kansainväliset tieteelliset lehdet, konferenssipaperit sekä konferenssiesitelmät. Tarkempi kuvaus
julkaisusuunnitelmassa (2010/9 ohjausryhmän kokouspöytäkirja).
Hankeessa toteutetut tiedotustoimenpiteet:
- Tiedotussuunnitelma
- Hankkeen kotisivu ja kuvaus
- Yritysneuvottelut
- Työpajatoiminta konsortion yritystoimijoiden kanssa
- Hankesuunnitelma ja sen viestiminen rahoittajalle
| Semogen-väliraportti, joulukuu 2010 | 42 (44)
- Vertex Systems Oy:n asiakaspäivät 1.9.2010
- Sandvik Mining and Construction Oy useita konelaboratorioesittelyjä
- Rahoittajan tapaamisen valmistelu
Tiedotustoimintaa on toteutettu niukasti, koska hankkeen tutkimustoimenpiteet ovat edellyttäneet
ryhmältä panostusta. Ohjausryhmä (ohjausryhmän pöytäkirja 2010/3/17.) on linjannut
kokouksessaan: "Hankkeelle pyritään saamaan tiedotusvälineisiin näkyvyyttä. Julkisuusperiaatteena
toimii, että yleistiedot ovat julkisia, mutta aineistot, tulokset, tarkat toimenpiteet ovat
luottamuksellisia."
Tiedotusvälineissä ei ole ollut vielä yhtään esitystä. Tiedotustoiminta aktivoituu kevätkaudella
2011.
4.2. Kaupallistaminen
Hankkeen kaupallistamistyöpaketti on suunniteltu käynnistyvän vuoden 2011 alussa, joten
konkreettisista toimenpiteistä ja tuloksista ei ole raportoitavaa.
Ohjausryhmä päättää 21.12.2010 kokouksessaan kaupallistamistoimenpiteiden tarkennuksen.
5. Yhteenveto
Tehdyn tutkimustyön pohjalta voidaan jo tutkimuksen tässä vaiheessa nostaa esille useita
mielenkiintoisia havaintoja. Erityisesti, lähdeaineiston laatuvaatimukset ja teknisen aineiston
kattavuus nousevat generoinnin näkökulmasta melko konkreettisesti esille. Käytännön
sovelluksissa, teknisen suunnittelutiedon käyttötapausten tulee olla tarkkaan määriteltyä paitsi
informaatiorajapintojen,
myös
työprosessin
vastuiden
osalta.
Toisaalta
erilaisten
suunnittelukäytäntöjen kirjavuus aiheuttaa haasteita ruohonjuuritason koordinoinnille. Oman
haasteena muodostavat lisäksi toteutustyön tekniset menetelmät ja erityisesti perusjärjestelmien
export-toiminnallisuus.
Nyt alustavasti raportoidun tapaustutkimuksen motiivina oli kokeilla semanttiseen prosessiin ja
erityisesti generointitapaukseen liittyviä haasteita käytännössä. Nyt ensimmäisessä vaiheessa työtä
tehtiin siis aineiston varassa, jota ei alun perin oltu tuotettu semanttisen prosessin tarpeet silmällä
pitäen. Aineistorajauksen mukaisesti, tarkastelun kohteena oli ns. puomin nosto –käyttötapaus.
Käytännössä osoittautui, että rakenteisuuden, viitattavuuden ja semanttisen yhdistelyn tarpeet
edellyttivät
lähdeaineiston
merkittävää
rikastamista
ja
kuvailemista
semanttisen
suunnitteluprosessin käsitteiden suhteen. Tutkimustyötä rikastamisen teknisten prosessien ja
ohjeiden osalta selvästikin tarvitaan vielä. Tässä tapaustutkimuksella on tärkeä rooli, sillä se
mahdollistaa tutkimuskysymysten hedelmällisen tarkentamisen teoreettisen ja konkreettisen
empiirisen viitekehyksen tukena.
On kuitenkin merkillepantavaa, että kun semanttisen rikastamisen ja integroinnin kriittinen vaihe
ylitetään (kuten esim. tämän tapaustutkimuksen generointiesimerkissä), tarjoaa semanttisesti
rikastettu aineisto varsin hyvän lähtökohdan erityyppiseen tietotekniseen sovelluskehitykseen, myös
varsinaisen generointitapauksen lisäksi. Jo tässä vaiheessa tuntuu siten luonnolliselta olettaa, että
| Semogen-väliraportti, joulukuu 2010 | 43 (44)
rikastamisen kustannusten ja siitä suoraan ja epäsuoraan saatavien kustannusten arviointi nousee
keskeiseen rooliin semanttisen prosessin käytännöllisissä sovelluksissa. Semogen-hankkeen
näkökulmasta tämä on mielenkiintoista myös tutkimusprojektin II-vaiheen tutkimuskysymysten
täsmentämisen osalta (esim. mittarit annetun lähdeaineiston analysointiin).
Lopuksi, vaikka kaikki tässä raportissa esiintyvät tekniset yksityiskohdat ovat tietenkin tärkeitä
(useimmat jopa välttämättömiä), on jo tässä vaiheessa hyvä yrittää nähdä metsä puilta: Tutkimuksen
tarjoamaa perustaa vasten suhteutettuna vaikuttaa melko ilmeiseltä, että sovellusprojektin tasolla
erään tärkeimmistä ongelmakentän ratkaisun avaimista muodostaa kompleksisuuden hallinta, niin
projekti-informaation/välineiden kuin projektihenkilöstönkin osalta. Näistä osa-alueista
ensimmäinen liittyy sovelluksen tausta-aineistoon, tavoitteisiin, työstettävään informaatiosisältöön,
välineisiin ja tuotoksiin, toinen puolestaan vastuiden, tehtävien ja roolien hallintaan.
Pienen projektiryhmän näkökulmasta melko intuitiivinen kiteytys on huomio "teknisen tietämyksen
pääsuunnittelijan" (knowledge engineer) roolin tarpeellisuudesta: Käytännön työssä tarvitaan
riittävän ammattitaidon ja projektivastuun omaavaa henkilöä, joka pitää informaation rakenteen,
laadun ja rajapintojen langat tiukasti käsissään, muita (rooleja) tarvittaessa ohjeistaen. Käytännön
projektikulttuuri huomioiden, tämä voi tarkoittaa/vaatia joko lisäresurssia pääsuunnittelijan tai
tapauskohtaisesti mekaniikkasuunnittelijan (tms.) roolille, tai kokonaan uuden henkilöresurssin
esittelyä suunnitteluprosessin osaksi.
Suunnitteluaineistolähtöinen virtuaalisen konelaboratorion tuotantomenetelmien kehitys edellyttää
suunnitteluaineiston semanttista rikastamista, yhteensopivuutta ja vaiheistettuja prosesseja sekä
metasuunnitteluprosessien ohjeistuksia. Yhteenvetona voidaan todeta, että tapaustututkimuksen
tulokset osoittavat merkittäviä kehitysmahdollisuuksia tuotantomenetelmiin. Tämä jäsentää
toimenpiteiden suuntaamista ja syventämistä.
Lähteet
Bailliez, S. et al. (2010). Apache Ant User Manual. [online]. Saatavilla:
http://ant.apache.org/manual/index.html
Beckett, D. (2004). RDF/XML Syntax Specification (revised). W3C-suositus. Saatavilla:
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
Carroll, J. J., Klyne, G. (2004). Resource Description Framework (RDF): Concepts and Abstract
Syntax. W3C-suositus. Saatavilla: http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
CANopen. (2000). Profile Database Specification for CANopen. Appendix to CiA Draft Standard
306. Revision 0.3. 15 May 2000. CAN in Automation (CiA) e.V.
CANopen. (2005). Electronic data sheet specification for CANopen. CiA Draft Standard 306.
Version 1.3. 01 January 2005. CAN in Automation (CiA) e.V.
CANopen. (2007). CANopen device description - XML schema definition. CiA Draft Standard
Proposal 311. Version 1.0. 8 March 2007. CAN in Automation (CiA) e.V.
| Semogen-väliraportti, joulukuu 2010 | 44 (44)
Clark, J. (2001). XSL Transformations (XSLT) Version 1.1. W3C Working Draft. Saatavilla:
http://www.w3.org/TR/2001/WD-xslt11-20010824/
Guha, R. V., Brickley, D. (2004). RDF Vocabulary Description Language 1.0: RDF Schema. W3Csuositus. Saatavilla: http://www.w3.org/TR/2004/REC-rdf-schema-20040210/
Hoppe, H., et al. (1993). Mesh optimization. SIGGRAPH '93 Proceedings of the 20th annual
conference on Computer graphics and interactive techniques.
Kay, M. (2009). XSL Transformations (XSLT) Version 2.0 (Second Edition). W3C Proposed
Edited Recommendation. Saatavilla: http://www.w3.org/TR/2009/PER-xslt20-20090421/
Markkula M. (2009). Hydraulisten ja mekaanisten järjestelmien simulointimallien automaattinen
generointi. Diplomityö. Tampere, Finland.
Nykänen, O. (2010). Semogen Semantic Process: Data Processing Aspect. Semogen project
technical document.
Nykänen, O. (2010b). RDF/cXML - A Canonical XML Serialisation Syntax for RDF. Semogen
project document. Internal working draft, Version 2010-10-28.
Schreiber, G., Dean. M. (2004). OWL Web Ontology Language Reference. W3C-suositus:
Saatavilla: http://www.w3.org/TR/2004/REC-owl-ref-20040210/
Ranta, P., Alarotu, V., Helminen, M., Koskinen, K. T., Markkula, M., Nykänen, O., Palonen, T.,
Punki, J., Rokala, M., Salonen, S. (2010). Selvitysraportti. Semogen-hanke.
Saha, H. (2008). CANdictionary: Keywords, Standards, Technical Terms. Finnish edition, May
2008. CAN in Automation e. V.
Springgay, D. (2001). Creating an Eclipse View. [online]. Saatavilla:
http://www.eclipse.org/articles/viewArticle/ViewArticle2.html
The Mathworks Inc. (2010). Simulink Basics. R2010b MathWorks Documentation. [online].
Saatavilla: http://www.mathworks.de/help/toolbox/simulink/ug/f2-14248.html
Wikia. (2010). Foster Hydraulics Wiki. Saatavilla: http://hydraulics.wikia.com/wiki/Main_Page
LIITE A
•
•
•
•
•
Suunnitteluprosessikuvaus
Järjestelmäsuunnittelija
Hydrauliikkasuunnittelija
Sähkösuunnittelija
Mekaniikkasuunnittelija
Automaatiosuunnittelija
Tuotetiedon hallinnoija
Tavoitteena on kuvata suunnittelijoiden suunnitteluprosessi ja vuorovaikutukset siten, että semanttinen mallinnus on mahdollista siihen integroida
Prosessikuvauksia hyödynnetään monilla eri toimialoilla, tämä pohja on ehdotus.
Roolit:
–
–
–
–
–
–
Yksi rooli ja yksi prosessiteema kerrallaan
Rooliin kiinnitetään myös vuorovaikutukset muilta suunnittelijoilta
Ajallinen eteneminen
Kiinnitys suunnitteludokumentteihin
Prosessit kuvataan prosessikuvausmallia hyödyntäen. ‐
‐
‐
‐
Prosessikuvauksia arvioidaan jalostetaan yhteisesti Semogen –hankkeessa.
LIITE A
PS
MS
HS
AS
SS
TS
Projektin resurssi‐ ja aikatauluarvio. Kustannussuunnitelma
Esisuunnittelu tarjousvaiheen tukena
Asiakkaan vaatimusmäärittely. Vaatimusmäärittelyn pilkkominen toteutuksen kannalta oleellisiin osiin.
Mekaniikka
Hydrauliikka
Automaatio
Sähkö
Tuotetieto
Tarjoussuunnittelu:
‐ Alustava suunnittelu resurssien tarpeen ja aikataulun arvioimiseksi: Luonnokset tarvittavista järjestelmistä(hydrauliikka, sähkö, automaatio), Luonnokset mekaniikasta. ‐Suunnittelulähtökohtien selvitys asiakkaan vaatimusmäärittelyn perusteella (Lähtötietolomake (dokumentti)): Toimintaympäristö, olemassa olevien laitteiden hyödynnettävyys. Saatavilla olevat tarkat yksityiskohtaiset tiedot. Suunnitteluun vaikuttavat standardit. Vaaditut toiminnallisuudet. Laitteen ulkoisten mittojen vaatimukset. Konseptisuunnittelu tuotekehitysprojektissa. Suunnittelijoiden hiljainen tieto. ERP:stä
aiempien vastaavien suunnitteluprosessien tiedot (kustannukset, toteutuneet aikataulut)
Pääsuunnittelija/ Projektipäällikkö
LIITE A
Teknologiavalinnat
Kokonaisuuden hallinta
Perussuunnittelu
Järjestelmän arkkitehtuuri
Laitteen mekaniikan perussuunnittelu: Toimintojen mekaaninen toteutus, laitteiden sijoittelu, komponenttien valinnat ja tilavaraukset, lähtötiedot muille suunnittelijoille, tekninen laskenta (alku), massat, taipumat, ominaistaajuudet, koneen turvajärjestelmät
PS
MS
Laitteen hydrauliikan perussuunnittelu: Lähtötiedot saadaan vaatimusmäärittelystä ja mekaniikka suunnittelusta. Toimilaitteiden , venttiilien , putkistojen, muiden komponenttien ja voimayksikön mitoitus ja vaatimukset (Ohjaussignaalit, tehon tarve)
Laitteen automaation perussuunnittelu: Liikkeet, anturoinnit, ohjaussignaalit. Ohjelmiston kehitys
Automaatio
Sähkö
Laitteen sähköjärjestelmien perussuunnittelu: Signaalin siirto (väylät), Sähköisten laitteiden mitoitus, suunnittelu ja valinta
Hydrauliikka
PDM‐ järjestelmän hallinnointi. Suunnittelijoilta saatavan tuote‐ ja suunnittelutiedon hallinta
Mekaniikka
Tuotetieto
HS
AS
SS
TS
Pääsuunnittelija/ Projektipäällikkö
LIITE A
Valmistus/tuotantosuunnittelu
MS
Hydraulijärjestelmän toimilaitteiden ja komponenttien osaluettelot
Yksityiskohtaiset valmistus‐, hitsaus‐ ja koonpanopiirustukset
Toimilaitteiden ja muiden komponenttien tiedot, putkitusohjeet
Käytettävät materiaalit ja aihiot, valmistustoleranssit ja ‐tarkkuudet
Kokonaisuuden hallinta
HS
Ohjelmistojen suunnittelu
PS
AS
Vetolista. Valmistusohje. Yksittäisen sähkökokoonpanon tarkempi kuvaus esim. sähkösolun kokoonpanoon. Kokoonpanon testaus ennen asennusta. Testausohje ja –raportti. Toimilaitteiden lopulliset toimintamitat, putkitusohjeet
SS
PDM:ään tuotettu rakenne on valmisteltu hankintaan ja tuontantoon. PDM:n rakennen lähetetään ERP‐ järjestelmään. PDM:n rakenne, jota tuotanto käyttää, on aina samanlainen. ERP‐ järjestelmään päivittyy tuotannon aikana lopullinen tuoterakenne. Päivittyy PDM:ään
Hydrauliikka
Sähkö
Tuotetieto
Rakenneohje sisältää tietyn laitteen kaaviot. Listaus kaavioista, päärakenteiden koodeista ja säätöarvot sähkökomponenteille. Esim. Moottorin suojakytkimen asetusarvo (mille virralle). Automaatio
Komponenttien hankinta, Valmistuksen sovitus muuhun tuotantoon, Valmistettavuuden varmistus
Mekaniikka
‐Hydraulikaavio tuotantoa varten ‐Symbolinen kaavio vianhakuun ja koulutukseen. TS
Osto, TuoS, Val
Pääsuunnittelija/ Projektipäällikkö
Osto, Tuotannon suunnittelu, Valmistus
LIITE A
MS
Kuvia dokumentaatioon, Hydraulisten laitteiden huolto‐ohjeita, kaavioita, käyttöohjeita
Kuvia dokumentaatioon, Mekaanisten laitteiden huolto‐ohjeita, käyttöohjeita
Hydrauliikka
Automaatio
Sähkö
Tuotetieto
Huolto‐ ja kunnossapitosuunnittelu (asiakasdokumentaatio)
HS
Kuvia dokumentaatioon, Automaatiojärjestelmän huolto‐ohjeita, kaavioita, käyttöohjeita
Kokonaisuuden hallinta
AS
Kuvia dokumentaatioon, Sähköjärjestelmän huolto‐ohjeita, kaavioita, käyttöohjeita
PS
SS
Dokumentointimateriaalin hallinnointi
Mekaniikka
Huolto‐ ja varaosasuunnittelu: Varaosakirjat, huoltopakettien suunnittelu
TS
AfSal
Pääsuunnittelija/ Projektipäällikkö
After Sales
OSIO III
Selvitysraportti
Huom! Osion tiedot saattavat olla puutteellisia tai ristiriitaisia loppuraportin kanssa, koska
selvitysvaiheessa kaikkea tietoa ei ollut käytettävissä.
1
Teollisuuden älykkäiden ja virtuaalisten konelaboratorioiden tuotantomenetelmien kehitys
semanttisen kuvauksen avulla –Semogen hanke
SELVITYSRAPORTTI
Pekka Ranta, toimittaja
Vänni Alarotu
Matti Helminen
Kari T. Koskinen
Mikko Markkula
Ossi Nykänen
Tuija Palonen
Janne Punki
Markus Rokala
Jaakko Salonen
Versio
Jakelu
v. 10 3.6.2010 Luonnos, vain Semogen –hankkeen sisäiseen käyttöön
Jakelu: Pauli Lappalainen AEL, Pasi Kaskinen AEL, Pekka Anttonen Sandvik Mining and Construction
Oy, Heikki Saha Sandvik Mining and Construction Oy, Jussi Puura Sandvik Mining and Construction Oy,
Veijo Niemelä Vertex Systems Oy, Manu Lammela Vertex Systems Oy, Jorma Salli Vertex Systems Oy,
Juha Leppänen Tuotekehitys Tamlink Oy, Kari T. Koskinen TTY/Hydrauliikan ja automatiikan laitos,
Seppo Pohjolainen TTY/Matematiikan laitos/Hypermedialaboratorio, Ossi Nykänen TTY/Matematiikan
laitos/Hypermedialaboratorio, Pekka Ranta TTY/Matematiikan laitos/Hypermedialaboratorio ja
Semogen –hankkeen tutkimushenkilöstö
Kuva. Metviro –projekti ja Sandvik Mining and Construction Oy
Selvitysraportti
2
Sisältö
Käsitteet ja lyhenteet ........................................................................................................................................ 4
1. Johdanto ........................................................................................................................................................ 6
2. Taustaa ja lähtökohdat .................................................................................................................................. 7
2.1. Älykkään ja virtuaalisen konelaboratorion tuotantoprosessi ................................................................ 7
2.2. Konejärjestelmän rajaus ......................................................................................................................... 8
2.3. Semanttinen mallinnus ......................................................................................................................... 10
2.3.1 Semanttisen mallinnuksen johdanto ............................................................................................. 10
2.3.2 Sovelluskäyttö................................................................................................................................. 11
2.4. Simulaatiomallien tuottaminen ............................................................................................................ 13
2.4.1 Hydraulismekaanisen järjestelmän nykyinen mallinnusprosessi ................................................... 13
2.5. Suunnittelujärjestelmät ........................................................................................................................ 16
2.6. Käyttäjät ............................................................................................................................................... 20
2.7. Sovellusesimerkit .................................................................................................................................. 21
2.8. Aineistot ............................................................................................................................................... 23
2.8.1. Poralaiteaineiston yleiskuvaus ...................................................................................................... 23
2.8.2. Suunnittelujärjestelmät ................................................................................................................. 24
2.9. M1 –teknologiaan perustuva ohjelmisto ............................................................................................. 24
2.9.1. Ohjelmiston kuvaus ....................................................................................................................... 24
2.9.2. M1-ohjelmiston ominaisuuksia ..................................................................................................... 27
2.9.3. Tekninen kuvaus ............................................................................................................................ 28
2.9.4. Dynaaminen kaavio ....................................................................................................................... 28
2.9.5 3D-mallien tuonti M1-ohjelmistoon ............................................................................................... 29
2.9.6 Toimintopuun ja -ketjun luonti M1-järjestelmässä ........................................................................ 31
2.9.7. CAN/Sähkösimulaatio .................................................................................................................... 32
3. Tuotantomallien ja -menetelmien kehitysehdotuksia ................................................................................ 33
3.1. Semanttisen mallinnuksen käytännön näkökohtia .............................................................................. 33
3.2 SemoGen-hankkeen erityispiirteet ........................................................................................................ 33
3.3. Tietojen tuonti suunnittelujärjestelmistä ............................................................................................. 34
3.3.1. Tiedon keräys suunnittelujärjestelmistä ja jatkokäsittely ............................................................. 35
3.3.2 Tapaus: Kaaviotiedon mekaaninen tuonti SemoGen-järjestelmään ............................................. 36
3.4. Datan prosessoinnin putkilinjastomalli ................................................................................................ 39
3.4.1. Konelaboratorion generointi ......................................................................................................... 41
3.4.2. Konejärjestelmän 3D -reaalikuvaus ............................................................................................... 43
Selvitysraportti
3
3.4.3 Dynaamisen kaavion automaattisen generoinnin vaatimukset .................................................... 44
3.4.4 Sähkö ja CAN-väylä simulaatioiden automaattinen toteuttaminen .............................................. 45
3.4.5 Toimintopuun ja –ketjun automaattinen generointi..................................................................... 45
3.4.6 Simulointimallien generointi .......................................................................................................... 45
3.4.9. Toimintokuvaukset ........................................................................................................................ 47
3.5. Suunnittelumenetelmät ja prosessit .................................................................................................... 48
3.6. Aineistotarpeet ..................................................................................................................................... 50
4. Yhteenveto .................................................................................................................................................. 54
5. Liitteet.......................................................................................................................................................... 57
Liite 5.1. Tutkimusongelmat ........................................................................................................................ 57
Liite 5.2. Sovellusesimerkit .......................................................................................................................... 58
Liite 5.3. Koneautomaatiojärjestelmien teknologioiden osaamiskartta ..................................................... 63
Selvitysraportti
4
Käsitteet ja lyhenteet
ACIS
Ohjelmisto 3D-mallintamiseen, hallintaan ja visualisointiin
CAD
Computer-aided design eli tietokoneavusteinen suunnittelu, joka perustuu
joko 2D- tai 3D-tasossa olevaan kuvaan
CAN
Controller Area Network on väyläratkaisu, jota käytetään yleisesti
ajoneuvoissa, liikkuvissa työkoneissa ja teollisuuslaitteissa.
DHD:SET
Dynaamisissa kaavioissa oleva elementti, jolla voidaan ryhmittää ja sitoa
kaavion objekteja simulaatioilta tuleviin signaaleihin
DPPM
Datan prosessoinnin putkilinjastomalli kuvaa virtuaalisen konelaboratorion
tuotantomprosessin ohjelmistoarkkitehtuurin.
Dynaaminen kaavio
Termillä kuvataan hydrauli-, sähkö- tai CAN-kaavioita, joissa kaavion objektit
ovat liikkeessä simulointisignaaleihin linkitettynä
IGES
Initial Graphics Exchange Specification määrittää neutraalin tietoformaation,
joka mahdollistaa tiedon vaihdon CAD-ohjelmien välillä
Inkscape
Avoimeen lähdekoodiin perustuva vektorigrafiikan käsittelyohjelma
Jumbo
Kutsumanimi Sandvik and Mining Constructionin valmistamille
mobiilitunnelinporauslaitteille
MATLAB
Korkean tason ohjelmointikieli ja teknillinen laskentaympäristö
M1-ohjelmisto
Konejärjestelmien koulutukseen tarkoitetun älykkään ja virtuaalisen
oppimisympäristön modulaarinen konelaboratorioalusta
Ogre3D
M1-ohjelmistossa käytössä oleva 3d-moottori
PDF
Portable Document Format on käyttöjärjestelmäriippumaton tiedostomuoto
tiedonsiirtämiseen
PDM
Product Data Management eli tuotetiedon hallintaan tarkoitettu
ohjelmistoympäristö. PDM:lla on mahdollista hallita yritysten tuotteisiin
liittyvää tietoa ja dokumentteja.
SFS
Suomen Standardisoimisliitto SFS ry on suomalainen standardisoinnin
keskusjärjestö
SFS-EN
Eurooppalaiset EN-standardit, jotka SFS Ry on vahvistanut Suomessa
ja mahdollisesti kääntänyt suomeksi
SFS-ISO
Maailmanlaajuiset ISO-standardit, jotka SFS Ry on vahvistanut Suomessa
ja mahdollisesti kääntänyt suomeksi
Selvitysraportti
5
SMC
Sandvik and Mining Construction on kallionporauslaite valmistaja
STEP
Standard for the Exchange of Product model data on ISO standardi tiedon
välittämiseen suunnittelujärjestelmien välillä. Erityisesti käytetty CADtiedostojen välittämiseen ohjelmista toiseen.
SVG
Scalable Vector Graphics on kaksiulotteisten vektorikuvien kuvauskieli, joka
pohjautuu XML-merkintäkieleen
Toimintaketju
Opetuksellisesti järkevien toiminnallisuuksien yksityiskohtaiseen ja
vaiheittaiseen kuvaamiseen tarkoitettu M1-ohjelmisto yhteensopiva
tietorakenne/-malli.
Toimintapuu
Konejärjestelmän vikatilanteiden ja niiden vaikutusten sekä vaikutusten
havainnoinnin kuvaamiseen
UDP
User Datagram Protocol on tiedonsiirtoprotokolla tietokoneiden väliseen tai
sisäiseen tiedonsiirtoon
XML
eXtensible Markup Language on sekä standardi että merkintäkieli, jolla tiedon
merkitys eli semantiikka voidaan lisätä kuvattavan tiedon sisään
Selvitysraportti
6
1. Johdanto
Tarkoitus ja kattavuus
Semogen -hankkeessa tutkitaan semanttisia kuvausmenetelmiä, mallien automaattista generointia ja
älykkäitä piirteitä sekä niitä sovelletaan virtuaalilaboratorioprototyypin kehitykseen. Tämä luo merkittävän
kehitysaskeleen teollisuuden virtuaaliprototypointi- ja osaamisen kehittämisen ratkaisujen
kustannustehokkaaseen ja niiden hallittuun kehitystyöhön sekä tietämysenhallintaan. Järjestelmiin ja
prosesseihin liittyvän semanttisen tiedon haltuunotto palvelee myös tulevaa tuote- ja
palvelukehitystoimintaa. (Semogen –hankeen tutkimussuunnitelma 2010.)
Hankkeen ensimmäinen työpaketti keskittyy kokonaisuuden selvitysvaiheeseen, johon muut työpaketit
perustuvat. Selvitysdokumentin tarkoituksena on tutkimustoimenpiteitä tukevalla tasolla kuvata
aineistojen, ohjelmistojen, mallien, suunnitteluprosessien sekä teknologioiden mahdollisuuksia, rajoitteita
ja yhteyksiä virtuaalisen konelaboratorion tuotantoprosessien automatisoinnissa sekä semanttisessa
mallinnuksessa. Selvitykseen on tuotettu myös ylemmän abstraktiotason prosessikartta, joka paikantaa
hankkeen tutkimustoimenpiteet laajempaan kokonaisuuteen. Selvityksen konkreettisena rajauksena toimii
valittu konejärjestelmä ja käytettävissä olevat suunnitteluohjelmistot, dokumentaatio sekä tavoiteltavat
pilot –järjestelmän sovellusesimerkeistä johdetut käyttövaatimukset. Rajauksen perusteella pyritään
yleistämään ja pelkistämään tutkittavien menetelmien ja mallien siirrettävyyttä myös muille toimialoille.
Selvitysdokumentin tietojen perusteella päätetään tarkennetut tutkimustoimenpiteet ja aikataulu. Ne
esitetään erillisessä dokumentissa.
Dokumentin lukijakuntana ovat asiantuntijat. Dokumentista löytyy myös hankkeen ohjausta ja yleisempää
päätöksentekoa tukevia osuuksia. Jokaisen luvun loppuun on tuotettu yleistajuinen tiivistys. Selvityksen
päätelmät kootaan yhteenvedoksi. Hankkeen tavoitteiden saavuttamiseksi olennaista on selvityksen
kattavuus ja riittävä alan asiantuntijoiden kommunikaatiota ja ymmärrystä tukeva syvällisyys. Selvityksen
syvyystaso rajautuu siten, että aineistojen, ohjelmistojen, teknologioiden, dokumenttien,
prosessikuvausten sekä suunnittelumenetelmien yksityiskohdat löytyvät erillisistä liitteistä. Näihin viitataan
pelkistetyn kuvauksen ja selkeän lähdeviittauksen avulla.
Selvitysraporttia on merkittävästi jalostettu Semogen –hankkeen työpajoissa. Lämmin kiitos AEL: Pasi
Kaskinen, Sandvik Mining and Constrction Oy: Pekka Anttonen, Heikki Saha, Jussi Puura ja Mikko Valtee,
Vertex Systems Oy: Manu Lammela ja Jorma Salli aineistoista, kommenteista ja näkemyksistä.
Yleiskatsaus dokumenttiin
Dokumentti rakentuu konejärjestelmärajauksen, suunnitteluohjelmiston, suunnitteluprosessien,
käytettävissä olevan aineistojen sekä virtuaalisen konelaboratorion erityisalueiden mukaan. Luvussa 2. on
kuvattu selvityksen tausta ja lähtökohdat. Luvussa 3. kuvataan tuotantomenetelmien ja –mallien
kehitysehdotuksia tutkimussuunnitelman tueksi. Luvussa 4. tehdään selvityksen yhteenveto.
Selvitysraportti
7
2. Taustaa ja lähtökohdat
2.1. Älykkään ja virtuaalisen konelaboratorion tuotantoprosessi
Semogen –hankkeen keskeisenä tavoitteena on kehittää älykkään ja virtuaalisen konelaboratorion
tuotantoprosessia. Konelaboratorion tuotantoprosessi liittyy laajempaan kehykseen kuten
liiketoimintatavoitteisiin, lainsäädäntöön, tuotetiedon hallintaan ja koneiden elinkaaren hallintaan.
Laajempi kehys ohjaa virtuaalisen konelaboratorion tuotantomenetelmien kehityksen painopistealueita.
Tuotantomenetelmien kehitystavoitteet pitää kohdentaa, rajata ja maadoittaa. Tämä tukee osaltaan myös
semanttista mallinnusta ja prosesseja, jolloin virtuaalisen konelaboratorion tuotantoprosessi (VKL –
prosessi) voidaan perustellummin jäsentää ja kohdentaa. Prosessien tunnistaminen, jäsentäminen ja
positiointi on keskeistä, jotta tutkimus- ja kehitystoimenpiteet voidaan kohdentaa tarkoituksenmukaisesti
ja näiden vaikuttavuutta osataan seurata ja arvioida. Kehitettyjen prosessimallien, menetelmien ja mallien
tuotteistaminen ja kaupallistaminen tapahtuu prosessin loppuvaiheessa. Kuvassa X on havainnollistettu
prosessikartaksi älykkään ja virtuaalisen konelaboratorion tuotantoprosessi. Prosessit on myös yksilöity.
Tähdellä merkityt koneen suunnnittelu (virtuaaliset konstruktiovaihtoehtojen arviointi) , käyttöönotto
(tekninen koulutus) ja koneen käyttö (kunnossapito) ovat tunnistettu keskeisiksi fokusalueiksi.
Kuvan 1 prosessikartta havainnollistaa älykkään ja virtuaalisen konelaboratorion tuotantoprosessiin (VKLprosessin) vaikuttavia tekijöitä, rajauksia sekä prosesseja.
Prosessikartasta johdetut prosessikuvaukset määritetään edelleen tarkennetuiksi prosessikaavioksi prosessi
kerrallaan. Kuvassa 2 L1: ”Aineiston rikastaminen” kuvataan ”uimaratakaavioksi”, jossa prosessien
keskeiset toimijat, prosessit ja vuorovaikutukset semanttisen kuvailutiedon keruun, rikastamisen ja
sovelluskäytön osalta. Kuvaus on viitteellinen ja vaatii tarkennusta.
Selvitysraportti
8
Kuvassa 2 kuvataan prosessikartan prosessikaavio L1. Aineiston rikastaminen kuvaa prosessikartasta
johdetun tietyn prosessin toimijat, aliprosessit sekä vuorovaikutukset kohdesovelluksen mallintamis- ja
määrittelytarpeisiin.
Prosessikaavioiden avulla kuvataan prosessikartassa määritellyt prosessit yhtenäisesti. Näiden avulla
voidaan kehittää sekä prosessimalleja että menetelmiä.
2.2. Konejärjestelmän rajaus
Semogen-projektin esimerkki konejärjestelmäksi on valittu Sandvik Mining and Construction Oy:n Jumbomobiilitunnelinporauskone (Kuva 1). SMC:n tunnelijumboja on useita eri malleja, joista tähän projektiin on
valittu DTi-sarjan tunnelijumbot. DTi-sarjaan kuuluu viisi konetta poikkileikkausten louhintaan, joiden
kokoluokka on 12-203 neliömetriä (DT920i, DT1120i, DT1130i ja DT1230i) [1]. Projektissa keskitytään
poralaite DT920i-malliin, jossa on kaksi TB100i porapuomia ja ei lainkaan koripuomia. Tarkennuksena
projekti keskittyy kyseisen mallin vasemman puoleiseen porauspuomiin, jotta mallinnus ja simulointi olisi
projektin näkökulmasta järkevästi rajattu. Yksittäinen porauspuomi koostuu mekaanisesta, hydraulisesta ja
sähköisestä järjestelmästä. Lisäksi voidaan erottaa puomi ja porauslaite erillisiksi järjestelmiksi, joista
poralaitteen toimintaa ei tässä projektissa mallinneta.
Tarkoitus on keskittyä ainoastaan porauspuomin mekaniikkaan ja hydrauliikkaan sekä sähkö- ja
väyläjärjestelmään. Rajaus helpottaa simulointia ja mallinnusta huomattavasti, mutta on riittävän laaja
projektin tavoitteiden saavuttamiseksi. Lisäksi jätetään mallintamatta ohjausohjelmisto, joten
simulointimallin porauspuomin paikannus tapahtuu manuaalisesti. Mallinnusprojektin ensimmäinen vaihe
aloitetaan nostotoiminnosta. Nostotoiminnon hydraulijärjestelmä sisältää yksinkertaisimmillaan
Selvitysraportti
9
toteutettuna pienen palan koko porauspuomista ja yksinkertaisen sähköohjauksen sekä yhden
hydraulisylinterin, venttiilin ja vakiopainesäädetyn pumpun. Tämän jälkeen kun generointiprosessi on
nostopuomin osalta saatu toimivaksi, voidaan siirtyä muiden toimilaitteiden toteuttamiseen samoilla
periaatteilla. http://www.tunnelbuilder.es/headline_4208_2.htm
Kuva 3. DTi-jumbo tunnelissa [1]
Syy DTi-sarjan valintaan on siinä olevat älykkäät ominaisuudet, kuten tuotanto- ja prosessi-informaation
keruu, suunnitteluohjelmistot automaattiporaukseen Lock-to-Target, QuickStep, Dynamic Correct, kunnon
monitorointi ja itsediagnostiikka. Projektin kannalta tärkeä ominaisuus DTi-sarjassa on myös väylätekniikka,
jota tämän sarjan jumboissa on käytetty paljon. [1,3] Väylätekniikan ja sähköjärjestelmien mallinnus ja
toiminnan esittäminen on tärkeä osa-alue Semogen-projektissa. DTI-sarjan ja sen yhden porauspuomin
valinta antaa hyvät mahdollisuudet väylä- ja sähkötekniikan liittämisen virtuaalikonelaboratoriossa osaksi
hydraulismekaanista järjestelmää. Näin virtuaalikonelaboratorion käyttäjälle muodostuu kokonaisvaltainen
kuva yksittäisen puomin toiminnasta ohjauksesta puomin mekaaniseen liikkeeseen asti.
Puomin hydraulijärjestelmä on vakiopainejärjestelmä, jotta puomilla saavutettaisiin mahdollisimman tarkka
paikoitus. Puomin mekaniikka ja hydrauliikka kostuu kahdeksasta nivelestä ja kuudesta vapausasteesta.
Puomin hydraulijärjestelmään liittyvät kahdeksan hydraulista toimintoa ovat puomin kääntö, nosto ja
zoomi sekä syöttölaitteen kallistus, siirto ja kääntö, roll-over ja lisäkallistus. Kaikkien toimilaitteiden nivelet
ovat ohjattavissa yhtä aikaa ja ne ovat anturoitu, joka mahdollistaa tarkan asemasäädön. Ohjausjärjestelmä
huomioi lisäksi puomin taipumat ja välykset ja paikoittaa automaattisesti puomin ratageneraattorilla.
Automaattiohjauksen lisäksi puomia on mahdollista ohjata suoraan käsiajomoodissa. [4] Tätä ohjaustapaa
käytetään myös projektissa simuloitavan virtuaalisen puomin ohjaamiseen, koska ohjausjärjestelmän
mallintaminen olisi erittäin työläs projekti. Käsiajomoodissa on mahdollista käyttää suoraohjaus,
yhdensuuntaisuusmoodi, koordinaattiajo käsiohjaimilla ja pulttauksen puomiohjaus koordinaattiajona.
Selvitysraportti
10
Sähkö- ja väylätekniikka rajautuu myös mukavasti ja on mukana projektin kannalta riittävällä laajuudella.
Jokaisella yksittäisellä puomilla on oma väylä, jota kutsutaan puomiväyläksi (Kuva 2). Kaikki puomin anturit
ja toimilaitteiden venttiilit ovat liitetty puomiväylään. Anturit ovat niin kutsuttuja älykkäitä antureita, jotka
kiinnittyvät suoraan väylään. Puomiväylä on yhteydessä runkoväylän kautta muihin väyliin, kuten
ohjaamoväylään. [4] Projektissa voidaan keskittyä pelkästään puomiväylän mallintamiseen. Runkoväylän ja
siinä kiinni olevan ohjausyksikön voidaan ajatella olevan mustalaatikko, josta tieto välittyy puomiväylään ja
takaisin runkoväylälle.
[1] http://www.tunnelbuilder.com/DTi_Series_Brochure.pdf
[2] http://www.tunnelbuilder.es/headline_4208_2.htm
[3] http://www.vuoriteknikot.fi/file_download/5/Vuority%C3%B6%20ja-tekniikka%202008.pdf
[4] http://wiki.tut.fi/pub/SemoGen/Tyopaja-2010-04-3/IUP017AKA_parsed_for_simulator_introduction.ppt
2.3. Semanttinen mallinnus
Semanttisella mallinnuksella tarkoitetaan merkitystiedon kuvaamista mekaaniseen käsittelyyn soveltuvassa
muodossa, pääsääntöisesti tietokoneella suoritettavaa laskentaa silmällä pitäen. Semanttisen mallinnuksen
rinnalla puhutaan siten usein myös semanttisesta laskennasta (Semantic Computing):
Semantic Computing (SC) is defined as "Computing with (machine processable) Descriptions of Content and
Intentions." It brings together those disciplines concerned with connecting the (often vaguely formulated)
intentions of humans with computational content that includes, but is not limited to, structured and semistructured data, multimedia data, text, programs, services and, even, network behavior.
(International Journal of Semantic Computing, http://www.worldscinet.com/ijsc/mkt/aims_scope.shtml)
2.3.1 Semanttisen mallinnuksen johdanto
Semanttinen mallinnus ja laskenta tähtäävät siis tietyn sovelluksen käyttäjien tiettyjen tavoitteiden
saavuttamiseen, mallintamalla sovelluksen semanttinen sisältö tiedon koneellisen käsittelyn näkökulmasta.
Semantiikalla tarkoitetaan (tässä) asian tai välineen kuvattua merkitystä sovelluksessa, suhteessa johonkin
selittävään malliin ja/tai teoriaan. Suunnittelutiedon tapauksessa tämä voi tarkoittaa esim. sitä että koneen
suunnitelupiirrustukseen liitetään visuaalisen mallin ohella myös käytettyjen komponenttien tunnistenimet,
jotka voidaan edelleen liittää esim. komponenttiluettelon tietoihin, jne. Koska tuotanto maksaa, tiedot
valitaan sovelluksen tarpeiden mukaan.
Aihepiirin stereotyyppisiä aktiviteettejä ovat mm.




analyysi ja mallinnus (tarpeet, tietolähteet),
tiedon integrointi,
hyödyntäminen sovellustasolla, sekä
semanttinen käyttöliittymäsuunnittelu
Tyypillisiä matalan tason tehtäviä ovat tiedon haku, integrointi, jäsentäminen (suhteessa tiettyyn malliin),
sekä tuottaminen ja/tai rikastaminen.
Selvitysraportti
11
Semanttinen mallinnus (ja laskenta) ovat osa laajempaa sovelluskehystä; eivätkä menetelmätasolla ota
erityistä kantaa tekniikoihin eikä sovelluksiin. Käytännössä tyypillisiä tekniikoita kuitenkin esim.
logiikkaohjelmointi (rajoitettu predikaattilogiikka, kuten Hornin logiikka, Prolog, yms.), World Wide Web
Consortiumin (W3C) stamdardoimat Semanttisen Webin tekniikat (esim. RDF ja OWL; ks.
http://www.w3.org/2001/sw/),
sumea
laskenta,
tietokantaintegraatio,
yms.
2.3.2 Sovelluskäyttö
Käytännön sovelluksissa on usein tavoitteena esim. sovellusintegraatio, tietämyksenhallinta ja/tai
sovellustiedon validointi (ks. esim. Gómes-Pérez, Fernández-López & Corcho, 2004). Semanttista
mallinnusta voidaan harjoittaa useilla tasoilla; yleensä tavoitteena on mahdollisimman yksinkertainen,
laajennettavissa malli joka kuitenkin täyttää sovelluksen kirjatut tavoitteet.
Esimerkiksi tehdasautomaatiossa (Process Monitoring, Factory Automation) monimutkainen kone (esim.
kokoonpanolinja) voidaan varustaa sensoreilla jotka havaitsevat edustamansa laitteen tilan tehtaassa. Eri
koneiden sensorien välittämä tieto tarjoaa kaksi keskeistä näkymää tehtaaseen: 1) Millainen tehdas on,
sekä 2) Mitä tehtaassa tapahtuu. Ilmeisenä vaatimuksena on sopiva & yhtenäinen (semanttinen) malli
tehtaan laitteista sekä näiden tehtävistä, sekä välineet joilla harjoittaa (semanttista) laskentaa esim.
tuotannonohjauksen näkymien ja kyselyiden tarpeisiin.
Käytännön sovelluksissa semanttinen malli --- tai yleisemmin, sovellusalueen teoria --- jaetaan yleensä
kahden toisiaan täydentävän teknisen komponentin, käsitemallin (Ontology) ja sääntöjärjestelmän (Rules)
kesken. Koska ko. teknisten komponenttien ilmaisuvoima on osin päällekkäistä, joissakin sovelluksissa
voidaan tulla toimeen jo toisellakin näistä. Käsitemalli kuvataan tyypillisesti vapaamuotoisesti ja
formalisoidaan soveltuvin osin esim. Web Ontology Language –tekniikalla (ks. esim. Allemang & Hendler,
2008). Tässä mallinnuksen perustan muodostaa tyypillisesti luokkahierarkia. Käsitteiden varassa toimivat
säännöt esitetään tyypillisesti Prolog-tyyppisen logiikkaohjelmoinnin avulla (ks. esim. Newton, Pollock, &
McGuinness, 2004; Hawke, Tabet, & Sainte Marie, 2005). Sääntöjärjestelmissä mallinnuksen perusosa on
yleensä faktoista ja säännöistä rakentuva proseduuri.
On erittäin tärkeätä huomata että tietokoneiden näkökulmasta semanttinen laskenta on tyypillisesti
"lasihelmipeliä" --- mallien suorituksessa ei yleensä oletuksena ole mukana esim. arkipäättelyä (ns.
Common Sense) joten virheellinen tai epäkelpo syöte johtaa yksinkertaisesti epäkelpoon suoritukseen.
"Älykkyys", jos ko. termiä ylipäänsä halutaan käyttää, on siten suoritettavan mallin tai teorian ominaisuus,
ei itse laskentakoneiston. Käytännössä erittäin merkittäväksi haasteeksi muodostuukin juuri inhimillisten
heuristiikkojen, peukalosääntöjen yms. epämääräisten päättelysääntöjen tarkoituksenmukainen
mallintaminen --- jotka yksinkertaisen logiikan näkökulmasta ovat usein ristiriitaisia. Eräs aihepiirin
perustutkimuksen haasteista onkin juuri tämäntyyppisten seikkojen huomiointi osana semanttisen
laskennan viitekehyksen (oletusarvoisia) primitiivejä. (Tämä selittää osaltaan esim. alan yleisen
kiinnostuksen sumeaan mallinnukseen.)
Sovellusalueen teoria voidaan käsitteelisesti jakaa edelleen kahteen osaan: ns. terminologiaan
(Terminology) ja esiintymätietoon (Assertions). Näistä ensimmäinen kuvaa tyypillisesti sovellusalueen
yleistä tietoa (esim. tehtaan logistiikka ja tuotantolinjat) ja jälkimmäinen valitun sovelluksen
tapauskohtaista tietoa (esim. tehtaan nimenomaiset koneet ja valmistettavien tuotteiden erityspiirteet).
Selvitysraportti
12
Käytännön sovelluksissa on merkillepantavaa että vaikka tietämysjärjestelmien yms. periaatteet ovat
teoriassa varsin hyvin tunnettuja (vrt. esim. Russel & Norvig, 1995: decide what to talk about; decide on a
vocabulary of predicates, functions, and constants; encode general knowledge about the domain; encode a
description of the specific problem instance; and pose queries to the inference procedure and get answers),
varsinaisen pullonkaulan asettavat tiedon virheettömään syöttämiseen, ylläpitoon ja ihmisen kognition
rajallisuuteen liittyvät haasteet (ks. esim. Hoffmann, 1998). Asian kärjistetty johtopäätös lienee myös
semanttisen mallinnuksen ja laskennan osalta se, että "riittävän yksinkertainen on kaunista". Todettakoon
että ohjelmistotekniikassa hyväksi havaittu suunnittelumallin käsite (Design Pattern) on tulossa myös
käsitemallinnukseen (ks. esim. Aranguren, 2005); käytännössä ala on kuitenkin vasta kehittymässä.
Lähteitä
Allemang, D. & Hendler, J. 2008. Semantic Web for the Working Ontologist: Effective Modeling in RDFS and
OWL. Morgan Kaufman, UK.
Aranguren, M.E. 2005. Ontology design patterns for the formalisation of biological ontologies, Ph.D. Thesis,
University of Manchester, faculty of engineering and physical sciences. Available at
http://www.gong.manchester.ac.uk/docs/MPhilThesis.pdf
Gómes-Pérez A., Fernández-López M., & Corcho, O. 2004. Ontological Engineering: With Examples from the
Areas of Knowledge Management, E-Commerce and the Semantic Web (Advanced Information and
Knowledge Processing). Springer, USA.
Hawke, S., Tabet, S., & Sainte Marie, C. de 2005. Rule Language Standardization, Report from the W3C
Workshop on Rule Languages for Interoperability, W3C Workshop on Rule Languages for Interoperability,
April 27-28, 2005, Washington, D.C., USA, W3C, Available at http://www.w3.org/2004/12/rules-ws/report/.
Hoffmann, A.G. 1998. Paradigms of Artificial Intelligence: A Methodological and Computational Analysis.
Springer, USA.
Newton, G., Pollock, J. & McGuinness, D.L. 2004. Submission request to the World Wide Web Consortium:
Semantic Web Rule Language (SWRL), W3C, Available at http://www.w3.org/Submission/2004/03/
Russel, S. & Norvig, P. 1995. Artificial Intelligence; A Modern Approach, Prentice Hall, USA.
Selvitysraportti
13
2.4. Simulaatiomallien tuottaminen
2.4.1 Hydraulismekaanisen järjestelmän nykyinen mallinnusprosessi
Järjestelmien simulointi ja mallinnus on yleensä iteratiivinen prosessi, kuten usein muutkin prosessit
ohjelmistotuotannossa. Konejärjestelmien mallinnusprosessia on vaikea kuvata yhtenä suoraviivaisena
putkimaisena prosessina. Ideaalitapauksessa simulointi ja mallinnusprosessi olisi vesiputousmalli, jossa
tiedon keruusta siirryttäisiin komponenttien mallintamiseen ja lopulta päädyttäisiin yhdistämään
komponentit järjestelmäksi.
1. Mallinnettavan järjestelmän määrittäminen ja rajaaminen
2. Järjestelmän ja komponenttien toiminnan ymmärtäminen
3. Tiedon kerääminen ja jäsentäminen
4. Mallintamisen aloittaminen komponentti kerrallaan ja yksittäisten komponenttimallien testaus
5. Komponenttimallien yhdistäminen toimivaksi järjestelmäksi
6. Kokonaismallin verfioiminen
7. Mallin liittäminen muihin simulaatiota tukeviin järjestelmiin
8. Lopullisten muutosten ja viimeistelyjen teko malliin
Ideaaliprosessia tuskin koskaan tapahtuu, koska tiedon tarve ja tietämys järjestelmästä kasvaa yleensä
prosessin kuluessa. Yleensä tiedon keruuta tapahtuu vielä komponentteja mallinnettaessa ja liitettäessä
mallinnettuja komponentteja yhteen ne eivät enää käyttäydy kokonaisjärjestelmässä samoin kuin yksittäin.
Käytännössä komponenteista mallinnetaan aluksi prototyyppimallit ja kootaan alustava
prototyyppisimulointimalli perustuen alustaviin tietoihin simuloitavasta järjestelmästä ja mallin
käyttötarkoituksesta. Näin jo projektin alkuvaiheessa muodostuu kuva kokonaisesta järjestelmästä ja
voidaan paremmin panostaa mallin kannalta tärkeiden komponenttien mallintamiseen. Ongelmana on, että
prototyyppiin mallinnettu ja vähemmän tärkeitä komponentteja ei enää paranneta vaan ne jäävät todella
yksinkertaiselle tasolle. Prototyyppi vaiheessa olisikin parempi keskittyä vain muutaman tärkeän
komponentin mallintamiseen ja lisätä malliin vähemmän olennaiset komponentit myöhemmin.
Prosessin kulusta riippumatta ensimmäinen askel on aina kerätä tietoa järjestelmästä, rajata simuloitava
järjestelmä ja miettiä simulointimallin käyttötarkoitusta. Konejärjestelmän simulointia ja mallinnusta varten
tarvitaan paljon taustatietoa järjestelmään kuuluvista komponenteista ja niiden liitoksista sekä
merkityksestä järjestelmän kokonaistoimintaan. Tarvittava komponenttikohtainen tieto riippuu mallin
käyttötarkoitusta tukevasta mallinnustarkkuudesta. Komponenteista, jotka ovat erittäin tärkeitä
järjestelmän päätehtävän tai simulointimallin käytön kannalta, tarvitsee kerätä enemmän ja tarkempaa
tietoa. Muista komponenteista ei välttämättä tarvita tarkkoja tietoja ja kuvauksia, koska ne voidaan
simuloida yksinkertaisemmilla matemaattisilla malleilla. Osaan malleista riittää komponentin
käyttäytymistä kuvaava siirtofunktio. Toisaalta osa malleista tarvitsee tarkat komponentin mittapiirustukset
ja tarkat tiedot esimerkiksi välyksistä.
Selvitysraportti
14
Edellä kuvattujen tietojen lisäksi on tutkittava, miten kyseiset komponentit voitaisiin mallintaa.
Kirjallisuudesta löytyvät aiemmat tutkimustulokset ja mallinnustavat on selvitettävä sekä tutkittava niiden
käyttökelpoisuus. Komponenttien mallintaminen voidaan aloittaa, kun tarvittavat alkutiedot on saatu ja
tehty tarvittava rajaus mallinnettavasta järjestelmästä sekä sovittu mallinnustarkkuus. Kokojärjestelmän
mallintaminen alkaa järjestelmän tärkeimmistä komponenteista, joista tehdään prototyyppimallit kerätyn
tiedon pohjalta. Mallinnus toteutetaan Simulinkillä ja parametrit kirjataan m-tiedostoon.
Komponenttimallit liitetään järjestelmää kuvaavaksi prototyyppimalliksi, jolla voidaan tehdä ensimmäisiä
testejä simulointimallin toimivuudesta. Viimeistään tässä vaiheessa mallinnusprosessi muuttuu selvästi
iteratiiviseksi ja komponenttien malleja on kehitettävä eteenpäin. Samalla kun tieto konejärjestelmästä
lisääntyy, on tehtävä tarkempia kysymyksiä järjestelmän toiminnasta, joita ei alkuselvityksessä huomattu
kysyä. Näin protomalliin voidaan tiedon lisääntyessä liittää uusien komponenttien malleja ja kehitellä
protomalleja paremmiksi tai korvata kokonaan uusilla malleilla. Lisäksi parametreja pitää usein muuttaa,
jotta toiminta vastaisi haluttua. Tämä iteratiivinen prosessi ei oikeastaan koskaan lopu, koska mallista
voitaisiin kokoajan löytää parannettavia asioita.
Simuloinnin liittäminen M1-järjestelmän kaltaiseen virtuaaliseen konelaboratorioon asettaa omat
haasteensa. Simulinkissa mallinnettu järjestelmämalli käännetään Matlabilla suoritettavaksi
simulointimalliksi, joka Semogen ja Metviro-hankkeissa on Windows-sovellus eli exe-tiedosto. Tieto
lähetetään sovelluksesta toiseen UDP-paketteina verkkokortin kautta. Tätä varten on sovittava IP-osoitteet
ja tietoliikenne portit, joita sovellukset käyttävät kommunikointiin. Rajapintana käytetään xml-tiedostoa,
johon tietoliikenne määritellään.
Hydraulismekaanista järjestelmää simuloitaessa ja esitettäessä simulointituloksia reaaliajassa 2D- ja 3Desityksinä simuloinnista on lähetettävä yllättävän paljon tietoa ulos, mutta myös vastaanotettavaa tietoa
on paljon. Lähetettävään tietoon kuuluu muun muassa eri paikoissa järjestelmää vallitsevat paineet,
tilavuusvirrat, karojen liikkeet ja toimilaitteiden asemat. Lisäksi mekaanisten rakenteiden asemat ja kulmat
on lähetettävä. Vastaanotettavaan tietoon lukeutuvat muun muassa ohjaussignaalit, asetusarvot ja lukuisat
vikasignaalit. Tietoliikenteen hallitsemiseksi ne tarvitsee dokumentoida ja sopia tarkasti tietoliikennepaketit
eri sovellusten kehittäjien kanssa. Paketeissa tarvitsee tietää lähetettävien signaalien määrä, signaalien
tyypit ja signaalien nimet.
MATLAB/Simulink
Mathworksin MATLAB on korkean tason ohjelmointikieli ja teknillinen laskentaympäristö. MATLAB on
tehokkaampi kieli tekniseen laskentaan verrattuna perinteisiin ohjelmointikieliin kuten C, C++ ja Fortran.
Siitä löytyy ominaisuuksia matriisien käsittelyyn, algoritmien, käyttöliittymien ja ohjelmien kehittämiseen,
datan analysointiin, muokkaamiseen ja visualisointiin sekä numeeriseen laskentaan. (Mathworks 2009a.)
Lisäksi MATLAB-kieleen on mahdollista integroida muilla kielillä tuotettuja ohjelmia ja MATLAB-kieli on
vastaavasti liitettävissä muihin ohjelmiin. Peruskokoonpanon voidaan liittää työkaluja (toolbox), joiden
avulla MATLAB-ohjelman käyttöä voidaan laajentaa useille erityisaloille. Lisäosia on olemassa esimerkiksi
säätösuunnitteluun, signaalinkäsittelyyn ja teknilliseen mallinnukseen.
Simulink on MATLAB-laajennus, joka tarjoaa erinomaisen keinon mallintaa, simuloida ja analysoida
järjestelmiä matemaattisilla malleilla. Mallinnus perustuu Simulinkin tarjoamaan graafiseen
käyttöliittymään ja lohkokaavioesityksiin eli symboliseen mallinnukseen. Se mahdollistaa dynaamisten
järjestelmien mallinnuksen yksinkertaisesti ja mallien kääntäminen suoritettaviksi ohjelmiksi on nopeaa.
Lisäksi Simulinkin S-funktiot mahdollistavat Simulink-ympäristön käytön laajentamisen muilla kielillä. Niiden
Selvitysraportti
15
avulla voidaan tehdä omia Simulink-komponentteja ja käyttää niitä valmiiden komponenttien tapaan. Ne
ovat kirjoitettu MATLAB-, C-, C++-, Ada- tai Fortra-kielellä ja MATLAB kääntää koodista MEX-tiedostoja.
Tämä mahdollistaa kolmansien osapuolien simulointiohjelmistojen linkittämisen Simulinkiin. Microsoft
Windowsissa mallien siirtämiseen ohjelmistosta toiseen käytetään yleensä DLL-muotoa (Dynamic Link
Library), jotka käännetään S-funktioiksi. (Mathworks 2009b.)
Matemaattisiin kaavoihin ja operaatioihin perustuva mallinnus on kuitenkin usein liian monimutkainen ja
aikaa vievä tapa mallintaa useita fyysisiä systeemejä. Ongelma ratkeaa Simulinkin MATLAB-kieleen
pohjautuvalla Simscape-kielellä. Simscape-kielessä lohkoille on määritelty fyysisen toiminta-alue (Physical
Domain) ja yksi lohko sisältää valmiiksi matemaattisen mallin fyysisestä osakokonaisuudesta. Lohkoja on
olemassa mekaanisista, hydraulisiin ja sähköisiin komponentteihin. Yhden toiminta-alueen sisällä lohkoille
määritellään toiminta-alueessa vallitsevat olosuhteet. Mallit voivat sisältää useita toiminta-alueita ja ne
voidaan liittää muihin Simulink-malleihin. (Mathworks 2009a.)
Mathworks 2009a [WWW]. [Viitattu 11.6.2009]. Saatavissa:
http://www.mathworks.com/products/product_listing/index.html
Mathworks 2009b. Simulink® 7 Writing S-Functions 7.3 (Release 2009a). [WWW].
Päivitetty Maaliskuussa 2009. Saatavissa:
http://www.mathworks.com/access/helpdesk/help/pdf_doc/simulink/sfunctions.pdf
Selvitysraportti
16
2.5. Suunnittelujärjestelmät
Suunnittelujärjestelmät
Koneensuunnittelun suunnitteluohjelmistot voidaan jakaa yleensä kolmeen osa-alueeseen
käyttötarkoituksensa mukaan. Nämä osa-alueet ovat: mekaniikkasuunnitteluun käytettävät ohjelmistot,
hydrauliikkasuunnitteluun käytettävät ohjelmistot ja sähkösuunnitteluun käytettävät ohjelmistot. Näiden
kolmen osa-alueen lisäksi nykyaikaisessa koneensuunnittelujärjestelmässä olennainen osa-alue on
tuotetiedonhallintaohjelmisto (PDM), jonka tarkoituksena on kerätä edellä mainittujen kolmen ohjelmiston
materiaali samaan paikkaan helposti saataville sekä materiaalin käsittelyn helpottamiseksi.
Mekaniikkasuunnitteluohjelmistot
Mekaniikkasuunnitteluun käytettäviä ohjelmistoja käytetään koneen mekaanisten rakenteiden ja
mekanismien suunnitteluun. Moderneissa ohjelmistoissa suunnittelu tapahtuu 3D- ympäristössä, jossa
suunniteltavat osat ja kokoonpanot mallinnetaan kolmiulotteisesti. Tämä tekee mahdolliseksi
suunniteltujen koneiden ja laitteiden kokoonpantavuuden ja toiminnan tarkastelun jo ennen
työpiirustusten valmistusta. Tällöin valmistus- ja testausvaiheissa ei jouduta korjaamaan tapahtuneita
suunnitteluvirheitä samassa määrin kuin ennen 3D- ohjelmistojen tuloa markkinoille.
Mekaniikkasuunnitteluohjelmistojen yleistyttyä niihin on alettu lisätä uusia toimintoja. Modernissa
mekaniikkasuunnitteluohjelmistossa voidaan määrätä suunnitelluille osille jo ohjelmistossa mm.
valmistusmateriaalit sekä kappaleiden väritykset. Varustelukokoonpanoissa käytettyjen komponenttien
tiedot on mahdollista myös tallentaa järjestelmään. Muuta lisättyä toiminnallisuutta
mekaniikkasuunnitteluohjelmistossa voi olla muun muassa mekanismisuunnittelu ja -tarkastelu,
lujuuslaskenta sekä virtaus- ja lämpömallinnus.
Mekaniikkasuunnitteluohjelmistot tallentavat niillä tehdyt tiedostot (osat, kokoonpanot, piirustukset)
yleensä ohjelmistojen omina tiedostomuotoina. Tämän takia esimerkiksi eri ohjelmistolla tehty osa ei
välttämättä aukea ollenkaan toisessa mekaniikkasuunnitteluohjelmistossa. Joidenkin ohjelmistojen
kohdalla on myös mahdollista, että ohjelmiston eri versioiden välillä ei ole mahdollista siirtää tiedostoja.
Jotta tiedostojen siirto eri suunnitteluohjelmistojen välillä onnistuisi, on kehitetty muutamia yleisiä
tiedostomuotoja 3D -mallien tallennukseen ja käsittelyyn. Näitä tiedostomuotoja ovat muun muassa STEP
(.stp), ACIS (.sat) ja IGES (.igs), jotka ovat yleisimmin teollisuudessa käytössä. Näiden tiedostomuotojen
mukana siirtyy kuitenkin yleensä vain kappaleiden geometriatietoja.
Tässä projektissa on esimerkiksi TTY:llä käytettävissä kaksi eri mekaniikkasuunnitteluohjelmistoa: Vertex G4
ja SolidWorks. SolidWorks on TTY:llä normaalisti käytössä oleva tutkimuskäyttöön lisensoitu
mekaniikkasuunnitteluohjelmisto. Vertex G4 -ohjelmisto on hankittu Vertexiltä nimenomaan Semogen projektiin.
Vertex G4 , HD ja ED
Vertex G4 on piirrepohjainen 3D-CAD-mekaniikkasuunnitteluohjelmisto, joka on yleisesti käytössä
teollisuudessa. Perusohjelmistolla on mahdollista tehdä 3D-suunnittelua sekä työpiirustukset näistä
malleista. Ohjelmistossa voidaan määritellä kappaleiden mittatietojen lisäksi materiaalitiedot, väritys sekä
valinnaisia lisätietoja, jotka saadaan näkyville esimerkiksi osaluetteloihin. Erilaisilla lisäosilla Vertex G4:n
käyttöä voidaan laajentaa huomattavasti.
Selvitysraportti
17
Vertex HD on hydraulikaavioiden ja vastaavasti ED sähkökaavioiden piirto-ohjelma. Ne ovat
ominaisuuksiltaan lähes identtiset ja niistä saatavat tiedot vastaavat toisiaan. ED:stä ja HD:stä on
mahdollisuus tulostaa kaavioita tiedostoon DXF-muodossa. Lisäksi kaavioita on mahdollista tulostaa
tiedostoon svg-muodossa erillisen svg-exportterin avulla.
HD ja ED ovat ominaisuuksiltaan (lähes) identtiset ja niistä saatavat tiedot vastaavat toisiaan.





Hydrauli- ja sähkökaavio-layout, kytkennät, lisätekstit.
Eri hydrauli- ja sähkökaavioiden yhteydet/linkkaukset
Jokaisesta osasta on mahdollista kuvata ohjelmalla:
o tunnus
o tuoteryhmä
o nimike
o nimitys
o tuote
o valmistaja
o lukumäärä
o yksikkö
o osanumero
Ohjelmassa on ainakin osittain kieliversiointi mahdollisuus
Yleiset attribuutit (nimi-arvo pari)
ED:stä ja HD:stä on mahdollisuus viedä kaavio svg-muodossa:


Tiedot lähes suoraan M1-kaaviotyökalu yhteensopivassa muodossa
o viivat hieman eri tavalla määritelty, mutta muutostyö on melko minimaalista
o kaaret eri formaatilla määritelty, ja voi vaatia työtä hieman enemmän
piirrosmerkit määritelty omina ryhminään, joille määritelty Vertexin omaa nimiavaruutta käyttäen
makron tunniste (=piirrosmerkkityypin tunniste) ja elementti-id.
Vienti on myös mahdollista DXF-muodossa.
SolidWorks
SolidWorks on myös piirrepohjainen 3D-CAD-mekaniikkasuunnitteluohjelmisto, joka on yleisesti käytössä
teollisuudessa. Perusohjelmistolla on mahdollista tehdä 3D-suunnittelua sekä työpiirustukset näistä
malleista. Ohjelmistossa voidaan määritellä kappaleiden mittatietojen lisäksi materiaalitiedot, väritys sekä
valinnaisia lisätietoja, jotka saadaan näkyville esimerkiksi osaluetteloihin. Erilaisilla lisäosilla SolidWorks:n
käyttöä voidaan laajentaa huomattavasti.
Suunnitteluohjelmistojen ominaisuuksia Semogen -projektin näkökulmasta
Modernit mekaniikkasuunnitteluohjelmistot ovat piirrepohjaisia 3D-CAD-ohjelmistoja. Kappaleiden
mallinnus näissä ohjelmistoissa tapahtuu erilaisten piirteiden avulla, joista tavallisimpia ovat erilaiset
pursotukset, leikkaukset ja pyyhkäisyt. Näiden piirteiden perustana voi olla joko 2D-piirros tai piirteet ovat
kirjastopiirteitä. Kappaleen mallintamisessa tehdyt piirteet sekä mahdolliset 2D-piirrokset voidaan
suunnittelijan toimesta nimetä vapaasti. Myös kappaleen mitat voidaan suunnittelijan toimesta nimetä
vapaasti. Mittojen nimet ovat ainakin SolidWorks:ssa muotoa esimerkiksi D4@Sketch1@Part1.sldprt. Tässä
Selvitysraportti
18
nimessä D4 on mitan nimi, Sketch1 on 2D-piirroksen tai piirteen nimi ja Part1.sldprt on mallinnetun
kappaleen nimi, jonka suunnittelija voi myös vapaasti tai käytössä olevan nimikkeistön rajoissa päättää.
SolidWorks:ssa partin, eli yksittäisen osan, tiedostomuoto on sldprt ja assemblyn, eli useasta osasta
koostuvan kokoonpanon, tiedostomuoto on sldasm. Tämä nimeämisperiaate pätee hyvin todennäköisesti
myös muihin mekaniikkasuunnitteluohjelmiin. Suunnitellun komponentin nimeen voidaan myös sisällyttää
lisätietoa osasta. Näiden tietojen perusteella voidaan siis, kun tiedetään halutun mitan nimi, hakea 3Dmallista haluttu parametritieto simulointimallia varten.
Moderneissa hydrauliikka- ja sähkösuunnitteluohjelmissa käytetään standardoituja piirrosmerkkejä,
komponenttien nimeämismenetelmiä sekä piirustustapoja. Hydrauliikan osalta tällaisia standardeja on
muun muassa:



SFS-ISO 1219-1 HYDRAULISET JA PNEUMAATTISET TEHONSIIRTOJÄRJESTELMÄT JA KOMPONENTIT.
PIIRROSMERKIT JA PIIRIKAAVIOT. OSA 1: PIIRROSMERKIT TAVANOMAISEEN KÄYTTÖÖN JA ATKSOVELLUKSIIN
SFS-ISO 1219-2 HYDRAULISET JA PNEUMAATTISET TEHONSIIRTOJÄRJESTELMÄT JA KOMPONENTIT.
PIIRROSMERKIT JA PIIRIKAAVIOT. OSA 2: PIIRIKAAVIOT
SFS-ISO 5598 Hydrauliikka- ja pneumatiikkasanasto
Sähkötekniikan osalta näitä standardeja ovat muun muassa:


SFS-EN 60617-13 Sähkötekniikan piirrosmerkit. Osa 13: Analogiatekniikan elimet
SFS-EN 60617-12 Sähkötekniikan piirrosmerkit. Osa 12: Binäärilogiikan elimet
Yleensä hydrauliikka- ja sähkösuunnitteluohjelmistoissa toimilaitteiden ja komponenttien osat voidaan
nimetä sekä lisätietoja näistä voidaan tallentaa tietokantoihin. Joissain ohjelmistoissa nämä tietokannat on
integroitu ohjelmistoon. Joissain suurissa suunnittelujärjestelmissä suunnitteluohjelmistot on sulautettu
itse tietokantaohjelmistoon. Tietokantojen muodot vaihtelevat todennäköisesti yritys- ja
sovelluskohtaisesti, joten tietojen hankinta näistä järjestelmistä tulee tällä hetkellä todennäköisesti
selvittää asiakas ja sovellus kerrallaan. Joissain ohjelmistoissa tiedot voivat olla yhteneviä, kun taas toisissa
ohjelmistoissa tiedot voivat vaihdella.
Tuotetietojärjestelmät (PDM)
Tuotetiedon hallinta tarkoittaa ohjelmistoympäristöä, joilla hallitaan keskitetysti yrityksen tuotteisiin
liittyvää tietoa ja tiedostoja. Selvityksessä ei löytynyt yksityiskohtaista tietoa, mitä konkreettista tietoa
näissä järjestelmissä on ja erityisesti mitä projektiin valitusta konejärjestelmästä olisi mahdollista löytää
PDM-järjestelmästä. Yleensä PDM voi sisältää esimerkiksi 2D- ja 3D malleja, osaluettelon,
konfiguraatiotiedot, laskentatiedostoja ja näihin linkitettyjä dokumentteja kuten tekstimuotoisia raportteja,
standardeja. Seuraavaan listaan on listattu mitä tietoja voi löytyä PDM-järjestelmästä.






dokumenttien käyttöoikeuksien hallinta
tietovirtojen ja prosessien hallintaa
osa/komponentti/kokoonpano kuvat
fyysiset mitat ja ominaisuudet
nimet ja linkityksiä
osaluettelo
Selvitysraportti







19
tuotteeseen liittyviä ohjelmistoja ja koodin pätkiä
mahdolliset konfiguraatio- ja variaatiomuutokset
3D-malli, pintaväritykset
yksilöivä tunniste kokoonpanossa
materiaali
tuotekustannus (ja paino)
tekstidokumentteja ja suunnitteluraportteja
Lisäksi yleensä mainitaan että siellä voi olla "kaikki tieto". Osassa tuotetietojärjestelmiä on myös
integroidun CAD-yhteensopivuuden lisäksi yhteensopivuus johonkin simulointijärjestelmään, joka kutoo
CADin ja simulaation ja mahdollistaa eri dokumenttiformaattien katselun mahdollisuuden sekä
mahdollisuuden tehdä huomautuksia ja merkintöjä dokumentteihin. Valitun konejärjestelmän PDM:n
sisältämän tiedon tarkempi selvitys edellyttäisi koneita valmistavan yrityksen PDM:n tutustumisen.
Selvitysraportti
20
2.6. Käyttäjät
Älykäs ja virtuaalinen konelaboratorio soveltuu useille eri käyttäjäryhmille. Käyttäjäryhmien tuntemus on
keskeistä ominaisuuksien ja toiminnallisuuksien määritystä varten. Pilot –ympäristön loppukäyttäjäryhmät
sijoittuvat konejärjestelmien koulutuksen, suunnittelun ja virtuaaliympäristöjen kehityksen kohderyhmiin.
Loppukäyttäjien tarpeiden ja prosessien tuntemus ohjaa osaltaan tutkimus- ja kehitystyötä. On
huomioitava, että pilot –ympäristöä hyödynnetään tutkimuksellisesti, joten konejärjestelmän rajaus,
konelaboratorion ominaisuudet ja käytettävyys eivät täysin vastaa kaikkia tarpeita. Tavoitteena on
kuitenkin kehittää rajattujen sovellusesimerkkejä ja käyttötapauksia, joiden avulla voidaan arvioida
ratkaisujen siirrettävyyttä, laajennettavuutta ja vaikuttavuutta. Keskeiset kohderyhmät on korostettu
kursiivilla.
Koulutus
-
huoltoasentajakouluttajat
huoltoasentajaopiskelijat
operaattorit (soveltuvin osin)
Virtuaalisen konelaboratorion kehitys
-
ohjelmoija
mallintaja ja simuloija
visualisoija
koulutuksellisten ominaisuuksien kehittäjä (ohjelmointi)
konejärjestelmäsuunnittelija (ohjelmointi)
suunnitteluohjelmistokehittäjä
Konejärjestelmän suunnittelu ja virtuaaliprototypointi
-
suunnittelija
mallintaja ja simuloija
testaaja
suunnitteluohjelmistokehittäjä
Käyttäjäryhmien kuvaus on yhteydessä luvun 2.1. prosessikuvausten sekä luvun 2.7. sovellusesimerkkien
kanssa. Nämä kolme lukua luovat yhdessä käyttökontekstin, jonka ymmärrys tukee sekä menetelmälllisten
että teknologisten tekijöiden ymmärrystä.
Selvitysraportti
21
2.7. Sovellusesimerkit
Älykkään ja virtuaalisen konelaboratorion tuotantomenetelmien tutkimuksen ja määrittelyjen tueksi on
laadittu kolme sovellusesimerkkiä käyttötapakuvauksineen, jotka liittyvät hankkeen tavoitteisiin ja kuvaavat
sisältöjä, käyttötapauksia sekä tavoiteltavia toiminnallisuuksia. Sovellusesimerkit perustuvat ohjausryhmän
ja työpajatyöskentelyn tuloksiin. Nämä toimivat vaatimusmäärittelyä tukevina kuvauksina.
Sovellusesimerkki 1. Huoltoasentajakoulutus ja kouluttajan työvälineet
Yleistavoite: Pilot –järjestelmään rakennetaan maanalaisen poralaitteen Jumbon puomiston virtuaalinen
konelaboratorio, jonka avulla koulutetaan sähköhydraulisen konejärjestelmän toimintaperiaatteita,
vianetsintää sekä järjestelmän ominaisuuksia. Pilot –järjestelmä sisältää myös manuaalisen
tunneliporauksen yleispiirteitä. Järjestelmä sisältää kouluttajan työvälineet, joiden avulla kouluttaja voi
laatia, muokata ja hallita esitys- ja vikaskenaarioita sekä havainnollistaa hakujen ja visualisointien avulla
huoltoasentajakoulutuksen tavoitteiden mukaisesti laitteen toiminto- ja komentoketjuja, hydraulipainetta
ja tilavuusvirtaa, ohjausjärjestelmän ja väyläliikenteen yhteyttä sekä keskeisiä mittauksia ja testejä.
Tavoitteena on hyödyntää M1 –teknologioita, jotka on rakennettu mahdollisimman
aineistoriippumattomiksi ja geneerisiksi, jotta uudet mallit, kuvaukset sekä aineistot voidaan liittää
ohjelmiston alustustietoina. Uudet ominaisuudet liittyvät semanttiseen hakuun ja tiedon visualisointiin
sekä kevyesti tunneliporaukseen
Sisältörajaus:







Huoltoasentajakoulutuksen aihepiirit liittyen puomistoon
Laitteen ohjaus ja hallintalaitteet
Puomiston hydrauliikka ja mekaniikka
Puomiston automatiikka, väyläliikenne ja analyysi
Vika- ja ongelmakuvaukset sekä analyysi hydrauliikan ja väylien osalta
Tunneliporaustapahtuma ja operaatiot
Koulutuksen suunnittelu ja toteutus
Tarkempi kuvaus löytyy liitteestä 3.
Sovellusesimerkki 2. Automaattinen generaatio
Yleistavoite: Konejärjestelmään suunnitellaan ja toteutetaan konstruktiomuutos, jota halutaan virtuaalisen
konelaboratorion avulla arvioida ja testata. Sovellusesimerkki 1 ja 2 toimii perustana esimerkki 3:lle.
Fysikaalisen mallin parametrien ja semanttisen mallin avulla voidaan konstruktiomuutokset automaattisesti
toteuttaa. Konstruktiomuutokset ja niiden kuvaukset voidaan hakea ja rajata sekä visualisoida
pilotjärjestelmän avulla. Konstruktiomuutosten vaikutuksia konejärjestelmään arvioidaan konelaboratorion
työvälineillä. Kokemuksia hyödynnetään sekä suunnittelijan että huoltoasentajan koulutuksessa.
Sisältörajaus:

Jumbon puomistorakenne
o Puomiston hydraulipumpun korvaus pienemmällä (liian vähän tilavuusvirtaa) pumpulla.
o Noston toimilaitteen sylinterien mitoitusvaihtoehdot.
Selvitysraportti
o
o
o
o
o
22
Yhdessä sylinterissä on valmistusvika, joka aiheuttaa ulkoisen vuodon.
Konstruktiomuutosten testaus ja arviointi sylintereiden osalta kuumissa +30 ° C ja kylmissä
-25 ° C olosuhteissa sekä pölyisessä ympäristössä.
Konstruktioita arvioidaan lisäksi 1000 h ja 5000 h käytön jälkeen.
Sylinterissä on tiivistevaurio, joka aiheuttaa vuodon kammioiden välille.
Vertailu alkuperäisen konstruktion kanssa.
Tarkempi kuvaus löytyy liitteestä 3.
Sovellusesimerkki 3. Jumbon puomin konstruktiomuutos
Yleistavoite: Konejärjestelmään suunnitellaan ja toteutetaan konstruktiomuutos, jota halutaan virtuaalisen
konelaboratorion avulla arvioida ja testa. Sovellusesimerkki 1 ja 2 toimii perustana esimerkki 3:lle.
Fysikaalisen mallin parametrien ja semanttisen mallin avulla voidaan konstruktiomuutokset automaattisesti
toteuttaa. Konstruktiomuutokset ja niiden kuvaukset voidaan hakea ja rajata sekä visualisoida
pilotjärjestelmän avulla. Konstruktiomuutosten vaikutuksia konejärjestelmään arvioidaan konelaboratorion
työvälineillä. Kokemuksia hyödynnetään sekä suunnittelijan että huoltoasentajan koulutuksessa.
Sisältörajaus:










Jumbon puomistorakenne
Puomiston hydralipumpun korvaus alitehoisella (liian vähän tilavuusvirtaa) pumpulla.
Noston toimilaitteen sylinterien mitoitusvaihtoehdot
Yhdessä sylinterissä on valmistusvika, joka aiheuttaa järjestelmään ulosvuodon ja näin ollen
toimilaitteen puutteellisen toiminnan.
Konstruktiomuutosten testaus ja arviointi sylintereiden osalta kuumissa +30 ° C ja kylmissä -25 ° C
olosuhteissa sekä pölyisessä ympäristössä.
Konstruktioita arvioidaan lisäksi 1000 h ja 5000 h käytön jälkeen.
Sylinterin sisäinen vuoto
Pumppuihin ja moottorien hyötysuhteet.
Suodattimen vaikutus. Suodattimen painehäviö on riippuvainen käyttötunneista/ympäristön
puhtaudesta.
Vertaus alkuperäisen konstruktion kanssa
Tarkempi kuvaus löytyy liitteestä 3.
Selvitysraportti
23
2.8. Aineistot
2.8.1. Poralaiteaineiston yleiskuvaus
Sandvik Mining and Construction Oy antoi suunnitteluaineistoa todellisesta Jumbo-mobiiliporauslaitteesta
Semogen-projektille. Selvitystyössä käytetty aineisto ei vielä täysin kata projektin tavoitteiden kannalta
tarpeellista aineistoa, mutta tähän mennessä saatu aineisto on käyttökelpoista ja antaa mahdollisuuden
tutustua tiedostomuotoihin sekä tiedon esitystapaan ja määrään suunnitteludokumenteissa. Aineiston
merkitys on erittäin suuri, koska sen avulla otetaan kantaa projektin kannalta tärkeimpään
suunnitteluongelmaan eli miten tietojen tuonti suoraan suunnittelujärjestelmästä oppimisympäristöön
toimisi. Materiaalin perusteella voidaan aloittaa järjestelmän mallintaminen ja simulointi. Myös 3Dmateriaalin tuotanto voidaan aloittaa saadun aineiston perusteella.
Hydrauliikkajärjestelmä
Koneesta saatiin kuusi hydrauliikkakaaviota sekä Vertex-tiedostoina että pdf -muodossa. Kaavioista kolme
on tarpeellisia tehdyn konejärjestelmän rajauksen puitteissa. Yksi hydraulikaavioista esittää koneen alustan
(carrier) koneikkorakennetta, josta yhden puomin tarvitseman tehon syöttö on projektin kannalta
tarpeellinen. Lisäksi puomin toimilaitteita ja puomin venttiilistöä esittävät kaaviot ovat tarpeellisia. Vertex
muodossa olevat kaaviot ovat tärkeitä, koska tiedosto sisältää suunnitteluohjelmiston tuottamat viittaukset
ja yhteydet.
Aineistoissa havaittiin suunnittelijakohtaisia eroja. Lisäksi nimeäminen dokumenttien välillä erosi.
Esimerkiksi puomin teleskooppiliikkeestä on käytetty nimikkeitä Boom zoom ja Boom telescope. Osassa
kaavioista nimikkeet suomeksi ja osassa on käytetty englantia. Nimikkeiden hallinta edellyttäisi yhtenäistä
sanastoa. Puomin hydrauliikasta saatu osaluettelo on excel-muodossa. Venttiilistöstä on aineistossa
kaavion lisäksi Bosch Rexrothin yleisesite.
Sähkö- ja väyläsuunnitteluaineisto
Sähkö- ja väyläsuunnitteluaineistoa ei ole vielä tullut, mutta prosessi on määritelty. Väylä kuvataan CAN
Open standardin 311 mukaisesti. Kuvausta hyödynnetään myös oikean konejärjestelmän
väyläsuunnittelussa.
Puomin CAN-väylästä toteutetaan tätä projektia varten hieman oikeasta järjestelmästä yksinkertaistetumpi
versio. Tämä toteutetaan siten, että oikeista DCF-profiileista kootaan projektin kannalta järkevä
kokonaisjärjestelmä, joka tallennetaan eds-formaattiin. DCF-profiilien käsittelyyn käytetyn ohjelman nimi
on ProCANOpen ja eds-tiedostejen lukemiseen voidaan käyttää ilmaista CANeds 3.5 ohjelmaa. Hankkeen
kannalta erittäin positiivinen asia on, että kummatkin formaatit ovat standardisoituneita tapoja käsitellä
CAN-järjestelmiä ja lisäksi tiedostoformaatit ovat ASCII-pohjaisia sekä metatiedolla varustettua tietoa.
3D-mallit
Saadut 3D-mallit esittävät porapuomia ja syöttölaitetta (boom ja feedrail). Alkuperäiset mallit ovat varsin
yksityiskohtaisia. Mallien osien nimeämisen vastaavuus osaluetteloon on tarkistettava. Mallit sisältävät
mekaaniset osat, hydraulisylinterit ja poran ulkokuoret. Mallit sellaisenaan ovat liian yksityiskohtaiset
käytettäväksi reaaliaikaympäristössä.
Selvitysraportti
24
Yleinen materiaali
Yleisestä materiaalista saatiin käyttöohjekirja ja jumbo-sarjan esite. Käyttöohjekirjassa on esitetty koneen
turvallisuusohjeet, käyttötarkoitus, pääkomponentit ja hallintalaitteet sekä ohjelmiston käyttöliittymä.
Tämän lisäksi käyttöohjeista löytyvät varsinaiset käyttöohjeet, operaattorin huolto-ohjeet (päivittäiset
tarkastukset) ja ohjeet mm. koneen hinaukseen ja varastointiin. Puomista ja syöttölaitteesta on lisäksi
tarkempi osaluettelo.
2.8.2. Suunnittelujärjestelmät
Vertex Systems Oy luovutti hankkeen tutkimuskäyttöön Vertex G4 mekaniikkasuunnittelu-, ED
sähkösuunnittelu ja HD - hydrauliikkasuunnitteluohjelmistot, SVG (skaalautuva vektorigrafiikka) –
laajennuksen, käyttökoulutuksen sekä laajan käyttöohjeistuksen.
Suunnittelujärjestelmät mahdollistavat poralaiteaineiston hyödyntämisen alkuperäisessä muodossaan ja
tallennettuna tietokantaan. Tämä tarjoaa mahdollisuuksia ohjelmiston sisäisten viittausten, linkitysten,
sanastojen ja kuvailutiedon hyödyntämiseen. Suunnitteluohjelmistojen tietokantarajapinta vaikuttaa
lupaavalta tuotantoprosessin putkilinjaston kannalta.
2.9. M1 –teknologiaan perustuva ohjelmisto
2.9.1. Ohjelmiston kuvaus
M1-ohjelmisto on yleinen konelaboratorioalusta, jota on kehitetty mm. Metviro ja Lihaako -projekteissa.
Ohjelmiston avulla luodut konelaboratoriot ovat tähdänneet koulutuskäytöön, mutta ovat myös toimineet
tuote-esittelyn ja markkinoinnin välineinä. M1-ohjelmisto perustuu siihen että konelaboratorioalustan ja
koneen tiedot ovat eriytetty toististaan siten että samaa M1-ohjelmistoa voidaan hyödyntää eri koneisiin
perustuvien konelaboratorioiden pohjalla.
M1-ohjelmisto pitää sisällään mm. seuraavia ominaisuuksia/työkaluja:











Kaaviotyökalu (0-n kaaviota)
Virtuaalimaailmatyökalu
Ohjaamo
Huoltokirja/vianhaku
Tutor
Osaluettelot
Muistiinpanot
Mittaukset/säädöt/korjaukset
Äänet
Mittayksiköiden/värien vaihdot
Simulaation nauhoitus ja toisto
Selvitysraportti





25
Tehtävän läpikäynti
Tehtäväeditori
Toimintaketjueditori
Opiskelijaa toimiin mukautuva ohjelmaan upotettu WWW-lisätieto (esim. wiki linkkaus)
Tuki erilaisille simulaatiolle
Näistä ominaisuuksista voidaan jättää tarvittaessa pois eri ominaisuuksia riippuen kunkin konelaboratorion
tarpeesta.
M1-ohjelmisto on rakenteeltaan modulaarinen ja konejärjestelmäriippumaton. Kuvassa 4 on M1ohjemiston rakenteen modulaarisuus kuvattuna. Ohjelmiston monipuolisuus ja joustavuus perustuu
oppimisympäristö ytimeen eli virtuaalinen oppimisympäristö –ohjelmistokehykseen (kuvassa Sofware
framework) joka tarjoa monipuoliset palvelut sisältäen mm. ohjelmiston sisäiset viestiväylät muille
ohjelmiston työkaluille. Työkalut (Kuvassa vaaleansinisellä) toteuttavat käyttöliittymän konejärjestelmän
käsittelyyn. Ne hyödyntävät kehyksen palveluita ja muodostavat kukin oman itsenäisen mutta toisiinsa
linkitetyn palvelunsa käyttäjälle. Nämä työkalut eivät sisällä tietoa konejärjestelmistä ja ovat siten pysyviä
osia M1-ohjelmistossa. Nitä voidaan kuitenkin kytkeä pois käytöstä. Työkalujen käyttämä konejärjestelmä
tieto määritellään ohjelmistosta erillisissa alustustiedostoissa (kuvassa vihreällä). Näillä konekohtaisilla
sisällöillä määritellään mitä konejärjestlelmää M1-ohjelmistsa käsitellään ja vain ne vaihtamalla voidaan
vaihtaa myös koko konejärjestelmä. Kehys ja työkalut tarjoavat myös monia rajapintoja, joilla työkaluja tai
työkalun osia (esim. mittarityyppejä) voidaan lisätä kohtuullisella vaivalla koskematta muuhun osaan
ohjelmistosta.
Selvitysraportti
Kuva 4: M1-ohjelmiston modulaarinen rakenne, jossa erottuvat asetustiedostot (vihreät) sekä
konelaboratorion toiminnallisuudet (vaalean sininen).
26
Selvitysraportti
27
2.9.2. M1-ohjelmiston ominaisuuksia
Konejärjestelmän simulaatio




”Näe liikkuvan koneen sisään”
Realistinen, reaaliaikainen ja dynaamisesti simuloitu konejärjestelmä
Toiminta muokattavissa ajonaikaisesti parametrien avulla, esimerkiksi vikoja ja säätöjä asemalla
Voidaan mallintaa viat, testit, havainnot ja toiminnot
Virtuaalinen ja dynaaminen kaavio




Kaavion vapaa liikuttelu ja tarkennus ruudulla
Komponenttien piirrosmerkit ja nimet
Simulaatioon perustuva öljyn paineiden ja virtauksen, sähkön jännitteen ja virran sekä liikkeiden
visualisointi
Mittaus- ja korjausmahdollisuudet
Virtuaalinen ja dynaaminen kone









Paine- ja virtaushavainnollistukset
Dynaamisten toimintojen visualisointi
Korostukset ja valinnat yhteistoiminnassa muiden työkalujen kanssa
Realistisesti toimiva ja kolmiulotteinen konejärjestelmä
Komponenttien tarkastelu läpinäkyvänä ja/tai leikattuna
Käyttöä tukevat valmiit oletuskuvakulmat
Liikeajojen tallennus ja tarkastelu hidastettuna, nopeutettuna, pysäytettynä sekä askeleittain
Koneen äänet ja niiden mukautuminen koneen tilaan
Osaluettelo ja osien yhteys kaavioon ja virtuaaliseen koneeseen
Virtuaaliset huoltotoimenpiteet



Konejärjestelmän toimintaan vaikuttaminen ohjauksen, säätöjen ja korjauksien avulla
Aidonkaltaiset ja järjestelmän toiminnan kannalta oleelliset mittauskohteet, mittarit ja testit sekä
mittayksiköt
Korjausten tekeminen ja niiden vaikutusten esittäminen
Vianhaun älykäs tuki




Vianetsintäprosessin järjestelmällisen etenemisen oikea-aikainen tuki ja ohjaus
Opiskelun ja oppimisen ajatteluprosessin tukeminen suuntaa-antavien vihjeiden ja
toimintaehdotussten avulla
Opiskelijan käsitteellisen ja toiminnallisen mallin kehityksen tukeminen
Vaikuttamismahdollisuus saatavilla olevaan tukeen
Pedagogiset työvälineet



Rikkaat havainnollistamismahdollisuudet aihepiirien opetukseen
Kouluttajan työvälineet tehtävien laatimiseen ja muokkaamiseen sekä oppimateriaalien hallintaan
Kieliversiointimahdollisuus
Selvitysraportti





28
Järjestelmällisen vianetsinnän tuki ja hallinta
Lisätietoa järjestelmän rakenteesta, toiminnasta, vioista, testeistä ja korjauksista
Opiskelijan ajatteluprosessin ulkoistamisvälineet
Vianhaun muistiinpanojen ja etenemisen työvälineet
Tehtävien arviointi ja läpikäynti
2.9.3. Tekninen kuvaus
Ohjelmisto on tehty .NET framework ympäristöön ja se edellyttää koneesta Windows käyttöjärjestelmää
(XP, Vista, 7) ja .NET framework 2.0 kirjastoa. Ohjelman pitäisi myös toimia Linux+Mono ympäristössä, jos
siihen tehdäisiin pieniä muutoksia ja otettaisiin muutama ominaisuus pois käytöstä. 3D-ympäristö käyttää
Ogre3D-kirjastoa, joka on avoimen lähdekoodin 3d grafiikkamoottori. Mm. Ogre3D ja kaavion piirto
puolestaan hyödyntävät DirectX-rajapintaa. M1-ohjelmisto vaatii siten toimiakseen DirectX 9.0C
(Maaliskuu 2009 tai myöhempi) ajoympäristön asennettuna koneelta. Lisäksi näytönohjaimen on oltava
suht tehokas jotta ohjelmiston käyttö olisi jouhevaa. Esimerkiksi kannettavan tietokoneen yhdysrakenteiset
näytönohjaimet (lähinnä Intel-merkkiset) ovat osoittatuneet testeissä useimmiten liian heikkotehoiseksi.
Näyttölaitteeksi suositellaan kahta monitoria tai laajakuvamonitoria riittävällä resoluutiolla, mutta käyttö
onnistuu myös yhdellä näytöllä tai videoprojektorilla.
2.9.4. Dynaaminen kaavio
Kaavio on kaksiulotteinen piirustus, joka tarkastelee asiaa tietystä rajatusta näkökulmasta. Kaavioon on
suodatettu tarkasteltavasta asiasta ainoastaan sen käytön kannalta oleelliset tiedot. Dynaamisuudella
kaavio saadaan esittämään simuloidun koneen tilatietoa. Lisäksi kaavioon voidaan lisätä käyttäjän
kulloistakin toimintaa tukevia tilatietoja, kuten vianhaun tilaa ja havainnoinnin kohdetta.
Nykyisessä M1-teknolgiaan perustuvassa ohjelmistossa tuotantoprosessi dynaamisen kaavion osalta kattaa
seuraavat viisi vaihetta:
1.
2.
3.
4.
5.
Kaavioiden hankinta
Kaavioiden uudelleenpiirto svg-muotoon
Kaavioiden komponenttien merkkaus ja ryhmittely
Komponenttien nimeäminen
Dynamiikan sidonta
Vaiheissa on yleensä hieman päällekkäisyyksiä ja välillä joudutaan palamaan takaisinpäin. Tämä vaiheistus
on kuitenkin hyvä ajatusmalli prosessista. Seuraavaksi on esitelty eri vaiheiden tarkemmin kuvaus:
1. Vaihe
Hankitaan konejärjestelmään liittyvät kaaviot. Tällä hetkellä on käytetty pdf-muotoisia tai paperilla olevia
kaavioita.
2. Vaihe
Nykyisin on käytetty Inkscapea, jolla piirretty sähkökaaviot käsin uudelleen svg-muotoon. Kaavioita on
karsittu ja valittu tärkeimmät komponentit, jotka piirretään. Toisena tapana on käytetty käsin kirjoitettuja
svg-piirtoalkioita, joista on kasattu käsin koostamalla kaaviot, jotka vastaavat haluttua kaaviota. Lisäksi
tässä vaiheessa on jouduttu miettimään kaavioon liittyvää dynamiikkaa, koska liikkeet vaativat hieman
tilaa. Tätä ei yleensä ole alkuperäisessä kaaviossa huomioitu.
Selvitysraportti
29
3. Vaihe
Svg-kaavioon on lisätty dhd:set -elementtejä, joilla kaavion komponentteja voidaan ryhmittää toimiviksi
kokonaisuuksiksi.
4. Vaihe
Kirjoitetaan erilliseen kielitiedostoon nimet komponenteille. Nimet sidotaan komponentin key attribuuttiin.
5. Vaihe
Kaavioon kirjoitetaan lisätyt dynamiikansidonnat, joilla määritetään mikä simulaation parametri arvo
vaikuttaa mihinkin piirtoalkioon minkä liiketyylin mukaisesti. Tässä vaiheessa on tiedot on myös sidottava
avaimiin, jotka on luotu system.xml-tiedostoon simulointisignaaleista.
2.9.5 3D-mallien tuonti M1-ohjelmistoon
Nykyinen tuotantoprosessi kattaa 10 vaihetta:
1. 3D-mallien hankinta ja / tai piirtäminen
2. 3D-mallien siirto CAD-ohjelmasta renderöinti-ohjelmaan
3. 3D-mallien kevennys
4. 3D-mallien teksturointi ja / tai materiaalien muokkaus
5. 3D-mallien osien nimeäminen ja ryhmittely
6. 3D-mallien kinematiikkaketjun dynaaminen sitominen animointia varten
7. Yksittäisten mallien yhdistäminen virtuaalimaailmaksi
8. Maailman osien näkyvyyden määrääminen näkyvyysbiteillä
9. Virtuaalimaailman tuonti renderöintiohjelmasta Ogre3D?-yhteensopivaan muotoon
10. Animoinnin alustustiedoston muodostaminen
1. Vaihe
3D-mallit tuotetaan koneiden ja / tai hydraulikomponenttien suunnittelu- ja valmistusprosessissa syntyvien
CAD-mallien pohjalta. Koneen ollessa kysymyksessä CAD-mallit voivat olla ns. pintamalleja
esittelytarkoitukseen, jotka esittävät koneen vain ulkoasun yksinkertaistettuna tai mallit voivat tuotantoon
tarkoitetut mallit koneesta, jolloin niistä joudutaan karsimaan yksityiskohtia. Hydraulikomponenttien
ollessa kysymyksessä käytetään komponentin kokoonpanomalleja tai mikäli näitä ei ole käytettävissä,
komponentin runkomalliin ( ulkoiset mitat ), lisätään sisällön 3D-mallit tuottamalla ne itse. 3D-mallien
tuottaminen itse vaatii mittatietoa ja kuvia mallinnettavasta komponentista.
2. Vaihe
CAD-mallit siirretään tietyssä formaatissa renderöintiojelmaan, joka on esim. 3DSMax tai Blender.
Siirtoformaatteina käytetään joko .wrml tai STL (StereoLitho?)-formaattia. Kummassakin siirtoformaatissa
on puutteita, WRML-hukkaa osien nimeämisen, mutta säilyttää osien materiaalit ja STL vastavuoroisesti
säilyttää nimeämisen, mutta hukkaa materiaalit. STL-formaatissa voidaan vaikuttaa muotojen tarkkuuteen
jo siirtovaiheessa.
Selvitysraportti
30
3. Vaihe
Renderöintiohjelmassa mallien muototarkkuutta heikennetään, joilloin mallien piirto kevenee. Mallit
koostuvat tässä vaiheesta kolmioista muodostuvasta verkosta, jonka kolmioiden määrää pyritään
vähentämään. Kolmioiden vähennys tapahtuu joko renderöintiohjelman automaattisella työkalulla tai
kokonaan piirtämällä 3D-malli käsin uudestaan. Automaattiselle työkalulle annetaan kynnysarvo, jota
lähempänä olevat kolmioiden kärkipisteet ( vertexit ) yhdistetään yhdeksi pisteeksi. Tulos tarkastetaan
silmämääräisesti ja kynnysarvoa suurennetaan tai pienennetään tarvittaessa. Yksittäisistä osista saadaan 10
- 80 % kolmioista poistettua ja osakokoonpanoissa pyritään 30 .. 50 %:n välille kolmioiden alkuperäisestä
määrästä.
4. Vaihe
Teksturointivaiheessa malleille annetaan meteriaalit. Mikäli malli on tuotu renderöintiohjelmaan
teksturoituna, eri pintojen samanlaiset materiaalit muokataan samannimisiksi. Siirtoformaatti käsittelee
jokaisen pinnan tekstuuria yksittäisenä materiaalina, vaikka se olisi identtinen muiden materiaalien kanssa.
Mikäli mallia ei ole tuotu teksturoituna, mallille annetaan materiaali. Jos mallissa tarvitaan virtauspintojen
teksturointia, jota ei ole tehty CAD-ohjelman puolella, se on tehtävä renderöintiohjelmassa valitsemalla
käsin virtauspinnan muodostavat kolmiot ja asettamalla niille oikea tekstuuri. Yksittäisille malleille
määrätään UV-koordinaatit, jotta tekstuurien valo-ominaisuudet toimivat oikein virtuaaliympäristössä.
Tähän on automaattinen työkalu renderöintiohjelmassa.
5. Vaihe
Nimeämisvaiheessa jokaiselle mallille annetaan uniikki nimi. Nimi muodostetaan useimmiten osaluettelon
osanumeroinnin perusteella. Oppimisympäristöön vietävässä kokonaisuudessa ei saa olla saman nimisiä
osia. Ryhmittelyssä yksittäisistä osista muodostetaan ryhmiä, jotka esittävät jotakin osakokonaisuutta.
6. Vaihe
Kinematiikkaketjun sitomisella tarkoitetaan mallien sitomista toisiinsa animointia varten. Jokaiselle mallille
määrätään keskipiste, jonka ympäri malli kääntyy. Mikäli tätä ei ole määrätty, malli kääntyy oletusarvoisesti
maailman origon ympäri. Mallin lokaalien akselien suunta määrätään keskipisteen orientaatiota
muuttamalla. Tämä helpottaa esimerkiksi viistoon liikkuvien kappaleiden animointia. Mallien sidotaan
tiettyyn koordinaattiin isäkappaleen keskipisteeseen nähden. Tällöin lapsikappaleen keskipiste on
sijoitettava nivelpisteeseen. Työ tehdään käsityönä.
7. Vaihe
Yksittäiset mallit
virtuaalimaailman.
sijoitellaan
samaan
työtilaan
renderöintiohjelmassa,
jotta
ne
muodostavat
8. Vaihe
Jos virtuaalimaailmasta käytetään oppimisympäristössä useampaa erinäkymää, malleille määrätään
näkyvyysbitit sen mukaan missä näkymissä niiden kuuluu näkyä. Mikäli mallilla on 2 tai useampia
vaihtoehtoisia malleja, vaihtoehtoiset mallit määrätään piilotetuiksi export-pluginin asetuksista. Työ
tehdään käsityönä.
Selvitysraportti
31
9. Vaihe
Virtuaalimaailma käännetään ogre-yhteensopivaan muotoon export-pluginilla automatisoidusti. Exportpluginin tuottaman scene-tiedoston nimen on oltava sama kuin oppimisympäristön system.xml:ssä
määrätty tai oppimisympäristön system.xml-tiedostoa on muokattava. Exporttauksen tuottamat tiedostot
siirretään tyyppinsä mukaisesti paikoilleen oppimisympäristön työhakemistoon. XML-pohjaista
materiaalitiedostoa muokataan tarvittaessa materiaalien ulkoasun parantamiseksi.
10. Vaihe
Virtuaalimaailman animoinnit tapahtuvat simulointimallilta tulevan liiketiedon perusteella. Animointja
varten tehdään alustustiedosto, jossa määrätään funktiot minkä mukaan eri mallit liikkuvat maailmassa.
Alustustiedoston formaatti liitteenä. Animointien toteutus tehdään käsin ja funktioiden kertoimia
säädetään visuaalisen palautteen perusteella.
2.9.6 Toimintopuun ja -ketjun luonti M1-järjestelmässä
Toimintopuu-käsitteellä tarkoitetaan konejärjestelmän kuuluvien komponenttien ja toimintojen
linkittämistä puumaiseen rakenteeseen. Toimintapuun rakentamista varten on tehty editori, jonka avulla
puuta voidaan rakentaa graafisen käyttöliittymän avulla. Toimintapuu mahdollistaa esimerkiksi vikojen
konejärjestelmään aiheuttamien muutosten listaamisen ja linkittämisen. Esimerkiksi luodaan vika
työhydrauliikanpumppuun, josta heijastuu ongelmia järjestelmän paineisiin, tilavuusvirtoihin ja lopullisesti
vika voidaan havaita järjestelmätasolla toimilaitteiden liikkumattomuutena.
Toimintoketju on käsitteenä hyvin lähellä toimintopuuta, mutta on vianhausta askel toimintojen linkityksen
havainnollistamiseen ja opettamaan miten konejärjestelmän komentoketjut toimivat. Toimintoketjujen
muodostamiseksi on olemassa myös oma editori. Käyttöliittymä on graafinen ja sen avulla käyttäjä voi
luoda haluamiansa toimintoketjuja, jotka voivat olla lyhyitä ja yksinkertaisia tai pitkiä ja sisältäen kaikki
mahdolliset toimintoketjuun liittyvät havainnollistukset. Kaaviota, 3D:tä, osaluetteloa jne. käytetään
toimintaketjun visualisointiin toimintaketjutyökalun tahdittamana. Vaiheeseen liittyvät piirrosmerkit
(toiminta tai komponentti) korostetaan, kohdistetaan tarvittaessa ja muokataan dynamiikan
ohjauskomennoilla. Teknisesti kaavio toimii samalla lailla kun tavallistakin simulaatiota ajettaessa. Alla on
esitetty esimerkkinä; noston toimintaketjun esittäminen vaiheistuksen avulla -skenaario. Nostoliike
aloitetaan ja päättyy siihen, kun puomi alkaa nousta. Alkutilanne: Kone: pumppu lähes nollakulmalla
(tasapainotila ilman kuormitusta, paitsi kompensoi vuodot), paineet tyhjäkäynnillä, puomi kuormatilassa,
öljy lämmintä, kone tasaisella kentällä. Tarkasteltavat työvälineet; sähkökaavio, hydraulikaavio, 3D,
ohjaamo:
1. Kuljettaja käyttää ohjausvipua sähkökaavio: ohjain siirtyy uuteen asemaan ohjaamo: ohjain siirtyy uuteen
asemaan
2. Signaali siirtyy ohjaimelta ohjainmoduulille sähkökaavio: linja näkyy aktiivisena
3. Ohjainmoduuli muokkaa ohjausta kuljettajan säädöillä sähkökaavio: moduuli aktiivisena prosessoimassa
jotain
4. Signaali siirtyy ohjainmoduulita nosturin moduulille (CAN-väylä) sähkökaavio: linja näkyy aktiivisena
5. Nosturin moduuli (VBU) muuntaa signaalin venttiilille sähkökaavio: moduuli aktiivisena
6. Signaali siirtyy nosturin moduulilta noston esiohjausventtiilin kelalle. sähkökaavio: linja näkyy aktiivisena
(analogisen signaalin suuruus)
7. Kela virroittuu ja tuottaa voimaa karalle hydraulikaavio: kelan väri muuttuu suhteessa virtaan (mitä
isompi pinta-ala kelasta väritetty, niin sitä suurempi virta)
Selvitysraportti
32
8. Esiohjauskara siirtyy siihen asemaan, että paine esiohjauksen painekanavasta välittyy toimilaitekanavaan
(linja aukeaa; venttiilin tilasta 1 tilaan 2) hydraulikaavio: piirrosmerkin kara siirtyy uuteen asemaan
9. Pääkaran ohjauskanava paineistuu (huomioi kuristus) hydraulikaavio: linja väritetään painetta vastaavalla
värillä
10. Pääkara siirtyy LS-linjan avaavaan asemaan hydraulikaavio: piirrosmerkin kara siirtyy uuteen asemaan
11. LS-linja paineistuu karalta noston vaihtovastaventtiilille hydraulikaavio: linja väritetään painetta
vastaavalla värillä
12. Noston vaihtovastaventtiili valitsee suuremman signaalipaineen välitettäväksi eteenpäin hydraulikaavio:
vvv-pallo siirtyy oikeaan laitaan
13. Signaali siirtyy nostonlohkosta painepäädyn kopiokaralle hydraulikaavio: linja väritetään painetta
vastaavalla värillä
14. Kopiokara säätää lähtevän signaalipaineen vastaamaan sisäistä LS-linjan painetta. hydraulikaavio:
piirrosmerkin kara siirtyy uuteen asemaan
15. Signaalipaine siirtyy venttiililohkolta pumpun säätimelle kuristuksen kautta. hydraulikaavio: linja
väritetään painetta vastaavalla värillä
16. Pumpun virtaussäädin säätyy signaalipainetta ja pumpun ohjaussylinterissä vallitsevaa painetta
vastaavaan tasapainotilaan. hydraulikaavio: piirrosmerkin kara siirtyy uuteen asemaan (vasemmalle)
17. Paine ohjaussylinterin männänpuolella laskee. hydraulikaavio: linjat ja kammio väritetään painetta
vastaavalla värillä (sininen)
18. Pumpun kulma suurenee hydraulikaavio: pumpun säätönuoli kiertyy myötäpäivään
19. Paine painelinjassa kasvaa hydraulikaavio: linja väritetään painetta vastaavalla värillä
20. Nostoventtiilin pääkara siirtyy yhdistäen painelinjan ja toimilaitteen kanavat
21. Virtaus alkaa ja sylinteri liikkuu
22. Puomi liikkuu
2.9.7. CAN/Sähkösimulaatio
Nykyinen tuotantoprosessi CAN- ja sähkösimuloinnin osalta kattaa kolme vaihetta:
1. Tiedon ja materiaalin keruu laitevalmistajilta
2. Toimintalogiikan suunnittelu ja toteutusvaihtoehtojen kartoittaminen
3. Toimintalogiikan koodaus eli CAN- ja sähköjärjestelmien simulointi
Selvitysraportti
33
3. Tuotantomallien ja -menetelmien kehitysehdotuksia
3.1. Semanttisen mallinnuksen käytännön näkökohtia
SemoGen-hankkeessa käytännöllisiä mallinnuksen ja tutkmuksen näkökohtia ja haasteita muodostavat
erityisesti seuraavat huomiot:
1. Semanttinen mallinnus (ja integrointi) perustuu pitkälti avainrakenteisiin. Lähdeaineiston
rikastaminen tarkoittaa tästä näkökulmasta katsottuna erityisesti avainrakenteiden
kirjaamista ja hallintaa; semanttinen mallinnus voidaan siten suorittaa varsinaisten
suunnittelujärjestelmien "ulkopuolella".
2. Aineiston esikäsittely/harmonisointi tyypillisesti edellyttää myös suunnitteluprosesseissa
tapahtuvia muutoksia, ts. pelkkä tekniikoiden esittely ei riitä vaan tarvitaan myös muutoksia
työtavoissa.
3. Semanttisen mallinnuksen erittäin hyödyllinen "esiaste" ovat erilaiset taksonomiat ja
asiasanastot. Monimutkaisempi formaali käsitemallinnus kannattaa todennäköisesti aloittaa
vasta kun esim. taksonomioiden hyödyt on otettu käyttöön projektissa. Monimutkaisten
semanttisten mallien arkikäytön suurin haaste lienee järjestelmien hyväksyttävyys (erit.
virheetön toiminta, ymmärrettävyys ja läpinäkyvyys). Käytännön nyrkkisääntö on kuitenkin
se, että mitä monimutkaisempi malli on, sitä vaikeampi loppukäyttäjän on sitä ylläpitää ja
ymmärtää.
4. Tyypillisiä aihepiirin kehitysprojektien kriittisiä haasteita ja riskejä ovat epäselvät
käyttötapaukset/kohdesovellukset (esim. liian abstraktit tavoitteet/mittarit), aineistossa
tapahtuvat skeematason muutokset (esim. suunnittelijan vaihtuessa semanttinen
nimikkeistö muuttuu odottamattomasti), ja inhimilliset tekijät (esim. ymmärretään mallin
tarkoitus väärin ja tietoa syötetään virheellisesti).
Em. näkökohtien huomiointi on erityisen tärkeää määrittelyvaiheessa. Ideaalitilanteessa semanttisen
mallinnuksen kohdesovellukset iteroidaan sidosryhmien kanssa ennen varsinaiseen sovelluskehitykseen
ryhtymistä. Tämäntyyppisen ongelmat korostuvat erityisesti implementointipainotteisissa projekteissa,
eivät niinkään tutkimushankkeissa. Tästä syystä aihepiirin tutkimukselliset tavoitteet ja
implementointitavoitteet on syytä jäsentyneesti eritellä hyvissä ajoin.
3.2 SemoGen-hankkeen erityispiirteet
Semanttisen mallinnuksen (ja laskennan) rooli SemoGen-projektissa on rajattu kahteen keskeiseen
käyttökohteeseen, jotka ovat:
1. Virtuaalilaboratorion generointi
2. Loppukäyttäjän sovellukset
Tässä tulkintana on se, että semanttinen mallinnus ja laskenta tarjoavat projektin käyttöön/tietoisuuteen
tiedon mallinnusfilosofian, tietokanta/SemWeb-tekniikoita, sekä dataprosessori/putkilinjastotekniikoita.
Varsinaiseen "älykkyyteen" ei laskenta-alustan tasolla tähdätä, vaan kyse on pikemminkin hyödyllisen
tiedon rikastamisesta/käytöstä hyvin määriteltyjen sovellusten tehokkaan toteutuksen tukena.
Selvitysraportti
34
Generoinnilla pääpaino on sovellustiedon semanttisessa rikastamisessa siten, että halutuntyyppisen
tietosisällön omaavan virtuaalilaboratorion aihio voidaan oleellisesti "tulostaa" annetun abstraktin
kuvauksen perusteella. Loppukäyttäjän sovelluksissa semanttista tietoa voidaan puolestaan hyödyntää
esim. semanttisten haku- ja annotointivälineiden osalta jotka tarjoavat laajalti integroidun näkymän
saatavissa olevaan tietosisältöön.
Käytännön toteutuksen näkökulmasta käsitemallin ylläpito jakautunee suunnitelijan oletusvälineiden
(kuten Vertex-suunnitteluohjelmat) ja erityisesti käsitemallien suunnitteluun tarkoitettujen välieiden
kesken (erit. Protege, ks. http://protege.stanford.edu/). Kyselysovellusten toteutuksen perusjärjestelmä on
tyypillisesti Java-pohjainen Jena (ks. http://jena.sourceforge.net/), joka tarvitsee tuekseen päättelykoneen
(esim. Pellet, ks. http://clarkparsia.com/pellet/). Perusväline putkilinjastojen toteutukseen on esim. Apache
Ant (ks. http://ant.apache.org/).
Em. Java-pohjaiset sovellukset ja kehitysympäristöt ovat saatavilla Open Source-lisenssein. Mikäli
kehitystyössä päädytään esim. C#-tekniikoihin, vastaavia tuotteita löytyy seuraavasti. Semanttisen mallin
käsittelyyn käy esimerkiksi OwnDotNetApi-kirjasto (http://users.skynet.be/bpellens/OwlDotNetApi/), joka
on lähes ainut OWL-api .NET frameworkiin. Eräs vaihtoehto on tehdä kehitys pääosin .NET pohjaisesti,
mutta hyödyntää semanttisen mallin käsittelyssä edellä mainittuja ohjelmistoja oman ohjelmiston kautta.
3.3. Tietojen tuonti suunnittelujärjestelmistä
Oikein toteutettuna ja parametrisoituna osa simulointimalleista on mahdollista käyttää geneerisesti hyväksi
luotaessa uusia järjestelmämalleja. Ihminen tekee samoin mallintaessaan järjestelmiä. Hänelle on kertynyt
eri mallinnusprosessien aikana tietoa ja taitoa sekä vanhoja komponenttisimulointimalleja. Näitä kaikkia
ihminen käyttää hyväkseen tehdessään uusia malleja järjestelmistä. Samaa periaatetta voidaan soveltaa
tietokoneiden käytettäväksi eli kirjastoidaan geneerisiä komponentteja kuvaavia simulointimalleja, joita
voidaan parametrisoimalla muokata ja liittää järjestelmiksi. Parametritietoja on rajallisesti mahdollista
poimia koneellisesti suoraan suunnittelujärjestelmistä. Ihmisen on kuitenkin siis vielä puututtava prosessiin.
Ensimmäisessä mallinnusvaiheessa tämä pitää huomioida ja yrittää parametrisoida mallit saatavilla olevan
tiedon mukaan. Lisäksi on huomioitava geneeristen mallien erityistarpeet.
* Mallit eivät saa olla liian primitiivisiä parametrisoinnin näkökulmasta
o Tällainen voisi olla vaikka siirtofunktiolla mallinnettu sylinteri eli sylinterimalli ilman
männänhalkaisijaparametria
o Pitäisi kehittää laskukaava uuden siirtofunktion laskemiseksi vastaamaan uutta
sylinterikokoa
* Edellistä tulisi välttää ja mallit pitäisi parametrisoida saatavilla olevan tiedon mukaisesti mallintaa
o Parametrisoida mallit sillä tarkkuudella mitä suunnittelujärjestelmistä on normaalisti
saatavilla
o Esimerkiksi ei tarvita parametria erikseen kitkoille, jos tällaista tietoa ei ole
suunnittelujärjestelmistä saatavilla
Selvitysraportti
35
o Tällaiset parametrit pitää laskea generointivaiheessa perustuen johonkin muuhun
parametriin (sylinterin halkaisija)
Aiemmin luvussa 2.4. kuvattiin mitä tietoa mallinnettaessa järjestelmiä tarvitaan ja mistä tieto yleensä
löytyy. Ihmisellä, joka toimii mallintajana on kyky lukea hydraulikaaviota ja CAD-kuvia. Tietokoneelle tämä
voi olla hankalaa, koska tietoa ei ole aina kuvattu tarpeeksi rikkaalla kuvauksella. Tämän takia tietokoneen
lukiessa suunnittelujärjestelmistä saatavaa tietoa (esim. hydraulikaaviota) voi ongelmaksi muodostua eri
komponenttien tunnistaminen ja niistä saatavilla olevan tiedon tulkitseminen. Teoriassa on kuitenkin
mahdollista kuvata suunnittelujärjestelmissä tietoa riittävän rikkaasti, sen käyttämiseksi mallinnuksen
pohjana.
Kuva 5: Ehdotus simulointimallin automaattisen generaation työvaiheiksi
Tieto suunnittelujärjestelmistä ja -dokumenteista tuotaisiin simulointimalliin ja virtuaaliympäristöön
käytännössä jonkinlaisen importerin kautta. Importeri lukee semanttisesti järkevästi merkatun tiedon ja
antaisi tässä vaiheessa käyttäjälle mahdollisuuden rikastuttaa ja modifioida kerättyä informaatiota. Tämän
jälkeen ohjelma pystyisi tuottamaan semanttisen kuvauksen konejärjestelmästä. Tällaisen kuvauksen
pohjalta voitaisiin seuraavaksi koota geneerisistä simulointimalleista kokojärjestelmää kuvaava malli, jonka
parametrit olisivat kerätty suunnittelujärjestelmästä. Osa parametreista voisi siis olla kiinteitä suoraan
suunnittelujärjestelmästä, osa käyttäjän antamia generointivaiheessa ja loput osittain muokattavissa
reaaliaikaista simulointia ajettaessa.
3.3.1. Tiedon keräys suunnittelujärjestelmistä ja jatkokäsittely
Semogen pilottijärjestelmän tarvitsema tieto on kerättävä useasta eri lähteestä. Näitä lähteitä ovat mm.
suunnittelujärjestelmät ja tuotetiedonhallintajärjestelmät. Näissä järjestelmissä olevat tieto on koottava
yhtenäiseksi, jotta sitä voidaan hyödyntää pilottijärjestelmässä. Tiedon saamiksesi järjestelmästä tiedon
oltava joko luettavassa muodossa tai järjestelmässä on oltava rajapinta, jonka kautta tarvittava tieto
voidaan hakea järjestelmästä. Luettavilla muodoilla tarkoitetaan esimerkiksi ASCII- tai xml-muotoista tietoa
tai muuten semanttista muotoa, jota voidaan lukea tarkoitukseen rakennetulla lukijalla, parserilla.
Kerättävän tiedon pohjana voidaan käyttää osaluetteloa, joka toimii syötteenä semogen-pilottijärjestelmän
luku- ja keräilyosalle. Tämä ’masterparser’ kerää tarvittavat tiedot joko rajapintojen tai erilaisten lukijoiden
Selvitysraportti
36
kautta ja jakaa ne sitten eri ohjelmiston työkalujen generointiin erikoistuneille osioille (LabGen). Mikäli
käyttäjän syötettä tarvitaan tiedon rikastamiseen se tapahtuu erikoistuneiden osioiden kohdalla.
3.3.2 Tapaus: Kaaviotiedon mekaaninen tuonti SemoGen-järjestelmään
Suunnittelutiedon mekaanisen käsittelyn näkökulmasta erittäin keskeisiä kysymyksiä ovat lähdeaineiston
rakenteisuus, aineiston sisäiset ja ulkoiset viittaukset, sekä aineiston elinkaaren ja keskeisten
suunniteluratkaisujen tunnistaminen.
Seuraavassa tarkastellaan esimerkinomaisesti tietojen tuontia Vertex ED – suunnittelujärjestelmästä,
perustuen Vertexin toimittamaan esimerkkiaineistoon. Esimerkki edustaa ns. hyvää tapausta, so. tilannetta
jossa lähdeaineiston formaatti ja rakenne ovat tunnettuja ja (rakenteisen export-toiminnon ansiosta)
helposti luettavissa. Tilanteessa jossa suunnittelutietoa joudutaan lukemaan "toissijaisesta"
lähdeaineistosta (esim. suunnitteluaineiston pohjalta generoitu PDF) aineiston jäsentäminen saattaa olla
huomattavasti hankalampaa.
Aineisto (Export SVG)
Kuva 6 esittää Vertex ED -esimerkkikaaviota SVG Export toiminnon jälkeen Firefox-selaimessa. Kuvasta
nähdään kaavion komponentteja, yhteyksiä ja merkintöjä.
Kuva 6: Esimerkkikaavio Vertex ED SVG Export toiminnon jälkeen (symbolin K2 korostus ellipsillä ei kuulu
lähdeaineistoon vaan ainoastaan tässä korostaa seuraavassa tarkasteltavaa kuvan osaa)
Kuvan tuotantoprosessi on periaatteessa yksinkertainen: Suunnittelija on ensin työstänyt kuvan Vertex ED –
suunnitteliohjelmassa, minkä jälkeen kaaviosta on tuotettu suunnitteluohjelman export-toiminnolla SVGkuva.
Suunnittelijan tekemillä mallinnuksen valinnoilla ja työtyylillä saattaa kuitenkin olla huomattava merkitys
suunnittelutiedon mekaanisen lukemisen onnistumisen näkökulmasta: SVG-kuvasta on tietenkin luettavissa
Selvitysraportti
37
vain kaavioon erikseen piirretty, kirjoitettu ja ryhmitelty tietoaineis, ei suunittelijan hiljaista tietoa esim.
komponttien yhteyksistä ja rooleista suunnitteluratkaisussa, eikä tietoa ulkoisten viittausten takana
vaikuttavista käsitemalleista yms.
SVG, eli Scalable Vector Graphics, on W3C:n suosittama, laajennettavissa oleva teknologia vektorigrafiikalle
(ks. http://www.w3.org/TR/SVG11/). Mekaanisen luettavuuden näkökulmasta SVG on hyvä ratkaisu sillä
sen kirjaaman rakenteisen tiedon lukemiseen ja jäsentämiseen soveltuu periaatteessa mikä tahansa XMLasiakasohjelma (tai sellainen voidaan helposti toteuttaa valmisjäsentimiin perustuen). Varsinaiseen vektorija kaaviotiedon semantiikan tulkintaan tarvitaan tietenkin SVG-sanaston ja sen export-toiminnossa
määrittelemien (kaaviospesifien) Vertex-laajennusten tuntemusta (ks. @REF VertexED-SVG_semogen.doc).
Esimerkkijärjestelmä suunnittelijan näkökulmasta
Kaaviossa on esitetty suurempaan hydraulijärjestelmään kuuluva yksittäinen sylinteritoimilaite sekä
toimilaitteen ohjaukseen käytettävät komponentit. Kaksitoimista epäsymmetristä sylinteriä S1 ohjataan
sähköisesti ohjatulla 4/2- suuntaventtiilillä V10. Suuntaventtiilin tyypin takia sylinterin mäntää ei voida
asemoida väliasemiin vaan sylinteri liikkuu aina joko täysin sisään tai täysin ulos. Toisin sanoen painelinja on
aina avoin joko sylinterin A-kammioon tai B-kammioon riippuen suuntaventtiilin asemasta ja venttiilin
avulla hallitaan vain sylinterin liikesuuntaa. A-puolen letkuun on lisäksi liitetty painekytkin K2, josta
saadaan signaali kun A-linjan paine ylittää kytkimeen asetetun raja-arvon. 4/2- suuntaventtiilin solenoidin
ohjaussignaali löytyy kaaviosta A01:2/24 ja signaali on nimetty ref_V10. Suuntaventtiilin tankkilinja on
liitetty suoraan T1-tankin f-liitäntään. Tämän linjan kautta palautetaan sylinteriltä poistuva tilavuusvirta
tankkiin.
Suuntaventtiilille V1 tulevassa painelinjassa vallitsevaa painetta säädetään paineenalennusventtiilillä V8,
jolla varmistetaan että paine ei nouse missään vaiheessa liian suureksi suuntaventtiilissä tai sylinterissä.
Välissä on vielä pikaliitäntä X3, johon kytkettävä asia on kuvattu kaaviossa 2/12 ja on kytketty linjaan, jonka
nimi on ref_x3. Ennen paineenalennusventtiiliä painelinjasta löytyy jousikuormitettu vastaventtiili V7.
Tämän venttiilin avulla estetään öljyn kulkeutuminen väärään suuntaan paineen laskiessa ennen venttiiliä.
Tällä venttiilillä myös varmistetaan, että syöttöpaine venttiilinV7 A-linjassa nousee riittävän korkeaksi
ennen kuin venttiili avautuu.
Ennen vastaventtiiliä V7 järjestelmästä löytyy toinen painekytkin K1. Lisäksi samasta linjasta löytyy myös
paineakku T2, jolla varmistetaan sylinterin toiminta silloin, kun järjestelmään ei syötetä riittävästi
tilavuusvirtaa. Akku voi toimia myös muualta järjestelmästä tulevien paineiskujen kompensoinnissa mutta
sylinterin S1 paineiskuihin se ei pysty tässä järjestelmässä vaikuttamaan. Akun koosta riippuen sitä voidaan
käyttää, joko ylläpitämään sylinterin käyttöpaine vikatilanteessa (pieni akku), tai tilavuusvirtareservinä,
jonka avulla sylinteri voidaan ajaa hallitusti turvalliseen asentoon (iso akku). Paineenrajoitusventtiilillä V5
säädetään akun täyttöpaine sekä rajoitetaan koko sylinterijärjestelmän paine haluttuun tasoon. Kun
asetuspaine ylitetään, paineenrajoitusventtiili avautuu ja sen kautta johdetaan ylimääräinen öljy tankkiin T1
liitännän f kautta. Normaalisti suljetulla hanalla V6 voidaan paineakusta poistaa paine näin halutessa, jolloin
hanan avauksen jälkeen hanan läpi kulkeva tilavuusvirta johdetaan tankkiin T1 liitännän f kautta. Sylinterin
S1 järjestelmä on liitetty muuhun järjestelmään vastaventtiilillä V4. Tällä venttiilillä päästetään
pääjärjestelmästä tuleva tilavuusvirta sylinterin järjestelmään ja estetään sylinterin järjestelmästä virtaus
pääjärjestelmään. Kaaviosta löytyy vielä painemittari, jota kuitenkaan ei ole liitetty mihinkään.
Selvitysraportti
38
Sylinterin liikenopeutta ei pystytä säätämään kaavion komponenteilla järjestelmässä. Suuntaventtiilin
läpäisy määrää sylinterin liikenopeuden.
Kaaviossa esitetty painekytkin K1 voi olla mahdollisesti osa pääjärjestelmän pumpun ohjausta. Kun paine
laskee painekytkimen K1 tarkkailemassa linjassa saattaa pumpun ohjaukselle mennä tieto tilavuusvirran
tarpeesta tässä osajärjestelmässä. Tällöin pumpun tuottoa kasvatetaan tiettyyn asetusarvoon ja pidetään
siinä niin kauan että paine taas nousee K1-kytkimen tarkkailemassa linjassa riittävän suureksi. Paineen
noustua pumpun tuottoa taas vähennetään.
Painekytkimellä K2 taas saatetaan tarkastella sylinterin S1 asemaa. Koska painekytkin tarkastelee sylinterin
A-linjaa, voi sen arvo muuttua vain, kun tässä linjassa paine muuttuu riittävästi. Kaavion alkutilanteessa Alinjan paine on tankissa vallitseva paine, joka on aina huomattavasti pienempi kuin järjestelmän
asetuspaine. Kun suuntaventtiilin V10 asento muutetaan, ajetaan sylinterin mäntä ulos. liikkeenaikana
paine nousee sen suuruiseksi kuin kuorman siirtämiseen vaaditaan. Tämä painetaso ei kuitenkaan ole vielä
korkein painetaso A-linjassa. Kun sylinterin mäntä on ajettu toista päätyä vasten, nousee paine sylinterin Alinjassa paineenalennusventtiilin V8 asetuspaineeseen. On todennäköistä, että painekytkimen K2 signaali
muuttuu vasta tällä painetasolla, jolloin tiedetään sylinterin olevan toisessa päädyssään.
Vaikka kaaviossa on piirretty tankki kolmeen kertaan, tarkoitetaan tällä merkinnällä kuitenkin kokoajan
yhtä ja samaa tankkia T1. Tässä tapauksessa kaikki kolme erillistä linjaa myös on yhdistetty jossain
vaiheessa ja kaikkien virtaukset kulkeutuvat tankkiin saman liitoksen läpi. Lisäinformaationa voidaan vielä
todeta että tämän liitoksen putken pää on tankissa nestepinnan yläpuolella eikä alapuolella, koska linjojen
viivat eivät pääty tankin piirrosmerkin pohjaan.
Kaavion järjestelmä voi kuvata esimerkiksi hydraulista lukkoa, joka ei kuitenkaan saa jäädä päälle koneen
pysähdyttyä.
Kaavioissa on tapana merkitä toimilaitteiden ja komponenttien avaintiedot, jotka kuitenkin kaikki puuttuvat
esimerkkikaaviosta. Esimerkiksi sylinteristä kerrotaan männän ja männänvarren halkaisijan lisäksi iskun
pituus.
Internetistä
löytyy
IHA:n
sivuilta
PDF
http://www.iha.tut.fi/education/IHA2100/harkka_kaavohj.pdf, jossa on otettu tärkeimmät kohdat näihin liittyvästä standardista.
Mitoitustietoa voidaan sisällyttää myös PDM- järjestelmään mutta käytännöt vaihtelevat, eivätkä tätä
toimintaa määrää standardit. Järjestelmissä on yleensä niin kutsuttujen päätietorivien lisäksi, joiden tieto
näkyy osaluettelossa, myös lisärivejä ylimääräiselle informaatiolle, joka ei näy osaluettelossa.
Tietosisältö mekaanisen käsittelyn näkökulmasta
Nyt on mielenkiintoista tarkastella mitä tietoja SVG-kuvasta on (kuvan tulostamisen lisäksi) luettavissa.
Mekaanisen tulkinnan näkökulmasta keskeisellä sijalla ovat tässä erityisesti seuraavat kuvan edustaman
suunnitteluratkaisun piirteet:
1. Komponentit yms. identifioiva avaintieto (esim. symbolien ja symboliluokkien nimet)
2. Komponenttien tyyppitieto, tyypien (luokka)hierarkia yms. (esim. symboli x on tyyppiä X, X on Y:n
aliluokka)
3. Yhteys/kytkentätieto yksittäisten komponenttien välillä (esim. symbolit x ja y on yhdistetty viivalla
z)
4. Viittaukset standardikomponenttien kuvailutietoihin (esim. moottoritoimittajan tarjoamat tiedot)
Selvitysraportti
39
5. Suunnitteluratkaisuja selittävä tieto (esim. muut osat on valittu puomin nostovoiman ehdoilla)
6. Mahdolliset korvaavuudet vaihtoehtoiset ratkaisut, yms. (esim. sylinterit saa vaihtaa, moottoria ei)
7. Tieto suunnittelijoista ja välineistä, suunnitteluratkaisun elinkaaritieto, mahdollinen versiotieto,
yms. (esim. Saara Suunnittelija, luonnos 0.9, koulutuskäyttöön soveltuva tarkkuus, vain sisäiseen
jakeluun)
3.4. Datan prosessoinnin putkilinjastomalli
Ehdotettu datan prosessoinnin putkilinjastomalli DPPM (data processing pipeline model) on esitetty
kuvassa 7.
Malli kuvaa kehitettävän järjestelmän arkkitehtuurin. Valmiiden suunnittelu- ja
tuotantojärjestelmien (Legacy editor esim. Vertex –ohjelmistot) kuvataan aineisto mahdollisimman
rikkkaasti ja yhtenevästi. System importer on toiminto, joka vastaa suunnittelu- ja tuotetietojärjestelmistä
saatavilla olevan tiedon tuonnista lab generator yhteensopivaan muotoon. Toiminto voi hyödyntää useita
eri suunnittelujärjestelmän tietoja. Se hyödyntää semanttista tietoa tuonnin aikana liittämään osaksi muita
tunnettuja tietoja. Osasta suunnittelujärjestelmästä tuotuja tietoja luodaan kirjastomoduuleita (3d mallit),
joita voidaan hyödyntää muissakin konelaboratorioissa. Osassa tuodoista tiedoissa valitaan olemassa
olevista kirjastomoduuleista vastaava palanen (esim. 2d dynamiikka). Tiedoista luodaan myös
konelaboratoriojärjestelmän peruskuvaus, joka kertoo eri visualisointien ja loogisen asettelun sekä
tunnisteet, osa-/komponenttihiearkian ja osa-/komponenttien käyttöliittymänimet (jos eivät tule
kirjastomoduuleista).
Suunnittelujärjestelmistä tuotava tieto ei todennäköisesti ole automaattisesti muokattavissa 100% M1teknologia yhteensopivaksi, joten tuotavan tiedon muokkaukseen tarvitaaan mahdollisesti omia editoreita
(mm. visualisointien dynamiikka).
Kuva 7: Virtuaalisen konelaboratorion ohjelmistojen ja mallien putkilinjakuvaus, jossa kuvataan alustavasti
ehdotus järjestelmän rakenteesta ja prosesseista.
Selvitysraportti
40
Putkilinjaston perusidea voidaan kiteyttää siihen että lähtötietoina ovat manuaalisesti semanttisella
editorilla tuotettu semanttinen tieto sekä suunnittelujärjestelmillä tuotettu tieto. Suunnittelujärjestelmillä
tuotettutieto tuodaan putkeen hyödyntäen semanttista dataa. Tällöin kaikki tieto linkitetään semanttisesti
toisiinsa semogen-yhteensopivaksi. Tätä tuotua tietoa voidaan tarvittaessa muokata erilaisilla editoreilla.
Kun konejärjestelmä on valmis otettavaksi käyttöön siitä tuotetaan M1-yhteensopiva muoto
konejärjestelmän vientitoiminnallisuudella.
Kuva 8: Suunnittelutiedon tuontiperiaate putkilinjastossa
Konelaboratoriojärjestelmää pitää mahdollisesti muokata ennen varsinaista generointivaihetta, koska:





automaattisesti muualta tuotu data on puutteellista
automaattinen generointi ei kata kaikkia osa-alueita
kaikkia tietoja ei ole saatavilla
saatavilla olevat tiedot eivät ole yhteensopivia automaattisen generoinnin kanssa
konelaboratorion käyttötarkoitus edellyttää muutoksia järjestelmään
Mitä asioita voisi olla mahdollista muokata, minkälaisella muokkaimella:







2d dynaamiset symbolit ja kaavioasettelu (Kaavioeditori)
3d mallien dynamiikka ja 3d-asettelu ( VWEditor)
3d mallien kevennys, nimeäminen, dynamiikka ja 3d-asettelu ( SIACT )
konelaboratoriojärjestelmän ohjaus (Ohjaamoeditori)
Simulaation asetukset (Simueditori)
Vika- ja toimintokuvaukset
Äänien liittäminen konejärjestelmään (Äänieditori)
Selvitysraportti


41
Valmiit toimintaketjut (Toimintaketjueditori)
Toimintapuun hienosäätö (Toimintapuueditori)
Lab system editor -työkalun eri muokkaimilla käsitelty tieto tallennetaan osana semanttista mallia
tallennettuun lab system dataan. Osa muokkaustoimenpiteistä voitaisiin tehdä vasta lab generator-vaiheen
jälkeen, vaikkakin silloin kyseiset tiedot menetettäisiin uudelleen generoinnissa.
3.4.1. Konelaboratorion generointi
Putkilinjaston viimeisessa osassa integroidusta semanttisesta mallista luodaan lab generator vaiheessa M1teknologia yhteensopivat kuvaukset, joiden avulla järjestelmä on käytettävissä M1-ohjelmistosta. Kuva 9
kertoo lab generator vaiheen tietovirrat ja kuvaa mitä M1-teknologia järjestelmätiedostoja vaiheessa
tuotetaan. Tässä toiminnossa käyttäjä ei enää vaikuta luotavaan järjestelmään vaan aikaisemmissa
vaiheissa tuoduista, luoduista ja muokatuista tiedoista generoidaan M1-yhteensopivia malleja. Lab
generator ottaa pohjaksi järjestelmän kuvauksen (lab system data) ja yhdistää sen semanttisen mallin
tietojen pohjalta yhteen hyödyntäen luotuja ja tuotuja kirjastoalkioita. Alla on kuvattu tärkeimmät
tarvittavat tiedostot, jotka generoidaan kun käytetään M1:stä loppuajoympäristönä. Nimeämisessä on
käytetty M1-ohjelmiston oletusnimiä, joita voidaan vapaasti muuttaa. Kaikki näissä tarvittava tieto on
oltava kuvattuna semanttisessa mallissa. Se voidaan jakaa kolmeen eri osaan: tuotu ja editoreilla
mahdollisesti muokattu konejärjestelmätieto (lab system data), kirjastoalkiot (mm. 3d-mallit) ja generointi
informaatio.
Näistä jälkimmäinen määrää miten eri konejärjestelmän tietoja käytetään ja
konejärjestelmätieto puolestaan määrittää missä kirjastoalkioita hyödynnetään.
Selvitysraportti
42
Kuva 9 Lab generator vaiheen tietovirrat
Kuvassa 9 generoinnin tuloksena syntyvät alustustiedostot sisältävät seuraavanlaisia tietoja:











pic.*
: mahdollisesti tarvittavia kuvia
*.wav
: koneen ääniefektit
*.mesh
: 3d-mallit worldviews.xml: valmiit 3d-kuvakulmat
worldviews.xml: valmiit 3d-aihealuerajaukset
ToolBarviews.xml: Valmiit kuvakulmat näkymävalikossa
names3d.xml : 3d-dynamiikka ja nimeäminen
all.scene
: 3d-asettelu
diagram*.svg : dynaaminen kaavio
system.xml
: järjestelmän yleinen kuvaus, mm. simulaatio liitokset,komponenttihierakiat jne.
sysNames.xml : Käyttöliittymänimet
actiontree.xml : toimintapuu functionchains.xml: toimintaketjut
Selvitysraportti


43
simulation.mdl : simulaation matlab-malli
simulation_param.m: simulaatiomallin parametrit
M1-ohjelmiston kehitystarpeet Semogen hankkeessa
Vaikka M1-ohjelmisto nykyiselläänkin toimisi kohtuullisen hyvin generoinnin kohdejärjestelmänä, on sitä
hankkeen puitteissa kehittää ainakin muutamin osin. Tärkeimmiksi kehityskohteiksi voisi nimetä seuraavat
asiat:

Semanttisesti kuvatun materiaalin suora hyödyntäminen

Käytettävyyden parantaminen

Mahdolliset suunnittelutiedon ja nykyisen M1-formaattien välisten ristiriitojen ratkonnat

Vielä puuttuvien, mutta tarpeellisten/välttämättömien, konelaboratorio-ominaisuuksien
kehittäminen esimerkkijärjestelmän käytön vaatimusten mukaan
3.4.2. Konejärjestelmän 3D -reaalikuvaus
Nykytilanteessa käytetään VirtualWorldin tuottamiseen käytetään kahta import/export -pluginia (CAD:stä
renderöintiohjelmaan ja renderöintiohjelmasta OGRE:een ja renderöintiohjelmaa). Virtuaalimaailman
tuomisessa M1-ohjelmistoon on kaiken kaikkiaan 10 eri vaihetta ja lisäksi kamerakulmien määriminen
voidaan laskea omaksi vaiheekseen. Usean eri työvaiheen ongelmina ovat kallis renderöintiohjelma,
erikseen hankittavat import / export-pluginit eri tiedostoformaateille ja alustus ja animointitietojen
muokkaus käsin.
Semogen-projektissa ehdotetaan
lähderiippumatonta, automatisoitua
independent automated construction
poistaa renderöintiohjelman käyttö
alustustiedostojen muokkausta.
ratkaisuksi 3D-virtuaalimallien tuomiseen M1-ohjelmistoon
työkalua virtuaalisten konejärjestelmien mallinnukseen (source
tool for virtual machine systems, SIACT). Työkalun tehtävänä on
mallien tuonnista ja vähentää huomattavasti käsin tehtävää
SIACT ominaisuudet:
1. Riippumattomuus lähdemateriaalin formaatista
* SIACT rakennetaan laajennettavissa oleva parseri, joka hyödyntää suoraan eri CADformaattien rajapintoja.
2. Lähdemateriaalin automaattinen keventäminen
* Perustuu vertexien välimatkaan
* Lopputuloksen laadun tarkastukseen vaaditaan edelleen ihminen
3. Järjestelmän komponenttien lataus työtilaan osaluettelon perusteella
* Mikäli järjestelmää ei ole valmiiksi koottu CADissä ( kokoonpanokuvat ) , Järjestelmän
rakentamista SIACTissa voidaan nopeuttaa lataamalla komponentit valmiiksi työtilaan
Selvitysraportti
44
järjestelmän osaluettelon perusteella. Komponentit sijoitellaan tietylle etäisyydelle
toisistaan.
* Lopullinen sijoittelu vaatii edelleen käyttäjän toimia.
4. Nimeäminen
* Mallien nimeämistä varten SIACT:iin luodaan helppokäyttöinen työkalu, joka mahdollistaa
mallien nopean uudelleen nimeämisen.
5. Animointien sidonta ja liikerajojen määräys
* Kappaleiden liikkeiden määräämiseen suhteessa toisiinsa luodaa erillinen työkalu.
Työkalulla voidaan määrätä kappaleen isäkappale, kappale jota seurataan, ja vapausasteiden
rajoitukset.
* Kappaleen maksimiliike alueiden määrityksellä voidaan estää kappaleen liikkuminen yli
rajojensa lopullisessa animoinnissa. Maksimiliike rajoja käytetään myös kappaleen
liikefunktion määrittämiseen.
6. Tallennus semanttisessa, M1-yhteensopivassa muodossa.
3.4.3 Dynaamisen kaavion automaattisen generoinnin vaatimukset
Kaavioiden automaattisen generoinnin vaatimukset





Tarvitaan sähkö- ja hydrauli- sekä mahdolliset CAN-kaaviot koneesta
Sähkökaaviot ja hydraulikaaviot on todennäköisesti piirretty Vertexin ohjelmistoilla
CAN-kaaviota varten pitää keskustella Vertexin kanssa mahdollisuudesta piirtää CAN-kaavioita
heidän ohjelmistoillaan tai vaihtoehtoisesti piirtää CAN-järjestelmän rakenne Microsoft Visiolla.
Kaavioiden tulee olla koneellisesti luettavassa muodossa (esim. sähkökaavio Vertex ED), josta
voidaan helposti tunnistaa eri komponentit ja niiden väliset yhteydet (mikä komponentti on
kytkettynä mihinkin). Vertexin esitteestä: "Piirikaavioita tehtäessä syntyy automaattisesti
kytkentätieto, jota käyttäen sovelluksen toiminnoilla suunnitellaan ja dokumentoidaan
johdinsarjojen rakenne."
Kaavioiden automaattinen generointi tuottaa mahdollisesti liian runsaan kaavion, josta liiallisia
yksityiskohtia voi joutua käsin poistamaan. Myös animointeja varten voi kaavion komponentteja
joutua siirtelemään, koska dynaamiset liikkeet vaativat. Tätä ei yleensä ole mietitty kaavion
piirtovaiheessa lainkaan. Tähän mahdollisena ratkaisuna oma kaavioeditori tai kaavioiden
muokkaus sopivaksi vaikka Vertexin ohjelmistoilla.
Suunniteltu tuotantoprosessi:
1. Kaavioiden hankinta suoraan suunnittelujärjestelmästä saatavassa muodossa esim. rakenteellisessa
muodossa.
2. Kaavion tuonti semanttiseen malliin koneellisesti hyödyntäen kaikki saatavilla oleva tieto
3. Mahdollinen raakamateriaalissa olevan tiedon rikastaminen ja muokkaaminen ja uudelleen tuonti
semanttiseen malliin.
Selvitysraportti
45
4. Rikastetun tietojen hyödyntäminen mm. simulaation ja kaavio dynamiikan automaattisessa luonnissa
5. Kaavion ja dynamiikan ulosotto M1-yhteensopivassa muodossa hyödyntäen mm. kirjastoitua dataa.
3.4.4 Sähkö ja CAN-väylä simulaatioiden automaattinen toteuttaminen
Sähkö- ja väyläsimulaatioiden tuottamiseen vaadittava ainesto on kuvattu luvussa 3.6. M1-teknologiassa
sähkö- ja väyläjärjestelmät ovat simuloitu ohjelmallisesti C#-kielellä. Tämä on mahdollistanut
asetustiedostojen käytön eli itse sähkö- tai väyläjärjestelmää ei ole ollut tarvetta täysin kovakoodata. Tämä
on mahdollistanut joustavan tavan laajentaa järjestelmää suoraan xml-tiedostoa muokkaamalla.
Vaihtoehtona on käyttää Simulinkia myös sähkö- ja väyläjärjestelmien simulointiin hydrauli- ja
mekaniikkajärjestelmän tapaan. Toteutettaessa väyläjärjestelmä tai sähköjärjestelmä Simulinkilla tullaan
samalle ongelmakentälle, kuin hydrauliikan ja mekaniikan simuloinnissa. Lähdetiedoista olisi generoitava
suoraan valmista järjestelmää kuvaava malli, joka olisi käännettävä suoritettavaksi ohjelmaksi. Ongelmaksi
nousee muokattavuus ja generoitavuus, mutta tämä on joka tapauksessa tehtävä hydrauli- ja
mekaniikkajärjestelmän kanssa, joten se ei ehkä olisi niin suuri ongelma. Selvitystyö jatkuu vielä ja näitä
kahta vaihtoehtoa tullaan varmasti pohtimaan vielä toteutusvaiheen alkaessakin. Lisäksi materiaalin
tarkentuessa voidaan tehdä tarkempia päätelmiä toteutustavoista.
Alustavasti väyläjärjestelmästä ei ole meidän tietojen mukaan saatavilla kaaviota, kuten hydrauli- ja
sähköjärjestelmästä. Saatava materiaali on dcf- ja eds-tiedostoja. Kyseiset tiedostoformaatit kattavat
erittäin hyvin konejärjestelmän väyläkuvauksen. Niihin on mahdollista liittää monenlaista metatietoa, kuten
komponenttinumeroita, valmistajatunnisteita, IO-porttien numeroita ja lisäksi omaa semanttista
metatietoa. Kyseiset dcf ja eds -tiedostot ovat ehkä jopa hankkeen kannalta parempia kuin perinteiset
kaaviot. Niissä solmujen tieto ja solmujen väliset yhteydet on kuvattu standardissa ja rikkaassa muodossa.
Kyseiset tiedostot mahdollistavat väyläjärjestelmästä xml-kuvaksen tekemisen, koska itse lähdemateriaali
on jo lähellä tavoitetta.
Hankkeeseen saatava materiaali on sähköjärjestelmän osalta vielä kirjoitushetkellä auki, joten suuria
päätelmiä toteutuksesta on vielä hankala tehdä. Jos raakamateriaali on Vertex ED:ssä tuotettua, on
toteutus lähellä hydraulijärjestelmien (Vertex HD) vastaavaa toteutusta. Linkitykset tulee siis lukea
kaaviossa olevien tunnusten avulla ja luultavasti rikastamalla kaaviotietoa tarvittavissa määrin.
3.4.5 Toimintopuun ja –ketjun automaattinen generointi
Tällä hetkellä ei ole tiedossa tietolähdettä, josta toimintapuun tai – ketjujen tiedot voitaisiin lukea. M1teknologia sisältää molempiin kuvauksiin omat editorinsa, joita voidaan hyödyntää tämänkin projektin
puitteissa, mutta ne eivät tue tiedon lukua mistään lähteistä.
3.4.6 Simulointimallien generointi
Metviron ja M1 teknologiassa hyödynnetyt kokonaissimulointimallit eivät vaadi täydellisen tarkkaa
mallintamista, koska pääpaino on ollut konejärjestelmän opetuksessa ja käyttäytymisen kuvaamisessa
mallintamisessa. Samaa periaatetta tullaan jatkamaan Semogeniin mallinnettavien komponenttien osalta.
Erityishuomio Semogen simuloinnissa on komponenttimallien käyttö uudelleen generointiin eli
simulointimallit tarvitsee kirjastoida. Järjestelmämallien automaattisessa generoinnissa yksittäisten
komponenttien mallit pitää olla valmiiksi mallinnettu ja mahdollisimman tarkasti parametrisoitu.
Selvitysraportti
46
Kirjastointi ei kuitenkaan poista tarvetta iteratiivisesti parantaa simulointimallia prosessin aikana. Toisaalta
kirjastointi tuo lisähaasteena ison komponenttikirjaston hallitsemisen ja mallintamisessa pitää tarkemmin
miettiä komponenttimallien rajapintoja. Tämän ei pitäisi muodostua ongelmaksi, kun kunkin
komponenttimallin ulkoiset rajapinnat pystytään määrittelemään aikaisessa vaiheessa. Tämän jälkeen
mallin sisältöä voidaan muokata ja kehittää, muista suunnittelujärjestelmistä erillään.
Kirjastoinnin hallintaan käytetään todennäköisesti XML-pohjaisia ratkaisuja. Näin yksittäisen kirjastoidun
kokonaisuuden tiedot voidaan merkata ja lukea jälkikäteen koneellisesti. Toinen huomion arvoinen seikka
on aikaisemmin esitellyn Simulink-tiedosto formaatti (mdl). Simulink käyttää mallien tallentamiseen ASCIIpohjaista kuvailevaa tekstitiedostoa. Periaatteessa tiedosto on metatiedolla varustettua informaatiota
simuloidusta järjestelmästä. Ongelmana on vain sen lukeminen muilla sovelluksilla kuin Simulink. Tämä
mahdollistaa kuitenkin suhteellisen helpon tavan muodostaa Simulinkin mdl-tiedostoja kirjastoiduista
komponenttimalleista.
Simulink tukee modulaarista mallintamista eli simuloitavat järjestelmät voidaan jakaa alijärjestelmiksi
mallia luotaessa. Tällainen rakenne voidaan myös luoda ilman Simulinkin graafista editoria kirjoittamalla
suoraan tekstiä mdl-tiedostoon.
Block {
BlockType
SubSystem
Name
"My Subsystem"
System {
Name
"My Subsystem"
Location
[645, 182, 835, 290]
Block {
BlockType
SubSystem
…
}
Kuva 10. Alijärjestelmän määrittävä MDL-syntaksi
Toinen mukava piirre Simulinkissä on Bus-väylät. Niiden avulla Simulinkissä olevat tietovirrat voidaan
kuljettaa väylää pitkin ja poimia väylältä tunnisteen perusteella. Bus-väylä tyyppisen yhteyden kokoavien
(Creator) ja purkavien (Selector) lohkojen rakenteita voidaan koneellisesti muokata halutuiksi perustuen
saatavilla olevaan materiaaliin. Jos tarpeena on yhdistää ainoastaan venttiilin ja sylinterin väliset yhteydet,
voidaan käyttää yksinkertaisia Line-elementtejä. Kuten aiemmissa lohkoissa, niissä on selvästi metatiedolla
merkattu muun muassa lähde ja kohde lohkot.
Line {
SrcBlock "Gain"
SrcPort 1
Points
[20, 0]
Branch {
Points [0, 10]
DstBlock
"Scope"
DstPort 1
}
Branch {
Points [10, 0]
Selvitysraportti
DstBlock
DstPort 1
47
"Display"
}
}
Kuva 12. Kolmea lohkoa yhdistävä viiva tekstimuodossa.
Edellä esitetyn tekstin generoiminen XML-kuvauksesta ei ole hankalaa, mutta haasteena ovat tietovirtojen
hallinta ja tiedon linkittäminen järkeväksi kokonaisuudeksi. Lisäksi pitää huomioida, että mdl-tiedosto
täytyy kokoamisen jälkeen kääntää kohdejärjestelmälle Visual Studion kääntäjällä.
Lähde: Diplomityö: Hydraulisten ja mekaanisten järjestelmien simulointimallien automaattinen generointi,
2009. Mikko Markkula, TTY/IHA
3.4.9. Toimintokuvaukset
Toimintopuu -käsittellä tarkoitettaan konejärjestelmän kuuluvien komponenttien ja toimintojen
linkittämistä puumaiseen rakenteeseen. Toimintapuun rakentamista varten on tehty editori, jonka avulla
puuta voidaan rakentaa graafisen käyttöliittymän avulla. Toimintapuu mahdollistaa esimerkiksi vikojen
konejärjestelmään aiheuttamien muutosten listaamisen ja linkittämisen. Esimerkiksi luodaan vika
työhydrauliikanpumppuun, josta heijastuu ongelmia järjestelmän paineisiin, tilavuusvirtoihin ja lopullisesti
vika voidaan havaita järjestelmätasolla toimilaitteiden liikkumattomuutena.
Toimintoketju on käsitteenä hyvin lähellä toimintopuuta, mutta on vianhausta askel toimintojen linkityksen
havainnollistamiseen ja opettamaan miten konejärjestelmän komentoketjut toimivat. Toimintoketjujen
muodostamiseksi on olemassa myös oma editori. Käyttöliittymä on graafinen ja sen avulla käyttäjä voi
luoda haluamiansa toimintoketjuja, jotka voivat olla lyhyitä ja yksinkertaisia tai pitkiä ja sisältäen kaikki
mahdolliset toimintoketjuun liittyvät havainnollistukset. Kaaviota, 3D:tä, osaluetteloa jne. käytetään
toimintaketjun visualisointiin toimintaketjutyökalun tahdittamana. Vaiheeseen liittyvät piirrosmerkit
(toiminta tai komponentti) korostetaan, kohdistetaan tarvittaessa ja muokataan dynamiikan
ohjauskomennoilla. Teknisesti kaavio toimii samalla lailla kun tavallistakin simulaatiota ajettaessa. Alla on
esitetty esimerkkinä; noston toimintaketjun esittäminen vaiheistuksen avulla -skenaario. Nostoliike
aloitetaan ja päättyy siihen, kun puomi alkaa nousta. Alkutilanne: Kone: pumppu lähes nollakulmalla
(tasapainotila ilman kuormitusta, paitsi kompensoi vuodot), paineet tyhjäkäynnillä, puomi kuormatilassa,
öljy lämmintä, kone tasaisella kentällä. Tarkasteltavat työvälineet; sähkökaavio, hydraulikaavio, 3D,
ohjaamo:
1. Kuljettaja käyttää ohjausvipua sähkökaavio: ohjain siirtyy uuteen asemaan ohjaamo: ohjain siirtyy uuteen
asemaan
2. Signaali siirtyy ohjaimelta ohjainmoduulille sähkökaavio: linja näkyy aktiivisena
3. Ohjainmoduuli muokkaa ohjausta kuljettajan säädöillä sähkökaavio: moduuli aktiivisena prosessoimassa
jotain
4. Signaali siirtyy ohjainmoduulita nosturin moduulille (CAN-väylä) sähkökaavio: linja näkyy aktiivisena
5. Nosturin moduuli (VBU) muuntaa signaalin venttiilille sähkökaavio: moduuli aktiivisena
6. Signaali siirtyy nosturin moduulilta noston esiohjausventtiilin kelalle. sähkökaavio: linja näkyy aktiivisena
(analogisen signaalin suuruus)
7. Kela virroittuu ja tuottaa voimaa karalle hydraulikaavio: kelan väri muuttuu suhteessa virtaan (mitä
isompi pinta-ala kelasta väritetty, niin sitä suurempi virta)
8. Esiohjauskara siirtyy siihen asemaan, että paine esiohjauksen painekanavasta välittyy toimilaitekanavaan
(linja aukeaa; venttiilin tilasta 1 tilaan 2) hydraulikaavio: piirrosmerkin kara siirtyy uuteen asemaan
Selvitysraportti
48
9. Pääkaran ohjauskanava paineistuu (huomioi kuristus) hydraulikaavio: linja väritetään painetta vastaavalla
värillä
10. Pääkara siirtyy LS-linjan avaavaan asemaan hydraulikaavio: piirrosmerkin kara siirtyy uuteen asemaan
11. LS-linja paineistuu karalta noston vaihtovastaventtiilille hydraulikaavio: linja väritetään painetta
vastaavalla värillä
12. Noston vaihtovastaventtiili valitsee suuremman signaalipaineen välitettäväksi eteenpäin hydraulikaavio:
vvv-pallo siirtyy oikeaan laitaan
13. Signaali siirtyy nostonlohkosta painepäädyn kopiokaralle hydraulikaavio: linja väritetään painetta
vastaavalla värillä
14. Kopiokara säätää lähtevän signaalipaineen vastaamaan sisäistä LS-linjan painetta. hydraulikaavio:
piirrosmerkin kara siirtyy uuteen asemaan
15. Signaalipaine siirtyy venttiililohkolta pumpun säätimelle kuristuksen kautta. hydraulikaavio: linja
väritetään painetta vastaavalla värillä
16. Pumpun virtaussäädin säätyy signaalipainetta ja pumpun ohjaussylinterissä vallitsevaa painetta
vastaavaan tasapainotilaan. hydraulikaavio: piirrosmerkin kara siirtyy uuteen asemaan (vasemmalle)
17. Paine ohjaussylinterin männänpuolella laskee. hydraulikaavio: linjat ja kammio väritetään painetta
vastaavalla värillä (sininen)
18. Pumpun kulma suurenee hydraulikaavio: pumpun säätönuoli kiertyy myötäpäivään
19. Paine painelinjassa kasvaa hydraulikaavio: linja väritetään painetta vastaavalla värillä
20. Nostoventtiilin pääkara siirtyy yhdistäen painelinjan ja toimilaitteen kanavat
21. Virtaus alkaa ja sylinteri liikkuu
22. Puomi liikkuu
Tällä hetkellä ei ole tiedossa tietolähdettä, josta toimintapuun tai – ketjujen tiedot voitaisiin lukea. M1teknologia sisältää molempiin kuvauksiin omat editorinsa, joita voidaan hyödyntää tämänkin projektin
puitteissa, mutta ne eivät tue tiedon lukua mistään lähteistä.
3.5. Suunnittelumenetelmät ja prosessit
Suunnittelijoiden käytännöt kaavioiden, piirustusten sekä CAD-mallien teossa vaihtelevat jopa
henkilötasolla. Yrityksissä pyritään yleensä samankaltaisiin suunnittelukäytäntöihin suunnittelijoiden
kesken mutta tämä toteutuu harvoin täydessä mitassa. Tämä johtuu näitä käytäntöjä ohjaavien standardien
puutteesta sekä siitä, että suunnittelijat ovat hankkineet aikaisemman kokemuksensa muualta kuin
yrityksestä, jossa ovat sillä hetkellä töissä. Tietojen tallentamisessa tietokantoihin käytännöt ovat yleensä
samoja yritysten sisällä, koska näihin on ohjeistukset, jotka käytetty ohjelmisto asettaa.
Hydrauliikka- ja sähkösuunnitteluohjelmistoissa suunnittelutiedon saatavuus vaihtelee edellä esitettyjen
syiden takia. Jos ohjelmistoissa tallennetaan oikea tieto riittävän rikkaana, voidaan parhaassa tapauksessa
näiden tietojen perusteella generoida niin kaavioita, 3D-malleja, osaluettelot sekä simulointimallien
rakenteet ja parametrit. Tätä ei kuitenkaan aina tehdä vaan yleensä yrityksissä riittää, että osat voidaan
tilata tai valmistaa tallennettujen tietojen perusteella. Nämä tiedot eivät yleensä riitä simulointimallien,
kaavioiden ja 3D-mallien generointiin yksistään mutta osaluettelot näiden tietojen perusteella voidaan
generoida.
Suunnittelumenetelmiä kuvataan yrityksen laatujärjestelmässä. On huomioitava, että virtuaalisen
konelaboratorion tuotantoprosessin tarvetta tuskin on tunnistettu, vaan muut liiketoimintatavoitteet
ohjaavat suunnittelua. Suunnittelijan on mahdotonta tuottaa koneen luettavissa olevaa, yhtenäistä ja
yhteensopivaa aineistoa, jos ohjeistusta ja merkityksiä ei ole.
Selvitysraportti
49
Jotta mallien generointi olisi mahdollista, tulee nykyisistä suunnittelujärjestelmistä saatava tieto rikastaa.
Tämä aineiston rikastaminen voisi tapahtua, nykyisissä järjestelmissä toimiakseen, omana vaiheenaan
mallin automaattisessa generoinnissa, kuten kappaleen 3.3 kuvassa X.X on esitetty. Tässä vaiheessa
kappaleessa 3.3 kuvattu importteri tarkistaa mitä tietoja simulointimallin generoimiseksi vielä puuttuu ja
ilmoittaa näistä puutteista suunnittelijalle tai muulle aineiston rikastajalle. Tämän jälkeen aineistoon
voidaan lisätä puuttuvat tiedot käsin ja mallit voidaan generoida virtuaaliseen konelaboratorioon.
Ideaalisessa tilanteessa suurin osa virtuaalisen konelaboratorion generoimiseksi tarvittavasta tiedosta tulee
löytyä jo valmiiksi suunnittelujärjestelmästä. Tällöin itse suunnittelujärjestelmän tulisi olla sellainen, että
tietojen tallentaminen järjestelmään sekä lukeminen järjestelmästä on helppoa ja hyvin ohjeistettua.
Tällaista suunnittelujärjestelmää käyttämällä suunnittelija voisi tallentaa suurimman osan mallien
generoimiseksi vaadittavasta tiedosta jo suunnitteluvaiheessa. Tässä vaiheessa ei kuitenkaan ole
välttämättä järkevää vielä tallentaa sellaista tietoa mitä ei tarvita missään muualla kuin mallien
generoinnissa. Järkevien mittasuhteiden selvittäminen tiedon tallentamiselle eri suunnittelun ja mallien
generoinnin vaiheissa tulisikin selvittää vielä tarkemmin.
Selvitysraportti
50
3.6. Aineistotarpeet
Tiedon tarve hydrauliikan, mekaniikan, sähkötekniikan ja väylätekniikan mallintamisessa
Mallinnusprosessin alussa päätetyt rajaukset mallintarkkuudesta vaikuttavat tarvittavan tiedon määrään.
Ennen mallinnusta tarvitaan tieto järjestelmään kuuluvista komponenteista ja niiden liitoksista sekä
merkityksestä järjestelmän toimintaan. Kuten aiemmin todettiin, komponenteista osa on erittäin tärkeitä ja
toiset vähemmän tärkeitä järjestelmän päätoimintojen kannalta. Tarvittava komponenttikohtainen tieto
riippuu siis mallinnustarkkuudesta. Tietoa on yleensä paljon tarjolla ja käytetään mahdollisuuksien mukaan
ihmisen toimesta mallinnusvaiheessa hyödyksi. Usein tieto ei kuitenkaan ole tarkkaa ja tarvitaan sovellusta.
Tämän takia tietokoneen on hankala käsitellä kyseistä tietoa. Käytännössä ensimmäisen järjestelmää
kuvaavan simulointimallin toteuttamiseen vaaditaan aina ihmistä. Alla olevaan listaukseen ja taulukkoon 1
on kerätty, mitä tietoa voidaan tarvita, mutta kaikkea tätä tietoa ei välttämättä joka mallinnusprojektissa
tarvita. Lisäksi on otettu kantaa mistä tämä tieto yleensä saadaan. Lisäksi joudutaan usein turvautumaan
usein haastatteluihin kone- ja laitevalmistajien kanssa.
• Komponenttilistaus (hydraulikaavio/työkoneen CAD-kuvat)
• Ohjaukset ja anturoinnit (hydraulikomponenttien datalehdet/sähkökaavio)
• CAN-väylän topologia ja siinä olevat CAN-solmut (CAN-dokumentaatio, konevalmistajan
esitteet
Selvitysraportti
Komponentti
51
Mitä tietoa vähintään tarvitaan
Missä tieto mahdollisesti on
Koneen fyysinen rakenne Toimilaitteiden, mekaanisten osien ja renkaiden
kiinnityspisteet, rungon ja mekaanisten osien
nivelpisteet, kaikkien kappaleiden hitausmomentit,
massat, nivelten vapausasteet ja dimensiot
Arvioita, konevalmistajan
esitteet, CAD-kuvat
Suuntaventtiilit
Venttiilinrakenne eli virtaustiet ja esiohjaustapa.
Virtausteiden läpimitat eli tilavuusvirran ja paineen
yhteys
Komponentin
datalehdet/todellisen
komponentin mittaaminen
Paineventtiilit
Virtausteiden läpimitat, asetusarvot
Hydraulikaavio, huoltomanuaali
Sylinterit
Sylinterin ja männänvarren halkaisijat, iskunpituudet,
liikenopeudet
Hydraulikaavio, CAD-kuvat
Hydraulimoottorit
Syrjäytystilavuudet, säätöjärjestelmä
Hydraulikaavio, datalehdet,
CAD-kuvat
Hydraulipumput
Syrjäytystilavuudet, säätöjärjestelmä
Hydraulikaavio, datalehdet,
CAD-kuvat
Suodatin
Läpäisykyky, paineenkestävyys
Suodattimen esitteet
Poltto-/sähkömoottorit
Teho, kierrosluvut
huoltomanuaali
Vuodot
Kaikkien komponenttien sisäiset ja ulkoiset vuodot
Komponenttien esitteet,
arvioita, mittaustuloksia
Letkut ja putkistot
Pituus ja sisäläpimitta eli tilavuus
Arvioita komponenttien
sijoittelukuvasta
Komponenttien
sisältämät kitkat
Mekaanisten liitosten ja hydraulisten komponenttien
sisäiset kitkat
Arvioita ja kirjallisuudesta
löytyviä tutkimustietoa
Mittaustuloksia
Valmiiden mallien verifiointia ja validointia varten. Onko Mitataan itse, haetaan
virtaukset ja paineet mallinnetuissa komponenteissa
kirjallisuudesta tai kysytään
riittävän lähellä oikeata entä toimilaitteiden liikkeet?
laitevalmistajilta
Anturit
I/O vai CAN liityntä, ulostulosignaali
CAN-dokumentaatio, anturin
datalehti
CAN-solmut ja väylä
Väylän topologia, mitä viestejä kulkee
CAN-dokumentaatio,
konevalmistajan esitteet , Pro
Can Open editor
Sähkökomponentit
Anturi- ja ohjaussignaalien muoto sekä jännite- ja
virtatasot
Sähkökaaviot ja komponenttien
datalehdet
Taulukko 1: Simulointimallien tuottamiseen vaadittavat vähimmäistiedot ja nykyinen tiedon etsintä
mahdollisuus.
Selvitysraportti
52
M1-ohjelmiston aineistovaatimukset
Jotta M1-ohjelmistoon saataisiin tietty konejärjestelmä käyttöön, on konejärjestelmä kuvattava tietyllä
tavalla. Osa tarpeista on välttämättömiä (esim. perus symbolinen kuvaus) , osa taas optionaalisia, mutta
hyödyllisiä (esim. äänet). Tässä on kuvattu aineistotarpeet M1-ohjelmiston näkökulmasta oikeassa
muodossa. Sen mistä kuvattu materiaali koostetaan, voi sisältää informaation varsin eri muodossa. M1ohjelmiston simulaatio ja virtuaalimaalin tarpeet on kuvattu omissa osioissaan. M1-ohjelmisto käyttää
seuraavanlaisia tietoja konejärjestelmästä ja aineistojen keskinäisistä yhteyksistä:







Symbolinen kuvaus
o symbolien asettelu ja yhdysviivat
o 2D-piirrossymbolit vektorigrafiikkana
o piirrossymbolin eri aliosat (siihen kuuluvat grafiikka-alkiot)
o piirrossymbolin dynamiikka sidottuna simulaatioon
o liike (liikesuunta, -tyyli ja -rajat sekä grafiikka-alkiot)
o paine (grafiikka-alkiot)
o tilavuusvirta (grafiikka-alkiot)
o jännite
o sähkövirta
Reaalikuvaus
o esitettävän järjestelmän 3D-mallit mesh tiedostoina
o 3D-mallin dynamiikka sidottuna simulaatioon
o liike (suunnat, mallien skaalaukset)
o virtuaalimaailman käyttöliittymän asetukset
o 3D-mallien tekstuurit
o tekstuurien animointitiedot (paine ja tilavuusvirta)
Muu tarvittava järjestelmäkuvaus
o järjestelmän eri osien nimet hierarkioineen
o kunkin osan tyyppi
Mittaukset:
o simulaation ulostulo
o tyyppi
o virtuaali/reaalimittaus/”vaikea mittaus” (+vaihtoehtoinen tapa)
o komponentti-/osaliitos
Korjaukset/osamuutos:
o aika
o kustannus
o simulaation sisäänmenojen muutokset
o vikojen korjaukset
o korjauksen kälitekstit eri vikatilanteissa
o komponentti-/osaliitos
Säädöt:
o simulaation sisäänmeno
o oletus-, minimi- ja maksimiarvo
o säädöt tyyppi (=>minkänäköinen käli)
o komponentti-/osaliitos
Ohjaukset:
o ohjain/ohjaimen akseli/nappi/näppäimistön vastine
Selvitysraportti
o
o
o
o






simulaation sisäänmeno
”nolla-”, minimi- ja maksimiarvo
komponentti-/osaliitos
ohjainasettelu
Komponentin ”toimintapuukuvaus”
o toiminnalliset sisääntuloliitokset suhteessa symbolisiin liitoksiin
o toiminnalliset ulostulot ( fyysinen tyyppi ja käliteksti)
o ulostulon laskentasäännöt
Komponentin viat
Järjestelmän toimintaketjukuvaukset
Komponenttiin liittyvät testit
o testitulokset ja niiden ”esiintyminen” eri vikatilanteissa
o testin tunnusarvot: aika, vaikeus, kustannus, käyttökelpoisuus, tulkittavuus
o testi/osaliitos
Komponentin äänet
o Äänisample
o millä arvoilla kuuluu
o koneen erikseen kuunneltavat osa
o äänen muuttuminen simulaation perusteella
Simulaation liittäminen osaksi muuta ympäristöä
o komponenttimallien inputit ja outputit muuhun ympäristöön
o vastaavuus symboliseen malliin
o vastaavuus virtuaalimaailmaan
53
Selvitysraportti
54
4. Yhteenveto
Selvitystehtävä osoitti, että digitaalisen tuotantoprosessin kehittämisen yleishaasteet korostuvat myös
virtuaalisen konelabratorion tutkimus- ja kehitystyössä (Lempiäinen, Aalto, Delfoi & Söderlin, 2007)
Selvitystyö edellyttää useiden eri tieteen ja teknologioiden syvällistä sekä kokonaisvaltaista tuntemusta.
Selvitys osoitti, että virtuaalisen konelaboratorion tuotantomenetelmiä on mahdollista runsaasti kehittää
semanttisen mallinnuksen, ohjelmistojen sekä prosessien kehittämisen avulla.
Työtehtävän haastavuus konkretisoitui selvitystyön yhteydessä. Yhden henkilön tai tietyn tieteen alan
osaaminen ei riitä, vaan tässä yhteydessä edellytetään konejärjestelmien, simuloinnin, suunnittelun,
ohjelmistojen, rakenteisten dokumenttien, koulutuksen, prosessimallinnuksen, suunnittelumenetelmien ja
kokonaisintegroinnin ammattilaisia. Lisäksi toimijoiden tulee voida kommunikoida yhtenäisellä tavalla.
Konejärjestelmien perustuntemus, tietojenkäsittelyn ja prosessien mallinnustavat ovat edellytys yhteiselle
kommunikaatiolle. Voidaan todeta, että Semogen –hankkeen konsortio muodostaa varsin kattavan
osaamisen ja edellytykset yhteistyöhön ovat erittäin myönteiset.
Teknologioiden kehityksen lisäksi tulee keskittyä suunnittelumenetelmiin, yhtenäisiin käsitteisiin,
prosesseihin sekä työn ohjeistuksiin. Teknologiat eivät voi juurikaan tukea automatisointia, mikäli
kuvaustavat ovat eriäviä, puutteellisia tai kirjavia. Tässä mielessä Semogen –hanke on varsin tyypillinen
projekti, että varsinaisten sovellusteknologioiden hyödyntämisen edellytyksenä ovat inhimilliset,
organisatoriset ja työn ohjaukseen liittyvät tekijät.
Selvitystulosten yhteenveto
Konejärjestelmärajaus tarjoaa hyvän perustan lähestyä tavoitteita. Järjestelmästä saatiin varsin rikas
aineisto, joka täydentyy ja jalostuu työpajojen avulla. Aineisto täydentyy ja aineistotarpeet jäsentyvät
tutkimustyön myötä. Tämä on selkeästi positiivinen asia.
Semanttisen mallinnuksen periaatteita voidaan soveltaa virtuaalisen konelaboratorion muokkainten ja
tuotantomenetelmien kehityksessä. Semanttisen ja yleisemminkin mallinnuksen periaatteet
konkretisoituivat myös selvitystyössä.
1. Semanttinen mallinnus (ja integrointi) perustuu pitkälti avainrakenteisiin. Lähdeaineiston rikastaminen
tarkoittaa tästä näkökulmasta katsottuna erityisesti avainrakenteiden kirjaamista ja hallintaa; semanttinen
mallinnus voidaan siten suorittaa varsinaisten suunnittelujärjestelmien "ulkopuolella".
Monitieteinen tutkimustyö edellyttää useiden osa-alueiden ja rakenteiden ymmärrystä oman
eksperttialueen lisäksi. Avainrakenteiden tulisi olla yhteydessä toisiinsa. Tämä edellyttää yhtenäisiä
sanastoja ja kuvaustapoja. Esimerkiksi työkoneen väyläkuvauksen tuottaminen Open CAN standardin
mukaisesti konejärjestelmään tarjoaa luontevan yhteyden hyödyntää kuvausta myös virtuaalisen
konelaboratorion kehityksessä. Sieltä voidaan tunnistaa avainraKuvauksen tulisi olla yhteydessä myös
vastaavasti muihin konejärjestelmäkuvauksiin.
2. Aineiston esikäsittely/harmonisointi tyypillisesti edellyttää myös suunnitteluprosesseissa tapahtuvia
muutoksia, ts. pelkkä tekniikoiden esittely ei riitä vaan tarvitaan myös muutoksia työtavoissa.
Suunnittelumenetelmien tarkempi selvitys ja prosessikuvaus ovat tärkeitä, koska näiden avulla voidaan
määrittää ohjeistuksia ja toimintamalleja aineistojen tuottamiseen ja muokkaukseen. Automaattinen
Selvitysraportti
55
generointi edellyttää tietojen yhtenäisyyden lisäksi riittävän tietomäärän ja tarkkuuden. Puuttuva ja/tai
eroava aineisto pitää muokata käsin.
3. Semanttisen mallinnuksen erittäin hyödyllinen "esiaste" ovat erilaiset taksonomiat ja asiasanastot.
Monimutkaisempi formaali käsitemallinnus kannattaa todennäköisesti aloittaa vasta kun esim.
taksonomioiden hyödyt on otettu käyttöön projektissa. Monimutkaisten semanttisten mallien arkikäytön
suurin haaste lienee järjestelmien hyväksyttävyys (erit. virheetön toiminta, ymmärrettävyys ja
läpinäkyvyys). Käytännön nyrkkisääntö on kuitenkin se, että mitä monimutkaisempi malli on, sitä vaikeampi
loppukäyttäjän on sitä ylläpitää ja ymmärtää. Aineistojen nimeämiskäytännöt tulee sopia ja kuvata
yhtenäisellä tavalla. Nimeämiseen vaaditaan ohjeistus ja koneen tietojenkäsittelyä tukeva skeema.
Aineistojen perusteella voidaan todeta, että aineistoa ja tietoa on useissa formaateissa ja dokumenteissa,
jotka eivät ole yhteneviä ja eivät ole yhteensopivassa muodossa. Lisäksi kieli voi vaihtua suunnittelijoiden
välillä. Nimeämiskäytäntöjen eroavaisuuksien vuoksi on vaikea rakentaa yhtenäistä nimikkeistöä. Samasta
käsitteestä on toisistaan eroavia nimikkeitä. Lisäselvitystä vaatisi konejärjestelmien sanastojen kuvailuun
liittyvän standardin löytyminen.
4. Tyypillisiä aihepiirin kehitysprojektien kriittisiä haasteita ja riskejä ovat epäselvät
käyttötapaukset/kohdesovellukset (esim. liian abstraktit tavoitteet/mittarit), aineistossa tapahtuvat
skeematason muutokset (esim. suunnittelijan vaihtuessa semanttinen nimikkeistö muuttuu
odottamattomasti), ja inhimilliset tekijät (esim. ymmärretään mallin tarkoitus väärin ja tietoa syötetään
virheellisesti). Tässä yhteydessä sovellusesimerkkejä tulee kirkastaa ja rajata. Lisäksi niistä pitäisi voida
päätellä tutkimukselliset tavoitteet. Myös mittaristot tulee määrittää.
Suunnitteluohjelmistojen tuottama ja keräämä data on tärkeä. Tämän hyödyntämiseen löytyy lupaavia
menetelmiä kuten tietokantarajapinnat sekä konejärjestelmäsovelluksia tukevat tuontiformaatit.
Tietokantarajapinta tarjoaa lupaavia mahdollisuuksia yhdistää suunnitteluohjelmiston aineistoa
virtuaaliseen konelaboratorion käyttöön. Tämä vaatii vielä tarkennusta ja yhteensovittamista.
Suunnitteluohjelmistojen sisäisen yhtenevyyden ja linkitysten kehittäminen tukisivat myös
virtuaalilaboratorion tuotantomenetelmiä.
Hankkeen tavoitteena on rakentaa rikas semanttinen malli ja kuvata semanttinen suunnitteluprosessimalli
(semantiv process-based design). Heikki Saha ja Pekka Anttonen SMC:ltä nostivat esiin mahdollisuuden
kehittää Simulink –ohjelmiston avulla yhtenäinen konejärjestelmämalli, jonka avulla voitaisiin tuottaa
tarvittavia konelaboratorioiden aineistoja. Suuret kansainväliset laite- ja järjestelmätoimittajat kuten EADS,
Boeing, NASA ja Volvo ovat hyödyntäneet mallipohjaista suunnittelumenetelmää. Hankkeen tavoitteena
alkuperäisenä tavoitteena on tuottaa suunnittelua tukeva semanttinen kuvaus eli ontologia, joten
tavoitteet ovat yhtenevät. On haastavaa tässä vaiheessa tietää tarkkaan rikkaan mallin
ominaisuusvaatimukset. Käyttötapakuvausten sekä tutkimuksen avulla voidaan löytää vaatimukset,
menetelmät ja mallit, jotta konejärjestelmän ontologia voidaan hallitusti tuottaa.
Yksittäisten työvälineiden ratkaisuihin löytyy ratkaisumalleja, jotka tukevat tuotantomenetelmien kehitystä.
Kokonaisuuden kannalta yksittäisistä ratkaisuista tulisi löytää yhteensopivia, modulaarisia, laajennettavia ja
prosessien hallintaa tukevia malleja ja menetelmiä. Eri tieteen aloilla on eriäviä käsityksiä
lähestymistavoista. Perinteinen tapa lähestyä loppusovelluksesta käsin ”reverse engineering” –periaatteella
edellyttää myös lähdeaineistojen rikkauden ja yhteensopivuuden huomioimista sekä kokonaisputkilinjan
ymmärrystä. Toisaalta yleisen, kattavan ja yhtenäisen aineiston tuottaminen on erittäin haastavaa, jolloin
Selvitysraportti
56
rajauksen ja sovellusalueen ymmärrys on keskeistä. Ohjelmiston kirjastointiratkaisujen sekä yhtenevien
teknologioiden avulla voidaan löytää mielekkäitä lähestymistapoja.
Ohjelmistojen
yhteensopivuutta
tulisi
kehittää
sekä
suunnitteluohjelmistojen
että
konelaboratorioteknologioiden lisäksi. Virtuaalisen konelaboratorion sovellusteknologiat edellyttävät
semanttiseen mallinnukseen soveltuvien teknologioiden integrointia tai ohjelmointia. Nykyiseen
teknologiavalintaratkaisuun (C# ja .NET) on löydetty sovellusteknologioita, mutta myös vaihtoehtoisia
toimiviksi koettuja JAVA –teknologiapohjaisia. Selvitystyö jatkuu edelleen.
Järjestelmän toimintalogiikan kuvausta aineistot ja suunnitteluohjelmat eivät suoraan tue. Tämä pitää
kuvata käsityönä. Myös yksilöivien tunnisteiden automatisoitu tuottaminen edellyttää nimikkeiden
yhtenäistämistä ja käsin tehtävää tarkistusta.
Selvityksen avulla voidaan määrittää tarkemmin toimenpiteitä ja aikatauluja. Ne esitetään erillisessä
dokumentissa ohjausryhmän päätösten perusteella.
Lähteet:
Digitaalinen
suunnittelu
ja
valmistus
eli
tietotekniikka
koneenrakennuksessa
http://akseli.tekes.fi/opencms/opencms/OhjelmaPortaali/ohjelmat/MASINA/fi/Dokumenttiarkisto/Viestint
a_ja_aktivointi/Julkaisut/Digiraporttiver1.5.pdf.
Selvitysraportti
57
5. Liitteet
Liite 5.1. Tutkimusongelmat
Semogen hankkeen tutkimusongelmat:
1. Miten konejärjestelmien suunnitteludokumentteja ja suunnitteluohjelmistojen tuottamaa
informaatiota voidaan hyödyntää virtuaalisen konelaboratorion rakentamisessa? TIEDON
HYÖDYNNETTÄVYYS JA EHEYS
a. Mitä konejärjestelmän suunnittelutietoa voidaan hyödyntää simulointimallin (ja
parametrit), mekaniikkamallien 3D, kaavionäkymien ja toimintokuvausten
suunnitteluaineiston ja semanttisen mallinnuksen avulla?
b. Mitä konejärjestelmien suunnitteluohjelmistojen tietoja ja tietorakenteita voidaan
hyödyntää virtuaalisen konelaboratorion pohja-aineistona?
c. Miten eri järjestelmissä ja dokumenteissa oleva informaatio voidaan yhdistää semanttisesti
eheäksi malliksi?
2. Miten virtuaalisen konejärjestelmäontologia määritetään? SEMANTTINEN MALLINNUS
a. Millä sanastoilla ja standardeilla konejärjestelmäontologia kuvataan virtuaalisen
konelaboratorion kehitykseen?
b. Miten yhtenevä ja koneen käsiteltävissä oleva ontologia tuotetaan?
c. Minkälainen on ontologian tuotantoprosessi?
3. Miten virtuaalisen konelaboratorion tuotantomenetelmiä pitäisi kehittää, jotta käsityön määrää
voidaan vähentää ja prosesseja automatisoida? TUOTANTOMENETELMÄT ja AUTOMATISOINTI
a. Miten konejärjestelmä tulisi semanttisesti mallintaa ja kuvata, jotta mallia voidaan
hyödyntää automaattisessa generoinnissa ja visualisoinneissa?
b. Mistä ohjelmistoista ja vaiheista konelaboratorion automaattisten tuotantomenetelmien
putkilinja-arkkitehtuuri ja suunnittelumenetelmä koostuu?
c. Miten suunnittelumenetelmiä tulee kehittää, jotta virtuaalisen konelaboratorion
aineistovaatimukset voidaan tarkoituksenmukaisesti huomioida?
4. Mitä lisäarvoja kehitetyt tuotantomenetelmät ja -ohjelmistot tuovat liiketoimintaprosesseihin?
TUOTANTOMENETELMIEN LISÄARVOT
a. Mitä lisäarvoja konelaboratorio ja tuotantomenetelmät tuovat tekniseen koulutukseen?
b. Mitä lisäarvoja konelaboratorio ja tuotantomenetelmät tuovat virtuaaliseen prototypointiin
ja suunnitteluratkaisujen arviointiin?
c. Mitä yleisvaikutuksia tuotantomenetelmien kehityksellä ja virtuaalisen konelaboratoriolla
on konejärjestelmän suunnitteluprosessiin?
Näistä voidaan rakentaa myös hypoteesit.
Selvitysraportti
58
Liite 5.2. Sovellusesimerkit
Sovellusesimerkki 1. Huoltoasentajakoulutus ja kouluttajan työvälineet
Yleistavoite: Pilot –järjestelmään rakennetaan maanalaisen poralaitteen Jumbon puomiston virtuaalinen
konelaboratorio, jonka avulla koulutetaan sähköhydraulisen konejärjestelmän toimintaperiaatteita,
vianetsintää sekä järjestelmän ominaisuuksia. Pilot –järjestelmä sisältää myös automaattisen
tunneliporauksen yleispiirteitä. Järjestelmä sisältää kouluttajan työvälineet, joiden avulla kouluttaja voi
laatia, muokata ja hallita esitys- ja vikaskenaarioita sekä havainnollistaa hakujen ja visualisointien avulla
huoltoasentajakoulutuksen tavoitteiden mukaisesti laitteen toiminto- ja komentoketjuja, hydraulista paineja tilavuusvirtaa, ohjausjärjestelmän ja väyläliikenteen yhteyttä sekä keskeisiä mittauksia ja testejä.
Tavoitteena on hyödyntää M1 –teknologioita, jotka on rakennettu mahdollisimman
aineistoriippumattomiksi ja geneerisiksi, jotta uudet mallit, kuvaukset sekä aineistot voidaan liittää
ohjelmiston alustustietoina. Uudet ominaisuudet liittyvät semanttiseen hakuun ja tiedon visualisointiin
sekä kevyesti tunneliporaukseen
Sisältörajaus:







Huoltoasentajakoulutuksen aihepiirit liittyen puomistoon
Laitteen ohjaus ja hallintalaitteet
Puomiston hydrauliikka ja mekaniikka
Puomiston automatiikka, väyläliikenne ja analyysi
Vika- ja ongelmakuvaukset sekä analyysi hydrauliikan ja väylien osalta
Tunneliporaustapahtuma ja operaatiot
Koulutuksen suunnittelu ja toteutus
Ominaisuudet ja toiminnallisuudet




Tiedon visualisoinnit
o Laite- järjestelmä, alijärjestelmä, komponenttiryhmä, komponentti, osa
o Kaaviot
o Mittarit ja testit
o Nauhoitukset
o Osaluettelo
Käyttöliittymä
o M1 –teknologia
o Jumbon 2,5D tai 3D –näkymä toimii perusjäsennyksenä, halkaistu
Editorit
o Skenaarioiden editori ja hallinta (soveltuvin osin)
o Toimintoketjueditori
o Toimintopuueditori
Työprosessien hallinta
o Tunnelin poraussuunnitelma
o Operaattorin toteuttamat manuaaliset ohjaus- ja hallintatoimenpiteet
Selvitysraportti
59
Käyttötapakuvaus
Kouluttajalla on käytössään virtuaalinen konelaboratorio, joka perustuu M1 –teknologioihin. Tässä
hyödynnetään aikaisemmissa projekteissa tuotettuja ohjelmistoja ja määrityksiä. Tarkemmat ominaisuudet
löytyvät M1 –teknologioita hyödyntävistä konelaboratorioista.
Ominaisuudet on kuvattu luvussa 2.9. Näistä ominaisuuksista pilot –ympäristössä on käytössä:
a) Puomiston dynaaminen hydrauliikka-, sähkö- ja väyläkaavio, jossa paine- ja sähköiset signaalit
visualisoidaan simulointimallin perusteella. Kaaviosta löytyvät kahdeksan toimilaitetta. Puomin kääntö,
nosto, zooom, syöttölaitteen kallistus, kääntö, siirto, lisäkallistus ja rollover. Komponenttien yksilöidyt
nimet ja yhteydet osaluetteloon, reaalikuvaukseen sekä wiki –ympäristön kanssa.
Kaaviot sisältävät myös mittauspisteet väylän ohjaussignaalin mittaamisen oskilloskoopilla (vaatii
määrittelyn), paine- ja tilavuusvirran mittauksen, delta p –testin. Mittausvälineet ovat piirturi, analoginen,
oskilloskooppi ja CAN analysaattorin kevyt versio.
b) Puomijärjestelmän dynaamisen simulointimalli toimilaitekohtaisesti mallinnettuna
koulutustarkoitukseen soveltuvalla tasolla.
c) Puomiston mekaniikkamallista tuotettu reaalinen 3D –näkymä havainnollistaa puomiston päätoiminnot,
nivelet, sylinterit ja rakenteet koulutustarkoitukseen soveltuvalla tasolla. Lisäksi havainnollistetaan pumppu
ja venttiililohko. Letkustoa ei kuvata.
d) Osaluettelo, joka kuvaa koulutustarkoitukseen soveltuvalla tasolla puomistosta järjestelmäalijärjestelmä-komponenttiryhmä- komponentti- osa.
e) Lisäaineisto wikissä mahdollistaa järjestelmän lisätiedon esittämisen järjestelmä-alijärjestelmäkomponenttiryhmä- ja komponenttikohtaisesti.
f) Vikakuvauksien muokkain, jossa on kuvattu vuoto, tukos, kaapelikatkos, liitinvika, (tarkemmin)
e) Toimintoketjumuokkain, jonka avulla kouluttaja voi määrittää järjestelmän komento-/toimintoketjuja
ohjaimista toimilaitteisiin.
g) Semanttisen haun ja tiedon visualisoinnin välineet. Kouluttaja voi hakea seuraavilla hakuehdoilla
- tietyn alijärjestelmän hydrauliset, sähköiset ja tietoliikennekomponentit
- tiettyjä ominaisuuksia sisältävät ja tietyn tyyppiset komponentit- ja komponenttiryhmät
jäsennettynä teknologioittain (määritys). Esimerkiksi esitä puomistosta
painekompensaattorit. Esitä puomin noston toimintaan vaikuttavat sähköiset ja hydrauliset
komponentit.
- komentoketjut päätoimintojen mukaisesti
Hakuehtojen mukaan tulokset esitetään kaaviossa ja reaalikuvauksessa sekä listauksena.
h) Tunnelin katkoksen poraussuunnitelma 3D näkymässä. Ei poraustapahtumaa.
Selvitysraportti
60
Kouluttaja opettaa puomiston koneautomaatiojärjestelmän toimintaperiaatteita, kaavioiden lukua,
vianetsintää sekä toimintaympäristön vaikutuksia. Kts. liite 4. Näistä kohdennutaan hydrauliikkaa,
tietoliikenteeseen ja sähkö-elektroniikkaosuuteen. Muita osa-alueita ei tueta. Yksittäisten teknologioiden
lisäksi läpäisevinä aihepiireinä hyödynnetään kunnossapidosta vianhaku sekä käytön osalta työympäristön
lämpötilan muutos sekä järjestelmään vaikuttava epäpuhtaus.
Opetuksessa hyödynnetään M1 –teknologian välineistöä. Kouluttaja laatii opintojaksosuunnitelman
konelaboratorion ominaisuuksien ja mahdollisuuksien perusteella. Opintojakso sisältää kouluttajan
toteuttaman luennon, jossa konelaboratoriota hyödynnetään sekä käytännön vianhakuharjoituksia.
Sovellusesimerkki 2. Automaattinen generaatio
Yleistavoite: Virtuaalisen konelaboratorion generointi automaattisesti ja/tai semiautomaattisesti
suunnitteludokumenttien, -ohjelmistojen ja konelaboratorion semanttisten kuvausmenetelmien avulla.
Mallien, suunnittelutietojen ja kuvausten hyödyntämiseen kehitetään mallinnus-, ohjelmistokehitys- ja
suunnittelumenetelmiä, jotka tukevat mahdollisimman automaattista tiedon käsittelyä. Sovellusesimerkki
liittyy olennaisesti esimerkki 1:seen, jonka ominaisuuksien ja toiminnallisuuksien kehittämisen ratkaisuja
automatisoidaan. Keskeiset automaattisesti generoitavat ominaisuudet ja toiminnallisuudet on kursivoitu.
Sisältörajaus:





Suunnittelumenetelmän kuvaus
Puomistokonstruktion rajaus dokumentaatiosta ja suunnittelujärjestelmistä
Virtuaalisen konstruktioluonnoksen tuottaminen virtuaaliseen konelaboratorioon
Konstruktioluonnoksen kuvaus, muokkaus ja jalostus
Konstruktion julkaisu ja käyttö
Ominaisuudet ja toiminnallisuudet




Tiedon visualisoinnit
o Laite- järjestelmä, alijärjestelmä, komponenttiryhmä, komponentti, osa
o Kaaviot
 kaavioiden väliset yhteydet
 hydraulikaavio
 väyläkaavio
 sähkökaavio
o Mittarit ja testit
o Nauhoitukset
o Osaluettelo
Käyttöliittymä M1 –työvälineet ja Jumbon 2,5D tai 3D –näkymä toimii perusjäsennyksenä,
Editorit
o Skenaarioeditori ja hallinta
o Toimintoketjueditori
o Toimintopuueditori
Työprosessien hallinta
Selvitysraportti
o
o
61
Tunnelin poraussuunnitelma
Operaattorin manuaaliset ohjaus- ja hallintatoimenpiteet
Käyttötapakuvaus
Älykkään ja virtuaalisen konelaboratorion suunnittelijat, ohjelmoijat ja kehittäjät toteuttavat uuden
konejärjestelmän suunnitteludokumenttien, ohjeistetun suunnittelumenetelmän, suunnittelujärjestelmien
sekä konelaboratorion sovellusten avulla. Merkittävä etu on siinä, että määritetty suunnitteluprosessi ja
teknologiat tukevat mahdollisimman hyvin automaattista tiedon hakua aineistoista ja niiden perusteella
tapahtuvaa automaattista generointia. Järjestelmän generoinnin tavoitteena on saada sovellusesimerkki
1:n mukaiset toiminnot.
1. Määritetään konelaboratorion tarpeet , käyttötarkoitus ja käyttäjät
2. Määritetään konelaboratorion ominaisuudet, näkymät ja toiminnallisuudet
3. Määritetään tarkoituksenmukainen konejärjestelmärajaus
4. Selvitetään käytettävissä oleva aineisto generointivaatimusten mukaisesti. Analysoidaan vaatimuksia
vasten aineiston hyödynnettävyys
5. Hyödynnetään kehitettyä suunnittelumenetelmää ja ohjeistuksia aineistojen kuvauksessa.
6. Tuotetaan puuttuva aineisto suunnittelujärjestelmien ja virtuaalisen konelaboratorion muokkainten
avulla.
7. Tunnistetaan aineistojen muokkaus- ja konvergointitarpeet
8. Hyödynnetään virtuaalisen konelaboratorion tuotantoon soveltuvia teknologioita
konelaboratorioluonnoksen automaattisessa tuottamisessa ja rikastuttamisessa alueittain simulointimalli,
reaalinen 3D, dynaaminen kaavio, toimintakuvaus, sisältöluettelo ja hakumahdollisuudet.
9. Testataan luonnos ja arvioidaan kehitystarpeet
10. Jalostetaan ja muokataan aineistoa.
11. Generoidaan aineisto konelaboratorioon
12. Tarkistetaan konelaboratorion toimivuus.
Sovellusesimerkki 3. Jumbon puomin konstruktiomuutos
Yleistavoite: Konejärjestelmään suunnitellaan ja toteutetaan konstruktiomuutos, jota halutaan virtuaalisen
konelaboratorion avulla arvioida ja testata. Sovellusesimerkki 1 ja 2 toimii perustana esimerkki 3:lle.
Fysikaalisen mallin parametrien ja semanttisen mallin avulla voidaan konstruktiomuutokset automaattisesti
toteuttaa. Konstruktiomuutokset ja niiden kuvaukset voidaan hakea ja rajata sekä visualisoida
Selvitysraportti
62
pilotjärjestelmän avulla. Konstruktiomuutosten vaikutuksia konejärjestelmään arvioidaan konelaboratorion
työvälineillä. Kokemuksia hyödynnetään sekä suunnittelijan että huoltoasentajan koulutuksessa.
Sisältörajaus:

Jumbon puomistorakenne
o Puomiston hydraulipumpun korvaus pienemmällä (liian vähän tilavuusvirtaa) pumpulla.
o Noston toimilaitteen sylinterien mitoitusvaihtoehdot.
o Yhdessä sylinterissä on valmistusvika, joka aiheuttaa ulkoisen vuodon.
o Konstruktiomuutosten testaus ja arviointi sylintereiden osalta kuumissa +30 ° C ja kylmissä
-25 ° C olosuhteissa sekä pölyisessä ympäristössä.
o Konstruktioita arvioidaan lisäksi 1000 h ja 5000 h käytön jälkeen.
o Sylinterissä on tiivistevaurio, joka aiheuttaa vuodon kammioiden välille.
o Vertailu alkuperäisen konstruktion kanssa.
Ominaisuudet ja toiminnallisuudet





Konstruktion muutos suunnitteludokumentaation rajauksessa
Tarvittavien mallien haku ja liitäntä
Semanttinen kuvaus luonnoksen perusteella
Konstruktiomuutoksen tarkastelu, testaus ja arviointi
Vertailut
Käyttötapakuvaus
Konejärjestelmän suunnittelija haluaa testata konstruktiomuutoksen vaikutuksia puomin käyttäytymiseen.
Suunnittelija mittaa tarvittavat/haluamansa ominaisuudet alkuperäisestä järjestelmästä ja tallentaa arvot
konelaboratorioon.
Suunnittelija voi pienentää pumpun kokoa tai vaihtaa puomin nostosylinterin kokoa. Lisäksi suunnittelija voi
tutkia käyttötuntien ja ympäristön lämpötilan ja pölyisyyden vaikutuksia järjestelmän ominaisuuksiin.
Suunnittelija voi koostaa järjestelmän tukemista muutoksista haluamansa kombinaation.
Suunnittelija määrittää virtuaalisen konelaboratorion kehittäjien kanssa tarvittavat komponentit
ohjelmistokirjastoista ja toteuttaa automaattisen generointiprosessin (sovellusesimerkki 2). Järjestelmä
sisältää mahdollisuuden muuttaa määriteltyjen komponenttien ja järjestelmän simulointiparametreja.
Suunnittelija suorittaa tarvittavat/haluamansa mittaukset muutetusta konstruktiosta. Tarvittavia mittauksia
voivat olla esimerkiksi pumpun ohjearvo, pumpun tuottama tilavuusvirta, nostosylinterin nopeus,
nostosylinterin asema, paineet sylinterikammoissa, venttiilin ohjaussignaali sekä paine-ero suodattimen yli.
Suunnittelija tallentaa arvot konelaboratorioon. Suunnittelija vertaa konstruktio- , ympäristö- ja/tai
elinkaarimuutoksia alkuperäiseen järjestelmään mittaustulosten avulla.
Selvitysraportti
63
Liite 5.3. Koneautomaatiojärjestelmien teknologioiden osaamiskartta
Luonnos: TTY/SmartSimulators –tutkimusryhmä
Kari T. Koskinen ja Pekka Ranta 21.5.2010
Liikkuvien työkoneiden koneautomaatiojärjestelmien teknologioiden osaamiskartta
Kartan tarkoitus on alustavasti määrittää teknologioittain osaamisvaatimuksia, jotta älykkäitä ja virtuaalisia
konelaboratorioita voidaan kehittää koulutuskäyttöön. Järjestelmäosaamisen taustalla on teknologioiden
perusteet, joita tässä ei kuvata. Osaamiskarttaa on tarkoitus jalostaa useissa eri hankkeissa.
Käyttö, kunnossapito, turvallisuus, ympäristötekijät ja energiatehokkuus toimivat teknologioita läpäisevinä
aihepiireinä. Nämä myös syventävät teknologioissa vaadittavaa osuutta. Ne kuvataan ja tarkennetaan eri
kartassa. Osaamiskartat laaditaan koneasentajalle, suunnittelijalle ja teknologiajohtajalle.
Profiili 1: Koneasentaja
Hydrauliikka
Kaavioiden luku ja tulkinta
Sähkö- ja elektroniikka
Sähkökaavioiden luku ja tulkinta
Hydraulisen järjestelmän
toiminnan ymmärrys ja yhteydet
konejärjestelmiin
Venttiilien ja toimilaitteiden
sähköinen ohjaus (jännite ja virta)
Komponenttien rakenteen ja
toiminnan tuntemus
Komponenttien rakenteen ja
toiminnan tuntemus
Järjestelmän tilan diagnosointi
Järjestelmän säätö
Järjestelmän tilan diagnosointi
Järjestelmän säätö
Mekaniikka
Piirrosten luku ja tulkinta
Materiaalien ja perusrakenteiden
ominaisuudet
Pneumatiikka
Kaavioiden luku ja tulkinta
Pneumaattisen järjestelmän
toiminnan ymmärrys ja yhteydet
konejärjestelmiin
Komponenttien rakenteen ja
toiminnan tuntemus
Polttomoottoritekniikat
Piirrosten luku ja tulkinta
Polttomoottorien perusrakenteen
ja toiminnan ymmärrys sekä
yhteydet konejärjestelmiin
Komponenttien rakenteen ja
toiminnan tuntemus
Järjestelmän tilan diagnosointi
Järjestelmän tilan diagnosointi
Järjestelmän säätö
Kaavioiden luku ja tulkinta
Järjestelmän säätö
Laakerointi-, tiiviste- ja
nivelratkaisujen sekä johteiden
ymmärrys
Järjestelmän tilan koestus ja
diagnosointi
Tribologia
Tietoliikenne ja ohjelmistot
Tietoliikennekaavioiden luku ja
tulkinta
Tietoliikenneväylän,
verkkorakenteen ja
kommunikaation perusteiden
tuntemus ja yhteydet
konejärjestelmiin.
Kokonaisohjauksen
perusrakenteen ja toiminnan
ymmärrys sekä yhteydet
konejärjestelmiin
Väyläohjaus toimilaitteelle
Anturien ja mittalaitteiden
toiminnan merkityksen ymmärrys
Järjestelmän tilan diagnosointi
Järjestelmän säätö