SIMATIC NET OPC UA Server Applikationsbeschreibung ......von OPC UA Clients in C# unter .NET sammeln...

Applikationen & Tools

Answers for industry.

Deckblatt

Programmierung eines Meldesystems für OPC UA Alarms & Conditions mit .NET C# für den SIMATIC NET OPC UA Server SIMATIC NET OPC UA Server

Applikationsbeschreibung Dezember 2011

2 .NET OPC-UA A&C Client

V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Siemens Industry Online Support

Dieser Beitrag stammt aus dem Siemens Industry Online Support. Durch den folgenden Link gelangen Sie direkt zur Downloadseite dieses Dokuments:

http://support.automation.siemens.com/WW/view/de/26548467

Vorsicht: Die in diesem Beitrag beschriebenen Funktionen und Lösungen beschränken sich überwiegend auf die Realisierung der Automatisierungsaufgabe. Bitte beachten Sie darüber hinaus, dass bei Vernetzung Ihrer Anlage mit anderen Anlagenteilen, dem Unternehmensnetz oder dem Internet entsprechende Schutzmaßnahmen im Rahmen von Industrial Security zu ergreifen sind. Weitere Informationen dazu finden Sie unter der Beitrags-ID 50203404.

http://support.automation.siemens.com/WW/view/de/50203404.

Bei Fragen zu diesem Beitrag wenden Sie sich bitte über folgende E-Mail-Adresse an uns:

mailto:[email protected]

Nutzen Sie auch aktiv unser technisches Forum aus dem Service & Support Portal zu diesem Thema. Bringen Sie Fragen, Anregungen oder Probleme mit ein und diskutieren Sie diese zusammen mit unserer starken Forengemeinde:

http://www.siemens.de/forum-applikationen

http://support.automation.siemens.com/WW/view/de/26548467�


mailto:[email protected]�

http://www.automation.siemens.com/WW/forum/guests/Conference.aspx?ForumID=229&Language=de�

.NET OPC-UA A&C Client V 1.0, Beitrags-ID: 26548467 3

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

SIMATIC .NET OPC-UA A&C Client

OPC UA Alarms & Condition Beispiel für SIMATIC NET OPC UA Server

Automatisierungsaufgabe

1

Automatisierungslösung

2

Grundlagen

3 Funktionsmechanismen der Client Applikation

4

Funktionsmechanismen der S7 Applikation

5

Konfiguration und Projektierung

6

Installation und Inbetriebnahme

7

Bedienung der Applikation

8

Weitere Hinweise, Tipps und Tricks, etc.

9

Literaturhinweis

10

Historie

11

Gewährleistung und Haftung


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Gewährleistung und Haftung Hinweis Die Applikationsbeispiele sind unverbindlich und erheben keinen Anspruch auf

Vollständigkeit hinsichtlich Konfiguration und Ausstattung sowie jeglicher Eventualitäten. Die Applikationsbeispiele stellen keine kundenspezifischen Lösungen dar, sondern sollen lediglich Hilfestellung bieten bei typischen Auf-gabenstellungen. Sie sind für den sachgemäßen Betrieb der beschriebenen Produkte selbst verantwortlich. Diese Applikationsbeispiele entheben Sie nicht der Verpflichtung zu sicherem Umgang bei Anwendung, Installation, Betrieb und Wartung. Durch Nutzung dieser Applikationsbeispiele erkennen Sie an, dass wir über die beschriebene Haftungsregelung hinaus nicht für etwaige Schäden haftbar gemacht werden können. Wir behalten uns das Recht vor, Änderungen an diesen Applikationsbeispielen jederzeit ohne Ankündigung durchzuführen. Bei Abweichungen zwischen den Vorschlägen in diesem Applikationsbeispiel und anderen Siemens Publikationen, wie z.B. Katalogen, hat der Inhalt der anderen Dokumentation Vorrang.

Für die in diesem Dokument enthaltenen Informationen übernehmen wir keine Gewähr.

Unsere Haftung, gleich aus welchem Rechtsgrund, für durch die Verwendung der in diesem Applikationsbeispiel beschriebenen Beispiele, Hinweise, Programme, Projektierungs- und Leistungsdaten usw. verursachte Schäden ist ausgeschlossen, soweit nicht z.B. nach dem Produkthaftungsgesetz in Fällen des Vorsatzes, der groben Fahrlässigkeit, wegen der Verletzung des Lebens, des Körpers oder der Gesundheit, wegen einer Übernahme der Garantie für die Beschaffenheit einer Sache, wegen des arglistigen Verschweigens eines Mangels oder wegen Verletzung wesentlicher Vertragspflichten zwingend gehaftet wird. Der Schadens-ersatz wegen Verletzung wesentlicher Vertragspflichten ist jedoch auf den vertragstypischen, vorhersehbaren Schaden begrenzt, soweit nicht Vorsatz oder grobe Fahrlässigkeit vorliegt oder wegen der Verletzung des Lebens, des Körpers oder der Gesundheit zwingend gehaftet wird. Eine Änderung der Beweislast zu Ihrem Nachteil ist hiermit nicht verbunden.

Weitergabe oder Vervielfältigung dieser Applikationsbeispiele oder Auszüge daraus sind nicht gestattet, soweit nicht ausdrücklich von Siemens Industry Sector zugestanden.

Vorwort


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

26

548

467

_OP

CU

A_A

C_

DO

KU

_V

1_0_

d.d

oc

Vorwort

Ziel der Applikation

Ziel dieser Applikation ist es dem Programmierer eines individuellen Meldesystems einen umfassenden Überblick über die Verwendung der Kommunikationsschnittstelle von OPC UA zu liefern, die die Daten, Alarme und Diagnoseinformationen aus der SIMATIC S7 Steuerung anbietet. Sie lernen die verwendeten Komponenten, Standard Hard- und Softwarekomponenten, sowie eigens erstellte Anwendersoftware kennen.

Dokumentstruktur

Die folgende Tabelle zeigt die einzelnen Kapitel dieses Dokuments, welche Inhalte darin behandelt werden und an welche Leser es sich richtet.

Nr Kapitel Inhalt Leser

1. Automatisierungs-aufgabe

Übersicht der Aufgabe dieses Beispiels

Alle

2. Automatisierungslösung Gesamtlösung diese Beispiels, Kernfunktionalität

Anwender, Inbetriebnehmer, Programmierer

3. Grundlagen OPC und OPC UA, speziell OPC UA Alarms&Conditions

Techniker, Programmierer

4. Funktionsmechanismen der Client Applikation

Softwarebeschreibung der Oberfläche, Klassendiagramme

Programmierer

5. Funktionsmechanismen der S7 Applikation

Alarme in der S7-300 und 400 und wie sie verwendet werden

SPS Programmierer, Projektierer, Engineering

6. Konfiguration und Projektierung

Konfigurieren und laden der S7-Stationen und der PC Station mit OPC Server

Inbetriebnehmer

7. Installation und Inbetriebnahme

Installationsanweisung, Schnellinbetriebnahme

Anwender, Inbetriebnehmer

8. Bedienung der Applikation

Funktionen der Oberfläche des UA A&C Client

Anwender

9. Weitere Hinweise, Tipps und Tricks, etc.

Alle

10. Literaturhinweis Literatur, Internetlinks, Weiterführende Information

Alle

11. Historie Versionen diese Dokuments

Alle

Inhaltsverzeichnis


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Inhaltsverzeichnis Gewährleistung und Haftung...................................................................................... 4 Vorwort.......................................................................................................................... 5 1 Aufgabe .............................................................................................................. 8

1.1 Übersicht .............................................................................................. 9 1.2 Anforderungen.................................................................................... 10

2 Lösung.............................................................................................................. 11 2.1 Übersicht Gesamtlösung.................................................................... 11 2.2 Beschreibung der Kernfunktionalität .................................................. 12

Abgrenzung ........................................................................................ 15 2.3 Verwendete Hard- und Software-Komponenten ................................ 16 2.4 Alternativlösungen.............................................................................. 17

3 Grundlagen....................................................................................................... 18 3.1 Grundlagen OPC................................................................................ 18 3.2 Grundlagen von OPC Unified Architecture ........................................ 20 3.2.1 OPC UA Spezifikationen .................................................................... 20 3.2.2 Aufbau des OPC UA Server Adressraums ........................................ 22 3.2.3 Schnittstelle für den Zugriff auf den OPC UA Server

Adressraum ........................................................................................ 25 3.2.4 Protokolle und Sicherheitsmechanismen........................................... 28 3.3 Grundlagen OPC UA Ereignismeldungen und Alarme ...................... 33

4 Funktionsmechanismen der Client Applikation ........................................... 38 4.1 OPC UA Client API............................................................................. 41 4.2 OPC UA Alarms&Conditions Client.................................................... 43 4.2.1 Oberfläche.......................................................................................... 43 4.2.2 Klassendiagramm............................................................................... 44 4.2.3 Sequenzdiagramme ........................................................................... 47

5 Funktionsmechanismen der S7 Applikation................................................. 52 5.1 Erweiterte Alarmprojektierung ab STEP 7 V5.5................................. 52 5.2 Alarme der SIMATIC S7 Station ........................................................ 55 5.3 Abbildung auf OPC UA Eventfelder ................................................... 58 5.4 S7 Programm dieses Beispiels .......................................................... 61 5.5 Beispielhafte Projektierung eines SCAN Alarms ............................... 63 5.6 Beispielhafter Aufruf eines ALARM_8P ............................................. 66 5.7 Beispielhafte Projektierung von Systemfehlermeldungen.................. 69 5.8 Hinweise zur Alarmprojektierung der S7-300..................................... 71

6 Konfiguration und Projektierung ................................................................... 73 6.1 Konfiguration der SIMATIC S7 Stationen........................................... 73 6.2 Konfiguration der PC Station.............................................................. 76 6.3 Konfiguration der OPC UA Security ................................................... 80 6.3.1 OPC UA Remote Kommunikation ...................................................... 80 6.3.2 Zertifikatsspeicher .............................................................................. 81 6.3.3 Authentication, SecurityPolicy und MessageSecurtityMode.............. 86

7 Installation und Inbetriebnahme .................................................................... 89 7.1 Installation der Hard- und Software.................................................... 89 7.2 Installation der Applikationssoftware.................................................. 91 7.3 Inbetriebnahme der SIMATIC S7 Stationen....................................... 92 7.4 Inbetriebnahme der PC Station.......................................................... 94

8 Bedienung der Applikation............................................................................. 97

Inhaltsverzeichnis


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

9 Weitere Hinweise, Tipps und Tricks, etc. .................................................... 102 10 Literaturhinweis ............................................................................................. 103

10.1 Literaturangaben .............................................................................. 103 10.2 Internet-Link-Angaben...................................................................... 103

11 Historie............................................................................................................ 104

1 Aufgabe


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

1 Aufgabe

Veranlassung

Mit OPC Unified Architecture (UA) existiert im SIMATIC NET OPC Server eine zusätzliche, komfortable und performante Möglichkeit der Prozessankopplung. Diese Ankopplung von PC-Systemen an SIMATIC S7, wird sukzessive die bestehende OPC Data Access (DA) und Alarms & Events (A&E) Funktionen ersetzen.

Die wesentlichen Vorteile von OPC UA gegenüber herkömmlichen OPC Schnittstellen sind:

• Kommunikation über das Internet und über Firewalls hinweg.

• Optimiertes, robustes und fehlertolerantes Protokoll mit integrierten Sicherheitsmechanismen.

• OPC UA kann direkt in Anwendungen auf verschiedenen Betriebssystemen mit verschiedenen Programmiersprachen integriert werden.

• Alle OPC Informationen wie Daten oder Alarme sind in einem Namensraum integriert.

• Informationen können mit objektorientierten Mitteln beschrieben werden.

Zielgruppe

Diese Applikation ist für Endanwender gedacht, die einen fundierten Einstieg in diese Technologie benötigen und die Erfahrung mit der professionellen Erstellung von OPC UA Clients in C# unter .NET sammeln wollen.

Inhalt

Hier verschaffen Sie sich einen Überblick über die Verwendung der Kommunikationsschnittstelle OPC UA, die Daten, Alarme und Diagnoseinformationen aus SIMATIC S7 Steuerungen anbietet. Sie lernen die verwendeten Komponenten, Standard Hard- und Softwarekomponenten, sowie eigens erstellte Anwendersoftware kennen.

Die Anwendersoftware bietet Beispiele für die Erstellung von OPC UA Alarm Clients mit C# unter .NET. Enthalten sind eine vereinfachte, wieder verwendbare API und eine Beispielapplikation für ein Meldesystem mit einer komfortablen Oberfläche. Das Beispiel gibt auch Hinweise zur Optimierung und Erweiterung der Anwendung.

1 Aufgabe

1.1 Übersicht


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

1.1 Übersicht

Einführung/Einleitung

Zur Realisierung einer Datenkopplung werden heute bevorzugt standardisierte Mechanismen verwendet, um einen derartigen Datenaustausch unabhängig vom eingesetzten Bussystem bzw. Protokoll oder sogar Hersteller zu halten. Auch für den Austausch von Ereignis- und Alarmmeldungen wird ein standardisierter Mechanismus für die Anbindung verschiedener Subsysteme verwendet werden. Dieser Mechanismus soll neben einer lokalen Kommunikation auch den Informationsaustausch über Firewalls und das Internet ermöglichen, was auch eine Benutzerauthentifizierung und eine verschlüsselte Datenübertragung erfordert.

Übersicht über die Automatisierungsaufgabe

Folgende Abbildung zeigt einen Überblick über die Automatisierungsaufgabe.

Abbildung 1-1

PC Station

PC Applikation

Internet

Informations-ServerOPC Unified Architecture

Prozess / Produktionsanlage

Informations-ServerOPC Unified Architecture

Prozess / Produktionsanlage

Meldesystem

Anzeige Quittierung

Beschreibung der Automatisierungsaufgabe

Im Automatisierungssystem soll der OPC UA Server als Informationsserver betrachtet werden, der einzelne Komponenten aber auch die gesamte Anlage abbilden und beschreiben kann. Durch den mit Zertifikaten geprüften und sicheren, verschlüsselten Zugriff ist auch eine Ankopplung von weiteren Standorten möglich.

Bei der Automatisierungsaufgabe sollen Ereignismeldungen und Alarme aus den Automatisierungssystemen in einem zentralen Meldesystem auf einer PC Station erfasst werden. Die PC Station sammelt die Alarme auf und stellt sie reihenfolgerichtig dar. Weiterhin kann die PC Station Alarme quittieren falls dies

1 Aufgabe


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

erforderlich ist. Die Kommunikation zwischen den Automatisierungssystemen und der PC Station soll über Ethernet erfolgen.

Die Applikation soll folgende Funktionalitäten beinhalten:

• Auswahl des Servers inklusive Sicherheitseinstellungen.

• Anzeige der Meldungen und Alarme inklusive Begleitwerte von den verschiedenen Stationen in einer Liste.

• Anzeige von Standard- und Anwenderdefinierte Diagnosemeldungen.

• Anzeige von Symbolbezogene Meldungen.

• Auswahl von Begleitwerten.

• Bei Bedarf eine Quittierung von Einzelmeldungen.

Eine datentechnische Weiterverarbeitung (z.B. Speicherung in einer Datenbank, o.ä.) wird in dieser Applikation nicht beschrieben.

1.2 Anforderungen

Anforderungen durch die Automatisierungsaufgabe

Der Alarm- und Eventmechanismus wird nicht zur zyklischen Übertragung großer Datenmengen verwendet, vielmehr werden wichtige Ereignisse aus der Steuerung gemeldet, ohne dass durch Pollen der PC Station auf der Steuerung unnötig Kommunikationslast erzeugt wird.

Anforderung an die Steuerung

Die Steuerung sollte in der Lage sein, bei unerwarteten Ereignissen aus dem Anwenderprogramm heraus aktiv eine Meldung schicken zu können, ohne dass die PC Station die Steuerung dafür pollen muss.

Die Steuerung muss eine Kommunikationsmöglichkeit, bevorzugt über Ethernet, zu einem zentralen Meldesystem haben.

Anforderungen an die PC Station

Die PC Station muss die nötige physikalische Anbindung mit entsprechender Hardware und Software zur Kommunikation mit der Steuerung enthalten.

Die Applikation zur Anzeige und Quittierung von Ereignismeldungen soll eine standardisierte Schnittstelle zur Kommunikationssoftware verwenden, um beliebige Ereignisquellen einbinden zu können.

2 Lösung

2.1 Übersicht Gesamtlösung


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

2 Lösung

2.1 Übersicht Gesamtlösung

Übersicht

Die folgende Abbildung zeigt schematisch die wichtigsten Komponenten der Lösung:

Abbildung 2-1

S7-300 Station

CPU 315-2 DPCP 343-1

S7-400 Station

CPU 416-3 PN/DPCP 443-1 Adv.

SIMATIC PC Station

Std. Ethernet CardSIMATIC NET CD 2008 SP2 (OPC UA Server)SOFTNET S7 IE/LeanSTEP 7 V 5.5 SP1Visual Studio 2008 (C#)

Ind. Ethernet

OPC UA Client- Meldesystem- Anzeige- Quittierung

Aufbau

Eine PC Station wird über Ethernet mit einer CPU 315-2 PN und einer CPU 414-2 verbunden. Im PC wird eine Standard Ethernetkarte verwendet.

OPC-UA Client Software

Der OPC-UA Client in der PC Station realisiert ein Meldesystem auf Basis von OPC UA mit der Anzeige der Meldungen und der Möglichkeit einer Quittierung. Der Client mit komfortabler Oberfläche demonstriert Ihnen den professionellen Umgang mit wieder verwendbaren C# Klassen für die Implementierung eines .NET basierten OPC UA Clients.

Die Funktionalität dieser Beispiel-Clients wird im nächsten Abschnitt erläutert.

2 Lösung


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

2.2 Beschreibung der Kernfunktionalität

Übersicht

Den Kern der Funktionalität dieses Beispiels bildet der SIMATIC NET OPC UA Server. Dieser vereint die Funktionen und Informationen der klassischen OPC Server für Data Access und Alarm & Events in einem einzigen Namensraum und erlaubt den Zugriff auf die Informationen über eine serviceorientierte Architektur. Dabei ist die Kommunikation auch über das Internet und Firewalls hinweg sicher und performant möglich. Im Bereich der Alarmverarbeitung besitze er die Möglichkeit, Meldungen direkt aus der Steuerung zu empfangen ohne pollend auf die Steuerung zugreifen zu müssen.

Die folgende Abbildung zeigt die Wirkungskette für eine solche Meldung.

Abbildung 2-2

S7 Verbindung

S7 Protokoll

UA TCP

OPC UA Server

Internet

OPC UA Client

OPC UA Client

2

3

ind. Ethernet

ind. Ethernet

CP

U 412-2

DP

CP

443-1

In / Out

E0.3ALARM_8P

1

Anzeige

Anzeige

Tabelle 2-1

Nr. Komponente Beschreibung

1. S7 Station Tritt ein Ereignis auf, z.B. ein Fehlereingang E0.3 wird gesetzt, kann im S7 Programm ein Alarmbaustein aufgerufen werden z.B. ALARM_8P.

2. OPC UA Server Die S7 Station sendet ein Ereignis über das S7 Protokoll an den SIMATIC NET OPC UA Server. Der OPC UA Server setzt die Ereignisse auf OPC UA Events und Alarmobjekte um und stellt die OPC Dienste wie Browse, Read, Event Monitoring und Methodenaufrufe zur Quittierung zur Verfügung.

3. OPC UA Client Der OPC UA Client kann eine sichere Verbindung zum Server aufbauen und Events empfangen und anzeigen.

2 Lösung



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Softwarekomponenten der Applikation (OPC UA .NET Client)

Die folgende Abbildung zeigt die Softwarekomponenten, welche bei der komplexeren Applikation (OPC UA .NET Client) verwendet werden. Dabei stammen der OPC UA Server und die Basisbibliotheken für die OPC UA Kommunikation auf der Clientseite von der SIMATIC NET CD.

Die für die Applikation in C# erstellten Softwarekomponenten können in wieder verwendbare Module und Beispielcode aufgeteilt werden.

Abbildung 2-3

Tabelle 2-2

Modul Beschreibung

OPC UA .NET Stack Der .NET OPC UA Stack von der OPC Foundation für die Realisierung der Netzwerkkommunikation.

.NET Client SDK Das .NET OPC UA Client SDK der OPC Foundation. Die beiden DLLs der OPC Foundation sind Lieferbestandteil der SIMATIC NET CD.

Client API Wiederverwendbare, vereinfachte und auf die Aufgabe zugeschnittene .NET Client API. Sie bietet für Discovery, Session und Subscription Handling wiederverwendbare C# Klassen an.

UA Client Komfortabler OPC Client mit den Funktionen Discovery, Connect, Disconnect, Monitoring von Events, Filtereinstellungen für Events, Auswahl der gelieferten Eventfelder und Quittierung von Alarmen. Allgemeine Funktionen wie Browsen von Areas, Anzeige der verfügbaren Filter und Anzeige der Eventfelder sind in wiederverwendbaren Controls gekapselt.

S7 OPC UA Server Der SIMATIC NET OPC UA Server implementiert die notwendige Serverlogik für Sessions und Subscriptions und die Datenanbindung an die S7 Stationen.

2 Lösung


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Übersicht und Beschreibung der Oberfläche (OPC UA AC .NET Client)

Die folgende Abbildung und Tabelle beschreiben die Oberfläche des OPC UA AC Client Beispiels, mit dem Alarme und Events von einem OPC UA Servers empfangen und Quittiert werden können.

Abbildung 2-4

Tabelle 2-3

Nr. Beschreibung

1. Über die Auswahlliste Endpoints kann der Server ausgewählt werden. Dafür wird die Liste der verfügbaren OPC UA Server vom jeweiligen Netzwerkknoten ermittelt. Der Rechner, auf dem die Liste abgefragt werden soll, kann im Textfeld Node eingegeben werden. Ist das Feld leer, wird die Liste auf dem lokalen Rechner ermittelt. Die URL des OPC UA Servers kann auch manuell eingegeben werden. Die URL setzt sich für den SIMATIC NET OPC UA Server zusammen aus opc.tcp://<Rechnername>:4845.

2. Über den Button Connect kann die Verbindung zum Server auf- bzw. abgebaut werden.

3. Im Hauptfenster kann zwischen 2 Ansichten gewechselt werden: Events: Zeigt alle Events an die empfangen werden. Alarms: Zeigt nur Condition Events an (im Bild sichtbar).

4. Liste der empfangenen Condition Events.

5. Eventfelder zu dem aktuell selektierten Event. Die angezeigten Eventfelder können im Konfigurationsdialog ausgewählt werden.

6. Über das Applikationsmenü können die Eigenschaften der Subscription und die Konfiguration der Filter, Areas und Eventfelder verändert werden. So kann z.B. das Publishing Interval der Subscription geändert werden.

7. Aktueller Status und URL der Verbindung zum Server.

1

3

4

2

5

6

7

2 Lösung



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Vorteile dieser Lösung

Die hier vorgestellte Lösung bietet Ihnen folgende Vorteile:

• Verwendung des internationalen Standards OPC Unified Architecture

• Einfache Realisierung einer Kopplung zu unterschiedlichen Ereignisquellen

• Performante Datenübertragung durch Verwendung der Eventmechanismen auf allen Ebenen der Kommunikation ohne einen pollenden Zugriff

• Investitionsschutz durch einfache Erweiterbarkeit

• Wieder verwendbare Komponenten

• Zugriff über das Internet und durch Firewalls möglich

• Zugriffsrechte können individuell für Benutzer vergeben werden

• Sicherheit mit Zertifikaten, Verschlüsselung und Authentifizierung

Abgrenzung

Diese Applikation enthält keine Beschreibung zur Verarbeitung oder Speicherung der Daten im OPC UA Client z.B. in Datenbanken.

Vorausgesetzte Kenntnisse

Grundlegende Kenntnisse über den Umgang mit dem SIMATIC Konfigurations- und Programmiertool STEP7 sowie der Entwicklungsumgebung Microsoft Visual Studio 2008 und der Programmiersprache C# und objektorientierter Programmierung werden voraus gesetzt.

2 Lösung


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

2.3 Verwendete Hard- und Software-Komponenten

Die Applikation wurde mit den nachfolgenden Komponenten erstellt:

Hardwarekomponenten

Tabelle 2-4

Komponente Anz. MLFB/Bestellnummer

Hinweis

S7-400 CPU 416-3 PN/DP

1 6ES7416-3ER05-0AB0 Es kann auch jede andere S7-400 CPU verwendet werden.

CP 443-1 Advanced 1 6GK7443-1GX20-0XE0 Alternativ kann auch jeder andere S7 fähige Ethernet CP verwendet werden.

S7-300 CPU 315-2DP 1 6ES7315-2AG10-0AB0 Alternativ kann auch jede andere S7-300 mit einem Ethernet CP verwendet werden.

CP 343-1 1 6GK7343-1EX30-0XE0 Alternativ kann auch jeder andere S7 fähige Ethernet CP verwendet werden.

SIMATIC PC Station als OPC UA Server

1 6AG4104-1AA22-0BB0 Standard-PC (z.B. PGs) unter Windows Vista oder Windows XP.

Standard PC als OPC UA Client

1 6AG4104-1AA22-0BB0 Alternativ kann der Client auch lokal auf der SIMATIC PC Station betrieben werden.

Softwarekomponenten

Tabelle 2-5

Komponente Anz. MLFB/Bestellnummer Hinweis

SIMATIC NET CD 2010 (V8.1) SOFTNET S7 IE

1 6GK1704-1LW71-3AA0 6GK1704-1CW71-3AA0

LW=8 S7-Verbindungen (Lean), CW=64 S7-Verbindungen

STEP 7 V5.5 SP1 1 6ES7810-4CC08-0YA5 Zur Projektierung von beidseitigen S7 Verbindungen auf S7 300 / 400 CPUs

Microsoft Visual Studio 2008 SP1

1 Standard Edition Professional Edition

Erhältlich im Microsoft Store (http://emea.microsoftstore.com/DE/Microsoft/Design-+-Entwicklung/Visual-Studio)

2 Lösung

2.4 Alternativlösungen


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Beispieldateien und Projekte

Die folgende Liste enthält alle Dateien und Projekte, die in diesem Beispiel verwendet werden.

Tabelle 2-6

Komponente Hinweis

26548467_OPC_UA_DOKU_v10_d.pdf Dieses Dokument.

OPC_UA_CODE_v10.zip Diese gepackte Datei enthält den OPC UA Client und die Quellen.

OPC_UA_STEP7_v10.zip Diese gepackte Datei enthält das STEP 7 Projekt

2.4 Alternativlösungen

OPC Data Access auf Basis von COM

Die Automatisierungsaufgabe wird heute typischerweise mit der COM basierten klassischen OPC Alarm & Events Schnittstelle gelöst.

Vorteile der Lösung mit COM OPC Alarm & Events:

• Große Verbreitung der Schnittstelle.

• Viele Anwendungen für verschiedene Aufgaben unterstützen die Schnittstelle.

• Einfacher Zugriff für lokale Anwendungen.

Nachteile der Lösung mit COM OPC Alarm & Events:

• Komplizierte DCOM Konfiguration für remoten Zugriff.

• Keine Kommunikation über Firewall- oder Internetgrenzen möglich.

• OPC Clients können nur auf Windows PC Systemen betrieben werden.

• Eingeschränkte Sicherheitsmechanismen und Benutzer-Authentifizierung nur im Rahmen der DCOM Konfiguration.

• Keine benutzerbezogenen Zugriffsrechte möglich.

• Kein gemeinsamer Namensraum mit Data Access

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

3 Grundlagen

Das folgende Kapitel richtet sich an Techniker und Programmierer welche sich einen Überblick über die Grundlagen von OPC Unified Architecture verschaffen wollen.

Das Kapitel beginnt mit einem Überblick über die OPC Foundation und die bisher verfügbaren Standards. Im folgenden Teil werden die Grundlagen des Aufbaus und Inhaltes eines OPC UA Server Adressraumes und die Schnittstelle für den Zugriff auf den OPC UA Server und die dabei eingesetzten Protokolle und Sicherheitsmechanismen erläutert. Im letzten Teil des Kapitels werde die Grundlagen des Alarmmodells und er Alarmverarbeitung in OPC UA beschrieben.

3.1 Grundlagen OPC

Übersicht

Die OPC Foundation (eine Interessenvereinigung namhafter Hersteller für die Definition von Standardschnittstellen) hat in den letzten Jahren eine Vielzahl von Softwareschnittstellen definiert, um den Informationsfluss von der Prozessebene bis zur Managementebene zu vereinheitlichen. Entsprechend der unterschiedlichen Anforderungen innerhalb einer industriellen Anwendung sind in der Vergangenheit verschiedene OPC Spezifikationen entstanden: Data Access (DA), Alarm & Events (A&E), Historical Data Access (HDA) und Data eXchange (DX). Der Zugriff auf Prozessdaten ist in der DA Spezifikation beschrieben, A&E beschreibt eine Schnittstelle für ereignisbasierte Information inklusive Quittierung, HDA beschreibt Funktionen für archivierte Daten und DX definiert eine Server zu Server Querkommunikation.

Basierend auf den Erfahrungen dieser klassischen OPC Schnittstellen hat die OPC Foundation eine neue Plattform mit dem Namen OPC Unified Architecture (UA) definiert. Ziel dieses neuen Standards ist die generische Beschreibung und der einheitliche Zugriff auf alle Informationen die zwischen Systemen bzw. Applikationen ausgetauscht werden müssen. Das schließt die Funktionalität aller bisherigen OPC Schnittstellen mit ein. Außerdem soll die Möglichkeit geschaffen werden, die Schnittstelle nativ in das jeweilige System zu integrieren, unabhängig davon, auf welchem Betriebssystem das System betrieben wird und unabhängig davon, mit welcher Programmiersprache das System erstellt ist.

Dieses Beispiel beschäftigt sich mit der Schnittstelle OPC Unified Architecture. Eine detaillierte Dokumentation befindet sich auf der SIMATIC NET CD. Weitere Informationen sind unter www.opcfoundation.org zu finden.

Was ist OPC

OPC war in der Vergangenheit eine Sammlung von Softwareschnittstellen zum Datenaustausch zwischen PC Anwendungen und Prozessgeräten. Diese Softwareschnittstellen waren entsprechend den Regeln von Microsoft COM (Component Object Model) definiert und damit auf Microsoft Betriebssystemen leicht integrierbar. COM bzw. DCOM (Distributed COM) stellt die Funktionalität der Interprozesskommunikation zur Verfügung und organisiert den Informationsaustausch zwischen Anwendungen, auch über Rechnergrenzen hinweg (DCOM). Ein OPC Client (COM Client) kann damit unter Verwendung von Mechanismen des Microsoft Betriebssystems Informationen mit einem OPC Server (COM Server) austauschen.

http://www.opcfoundation.org/�

3 Grundlagen

3.1 Grundlagen OPC


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Der OPC Server stellt Prozessinformationen eines Gerätes an seiner Schnittstelle zur Verfügung. Der OPC Client verbindet sich mit dem Server und kann auf die angebotenen Daten zugreifen.

Die Verwendung von COM bzw. DCOM führt dazu, dass OPC Server und Clients nur auf einem Windows PC oder im lokalen Netzwerk betrieben werden können und diese die Kommunikation zum entsprechenden Automatisierungssystem meist über proprietäre Protokolle realisieren müssen. Für die Netzwerkkommunikation zwischen Client und Server müssen oft zusätzliche Tunneling Tools eingesetzt werden, um durch Firewalls zu kommen oder um die komplizierte DCOM Konfiguration zu umgehen. Außerdem kann nur mit C++ Applikationen nativ auf die Schnittstelle zugegriffen werden, .NET oder JAVA Applikationen können nur über eine Wrapperschicht zugreifen. Diese Einschränkungen führen in der Praxis zu zusätzlichen Kommunikations- und Softwareschichten, welche den Konfigurationsaufwand und die Komplexität erhöhen.

Durch die große Verbreitung von OPC wird der Standard immer mehr zur generellen Kopplung von Automatisierungssystemen eingesetzt und nicht mehr nur für den ursprünglichen Anwendungsfall als Treiberschnittstelle in HMI und SCADA Systemen für den Zugriff auf Prozessinformationen.

Um die genannten Einschränkungen in der Praxis zu lösen und den zusätzlichen Anforderungen gerecht zu werden, hat die OPC Foundation in den letzten fünf Jahren eine neue Plattform mit dem Namen OPC Unified Architecture definiert, welche eine einheitliche Basis für den Informationsaustausch zwischen Komponenten und Systemen bietet. OPC UA wird auch als IEC 62541 Standard verfügbar sein und bildet damit auch die Basis für andere internationale Standards.

OPC UA bietet die folgenden Features:

• Zusammenfassung aller bisherigen OPC Features und Informationen wie DA, A&E und HDA in einer generischen Schnittstelle.

• Verwendung offener und plattformunabhängiger Protokolle für die Interprozess- bzw. Netzwerkkommunikation.

• Internetzugriff und Kommunikation durch Firewalls.

• Integrierte Zugriffskontrolle und Sicherheitsmechanismen auf Protokoll- und Applikationsebene.

• Umfangreiche Abbildungsmöglichkeiten für objektorientierte Modelle, Objekte können Variablen und Methoden haben und Events feuern.

• Erweiterbares Typsystem für Objekte und komplexe Datentypen.

• Transportmechanismen und Modellierungsregeln bilden die Basis für andere Standards.

• Skalierbarkeit von kleinen embedded Systemen bis hin zu Unternehmensanwendungen und von einfachen DA Adressräumen bis hin zu komplexen, objektorientierten Modellen.

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

3.2 Grundlagen von OPC Unified Architecture

In diesem Kapitel werden die für das Beispiel notwendigen Grundlagen von OPC Unified Architecture erläutert.

3.2.1 OPC UA Spezifikationen

Übersicht

Die OPC UA Spezifikationen sind auf Grund der IEC 62541 Standardisierung in verschiedene Parts aufgeteilt. Abbildung 3-1 zeigt die verschiedenen Parts im Überblick.

Abbildung 3-1

Part 1 bis 7 bilden die Basis der Technologie und die Realisierung von OPC UA Applikationen. Vor allem die Parts 3 bis 5 bilden den Kern des Standards.

Die Parts 8 bis 11 definieren OPC spezifische Informationsmodelle zur Bereitstellung klassischer OPC Informationen wie aktuelle Prozessdaten oder Alarme.

Ergänzende Hilfsmittel sind in Part 12 und 13 definiert.

Darüber hinaus entstehen sogenannte Companion Spezifikationen, die in Zusammenarbeit mit anderen Standardisierungsorganisationen zusätzliche Informationsmodelle auf Basis von OPC UA definieren. Dabei bilden die Modelle und Informationen in anderen Standards die Grundlage und die Companion Spezifikation definiert, wie diese Informationen mit OPC UA beschrieben und transportiert werden.

Hinweis Relevant für diese Applikation sind die Teile drei bis fünf und Teil acht. Die Beschreibung der anderen Teile ist für die Vermittlung eines kompletten Überblicks über die OPC Unified Architecture enthalten.

3 Grundlagen



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Liste der Spezifikationen

Tabelle 3-1 erläutert die Liste der Spezifikation und deren Inhalte. Die für den SIMATIC NET Server aktuell relevanten Spezifikationen sind hervorgehoben.

Tabelle 3-1

Spezifikation Beschreibung

Part 1 – Concepts Dieser nicht normative Teil gibt einen Überblick über den Standard.

Part 2 – Security Die Anforderungen an Security und eine Einführung in die Grundlagen ist in dem ebenfalls nicht normativen zweiten Teil beschrieben.

Part 3 – Address Space Model

Dieser Teil definiert die Grundregeln und Grundelemente für den Aufbau des Adressraumes eines OPC UA Servers. Diese Regeln bilden die Basis für die Informationsmodelle in Part 5, 8 bis 11 und den Companion Spezifikationen.

Part 4 – Services Dieses Dokument definiert als einziger Teil die Schnittstelle für den Zugriff auf alle OPC UA Informationen. Er spezifiziert eine Liste von Methoden, die sogenannten Services. Diese Services sind generisch und bilden die Basis für alle Informationsmodelle.

Part 5 – Information Model Das Basis Informationsmodell definiert die Einstiegspunkte in den Adressraum und grundlegende Typen wie z.B. Datentypen oder Objekttypen. Der Teil bildet zusammen mit Part 3 und 4 den Kern von OPC UA.

Part 6 – Service Mapping Die Services in Part 4 sind unabhängig vom verwendeten Transport-mechanismus definiert. Dieser Teil spezifiziert die Umsetzung der Services auf verschiedene Arten von Serialisierung, Sicherung und Transport-protokollen für die Nachrichten zwischen OPC UA Client und Server. Dieser Teil bildet die Basis für die Implementierung von Kommunikationsstacks und ist für Anwender der Technologie nicht relevant.

Part 7 – Profiles Ein Profil legt eine Untermenge von OPC Funktionalitäten für verschiedene Anwendungsfälle fest, die von einem OPC UA Server angeboten bzw. von einem OPC UA Client genutzt werden können. Dieser Teil definiert die Liste der Profile für OPC UA.

Part 8 – Data Access Dieser Teil definiert Variablentypen, Properties und Quality Status Codes für Prozessdaten. Alle anderen notwendigen Konzepte sind bereits in den Parts 3 bis 5 enthalten.

Part 9 – Alarms and Conditions

Dieser Teil definiert das Modell für die Beschreibung von Zustandsüberwachungen und Prozessalarmen und der Meldung von Statuswechseln über Events. Die notwendigen Konzepte für Events sind bereits in den Parts 3 bis 5 enthalten.

Part 10 – Programs Dieser Teil definiert wie länger laufende Aktionen gestartet und überwacht werden können. Dies geschieht auf Basis von Zustandsmaschinen, deren Handhabung in OPC UA in Part 5 definiert ist.

Part 11 – Historical Access Hier wird der Zugriff auf historische Daten und Events definiert.

Part 12 – Discovery Definiert wie OPC UA Server im Netzwerk gefunden werden können.

Part 13 – Aggregates Dieser Teil definiert Aggregatsfunktionen für die Datenkompression wie z.B. Mittelwert oder Maximalwert über ein Zeitbereich. Die Aggregates können auf aktuelle Daten oder auf historische Daten angewendet werden.

Devices (DI) Diese Companion Spezifikation definiert ein generisches Modell für die Konfiguration und Diagnose von Geräten.

IEC 61131-3 (PLC) Diese Companion Spezifikation definiert ein Mapping des IEC 61131-3 Softwaremodells und der standardisierten Steuerungsprogrammiersprachen auf einen OPC UA Server Adressraum.

Analyzer Device Integration (ADI)

Diese Companion Spezifikation definiert ein Modell für die Konfiguration und Datenanbindung für komplexe Geräte zur Prozessanalyse aufsetzend auf DI

Field Device Integration (FDI)

Diese Companion Spezifikation definiert ein Modell für das komplette Engineering von Feldgeräten auf Basis von Electronic Device Description Language (EDDL) und Field Device Tool (FDT).

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

3.2.2 Aufbau des OPC UA Server Adressraums

Knoten im Adressraum

Ein Knoten im OPC UA Adressraum ist von einem bestimmten Typ wie z.B. Objekt, Variable oder Methode und wird durch eine Liste von Attributen beschrieben. Alle Knoten haben gemeinsame Attribute wie Name oder Beschreibung und spezifische Attribute wie z.B. den Wert einer Variablen. Die Liste der Attribute ist nicht erweiterbar. Zusätzliche Informationen über den Knoten können als Property ergänzt werden. Properties sind eine spezielle Art von Variablen.

Die Knoten sind mit Referenzen untereinander verbunden. Die Referenzen sind typisiert. Es gibt zwei Hauptgruppen, hierarchische Referenzen wie z.B. HasComponent für die Komponenten eines Objektes oder nicht-hierarchische Referenzen wie z.B. HasTypeDefinition für eine Verbindung von einer Objektinstanz zu einem Objekttyp. Ein Beispiel für Knoten und die verbindenden Referenzen bietet Abbildung 3-2.

Abbildung 3-2

Variable

Objekt

Attribute- Name- Beschreibung

Referenzen- HasComponent

- HasComponent

- HasComponent

Attribute- Name- Datentyp- Wert

Referenzen

Methode

Attribute- Name- Beschreibung

Referenzen

Variable

Attribute- Name- Datentyp- Wert

Referenzen

Verfügbare Typen von Knoten im Adressraum

Die definierten Knotentypen sind in Tabelle 3-2 aufgeführt. Die Liste der Typen ist nicht erweiterbar.

Tabelle 3-2

Knotentyp Beschreibung Beispiel

Objekt Ein Objekt dient als typisierte Container für Variablen, Methoden und Events.

Die Objekte, die eine S7 Verbindung repräsentieren, sind immer gleich aufgebaut.

Variable Variablen repräsentieren die Daten von Objekten oder als Property die Eigenschaften eines Knotens.

S7 Variable in einem Datenbaustein.

Methode Methoden sind Komponenten von Objekten und können eine Liste von Eingangs- bzw. Ausgangsparametern haben. Die Parameter werden über definierte Properties beschrieben.

Methode blockRead( ) an einem S7 Verbindungsobjekt mit der ein Baustein aus einer S7 ausgelesen werden kann.

View Views repräsentieren einen Teil des Adressraumes. Der Knoten dient als

Views sind im SIMATIC NET Server nicht vorhanden.

3 Grundlagen



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Knotentyp Beschreibung Beispiel

Einstiegspunkt und als Filter beim Browsen.

Objekttyp Objekttypen liefern Informationen über den Aufbau bzw. die Komponenten eines Objektes.

S7ConnectionType beschreibt die Komponenten die an einem S7 Verbindungsobjekt vorhanden sind.

Variablen Typ

VariablenTypen beschreiben typischerweise, welche Properties bzw. Datentypen an einer Instanz des Typs (Variable) gefunden werden können.

AnalogItemType definiert, dass eine Variable dieses Types die Properties EngineeringUnits und EURange zur Verfügung stellt.

Referenz Typ

Referenz Typen definieren die möglichen Arten von Referenzen zwischen Knoten.

Eine Methode wird von einem Objekt mit HasComponent referenziert.

Datentyp Datentypen beschreiben den Inhalt des Wertes einer Variablen.

Der Wert einer Variablen kann den Datentyp Double haben.

Strukturierung des Adressraums

Die Grundstruktur des OPC UA Adressraums ist in Part 5 definiert. Abbildung 3-3 zeigt einen Teil dieser Struktur und SIMATIC NET spezifische Teile. Die verschiedenen Bereiche sind in

Tabelle 3-3 beschrieben.

Abbildung 3-3

Tabelle 3-3

Nr. Beschreibung

8. Im Verzeichnis Objects sind die Instanzen wie Objekte und Variablen zu finden. Ein Data Access Client findet unter diesem Verzeichnis die Variablen für den Datenzugriff. Neben dem SIMATIC NET spezifischen Verzeichnissen findet man hier auch das Server Objekt, welches von OPC UA definiert ist. Es enthält Informationen über Funktionsumfang und Status des Servers.

9. Die zwei Verzeichnisse S7: und SYM: unter Objects sind spezifisch für den SIMATIC NET OPC UA Server. Unter S7: sind die Konfigurierten S7 Verbindungen als Objekte aufgelistet. Unter SYM: sind die Symbole aus dem STEP 7 Projekt zu finden.

10. Im Verzeichnis Types befinden sich die verschiedenen Typknoten für DataTypes, ObjectTypes, ReferenceTypes und VariableTypes.

11. Ein S7 Verbindungsobjekt stellt diverse Statusinformationen und Methoden zur Verfügung. So können z.B. Blöcke in der S7 über Methoden bearbeitet oder ausgelesen werden. Neben den Methoden liefern Properties Informationen über die Konfiguration der S7 Verbindung.

1

2

3

4

5

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Nr. Beschreibung

12. Der zu dem S7 Verbindungsobjekt zugehörige S7ConnectionType kann im Verzeichnis ObjectTypes gefunden werden. Er beschreibt, welche Methoden und Variablen an der Instanz mindestens vorhanden sind. Die Regeln für das Typsystem sind in /2/ ausführlich beschrieben.

Namespaces und NodeId

Jeder Knoten im OPC UA Adressraum wird durch eine NodeId eindeutig identifiziert. Diese NodeId setzt sich zusammen aus einem Namespace zur Unterscheidung von Kennungen aus verschiedenen Subsystemen und einer Kennung, die entweder ein numerischer Wert, ein String oder eine GUID sein kann.

Für die Kennung werden typischerweise Strings verwendet. Dies ist analog zu OPC Data Access, wo die ItemId als Kennung auch ein String ist. Numerische Werte werden für statische Namensräume wie z.B. Typsystem eingesetzt.

OPC UA definiert einen Namespace für die von OPC definierten Knoten. Die OPC UA Server definieren zusätzlich einen oder mehrere Namespaces. Tabelle 3-6 listet die relevanten Namespaces für den SIMATIC NET OPC UA Server.

Tabelle 3-4

Namespace Beschreibung

http://opcfoundation.org/UA/ Wird verwendet für Knoten, die in der OPC UA Part 5 definiert werden. Dies sind Knoten, welche die Grundstruktur des Adressraumes bilden und Knoten die von OPC UA definierten Typen repräsentieren.

S7: Namensraum für direkte Adressierung von S7 Variablen mit einer optimierten Syntax.

S7COM: Namensraum für direkte Adressierung von S7 Variablen mit einer zum OPC Data Access Server kompatiblen Syntax.

SYM: Namensraum für symbolische Adressierung von S7 Variablen. Die Symbolinformationen werden aus dem STEP 7 Projekt exportiert.

S7AREAS: Namensraum für die Alarm Area Objekte.

S7SOURCES: Namensraum für Event Source Objekte.

Attribute der Knoten

Die wichtigsten Attribute von Knoten sind exemplarisch in der folgenden Tabelle aufgelistet. Der Schwerpunkt liegt dabei auf dem Knotentyp Variable.

Tabelle 3-5

Attribute Knotentyp Beschreibung

NodeId Alle Eindeutige Adresse des Knotens.

DisplayName Alle Lokalisierter Anzeigname für den Knoten. Die Sprache hängt von der vom Client angefragten Sprache für die Verbindung und vom Server unterstützten Sprachen ab.

BrowseName Alle Nicht lokalisierter Name für den Knoten. Der Namen enthält eine Namespace und ist vor allem bei der Verwendung von Typen relevant.

NodeClass Alle Art des Knotens wie z.B. Objekt, Variable oder Methode.

3 Grundlagen



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Attribute Knotentyp Beschreibung

Description Alle (optional) Optionale lokalisierte Beschreibung des Knotens.

Value Variable Wert der Variable. Zeitstempel und Status des Wertes werden wie bei allen anderen Attributen beim Lesen zusammen mit dem Wert des Attributs geliefert.

DataType Variable Datentyp der Variable bzw. des Value Attributes. Datentypen sind z.B. OPC UA definierte Datentypen wie Int32, Double oder String oder auch strukturierte Datentypen.

ValueRank Variable Gibt an, ob der Wert (Value Attribut) ein skalarer Wert, ein Array oder ein multidimensionales Array ist.

AccessLevel Variable Gibt an, ob die Variable gelesen oder geschrieben werden kann.

3.2.3 Schnittstelle für den Zugriff auf den OPC UA Server Adressraum

Kommunikationskanal und Applikationsobjekte

Abbildung 3-4 zeigt die verschiedenen Objekte, die beim Datenaustausch zwischen OPC Client und Server angelegt werden können. Die Objekte werden in Tabelle 3-6 beschrieben.

Abbildung 3-4

UA ServerUA Stack

Session

Subscription

Subscription

Monitored Item

Monitored Item

Secure Channel

Tabelle 3-6

Objekt Beschreibung

Secure Channel Der gesicherte Kommunikationskanal wird im OPC UA Stack realisiert. Die Objekte auf Applikationsebene sind davon unabhängig lebensfähig. Sie können aber nur im Kontext eines Secure Channel erzeugt, verwendet oder verändert werden. Wird nach einer Verbindungsunterbrechung ein neuer Secure Channel aufgebaut, muss dieser der Session auf Applikationsebene zugeordnet werden.

Session Die Session im Server ist die logische Verbindung zwischen OPC UA Client und Server. Sie hält die Benutzerinformationen und Spracheinstellungen für die Verbindung. Die Session wird vom Server gelöscht wenn innerhalb des Timeouts keine Aufrufe vom Client empfangen werden. Der Timeout wird vom Client vorgegeben. Die Session ist an einen Secure Channel gebunden, kann aber auf einen neuen Secure Channel zugewiesen werden, wenn die Kommunikation gestört war.

Subscription Ein Subscription Objekt kann vom Client zur Gruppierung von Monitored Items erzeugt werden. Monitored Items dienen zur Beobachtung von Werteänderungen oder zum Empfangen von Ereignismeldungen. Die Subscription wird vom Server gelöscht, wenn innerhalb des Timeouts keine Daten oder KeepAlive Nachricht an den Client geschickt werden konnte. Der Timeout wird vom Client vorgegeben.

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Methoden zum Verbindungsaufbau

Tabelle 3-7 erläutert die wichtigsten Methoden der OPC UA Schnittstelle zum Verbindungsaufbau.

Tabelle 3-7

Methode Beschreibung

OpenSecureChannel Öffnet einen sicheren Kommunikationskanal zwischen Client und Server. Zum Öffnen der Verbindung sind die URL des Servers, die Applikationszertifikate und die Sicherheitseinstellungen notwendig.

CreateSession Anlegen einer Applikationssession im Kontext eines Secure Channels.

ActivateSession Aktivieren der Session durch Übergabe der Benutzerauthentifizierung und der Spracheinstellungen. Diese Methode wird auch verwendet, um eine bestehende Session auf einen neuen Secure Channel zuzuweisen bzw. um den Benutzer zu wechseln.

CloseSession Schließt die Applikationssession.

Methoden des Session Objektes

Tabelle 3-8 erläutert die wichtigsten Methoden der OPC UA Schnittstelle bezüglich der Session.

Tabelle 3-8


Browse Liefert die Liste von Knoten, die von einem Startknoten aus über eine Referenz erreichbar sind. Die Menge der Knoten kann durch Filter eingeschränkt werden. Für jeden Knoten werden Informationen geliefert, die z.B. für die Anzeige in einer Baumansicht notwendig sind.

Read Liest eine Liste von Attributen von Knoten. Mit der Methode können sowohl Werte von Variablen (Value Attribut) als auch Metadaten wie z.B. der Datentyp einer Variablen (DataType Attribut) gelesen werden.

Write Schreibt eine Liste von Attributen von Knoten. Mit dieser Methode werden typischerweise Werte von Variablen geschrieben. Wenn der Server dies erlaubt, können auch andere Attribute geschrieben werden.

Call Ruft eine Liste von Methoden auf. Für eine Methode wird die NodeId des Objektes und die NodeId der Methode übergeben die Aufgerufen werden soll. Sind für die Methode Parameter definiert, so werden die Inputparameter beim Aufruf übergeben und die Outputparameter im Ergebnis geliefert. Methoden werden auch für Aktionen an Alarmobjekten wie z.B. die Quittierung von Alarmen verwendet.

CreateSubscription Anlegen einer Subscription für das Empfangen von Datenänderungen oder Ereignismeldungen. Die Subscription dient der Gruppierung von Informationen, die beobachtet werden sollen. Alle neuen Daten bzw. Ereignisse werden als Paket in einstellbaren Zeitintervallen für eine Subscription geliefert.

DeleteSubscription Löschen einer Subscription.

3 Grundlagen



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Methoden des Subscription Objektes

Tabelle 3-9 erläutert die wichtigsten Methoden der OPC UA Schnittstelle bezüglich der Subscription.

Tabelle 3-9


ModifySubscription Ändert die Einstellungen einer Subscription wie z.B. das Publish Intervall in der neue Daten für den Client gesammelt und zusammen geschickt werden.

CreateMonitoredItems Anlegen einer Liste von Monitored Items in einer Subscription. Ein Monitored Item dient entweder zur Überwachung eines Wertes einer Variablen oder zur Überwachung von Ereignismeldungen. Beide Arten von Monitored Items können in einem Aufruf an diese Methode gemischt werden. In dieser Applikation werden nur Ereignismeldungen überwacht.

ModifyMonitoredItems Ändert die Einstellungen einer Liste von MonitoredItems wie z.B. den Event Filter für die Überwachung auf Ereignismeldungen.

DeleteMonitoredItems Löscht eine Liste von Monitored Items in einer Subscription.

Publish Methode zur Übertragung von Datenpaketen für eine Subscription mit Werteänderungen und Ereignismeldungen im Publish Intervall. Diese Methode wird in der Client API nicht sichtbar. Die Funktionalität ist dort als Callback an die Client Applikation realisiert.

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

3.2.4 Protokolle und Sicherheitsmechanismen

OPC UA Kommunikationsarchitektur

Die Services für den Zugriff auf die Informationen in einem OPC UA Server Adressraum wie Browse, Read und Write sind abstrakt und unabhängig vom Transportprotokoll in Part 4 spezifiziert.

Die verschiedenen Bindings für die Übertragung der Service Nachrichten zwischen OPC UA Client und Server sind in Part 6 definiert. Ein Binding setzt sich aus Protokoll, Sicherheitsmechanismus und Serialisierungsart für die Daten zusammen.

Die Bindings werden in Kommunikationsstacks implementiert. Zurzeit gibt es von der OPC Foundation drei Implementierungen, nämlich in ANSI C, C# / .NET und JAVA. In dieser Applikation wird der C# / .NET Stack verwendet.

Die Methoden an der API des Stacks für die Applikation entsprechen den Services in Part 4 mit konkreten Datentypen aus der jeweiligen Programmiersprache. Damit kann in der Applikationsentwicklung auf eine native API in der entsprechenden Programmiersprache zugegriffen werden. Die Applikation kann auch unabhängig vom verwendeten Binding implementiert werden. Neue Bindings können durch Austausch des OPC UA Stacks erweitert werden.

Synchrone und asynchrone Aufrufe

Abbildung 3-5

Stack

DA Client DA Server COMCOM

Synchron

Asynchron

Read

Read Callback

UA Client

Synchron

Asynchron

UA Server Stack

Read

Read

Request

Request

Response

Response

Timeout bis zu 6 Minuten

KonfigurierbareWartezeit

Aufruf abgeschlossen

Bei COM sind alle Aufrufe zum Server synchron. Aus diesem Grund wurden dort für wenige Aktionen wie Read und Write zusätzliche asynchrone Funktionen definiert. Ein synchroner Aufruf startet die Aktion im Server. Nach Abschluss der Aktion wird vom Server ein synchroner Callback an den Client geschickt. Durch den synchronen Aufruf zum Starten der Aktion können auch asynchrone Aufrufe blockieren wenn die Netzwerkverbindung unterbrochen ist.

Bei OPC UA sind alle Aufrufe zum Server asynchron, eine Unterscheidung zwischen synchronen und asynchronen Methoden wird in der Spezifikation nicht

3 Grundlagen



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

gemacht. Nachdem die Request Nachricht auf das Netzwerk geschrieben ist, wird der asynchrone Aufruf an die Client Applikation zurückgegeben. Ein Blockieren ist deshalb beim asynchronen Aufruf nicht möglich. Da ein asynchroner Aufruf immer synchron gemacht werden kann, bieten die Stacks alle OPC UA Methoden auch als synchrone Aufrufe an. Dafür wird der Aufruf so lange im Stack festgehalten, bis die Response Nachricht vom Server eingetroffen ist oder bis der Timeout abgelaufen ist. Die Timeouts können pro Aufruf individuell eingestellt werden. Für den Server gibt es keinen Unterschied zwischen synchronen und asynchronen Aufrufen.

Sicherheitsschichten

Die verschiedenen Sicherheitsschichten von OPC UA werden in Abbildung 3-6 und Tabelle 3-10 beschrieben.

Abbildung 3-6

UA Client UA Server

Transportschicht

UA Stack

Applikation

Transportschicht

UA Stack

ApplikationSession

Secure Channel

Socket

Tabelle 3-10

Schicht Beschreibung

Socket Auf Socketebene kann zusätzlich oder alternativ zum Secure Channel eine verbindungsorientierte Sicherung der Socketverbindung durch Secure Socket Layer (SSL) oder durch ein Virutal Private Network (VPN) eingesetzt werden.

SecureChannel Auf der SecureChannel Ebene erfolgt eine gegenseitige Authentifizierung der Applikationen und eine nachrichtenbasierte Sicherung der Kommunikation. Dabei wird jede Nachricht signiert und verschlüsselt, um die Integrität und die Geheimhaltung der Nachrichten sicher zu stellen. Basis dieser Mechanismen sind Zertifikate, welche die Applikationen eindeutig auf Basis eines Public Key Infrastructure (PKI) Systems identifizieren. Eine detaillierte Beschreibung dieser Mechanismen findet sich in /2/. Der Austausch dieser Zertifikate als wichtigster Schritt bei der Sicherheitskonfiguration ist im nächsten Abschnitt beschrieben.

Session Auf Sessionebene wird eine Benutzerauthentifizierung durchgeführt.

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Konfigurationsoptionen für Security

Tabelle 3-11 beschreibt die verschiedenen Konfigurationsoptionen für die Sicherheitsmechanismen.

Tabelle 3-11

Option Beschreibung

Security Policy None – Es wird keine Sicherheit im Secure Channel verwendet. Basic128Rsa15 – Set von Algorithmen für die Security. Basic256 – Set von Algorithmen für die Security mit längeren Schlüsseln.

Message Security Mode

None – Die Nachrichten werden nicht gesichert. Sign – Die Nachrichten werden signiert. Sign&Encrypt – Die Nachrichten werden signiert und verschlüsselt.

User Authentication

Anonymous – Es ist keine Benutzerauthentifizierung notwendig. User Password – Die Benutzerauthentifizierung wird mit Benutzernamen und Passwort durchgeführt. Certificate – Die Benutzerauthentifizierung erfolgt durch ein Zertifikat.

Austausch der Zertifikate

Der Austausch der Zertifikate zwischen Client und Server und das Akzeptieren der Zertifikate ist in Abbildung 3-7 und Tabelle 3-12 erläutert.

Wenn alle beteiligten Applikationen die Richtlinien von OPC UA zur Sicherheitskonfiguration umsetzen, ist für den Austausch der Zertifikate nur ein manueller Schritt beim Server notwendig, da die Zertifikate zwischen den Applikationen automatisch ausgetauscht werden und nur das Akzeptieren der Zertifikate durch einen Administrator erfolgen muss.

Da noch nicht alle Applikationen die automatischen Schritte umsetzen, wird der manuelle Austausch der Zertifikate in Kapitel 6.3.2 erläutert.

Abbildung 3-7

Client Certificate Store

OPC UA ServerOPC UA Client

Client.der

GetEndpoints

Server Certificate Store

Server.der

OpenSecureChannel

SecureChannel

Server.der

CopyRejected Client.der

Accept

4

1

2

3

3 Grundlagen



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Tabelle 3-12

Schritt Beschreibung

1. Bevor der Client sich mit einem Server verbinden kann, benötigt er die notwendigen Informationen wie die vom Server geforderten Sicherheitsmechanismen, Protokoll und die Adresse zum Verbinden. Diese Informationen kennzeichnen einen sogenannten Endpoint. Mit dem Aufruf GetEndpoints werden die verfügbaren Endpoints eines Servers geliefert. Mit der Beschreibung des Endpoints liefert der Server auch sein Zertifikat.

2. Nach der Auswahl des Endpoints mit den Sicherheitseinstellungen wird der Benutzer gefragt, ob er das Zertifikat akzeptieren will. Wenn ja, wird es im Zertifikatsspeicher des Clients abgelegt.

3. Beim Aufruf von OpenSecureChannel wird das Client Zertifikat an den Server übergeben. Ist das Zertifikat im Server nicht bekannt, wird es in einem Rejected Verzeichnis gespeichert.

4. Mit einem Konfigurationstool des Servers können Zertifikate aus dem Rejected Verzeichnis akzeptiert werden. Dabei werden sie in den Zertifikatsspeicher des Servers verschoben.

Server Discovery

Bisher ist für OPC UA Discovery ein Local Discovery Service (LDS) definiert, der von der grundlegenden Funktionalität her mit dem OPC Enum bei klassischem OPC vergleichbar ist.

Abbildung 3-8

Device1

UA Client

UA Server opc.tcp://device1:4840- Basic128Rsa15- Sign

PC1Discovery Server

opc.tcp://pc1:4840

SIMATIC NET opc.tcp://pc1:4845- Basic128Rsa15- Sign

opc.tcp://localhost:4845- None / None

UA Server opc.tcp://pc1:27271- Basic128Rsa15- Sign&Encrypt

FindServers

GetEndpoints

CreateSession

FindServers

GetEndpoints

CreateSession

RegisterServer

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Ein LDS liefert eine Liste der lokal auf dem Netzwerkknoten verfügbaren OPC UA Server. Der LDS läuft standardmäßig auf dem für OPC UA registrierten Port 4840. Damit ist der LDS immer über opc.tcp://<Node>:4840 als URL ansprechbar. Die Server auf einem PC registrieren sich mit dem LDS.

Ein Client kann mit den folgenden Schritten einen Server aussuchen und eine Verbindung aufbauen:

• Verbindungsaufbau ohne Security mit Port 4840 und Aufruf von FindServers. Dieser Aufruf liefert die Liste der verfügbaren Server und deren Discovery URL.

• Verbindungsaufbau ohne Security zur Discovery URL des gewünschten Servers und Aufruf von GetEndpoints. Dieser Aufruf liefert die Liste der Enpoints mit den Endpoint URLs und den Sicherheitseinstellungen der Endpoints.

• Verbindungsaufbau mit der Endpoint URL und den geforderten Sicherheitseinstellungen. Danach kann mit CreateSession eine Applikationssession mit dem Server geöffnet werden.

Ist auf einem System nur ein OPC UA Server verfügbar, kann dieser auf dem Standardport 4840 laufen, da alle Server auch FindServers implementieren müssen und dann nur sich selbst liefern. Auch die Endpoints verwenden in diesem Fall den Port 4840.

3 Grundlagen

3.3 Grundlagen OPC UA Ereignismeldungen und Alarme


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


Eventtypen

Wie alle anderen Typinformationen sind auch die Arten von Events, die der Server liefern kann, im Adressraum des OPC UA Servers sichtbar. Abbildung 3-9 zeigt ein Beispiel für die Typhierarchie der Eventtypen. Die Wurzel der Ableitungshierarchie ist der BaseEventType. Die Typen für Alarms & Conditions sind unterhalb des ConditionType zu finden. Applikationsspezifische Eventtypen wie z.B. MyEventType können an beliebiger Stelle von den Standardtypen abgeleitet werden.

Abbildung 3-9

Ein Eventtyp definiert vor allem die Eventfelder die mit dem Event geliefert werden und auf die gefiltert werden kann wie z.B. Nachrichtentext (Message), Zeitstempel (Time) oder Eventquelle (SourceNode) die am BaseEventType definiert sind. Diese Informationen werden als Filter beim anlegen eines Event Monitored Items angegeben.

Für die Verwendung der Eventfelder im Filter ist der Pfad der BrowseNames vom Eventtyp aus relevant. Für die meisten Eventfelder ist dieser Pfad nur einen BrowseName lang. Eventfelder mit dem gleichen Namen an verschiedenen Eventtypen wie z.B. MyEventField können gemeinsam selektiert werden. In diesem Fall wird als Eventtyp einfach der BaseEventType angegeben.

Eventmeldeobjekte und Eventhierarchie

Events selbst sind nicht als Knoten im Adressraum sichtbar. Sie können nur über Objekte empfangen werden. Nicht alle Objekte können Events melden. Ob ein Objekt Events melden kann wird durch das Attribut EventNotifier am Objekt angegeben. Nur Objekte an denen dieses Attribut gesetzt ist können in einem Event Monitored Item angegeben werden um im Clients Events zu empfangen.

Über das von OPC UA definierte Server Objekt können alle Events vom Server empfangen werden. Es wird deshalb vom Client in einem Monitored Item verwendet wenn die Menge der Events nur auf Basis des angegeben Filters eingeschränkt werden soll. Die Angabe eines konkreten Objektes ist eine Art Vorfilter auf die Menge der Events.

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Für diesen Vorfilter kann der Server auch eine Hierarchie mit sogenannten Areas bilden um den Clients eine Auswahl von Events aus Bereichen zu erlauben. Abbildung 3-10 zeigt ein Beispiel für eine solche Eventhierarchie. Der Wurzelknoten dieser Hierarchie ist das Server Objekt. Der Baum wird mit HasNotifier und HasEventSource Referenzen gebildet. HasNotifier wird verwendet wenn das Ziel der Referenz ein Eventmeldeobjekt ist. Die HasEventSource Referenz wird verwendet um auf die Quelle von Events zu zeigen. Die Quelle für Events können Variablen oder Objekte sein.

Abbildung 3-10

HasNotifier

Objects

Server

Tank A

Organizes

LevelMeasurement

Area 1

Tank Farm Machine B

Device B

HasEventSource

HasEventSource

MyEventType

GeneratesEvents

DeviceType

Die Referenz GeneratesEvents wird verwendet um für einen Objekttyp die Eventtypen zu referenzieren die von diesem Objekt gefeuert werden können.

Events vom Server empfangen

Will ein OPC UA Client Events von einem Server empfangen muss er ein oder mehrere Event Monitored Items in einer Subscription anlegen. Für ein Event Monitored Item muss ein Eventmeldeobjekt, das Attribut EventNotifier und ein Event Filter angegeben werden. Der Filter setzt sich aus einer Selektion der Eventfelder und einem Filter auf die Eventfelder zusammen. Tabelle 3-13 zeigt ein Beispiel für die Einstellungen für ein Event Monitored Item.

Tabelle 3-13

Parameter Beispiele für Event Monitored Item

NodeId Tank A

Attribut EventNotifier

Index EventType Pfad Attribut 0 BaseEventType SourceNode Value 1 BaseEventType Message Value 2 BaseEventType Severity Value 3 MyEventType MyEventField Value

Filter Select Clause Where Clause

Index Operator Operand 1 Operand 2 0 And Index 1 Index 2 1 GreaterThan Severity 500 2 OfType MyEventType

3 Grundlagen



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Die Where Clause im Eventfilter wird verwendet um die Anzahl der Events die vom Server für das gewählte Objekt geliefert werden zu beschränken. In dem Beispiel werden nur Events vom Typ MyEventType geliefert bei denen die Severity größer 500 ist.

Dieser Filter wird aus einer Liste gebildet bei der sich ein Eintrag aus einem Operator und einer vom Operator abhängigen Anzahl von Operanden zusammen setzt. Einzelne Zeilen können dann logisch mit AND bzw. OR verknüpft werden.

Die Select Clause gibt die Liste der Eventfelder an die mit einem Event gemeldet werden. Diese Liste ist unabhängig von den Eventfeldern die für den Filter verwendet werden.

Condition Objekte und Condition Events

Condition Objekte werden verwendet um Zustandsüberwachungen abzubilden. Ein solches Überwachungsobjekt wird von einem OPC UA Client normalerweise nicht einzeln über Data Access beobachtet sondern es werden nur interessante Zustände über Events an einen OPC UA Client geliefert. Dabei spricht man normalerweise von Alarmen. Bei einer Füllstandsüberwachung können z.B. kritische Füllstände unterhalb oder oberhalb von Grenzen als Alarm an den Client gemeldet werden.

Ein Alarm setzt sich aus verschiedenen verschachtelten oder parallelen Zustandsmaschinen zusammen. Abbildung 3-11 zeigt die wichtigsten Zustandsmaschinen eines Alarms. Die Überwachung kann generell eingeschaltet (Enabled) oder abgeschaltet sein (Disabled). Ist die Überwachung eingeschaltet, kann der Alarm aktiv oder inaktiv und bestätigt oder nicht bestätigt sein.

Abbildung 3-11

Disabled

Enabled

Active Inactive

Unacknowledged Acknowledged

Der Basistyp für alle Condition Objekte ist der ConditionType. Er ist vom BaseEventType abgeleitet. Im Gegensatz zu einfachen Events können Condition Objekte aber im Adressraum des OPC UA Servers sichtbar sein da sie zwar für Statuswechsel Events schicken, die aktuellen Zustände der verschiedenen Zustandsmaschinen aber immer auslesbar sind. Die Sichtbarkeit im Adressraum ist aber optional. Alle Mechanismen zur Alarmverarbeitung funktionieren auch ohne dass die Condition Objekte im Adressraum enthalten sind.

Ändert ein Condition Objekt einen oder mehrere Zustände, sendet der Server einen Event mit den angeforderten Eventfeldern an den Client. Aktionen vom Client an den Condition Objekten, wie z.B. die Bestätigung eines Alarms, erfolgen über den Aufruf definierter Methoden an den Condition Objekten. Über die Methode Refresh können nach dem Verbindungsaufbau des Clients mit dem OPC UA Server die Zustände der aktuell aktiven Alarme als Events an den Client geschickt werden.

3 Grundlagen


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Eventfelder von einfachen Events

Der BaseEventType definiert einen Satz von Eventfeldern, die für alle Events vom Server geliefert werden kann. Tabelle 3-14 beschreibt die wichtigsten Eventfelder. Die anderen Eventtypen haben diese Eventfelder ebenfalls als Basis, liefern aber noch zusätzliche Eventfelder für den jeweiligen Typ.

Tabelle 3-14

Eventfelder Beschreibung

SourceName SourceNode

Name bzw. NodeId der Quelle der Ereignismeldung.

Time Zeitpunkt, an dem das Ereignis aufgetreten ist.

ReceiveTime Zeitpunkt, an dem das Ereignis im Server verarbeitet worden ist.

EventType NodeId des Eventtyps der Ereignismeldung.

Message Beschreibender Text für die Ereignismeldung.

Severity Priorität der Ereignismeldung. Der Wertebereich der Priorität liegt im Bereich von 1 bis 1000. Dabei entspricht 1000 der höchsten Priorität.

EventId Eindeutiger Identifier für den Event

Eventfelder von Condition Events

Die OPC UA Alarms & Conditions Spezifikation definiert einen Satz von Eventfeldern, der für Condition Events und Alarme vom Server geliefert wird. Dieser Satz besteht aus den Eventfeldern, die vom BaseEventType definiert sind, und zusätzlichen Eventfeldern für Condition Events. Tabelle 3-15 beschreibt die wichtigsten zusätzlichen Eventfelder.

Tabelle 3-15

Eventfelder Beschreibung

ConditionName ConditionId

Name bzw. NodeId der Condition bei der ein Zustandswechsel aufgetreten ist.

ConditionClassName ConditionClassId

Name bzw. NodeId der Condition Klassifizierung. Für die Klassifizierung ist eine eigene Typhierarchie vorgesehen. Vordefinierte Klassen sind Process, System und Maintenance.

EnabledState Gibt an ob die Zustandsüberwachung eingeschaltet oder ausgeschaltet ist.

AckedState Gibt an ob der Alarm quittiert werden muss.

ActiveState Gibt an ob der Alarm aktiv ist.

Retain Ein Flag das angibt ob die Condition in einem für den Client interessanten Status ist und angezeigt werden soll.

Quality Gibt die Qualität des Wertes an, auf dem die Condition beruht. Dies kann zum Beispiel der Füllstand eines Tanks sein.

Comment Kommentar der von einem Client für die Condition gesetzt wurde. Dies kann auch über die Quittierung eines Alarms erfolgen

ClientUserId Text Identifier, welche die Applikation identifiziert, die den Alarm quittiert hat oder einen Kommentar hinzugefügt hat.

3 Grundlagen



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Methoden von Condition Objekten

Condition Events können als Objekte im Adressraum des Servers sichtbar werden. Unabhängig von der Sichtbarkeit kann ein OPC UA Client aber Methoden an den Objekten aufrufen. Tabelle 3-16 beschreibt die wichtigsten Methoden an einem Condition Objekt.

Tabelle 3-16


Refresh Der Aufruf der Methode löst für alle Conditions einen Event für den Aufrufenden Client mit dem aktuellen Zustand aus. Es werden nur Conditions aktualisiert, bei denen das Retain Flag gesetzt ist.

Enable Schaltet die Überwachung einer Condition ein.

Disable Schaltet die Überwachung einer Condition ab.

AddComment Setzt einen Kommentar an der Condition.

Acknowledge Quittiert einen Alarm.

Operatoren für Event Filter

Tabelle 3-17 beschreibt die wichtigsten Operatoren die in einem Event Filter in der Where Clause verwendet werden können.

Tabelle 3-17

Operator Beschreibung

Equals Wahr wenn Operand eins gleich Operand zwei ist. GreaterThan Wahr wenn Operand eins größer Operand zwei ist. LessThan Wahr wenn Operand eins kleiner Operand zwei ist. GreaterThanOrEqual Wahr wenn Operand eins größer oder gleich Operand zwei ist. LessThanOrEqual Wahr wenn Operand eins kleiner oder gleich Operand zwei ist. Like Wahr wenn Operand eins einem Textpattern entspricht das in

Operand zwei definiert ist. Not Wahr wenn Operand eins nicht wahr ist. Between Wahr wenn Operand eins größer oder gleich Operand zwei und

kleiner oder gleich Operand drei ist. InList Wahr wenn Operand eins gleich einem der anderen Operanden ist. And Wahr wenn Operand eins und Operand zwei wahr sind. Or Wahr wenn Operand eins oder Operand zwei wahr sind. OfType Wahr wenn der Eventtyp gleich dem Operand eins ist oder ein

Subtyp von Operand eins ist.

Operanden für Event Filter

Tabelle 3-18 beschreibt die Operanden die in einem Event Filter in der Where Clause verwendet werden können.

Tabelle 3-18

Operator Beschreibung

Literal Gibt einen Wert an. Attribute Gibt ein Eventfeld eines Events an. Das Eventfeld wird über den

BrowseName angegben. Element Verweist über einen Index auf einen anderen Eintrag in der Liste

Where Clauses.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

4 Funktionsmechanismen der Client Applikation Das folgende Kapitel richtet sich an Programmierer welche sich einen Überblick über die Funktionsmechanismen der OPC UA Client Applikation verschaffen wollen.

Das Kapitel beginnt mit einem Überblick über die Gesamtarchitektur. Im folgenden Teil wird die Client API beschrieben. Im letzten Teil des Kapitels werde die Funktionsabläufe in Klassen- und Sequenzdiagrammen beschrieben.

Gesamtübersicht

Abbildung 4-1

Tabelle 4-1

Modul Beschreibung

OPC UA .NET Stack Der .NET basierte OPC UA Kommunikationsstack von der OPC Foundation.

.NET Client SDK Das .NET basierte OPC UA Client SDK der OPC Foundation.

Client API Wiederverwendbare, vereinfachte und auf die Aufgabe zugeschnittene .NET Client API. Sie bietet für Discovery, Session und Subscription Handling wiederverwendbare C# Klassen an.

UA Client Komfortabler OPC Client mit den Funktionen Discovery, Connect, Disconnect, Monitoring von Events, Filtereinstellungen für Events und Auswahl der gelieferten Eventfelder. Allgemeine Funktionen wie Browsen von Areas, Anzeige der verfügbaren




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Modul Beschreibung

Filter und Anzeige der Eventfelder sind in wiederverwendbaren Controls gekapselt.

ANSI C UA Stack Der SIMATIC NET OPC UA Server verwendet den optimierten und portablen OPC UA ANSI C Stack der OPC Foundation.

S7 OPC UA Server Der SIMATIC NET OPC UA Server implementiert die notwendige Serverlogik für Sessions und Subscriptions und die Datenanbindung an die S7 Stationen.

Programmübersicht

Die folgende Abbildung zeigt die Funktionsblöcke im OPC UA Client und das Zusammenspiel mit dem OPC UA Server.

Abbildung 4-2

Protokollschicht / Treiber

OPC UA Server

OPC UA Schnittstelle

.Ne

t OP

C U

A C

lien

t P

roze

ssO

PC

UA

Se

rve

r P

roze

ss Session Subscription2 5

Client Applikation

ServerVerbindung

SubscriptionVerwaltungCallback

Objekt

4

316

Browse

Tabelle 4-2

Nr. Beschreibung

1 Beim Verbindungsaufbau der Oberfläche mit dem OPC UA Server wird auf Clientseite ein Client API Objekt erzeugt. Dieses Objekt verwaltet die Verbindung mit dem Server (2). Es stellt darüber hinaus alle OPC UA Services zur Verfügung mit Ausnahme von Services, die sich auf eine Subscription beziehen.

2 Über die OPC UA Schnittstelle wird ein Session Objekt im Server erzeugt.

3 Beim Starten des Konfigurationsdialogs wird auf dem OPC UA Server nach Areas, Event Typen und Eventfeldern gebrowsed und diese im Konfigurationsdialog in jeweils einem Baum angezeigt.

4 Beim Verbinden wird ein Subscription Objekt erzeugt, das alle OPC UA Services zur Verfügung stellt, die sich auf eine Subscription beziehen. In die



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Nr. Beschreibung

Subscription wird ein MonitoredItem eingefügt. Das ist standardmäßig das Server Objekt - im Konfigurationsdialog kann auch ein anderes Objekt oder eine Area gewählt werden.

5 Über die OPC UA Schnittstelle wird im Server ein Subscription Objekt erzeugt, das alle Subscription relevanten Einstellungen verwaltet.

6 Um Events vom Server empfangen zu können, wird eine Callback-Verbindung aufgebaut. Dafür wird ein SubscriptionCallback Objekt im Client angelegt und mit der Subscription im Server verbunden. Werden Events vom Server an den Client geschickt, trägt dieser die Änderungen in das EventView Fenster ein.


4.1 OPC UA Client API


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

4.1 OPC UA Client API

Das Klassendiagramm in Abbildung 4-3 zeigt die Klassen der OPC UA Client API. Diese Klassen kapseln die Zugriffe auf den OPC UA Server in eine vereinfachte und wiederverwendbare .NET API.

Die Klassen sind in der .NET Assembly Siemens.OpcUA.dll zusammengefasst. Sie hat Abhängigkeiten zu der .NET Client SDK Assembly Opc.Ua.Client.dll und zu der .NET Stack Assembly Opc.Ua.Core.dll.

Abbildung 4-3

Klasse Discovery

Die in der folgenden Tabelle beschriebene Wrapperklasse Discovery kapselt die notwendigen Methoden für das Server Discovery.

Die Klasse ist in der Datei ClientDiscovery.cs im Projekt ClientApi implementiert.

Tabelle 4-3

Methode Funktionalität

FindServers Ermittelt die OPC UA Server auf einem Rechner.

GetEndpoints Ermittelt die verfügbaren Endpunkte (Endpoints) für einen oder mehrere Server.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Klasse Server

Die in der folgenden Tabelle beschriebene Wrapperklasse Server kapselt die Funktionalität für den Zugriff auf den OPC UA Server. Darüber hinaus vereinfacht sie die Verwendung derjenigen OPC UA Services, die von der Client Applikation benötigt werden, mit Ausnahme der Services für die Subscription.

Die Klasse ist in der Datei ClientAPI.cs im Projekt ClientApi implementiert.

Tabelle 4-4


Connect Erzeugt einen Secure Channel als Kommunikationskanal und eine Session im OPC UA Server.

Disconnect Löscht die Session im Server und baut die Secure Channel Verbindung ab.

Browse Liefert eine Liste von Knoten die vom übergebenen Startknoten aus über eine Referenz erreichbar sind. Die Liste der Ergebnisse kann über Filtereinstellungen beeinflusst werden.

Call Ruft eine UA Methode auf.

Read Liefert die Werte zu einer Liste von Attributen eines Knotens.

ReadValues Liefert die Werte des Value Attributs einer Liste von Knoten.

WriteValues Schreibt den Wert des Value Attributes einer oder mehrerer Variablen.

AddSubscription Erzeugt eine Subscription und verknüpft diese mit der Session.

ModifySubscription Ändert die Einstellungen einer Subscription.

RemoveSubscription Entfernt eine existierende Subscription.

Session_KeepAlive Keep-alive Callback.

Session_Notification Wird aufgerufen, wenn der OPC UA Server eine Antwort (Publish) sendet.

CertificateValidator_ CertificateValidation

Wird aufgerufen, wenn das Zertifikat des Servers als nicht vertrauenswürdig eingestuft wird.

Klasse Subscription

Die in der folgenden Tabelle beschriebene Wrapperklasse Subscription kapselt die Verwendung einer Subscription zum Empfang von Werteänderungen und Events vom Server.

Die Klasse ist in der Datei ClientSubscription.cs im Projekt ClientApi implementiert.

Tabelle 4-5


AddDataMonitoredItem Erzeugt ein Monitored Item zur Beobachtung von Werteänderungen und verknüpft dieses mit der Subscription.

AddEventMonitoredItem Erzeugt ein Monitored Item zum Empfangen von Events und verknüpft dieses mit der Subscription.

ModifyMonitoredItem Ändert die Einstellungen eines Monitored Items.

RemoveMonitoredItem Entfernt ein Monitored Item aus der Subscription.


4.2 OPC UA Alarms&Conditions Client


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


4.2.1 Oberfläche

Die folgende Abbildung und Tabelle beschreiben die Oberfläche des generischen OPC UA Clients Beispiels mit dem auf die Informationen des Namensraums eines OPC UA Servers komfortabel zugegriffen werden kann.

Abbildung 4-4

Tabelle 4-6

Nr. Beschreibung

1. Über die Auswahlliste kann der Server Endpoint ausgewählt werden. Dafür wird die Liste der Server und Endpoints vom Discovery Server ermittelt. Der Rechner auf dem der Discovery Server abgefragt werden soll, kann im Textfeld Node eingegeben werden. Ist das Feld leer, wird der lokale Discovery Server angesprochen.

2. Über den Button Connect/Disconnect kann die Verbindung zum Server auf- bzw. abgebaut werden.

3. Im EventView Control stehen zwei Ansichten zur Auswahl die über ein TabControl umgeschaltet werden können.

o Events-Tab: zeigt alle Events an o Alarms-Tab: zeigt nur Events von Typ ConditionType (oder Subtypen) an

4. Anzeige der empfangenen Events mit vorkonfigurierten Eventfeldern. Die Standard Eventfelder sind:

o Im Events-Tab: Time, ReceiveTime, Severity, SourceName, Message, EventType und SourceNode

o Im Alarms-Tab: AcknowledgeState, Time, Severity, SourceName, Message, ConditionName, ActiveState und Retain Flag

5. Im Alarm-Tab wird in der ersten Spalte über ein Symbol angezeigt ob ein Event schon quittiert

1

45

2

6

7

3



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Nr. Beschreibung

wurde. (rote Fahne: nicht quittiert, grüner Haken: quittiert)

6. Für das aktuell ausgewählte Event in der Eventliste(4) werden alle Eventfelder angezeigt, die zu diesem Event geliefert wurden.

7. Über das Applikationsmenü „Subscription“ kann das Publishing Interval für die Subscription geändert werden. Über das Applikationsmenü „Event Filter“ kann die Konfiguration der Eventfilter, Area und Eventfelder geändert werden. Die Einstellung „Show All EventFields“ im Untermenü gibt an ob Eventfelder die angefordert wurden zu denen jedoch kein Wert geliefert wurde trotzdem in der Liste (6) angezeigt werden.

4.2.2 Klassendiagramm

Das folgende Klassendiagramm zeigt die Klassen des OPC UA Beispielclients. Diese Klassen realisieren die Funktionalität der Oberfläche und verwenden die Klassen der UA Client API. Auf den folgenden Seiten werden die einzelnen Klassen im Detail erläutert.

Abbildung 4-5




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Klasse MainForm

Die in der folgenden Tabelle beschriebene Klasse MainForm implementiert die Funktionalität des Hauptdialoges der Client Applikation.

Der Klassenname entspricht dem Dateinamen im Projekt UAClient.

Tabelle 4-7


MainForm Konstruktor der Klasse.

Connect Implementiert die Funktionalität, um die Verbindung mit dem Server aufzubauen und initialisiert das Browse Control.

Disconnect Baut die Verbindung zum Server ab.

UrlCB_DropDown Füllt alle verfügbaren UA Endpints in die ComboBox ab. Wenn das Feld Node leer ist wird der lokale DiscoveryServer abgefragt, ansonsten der DiscoveryServer auf dem Rechner der im Node Feld angegeben ist.

OnSelectPublishingInterval Stellt das Publishing Interval für die Subscription am EventView ein.

OnChangeConfiguration Zeigt den Konfigurationsdialog (ConfigurationDlg) an und ruft nach Änderung der Konfiguration UpdateConfiguration am EventView auf.

Klasse EventView

Die in der folgenden Tabelle beschriebene Klasse EventView implementiert die Funktionalität für das Empfangen und Anzeigen von Events des Servers.


Tabelle 4-8


EventView Konstruktor der Klasse.

ClearAll Löscht alle Einträge in den Listen im Alarms-Tab und Events-Tab.

ModifyPublishingInterval Ändert das Publishing Interval der Subscription.

ModifySamplingInterval Ändert das Sampling Interval für das MonitoredItem.

SubscribeForEvents Legt eine Subscription an und fügt ein MonitoredItem in die Subscription ein.

UnsubscribeForEvents Löscht die Subscription.

UpdateConfiguration Legt die Subscription neu an mit den geänderten Parametern.

Klasse EventConfiguration

Die in der folgenden Tabelle beschriebene Klasse EventConfiguration hält alle Parameter für den Empfang und die Anzeige der Events im EventView.


Tabelle 4-9

Property Funktionalität

AreaConfiguration Hält die NodeId des UA-Objekts von dem Events empfangen werden sollen.

EventFields Hält die Liste von Eventfeldern welche vom Server als Begleitwerte zu den Events geschickt werden sollen.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

FilterConfiguration Hält die Konfiguration des EventFilters. Dazu gehört: o Min Severity o Max Severity o EventTypes (Liste von Typen von Events die geschickt werden

sollen)

Klasse AcknowledgeDlg

Diese Klasse Zeigt einen Dialog zum Quittieren von Events an. Beim Quittieren kann ein Text vom Benutzer eingegeben werden, der zum Server übertragen wird.


Klasse ConfigurationDlg

Die in der folgenden Tabelle beschriebene Klasse ConfigurationDlg implementiert das Anzeigen der Konfiguration für die im EventView angezeigten Events. Dazu gehören Filtereinstellungen, Auswahl der Eventfelder und das UA-Objekt von dem die Events empfangen werden sollen. Folgende Controls werden in dem ConfigurationDlg gehalten.

Tabelle 4-10

Control Funktionalität

AreaSelectionControl Hier kann das Objekt bzw. Area ausgewählt werden von dem Events empfangen werden sollen.

EventFieldSelectionControl Hier können alle Eventfelder ausgewählt werden die vom Server als Begleitwerte zu den Events mitgeschickt werden.

EventFilterSelectionControl Nur Events von den hier ausgewählten Eventtypen (oder deren Subtypen) werden vom Server gesendet.

Verwendung der Client API im Beispiel

In der folgenden Tabelle sind die Dateien und Funktionen aufgelistet in denen die Client API verwendet wird.

Tabelle 4-10

Client API Verwendet in

Klasse Discovery

FindServers MainForm.cs in der Methode UrlCB_DropDown

GetEndpoints MainForm.cs in der Methode UrlCB_DropDown

Klasse Server

Connect MainForm.cs in der Methode Connect

Disconnect MainForm.cs in der Methode Disconnect

Call EventView.cs in der Methode menuItem_Acknowledge_Click

Browse EventFieldSelectionControl.cs in der Methode Browse

Read EventView.cs in der Methode getDisplayNameForNodeId.

ReadValues Wird in diesem Beispiel nicht verwendet.

WriteValues Wird in diesem Beispiel nicht verwendet.

AddSubscription EventView.cs in der Methode SubscribeForEvents

ModifySubscription EventView.cs in der Methode ModifyPublishingInterval




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

RemoveSubscription EventView.cs in der Methode UnsubscribeForEvents

Klasse Subscription

AddDataMonitoredItem Wird in diesem Beispiel nicht verwendet.

AddEventMonitoredItem EventView.cs in der Methode SubscribeForEvents

ModifyMonitoredItem EventView.cs in der Methode ModifySamplingInterval

RemoveMonitoredItem EventView.cs in der Methode UnsubscribeForEvents

4.2.3 Sequenzdiagramme

Verbindung zum OPC UA Server aufbauen und beenden - Bedienoberfläche

Das folgende Sequenzdiagramm zeigt die Abläufe, die notwendig sind, um die Verbindung zum OPC UA Server aufzubauen. Durch Anklicken der Combobox Endpoints wählt der Benutzer zunächst einen verfügbaren Endpoint aus.

Der Verbindungsaufbau kann über den Button Connect in der Oberfläche oder über das Menü Server gestartet werden. Nach einem erfolgreichen Verbindungsaufbau erscheint auf dem Button Connect die Aufschrift Disconnect. Das Sequenzdiagramm zeigt auch die Abläufe, die durch die Aktion „Disconnect Server“ über den Button Disconnect angestoßen werden.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Abbildung 4-6

2a

2b

3

1

4

5

6

7

8




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Tabelle 4-11

Nr. Beschreibung

1 Beim Öffnen der Auswahlliste wird ein ClientAPI::Discovery Objekt erzeugt und dort die Methoden FindServers und GetEndpoints aufgerufen.

2 Durch die Benutzeraktion „Connect“ wird die Methode ConnectDisconnect_Click am Objekt MainForm aufgerufen. In dieser Methode werden die Aktionen zum Verbindungsaufbau mit dem Server durchgeführt. Im ersten Schritt wird das ClientAPI::Server Objekt und dort Methode Connect aufgerufen (2a). Damit wird die Verbindung zum - durch die URL definierten - OPC UA Server aufgebaut. Wird ein Zertifikat noch nicht als vertrauenswürdig eingestuft, kann der Benutzer dieses prüfen und akzeptieren und der Verbindungsaufbau wird fortgesetzt (2b).

3 Im Fall einer bestehenden Verbindung wird in einem zweiten Schritt der Konfigurationsdialog (ConfigurationDlg) angezeigt. Im Konfigurationsdialog werden Einstellungen zu Area, Eventfelder und Filter gemacht.

4 Beim Start des Dialogs wird automatisch auf dem Server nach Areas, Eventtypen und Eventfelder gebrowsed um dem Benutzer die möglichen Einstellungen anzeigen zu können.

5 Im EventView wird eine Subscription angelegt und in die Subscription ein Event Monitored Item eingefügt.

6 Die Methode Refresh wird aufgerufen. Dadurch schickt der OPC UA Server die Zustände der aktuell aktiven Alarme als Events an den Client.

7 ConnectDisconnect_Click am Objekt MainForm aufgerufen. Im Fall einer bereits existierenden Verbindung wird in dieser Methode die Methode Disconnect am ClientAPI::Server Objekt aufgerufen. Damit wird die Verbindung zum OPC UA Server beendet.

8 Das Event Monitored Item wird aus der Subscription gelöscht und die Subscription, die vom EventView erzeugt wurde wird gelöscht.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Verbindung zum OPC Server aufbauen und beenden – Client API

Das folgende Sequenzdiagramm zeigt die Abläufe beim Aufbau und Beenden einer Verbindung zu einem OPC UA Server im Kontext der Client API.

Abbildung 4-7

Tabelle 4-12

Nr. Beschreibung

1 Bei der Aktion Connect wird einSDK::SessionChannel Objekt für den Aufbau einer gesicherten Verbindung mit dem Server erzeugt.

2 Anschließend wird ein ClientAPI::Session Objekt erzeugt, dass den Kanal zum Server kapselt.

3 Im nächsten Schritt meldet das ClientAPI::Session Objekt ein KeepAlive Callback beim OPC UA Server an.

4 Der Aufruf Open schließlich stellt die eigentliche Verbindung zwischen Client und Server her.

5 Im Rahmen der Aktion Disconnect wird am ClientAPI::Session Objekt Close aufgerufen.

1

2

3

4

5




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Konfiguration der Eventfilter ändern

Das folgende Sequenzdiagramm zeigt die Abläufe beim Ändern der Konfiguration für das Event Monitored Items bzw. dessen Event Filter.

Abbildung 4-8

Tabelle 4-13

Nr. Beschreibung

1 Der Benutzer löst die Aktion ChangeConfiguration über das Menü EventFiler in der Menüleiste aus. Der Konfigurationsdialog wird angezeigt.

2 Der Benutzer ändert die gewünschten Parameter im Konfigurationsdialog (Filter, Eventtypen, Eventfelder). Wird der Dialog mit OK geschlossen wird darauf UpdateConfiguration am EventView Objekt aufgerufen.

3 Das Event Monitored Item wird aus der Subscription gelöscht. Die Subscription wird gelöscht.

4 Eine Subscription wird neu angelegt. Ein Event Monitored Item mit den neuen Konfigurationsparameters wird angelegt.

5 Die Methode Refresh wird aufgerufen. Dadurch schickt der OPC UA Server die Zustände der aktuell aktiven Alarme als Events an den Client.

1

2

3

4

5

5 Funktionsmechanismen der S7 Applikation


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

5 Funktionsmechanismen der S7 Applikation Das folgende Kapitel richtet sich an Techniker und Programmierer welche sich einen Überblick über die Funktionsmechanismen der S7 Applikation verschaffen wollen.

Das Kapitel beginnt mit einem Überblick über die Möglichkeiten zur Alarmprojektierung und Alarmprogrammierung. Im folgenden Teil werden die verschiedenen Alarm-Typen und deren Informationsgehalt beschrieben. Im letzten Teil des Kapitels werden beispielhaft verschiedene Alarme in einer S7 Applikation erstellt.

Der Typ und die Anzahl der von einer S7 CPU unterstützten Alarme ist von ihrem Typ und der Version ihrer Firmware abhängig. In \1\ finden Sie eine entsprechende Übersicht.

5.1 Erweiterte Alarmprojektierung ab STEP 7 V5.5

In diesem Kapitel werden die Konzepte des Alarmmeldeverfahrens und die grundsätzlichen Schritte zu dessen Projektierung erklärt. Hierbei wird das so genannte Meldenummernverfahren betrachtet, dass im Gegensatz zum Bitmeldeverfahren bei dem das Bediensystem bzw. der OPC Server einzelne Bits pollend überwacht, tatsächlich aktiv Events aus dem Automatisierungssystem feuert und damit eine deutlich niedrigere Busbelastung verursacht. Die Meldetexte beim Meldenummerverfahren werden aus einer gemeinsamen Datenbasis generiert und es können auch Zusatztexte konfiguriert werden. Die Meldungen enthalten den Zeitstempel aus dem Automatisierungssystem.

Die Konfiguration an sich ist nicht neu, aber ab der Version STEP 7 V5.5 werden die projektierten Alarminformationen beim „speichern und übersetzen“ für den SIMATIC NET OPC Server (ab V7.1) aufbereitet. Wird nun die PC-Station, die den OPC Server enthält, geladen (oder XDB Import) kennt auch der OPC Alarms&Event Server die Projektierung und zeigt Meldetexte, Source und Areas als OPC Attribute an. Die Konfiguration über eine zusätzliche Datei (scores7.msg) wie in den früheren Versionen des OPC A&E Servers nötig, entfällt somit und die Projektierung ist durchgehend und konsistent.

Einführung

Es werden grundsätzlich drei verschiedene Arten von Meldungen unterschieden, die sich hinsichtlich ihres Anwendungsbereichs unterscheiden:

• bausteinbezogene Meldungen Melden von programmsynchronen Ereignissen, Programmierung über Meldebausteine

• symbolbezogene Meldungen Melden von programmunabhängigen Ereignissen, Projektierung über die Symboltabelle (nur S7-400)

• anwenderdefinierte Meldungen Melden von programmsynchronen Diagnoseereignissen, Programmierung über Systemfunktionen

Konfiguration und Projektierung

STEP 7 unterstützt die Projektierung des Meldenummernverfahrens mit den folgenden Sprachen bzw. Tools:


5.1 Erweiterte Alarmprojektierung ab STEP 7 V5.5


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

• KOP/FUP/AWL/SCL

• Symboltabelle

• PDIAG

• CFC

• S7-GRAPH

Im vorliegenden Beispiel wird ausschließlich STEP 7 (AWL und Symboltabelle) zur Projektierung verwendet.

Bausteinbezogene Meldungen

Der Meldebaustein ist der am häufigsten verwendete Alarm. Es gibt unterschiedliche Bausteine (SFB/SFC) die sich in der Anzahl der überwachten Signale und der Anzahl der Begleitwerte sowie der Quittierfähigkeit unterscheiden.

Jeder dieser Bausteine stellt einen Meldungstyp dar sobald er mit entsprechenden Formalparametern versorgt z.B. in einem FB aufgerufen wird und somit einen meldefähigen FB darstellt. Dieser Typ kann nun in STEP7 konfiguriert werden und die Eigenschaften können festgelegt und sogar gesperrt werden.

Im Simatic Manager mit rechter Maustaste auf den FB (der den SFB aufruft) anschließend Spezielle ObjekteigenschaftenMeldung… wird der Dialog zur Konfiguration des Typs geöffnet. Das es sich um eine Konfiguration des Typs handelt erkennt man an der Spalte Meldenummer=0

Abbildung 5-1

Die Konfiguration des Typs und auch das Sperren der Parameter wird immer dann verwendet wenn man einen Baustein zum Melden immer gleicher Ereignisse verwenden möchte. Beispielsweise haben analoge Messstellen hinsichtlich ihrer Alarme immer den gleichen Aufbau und liefern immer Alarme bei Grenzwertüber- oder unterschreitung, bei Schwellwertüber- oder unterschreitung und einen generellen Fehleralarm wenn die Messstelle defekt ist. Es wird nun ein entsprechender Alarmtyp erstellt, von dem später im Programm Instanzen erzeugt werden, die immer gleich aufgebaut sind.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Beim Aufruf des FB im OB1 wird ein Instanzdatenbaustein erzeugt (Call FB200, DB200). Die Meldungen dieser Instanz sehen nun exakt so aus wie im Meldungstyp definiert. An der Instanz können nun die Parameter abgefüllt werden, die nicht gesperrt wurden, die instanz-spezifischen Parameter.

Im Simatic Manager mit rechter Maustaste auf den DB (der Multiinstanz DB des FB) dann Spezielle ObjekteigenschaftenMeldung… wird der Dialog zur Konfiguration der Instanz geöffnet. Das es sich um eine Konfiguration der Instanz handelt erkennt man an der Spalte Meldenummer=<nr.> (ungleich „0“)

Abbildung 5-2

In grüner Schrift werden die Parameter gekennzeichnet, die noch denen des ursprünglichen Typs entsprechen, alle anderen wurden für diese Instanz bereits geändert.

Symbolbezogene Meldungen

Die symbolbezogene Meldung wird selten und ausschließlich zur Überwachung von asynchronen Ereignissen verwendet, mit asynchron ist hier asynchron zum OB1-Zyklus gemeint. Sie kostet Systemressourcen, belastet die Zykluszeit der CPU und ist nur bei der S7-400 möglich. Die Überwachung eines binären Signals wird über die Symboltabelle konfiguriert. Unabhängig vom OB1 Zyklus wird dieses Bit in einem festen Raster (100, 500, 1000 ms) überwacht (SCAN). Das Zeitraster ist vom CPU-Typ abhängig.

Nach Abschluss der Konfiguration in der Symboltabelle, müssen Systembausteine (SDB) generiert und in die Steuerung geladen werden.

Es können alle binären Symbole überwacht werden (Eingänge, Ausgänge und Merker). Sobald ein Signalwechsel erkannt wurde, wird der konfigurierte „Scan-Alarm“ gefeuert. Dieser Alarm kann bis zu 10 Begleitwerte enthalten.

Anwenderdefinierte Meldungen

Mit der Systemfunktion SFC52 (WR_USMSG) werden Anwendereinträge in den Diagnosepuffer der CPU geschrieben und gleichzeitig eine Meldung gesendet.


5.2 Alarme der SIMATIC S7 Station


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Diese Art der Meldung wird daher ausschließlich für systemrelevante Ereignisse verwendet. Es stehen für zwei Fehlerklassen (A und B) jeweils 255 Ereignisnummern zur Verfügung, für die jeweils ein Text für kommende und gehende Meldung projektiert werden kann.

Im Anwenderprogramm wird dann an geeigneter Stelle (z.B. im OB100, dem Warmstart OB) die Systemfunktion aufgerufen (Call SFC 52) und mit der gewünschten EreignisID (0xA101)versorgt.

Abbildung 5-3

Im Unterschied zu der Funktion „Systemfehler melden“ vergibt der Anwender hier Ereignisnummern und ruft im Programm die SFC 52 auf. Beim Systemfehler melden sind die Nummern (ein spezielles Nummernband) und auch die Texte von System vorgegeben bzw. werden durch Ermittlung von Diagnoseinformationen beim Aufruf zusammen gestellt.


In diesem Kapitel werden die möglichen Ereignismeldungen einer SIMATIC S7 Station aufgezeigt und deren Abbildung in OPC UA (SIMATIC NET V8.0) genauer beschrieben.

Kategorien

Ereignismeldungen, die von einer S7 Station gemeldet werden können, sind in zehn Kategorien (Categories) eingeteilt:

• System Meldung (system message)

• Programmierter Alarm (off normal)

• Programmierter Alarm (level)



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

• Programmierter Alarm (deviation)

• Programmierter Alarm (rate of change)

• Programmierter Alarm (trip)

• Programmierter Alarm (change of state)

• Programmierter Alarm (device failure)

• Programmierter Alarm (system failure)

• Verbindungs-Alarm (statepath)

System Meldungen

Ereignisse aus der Klasse der Systemfehlermeldung (früher Diagnoseereignisse) werden von der S7-CPU oder CP bzw. der Peripheriebaugruppe (z.B. DP-Slaves oder PNIO-Device) selbstständig ausgelöst und in den Diagnosepuffer der entsprechende Komponente abgefüllt. Es werden die entsprechenden Fehler-OBs aufgerufen und Anhand der hexadezimalen ID-Nummer des Diagnoseereignisses kann unter Zuhilfenahme der Baugruppenbeschreibung die Ursache ermittelt werden (z.B. Neustart/Warmstartaufforderung, Wiederanlauf, Peripheriezugriffsfehler, Ziehen/Stecken Alarm, etc.).

Ereignisse aus der Klasse der anwenderdefinierten Diagnosemeldungen (SFC52) werden grundsätzlich im Diagnosepuffer der CPU eingetragen und können zusätzlich als Systemmeldung über OPC verfügbar gemacht werden. Im Anwenderprogramm wird die Funktion WR_USMSG aufgerufen, die zuvor mit Textmeldungen für kommendes und gehendes Ereignis projektiert wurde.

Programmierte Alarme

Die SIMATIC S7 Steuerungsfamilie bietet als Bestandteil des Betriebssystems Systemfunktionsbausteine (SFB/SFC), die Ereignisse über das S7-Protokoll versenden können. Der Umfang und Typ dieser SFC ist abhängig vom Typ der jeweiligen S7-CPU. Diese Bausteine müssen im S7 Steuerungs-Programm (z.B. AWL-Code) aufgerufen werden, um einen entsprechenden Alarm auszulösen. Daher die Bezeichnung „SIMATIC S7 programmed alarm“.

Die folgende Tabelle enthält alle blockbezogenen S7 Ereignisse. Es sind jeweils der Name des Bausteins und seine Kernfunktion gegenübergestellt. Die aufgelisteten Bausteine unterscheiden sich in der Anzahl der Kanäle (Anzahl der überwachten Signale) und in der Anzahl der möglichen Begleitwerte, die mit übertragen werden können. Weiterhin können einige Alarme quittiert werden, andere nicht.

Tabelle 5-1

Ereignis Beschreibung

ALARM_8 (SFB34) 8 Kanäle, quittierbar, keine Begleitwerte

ALARM_8P (SFB35) 8 Kanäle, quittierbar, bis zu 10 Begleitwerte

NOTIFY (SFB36) 1 Kanal, unquittierbar, bis zu 10 Begleitwerte

ALARM (SFB33) 1 Kanal, quittierbar, bis zu 10 Begleitwerte

ALARM_S (SFC18) 1 Kanal, unquittierbar, 1 Begleitwert

ALARM_SQ (SFC17) 1 Kanal, quittierbar, 1 Begleitwert

AR_SEND (SFB37) zum Versenden von Archiven




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Ereignis Beschreibung

NOTIFY_8P (SFB 31) 8 Kanäle, unquittierbar, bis zu 10 Begleitwerte

ALARM_DQ (SFC 107) 1 Kanal, quittierbar, 1 Begleitwert

ALARM_D (SFC 108) 1 Kanal, unquittierbar, 1 Begleitwert

Die S7-300 besitzt nicht den vollen Umfang der Alarmfunktionen.

Hinweis SIMATIC S7-300 unterstützt nur ALARM_S und ALARM_D sowie die quittierbaren Varianten ALARM_SQ und ALARM_DQ.

Es wird bei jeder Zustandsänderung eines der überwachten Kanäle ein Alarm ausgelöst und gesendet (steigende und fallende Flanke eines Kanaleingangs bilden kommendes und gehendes Ereignis). Die Dauer eines anstehenden Alarms bezeichnet man als Alarmzyklus, also die Zeit zwischen steigender und fallender Flanke des Signaleingangs während der Signaleingang (SIG) des Bausteins den Zustand „high“ (true) besitzt. Während dieser Zeit belegt der Alarm Systemressourcen, sein Zustand und Zeitstempel werden im Speicher gehalten und können beispielsweise durch einen Refresh abgefragt werden. Wenn die Zustandsmaschine vollständig abgearbeitet wurde, also ein quittiertes Alarmereignis „gegangen“ ist und entsprechend der SIG Eingang auf „low“ (false) gefallen ist, „vergisst“ die S7 CPU diesen Alarm und gibt die Ressource frei. Es wird also keine Historie in der Steuerung gehalten.

Zusätzlich zu den oben beschriebenen programmierten Alarmen bietet die S7-400 den SCAN-Alarm, der sogenannte symbolische Meldung. Hierbei handelt es sich um eine zyklische Überwachung einzelner Binärsignale (Input, Output und Merker). Der SCAN-Alarm wird über die Symboltabelle projektiert und sollte „sparsam“ eingesetzt werden, da er aufgrund der zyklischen Prüfung das System belastet. Für den SCAN-Alarm wird kein Programmbaustein aufgerufen daher wird er auch als „projektierter“ Alarm (im Gegensatz zum „programmierten“ Alarm) bezeichnet.

Verbindungs-Alarme

Die Klasse der Verbindungs- oder Statepath-Alarme wird nicht in der S7 Station initiiert sondern im OPC Server selbst. Der Wegfall einer S7-Verbindung oder eine Verbindungsunterbrechung (z.B. CP geht in Stop oder Kabel wird gezogen) wird vom OPC Server erkannt, ein entsprechender Alarm wird generiert und an alle dafür angemeldeten Clients gesendet.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

5.3 Abbildung auf OPC UA Eventfelder

Die OPC UA Alarm & Conditions Spezifikation definiert Eventfelder, die in einem OPC UA Alarm enthalten sein müssen und solche, die je nach Alarm Typ (Event Typ) zusätzlich enthalten sein müssen. Weiterhin gibt es Attribute, die optional (herstellerspezifisch) enthalten sein können.

Dieses Kapitel beschreibt die OPC Eventfelder und ihren Inhalt entsprechend der S7-Alarme. Hier beschrieben sind die Defaultbelegungen dieser Felder. Einige Felder wie beispielsweise „Source“, „Area“ und „Message“ sowie „Time“ können durch Konfigurationsoptionen auch mit anderen Inhalten befüllt werden. (siehe hierzu z.B. Kapitel 5.5)

Event Information des BaseEventType

Alle Events in OPC UA leiten sich vom BaseEventType ab. Die folgende Tabelle zeigt alle Standard Information, die mit jedem Event geliefert werden:

Tabelle 5-2

BrowseName Beschreibung

EventId ByteString

EventType NodeId (NamespaceIndex und Category Nummer der Alarmtyps

Time <S7 Zeit als der Alarm gerufen wurde> (änderbar über NetPro S7-Verbindungprojektierung, Hinweis: nur bei Statepath wird PC Zeit in UTC geliefert)

TimeZone Die Zeitzone von UTC abweichend (default null)

ReceiveTime Zeit als der Alarm vom Server empfangen wurde (UTC)

Severity <1..1000> (default=500, einstellbar über NetPro, S7-Verbindungsprojektierung oder direkt beim Bausteinaufruf angegeben)

Message <Text#> Der Text kann über STEP7 geändert werden. Die Konfiguration ist in Kapitel 5.1 beschrieben.

SourceNode NodeID der Quelle <VerbindungsName\PfadZumBaustein> (änderbar über STEP7 Bausteinprojektierung)

SourceName <VerbindungsName\PfadZumBaustein> (änderbar über STEP7 Bausteinprojektierung)

Hinweis Bei einigen Bausteinen wie ALARM, ALARM_8P oder NOTIFY wird im S7-Programm direkt am Baustein die Priorität angegeben (0-16); diese setzt sich gegen die in NetPro projektierbare Vorgabe-Priorität für Alarmmeldungen durch und wird entsprechend einer linearen Umrechnung automatisch in OPC Severity (1000-1) umgewandelt. Die höchste Bausteinpriorität „0“ entspricht der höchsten OPC Severity „1000“.

Die in NetPro projektierten Alarm-Prioritäten für bestimmte Alarm-Nummern setzen sich gegenüber der allgemeinen Vorgabe-Priorität für Alarmmeldungen und auch gegenüber programmierten Meldungsgewichten durch.

ALARM_S/D und ALARM_SQ/DQ besitzen keine Severity, so dass immer die projektierten Meldungsgewichte verwendet werden.


5.3 Abbildung auf OPC UA Eventfelder


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Zusätzliche Eventfelder für ConditionType Events

Die folgende Tabelle zeigt Felder, die bei „ConditionalType Events“ zusätzlich zu den in Tabelle 5-3 gezeigten, geliefert werden.

Tabelle 5-3


ConditionNodeID String NodeID <FesterText#> (vorgegebener Text, bestehend aus symbolischem Verbindungsnamen.alarm<Nummer>)

ConditionName <symbolischer Name der EventID,SubConditionName

Retain Information ob der Alarm angezeigt werden soll oder nicht

Zusätzliche Eventfelder für AcknowledgeableConditionType Events

Die folgende Tabelle zeigt Felder, die bei „AcknowledgeableConditionalType Events“ zusätzlich zu den in Tabelle 5-4 gezeigten, geliefert werden.

Tabelle 5-4


AckedState Zeigt den Quittierungszustand an entweder „Acknowledged“ oder „Unacknowledged“

EnabledState Immer Enabled

Attribute für Category 40 bis 47 (Programmed)

Programmierte Alarme der Kategorie 40 bis 47 liefern in weiteren Eventfeldern zusätzliche Informationen entsprechend der folgenden Tabelle. Es können bis zu 10 Begleitwerte (jeweils mit Datentyp, Länge und den eigentlichen Daten) als Eventfelder in einem Alarm enthalten sein.

Tabelle 5-5


S7AlarmAddData1 Begleitwert 1 (Wert und Datentyp)

…

S7AlarmAddData10 Begleitwert 10 (Wert und Datentyp)

S7AlarmAddText1 Text (über Step7 projektiert), Sonderbedeutung SourceName

S7AlarmAddText2 Text (über Step7 projektiert), Soderbedeutung AreaName

...

S7AlarmAddText9 Text (über Step7 projektiert)

S7AlarmId <Event ID> (VT_UI4) =”3”

S7Time <S7 Zeit> (VT_Date)

S7Connection String NodeID (symbolischer Verbindungsname)

S7AlarmSubId <Subevent ID> (VT_UI4) =”3”

S7AlarmState AckState (Quittierzustand Statuswort), EventState, State



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Eventfelder für Category 14 (Statepath)

Verbindungs-Alarme der Kategorie 14 liefern in Eventfeldern feste Informationen entsprechend der folgenden Tabelle.

Tabelle 5-6


Message “statepath”

AckedState “Acknowledged”

ConditionName “statepath”

Retain “True”

Time PC Zeit in UTC

ReceiveTime Wie Time


5.4 S7 Programm dieses Beispiels


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

5.4 S7 Programm dieses Beispiels

Einführung

Für dieses Applikationsbeispiel wurde ein Bausteinaufruf gewählt, der möglichst in allen S7 CPUs ablauffähig ist und die Grundfunktionen der „programmierten Alarme“ verdeutlicht. Auf eine Auswertung des Status-Wortes wurde aus Gründen der Übersichtlichkeit verzichtet.

Das erforderliche AWL Code-Fragment ist in der S7-300 und in der S7-400 ablauffähig und wird daher hier als allgemeines Beispiel verwendet.

Anwenderprogramm

Das S7 Programm teilt sich im Wesentlichen in zwei Teile. Zunächst werden die Binärsignale für die Alarme simuliert, anschließend werden die Alarmbausteine mit den Signalen beschaltet und im FB 200 aufgerufen.

Abbildung 5-4

Simulation der Binärsignale

Die folgende Tabelle gibt eine kurze Übersicht über die Programmteile und ihre Funktion zur Signalsimulation. Auf Details wird hier bewusst verzichtet, weitere Kommentare befinden sich im AWL-Code.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Tabelle 5-7

Baustein Anmerkung

OB1 Cyclic Main Hier wird zunächst ein variabler Timer gesetzt, mit dessen Intervall die weiteren Programmfunktionen aufgerufen werden. Die Datenänderungsgeschwindigkeit kann über DB11 Byte 0 gesetzt werden.

FC15 ChangeSignalBits Toggelt boolesche Variablen im DB11 sowie das Merkerbit 20.0 (symbolische Meldung).

DB11 SimulationAlarms enthält globale Variablen zur Konfiguration der Datensimulation.

DB20 AssiciatedValues enthält beispielhaft einige Begleitwerte, die mit ausgelösten Alarmen verschickt werden sollen.

Programmierte Alarme

Die folgende Tabelle gibt eine kurze Übersicht über die Programmteile und ihre Funktion zur Signalsimulation. Auf Details wird hier bewusst verzichtet, weitere Kommentare befinden sich im AWL-Code.

Tabelle 5-8

Baustein Anmerkung

OB1 Cyclic Main Aufruf des Alarmbausteins (SFC107) für ALARM_DQ und des Alarmbausteins (SFB35) für ALARM_8P über den Funktionsblock 200. Der SFB35 existiert nur in der S7-400.

SFB35 + Multi-Instanz-DB200

ALARM_8P Der Alarmbaustein besitzt 8 Signaleingänge sowie 10 mögliche Begleitwerte. Er ist mit 8 Signalbits aus DB11 und den Begleitwerten aus DB20 beschaltet.

SFC107 ALARM_DQ Der Alarmbaustein besitzt einen Signaleingang und kann einen Begleitwert liefern.

Projektierter Scan

In der S7-400 wurde ein Scan-Alarm projektiert, der im 500ms Intervall das Merkerbit 20.0 überwacht.


5.5 Beispielhafte Projektierung eines SCAN Alarms


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


Einführung

In der S7-400 besteht die Möglichkeit symbolbezogene Meldungen zu projektieren. Diese so genannten SCAN-Alarme werden über die Symboltabelle von STEP 7 konfiguriert. Im Folgenden wird beispielhaft ein SCAN-Alarm projektiert, um die prinzipielle Vorgehensweise zu erläutern.

Hinweis Symbolbezogene Meldungen (SCAN) stehen nur in S7 400 CPUs zur Verfügung. Sie werden über Systemdatenbausteine (SDB) übertragen, entsprechend müssen diese bei Änderung runter geladen werden, ebenso die PC Station (OPC Server).

Vorgehensweise

Für symbolische Meldungen werden azyklisch zum Programmablauf in einem festen Raster binäre Signalzustände geprüft. Daher sind sie besonders für Ereignisse geeignet, die nicht direkt im Zusammenhang mit dem Programmfluss stehen. Wenn beispielsweise das S7 Programm eine Schrittkette zur Steuerung eines Lastenaufzugs darstellt, würde die Temperaturüberwachung des Antriebsmotors mit einem Scan-Alarm überwacht werden. Die Endschalter der Türen dagegen würden mit programmierten Alarmen (SFC) abgebildet werden, da sie direkt den Programmablauf beeinflussen.

Tabelle 5-9

Nr. Aktion Anmerkung

1. Öffnen Sie den Symboleditor und fügen Sie zwei Symbole ein. Ein Merkerbit, das das zu überwachenden Signal darstellt und ein Merkerwort, das als Begleitwert verwendet werden soll.

Nachdem die Symbole angelegt wurden muss die Symboldatei gespeichert werden.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


2. Mit Rechtsklick auf das zu scannende Symbol (hier „Scan_Signalbit“) öffnen Sie über „Special Object PropertiesMessage…“ den Konfigurationsdialog. (deutsch: „Spezielle ObjekteigenschaftenMeldung…“)

3. Blenden Sie im Konfigurationsdialog der Meldungsprojektierung die erweiterte Ansicht auf.

Der Meldetext und der Infotext können auch mehrzeilig angegeben werden. Falls Begleitwerte im Meldetext angezeigt werden sollen, müssen diese in „@“ eingeschlossen werden.

4. Editiert Sie den Platzhalter entsprechend des gewünschten Formats.

Der Aufbau des Platzhalters ist wie folgt: @<Nr. des Begleitwertes><Elementtyp><Formatangabe>@ Die Formatangabe wird mit „%“ eingeleitet, gefolgt von der Anzahl der Stellen und dem Formatkennzeichner. Eine detaillierte Beschreibung findet sich in der STEP7 online Hilfe.

5. Konfigurieren Sie in der Lasche „SCAN-Attribute“ den Begleitwert.

Es können bis zu 10 Begleitwerte konfiguriert werden, für eine bessere Übersicht können Filter gesetzt werden, um die gewünschten Begleitwerte einfacher zu finden. Das SCAN-Raster ist auf 500ms voreingestellt.




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


6. In der Lasche „Additional text“ können Sie bis zu 9 zusätzliche Texte angeben. Aus dem ersten Zusatztext wird das OPC Attribut „Source“ und aus dem zweiten Zusatztext das Attribut „Area“ gebildet. Weitere Einstellungen wie Alarmklasse und Priorität können für jeden Scan-Alarm getrennt eingestellt werden. Hier wird exemplarisch eine „Warning – high“ eingestellt. Die Priorität ist zwischen „0“ und „16“ einstellbar.

Im Gegensatz zu programmierten Alarmen bedeutet bei projektierten, symbolischen Meldungen ein niedriger Wert auch eine niedrige Priorität. Hier wird „8“ eingestellt, um als OPC-Severity einen mittleren Wert von 500 zu erhalten.

7. Nachdem die Projektierung der SCAN-Alarme abgeschlossen ist, müssen Sie die Systemdatenbausteine (SDB) neu generieren und in die S7-400 laden.

Das grüne Fähnchen zeigt an dass für dieses Symbol ein Scan-Alarm konfiguriert ist.

Hinweis Für jede konfigurierte SCAN Rate werden Systemdatenbausteine generiert. Die projektierten Signale werden asynchron zum laufenden Programm geprüft. Es ist zu beachten, dass die SCAN-Funktion das System belastet und daher nur in geringem Umfang genutzt werden sollte.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Hinweis Auch die PC Station (OPCServer) muss neu übersetzt werden (z.B. in NetPro) und anschließend erneut runter geladen werden.

5.6 Beispielhafter Aufruf eines ALARM_8P

Einführung

Der am häufigsten verwendete Alarmbaustein in S7-400 Stationen ist der SFB35 (ALARM_8P). Dieser Baustein stellt die größtmögliche Funktionalität im Hinblick auf Alarm and Events bereit. Die Aufrufparameter werden beispielhaft erläutert und ihre Bedeutung für die OPC Events erklärt.

Hinweis Der Baustein steht nur in S7 400 CPUs zur Verfügung. In CPU Konfiguration (HW-Konfig) ist die Deaktivierung der Einstellung „Acknowledgement Triggered Reporting“ erforderlich, denn nur dann sendet ALARM_8P auch Alarme.

Hinweis Der Baustein wird hier beispielhaft zyklisch im OB1 aufgerufen, um die Funktionalität zu demonstrieren. Entsprechend des gewünschten Anwendungsfalles ist ein Aufruf im zeitgesteuerten OB35 oder in anderen OBs (z.B. OB40) sinnvoll.

Das folgende Bild zeigt den Bausteinaufruf im AWL-Code einer S7-400. Es wird ein Instanzdatenbaustein (hier DB35) erzeugt, der die Lokaldaten des Aufrufs hält. Wird der SFB innerhalb eines FB aufgerufen, können die Parameter im Multiinstanz DB abgelegt werden. Die benötigten Systemattribute (z. B. S7_server und S7_a_type) und die entsprechenden Werte werden automatisch zugewiesen, sobald hier ein symbolischer IN Parameter angelegt wurde und am SFB Aufruf angegeben ist. Auf eine Auswertung von Error-Bit und Status-Wort wurde aus Gründen der Übersichtlichkeit verzichtet. Eine detaillierte Beschreibung der Parameter findet sich in der STEP7 Online Hilfe.


5.6 Beispielhafter Aufruf eines ALARM_8P


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Abbildung 5-5

Kanal Parameter

Auf die Signaleingänge (auch Kanäle) SIG_1 bis SIG_8 des Bausteins werden z.B. die Eingänge einer Peripheriebaugruppe geschaltet. Sobald einer der Signaleingänge seinen Zustand ändert, wird ein Alarm ausgelöst. Positiver Wechsel wird als „kommendes“ Ereignis und negativer Wechsel als „gehendes“ Ereignis gewertet.

Verwaltungs-Parameter

Die Ereignisnummer (EV_ID) identifiziert den Baustein steuerungsweit eindeutig und wird von Step7 vergeben um Konsistenz zu gewährleisten („0“ ist nicht erlaubt)

Die Priorität (auch Gewichtung) des Alarms wird am Parameter SEVERITY mit dem Wertebereich „0“ bis „127“ eingestellt, wobei eine niedrige Zahl eine hohe Priorität repräsentiert.

Der aktuelle Quittierungszustand der einzelnen Kanäle wird im Parameter ACK_STATE dargestellt. Das Bitfeld zeigt eine „1“ für quittiert und eine „0“ für unquittiert. Die Bits 0 bis 7 werden für „kommende“ Ereignisse und die Bits 8 bis 15 für „gehende“ Ereignisse der 8 Kanäle benötigt.

Begleitwert-Parameter

Bis zu 10 Begleitwerte können parametriert werden. Es handelt sich um ANY-Pointer, die wie hier dargestellt z.B. auf den Datenbaustein DB10 zeigen. Der dort enthaltene Wert wird beim Auslösen des Alarms als Begleitwert mitgeschickt.

Hinweis Es werden immer alle aktuell anstehenden Begleitwerte mitgeschickt, unabhängig davon, welcher Kanal (Signaleingang) den Alarm ausgelöst hat.

Any-Pointer auf Begleitwerte

Signaleingang des überwachten binären Signals



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Verhalten

Die folgende Abbildung zeigt das Verhalten der Komponenten wenn ein Alarm ausgelöst wird:

Abbildung 5-6

Die folgende Tabelle beschreibt die Abläufe zwischen den Komponenten wenn ein Alarm ausgelöst wird.

Tabelle 5-10

Nr. Beschreibung

1 Der Eingang E0.3 erfährt eine Zustandsänderung von „0“ nach „1“. Es wird ein Aufruf des ALARM_8P Bausteins angestoßen.

2 Die S7 Station sendet ein Ereignis über das S7-Protokoll an den Verbindungspartner (die PC Station). Der SIMATIC NET OPC Server identifiziert den Alarm anhand seiner Herkunft (S7-Verbindung) und anhand seiner Event ID (hier „1“). Weiterhin ist der auslösende Kanal (hier SIG_3) bekannt (siehe Parameter des Bausteinaufrufes).

3 Nun prüft der OPC Server die empfangenen Parameter und bildet diese auf einen OPC Event ab. Das Ereignis bekommt den Bezeichner „ALARM1,3“ (Event ID=1 und Signal =3) und die Eventfelder werden befüllt. Die S7-Baustein-Severity wird auf die OPC-Event-Severity umgerechnet (hier: „0“ wird zu default = „500“). Als OPC Event Source wird der S7-Verbindungsname eingetragen (hier „S7:\400“), die Time und ActiveTime Parameter und die OPC Category werden befüllt.

4 Bevor der Alarm nun an die OPC Clients gemeldet wird, wird noch die Textdatenbank des S7 Servers durchsucht ob für „ALARM1,3“ ein Meldetext, Area oder Source hinterlegt ist, falls ja werden die entsprechenden OPC Eventfelder befüllt. Falls erforderlich werden Begleitwerte extrahiert und formatiert in den Text eingehängt.

5 Wenn kein Filterkriterium es verhindert, wird die Notification an den OPC Client gesendet.

6 Der Event wird im OPC Client angezeigt. Der Zustand ist ACTIVE und ACK_REQUIRED, das entspricht „gekommen“ und „quittierpflichtig“. Wird der Alarm im Client quittiert, sendet der OPC UA Server eine Nachricht in die S7-400 CPU. Der Status kann im Merkerwort geprüft werden


5.7 Beispielhafte Projektierung von Systemfehlermeldungen


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Hinweis Die Bezeichnung des Alarms mit „ALARM<EV_ID>,<SIG#> gibt es nicht für den ersten Kanal (SIG_1), dieser wird ohne Signalnummer geliefert. Im obigen Beispiel sind 5 von 8 Kanälen beschaltet und es können Ereignisse mit folgende Bezeichnern auftreten: „ALARM1“, „ALARM1,2“, „ALARM1,3“, „ALARM1,5“ und „ALARM1,6“.

Hinweis Weitere Hinweise zu den Parametern der Alarmbausteine finden Sie in der STEP7 Online-Hilfe

5.7 Beispielhafte Projektierung von Systemfehlermeldungen

Einführung

In den SIMATIC Stationen besteht die Möglichkeit Meldungen zu projektieren, die Systemfehler beschreiben. Die hierfür erforderlichen Bausteine und Textmeldungen sind vorkonfiguriert und lesen z.B. Hardwareinformationen aus und fügen diese in Texte ein. Im Folgenden wird beispielhaft gezeigt wie diese Meldungen generiert werden.

Hinweis Die notwendigen Bausteine und Meldetexte werden von STEP 7 erzeugt. Vom Anwender müssen die erzeugten Bausteine lediglich in die CPU geladen werden. Der OPC Server muss anschließend auch neu geladen werden um die Textdatenbank zu aktualisieren.

Vorgehensweise

Die Komponenten der S7-300-Stationen, S7-400-Stationen, PROFINET IO-Devices, DP-Slaves und WinAC werden von "Systemfehler melden" unterstützt, sofern sie Funktionen wie Diagnosealarm, Ziehen/Stecken-Alarm und kanalspezifische Diagnose unterstützen. Die Diagnosedatensätze entsprechend der Profibus/Profinet Baugruppen werden über die SFB52 (RDREC) und SFB54 (RALRM) gelesen.

Die erforderlichen Bausteine werden von STEP 7 erzeugt.

Tabelle 5-11


1. Markieren Sie in HW Konfig die CPU und über OptionsReport System Errors…(deutsch: Extras Systemfehler Melden…)

Diese Schritte müssen für jede CPU wiederholt werden für die Systemfehler gemeldet werden sollen



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


2. In der Lasche „General“ (deutswch: „Allgemein“) werden die Ziel FB und DB Nummern festgelegt.

Hier ist darauf zu achten das diese Nummern nicht schon anderweitig im Programm verwendet werden. Gegebenenfalls sind hier Korrekturen vorzunehmen.

3. Konfigurieren Sie in der Lasche „Messages“ (deutsch: „Meldungen“) die Meldungen.

Hier sollte für jede meldende Komponente die korrekte Meldungsklasse vergeben werden und auch die Priorität entsprechend angepasst werden.


5.8 Hinweise zur Alarmprojektierung der S7-300


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


4. Klicken Sie auf die Schaltfläche Generate (Generieren) um die Bausteine zu generieren.

Nachdem die Bausteine generiert wurden, muss neben der S7 auch der OPC Server neu geladen werden (z.B. NetPro -> alles Speichern und übersetzen und anschließend runterladen.

Funktionsweise

Der von 'Systemfehler melden' erzeugte Diagnose-Baustein (FB mit zugeordnetem Instanz-DB und ein oder mehrere Global-DB(s) und einem FC) wertet die Lokaldaten des Fehler-OBs aus und liest evtl. zusätzliche Diagnoseinformationen der Fehler auslösenden Hardware-Komponente.

Wird nun beispielsweise eine Baugruppe aus den Rack gezogen/gesteckt wird der dazugehörige Fehler OB (OB8x) aufgerufen. In diesem OB wird nun der SFM Baustein gerufen, der die Meldung erzeugt (intern wird ein alarm_s ausgelöst).

In Abhängigkeit von der verwendeten CPU werden Fehler-OBs 7x (Redundanzfehler) und Fehler-OBs 8x (Zeit/ Hardwarefehler) erzeugt. Falls diese schon existieren, wird der Code zur Erzeugung von Meldungen, der Aufruf des generierten FB, hinten angehängt.

Hinweis Eine detaillierte Beschreibung der einzelnen Parameter findet sich in der STEP7 online Hilfe.

5.8 Hinweise zur Alarmprojektierung der S7-300

Allgemein

Die Steuerungen der SIMATIC S7-300 Familie unterstützen nur die Alarmbausteine ALARM_S und ALARM_SQ sowie die Bausteine ALARM_D und ALARM_DQ. (D und DQ erst ab Firmwareversion > 2.5.0). Die S7-300 unterstützt Systemfehlermeldungen.

Weiterhin ist es vom Typ der CPU abhängig wie viele Alarmbausteine gleichzeitig aufgerufen werden können da hierdurch Systemressourcen belegt werden. Es



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

können je nach CPU somit 20, 40 oder 300 Alarme gleichzeitig anstehen. Eine Übersicht finden sie unter \1\.

Projektierung von Alarmtexten

Für die Projektierung der Alarmtexte mit STEP7 ist ein Projekt erforderlich in dem die S7-300 sowie eine PC Station mit OPC Server vorhanden sind. Es muss eine S7 Verbindung zwischen diesen beiden Komponenten bestehen. Nur dann wird beim „Speichern und Übersetzen“ die Alarmprojektierung inklusive der Textdatenbank für den OPC Server erzeugt. Der OPC Server muss jedes Mal neu geladen werden, sobald an den Alarmtexten Änderungen vorgenommen wurden.

Hinweis Eine Projektierung von Alarmtexten für eine einseitig verbundenen S7-300 mittels STEP7 ist erst ab der STEP7 Version 5.5 inklusive HotFix 4 möglich.

6 Konfiguration und Projektierung

6.1 Konfiguration der SIMATIC S7 Stationen


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

6 Konfiguration und Projektierung Das folgende Kapitel richtet sich an Techniker und Programmierer welche Alarme an einer Anlage konfigurieren und in Betrieb nehmen wollen.

Die folgenden Kapitel beschreiben detailliert die Konfiguration der S7 Steuerung, der PC Station mit OPC UA Server und die Konfiguration des OPC UA Servers und dessen Security-Einstellungen.


Es wird vorausgesetzt, dass alle Hardware- und Softwarekomponenten erfolgreich installiert und entsprechend verkabelt wurden.

Die folgenden Projektierungs- und Konfigurationsschritte der SIMATIC S7-Stationen beschreiben beispielhaft die Vorgehensweise. Nehmen Sie selbstständig Anpassungen entsprechend Ihrer Hardware vor.

Hinweis Nach dem Speichern und Übersetzen werden alle Konfigurations- und Projektierungsinformationen überschrieben.

Die folgende Tabelle zeigt die Konfiguration und Projektierung der SIMATIC S7 Station.

Tabelle 6-1


1. Starten Sie STEP 7: SIMATIC Manager öffnen und legen Sie ein neues Projekt an.

Hier wurde der Name „AE-Sample2“ verwendet.

2. Fügen Sie eine SIMATIC 400 Station ein und vergeben Sie einen Namen (hier „S7-400“). Fügen Sie eine SIMATIC 300 Station ein und vergeben Sie einen Namen (hier „S7-300“).



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


3. Öffnen Sie die SIMATIC Stationen mit HW-Config und fügen Sie die CPU sowie CP und andere Komponenten ein.

4. Öffnen Sie den Eigenschaften-Dialog und stellen Sie die IP Adresse ein.

5. Stellen Sie die IP Adresse ein (hier 192.168.0.52) sowie die dazugehörige Subnetmaske. Legen Sie ein Ethernet Netzwerk an. Eine MAC Adresse wird nur dann eingegeben wenn die Station über ISO Transport Layer 4 kommunizieren soll.




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


6. Wiederholen Sie die Schritte entsprechend für beide SIMATIC Stationen und laden Sie anschließend beide Stationen.

Führen Sie diesen Schritt für die S7-300 und die S7-400 Station durch.

7. Neustart der Baugruppen Die Stationen werden neu gestartet (Warmstart). Bestätigen Sie entsprechende Dialoge mit „JA“.

8. S7-Verbindungen anlegen Die Verbindungsprojektierung wird zusammen mit der Konfiguration der PC Station beschrieben (im Kapitel 6.2)



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

6.2 Konfiguration der PC Station

Die Konfiguration und Projektierung der SIMATIC PC Station wird mittels STEP 7 vorgenommen und schrittweise beschrieben. Alternativ kann auch mit Hilfe des NCM-PC Softwarepakets eine Projektierung vorgenommen werden. Die Vorgehensweise ist identisch, es werden jedoch einseitig projektierte Verbindungen verwendet.

Tabelle 6-2


1. Starten Sie STEP 7: SIMATIC Manager und öffnen Sie das Projekt.

Öffnen des zuvor angelegten Projektes „AE-Sample“.

2. Fügen Sie eine SIMATIC PC Station ein und vergeben Sie einen Namen. Der Name der PC Station muss identisch mit dem „Windows-Namen“ des PCs sein (siehe Arbeitsplatz Eigenschaften Computername).

3. Öffnen Sie die PC Station mit HW-Config und fügen Sie den OPC Server und den CP ein. Der Steckplatz muss identisch mit dem Index sein, der in der Konfigurationskonsole vergeben wurde, hier Index „2“ für Ethernetkarte. Die Applikation „OPC Server“ wurde auf Steckplatz „1“ gesteckt.




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

4. Vergeben Sie für die Ethernetkarte eine IP-Adresse (hier „192.168.172.1“) und verbinden Sie die Karte mit dem Ethernetnetzwerk.

5. Aktivieren Sie auf den Eigenschaftsseiten des OPC Servers (Doppelklick auf OPC Server) im Register „S7“ die Verwendung der symbolischen Adressierung.

6. Legen Sie mit NetPro zwei S7-Verbindungen vom OPC Server zu den beiden Steuerungen an. Es werden beide Verbindung über Ethernet angelegt. Nachdem der OPC Server selektiert wurde wird durch Doppelklick in die Verbindungsliste der Eigenschaftsdialog aufgeblendet.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

7. S7-Verbindung über Ethernet: Nachdem der Verbindungsweg gewählt wurde, kann der Verbindungsname geändert werden (hier „300“ für die Verbindung zur S7-300 und „400“ für die Verbindung zur S7-400). Die Verbindungspartner und die Parameter der Verbindung werden angezeigt.

8. Selektieren Sie im Eigenschaftsdialog der S7-Verbindung den zweite Reiter (OPC Connection Parameter). Hier werden verbindungs-spezifische Einstellungen vorgenommen. Stellen Sie den Verbindungsaufbau auf „permanent“ ein, damit die Verbindung gehalten wird, auch wenn gerade nicht kommuniziert wird. Konfigurieren Sie die Verbindung für die Übertragung von „Block and Symbol-related Messages“ und „Diagnostic Messages“.

10

9




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

9. Stellen Sie die Sprache (für mehrsprachige Meldungen) und die Zeitstempel ein. Slatfläche „Messages“ (deutsch „Meldungen“) (s. Schritt 8) Den Dialog der verwendeten Zeitstempel erreicht man über sie Schaltfläche „Message text details...“

Das Meldekonzept sieht verschiedene Zeitstempel vor. Hier wird konfiguriert welcher Zeitstempel für die Meldung verwendet werden soll. Entweder die S7-CPU Zeit (diese sollte entsprechend synchronisiert sein), die S7-CPU Zeit zuzüglich eines festen Offset (z.B. um eine bestimmte Zeitzone zu bilden), oder die PC-Zeit des OPC Servers in UTC (diese Einstellung wird beispielsweise verwendet wenn die nicht die S7 sondern nur der PC zeitsynchronisiert ist.

10. Das Einstellen der Alarm Priorität ist üblicherweise nicht erforderlich. Alle Alarme werden mit der default Priorität „500“ an die OPC Clients gemeldet. Die Liste der projektierten OPC Severity erreicht man über sie Schaltfläche „Messages...“ (s. Schritt 8)

Alle Alarme der SIMATIC Station werden, entsprechend einer Umrechnungstabelle, auf die entsprechende „OPC-Severity“ abgebildet. Wenn keine Priorität am Funktionsbaustein angegeben werden kann, wird default „500“ verwendet. Mit einer Liste von Ausnahmen kann einzelnen Alarmen eine geänderte Severtity mitgegeben werden, diese „projektierte Priorität“ setzt sich immer durch.

11. Nachdem die Verbindungen angelegt und konfiguriert sind, muss mit „Speichern und Übersetzen“ das Projekt kompiliert werden. Anschließend müssen die Stationen geladen werden (Download). Die PC Station kann auch mit der XDB-Datei, wie in Kapitel 7.4 beschrieben, geladen werden.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

6.3 Konfiguration der OPC UA Security

Die Sicherheitsmechanismen von OPC Unified Architecture werden in verschiedenen Ebenen eingestellt. Es können Verschlüsselung und Signierung der Übertragung sowie Authentifizierung zum Verbindungsaufbau getrennt voneinander eingestellt werden. Nach der Installation des SIMATIC NET OPC UA Servers sind grundsätzlich sichere Verbindungen möglich. Neben dieser verschlüsselten Kommunikation ist auch eine unverschlüsselte Verbindung möglich. Der Server akzeptiert Authentifizierung mit Benutzer und Passwort oder auch den anonymen Verbindungsaufbau. Diese Einstellungen sind „unsicher“ und dienen nur der Erleichterung der Inbetriebnahme. Der OPC UA Server kann so konfiguriert werden, dass er ausschließlich eine verschlüsselte Übertragung mit Benutzer-Authentifizierung akzeptiert.

6.3.1 OPC UA Remote Kommunikation

Alle serverseitig erforderlichen Einstellungen bezüglich der Windows Firewall lassen sich einfach mit dem Konfigurationstool „PC Station einstellen“ (Configuration Console) einstellen und auch wieder entfernen.

Tabelle 6-3


12. Starten Sie das Konfigurationstool: Configuration Console (deutsch: PC Station einstellen) und selektieren Sie die Unterpunkt „Security“ (deutsch: Sicherheit).

Auf dem Server PC „OPC Server Station“: StartProgrammeSimaticSimaticNETConfiguration Console

13. Mit einem einzelnen Knopfdruck werden alle erforderlichen Einstellungen in der Firewall vorgenommen, um eine remote Kommunikation zu erlauben bzw. auch wieder zu sperren.

Hinweis Beachten Sie, dass an der Firewall des PC „OPC Client Station“ auch eine Ausnahme für die Applikation und den TCP-Port (4845) eingetragen werden muss.




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

6.3.2 Zertifikatsspeicher

Beim Aufbau einer sicheren Verbindung zwischen OPC UA Client und OPC UA Server werden Zertifikate ausgetauscht. Beide Applikationen müssen das entsprechende Zertifikat der Gegenseite prüfen und akzeptieren, damit ein Verbindungsaufbau zustande kommt.

Abbildung 6-1

Windows Certificate Store

SIMATIC NET OPC UA Server

.NET Sample OPC UA Client

Client.der

Secure EndPoint

Server‘s Certificate Location

Server.der

Certificates

Basic128RSA15

Server.der

CopyRejected Client.der

Accept

Certificates

SecureChannel withselected

SecurityPolicy

Der OPC UA Client dieses Beispiels verwendet die Windows Zertifikatsverwaltung (Windows Certificate Store). Hier befindet sich das öffentliche Zertifikat des Clients. Beim Verbindungsaufbau einer verschlüsselten Verbindung tauschen Server und Client ihre Zertifikate aus. Der Client zeigt das Zertifikat an und der Anwender muss diesem Zertifikat vertrauen. Durch das Akzeptieren wird das Serverzertifikat in der Windows Zertifikatsverwaltung hinterlegt.

Der OPC UA Server verwendet ein eigenes Zertifikatsverzeichnis und ist unabhängig von der Windows Zertifikatsverwaltung. Aus Sicherheitsgründen lehnt der OPC UA Server zunächst jedes Zertifikat eines unbekannten Client ab und speichert dieses in einem „Quarantäne-Ordner“ (rejected-folder). Wie bei anderen Serverdiensten muss ein Administrator dieses Client-Zertifikat in die Liste der vertrauenswürdigen Zertifikate kopieren, um dem entsprechenden Client den Zugriff auf den Server zu gestatten. Der Ort, an dem der OPC UA Server seine eigenen und die Zertifikate von OPC UA Clients speichert und verwaltet, ist das Datenverzeichnis des OPC UA Servers.

C:\ProgramData\Siemens\OPC\PKI\CA\

Hier befinden sich drei Unterordner mit folgendem Inhalt:

• \certs enthält das öffentliche Zertifikat des Servers sowie alle vertrauenswürdigen Zertifikaten von Clients. In diesen Ordner müssen öffentliche Zertifikate von OPC UA Clients kopiert werden damit der Server sie akzeptiert.

• \crl enthält eine Datei mit einer Liste von nicht vertrauenswürdigen Zertifikaten, die sogenannte „RevocationList“



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

• \private enthält das private Zertifikat des OPC UA Servers. Dieses Zertifikat darf niemandem zugänglich gemacht werden.

Der Server legt selbstständig unterhalb von \certs\ den Ordner \reject\ an und speichert alle unbekannten Client-Zertifikate zunächst in diesem „Quarantäne-Ordner“. Durch einfaches „Verschieben“ der Datei kann das Zertifikat vertrauenswürdig gemacht werden.

Konfiguration Server mit SIMATIC NET CD 2010 (V8.0)

Ab der SIMATIC NET CD V8.0 ist dies mit dem Konfigurationstool „PC Station einstellen“ möglich.

Tabelle 6-4


14. Starten Sie das Konfigurationstool: Configuration Console (deutsch: PC Station einstellen) und selektieren Sie den Unterpunkt „OPC UA Certificates“ (deutsch: OPC UA Zertifikate).

Auf dem Server PC „OPC Server Station“: StartProgrammeSimaticSimaticNETConfiguration Console

15. Hier finden Sie alle öffentlichen UA Zertifikate die der Server kennt. Mit Rechtsklick auf ein ausgewähltes Zertifikat können Sie dieses akzeptieren.




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Konfiguration Server mit SIMATIC NET CD 2008 (V7.1)

In der SIMATIC NET CD 2008 (V7.1) müssen vertrauenswürdige Client Zertifikate manuell in das Zertifikatsverzeichnis des Servers kopiert werden. Dazu werden sie zunächst auf dem Client PC aus der Windows-Zertifikatsverwaltung exportiert.

Tabelle 6-5


1. Öffnen Sie die Windows Zertifikatsverwaltung in der Management Konsole.

Auf dem Client PC „OPC Client Station“ Start Ausführen „mmc“

2. Im Menu Datei wählen Sie „SnapIn hinzufügen/entfernen“ und wählen Sie anschließend „Add>“.

3. Wählen Sie die Zertifikate für das „Computerkonto“ des lokalen Computers.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


4. Wählen Sie das zu exportierende Zertifikat (Rechtsklick Alle Aufgaben exportieren).

Der Export Wizard wird gestartet

5. Der private Schlüssel wird NICHT exportiert, sondern nur der „öffentliche“ Schlüssel

6. Wählen Sie DER Kodierung




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


7. Geben Sie einen Dateinamen an und speichern Sie die Zertifikatsdatei ab.

Manueller Import des Client Zertifikats beim Server

In der SIMATIC NET CD 2008 (V7.1) müssen vertrauenswürdige Client Zertifikate direkt in das Zertifikatsverzeichnis des Servers kopiert werden. Dazu wird die auf dem Client PC aus der Windows-Zertifikatsverwaltung exportierte Zertifikatsdatei umbenannt und auf den Server PC kopiert (ins Zertifikatsverzeichnis des Servers).

Tabelle 6-6


1. Öffnen Sie das Verzeichnis im Windows Explorer

Auf dem Server PC „OPC Server Station“

2. Kopieren Sie die Datei auf den Server PC „OPC Server Station“ und ändern sie die Dateiendung auf DER

Beispiel: „SampleClientPublic.der“

3. Im Zertifikatsverzeichnis der Servers finden Sie alle öffentlichen OPC UA Zertifikate denen der Server vertraut. An diese Stelle muss das Client-Zertifikat kopiert werden, um vom Server akzeptiert zu werden.

Das Verzeichnis befindet sich im Datenverzeichnis der SIMATIC NET Software. C:\ProgramData\Siemens\OPC\PKI\CA\



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

6.3.3 Authentication, SecurityPolicy und MessageSecurtityMode

In der SIMATIC NET CD 2008 (V7.1) sowie in der SIMATIC NET CD 2010 (V8.0) müssen nachfolgende Schritte manuell konfiguriert werden. Ab der SIMATIC NET CD 2011 (V8.1) sind diese Einstellungen in „PC Station Einstellen“ über die Oberfläche konfigurierbar. Der OPC UA Server unterstützt Authentifizierung von Clients beim Verbindungsaufbau. Es werden zwei Arten der Authentifizierung unterstützt:

• Anonymous

• UserName / Password

Nach der Installation sind beide Modi aktiv, um eine Inbetriebnahme zu erleichtern. Der Server kann umkonfiguriert werden, damit keine anonymen Anmeldungen mehr möglich sind. Benutzername und Passwort müssen vom Client angegeben werden und der Server prüft diese gegen die Windows Benutzerverwaltung. Somit können sich nur noch Clients verbinden, die einen Windows-Account auf der Servermaschine besitzen.

Der Server besitzt zwei Verbindungsendpunkt-Konfigurationen, die von Clients verwendet werden können. Jeder dieser Endpunkte repräsentiert einen anderen Verschlüsselungsmechanismus für die Datenübertragung.

• None

• Basic128RSA15

Nach der Installation sind beide SecurityPolicies aktiv, um eine Inbetriebnahme zu erleichtern. Der Server kann umkonfiguriert werden, um ausschließlich sichere verschlüsselte Verbindungen zu verwenden. Somit können sich nur noch Clients verbinden, die die Basic128RSA15 Verschlüsselung beherrschen.

Wenn Sie die Sicherheitsmechanismen des OPC UA Servers verändern wollen, editieren Sie die Konfigurationsdatei des OPC UA Servers und starten Sie den Server anschließend neu.

C:\ProgramData\Siemens\Simatic.Net\opc2\bins7\ SCoreS7.xml




Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Tabelle 6-7


1. Öffnen der OPC UA Serverkonfigurationsdatei „SCoreS7.xml“ in einem Editor (z.B. Notepad)

Die Datei befindet sich im Datenverzeichnis der SIMATIC NET Software. C:\ProgramData\Siemens\Simatic.Net\opc2\bins7

2. Stellen Sie RequireUserAuthenticationForSession auf „true“, wenn jeder OPC UA Client sich mit Benutzername und Passwort am Server authentifizieren soll, um eine Session aufbauen zu dürfen.

3. Löschen Sie den kompletten Eintrag SecuritySetting für SecurityPolicy „none“ und MessageSecurityMode „none“ aus der UAEndpoint Konfiguration. Der Server erlaubt danach ausschließlich verschlüsselte Übertragung vom Typ „Basic128RSA15“ mit Signierung und Encryption. Nur Clients, die ebenfalls diesen Verschlüsselungstyp unterstützen, können sich verbinden (falls ihrem Zertifikat vertraut wird).

Hinweis In den Nachfolgeversionen vom OPC UA Server auf der SIMATIC NET CD V8.1 werden diese Konfigurationsschritte über das Konfigurationstool „PC Station einstellen“ (Configuration Console) möglich sein.

Tabelle 6-8


4. Öffnen Sie das Tools „PC Station Einstellen (englisch: Configuration Console) und

In der Zeile S7 (Change details…) werden Einstellungen zur Sicherheit des S7 OPC UA Servers vorgenommen.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


selektieren Sie Protokollauswahl (englisch: Select OPC protocol)

5. Im Dialog der Protokolldetails kann der unsichere (unverschlüsselte) Endpoint an- und abgeschaltet werden.

7 Installation und Inbetriebnahme

7.1 Installation der Hard- und Software


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


Dieses Kapitel beschreibt, welche Hard- und Softwarekomponenten installiert werden müssen. Die Beschreibungen, Handbücher und Lieferinformationen, die mit den entsprechenden Produkten ausgeliefert werden, sind in jedem Fall zu beachten.

Übersicht

Nachfolgendes Bild zeigt den Hardwareaufbau der Anwendung sowie die erforderlichen Softwarekomponenten.

Abbildung 7-1

OPC Client Station

CPUS7-300

CPUS7-400

OPC Server Station

S7 Protokoll

Ethernet NIC

MS Visual Studio2008 SP1

.NET Framework 3.5 SP1

.NET BeispielOPC UA Client

Ethernet NIC

SIMATIC NETOPC UA Server S7

min. CD Edition 2010opc.tcp

CP CP

S7

S7

UA Stack

7.1 Installation der Hard- und Software

In diesem Kapitel wird beschrieben, welche Hardware- und Softwarekomponenten installiert werden müssen. Die Beschreibungen und Handbücher sowie Lieferinformationen, die mit den entsprechenden Produkten ausgeliefert werden, sollten in jedem Fall beachtet werden.

Installation der Hardware

Die Hardware-Komponenten entnehmen Sie bitte dem Kapitel 2. Gehen Sie für den Hardwareaufbau gemäß folgender Tabelle vor:

Tabelle 7-1


1. PC Station: Bauen Sie die PCI Einsteckkarte CP CP1613 entsprechend der beiliegenden Einbauanleitung in die PC Station ein.

Anstelle der des CP 1613 kann auch die onboard Ethernetkarte verwendet werden.

2. SIMATIC Stationen: Bauen Sie die S7 Steuerungen entsprechend der Abbildung in Kapitel 2 auf.

Abweichungen im Hardwareaufbau müssen in der Konfiguration berücksichtigt werden.

3. Verbinden Sie die PC Station mit den beiden SIMATIC Beachten sie die Einstellung von



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


Stationen über Ethernet analog zur Abbildung in Kapitel 2. Subnetmasken.

Hinweis Die Aufbaurichtlinien für Industrial Ethernet Netzwerke sind generell zu beachten.

Installation der Standard Software

Die Softwarekomponenten entnehmen Sie bitte dem Kapitel 2.

Für die Inbetriebnahme des Beispiels werden von der SIMATIC NET CD 2010 (V8.0) die folgenden Komponenten benötigt:

• SIMATIC NET PC-Produkte

• SIMATIC NCM PC/S7

Hinweis SIMATIC NCM PC/S7 müssen Sie nur installieren, wenn Sie kein STEP 7 auf dem PC installiert haben.

Das Projektierungstool SIMATIC STEP 7 V5.5 wird auf der PC Station nur benötigt, wenn die S7-Steuerungen geändert bzw. geladen werden sollen. Alternativ kann dieses Softwarepaket auch auf einem separaten Rechner installiert werden.

Hinweis Falls weder STEP 7 noch SIMATIC NET auf der PC Station installiert ist, installieren sie zuerst STEP 7

Microsoft Visual Studio .Net Professional wird auf der SIMATIC PC Station nur benötigt, wenn der Beispielcode verändert werden soll. Alternativ kann die Entwicklungsumgebung auf einem separaten PC (z.B. Engineering Station) installiert werden.

Hinweis Während der Installation des Visual Studio .Net werden die Sicherheitseinstellungen des Windows Betriebssystems gelockert. Überprüfen Sie nach der Installation der Entwicklungsumgebung die Sicherheit der SIMATIC PC Station und führen Sie gegebenenfalls ein Windows Update durch.


7.2 Installation der Applikationssoftware


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Tabelle 7-2


1 Installieren Sie SIMATIC NET CD 2010 (V8.1) auf die SIMATIC OPC Server Station.

2 Installieren Sie STEP 7 V5.5 SP1 auf die Engineering Station (z.B. Laptop).

Nur zur Programmierung und Verbindungsprojektierung der S7-300/400 und zum Erzeugen der Alarm- und Symbolinformation erforderlich

3 Installieren Sie das .NET Framework 3.5 SP1 auf die OPC Client Station.

Dieser Schritt ist nur dann nötig wenn das Framework noch von keiner anderen Applikation installiert wurde.

4 Installieren Sie Microsoft Visual Studio 2008 SP1 auf die OPC UA Client Station. Installieren Sie die C# Entwicklungsumgebung.

Dieser Schritt ist nur dann nötig, wenn der Code verifiziert oder modifiziert werden sollte.

7.2 Installation der Applikationssoftware

Die Bedienoberfläche und der Quell-Code der Applikation werden als ZIP-Datei geliefert.

Zum Starten der Bedienoberfläche auf der SIMATIC PC-Station sind die in der folgenden Tabelle aufgeführten Schritte notwendig.

Tabelle 7-3


1 Installieren Sie die Applikationssoftware auf die OPC UA Client Station. Kopieren Sie die Executables sowie die Assemblies (Ordner: „bin“) und auch den Quellcode (Ordner: „scr“) in ein Verzeichnis, auf das Sie Zugriffsrechte besitzen.

Den Quellcode benötigen Sie nur, wenn sie Modifikationen vornehmen wollen oder einzelne Funktionen verifizieren wollen.

2 Installieren Sie das STEP 7 Programm. Kopieren und entpacken Sie das STEP 7 Projekt.

Nehmen Sie ggf. Anpassungen bezüglich ihrer Hardware vor.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

7.3 Inbetriebnahme der SIMATIC S7 Stationen

Es wird vorausgesetzt, dass alle Hardware- und Softwarekomponenten erfolgreich installiert und entsprechend verkabelt wurden.

Hinweis Die mit diesem Beispiel ausgelieferte Projektdatei enthält die vollständig konfigurierten und projektierten SIMATIC S7-Stationen entsprechend der Beschreibung in Kapitel 2.3. Dieses STEP7 Projekt kann nur dann ohne Anpassung verwendet werden, wenn die Hardware identisch mit der Projektierung ist.

Falls abweichende Hardware verwendet wird, muss die Konfiguration der SIMATIC Stationen angepasst werden. Dies ist speziell dann erforderlich, wenn die Hardwareausgabestände unterschiedlich sind oder die Ethernetadressen abweichen. Das mitgelieferte STEP 7 Projekt muss dann geöffnet und entsprechend angepasst werden. Nach dem Speichern und Übersetzen werden alle Konfigurations- und Projektierungsinformationen überschrieben.

Die folgende Tabelle zeigt die Konfiguration und Projektierung der SIMATIC S7 Station mittels Download vom SIMATIC Manager.

Tabelle 7-4


1. Projekt dearchivieren Entpacken Sie die Datei 26548467_OPC_AC_STEP7_v10.zip

2. Öffnen des SIMATIC Manager durch Doppelklick auf das

Symbol auf dem Desktop.

3. Einstellen des Zugangspunktes S7ONLINE für STEP7. Wählen Sie Options --> Set PG/PC Interface ... (deutsch: ExtrasPG/PC Station Einstellen)

Stellen Sie den Zugangspunkt auf die Karte, mit der Sie mit den Steuerungen verbunden sind.


7.3 Inbetriebnahme der SIMATIC S7 Stationen


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


4. Öffnen Sie das Tool HWKonfig zum Überprüfen der IP Adressen und anderer Hardware Einstellungen.

Führen Sie diesen Schritt für die S7-300 und die S7-400 Station sowie für die PC Station durch.

5. Öffnen Sie den Dialog Properties (deutsch: Eigenschaften) des Kommunikationsprozessors. Passen Sie die IP Adresse an.

6. Öffnen Sie das Tool NetPro zum Einstellen/Überprüfen der Verbindungsprojektierung.

Führen Sie diesen Schritt für die S7-300 und die S7-400 Station sowie für die PC Station durch.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


7. Wahl Sie die Station zum Download der Konfiguration.

Klicken Sie das Symbol im SIMATIC Manager

Führen Sie diesen Schritt für die S7-300 und die S7-400 Station durch. Markieren Sie die S7-Station bzw. den OPC-Server und starten Sie den Download. Bestätigen Sie die Dialoge mit „JA“ um die Station komplett zu überschreiben.

8. Neustart der Baugruppen Sie Stationen werden neu gestartet (Warmstart). Bestätigen Sie entsprechende Dialoge mit „JA“.

9. Konfigurieren und Download der PC Station mit dem SIMATIC Manager

Dieser Schritt ist nicht erforderlich wenn Sie die XDB Datei importieren. Alternative: Die PC Station kann mit den zwei Schritten Konfigurieren und Laden auch remote mit dem SIMATIC Manager projektiert werden. Klicken Sie hierzu mit der rechen Mouse auf die PC Station und wählen Sie PLC --> Configure... Führen Sie nach erfolgreichem Konfigurieren den Schritt Laden aus PLC --> Download

7.4 Inbetriebnahme der PC Station

Es wird vorausgesetzt, dass alle Hardware- und Softwarekomponenten erfolgreich installiert und verkabelt wurden.

Hinweis Die mit diesem Beispiel ausgelieferte Projektdatei (XDB) enthält die vollständig konfigurierte und projektierte PC-Station. Diese Datei kann nur dann ohne Anpassung verwendet werden, wenn die Hardware identisch mit der Projektierung ist.

Falls abweichende Hardware verwendet wird, muss die Konfiguration der PC Station angepasst werden. Dies ist speziell dann erforderlich wenn die Hardwareausgabestände unterschiedlich sind oder die Ethernetadressen abweichen. Das mitgelieferte STEP 7 Projekt muss dann geöffnet und entsprechend angepasst werden (siehe hierzu Kapitel 6.2). Nach dem Speichern und Übersetzen werden alle Konfigurations- und Projektierungsinformationen in der XDB-Datei überschrieben.


7.4 Inbetriebnahme der PC Station


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Die folgende Tabelle zeigt die Konfiguration und Projektierung der PC Station mittels Import einer XDB Datei.

Tabelle 7-5


1. Dearchivieren Sie das Projekt. Entpacken Sie die Datei 26548467_OPC_AC_STEP7_v10.zip

2. Öffnen Sie das Tool Station Configurator durch

Doppelklick auf das Symbol in der Taskleiste.

3. Klicken Sie Import Station Bestätigen Sie die folgende Abfrage mit Ja

4. Wählen Sie die XDB-Datei aus. Die XDB-Datei befindet sich im Unterverzeichnis XDBs der entpackten ZIP-Datei im Verzeichnisbaum des STEP7 Projektes.



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


5. Nach dem Import der XDB-Datei ist die PC-Station konfiguriert.

8 Bedienung der Applikation


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


Hier erfahren Sie...

wie Sie alle Funktionen dieser Applikation bedienen können. Die hier beschriebene Bedienung beschränkt sich auf das Auslösen von Alarmen und das Vorbelegen von Begleitwerten.

Hinweis Um die Funktionsweise vereinfacht darzustellen, wird ein ALARM_SQ über den FB200 zyklisch im OB1 aufgerufen. Das erforderliche AWL Code-Fragment ist in der S7-300 und in der S7-400 ablauffähig und wird daher hier als allgemeines Beispiel verwendet.

Übersicht

Zur Simulation eines Alarms wurde zusätzlich zum Eingang auch ein Merkerbit verschaltet. Ein ALARM_SQ wird ausgelöst wenn entweder der Eingang 0.1 oder das Datenbaustein-Bit DB11.DBX 16.1 in den Zustand „1“ wechselt.

Abbildung 8-1

Der Alarmbaustein bekommt eine feste ID, die CPU weit eindeutig ist und wurde mit einem Begleitwert beschaltet (hier ein Any-Pointer, der auf ein Doppelwort im Datenbaustein 11 zeigt). Der Return-Wert des Alarmbauseins wird in eine Lokalvariable geschrieben.

Auslösen von Alarmen

Zur Simulation eines Alarms kann nun neben dem physikalischen Eingang E0.3 auch das Bit 16.1 im Datenbaustein 11 verwendet werden. Mit dem OPC Scout kann nun das Merkerbit geschrieben (Trigger) werden. Es wird beim



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

Zustandwechsel von „0“ „1“ ein Alarm mit der ID-Nummer z.B. 5 ausgelöst, beim Zustandswechsel von „1“ „0“ wird ein weiterer Alarm gefeuert. Dies entspricht den „gekommen“ und „gegangen“ Prinzip von zustandsgesteuerten Alarmen.

Eine permanente automatische Alarmsimulation kann über Bit 2.0 im Datenbaustein 11 (DB11.DBX2.0) bzw. das Symbol „SimulationAlarms.SimulationActive“ angeschaltet werden. Dieses Bit kann entweder über STEP7 mit der Variablentabelle (VAT_1) oder über OPC DataAccess (OPC Scout) gesetzt werden.

Tabelle 8-1


1. Starten Sie den OPC UA A&C Client (dieses Beispiel).

Beim ersten Start sind Administrator-Rechte erforderlich, da der Client sein eigenes Zertifikat erzeugt um im Windows Zertifikatstore ablegt. Anschließend kann der Client auch mit User-Rechten gestartet werden.

2. Auswahl des Server In der Drop-Down Box der Oberfläche kann der OPC UA Server ausgewählt werden. Falls er dort nicht erscheint ist der UA Server nicht am lokalen Discovery Server angemeldet, dann muss die URL manuell eingegeben werden (opc.tcp://localhost:4845)

3. Connect Über den Connect Button wird die Verbindung zum Server aufgebaut. Nach dem Connect wird ein Dialog zum akzeptieren des Zertifikats aufgeblendet.



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


4. Auswahl der 1) Nodes 2) Filter 3) Eventfelder

5. Auswahl der Knoten für die Events empfangen werden sollen. Der Rootknoten „Server“ ist vorausgewählt, um alle Events zu erhalten, die der Server feuert

1 2 3



V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


6. Auswahl der Filter. Es kann hier auf einen bestimmten Prioritätsbereich gefiltert werden, der maximale Umfang (1-1000) ist vorausgewählt. Weiterhin kann auf unterschiedliche Event-Typen gefiltert werden.

7. Auswahl der Felder. Es sind bereits die für die Oberfläche erforderlichen Eventfelder ausgewählt. Weitere Felder können angehakt werden und die entsprechende Information wird im unteren Fenster (Detailansicht) dargestellt.



Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d


8. Ansicht aller Events in zeitlicher Reihenfolge. Jeder Zustandswechsel wird in eine neue Zeile geschrieben.

9. Ansicht aller anstehenden Alarme. Jeder Alarm wird in einer Zeile angezeigt, ein Zustandswechsel bewirkt einen Farbumschlag.

10. Quittieren eines Alarms über Rechtsklick.

Ein Quittierter Alarm wird mit einem grünen Häkchen dargestellt.

9 Weitere Hinweise, Tipps und Tricks, etc.


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

9 Weitere Hinweise, Tipps und Tricks, etc.

Wiederverwendung und Erweiterung der Client API

Die Client API ist als eigenständige, wiederverwendbare Assembly DLL realisiert. Sie kann direkt in anderen Applikationen angewendet werden. Eine Erweiterung auf zusätzliche OPC UA Features wie Methodenaufrufe ist einfach möglich.

Wiederverwendung der GUI Controls

Die GUI Elemente für Browsen, Auflistung der Attribute und für die Beobachtung von Variablenwerten sind als Controls erstellt. Für eine Wiederverwendung macht es Sinn, diese Controls in eine eigene Assembly DLL auszulagern.

Speichern von NodeIds

NodeIds setzen sich aus einem Identifier und dem Namespace Index zusammen. Der Namespace Index ändert sich zwar nicht, so lange der OPC UA Server läuft, aber prinzipiell kann sich der Index bei einem Neustart des OPC UA Servers ändern. Das ist zwar beim SIMATIC NET OPC UA Server nicht der Fall, aber ein OPC UA Client sollte darauf vorbereitet sein, wenn er die NodeIds speichert.

Beim Speichern darf nicht einfach der Index gespeichert werden, sondern es muss die Namespace URI gespeichert werden. Diese URI bleibt konstant, auch wenn sich der Index ändert.

Es gibt zwei Strategien, die Namespace URI zu speichern:

• Die URI wird statt des Index mit dem Identifier für die NodeId gespeichert. Das ist die einfachste Variante, hat aber den Nachteil, dass sehr viel redundante Information gespeichert wird, wenn die Namespace URI für alle gespeicherten NodeIds des Server gleich ist.

• Der Index wird mit dem Identifier gespeichert, aber parallel dazu wird die passende Namespace Tabelle mit den Namespace URIs abgelegt. Diese Variante ist effizienter, erfordert aber einen zusätzlichen Speicherort für die Tabelle.

Für beide Varianten muss nach dem Verbindungsaufbau mit dem Server die Namespace Tabelle vom Server gelesen werden und die Namespace URI wieder in den aktuellen Index umgesetzt werden.

Optimierung der NodeIds für Read und Write

NodeIds können lange Texte enthalten und sind deshalb nicht dafür geeignet, in zyklischen Aufrufen von Read und Write verwendet zu werden, da ein unnötiger Overhead auf dem Netzwerk und bei der Verarbeitung im Server erzeugt wird.

OPC UA stellt die speziellen Services RegisterNodes und UnregisterNodes zur Verfügung, um eine Optimierung zu erreichen. RegisterNodes liefert für eine Liste von originalen NodeIds eine liste von optimierten NodeIds mit numerischen Identifiern, die wie Handles verwendet werden können. Diese NodeIds sind auf dem Netzwerk nur vier Byte lang und können im Server für einen sehr schnellen Zugriff auf die Daten verwendet werden.

Da das Handle auch eine NodeId ist, kann es in allen Services anstatt der originalen NodeId verwendet werden. Die optimierte NodeId ist aber nur innerhalb der Session gültig.

Werden registrierte NodeIds nicht mehr benötigt, sollten sie mit UnregisterNode freigegeben werden, um die Ressourcen im Server freizugeben.

10 Literaturhinweis


Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

10 Literaturhinweis

10.1 Literaturangaben

Diese Liste ist keinesfalls vollständig und spiegelt nur eine Auswahl an geeigneter Literatur wieder.

Tabelle 10-1

Themengebiet Titel

/1/ STEP 7 Automatisieren mit STEP7 in AWL und SCL Hans Berger Publicis MCD Verlag ISBN 3-89578-113-4

/2/ OPC UA OPC Unified Archticture Mahnke, Leitner, Damm Springer Verlag ISBN 978-3-540-68898-3

10.2 Internet-Link-Angaben

Diese Liste ist keinesfalls vollständig und spiegelt nur eine Auswahl an geeigneten Informationen wieder.

Tabelle 10-2

Themengebiet Titel

\1\ Mengengerüst zum Meldenummernverfahren

Im Produktsupport unter Beitrags ID: 2654846


\2\ Siemens I IA/DT Customer Support

http://support.automation.siemens.com

\3\ OPC Data Access Custom Interface Version 3.0

Spezifikation auf der OPC Foundation Webseite zum Download für OPC Mitglieder

www.opcfoundation.org

\4\ OPC Unified Architecture

Spezifikation auf der OPC Foundation Webseite zum Download für OPC Mitglieder

www.opcfoundation.org

\5\ SIMATIC NET PCStationen in Betrieb nehmen - Anleitung und Schnelleinstieg für SIMATIC NCM PC / STEP 7 ab Version V5.2

Beschreibung bzw. Informationen zu:

• Allgemeine Informationen über die PC–Werkzeuge.

• Funktionen von NCM PC . Wird von SIMATIC NET installiert, siehe: Start Simatic Dokumentation Deutsch. Im Produktsupport unter Beitrags ID: 13542666


\6\ SIMATIC NET – Industrielle Kommunikation mit PG/PC

Handbuch zur Industriellen Kommunikation auf PG/PC mit SIMATIC NET. Wird von SIMATIC NET installiert, siehe: Start Simatic Dokumentation Deutsch. Im Produktsupport unter Beitrags ID: 2044387




http://support.automation.siemens.com/�



http://www4.ad.siemens.de/WW/view/DE/1214574�



11 Historie


V 1.0, Beitrags-ID: 26548467

Co

pyr

igh

t

Sie

me

ns

AG

20

12

All

righ

ts r

ese

rve

d

11 Historie

Tabelle 11-1

Version Datum Änderung

V1.0 12/2011 Erste Ausgabe

Date post:	31-Jan-2020
Category:	Documents
Upload:	others
View:	30 times
Download:	0 times

SIMATIC NET OPC UA Server Applikationsbeschreibung ......von OPC UA Clients in C# unter .NET sammeln...

Documents