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

Koko: px
Aloita esitys sivulta:

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

Transkriptio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

Luento 12: XML ja metatieto

Luento 12: XML ja metatieto Luento 12: XML ja metatieto AS-0.110 XML-kuvauskielten perusteet Janne Kalliola XML ja metatieto Metatieto rakenne sanasto Resource Description Framework graafikuvaus XML Semanttinen Web agentit 2 1 Metatieto

Lisätiedot

W3C-teknologiat ja yhteensopivuus

W3C-teknologiat ja yhteensopivuus W3C-teknologiat ja yhteensopivuus Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), Hypermedialaboratorio W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: W3C asettaa

Lisätiedot

Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0. Kuntamarkkinat Tuula Seppo, erityisasiantuntija

Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0. Kuntamarkkinat Tuula Seppo, erityisasiantuntija Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0 Kuntamarkkinat 14.9.2016 Tuula Seppo, erityisasiantuntija Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0 Hallinnon toimintatapojen digitalisointi

Lisätiedot

REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN

REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN Arkistolaitos REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN Ohje v. 1.0 (16.10.2012) Kansallisarkisto Rauhankatu 17 PL 258, 00171 Helsinki Puh. Tel. (09) 228 521 arkisto@narc.fi Riksarkivet

Lisätiedot

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen 16.06.2014 Ohjaaja: Urho Honkanen Valvoja: Prof. Harri Ehtamo Työn saa tallentaa ja julkistaa Aalto-yliopiston

Lisätiedot

Sisällönhallinnan menetelmiä

Sisällönhallinnan menetelmiä Sisällönhallinnan menetelmiä Airi Salminen Jyväskylän yliopisto http://www.cs.jyu.fi/~airi/ Suomalaisen lainsäädäntötyön tiedonhallinta: suuntana semanttinen web RASKE2-projektin loppuseminaari Eduskunnassa

Lisätiedot

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen 1 FYSIIKKA Fysiikan päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta fysiikan opiskeluun T2 ohjata

Lisätiedot

Metatiedot organisaatioiden sisällönhallinnassa

Metatiedot organisaatioiden sisällönhallinnassa Metatiedot organisaatioiden sisällönhallinnassa Airi Salminen Jyväskylän yliopisto http://www.cs.jyu.fi/~airi/ Lainsäädäntöprosessin tiedonhallinnan kehittäminen Metatiedot suomalaisen lainsäädäntöprosessin

Lisätiedot

Virtuoosi POS-järjestelmien joukossa

Virtuoosi POS-järjestelmien joukossa Virtuoosi POS-järjestelmien joukossa Menestyvä liiketoiminta muistuttaa monin osin huippuunsa viritettyä orkesteria jossa eri osien sopusuhtainen vuorovaikutus ja integrointi luovat sykähdyttävän esityksen.

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

AVOIN DATA AVAIN UUTEEN Seminaarin avaus Kansleri Ilkka Niiniluoto Helsingin yliopisto

AVOIN DATA AVAIN UUTEEN Seminaarin avaus Kansleri Ilkka Niiniluoto Helsingin yliopisto AVOIN DATA AVAIN UUTEEN Seminaarin avaus 1.11.11 Kansleri Ilkka Niiniluoto Helsingin yliopisto TIETEELLINEN TIETO tieteellinen tieto on julkista tieteen itseäänkorjaavuus ja edistyvyys tieto syntyy tutkimuksen

Lisätiedot

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen KEMIA Kemian päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta kemian opiskeluun T2 ohjata ja

Lisätiedot

Teollisuuden digitalisaatio ja johdon ymmärrys kyvykkyyksistä

Teollisuuden digitalisaatio ja johdon ymmärrys kyvykkyyksistä Teollisuuden digitalisaatio ja johdon ymmärrys kyvykkyyksistä Markus Kajanto Teollisuuden digitalisaation myötä johdon käsitykset organisaation resursseista, osaamisesta ja prosesseista ovat avainasemassa

Lisätiedot

VBE II Tulosseminaari Teknologian valmiusaste. Virtuaalirakentamisen Laboratorio Jiri Hietanen

VBE II Tulosseminaari Teknologian valmiusaste. Virtuaalirakentamisen Laboratorio Jiri Hietanen VBE II Tulosseminaari Teknologian valmiusaste 1 2 Sisältö Tietomalleihin perustuva järjestelmä Järjestelmän osien valmiusaste Rakennuksen tietomallien tuottaminen Rakennuksen tietomalleihin perustuvat

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 3. Arkkitehtuurin nykytilan ja tavoitetilan kuvaus

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 3. Arkkitehtuurin nykytilan ja tavoitetilan kuvaus JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 3. Arkkitehtuurin nykytilan ja tavoitetilan kuvaus Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi Sisällys

Lisätiedot

Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous

Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous 12.6.2015 Pasi Oksanen 1 Tavoite ja lähtökohdat Tavoitteena aikaansaada Varsinais-Suomen

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi Sisällys

Lisätiedot

Johdatus rakenteisiin dokumentteihin

Johdatus rakenteisiin dokumentteihin -RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista

Lisätiedot

Projektin tilanne. Tavaraliikenteen telematiikka-arkkitehtuuri Liikenne- ja viestintäministeriö

Projektin tilanne. Tavaraliikenteen telematiikka-arkkitehtuuri Liikenne- ja viestintäministeriö Projektin tilanne Tavaraliikenteen telematiikka-arkkitehtuuri Liikenne- ja viestintäministeriö Tehtyä työtä Syksyn mittaan projektiryhmä on kuvannut tavaraliikenteen telematiikkaarkkitehtuurin tavoitetilan

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

NÄYTÖN ARVIOINTI: SYSTEMAATTINEN KIRJALLISUUSKATSAUS JA META-ANALYYSI. EHL Starck Susanna & EHL Palo Katri Vaasan kaupunki 22.9.

NÄYTÖN ARVIOINTI: SYSTEMAATTINEN KIRJALLISUUSKATSAUS JA META-ANALYYSI. EHL Starck Susanna & EHL Palo Katri Vaasan kaupunki 22.9. NÄYTÖN ARVIOINTI: SYSTEMAATTINEN KIRJALLISUUSKATSAUS JA META-ANALYYSI EHL Starck Susanna & EHL Palo Katri Vaasan kaupunki 22.9.2016 Näytön arvioinnista Monissa yksittäisissä tieteellisissä tutkimuksissa

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Teoreettisen viitekehyksen rakentaminen

Teoreettisen viitekehyksen rakentaminen Teoreettisen viitekehyksen rakentaminen Eeva Willberg Pro seminaari ja kandidaatin opinnäytetyö 26.1.09 Tutkimuksen teoreettinen viitekehys Tarkoittaa tutkimusilmiöön keskeisesti liittyvän tutkimuksen

Lisätiedot

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä Liite 4 Nykytilan ja tavoitetilan kuvaus Versio:1.0 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Nykytilan kuvaaminen...

Lisätiedot

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Terveyden

Lisätiedot

Ne liittyvät samaan henkilöön, paikkaan, projektiin, asiaan, asiakkaaseen, tapahtumaan tai seikkaan.

Ne liittyvät samaan henkilöön, paikkaan, projektiin, asiaan, asiakkaaseen, tapahtumaan tai seikkaan. 6. Asiakirjapalvelu 6.1 PALVELUINFORMAATIO Palvelun nimi Asiakirjapalvelu Palvelun versio 1.0 Tunnus (ks. M14.4.42) 6.2 Avainkäsitteet 6.2.1 Tarkoituksenmukainen asiakirjakoosteiden muodostaminen MoReq2010

Lisätiedot

mekaniikka suunnittelu ohjelmisto

mekaniikka suunnittelu ohjelmisto Ver tex Systems Oy on vuonna 1977 perustettu suomalainen tietokoneohjelmistoja valmistava yritys. Kehitämme ja markkinoimme tekniseen suunnitteluun ja tiedonhallintaan tarkoitettuja Vertex-ohjelmistoja.

Lisätiedot

Korkeakoulujen yhteentoimivuusmalli

Korkeakoulujen yhteentoimivuusmalli Korkeakoulujen yhteentoimivuusmalli Tavoitteena korkeakoulujen opetus-, tutkimus- ja julkaisutietojärjestelmien yhteentoimivuus Miika Alonen Suvi Remes Nykytila Esim. Kirjastotoimi Opintopolku? Korkeakoulujen

Lisätiedot

Jäsenyysverkostot Kytkökset ja limittyneet aliryhmät sosiaalisten verkostojen analyysissä

Jäsenyysverkostot Kytkökset ja limittyneet aliryhmät sosiaalisten verkostojen analyysissä Jäsenyysverkostot Kytkökset ja limittyneet aliryhmät sosiaalisten verkostojen analyysissä Hypermedian jatko-opintoseminaari 2008-2009 20.3.2009 Jaakko Salonen TTY / Hypermedialaboratorio jaakko.salonen@tut.fi

Lisätiedot

Paikkatiedon kehittämisohjelma

Paikkatiedon kehittämisohjelma Paikkatiedon kehittämisohjelma 2011-2014 Toimeenpanon toteutumisen tilannekatsaus, siht. Outi Hermans Tiivistelmä Strategiset päämäärät Missio: Kaupungin tehtävänä on palvella kuntalaisiaan ja alueellaan

Lisätiedot

W3C ja alueellinen standardointi

W3C ja alueellinen standardointi W3C ja alueellinen standardointi Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: W3C on kansainvälinen konsortio

Lisätiedot

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure Automaattinen regressiotestaus ilman testitapauksia Pekka Aho, VTT Matias Suarez, F-Secure 2 Mitä on regressiotestaus ja miksi sitä tehdään? Kun ohjelmistoon tehdään muutoksia kehityksen tai ylläpidon

Lisätiedot

arvioinnin kohde

arvioinnin kohde KEMIA 9-lk Merkitys, arvot ja asenteet T2 Oppilas tunnistaa omaa kemian osaamistaan, asettaa tavoitteita omalle työskentelylleen sekä työskentelee pitkäjänteisesti T3 Oppilas ymmärtää kemian osaamisen

Lisätiedot

Yhteentoimivuutta edistävien työkalujen kehittäminen - JulkICTLab pilottiehdotus

Yhteentoimivuutta edistävien työkalujen kehittäminen - JulkICTLab pilottiehdotus Yhteentoimivuutta edistävien työkalujen kehittäminen - JulkICTLab pilottiehdotus Pilottiehdotuksen osapuolet: CSC Tieteen tietotekniikan keskus Oy Verohallinto Yhteyshenkilö: Suvi Remes suvi.remes@csc.fi

Lisätiedot

TTA palvelukokonaisuuden esittely Korkeakoulujen IT-päivät 6.11.2013

TTA palvelukokonaisuuden esittely Korkeakoulujen IT-päivät 6.11.2013 TTA palvelukokonaisuuden esittely Korkeakoulujen IT-päivät 6.11.2013 CSC Tieteen tietotekniikan keskus Oy Tutkimuksen tietoaineistot 2014-2017 Keskeinen tavoite edistää sähköisten tutkimusaineistojen hyödyntämistä,

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi

Lisätiedot

SÄHKÖTEKNIIKAN KOULUTUSOHJELMA 2010

SÄHKÖTEKNIIKAN KOULUTUSOHJELMA 2010 SÄHKÖTEKNIIKAN KOULUTUSOHJELMA 2010 Sähkötekniikan koulutusohjelman toimintaympäristö ja osaamistavoitteet Sähkötekniikan koulutusohjelma on voimakkaasti poikkialainen ja antaa mahdollisuuden perehtyä

Lisätiedot

Valo- ja äänisuunnittelun laitoksen kehittämishanke Digitaalisen äänen tutkimusprojekti

Valo- ja äänisuunnittelun laitoksen kehittämishanke Digitaalisen äänen tutkimusprojekti Valo- ja äänisuunnittelun laitoksen kehittämishanke Digitaalisen äänen tutkimusprojekti Jatkohanke vuonna 2001 aloitetulle digitaalisen valon ja äänen tutkimushankkeelle, jolle saatiin 2001 osarahoitus.

Lisätiedot

ELATI-SEMINAARI Eviran puheenvuoro LIMS-YLVA projekti: -ajatuksia standardoinnista ja luokittelusta

ELATI-SEMINAARI Eviran puheenvuoro LIMS-YLVA projekti: -ajatuksia standardoinnista ja luokittelusta ELATI-SEMINAARI Eviran puheenvuoro LIMS-YLVA projekti: -ajatuksia standardoinnista ja luokittelusta 1 LIMS-YLVA sanastot ja standardit Sisältö Eviran LIMS-YLVA hanke Sanasto LIMS-YLVA hankkeessa Standardit

Lisätiedot

Liikkuvien työkoneiden etäseuranta

Liikkuvien työkoneiden etäseuranta Liikkuvien työkoneiden etäseuranta TAMK IoT Seminaari 14.4.2016 2 1) IoT liiketoiminnan tukena 2) Iot ja liikkuvat työkoneet 3) Case esimerkit 4) Yhteenveto, johtopäätökset, tulevaisuuden näkymät Cinia

Lisätiedot

Finna ja ontologiat tms.

Finna ja ontologiat tms. Finna ja ontologiat tms. Erkki Tolonen 3.9.2014 Finna.fi - taustaa FINNA on osa Kansallinen digitaalinen kirjasto hanketta, sen asiakasliittymä, joka on toteutettu avoimen lähdekoodin ohjelmistojen päälle.

Lisätiedot

buildingsmart Finland

buildingsmart Finland buildingsmart Finland Tero Järvinen buildingsmart Finland Talotekniikkatoimialaryhmä Finnbuild 2014 03.10.2014 TALOTEKNIIKKATOIMIALARYHMÄN KYSELY Kyselyn tarkoitus Kartoittaa talotekniikan tietomallikäytäntöjä

Lisätiedot

Kansallisen paikkatietoportaalin kehittäminen

Kansallisen paikkatietoportaalin kehittäminen Kansallisen paikkatietoportaalin kehittäminen 20.9.2010 VN periaatepäätös Valtioneuvoston periaatepäätökseen 21.6.2007 kansallisen tietoyhteiskuntapolitiikan tavoitteista vuosina 2007-2011 on kirjattuna:

Lisätiedot

Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos. Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke

Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos. Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke Rakenteisuus kahdella tasolla Oppimisaihiot ( Learning Objects

Lisätiedot

Laatukäsikirja - mikä se on ja miten sellainen laaditaan?

Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka

Lisätiedot

Semantic Web käytännön sovelluksissa. TkT Janne Saarela Profium Oy

Semantic Web käytännön sovelluksissa. TkT Janne Saarela Profium Oy Semantic Web käytännön sovelluksissa TkT Janne Saarela Profium Oy 26.5.2004 Sisällysluettelo Johdanto Semanttisen Webin maailmaan Mahdollisuudet Tämän päivän käyttökohteet Haasteet 1 Johdanto Semanttisen

Lisätiedot

Mallinnusinnovaatioiden edistäminen infra-alalla hankinnan keinoin

Mallinnusinnovaatioiden edistäminen infra-alalla hankinnan keinoin TEKNOLOGIAN TUTKIMUSKESKUS VTT OY Mallinnusinnovaatioiden edistäminen infra-alalla hankinnan keinoin Pirkanmaan maanrakennuspäivä 2016 12.1.2016 Markku Niemi Taustaa Liikenneviraston hallinnoiman väyläomaisuuden

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Tällä kurssilla on tutustuttu ohjelmistojen mallintamiseen oliomenetelmiä ja UML:ää käyttäen Samaan aikaan järjestetyllä kurssilla on käsitelty

Lisätiedot

Rakennustietomallien hallinta linkitettynä tietona

Rakennustietomallien hallinta linkitettynä tietona Rakennustietomallien hallinta linkitettynä tietona Seppo Törmä, Jyrki Oraskari, Nam Vu Hoang Hajautettujen järjestelmien ryhmä Tietotekniikan laitos Aalto Yliopisto, Perustieteiden korkeakoulu Rakennustietomallit

Lisätiedot

LUC-palvelupiste. Käyttöönoton vaiheet ja tulevaisuuden tavoitteet Sakari Tarvainen

LUC-palvelupiste. Käyttöönoton vaiheet ja tulevaisuuden tavoitteet Sakari Tarvainen LUC-palvelupiste Käyttöönoton vaiheet ja tulevaisuuden tavoitteet Sakari Tarvainen Taustat - Konsernin strategiasta (2009) löytyy toiminta-ajatus Palvelut tuotettava pääosin yhdessä - Yhdeksi kehityskohteeksi

Lisätiedot

Helsinki Region Infoshare Pääkaupunkiseudun tiedon avaaminen

Helsinki Region Infoshare Pääkaupunkiseudun tiedon avaaminen Helsinki Region Infoshare Pääkaupunkiseudun tiedon avaaminen Projektipäällikkö Ville Meloni Forum Virium Helsinki 2.11.2011 - MML Paikkatietomarkkinat 2011 Helsinki Region Infoshare Kehitetään tiedontuottajien

Lisätiedot

Alueelliset tietovarastot ja niiden käyttö. Terveydenhuollon ATK-päivät Janne Saarela

Alueelliset tietovarastot ja niiden käyttö. Terveydenhuollon ATK-päivät Janne Saarela Alueelliset tietovarastot ja niiden käyttö Terveydenhuollon ATK-päivät Janne Saarela 31.5.2005 Sisällysluettelo 1. Alueelliset tietovarastot Kytkös sähköisien potilaskertomuksien arkistointiin Kytkös organisaatiorajat

Lisätiedot

Luku 8. Aluekyselyt. 8.1 Summataulukko

Luku 8. Aluekyselyt. 8.1 Summataulukko Luku 8 Aluekyselyt Aluekysely on tiettyä taulukon väliä koskeva kysely. Tyypillisiä aluekyselyitä ovat, mikä on taulukon välin lukujen summa tai pienin luku välillä. Esimerkiksi seuraavassa taulukossa

Lisätiedot

MONIKONESIMULAATTORI. Uuden sukupolven ratkaisu työkonekoulutukseen

MONIKONESIMULAATTORI. Uuden sukupolven ratkaisu työkonekoulutukseen MONIKONESIMULAATTORI Uuden sukupolven ratkaisu työkonekoulutukseen Ylänäkymä 20 Ajoneuvon kohdealue Törmäys 10 Simulaattoriharjoitusraportti 17.4.2016 14:47:47 Tulos: Hyväksytty [m] 0 Arvo Pisteet -10

Lisätiedot

Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136

Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136 Laatudokumentoinnin kehittäminen, sähködokumentaatio-mapin sisältö. 3D-mallinnus ja sen käyttö Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136 Laadunhallintaan

Lisätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta

Lisätiedot

Taloteknisen suunnittelun tehtäväluettelo

Taloteknisen suunnittelun tehtäväluettelo Taloteknisen suunnittelun tehtäväluettelo HUS-suunnittelijaseminaari 18.9.2014 Kari Kaleva / Granlund Oy Esityksen sisältö Uudet suunnitteluvaiheet Taloteknisen tehtäväluettelon rakenne Avoimen rakentamisen

Lisätiedot

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa 4. Roolimallipalvelu 4.1 Tiedot palvelusta Palvelun nimi: Palvelun versio 01.01.00 Toteuttaa palvelun yksilöllistä palvelua (kts. M14.4.42) Roolimallipalvelu (Model role service) MYJ:lle, jotka toteuttavat

Lisätiedot

JOPE. Tutkimus- ja kehittämiskysymykset olivat:

JOPE. Tutkimus- ja kehittämiskysymykset olivat: Lomake C1 HANKKEEN LOPPURAPORTTI - YHTEENVETO Hankkeen numero 1080107 Työsuojelurahaston valvoja Ilkka Tahvanainen Raportointikausi 1.5-1.12.2009 Arvio hankkeen toteutumisesta Hankkeen nimi lyhyesti JOPE

Lisätiedot

Torstai Mikkeli

Torstai Mikkeli Torstai 14.2.2013 Mikkeli OSUVA (2012 2014) - Osallistuva innovaatiotoiminta ja sen johtamista edistävät tekijät sosiaali- ja terveydenhuollossa. hanke tutkii minkälaisilla innovaatiojohtamisen toimintatavoilla

Lisätiedot

Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä

Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä Omistaja Tyyppi Tiedoston nimi Turvaluokitus Kohderyhmä Turvaluokituskäytäntö --- SE/Pekka Järveläinen Projektisuunnitelma projektisuunnitelma_kielihallinto.doc

Lisätiedot

Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen

Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen Suvi Remes Miika Alonen Petri Mustajoki Totti Tuhkanen So far Toimeksianto: Opiskelun ja opetuksen tuen ja hallinnon viitearkkitehtuuri Tietoarkkitehtuurin osuuteen liittyen Synergiaryhmä 4.12.2014 linjannut,

Lisätiedot

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op FT Ari Viinikainen Tietokoneen rakenne Keskusyksikkö, CPU Keskusmuisti Aritmeettislooginen yksikkö I/O-laitteet Kontrolliyksikkö Tyypillinen Von Neumann

Lisätiedot

Käytännön ideoita verkostotyöhön & toimintatutkimuksellinen ote verkostojen kehittämiseen. Timo Järvensivu, KTT Aalto-yliopiston kauppakorkeakoulu

Käytännön ideoita verkostotyöhön & toimintatutkimuksellinen ote verkostojen kehittämiseen. Timo Järvensivu, KTT Aalto-yliopiston kauppakorkeakoulu Käytännön ideoita verkostotyöhön & toimintatutkimuksellinen ote verkostojen kehittämiseen Timo Järvensivu, KTT Aalto-yliopiston kauppakorkeakoulu Toimintatutkimus? Toimintatutkimus on sosiaalinen prosessi,

Lisätiedot

Interfacing Product Data Management System

Interfacing Product Data Management System Interfacing Product Data Management System Tekijä: Työn valvoja: Mats Kuivalainen Timo Korhonen Esitelmän sisältö Työn suorituspaikka - Ideal Product Data Oy Käsitteitä Työn tavoitteet Työn tulokset 1/5

Lisätiedot

Infra FINBIM Pilottipäivä 9. Pisararata

Infra FINBIM Pilottipäivä 9. Pisararata Infra FINBIM Pilottipäivä 9 Pisararata 6.2.2014 Pisararata: - Helsingin keskustan alle suunniteltava lähijunien kaupunkiratalenkki - Kolme asemaa: Töölö, Keskusta, Hakaniemi - Rata- ja rakentamissuunnittelu

Lisätiedot

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn

Lisätiedot

Yhteenveto. Ymmärrä kokonaisuus

Yhteenveto. Ymmärrä kokonaisuus Mikko Jokela Yhteenveto Poista tiedon monistaminen Järjestele hallittaviin kokonaisuuksiin Mahdollista informaation kulku Luo tiedolle saavutettavuus Käännä oikealle kielelle Ymmärrä kokonaisuus Yritykset

Lisätiedot

Tuotemallinnus tuottavuus- ja kilpailutekijänä Suomen buildingsmart toiminnan käynnistysseminaari

Tuotemallinnus tuottavuus- ja kilpailutekijänä Suomen buildingsmart toiminnan käynnistysseminaari Tuotemallinnus tuottavuus- ja kilpailutekijänä Suomen buildingsmart toiminnan käynnistysseminaari Keskiviikko, 31.1. 2007 Spektri, Otaniemi Reijo Hänninen, toimitusjohtaja Insinööritoimisto Olof Granlund

Lisätiedot

TOR Arkkitehtuuri. - Muiden palveluiden hyödyntäminen - Tiedon loogiset vastuut - Tietovirrat - Master data -malli - Tietojen siirto

TOR Arkkitehtuuri. - Muiden palveluiden hyödyntäminen - Tiedon loogiset vastuut - Tietovirrat - Master data -malli - Tietojen siirto TOR Arkkitehtuuri - Muiden palveluiden hyödyntäminen - Tiedon loogiset vastuut - Tietovirrat - Master data -malli - Tietojen siirto Opintopolun palveluiden hyödyntäminen TOR hyödyntää vähintään organisaatiopalvelua,

Lisätiedot

Heikki Kulusjärvi. Tuotemalliprosessin laadunvalvonta Dipoli Solibri Oy. Täyden palvelun ohjelmistotoimittaja

Heikki Kulusjärvi. Tuotemalliprosessin laadunvalvonta Dipoli Solibri Oy. Täyden palvelun ohjelmistotoimittaja Heikki Kulusjärvi Tuotemalliprosessin laadunvalvonta Dipoli 16.5.2002 Solibri Oy Täyden palvelun ohjelmistotoimittaja Projektin alkuvaiheet Päätöksenteon tuki Tuotemallintaminen, analyysi, visualisointi

Lisätiedot

Tietomallien hyödyntäminen toiminnallisessa suunnittelussa. 13.11.2014. Nicola Ugas, Sweco Architects Oy

Tietomallien hyödyntäminen toiminnallisessa suunnittelussa. 13.11.2014. Nicola Ugas, Sweco Architects Oy Tietomallien hyödyntäminen toiminnallisessa suunnittelussa 13.11.2014. Nicola Ugas, Sweco Architects Oy Sweco Architects Oy Kuuluu Suomen Sweco-konserniin Osa Sweco Architects Ab:ta, pohjoismaiden suurin

Lisätiedot

JUHTA kokous JHS 179 v 2.0 esittely VM

JUHTA kokous JHS 179 v 2.0 esittely VM JUHTA kokous JHS 179 v 2.0 esittely VM 27.01.2017 Hannu Ojala Kokonaisarkkitehtuuri JHS 179 uudistuu JHS 179 v2.0 on huomattavasti kattavampi kokonaisuus kuin edeltävä JHS 179 v1.0. Se tarjoaa päästä-päähän

Lisätiedot

Tietomallintaminen. Suunnittelun kipupisteet

Tietomallintaminen. Suunnittelun kipupisteet Tietomallintaminen Suunnittelun kipupisteet 25.10.2016 Tietomallinnus yhteiset pelisäännöt (YIV) edellytys eri järjestelmissä tuotetun tiedon yhdistämiseen (IInfraBIM-nimikkeistö) standardi tiedonsiirtoformaatit

Lisätiedot

Savonia ammattikorkeakoulu Miten tilintarkastajan tulee toimia? v. 0.5 > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%)

Savonia ammattikorkeakoulu Miten tilintarkastajan tulee toimia? v. 0.5 > 80 % % % < 50 % Suhteellinen osuus maksimiarvosta (%) Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Savonia ammattikorkeakoulu Miten tilintarkastajan tulee toimia? v. 0.5 > 80 % 80 60 % 60 50 % < 50 % Arviointialue

Lisätiedot

Tietohallinto big picture

Tietohallinto big picture Tietohallinto big picture g Tietohallinto tiedon tuottamista (liike)toiminnan tarpeisiin g Tiedon oltava Saatavissa Luotettavaa Ehjää g Tietohallinnon oltava kustannustehokasta Suorat kustannukset Epäsuorat

Lisätiedot

Määrittely- ja suunnittelumenetelmät

Määrittely- ja suunnittelumenetelmät Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka

Lisätiedot

Tietoarkkitehtuuri nyt!

Tietoarkkitehtuuri nyt! 1 Tietoarkkitehtuuri nyt! - tietoarkkitehtuuri tietovarastoinnin kivijalkana - miten ratkaista lähes kaikkia vaivaava tietojen siiloutumistauti - miten saada käyttäjät määrittelyyn mukaan Ari Hovi Ari

Lisätiedot

Tieto- ja viestintätekniikkaa opetustyön tueksi

Tieto- ja viestintätekniikkaa opetustyön tueksi Tieto- ja viestintätekniikkaa opetustyön tueksi Opettajat arvioinnin ja koulu-koti-yhteistyön toteuttajina Heidi Krzywacki, Tiina Korhonen, Laura Koistinen, Jari Lavonen 19.8.2011 1 Tutkimus- ja kehittämishankkeessa

Lisätiedot

KAUPPATIEDONSIIRRON VÄLINEET RAKENNUSALAN VERKOSTOTALOUDESSA

KAUPPATIEDONSIIRRON VÄLINEET RAKENNUSALAN VERKOSTOTALOUDESSA KAUPPATIEDONSIIRRON VÄLINEET RAKENNUSALAN VERKOSTOTALOUDESSA CM-Systems Oy tutkimuksen tausta ja tavoite tulos ja kehitetty ratkaisu ohjelmiston kuvaus projektinhallintaan erikoistunut ohjelmisto- ja konsulttiyritys,

Lisätiedot

Ketteryydestä muutamien esimerkkien kautta eli mitä voimme

Ketteryydestä muutamien esimerkkien kautta eli mitä voimme Ketteryydestä muutamien esimerkkien kautta eli mitä voimme oppia Tarzanista ja jazz-yhtyeestä Ketterä toiminta on aina ihmisten toimintaa. Kehitettäessä ketteryyttä on hyvä tarkastella prosessien takana

Lisätiedot

Tulevaisuuden Internet. Sasu Tarkoma

Tulevaisuuden Internet. Sasu Tarkoma Tulevaisuuden Internet Sasu Tarkoma Johdanto Tietoliikennettä voidaan pitää viime vuosisadan läpimurtoteknologiana Internet-teknologiat tarjoavat yhteisen protokollan ja toimintatavan kommunikointiin Internet

Lisätiedot

Järjestelmien elinkaarenhallinta, järjestelmäsalkunhallinta ja Thinking Portfolio

Järjestelmien elinkaarenhallinta, järjestelmäsalkunhallinta ja Thinking Portfolio 1 Järjestelmien elinkaarenhallinta, järjestelmäsalkunhallinta ja Thinking Portfolio Teppo Jalkanen Asiantuntijapäällikkö: Arkkitehtuuriohjaus OP Arkkitehtuuri 23.9.2016 Järjestelmäsalkunhallinnan käyttöönotto

Lisätiedot

Harjoitustehtävät ja ratkaisut viikolle 48

Harjoitustehtävät ja ratkaisut viikolle 48 Harjoitustehtävät ja ratkaisut viikolle 48 1. Tehtävä on jatkoa aiemmalle tehtävälle viikolta 42, missä piti suunnitella älykodin arkkitehtuuri käyttäen vain ennalta annettua joukkoa ratkaisuja. Tämäkin

Lisätiedot

Ikivihreä kirjasto loppuraportti määrittelyprojektille

Ikivihreä kirjasto loppuraportti määrittelyprojektille loppuraportti määrittelyprojektille Mikkelin Ammattikorkeakoulu Oy Sähkö ja informaatiotekniikan laitos Versiomuutokset 29.1.2014 viimeisin tilanne tietokantakonversiosta Mirja Loponen 7.2.2014 tarkennettu

Lisätiedot

TOIMITUSSOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ

TOIMITUSSOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ TOIMITUSSOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ Liite TS2.4 Migraatiovaatimukset 1/10 VERSIOHISTORIA Päivä Versio Kuvaus Tekijä 12.3.15 3.0 Tarjouspyynnön liitteeksi Hanketoimisto 2/10 SISÄLLYS

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702)

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri (TK081702) yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

Sosiaalialan tiedonhallinta

Sosiaalialan tiedonhallinta Sosiaalialan tiedonhallinta Mitä Tikesos-hankkeen jälkeen? KASTE Itä- ja Keski-Suomen alueellinen johtoryhmä 21.12.2011 Antero Lehmuskoski Itä-Suomen sosiaalialan osaamiskeskus Tieto on hallussa Milloin

Lisätiedot

Ethical Leadership and Management symposium

Ethical Leadership and Management symposium www.laurea.fi Ethical Leadership and Management symposium Hyvinvointipalvelut ekosysteemien tietojen mallintaminen 6.10.2016 Dos. Jorma Jokela 2 3 MORFEUS hanke WORKSHOP työskentelyn taustalla yliopettaja

Lisätiedot

90 ryhmän 1 huomautuksen f alakohdan nojalla. Näin ollen tavara luokitellaan CN-koodiin 8108 90 90 muuksi titaanista valmistetuksi tavaraksi.

90 ryhmän 1 huomautuksen f alakohdan nojalla. Näin ollen tavara luokitellaan CN-koodiin 8108 90 90 muuksi titaanista valmistetuksi tavaraksi. 14.11.2014 L 329/5 (CN-koodi) Kiinteä, lieriön muotoinen, kierteitetty tuote, joka on valmistettu erittäin kovasta värikäsitellystä titaaniseoksesta ja jonka pituus on noin 12 mm. Tuotteessa on varsi,

Lisätiedot

Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka: Voima ja sen komponentit > 80 % % % < 50 %

Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka: Voima ja sen komponentit > 80 % % % < 50 % Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Suomen virtuaaliammattikorkeakoulu Teknillinen mekaniikka: Voima ja sen komponentit > 80 % 80 60 % 60 50 %

Lisätiedot

arvioinnin kohde

arvioinnin kohde KEMIA 8-lk Merkitys, arvot ja asenteet T2 Oppilas asettaa itselleen tavoitteita sekä työskentelee pitkäjänteisesti. Oppilas kuvaamaan omaa osaamistaan. T3 Oppilas ymmärtää alkuaineiden ja niistä muodostuvien

Lisätiedot

Helsingin ammattikorkeakoulu Stadia Verkkosivujen silmäiltävyys ja selailtavuus v. 0.9 > 80 % % % < 50 %

Helsingin ammattikorkeakoulu Stadia Verkkosivujen silmäiltävyys ja selailtavuus v. 0.9 > 80 % % % < 50 % Oppimisaihion arviointi / Arvioinnin tulos 9 Aineiston arvioinnin tulos arviointialueittain Helsingin ammattikorkeakoulu Stadia Verkkosivujen silmäiltävyys ja selailtavuus v. 0.9 > 80 % 80 60 % 60 50 %

Lisätiedot

septima tuotannon uusi elämä

septima tuotannon uusi elämä septima tuotannon uusi elämä 1 2 3 4 5 6 7 Lupaus Septima-palvelutuotteella saamme seitsemässä päivässä aikaan yrityksesi tuotannolle uuden elämän. Uuden tehokkaamman elämän, jossa kustannukset saadaan

Lisätiedot

Kehittyvän ympäristön ja teknologian haasteet

Kehittyvän ympäristön ja teknologian haasteet Kehittyvän ympäristön ja teknologian haasteet Matti Helkamo Siemens Osakeyhtiö, Building Technologies Kiinteistöjen paloturvallisuuden ajankohtaispäivät Restricted Siemens Osakeyhtiö 2016 www.siemens.fi

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä

JHS XXX ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä JHS XXX ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä Liite 1 Nykytilan ja tavoitetilan kuvaus Versio: luonnos Julkaistu: Voimassaoloaika: Sisällys 1 Nykytilan kuvaaminen... 2 1.1 Organisaation

Lisätiedot