Examensarbete i datalogi vid Stockholms universitet 2009

Analys av OLE för processkontroll

Lars Öman

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-1653-5715 Institutionen för numerisk analys och datalogi KTH 100 44 Stockholm

Referat

OPC

är en standard som skapats för överföring av processdata och

andra data mellan olika datorsystem inom olika typer av processindu-

strier. 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.

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, per-

formance, 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.

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.

Innehåll

1 Inledning ........................................................................................ 1

1.1 Bakgrund .............................................................................. 1 1.2 Syfte och problemformulering ............................................. 1 1.3 Metod ................................................................................... 2 1.4 Avgränsningar ...................................................................... 2

2 Genomgång av COM/DCOM-standarden ..................................... 3

2.1 Översikt ................................................................................ 3 2.2 Orsak till varför COM utvecklades ...................................... 4

2.3 Vad är COM? ....................................................................... 4 2.4 Grundläggande krav som COM måste uppfylla .................. 7

2.5 Beskrivning hur COM-objekt används ................................ 7 2.6 Hur klient kommunicerar med COM-objekt ..................... 10 2.7 Beskrivning av hur COM-objekt definieras ....................... 12 2.8 Allmän beskrivning av COM+ .......................................... 13

3 OPC-standarden .......................................................................... 14

3.1 Historik .............................................................................. 14 3.2 Beskrivning OPC (COM-baserad) ..................................... 16

3.2.1 Generell beskrivning ............................................... 16 3.2.2 Beskrivning av OPC DA: Data Access ................... 17

3.2.3 Beskrivning av OPC HDA: History Data Access ... 21 3.2.4 Beskrivning av OPC AE: Alarm and Event............. 22

3.2.5 Beskrivning av OPC XMLDA: XML Data Access . 22 3.2.6 Beskrivning av OPC Batch...................................... 25

3.2.7 Beskrivning av OPC Security.................................. 25 3.2.8 Beskrivning av OPC DX: Data eXchange .............. 25 3.2.9 Beskrivning av OPC CX: Complex Data ................ 26

3.2.10 Beskrivning av OPC Commands ............................ 26 3.3 Beskrivning av OPC UA ................................................. 27

3.3.1 Generell beskrivning ............................................... 27

3.3.2 Utförligare beskrivning ........................................... 28

4 Analys och resultat ...................................................................... 38

4.1 Jämförelse mellan OPC-DCOM och OPC UA .................. 38 4.1.1 Applicerbarhet ......................................................... 38 4.1.2 Prestanda ................................................................. 39

4.1.3 Standarder ................................................................ 40 4.1.4 Säkerhet ................................................................... 40

4.1.5 Tillförlitlighet .......................................................... 41 4.1.6 Tillgänglighet .......................................................... 41

4.2 Generell utvärdering .......................................................... 42 4.3 Utveckling och framtid för OPC ........................................ 45

Källförteckning ................................................................................... 48

1

1 Inledning

Detta kapitel handlar om examensarbetets bakgrund, syfte och av-

gränsningar.

1.1 Bakgrund

OPC1 är en standard som skapats för överföring av processdata och

andra data mellan olika datorsystem inom olika typer av process-

industrier. 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. An-

vändningen av standarden har under årens lopp spridit sig även utan-

för processindustrin, bland annat återfinns standarden för kommunika-

tion mellan styrenheter för styrning av värme och ventilation av fastig-

heter.

1.2 Syfte och problemformulering

Syftet med detta arbete har varit att analysera underliggande tek-

nologier 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, in-

klusive vissa av de mest använda delstandarderna.

När denna rapport påbörjades 2005, var OPC UA2 ä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

2

Arbetet avbröts för att återupptas under 2008. Under denna tid hade

OPC UA utvecklats markant genom att en mängd dokument som be-

skriver UA hade släppts. Det uppstod därmed ett intresse av att inklu-

dera 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 sen-

are 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 DA3 bland de COM-baserade standarderna. Övriga COM-base-

rade 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

3

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.

ActiveX4 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-stan-

darden inte längre återfinns på Microsofts hemsidor. Detta innebär inte

att COM inte har haft någon betydelse inom mjukvaruindustrin. Sna-

rare ä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.

1992 Windows 3.1 släpps med OLE 1.0 integrerat.

1993 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.

1996 DCOM släpps.

1997 Microsoft börjar använda COM som eget begrepp.

1999 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 tillhan-

dahå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

4

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 ur-

sprungliga 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 klient-

applikation 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 grund-

lä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 kompila-

torer 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 (seri-

alisering) föreligga.

2.3 Vad är COM?

COM-standarden definierar endast hur de olika gränssnitten till COM-

objekten 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 (COM-

klass) 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.

5

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:s6 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å Mi-

crosoft 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 OLE8-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 Mic-

rosoft 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 an-

dra programmerare utan att dessa behövde tillgång till objektets käll-

kod 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 kompila-

torer av olika fabrikat ofta drabbades av problem när de skulle an-

vändas tillsammans. Som nummer fyra på listan fanns problemet att

en ändring av ett enskilt objekt i en större applikation medförde om-

kompilering 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 kommuni-

cera med ett objekt. Implementationer är konkreta datatyper som un-

derstöder ett eller flera gränssnitt. Klasser slutligen är namngivna im-

plementationer som representerar instansierbara objekt och kallas för

COM-klasser (på engelska ”coclasses”).

6 Object Management Group www.omg.org

7 Common Object Request Broker Architecture

8 Object Linking and Embedding

6

En COM-klass är implementerad i en server. En server kan imple-

menteras 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 DCOM9.

En DLL10

-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. RPC11

). 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

7

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:er12

som är 128

bitar långa tal. Dessa baseras på UUID:er13

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:er14

. Handlar det istället om COM implementationer (COM-

klasser) betecknas deras identitet med klassidentitet eller CLSID:er15

.

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 CATID16

. 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”

8

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 .exe-

implementerad 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 COM-

grä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 funk-

tioner, 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.

9

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 COM-

objekt 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.

10

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 COM-

servern (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 under-

stödjer COM måste ha såväl ett COM-bibliotek som en SCM.

klient

COM

bibliotek

objekt

server

system

registry

5. klienten kan anropa funktioner

i gränssnittet

4. pekare till gränssnitt returneras via

COM-biblioteket

1. klienten anropar COM-biblioteket

2. COM lokaliserar server

3. COM instansierar server

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 efter-

frågade gränssnittet IDataTrans.

11

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 klass-

fabriker18

. 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 klass-

objekt 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 DLL-

hantering 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 mellanservrar19

och stubbar20

. 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

12

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 ORPC21

som i sin tur

använder MS-RPC22

.

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-fil23

.

COM:s IDL definition, MIDL24

, bygger på OSF:s25

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 beteck-

ningen MIDL, medan Microsofts IDL-specifikation benämns COM

IDL.

En definition av ett gränssnitt i IDL (åskådliggjort i figur 8) måste in-

ledas med begreppet ”interface”. Denna föregås av attribut som är an-

givna 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

13

[

local,

object,

uuid(00000000-0000-0000-C000-000000000046)

]

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

serialisering26

)

typbibliotek27

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. Typ-

biblioteket ä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, MTS28

. 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

14

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 bas-

erade 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 om-

vä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örs-

händelser, informationsmeddelanden och spårnings-/loggningsmed-

delanden.

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,

www.opcfoundation.org

15

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 över-

vakning/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 ident-

ifierar, 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.

2002 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

16

3.2 Beskrivning OPC (COM-baserad)

Här beskrivs de första generationernas OPC-standarder som föregick

OPC-UA.

3.2.1 Generell beskrivning

På olika fabriker fanns (och finns i växande grad) ett stort antal data-

system. Dessa omfattar hela omfånget från processnära styrsystem

(DCS), via informationssystem och vidare till fabriks- och koncern-

visa 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 10.

17

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.

3.2.2 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 DA-

klient senast tillgängliga realtidsdata, men klienten kan också skicka

data med tidstämpel. Tack vare OPC-standardens grundidé inne-

bä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.

18

nuerligt synkroniserade med avseende på aktuell tid, kan denna kon-

figurering 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änd-

andet 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 custom-

gränssnittet medan stöd av Automation-gränssnittet är valfritt. Ett DA

Automation-hölje31

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ållare32

för ett eller flera DA grupp-objekt. DA-

servrar innehåller dessutom information om sig själva.

31

Wrapper 32

Container

19

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).

20

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 in-

väntar svaret på anropet i form av data från servern, utan att däre-

mellan 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ödband33

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

21

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 IDL-

filer och header-filer för felhantering. Dessutom finns standardfiler för

mellanservrar34

, stubbar35

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.

3.2.3 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 server-

objekt (inkl. grupper och poster), specificeras inte. Genom använ-

dandet 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ölje36

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 Automation-

gränssnitt. HDA-servern kan vara av typ ”In Process”, lokal exe-fil

eller på distans d.v.s. finnas på annan maskin än klient-

applikationerna.

34

proxies 35

stubs 36

wrapper

22

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.

3.2.5 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 prenumerationsreferens37

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

23

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 prenu-

meration 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å prenu-

merationsparametrarna ”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 tid-

stä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ällan38

eller från en buffert39

. 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äst-

kommande 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 indi-

kera lyckad utgång eller fel). Dessa kvalificeras alltid med namn-

38

device 39

cache

24

rymden ”http://opcfoundation.org/webservices/XMLDA1.0/1.0/”.

Utöver detta kan egna returkoder skapas, då med en egen namnrymd

(exempelvis ”http://bolag.com/etc”).

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 efter-

frå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.

25

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 prod-

uktion. Datautväxling är avsedd att utväxlas med framför allt fyra

typer av information: utrustningskapacitet, pågående driftstatus, hist-

orisk 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.

3.2.7 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.

3.2.8 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 ut-

vä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 speci-

ficerar 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.

26

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 dataposter40

, 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.

3.2.10 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

27

Beskrivning av OPC UA

Här beskrivs den senaste generationen av OPC-standard.

3.3.1 Generell beskrivning

Under 2005 offentliggjorde och släppte OPC Foundation en arkitektur

eller standard vid namn ”Unified Architecture”. Denna har alltefter-

som kompletterats.

De dokument som släppts är följande (2008.10.01):

OPC UA part 1 – Overview and Concepts RC 1.01.03 Specification

OPC UA Part 2 – Security Model RC 1.01.52 Specification

OPC UA Part 3 – Address Space Model RC1.01.13 Specification

OPC UA Part 4 – Services RC 1.01.30 Specification

OPC UA Part 5 – Information Model RC 1.01.13 Specification

OPC UA Part 6 – Mappings RC 1.00.08 Specification

OPC UA Part 7 – Profiles RC 1.00.00 Specification

OPC UA Part 8 – Data Access RC 1.01.10 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 del-

standarder 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 struk-

turen 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).

28

Figur 16: UA-servrar och klienter på olika nivåer på en fabrik [4].

3.3.2 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änster41

som en server kan tillhandahålla.

3.3.2.1 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

29

specifikationerna och knappast av värde vid implementation av server-

programvara.

De service sets som är definierade i ”UA Specification Part 4” är:

Service Set Beskrivning

Discovery Tjänster som kan anropas för att få angivet

samtliga ändpunkter och dessas krav på

säkerhet på refererad server.

SecureChannel Tjänster som används för att öppna en

kommunikationskanal på godtaget sätt sett

ur säkerhetsperspektiv.

Session Tjänster för att etablera kopplingar på

applikationsnivå inom ramen för sessioner.

NodeManagement Tjänster för att administrera UA

objektnoder inom dess adressrymd

View Tjänster för att navigera bland UA

objektnoder inom adressrymd eller för att

navigera inom en vy

Query Åtkomst av UA objektsnoders data.

Attribute Åtkomst av UA objektsnoders attribut.

Method Funktionsanrop av UA objekt.

MonitoredItem 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 dedi-

kerad ”Discovery Server”-nod.

3.3.2.2 UA objektmodell

En grundläggande funktionalitet som eftersträvas med UA är att för-

medla 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.

30

Figur 17: Verkligheten representerad i UA:s objektmodell.

I specifikationerna för UA återfinns några grundbegrepp avseende

objektmodellen:

nod (eng. ”node”)

nodklass (eng. ”node Class”)

objekt (eng. ”object”)

objekttyp (eng. ”object Type”)

variabel (eng. ”variable”)

attribut (eng. ”attribute”)

egenskap (eng. ”property”)

referens (eng. ”reference”)

metod (eng. ”method”)

datatyp (eng. ”data Type”)

metoder (eng. ”methods”)

händelser (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.

31

En nod som symboliserar en fysisk enhet i riktiga världen består nor-

malt 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.

32

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ändelse-

hantering måste ha minst en nod som är definierad som händelse-

aviserare42

.

3.3.2.3 UA kommunikationsstack

UA definierar en egen kommunikationsstack (figur 20) i det app-

likationslager 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 sist-

nä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-stan-

darden, 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 ut-

givet av OPC Foundation. Detta XML-Schema återfinns på OPC

Foundations hemsidor.43

42

Event Notifier 43

http://www.opcfoundation.org/UAPart6/Types.xsd

33

”UA Binary”-kodning är en binär version av WS-Secure och medger

säker kommunikation för UA där varken SOAP eller XML används.

Specifikationen för ”UA Binary”-kodning återfinns även den, enligt

”OPC UA Part 6 – Mappings RC 1.00.08 Specification” på OPC

Foundations webbsidor.44

UA Binary-kodning ger ett binärt meddelandeformat som är avsett att

kräva mindre utrymme och kapacitetskrav jämför med meddelanden i

UA XML-format. Detta till priset av att använda en specifikation som

inte är allmänt känd utan istället definierad av OPC Foundation.

I säkerhetslagret återfinns funktionaliteter som tillförsäkrar att

meddelanden kan utväxlas utan att förvanskas eller obehörigen

avlyssnas. Detta sker genom kryptering där två olika algoritmer kan

användas; ”WS Secure Conversation” eller ”UA Secure

Conversation”. Den förstnämnda är baserad på WS-Security, vilken är

en öppen standard som beskriver hur signaturer och kryptering

appliceras på SOAP-meddelanden. För närvarande används version

1.1. I denna ingår delstandarder WS-Trust, WS-Addressing, XML

Signature och ”XML Encryption. Den sistnämnda, ”UA Secure

Conversation”, är en binär version av ”WS Secure Conversation”.

Transportlaget i UA:s kommunikationsstack hanterar slutligen komm-

unikation mot underliggande strukturer – återigen normalt transport-

lagret i en OSI- eller TCP/IP-stack.

Det finns två olika strukturer att använda sig av i UA:s transportlager:

SOAP/HTTP

UA TCP

Det är svårt att uppskatta resursbehov (framför allt på nätverk) relativt

de två transportlagren, då det inte getts möjlighet att testa dylikt, och

material rörande test dessutom inte återfunnits i öppna media. Man

kan dock anta att ”UA TCP” genom sitt binära format inte är mer

resurskrävande än SOAP/HTTP, utan med stor säkerhet istället

mindre.

De ovan angivna alternativen i de olika UA-lagren kan sedan

kombineras ihop på följande tre olika sätt (se figur 21):

”XML Web Services”

”UA Native Binary”

”UA Native Binary” med SOAP

44

http://www.opcfoundation.org/UAPart6/2008/02/Types.bsd.xml

34

Figur 21: UA kommunikationsstack [1] .

Det fösta alternativet, ”XML Web Services” använder

SOAP/HTTP/HTTPS tillsammans med ”WS Security” för att kommu-

nicera UA-meddelanden. Som figuren visar, kan såväl ”UA XML”-

kodning som ”UA Binary”-kodning användas för ”XML Web

Services”. Skulle istället SOAP/HTTP/HTTPS användas tillsammans

med ”UA Security” och ”UA Binary”, kategoriseras detta som ”UA

Native Binary” med SOAP. Ersätter man slutligen

SOAP/HTTP/HTTPS med ”UA TCP” istället, når man ”UA Native

Binary”.

Dessa tre olika alternativ ingår i olika s.k. profiler, där en profil speci-

ficerar de krav som en tjänst uppfyller. I en profil ingår då bland annat

vilken variant av UA-stack som används.

3.3.2.4 UA Meddelandestruktur

Grunden i kommunikation mellan en UA-klient och en UA-server är

utväxling av meddelanden. Klienten skickar en förfrågan på vilken

servern skickar ett svar. Servern är uppbyggd av ett antal tjänster där

typ av förfrågan avgör vilken tjänst som svarar.

För att tillförsäkra en hög tillförlitlighet av kommunikation, ingår

vissa specifika funktionaliteter. När en kommunikation mellan en

klient och en server ska uppnås, måste först en ”secure channel” upp-

rättas mellan de två enheternas UA-stackar (kommunikationslager i

figur 22 nedan). Därefter upprättas en session på applikationsnivå.

35

Figur 22: Sessioner och ”secure channels”.

Först efter det att en session är upprättad, kan en klient anropa en

tjänst på servern. En session är fortfarande öppen såtillvida att den kan

återuppkopplas om den ”secure channel”-koppling som sessionen

använder, fallerar. Innan sessionen återuppkopplas, måste naturligtvis

en ”secure channel” först återskapas. Skulle det sistnämnda inte

inträffa inom sessionens definierade livslängd, faller även sessionen.

Det finns några få tjänster som ingår i ”Discovery Service Set” som

inte kräver att en underliggande ”secure channel” finns upprättad

innan anrop från klient görs. En av dessa är ”FindServers”-tjänsten.

Ett upprättande av en kommunikation mellan en UA-klient och en

UA-server kan typiskt se ut enligt följande:

en klient anropar ”FindServers”-tjänsten på en känd

”Discovery Server”. Till svar får klienten en

”ServerDescription” som anger ändpunkter till lämpliga

servrar.

klienten anropar ”GetEndpoints”-tjänsten på den server med

vilken klienten önskar kontakt. Till svar får klienten en

”EndpointDescription” som anger ändpunkter till tillgängliga

tjänster på servern. Dessutom erhåller klienten all annan konfi-

guration som är nödvändig för att upprätta kontakt med önskad

tjänst på servern.

klienten anropar ”OpenSecureChannel”-tjänsten för att skapa

en säker kommunikationskanal. Detta anrop sker enbart på

UA-stacknivå, d.v.s. ingen tjänst på UA-applikationsnivå är

inblandad.

klienten anropar därefter ”CreateSession”- och

”ActivateSession”-tjänsterna (användande den säkra kanalen).

om klienten är ett interaktivt MMI kan ”Browse”-tjänsten an-

ropas för att kunna presentera vilken data som finns tillgänglig

för presentation.

klienten anropar ”CreateSubscription”-tjänsten för att initiera

en prenumeration på utvald data medförande att klienten konti-

nuerligt erhåller uppdaterad data.

Det finns ett antal tjänster för att avsluta prenumeration, session

respektive kanal.

36

3.3.2.5 UA Säkerhetsstruktur

Stor vikt har lagts avseende säkerhet i UA specifikationen. För alla

UA applikationer krävs ett ”application instance” certifikat utfärdat av

en ”Certificate Authority” (CA). Varje organisation som utvecklar en

UA klient eller en UA Server måste alltså ordna att ett sådant certifikat

som tilldelas applikationen. Dessa certifikat utväxlas sedan mellan

klient och server för validering av implementation.

Autentisering av användare och användarrättigheter hanteras på appli-

kationslagernivå. För det förstnämnda kan antingen användarnamn

med tillhörande nyckel användas, alternativt kan digitalt certifikat som

intygar användarens identitet. I det sistnämnda fallet används X.509-

standarden. Oavsett val av implementation, måste användarens iden-

titet skickas till servern.

På kommunikationslagernivån (UA stack) hanteras konfidentialitet

(data endast tillgänglig för avsedd mottagare), integritet (data är inte

manipulerat) och applikationsidentitet. Detta uppnås genom kryp-

tering och signering av alla meddelanden som skickas.

För UA/”Web Services” används ”WS Security Conversation” med

underliggande WS-Security, som beskriver hur signaturer och kryp-

tering appliceras på SOAP-meddelanden. För närvarande används

version 1.1. I denna ingår delstandarder WS-Trust, WS-Addressing,

XML Signature och XML Encryption 1.0.

För UA/Binary används ”UA Security Conversation”, som har en

underliggande struktur som motsvarar till WS Security. Istället för att

krypteringen appliceras på SOAP-meddelanden, appliceras kryp-

teringen på meddelanden i binärform med hjälp av SSL/TLS.

3.3.2.6 Integrering av DCOM-OPC till UA-OPC

För att möjliggöra användning av UA klienter mot en stor bas av redan

installerade OPC DA COM Servrar, kan höljen användas. Figur 23

åskådliggör detta.

Figur 23: Användning av hölje mellan UA-klient och DA Server.

Höljen kommer att på motsvarande sätt kunna användas när DCOM-

baserade klienter ska användas mot UA servrar (figur 24).

37

Figur 24: Användning av höljen mellan DA-klient och UA Server.

OPC Foundation har ett antal höljen tillgängliga för utvecklare att utgå

ifrån, när de vill implementera funktionen.

38

4 Analys och resultat

I detta kapitel analyseras de olika OPC-standarderna. En jämförelse

görs mellan de äldre och den senaste standarden (OPC UA).

4.1 Jämförelse mellan OPC-DCOM och OPC UA

Då OPC-UA:s kommunikationsstack kan baseras på flera olika

kommunikationsstrategier, måste hänsyn tas till dessa valmöjligheter

när en jämförelse görs mellan den nyare OPC-UA och den äldre OPC-

standarden baserad på DCOM.

Nedan följer en jämförelse mellan de olika alternativen av UA och

OPC-DCOM ur olika perspektiv.

4.1.1 Applicerbarhet

När man jämför UA med DCOM-baserad OPC, framträder några

signifikanta skillnader, sett ur ett perspektiv där användbarhet eller

applicerbarhet bedöms.

Först och främst är DCOM i praktiken begränsat till noder med ett

Windows-operativ. Även om DCOM-lösningar finns för Unix/Linux,

verkar dessa vara implementerade i ytterst begränsad omfattning.

En annan begränsning för DCOM är dess användning av portar. Ett

antal fasta och dynamiska portar behövs för att DCOM ska fungera

som avsett. Detta kan skapa problem om kommunikationen ska ske

genom brandväggar, orsakerna är två:

de fasta portarna återfinns bland portnummer 135–139, vilka

är ökända och används ofta av icke behörig programvara. Inte

minst används port 135 för att lokalisera alla på noden

befintliga COM-servrar. Olika säkerhetsbrister (kända eller

okända) i dessa kan då användas för att obehörigen få tillgång

till noden.

dynamisk tilldelning av portnummer innebär att ett stort antal

portar måste öppnas i en brandvägg.

Båda ovanstående punkterna ses av de flesta nätverksadministratörer

som en källa till säkerhetsproblem. Olika lösningar existerar, exempel-

vis att använda på marknaden befintliga programvaror som medger

någon form av så kallad tunnling. Nackdelen av att använda sådan

tunnling är tillkommande licenskostnader, i tillägg till installation av

ytterligare programvara. Olika meningar råder huruvida det

sistnämnda också innebär utökat administrativt arbete.

39

Svagheten med nödvändiga portar undviks om UA används istället.

Väljs UA/”Web Services”, som baseras på SOAP/HTTP, används den

normala porten för webbkommunikation, port 80 (ytterligare filtrering

av meddelanden genom denna port kan ske genom isolering av

MIME-typer). Väljs istället UA/”Binary”, kan en godtycklig fast port

väljas, port 4840 är dock tilldelad för UA-TCP och port 4843 för UA-

SSL av IANA.

Om UA/”Web Services” används, kan val av Webbserver medföra

vissa konsekvenser. Antingen används en på marknaden befintlig

standardprodukt, eller tvingas man utveckla en egen. Det förra valet

har vissa nackdelar – bl.a. onödig överbyggnad i form av funk-

tionalitet (inkl. administrationsverktyg). Inte minst kan det finnas en

motvilja mot att installera sådana standardprodukter i processnära och

kritiska tillämpningar. Mot detta står att utveckla en egen webbserver,

vilket är ett jobb vars omfattning inte ska negligeras.

4.1.2 Prestanda

Då UA/”Web Services” baseras på SOAP/HTTP, kan dataöverföring i

flera avseenden anses mer resurskrävande i jämförelse med

COM/DCOM. En orsak till detta är säkerligen förhållandet att

SOAP/HTTP är baserat på ett textformat, medan COM/DCOM är

baserat på ett binärformat. Ett flertal studier har påvisat denna skillnad

i prestanda [6][10][11]. Dock påpekar Cook och Barfield i en studie

de genomförde att webb-baserad teknologi kan vara minst lika effektiv

som traditionella objektbaserade standarder om överföring av data

utgår från data i dokumentformat istället för i objektformat [5]. Även

om de i undersökningen använde CORBA för utvärdering, kan

troligen COM/DCOM anses jämförbar med CORBA i detta

sammanhang. Detta då de båda i grunden är baserade på en likartad

objektmodell.

Å andra sidan är tillämpningen av ”Web Services” i OPC mer objekt-

än dokumentbaserad, innebärande att nackdelarna avseende prestanda

för ”Web Services” i hög grad gäller. En undersökning visade att

XML-baserad OPC-kommunikation var tre till sex gånger

långsammare än DCOM-baserad motsvarighet [7]. Även om UA inte

testades i detta fall, kan användandet av webbformat som

kommunikationsplattform i undersökningen indikera en skillnad i

prestanda vid OPC-tillämpningar.

Användning av UA/Binary kan med stor säkerhet anses mindre resurs-

krävande än UA/”Web Services”, men hur resurskrävande den förra är

i förhållande till OPC/DCOM är oklart.

40

4.1.3 Standarder

Microsofts COM/DCOM stöds numera inte till fullo. Det är egentligen

bara vid utveckling av inbäddade tillämpningar och tillämpningar

inom mobiltelefonsegmentet som COM/DCOM fortfarande finns till-

handa i form av utvecklingsmiljöer. Inom alla andra tillämpningar

stöds standarden såtillvida att tidigare utvecklade applikationer kan

exekveras i Windows-miljö. Även om viss nyutveckling kan ske i

Microsofts senaste utvecklingsmiljö, kan Microsofts minskade

understöd av standarden märkas bland annat genom minskad

dokumentation av COM/DCOM på dess webbsidor. Leverantörer av

olika OPC-produkter baserade på DCOM, vilka under årens lopp har

byggt upp nödvändiga kunskaper och verktyg, kommer troligen att

även under överskådlig tid leverera nya produkter baserade på COM-

plattformen. Detta parallellt med att leverantörerna börjar utveckla

produkter baserade på UA.

När specifikationerna för UA tagits fram, har ett av kriterierna varit att

använda befintliga öppna standarder i möjligaste mån. Detta gäller

framför allt för UA/”Web Services” men även till stor del UA/Binary.

Med detta har man kommit från den låsning till Microsoft-standard

som man de facto befann sig i genom COM/DCOM.

4.1.4 Säkerhet

Begreppet säkerhet innefattar flera olika delar, vart och ett med sin

egen innebörd; autentisering, behörighet, konfidentialitet, integritet.

Säkerhetshanteringen i DCOM baseras i mångt och mycket på funk-

tionalitet i Windows operativsystem. Även om hanteringen av många

anses vara roten till många problem, inte minst vid installationer, kan

den anses för ändamålet fungera tillfylles. Dess stora nackdel är

snarare just behovet av en Windows-miljö, vilket försvårar integration

mot system som inte har Windows-operativ.

Genom implementering av ett flertal öppna standarder som hanterar

olika aspekter av säkerhet, har man försökt att nå en betryggande

säkerhetsnivå inom UA. Detta inbegriper såväl användning av certi-

fikat för autentisering, som kryptering för konfidentialitet och inte-

gritet. Med detta har man kommit från beroendet av Windows. Genom

olika tillämpning av dessa säkerhetsstandarder, kan en för systemet

lämplig säkerhetsnivå nås.

UA-specifikationen har ett avsnitt om ”Cyber Security Management

System” (CSMS), som avser ett dokument som varje systemägare är

ansvarig för och som specificerar olika säkerhetsaspekter för

systemet.45

Detta inbegriper säkerhetspolicy, procedurer och ansvars-

45

OPC UA Part 2, avsnitt 4.4

41

förhållanden. Säkerhetsnivån i UA borde sedan överensstämma med

den nivå som eftersträvas i CSMS. Det är meningen att det ska vara

upp till varje systemansvarig att definiera rätt säkerhetsnivå när UA

implementeras.

Det går således inte att påstå att UA är säkrare än DCOM eller vice

versa. Det är – som ofta är fallet – inte tekniken utan tillämpningen

som avgör om säkerheten är acceptabel, d.v.s. god. Den stora skill-

naden är att säkerhetsarkitekturen i UA medger upprätthållen säkerhet

mellan system med olika operativsystem.

4.1.5 Tillförlitlighet

OPC-applikationer utvecklade i DCOM är vid det här laget in-

stallerade i många tusental, världen över. Dessa installationer har, ofta

i produktionskritiska tillämpningar, ombesörjt datakommunikation

utan större problem, vilket indikerar en stabilitet som UA-standarden

fortfarande har att bevisa.

OPC Foundation har, förutom att publicera specifikationer för UA,

dessutom gett ut standardiserade procedurer och krav med avsikt att

leverantörer ska kunna certifiera sina produkter. Detta talar för att UA-

produkter borde kunna nå lika hög tillförlitlighet som DCOM-

baserade produkter. Med tanke på det fåtal lösningar av UA som hit-

intills installerats, går det inte att ännu uttala sig om något utfall. Det

kommer troligen att ta flera år innan sådan bas finns så att någon

slutsats kan dras.

Oavsett om en produkt uppfyller alla krav, återstår det också att se om

UA kan uppfylla alla krav i olika produktionsmiljöer. Inte minst blir

det intressant att se om den webb-baserade varianten innebär några

lastproblem om – eller kanske snarare när – den ersätter befintliga

DCOM-installationer.

4.1.6 Tillgänglighet

En faktor som påverkar en standards genomslagskraft, är tillgång till

olika slag av utvecklingsverktyg och SDK-er46

.

När det gäller DCOM, har i princip alla OPC-applikationer utvecklats

i Microsofts Visual Basic och Visual C++. Till detta har funnits ett

flertal tilläggspaket från tredjepartsleverantörer. Med introduktionen

av Microsofts Dotnet-miljö, har ett antal höljen47

utvecklats i Visual

C++, vilka möjliggör utveckling av OPC-applikationer även med

Microsofts språk C#.

46

Software Development Kit 47

wrappers

42

Med införandet av UA öppnas fler möjligheter att välja

utvecklingsmiljö, detta kommer till uttryck bland annat i OPC

Foundations avsikt att släppa följande UA SDK-er:

ANSI C

Dotnet 3.0

Java EE 5.0

En annan faktor, måhända av lägre vikt, som påverkar tillgängligheten

är den komplexitet med vilken underliggande struktur påverkar

programkodning. Även om UA och alla dess byggstenar kan vara allt

annat än enkelt att sammanfoga till en enhet, är det många som hävdar

att COM/DCOM och dess uppbyggnad i sig medför en komplexitet

som överstiger UA. Har man som programleverantör lyckats utveckla

en stor mängd av DCOM-lösningar, borde förutsättningarna för att

utveckla UA-lösningar inte vara sämre.

En ytterligare faktor, som inbegriper tillgänglighet, är hur uppgrad-

eringar av applikationer kan – och måste – genomföras. Jämför man

UA:s användning av WSDL med DCOM:s användning av Windows-

registret, måste DCOM anses komma till korta. Det är alltså mindre

komplicerat att uppgradera en UA applikation. Inte minst medför

kravet på ändringar i Windows-registret tillgång till administratörs-

rättigheter, såväl på server som på klient (sedan länge ett administra-

tivt problem inom många organisationer).

4.2 Generell utvärdering

De flesta OPC-delstandarder fram till idag har varit baserade på

COM/DCOM arkitektur. Även om COM fortfarande understöds på

alla Windows-system – inte minst med tanke på det ofantliga antal

applikationer som är i bruk – är det en teknik på utgående. Microsoft

är drivande i denna fråga. Som tidigare nämnts går COM-standarden48

inte sedan länge att återfinnas på Microsofts hemsidor. På Windows

”portal” för COM [8], kan man läsa att COM fortsättningsvis kommer

att stödjas som en del av Windows. På samma sida rekommenderas

samtidigt att inte påbörja nyutveckling av COM-baserade

applikationer, istället förordas implementering av s.k. ”Managed

Code” inom .NET-miljön.

Trots Microsofts rekommendation kan man fortfarande utveckla

COM-baserade applikationer genom att konstruera ”Unmanaged

Code”, företrädesvis i C++. Med tanke på den utveckling som pågår,

bör detta rekommenderas endast vid vidareutveckling av befintliga

lösningar.

När de ursprungliga (COM-baserade) OPC-standarderna togs fram var

48

”The Component Object Model Specification”, version 0.9

43

ovanstående perspektiv inte förutsebart. Snarare sågs OPC som en i

det närmaste nödvändig tillämpning för datakommunikation inom

tillverknings- och processindustrin.

UA-standarden har således framtagits för att undvika liknande

problem i framtiden. OPC UA kan ses som helt ny ansats då

medlemmarna i OPC Foundation har strävat efter att använda

funktionalitet given i öppna standarder, på tillfredsställande teknisk

och funktionsmässigt nivå. Med detta har man förhoppningsvis fått en

acceptans för standarden inom branschen, hos såväl absoluta flertalet

av systemleverantörer som hos alla slutanvändare, d.v.s. systemägare.

En uppställning av UA:s för- och nackdelar gentemot DCOM-baserad

OPC, kan se ut enligt följande:

Fördelar med UA

Generellt samtycke av industrin genom användning av öppna

standarder.

Operativoberoende.

Tillgänglighet: utveckling av applikationer.

Ingen användning av Windows-registret.

Lägre komplexitet än DCOM.

Förekomst av brandvägg innebär inte ett större hinder

Ett flertal alternativ erbjuds avseende val av delstandarder.

Nackdelar med UA

Flertalet alternativ avseende val av delstandarder.

Stabilitet återstår att visas.

Tillgång till Webb Server (om SOAP/HTTP implementeras).

Fördelar med COM

Fördelarna med COM/DCOM kan kanaliseras till några få egenskaper.

Låga resurskrav genom binärt format.

Inbyggd autenticitets- och rättighetskontroll genom Windows.

Demonstrerad stabilitet genom stort antal installationer genom

åren.

Nackdelar med COM

Arkitekturen som definierar COM är ganska omfattande i syfte att

täcka olika krav, men trots det finns dock ett flertal nackdelar med

denna. Don Box anger t.ex. åtta begränsningar hos COM [3]:

Ingen enhetlig standard för att definiera typer.

Såväl IDL som typbibliotek kan användas för att beskriva

typer. Dessa båda kan delvis ersätta varandra.

Brist på specifikation vilken DLL (och version) som måste

installeras för att komponent ska fungera korrekt. En

komponent som har fungerat mot en tidigare version av en

DLL, kan sluta fungera när en senare version av DLL:en in-

stallerats. Även om gränssnitten är oförändrat, kan ändrad

44

implementation bakom, orsaka oförutsedda resultat49

Ingen specifikation tillgänglig angående vilka privata typer

som används internt inom komponenten.

Ingen klar definition av termen ”komponent”. Den kan tolkas

såväl som ett objekt, en klass eller som en DLL som innehåller

en eller flera klasser. Då denna punkt kanske mer är av

språklig art, visar den ändå på en brist i standarden. Detta inte

minst då termen ingår i standardens förkortning – COM.

Det är möjligt att definiera privata gränssnitt (”interfaces”) i

C++ även om de inte är definierade i IDL eller något COM

typbibliotek. Denna möjlighet för en utvecklare att skapa

odokumenterade gränssnitt kan medföra problem. Inte minst

faller möjligheten att systemet kan skapa ”marshaller” när

kontextbyte ska ske (exempelvis när en klient i en process ska

kommunicera med en server i en annan process).

Typsystemet har två rötter: ”IUnknown” och ”VARIANT” –

det förra utgör rottypen för objektreferenser, det senare

rottypen för värden. Behovet av två olika typsystem visar på

en viss inkonsekvens i standarden som medför ökad

komplexitet.50

.

Endast singel-arv tillåts. Detta är ett medvetet val för att

behålla öppenheten för flera typer av kompilatorer att skapa

COM-komponenter. Detta medför dock en begränsning i sättet

att använda OOP51

.

Ytterligare nackdelar som kan anses väsentliga:

Dess beroende av Windows

En klient, som inte längre behöver data från en komponent, är

ansvarig för att uppbundet minne frigörs. Detta leder till att

slarvigt utformade applikationer kan orsaka svårupptäckta

minnesläckor.

Att öppenhet för val av delstandarder medtagits som såväl fördel och

nackdel baseras på att UA-standarden ger utrymme för anpassning till

rådande situation vid installation. Fördelen är alltså att oavsett vilken

IT-miljö som föreligger, kan UA appliceras. Nackdelen kan sägas vara

att alternativen indikerar en brist i den grundläggande strukturen – UA

kan ses som ett lapptäcke och inte en enhetlig standard.

En frågeställning som dyker upp är om inte CORBA hade kunnat

ersätta DCOM och användas istället för de standarder som nu valts.

Svaret på detta är att i princip har då de nackdelar som följer med

DCOM, också erhållits med CORBA. Detta då de båda i grunden är

baserade på en objektmodell som i grunden är likartad.

49

”DLL Hell” 50

Som jämförelse kan nämnas att samtliga typer i .Net utgår från en typ -

”System.Object” 51

OOP: Objektorienterad programmering

45

4.3 Utveckling och framtid för OPC

Den befintliga basen av OPC-DCOM installationer som återfinns före-

trädelsevis på en processnära nivå, kommer att kvarstå ett antal år

framåt. Även efter det att UA konstaterats hålla vad som utlovas, leder

inte det till att befintliga DCOM-installationer kommer att ersättas

bara för sakens skull. Istället måste ett tekniskt eller ekonomiskt

incitament uppstå för att så ska ske.

Ett stort antal applikationsleverantörer kommer med tiden att får fram

nya produkter som stödjer UA. Troligen kommer ett flertal av dessa

produkter att medge att såväl UA/”Web Services” som UA/Binary kan

väljas vid installation. Dessa kommer sedan att användas framförallt

vid nyinstallationer, där det inte redan finns en befintlig (DCOM-

baserad) OPC-lösning. Grundkravet för detta är att UA-applikationer

då finns att tillgå på marknaden för såväl mottagande (klient) som

sändande (server) sida. Under en övergångsperiod kommer DCOM-

baserade applikationer att samexistera med UA-applikationer med

hjälp av s.k. höljen52

.

När det gäller processnära installationer är det författarens antagande

att ”UA/Binary” kommer att väljas före UA/”Web Services”.

Anledningen är behovet av resurssnåla dataöverföringar över ofta

driftkritiska nätverk.

När vi istället börjar förflytta oss uppåt i systemarkitekturen, handlar

det om att förbinda de processnära systemen med system av mer

administrativ art på olika nivåer, benämnda MES (”Manufactoring

Execution System”), PDM (”Product Data Management”), ERP

(”Enterprise Resource Planning”) och annat. Information som utväxlas

på denna nivå är normalt inte av realtidskaraktär, d.v.s. det är inte

tidskritiskt att få data. Till skillnad från de tidigare DCOM-baserade

OPC-standarderna, har introduktionen av UA medfört tillgång av ett

större urval av underliggande tekniker för detta. Här kan UA/”Web

Services” ha en möjlighet att få ett genomslag.

OPC kommer genom framtagandet av UA 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 betydande faktor 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.

Skulle UA-standarden inte uppnå sådan acceptans och dess genomslag

således utebli, står vi inför en utveckling där få alternativ existerar.

Det första är att DCOM-lösningarna kvarstår under överskådlig tid.

Med tanke på den ofantligt stora mängd gjorda installationer av

DCOM-lösningar (som inte har med OPC att göra), kommer den med

52

wrappers

46

säkerhet att stödjas i Windows-miljön under överskådlig tid. Vad som

är av större vikt, är ett ökat behov att understödja OPC på andra

miljöer än Windows. Om sådant stöd inte utvecklas, kommer det

uppenbara alternativet vara att ett antal egna standarder utvecklas av

olika leverantörer. Detta skulle innebära en utveckling som frångår

alla parters önskemål och behov av en öppen standard.

47

Förkortningar

AE Alarm and Event (OPC delstandard)

ATL Active Template Library (programbibliotek utgivet av

Microsoft, bestående av C++-klasser)

CATID Category ID (COM-begrepp)

CLSID Class ID (COM-begrepp)

COM Component Object Model

CORBA Common Object Request Broker Architecture

CX Complex Data (OPC delstandard)

DA Data Access (OPC delstandard)

DCE Distributed Computing Environment

DCOM Distributed COM

DCS Distributed Control System

DLL Dynamic Linking Library (filtyp)

DNA Distributed interNet Applications Architecture (begrepp

skapat av Microsoft, numera ovanligt)

DX Data Exchange (OPC delstandard)

EXE Executable (filtyp)

HDA History Data Access (OPC delstandard)

HTTP Hypertext Transfer Protocol

IDL Interface Definition Language

IETF Internet Engineering Task Force

IID Interface ID

MAC Media Access Control

MFC Microsoft Foundation Classes (programbibliotek utgivet av

Microsoft, bestående av C++-klasser)

MIDL Microsoft Interface Definition Language

MTS Microsoft Transaction Server

OLE Object Linking and Embedding

OOP Object Oriented Programming

OPC OLE for Process Control

ORPC Object RPC

OSF Open Software Foundation

ProgID Program ID (COM-begrepp)

RPC Remote Procedure Call

SOAP Simple Object Access Protocol

SDK Software Development Kit

UA Unified Architecture (OPC standard)

UUID Universally Unique Identifiers

W3C World Wide Web Consortium

XML Extensible Markup Language

48

Källförteckning

[1] Armstrong. 2007. Implementing UA – The Stack and Wire

Protocol, DevCon 2007 OPC Unified Architecture. http://www.opcfoundation.org/DownloadFile.aspx?CM=3&RI=459&CN=K

EY&CI=288&CU=42, senast besökt 2008-10-15.

[2] Box. 1998. Essential COM, Addison Wesley, ISBN 0-201-63446-5

[3] Box. december 2000. Is COM Dead?. MSDN Magazine,

http://msdn.microsoft.com/msdnmag/issues/1200/com/toc.asp?frame=

true, senast besökt 2008-10-15.

[4] Burke. 2007. Introduction to Unified Architecture – The Next

Generation of System Interoperability, DevCon 2007 OPC Unified

Architecture. http://www.opcfoundation.org/DownloadFile.aspx?CM=3&RI=425&CN=K

EY&CI=288&CU=42, senast besökt 2008-10-31.

[5] Cook, Barfield. 2006. Web Services versus Distributed Objects: A

Case Study of Performance and Interface Design. http://

www.cs.utexas.edu/~wcook/Drafts/2006/WSvsDO.pdf, senast besökt

2008-10-15.

[6] Davis, Zhang. 2002. A comparative Study of DCOM and SOAP,

Proceedings of the IEEE Fourth International Symposium on

Multimedia Software Engineering. årgång 2002

[7] Lange, Softing AG. 2006. Quo Vadis OPC? From Data Access to

Unified Architecture

http://www.softing.com/home/en/pdf/ia/professional-

article/opc/2006/0604_Quo_Vadis_OPC.pdf, senast besökt 2008-10-15.

[8] Microsoft. Microsoft COM: Component Object Model Technolo-

gies. http://www.microsoft.com/Com/default.mspx. Senast besökt

2008-10-15

[9] Microsoft. MSDN Library - DLLs.

http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/vccore/html/_core_dll_topics.asp. Senast besökt 2008-10-15

[10] Microsoft. Performance of ASP.NET Web Services, Enterprise

Services, and .NET Remoting.

http://msdn.microsoft.com/en-us/library/ms996381.aspx, senast besökt

2008-10-31.

49

[11] Nordström, Noreklint. 2002. Nya möjligheter med .NET – en

utredning av skillnaderna mellan DCOM och webbtjänsttekniken.

Examensarbete C-nivå.

http://www.cs.kau.se/cs/education/courses/dvgc09/Exjobb_2002/C200

2-11.pdf, senast besökt 2008-10-15.

[12] OMG. Catalog of OMG IDL / Language Mappings Specifica-

tions.

http://www.omg.org/technology/documents/idl2x_spec_catalog.htm,

Senast besökt 2008-10-15

[13] Rydberg. 2004. Utvärdering av kommunikationsprotokollen

SOAP, DCOM, CORBA samt HTML/PHP med avseende på

Interliving-projektet. Examensarbete

http://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2004/ra

pporter04/rydberg_claes-johan_04048.pdf, senast besökt 2008-10-31.

[14] Tapadiya. 2000. COM+ Programming, A Practical Guide Using

Visual C++ and ATL, Prentice Hall. ISBN 978-0130886743

[15] The Component Object Model Specification, version 0.9. finns

inte längre som officiellt dokument hos Microsoft. Finns dock till-

gänglig på Department of Computer Science – DaimiFaculty of Sci-

ence, University of Aarhus

http://www.daimi.au.dk/~datpete/COT/COM_SPEC/html/com_spec.ht

ml, senast besökt 2008-10-15.

[16] The Open Group. The Open Group DCE Portal.

http://www.opengroup.org/dce, Senast besökt 2008-10-15

[17] COM är beskrivet hos Microsoft på

http://msdn.microsoft.com/en-us/library/ms877981.aspx, senast besökt

2008-10-15.

50

Följande specifikationer finns 2008-10-01 tillgängliga för nerladdning

på www.opcfoundation.org (registrering krävs):

OPC Common 1.00 Specification

OPC Common 1.10 Specification

OPC DA Auto 2.02 Specification

OPC DA 2.05a Specification

OPC DA 3.00 Specification

OPC XMLDA 1.01 Specification

OPC HDA Auto 1.00 Specification

OPC HDA 1.20 Specification

OPC AE 1.01 Auto Specification

OPC AE 1.10 Specification

OPC Batch Auto 1.00 Specification

OPC Batch 2.00 Specification

OPC Commands 1.00 Specification

OPC Complex Data 1.00 Specifikation

OPC DX 1.00 Specification

OPC Security 1.00 Specification

OPC UA part 1 – Overview and Concepts RC 1.01.03

Specification

OPC UA Part 2 – Security Model RC 1.01.52 Specification

OPC UA Part 3 – Address Space Model RC1.01.13

Specification

OPC UA Part 4 – Services RC 1.01.30 Specification

OPC UA Part 5 – Information Model RC 1.01.13 Specification

OPC UA Part 6 – Mappings RC 1.00.08 Specification

OPC UA Part 7 – Profiles RC 1.00.00 Specification

OPC UA Part 8 – Data Access RC 1.01.10 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

OPC Test Lab Part 1 – Concepts RC 1.00.01 Specification

OPC Test Lab Part 2 – Abstract Test Suite RC 1.00.01

Specification

OPC Test Lab Part 3 – Test Lab Realization RC 1.00.02

Specification

OPC Test Lab Part 4 – Certification Process RC 1.00.01

Specification

OPC Test Lab Part 5 – Quality Management Manual RC

1.00.01 Specification

OPC Test Lab Part 6 – COM DA Server RC 1.00.01

Specification

OPC Test Lab RC 1.00 Specification Parts 6-7

TRITA-CSC-E 2009:090 ISRN-KTH/CSC/E--09/090--SE

ISSN-1653-5715

www.kth.se