OPC für Prozessleitsysteme - ostfalia.de · SCADA Supervisory control and data acquisition SOAP Simple Object Access Protocol SPS Speicherprogrammierbare Steuerung TCP/IP Transmission

Fachhochschule -

Braunschweig/Wolfenbüttel

Fachbereich Elektrotechnik

Leittechnik

OPC für Prozessleitsysteme

Bearbeiter: Florian Rudolph 20563048

I

Inhaltsverzeichnis

Inhaltsverzeichnis ........................................................................................................ I

Abbildungsverzeichnis .............................................................................................. II

Abkürzungs- und Sachwortverzeichnis ................................................................ III

1 Einführung .......................................................................................................... 4

2 Prinzip und Funktion ......................................................................................... 6

2.1 Die Kommunikation mit DCOM ..................................................................... 7

2.2 Softwareumsetzung eines Interfaces, Servers und Clients ............................... 8

3 Schnittstellen und Spezifikationen ................................................................. 12

3.1 OPC Data Access ........................................................................................... 12

3.2 OPC Alarm and Event .................................................................................... 15

3.3 OPC Historical Data Access .......................................................................... 16

3.4 OPC Commands ............................................................................................. 17

3.5 OPC XML Direct Access ............................................................................... 18 3.5.1 XML oder DCOM? .................................................................................... 20

4 Industrielles Anwendungsbeispiel .................................................................. 23

4.1 Aufgabenstellung ........................................................................................... 23

4.2 Lösungsansatz ................................................................................................ 23

4.3 Finanzielle Sichtweise .................................................................................... 25

5 Literaturverzeichnis ......................................................................................... 27

II

Abbildungsverzeichnis

Bild 1.1: Situation vor der Einführung von OPC ......................................................... 4

Bild 1.2: Die Situation mit OPC-Schnittstelle ............................................................. 5

Bild 2.1: Informationsfluss im industriellen Bereich [2] ............................................. 6

Bild 2.2 Konzept des OPC-Servers und des -Interfaces .............................................. 7

Bild 3.1: OPC-Schnittstellenspezifikationen [4] ........................................................ 12

Bild 3.2: Struktur der Data Access-Spezifikation ...................................................... 13

Bild 3.3: Synchroner Modus der Kommunikation ..................................................... 14

Bild 3.4: Asynchroner Modus der Kommunikation (Abonnement) .......................... 14

Bild 3.5: Infrastruktur des OPC XML DAs [7].......................................................... 19

Bild 3.6: Systemumgebung von OPC-XML Direct Access ....................................... 20

Bild 3.7: Vergleich der Übertragungszeiten bei XML und DCOM [8] ..................... 21

Bild 3.8: Vergleich von OPC XML DA unter Linux und Windows [8] .................... 21

Bild 3.9: Vergleich von OPC XML DA im Intranet und Internet [8] ........................ 22

Bild 4.1: Herkömmlicher Lösungsansatz [6] ............................................................. 24

Bild 4.2: Lösung mit OPC [6] .................................................................................... 25

Bild 4.3: Finanzielle und zeitliche Sicht der Lösungen [6] ........................................ 26

III

Abkürzungs- und Sachwortverzeichnis

ASP Active Server Pages

CORBA Common Object Request Broker Architecture

DCOM Distributed Component Object Model

DOS Disk Operating System

HTTP Hypertext Transfer Protocol

MMI (auch HMI) Man Machine Interface

.NET Softwareplattform von Microsoft

OLE Object linking and embedding

OPC OLE for process control

PLC Programmable Logic Controller

SCADA Supervisory control and data acquisition

SOAP Simple Object Access Protocol

SPS Speicherprogrammierbare Steuerung

TCP/IP Transmission Control Protocol / Internet Protocol

Treiber Software zum Zugriff auf Hardwarekomponenten

UDDI Universal Description, Discovery and Integration

VB Visual Basic

WSDL Web Service Description Language

XML Extensible Markup Language

OPC für Prozessleitsysteme - 1 Einführung

4

1 Einführung

OPC (OLE for process control) definiert einen weltweiten, offenen Standard für den

Daten- und Informationsaustausch von Softwarekomponenten. Der OPC-Standard

wird durch die OPC Foundation verwaltet und publiziert. Die OPC Foundation stellt

ein Gremium aus ca. 200 Automatisierungs- und Softwareherstellern sowie

Anwendern dar. Die Grundidee war die Definierung einer standardisierten

Schnittstelle, um über Software auf Daten in sämtlichen Geräten im Prozess-

leitsystem zugreifen zu können.

Bild 1.1: Situation vor der Einführung von OPC

Bild 1.1 soll die ursprüngliche Situation verdeutlichen, aus der es heraus nötig

geworden ist im Bereich der Automatisierung den OPC-Standard zu definieren.

Auf Seiten der Applikationsebene besteht ein erhöhter Entwicklungsaufwand, da

jeder Hersteller eigene Treiber für jedes Gerät auf Seiten der Automatisierungsebene

entwickeln muss [1]. Durch diese Situation ist die Problematik inkompatibler Treiber

von unterschiedlichen Herstellern auf einem System unausweichlich. Es ist geradezu

unmöglich mehrere Treiber nebeneinander auf einem System problemlos arbeiten zu

lassen.

Als Veranschaulichung der beschriebenen Problematik dient ein Blick auf das 1982

gängige Betriebssystem MS-DOS, unter dem die Anwendung Microsoft Word

bereits mehr Disketten für potentielle Druckertreiber mitlieferte, als die Software

selber benötigte. Adaptiert man diese Situation auf den Bereich der industriellen

OPC für Prozessleitsysteme - 1 Einführung

5

Automatisierung, wird schnell klar, dass durch die Vielzahl der internationalen

Hersteller und einer Unmenge an unterschiedlichster Hardware ein reibungsloser und

störungsfreier Automatisierungsprozess unmöglich erscheint.

Bild 1.2: Die Situation mit OPC-Schnittstelle

Durch die Einführung von OPC (siehe Bild 1.2) ergibt sich eine Strukturänderung im

System. Von einer direkten Kommunikation der Software mit der Hardware, fungiert

nun eine OPC-Schnittstelle anschaulich gesprochen als Vermittler.

OPC für Prozessleitsysteme - 2 Prinzip und Funktion

6

2 Prinzip und Funktion

OPC definiert Standardschnittstellen, welche eine Verbindung zwischen Software

und Applikation herstellen. Die Aufgabe der Hersteller liegt nun darin entweder

einen OPC-Client für die Software und einen OPC-Server für die Hardware zu

liefern. Die Hersteller sind dabei nun unabhängig voneinander. Der OPC-Server

implementiert das gerätespezifische Protokoll hinter der standardisierten OPC-

Schnittstelle.

In Anlehnung an das in Kapitel 1 erwähnte Beispiel der Druckertreiber, wäre hier zu

nennen, dass heutzutage jeder Druckerhersteller einen Treiber liefert, den alle

Applikationen verstehen und verwenden. Das gleiche Prinzip verfolgt der OPC-

Standard in der Automatisierungsbranche. Es sollte demnach selbstverständlich sein,

dass jedes Gerät den passenden OPC-Server in Form von Software mitliefert.

Um den Fluss von Prozessdaten und deren Verarbeitung in Verbindung mit OPC zu

erkennen und zu beschreiben, dient zunächst Bild 2.1. Es zeigt den allgemeinen

Informationsfluss von Prozessdaten im industriellen Bereich.

Bild 2.1: Informationsfluss im industriellen Bereich [2]


7

Daten auf der Field Management-Ebene bilden die Basis. Eine große Menge an

Informationen aus unterschiedlichsten Quellen muss dem Anwender sowie der

Software, welche darauf zugreift, ständig und in einheitlicher Art und Weise zur

Verfügung stehen.

Auf der Process Management-Ebene steuert und überwacht das Prozessleitsystem

die Prozesse und stellt beispielsweise Daten und Informationen über

Herstellungsabläufe bereit. Prozesse können auch über Software in dieser Ebene

manuell angepasst und gesteuert werden. Zu nennen wären in dieser Ebene das

Konzept der Supervisory Control and Data Acquisition (SCADA).

Die höchste Ebene des Leitsystems stellt die Business-Ebene dar. Hier kommen alle

Daten- und Informationsflüsse zusammen. Hier gilt es die Prozesse zu optimieren

und in der Effizienz zu steigern, was wiederum ein Mehr an Informationsfluss zur

Folge hat.

2.1 Die Kommunikation mit DCOM

Um nun das OPC-Konzept, wie es in Kapitel 1 angedeutet wurde zu konkretisieren,

dient Bild 2.2.

Bild 2.2 Konzept des OPC-Servers und des -Interfaces

Die Applikationen 1 bis 3 stellen hier die OPC-Clients dar. Der OPC-Server hat nun

die Aufgabe als Vermittler die Daten aus den Datenquellen mit den Clients zu

tauschen. Er ist aus Sicht der Kommunikation wie eine Datenquelle selber zu

betrachten, da er nur auf Anfragen des Clients antwortet, d.h. Anfragen bearbeitet

und gemäß antwortet. Er selber generiert jedoch keine Nachfragen. Als Analogie


8

dazu kann man den Server mit einem Kellner im Restaurant vergleichen, der nur auf

Bestellung handelt und im Normalfall keine Bestellung ohne Anfrage alleine

ausführt.

Der Client hingegen sendet dem Server nur Anfragen. Er selber kann sie nicht

ausführen bzw. erfüllen. Somit kann man den Client mit dem Kunden im Restaurant

vergleichen.

Kommuniziert wird bei OPC über DCOM. DCOM wurde von Microsoft entwickelt

und stellt ein Protokoll dar, dass Softwarekomponenten die direkte Kommunikation

über ein Netzwerk ermöglicht. Es handelt sich dabei um ein objektorientiertes

System, welches auch Funktionen in anderen Adressräumen aufrufen kann. Man

spricht daher auch von einer Interprozesskommunikation. DCOM-Objekte können

von verschiedensten Programmiersprachen erzeugt werden und stellen nichts weiter

als kompilierten Code dar, der einen Dienst zur Verfügung stellt. Ein Objekt wird

gemäß Objektorientierung von einer DCOM-Klasse erzeugt, Microsoft spricht hier

leider nicht von einer Klasse, sondern von einer Komponente [3]. Diese Komponente

implementiert eine oder mehrere Schnittstellen. Sie ist also eine Sammlung von

Methodenaufrufen, die semantisch zu einem DCOM-Interface zusammengefasst

wurden. In der Literatur spricht man daher auch von Aggregation, anstatt von

Klassenvererbung zu sprechen. Zu erwähnen wäre darüberhinaus noch, dass eine

Komponente bzw. Klasse mehrere DCOM-Objekte bzw. -Schnittstellen enthalten

kann, anders als es beispielsweise bei CORBA der Fall ist.

Damit ein verbindungsfähiges Objekt nun Kontakt zum Client herstellen kann, muss

der Client eine Schnittstelle bzw. Interface zur Verfügung stellen. Ein Objekt kann

gleichzeitig mit mehreren Clients verbunden sein und kann somit mehrere

verbindungsfähige Objekte abhören.

2.2 Softwareumsetzung eines Interfaces, Servers und

Clients

Nachfolgend wird ein einfacher Zähler vorgestellt der über DCOM kommuniziert

und auf Anfragen des Clients über einen Server zählt. Die Implementierung erfolgte

in Java. Letztlich erhält man drei Codepakete, die beispielhaft darstellen wie der

Informationsfluss bei einem OPC-System abläuft.


9

Zunächst wird der Code für das Interface dargestellt. Wie bereits in Kapitel 2.1

erwähnt, benötigt der Client ein Interface, um eine Kommunikation herzustellen.

Obiger Quellcode stellt nun das Zähler-Interface dar, eine sog. IDL-Datei. Aus der

IDL-Datei erzeugt ein Compiler eine sprachspezifische Schnittstellendefinition. Per

Vereinbarung muss jede Klasse bzw. Komponente mindestens die Schnittstelle

IUnknown (Zeile 9) unterstützen, dies ermöglicht den ersten Zugriff [3], d.h.

IUnknown implementiert die nötigsten Methoden. Darüberhinaus ist eine

eindeutige Zuordnung per 16 Byte UUID (Zeile 2) nötig.

Der Datentyp HRESULT (Zeile 12-14) gibt den Status der Operationen von

microsoftspezifischen Komponenten an. Das bedeutet HRESULT ist ein 32-Bit-Wert,

der in drei Felder unterteilt ist: Schweregradcode, Bereichscode und Fehlercode. Auf

die genauen Eigenschaften der einzelnen Felder kann im Rahmen dieser Arbeit nicht

näher eingegangen werden. Anschaulich kann man sagen, dass jeder Ausnahme d.h.

jedem Ereignis ein eindeutigen HRESULT zugeordnet ist. Wenn ein verwalteter Code

01 //Count.idl

02 [uuid(1689CB21-2ADE-11d0-892E-00A024638502),version(1.0)]

03 library Counter

04 { [object,

05 uuid(1689CB22-2ADE-11d0-892E-00A024638502),

06 pointer_default(unique),

07 oleautomation

08 ]

09 interface ICount : IUnknown

10 {

11 import "oaidl.idl";

12 HRESULT set_sum([in] int val);

13 HRESULT get_sum([out, retval] int* retval);

14 HRESULT increment([out, retval] int* retval);

15 };

16 importlib("stdole32.tlb");

17 [uuid(1689CB23-2ADE-11d0-892E-00A024638502)]

18 coclass Count

19 {

20 [default] interface ICount;

21 };

22 };


10

eine Ausnahme auslöst, übergibt die Software-Plattform HRESULT an den COM-

Client. Nachfolgend sind die drei benötigten HRESULT dargestellt:

set_sum (Setzen des Zählers)

get_sum (Zählerstand ausgeben)

increment (Zählerstand um 1 erhöhen)

Nun betrachten wir den Server:

Der obige Server ist trivial aufgebaut, er implementiert die Methoden, die für den

Zähler essentiell sind. Man erkennt auch anhand der Methoden die Flussrichtung der

Information. Die Methoden increment() und get_sum() liefern den Wert des

Zählers zurück an den Client, wie in Kapitel 2.1 beschrieben, jedoch erst nach

Anfrage und niemals ohne Aufforderung. Die Methode set() kann nur der Client

aufrufen, um den Zählerstand zu erhöhen.

Abschließend wird nachfolgend der Java-Code für den Client dargestellt und

beschrieben.

01 //Count.java

02 import com.ms.com.*;

03 import count.*;

04 class Count implements ICount

05 {

06 private int sum;

07 public int get_sum() throws ComException

08 {

09 return sum;

10 }

11 public void set_sum(int val) throws ComException

12 {

13 sum = val;

14 }

15 public int increment() throws ComException

16 {

17 sum++;

18 return sum;

19 }

20 }


11

Der Client macht in seiner Main-Methode (Zeile 5 ff.) folgendes:

1. Erzeugen eines Objektes der Server-Klasse Count mit Typecast als ICount

(Zeile 10)

2. Den Zähler auf null setzen (Zeile 13)

3. 1000mal den Zähler inkrementieren (Zeile 15-18)

Zum Informationsfluss lässt sich sagen, dass der Client die Anfrage auf das

Nullsetzen oder das Inkrementieren über das Objekt der Server-Klasse erteilt und der

Server die Aufgabe erledigt und mit dem aktuellen Zählerstand bei der Methode

increment() antwortet. Der Rückgaebwert findet hier beim Client keine

Berücksichtigung.

Durch die Verwendung von DCOM muss der Server nicht auf dem gleichen System

oder PC arbeiten wie der Client.

01 //CountDCOMClient.java

02 import count.*;

03 class CountDCOMClient

04 {

05 public static void main(String args[])

06 {

07 try

08 {

09 System.out.println("Erzeuge Ein neues Zählerobjekt");

10 ICount counter = (ICount)new count.Count();

11 // Zähler zu Beginn auf null setzen

12 System.out.println("Zähler auf 0");

13 counter.set_sum((int)0);

14 // 1000x inkrementieren

15 for (int i=0; i<1000; i++)

16 {

17 counter.increment();

18 }

19 }

20 catch(Exception e)

21 {

22 System.err.println("System Exception");

23 System.err.println(e);

24 }

25 }

26 }

OPC für Prozessleitsysteme - 3 Schnittstellen und Spezifikationen

12

3 Schnittstellen und Spezifikationen

Seit der Veröffentlichung der ersten Spezifikation von OPC im Jahre 1996 sind die

Standards zur Schnittstellenbeschreibung gewachsen. Man unterscheidet heute

folgende Schnittstellen:

Bild 3.1: OPC-Schnittstellenspezifikationen [4]

3.1 OPC Data Access

Der größte Anwendungsbereich von OPC ist OPC DA. Der Zugriff auf

Echtzeitdaten, speziell in Automatisierungsgeräten, erfolgt hierbei über eine

bestimme logische Struktur (siehe hierzu Bild 3.2).

Der Client kann eine beliebige Anzahl von Gruppen oder Groups erzeugen. In jeder

Gruppe kann der Client Items erzeugen, die nichts anderes darstellen, als Information

bzw. Daten eines Datenfeldes im Automatisierungsgerät. Diese Information im

Automatisierungsgerät nutzt der Client. Die wesentlichen Eigenschaften der

Informationen sind [1]:

Wert (z.B. einer Messgröße eines Sensors)

Qualitätsstatus (Fehler, gut, unbekannt)

Zeitstempel

Zugriffsrechte (lesen, schreiben oder beides)


13

Bild 3.2: Struktur der Data Access-Spezifikation

Der Client erhält zu einem sog. Datenpunkt nur aktuelle Werte, d.h. zu einer Abfrage

gibt es immer nur Echzeitdaten. Der Zeitstempel wird entweder vom Auto-

matisierungsgerät vergeben oder aber der Server vergibt diesen Wert, falls Geräte

(z.B. Waagen) oder Protokolle (z.B. Modbus) keine Zeitstempel vorsehen.

Der Qualitätsstatus beschreibt den Zustand des Wertes. Beispielsweise erhält man

vom OPC-Server bei Kommunikationsabbruch den Qualitätszustand „bad“.

Der Client besitzt verschiedene Möglichkeiten auf diese Items zuzugreifen. Zu

nennen wären da:

Synchrones Schreiben und Lesen (Pollen)

Asynchrones Lesen (Abonnieren) und Schreiben

Nachfolgend wird kurz auf die Zugriffsmodi eingegangen. Datenanforderungen vom

Client werden als Lesen interpretiert. Schreiben bedeutet, dass der Client einem

Automatisierungsgerät einem Wert zuweist. Beispielweise wird eine auszuführende

Aktion wie „Ventil bei Temperatur X öffnen“ mit einem Wert dem Gerät mitgeteilt.

Zu unterscheiden sind die Lesemodi. Man spricht vom Pollen, wenn der Client

kontinuierlich Werte abfragt und eine Antwort erhält. Dies ist der Fall beim

synchronen Lesen (vgl. Bild 3.3).


14

Bild 3.3: Synchroner Modus der Kommunikation

Beim asynchronen Lesen (vgl. Bild 3.4) erhält der Client nur dann Werte vom

Automatisierungsgerät, wenn sich diese geändert haben.

Bild 3.4: Asynchroner Modus der Kommunikation (Abonnement)

Jedoch ist zu bedenken, dass im Falle des asynchronen Lesens beim Client nicht

immer derselbe Mechanismus auch für den OPC-Server verwendet wird. Es steht

dem Server völlig frei nicht dennoch das Automatisierungsgerät zu pollen, was bei

den meisten SPS-Geräten auch der Fall ist [1].

Wertänderung

Wertänderung


15

Betrachtet man die Kommunikation zwischen Server und Datenquelle etwas näher,

gilt es auch hier die Lesemodi zu unterscheiden. Zu nennen wäre in diesem

Zusammenhang Cache reads und Device reads. Das Cache read arbeitet mit einem

Pufferspeicher auf dem OPC-Server, das bedeutet, dass das Automatisierungsgerät

schneller Daten liefern kann, da diese auf einem Speicher zwischengelagert werden,

um letztlich vom Client verarbeitet werden zu können. Beim Device read greift der

Client direkt über den Server auf die Datenquelle zu. Die Zugriffsrate und damit die

Performance des Servers lassen sich durch das Zwischenspeichern und die

asynchrone Kommunikation erhöhen.

3.2 OPC Alarm and Event

Dieser Schnittstellenstandard bietet dem Client die Möglichkeit über bestimmte

Ereignisse oder Alarmsituationen benachrichtigt zu werden. Darüberhinaus besteht

mit Hilfe des Servers für den Client die Möglichkeit Fehler zu bestimmen und

Bedingungen d.h. Szenarien festzulegen, bei denen Ereignisse zu einer

Benachrichtigung führen [2]. Die Grenzen zwischen einem Alarm und einen Ereignis

sind verwischt, es bleibt letztlich dem Anwender und Nutzer überlassen, wie er was

definiert. Oftmals dienen die Begriffe nur als Synonym für bestimmte Anwendungen

des Nutzers und sind nicht in ihrer eigentlichen Bedeutung zu verstehen.

Dennoch gilt nach [2] innerhalb des OPC-Standards ein Fehler als ein unge-

wöhnlicher Zustand d.h. ein nicht erwartetes Ereignis.

Kurzbeispiel:

Der Baustein FC101 einer S7 SPS hat die Aufgabe bzw. Funktion den Ausgangs-

bereich sofort zu setzen [4]. Ihm könnten drei Zustände zugeordnet sein:

High Alarm

Normal

Low Alarm

Somit erfüllt der Baustein FC101 im OB1 der SPS die Alarmfunktion, indem er dem

Server und damit dem Client Alarmzustände mitteilt.

Neben den besagten Alarmen existieren noch die bereits erwähnten Ereignisse.

Ereignisse müssen nicht immer mit bestimmten Zuständen in Verbindung gebracht


16

werden. Der Übergang von High Alarm in Normal ist beispielsweise verknüpft mit

Zuständen. Wohingegen Änderungen in der Systemkonfiguration, System-Fehler und

Änderungen durch Anwender Ereignisse hervorrufen können, die eben ohne

Beziehung zu einem Zustand im Prozess ausgelöst werden können. Letztlich legt der

Client fest welches Ereignisse oder Fehler er abonniert und wie es dem Prozess

zuzuordnen ist.

Abschließend lässt sich zur OPC Alarm and Event-Schnittstelle folgendes

zusammenfassen:

Der Client legt die Typen von Ereignissen fest, die der Server detektiert

Der Client kann bestimmte Events abonnieren und erhält Informationen zu

deren Auftreten

Der Client kann manipulierend in Zustände des Server eingreifen [2]

3.3 OPC Historical Data Access

Eine Vielzahl von Daten wird in einem Prozessleitsystem produziert und abgerufen.

Aufgrund der Tatsache, dass oftmals mehrere Teilnehmer dieselben Daten zu

unterschiedlichen Zeiten benötigen, ist eine Speicherung dieser Daten

unausweichlich.

Es existieren bereits viele proprietäre Schnittstellen, die gemeinsam ein großer

Nachteil vereint. Allesamt sind nicht zu anderen Schnittstellen kompatibel und eine

Anreicherung fremder Daten oder der Zugriff auf andere Schnittstellen ist nicht

möglich. Die OPC Historical Data Access-Schnittstelle greift diesen Punkt auf und

liefert eine Standard-Schnittstelle.

Man unterscheidet bei diesem Standard zwei Typen von Servern:

Simple Trend Data Server

Complex data compression and analysis server

Der wesentliche Unterschied beider Varianten liegt darin, dass die erst genannte

Server-Variante Rohdaten speichert, wohingegen die zweite Variante sowohl die

Rohdaten speichert, als auch eine Analyse dieser vornimmt. Zu nennen wäre da

Mittelwertbildung, Ermittlung von Minima- und Maxima-Werten, u.v.m.


17

3.4 OPC Commands

OPC findet bereits breite Anwendung in der Bereitstellung von Automati-

sierungsinfrastrukturen und Softwareschnittstellen. Die Entwicklung der letzten

Jahre hatte zur Folge, dass bereits heute der OPC-Standard einen großen Bereich im

Daten-Management abdeckt.

Lösungen im Automatisierungsbereich umfassen jedoch nicht ausschließlich den

Transport von Daten und die Verarbeitung [7]. Im Ausführen und Regeln von

Kommandos, im Folgenden auch commands genannt, liegt ein weiterer Bereich, den

auch der OPC-Standard abdeckt.

Die OPC Foundation spricht von commands, wenn bestimmte Aktionen eine

Änderung eines Zustandes beim Server oder bei einem Automatisierungsgerät her-

vorrufen. Gerade diese Aktionen nehmen im Prozess oft mehr Zeit in Anspruch, als

das Lesen oder Schreiben von Daten [7]. Ein Nutzer bzw. implizit der Client kann

nur Information an den Server senden, wenn zuvor ein Kommando gestartet wurde.

Welche Rolle spielt nun der OPC-Standard bei dieser Sichtweise? Der OPC-Standard

bietet eine Informationsschnittstelle, die es ermöglicht Kommandos (auch Methoden

genannt) auf Seiten des Servers zu ermitteln und zu verstehen. Die OPC Foundation

spricht von „understanding“, gemeint ist vielmehr die Wirkung der Methode und

nicht die Semantik dahinter, daher wäre der Ausdruck von „making an impact“

angebrachter.

Der Client erhält die Information von welcher Ebene die Methode kommt (OPC-DA,

OPC-A&E,…). Methoden werden dahingehend in zwei Kategorien eingeordnet:

Global level (Methoden, die zum Server selber gehören oder zur

Infrastruktur, die der Server abdeckt)

Sub level (Methoden, die zu einer Infrastruktur hinter dem Server gehören)

Beschreibungen dieser Methoden werden ebenso zur Verfügung gestellt, wie die

Methoden selber. Die Beschreibung eines Kommandos oder einer Methode

beinhaltet Informationen über Vorbedingungen, Eingangs- und Ausgangsparameter

und natürlich wie die Methode vom Server ausgeführt wird. Für diese Art der

Beschreibung sind Zustandsdiagramme prädestiniert und finden dahingehend auch

ihre Anwendung.


18

OPC Commands bietet einen Basis-Zustandsautomaten (endlicher Automat) an, der

je nach Erfordernis der Methode geändert und erweitert werden kann. Neben der

Informationsschnittstelle existiert darüberhinaus auch ein sog. Command execution

interface, also eine Schnittstelle die die Ausführung der Methode veranlassen kann.

Wie bereits erwähnt kann die Ausführung synchron oder asynchron erfolgen. Die Art

der Kommunikation wurde bereits in Kapitel 2.1 und auch Kapitel 3.1 erwähnt. In

Bezug auf dieses Kapitel ist noch zu ergänzen, dass die zurückgelieferten Daten, wie

es beim Abonnieren als auch beim Pollen der Fall ist durch OPC commands neben

den eigentlichen Nutzdaten auch Reportdaten enthalten. Reportdaten enthalten

Informationen über die Transition, also über den Übergang von einen in den anderen

Zustand und auch die damit verbundenen Informationen über Ereignisse bzw. events.

Wie bereits ebenso erwähnt legt der Client fest, über welche events er informiert

werden möchte.

Zusammenfassend lässt sich sagen, OPC commands dient

der Klärung über Vorbedingungen von Methoden (Was wird für die

Ausführung benötigt?),

der Information über die Wirkung dieser Methode (Was passiert nach Aufruf

der Methode?),

dem Client o.a. zur Findung und Darlegung von Bedingungen für den Aufruf

(Wer kann die Methode wann aufrufen?)

und es dient letztlich der Klärung wie diese Methode in ihrer Ausführung

arbeitet.

3.5 OPC XML Direct Access

Die jüngste Spezifikation von OPC wurde im Jahre 1999 erstmalig erwähnt. Im Juli

2003 wurde das erste Release 1.0 veröffentlicht, um im Dezember des Jahres 2004

durch die Version 1.01 mit marginalen Änderungen erweitert zu werden.

Neue Standards in der Informationstechnologie sog. Web Services führten zu dieser

Spezifikation. Zu diesen Standards zählen [1]:

XML

XML Schema

SOAP


19

UDDI

Der Hintergrund dieser Standards ist der plattformübergreifende Zugriff auf Daten

verschiedener Systeme in Echtzeit. Für diverse Programmiersprachen existieren sog.

Toolkits. Zu nennen wäre auf Windowsbasis das .NET-Framework.

Web Services benötigen keine spezielle Kommunikationsinfrastruktur. HTTP auf

TCP/IP ist derzeit der am häufigsten genutzte Transportweg. Somit kann durch die

Nutzung von Web Services die Abhängigkeit von Windowsplattformen bei OPC

gelöst werden.

Der externe Zugriff auf Web Services erfolgt durch Dateien, welche in einer sog.

Web Service Description Language (WSDL), basierend auf XML, verfasst sind.

WSDL beschreiben nur das externe Verhalten und geben keine Informationen über

interne Zusammenhänge der Services.

Anwendungen, die Web Services nutzen, kommunizieren untereinander über das

Simple Object Access Protocol (SOAP). SOAP nutzt XML um die Informationen in

das Protokoll einzubinden und damit das HTTP und damit auch TCP/IP nutzen zu

können.

Zusammenfassend lässt sich sagen, dass SOAP innerhalb des TCP/IPs läuft und es so

ermöglicht wird verschiedene andere Netzwerk-Protokolle nutzbar zu machen. Bild

3.5 soll dies verdeutlichen.

Bild 3.5: Infrastruktur des OPC XML DAs [7]


20

In der Konsequenz bedeutet dies, dass nur zwei Bedingungen erfüllt sein müssen,

damit Automatisierungsgeräte Web Services nutzen können:

1. HTTP- und

2. XML-Unterstützung

So ist es auch möglich OPC XML DA über das Internet ausführbar zu machen.

Das .NET-Framework basiert bei der Kommunikation nicht mehr auf DCOM, sodass

in Zukunft damit zu rechnen ist, dass OPC eine andere Plattform erhält. Die .NET-

Plattform bietet eine sehr umfangreich Unterstützung von Web Services, sodass

zukünftig neue OPC-Spezifikationen auf Microsofts .NET-Framework bauen

werden. In Bild 3.6 ist die neue Systemstruktur zu erkennen.

Bild 3.6: Systemumgebung von OPC-XML Direct Access

3.5.1 XML oder DCOM?

Grundlegender Unterschied beider Systeme ist die Art der übertragenen Information.

DCOM überträgt binäre Information, wohingegen bei OPC XML DA die Daten

textuell mit zusätzlichen Strukturelementen übertragen werden. Diese Tatsache

beeinflusst natürlich die Performance des Systems. Die in Bild 3.3 und Bild 3.4 auf

Seite 14 gezeigte Aktualisierungszeit variiert dabei.


21

Bild 3.7: Vergleich der Übertragungszeiten bei XML und DCOM [8]

Die Messungen aus Bild 3.7 wurden für synchrones Lesen (Pollen) ermittelt. Trotz

der verlangsamten Geschwindigkeit für OPC XML DA sind die gemessenen Zeiten

für nahezu alle Automatisierungsapplikationen ausreichend schnell, um echtzeitfähig

betrieben zu werden.

Es wurde die Plattformunabhängigkeit bei OPC XML DA angesprochen, somit ist

der logische nächste Schritt ein Vergleich von OPC XML DA unter verschiedenen

Plattformen. Nachfolgend wird Linux und Windows betrachtet.

Bild 3.8: Vergleich von OPC XML DA unter Linux und Windows [8]

Der Vergleich beider Plattformen fällt positiver für die Linux-Plattform aus, jedoch

nicht signifikant.

Abschließend wird nun noch der angesprochene Einsatz von OPC XML DA unter

Verwendung des TCP/IPs im Internet untersucht. Es wurde ein Linux OPC-Server

verwand, um den Vergleich zwischen Internet und Intranet herstellen zu können.

0

100

200

300

400

500

600

700

800

0 200 400 600 800 1000 1200

t in m

s

Anzahl der Items

DCOM DA

XML DA

0

100

200

300

400

500

600

700

800

0 200 400 600 800 1000 1200

t in m

s

Anzahl der Items

Linux OPC XML DA

Windows OPC XML DA


22

Bild 3.9: Vergleich von OPC XML DA im Intranet und Internet [8]

Es lässt sich mit steigernder Anzahl von Items erkennen, dass die Zeiten einen

stärkeren Unterschied aufweisen als bei weniger Items. Die Zeiten, die für das

Senden und Empfangen hier benötigt wurden, liegen weit entfernt von einer

Echtzeitfähigkeit. Man kann im Durchschnitt davon ausgehen, dass bei 1000 Items

ein Client bei OPC XML DA im Durchschnitt 40 kB sendet und ca. 128 kB

empfängt.

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

0 200 400 600 800 1000 1200

t in m

s

Anzahl der Items

Intranet

Internet

OPC für Prozessleitsysteme - 4 Industrielles Anwendungsbeispiel

23

4 Industrielles Anwendungsbeispiel

Im Folgenden wird der Einsatz der OPC-Technologie mit einer herkömmlichen

proprietären Lösung verglichen und anschließend bewertet. Als Quelle der Daten ist

[6] zu nennen.

4.1 Aufgabenstellung

In der Chemieindustrie besitzt ein Kunde drei Datenquellen und möchte mit drei

verschiedenen Applikationen kommunizieren. Gesucht sind eine kostengünstige

Realisierung sowie eine geringe Auslastung der Steuerung.

Als Clients sind zu nennen:

MMI (Wonderware InTouch)

Prozessdatenspeicher inkl. Prozessdatenanalyse in Form eines Servers

(Honeywell PHD)

Sensordatenüberwachung und -aufnahme/Monitoring (BNC DM2000)

Als Datenquellen stehen zur Verfügung:

PLC/SPS (Triconex Tricon)

Excel-Arbeitsmappe

Sensor (BNC Data)

4.2 Lösungsansatz

Um einen Vergleich zu ermöglichen, wird zunächst der herkömmliche

Lösungsansatz betrachtet. Bild 4.1 zeigt die benötigte Infrastruktur, wie sie ohne

OPC nötig wäre.

Es sind bei nur je drei verschiedenen Clients und Datenquellen neun Schnittstellen

(Treiber) nötig, damit eine Kommunikation untereinander aufgebaut werden kann.

Darüberhinaus benötigt jede Quelle drei Clientanbindungen. Es handelt sich hierbei

um ein möglichst einfaches, überschaubares Beispiel. Adaptiert man die eben

genannten Tatsachen auf ein reales Prozessleitsystem im Bereich der

Automatisierung, wird das Ausmaß an Schnittstellen und Anbindungen schnell

ersichtlich.


24

Bild 4.1: Herkömmlicher Lösungsansatz [6]

Darüberhinaus ist hierbei noch die Problematik zu bedenken, dass es im Normallfall

nicht möglich ist mehrere Treiber bei der proprietären Lösung auf einen PC arbeiten

zu lassen.

Es existiert keine geordnete Kontrolle der Datenzugriffe. Wann Daten abgefragt

wurden, wie oft und wie viel bleibt hier unbeantwortet.

Abstraktes Analogon:

Person X steht vor einer Gruppe von Menschen, die Gruppe besteht aus 8 Personen,

alle stellen Fragen zur gleichen Zeit an Person X.

Die Problematik lässt sich an fünf Punkten beschreiben:

Wer bekommt seine Antwort?

Wann bekommt man eine Antwort?

Fragen werden überhört und an bekommt keine Antwort!

Unwichtige Fragen können vor wichtigen beantwortet werden!

Person X verliert nach gewisser Zeit den Überblick

So ist es in ähnlicher Weise möglich das komplette System aus Bild 4.1 bei erhöhtem

datenaufkommen lahm zu legen.

Betrachtet man nun die Lösung dieser Aufgabe mit Hilfe von OPC, ergibt sich

folgendes Bild.


25

Bild 4.2: Lösung mit OPC [6]

Die Erfordernis von drei verschiedenen OPC-Servern mag etwas ungewöhnlich

anmuten, dabei ist jedoch folgendes zu berücksichtigen: Da es sich um ein

standardisiertes Konzept handelt, benötigt man nur einen Server aus Hardwaresicht.

Das heißt anschaulich, dass ein Server (Hardware) als dreifacher OPC-Server

(Software) fungiert. OPC ermöglicht den parallelen Betrieb von mehreren OPC-

Servern sowie -Clients.

Man hat nun eine Datenschnittstelle pro Quelle mit je einem OPC-Server. Das

System benötigt nur einen OPC-Client und die Kommunikation würde über OPC DA

erfolgen. Der Zugriff erfolgt demnach über die Server. Gebündelte Anfragen stellt

der Server an das Gerät, das führt zu einem entlasteten System und strukturiertem

Datenaufkommen.

4.3 Finanzielle Sichtweise

Nachfolgend wird kurzer ein Blick auf die finanziellen Hintergründe für die

Umsetzung der in Kapitel 4.2 beschriebenen Lösungen geworfen. Folgende Daten

entstammen der FA. MatrikonOPC [6] und sind als Anhaltwerte zu verstehen, um die

Größenordnungen für die Umsetzungen dieses Beispiels einordnen zu können.


26

Bild 4.3: Finanzielle und zeitliche Sicht der Lösungen [6]

Wie man in Bild 4.3 erkennt ist die Umsetzung der OPC-Lösung wesentlich

schneller und vor allem kostengünstiger. Das bedeutet neben den Vorteilen im

Betrieb der Anlage besticht die OPC Lösung auch im Bereich der Anschaffung und

Umsetzung durch geringere Kosten und schnellere Umsetzung.

OPC für Prozessleitsysteme - 5 Literaturverzeichnis

27

5 Literaturverzeichnis

[1] Kon-Cept Management Information Services GmbH - OLE for process control (Publikation), http://www.kon-cept.at, Mai 2008

[2] OPC Task Force - OPC Overview V1.0 (Publikation), 27. Oktober 1998

[3] Weber, Michael - DCOM (Skript), Universität Ulm, Wintersemester 2000/2001

[4] Softing AG - OPC-Spezifikationen, Frank Iwanitz, Zugriff: Juni 2009

[5] Siemens AG - Step 7 Produktinformationen und Systembeschreibungen, http://support.automation.siemens.com, Zugriff: Juni 2009

[6] Matrikon Deutschland AG - Was ist OPC?, Silvia Heimeier, Zugriff: Juni 2009

[7] Praxis Profiline – OPC2004, Vogel Industrie Medien GmbH & Co. KG

[8] Iwanitz, Frank - XML-DA opens windows beyond the firewall, The industrial ethernet book, http://ethernet.industrial-networking.com, Zugriff: Juli 2009

Documents

OPC für Prozessleitsysteme - ostfalia.de · SCADA Supervisory control and data acquisition SOAP Simple Object Access Protocol SPS Speicherprogrammierbare Steuerung TCP/IP Transmission