Tuotteen elinkaaren hallinta verkostotaloudessa haasteita ja ratkaisumalleja Kary Främling

Transkriptio

1 Tuotteen elinkaaren hallinta verkostotaloudessa haasteita ja ratkaisumalleja TKK/BIT Tutkimuslaitos

2 Esityksen aiheet Tuotteen elinkaari Tuotteen ja tiedon yhteen kytkeminen Tuoteagentti Esimerkkejä: lähetysten seuranta, tuotetiedon haku Tuotetiedon hallinta yritysverkostossa, suunnittelumallit Käytännön toteutus, kokemukset Tulevaisuuden kehityssuuntia Yhteenveto 2

3 Tuotteen elinkaari Luokitellaan usein seuraaviin vaiheisiin: Suunnittelu Tuotanto Käyttö ja ylläpito Käytöstä poistaminen Jokaisessa tarvitaan muiden vaiheiden tuottamaa tietoa Suuri määrä toimijoita käyttää ja tuottaa tietoa tuotteen elinkaaren aikana Tuotetiedon jakaminen kaikkien toimijoiden kesken on yleensä mahdotonta 3

4 Tuotteen ja tiedon yhteen kytkeminen Internet of Things : tuotetiedot saatavissa kaikkialla Internetin kautta Suuri tuki teollisuudesta MIT:n Auto-ID hankeelle RFID (Radio Frequency Identification) etätunnisteet oleellisessa roolissa Esitettyjä standardeja Electronic Product Code (EPC), sisältäen signaalitason RFIDstandardeja Object Name Service (ONS), Product Markup Language (PML), Savant middleware Tällä hetkellä ainoastaan EPC näyttää saavan laajamittaista tukea 4

5 Teknillisen korkeakoulun lähestymistapa Dialog projekti vuonna 2001 Tuote kytketään tietoihin URI: Internet-osoite mistä tuotetiedot löytyvät (esimerkiksi tuotteen valmistaja) ID: tuotteen yksilöivä numero (sarjanumero, SSCC, EPC tai vastaava) Mahdollista ottaa käyttöön heti ja kerätä käytännön kokemuksia standardointia varten 5

6 avulla tuotetietoa voi hakea ja päivittää Esimerkiksi Otetaan yhteyttä palvelimeen dialog.hut.fi ja haetaan/päivitetään tuotteen/lähetyksen SN tietoja Käyttää olemassaolevia standardeja, nopea ja kevyt ottaa käyttöön Mahdollista kiinnittää tuotteeseen tekstinä, viivakoodina, RFIDtaginä (jossa kirjoitettavaa muistia),... myös mahdollinen on yhteensopiva tulevien Auto-ID järjestelmien kanssa 6

7 Tuoteagentti Internet-kytketty ohjelmakomponentti joka hallinnoi tuotteen tietoja ja palveluita Tuoteagentti vastaa olio-ohjelmoinnin oliota vastaa olio-ohjelmoinnin olioviitettä Yhtymäkohdat olio-ohjelmointiin tarjoavat valmiita ratkaisumalleja tuotetiedon hallintaan 7

8 Olio-ohjelmointi Tuoteagentti OO konsepti Olio Olioviite Metodi Rajapinta Oliokokoelma Tuoteagenttikonsepti Internetin kautta käytettävä ohjelmakomponentti EPC tai vastaava Viesti Rajapinta joka määrittelee mahdolliset viestit ja viestimuodot Tietokantataulu joka sisältää olioviitteitä (esim. 8

9 Tuoteagenttisovellus 1: Huolitsijariippumaton lähetysten seuranta Valmistaja Huolitsija A Huolitsija B Huolitsija C Asetetaan ID@URI Päämäärä ID@URI ID@URI ID@URI ID@URI Valmistajan lähetysten seurantajärjestelmä annetussa URI-osoitteessa ( Tuoteagentti ) Sijaintipäivitysviestejä Välttää huolitsijoiden seurantanumeroiden käyttämistä Sijaintitiedot reaaliajassa, ei haeta huolitsijoiden WWWsivuilta 9

10 Tuoteagenttisovellus 2: Electrical motor, manufactured by XXX, previous maintenance... Tuotetiedon haku Fetch information (text or WWW-page) URI_1 Fetch information (text or WWW-page) URI_2 Pizza containing..., last date of use..., heat one minute at 600W Fetch information (text or WWW-page) Bus stop XXX, next bus to your destination arrives in three minutes URI_3 10

11 Tuotetiedon hallinta yritysverkostossa Usean yrityksen verkostoissa vaaditaan kehittyneempiä tiedonhallinnan malleja Esimerkiksi lähetysten seurantatiedon hallittu jakaminen on selkeästi ilmaistu tarve teollisuudessa Olio-ohjelmointi tarjoaa valmiita työkaluja tähän 11

12 Suunnittelumallit eli Design Pattern Suunnittelumallit määrittelevät oliopohjaisia vakioratkaisuja useisiin tiedonhallinnan tehtäviin Kokeneiden ohjelmoijien määrittelemiä Käytännön kokemuksia useammalta sovellusalueelta 12

13 Composite suunnittelumalli Malli part-whole hierarkioiden tiedon hallintaan Samoja toimintoja voidaan soveltaa perus-elementteihin sekä niiden ryhmiin Hyödyllinen esimerkiksi useamman valmistajan tuotteissa ja kuljetusyksiköissä Suunnittelumalli määrittelee get, add, remove etc. operaatioita Made by company A Car Made by company B Engine Made by company C ABS system Made by company D Injection system 13

14 Tiedon päivitys composite tuotteelle , 262, 263 comp1.com Tiedon päivitysviesti comp4.com comp3.com comp2.com 264, 261,

15 Composite yhteenveto Eri yhtiöiden tuoteagentit välittävät tiedon päivityksen toisilleen Sama toimii tiedon hakemisessa Jokainen yritys voi itse valita mitä viestejä se vastaanottaa ja lähettää eteenpäin 15

16 Observer suunnittelumalli Defines one-to-many dependencies between objects so that when one object changes state, all its dependents are notified and updated automatically Agentti ilmoittaa toiselle agentille että haluaa saada tietyt päivitysviestit myös itselleen Tarve esitetty useaan kertaan yritystaholta Toteutus saman tyyppinen kuin Composite Tarvitaan esimerkiksi lähetysten seurannassa yrityksessä jonka osia ei ole mukana lähetyksessä (esimerkiksi kun lähetyksen vastaanottaja haluaa seurata lähetyksen sijaintia) 16

17 Tiedon päivitys Observer - mallilla Eri yhtiöiden tuoteagentit välittävät tiedon päivityksen toisilleen comp2.com comp5.com Tiedon päivitysviesti comp1.com comp3.com comp4.com comp6.com 17

18 Käytännön toteutus Middleware, toteutus Java komponentteina Osaavat hakea/päivittää tietoa yritysten tietokannoista/tietokantoihin Osaa automaattisesti luoda tarvittavat tietokantataulut Asennustiedostot kymmenien kilotavujen kokoisia, asennus tyypillisesti alle viisi minuuttia Riippumaton käytetystä tunnisteteknologiasta (RFID, viivakoodi, j.n.e.) Avoimen lähdekoodin yhteisö avattu osoitteessa 18

19 Pilottiasennukset Kvaerner Pulping, keväällä 2002 Projektilähetysten seurantaan, todennettiin konseptin toiminta tunnisteena, mutta URI oli vakio RFID-tunnisteet Projektoiva elektroniikkateollisuuden yritys, syksy 2003-> Sisääntulevan ja ulosmenevän tavaran seuranta kolmannen osapuolen välivarastoissa Viivakooditunnisteet Johtopäätös: DIALOG-konsepti ja komponentit toimivat moni-yritys ympäristössä 19

20 Käytännön kokemuksia Viestien välitys mahdollista SOAP, HTML forms, Java RMI muodoissa Palomuuriongelmat kasvamassa SOAP periaatteessa OK, käytännössä ongelmia HTML form toimii kaikkien palomuurien kanssa (ainakin tähän asti) Java RMI ainoastaan palomuurien sisällä 20

21 Tulevaisuuden kehityssuuntia TKK mukana syksyllä 2004 alkavassa PROMISE kuudennen EU puiteohjelman integroidussa projektissa Suuri määrä yrityksiä Uusien vaatimusten kartoitus erilaisille palveluille Mahdollinen DIALOG-konseptin evaluointi suuremmassa mittakaavassa Käytännön kokemuksia Composite - ja Observer - mallien soveltamisesta Muiden vastaavien suunnittelumallien identifiointi tuotetiedon hallintaan Standardisointi 21

22 Yhteenveto Tuoteagentti-konsepti tarjoaa monia etuja tuotteen elinkaaren hallintaan Olio-ohjelmointi tarjoaa valmiita ratkaisuja moniin tiedonhallinnan haasteisiin Middleware -tasolla on mahdollista hallita monia tiedonhallinnan tehtäviä; vältetään ERPjärjestelmien muokkausta Testatut ja toimivaksi todetut toimintaperiaatteet Suurin haaste: viestien ja viestintäprotokollien standardointi 22

23 MIT Auto-ID EPCglobal hallinnoi standardointityötä syksystä 2003 lähtien RFID-tagien standardit valmiita, mutta useita eri järjestelmiä vielä olemassa EPC (Electronic Product Code) koodijärjestelmän standardointi suhteellisen valmis ONS (Object Name Service) järjestelmän standardointi vielä alkutekijöissään Savant järjestelmän (middleware-arkkitehtuuri) määritys alkutekijöissään Kehitystä seurataan, hyvät asiat integroidaan tarvittaessa 23

24 Middleware komponentit Osaavat vastata tiedon hakuun/päivityksiin viestien avulla Tällä hetkellä komponentit tukevat kolmea eri tiedonsiirtoprotokollaa: HTML-form: ei palomuuri-ongelmia, rajalliset toiminnallisuudet SOAP: palomuuri-ongelmia esiintynyt (vaikka ei pitäisi) RMI: lähinnä pilotointiin, yritysten sisäiseen käyttöön Komponentit osaavat hakea/päivittää tietoa yritysten tietokannoista/tietokantoihin Komponentit muutamien kymmenien kilotavujen kokoisia, asennus tyypillisesti alle viisi minuuttia 24

25 Käytännön kokemuksia Tiedonsiirtoprotokollat: SOAP: Web-service protokolla, monipuolinen. Käytännössä esiintynyt palomuuriongelmia, mikä oli yllätys. HTML-form & JavaScript: Vanha tekniikka, mutta toimiva. Saattaa joskus vaatia niksien käyttöä. Ei palomuuriongelmia. Ei erillistä klientin asennusta. Ei tue viestien bufferointia eikä lukijoiden ajureita. RMI: Monipuolisin. Palomuurit suuri ongelma. Lähinnä kehitys- ja testausprotokolla sekä yritysten sisäiseen käyttöön. Tunnistetekniikka: RFID: toimii, mutta järjestelmien moninaisuus (taajuus, kommunikointi, lukijoiden erilaisuus) suuri ongelma. Hinta on myös kynnyskysymys Viivakoodi: Halpa, helppo ottaa käyttöön. Vaatii kuitenkin operaattorin ja optisen näkyvyyden. 25