Ethernet-Anschaltung von Siemens-SPSen mit dem Industrial Ethernet Powerpack - Warum braucht man es? Wie funktioniert es? Was bringt es?
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Langner Communications Whitepaper
Ethernet-Anschaltung von
Siemens-SPSen mit dem
Industrial Ethernet Powerpack
Warum braucht man es?
Wie funktioniert es?
Was bringt es?Copyright © 2004 Langner Communications AG, Eulenkrugstr. 27, D-22359 Hamburg Alle Rechte vorbehalten. Langner, LUCA, i-Plant, das i-Plant-Logo, P2B, FactoryXML und das FactoryXML-Logo sind eingetragene Marken von Langner Communications AG. Step7, Simatic und WinCC sind eingetragene Marken von Siemens AG. InTouch ist eine eingetragene Marke von Invensys. Über Langner Communications Langner Communications AG ist Hersteller der Middleware i-Plant für die produktionsnahe IT. Das 1988 gegründete Softwarehaus hat seinen Firmensitz in Hamburg und betreut über 3000 Kunden in Europa, den USA, und Asien. Durch die konsequente Fokussierung auf automatisierte Meldesysteme speziell im industriellen Umfeld ist Langner Communications einer der international anerkannten Technologieführer auf diesem Sektor. Zahlreiche namhafte Softwarehersteller nutzen OEM-Softwarekomponenten von Langner Communications in ihren eigenen Produkten. Weitere Informationen über Langner Communications finden Sie im Internet unter www.langner.com. Weitere Informationen über i-Plant finden Sie unter www.factoryxml.com. Industrial Ethernet Powerpack (Übersicht) Seite 2 Copyright © 2004 Langner Communications AG Alle Rechte vorbehalten
Inhalt
Industrial Ethernet für die IT-Integration: "Ja, aber!" ....................................................................................4
Problem Nummer Eins: Überhöhte Netzlast und schlechte Performance ................................................4
Problem Nummer Zwei: Unvollständige und inkonsistente Daten...............................................................4
Problem Nummer Drei: Fehlender Schutz vor Datenverlusten bei Leitungsstörungen ........................5
Wie funktioniert das Industrial Ethernet Powerpack?...................................................................................5
Aktives zyklisches Senden ohne Abfrage durch den PC................................................................................5
Einrichten eines Backlog-Speichers auf der SPS .............................................................................................6
Ereignisgesteuertes Senden....................................................................................................................................6
Verbindungsüberwachung per "Heartbeat".........................................................................................................6
Hintergründe zu Performance und Netzbelastung .........................................................................................6
ISO-on-TCP oder UDP für die Send-Verbindung? ...........................................................................................6
Protokoll-Overhead im Vergleich............................................................................................................................7
Benchmarks...................................................................................................................................................................7
Produktübersicht Industrial Ethernet Powerpack...........................................................................................8
Voraussetzungen.........................................................................................................................................................8
Industrial Ethernet Powerpack (Übersicht) Seite 3
Copyright © 2004 Langner Communications AG Alle Rechte vorbehaltenIndustrial Ethernet für die IT-Integration: "Ja, aber!"
Industrial Ethernet ist das ideale Medium zur Anbindung von IT-Anwendungen an SPSen, was sich nicht zuletzt auch in stark
steigenden Installationszahlen dieser Anschalttechnik niederschlägt. Siemens bietet für die S7-Reihe hierfür die beiden CPs
343 und 443 an. Diese CPs bieten dem Automatisierungstechniker unterschiedliche Übertragungsverfahren für die
Datenübertragung, wie man sie ähnlich auch von PROFIBUS und Punkt-zu-Punkt-Schnittstellen kennt. Leider sind die
angebotenen Protokollvarianten für das Medium Ethernet jedoch ungeeignet, wenn sie – was nahe liegt – genau so
verwendet werden wie bei PROFIBUS und RS-232. Dafür gibt es einen einfachen Grund.
• Ethernet geht von einer meldebasierten Datenübertragung aus und verwendet für die Koordination des Buszugriffs das
sogenannte CSMA/CD-Verfahren (Carrier Sense Multiple Access with Collision Detection). Dieses Verfahren ermöglicht
den konkurrenten Buszugriff aller Stationen und geht von der Annahme aus, dass eine Station den Bus nur dann
benutzt, wenn tatsächlich Informationen zu übertragen sind. Versuchen zwei oder mehr Stationen gleichzeitig zu
senden, kommt es zu einer sogenannten Kollision, die zu einem Datenverlust führt. Die Kollision wird von den
sendenden Stationen erkannt und bewirkt einen erneuten Sendeversuch. Um Deadlock-Situationen zu vermeiden, wird
vor dem erneuten Sendeversuch eine zufallsgesteuerte Verzögerung (von einigen Millisekunden) abgewartet.
Kollisionen beeinträchtigen somit nicht die Datenintegrität, sondern die effektive Übertragungsgeschwindigkeit am Bus.
• Im Unterschied zu Ethernet verwenden die meisten Feldbusse (wie z. B. PROFIBUS) ein Busmaster-Zugriffsverfahren,
bei dem eine Station (der Busmaster) alle anderen Stationen (die Slaves) zyklisch abfragt. Ein spontaner Buszugriff der
Slaves ist nicht vorgesehen, da nicht von einer meldebasierten Datenübertragung ausgegangen wird, sondern von
einem kontinuierlichen Speicherzugriff. Kollisionen sind bei diesem Verfahren unmöglich, und die effektive
Übertragungsgeschwindigkeit am Bus variiert nicht – sie ist deterministisch. Der Preis hierfür ist eine vergleichsweise
unökonomische Ausnutzung der Bandbreite des Mediums: Daten werden auch dann übertragen, wenn überhaupt keine
neue Information vorliegt (wenn sich also z. B. der Wert einer bestimmten Prozessvariablen gar nicht geändert hat). Im
Vergleich hierzu wirkt ein konkurrentes Zugriffsverfahren wie eine Art Online-Datenkompression.
• Auch bei den klassischen Punkt-zu-Punkt-Schnittstellen (z. B. PG-Schnittstelle) sind Polling-Verfahren üblich – der PC
fragt ständig die Datenbausteine ab, an deren Inhalt er interessiert ist. Im Hinblick auf die Bandbreite des Mediums ist
das in diesem Fällen unerheblich, da eine Punkt-zu-Punkt-Schnittstelle ohnehin exklusiv genutzt wird und eine
Reduzierung des Datenvolumens keinen Nutzen bringt.
Industrial Ethernet ist ein vergleichsweise junges Medium. Daher war es naheliegend, die für Punkt-zu-Punkt-Schnittstellen
und für Feldbusse bereits implementierten und bewährten Protokolle und Verfahren unmodifiziert zu übernehmen. Wie
andere Hersteller von SPSen auch, ist Siemens diesen Weg gegangen. Die Folge davon ist, dass die IT-Anbindung von
SPSen über Industrial Ethernet mit den von Siemens nahe gelegten Verfahren unbefriedigend sind.
Die bislang überwiegend praktizierte Verwendung althergebrachter SPS-Zugriffsmethoden über Industrial Ethernet kommt
einem Sportwagen gleich, der nur im ersten Gang mit angezogener Handbremse gefahren wird. Eine intelligente
Kombination der von Siemens bereit gestellten Verfahren ermöglicht es jedoch, die Effizienz einer Industrial-Ethernet-
Anschaltung drastisch zu erhöhen. Genau dazu dient das Industrial Ethernet Powerpack.
Problem Nummer Eins: Überhöhte Netzlast und schlechte Performance
Eine IT-Anwendung greift auf eine S7 mit Ethernet-CP fast immer über zwei Verfahren zu: Entweder über die sogenannten
S7-Funktionen ("PG-Schnittstelle über Ethernet") oder über das sogenannte Fetch/Write-Protokoll (auch als "S5-
Datenübertragung" bekannt). Bei beiden Verfahren werden kontinuierlich in einer Schleife diejenigen Operanden (DBs,
Zähler, Merker usw.) abgefragt, an denen die IT-Anwendung interessiert ist. Die Folge davon ist ein kontinuierlicher
Datenverkehr, der den Bus für andere Stationen sperrt. Es ist leicht vorstellbar, wie drastisch die effektive
Übertragungsgeschwindigkeit am Bus sinkt, wenn auf diese Weise zehn oder hundert SPSen angesprochen werden. Das
unbefriedigendste dabei: Zwischen 50 und 99% der Abfragen wären gar nicht erforderlich, weil sie ohnehin redundante
Daten liefern. In der Regel wird ja doppelt so schnell wie die Taktzeit gelesen, um nur keine Datenänderungen zu verpassen.
Problem Nummer Zwei: Unvollständige und inkonsistente Daten
Für eine Prozessvisualisierung stellt sich die Entwicklung von Prozessvariablen kontinuierlich dar. Entscheidend für die
Brauchbarkeit der von der Steuerung gelesenen Daten ist hier das Intervall (je kleiner, desto akkurater), nicht aber der
Industrial Ethernet Powerpack (Übersicht) Seite 4
Copyright © 2004 Langner Communications AG Alle Rechte vorbehaltenexakte Zeitpunkt des Datenzugriffs. Prozessvisualisierungen sind jedoch im modernen Produktionsumfeld nur eine von
mehreren Anwendungen, die an den Daten der Steuerung interessiert sind. Für andere Anwendungen ist der "richtige"
Zeitpunkt des Datenzugriffs sehr wohl entscheidend.
• Beispiel 1: Eine QS-Anwendung benötigt von jedem gefertigten Produkt das Ergebnis der Qualitätsprüfung, zusammen
mit den zugehörigen Messwerten. Diese Daten entstehen jeweils am Ende des Taktes, wobei die Taktzeit natürlich
variiert. Das Taktende bzw. Ausfahren des Produkts aus der Station ist der SPS bekannt, der QS-Anwendung jedoch
nicht. Beim Abfrageverfahren muss die QS-Anwendung auf jeden Fall öfter pro Zeiteinheit lesen als die kleinstmögliche
Taktzeit. Bei dokumentationspflichtigen Daten wird sich nicht jeder mit einem derartigen blinden "Herumstochern"
anfreunden können.
• Beispiel 2: Eine BDE-Anwendung überwacht den Auftragsfortschritt und benötigt unbedingt den "letzten" Datensatz vor
Los- bzw. Chargenwechsel. Wann dieser Wechsel erfolgt, ist aber der BDE-Anwendung in der Regel nicht bekannt; der
SPS hingegen sehr wohl. Die BDE-Anwendung hat beim Abfrageverfahren also wieder nur die Möglichkeit, "schnell
genug" zu lesen, um nur nicht den "letzten" Datensatz zu verpassen. Genau genommen muss exakt zwischen dem
letzten Datensatz des aktuellen Loses und vor dem ersten Datensatz des nächsten Loses gelesen werden. Gerade bei
Daten, die sich extrem selten (einige Male pro Schicht) ändern, ist dies absolut unbefriedigend.
Mit dieser fehlenden zeitlichen Koordinierung hängt auch das Problem des konkurrenten Speicherzugriffs zusammen. Die
SPS-CPU kann den Inhalt eines Datenbausteins ändern, während der PC gerade einen Lesevorgang durchführt (die von
Siemens hierfür angebotene Abhilfe mit AG_LOCK ist leider nicht immer praktikabel). Die Folge hiervon können
Dateninkonsistenzen sein, sofern nicht gerade Prozessdaten übertragen werden. Beispiel: Wenn bei obigem Loswechsel der
Datenbaustein, welcher Losnummer, Sollmenge, Gutmenge und Ausschuss enthält, gerade in dem Moment vom PC
gelesen wird, in dem die CPU Gutmenge und Ausschuss nullt (die anderen Daten jedoch bereits gelesen wurden), dann
entsteht ein verfälschter Datensatz.
Problem Nummer Drei: Fehlender Schutz vor Datenverlusten bei Leitungsstörungen
Ein MPI-Kabel zwischen PC und S7 ist in der Regel nur wenige Meter lang. Ein Produktionsnetzwerk mit Industrial Ethernet
ist demgegenüber wesentlich länger und komplexer (zwischengeschaltete Hubs, Switches, Router usw.). Allein durch diese
Komplexität und Länge ist die Wahrscheinlichkeit von Leitungsstörungen durch gezogene Kabel usw. wesentlich höher als
bei anderen Anschaltvarianten. Die Praxis bestätigt dies. Da die Komplexität des Netzwerks höher ist, dauert auch die
Fehleranalyse und somit die Fehlerbehebung länger – ein bis zwei Stunden sind nicht unüblich. IT-Anwendungen, die den
SPS-Zugriff mit den landläufigen Brot-und-Butter-Verfahren vornehmen, haben für den Zeitraum einer
Verbindungsunterbrechung einen nicht wiederherstellbaren Datenverlust. Das mag für Prozessdaten und
Prozessvisualisierungen zu verschmerzen sein, für buchungspflichtige Daten ist es hingegen völlig inakzeptabel.
Alle oben genannten Probleme können technisch gelöst werden, und zwar mit der Standard-Hardware von Siemens und mit
Standard-PCs. Genau dies macht das Industrial Ethernet Powerpack.
Wie funktioniert das Industrial Ethernet Powerpack?
Aktives zyklisches Senden ohne Abfrage durch den PC
Architekturen, die zwangsläufig einen zyklischen Datenaustausch zwischen SPS und PC voraussetzen, können durch eine
einfache Modifikation bereits drastisch verbessert werden. Diese Modifikation besteht darin, dass die SPS selbsttätig die
vom PC benötigten Daten absendet, ohne hierfür für jeden Sendevorgang von der IT-Anwendung aufgefordert zu werden.
Die Vorteile:
• Sämtliche Abfragen seitens des PCs (Fetch-Telegramme) entfallen
• Der Protokoll-Overhead des Fetch-Rücksendetelegramms entfällt
• Die Datenkonsistenz ist gewährleistet, da kein konkurrenter Speicherzugriff erfolgt
Industrial Ethernet Powerpack (Übersicht) Seite 5
Copyright © 2004 Langner Communications AG Alle Rechte vorbehaltenEinrichten eines Backlog-Speichers auf der SPS
Ein SPS-Programm, welches Daten sendet, kann die zu sendenden Daten auch zusätzlich in einem Pufferspeicher
(Backlog) sichern. Hierzu ist nur ein einfacher Kopiervorgang nötig.
Die Vorteile:
• Die IT-Anwendung kann durch Leitungsstörungen oder anderweitig verlorene Datensätze wiederherstellen
Ereignisgesteuertes Senden
Wenn Daten nicht der Natur der Sache nach zyklisch benötigt werden, sondern in unregelmäßigen Abständen anfallen, dann
ist eine ereignisgesteuerte Datenübertragung die einzig fachgerechte Implementierung. Der Unterschied zum bisher
erläuterten Verfahren besteht darin, dass das SPS-Programm den Sendeaufruf nicht in jedem Zyklus tätigt, sondern
kriterienbasiert (Beispiel: Loswechsel).
Die Vorteile:
• Das Datenvolumen wird drastisch reduziert, wodurch sich die effektive Bandbreite des Netzwerksegments drastisch
erhöht
• Die Datenübertragung findet zum "richtigen" Zeitpunkt statt; ständiges "Danebengreifen" der IT-Anwendung entfällt
Verbindungsüberwachung per "Heartbeat"
Bei Umstellung der Datenübertragung auf eine ereignisgesteuerte Logik entfallen zyklische Benachrichtungen seitens der
Steuerung. Es kann dann durchaus Situationen geben (zum Beispiel bei reinen BDE-Anschaltungen), in denen von der SPS
nur noch wenige Male pro Schicht überhaupt Daten übertragen werden. Für die IT-Anwendung ergibt sich nun die Frage, ob
das Ausbleiben von Telegrammen "richtig" ist oder auf eine unterbrochene Verbindung hinweist. Ein Problem bei
Verwendung von TCP/IP besteht darin, dass die Kommunikationspartner einen Verbindungsverlust – wie er z. B. durch ein
gezogenes Kabel entsteht – nicht immer automatisch erkennen können. Zweifellos ist dies für die Automatisierungstechnik
ein unbefriedigender Zustand. Die Abhilfe lautet hierfür: Wenn für einen bestimmten Zeitraum keine Sendepakete anliegen,
wird stattdessen ein leeres Telegramm geschickt, anhand dessen die Gegenstelle feststellen kann, dass die Verbindung
noch existiert. Kommen innerhalb des festgelegten Zeitraums keine Telegramme an, ist von einer gestörten Verbindung
auszugehen.
Die Vorteile:
• Automatisches Erkennen einer Leitungsstörung
• Automatisches Umschalten auf eine Backup-Verbindung möglich
Hintergründe zu Performance und Netzbelastung
ISO-on-TCP oder UDP für die Send-Verbindung?
Siemens-CPs geben Ihnen für die Send/Receive-Schnittstelle grundsätzlich die Wahl zwischen einer ISO-on-TCP-
Verbindung und UDP (User Datagram Protocol). Beide Protokollarten sind wenig verstanden, weshalb wir hier die
wichtigsten Charakteristika aufführen:
• ISO-on-TCP – manchmal auch als RFC1006 bezeichnet – ist eine Protokollschicht oberhalb von TCP (Transmission
Control Protocol), die nur zur Paketierung der Daten dient. TCP für sich genommen arbeitet datenstromorientiert, so
dass der Empfänger bei alleiniger Verwendung von TCP nicht erkennen kann, wo ein Datensatz (Telegramm,
Datenbaustein usw.) beginnt und wo er endet. TCP allein ist somit für die SPS-Ankopplung ungeeignet. Das überlagerte
RFC1006-Protokoll stellt die Paketierung her, so dass der Empfänger eindeutig erkennen kann, wo ein Telegramm
beginnt und wo es endet.
• UDP liegt auf derselben Protokollschicht wie TCP und kann damit als TCP-Ersatz verwendet werden. Anders als TCP
ist UDP bereits paketierend, so dass eine weitere Protokollschicht wie RFC1006 unnötig ist. Ein weiterer Unterschied zu
TCP besteht allerdings darin, dass UDP keine integrierte Fehlerkorrektur verwendet, sondern lediglich über eine
Fehlererkennung verfügt. In der Praxis bedeutet dies, dass die Datenpakete, die der Empfänger über UDP erhält, nicht
Industrial Ethernet Powerpack (Übersicht) Seite 6
Copyright © 2004 Langner Communications AG Alle Rechte vorbehaltenverfälscht sein können. Leitungsstörungen führen jedoch dazu, dass Datenpakete "verloren" gehen. Ausserdem können
Daten bei UDP auch in der "falschen" Reihenfolge eintreffen, und es kann zu Verdopplungen von Datenpaketen
kommen. Innerhalb des Industrial Ethernet Powerpacks sind dies keine wirklichen Probleme, da diese Situationen durch
den Sequenzzähler und den Backlog abgefangen werden.
Ein wichtiges Argument für den Einsatz von UDP anstelle von ISO-on-TCP ist die aufgrund des geringeren Protokoll-
Overheads wesentlich höhere Performance. Details hierzu werden weiter unten deutlich. Da die prinzipiellen UDP-Nachteile
mit dem Industrial Ethernet Powerpack umgangen werden können, empfiehlt sich grundsätzlich die Bevorzugung von UDP
anstelle von ISO-on-TCP.
Protokoll-Overhead im Vergleich
Mit dem Industrial Ethernet Powerpack hat der Benutzer unterschiedliche Protokollvarianten zur Verfügung, um Daten von
der SPS zu übertragen. Die verfügbaren Protokollvarianten unterscheiden sich erheblich im Hinblick auf Ihre Performance.
Alle hier betrachteten Protokolle verwenden dasselbe Basismedium (Ethernet mit IP), haben jedoch unterschiedlich große
Protokollrahmen und ggf. Quittungsmeldungen, welche die Datenmenge pro Transaktion wesentlich beeinflussen.
Im folgenden ist der Protokoll-Overhead (Header, Trailer und eventuell Quittungspaket) für die einzelnen Protokollvarianten
aufgelistet. Die IP-Schicht sowie die Ethernet-Schicht wurde dabei nicht berücksichtigt, da sie für alle Protokollvarianten
identisch ist.
F et ch üb er ISO - o n- T C P 79
F et ch üb er T C P 72
S7- V er b ind ung 67
I EP Send üb er ISO - o n- T C P 47
I EP Send üb er U D P 12
0 10 20 30 40 50 60 70 80 90
Pr o t o ko l l o ver head p r o T r ansakt i o n i n B yt e
(Hohe Wert e signalisieren schlecht e Perf ormance)
Benchmarks
Es ist selbstverständlich zu erwarten, dass die Verwendung von Protokollen mit höherem Overhead in einer schlechteren
Performance niederschlagen. Wir haben darauf hin die unterschiedlichen Verbindungsvarianten getestet und die
Performance gemessen. Alle Messungen wurden mit folgender Umgebung vorgenommen:
• S7-312 mit CP343
• 10 Mbit/s Ethernet mit Kreuzverkabelung zum PC (keine weiteren Stationen im Netz)
• Windows-PC mit AMD Athlon 1.2 GHz
Zum Testen der Send-Verbindung wurde auf der SPS in jedem Zyklus die Funktion IEPSendCyclic aus dem Industrial
Ethernet Powerpack mit einem Sendeinvervall von Null Millisekunden (also ohne Verzögerung) aufgerufen.
Zum Testen der Fetch-Verbindungen und der S7-Verbindung wurde ein Testprogramm verwendet, welches mit der
Komponentenbibliothek LUCA erstellt wurde.
Industrial Ethernet Powerpack (Übersicht) Seite 7
Copyright © 2004 Langner Communications AG Alle Rechte vorbehaltenBei diesem Testaufbau ging es darum, die Effizienz der unterschiedlichen Übertragungsverfahren zu vergleichen, indem die
maximal übertragbare Anzahl Datenwörter pro Sekunde ermittelt wurde. Die Ergebnisse sind in folgender Grafik dargestellt.
9000
6500
2200 2100 2100
IEP Send über UDP IEP Send über ISO-on- S7-Verbindung Fetch über TCP Fetch über ISO-on-
TCP TCP
Anzahl übertragener Datenworte pro Sekunde
(Hohe Werte bedeuten gute Performance)
Die Ergebnisse lassen sich wie folgt zusammenfassen:
• Das Senden per UDP zeigt erwartungsgemäß die höchste Performance. Diese Variante ist über viermal schneller als
die Abfrageverfahren (Fetch/Write und S7-Verbindung).
• Das Senden per ISO-on-TCP ist erwartungsgemäß weniger performant als UDP. Die Gründe hierfür liegen in dem
höheren Protokolloverhead und in der Tatsache, dass jedes Paket von der Gegenstelle bestätigt werden muss
(Turnaround-Overhead). Trotzdem ist diese Variante immer noch etwa dreimal schneller als die Abfrageverfahren.
• Die Abfrageverfahren sind erwartungsgemäß deutlich langsamer als die meldebasierten Verfahren. Ein Grund hierfür ist
neben dem erwähnten Protokolloverhead die Tatsache, dass der CP für die Bearbeitung einer Fetch-Anfrage eine
Latenzzeit von ca. 200 Millisekunden benötigt.
• Der ca. zehnprozentige Protokolloverhead von Fetch über ISO-on-TCP gegenüber Fetch über TCP fällt nicht messbar
ins Gewicht. Dennoch erhöhen die zusätzlich (und unnötig) übertragenen Protokolldaten natürlich die
Netzwerkbelastung und somit die Häufigkeit von Kollisionen, weshalb wir nochmals davon abraten, Fetch über eine
ISO-on-TCP-Verbindung zu projektieren.
Produktübersicht Industrial Ethernet Powerpack
Das Industrial Ethernet Powerpack besteht aus Step7-Funktionen für die Datenübertragung und aus einem OPC-Server als
Gegenstück für die PC-Seite. Auf der Produkt-CD finden Sie ausserdem noch mehrere Beispielprojekte, in denen die
Benutzung der einzelnen Funktionen veranschaulicht wird.
Auf der Produkt-CD befindet sich ausserdem noch eine Demo-Version der proprietären Treiberbibliothek LUCA sowie eine
Demo-Version des Produkts PowerOPC Client Developer. Beide Produkte sind interessant für Softwareentwickler, die aus
selbst erstellten Anwendungen mit S7-Steuerungen Daten austauschen wollen.
Voraussetzungen
Steuerungsseitig benötigen Sie eine S7-300 oder S7-400 mit Ethernet-CP 343 oder 443. Der CP muss TCP/IP unterstützen.
Bitte beachten Sie, dass die erste Baureihe der CPs 343 und 443 nicht TCP/IP, sondern nur die ISO-Protokolle unterstützte.
Zur Inbetriebnahme des mitgelieferten OPC-Servers benötigen Sie einen Windows-PC.
Industrial Ethernet Powerpack (Übersicht) Seite 8
Copyright © 2004 Langner Communications AG Alle Rechte vorbehaltenSie können auch lesen
