automatisierungstechnik 2016/17 - profil aitportal.ts-muenchen.de/dateien/at_17_skript.pdf ·...
TRANSCRIPT
-
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 - [email protected] - http://portal.ts-muenchen.de
mailto:[email protected] -
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()