Automatisierungstechnik 2016/17

Entwicklung der industriellen Automatisierung

Struktur industrieller Anlagen

modulare Systeme

Verfgbarkeit

vertikale Vernetzung

Prozessebene

Kommunikationssysteme

Feldbus : Profibus DP

Ethernet : TCP/IP und Profinet

Verkettung von Fertigungsmodulen, Handshakeprinzip

Beschreibung nebenlufiger Systeme : Petrinetz

MES-Ebene

Struktur MES

Schnittstelle : SPS - PC

MES-Kernfunktionen

Kommunikation : OPCuA

IT-Ebene (ERP)

Struktur ERP

redundanzfreie Datenhaltung (SQL)

Kommunikation mit der ERP-Ebene : Webservices, Middleware

Zulieferer (supply chain)

Dipl.-Ing. Reiner Doll - mail@reinerdoll.de - http://portal.ts-muenchen.de

mailto:mail@reinerdoll.de

Dieses Skript ist analog der hufig benutzen Dreiecksstruktur von Automatisierungsystemen

aufgebaut.

Nach einem einfhrenden Kapitel, das die Entstehung dieser Struktur erlutert,

folgen, von unten beginnend, Prozessebene, MES-Ebene und die ERP-Ebene.

ERP

MES

Prozess

Vor jedem Kapitel finden Sie eine kurze bersicht zur Motivation, also warum die Inhalte

gewhlt wurdem, und zu den Zielen, also was mit dem Kapitel erreicht werden soll.

Entwicklung der industriellen Automatisierung

Anlagenstrukturen und Teilkomponenten sind selten geschlossene Neuentwicklungen mit

konsequenter Anwendung modernster Techniken. Meist entstehen solche Anordnungen im

Rahmen eines lngerfristigen Migrationsprozesses. Viele Systeme und Komponenten lassen

sich im Funktionskern nur richtig verstehen, wenn man die Entwicklung hin zur aktuellen

Ausprgung kennt. Damit fangen wir an.

Ein kurzer berblick zur Entwicklung der Struktur industrieller Leitsysteme soll Ihnen

zunchst verstndlich machen, warum moderne Anlagen heute modular aufgebaut und mit

leistungsfhigen Kommunikationssystemen ausgerstet werden. Dies wird entlang der

Entwicklung der Leittechnik seit ca. 1970 erlutert.

Das Thema Modularitt wird dann vertieft und ansatzweise auch rechnerisch betrachtet.

Sie sollen erkennen, da neben den trivialen Erklrungen fr diese Struktur auch

quantitative Aussagen und Planungen mglich sind, und einfache Rechnungen zur

Verfgbarkeit von modular strukturierten Systemen durchfhren knnen.

Der wichtigste Teil ist ein berblick zur Entwicklung der Kommunikationsnetze. Er soll

verstndlich machen, wie es zur Entwicklung der Bussysteme in der Industrietechnik

(Feldbus) kam und wie sich die Kommunikationsstrukturen entwickelt haben. Damit soll

wieder das Verstndnis heutiger Strukturen erleichtert werden.

Struktur industrieller Anlagen

- zentrale Prozessleittechnik (1970) :

Leitwarte mit Prozessrechner

( Echtzeit-BS, Infokompression [rot/grn], Fhrungsroutinen [Notaus])

Schnittstellentopologie : 420mA, NAMUR, NPN/PNP

HMI mit Einzelanzeigen, Einzelbedienelementen

Beispiele : Flugzeug, Kraftwerk

Prozessrechentechnik in zentralen Leitwarten

Um 1970 begann die Einfhrung von sogenannten Minirechnern in industriellen Anlagen,

wobei die Kraftwerkstechnik hier fhrend war. Mehrere Elektronikhersteller (meist

ehemalige Bromaschinenhersteller) brachten Rechensysteme auf den Markt, die

programmierbar in Echtzeit direkt Signale analoger Sensoren aufnehmen und damit nach

Verarbeitung Aktoren ansprechen konnten. Programmiert wurde in FORTRAN.

Zu Anfang waren die Gerte Kleiderschrankgro, muten klimatisiert werden und

bentigten, bei einem Preis von mehreren hunderttausend Dollar, Spezialisten (Operator)

zum Betrieb.

Marktfhrer : DEC (PDP11)

Weitere Hersteller : IBM (AS/400), PRIME(P400), HP

Prozessrechner wurden lange nur zur Informationsverarbeitung, nicht zur Prozessfhrung im

Anlagenkern benutzt :

Komplexe Prozess- Komplexe

Informationen Entscheider (Mensch) Anlagenfhrung

-> Nchster Schritt : Modularisierung der Anlage

- modulares, proprietres Prozessleitsystem (1980) :

Einfhrung des P (vorher tausende Einzelelemente, mit wire-wrap verdrahtet)

Bedienwarte , HMI als Grafik

Zellen mit Zellenrechner (spter PLC / SPS)

Modularitt : Komplexittsreduzierung, Testbarkeit, Flexibilitt

Kommunikationsbedarf entsteht : proprietrer Systembus

Beispiele : Teleperm M (Siemens), Contronic (Bosch)

Teleperm (Siemens) :

CS 275 (redundant)

-> Nchster Schritt : open systems (Multivendor)

AS (SPS)

AS (SPS)

HMI

- modulares Mulitvendor-Leitsystem (1985..90) :

Systembus als open system, offenes Kommunikationsprotokoll,

Kommunikationsdienste

Beispiel : MAP (manufactoring automation protocol : GM 1984, ISO/OSI, Token Bus)

Struktur : Bus Kommunikationsprozessor (L7-Dienste !!) - Endgert

MAP :

MAP-Bus (open system)

MMS

(wichtige Begriffe : Modularitt, Protokoll, Dienst (Service-> Server), MMS )

-> Zukunft : Vereinheitlichung der Bussysteme (Ethernet ?)

CP :

MMS !!

CP

CP

Endgert

Hersteller A

Endgert

Hersteller B

Endgert

Hersteller C

Modulare Systeme :

- unabhngig funktionsfhig

- unabhngig testbar (ggf. Testumgebung)

- unabhngig entwickelbar

- Schnittstellendefinition wichtig (optimal : Standardprotokoll)

- Funktionsdefinition und Testverfahren sind zu dokumentieren

- Modulsteuerstrategie mu entwickelt werden (Verkettung)

Bei modularen Systemen sinkt die Komplexitt der Funktion je Modul, dafr steigt der

Kommunikationsdedarf.

Durch geeignete Anordnung (z.b. parallel) kann das Ausfallverhalten beeinflut werden.

Verfgbarkeit und Sicherheit von Anlagenmodulen

MTBF

p = _____________________ (mean time between failure, mean time to repair)

MTBF + MTTR

q (Unverfgbarkeit) = 1 - p

Phase 1 : Frhausflle

meist Produktionsfehler (Ltstellen, Steckkontakte)

Abhilfe : Burn-In (Zykeln mit Strebedingung)

Beispiel : Drucksensor p=10bar , 1000 Druckschlge 12 bar, 48 h zykeln 070C

Phase 2 : Zufallsausflle

kein Verschlei, aber zufllige Defekte mit etwa konstanter Unverfgbarkeit

vorbeugende Wartung verlngert Phase 2

Beispiel : Verfallsdatum auf Servernetzteil, lwechsel

Phase 3 : Verschleiausflle

Lebensdauer von Komponenten (typisch z.b. Kugellager) erreicht

Fehlertoleranter Aufbau modularer Systeme :

Klassisches Beispiel : Diodenquartett

Ausfall von einer (ggf. mehreren) Diode(n) wird verkraftet : System ist nach auen immer

noch eine Diode !

3-fach redundanter Modulaufbau :

TMR-Betrieb : demokratische Entscheidung wenn eine Komponente ausfllt

(typische Anwendung : Leitrechner in Flugzeug)

Zuverlssigkeitsbetrieb : Betrieb solange noch funktionsfhige Komponenten vorhanden

(typisch : Mehrstrahl-Jet)

Sicherheitsbetrieb : Bei Ausfall einer Komponente werden Restkomponenten nur

zum kontrollierten Runterfahren der Anlage benutzt

Betriebsarten redundanter Systeme :

dynamische Redundanz : Ersatzkomponente wird erst im Fehlerfall betrieben

(cold standby, z.b. Notdiesel in Krankenhaus)

statische Redundanz : Ersatzkomponente luft immer mit

(hot standby, z.b. doppelte Lfter)

Gesamtverfgbarkeit modularer Systeme :

Serienschaltung : p(gesamt) = Produkt aller p(einzel)

Parallelschaltung : q(gesamt) = Produkt aller q(einzel)

Literaturstelle aus dem Internet zum Thema :

( http://www.channelpartner.de : 12.09.2013 - Ratgeber fr Cloud- und Hosting-Projekte )

Von Thomas Wittbecker *

Whrend der Angebotsphase stellt sich bei unseren Hosting-Projekten hufig die Frage nach

der Verfgbarkeit einzelner Services. In meinen Gesprchen mit den Kunden stelle ich dann

hufig fest, dass die konkrete Vorstellung von Verfgbarkeit recht vage ist.

Meistens wird die Verfgbarkeit eines Services mit einer Prozentzahl beschrieben. Dabei wird

jedoch hufig auer Acht gelassen, dass bei der Berechnung dieser Prozentzahl, die dann in

den Service Level Agreements (SLA) festgeschrieben wird, einige Fallstricke lauern.

Solche Fallstricke sind beispielsweise der Bezugspunkt der Berechnung der Ausfallzeiten

(Jahr oder Monat), die Definition des zugrunde liegenden Services (Server, Firewall,

Netzanbindung) oder die potentielle Verknpfung von Verfgbarkeiten.

Wie lsst sich die Verfgbarkeit von IT-Plattformen sinnvoll berechnen?

Beispiel Server-Verfgbarkeit

Hufig bekommen wir Anfragen mit der Aussage "Wir htten gerne einen Server mit der

Verfgbarkeit von 99,5 %.

OK, dann nehme ich das einfach so in ein Angebot auf, unterstelle es, die gewnschte

Verfgbarkeit bezieht sich auf das Jahr und ausschlielich auf den Server.

Dem Kunden ist jetzt wahrscheinlich nicht klar, dass der Server durchaus einen ganzen Tag

am Stck ausfallen kann und die Verfgbarkeit trotzdem eingehalten wird. Oder, dass die

Verfgbarkeit des Servers nicht berhrt ist, wenn die Firewall oder die Netzanbindung weg

ist, der Server noch luft, aber von auen nicht mehr erreichbar ist.

http://www.channelpartner.de/http://www.adacor.com/company/http://www.channelpartner.de/channelcenter/cloud_computing/2603203/

Mglichkeiten fr die Berechnung der Ausfallzeiten

Eine gute bersicht darber wie sich die prozentuale Verfgbarkeit eines Service in der

Praxis auswirkt, bekommt man mit einer Tabelle, der auf das Jahr gerechneten mglichen

Ausfallzeiten.

Berechnung der Ausfallzeiten

Verfgbarkeit

Prozentual

Minimale erwartete Verfgbarkeit

(Stunden)

Maximale erlaubte Ausfallzeit

(Stunden)

99,0% 8672,40 87,60

99,1% 8681,16 78,84

99,2% 8689,92 70,08

99,3% 8698,68 61,32

99,4% 8707,44 52,56

99,5% 8716,20 43,80

99,6% 8724,96 35,04

99,7% 8733,72 26,28

99,8% 8742,48 17,52

99,9% 8751,24 8,76

99,99% 8759,124 0,876

Alternativ kann man die Verfgbarkeit bei kritischen Projekten auch auf den Monat bezogen

angeben: zum Beispiel 99,9 Prozent Verfgbarkeit auf den Monat gerechnet bedeutet einen

Maximalausfall von 43:48 Minuten pro Monat.

Wenn man ber die Verfgbarkeit eines Services spricht und prozentual ausdrckt, muss man

sich also berlegen, ob man mit der maximal mglichen Ausfallzeit leben kann.

Eine weitere Variante ist es, zustzlich die maximale Ausfalldauer zu beschrnken. Gerade

bei nicht ganz so kritischen Projekten kann es sein, dass zwei oder drei Ausflle pro Jahr nicht

ins Gewicht fallen. Sie sollten jedoch nicht lnger als vier Stunden am Stck betragen. Also

definiere ich beispielsweise 99,5 Prozent Verfgbarkeit pro Jahr, bei maximal vier Stunden

Ausfall am Stck.

Worauf bezieht sich die Verfgbarkeit konkret?

Eine weitere Quelle von Missverstndnissen ist die Definition des Services. Nehmen wir an,

einem Kunden wird die Verfgbarkeit eines Servers garantiert, und er lsst von einer

Webagentur eine Website auf diesem Server betreiben.

Aus der Sicht des Betreibers ist der Server solange verfgbar, wie er einwandfrei luft. Das

kann auch dann der Fall sein, wenn der Webserver aus irgendeinem Grund kein http mehr

ausliefert. Sprich, die Website nicht mehr erreichbar ist.

IM BUNGSTEIL :

bung : Verfgbarkeits-

berechnungen

vertikale Vernetzung modularer Systeme

Strukturierung in sich berlagernde Rechenebenen (SPS, Industrie-PC, Server)

Verteilung der Funktionen (Modularisierung)

Kopplung mit der Bro-IT (Gateways)

CIM : Rechnergesttzte Automatisierung (menschenleere Fabrik) 1980 ..85

Strukturierung : was wird wo gerechnet ?

altes Strukturmodell (1990) :

- Prozessleitebene :

groe Datenmengen, schnelle Bussysteme, keine Echtzeit : Leitrechner, Datenbank

- Zellebene :

Prozessfhrung, Datenerfassung, Notbedienebene, Alarmbehandlung

- Feldebene :

Feldgerte (SPS), busfhige Aktoren / Sensoren, Echtzeit, geringe Datenmenge

Neueres Strukturmodell (2005) :

Integration der Brodatenverarbeitung (=Kopplung an Ethernet)

Kommunikation mit Zulieferbetrieben (Supply chain)

Durchgngige Vernetzung ohne Gateways von IT-Ebene bis SPS

- ERP-Ebene :

strategische Unternehmensebene, Betriebswirtschaft. SCM

- MES-Ebene :

Prozessfhrung, Datenerfassung, Verkettung der Fertigungsmodule

- Prozessebene :

Feldgerte (SPS), busfhige Aktoren / Sensoren, Echtzeit, geringe Datenmenge

Hier gebruchliche Kommunikationssysteme :

Beispiel : digitale Fabrik der tsm (alter Stand 2009 mit Profibus DP) :

ERP nimmt Kundenauftrge entgegen und bearbeitet diese

nach betriebswirtschaftlichen Gesichtspunkten.

MES holt Auftrge aus ERP, bearbeitet diese nach technischen Der SPS-Master bedient die Module mit den von MES

Gesichtspunkten (z.b. optimale Reihenfolge), und schickt eintreffenden Auftrgen.

Fertigungsbefehle an die Prozessebene.

Prozessebene

Dieser Anschnitt ist in zwei Teile gegliedert :

Im ersten Teil wird auf die technischen Grundlagen industrieller Kommunikationssysteme

in der Prozessebene eingegangen. Von der rein elektrischen Betrachtung (am Kabel) bis

hin zur logischen Funktion der Kommunikation werden die relevanten Systeme und ihre

Unterschiede betrachtet. Sie sollen damit in die Lage versetzt werden, zu einer gegebenen

Anordnung mit einem gegebenen Kommunikationsbedarf das richtige Kommunikations-

system auswhlen zu knnen. Oder anders gesagt : was kann ein bestimmtes System, was

kann es nicht ? Als wesentlichstes Hilfsmittel zur Erarbeitung einer Systemfunktion wird das

ISO/OSI 7-Schichten-Modell benutzt, dessen Sinn erkannt werden soll. Profibus DP und

Profinet I/O werden vertieft behandelt, und sollen auch in der Praxis beherrscht werden.

Im zweiten Teil wird die Technik angewandt. Kommunikationsprotokolle als Definition der

Funktionsprinzipien sind zu verstehen. Sie sollen vor allem das Prinzip der Handshake-

Kommunikation verstehen und auch lernen es zu realisieren. Zur Beschreibung von zeitlich

ablaufenden Vorgngen wird die graphische Syntax der Petrinetze benutzt. Graphische

Programmierwerkzeuge basieren oft auf dieser Syntax, so da es lohnt, die Grundlage zu

kennen. Daraus wird dann mit Benutzung weiterer Hilfsmittel der Ablauf der Realisierung

von Kommunikationsprotokollen an einfachen Beispielen gezeigt und gebt.

Teil 1 : Kommunikationssysteme

Entwicklung (s.o.) : modulare Anlagenstruktur

vertikale Vernetzung aller Ebenen

Folgerung : Notwendigkeit geeigneter Kommunikationssysteme

theoretische Basis : ISO/OSI-Modell (1984, MAP)

Was ist ein Netz / Bus / Schnittstelle (Verfgbarkeit) ?

- Topologie

- Hardware fr Schnittstellenanschaltung (Tristate)

- Layer 2

ISO/OSI-Modell :

Application layer Anwendung (Programm) Application layer

Presentation layer Codierung, Verschlsselung Presentation layer

Session layer Isar 12 bitte melden Session layer

Transport layer Files Pakete Transport layer

Network layer routing Network layer

MAC layer (link layer) Buszugriff, Busadresse MAC layer (link layer)

Physical layer Hardware Physical layer

Profibus DP

Layer 1 : - Toplogie

(Grundlagen : Linie, Stern, Ring ? )

Linientopologie, Segmentlnge 1200m, max. 3 Repeater

max. 32 Teilnehmer, Stichleitungen max. 0,3m

- Hardware, Datenformat (entspricht RS485)

shielded twisted pair (130150 Ohm)

Sub-D 9-polig

symetrisch +/- 5V 390-220-390 Ohm am Komperator

bis 12 Mbit/sec.

11 Bit seriell asynchron pro Byte

Startbit low, Stopbit high, Parity, LSB first

Sub-D

Layer 2 : MAC-Verfahren :

(Grundlagen : Schnittstelle, Bus, Netz -> Zugriff ?)

deterministische Verfahren : Token passing

Begriffe : aggregierte Bandbreite, Determinismus !

Token bus, Gap update (Lcken mglich), Freitoken nach TRT

Framelnge max. 255 Byte (244 Byte Data) :

Hybridnetz : unterlagerter Master/Slave

Slave : kein Token

Master : in DP nur 1 echter Master ! (=Bussystem)

Layer 3-7 : leer !!

(alle Layer in Feldbus nur bei MAP)

Layer 7 bei FMS vorhanden

Bedeutung des Layer 7 in Feldbussystemen !

Profibus DP und Simatic S7 in modularen Anlagen

- Ursprngliches Konzept : dezentrale Peripherie

Bei rumlich ausgedehnten Anlagen ist die Verkabelung aller Peripherieelemente zu einer

zentralen SPS aufwndig. Deshalb : Einsatz von DP-Slaves als dezentrale Klemmen-

konzentratoren . Diese werden an Orten mit vielen Peripherieelementen angebaut, und

dort mit der Peripherie mit geringem Kabelaufwand verdrahtet. Der DP-Slave (keine SPS !)

kommuniziert dann die Informationen seiner gesamten Peripherieverdrahtung ber die 2-

Draht Busleitung zum DP-Master, also der SPS.

Beispiel fr DP-Slave : ET-200 Serie von Siemens

SPS (Master)

Eingnge und

Ausgnge

Eingnge und

Ausgnge

DP-

Slave

DP-

Slave

Profibus DP fr modulare Anlagen : i-Slaves

Ziel : Einsatz von Profibus DP in dezentraler Leittechnik (Module mit eigener SPS)

Problem : In Profibus DP nur 1 Master mglich (bei dezentraler Peripherie auch sinnvoll..)

Die Master-SPS betreibt am Profibus DP wie bei dezentraler Peripherie einige Slaves.

Dies Speicher in den Slaves sieht der Master wie gehabt als Ein-Ausgnge :

Sie gehren logisch zum Adresssystem der Master-CPU !

Statt einer Klemmenverdrahtung ist die Hardware am Slave aber nun als Speicher (im

Kommunikationsprozessor) aufgebaut, der ber einen zweiten Zugang von der i-Slave SPS aus

zugegriffen werden kann. Dieser Speicher kann vom Slave nicht direkt adressiert werden,

das Betriebssystem der i-Slave-SPS kommuniziert die Daten im Hintergrund mit dem im i-Slave

konfigurierten Speicher :

DP-Master

i-Slave DP-Slave

E

A

A

E

Wird im Master

konfiguriert

Wird im Slave

konfiguriert

Wird vom BS

ausgefhrt

konfiguriert

In der Praxis : Profibus DP mit dem TIA-Portal

Starten Sie die SST-Maschine mit Oracle Virtual Box !

1. Projekt laden

Kopieren Sie von \\r2d2\filer\at\muster2016_17 das fertig konfigurierten Projekt :

STT_Muster_2016.zap3 auf Ihren PC in C:/Daten/.. in Ihrem Klassenordner in einem

Subdirectory mit Ihrem Namen

ffnen Sie TIA, gehen Sie in die Projektansicht und dearchivieren Sie das Musterprojekt, als

Speicherziel geben Sie wieder Ihr Subdirectory unter Ihrem Klassenordner an.

Sie erhalten ein Bild, das etwa so aussieht, wenn Sie die Netzansicht whlen :

file://r2d2/filer/at/muster2016_17

2. Hardware konfigurieren

Nun konfigurieren Sie zunchst den MAster.

Klicken Sie die RS485-Buchse auf der Gerteansicht :

Sie mssen ein neues Subnetz einfgen, den Profibus.

Als Profibusadresse whlen Sie bei Master die 1.

Den Punkt Schnittstelle vernetzt mit belegen Sie mit dem neuen Subnetz Profibus_1.

Die Betriebsart passt schon, weil Master hier die Default-Einstellung ist.

Nun die Slaves :

Die Sub-D Schnittstelle anklicken, den Slave an den Profibus_1 anhngen :

Im Menpunkt Betriebsart whlen Sie den DP-Slave aus.

Nun folgt die Konfiguration der im Unterricht besprochenen Kommunikationsspeicherzellen

(die toten Briefksten).

Die einzuhaltende Konvention fr die Kommunikationadressen finden Sie in der

Anlagendokumentation im Web :

http://portal.ts-muenchen.de dort auf: digitale Fabrik und darin auf : Dokumentation

Nach ffnen des .pdf- Files (das Sie sich am Besten irgendwo speichern) schauen Sie auf

Seite 14 nach, dort ist die gesamte Anlage mit Profibus DP konfiguriert.

Als DP-Master weisen Sie die Master-Station zu

Ihren Slave (Band) konfigurieren Sie also so :

Sie SPS am Lineararm bekommt am Profibus die DP-Adresse 3, die Adressen der

Kommunikationsspeicher entnehmen Sie dem Dokumentations-pdf .

http://portal.ts-muenchen.de/

3. Software

Laut Dokumentation mssen Sie fr die Kommunikationsfunktionen FB-Bausteine zwischen 0

und 100 verwenden (suchen Sie diese Konvention in der Doku !).

Also einen FB10 zum Beispiel.

Wir gehen in der Reihenfolge der nachher tranportierten Daten vor. Zunchst mu der Band-

Slave den Taster am Bedienwinkel einlesen. Welchem Peripheriebit dies entspricht,

entnehmen Sie wieder der Doku .

Zunchst erzeugen wir der Ordnung halber zwei Satndard-Variablen, um danach dann mit

Namen, nicht mit Adressen arbeiten zu knnen :

Damit nun in einem neu erzeugten Baustein (die Doku schreibt vor, da

Kommunikationsfunktionen im Adressbereich 0..100 sein mssen, also z.b. FB10) in SCL

die am Slave ntige Aktion :

Der FB entsteht durch Klick auf neuen Baustein hinzufgen, in der Syntax knnen Sie sich

die Schreiberei vereinfachen, indem Sie vorher mit einfachem (nicht doppelt) Masuklick auf

Standard-Variablentabelle die zur Verfgung stehenden Varaiblen links unter erscheinen

lassen. Mit Anklicken und Rberziehen ersparen Sie sich die Schreiberei.

Nun noch der Aufruf des eben erzeugten FB im OB1 :

Nach dem Aufruf : call fb10, db10 frgt das Tia-Portal, ob es den ntigen Instanz-DB fr den

FB10 automatisch erzeugen soll, wir besttigen dankbar mit OK.

An allen Stationen werden dann noch zustzliche OBs eingebunden (die z.B. dafr sorgen,

da der Profibus stabil startet, auch wenn anfangs noch nicht alle Stationen geladen sind) :

OB86 und OB82

Die nchste Station auf dem Datenweg ist der Master.

Hier mu nur rangiert werden, also der Briefkasteninhalt vom Slave zum Linearmodul.

Wieder werden zunchst Variablen erzeugt, um griffigere Namen zu bekommen :

.. und damit wird dann hantiert (wieder in einem neuen FB10) :

Im OB1 (wie vorher beim Slave) noch der Aufruf des FB10 :

Zum Schlu die Aktion im Linearmodul, eigentlich genau das Gleiche wie vorher beim

Band.In der Standard-Variablentabelle wurde die Variable xe_kommunikationszelle mit

%E0.0, diese schreibt in einen leicht zu testenden Ausgang, z.b. ein Ventil :

4. Stationen laden :

Mit Klick der rechten Maustaste auf die Slave-Station ffnen Sie ein Men, in dem Sie zuerst

alles bersetzen. Dann laden Sie im selben Men alles auf die Hardware.

Hierbei mssen Sie peinlich genau darauf achten, wirklich ber die

Ethernetschnittstelle auf die richtige Station zu laden !!

Also so :

Die Station Band ist hier zu erreichen !

Noch einfacher ist es, wenn sie den Hacken bei alle kompatiblen Teilnehmer rausnehmen,

dann wird nur noch der richtige Teilnehmer angezeigt :

IM BUNGSTEIL :

Praktikum Kommunikation

mit Profibus DP

Ethernet-basierte Industriekommunikation

Entwicklung des Ethernetstandards (Layer 1 und 2) :

10base5 : Ethernetstandard vor 1975. Dickes gelbes Kabel, 500m Segemtlnge, 10 mBit/s

10base5

10 Mbit/s Basisband 500m Segment

10base2 : Standard um 1980, Kabel dnner, billiger (Cheapernet) und flexibler, dafr

krzere Segmentlnge. BNC-Steckersystem, Standard-Koaxialkabel.

10baseT : Ca. 1990 Standard auf verdrillten 2-Draht Leitungen. Damals praktisch, weil

viele solche Telefonleitungen existieren. Kabelaufwand aber erheblich, weil

keine Linientopologie mglich, und deshalb Sterntopologie eingesetzt wird.

10baseT : T fr Twisted Pair

Segementlnge 100m

Die Sternmittelpunke (Hubs) sind Layer1-Gerte (nachdenken : was bedeutet

das ?). Die Steckertechnik ist RJ45, billige Spielzeugstecker (fr Office).

100baseT : Weiterentwicklung in sanfter Migration zu hherer Bandbreite ohne die

Hardware (also die Kabel) tauschen zu mssen.

Der Sternmittelpunkt kann als Hub ausgefhrt werden, meist kommen aber

Switches zum Einsatz. Das sind Layer 2 Gerte. (Wieder : nachdenken !)

Der Einsatz von Switches fhrt zur Idee der strukturierten Verkabelung

Die Sterntopologie wird hier im Gebude konsequent verteilt.

Im Keller steht der Primrswitch, der mit der ffentlichen Leitung verbunden ist. Von diesem

gehen Leitungen in jede Etage, hier stehen die Sekundr-Switches (Etagenverteiler). Von da

gehts entweder direkt zu jeder LAN-Dose, oder zum Tertirswitch (Raum-Verteiler).

Diese Verkabelung wird fest als (Kabelkanle) Hausinstallation ausgefhrt, an jedem Switch

werden die Leitungen in einem Patchpanel zusammengefhrt :

Das Patchpanel ist meist in einem Patchschrank

untergebracht. Die Patchkabel fhren (konfigurierbar)

zum Switch :

Bei vielen Anschlssen folgt aus der Sterntopologie groer Kabelaufwand :

(Das Bild zeigt keine bliche Verkabelung ;-)

Trotz kollisionsfreier bertragung in Vollduplex ist diese Ethernetvariante (Switched

Ethernet) nicht deterministisch. Schnelle Switches knnen zwar Pakete puffern, aber wenn

z.B. mehrere Gerte mit voller Leistung auf ein Gert senden, die Puffer laufen aber schnell

ber und Pakete gehen verloren.

GBE : 1000baseT, sanfte Migration aus 100baseT, Kabel mssen aber gewissen

nachrichtentechnischen Standards entsprechen (Cat 6).

Weiterentwicklung : 10GBE : 10 Gigabit/s, sanfte Migaration .

100GBE : 100 Gigabit /s, Spezialkabel ntig (Twinaxial)

Gerte im Ethernet (Infrastruktur) :

Hub Layer 1 Gert. Sternmittelpunkt bei 10baseT und 100baseT

Switch Layer 2-Gert. Basis fr switched Ethernet

Layer 3 Switch

Eigentlich ein routing Switch, der auf Layer 3 Tabellen fhrt und damit die Ports

schaltet. Bei statischer IP-Verteilung sehr schnell, bei dynamischem Verkehr

durch das langsame Routing-Protokoll weniger.

Router Eigentlich kein Ethernet-Gert weil Layer 3. Fhrt Routing-Tables, identifiziert

Endgerte (Ethernet) ber ARP-Protokoll.

Gateway Layer 7- Gert. Verbindet verschiedene Netztoplogien, die nicht Routing-fhig

sind (z.b. Einwhlen in Netz ntig : Modembetrieb).

Ethernetframe :

Prambel zum Einschwingen des Empfngertakts.

Adressformat 48 bit CSV, meist hexadezimal geschrieben: AA:B1:CA:10:E4:F1

CRC erkennt Bitfehler und kann gewisse Anzahl korrigieren

Payload rund 1500 Byte (fr Anlagentechnik ziemlich viel)

Bei Bedarf kleine Wiederholung : IP-Routing

Netze :

IP-Adressen werden im QDN-Format (quad dotted notation) angegeben :

Beispiel : 62.245.200.166

Das erste Byte besagt in der Orginalversion des Protokolls, ob es sich bei der Adresse um

eine Class A, Class B oder Class C Adresse handelt. Dies gibt an, welcher Teil der Adresse

die Netzadresse (Vorwahl), und welcher Teil die Rechneradresse in diesem Netz ist.

Class A (erstes Byte zwischen 1 und 127) : erstes Byte ist Netzadresse

Class B (erstes Byte zwischen 128 und 191) : die ersten beiden Byte sind Netzadresse

Class C (erstes Byte zwischen 192 und 223) : die ersten drei Byte sind Netzadresse

Netmask :

Diese Aussage kann auch durch die netmask angegeben werden, die beiden den Stellen der

Netzadresse (netbit) 1, bei denen der Rechneradresse (hostbit) 0 ist :

netmask Class A : 255.0.0.0

netmask Class B : 255.255.0.0

netmask Class C : 255.255.255.0

Die netmask wird auch krzer geschrieben, indem man einfach die Anzahl der 1-en in der

netmask neben der IP-Adresse hinter einem Schrgstrich angibt :

204.66.23.2 / 24 ist z.b. eine Adresse in einem Class-C Netz

Broadcast :

In einem Netz knnen fr bestimmte Funktionen alle Rechner zugleich angesprochen

werden, man nennt dies einen Broadcast. Die Broadcastadresse in einem Netz wird gebildet,

indem man alle hostbit = 1 setzt.

Netadress :

Das Netz selbst (eigentlich das Kabel..) hat die Adresse, bei der nach der Netzadresse alle

hostbit = 0 gesetzt werden.

Hier sind nun zwei lokale Netze zu sehen, links das Biernetz, rechts das Weinnetz.

Die Hosts im Biernetz haben die Adressen :

Pils : 182.166.17.4 / 16

Bock : 182.166.18.5 / 16

Weizen : 182.166.18.6 / 16

Die Hosts im Weinnetz haben die Adressen :

Barolo : 62.245.200.162 / 8

Chianti : 62.245.123.2 / 8

Brunello : 62.245.1.1 / 8

Der Router Monika zwischen den beiden lokalen Netzen hat links die Adresse 182.166.0.1

und rechts die Adresse 62.0.0.1 (jeweils die ersten IPs in den lokalen Netzen).

Pils Bock Weizen Monika Barolo Chianti Brunello

Jeder Rechner hat nun eine Tabelle konfiguriert, in der seine IP-Nachbarschaft angegeben

ist. Diese Tabelle heit routing-table.

Routing-table von Pils :

Net Netmask Gateway Interface

182.166.0.0 255.255.0.0 -- eth0

62.0.0.0 255.0.0.0 182.166.0.1 eth0

erreichbare Netze deren Netmask der zustndige Router die Netzkarte

Routing-table von Monika :

Net Netmask Gateway Interface

182.166.0.0 255.255.0.0 -- eth0

62.0.0.0 255.0.0.0 -- eth1

Jetzt will Pils eine Nachricht an Weizen schicken :

ping 182.166.18.6

routing-protokoll

Das IP-Protokoll im Layer 3 von Pils prft nun anhand der Routing-table, ob Weizen lokal

erreichbar ist, oder ob ein Router beauftragt werden mu.

Hierzu vergleicht er Zeile fr Zeile, indem er die Zieladresse 182.166.18.6 mit der in der Zeile

stehenden netmask bitweise parallel UND-verknpft (ein 32-bit Prozessor kann das in einem

einzigen Befehl), und das Ergebnis mit der in der ersten Spalte stehenden netadress

vergleicht. Hier ist schon die erste Zeile erfolgreich.

arp-protokoll

Nun mu der Frame aber im Layer 2 als Zieldaresse die MAC von Weizen bekommen, und

die ist momentan noch unbekannt. Layer 3 gibt die Ziel-IP 182.166.18.6 an das Arp-Protokoll.

Das ARP-Protokoll schickt nun einen Layer 2 Broadcast ins Netz mit dem Inhalt :

Who has 182.166.18.6 ?

Jeder Rechner vergleicht in Layer 3, Weizen sieht, da er gemeint ist und ruft zurck :

Its me !

Damit hat er sich verraten, weil an dem Antwortframe seine MAC dransteht. Das ARP-

Protokoll trgt nun den Zusammenhang IP-MAC fr Weizen in eine Cache-Tabelle ein (ARP-

Cache), so da beim nchsten Frame nicht wieder gefragt werden mu.

Der Ethernetfame kann nun gebildet werden, der Ping geht an Weizen.

Jetzt will Pils eine Nachricht an Brunello schicken :

Ping 62.245.1.1

Der Ablauf ist der Gleiche wie vorher, nur erkennt Pils in seiner Routing-table, da er Monika

beauftragen mu. Er schickt (nach ARP auf Monikas IP) Monika den Frame.

Monika prft nun in ihrer Routing-table, wohin der Frame mu, und sieht in Zeile 2 das

richtige Netz. Sie setzt auf Eth1 (ihre zweite Netzkarte) einen ARP-Request auf Brunello ab,

und erhlt seine MAC, dann schickt sie ihm das Paket von Pils.

Subnetting :

IP-Adressen wie oben beschrieben (Class A,B oder C) werden heute kaum noch benutzt.

Man teilt diese Netze in kleinere Teilnetze auf, dieser Vorgang wird Subnetting genannt.

Hierzu wird die netmask, also die Grenze zwischen Netzteil und Hostteil in der IP, nicht mehr

an der Bytegrenze sondern beliebig innerhalb der QDN gezogen.

Wenn man die IP nicht in Byteschreibweise, sondern binr angibt, ist das nichts besonderes :

62.245.200.163 / 29 ist kompliziert zu handhaben, im letzten Byte verluft die Grenze.

11111000.11110101.11001000.10100 011 lautet diese IP binr

Netzadresse (dezimal 62.245.200.160) Rechner

Es ist auch leicht zu erkennen, wieviele Rechner dieses Subnet aufnehmen kann :

Mit 3 Bit sind 8 Adressen mglich, eine davon ist die Netadress, eine der Broadcast, also sind

noch 6 IP fr Rechner frei. (Vermutlich wird aber noch eine davon fr einen Router bentigt)

kleine bung :

Teilen Sie das B-Netz 132.130.0.0 / 16 in 12 Subnetze, geben Sie fr das letzte dieser 12

Netze die erste und letzte fr Rechner nutzbare IP an !

(Lsung : erste IP = 132.130.176.1, letzte IP = 132.130.191.254)

Parameter der Ethernet TCP/IP-Verbindung

Heute geschieht die Prozessanbindung meist ber TCP/IP auf Ethernet 100baseT.

Hierbei ist es wichtig, die Adressdaten der Kommunikation zu verstehen. Insbesondere die

Service-Access-Points (Ports) sind wichtig :

Windows-Rechner

CP SPS_1 CP SPS_2

Fr die Verbindung PC -> SPS_2 gelten also folgende Kommunikationsparameter :

LSAP oder SSAP (Local/Source Service Access Point) : 2001

RSAP oder DSAP (Remote/Destination Service Access Point) : 2000

SIP (Source IP-Adress) : 107.12.14.11

DIP (Destination IP-Adress) : 107.12.14.13

SMAC (Source MAC-Adress) : 00:a0:ab:ef:1a:12

DMAC (Destination MAC-Adress) : 00:ba:f0:d2:12:14

Der erste SAP (Default-SAP) fr S7 Verbindungen ist immer 2000, bei weiteren Verbindungen

zhlt das System den SAP hoch : 2001, 2002

Programm

Layer 4

Layer 3

Layer 7 nchster LSAP (Port)

2001

SAP (Port) 2000 erster LSAP (Port)

2000

SAP (Port) 2000

IP: 107.12.14.11

SAP (Port) 2000

MAC: 00:ba:f0:d2:12:14

SAP (Port) 2000

Layer 2

LSAP (Port) 2000

SAP (Port) 2000

LSAP (Port) 2000

SAP (Port) 2000

MAC: 00:a0:ab:ef:1a:12

SAP (Port) 2000

IP: 107.12.14.12

SAP (Port) 2000

Layer 2

Layer 3

Layer 4

IP: 107.12.14.13

SAP (Port) 2000

MAC: 00:ac:ff:2f:10:13

SAP (Port) 2000

berblick : Ethernetkommunikation in der Prozessebene

Basiskommunikation (native) :

Hier kann mit Ethernet-Gerten ber verschiedene Layer4-Protokolle kommuniziert werden.

TCP, UDP und ISO-on-TCP ist mit Standard-Ethernethardware mglich. Grenordnung

100ms, UDP etwa doppelt so schnell wie TCP, hngt von Datenlngen usw. ab.

Profinet I/O :

Profinet I/O lst soll mit hnlicher Topologie (Begriffe : Investitionsschutz, sanfte Migration)

Profibus DP ablsen. Einteilung in 3 Klassen :

Class B : Diagnosetools

und mgliche Redundanz

Class C optimiert :

Summenframeverfahren

=250 s, Jitter= 1s

Class A :

Kommunikation ber

Layer 2 und UDP (= 30ms)

Class A

Class C :

(Profinet IRT) =1ms,

Jitter= 1s : Deterministisch

Deterministische Echtzeitkommunikation :

Profinet IRT (I/O Class C) basiert auf (nicht billiger) Spezialhardware, Echtzeituhren (HW/SW)

EtherCat arbeitet hnlich, nur Summenframeverfahren

Sercos als Bussystem vor allem fr Antriebe hat hnliche Eigenschaften, noch schneller

Objektorientierter Ansatz :

Profinet CBA ist ein (zukunftsweisender !) Ansatz zum Entwurf komplexer Systeme.

Module werden als wiederverwendbare Objekte definiert und in (XML-) Dateien

beschrieben. Der Systementwickler setzt diese dann zusammen.

Ethernet (auch : Industrial Ethernet, mit vernnftigen Steckern usw.)

Zunchst eine genauere Erklrung der einzelnen Verfahren

aus theoretischer Sicht :

1) ISO-on-TCP

Durch eine kleine Erweiterung in Layer 4 (TCP) wird das frher von Siemens (S5) hufig

benutzte ISO-Protokoll in den modernen Kommunikationsrahmen eingebaut.

Siemens nennt als grten Vorteil die Nachrichten-Orientierung dieser Protokollvariante.

Das bedeutet grob, da nicht gesichtslose Frames bertragen werden, und der Empfnger

sich aus diesem Wust dann (mithilfe des TCP-Protokolls) seine Info wieder zusammenbasteln

mu. Es wird vom Sender mitgeteilt, wann eine Nachricht beginnt und wann sie zu Ende ist.

(Eigentlich eine klassische Layer5-Funktion, wird aber nicht als solche bezeichnet)

Das Protokoll wurde 1987 als Request for Comment verffentlicht : RFC 1006

Layer 7 : Simatic S7 Layer 7 : Simatic S7

. .

Layer 4 : TCP

Layer 4 : TCP

Layer 3 : IP Layer 3 : IP

Layer 2 : MAC Layer 2 : MAC

Layer 1 : 100baseT Layer 1 : 100baseT

RFC 1006 RFC 1006

2) Profinet I/O Class C (Profinet IRT) :

Die Kommunikation in IRT ist kein Standard-Ethernet Protokoll !

Es kann nur auf Spezial-Hardware ausgefhrt werden, die eine Zeitsynchrone

Datenbertragung zwischen den Stationen sicherstellt. Hierzu werden alle aktiven Gerte

(Teilnehmer und Switches) mit einem hochgenauen Timing-Protokoll synchronisiert.

PTP : precision time protocoll

PTP kann als Software realisiert die Gerte bis auf einige Microsekunden, in Hardware

ausgefhrt (teuer !!) bis auf einige Nanosekunden genau synchronisieren.

Die synchrone Zeitbasis erlaubt nun, den Sendezyklus auf der Ethernetleitung in einen

starren Teittakt, mit eimem isochronen (=zeitgleichen) Bereich am Anfang und einem

darauf folgenden Standard-Ethernetbereich zu unterteilen. Im isochronen Bereich werden

die Nachrichten von den Switches nach fest konfigurierten Schema bermittelt , hnlich

einem Zeitmulitplexverfahren. Kollisionen oder andere Strungen knnen nicht auftreten.

Im Standardbereich knnen (wenn der Switch das untersttzt) die RT-Daten priorisiert

werden.

Damit wird die maximale Sendelatenzzeit berechenbar -> IRT ist deterministisch !

3) Profinet CBA :

Wesentlicher Hintergrund :

Die Realisierung von Anwendungen wird in zwei Ttigkeitsgfelder aufgeteilt :

A) Der Entwickler einer Automatisierungskomponente entwirft eine Klasse, die den

Anlagenentwicklern vor Ort zur Verfgung zur Verfgung gestellt wird. Die komplexen

internen Ablufe der Komponente bleiben dem Anlagenentwickler verborgen

B) Der Anlagenentwickler setzt die Komponente wie in der Objektorientierten

Programmierung in seinen Projekt ein, und verdrahtet nur noch die Kommunikation.

Um die Technik hinter Profinet CBA verstehen zu knnen, ist ein kleiner Ausflug in die

Betriebssystemtechnik ntig :

In Windows 3.1 wurde von Microsoft ein Mechanismus implementiert, der

objektorientierte Interaktion zwischen verschiedenen Programmen ermglicht.

(Das ist brigens gar nicht so einfach wie es sich anhrt : in einem Rechner mit nur

einem Prozessor luft zu einer Zeit natrlich nur ein Programm. Will das jetzt mit einem

anderen kommunizieren, ist das Problem, da der Partner ja gar nicht luft. Die

ntigen Mechanismen, damit das klappt, nennt man Interprozesskommunikation)

Fr den Anwender hat das den Vorteil, z.B. den Zugriff auf eine Datenbank in ein Text-

verarbeitungsprogramm einbauen zu knnen : Serienbriefe knnen so sehr einfach

adressiert werden. Wird der Text ausgegeben, so ruft das Textprogramm automatisch

die Datenbank auf und veranlasst sie, den ntigen Datensatz zu suchen und zu

schicken.

Microsoft hat das OLE genannt : Object Link Embedding.

Die Schnittstellendefinition fr die Kommunikation solcher Objekte wurde von

Microsoft COM genannt : Component Object Model. Einer der beiden Prozesse (der

Client : hier das Textprogramm ) fragt hier den anderen (den Server : hier die

Datenbank) nach Leistungen (Services, meist Daten).

Mit Windows NT wurde das Ganze dann so erweitert, da ber das Netz auch Services

in anderen Rechnern genutzt werden knnen : DCOM (distributed COM).

Ein Rechner kann in einem Anderen ein Programm dazu bringen, etwas zu tun und ihm

dann z.b. Daten zu schicken.

Dieser DCOM-Mechanismus wird nun in das Betriebssystem der beteiligten SPS eingebaut.

Damit kommunizieren Gerte der Feldebene unter Profinet CBA mit Methoden aus der PC-

Welt (Windows). Das hat mit blicher Feldkommunikation (Feldbus, z.b. Profibus DP oder

Profinet I/O) bis auf den Namen nicht das geringste gemeinsam !

Nachteile sind die langsame Reaktion (groer Rechenaufwand in der SPS ) und die Probleme,

die auftreten, wenn Microsoft DCOM irgendwann nicht mehr untersttzt.

Ein Anlagenmodul (durch eine SPS dezentral gesteuert) wird als Komponente betrachtet.

hnlich der objektorientierten Betrachtungsweise in modernen Programmiersprachen mit

Daten (Eigenschaften -> properties) und Programmfunktionen (Methoden -> methods) eines

Objekts besteht eine solche Komponente aus Daten, die an einer definierten Schnittstelle

zugreifbar sind (das sind meist Handshake-Signale), und Funktionen, also Programmen, die

mit diesen Daten arbeiten.

Solche Komponenten werden mit Entwicklungswerkzeugen erzeugt, bei Siemens z.B. mit

dem Simatic Manager. Man definiert Daten in der SPS als Datenbausteine (DB) und schreibt

Programme als Funktionen (FC) oder Funktionsbausteine (FB). Daraus erzeugt der Simatic

Manager eine Profinet-CBA kompatible Komponente, die als XML-Datei gespeichert wird.

Diese Komponenten beschreiben also ganz allgemein objektorientierte Funktionsmodule,

die nicht auf eine spezielle SPS o.. zugeschnitten sind. Idealerweise sind diese

Komponenten dann mehrfach nutzbar.

Profinet-Komponente :

DB

Daten-

schnittstelle

FB

FB

FB

Die Komponenten (auch von verschiedenen Herstellern !) knnen in der Anlage nun beliebig

verkettet werden. Dies geschieht bersichtlich in grafischer Darstellung mit einem

Verschaltungseditor :

Weiter werden die Komponenten, die in Profinet ber TCP/IP kommunizieren, auch noch mit

IP-Adressen versehen. Damit ist die Komponente dann auf ein spezielles Anlagenmodul (SPS)

spezifiziert.

Als Verschaltungseditor bietet z.B. Siemens das Tool Simatic IMAP an.

Praktische Beispiele von Realisierungen der Verfahren mit

Simatic S7 :

In der Praxis : ISO-on-TCP mit 2 Simatic S7-SPS

Diese Kommunikation ist nicht so ganz einfach zu realisieren. Im Prinzip luft es so ab :

Man erzeugt mit Hilfe eines Tools von Siemens (Open Communication Wizard) alle ntigen

Kommunikationsparameter. Diese werden in den beteiligten Stationen in je einem DB

gespeichert.

Der Kommunikationskanal mu dann mit Hilfe eines FB geffnet werden, weitere FB (Send

und Receive) ermglichen dann den Datenaustausch.

Sie mssen das nicht unbedingt selber hinkriegen, mssen aber die Struktur der

Kommunikation verstanden haben.

1. Kommunikationsparameter und Bausteine einfgen :

Laden Sie das fertig konfigurierte Projekt Muster2011 und speichern Sie es unter einem

individuellen Namen (hier : TCP_Doll) lokal auf Laufwerk c:

Nun rufen Sie den OPEN COMMUNICATIN WIZARD auf (Programme/Siemens), den Sie,

falls nicht installiert, auch hier finden knnen : //filer_labornetz/software/tcp_wizard.zip

Geben Sie im Wizard zunchst Gert A (hier die Bandstation) an, und den Ordner, in dem

sich die Bausteine hier befinden :

Alle weiteren Fenster durchklicken, bis zur Auswahl des Verbindungstyps.

Hier whlen Sie ISO-on-TCP :

Nun gleich beide Gerte parametrieren, hier Band und Vertikalarm :

Dann die ntigen Parameter, wie z.b. IP-Adressen, angeben :

Dann Service-Access-Points(hier Transport-SAP, TSAP genannt) am Besten als symbolischen

Text eingeben, dann wird der Wert vom Wizard festgelegt :

Nun mssen die Parameter in einem Datenbereich der SPS-en gespeichert werden.

Das kann in ein einem DB geschehen, in den Siemens-Vorlagen wird aber stets ein UDT

(user defined type) verwendet. Weil laut Pflichtenheft der digitalen Fabrik alle

Kommunikationsadressen unter 100 liegen sollen, wird hier der UDT 50 benutzt :

(http://portal.ts-muenchen.de/Dateien/digitaleFabrik_2010_11.pdf, Seite 20)

Das wars, mit einigen weiter und fertig stellen kann man den Wizard abschlieen.

http://portal.ts-muenchen.de/Dateien/digitaleFabrik_2010_11.pdf

Nun im Simatic Manager das Projekt ffen, die erste Station (Band) anwhlen, und aus der

Bibliothek Standard Library in Communication Blocks die drei Funktionen FB65 (Connect),

FB63 (Send) und FB66 (Close) in denm Bausteinordner der SPS kopieren :

Fr die Nutzung der UDT50-Daten wird nun noch ein DB50 erzeugt .

Neues Objekt einfgen -> Datenbaustein :

Der UDT wird (nach Doppelklick auf den DB50) eingefgt :

Das gleiche Spiel mit dem Kommunikationspartner (hier das Vertikalmodul), nur da hier

statt dem FB63 (Send) der FB64 (Receive) eingebunden wird :

2. SPS-Programme :

Es soll ein Demo-Programm entstehen, das manuell durch Variablensteuerung bedient wird.

Fr die Steuersignale werden Merker ab 10 benutzt, die Signale aus den Bausteinen werden

im gleichen Adressbereich wie die Bausteinnummern belegt (z.b. MB63 fr FB63).

Verbindungsaufbau in Modul A (Band) :

M10.0 startet (manuell) den Verbindungsaufbau, wird bei erfolgter Verbindung (DONE,

M65.0) wieder zurckgesetzt. M10.1 zeigt dann die stehende Verbindung an.

Fr den Verbindungsaufbau in Modul B (Vertikalmodul) wird der OB1 dort identisch

programmiert.

Testen :

Alles in die Stationen laden, und die Bedienung durch Variable beobachten und steuern

vorbereiten. Dann zuerst beim passiven Teilnehmer (Vertikal) und dann beim aktiven

Teilnehmer (Band) den Verbindungsaufbau durch M10.0 = 1 starten.

-> Jetzt mu bei beiden Stationen der M10.0 wieder FALSE werden und M10.1 mit TRUE

die stehende Verbindung anzeigen !

Weiter zur Datenbertragung :

Im Band wird der Inhalt von MB20 nach Triggern mit M10.4 geschickt :

Im Vertikalmodul wird der empfangene Datenwert in MB20 gespeichert :

Testen :

Wieder in der Variablenbedienung zunchst die Verbindung aufbauen :

Dann am Empfnger den Eingang ffnen (Enable) M10.4=TRUE,

am Sender einen Wert in den Datenspeicher MB20,

und dann am Sender mit M10.4 den Sendevorgang triggern :

Bei anderer Bedienung verhlt sich das etwas komisch (man kann z.b. durch Spielen

erreichen, da Daten auch ohne Trigger M10.4 gesendet werden). Das kann aber nur bei

manueller Fehlbedienung passieren .

Jetzt kann man noch den Verbindungsabbau einprogrammieren, das geht aber auch zum

testen einfach durch Neuladen der Stationen.

In der Praxis : Profinet I/O

Laden Sie das unbenutze AT-Musterprojekt (auf Ihrem Desktop oder vom filer).

Im Hardwarekatalog ihres TIA-Portals mu sich die WAGO-Device Komponente 750/753

befinden. Wenn nicht : auf \\r2d2\filer finden Sie den passenden GSD-Gertedatensatz unter

at/wago-gsd Dateien. Der Import in TIA erfolgt unter dem Hauptmenpunkt Extras.

Profinet-Device hinzufgen :

Aus dem Hardwarekatalog fgen Sie das Wago-Device I/O-System 750-340 (FW3) zum

Netz hinzu :

Device im Katalog anklicken und mit der Maus ans Ethernet PN/IE ziehen.

Nach Doppelklick auf die Komponente geht die Gertesicht auf, in der Sie dem Device die

richtigen IP-Parameter und einen Namen geben.

Beispiel : Das Device am Vertikalarm soll Vertikal_Lampe heien, und hat die IP-Adresse

1.0.6.24 (Dokumentation digitale fabrik Seite 16) :

file://r2d2/filer

In der Netzsicht des TIA-Portals ordnen Sie die noch nicht zugeordnet genannte Station

jetzt (Mausklick) der Gewnschten S7_Station (=Profinet-Controller) zu :

Jetzt kann das Device fertig konfiguriert werden, in der Gertesicht des Device ziehen Sie die

in der Hardware gesteckte I/O-Baugruppe 75x-504 4DA + 4bit A in den ersten freien

Steckplatz der Konfigurationsgrafik

:

..und konfigurieren dann die I/O-Adressen auf Werte im Adressbereich 0..99 (Doku !) :

Die Konfiguration des Device mu nun an die Hardware bertragen werden.

Dieser Schritt heit bei TIA Namen zuweisen, er erfolgt durch Klick auf diesen Button :

In der gewhlten S7-Station schreiben Sie einen kleinen FB (sportlich sein : SCL schreiben !),

der den Taster am Bedienwinkel liest und in ein Bit des Profinet-Device- Ausgangs schreibt.

bertragen, testen !

Teil 2 : Kommunikation in modularen Strukturen

Schnittstellen an Fertigungsmodulen -> Standardschnittstellen

Nach der rein elektrotechnischen Betrachtung der Schnittstellenprotokolle wenden wir uns

nun der Anwendung dieser zu. Wie, mit welchen Signalen, wird im Industrieumfeld in

modularen Anlagen kommuniziert ?

Auftrag : was ?

Timing : wann ?

Die Unterscheidung in Timing und Auftragsinformation ist erst in jngster Zeit relevant

geworden. Die Mglichkeit, mit Fertigungsmodulen ohne Umrsten verschiedene

Ttigkeiten auszufhren (Varaintenfertigung, flexible Fertigung bis hin zu Losgre 1) ist eine

der Voraussetzungen fr Industrie 4.0. Erst dadurch wird Auftragsinformation ntig.

Fr die Informationsschnittstellen an Fertigungsmodulen sind firmeninterne

Standardprotokolle gebruchlich (Standard : gleiche Schnittstelle an allen Modulen !).

Beschreibung und Realisierung von Schnittstellen

Schnittstellenprotokolle an Industriekomponenten werden meist in drei mglichen

Beschreibungsweisen definiert :

1) Text.

Die Beschreibung in Form eines Pflichtenheft-hnlichen Textes.

Nicht einfach, einen komplexen Funktionsablauf in Worten zu beschreiben

In Patentschriften oder hnlichen juristisch relevanten Fllen ntig, vielleicht

auch dann, wenn der Gesprchspartner keinen technischen Hintergrund hat.

2) Das Timingdiagramm.

Hier werden die Signale der Kommunikation wie Spuren eines Mehrstrahl-

Oszillokopes dargestellt. Auf einer gemeinsamen t-Achse beliebig viele Signale.

Vorteil : gute bersicht.

Nachteil: Man sieht nicht, welche Signale Ein- oder Ausgnge am Modul sind

3) Das Petrinetz.

Sehr elegante und gut lesbare Form der Zustandsablufe.

Es lohnt sich das zu kennen, viele Programmieroberflchen arbeiten damit, z.B.

Simatic Graph7 oder PLD-Programmiersysteme.

Funktionsbeschreibung von Kommunikationsschnittstellen

mit Timing-Diagrammen

Das Timingdiagramm zeigt den zeitlichen Ablauf qualitativ, also ohne Angabe von Einheiten.

ber einer gemeinsamen Zeitachse werden (meist digitale) Signalspuren angetragen.

Mit dem ? Symbol werden Bedingungen definiert (das Signal kann nur erfolgen, wenn die

Bedingung vorhanden ist, mu aber nicht), mit dem !-Symbol werden zwingende Abfolgen

definiert (das Signal mu folgen).

Ntzlich, auch wenn es trivial erscheint, ist eine kleine Skizze, die zeigt, welches Signal

an welchem Modul Ein- und Ausgang ist :

A

B

C

Damit wird das Timing klarer :

A

B ?

C !

Als Text :

Modul X2 kann (mu aber nicht) B setzen, wenn A von X1 anliegt, X1 mu darauf dann mit C

reagieren

Modul X1 Modul X2

Funktionsbeschreibung von Kommunikationsschnittstellen

mit Petrinetzen

Ein Petri-Netz ist ein mathematisches Modell von nebenlufigen Systemen. Es ist eine

formale Methode der Modellierung von Systemen bzw. Transformationsprozessen.

(Quelle : Wikipedia, siehe auch Automatentheorie und Moore-Automaten)

Es besteht aus Zustnden (state, diese sind in der Hardware durch die Ausgnge

speichernder Bauteile definert) und Zustandsbergngen (transition). Eine Marke (Punkt)

definiert, ob ein Zustand aktiv oder nicht aktiv ist.

Funktionsregel :

Wenn alle Zustnde vor einer Transition akitv sind, schaltet diese. Die Marke wandert dann

auf die nachfolgenden Zustnde :

Zeitpunkt 1 : Zeitpunkt 2 :

http://de.wikipedia.org/wiki/Modellhttp://de.wikipedia.org/wiki/Nebenl%C3%A4ufigkeithttp://de.wikipedia.org/wiki/System

Modifikation der Petrinetz-Darstellung zum Zustands-

automaten (state machine) :

Um Ein- und Ausgnge deutlicher unterscheiden zu knnen, werden die Eingnge ohne

Kreise dargestellt und an die Transition seitlich angeschrieben :

B = 1 B = 0

(Weitere einfache Beispiele : Mausfalle )

Darauf basierend wurden SPS-Programmiersprachen entwickelt, z.B. Graph7 und Higraph

von Siemens.

A = 0 A = 1

IM BUNGSTEIL :

bung : Aufgabe zum

Petrinetz

Handshake Kommunikation

In Industrieanwendungen wird bei der Kommunikation zwischen Modulen meist vom

Handshakeprinzip Gebrauch gemacht. Das bedeutet im Wesentlichen, da alle Signale vom

Kommunikationspartner quittiert werden (Polizeifunk), und da Signale immer abhngig

vom Zustand des Partners erfolgen. Das minimalste Handshake-Protokol wre ein quittiertes

Start-Signal.

1. Welche Signale sind Eingnge und Ausgnge bei den beteiligten Gerten ?

2. Darstellung in Timing-Diagramm (I/O-Richtungs-Information geht verloren !) :

Start

Acknowl.

Modul A Modul B

Start

Acknowledge

3. Realisierung des Protokolls mit Petrinetz fr Gert B :

Start= 1 Start= 0

Einfaches Beispiel fr Handshakekommunikation

Zwei Gerte (A und B) tauschen Nachrichten aus. :

Gert A meldet durch das Signal READY = 1 seine Betriebsbereitschft (z.b. nach Selbsttest).

Gert B kann Gert A durch das Signal START = 1 starten, wenn A betriebsbereit.

START und READY fhren nun einen Handshake aus. READY wird = 0 sobald START erkannt

ist (intern luft jetzt die Mechanikaktion in A an). Mit READY = 0 wird START ebenfalls

zurckgesetzt. A luft nun bis zum Funktionsende seiner Mechanik, und setzt dann READY

wieder = 1. Der Ablauf beginnt von vorne

1) Zeichnen Sie Blockbild und Timing dieses Ablaufes

2) Stellen Sie die Funktion von Gert A und Gert B als Petrinetz dar.

Nun sollen 2 Gerte vom Typ A an B angeschlossen werden (A1 und A2). Diese beiden Gerte

sollen in zwei verschiedenen Betriebsarten gekoppelt werden :

3) Koppeln Sie A1 und A2 parallel (Timing, Graph)

4) Koppeln Sie A1 und A2 seriell (Timing, Graph)

Ack = 0 Ack = 1

1) READY

START

READY

? ! !

START

2) Gert A : Gert B :

START (mgliche Bedingung ?) READY

(Funktionsende) / READY

GERT A GERT B

READY

/ READY

/ START

START

3)

R1 R2

S1 S2

R1

S1

R2

S2

Ready 1 Ready 2

/Ready 1 /Ready2

B

A1 A2

/ START 2

START 2

/ START1

START 1

IM BUNGSTEIL :

Praktikum : Handshake in

der Prozessebene

IM BUNGSTEIL :

bung : Testfragen zur

Handshakekommunikation

IM BUNGSTEIL :

bung : Aufgaben zur

Handshakekommunikation

MES-Ebene

Sie sollen zunchst verstehen, welche Grundfunktionen MES-Systeme ausfhren.

Hier arbeiten wir zum ersten Mal mit der digitalen Fabrik der TSM als Fertigungssystem :

Durch die praktische Programmierung grundliegender MES-Funktionen fr die Anlage sollen

Sie ein tieferes Verstndnis fr Funktion und Einordnung von MES-Systemen gewinnen.

Beabsichtigter Nebeneffekt ist die rudimentre Nutzung objektorientierter Methoden.

Dieses Thema gewinnt in der Automatisierungstechnik rasant an Bedeutung und soll

darum mit behandelt werden. Die Bedeutung von Begriffen wie Objekt, Methode usw.

wird durch praktische Anwendung schnell klar.

Ein wesentliches Problem der aktuellen Industrieautomatisierung ist die berschneidung der

Anlagenwelt mit der IT-Welt. Ein Beispiel hierfr ist die Schnittstelle von PC zu SPS. Hier

sollen Sie durch Betrachtung der unterschiedlichen Betriebssystem-Funktionen zum

Verstndnis typischer Programmierstrukturen kommen.

Struktur eines MES-Sytems :

Obwohl die in der Praxis vorkommenden MES-Syteme sehr uneinheitlich und stark dem jeweiligen

Prozess angepasst sind, lt sich doch meist eine innere Grundstruktur erkennen :

MES-System

Logging and

Reporting

Manufactoring

flow

execution

Kommunikationskern

der gesamten Anlage.

Connectivity zu

allen Ebenen.

ERP-System

Process

(shop floor)

HMI

(SCADA)

flow planing

Logging, Reporting :

Prozessdaten (Mewerte, Energieverbrauch, Fehlermeldungen, usw.) werden aus der

Prozessebene (SPS) an die MES-Ebene kommuniziert.

Sie werden dort in groen Mengen gespeichert und archiviert. Bei auftretenden Fehler kann

dann z.b. anhand der Verlaufsdaten eine Analyse mglich werden.

Die Daten knnen weiter mit Grafiktools zu zusammenfassenden Aussagen aufbereitet

werden, und bilden dann sog. KPI-Daten (key performance indicators) :

Daten werden erfasst : Tag (Wert + Zeitstempel) logging

Daten werden auf Grenzwerte geprft : Alarming

Daten werden zu aussagekrtigen Darstellungen gewandelt : Report Design

Manufactoring flow execution :

Produktauftrge aus der ERP-Ebene werden zu Fertigungsschritten im Prozess aufbereitet.

Das MES-System steuert wie ein Dirigent die Abfolge der Aktionen in der modular

aufgebauten Prozessebene, reagiert auf Fehler und lt eine manuelle (Not-) Bedienung zu.

Der bergang zwischen manuell vom Anlagenfahrer bedienten Anlagen und voll-

automatischen MES-gefhrten Anlagen ist hier flieend.

Ein wichtiger Begriff im Rahmen des Entwurfs von Flow execution ist die Art und Weise, wie

die Modulaktionen voneinander abhngen (wird auch flow design genannt). Werden Sie

immer gleichzeitig gestartet (gemeinsamer Anlagentakt), nacheinander oder laufen Sie vllig

unabhngig voneinander ?

Im Maschinenbau wird diese Struktur Verkettung genannt (ursprnglich ein Begriff fr die

Struktur des Materialtransports von einem Modul zum Nchsten).

Fr die Leittechnik bedeutet Verkettung heute auch die Koordinierung der Modulaktionen

in der Prozessebene :

serielle Kopplung : Manufakturbetrieb, Herstellen von Einzelstcken

parallele Kopplung : Serienbetrieb mit allen Modulen gleichzeitig, Chargenfertigung

starre Kopplung : Die Module werden von einem gemeinsamen Anlagentakt gesteuert

lose Kopplung : Die Module laufen frei ohne berlagerten Anlagentakt

(Materialpuffer, Auswirkung auf Verfgbarkeit)

flexible Fertigung : Die Anlage kann ohne Umrsten verschiedene Produkte herstellen

(Variantenfertigung, Losgre 1 )

Die dazu auch wichtigen Begriffe Charge und Los werden hierbei in der Literatur verschieden

definiert. Im Weiteren gilt hier :

Charge ist die Anzahl von Produkten, die in einem Serienlauf (Produktionsanlauf

Produktion Produktionsauslauf) gefertigt werden

Losgre ist die Anzahl der Produkte (nacheinander innerhalb einer Charge), die identischen

Aufbau haben.

Moderne Anlagen sollen in loser Kopplung Losgre 1 fahren knnen.

Die Zuordnung der ntigen Auftragsinformation bei Losgre 1 wird dann schwierig.

Produktidentifikation (z.b. Barcode-Aufkleber, RFID ) lst dieses Problem.

HMI, SCADA :

Human machine interface und supervisory control and data acquisition bezeichnen die

Schnittstelle, an der Eingriffe und Kontrolle durch den Anlagenfahrer mglich sind.

Prozessvisualisierung wird das auch genannt, hier werden Ablufe grafisch dargetellt :

Weiter bieten manche SCADA-Systeme die Mglichkeit, den Fertigungsablauf in der

Reihenfolge der zu fertigenden Produkte zu beeinflussen. Man nennt das Sequenzieren oder

flow planing, hierzu wird dann meist auch eine grafische Oberflche benutzt, das

Sequenzier-terminal :

:

Die zu fertigenden Produkte werden in eine optimale Reihenfolge sequenziert.

WICHTIG : Die Produktreihenfolge, nicht die der Modulaktionen (Fertigungsschritte) !

Connectivity : OPC als Kommunikationsstandard in der MES-Ebene

OPC uA scheint sich neben Webservices (REST) als Standard in der MES-Ebene

durchzusetzen. Deshalb zunchst eine theoretische Einfhrung in diese Technik, dann Praxis.

OPC ist ein Kommunikationsprotokoll fr die bertragung von einzelnen Steuer- oder

Prozesswerten (also meist Bytes oder hnliche Formate). Es wurde ursprnglich aus

Microsoft OLE (OLE for process control) abgeleitet, das (wie Profinet CBA, siehe oben) mit

der DCOM-Technik (Microsoft) arbeitet. Weil Microsoft COM auslaufen lies, war man

gezwungen, eine alternative Protokollbasis zu erstellen, was zur Entwicklung von OPCuA

fhrte. (OPC nun fr open process control, uA fr unified architecture).

Einen berblick zu den aktuell (Februar 2017) eingesetzten Protokollen zeigt dieses Bild :

Es werden zunchst prinzipiell zwei OPC-Protokolle genutzt : OPCuA binary und OPCuA XML

Im Binrprotokoll luft die Kommunikation ber UA secure conversation, das ist ein

Protokoll, welches ber Authentifizierung und Autorisierung, Verschlsselung usw. sichere

Kommunikation herstellt. Auf Layer 4/3 wird TCP/IP genutzt, darunter die blichen

Ethernetprotokolle. Der Standardport hierfr (es wird nur ein Port benutzt) ist 4840,

dieser mu bei Fernzugriff in der Firewall geffnet werden.

Das Binrprotokoll ist sehr effizient (keine Decodierung von http, soap und xml), wird

deshalb oft bei embedded systems (Microcontroller oder Systeme wie z.B. Raspbery Pi)

benutzt.

Im Webservice-Protokoll werden die Nutzdaten in XML verpackt. (Das ist so hnlich wie

html, nur mit frei definierten Tags, zum Beispiel : 1). Die bertragung

geschieht wieder durch ein sicheres Protokoll, in diesem Fall WS secure conversation, wobei

WS fr Web Services steht, also ein Protokoll, in dem die Datenquelle ein Webserver ist.

Die Daten werden vom Webserver weiter verpackt, und zwar in das SOAP-Format, das einen

etablierten Standard fr die bertragung von XML-Daten darstellt. Im wesentlichen werden

die Daten (SOAP Body) darin mit weiterer Information versehen (SOAP Header) und nach

bestimmten Regeln aufgebaut und geschickt :

Der Vorteil einer Standardisierung wie SOAP

ist, da durch die frei zugngliche

Dokumentation des Datenformats (weltweit)

auf Daten zugegriffen werden kann, ohne

jeweils spezifische Formate bercksichtigen

zu mssen.

Beispiel SOAP-Anfrage : (Zeilennummern sind hinzugefgt)

1 2 7 123 8 9 10

Zeile:

1 Dieses Dokument ist in XML Version 1.0 codiert, Zeichensatz ist UTF-8

2 jetzt folgt der SOAP-Umschlag (Envelope)

3 der Umschlag ist in der Syntax von schemas.xmlsoap.org codiert (ein Standard !!!)

Damit ist u.A. festgelegt, wie die Nachricht im Umschlag aussieht, es kann z.B.

(mu aber nicht) ein Header (berschrift) angegeben werden, und es

mu ein Inhalt (body) folgen, der diesen und jenen Regeln entspricht

4 Hier geht der Inhalt los

5 Im Namesraum ns1 gibts eine Methode double Integer, die wird aufgerufen

6 der Namensraum ns1 ist definiert als das Verzeichnis : MySoapServices

7 der Parameter lautet (mit Datentypangeben) : 123

8 hier ist der Aufruf zu Ende

9 hier ist der body zu Ende

10 hier ist der Umschlag zu Ende

Beispiel SOAP-Antwort :

1 2

Fr den Anwender unangenehm, sind aktuell zwei nicht kompatibleVarianten am Markt :

OPC dA (data access) : Die (Steinzeit) OPC-Variante mit DCOM

OPC uA (unified architecture) : OPC auf offener Basis, entweder mit effizienten

Binrprotokollen (opc.tcp://url:port) oder mit

Webservices XML (http://url:port) kommunizierend.

Inkompatibilitten durch verschiedene OPC-Varianten beseitigt bersetzungssoftware :

OPC-Wrapper : OPC-Proxy :

OPC uA OPC dA

OPC dA OPC uA

bersetzung in beide Richtungen : OPC- Gateway

uA-Server

dA-

Client

dA-Server

uA-

Client

http://url:port

Was bringt OPC ?

Wird nun als Kommunikationskern eines MES-Systems ein OPC-Server eingesetzt, so mssen

die beteiligten Rechner nicht mehr einzeln alle fr ihre Kommunikation ntigen Treiber und

Schnittstellen aufweisen. Der OPC-Server ersetzt diese Vielfalt durch eine einheitliche

Kommunikationssprache (OPC-Protokoll). Man nennt solche Strukturen Middleware.

Beispiel : Wenn am Flughafen Mnchen 3 Flugzeuge landen wollen, deren Piloten

Chinesisch, Indisch und Russisch sprechen, mte der Fluglotse alle 3 Sprachen

beherrschen. Um dies zu vermeiden, einigt man sich auf ein gemeinsames

Kommunikationsprotokoll, in diesem Beispiel auf Englisch als

Zwischensprache (=Middleware).

Der Server ist blicherweise kein eigenes Gert, sondern einfach ein Dienst,

der auf irgendeinem immer laufenden MES-Server installiert wird :

(Ethernet TCP/IP)

OPC-Protokoll

herstellerspezifische Treiber

proprietre Protokolle

Feldgerte, z.b. SPS verschiedener Hersteller, Sensoren, Aktoren usw.

Mit OPC-Clients lassen sich dann die Variablen (Tags) in Peripheriegerten (z.B. SPS) mit

einem Browser darstellen .

OPC-Server

z.B. MES

Einige Begriffe aus der Konfiguration von OPC-Servern :

namespace

Um Ordnung in die Liste der Variablen (Tags) zu bringen, die von einem Gert am OPC-Server

zugnglich sind, wird diese in Namespaces (Namensrume) unterteilt.

Die Namespaces sind durchnummeriert, und gliedern im interessierenden Teil die Tags.

Das entspricht so etwa der Definition von Freigaben in einem Windows-Netz.

Namespace 0 (ns=0) ist reserviert, hier stehen immer Angaben ber das Serverobjekt.

Namespace 1 (ns=1) ist oft der atalog von Devices, also z.b. SPS

Namespace 2 (ns=2) untergliedert weiter in einzelne tags oder Gruppen usw..

Um herauszukriegen, in welchem namespace ein gewnschtes Tag liegt, ist es am

einfachsten, den Server mit einem grafischen OPC-Client zu browsen.

tag

Tags haben mehr Attribute als gewhnliche Variablen :

Value : Der eigentliche Datenwert (Byte oder hnliches Format)

Quality : Eine Angabe ber die Verbindungsqualitt (Bad, Uncertain, Good)

Timestamp : Zeitpunkt der Erfassung durch die Subscription und der Weiterleitung

an den Zielrechner.

subscription

In der Praxis von Bedeutung ist weiter die sogenannte Subscription, ist die Mglichkeit,

mittels eines Abbonnements die berwachung der Tags dem Server zu berlassen.

Er prft dann stndig in der eingestellten Zykluszeit den Tagwert, und bertrgt diesen nur

wenn gewnscht (z.b. wenn er sich verndert) an den Zielrechner.

In der Praxis : OPC uA

Gezeigt wird hier die Anbindung eines OPC-Servers an die SPS der Prozessebene, und dann

der Zugriff auf die Prozessdaten als OPC-Tags.

1) Der OPC-Server

Wir verwenden hier die Trial-Version eines in USA sehr verbreiteten MES-Systems, des

Ignition Gateway. Diese Software kann alle oben beschriebenen Funktionen eines MES-

Systems in Modulen ausfhren. Hier kommt aber nur das OPC-Modul zum Einsatz.

Konfiguriert wird mittels Webinterface :

Man whlt zunchst den Treiber aus, der die Zielhardware mittels TCP/IP kontaktieren soll :

..und gibt dann weitere Parameter an :

So entsteht eine Liste verfgbarer Prozessmodule :

2) Der OPC-Client

Im allgemeinen wird der Zugriff auf die Prozessvariablen, die Tags genannt werden, nun aus

einem Programm heraus erfolgen, das die Anlage steuert (MES Core-System).

Man kann aber zu Testzwecken auch einen grafischen Client verwenden, der manuelle

Bedienung erlaubt. Hier verwenden wir den freien OPC-Client der Firma Softing.

Zunchst stellen wir die Verbindung zum OPC-Server auf MES1 her. Die URL des OPC-Servers

im Labornetz lautet : opc.tcp://mes1:4096

(Die Kennung opcuauser mit dem Passwort password wurde vorher im OPC-Server definiert)

Ist der Client zum OPC-Server verbunden, sieht man die zur Verfgung stehenden Gerte :

Hier wurde eine Verbindung

hinzugefgt

Deren Daten hier zu sehen sind

Im Message-Feld stehen Fehlermeldungen usw.

Leider untersttzt dieser Server das Browsen der Tags nicht, so da die Prozessvariablen

nicht automatisch angezeigt werden knnen.

Man mu die gewnschten Tags manuell hinzufgen :

Klick auf + fgt einen Datenkanal (Subscription) hinzu :

Rechter Mausklick auf diese Subscription, und ein neuer Tag kann erzeugt werden (create

monitored item). Dieser mu jetzt korrekt benannt werden.

Tagbezeichnung

(ns=1 bei Ignition Server)

Abtastrate

lesen oder schreiben

Datenwert

Verbindungsqualitt

Zeitstempel

IM BUNGSTEIL :

Praktikum : SPS-Zugriff mit

OPCuA

IM BUNGSTEIL :

Praktikum : Installieren und

Konfigurieren von OPC Server

Ein neuer Standard ? MQTT in der Automatisierungstechnik

Seit 2016/17 erscheint in der industriellen Protokollwelt der Begiff MQTT.

Dieses sehr schlanke Protokoll (Message queue telemetry transport) wurde 1999 von IBM

und Anderen entwickelt, um Wartungsdaten von lpipelines zu SCADA-Servern zu

bertragen.

MQTT scheint sich als Konkurrenz zu OPCuA zu etablieren, obwohl es eigentlich in der IoT-

Welt zuhause ist. Dort geben kleine Prozessoren Daten ab, die in Clouds zentral

gespeichert, und von anderen Clients wieder gelesen werden knnen. (Sozusagen die M2M-

Version von Dropbox )

In fortgeschritteneren Varianten wird dann auch die zentrale IT (etwa ERP-Funktionen o.) in

der Cloud angesiedelt.

Eine MQTT-Umgebung hat folgende Struktur :

Zentrale Komponente ist der MQTT-Broker (zentral in der Cloud).

Dieser arbeitet wie ein schwarzes Brett, Clients knnen Nachrichten eingeben (Publish)

oder /und lesen (Subscribe). Ein nettes Feature ist die Mglichkeit, eine sogenannte Last

will and Testament- Nachricht zu spezifizieren, die vom Broker dann abgegeben wird, wenn

die stndig berprfte TCP/IP-Verbindung keine Daten mehr liefert.

Ein Beispiel (aus der IoT-Welt) :

Ein intelligentes Kugellager mit einem kleinen Controller ist in der Lage, Zustandsdaten

(Temperatur, Drehzahl, ) ber MQTT in eine Cloud zu schreiben. Dort werden sie von

einem Rechner abgeholt und fr predictive maintenance (vorausschauende Wartung)

benutzt. Dies ist eine klassische Industrie 4.0-Anwendung mit Digitalisierung bis in die

unterste Ebene (IoT : Internet of Things).

Als Cloud werden entweder spezialisierte ffentliche Clouds (z.B. IBM Bluemix ) oder in

Firmen selbst gepflegte Clouds (private cloud) benutzt, die dann einen Broker wie z.b.

Mosquitto (open source) oder HiveMQ (kommerzielles Produkt)beinhalten.

Ob sich MQTT in der Zukunft in breitem Rahmen in der Industriekommunikation etablieren

wird, (parallel zu Webservices und OPCuA), werden die nchsten Jahre zeigen.

Realisierung von MES-Funktionen 1. Einfhrung VisualBasic

Nun sollen Sie selber MES-Funktionen programmieren und an der Anlage testen:

Als Programmiersprache wren hier alle modernen Sprachen mglich : C#, C++, Java, usw..

Als Skriptsprache ist z.B. in Ignition Gateway Python integriert.

Wir verwenden der Einfachheit halber Visual Basic, weil es sehr einfach zu bedienen ist.

Im Folgenden sehen Sie links die logischen Operationen, rechts die dazugehrige Syntax :

Anweisung : a = b + c

a = b c

a = b * c

a = b / c

Schleife : do while a < 0

..

..

loop

Zhlschleife : for i=1 to 100

..

..

next

solange Bedingung gilt

a = b + 1 ;

fr i von 1 bis 100

Verzweigung : a > 0 ? if a > 0 then

ja nein .. ..

..

else

..

..

end if

Stringoperationen :

Strings (und Variableninhalte) zusammenfgen: neu = Hallo & name

Stringanalyse : a = right (test,3) 3 Zeichen von rechts aus test in a

b = left (test,4) 4 Zeichen von links aus tes in b

c = mid (test, 5, 3) 3 Zeichen ab der 5-ten Stelle von test in c

Einfache Versuche knnen mit einer Minimalversion von Visual Basic direkt als Interpreter-

Skript auf dem Desktop von Windows-Rechnern ausgefhrt werden (VB classic).

Sie schreiben (nach Struktogramm ;-) den Programmcode einfach als Textdatei,

die Sie dann als Textdatei.vbs abspeichern. Durch ffnen oder Doppelklick mit der Maus

knnen Sie das dann starten. Wenn es nicht mehr zu stoppen ist, im

Maskmanager nach Wscript.exe suchen und terminieren.

Ein-Ausgabe im Interpreter : a= InputBox(text) MsgBox(a)

IM BUNGSTEIL :

bung : Programmieren in

VB Skript

Ein Werkzeug zur komfortablen Programmierung :

Visual Studio

Microsoft-Systeme haben in der modernen Industrietechnik eine dominierende Stellung

eingenommen. Deshalb wird hier die von Microsoft stammende Entwicklungsumgebung

Visual Studio (in der kostenfreien Variante Visual Basic Express 2012) benutzt.

In der Praxis : Microsoft Visual Studio

1. Visual Basic 2010 Express ffnen, Forms-Projekt anlegen :

Forms-Anwendung whlen

Einen Namen vergeben

Einen Pfad angeben

Wir benutzen einen Button und zwei Textbox-Elemente :

Die Details der Elemente (z.b. Namen, angezeigte Texte und so) knnen sie in den

Eigenschaften einstellen, die auch ber das Ansicht-Men anzeigbar sind.

Jetzt wirds ernst.

Aufgabe : in Feld 1 wird eine Zahl reingeschrieben, die soll verdoppelt und an Feld 2

ausgegeben werden, wenn man den Button drckt.

Das Programm dazu schreiben sie, indem sie es an das gewnschte Windows-

Bedienelemente anbinden. Dieses Element (unser Button) doppelklicken sie bitte :

Programmkopf

Wenn sie den

drcken..

..passiert, was sie

hier reinschreiben

Ich lese den Wert aus Textbox1 ein (siehe Eigenschaften !), verdopple und gebe an Textbox2

aus :

..und so entsteht meine Lsung :

Wenn ich hier was schreibe, das dem Editor schon bekannt ist (das

werden spter auch die Methoden und Eigenschaften sein !), dann

schlgt er was vor.

..das ich dann

whlen kann !

Die ich ausprobiere, indem ich den Debug Modus starte :

.. sieht dann so aus :

Das wrs.

Alles speichern, und wenn sie das Programm ohne die Entwicklungsumgebung bentigen,

finden Sie im Projektordner unter \bin\debug das .exe file.

Pfeil drcken !

(mit Rechteck wieder stoppen)

IM BUNGSTEIL :

Praktikum : Einfhrung in

Visual Studio

Zugriff auf Peripheriegerte mit OPCuA in Visual Basic

Im Labornetz der tsm sind 3 OPCuA-Server installiert :

OPC Suite von Softing auf dem Server MES1 (Port4089),

Ignition Gateway auf MES1 (Port 4096),

Kepware Server auf MES2(Port 4097).

Verwenden Sie frs Praktikum immer den Kepware-Server auf mes2 !

Ihr Rechner bentigt VisualStudio ab der Version 2012.

Erzeugen Sie in VisualStudio ein neues VB-Formprojekt, und geben sie ihm einen eindeutigen

Namen, der mit Ihrem zusammenhngt. Es wird noch die Erweiterung QuickOPC (OPC Labs :

http://www.opclabs.com) geladen. Deren Werkzeuge tauchen dann in der Toolbox von Visual

Studio auf. In der Projektmappe (Solution Explorer) sind bei my Project im Untermen

Verweise die Treiber :

OpcLabs.BaseLib.dll, OpcLabs.BaseLibExtensions.dll, OpcLabs.EasyOpc.dll, OpcLabs.EasyOpcUA.dll

und OpcLabs.EasyOpcUAInternal.dll

nachzuladen (zu finden im lokalen Ordner C:\OPCuA ).

- Als erste Zeile, noch vor der public class Definition, binden Sie die Klasse EasyOpc.UA ein :

Imports OpcLabs.EasyOpc.UA

- Innerhalb der public class erzeugen Sie dann ein Objekt :

Dim Apfel As New EasyUAClient

- dessen Methoden Sie dann im Weiteren benutzen knnen :

Apfel.WriteValue(..

Der schreibende Zugriff auf Tags geschieht mit der Methode WriteValue :

Birne.WriteValue(..ID.., data )

Der lesende Zugriff auf Tags geschieht mit der Methode ReadValue :

Wert = Birne.ReadValue(..ID..).ToString

http://www.opclabs.com/

Beispiel :

Aus der Toolbox (Werkzeugkasten) ziehen Sie einen Button und eine Textbox in die Form-

Grafik. (Toolbox fehlt ? -> ANSICHT ).

Nach Doppelklick auf den Button gelangen sie in die Programmierebene, dort ergnzen sie

die Syntax um folgende Eintrge um auf den Kepserver zuzugreifen :

Imports OpcLabs.EasyOpc.UA Public Class Form1 Dim Birne As New EasyUAClient Private Sub Button1_Click() Handles Button1.Click

TextBox1.Text = Birne.ReadValue(ID).ToString End Sub End Class

..ID.. mssen Sie hier durch die korrekte Angabe des OPC-Tags ersetzen :

Binrprotokoll whlen Namespace und Tagname :

mit dem grafischen Client browsen (Node-ID) !

(Protokoll://Socket,ns=Namespace;s=Tagname als String)

IP und Port des Servers

Detail der SPS / Rechner - Schnittstelle :

Eine wichtige Teilfunktion aus obigem Beispiel soll nher betrachtet werden :

Leitrechner in Industrieanlagen kommunizieren wie die anderen Gerte auch immer mit

Handshakeprotokollen. Zur Erinnerung :

- Gert A meldet START

- Gert B quittiert den Empfang von START mit QUITT

Im Petrinetz :

Start

Da die Arbeitsweise des Betriebssystems im Rechner anders als die in der SPS ist, kann ein

Entwurfsverfahren wie das Petrinetz hier aber nicht sinnvoll benutzt werden. Ein PC kann

das so nicht realisieren (Im Kern : es fehlt der OB-Ablaufzyklus !). Deshalb mssen wir die

Funktion in einem zur Funktionsweise passenden Werkzeug beschreiben, optimal im

Struktogramm.

/Quitt

Quitt

Der PC mu warten, bis das Signal des Kommunikationspartners eintrifft, indem er die Frage

nach dem erwarteten Signal (hier START) immer wieder neu stellt :

Dieses Verfahren wird in der Informatik als Polling (aktives Warten) bezeichnet.

kleines Bilderrtsel zum Thema :

..was ist falsch ?

solange das Signal noch

nicht eingetroffen ist

lies den

Signalwert

IM BUNGSTEIL :

bung : Kommunikation

SPS PC (optional)

IM BUNGSTEIL :

Praktikum : Zugriff auf OPC-

Server aus Visual Basic

Objektorientierte Programmierung von MES-Kernfunktionen

Zum Begriff Objektorientierung :

Bei der Programmierung im Industrieumfeld wird heute praktisch ausschlielich von der

Technik der Objektorientierung Gebrauch gemacht.

Objektorientierung bedeutet hier im Wesentlichen, da der Programmierer vorgefertigte

Stukturen benutzt (die von Anderen programmiert wurden), und diese nur noch wie in

einem Lego-Baukasten zusammensetzt. Diese Strukturen bestehen aus Daten, die

Eigenschaften beschreiben (Attribute) und dazugehrigen Programmen, die mit diesen

Daten arbeiten knnen (Methoden). Eine solche Struktur wird Objekt genannt. Die

Programme (Methoden) sind nur zur Bedienung zugnglich, ihr Code bleibt nicht sichtbar

und unvernderbar.

Die benutzte Programmsprache und die in einer Firma meist vorhandenene eigene

Bibliothek (z.b. Programmteile zur Steuerung von Robotern oder hnliches) beinhalten nun

eine Vielzahl solcher Objekte. Diese werden beim Aufruf (diesen Vorgang nennt man auch

Referenzieren) quasi in das eigene Programm hineinkopiert. Die Kopiervorlagen fr die

Objekte werden Klassen genannt, sie sind in einer Klassenbibliothek gespeichert.

Prinzipielle Vorgehensweise :

- Nachschauen, welche Klasse die gewnschten Funktionen beinhaltet

- Durch Erzeugen eines Objekts diese Funktionen zugnglich machen

- Die Methoden aufrufen, die Attribute benutzen

Dokumentation der Klassenbibliothek tsmlib_1617 :

(Sie finden diese Klassenbibliothek als .dll in \\r2d2\filer\at)

Die Klassen werden in folgender Form beschrieben :

Name

Attribute

Methoden

Name : sps_modul

Attribute : ip (String)

auftrag (Byte)

status (String)

error_type (string)

Methoden : start_modul()

lies_status()

reset_error()

SPS-Bedienung ber OPCuA mit dem Ignition Gateway :

Serveradress mes1, 62.245.200.166

module_name band, linear, vertikal, horizontal, lager

order Dezimalwert des Auftragbits : 1, 2, 4 .. jeweils nur ein Bit setzen !

state not connected, ready, running,error

start_module() startet Modul mit einem Standardhandshake

read_state() liest den aktuellen Betriebszustand aus dem Modul

write_order() schreibt Auftrag in SPS

minimales Anwendungsbeispiel :

Imports tsmlib_1617 Public Class spstest Private vertikal As New ignition_opc_module Private Sub Button1_Click() Handles Button1.Click vertikal.serveradress = "mes1" vertikal.module_name = vertikal

vertikal.order = 2 vertikal.start_module()

Do vertikal.read_state() Loop Until vertikal.state = "ready" End Sub End Class

DIESER SERVER DIENT ALS COLD STANDBY !

VERWENDEN SIE DEN KEPWARE SERVER (NCHSTE SEITE)

Name : ignition_opc_module

Attribute : serveradress (String)

module_name (String)

state (string)

order (byte)

Methoden : start_modul()

read_state()

write_order()

disconnect()

SPS-Bedienung ber OPCuA mit dem Kepware-Server :

serveradress im Labornetz : mes2 (von auen : 62.245.200.166)

plant stammwerk, zulieferer

module_name band, linear, vertikal, horizontal, lager.(sps bei plant = zulieferer)

order Dezimalwert des Auftragbits : 1, 2, 4 .. jeweils nur ein Bit setzen !

state not connected, ready, running, error

errorbyte verschieden je nach Station, siehe Anlagendokumentation

start_module() startet Modul mit einem Standardhandshake

read_state() liest den aktuellen Betriebszustand aus dem Modul

read_errorbyte() liest das Fehlerbyte (DB20.DBB2)

write_order() schreibt Auftrag in SPS

Bemerkung zu den Fehlerinformationen :

Im Status state bedeutet error, da das Modul gestoppt hat, weil kein Material vorhanden war.

Im Betrieb auto (Bedienwinkel) luft das Modul trotzdem weiter.

Im Betrieb manu bleibt es mit roter Lampe stehen -> Lager fllen, und den Start-Taster bettigen !

Name : kepware_opc_module

Attribute : serveradress (String)

module_name (String)

plant (String)

state (string)

order (byte)

errorbyte(byte)

Methoden : start_modul()

read_state()

read_errorbyte()

write_order()

disconnect()

RFID-Bedienung :

kanal Nummer des Fertigungsmoduls (0=lin, 1=vert, 2=hor, 3=lager)

wert1 .. wert3 gelesener oder zu schreibender Wert (max. 3 einzelne Byte)

uid_wert MAC-Adresse des RFID-Tags (nach : read_uid)

read_uid Rckgabe von pruef_tag : tag ok oder no tag

readdata Rckgabe von lies_tag() : ok oder lesefehler

connect Rckgabe von init_controller() : connect ok oder connect fehler

writedata Rckgabe von schreib_tag() : ok oder schreibfehler

init_controller() ffnet TCP/IP-Kanal zum Controller (vor Zugriff einmal ausfhren !)

pruefe_tag() testet, ob ein Tag im Lesebereich (liest UID)

schreib_tag() schreibt Wert(e) auf den Tag

lies_tag() liest Wert(e) vom Tag

Name : rfid_controller

Attribute : kanal (Byte)

read_uid(string)

wert1 bis wert3 (Byte)

connect (string)

writedata (string)

Methoden : init_controller()