Embed Size (px)
Citation preview
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)
-> Nächster 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 !!) - Endgerät
MAP :
MAP-Bus (open system)
MMS
(wichtige Begriffe : Modularität, Protokoll, Dienst (Service-> Server), MMS )
-> Zukunft : Vereinheitlichung der Bussysteme (Ethernet ?)
CP :
MMS !!
CP
CP
Endgerät
Hersteller A
Endgerät
Hersteller B
Endgerät
Hersteller C
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 : p(gesamt) = Produkt aller p(einzel)
Parallelschaltung : q(gesamt) = Produkt aller q(einzel)
IM ÜBUNGSTEIL :
Übung : Verfügbarkeits-
berechnungen
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 Der SPS-Master bedient die Module mit den von MES
Gesichtspunkten (z.b. optimale Reihenfolge), und schickt eintreffenden Aufträgen.
Fertigungsbefehle an die Prozessebene.
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) Buszugriff, Busadresse
Physical layer 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)
CRC Endbyte
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 !
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 „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 für DP-Slave : ET-200 Serie von Siemens
SPS (Master)
Eingänge und
Ausgänge
Eingänge und
Ausgänge
DP-
Slave
DP-
Slave
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
i-Slave DP-Slave
E
A
A
E
Wird im Master
konfiguriert
Wird im Slave
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
CP SPS_1 CP SPS_2
Für 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) für S7 Verbindungen ist immer 2000, bei weiteren Verbindungen
zählt das System den SAP hoch : 2001, 2002 …
Programm
Layer 4
Layer 3
Layer 7 nächster LSAP (Port)
erster LSAP (Port)
IP: 107.12.14.11
MAC: 00:ba:f0:d2:12:14
Layer 2
LSAP (Port) 2000 LSAP (Port) 2000
MAC: 00:a0:ab:ef:1a:12
IP: 107.12.14.12
Layer 2
Layer 3
Layer 4
IP: 107.12.14.13
MAC: 00:ac:ff:2f:10:13
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) : 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 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 : 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 heißt 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 zuständige 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 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 ARP-
Protokoll trägt nun den Zusammenhang IP-MAC für Weizen in eine Cache-Tabelle ein (ARP-
Cache), 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 lautet diese IP binär
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 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
…. ….
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
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 Text-
verarbeitungsprogramm 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 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 (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 :
DB
Daten-
schnittstelle
FB
FB
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.
Da hinein wird jetzt die gewünschte Funktion programmiert …
Hier definieren Sie die
Datenschnittstelle
mit Varaiblen Wenn das linke Fenster fehlt,
hier klicken !
Extras :
Bausteineinstellungen-
FB-Parameter-
minimal
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 :
Die Warnung zu fehlerhafter Zyklusbelastung einfach wegklicken …
… das Gleiche wird mit der zweiten Station ausgeführt : 2 Komponenten sind verfügbar !
Hier einen Speicherort wählen.
Entweder ihr Homedirectory
oder irgendeinen Pfad, der für
sie individuell lautet …
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 Kommunikations-
verbindungen 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 :
B = 1 B = 0
(Weitere einfache Beispiele : Mausfalle …)
Darauf basierend wurden SPS-Programmiersprachen entwickelt, z.B. Graph7 und Higraph
von Siemens.
Man kann damit auch die Kopplung freilaufender Anlagenteile beschreiben (später „lose
Kopplung“ gennant), das sogenannte Erzeuger-Verbraucher-Problem :
A = 0 A = 1
IM ÜBUNGSTEIL :
Übung : Aufgaben zum
Petrinetz
IM ÜBUNGSTEIL :
Übung : Aufgaben zum
Petrinetz - 2
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 ?
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 für Gerät B :
Start= 1 Start= 0
Beispiel : Handshakeprotokoll der digitalen Fabrik der tsm (Stand 2010):
READY
START
AUFTR. x y
ACK.
BUSY
(ERROR)
Ack = 0 Ack = 1
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, Material-
und 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
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)
MES-System
Manufactoring
flow
design
Manufactoring
flow
planing
Manufactoring
flow
execution
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 Material-
transporteinrichtungen.
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 MES-
Terminal möglich, nötige manuelle Unterstützung zeugt aber oft von mangelhaften MES-
Algorithmen.
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 + c
a = b – c
a = b * c
a = b / c
Schleife : do while a < 0
…..
…..
loop
Zählschleife : for i=1 to 100
…..
…..
next
solange Bedingung gilt
a = b + 1 ;
für i von 1 bis 100
Verzweigung : a > 0 ? if a > 0 then
ja nein .….
…..
…..
else
…..
…..
end if
Vergleichsoperatoren : > 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) 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
Ein-Ausgabe :
a = InputBox(“Text zur Eingabe”) MsgBox(a)
IM ÜBUNGSTEIL :
Übung : Programmieren in
VB classic (VB Skript)
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 Windows-
Bedienelemente 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 :
..und so entsteht meine Lösung :
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 !
Die ich ausprobiere, indem ich den „Debug“ – Modus starte :
.. 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.
Pfeil drücken !
(mit Rechteck wieder stoppen)
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 HIER WIRD EINE KLASSE ERZEUGT
public name, strasse, zahl=0
sub rein() DAS SIND ATTRIBUTE
zahl=zahl+1 DAS IST EINE METHODE
end sub
end class
Benutzen der Klasse :
set meins=new haus MIT set …new WIRD EIN OBJEKT AUS DER KLASSE haus
meins.name="daheim" ERZEUGT (REFERENZIERT..)
meins.strasse="falter"
meins.rein ATTRIBUTE WERDEN GESETZT
meins.rein METHODE rein WIRD AUFGERUFEN (Person geht rein)
set deins=new haus
deins.name="dort"
deins.strasse="baum"
usw..
msgbox meins.name EIN ATTRIBUT WIRD AUSGEGEBEN
msgbox meins.zahl
(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
Attribute
Methoden
Beschreibung der Attribute
Beschreibung der Methoden
Beispielprogramm
-------
-------
Name : sps_modul
Attribute : ip (String)
auftrag (Byte)
status (String)
error_type (string)
Methoden : start_modul()
lies_status()
reset_error()
SPS-Bedienung :
ip IP-Adresse des Moduls (1.0.6.x)
auftrag Fertigungsauftrag für Modul (Lagerwahl)
Dezimalwert des Auftragbits : 1, 2, 4, usw. (jeweils nur ein Bit setzen !)
status 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)
fehler - Zulieferlager leer (Nur bei Linearmodul ! )
- Zulieferlager bestückt (Nur bei Linearmodul ! )
start_modul() startet Modul mit einem Standardhandshake
lies_status() 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
Name : sps_modul
Attribute : ip (String)
auftrag (Byte)
status (String)
fehler (string)
Methoden : start_modul()
lies_status()
RFID-Bedienung :
busadress Adresse des Controllers am RS485-Bus ,it den Werten
1 (linear), 2(vertikal), 3(horizontal) und 4(lager)
wert gelesener oder zu schreibender Datenwert (ID als laufende Nummer)
status zeigt Verbindung (active, ok, no_tag)
schreib_wert() schreibt Wert auf den Tag
lies_wert() 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
Name : rfid_controller
Attribute : Busadress (Byte)
Wert (Byte)
status (string)
Methoden : schreib_wert()
lies_wert()
ERP-Bedienung :
id Produkt-ID des Produkts (laufende Nummer als String)
teil Auswahl der zu lesenden Info : unten, mitte, oben, lager
auftrag Ausgabe der Variante für gewähltes Bauteil (1, 2, 3, beim lager auch 4)
fehler Ausgabe von lies_fehler : 0 –> alles ok, 1-> Auftrag nicht vorhanden
sc 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
Name : erp_connect
Attribute : id (String)
teil (String)
fehler(Byte)
auftrag(Byte)
Methoden : lies_teil()
lies_fehler
schreib_sc
lies_sc
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 :
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
Einbinden der Klassenbibliothek
Objekt referenzieren
Attribute setzen
Methode aufrufen
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
Anzeigen des Modul-Status
Bewirkt Anzeige bevor’s weitergeht
Nur starten, wenn betriebsbereit
IM ÜBUNGSTEIL :
Praktikum : SPS
objektorientiert ansprechen
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 :
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 müssen 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 Bilderrätsel zum Thema :
…..was ist falsch ?
solange das Signal noch
nicht eingetroffen ist
lies den
Signalwert
IM ÜBUNGSTEIL :
Praktikum : Verkettung von
Modulen der Prozessebene
IM ÜBUNGSTEIL :
Übung : Kommunikation
SPS <-> PC
ERP-Ebene
Ausgangsbasis für die Entstehung von ERP-Systemen (früher PPS, Produktionsplanungs-
System 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
Lager,
Maschinen,
Gebäude
Personal
Produktion
SQL-Datenbank
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“ :
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.
ERP-System
Daten (z.b. SQL)
MES-System
Daten (z.b. CSV)
Webserver
123ad
11qwe
….
receiv
send
send
receiv http-
Kanal
RPC :
remote
procedure
call
XML-
Daten
123ad
11qwe
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 :
Praktikum : Aufruf eines
Webservice mit Browser
IM ÜBUNGSTEIL :
Ein XML-File schreiben
Ein MES-System für die digitale Fabrik der Technikerschule :
XML-Kommunikation
objektorientiert
Kernprogramm
(Core) in VB.net
TERMINAL
TCP/IP-Kommunikation
objektorientiert
PROZESS
tsMes
ERP
------------------
------------------
------------------
IM ÜBUNGSTEIL :
Projekt : MES für die
digitale Fabrik der tsm
