Automatisierungstechnik 2013/14
Werbung
Automatisierungstechnik 2013/14 Einführung : Entwicklung der industriellen Automatisierung Struktur industrieller Anlagen modulare Systeme Verfügbarkeit vertikale Vernetzung Prozessebene Kommunikationssysteme Feldbus : Profibus DP Ethernet : TCP/IP und Profinet MES-Ebene Struktur MES Verkettung von Fertigungsmodulen, Handshakeprinzip Beschreibung nebenläufiger Systeme : Petrinetz Programmierung an der SPS-Schnittstelle Programmierung von MES-Kernfunktionen IT-Ebene (ERP) Struktur ERP redundanzfreie Datenhaltung (SQL) Kommunikation in der ERP-Ebene : Webservices, Middleware Zulieferer (supply chain) Dipl.-Ing. Reiner Doll, Technikerschule München ([email protected]) Entwicklung der industriellen Automatisierung Struktur industrieller Anlagen - zentrale Prozessleittechnik (1970) : Leitwarte mit Prozessrechner ( Echtzeit-BS, Infokompression [rot/grün], Führungsroutinen [Notaus]) Schnittstellentopologie : 4…20mA, NAMUR, NPN/PNP HMI mit Einzelanzeigen, Einzelbedienelementen Beispiele : Flugzeug, Kraftwerk -> Nächster Schritt : Modularisierung der Anlage - modulares, proprietäres Prozessleitsystem (1980) : Einführung des µP Bedienwarte , HMI als Grafik Zellen mit Zellenrechner (später PLC / SPS) Modularität : Komplexitätsreduzierung, Testbarkeit, Flexibilität Kommunikationsbedarf entsteht : proprietärer Systembus Beispiele : Teleperm M, Contronic Teleperm (Siemens) : CS 275 (redundant) AS (SPS) AS (SPS) HMI -> Nächster Schritt : open systems („Multivendor“) - 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 !!) - Endgerät MAP : MAP-Bus (open system) CP : MMS MMS !! Endgerät Hersteller A CP Endgerät Hersteller B CP Endgerät Hersteller C (wichtige Begriffe : Modularität, Protokoll, Dienst (Service-> Server), MMS ) -> Zukunft : Vereinheitlichung der Bussysteme (Ethernet ?) Modulare Systeme : - unabhängig funktionsfähig - unabhängig testbar (ggf. Testumgebung) - unabhängig entwickelbar - Schnittstellendefinition wichtig (optimal : Standardprotokoll) - Funktionsdefinition und Testverfahren sind zu dokumentieren - Modulsteuerstrategie muß entwickelt werden („Verkettung“) Bei modularen Systemen sinkt die Komplexität der Funktion je Modul, dafür steigt der Kommunikationsdedarf. Durch geeignete Anordnung (z.b. parallel) kann das Ausfallverhalten beeinflußt werden. Verfügbarkeit und Sicherheit MTBF p= _____________________ (statistisch ermittelte Werte) MTBF + MTTR q (Unverfügbarkeit) = 1 - p Phase 1 : Frühausfälle meist Produktionsfehler (Lötstellen, Steckkontakte) Abhilfe : Burn-In (Zykeln mit Streßbedingung) Beispiel : Drucksensor p=10bar , 1000 Druckschläge 12 bar, 48 h zykeln 0…70°C Phase 2 : Zufallsausfälle kein Verschleiß, aber zufällige Defekte mit etwa konstanter Unverfügbarkeit vorbeugende Wartung verlängert Phase 2 Beispiel : Verfallsdatum auf Servernetzteil, Ölwechsel Phase 3 : Verschleißausfälle 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 außen immer noch eine Diode ! 3-fach redundanter Modulaufbau : TMR-Betrieb : „demokratische“ Entscheidung wenn eine Komponente ausfällt (typische Anwendung : Leitrechner in Flugzeug) Zuverlässigkeitsbetrieb : Betrieb solange noch funktionsfähige 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 läuft immer mit (hot standby, z.b. 4-Stahl Jet) Gesamtverfügbarkeit modularer Systeme : Serienschaltung : Parallelschaltung : p(gesamt) = Produkt aller p(einzel) q(gesamt) = Produkt aller q(einzel) IM ÜBUNGSTEIL : Übung : Verfügbarkeitsberechnungen vertikale Vernetzung modularer Systeme Strukturierung in sich überlagernde Rechenebenen (SPS, Industrie-PC, Server) Verteilung der Funktionen (Modularisierung) Kopplung mit der Büro-IT (Gateways) CIM : Rechnergestützte Automatisierung („menschenleere Fabrik“) 1980 ..85 Strukturierung : was wird wo gerechnet ? altes Strukturmodell (1990) : - Prozessleitebene : große Datenmengen, schnelle Bussysteme, keine Echtzeit : Leitrechner, Datenbank - Zellebene : Prozessführung, Datenerfassung, Notbedienebene, Alarmbehandlung - Feldebene : Feldgeräte (SPS), busfähige Aktoren / Sensoren, Echtzeit, geringe Datenmenge Aktuelles Strukturmodell (2005) : Integration der Bürodatenverarbeitung (=Kopplung an Ethernet) Kommunikation mit Zulieferbetrieben (Supply chain) Durchgängige Vernetzung ohne Gateways von IT-Ebene bis SPS - ERP-Ebene : strategische Unternehmensebene, Betriebswirtschaft. SCM - MES-Ebene : Prozessführung, Datenerfassung, Verkettung der Fertigungsmodule - Prozessebene : Feldgeräte (SPS), busfähige Aktoren / Sensoren, Echtzeit, geringe Datenmenge Hier gebräuchliche Kommunikationssysteme : Beispiel : digitale Fabrik der tsm (alter Stand 2009 mit Profibus DP) : ERP nimmt Kundenaufträge entgegen und bearbeitet diese nach betriebswirtschaftlichen Gesichtspunkten. MES holt Aufträge aus ERP, bearbeitet diese nach technischen Gesichtspunkten (z.b. optimale Reihenfolge), und schickt Fertigungsbefehle an die Prozessebene. Der SPS-Master bedient die Module mit den von MES eintreffenden Aufträgen. Prozessebene 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 (Verfügbarkeit !) ? ISO/OSI-Modell : Application layer Anwendung (Programm) Presentation layer Codierung, Verschlüselung Session layer „Isar 12 bitte melden“ Transport layer Files - Pakete Network layer routing MAC layer (link layer) Physical layer Buszugriff, Busadresse Hardware Kommunikationskatalog für Simatic-SPS (na ja..) : Ethernet-IP-UDP Ethernet-IP-TCP Ethernet-IP-TCP-ISO Ethernet-IP-TCP-ISO-S7protokoll Ethernet- ISO-S7protokoll MPI-FDL- S7protokoll Profibus-FDL-FMS Profibus-FDL-DP IEC1185-FDL-PA (Profinet fehlt !) Profibus DP Layer 1 : - Toplogie (Grundlagen : Linie, Stern, Ring) Linientopologie, Segmentlänge 1200m, max. 3 Repeater max. 32 Teilnehmer, Stichleitungen max. 0,3m - Hardware, Datenformat (entspricht RS485) shielded twisted pair (130…150 Ohm) Sub-D 9-polig symetrisch +/- 5V, 390-150-390 Ohm am Komperator bis 12 Mbit/sec. 11 Bit seriell asynchron pro Byte Startbit low, Stopbit high, Parity, LSB first Layer 2 : - MAC-Verfahren Grundlagen : stochastische Verfahren – CSMA/CD deterministische Verfahren – Token passing Begriffe : aggregierte Bandbreite, Determinismus ….) Token bus, Gap update (Lücken möglich), Freitoken nach TRT Framelänge max. 255 Byte (246 Byte Data) : Startbyte Destinationadress Sourceadress Frame Control (Frage /Antwort ) Nutzdaten (Information) Hybridnetz : unterlagerter Master/Slave Slave : kein Token Master : in DP nur 1 echter Master ! (=Bussystem) Layer 3-7 : leer !! (alle Layer nur bei MAP) Layer 7 bei FMS vorhanden Bedeutung des Layer 7 in Feldbussystemen ! CRC Endbyte Profibus DP und Simatic S7 - Ursprüngliches Konzept : “dezentrale Peripherie” Bei räumlich ausgedehnten Anlagen ist die Verkabelung aller Peripherieelemente zu einer zentralen SPS aufwändig. Deshalb : Einsatz von DP-Slaves als dezentrale „Klemmenkonzentratoren“ . 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 2Draht Busleitung zum DP-Master, also der SPS. SPS (Master) DPSlave Eingänge und Ausgänge DPSlave Beispiel für DP-Slave : ET-200 Serie von Siemens Eingänge und Ausgänge Profibus DP für modulare Anlagen : i-Slaves Ziel : Einsatz von Profibus DP in dezentraler Leittechnik (Module mit eigener SPS) Problem : In Profibus DP nur 1 Master möglich (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-Ausgänge : Sie gehören 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 Wird im Slave konfiguriert i-Slave DP-Slave E A A E Wird im Master konfiguriert Wird vom BS ausgeführt konfiguriert In der Praxis : Profibus DP mit 2 Simatic S7-SPS 1. Hardwarekonfiguration : Laden des fertig konfigurierten Projekts „Muster1“ , Speichern unter einem individuellen Namen (hier : DP_Doll) : Konfigurieren der DP-Vernetzung : In der Hardwarekonfiguration der Slave-Station wird die MPI/DP-Schnittstelle auf den Profibusbetrieb konfiguriert und an das Netz angekoppelt .. ..und in den Eigenschaften als DP-Slave konfiguriert. Dann folgt die Konfiguration der Datenschnittstelle im Slave : Hier als Beispiel ein Slave-Eingang mit der Länge Wort (Adresse EW0), es folgt noch ein Ausgangswort, dann wird gespeichert : Im Menü der Hardwarekonfiguration Station speichern und übersetzen wählen. Nun die Hardwarekonfiguration der Master-Station öffnen, Und die MPI/DP-Schnittstelle auf DP schalten, am Profibus anschließen und in der Betriebsart auf DP-Master parametrieren. Speichern, dann muß die DP-Leitung sichtbar werden : Aus dem rechten Hardwarekatalog wird nun die bereits projektierte Station gewählt, das ist hier unser DP-Slave, eine 314-CPU : Draufklicken, Maus gedrückt halten und die Station nach links ans DP-Kabel anschließen : Mit Drücken auf Koppeln wird die Station angeschlossen, dann wird vor dem Speichern die Konfiguration aufgerufen und die im Slave sichtbaren Datenbereiche werden doppelgeklickt: Hier ist rechts der vorher im Slave konfigurierte Eingang zu sehen, dieser wird nun im Master als Ausgang konfiguriert, wichtig ist daß die beiden Längen übereinstimmen (hier : Wort) Fertig -> Station speichern und übersetzen Programme : Im Master soll ein Schalter gelesen werden, der Wert wird an den Slave übertragen und an ein Ventil ausgegeben. Die Peripherieverdrahtung finden sie (eigentlich) in http://portal.ts-muenchen.de : ..wobei der Master hier aber leider fehlt (er wird bei neueren Projekten nicht mehr benutzt). Die Schalter am Master liegen auf EB124, wir verwenden E 124.0 Das Programm im Master ist schnell geschrieben, wir mißachten hier allerdings die Vorschriften zur Programmstrukturierung in FB’s, die in der Dokumentation angegeben sind : Ähnlich die Programmierung des Slaves, hier können wir aus den Ventilen am Band auswählen : Der Aufruf, der im OB1 schon enthalten ist, kümmert sich um den schnellen Zähler, der später gebraucht wird, hat hier aber keine Funktion. Nun noch beide Stationen auf die SPS laden, testen ! IM ÜBUNGSTEIL : Praktikum Kommunikation mit Profibus DP Ethernet : Grundlagen Layer 1 : Toplogie : Stern, Mittelpunkt als Switch oder Hub Hardware : 4 x twisted pair (shield, screen) RJ 45 “Western” : Spielzeugstecker 100baseT : 100 Mbit/sec Layer 2 : MAC-Adresse 6 Byte CSV, hardwareabhängig Framelänge ca. 1.5 kByte (Type = SAP) CSMA/CD -> switched Ethernet stochastisch : aggregierte Bandbreite, Plug+Play Layer 3 : Routing, heute immer IP Layer 4 : TCP , UDP , RFC1006 : ISO on TCP Layer 5,6,7 : Dienste des Kommunikationsprotokolls ( z.b. S7-Protokoll) 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 auch wichtig : Windows-Rechner Layer 7 Programm nächster LSAP (Port) Layer 4 CP erster LSAP (Port) Layer 3 IP: Layer 2 MAC: 00:a0:ab:ef:1a:12 SPS_1 Layer 2 MAC: 00:ac:ff:2f:10:13 Layer 3 IP: 107.12.14.12 CP 107.12.14.11 SPS_2 MAC: 00:ba:f0:d2:12:14 IP: 107.12.14.13 Layer 4 LSAP (Port) 2000 LSAP (Port) 2000 Für die Verbindung PC -> SPS_2 gelten also folgende Kommunikationsparameter : LSAP oder SSAP (Local/Source Service Access Point) : RSAP oder DSAP (Remote/Destination Service Access Point) : SIP (Source IP-Adress) : DIP (Destination IP-Adress) : SMAC (Source MAC-Adress) : DMAC (Destination MAC-Adress) : 2001 2000 107.12.14.11 107.12.14.13 00:a0:ab:ef:1a:12 00:ba:f0:d2:12:14 Der erste SAP (Default-SAP) für S7 Verbindungen ist immer 2000, bei weiteren Verbindungen zählt das System den SAP hoch : 2001, 2002 … Der Sinn einer Layer 3 – Verbindung : 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) : Class B (erstes Byte zwischen 128 und 191) : Class C (erstes Byte zwischen 192 und 223) : erstes Byte ist Netzadresse die ersten beiden Byte sind Netzadresse 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 kürzer geschrieben, indem man einfach die Anzahl der 1-en in der netmask neben der IP-Adresse hinter einem Schrägstrich angibt : 204.66.23.2 / 24 ist z.b. eine Adresse in einem Class-C Netz Broadcast : In einem Netz können für 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 : Bock : Weizen : 182.166.17.4 / 16 182.166.18.5 / 16 182.166.18.6 / 16 Die Hosts im Weinnetz haben die Adressen : Barolo : Chianti : Brunello : 62.245.200.162 / 8 62.245.123.2 / 8 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 heißt routing-table. Routing-table von Pils : Net Netmask Gateway Interface 182.166.0.0 62.0.0.0 255.255.0.0 255.0.0.0 -182.166.0.1 eth0 eth0 erreichbare Netze deren Netmask der zuständige Router die Netzkarte Routing-table von Monika : Net Netmask 182.166.0.0 62.0.0.0 255.255.0.0 255.0.0.0 Gateway --- Interface eth0 eth1 Jetzt will Pils eine Nachricht an Weizen schicken : ping 182.166.18.6 routing-protokoll Das IP-Protokoll im Layer 3 von Pils prüft nun anhand der Routing-table, ob Weizen lokal erreichbar ist, oder ob ein Router beauftragt werden muß. Hierzu vergleicht er Zeile für Zeile, indem er die Zieladresse 182.166.18.6 mit der in der Zeile stehenden netmask bitweise parallel UND-verknüpft (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 zurück : It’s me ! Damit hat er sich verraten, weil an dem Antwortframe seine MAC dransteht. Das ARPProtokoll trägt nun den Zusammenhang IP-MAC für Weizen in eine Cache-Tabelle ein (ARPCache), so daß beim nächsten 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 prüft 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 erhält 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 binär angibt, ist das nichts besonderes : 62.245.200.163 / 29 ist kompliziert zu handhaben, im letzten Byte verläuft die Grenze. 11111000.11110101.11001000.10100 011 Netzadresse (dezimal 62.245.200.160) lautet diese IP binär Rechner Es ist auch leicht zu erkennen, wieviele Rechner dieses Subnet aufnehmen kann : Mit 3 Bit sind 8 Adressen möglich, eine davon ist die Netadress, eine der Broadcast, also sind noch 6 IP für Rechner frei. (Vermutlich wird aber noch eine davon für einen Router benötigt) kleine Übung : Teilen Sie das B-Netz 132.130.0.0 / 16 in 12 Subnetze, geben Sie für das letzte dieser 12 Netze die erste und letzte für Rechner nutzbare IP an ! (Lösung : erste IP = 132.130.176.1, letzte IP = 132.130.192.254) Wenn Sie mehr Übung brauchen, finden Sie theoretische Übungen und ein TCPIP- Praktikum auf einem lauffähigen IP-Netz mit Router unter http://onlinekurse.ts-muenchen.de Überblick : Ethernetkommunikation in der Prozessebene Im Folgenden wird eine Reihe von möglichen Realisierungen besprochen : Basiskommunikation : Hier kann mit S7-Geräten (proprietär) über verschiedene Layer4-Protokolle kommuniziert werden. TCP, UDP und ISO-on-TCP ist mit Standard-Ethernethardware möglich. Profibus DP- ähnliche Kommunikation : Profinet I/O löst mit ähnlicher Topologie (Investitionsschutz, sanfte Migration) DP ab. Deterministische Echtzeitkommunikation : Profinet IRT basiert auf (nicht billiger) Spezialhardware EtherCat arbeitet ähnlich, wegen dem Summenframeverfahren aber noch schneller Sercos als Bussystem vor allem für Antriebe hat ähnliche Eigenschaften “Objektorientierter“ Ansatz : Profinet CBA ist ein (zukunftsweisender ?) Ansatz zum Entwurf komplexer Systeme ISO-on-TCP Durch eine kleine Erweiterung in Layer 4 (TCP) wird das früher von Siemens (S5) häufig benutzte ISO-Protokoll in den modernen Kommunikationsrahmen eingebaut. Siemens nennt als größten Vorteil die Nachrichten-Orientierung dieser Protokollvariante. Das bedeutet grob, daß nicht „gesichtslose“ Frames übertragen werden, und der Empfänger 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“ veröffentlicht : RFC 1006 Layer 7 : Simatic S7 Layer 7 : Simatic S7 …. …. RFC 1006 RFC 1006 Layer 4 : TCP Layer 4 : TCP Layer 3 : IP Layer 3 : IP Layer 2 : MAC Layer 2 : MAC Layer 1 : 100baseT Layer 1 : 100baseT In der Praxis : ISO-on-TCP mit 2 Simatic S7-SPS Diese Kommunikation ist nicht so ganz einfach zu realisieren. Im Prinzip läuft es so ab : Man erzeugt mit Hilfe eines Tools von Siemens („Open Communication Wizard“) alle nötigen Kommunikationsparameter. Diese werden in den beteiligten Stationen in je einem DB gespeichert. Der Kommunikationskanal muß dann mit Hilfe eines FB geöffnet werden, weitere FB (Send und Receive) ermöglichen dann den Datenaustausch. Sie müssen das nicht selber hinkriegen, sollten aber die Struktur der Kommunikation verstanden haben. 1. Kommunikationsparameter und Bausteine einfügen : 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 können : //filer_labornetz/software/tcp_wizard.zip Geben Sie im Wizard zunächst Gerät 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 wählen Sie ISO-on-TCP : Nun gleich beide Geräte parametrieren, hier Band und Vertikalarm : Dann die nötigen 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 müssen 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 war’s, mit einigen „weiter“ und „fertig stellen“ kann man den Wizard abschließen. Nun im Simatic Manager das Projekt öffen, die erste Station (Band) anwählen, 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 : Für die Nutzung der UDT50-Daten wird nun noch ein DB50 erzeugt . Neues Objekt einfügen -> Datenbaustein : Der UDT wird (nach Doppelklick auf den DB50) eingefügt : 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. Für die Steuersignale werden Merker ab 10 benutzt, die Signale aus den Bausteinen werden im gleichen Adressbereich wie die Bausteinnummern belegt (z.b. MB63 für FB63). Verbindungsaufbau in Modul A (Band) : M10.0 startet (manuell) den Verbindungsaufbau, wird bei erfolgter Verbindung (DONE, M65.0) wieder zurückgesetzt. M10.1 zeigt dann die stehende Verbindung an. Für 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 Datenübertragung : 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 zunächst die Verbindung aufbauen : Dann am Empfänger 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 verhält 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. Profibus DP -> Profinet Profibus DP wird auf Ethernet „abgebildet“. Projektierung und Struktur genau wie bei Profibus DP (nur 1 Master) : Profibus-Master -> Profinet-Controller Profibus-Slave -> Profinet-Device i-Slave -> i-Device Einheitliche Verkabelung, alles Ethernet (100baseT) Aber : sanfte Migration der Kommunikationsstruktur (Investitionsschutz) Profinet I/O : Umfasst die in den höheren Layern Profibus-kompatiblen Datentransport-Protokolle. Transportprotokolle je nach Datentyp : Zyklische Daten (Controller/Device, wie Profibus) : - Profinet RT („Real-Time“ ) : kein Layer 3 (oh !), nur MAC, etwa 10ms Zykluszeit, Standard-Ethernethardware Azyklische Daten (Konfigurationsparameter) : - UDP/IP, niedrige Priorität bei Switch, ca. 100 ms Zykluszeit Profinet IRT (Isochronous Real Time) : Layer 2 (MAC), Zykluszeit < 1ms, Jitter < 1µs Spezialhardware nötig für Netzstruktur (siehe unten) Profinet CBA (Component based automation) : Kommunikationssystem, das auf Windows-Betriebssystemfunktionen basiert. Objektorientierter Ansatz. Hat (bis auf den Namen) nichts mit Profinet zu tun … Realisierung von Profinet IRT : Die Kommunikation in IRT ist kein Standard-Ethernet Protokoll ! Es kann nur auf Spezial-Hardware ausgeführt werden, die eine Zeitsynchrone Datenübertragung zwischen den Stationen sicherstellt. Hierzu werden alle aktiven Geräte (Teilnehmer und Switches) mit einem hochgenauen Timing-Protokoll synchronisiert. PTP : precision time protocoll PTP kann als Software realisiert die Geräte bis auf einige Microsekunden, in Hardware ausgeführt (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 Störungen können nicht auftreten. Im Standardbereich können (wenn der Switch das unterstützt) die RT-Daten priorisiert werden. Damit wird die maximale Sendelatenzzeit berechenbar -> IRT ist deterministisch ! In der Praxis : Profinet I/O mit S7 und Wago-Peripherie Dearchivieren Sie wieder das Muster.zip – Projekt aus \\filer_labornetz\STT\Musterprojekte. Dann muß in einer beliebigen Station die Profinet-Device Komponente hinzugefügt werden. Weil im Simatic Manager die Wago-Komponenten nicht enthalten sind, werden sie als Geräte-Stamm-Datei (GSD) nachinstalliert : Sie können den Datensatz von www.wago.com holen, oder aus dem Labornetz laden : \\filer_labornetz\at\wago-gsd-dateien Und dann in der Hardwarekonfig unter Extras einbinden : Nun erklären Sie die gewählte Station zum I/O-Controller, indem Sie die CPU (Steckplatz 2, dort den zweiten Eintrag X2) rechtsklicken, und „Profinet I/O-System einfügen“ wählen. Es muß dann das Profinet-„Kabel“ sichtbar werden : Nun kann man das Profinet-Device (genau wie bei DP einen Slave) an den Controller anbinden. Hierzu wählen Sie aus dem Hardware-Menü rechts aus Profinet I/O den Menüpunkt „andere Feldgeräte“, und dort das richtige Wago I/O-Device. Anklicken, Maus gedrückt halten und Gerät nach links ans Profinetkabel ziehen : Dann wählen Sie die Objekteigenschaften an. Hier können Gerätenamen und IP-Adressen (Vorsicht : muß natürlich ins Subnet vom Controller passen !) vergeben werden. Als nächstes konfiguriert man die HW-Variante des Profinet-Device. Schauen Sie auf der Baugruppe nach, welcher Schnittstellenbaustein (digitaler Ausgang) angebaut ist, und konfigurieren Sie diesen unten im Fenster in den zweiten Steckplatz. Das in der Hardware gesteckte dritte Modul (Abschlußmodul) muß in der Konfguration nicht angegeben werden. Schließlich weisen Sie einen Gerätenamen zu. Dahinter steckt mehr : es wird hier das gewünschte Device ausgewählt, falls mehrere im Netz vorhanden sind, und die IP-Adresse wird diesem Device (zusammen mit dem Gerätenamen) zugewiesen. Hierzu wählen Sie im Hardware-Konfig den Menüpunkt Zielsystem (englisch PLC für programmable logic controller) und dort den Unterpunkt Ethernet. Nachdem alles erfolgreich gespeichert wurde, kann nun die Konfiguration auf die SPS geladen werden (siehe oben, azyklische UDP-Kommunikation) Mit Hilfe der Variablenbeobachtung können Sie ihr System nun testen … IM ÜBUNGSTEIL : Praktikum : Kommunikation mit Profinet I/O Realisierung von Profinet CBA : Wesentlicher Hintergrund : Die Realisierung von Anwendungen wird in zwei Tätigkeitsgfelder aufgeteilt : A) Der Entwickler einer Automatisierungskomponente entwirft eine „Klasse“, die den Anlagenentwicklern vor Ort zur Verfügung zur Verfügung gestellt wird. Die komplexen internen Abläufe 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 können, ist ein kleiner Ausflug in die Betriebssystemtechnik nötig : In Windows 3.1 wurde von Microsoft ein Mechanismus implementiert, der objektorientierte Interaktion zwischen verschiedenen Programmen ermöglicht. (Das ist übrigens gar nicht so einfach wie es sich anhört : in einem Rechner mit nur einem Prozessor läuft zu einer Zeit natürlich nur ein Programm. Will das jetzt mit einem anderen kommunizieren, ist das Problem, daß der Partner ja gar nicht läuft. Die nötigen Mechanismen, damit das klappt, nennt man „Interprozesskommunikation“) Für den Anwender hat das den Vorteil, z.B. den Zugriff auf eine Datenbank in ein Textverarbeitungsprogramm einbauen zu können : Serienbriefe können so sehr einfach adressiert werden. Wird der Text ausgegeben, so ruft das Textprogramm automatisch die Datenbank auf und veranlasst sie, den nötigen Datensatz zu suchen und zu schicken. Microsoft hat das OLE genannt : Object Link Embedding. Die Schnittstellendefinition für 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 können : 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 Geräte der Feldebene unter Profinet CBA mit Methoden aus der PCWelt (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 (großer Rechenaufwand in der SPS ) und die Probleme, die auftreten, wenn Microsoft DCOM irgendwann nicht mehr unterstützt. 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 : FB DB DatenFB schnittstelle FB Die Komponenten (auch von verschiedenen Herstellern !) können 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. In der Praxis : Profinet CBA mit Simatic-SPS 1. Komponenten erstellen ( Tätigkeit A : Komponentenentwickler ) Wir konfigurieren im Simatic Manager eine Anordnung mit 2 Modulen, den Prozessmaster und ein Fertigungsmodul. Nach Speichern der Hardwarekonfiguration wählen wir in der Projektansicht nach Klick der rechten Maustaste auf ein Modul den Menüpunkt : 1.1 Profinet Interface erstellen : Hier wird die beschriebene Datenschnittstelle der Komponente erzeugt : Nach Hinzufügen einer „Funktion“ und umbenennen auf einen aussagefähigen Namen wird darin ein „PN-Baustein“ erzeugt, der einen Datenbaustein in der SPS darstellt : Ein-Ausgänge werden mit dem richtigen Datenformat definiert. Wenn alle nötigen Daten definiert sind, kann das Interface (der DB..) gespeichert werden. 1.2 Funktion programmieren : Nun muß die Programmfunktion erzeugt werden, die mit den Daten des vorher definierten Interface arbeitet. Hier wird z.b. ein einfacher Handshake auf Masterseite im FB210 erzeugt : Wichtig : Alle Ein-und Ausgänge der Funktion müssen unbedingt als Variablen definiert werden, damit der Baustein bibliotheksfähig wird. Stellen sie bei „Extras“ die Parameter auf „minimal“, dann ist später die Zuweisung von Werten übersichtlicher. Hier definieren Sie die Datenschnittstelle mit Varaiblen Wenn das linke Fenster fehlt, hier klicken ! Extras : BausteineinstellungenFB-Parameterminimal Da hinein wird jetzt die gewünschte Funktion programmiert … 1.3 Komponente erzeugen : Nun muß das XML-File erzeugt werden, das die CBA-Komponente beschreibt. Mit rechtem Mausklick auf die Station klicken, den Menüpunkt „Komponente erzeugen“ wählen : Hier einen Speicherort wählen. Entweder ihr Homedirectory oder irgendeinen Pfad, der für sie individuell lautet … Die Warnung zu fehlerhafter Zyklusbelastung einfach wegklicken … … das Gleiche wird mit der zweiten Station ausgeführt : 2 Komponenten sind verfügbar ! 2. Komponenten verschalten (Tätigkeit B : Anwender): Nachdem mit dem Simatic Manager alle nötigen Komponenten erzeugt sind, kann ein Verschaltungseditor die Anlage konfigurieren. Wir verwenden hier IMAP von Siemens. Starten Sie IMAP, und klicken Sie mit der rechten Maus in die Projekt-Bibliothek. Nun importieren sie nacheinander die gewünschten Komponenten, indem Sie den richtigen Pfad eingeben und das XML-File anklicken : Nun klicken Sie nacheinander die Komponenten aus der Bibliothek, die sie vernetzten wollen, und ziehen die Symbole mit der Maus auf die Fläche „Anlagenplan“ : Ordnen Sie die Symbole in der Anlagensicht ein wenig, und klicken Sie mit der rechten Maus auf jedes Symbol, um seine IP-Adresse (und damit die Festlegung, welche konkrete Station nun diese Funktion ausführen soll…) zu konfigurieren : Durch Klicken auf die Anschlüsse der Komponenten können sie nun die Vernetzung graphisch erstellen : Nun können Sie den Verbindungseditor die nötigen Daten für das Projekt generieren lassen. Hier wird nun alles erzeugt, was nötig ist um die graphisch definierten Kommunikationsverbindungen der XML-Komponenten mittels DCOM auf den beteiligten SPS auszuführen : Projekt -> generieren -> Steurungsanteil -> Alles neu Wenn alles ohne Fehlermeldung läuft, können Sie das Projekt nun auf die Anlage laden : Online -> Download alle Instanzen -> Alles IM ÜBUNGSTEIL : Übung : Überblick zu den Kommunikationsvarianten Schnittstellen von 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, wieviel … Timing : jetzt ! Für die Informationsschnittstellen an Fertigungsmodulen sind firmeninterne Standardprotokolle gebräuchlich (Standard : gleiche Schnittstelle an allen Modulen !). Funktionsbeschreibung von Kommunikationsschnittstellen mit Petrinetzen „Ein Petri-Netz ist ein mathematisches Modell von nebenläufigen Systemen. Es ist eine formale Methode der Modellierung von Systemen bzw. Transformationsprozessen.“ (Quelle : Wikipedia, siehe auch Automatentheorie und Moore-Automaten) Es besteht aus Zuständen („state“, diese sind in der Hardware durch die Ausgänge speichernder Bauteile definert) und Zustandsübergängen („transition“). Eine Marke (Punkt) definiert, ob ein Zustand aktiv oder nicht aktiv ist. Funktionsregel : Wenn alle Zustände vor einer Transition akitv sind, schaltet diese. Die Marke wandert dann auf die nachfolgenden Zustände : Zeitpunkt 1 : Zeitpunkt 2 : Um Ein- und Ausgänge deutlicher unterscheiden zu können, werden die Eingänge ohne Kreise dargestellt und an die Transition seitlich angeschrieben : A=1 A=0 B=1 B=0 (Weitere einfache Beispiele : Mausfalle …) Darauf basierend wurden SPS-Programmiersprachen entwickelt, z.B. Graph7 und Higraph von Siemens. IM ÜBUNGSTEIL : Übung : Aufgaben zum Petrinetz IM ÜBUNGSTEIL : Übung : Aufgaben zum Petrinetz - 2 Man kann damit auch die Kopplung freilaufender Anlagenteile beschreiben (später „lose Kopplung“ gennant), das sogenannte Erzeuger-Verbraucher-Problem : 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 abhängig vom Zustand des Partners erfolgen. Das minimalste Handshake-Protokol wäre ein quittiertes Start-Signal. Entwurf eines minimalen Handshakeprotokolls : 1. Welche Signale sind Eingänge und Ausgänge bei den beteiligten Geräten ? Start Modul A Modul B Acknowledge 2. Darstellung in Timing-Diagramm (I/O-Richtungs-Information geht verloren !) : Start Acknowl. 3. Realisierung des Protokolls mit Petrinetz für Gerät B : Ack = 0 Ack = 1 Start= 1 Start= 0 Beispiel : Handshakeprotokoll der digitalen Fabrik der tsm (Stand 2010): READY START AUFTR. x y ACK. BUSY (ERROR) IM ÜBUNGSTEIL : Praktikum : Handshake in der Prozessebene IM ÜBUNGSTEIL : Übung : Testfragen zur Handshakekommunikation MES-Ebene Das MES-System wandelt die Produktaufträge (Kunde oder Disposition) in auf der zur Verfügung stehenden, modularen Anlage (Prozessebene), ausführbare Fertigungsschritte um. Das MES-System reagiert im Idealfall online auf Ereignisse in der Prozessebene (Störungen aller Art) und kompensiert diese durch Änderung des Fertigungsablaufs. Das MES-System erfasst online Betriebsdaten während der Fertigung (Maschinenzeiten, Materialund Energieverbrauch usw.), fasst diese zu Betriebskenndaten KPI (key performance indicators) zusammen nd übermittelt diese an ERP zur Prozessoptimierung Das MES-System archiviert alle wichtigen Aktionen auf Prozessebene (Tag-logging), um den Prozessablauf lückenlos dokumentieren zu können Struktur eines MES-Sytems : Obwohl die in der Praxis vorkommenden MES-Syteme sehr uneinheitlich und stark dem jeweiligen Prozess angepasst sind, läßt sich doch meist eine innere Grundstruktur erkennen : ERP MES-System Manufactoring flow design Manufactoring flow planing Manufactoring flow execution Prozessebene Flow design : Abbildung der Produktion als Datenmodell : Was ist das Produkt ? Beschreibung durch Article Master Data (Stammdatensatz in ERP). Definiert wird das Produkt/Artikel (z.b. das Waschmaschinenmodell), nicht der eine Gegenstand (z.b. mit individueller Seriennummer) der vom Kunden XY bestellt wurde. Womit wird es hergestellt ? Datenmodell der Maschinen, Schnittstellen, Bedienpersonal usw. Wie wird es hergestellt ? Work plan, bill of process (Arbeitsvorschrift oder Prozessplan) Sequence numbers (Nummern der Arbeitsschritte) Was ist das Produkt ? Beispiel für eine Produktstammnummer : Womit wird es hergestellt ? Die Arbeitsprozesse (Fertigungsmodule) werden ebenfalls durch Nummern abgebildet. Hierbei können entweder Fertigungsvarianten oder andere Untergruppen gebildet werden. Wie wird es hergestellt ? Dann wird der Ablauf durch die Prozesse (Verkettung!) als Tabelle oder grafisch geplant : Work plan als Tabelle : Work Plan grafisch dargestellt : Die Festlegung der Funktionsreihenfolge innerhalb einer modularen Anlage wurde früher „Verkettung“ genannt. Dieser Begriff kommt aus dem Maschinenbau, weil ein wesentliches Teilproblem der Verkettung der Materialfluß darstellt, der mit verschiedensten Techniken realisiert wird. Verkettung nennt man dort die Verbindung der Module durch Materialtransporteinrichtungen. Für die Leittechnik bedeutet „Verkettung“ aber die Koordinierung der Modulaktionen in der Prozessebene : serielle Kopplung : Manufakturbetrieb, Herstellen von Einzelstücken parallele Kopplung : Serienbetrieb mit allen Modulen gleichzeitig, Chargenfertigung starre Kopplung : Im Parallelbetrieb werden die Module von einem gemeinsamen Anlagentakt gesteuert lose Kopplung : Die Module laufen frei ohne überlagerten Anlagentakt (Materialpuffer, Auswirkung auf Verfügbarkeit…) flexible Fertigung : Die Anlage kann ohne Umrüsten verschiedene Produkte herstellen (Variantenfertigung, angestrebt : Losgröße 1) Die Begriffe Charge und Los werden in der Literatur verschieden definiert. Im Weiteren gilt hier : Charge ist die Anzahl von Produkten, die in einem Serienlauf (Produktionsanlauf – Produktion – Produktionsauslauf) gefertigt werden Losgröße ist die Anzahl der Produkte (nacheinander innerhalb einer Charge), die identischen Aufbau haben. Moderne Anlagen sollen in loser Kopplung Losgröße 1 fahren können. Die Zuordnung der nötigen Auftragsinformation bei Losgröße 1 wird dann schwierig. -> Produktidentifikation (z.b. Barcode-Aufkleber, RFID …) oder parallele Virtualisierung. Flow planing : Die zu fertigenden Produkte werden in eine optimale Reihenfolge sequenziert. WICHTIG : Die Produktreihenfolge, nicht die der Modulaktionen (-> flow design)!! Hier sind verschiedenste Optimierungskriterien möglich : Kostenoptimierung Zeitoptimierung Ordnung nach Kundenpriorität Energieverbrauch … Der Flow plan kann sich auch dynamisch während der Laufzeit verändern, wenn z.b. Probleme in der Prozessebene auftreten (Maschinenausfall) oder durch Qualitätsmängel Nachfertigung von Produkten nötig wird. Hier ist üblicherweise ein manueller Eingriff an einer graphischen Darstellung an einem MESTerminal möglich, nötige manuelle Unterstützung zeugt aber oft von mangelhaften MESAlgorithmen. Beispiel für ein Sequenzierterminal : Flow execution : Hier werden die Vorgaben für den als flow plan geplanten Fertigungsablauf rechnergestützt umgesetzt. Programme führen die Abläufe aus und reagieren im Idealfall auf Ereignisse, die im Fertigungsablauf eintreten (Störungen). Der Ablauf der Fertigung wird auf einem MES-Terminal für den Anlagenfahrer graphisch dargestellt, und durch Rückmeldung von Anlagendaten (Betriebsdatenerfassung BDE) ständig überwacht und dokumentiert (Reports). Beispiel : Visualisierung eines Prozessablaufs : Einführung in Visual Basic : “VB classic“ VB classic ist eine Interpretersprache (Skipt-Sprache), das bedeutet, sie wird nicht übersetzt bevor man sie ausführen kann. Deshalb ist auch keine Deklaration von Variablen nötig. Der Interpreter ist Bestandteil aller Windows-Betriebssysteme. Ein VB-Skript wird einfach mit einem beliebigen Editor erstellt, name.vbs genannt (name beliebig) und durch anklicken ausgeführt. (Vorsicht beim Speichern : die meisten Editoren nennen das erstmal .txt !) Anweisung : a=b+1; a=b+c a=b–c a=b*c a=b/c Schleife : solange Bedingung gilt do while a < 0 ….. ….. loop Zählschleife : für i von 1 bis 100 for i=1 to 100 ….. ….. next Verzweigung : a>0? ja Vergleichsoperatoren : nein > < >= <= = <> if a > 0 then .…. ….. ….. else ….. ….. end if größer als kleiner als größer gleich kleiner gleich gleich ungleich Stringoperationen : Strings (und Variableninhalte) zusammenfügen : neu = “Hallo“ & name Stringanalyse : a = right (test,3) b = left (test,4) c = mid (test, 5, 3) 3 Zeichen von rechts aus test in a 4 Zeichen von links aus tes in b 3 Zeichen ab der 5-ten Stelle von test in c Ein-Ausgabe : a = InputBox(“Text zur Eingabe”) IM ÜBUNGSTEIL : Übung : Programmieren in VB classic (VB Skript) MsgBox(a) Ein Werkzeug zur komfortablen Programmierung objektorientierter Sprachen : 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 2010“) benutzt. In der Praxis : Microsoft Visual Studio 1. Visual Basic 2010 Express öffnen, Forms-Projekt anlegen : Forms-Anwendung wählen 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) können sie in den Eigenschaften einstellen, die auch über das Ansicht-Menü anzeigbar sind. Jetzt wird’s ernst. Aufgabe : in Feld 1 wird eine Zahl reingeschrieben, die soll verdoppelt und an Feld 2 ausgegeben werden, wenn man den Button drückt. Das Programm dazu schreiben sie, indem sie es an das gewünschte WindowsBedienelemente anbinden. Dieses Element (unser Button) doppelklicken sie bitte : Programmkopf Wenn sie den drücken….. ..passiert, was sie hier reinschreiben Ich lese den Wert aus Textbox1 ein (siehe Eigenschaften !), verdopple und gebe an Textbox2 aus : Wenn ich hier was schreibe, das dem Editor schon bekannt ist (das werden später auch die Methoden und Eigenschaften sein !), dann schlägt er was vor…. ..das ich dann wählen kann ! ..und so entsteht meine Lösung : Die ich ausprobiere, indem ich den „Debug“ – Modus starte : Pfeil drücken ! (mit Rechteck wieder stoppen) .. sieht dann so aus : Das wär’s. Alles speichern, und wenn sie das Programm ohne die Entwicklungsumgebung benötigen, finden Sie im Projektordner unter \bin\debug das .exe file. IM ÜBUNGSTEIL : Praktikum : Einführung in Visual Studio Zur Variablendefinition in VB : In VB classic : - Variablen werden gar nicht definiert Das geht in Skriptsprachen wie VB classic. Die Variale wird vom Interpreter erst zur Laufzeit angelegt wenn sie zum ersten mal einen Wert bekommt. In Vb .net : - Variablen im Modul („public class“) definieren, so daß sie nur innerhalb des Moduls gelten : o Private x as Variablentyp - Variablen im Modul definieren, so daß sie auch außerhalb zugreifbar sind : o Public x as Variablentyp - Variablen innerhalb einer Subroutine (private sub ..), die außerhalb nicht gelten : o Dim x as Variablentyp Objektorientierte Programmierung von MES-Kernfunktionen Zum Begriff „Objektorientierung“ : Bei der Programmierung im Industrieumfeld wird heute praktisch ausschließlich 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 dazugehörigen Programmen, die mit diesen Daten arbeiten können („Methoden“). Eine solche Struktur wird „Objekt“ genannt. Die Programme (Methoden) sind nur zur Bedienung zugänglich, ihr Code bleibt nicht sichtbar und unveränderbar. 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 für die Objekte werden „Klassen“ genannt, sie sind in einer „Klassenbibliothek“ gespeichert. Prinzipielle Vorgehensweise : - Nachschauen, welche Klasse die gewünschten Funktionen beinhaltet - Ein Objekt daraus benutzen ( „referenzieren“ oder „instanzieren“) - Die Methoden aufrufen, die Attribute benutzen Beispiel für objektorientiertes Programmieren in Visual Basic : In VB können eigene Klassen sehr einfach erzeugt werden. Damit soll hier prinzipiell gezeigt werden, wie eine objektorientierte Struktur aufgebaut ist : Erzeugen einer Klasse : class haus public name, strasse, zahl=0 sub rein() zahl=zahl+1 end sub end class HIER WIRD EINE KLASSE ERZEUGT DAS SIND ATTRIBUTE DAS IST EINE METHODE Benutzen der Klasse : set meins=new haus meins.name="daheim" meins.strasse="falter" meins.rein meins.rein MIT set …new WIRD EIN OBJEKT AUS DER KLASSE haus ERZEUGT (REFERENZIERT..) ATTRIBUTE WERDEN GESETZT METHODE rein WIRD AUFGERUFEN (Person geht rein) set deins=new haus deins.name="dort" deins.strasse="baum" usw.. msgbox meins.name msgbox meins.zahl EIN ATTRIBUT WIRD AUSGEGEBEN (Die Profis werden hier die Nase rümpfen, weil Attribute eigentlich nicht direkt zugegriffen werden sollten (private/public), sondern nur durch dafür vorgesehene Methoden. Kapselung heißt das, und es bewirkt, daß man mit den Attributen keinen Unsinn treiben kann ..) Dokumentation der Klassenbibliothek MES_2014_lib.dll : Die Funktionen sind nicht optimiert, sondern so weit wie möglich vereinfacht, um einen guten Überblick über die Grundfunktionen zu ermöglichen. Hierzu wird die Klassenbibliothek MES_2014_lib benutzt, die Objekte zur Bedienung der Peripherieschnittstellen beinhaltet. Die Klassen werden in folgender Form beschrieben : Name Name : sps_modul Attribute : ip (String) auftrag (Byte) status (String) error_type (string) Methoden : start_modul() lies_status() reset_error() Beschreibung der Attribute Beschreibung der Methoden Beispielprogramm ------------- Attribute Methoden SPS-Bedienung : Name : sps_modul Attribute : ip (String) auftrag (Byte) status (String) fehler (string) Methoden : start_modul() lies_status() ip auftrag status fehler start_modul() lies_status() IP-Adresse des Moduls (1.0.6.x) Fertigungsauftrag für Modul (Lagerwahl) Dezimalwert des Auftragbits : 1, 2, 4, usw. (jeweils nur ein Bit setzen !) Nach Initialisierung : - connected (nach Verbindungsaufbau) - not connected Nach start_modul() : - not ready (SPS läuft gar nicht) - running (Fertigungsschritt läuft) - ok (nach erfolgreichem Fertigungsschritt) - error (nach gescheitertem Fertigungsschritt) - Zulieferlager leer (Nur bei Linearmodul ! ) - Zulieferlager bestückt (Nur bei Linearmodul ! ) startet Modul mit einem Standardhandshake liest den aktuellen Betriebszustand aus dem Modul minimales Anwendungsbeispiel : Imports mes_2014_lib Public Class spstest Private vertikal As New sps_modul Private Sub Button1_Click() Handles Button1.Click vertikal.ip = "1.0.6.4" vertikal.auftrag = 2 vertikal.start_modul() Do vertikal.lies_status() Loop Until vertikal.status = "ok" End Sub End Class RFID-Bedienung : Name : rfid_controller Attribute : Busadress (Byte) Wert (Byte) status (string) Methoden : schreib_wert() lies_wert() busadress wert status Adresse des Controllers am RS485-Bus ,it den Werten 1 (linear), 2(vertikal), 3(horizontal) und 4(lager) gelesener oder zu schreibender Datenwert (ID als laufende Nummer) zeigt Verbindung (active, ok, no_tag) schreib_wert() lies_wert() schreibt Wert auf den Tag liest Wert vom Tag Anwendungsbeispiel : Imports mes_2014_lib Public Class rfidtest Private horizontall As New rfid_controller Private Sub Button1_Click() Handles Button1.Click busadress = „horizontal“ lies_wert() ‘hier muß der status ausgewertet werden ! End Sub End Class ERP-Bedienung : Name : erp_connect Attribute : id (String) teil (String) fehler(Byte) auftrag(Byte) Methoden : lies_teil() lies_fehler schreib_sc lies_sc id teil auftrag fehler sc Produkt-ID des Produkts (laufende Nummer als String) Auswahl der zu lesenden Info : unten, mitte, oben, lager Ausgabe der Variante für gewähltes Bauteil (1, 2, 3, beim lager auch 4) Ausgabe von lies_fehler : 0 –> alles ok, 1-> Auftrag nicht vorhanden Wert des Sequence-Call (1 : vorhanden, 0 : nicht vorhanden) lies_teil() liest aus ERP-Datenbank (Bestückungsliste) den Auftrag für Bauteil lies_fehler() liest aus ERP-Datenbank, ob ein Auftrag mit dieser id vorhanden (0 : kein Fehler, Teil ist in Datenbank. 1: Fehler, Teil nicht vorhanden) schreib_sc() schreibt Sequence-Call (=1) lies_sc () liest Sequence-Call entferne_sc() setzt den Sequence-Call zurück (=0) Anwendungsbeispiel : Imports mes_2014_lib Public Class erptest Private horauftrag As New erp_connect Private Sub Button1_Click() Handles Button1.Click horauftrag.id = 2 horauftrag.teil = „oben“ horauftrag.lies_teil() textbox1.text = horauftrag.auftrag End Sub End Class In der Praxis : MES-Funktion objektorientiert programmieren Wir öffnen ein neues Windows-Forms-Projekt in Visual Studio : Die oben angesprochene Klassenbibliothek MES_2014_lib binden wir ein, indem wir unter „my Projekt“ rechts im Projektmappen-Menü und Klick auf „Verweise“ im mittleren Bild den Punkt „Hinzufügen“ aktivieren : Nun muß angegeben werden, welche Bibliothek zugefügt werden soll. In unserem Fall ist der Pfad zur MES_2014_lib.dll anzugeben : Nun die Funktion des Windows-Forms : Wir wollen erreichen, daß die SPS bei Knopfdruck eine Aktion durchführt, als Auftrag geben wir einen Wert fest vor. Nach Aktion soll das Form warten, bis die SPS wieder auf „ok“ geht : Einbinden der Klassenbibliothek Imports mes_2014_lib Public Class spstest Objekt referenzieren Private vertikal As New sps_modul Private Sub Button1_Click() Handles Button1.Click vertikal.ip = "1.0.6.4" vertikal.auftrag = 2 vertikal.start_modul() Attribute setzen Do vertikal.lies_status() Methode aufrufen Loop Until vertikal.status = "ok" End Sub End Class Zum Testen muß natürlich in der Prozessebene die angesprochene SPS ein geeignetes Projekt tragen. Hierzu steht auf //r2d2/filer/stt/musterprojekte das archivierte Projekt : MES2014.zip bereit. Alle Fertigungsmodule sind hier mit einem minimalen, aber funktionsfähigen Programm und pflichtenheftkonformer Datenstruktur programmiert. Die Bedienung geht auch noch ein wenig eleganter. Eine Textbox wird in das Form eingefügt, um den Modulstatus „online“ anzuzeigen : Imports mes_2014_lib Public Class spstest Private vertikal As New sps_modul Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click vertikal.ip = "1.0.6.4" vertikal.auftrag = 2 vertikal.lies_status() TextBox1.Text = vertikal.status My.Application.DoEvents() If vertikal.status = "ok" Then vertikal.start_modul() vertikal.lies_status() TextBox1.Text = vertikal.status My.Application.DoEvents() Do vertikal.lies_status() TextBox1.Text = vertikal.status My.Application.DoEvents() Loop Until vertikal.status = "ok" End If End Sub End Class IM ÜBUNGSTEIL : Praktikum : SPS objektorientiert ansprechen Anzeigen des Modul-Status Bewirkt Anzeige bevor’s weitergeht Nur starten, wenn betriebsbereit Detail der SPS / Rechner - Schnittstelle : Eine wichtige Teilfunktion aus obigem Beispiel soll näher betrachtet werden : Leitrechner in Industrieanlagen kommunizieren wie die anderen Geräte auch immer mit Handshakeprotokollen. Zur Erinnerung : - Gerät A meldet START - Gerät B quittiert den Empfang von START mit QUITT Im Petrinetz : /Quitt Start Quitt 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 müssen wir die Funktion in einem zur Funktionsweise passenden Werkzeug beschreiben, optimal im Struktogramm. Der PC muß warten, bis das Signal des Kommunikationspartners eintrifft, indem er die Frage nach dem erwarteten Signal (hier START) immer wieder neu stellt : lies den Signalwert solange das Signal noch nicht eingetroffen ist Dieses Verfahren wird in der Informatik als „Polling“ (aktives Warten) bezeichnet. kleines Bilderrätsel zum Thema : …..was ist falsch ? IM ÜBUNGSTEIL : Übung : Kommunikation SPS <-> PC IM ÜBUNGSTEIL : Praktikum : Verkettung von Modulen der Prozessebene ERP-Ebene Ausgangsbasis für die Entstehung von ERP-Systemen (früher PPS, ProduktionsplanungsSystem oder ähnlich..) ist die Idee, alle Firmendaten in einer gemeinsamen Datenbank zu speichern. Dann werden auch Querverbindungen möglich, die vorher schwer zu realisieren waren. Beispiel : Wenn die Personaldaten und die Produktionsplanung gemeinsam zugänglich gespeichert sind, kann ohne großen Aufwand der Personaleinsatz für eine bestimmte Produktionsphase geplant werden. Die Software, die die gewünschten Aussagen aus dem Datenbestand generiert, ist meist in Module gegliedert. stark vereinfachte Übersicht : Kunden, Aufträge Finzanzen Personal SQL-Datenbank Produktion Lager, Maschinen, Gebäude Strukturbild von SAP : Entscheidend für die gute Funktionalität eines ERP-Systems ist die genaue Anpassung an die Bedürfnisse eines Betriebs, das sogenannte „Customizing“. Es werden die Module ausgewählt, die für die Geschäftsprozesse nötig sind, und diese dann an die lokalen Gegebenheiten angepasst. SAP war lange dafür berühmt, daß wichtige Funktionen sogar erst vor Ort beim Kunden programmiert worden sind. Kommunikation ERP-MES Die Schnittstelle zum ERP-System wird ausschließlich mit Rechnern realisiert. Die Kommunikationsbasis ist deshalb ein Rechnernetz, also meist Ethernet und TCP/IP. Darauf werden Middleware-Protokolle benutzt, wobei sich der moderne Standard Webservices gegen ältere Middleware wie z.b. CORBA durchgesetzt hat. In weniger technisch, eher betriebswirtschaftlich geprägten Umgebungen findet man auch EDI als Schnittstelle. Middleware-Kommunikation mit Webservices : „Ein Webservice ist ein Dienst, der über einen URL aufgerufen wird und XML-Daten liefert“ : ERP-System MES-System XMLDaten Webserver send receiv 123ad 11qwe …. Daten (z.b. SQL) receiv httpKanal RPC : remote procedure call send 123ad 11qwe Daten (z.b. CSV) Die Kommunikations – Endpunkte werden Stubs genannt. Sie sind beim Webserver meist in PHP programmiert, und werden vom Client aufgerufen : Remote procedure call (RPC). Die Stubs wandeln lokale Formate (z.b. CSV, character separated values) in das einheitliche Transportformat XML um. Dieser Vorgang wird Marshalling genannt, bzw. auf der Gegenseite Demarshalling. Als Kommunikationskanal wird HTTP benutzt, weil es weit verbreitet ist und wegen der Nutzung von Port 80 auch einfach von Firewalls zu handeln ist. HTTP : HTTP (Hypertext Transport Protocol) definiert vorrangig das Zusammenspiel von Webserver und Webbrowser im Internet. Es besteht im wesentlichen aus 4 Schritten : OPEN : der Client baut eine TCP-Verbindung zum Server auf. SEND : der Client schickt einen HTTP-Request an den Server, in dem normalerweise ein GET-Befehl beinhaltet ist, der den Server auffordert, ein Dokument zu schicken. RECEIVE : der Client empfängt den http-Response vom Server, der üblicherweise eine HTML-Seite zum Anzeigen enthält. Möglich sind hier auch Fehlermeldungen (z.b. Dokument nicht gefunden). CLOSE : der Server schließt die TCP-Session wieder Im industriellen Umfeld wird natürlich kein Browser benutzt, sondern ein Programm holt über http im Automationsablauf die Daten vom Server : B2B ( business-to-business) – Kommunikation. Größter Vorteil des http-Protokolls : Es ist ein weit verbreitetes Standardprotokoll (Web), und die Kommunikation läuft ohne Probleme auch über Firewalls, weil der Port 80 praktisch immer offen ist. Webservices ohne Browser : Da aus Programmen heraus ja nicht über einen Browser kommuniziert wird, muß ein Webservice natürlich auch direkt ansprechbar sein. Hier kann man z.b. einen Telnet-Client benutzen. In Win7 muß dieser erst aktiviert werden (Systemsteuerung / Programme und F. / Windows-Funktione aktivieren und deaktivieren). Dann gibt man die korrekte (!) URL einfach in der Kommandozeile ein. IM ÜBUNGSTEIL : Praktikum : Webservice mit telnet bedienen XML : XML (eXtensible Markup Language) wird wie alle Markup-Languages mittels Tags strukturiert. Die Tags geben quasi die Bedeutung der Inhalte vor. In XML können die Tags selber definiert werden : <Automarke> VW </Automarke> Regeln : Jedes Dokument besitzt genau ein Wurzelelement. Als Wurzelelement wird dabei das jeweils äußerste Element bezeichnet, z.B. <auftrag>. Alle Elemente mit Inhalt besitzen ein Beginn- und ein End-Tag (z. B. <eintrag>Eintrag 1</eintrag>). Als Dokumentkopf wird angegeben : <?xml version="1.0" encoding="UTF-8" ?> (Die Version 1.0 ist die aktuelle, UTF-8 ist der übliche Zeichensatz im Web) Beispiel : <?xml version="1.0" encoding="UTF-8" ?> <Chargenauftrag> <Turm1> <Teil1>1</Teil1> <Teil2>2</Teil2> </Turm1> </Chargenauftrag> IM ÜBUNGSTEIL : Ein XML-File schreiben IM ÜBUNGSTEIL : Praktikum : Aufruf eines Webservice mit Browser Ein MES-System für die digitale Fabrik der Technikerschule : ERP XML-Kommunikation objektorientiert tsMes TERMINAL Kernprogramm (Core) in VB.net ---------------------------------------------------- TCP/IP-Kommunikation objektorientiert PROZESS IM ÜBUNGSTEIL : Projekt : MES für die digitale Fabrik der tsm
