Infra-alan tuotetietomalliselvitys (Infra PDM) Infra-alan tuotemalliseminaari 11.10.2006
Mikä on tuotemalli?
Tuotemalli - periaatteet 1/3 Tuotemalli on reaalimaailman käsitteiden kuvaus tietokoneohjelmistoille soveltuvassa muodossa Tuotetietomalli on rakenteen määritys, spesifikaatio, jonka pohjalta voidaan toteuttaa tuotemallia käsitteleviä ohjelmistoja ja niiden välisiä rajapintoja (säännöstö, kuten puhutun kielen kielioppi ja sanasto = syntax & sematics ) Tuotemalli on em. määrityksen mukainen jonkun tietyn kohteen kuvaus (sisältö, kuten vaikkapa puhutun kielen kirja) Tuotemallipohjainen järjestelmä edellyttää toimiakseen määrityksen mukaisten ohjelmistojen ja rajapintojen toteuttamista (implementation)? Infra-alalle keskeinen elementti on myös rekisteritietojen kääntäminen tuotemallimääritysten mukaiseksi
Tuotemalli - periaatteet 2/3 Tuotetietomallin objektit voivat olla: Fyysisiä esineitä, tuotteita, mittoja, alueita, päivämääriä jne; silta, liikennemerkki, vapaa korkeus, vaikutusalue, aikataulu Abstrakteja käsitteitä; prosessi, ympäristövaikutukset, laatu Objektit kuvataan konsepteina: Ominaisuudet (attributes) Suhteet toisiin objekteihin (relationships) Käyttäytyminen (behaviour)
Tuotemalli - periaatteet 3/3 Tuotemallissa sama konsepti voidaan esittää useilla eri tavoilla: 2D ja 3D geometria, topologia, materiaalit, erilaiset tarkkuustasot jne. Kaikki 3D mallit eivät ole tuotemalleja eikä 3D geometria ole tuotemallin ehdoton edellytys - joskin yleensä 3D geometria on osa mallia
Reaalimaailman kohteet (Universe of Discourse) Reaalimaailman käsitteiden kuvaus formaalilla menetelmällä Tuotetietomalli (Product data model) EXPRESS UML Implementointi sovelluksiin ja palvelimille Kuinka kaikki teiden ja ratojen tiedot esitetään Tietyn kohteen (E18, Oikorata,..) tiedot. Esitystavat (Presentations) Sovellukset (Applications) DB Esitysmuodot (Representations) Tuotemalli (Product model)
Tuotemallipohjainen elinkaarenaikainen tiedonhallinta Lähde: Infra2010 ja Apilo / Ramboll LÄHTÖ- TIETOJEN HANKINTA SUUN- NITTELU RAKEN- TAMINEN JA RAKENNETUN TODENTA- MINEN TOIMIVUUS- JA RAKENNE- MITTAUKSET LUOVUTUS- MITTAUKSET LÄHTÖTIETO- MALLI SUUNNITTELU MALLI GEOMETRIA RAKENNE MUUT TIEDOT TOTEUTUS- MALLI RAKENNE MUUT TIEDOT TOTEUMA- MALLI YLLÄPITO- MALLI JÄÄNNÖS- ARVO- MALLI TUOTETIETOMALLI 3D simulointi ja visualisointi työmaaautomaatio ULKOISET TIETOKANNAT
Interaktiivinen ICT - tiedonhallinnan vaiheita - esimerkkejä työkaluista ja soveluksista Lähde: Infra2010 - muokkaus: InfraPDM-projekti Yhdyskuntasuunnittelu - ympäristövaikutusten arviointi Liikennejärjestelmä- / Väyläsuunnittelu - liikennevirtasimulaatiot Xcity Inroads Site CityCAD CityGIS WebMap SpatialWEB Kunto- ja käyttöinformaation jakelu RoadDoctor Käyttötiedon keräys - käyttötiedonhallinta Kuntotutkimussuunnitelma - kuntotiedon hallinta - vaurioanalyysit Hoito- / huoltosuunnitelma - hoitotiedon hallinta emodel GRRI survey Laser scanning Mittaukset - paikkatieto Kunnon seuranta Jäännösarvomalli Ylläpitomalli Lähtötietojen hankinta Lähtötietomalli Hankepankki Suunnittelu- ja rakentamistieto Ylläpidon tietopankki Ylläpitotieto Rekisterit Rata-, Tie-, Suunnittelumalli Toteutusmalli Projektisuunnittelu - kustannuslaskenta - aikataulusuunnittelu Väyläsuunnitelu ja rakennesuunnittelu MsProject HoLA CMpro AutoCAD InRoads Surwey MicroStation Tie- / Rata- / Silta- / Tunnelisuunnittelu Kunnallistekniikka Sähkösuunnittelu Automaatiosuunnittelu InRoads Xstreet Terrasolid Novapoint solutions InRail InRoads Bridge InRoads Storm & Sanitary Xpipe LCA- / LCC -laskenta Rakennesunnittelu Massa- / määrälaskenta EcoProp DynaRoad Tekla Structures Ylläpitosuunnitelma - ylläpitotiedonhallinta Hoito / huolto ja ylläpito Toteutumamalli Rakentamien ja korjausrakentaminen Työsuunnittelu Hankinnat Logistiikka PlaNet Arkistointi - toteumatiedonhallinta Rakennetun todentaminen Työmaa-automaatio Laaduntarkastus - tarkemittaukset Trimble S6, Leica Smart Station BladePro 3D, SiteVision GPS, SreedPro, LMGS-G Dozer 2000 GPS,Systemfive, Mikrograder, Roadsys
Elinkaaritietojen hallinnointi TARPEET TARPEET SUUNNITTELU JA RAKENTAMINEN HOITO JA YLLÄPITO Rekisteriarkisto Tarkistusprosessi REKISTERIT Projektiarkisto Ylläpitoarkisto
Tuotemallin hyötyjä muilla aloilla 1/2 Metsäteollisuus Tuotetietomalli mahdollistaa ohjelmistoriippumattomuuden Samat tiedot käytettävissä kaikilla toimijoilla koko laitoksen elinkaaren ajan Tuotetietomalli mahdollistaa suunnittelun hajauttamisen Tuotemallinnus mahdollistaa automaattisen suunnittelun (rule-based design) Lähde: Pöyry
Tuotemallin hyötyjä muilla aloilla 2/2 Talonrakennus Laatu paranee: mallintaminen vähentää virheitä lopputuotteessa Loppukäyttäjälle tarjotaan jo alkuvaiheessa nähtäväksi todellisuutta vastaava suunnitelma Työmaalla vastaantulevat ongelmat saadaan minimoitua Mallin avulla pystytään sovittamaan yhteen suunnittelutoimistojen suunnitelmat ja minimoimaan rakentamisvaiheen ongelmat Tuotemallinnus mahdollistaa eri vaihtoehtojen vertaamisen visuaalisesti Lähde: Pöyry
Yleisiä hyötyjä Standardoitu rajapinta mahdollistaa tehokkaiden prosessien ja uusien palvelujen kehittämisen Kustannussäästöt, tuottavuuden ja laadun parantaminen, kansainvälisen kilpailukyvyn kasvattaminen Elinkaaren aikainen tiedonhallinta
Tuotetietomallin hyödyntäminen LÄHTÖ- TIETOJEN HANKINTA SUUN- NITTELU RAKENTA- MINEN RAKENNETUN TODENTA- MINEN KÄYTTÖ, HOITO JA YLLÄPITO KUNNON SEURANTA LÄHTÖTIETO- MALLI SUUNNITELMA- MALLI TOTEUTUS- MALLI TOTEUMA- MALLI YLLÄPITO- MALLI JÄÄNNÖS- ARVOMALLI - vaatimusasetanta - kartta-aineisto - maasto- ja maaperätiedot - rekisteritiedot - palvelutasomittaukset - tarkentuva suunnittelu - simulointi (3D, muut) - vaihtoehtovertailu - määrätiedot - kustannustiedot - ympäristövaikutukset - toimivuus - on-line työmaaautomaatio - suunnittelua ohjaavat järjestelmät - automaattinen laadunvarmistus - luovutuskunto -toimenpidekirjasto ja -loki - uudet palvelut - ulkopuoliset järjestelmät
Osapuolikohtaisia hyötyjä 1/2 Omistajat/viranomaiset Toimintamallien selkeytyminen (rekisterit, tietopankit) Hallittu tiedonhallintaympäristö (yhteinen tuotetietomalli ja standardit rajapinnat) Kukin tieto tallennetaan ja sitä ylläpidetään yhdessä paikassa ja se on hyödynnettävissä eri järjestelmissä Mahdollista tukea ohjelmistoilla koko elinkaarta Ohjelmistot eivät vaikuta toteuttajien valintaan Palvelujen loppukäyttäjät Tarjolla ajantasaiset infraverkoston tiedot Mahdollisuus rakentaa tarpeiden mukaisia ja laadultaan parempia tietopalveluita Infraverkoston käyttöturvallisuuden paraneminen
Osapuolikohtaisia hyötyjä 2/2 Urakoitsijat Suunnitelmatietojen laadun paraneminen; vähemmän virheitä, nopeampi ja tarkempi kustannusten arviointi ja hallinta Tehokkaampi aikataulujen ja logistiikan hallinta Kehittyvän koneautomaation tehokas hyödyntäminen Konsultit Tiedonsiirto vaatii vähemmän manuaalista työtä ja pienentää virhemahdollisuuksia Mahdollisuudet kehittää uusia palvelukonsepteja Sovellukset voivat hyödyntää yhteen paikkaan tallennettua tietoa Käytettävät ohjelmistot valittavassa vapaasti Ohjelmistotoimittajat Vähemmän tuettavia tiedonsiirtotapoja Kansainvälisten markkinoiden avautuminen (kansainvälinen tietomalli, yhteiset standardit)
Miksi tuotemalli on tärkeä ja mitä hyötyjä siitä on?
Lähtökohta ja tavoite A - Tuotemalli ja tiedonsiirto: Keinot tavoitteiden saavuttamiseksi Roadmap: Kiviniemi 2006 Suunnittelu- ja rakentamisprosessi Hankintaprosessi Ylläpitoprosessi Koneautomaatio ja numeerinen ohjaus Laatutiedon automaattinen keruu ja jalostaminen Tietojen ja prosessien hallinta Reaaliaikainen raportointi Sensoriteknologia ja raportoivat rakenteet Koko elinkaaren aikainen tiedonhallinta Tehokas ja automatisoitu prosessi Mobiili tiedonsiirto C.1 Toimivuusvaatimusmenettelyn kehittäminen Tiedonsiirtoformaatit ja siirrettävän sisällön määritys Virtuaalimallinnus ja laadun todentaminen (simulointi) Rekisterien ja ulkoisten tietokantojen konvertointi Tuotetietomalli ja integrointi Tuotekirjastojen mallirakenteet Sähköinen kaupankäynti Tuotehyväksyntä B.3 Suunnitteluprosessin ohjeistaminen C.3 Rakenteiden kunnon todentaminen B.6 Kokonaistaloudellisuuden arviointimenetelmät Osapuolten välinen tiedonsiirto Yhteinen näkemys keskeisistä prosesseista Yhteinen näkemys mallin tietosisällöstä ja -rakenteista Prioriteetti 1 2 3
Kustannussäästöt? Kustannussäästöt todennäköisempiä mikäli väylävirastot tekevät yhteistyötä Norjassa ei ole tehty yhteistyötä väylävirastojen välillä Kokemuksia Norjassa vasta hyvin lyhyeltä ajalta 5% säästöarviot perustuvat odotuksiin, näyttöä ei ole BaneData? Informaation laatu parantunut? Ei rahallisia säästöjä ainakaan tässä vaiheessa Vianova Norway, Oslo 29.11.05, ylioptimistiset arviot:? Säästöt suunnittelussa 3 M? Säästöt ylläpidossa 50 M? Säästöt rakentamisessa 50 M? Säästöt onnettomuuksien vähenemisessä 31 M? Säästöt tieverkon käytön tehostumisessa 16 M? Muut säästöt 5 M? Vuosittaiset säästöt yhteensä 155 M Kannattavaa, vaikka virhe olisi 90%? 15 M säästöt 50-70 M :n investoinnilla
Tuotemallistandardin kehittämisen keskeisiä riskejä
Teknisiä riskejä Järjestelmä ei mahdollista tervettä kilpailua vaan suosii kohtuuttomasti jotakin tai joitakin toimijoita Järjestelmä ei perustu avoimeen standardiin Järjestelmän ydin on jonkun osapuolen hallinnassa Rajapintamääritykset eivät ole julkisesti saatavissa tai täysin dokumentoituja; järjestelmän ytimessä antaa haltijalleen mahdollisuuksia tehdä sovelluksiin ominaisuuksia, joita muut eivät voi toteuttaa Järjestelmä ei ole dynaamisesti päivitettävissä tai sen päivitysprosessissa on puutteita ISO TC211 standardit saattavat tarvita päivitystä, kun elinkaaren kattavuutta laajennetaan (suunnittelutiedot) Järjestelmä ei täytä suomalaisia tarpeita Norjalainen toteutus ja suomalaisen infrasektorin prioriteetit eivät kaikin osin kohtaa
Tiehankkeet: prioriteetit Suomessa ja implementoinnin tilanne Norjassa LÄHTÖ- TIETOJEN HANKINTA SUUN- NITTELU RAKENTA- MINEN RAKENNETUN TODENTA- MINEN KÄYTTÖ, HOITO JA YLLÄPITO KUNNON SEURANTA LÄHTÖ- TIETOJEN HANKINTA SUUN- NITTELU RAKENTA- MINEN RAKENNETUN TODENTA- MINEN KÄYTTÖ, HOITO JA YLLÄPITO KUNNON SEURANTA
Ratahankkeet: prioriteetit Suomessa ja implementoinnin tilanne Norjassa LÄHTÖ- TIETOJEN HANKINTA SUUN- NITTELU RAKENTA- MINEN RAKENNETUN TODENTA- MINEN KÄYTTÖ, HOITO JA YLLÄPITO KUNNON SEURANTA LÄHTÖ- TIETOJEN HANKINTA SUUN- NITTELU RAKENTA- MINEN RAKENNETUN TODENTA- MINEN KÄYTTÖ, HOITO JA YLLÄPITO KUNNON SEURANTA
Taloudellisia ja organisatorisia riskejä Järjestelmän toteutuksen aikataulu- ja kustannusarviot osoittautuvat liian optimistisiksi Kehittäminen on lähes poikkeuksetta hitaampaa ja kalliimpaa kuin alussa odotetaan Investoinnille ei saada kohtuullista katetta Järjestelmän tukipalvelujen saatavuus Kustannukset, riittävät resurssit, laatu Puutteellinen yhteistyö kehittämisessä ja käyttöönotossa Yhteensopivia ohjelmistoja ei synny tai infra-ala ei ota niitä käyttöön riittävän nopeassa tahdissa Puutteellinen koulutus Käyttöönotto edellyttää osaavaa verkostoa. Koulutus ei ehkä pysty tuottamaan osaavia käyttäjiä riittävän nopeasti Puutteellinen tai väärän tyyppinen viestintä Alan toimijat jarruttavat toimintatavan muutosta
NRDB aikataulu ja saavutettavat hyödyt Suunnitelma Määritys Asennus FAT SAT Viive 34 kk FAT = Factory Acceptance Test SAT = Site Acceptance Test 2001 2002 2003 2004 2005 2006 Toteutuma Määritys Asennus FAT SAT Tuotantokäyttö Investointi NPRA: 15 M Konvertointi? Tuotantotäytössä n.3 vuotta myöhässä (18.4.2006 alkaen) Hyödyt Arvio: säästö 5% 155 M /vuosi Hyödyntäjiä myös sidosryhmät ja palveluiden loppukäyttäjät Ei käytännön kokemuksia
BaneData aikataulu ja saavutettavat hyödyt 2000 2001 2002 2003 2004 2005 Analysointi Järj. suunnittelu Yksityiskohtainen suunnittelu 2006 Rekisteritiedot Investointi Kenttä workshopit Suunniteltu käyttöönotto NRA: 5 M (ylläpito-osuuden kehitys noin 15 M ) Toteutuman viive 2 vuotta, konvertoinnin lisäviive noin 2 vuotta = 4 vuotta Järjestelmän implementointi Tiedon Käyttöönotto Viive 2 vuotta konvertointi Ylläpitotietojen kehityshanke Hyödyt Arvio: Ei säästöjä, keskitetty järjestelmä, parempi laatu ja turvallisuus Hyödyntäjiä tulevaisuudessa myös liikennöitsijät ja sidosryhmät Suuret hyötyodotukset ylläpidosta
Quadrin avoimuus ja käyttöoikeudet
Avoin standardi, EU egovernment määrittely Soveltamisesta ja ylläpidosta vastuussa voittoa tavoittelematon taho, päätöksentekoprosessiin mahdollista osallistua. Standardin on julkaistu, sen määrittelyn (specification) kopiointi, levittäminen ja käyttö ovat tarjolla ilmaiseksi tai kulukorvausta vastaan. Standardiin perustuvan aineettoman omaisuuden (IPR) hyödyntäminen on sallittua ilman tekijänoikeuspalkkioita. Standardin uudelleenkäyttöä ei ole rajoitettu.
Standardointi ja Quadri Perustana ISO 19100-sarja (ISO TC 211) Kansainvälinen, avoin standardi paikkatiedoille (GIS) Ei kata väyliin liittyviä detaljitason tietoja erillinen ominaisuusmäärittelyt (Feature Catalogues) ovat välttämättömiä Implementointi edellyttää tarkempia soveltamismalleja (Application Schemas) Tuotetietomallin sisältö Ominaisuusmäärittelyt ja soveltamismallit ovat puhtaasti norjalaisia sovelluksia, osin avoimia, mutta eivät kuitenkaan standardin tasolla. Niiden käyttöön ja kehittämiseen liittyy ehtoja
Standardointi ja Quadri Toteutus (Quadri Server, Client API) Kaupallisia tuotteita, ei avoimia; nykyisten omistajien välillä keskinäiset sopimukset käyttöehdoista? Ohjelmistojen kilpailu ei ole tasapuolista, jos kaikkien on pakko hankkia Client-API järjestelmän toteuttajalta. Mahdollisuus palvelimen, järjestelmän ytimen, kilpailuttamiseen on välttämätöntä, mutta onko se mahdollista?? Ehdottomasti neuvoteltava ennen lopullisia päätöksiä Quadri palvelimen version vaihto vaatii manuaalista työtä tietokannan konvertoinnissa? Ylläpitoon ja päivittämiseen liittyvä lisäkustannus? Mahdollisuus järjestelmätoimittajan vaihtoon on huomioitava myös myöhemmissä vaiheissa
NRDB Client-API overview Klient Kuka omistaa ja ylläpitää spesifikaation ja ohjelmistot? Ohjelmistojen kilpailu ei ole tasapuolista, jos kaikkien on pakko hankkia Client-API järjestelmän toteuttajalta. NVDB Klient API NVDB Datakilde Utvalgsdialog Datamodul Kommunikasjonsmodul COM grensesnitt Metoder Klientprogram Intranett/ Internett HTTP protokoll NVDB Servere NVDB (ORACLE) NVDB-tjener Firewall/ sikkerhetsmur Databasetjener
Reaalimaailman kohteet (Universe of Discourse) Reaalimaailman käsitteiden kuvaus formaalilla menetelmällä Tuotetietomalli (Product data model) EXPRESS UML Implementointi sovelluksiin ja palvelimille Kuinka kaikki teiden ja ratojen tiedot esitetään Tietyn kohteen (E18, Oikorata,..) tiedot. Esitystavat (Presentations) Sovellukset (Applications) DB Esitysmuodot (Representations) Tuotemalli (Product model)
Tuotemalli IFC benchmark IFC Tiedonsiirtostandardi talonrakennusalalle Lähtökohtana avoin, globaali standardi 13 Chapteria, 20+ valtiota, 500+ yritystä Osallistuminen kehittämiseen ja käyttö avoinna kaikille Implementointi mahdollista kaikilla tasoilla Kattaa vain spesifikaation, ei toteutusta Ongelmana implementoinnin suppeus ja laatu Ohjelmistovalmistajille kysyntä on kriittinen tekijä Quadri Tiedonsiirtostandardi ja tietojärjestelmä Norjan infra-alalle Lähtökohtana järjestelmälle selkeä omistajuus Norjan tie- ja ratahallinto sekä Vianova Käyttö ja edelleen kehittäminen edellyttää sopimusta omistajien kanssa Palvelinjärjestelmän implementointi avoin kysymys Järjestelmään kuuluu oleellisena osana myös implementointi Ulkoinen implementointi ei ole järjestelmän käytölle elinehto, vaan sen laajennus
Tuotemalli IFC benchmark IFC Pääasiallinen sovellusalue suunnittelu- ja rakentaminen Käyttöönotto projektikohtaista, ei edellytä laajan tietokannan luomista Toimiala on fragmentoitunut Käyttöönotto edellyttää jonkun siitä hyötyvän tahon aktiivisuutta ja riskinottoa Suomessa vetureina rakennusyritykset ja Senaatti, USA:ssa GSA, Norjassa ja Singaporessa julkishallinto Quadri Pääasiallinen sovellusalue ylläpito Suunnittelun linkki kehitteillä Käyttöönotto edellyttää laajan tietokannan luomista = nykyisten rekisterien konversio merkittävä investointi ennen hyötyjä Omistaminen keskittynyttä Päätös käyttöönotosta voidaan tehdä keskitetysti
Tuotemalli IFC benchmark IFC Spesifikaation luominen ja käyttöönotto on ollut merkittävästi ennakoitua hitaampaa Kehitystyön rahoitus on ollut jatkuva ongelma Toistaiseksi vain vähän käytännön kokemuksia Todellisten hyötyjen mittaaminen vielä vaikeata, mutta kokemukset pääosin positiivisia niiltä osin kuin järjestelmää on käytetty Quadri Huolimatta selkeästä projektoinnista ja mittavasta rahoituksesta kehittäminen ja käytöönotto on ollut merkittävästi suunniteltua hitaampaa Toistaiseksi vain vähän käytännön kokemuksia Todellisten hyötyjen mittaaminen vielä vaikeata, mutta kokemukset pääosin positiivisia niiltä osin kuin järjestelmää on käytetty
Tuotemalliin siirtymisen edellytykset Suomessa
Tuotemallikokemuksia muilta aloilta 1/3 Tuotemallin tulee perustua kansainväliseen, laajasti käytettyyn standardiin, jolloin varmistutaan, että sitä kehitettään ja tuetaan myös tulevaisuudessa Mallin tulee olla avoin kaikille osapuolille, jotta malliin perustuvia tai sen päälle rakennettavia sovelluksia voidaan kehittää Tuotemallin tulee mahdollistaa eritasoisen tiedon käsittely Esimerkiksi 3D-malliin tulee voida liittää olemassa olevia piirustuksia, valokuvia yms. (hybridimalli)
Tuotemallikokemuksia muilta aloilta 2/3 Mallintamiseen siirtyminen ei tapahdu hetkessä Olemassa olevien tietojen siirto tuotetietomalliin kestää metsäteollisuudessa vuosia ja on talonrakennusteollisuudessakin työlästä Vanhoja rakenteita ei kannata lähteä erikseen mallintamaan vaan niiden tiedot voidaan kerätä korjausten (korjaussuunnitelmat) yhteydessä Infra-alalla on merkittävästi konvertoitavia rekisterejä, mutta osa tiedoista on hoidettava em. tavalla Tuotetietomalliin siirtyminen nostaa aluksi kustannuksia Teknologia- ja ohjelmistoinvestoinnit, kouluttaminen Ei pikavoittoja, hyödyt tulevat pitkällä aikavälillä Lähde: Pöyry
Tuotemallikokemuksia muilta aloilta 3/3 Uusien toimintamallien sisäistämien ja käyttöönotto vie aika aja vaatii kouluttamista ja joskus myös asennemuutosta Ihmiset ovat monesti tuotemallin käyttöönottoa rajaava tekijä Tilaajaosapuolen rooli tuotemallin käyttöönotossa on ratkaiseva Vaatimukset tuotemallin käytöstä, käytettävän standardin määrittäminen, jne. Lähde: Pöyry
Johtopäätöksiä 1/3 Tuotemalliteknologia on selvitystyöryhmän mielestä joka tapauksessa suositeltava etenemistie Infra-tiedon merkittävin perusstandardi on ISO 19100-sarja (ISO TC211, GIS) Paikallinen soveltaminen on tarpeellista, joten tarvitaan avoin suomalainen standardi, joka: perustuu kansainvälisiin standardeihin ja harmonisoituu mahdollisuuksien mukaan muiden kansallisten standardien kanssa mahdollistaa kaikki tarvittavat sovellusalueet (tie, rata,...) ja elinkaaren vaiheet sekä niiden välisen tiedonsiirron
Johtopäätöksiä 2/3 Norjalainen järjestelmä ei sellaisenaan sovellu Suomeen, mutta vaikuttaa yhdeltä lupaavalta mahdollisuudelta edellyttäen, että: käytön ja ylläpidon ehdot neuvotellaan ja sovitaan ennen lopullista päätöstä kaikki määritykset saadaan avoimesti käytettäviksi määritysten kehittäminen ja ylläpito sekä järjestelmän ytimen hallinta erotetaan toisistaan määritysten kehittämiseen voidaan muodostaa laaja konsortio, jota ohjaa puolueeton taho myös järjestelmän ytimen, palvelimen, tekninen toteutus voidaan kilpailuttaa vapaasti
Johtopäätöksiä 3/3 Alan kilpailun turvaaminen Yhteinen toimintaympäristö, kilpailu osaamisen sekä palvelujen ja tuotteiden laadulla Tietosisältöjen tulee olla siirrettävissä ohjelmistoista ja versioista toisiin Ohjelmistot, mukaan lukien järjestelmäpalvelin, ovat kaupallisia, lisensioitavia tuotteita Tuotetietomallin määritys ja kaikki rajapinnat, myös järjestelmäpalvelimen osalta, ovat avoimia ja niiden dokumentaatio on kaikkien vapaasti saatavissa Vaihtoehdot? Ruotsista löytyy avoin ja virallinen standardi, joka mahdollisesti soveltuisi suomalaisen spesifikaation pohjaksi, joskaan sen implementoinnista ei ole tietoja
Karkea arvio kokonaiskustannuksista
Norjan väylävirastojen investoinnit BaneData Rekisterien toteutettu osuus 5 M Laajentaminen ylläpitoon (käynnissä) 15 M Yhteensä 20 M Vuosittainen ylläpito nykyisin 0.1 M, ei sisällä muutoksia eikä päivityksiä NRDB Nyt toteutettu osuus 15 M Osa konversiokustannuksista puuttuu 10 M? Laajentaminen suunnitteluun (käynnissä) 25 M? Yhteensä 50 M Yhteensä vähintään 70 M
Arvioidut investoinnit ja aikataulu Tie- ja ratarekisterit Määritysten kehittäminen ja soveltaminen sekä palvelinjärjestelmän hankinta 15 M ±5 Tie ja ratarekisterien konvertointi 30 M ±10 Yhteensä 45 M ±15 Aikataulu Etenemistavasta päättäminen 6-12 kk Määritysten kehittäminen ja soveltaminen sekä palvelinjärjestelmän hankinta 18-30 kk Tie ja ratarekisterien konvertointi & testaus 12-18 kk Yhteensä 3-5 vuotta
Nollavaihtoehto: Jatketaan nykyisellä toimintatavalla? Toimintaympäristön muutokset edellyttävät joka tapauksessa järjestelmien kehittämistä Kehittyvä koneautomaatio edellyttää tiedonsiirron rajapintojen kehittämistä Hajanaisessa ohjelmisto- ja tietoympäristössä rajapintojen kehittäminen on hankalaa ja kallista Nykyisen fragmentoituneen tietoteknisen toimintaympäristön kehittäminen entiseen tapaan merkitsee lisäkustannuksia ilman mahdollisuutta toimintojen merkittävään tehostumiseen tai uusien palvelujen kehittämiseen
Ehdotus jatkotoimenpiteiksi
Avointen ja kaupallisten osuuksien suhteet Avoin Suomalainen infra-ala Kaupallinen Spesifikaatio määrittelee tuotetietomallin rakenteen, jonka pohjalta voidaan toteuttaa tuotemallia käsitteleviä ohjelmistoja ja niiden välisiä rajapintoja; säännöstö, kuten puhutun kielen kielioppi ja sanasto (syntax & sematics) Tarpeet Järjestelmätoimittaja(t) Spesifi Spesifi -kaatio -kaatio Avoin suomalainen konsortio Kansainväliset standardit ISO, OGC, OMG Kv. standardeja määrittelevät tahot Tietovarasto Rajapintakehittäjät Palvelinrajapinta Sovellusrajapinnat Järjestelmäpalvelin Sovellusohjelmat Sovelluskehittäjät Virastot, konsultit, jne. Sisältö
InfraPDM ja ylläpidon järjestäminen Alan toimijat mm. julkiset organisaatiot ja palvelujen tarjoajat InfraPDM-TOIMIKUNTA SOVELLUSja ICT- JÄRJESTELMÄ- KEHITTÄJÄT KÄYTTÖRAJAPINTA TARVE EHDOTUS kansaínvälinen HARMONI- SOINTI HYVÄK- SYNTÄ SOVELLUSRAJAPINTA PALVELINRAJAPINTA SPESIFIKAATION MÄÄRITYS JÄRJESTELMÄ- TOIMITTAJA(T) TEKNINEN TOTEUTUS JÄRJESTELMÄ- PALVELIN SPESIFIKAATION YLLÄPITO avoin ympäristö - läpinäkyvä spesifikaation päivitysprosessi sovellusten kehittäjien ja järjestelmän kehittäjän suuntaan JÄRJESTELMÄN YLLÄPITO kaupallista toimintaa - palvelimen ylläpito - tekniset päivitykset
Edellytyksiä onnistumiselle Laaja osallistuminen määritystyöhön Kaikki julkiset infra-alan toimijat:? Tiehallinto? Ratahallintokeskus? Maanmittauslaitos? Joitakin merkittävien kuntien edustajia Kaikkien merkittävien ohjelmistotoimittajien edustajat Urakoitsijoiden ja suunnittelijoiden edustajia Infra-alan palvelutoimittajien edustajia Sitoutuminen Kaikki alan keskeiset toimijat sitoutuvat tuotemallien käyttöön? Tuotemallien vaatiminen osana projekteja? Kaikkien kehitysprojektien liittyminen järjestelmään
Etenemispolku, vaihe 1 2006 4-6 kk 6-12 kk Päätökset etenemistavasta: Jatketaanko keskustelua norjalaisten kanssa Suomalaisen konsortion muodostaminen Kyllä Kyllä Ei Neuvottelut norjalaisten kanssa Muiden ohjelmistotalojen testit Sopimuksellisesti tyydyttävä lopputulos Teknisesti tyydyttävä lopputulos (4-6 kk) Muut tuotemallipilotit (koneautomaatio, suunnittelu, urakointi, ylläpito, jne.) Ei Ei Kyllä Kyllä Norjalais-suomalaiseen yhteistyöhön pohjautuva ratkaisu Muiden vaihtoehtojen hakeminen Järjestelmän 1. toteutusvaiheen prioriteetit ja sisältö Joku muu vaihtoehto Suomalainen infra-alan tuotetietomallispesifikaatio #1 Pilottien tuottamat sisältötarpeet 2008 2009 Vaihe 2
Rinnakkaisten kehitysprojektien ja spesifikaation määrityksen vuorovaikutus Tietojärjestelmien kehityspilotit: demoajot ja testaukset, uudet tekniikat Rajapintatarkastelut, Client API Dokumentoimattoman tiedon keräystekniikat Rekistereiden konvertointivalmius ICTpalvelujen kehitys Sisältövaatimuksia suomalaisen infra-alan tuotetietomallispesifikaation versiolle 1 Omien prosessien, työkalujen ja toimintavalmiuksien kasvu Tiedonsiirron tarpeet ja vaiheet Koneautomaation kehityspilotit Suunnittelun ja rakentamisen kehityspilotit Huollon ja ylläpidon tuottaman tiedon jäsennys Järjestelmien uudistustarpeet Uudet prosessipalvelut Prosessien kehityspilotit: Tuotemallipilotit elinkaaritiedonhallinnan ja prosessien tehokkuuden kannalta (mm. Prosessien ja työkalujen toimivuus, osa- ja kokonaisprosessien kehitys ja oppiminen)
Etenemispolku, vaihe 2 12-18 kk 8-12 kk 4-6 kk 2008 2009 2010 2012 Vaihe 1 Palvelinjärjestelmän kilpailuttaminen ja toteutus Yhteensopivien kaupallisten tuotteiden kehittäminen Keskeisten rekisterien konvertointi ja testaus Järjestelmän toimivuuden testaus Järjestelmä käytössä