OPC:n uudet tuulet. Mikä ihmeen OPC

Transkriptio

1 OPC:n uudet tuulet Mikä ihmeen OPC Oletan että suurin osa automaatioalan ihmisistä ja tämänkin lehden lukijoista on jossain vaiheessa kuullut kirjainyhdistelmän OPC. Seuraavassa ensin taustatietoa OPC:stä niille joille kirjainyhdistelmä merkitys ei ole niin tuttu. Puhuttaessa OPC:stä yleensä viitataan OPC-foundationin laatimaan OPC Data Access spesifikaation mukaiseen tiedonsiirtotapaan. OPC-foundation on voittoa tavoittelematon organisaatio, jonka jäseninä on yli 300 automaatioalan yritystä ympäri maailmaa sisältäen kaikki merkittävät automaatiojärjestelmien ja automaatioinstrumenttien valmistajat. Järjestön tavoitteena on laatia avoimia määrittelyjä automaatiosovellusten integrointiin ja prosessidatan siirtoon. Nykyiset OPC-määrittelyt ovatkin saavuttaneet de-facto aseman tiedonsiirrossa automaatiosovellusten välillä. Lyhenne OPC tulee alun alkaen sanoista OLE for Process Control. OLE eli Object Linking and Embedding puolestaan on Microsoftin COM tiedonsiirto ja ohjelmistokomponentti tekniikoiden vanha nimi. Alunalkaen vuonna 1995 OPC:n tarkoituksena oli kehittää Microsoftin komponenttitekniikkaa hyödyntävä tiedonsiirtostandardi automaatioalueelle. Vuonna 1996 OPC määrittelyn versio 1.0 julkaistiinkin. Tästä on tultu pitkän matkaa ja määrittelyjä on tullut lisää. Tunnetuimmat OPC määrittelyt ovat DA (Data Access), A&E (Alarms and Events) ja HDA (Historical Data Access). Näistä DA on tarkoitettu tosiaikaisen prosessidatan siirtoon prosessilaitteista ja ohjausjärjestelmistä. A&E on tarkoitettu hälytys ja tapahtumatietojen välittämiseen ja HDA puolestaan on tarkoitettu historiatietojen siirtoon. Edellä mainittujen spesifikaatioiden lisäksi OPC on määritellyt myös joukon muita rajapintoja ja määrittelyjä: - OPC Batch - OPC Data exchange - OPC Security - OPC XML-DA - OPC Complex Data - OPC Commands Näistä DX (Data exchange) on tarkoitettu horisontaaliseen tiedonsiirtoon OPCpalvelinten välillä. XML-DA on nimensä mukaisesti tarkoitettu samaan kuin DA standardi mutta käyttäen XML:ää ja WebServices tekniikoita tiedonsiirrossa.

2 Automaatioseuran OPC-toimikunta Nyt keväällä 2005 automaatioseuran yhteyteen perustettiin OPC-toimikunta. OPC - toimikunnan tavoitteena on edistää suomalaista automaatioalan opetusta, tutkimusta ja yritystoimintaa jakamalla tietoa OPC-järjestön toiminnasta ja spesifikaatioista, järjestämällä koulutusta ja tapahtumia sekä osallistumalla mahdollisuuksien mukaan OPC-spesifikaatioiden kommentointiin ja laadintaan. Jo aikaisemminkin Automaatioseuran puitteissa on järjestetty erilaista OPC aiheista aktiviteettiä Espoon Otaniemessä TKK:n tiloissa järjestettiin OPC-Roadshow tilaisuus, jossa Suomalaiset ja osin ulkomaisetkin yritykset esittelivät OPC:hen liittyvää toimintaansa. Lisäksi päivään liittyi OPC aiheisiä luentoja luennoitsijoina muun muassa Michael Vetter ja Jürgen Lange OPC-Europesta. Roadshow päivän lisäksi vuoden 2003 automaatiopäivien yhteydessä järjestetyssä Open Control Systems seminaaritapahtumassa järjestettiin OPC aiheinen sessio, jossa kutsuesitelmän pitivät Jürgen Lange ja Hans-Peter Otto OPC-Europesta. Yksi syy toimikunnan perustamiseen OPC:n ympärille on viimeaikoina OPC:n piirissä käynnissä ollut iso määrittelyaktiviteetti uuden OPC Unified Architecture nimisen spesifikaation laatimiseksi. OPC Unified Architecture Allekirjoittanut lähti Seattleen OPC Unified Architecture Developer Event tapahtumaan, jossa OPC-UA määrittely ensimmäisen kerran julkistettiin suurelle yleisölle, selvittämään OPC-UA määrittelyn tarkoitusta OPC-toimikunnan edustajana. Mieleen ennen matkaa nousi kysymys, miksi OPC on laatimassa taas uutta määrittelyä kun edellisiäkin on jo 9? Vastaukseksi voidaan todeta että OPC Unified Architecture ei ole 10 OPC:n standardi joukon jatkoksi vaan nimensä mukaisesti kokonaan uusi kokonaisvaltainen arkkitehtuuri, jonka on ajan kuluessa tarkoitus korvata edelliset irralliset määrittelyt. Syitä OPC Unified Architecture määrityksen laatimiseen on ollut useita. Internettekniikat ja verkottuminen ovat vaikuttaneet automaation tietotekniseen ympäristöön. Nykyinen automaation tietotekninen ympäristö asettaa käytettävälle tekniikalle vaatimuksia joihin ei 90-luvun puolivälissä osattu varautua. Verkottuminen on ennen kaikkea asettanut lisää vaatimuksia tietoturvalle ja luotettavuudelle. Lisäksi automaation edelleen jatkuva trendi moni toimittaja, moni toimija ympäristöihin sekä eri järjestelmien keskinäiseen integraatioon kaikilla toiminnan tasoilla alimman tason ohjauksesta aina yritystason järjestelmiin asettaa uusia vaatimuksia tiedonsiirtotekniikoille.

3 Teknisempiä motivaatioita OPC:n uudistamiselle on ollut OPC:ssä käytettävän COM/DCOM tekniikan osittainen vanhentuminen Microsoftin siirtyessä.net maailmaan ja WebService tekniikoiden yleistyminen vallitsevana tiedonsiirtotekniikkana. XML-DA oli OPC:n ensimmäinen askel Microsoft riippuvaisesta COM tekniikasta WebServicetekniikoihin. OPC:ssa ei kuitenkaan haluttu tehdä jokaisesta rajapintamäärittelystä uutta versiota WebServices tekniikoihin vaan samassa yhteydessä haluttiin myös katsoa koko OPC:n määrittelyperhettä. Yksi syy tähän oli se OPC:n nykyiset määrittelyt ovat erillisiä, josta aiheutuu tarpeettomia ongelmia. Esimerkiksi hälytys ja siihen liittyvät mittaustiedot joudutaan nykyisellään hakemaan erillisistä palvelimista. Lisäongelmia on aiheuttanut se että perinteisesti DA ja A&E palvelimilla on ollut käytössä erilaiset tietohierarkiat ja näiden keskinäiset riippuvuudet. OPC-UA:ssa vanhojen rajapintojen toiminnallisuudet tarjotaan yhden yhteisen palvelimen ja sen rajapintojen kautta. Lisäksi OPC:n vanhaa puumaista tietomallia on laajennettu monipuolisemmaksi verkkomalliksi, jossa samaan palvelimeen voidaan kuvata sekä DA-palvelimen tietohierarkia että A&E palvelimen hälytyshierarkia. OPC Unified Architecturen määrittely on edelleen käynnissä. OPC:n jäsenet pääsevät tällä hetkellä perehtymään OPC:n www-sivuilta alustavaan määrittelyyn. Kesä tai heinäkuun aikana spesifikaatiosta ja esimerkkikoodeista on tarkoitus julkistaa ensimmäinen beta versio ja loppusyksystä OPC:n on tarkoitus julkistaa OPC-UA:n ensimmäinen lopullinen versio. UA:n rakenne OPC:n UA spesifikaatio tulee poikkeamaan edellisistä määrittelyistä muodollisesti sillä se tulee noudattamaan IEC:n multipart spesifikaatioiden formaattia koostuen kahdestatoista osasta: Core Specification 1: Consepts 2: Address Space Model 3: Services 4: Information Model 5: Service Mappings 6: Profiles Access Type Specification 7: Data Access 8: Alarms and Events 9: Commands 10: Historical Data 11: Batch 12: Data Exchange

4 OPC:n tarkoituksena on yrittää saada OPC-UA IEC standardiksi myöhemmässä vaiheessa saatuaan sen ensin valmiiksi. Tietomalli OPC-UA:n arkkitehtuurin ydin koostuu oliomallista, osoiteavaruudesta, palvelurajapinnoista ja profiileista. Yksi iso keskeinen uusi asia OPC-UA:ssa on parempi tuki tietomallille, johon liittyy uudistettu osoiteavaruus, oliomalli ja semanttinen informaatiomalli. OPC-UA:han siirryttäessä osoiteavaruuden organisointi muuttuu monipuolisemmaksi verrattuna vanhoihin OPC-määrittelyihin. UA:ssa määritellyt oliomalli (Object Model), osoiteavaruusmalli (Address Space Model) ja informaatiomalli (Information Model) muodostavat ilmaisuvoimaisen kokonaisuuden, jolla OPC:llä siirrettävää data voidaan kuvata tietomallilla, joka on huomattavasti monipuolisempi kuin vanha puurakenne. UA:n osoiteavaruus onkin verkkorakenne jonka noodien välillä voi olla rajoittamattomasti nimettyjä riippuvuuksia. UA:ssa onkin määritelty lisäksi näkymät joilla osoiteavaruuden alijoukkoja voidaan esittää puurakenteina. Uuden tietomallin ja osoitehierarkian tarkoituksena on mahdollistaa eri standardointiryhmien määrittelemien tietomallien käytön OPC:ssa. OPC:llä onkin yhteistyötä esimerkiksi MIMOSAN ja ISA 88, 95 ja 99 työryhmien kanssa. Tietoturva ja Luotettavuus OPC-UA:n palvelurajapintoja ja tiedonsiirtoratkaisuita määriteltäessä erityistä huomiota on keskitetty tietoturvan ja luotettavuuden parantamiseen. Tietoturvan merkitys kasvaa laajennettaessa OPC:n käyttöä prosessitason suljetuista verkoista ylemmäs MES ja ERP tasoille sekä siirrettäessä tietoa hajautetuissa ympäristöissä internetin välityksellä. Vanhoista määrittelyistä poiketen UA määrittää käytettävät tietoturvaratkaisut ja asettaa minimivaatimukset, jotka jokaisen OPC-UA serverin ja clientin on toteutettava. Tietoturvaratkaisuissaan UA nojaa WebServices maailmasta peräisin oleviin WS Security standardeihin määrittäen standardien tarjoamista toiminnallisuuksista rajatut osajoukot joita UA:ssa käytetään. Käytettävän tietoturvan taso määritetään UA:n profiileilla kuten kaikki muukin vaihtoehtoinen toiminnallisuus UA:ssa. Minimivaatimus, jonka jokaisen UA sovelluksen on toteutettava, on Basic Security profiilin mukainen toiminnallisuus. Tässä client tunnistautuu salasana käyttäjätunnus parilla, jotka välitetään serverin ja clientin välillä salattuna. Salaus perustuu palvelimen sertifikaattiin ja julkisen ja salaisen avaimen salakirjoitukseen. Myös kaikki tunnistautumisen jälkeinen kommunikaatio serverin ja clientin välillä tapahtuu salattuna. Salauksen ja tunnistautumisen lisäksi minimitietoturvassa edellytetään kirjanpitoa kaikista tapahtuneista toiminnoista jotta tietoturvan perusvaatimuksiin liittyvä jäljitettävyys saavutetaan.

5 Basic Security profiilin lisäksi UA määrittää Kerberos ja X509 profiilit. Kerberos autentikointi on Windowsin käyttämä tapa. X509 kaikista profiileista monipuolisin ja siinä sekä client ja server tunnistautuvat sertifikaateilla. UA:n kommunikaatiomekanismeissa myös luotettavuuteen liittyviä asioita on parannettu huomattavasti vanhasta. Clientin ja serverin välisen yhteyden olemassaolon tarkkailu on UA:ssa sisäänrakennettu perustoiminnallisuuteen jolloin DA:n kaltaisia tilanteita jossa kestää minuuttia ennen kuin huomataan että yhteys on katkennut ei enää pääse tapahtumaan. Lisäksi UA:han on määritetty toiminnot, joilla yhteyskatkoksen jälkeen toivutaan ja välitetään kadonneet viestit. Myös clienttien ja servereiden kahdennus on mahdollista UA:ssa. Suorituskyky UA:n suorituskyvystä ei vielä ole selvyyttä. Varmaa on että sen suorituskyky ei tule yltämään nykyisen OPC-DA:n tasolle. Tämä johtuu WebServices tekniikoiden raskaudesta. Minimitavoitteeksi OPC-UA:n suorituskyvylle on asetettu se mihin DCOM pohjaisella DA:lla päästiin vuonna Tietokoneiden kapasiteetin nopea kehittyminen tulee joka tapauksessa nopeasti vähentämään OPC-UA:n suorituskykyongelmia. WebServices maailmassa on tällä hetkellä keskustelua XML:n binäärikoodaamisesta suorituskyvyn parantamiseksi. Kaikille on selvää että tekstimuotoinen XML tuhlaa siirtoresursseja. Binäärikoodaus on kuitenkin hankala kysymys koska eri ryhmillä ja käyttötarkoituksilla on keskenään ristiriitaisia tavoitteita. Tästä syystä OPC on määritellyt oman binäärikoodauksen OPC-UA:ssa käytettäväksi silloin kuin halutaan tiedonsiirtoa nopeuttaa. Implementointi Uuden OPC-UA arkkitehtuurin integroituminen vanhaan ja joustava siirtyminen vanhasta OPC DA, A&E ja HDA sovelluksista UA sovelluksiin on keskeinen edellytys OPC-UA:n onnistumiselle. OPC tulee tarjoamaan proxy-serverin ja client-stubin, joilla vanhojen ja uuden standardin mukaiset sovellukset saadaan keskustelemaan keskenään. Proxy-server tarjuaa UA:n mukaisen rajapinnan vanhoille servereille. Sen avulla vanhat DA, A&E ja HDA serverit saadaan näkymään yhtenä UA serverinä. Stubin avulla puolestaa vanhojen standardien mukainen client voi lukea tietoja UA serveristä. Rajoituksia tähän aiheuttaa UA:n monipuolisempi tietomalli. UA:n tietomallista on tarjottava vanhan standardin mukainen näkymä OPC clienteille. Proxyä ja stubia voidaan käyttää myös OPC yhteiden putkittamiseen WebService kommunikoinnin avulla Internet yli. Uusien Palvelinten ja clienttien ohjelmointiin OPC tulee tarjoamaan API:n, joka sisältää kirjaston jossa suurin osa OPC:n kommunikointiin liittyvästä toiminnallisuudesta on valmiiksi toteutettu. Ohjelmoija voi näin keskittyä itse sovelluksen ohjelmointiin. Alkuvaiheessa API tulee olemaan tarjolla.net ympäristöön C# kielellä ohjelmoiville. Myöhemmin API on tulossa ainakin ANSI C kielelle ja mahdollisesti myös Javalle mikäli kiinnostuneita vapaaehtoisia toteuttajia löytyy. Jos API:a ei löydy halutulle

6 ohjelmointiympäristölle OPC-UA on tietenkin myös mahdollista toteuttaa rajapintojen WSDL-kuvauksista ja Speksien määrittelyistä. Yhteensopivuus Myös yhteensopivuutta ja yhteensopivuustestausta on tarkoituksena parantaa OPC- UA:han siirryttäessä. Tämä on nähtävissä monella tasolla OPC-UA määrittelyssä. Spekseistä on poistettu hankalasti testattavat vapaaehtoiset toiminnallisuudet ja toiminnallisuudet on määritelty profiileina, jotka implementaatiot joko toteuttavat tai sitten eivät. Yhteensopivuuden korostaminen näkyy siinäkin että OPC tarjoaa ohjelmoijien käyttöön API rajapinnat joiden avulla OPC-UA clientit ja serverit toteutetaan, jotta rajapintamäärittelyjen erilaiset tulkinnat eivät häiritsisi yhteensopivuutta niin kuin nykyisten määrittelyjen yhteydessä. Lisäksi OPC on ilmoittanut että he tulevat tarjoamaan ohjelmoijien käyttöön edellisien määrittelyjen esimerkkitoteutuksista poiketen testatut referenssi-implementaatiot. Edellä mainittujen toimien lisäksi yhteensopivuustestausta tulleen UA:n yhteydessä entisestään kehittämään. Automaattisten testereiden ja yhteensopivuustestaus tapahtumien lisäksi kolmantena testauksen tasona tulee olemaan tarjolla riippumattomien laboratorioiden järjestämät testit. Näissä laboratoriotesteissä voidaan tehdä laajempia ja monipuolisempia testejä kuin aiemmin on voitu suorittaa. Uusia testattavia asioita tulevat olemaan ainakin kuormituskestävyys, vakaus pidemmällä aikavälillä ja erilaiset erikoistilanteet ja häiriöt. OPC:n tulevaisuus Kun kaiken edellä esitetyn huomioi, tulee mieleen kysymys siitä että onkohan OPC haukkaamassa nyt liian isoa palaa? Edellisten määrittelyjen vahvuushan on ollut siinä että ne ovat olleet helposti käsitettäviä rajattuja kokonaisuuksia tiettyä tehtävää varten ja onnistuneet lyömään itsensä läpi enemmän tai vähemmän helposti implementoitavani suppeutensa takia. Onko uusi OPC niin iso, laaja ja hankala että se ei tule samassa onnistumaan? Iso vaikutus tähän tulee olemaan kehitystyökaluilla. Mikäli OPC:n tarjoama ohjelmointi API on helppokäyttöinen ja integraatio kaupallisten ja avointen kehitystyökalujen ja web-service pakettien kanssa on ongelmatonta, implementointi ei tule olemaan ylitsepääsemätön haaste. Ainakin Microsoftin seuraavan sukupolven web-service ympäristön Indigon kanssa OPC- AU serverien ja clienttien ohjelmointi developer eventissä esitettyjen demojen ja puheiden perusteella tulee olemaan kohtalaisen helppoa. Kaikki monimutkaiset tietoturvaan, salauksiin ja kättelyihin liittyvät asiat hoituvat automaattisesti. OPC:n APIn pitäisi puolestaan huolehti kahdennuksiin ja luotettavuuteen liittyvistä asioista, joten ohjelmoijan vastuulle jää itse sovelluksen toteuttaminen. Myös muissa kuin Microsoft ympäristöissä OPC-UA:n käytän pitäisi olla helppoa koska UA:n käyttämä web-service

7 tekniikka on yhteisesti sovittujen standardien mukaista. OPC:n tarjoamaa API:a ei kuitenkaan välttämättä ole tarjolla kaikkiin järjestelmiin jolloin ohjelmoijan vastuulla on suurempi osa OPC-UA määrittelyjen mukaisen toiminnallisuuden toteuttamisesta.