Semogen I -hankkeen loppuraportti (PDF)
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 ([email protected]) 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 yD5, 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(xX) 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:[email protected]" /> </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, rf (because a failing rule is always due a firing rule). Thus, it always holds that F1. 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 ([email protected]) 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@[email protected]. 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ö
© Copyright 2024