OPC für Prozessleitsysteme

Transcription

Fachhochschule Braunschweig/Wolfenbüttel
Fachbereich Elektrotechnik
Leittechnik
OPC für Prozessleitsysteme
Bearbeiter:
Florian Rudolph
20563048
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 I
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 II
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
III
OPC für Prozessleitsysteme - 1 Einführung
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 Prozessleitsystem 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
4
OPC für Prozessleitsysteme - 1 Einführung
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.
5
OPC für Prozessleitsysteme - 2 Prinzip und Funktion
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 OPCSchnittstelle.
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 OPCStandard 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]
6
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
7
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.
8
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.
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
21
[default] interface ICount;
};
22 };
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
9
eine Ausnahme auslöst, übergibt die Software-Plattform HRESULT an den COMClient. 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:
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 }
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.
10
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 }
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.
11
OPC für Prozessleitsysteme - 3 Schnittstellen und Spezifikationen
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)
12
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 Automatisierungsgerä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).
13
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.
Wertänderung
Wertänderung
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].
14
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 ungewöhnlicher Zustand d.h. ein nicht erwartetes Ereignis.
Kurzbeispiel:
Der Baustein FC101 einer S7 SPS hat die Aufgabe bzw. Funktion den Ausgangsbereich 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
15
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.
16
3.4 OPC Commands
OPC findet bereits breite Anwendung in der Bereitstellung von Automatisierungsinfrastrukturen 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 hervorrufen. 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.
17
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
18

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]
19
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 .NETPlattform 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.
20
800
700
t in ms
600
500
DCOM DA
400
XML DA
300
200
100
0
0
200
400
600
800
1000
1200
Anzahl der Items
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.
800
Linux OPC XML DA
Windows OPC XML DA
700
t in ms
600
500
400
300
200
100
0
0
200
400
600
800
1000
1200
Anzahl der Items
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.
21
t in ms
20000
18000
16000
14000
12000
10000
8000
6000
4000
2000
0
Intranet
Internet
0
200
400
600
800
1000
1200
Anzahl der Items
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.
22
OPC für Prozessleitsysteme - 4 Industrielles Anwendungsbeispiel
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.
23
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.
24
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 OPCServern 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.
25
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.
26
OPC für Prozessleitsysteme - 5 Literaturverzeichnis
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
27

OPC für Prozessleitsysteme

Transcription

Similar documents

- Schule An der Wicke

Datafox BDE-MasterIV, Prospekt CI4 V2.cdr

KL1512

Produkt: Softwaretool taraVRcontrol

Bedienungshandbuch

Seite 18-19

Die Emnid-Umfrage von Februar / März 2011 Ein

Wie kriege ich Hauptspeicher?_20141113114814

GMP-Ausblick: Das erwartet die GMP-Welt in 2015 - GMP

Rheinisches Zahnärzteblatt 10/2001

Apex und JasperReports – ein starkes Team mit dem JR

Flyer

QUARK UND LOUIS VUITTON VERBINDEN INNOVATION UND