Analys av OLE för processkontroll. Lars Öman

Transkript

1 Analys av OLE för processkontroll Lars Öman Examensarbete i datalogi vid Stockholms universitet 2009

2 NADA Analys av OLE för processkontroll Lars Öman Examensarbete i datalogi (30 högskolepoäng) Fristående kurs Stockholms universitet år 2009 Handledare vid Nada var Kjell Lindqvist Examinator var Lars Kjelldahl TRITA-CSC-E 2009:090 ISRN-KTH/CSC/E--09/090--SE ISSN Institutionen för numerisk analys och datalogi KTH Stockholm

3 Referat OPC är en standard som skapats för överföring av processdata och andra data mellan olika datorsystem inom olika typer av processindustrier. Den utvecklades av olika systemleverantörer ur ett behov inom processindustrin att möjliggöra utväxling av processdata mellan system. På en fabrik fanns (och finns i växande grad) ett stort antal datasystem. Dessa omfattar hela omfånget från processnära styrsystem (DCS), via informationssystem och vidare till fabriks- och koncernvisa planerings- och uppföljningssystem. Det organ som ansvarar för utvecklingen av olika OPC-standarder, OPC Foundation, har sedan något år fokuserat sina ansträngningar på att introducera en ny standard, benämnd UA. Denna medger användning av ett flertal olika underliggande plattformar där inte minst val av olika webbtekniker medför ett paradigmskifte jämfört med föregående OPC-standarder som byggde (med något undantag) på Microsofts COM/DCOM-teknik. Syftet med detta arbete har varit att analysera dessa två olika generationer av OPC och i samband med detta klargöra deras olika styrkor och svagheter. De två olika generationerna har jämförts med avseende på applicerbarhet, prestanda, användning av olika underliggande standarder, säkerhet, tillförlitlighet och tillgänglighet. Slutsatsen av detta examensarbete är att OPC genom framtagandet av UA kommer att ges en stor möjlighet att behålla sin dominerande ställning på processnära nivå och också att slå sig in och bli en viktig standard för interkommunikation på affärsnivå. Inte minst borde stödet från tunga aktörer på marknaden av UA borga för detta. Det kvarstår att se hur kunderna, systemägarna, tar emot den.

4 Abstract Analysis of OLE for Process Control OPC is a standard created for transfer of process data and other data between different computer systems within various branches of the process industry. It originated from a need within the process industry to exchange data between systems from different suppliers. There is on each factory site a growing number of computer systems. This spans all type of systems, from DCS systems for process control further up towards planning and tracking systems on enterprise level. The organization responsible for development of different OPC standards, the OPC Foundation, has since a few years been focusing on introducing a new standard named UA Unified Architecture. This standard allows the use of several underlying platforms where the availability of several different web technologies leads to a paradigm switch in comparison to earlier OPC standards. Most of these earlier standards were, with just a few exceptions, based on Microsoft s COM/DCOM technology. The purpose of this thesis has been to analyze these two generations of OPC standards and clarify their strengths and weaknesses. The two generations have been compared concerning applicability, performance, reliance on open standards, security, stability and availability. The conclusion of this thesis is that OPC by the development of UA is given a high possibility to maintain its dominating position on the process control level and also that it has a high chance of becoming an important standard for communication on business level. This is supported by the high number of major suppliers backing up the standard. It remains to see how their customers, the owners of the systems, accept it.

5 Förord Denna rapport är den avslutande delen för en magisterexamen i datalogi vid Stockholms universitet. Jag vill tacka min handledare på Nada, Kjell Lindqvist, som gett rådigt och nödvändigt stöd samt tacka min hustru Lotta för hennes fulla stöd i detta. Utan henne hade denna rapport inte blivit av.

6 Innehåll 1 Inledning Bakgrund Syfte och problemformulering Metod Avgränsningar Genomgång av COM/DCOM-standarden Översikt Orsak till varför COM utvecklades Vad är COM? Grundläggande krav som COM måste uppfylla Beskrivning hur COM-objekt används Hur klient kommunicerar med COM-objekt Beskrivning av hur COM-objekt definieras Allmän beskrivning av COM OPC-standarden Historik Beskrivning OPC (COM-baserad) Generell beskrivning Beskrivning av OPC DA: Data Access Beskrivning av OPC HDA: History Data Access Beskrivning av OPC AE: Alarm and Event Beskrivning av OPC XMLDA: XML Data Access Beskrivning av OPC Batch Beskrivning av OPC Security Beskrivning av OPC DX: Data exchange Beskrivning av OPC CX: Complex Data Beskrivning av OPC Commands Beskrivning av OPC UA Generell beskrivning Utförligare beskrivning Analys och resultat Jämförelse mellan OPC-DCOM och OPC UA Applicerbarhet Prestanda Standarder Säkerhet Tillförlitlighet Tillgänglighet Generell utvärdering Utveckling och framtid för OPC Källförteckning... 48

7 1 Inledning Detta kapitel handlar om examensarbetets bakgrund, syfte och avgränsningar. 1.1 Bakgrund OPC 1 är en standard som skapats för överföring av processdata och andra data mellan olika datorsystem inom olika typer av processindustrier. OPC har sitt ursprung i användares behov att enkelt och effektivt möjliggöra kommunikation mellan system av olika fabrikat. Standarden släpptes 1996 och har sedan dess i allt högre grad använts inom processindustrin. Om vi bortser från olika systemleverantörers egna protokoll och sätt att föra över data mellan deras olika noder, fanns innan OPC i princip inget annat alternativ än textfiler. Detta innebar problem på olika produktionsanläggningar vilka önskade att skicka processdata mellan system av olika fabrikat. Anläggningarna var ofta tvungna att implementera någon form av speciallösning. Användningen av standarden har under årens lopp spridit sig även utanför processindustrin, bland annat återfinns standarden för kommunikation mellan styrenheter för styrning av värme och ventilation av fastigheter. 1.2 Syfte och problemformulering Syftet med detta arbete har varit att analysera underliggande teknologier hos OPC och i samband med detta klargöra dess olika styrkor och svagheter. Systemingenjörer stöter ofta på problem vid överföring av processdata mellan datorsystem. OPC-standarden har till viss del underlättat sådan överföring, men tillämpningen av OPC har knappast varit problemfri. Det var därför angeläget att undersöka och analysera standarden, inklusive vissa av de mest använda delstandarderna. När denna rapport påbörjades 2005, var OPC UA 2 ännu i sin linda, varför intresset helt fokuserades på den COM-baserade varianten av standarden. Problemformuleringen var då följande: Att undersöka och klarlägga standardens underliggande struktur Att undersöka och klargöra eventuella felaktigheter och problem i hur standarden appliceras 1 Object Linking and Embedding for Process Control 2 Unified Architecture 1

8 Arbetet avbröts för att återupptas under Under denna tid hade OPC UA utvecklats markant genom att en mängd dokument som beskriver UA hade släppts. Det uppstod därmed ett intresse av att inkludera UA i studien. Problemformuleringen fick därför även inkludera följande: Att jämföra den COM-baserade versionen av OPC-standarden med OPC-UA, och då särskilt fokusera på frågan har den senare förmåga att ersätta den förra inom processindustrin. 1.3 Metod Jobbet har främst bestått av litteraturstudier, men vissa studier av källkodsexempel avseende COM har även gjorts. 1.4 Avgränsningar Avgränsningar för examensarbetet har utgjorts av att studera enbart OPC DA 3 bland de COM-baserade standarderna. Övriga COM-baserade delstandarder har endast översiktligt studerats och beskrivits. Anledningen till detta är framför allt omfattningen av installerad mjukvara, där den COM-baserade DA-standarden är den absolut mest använda. Utöver detta har också nästa generation av OPC, UA, studerats. Denna har jämförts mot de äldre, DCOM-baserade, versionerna. Tiden har inte räckt till för att utföra egen testning av standardens olika delar. 3 Data Access 2

9 2 Genomgång av COM/DCOM-standarden Detta kapitel handlar om COM/DCOM-standarden, vilken utgör en plattform för den första generationens OPC-standarder. 2.1 Översikt COM är en av Microsoft definierad arkitektur eller standard, med vilken olika program kan erbjuda tjänster på ett strukturerat sätt. ActiveX 4 och OLE 5 är två, bland flera, olika begrepp eller tekniker som baseras på COM. Men trots att Microsoft inte ens nått upp till ett releasenummer högre än 0.9 för COM-standarden, är den en standard på utgående. Inte minst kan denna slutsats dras eftersom COM-standarden inte längre återfinns på Microsofts hemsidor. Detta innebär inte att COM inte har haft någon betydelse inom mjukvaruindustrin. Snarare är den i dag i högsta grad levande då den är implementerad i ett otal applikationer och mjukvarulösningar världen över. Några viktiga årtal värda att nämnas med COM:s utveckling: 1991 OLE (Object Linking and Embedding) 1.0 släpps. Denna teknik utvecklades i första hand för sammansatta Word- och Excel-dokument Windows 3.1 släpps med OLE 1.0 integrerat Första implementationen av COM släpps i form av underliggande objektmodell för OLE 2.0. Denna version av OLE utvecklas mer generellt för användning av mjukvarukomponenter. COM är vid denna tidpunkt inte ett eget begrepp, utan återfinns under samlingsnamnet OLE DCOM släpps Microsoft börjar använda COM som eget begrepp DCOM version 1.3 släpps 2000 Windows 2000 släpps. Integrerat med detta släpps samtidigt COM+. Som namnet indikerar, COM Component Object Model baseras arkitekturen på objektorienterad programmering. Den baseras också på ett klient/server koncept. De program som tillhandahåller tjänster enligt standarden kallas för COM-objekt. Varje sådant objekt tillhandahåller sina respektive tjänster genom ett eller flera s.k. gränssnitt (eng. interface ), eller för att uttrycka sig mer konkret, tjänsterna ifråga är normalt metoder i form av funktioner och procedurer. Varje COM-objekt hör hemma i en COM-server och är en instansiering av en COM-klass. En COM-server är alltså en binär fil som innehåller kod för en eller flera COM-klasser. 4 Microsoft-beteckning av komponent-objektmodell 5 Object Linking and Embedding 3

10 2.2 Orsak till varför COM utvecklades Det finns säkerligen ett flertal olika uppfattningar rörande vilken den ursprungliga orsaken var till att COM utvecklades som standard. Vid studie av dess historik (avsnitt 2.1 ovan) framgår det att den senaste versionen av standarden inte till fullo överensstämmer med de ursprungliga idéer som fanns vilket dock hör till sin natur. En grundläggande tanke när standarden utformades var att man måste kunna ändra i en implementationsklass utan att detta kräver att klientapplikation måste omkompileras. Om ett stort antal klientapplikationer finns distribuerade, måste man kunna ändra i serverapplikationen utan att klienterna tvingas uppgradera sina applikationer. En annan grundläggande tanke var att om en ändring nu görs på serversidan, måste en klientapplikation ges möjlighet att kunna upptäcka denna annars är ju tanken med att kunna ändra i serverapplikationen tämligen meningslös. Ett ytterligare krav var att användning av olika kompilatorer måste tillåtas. Programutvecklare måste på olika håll kunna arbeta med samma klient- och serverlösning utan att först behöva tänka på vilken utvecklingsmiljö övriga utvecklare arbetar i. Slutligen måste ett enhetligt system för interprocesskommunikation (serialisering) föreligga. 2.3 Vad är COM? COM-standarden definierar endast hur de olika gränssnitten till COMobjekten ska se ut. Den säger således ingenting om implementationen i objekten bakom varje gränssnitt. Hur programkoden i objekten (klasserna) utformas är alltså helt upp till objektleverantören, så länge reglerna för gränssnitten följs. Ett grundläggande krav i standarden är att ett COM-objekt (COMklass) inte kan ändra omfattningen av sina gränssnitt. Olika versioner kan alltså inte finnas. Ändras något gränssnitt i en COM-klass leder det till en ny klass med ny klassidentitet (engelska CLSID Class Identity). Ett COM-objekt brukar grafiskt representeras enligt figur 1. Figur 1: Ett COM-objekts tjänster är åtkomliga via dess olika gränssnitt. 4

11 Mot ett sådant gränssnitt ansluter sedan en klientapplikation. Varje gränssnitt inkluderar en eller flera metoder och varje gränssnitt döps till ett namn som börjar på I (från engelskans Interface ). Ett enkelt exempel representeras grafiskt i figur 2. Figur 2: En klientapplikation med pekare till COM-objekts gränssnitt. En konkurrerande teknologi är OMG:s 6 CORBA. 7 (för en intressant jämförelse läs [10]). Även om COM-standarden ska vara generell och inte vara bunden till något programspråk, visar dess uppbyggnad att dess skapare på Microsoft var influerade av programspråket C++. Allteftersom har dock olika tillägg gjorts för att anpassa standarden för att andra språk ska få tillgång till COM, som exempelvis Microsofts Visual Basic och Borlands Delphi. COM:s föregångare var Microsofts OLE 8 -teknik som än i dag används för utbyte av olika objekt inom Microsofts Office familj. Ett exempel på dess användning är att man enkelt kan flytta en tabell från ett Microsoft Excel-ark till ett Microsoft Word dokument. När COM-standarden släpptes, löste den ett antal problem för programmerare världen över inte minst inom Microsoft-världen. Ett av dessa var att kunna distribuera objekt som kunde användas av andra programmerare utan att dessa behövde tillgång till objektets källkod vid kompilering. Ett annat problem var att program skrivna i olika programspråk inte kunde användas tillsammans. Ett tredje problem var att program skrivna i samma språk men kompilerade i kompilatorer av olika fabrikat ofta drabbades av problem när de skulle användas tillsammans. Som nummer fyra på listan fanns problemet att en ändring av ett enskilt objekt i en större applikation medförde omkompilering och/eller omlänkning av hela applikationen. COM behandlar gränssnitt, implementationer och klasser som distinkta begrepp. Gränssnitt är abstrakta protokoll för att kommunicera med ett objekt. Implementationer är konkreta datatyper som understöder ett eller flera gränssnitt. Klasser slutligen är namngivna implementationer som representerar instansierbara objekt och kallas för COM-klasser (på engelska coclasses ). 6 Object Management Group 7 Common Object Request Broker Architecture 8 Object Linking and Embedding 5

12 En COM-klass är implementerad i en server. En server kan implementeras antingen som en s.k. in-process server en DLL-fil, som en lokal server en EXE-fil, eller som en distansserver en EXE-fil på en annan dator. Den sistnämnda innebär implementering av den utökning av den ursprungliga COM-standarden som betecknas DCOM 9. En DLL 10 -fil är ett publikt bibliotek av körklara funktioner. DLL:en laddas när en applikation som behöver någon funktion i DLL:en gör ett anrop. Inläsning till internminne sker alltså inte vid start av applikationen utan först vid anrop. Ett eller flera COM-objekt (med ett eller flera gränssnitt) i en DLL kan anropas från en klient. En DLL kan kompileras och länkas separat från den kallande applikationen (t.ex. en COM-klient). Koden tillhörande en DLL exekverar i samma process som den kallande applikationen [9]. En lokal server har ett COM-objekt implementerat i en egen exe-fil. Som sådan exekverar den i en egen process. Detta medför att ett anrop från klientapplikationen till den lokala servern kräver användning av något mellanliggande protokoll (som ex. RPC 11 ). Detta innebär exekvering av ytterligare kod jämfört med en in-process server. I figur 3 ser vi ur ett förenklat perspektiv de tre olika sätt på vilket en COM-klient kan koppla mot en COM-server. Figur 3: En COM-server kan implementeras på olika sätt. 9 Distributed COM 10 Dynamic Link Library 11 Remote Procedure Call 6

13 2.4 Grundläggande krav som COM måste uppfylla Baserat på vad som nämns i föregående avsnitt (2.2 och 2.3), uppkom några krav som måste uppfyllas. För det första innebär bristen av en binär standard hos C++ att omfattningen av funktionaliteter som kan utväxlas genom DLL-gränser begränsas. För det andra innebär den täta binära kopplingen i C++ mellan klient och objekt, och inkompatibilitet mellan kompilatorer och länkare av olika fabrikat att enkel export av C++-klasser i DLL:er inte låter sig göras. För att försäkra sig om att alla kompilatorer genererar likartad maskinkod ställs vissa krav på gränssnittsklassen. Pradeep Tapadiya uppställer följande punkter för att uppfylla kraven [14]: endast helt virtuella metoder inga överladdade ( overloaded ) virtuella metoder inga variabler ( member variables ) utgå ( derive ) från maximalt en basklass i arvskedja Resultatet av detta är att en abstrakt basklass, dvs. grunden till ett gränssnitt, erhålls. 2.5 Beskrivning hur COM-objekt används För identifiering av olika COM-typer används GUID:er 12 som är 128 bitar långa tal. Dessa baseras på UUID:er 13 som används i DCE RPC [16]. Det får inte finnas två typer med samma UUID överhuvudtaget. När ett nytt UUID behövs, använder algoritmen som skapar detta utifrån den lokala nodens klocka och MAC adress. Om typen ifråga är ett gränssnitt talar man om gränssnitts-identiteter eller IID:er 14. Handlar det istället om COM implementationer (COMklasser) betecknas deras identitet med klassidentitet eller CLSID:er 15. Olika COM-klasser som är likartade kan kategoriseras tillsammans. För detta finns möjligheter att tilldela sådana klasser en identisk s.k. katgori-identitet eller CATID 16. En sådan kategoriuppdelning skulle exempelvis kunna vara språktillhörighet. Varje COM-klass som ska användas av någon klient, måste vara registrerad i Windows systemregister (Windows Registry) 17. Varje respektive CLSID-nyckel innehåller sedan bl.a. information om var den sökta COM-servern finns (nod/sökväg). 12 Globally Unique Identifiers 13 Universally Unique Identifiers 14 Interface ID 15 Class ID 16 Category ID 17 nyckel HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID 7

14 Om ett CLSID är ohanterligt p.g.a. dess stora antal siffror, kan ett mer lättläst ID, en ProgID, tilldelas en typ. Denna ProgID garanterar dock inte samma unikhet av en typ som ett UUID utgör. Även ett ProgID måste registreras i systemregistret för att kunna användas. Ett ProgID definieras i form biblioteksnamn.klassnamn.version. Utifrån ett ProgID kan en klient erhålla motsvarande CLSID och vice versa. Registrering av en klass kan ske på flera olika sätt beroende på tillämpning. Antingen kan en register-fil (fil med filändelse reg ) där registernycklar och värden direkt är angivna kan skapas, eller så kan ett installationsprogram skapas. Alternativt kan klassen själv innehålla kod som hanterar registrering och avregistrering. För en.exeimplementerad server (servern finns i en exekverbar fil med filändelse exe ) kan då registrering ske genom att exekvera denna med flaggor tillagda i kommandot. För en dll måste funktionerna DllRegisterServer och DllUnregisterServer vara implementerade för att möjliggöra registrering och avregistrering. Registrering (och avregistrering) kan då ske dynamiskt vid exekvering eller som alternativ statiskt genom anrop av regsvr32.exe. Implementering av funktionerna kan vara relativt komplexa, men underlättas genom användning av ATL-mallar eller MFC-funktioner. COM biblioteket (eng. COM Library ) innehåller ett antal tjänster som behövs i COM och återfinns framför allt i DLL-filen OLE32.DLL. Bland annat används det för att skapa COM-objekt. IUnknown är roten till alla COM-gränssnitt och är det enda COMgränssnitt som inte ärver metodanrop från något annat gränssnitt. Varje COM-gränssnitt måste vara ett arv från IUnknown eller ett annat COM-gränssnitt (som i sin tur har ärvt gränssnittet IUnknown) dock maximalt ett annat sådant. En orsak till det sistnämnda är att kompilatortransparans [2] skulle frångås. Det är genom IUnknown som en klient kan få tillgång till övriga gränssnitt i ett objekt alla COM-objekt måste stödja IUnknown. IUnknown innehåller endast tre metoder: QueryInterface, AddRef och Release. Eftersom alla funktioner i ett COM-gränssnitt är rent virtuella, måste den ärvda klassen innehålla implementation för samtliga dessa funktioner, inklusive de som ingår i IUnknown. Precis som gäller för alla andra gränssnitt, finns det ingen kod tillgänglig som implementerar IUnknown, utan detta får konstruktören av server-objektet själv skapa eller kopiera från annat ställe. Dock beskriver COM noga vad en klient kan förvänta sig vid anrop av IUnknown. Figur 4 beskriver vilka metoder IUnknown måste stödja. 8

15 extern "C" const IID IID_Unknown; interface IUnknown { virtual HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, void **ppv) = 0; virtual ULONG STDMETHODCALLTYPE AddRef(void) = 0; virtual ULONG STDMETHODCALLTYPE Release(void) = 0; } Figur 4: C++ definition av gränssnitt IUnknown. Parametern riid till QueryInterface är det fysiska namnet (IID) på det gränssnitt som sökts av klienten medan parametern ppv är en pekare som returneras till klienten och som pekar på det önskade gränssnittet, samtidigt som HRESULT S_OK returneras. Om gränssnittet inte skulle finnas i objektet, sätts ppv till noll samtidigt som HRESULT E_NOINTERFACE returneras. Ett COM-objekt som själv kan finna och instansiera andra COMobjekt kallas för en moniker och stödjer IMoniker-gränssnittet. Genom användning av en moniker, kan förfarandet att skapa ett COM-objekt underlättas för en klient. En moniker kan skapas av en annan moniker. COM definierar ett antal gränssnitt för att möjliggöra persistens d.v.s. möjliggöra för ett objekt att såväl spara undan dess status på hårddisk som att ladda in samma parametrar från hårddisk. 9

16 2.6 Hur klient kommunicerar med COM-objekt Skeendet när en klientapplikation efterfrågar ett COM-objekt, är följande (åskådliggjort i figur 5): 1. klienten anropar COM-biblioteket med klassidentitet (CLSID) och identitet för önskat gränssnitt (IID). 2. COM-biblioteket lokaliserar plats (nod och sökväg) för COMservern (DLL eller EXE) med hjälp av Windows systemregister 3. COM-biblioteket ordnar så att servern laddas och instansierar objektet. COM-biblioteket efterfrågar (och erhåller) samtidigt pekare till efterfrågade gränssnittet. 4. Pekaren skickas vidare till klienten. 5. Klienten anropar med hjälp av pekaren, önskad metod i det efterfrågade gränssnittet. För att lösa uppgiften med att ladda och instansiera objektet, anropar COM-biblioteket en tjänst vid namn Service Control Manager (SCM) och som återfinns i filen RPCSS.DLL. Denna kategoriseras som en av flera beståndsdelar i COM+. Varje maskin som understödjer COM måste ha såväl ett COM-bibliotek som en SCM. klient 5. klienten kan anropa funktioner i gränssnittet objekt server 1. klienten anropar COM-biblioteket 4. pekare till gränssnitt returneras via COM-biblioteket 3. COM instansierar server COM bibliotek 2. COM lokaliserar server system registry Figur 5: Skapande av COM-objekt. Den pekare som returneras till klienten, är kopplad till gränssnittet IUnknown. Genom att sedan anropa metoden IUnknown::QueryInterface och skicka med IID för den önskade metoden, returneras till klienten en ny pekare till denna. Klienten kan därefter anropa den önskade klienten. Figur 6 visar ett exempel där en klient anropar IUnknown för att tillhandahålla referens till det efterfrågade gränssnittet IDataTrans. 10

17 Figur 6: En klient kopplar först mot IUnknown. För att aktivera ett COM-objekt, finns ett gränssnitt, IClassFactory, som används för att implementera s.k. klassobjekt eller klassfabriker 18. När ett sådant klassobjekt skapats, är dess främsta uppgift att skapa ett eller flera av klienten efterfrågade användarobjekt. Observera att såväl klassobjektet/klassfabriken som det eller de av klienten efterfrågade användarobjektet är implementerade enligt COM. Fördelen med att använda klassobjekt är att såväl språk- som lokaltransparens erhålls på ett stringent sätt. COM definierar tre olika aktiveringsmodeller som kan användas för att ladda in objekt till internminnet så att metodanrop därefter kan möjliggöras. Klienter kan via COM-biblioteket anropa ett klassobjekt (som i sin tur anropar användarobjekt). Klienter kan också anropa COM-biblioteket för att direkt anropa ett användarobjekt. Slutligen kan klienten fråga efter ett persistent objekt. d.v.s. ett objekt vars status är sparad på hårddisk. Av dessa tre är endast anrop av klassobjekt nödvändigt att implementera. Består servern av en DLL-fil, är aktivering av ett COM-objekt en relativt enkel hantering. Detta med hjälp av Windows inbyggda DLLhantering och COM/COM+ påbyggnader. Är servern istället implementerad i en EXE-fil, eller installerad på annan maskin än klient-maskinen, måste någon form av serialisering utföras. Med serialisering menas här en hantering för paketering av data i lämpligt format för utväxling mellan olika processer, antingen i samma eller mellan olika maskiner. För att hantera serialisering används mellanservrar 19 och stubbar 20. En mellanserver ser från klientapplikationens håll ut som det efterfrågade objektet d.v.s. dess gränssnitt ser identiskt ut. Men istället för att utföra den önskade funktionen, paketerar en mellanserver alla metodparametrar och skickar dessa vidare till en motsvarande stubb. Denna stubb paketerar sedan i sin tur upp metodparametrarna och anropar det riktiga objektet med dessa. Returnerat resultat skickas samma väg tillbaka. Klienten ser alltså ingen skillnad mellan en server implementerad i en DLL-fil 18 Class Objects, Class Factories 19 Proxies 20 Stubs 11

18 och en EXE-fil. Inte heller ser klienten någon skillnad mellan en lokal server och en server i en annan maskin. En DLL-baserad server är, då objektet exekverar i samma process som klienten, naturligtvis snabbare med att returnera ett resultat i jämförelse med en EXE-baserad dylik. Sker anropet dessutom över ett nätverk av någon form, ökar svarstiderna än mer. Man talar här om en kontextgräns, där en process eller en maskin (nod) kan ses som en sådan (se figur 7). När kontextgränsen är maskingräns, sker kommunikation mellan maskinerna med hjälp av ORPC 21 som i sin tur använder MS-RPC 22. Figur 7: Användning av mellanserver och stubb. 2.7 Beskrivning av hur COM-objekt definieras För att kunna skapa en COM-class, måste man utgå från en IDL-fil 23. COM:s IDL definition, MIDL 24, bygger på OSF:s 25 IDL-specifikation, men har fått några tillägg för att understödja COM:s objektorienterade inriktning [12]. För kompilering av sådana MIDL-filer, distribuerar Microsoft en MIDL-kompilator (MIDL.EXE). För enkelhets skull har denna kompilator i olika litteratur och dokumentation fått beteckningen MIDL, medan Microsofts IDL-specifikation benämns COM IDL. En definition av ett gränssnitt i IDL (åskådliggjort i figur 8) måste inledas med begreppet interface. Denna föregås av attribut som är angivna inom hakparenteser. Ett av attributen är en UUID en unik identitet för gränssnittet som alltid måste anges. 21 Object RPC 22 Remote Procedure Call 23 Interface Definition Language 24 Microsoft IDL 25 Open Software Foundation 12

19 [ local, object, uuid( c ) ] interface IUnknown { HRESULT QueryInterface( [in] REFIID riid, [out] void **ppv); ULONG AddRef(void); ULONG Release(void); } Figur 8: IDL definition av IUnknown. När en COM IDL fil kompileras av MIDL, genereras ett flertal filer som kan sammanfattas enligt följande: C/C++ header-filer kod för skapande av mellanservrar/stubbar (med tillhörande serialisering 26 ) typbibliotek 27 Header-filerna definierar de abstrakta bas-klasserna som motsvarar de gränssnitt som är definierade i IDL:en. Dessa header-filer används såväl av skapare av COM-objekt som av skapare av klientkod. Typbiblioteket är binär kod som tillåter andra COM-applikationer att skapa kopplingar mot den aktuella komponenten. Denna binärkod kan ingå i koden för en DLL- eller EXE-fil. 2.8 Allmän beskrivning av COM+ I ett försök att skapa en homogen miljö för utveckling och användning av program, inte minst riktad mot affärskritiska system, skapade Microsoft något de benämnde DNA. Denna bestod av en logisk arkitektur av tre lager presentation, affärslager och datalager. För kommunikation dessa lager emellan, skulle en blandning av COM/DCOM och HTTP användas. För hantering av affärslagret, fanns sedan tidigare en funktionalitet, MTS 28. Denna, tillsammans med ett antal andra funktioner i Windows, införlivades i Windows 2000 tillsammans med COM. Denna affärslager-funktionalitet samlades sedan under namnet COM+. 26 Marshalling 27 Type Library 28 Microsoft Transaction Server MTS 13

20 3 OPC-standarden Detta kapitel handlar om de olika OPC-standarder som presenterats av OPC Foundation. Här beskrivs såväl de tidigare generationerna baserade på COM/DCOM, som den senaste OPC-standarden, OPC-UA. 3.1 Historik The OPC Foundation är en sammanslutning av över 300 medlemmar i form av olika företag från hela världen. Den startades ursprungligen av ett antal företag inom automationsindustrin i avsikt att skapa en standard för datakommunikation. Arbetet skedde i samarbete med Microsoft då den ursprungliga standarden baserades på Microsofts OLE COM/DCOM standarder. De absolut flesta företag som återfinns inom automationsindustrin är idag medlemmar i sammanslutningen. Några exempel är ABB, Bosch, Emerson, GE, Honeywell, ICONICS, ISA Matricon, Microsoft, Metso Automation, Mitsubishi, Siemens, Toshiba och Yokogawa, En given deltagare är också Microsoft. 29 I OPC:s regi har ett antal delstandarder utvecklats. De viktigaste har varit: DA: Data Access Används för överföring av realtidsdata mellan en OPC DA server och en OPC DA klient. DA servern är normalt ett styrsystem eller annan processdatakälla. Data skickas normalt från server till klient, men omvänd datariktning kan förekomma. HDA: History Data Access Används för överföring av historisk data mellan en OPC HDA server och en OPC HDA klient. HDA servern är normalt ett styrsystem eller en annan processdatakälla. AE: Alarm and Event Används för konfigurerad larm- och händelsehantering (i motsats till det kontinuerliga dataflödet i DA). Inkluderar processlarm, operatörshändelser, informationsmeddelanden och spårnings-/loggningsmeddelanden. XMLDA: XML Data Access Används för överföring av data via XML (mer specifikt, SOAP och andra Web Services ). Batch: Används specifikt inom olika batch-processer. 29 Mer information om sammanslutningen kan återfinnas på dess hemsida, 14

21 Security: Används för att administrera säkerhet med avseende på åtkomst av data. DX: Data Exchange Används för dataöverföring på server/server-basis (istället för på klient/server). Konfiguration på distans, diagnostik och övervakning/administration kan dessutom tillföras med hjälp av denna standard.. CX: Complex Data Tilläggsstandard till DA och XML-DA. COmplex Data definierar (som dess namn antyder) hur mer komplicerade datatyper kan användas. Commands: Standard för att definiera hur OPC servrar och OPC klienter identifierar, skickar och kontrollerar kommandon som avses exekveras på någon form av enhet. Common Definitions: Dokumentet innehåller gemensamma regler och designfrågor som berör de övriga delstandarderna. UA: Nytt initiativ som i princip ska ersätta alla de tidigare delstandarderna (se vidare avsnitt 3.3) Om vi tittar på några årtal som markerar OPC-standardens utveckling, kan en lista se ut enligt följande: 1996 OPC Foundation presenteras på ISA möte. OPC DA 1.0 släpps något senare 1997 OPC DA 1.0A släpps 1998 OPC DA 2.0 och AE 1.0 släpps 1999 OPC AE 1.01 Auto och DA 2.02 släpps 2000 OPC HDA 1.0 släpps 2001 OPC Batch Auto 1.0, Batch 2.0, HDA Auto 1.0 och Security 1.0 släpps. OPC Compliance Testing and Certification för OPC DA servrar införs. Certifieringen införs så småningom även för AE Servrar OPC AE 1.1, Common 1.1 och DA 2.05a släpps 2003 OPC HDA 1.2, Complex 1.0, XMLDA 1.0, DX 1.0 och DA 3.0 släpps 2004 OPC Commands 1.0 släpps 2005 OPC UA Unified Architecture släpps 15

22 3.2 Beskrivning OPC (COM-baserad) Här beskrivs de första generationernas OPC-standarder som föregick OPC-UA Generell beskrivning På olika fabriker fanns (och finns i växande grad) ett stort antal datasystem. Dessa omfattar hela omfånget från processnära styrsystem (DCS), via informationssystem och vidare till fabriks- och koncernvisa planerings- och uppföljningssystem. Då det före OPC inte fanns någon enhetlig standard för överföring av processdata, utvecklade de olika leverantörerna egna gränssnitt för kommunikation mellan sina olika dataenheter i ett system (här avses begreppet gränssnitt mer generellt). Det var inte ovanligt att flera olika typer av gränssnitt från en och samma leverantör kunde förekomma. När sedan behov uppstod av att kommunicera mellan system från olika leverantörer, växte problematiken allt mer. Följden blev att en leverantör var tvungen att utveckla ett flertal gränssnitt inte enbart för att kommunicera mellan egenutvecklade system, utan dessutom ett flertal för att möjliggöra kommunikation mot alla andra leverantörers olika system. Utifrån behovet av en allmänt accepterad standard uppstod då OPC. Figur 9 åskådliggör problemet. Figur 9: Exempel på behov av gränssnitt mellan olika system. Inte minst baserat på systemägarnas krav, ledde utvecklingen till att Microsofts Windows-miljö valdes som en allmän plattform på vilken systemleverantörerna byggde sina applikationer. Det föll sig då naturligt att använda COM-arkitekturen som grund för en öppen standard att användas av de olika systemleverantörerna. Man nådde då en situation som schematiskt åskådliggörs i figur

23 Figur 10: Exempel på användning av OPC mellan olika system. 30 Då behovet till att börja med var att överföra processdata mellan olika process-system, utvecklades följaktligen OPC-DA standarden först. Allteftersom DA användes ute i industrierna, uppkom behov av utökad funktionalitet, varför delstandarder för dessa också utvecklades. Överföring av larm, händelser och historiska data är exempel på sådana behov. Då utvecklingen gjorde att slutet för COM kunde börja anas, utvecklades OPC XML DA där XML/SOAP utgjorde teknisk plattform. Initialt var intentionerna troligen att utveckla motsvarande XML-baserade alternativ för de övriga delstandarderna. Dessa intentioner föll troligtvis då tanken på en ny arkitektur som skulle ersätta samtliga delstandarder dök upp. Denna arkitektur är den under 2005 släppta UA Beskrivning av OPC DA: Data Access Den OPC DA standard som här beskrivs avser 3.0 för custom - gränssnitt och 2.02 för Automation-gränssnitt. OPC DA specificerar hur data kan utväxlas mellan en OPC DA-klient och OPC DA-server och baserar sig på COM. Klienten är här (som i de flesta klient/server-konfigureringar) den begärande parten och servern är den tjänande parten. Servern hämtar data från (eller skickar data till) en datakälla via något underliggande gränssnitt som inte nödvändigtvis är baserat på COM. Datakällan kan exempelvis vara en modul i ett styrsystem, arkitektoniskt nära belägen en industriprocess via exempelvis I/O till fältutrustningar. Normalt efterfrågar en DAklient senast tillgängliga realtidsdata, men klienten kan också skicka data med tidstämpel. Tack vare OPC-standardens grundidé innebärande öppenhet, kan en DA-klient koppla sig mot DA-servrar från olika leverantörer. Till varje värde hör en tidstämpel och en tillförlitlighetsfaktor. Tidstämpeln är normalt konfigurerbar att sättas av OPC-servern eller av OPC-klienten. Om inte OPC-servern och OPC-klienten är konti- 30 Cirkeln i figuren ska inte ses som någon fysisk eller logisk enhet, utan mer som en abstraktion. 17

24 nuerligt synkroniserade med avseende på aktuell tid, kan denna konfigurering vara av stor vikt. Tillförlitlighetsfaktorn kan även den sättas av OPC-servern eller OPC-klienten. Den anger med ett procenttal, i vilken grad värdet kan anses tillförlitligt. När exempelvis ett värde befinner sig utanför gränsvärdena med vilken en fältgivare är definierad att leverera data, sätts tillförlitlighetsfaktorn till ett värde av noll. OPC DA specificerar endast COM gränssnitt inte implementation av klient eller server-objekt (inkl. grupper och poster). Genom användandet av COM, får man i OPC DA en klient-server arkitektur, där en OPC-server via ett gränssnitt levererar ett antal objekt (och dess metoder) för en OPC-klient. OPC DA specificerar två typer av gränssnitt: DA custom och DA Automation. En DA-server måste alltid understödja customgränssnittet medan stöd av Automation-gränssnittet är valfritt. Ett DA Automation-hölje 31 i servern kan hantera den utökade funktionalitet som krävs för dess funktion. Det kan här nämnas att OPC Foundation tillhandahåller ett sådant hölje. En C++-applikation kan använda sig av ett DA custom gränssnitt medan en Visual Basic applikation (eller andra liktydig, ex. Delphi), måste använda ett Automation-gränssnitt (se figur 11). Figur 11: C++ applikation och Visual Basic application. Kommunikationen mellan DA-servrar och datakällor sker ofta med något internt format av kommunikation specificerad av datakällans leverantör. DA-servern kan vara av typ in- process, lokal exe-fil eller på distans d.v.s. finnas på annan maskin än klientapplikationerna. DA custom-standarden definierar två grundläggande gränssnitt: OPCServer och OPCGroup. Varje DA server-objekt implementerar gränssnittet OPCServer och fungerar som en behållare 32 för ett eller flera DA grupp-objekt. DAservrar innehåller dessutom information om sig själva. 31 Wrapper 32 Container 18

25 En DA-server tillhandahåller medel för en DA-klient för att skapa och manipulera DA-grupper, som i sin tur tillhandahåller medel för att skapa och manipulera DA-poster. Enligt OPC DA-standarden ska ett minimum av definierade gränssnitt understöds av en server (se figur 12). Förutom gränssnitten kan utvecklaren av en DA-server konstruera ytterligare egna sådana. Figur 12: Standard OPC DA server objekt. Servern måste konstrueras med ett delmål att minimera resursbehov på datakällan. Ett sätt att möjliggöra detta är att buffra (eng. cache ) data så att det räcker med en läsning i datakällan om flera klienter efterfrågar samma data. Någon form av optimering som balanserar behov från klienter av aktuell data kontra last på datakällan måste då ske. Förutom att optimera dataåtkomst i datakällan, ska servern även medge att data skickas dit. En DA-server kan lagra egen konfigurering på disk med hjälp av COM:s IPersistFile gränssnitt. All konfigurering (inkl. lagring på disk) av DA-grupper och DA-poster måste dock hanteras av klienten. Ett DA grupp-objekt implementerar gränssnittet OPCGroup och fungerar som behållare för ett eller flera DA post-objekt (eng. items ). DA-servrar innehåller dessutom information om sig själva. Enligt OPC DA-standarden ska ett minimum av definierade gränssnitt understöds av en grupp (se figur 13). 19

26 Figur 13: Standard OPC DA-grupp objekt. En DA-post representerar en koppling till ett datavärde i servern. Till varje post hör datavärdet själv (i form av typen VARIANT), ett kvalitetsvärde och en tidstämpel. Åtkomst från en DA-klient av dessa värden kan inte ske direkt, utan måste hanteras via en DA-grupp. Det finns helt enkelt inga publika COM/OPC gränssnitt definierade för en DA-post. Det finns två olika sätt för en klient att begära data från en server: synkron och asynkron. Den synkrona begäran innebär att klienten inväntar svaret på anropet i form av data från servern, utan att däremellan kunna göra något annat. Normalt läses synkron data från buffert. Normalt begärs också synkron data periodiskt, vilket innebär att all data som skapats sedan föregående begäran från klient läses från buffert, oavsett om datan ändrat värde eller ej. Asynkron begäran däremot innebär att klienten inte kan förutse hur lång tid det tar innan data returneras, men är å andra sidan normalt snabbare än synkron begäran. Asynkron begäran av data innebär i princip en prenumeration av data, fram till dess att denna avslutas av klienten. När begäran om asynkron data inkommer till servern, kan data returneras direkt eller efter ett längre tag beroende på bland annat att data inte ändrar värde. Asynkron leverans av data implementeras genom gränssnittet IOPCDataCallback. Genom användande av olika parametrar kan bland annat dödband 33 och uppdateringshastighet definieras, varvid den totala mängden av överförd data kan kontrolleras och därigenom indirekt belastning på noder och nätverk. 33 Dödband specificerar (normalt i procent) andel av ett värdes mätområde som värdet måste ändra för att anses intressant för klienten. Ett värde vars ändring inte överskrider denna gräns skickas inte till klienten 20

27 Den synkrona läsningen kan användas när relativt små mängder av data skickas. För effektivt utnyttjande av maskin- och nätverksresurser rekommenderas den asynkrona läsningen. Tillsammans med standarden själv, levererar OPC Foundation IDLfiler och header-filer för felhantering. Dessutom finns standardfiler för mellanservrar 34, stubbar 35 och C header-filer som genereras vid kompilering av ovan nämnda IDL-fil, även att tillgå på OPC Foundations hemsida. Användning av IOPCItemIO gränssnittet understöds först i version 3.0 av OPC DA. Om asynkron data önskas, måste implementering av en OPC DA grupp göras för att en prenumeration av data ska initieras. Detta är det normala sättet för en OPC DA klient att efterfråga data i en server och har understötts i tidigare versioner Beskrivning av OPC HDA: History Data Access OPC HDA specificerar hur data kan utväxlas mellan en HDA-klient och HDA-server och den baserar sig på COM. Klienten är (som i de flesta klient/server-konfigureringar) den begärande parten och servern den tjänande parten. En HDA-klient begär normalt data inom en viss tidsperiod, d.v.s. historisk data kan efterfrågas. På samma sätt som fallet gäller för OPC DA, specificerar OPC HDA endast COM gränssnitt. Någon implementation av klient eller serverobjekt (inkl. grupper och poster), specificeras inte. Genom användandet av COM, erhåller man i OPC HDA en klient-server arkitektur, där en HDA-server via ett gränssnitt levererar ett antal objekt och dess metoder för en HDA-klient. Likheterna med OPC DA är fler. OPC HDA specificerar två typer av gränssnitt: HDA custom och HDA Automation. En HDA-server måste alltid understödja custom-gränssnittet medan understöd av Automation-gränssnittet är valfritt. Ett OPC Automation-hölje 36 i servern kan hantera den utökade funktionalitet som krävs för dess funktion. OPC Foundation tillhandahåller ett sådant hölje. En C++-applikation kan använda sig av ett HDA custom gränssnitt medan en Visual Basic applikation måste använda ett Automationgränssnitt. HDA-servern kan vara av typ In Process, lokal exe-fil eller på distans d.v.s. finnas på annan maskin än klientapplikationerna. 34 proxies 35 stubs 36 wrapper 21

28 3.2.4 Beskrivning av OPC AE: Alarm and Event OPC AE specificerar hur en klient kan tillhandahålla larm och andra händelser från en server och baserar sig på COM. Specifikationen kompletterar, men är samtidigt separat från OPC DA specifikationen. Standarden specificerar i detalj de gränssnitt som kan användas vid implementation av OPC-DA klienter resp. OPC-DA servrar och hur dessa ska tillämpas. Standarden beskrivs inte ytterligare i denna rapport Beskrivning av OPC XMLDA: XML Data Access Den standard som här beskrivs avser 1.0. I motsats till övriga standarder som föregick UA, baseras inte XMLDA på COM. Istället beskriver den hur data kan utväxlas genom användning av XML och SOAP. Förutom skillnader i underliggande teknisk plattform, kan XMLDA ses som en utvidgning av DA 3.0 specifikationen. Den bygger på SOAP 1.1 och är utformad så att den tillåter strukturerad information att överföras i ett SOAP-meddelande. XML-DA servrar kan skapas som en självständig enhet, alternativt konstrueras för att fungera som ett lager utanpå en COM-baserad 2.0 eller 3.0 DA server. Standarden har inte någon mekanism som lokaliserar noder med OPC XML-DA servrar. På samma sätt som OPC DA specificerar en mekanism som möjliggör att en klient kan prenumerera på data från en server, definierar även OPC XML-DA en sådan mekanism. För den senare består prenumerationen av att klienten initierar en sådan, varefter den periodiskt frågar servern om nya data. I grundutförande definierar XML-DA följande tjänster för att hantera en dataprenumeration: Subscribe, SubscriptionPolledRefresh och SubscriptionCancel. Klientapplikationen initierar en prenumeration på data hos servern, varvid servern returnerar en prenumerationsreferens 37 till svar. Är flaggan ReturnValuesOnReply satt returneras dessutom samtidigt efterfrågade värden (värde, kvalitet och tidstämpel). Därefter skickar klienten periodiskt förfrågan om nya data genom anrop till SubscriptionPolledRefresh genom den initialt tillhandahållna prenumerationsreferensen. Servern ska då omedelbart svara genom att returnera all data som insamlats sedan sista förfrågan. Detta fortgår sedan fram till att klienten önskar upphöra prenumerationen, varvid den skickar en SubscriptionCancel. Klientapplikationen måste kunna hantera felkoder från servern. Skulle begäran om prenumeration returneras med en felkod som indikerar att felet försvinner inom viss tid, begär lämpligtvis klienten återigen en 37 handle 22

29 prenumeration (en eller flera gånger). Skulle å andra sidan felkoden indikera en annan typ av fel, måste klientapplikationen hantera detta på lämpligt sätt. Detta inkluderar även vid fall där upprättad prenumeration avbryts oplanerat. För att möjliggöra för en OPC-DA server att optimera dess hantering av en prenumerationsförfrågan från en klient, finns de två prenumerationsparametrarna Holdtime och Waittime att tillgå. Genom att använda dessa, kan klienten delegera till servern att hantera väntan mellan varje förfrågan av data. OPC XML-DA definierar på samma sätt som för OPC DA att en tidstämpel och ett tillförlitlighetsvärde hör ihop med varje datavärde (processvärde). På liknande sätt definierar OPC XML-DA att data kan hämtas direkt från datakällan 38 eller från en buffert 39. När klienten gör ett första anrop med begäran om att påbörja en prenumeration, kan klienten samtidigt ange vissa parametrar indikerande vissa önskemål som exempelvis önskad samplingshastighet, huruvida buffring av data önskas och önskad dödband. Det är sedan upp till servern att försöka leva upp till önskemålen, utan att stabil driftkondition överskrids, t.ex. med avseende på belastning. Samplingshastighet anger önskad maximal tid mellan insamlade värden d.v.s. hur ofta servern ska fråga datakällan efter ny data (för att lagra dessa värden i buffert se nedan). Servern har som ovan nämnts möjlighet att buffra upp data. En fördel med detta är att om två eller fler klienter efterfrågar samma data, behöver servern bara efterfråga data från datakällan en gång. När data sedan skickas till de olika klienterna, kan den hämtas från bufferten, utan att upprepade gånger gå ut och läsa från datakällan. Detta förfarande kan, beroende på serverimplementation tillsammans med hur datakällan är konstruerad, minimera belastning på underliggande nätverk och noder. Är buffring inte begärd, skickas enbart senaste värdet vid nästkommande anrop. Om buffring önskas, lagrar servern alla värden den läser i datakällan sedan sista anrop av SubscriptionPolledRefresh, och skickar alla dessa värden vid nästkommande anrop. Ett värde vars ändring inte överskrider gränsen för dödband, sparas inte i bufferten och skickas således inte till klienten vid nästa anrop av SubscriptionPolledRefresh. Tidstämpeln indikerar tidpunkten när värdet erhölls från datakällan, eller tidpunkten när servern uppdaterade eller validerade värdet och tillförlitlighetsvärdet i bufferten. OPC XML-DA specificerar ett antal standard returkoder (för att indikera lyckad utgång eller fel). Dessa kvalificeras alltid med namn- 38 device 39 cache 23

30 rymden Utöver detta kan egna returkoder skapas, då med en egen namnrymd (exempelvis ). När en klientbegäran fallerar totalt (då exempelvis servern inte är konfigurerad korrekt), måste servern returnera ett SOAP-fel, definierat genom SOAP-specifikationen. Om det däremot är ett fel med ett efterfrågat värde (men servern fungerar i övrigt och andra värden kan skickas utan fel), definierar OPC XML-DA en mekanism som påminner om SOAP-fel. XML-DA definierar bas-mallar (eng. schemas ) som återfinns i andra mallar och som beskriver meddelanden som överförs. XML-DA mallar baseras på hierarkisk struktur av information. I tillägg kan information specificeras genom s.k. attribut. Som första mall, beskriver XML-DA RequestList (se figur 14 för exempel). Denna inkluderar attribut som används vid läs, skriv och prenumerationsförfrågan från klienten. <s:complextype name="requestlist"> <s:attribute name="itempath" type="s:string" /> <s:attribute name="reqtype" type="s:qname" /> </s:complextype> Figur 14: Exempel på RequestList. En annan mall som beskrivs är ItemValue. Denna är en behållare som transporterar datavärden (se figur 15 för exempel). <s:complextype name="itemvalue"> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="diagnosticinfo" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="value" /> <s:element minoccurs="0" maxoccurs="1" name="quality" type="s0:opcquality" /> </s:sequence> <s:attribute name="valuetypequalifier" type="s:qname" use="optional" /> <s:attribute name="itempath" type="s:string" /> <s:attribute name="itemname" type="s:string" /> <s:attribute name="itempath" type="s:string" />... Figur 15: Exempel på ItemValue. 24

31 3.2.6 Beskrivning av OPC Batch OPC Batch specificerar hur data kan utväxlas mellan en Batch-klient och batch-server och baseras på COM. En OPC Batch server måste understödja alla gränssnitt givna i OPC DA 2.0 specifikationen, och därtill måste ytterligare ett antal gränssnitt stödjas. OPC Batch specificerar hur en klient kan tillhandahålla diverse värden, intressanta för processindustrier som hanterar satsvis produktion. Datautväxling är avsedd att utväxlas med framför allt fyra typer av information: utrustningskapacitet, pågående driftstatus, historisk data och receptdata. Standarden specificerar i detalj de gränssnitt som kan användas vid implementation av OPC Batch klienter resp. OPC Batch servrar och hur dessa ska tillämpas. Standarden beskrivs inte ytterligare i detta dokument Beskrivning av OPC Security Varje OPC server (DA, AE, HDA, etc.) som implementerar OPC Security måste implementera något av, eller båda gränssnitten IOPCSecurityNT respektive IOPCSecurityPrivate. Implementering av dessa ger tillgång till såväl autentisering som bemyndigande av klient att komma åt data på servern. En klient ska dock inte förutsätta att dessa gränssnitt existerar, utan måste snarare förutsätta motsatsen. Först när en klient erhåller en pekare när något av gränssnitten efterfrågats (via QueryInterface) kan klienten förutsätta att OPC Security är implementerat på servern. Standarden specificerar i detalj gränssnitten IOPCSecurityNT respektive IOPCSecurityPrivate när OPC Security ska implementeras på servrar. Standarden beskrivs inte ytterligare i detta dokument Beskrivning av OPC DX: Data exchange Medan de flesta andra OPC standarder anger hur en klient ska få tillgång till data från en server, specificerar OPC DX hur data kan utväxlas mellan två eller fler OPC DA servrar. En DX-server definieras som en OPC DA server med viss ytterligare funktionalitet. Standarden anger medel för överföring av data som inte är tidskritisk, från en OPC DA eller OPC DX server till en OPC DX server. Vidare specificerar standarden i detalj de tillägg till OPC DA som används vid implementation av OPC DX servrar och hur dessa ska tillämpas. Standarden beskrivs inte ytterligare i detta dokument. 25

32 3.2.9 Beskrivning av OPC CX: Complex Data OPC CX specificerar hur data av mer komplex karaktär kan utväxlas inom det existerande OPC DA ramverket. OPC DA specifikationen fordrar att klienters och servrars dataposter 40, med vilka data utväxlas, ska vara av enkla datatyper eller vektorer med enkla datatyper. Som namnet antyder möjliggör OPC CX-standarden användning av mer komplexa datatyper. OPC CX specificerar i detalj de tillägg till OPC DA som används vid implementation av OPC CX och hur dessa ska tillämpas. Standarden beskrivs inte ytterligare i detta dokument Beskrivning av OPC Commands OPC Commands är utvecklad för att skicka metodanrop till olika typer av enheter inom processindustrin, som exempelvis en styrenhet, en robot, ett fordon eller liknande. Standarden specificerar hur en klient kan få reda på vilka metoder som en server tillhandahåller och hur klienten därefter anropar dessa. Dessutom specificerar den hur metoderna implementeras på servern. Standarden beskrivs inte ytterligare i detta dokument. 40 items 26

33 Beskrivning av OPC UA Här beskrivs den senaste generationen av OPC-standard Generell beskrivning Under 2005 offentliggjorde och släppte OPC Foundation en arkitektur eller standard vid namn Unified Architecture. Denna har allteftersom kompletterats. De dokument som släppts är följande ( ): OPC UA part 1 Overview and Concepts RC Specification OPC UA Part 2 Security Model RC Specification OPC UA Part 3 Address Space Model RC Specification OPC UA Part 4 Services RC Specification OPC UA Part 5 Information Model RC Specification OPC UA Part 6 Mappings RC Specification OPC UA Part 7 Profiles RC Specification OPC UA Part 8 Data Access RC Specification OPC UA Part 9 Alarms Draft v0.62 OPC UA Part 10 Programs 1.00 Specification OPC UA Part 11 Historical Access 1.00 Specification Avsikten med denna standard var att ersätta alla befintliga delstandarder baserade på COM. OPC XML-DA ersätts då också. Införandet av UA har inte bara skapat en ny plattform för att ersätta befintliga applikationer (DA, HDA,...), utan istället har hela strukturen som möjliggör systemintegrationer med ett större omfång av data och dess typer, byggts om från grunden. OPC UA är en plattformsoberoende standard som möjliggör utväxling av data mellan olika system och enheter. Den är i grunden baserad på vad som populärt betecknas för Web Services en samling olika funktionaliteter som bygger på datautbyte via webbgränssnittet. Därtill är ett mer binärt format definierat, vilket möjliggör en mer resurseffektiv hantering till priset av man frångår öppna och standardiserade specifikationer. I och med introduktionen av OPC UA frikopplas således OPC från sitt beroende av en underliggande standard som i hög grad styrs av en enskild leverantör. Den föregående generationen av OPC-standarder var till stor del baserade på Microsofts COM/DCOM-standard. Grundtanken med OPC är som nämnts att utväxla produktionsdata mellan olika styrsystem inom processindustrin, men med UA fortsätter utvecklingen mot en mer generell arkitektur som möjliggör utväxling av data även uppåt från produktionssystem nära fabriksprocesserna till system av mer överordnad och administrativ karaktär (figur 16). 27

34 Figur 16: UA-servrar och klienter på olika nivåer på en fabrik [4] Utförligare beskrivning Grunden för utväxling av data när UA används är meddelanden. Detta är en konsekvens av att UA i stora drag baseras på Web Services, i vilket standarder som XML, WSDL och SOAP är grundpelare. Till detta kommer WS-standarder, såsom WS-Policy och WS-Eventing. Förutom att specificera hur olika meddelanden ska se ut, definierar UA ett antal olika tjänster 41 som en server kan tillhandahålla UA Server- och klientstruktur En UA server tillhandahåller minst en tjänst, men kan innehålla flera. I motsats till vad som gäller inom COM, måste en UA server vara i drift innan en klient anropar serverns tjänster. Varje tjänst ansluts via en s.k. ändpunkt ( Endpoint ), vilken utgörs av fysisk adress som klienten anger. När sådan ändpunkt ansluts, måste såväl transportprotokoll som serverns nodnamn och sökväg anges. Om det anslutande portnumret frångår standard, måste naturligtvis även en sådan anges. Följande portnummer har blivit tilldelade av IANA: UA-TCP: 4840 UA-SSL: 4843 De tjänster som är specificerade enligt OPC UA finns definierade i WSDL-dokument vilka finns tillgängliga i UA SDK (levereras av OPC Foundation). Dessa är avsedda att användas av utvecklare av UA klient- och server-programvara vilken kan ses som motsvarigheten till IDL i COM-miljön. Tjänsterna är grupperade i s.k. Service sets i specifikationerna. Dessa är i första hand avsedda att underlätta beskrivning i 41 Services, Service Sets 28

35 specifikationerna och knappast av värde vid implementation av serverprogramvara. De service sets som är definierade i UA Specification Part 4 är: Service Set Discovery SecureChannel Session NodeManagement View Query Attribute Method MonitoredItem Beskrivning Tjänster som kan anropas för att få angivet samtliga ändpunkter och dessas krav på säkerhet på refererad server. Tjänster som används för att öppna en kommunikationskanal på godtaget sätt sett ur säkerhetsperspektiv. Tjänster för att etablera kopplingar på applikationsnivå inom ramen för sessioner. Tjänster för att administrera UA objektnoder inom dess adressrymd Tjänster för att navigera bland UA objektnoder inom adressrymd eller för att navigera inom en vy Åtkomst av UA objektsnoders data. Åtkomst av UA objektsnoders attribut. Funktionsanrop av UA objekt. Prenumeration av data och händelser. Tjänsterna som kategoriseras i Discovery Service Set kan placeras såväl tillsammans med övriga tjänster i samma server som i en dedikerad Discovery Server -nod UA objektmodell En grundläggande funktionalitet som eftersträvas med UA är att förmedla data, huvudsakligen processdata. För att hantera detta används en objektmodell ( OPC UA Object Model ) som består av noder vilka återfinns i en adressrymd. Denna rymd är strukturerad som en hierarki, där de högsta nivåerna är standardiserade att se likadana ut på alla servrar. Varje enhet i en fabrik kan representeras av en nod i adressrymden. Detta avser inte minst mätande enheter (transmittrar), vilka samlar in och skickar processdata vidare. Även noder för icke datainsamlade enheter kan representeras, för att strukturera noderna i adressrymden så att de i någon mån återspeglar verkligheten. Ett enkelt exempel på hur verkligheten skulle kunna representeras i adressrymden ges i figur 17 nedan. 29

36 Figur 17: Verkligheten representerad i UA:s objektmodell. I specifikationerna för UA återfinns några grundbegrepp avseende objektmodellen: nod nodklass objekt objekttyp variabel attribut egenskap referens metod datatyp metoder händelser (eng. node ) (eng. node Class ) (eng. object ) (eng. object Type ) (eng. variable ) (eng. attribute ) (eng. property ) (eng. reference ) (eng. method ) (eng. data Type ) (eng. methods ) (eng. events ) En nod, som är en grundläggande entitet, kan vara ett objekt som representerar en enhet i verkliga livet eller mjukvaruvärlden. Alternativt kan en nod också skapas enbart för att representera ett värde. Noderna i adressrymden kan vara instansierade utgående från olika nodklasser, beroende på dess olika representation. Som grund för alla dessa klasser finns en Base NodeClass. Utifrån denna är sedan ett antal andra nodklasser definierade. Någon av dessa nodklasser används sedan när noder instansieras. Varje nod kan innehålla såväl attribut, egenskaper som referenser till andra noder, där attribut är dataelement som beskriver noden identitet är exempelvis en sådan som återfinns i alla noder. Egenskaper är server-definierade dataelement där nodversion är ett exempel. 30

37 En nod som symboliserar en fysisk enhet i riktiga världen består normalt av flera noder av olika typer av noder i en hierarkis struktur. I figur 18 ser vi ett exempel där processvärde och mätområde hörande till flödestransmitter FT-019 är lagrade i två noder instansierade från en Variable NodeClass. Figur 18: Värden lagras i separata noder. Specifikationen sätter inga hinder att vid implementation av server, spara värden som attribut istället för som i exemplet ovan i externa noder. Det finns även möjligheter att använda vyer. Med dessa kan valfria delar av adressrymden presenteras för klienter. En vy kan konfigureras så att vissa mellanliggande noder i den ordinarie strukturen inte syns. En grundtanke med att använda vyer är att begränsa det omfång av adressrymden som görs tillgängligt för klienter. Som utgångsläge kan hela adressrymden ses som en stor vy. När ett stort antal noder med tillhörande undernoder önskas definieras för att motsvara motsvarande enheter i verkligheten, kan en form av mallar eller typdefinitioner skapas. Dessa typdefinitioner används för att skapa önskat antal kopior och namnge dessa lämpliga namn som motsvarar verkligheten (ett exempel ges i figur 19). Det är i detta sammanhang som nodklasser av objekttyp och datatyp kommer till användning. Figur 19: Typdefinitioner kan användas. 31

38 Metoder definierar anropbara funktioner och anropar genom Call Service -tjänsten. De definieras i noder och en specifik nodklass används när sådan metodnod ska instansieras. Noder kan tillåta att klienter prenumererar på händelser beroende på hur noderna är konfigurerade, exempelvis när ett värde som tillhör en nod når en viss nivå. För händelseprenumeration används tjänsten Monitoring and Subscription. En server som stödjer händelsehantering måste ha minst en nod som är definierad som händelseaviserare UA kommunikationsstack UA definierar en egen kommunikationsstack (figur 20) i det applikationslager som återfinns i OSI:s och TCP/IP:s referensmodell. Denna kommunikationsstack innehåller tre lager: meddelande-, säkerhets- och kodningslager. Ovanpå denna kommunikationsstack återfinns dessutom UA applikationslager. Detta kan även uttryckas som att transportlagret i UA:s kommunikationsstack är inte densamma som det i OSI:s och TCP/IP:s referensmodeller och dessutom är UA:s applikationslager inte detsamma som applikationslagret i de senare nämnda referensmodellerna. Det förstnämnda ingår däremot i det sistnämnda. Figur 20: UA kommunikationsstack. Lagret för meddelandekodning används för att omforma meddelanden, sådant att dessa kan skickas via ett nätverk. Här sker enligt UA-standarden, en meddelandekodning antingen enligt ett format kallat UA XML alternativt UA Binary. XML-syntax används för att strukturera data i båda fallen, men i det förra fallet kodas data genom läsbara textsträngar medan data i det senare fallet kodas som binära dataströmmar. UA XML-kodning baseras på ett specifikt XML-Schema format utgivet av OPC Foundation. Detta XML-Schema återfinns på OPC Foundations hemsidor Event Notifier