DesignSpark Electrical Logolinkedin
Menu Suche
Ask a Question

19 Jun 2019, 9:55

Klassische Automatisierung trifft auf die fremde Welt der IT: Teil 2

In Teil 1 habe ich die Hauptunterschiede zwischen klassischer Automatisierung und klassischer IT hinsichtlich der Einsatzmöglichkeiten und Architekturen beschrieben: Die Automatisierung erfordert äußerst zuverlässige, schnelle und vorausschauende Systeme, während die IT-Welt „sozialer“ sein muss: vielseitig, anpassungsfähig und kommunikationsfreundlich. In diesem zweiten Teil werde ich versuchen, die wichtigsten Unterschiede in der Kommunikation zu erklären.

Teil 2

Feldbusse im Vergleich zu Internetprotokollen

Eine SPS (siehe Teil 1 für eine Erläuterung) erfasst ihre Eingangssignale und kombiniert sie mit internen Zuständen zu einem Schnappschuss namens „Prozessabbild“. Diese Momentaufnahme wird für Berechnungen und Entscheidungen verwendet. Dies führt zu einer gleichzeitigen Statuserneuerung (Änderung) aller Ausgänge. Eingangs- und Ausgangssignale sind in der Regel entweder digitale 24-V-Signale oder analoge Signale mit einer Spannung von 0 bis 10 V oder Stromschleife von 4 bis 20 mA. Wenn Sie jedoch Hunderte von Sensoreingängen haben, können Sie diese nicht mehr alle physisch über einzelne Kabel anschließen. Die Lösung ist ein „Bus“ mit einigen wenigen Verdrahtungen. Er transportiert die Informationen zwischen der SPS und vielen Sensoren und Betätigungselementen sequentiell (er arbeitet also „seriell“ statt „parallel“, Abbildung 1). Sensoren und Betätigungselemente müssen „intelligenter“ sein: Sie benötigen einen integrierten Kommunikationsprozessor, um ihre Werte mit der Steuereinheit auszutauschen.

Abbildung 1: Konventionelle Verdrahtung (links) im Vergleich zur Feldbusverkabelung (rechts).

So genannte „Feldbusse“ oder „industrielle Bussysteme“ müssen Informationen auf vorhersehbare Weise transportieren. Vorhersehbarkeit in der Kommunikation bedeutet, dass die maximale Ansprechzeit zwischen einer Anfrage und der Antwort auf diese Anfrage genau bekannt sein muss (übrigens ist dies die Definition von „Echtzeitfähigkeit“ und kein willkürlich definiertes absolutes Zeitlimit). Unabhängig von dieser Ansprechzeit wird jede Abweichung ihres Nennwerts als „Jitter“ bezeichnet und macht ein System weniger vorhersehbar. Ein kleiner und bekannter maximaler Jitter ist die entscheidende Eigenschaft eines Echtzeitsystems in der Automatisierungstechnik. Aus diesem Grund ist die Verkürzung der Ansprechzeit durch die Verwendung von Interrupts keine gute Idee: Jede Unterbrechung führt zu einem Unsicherheitsfaktor und das gesamte System verliert seine deterministischen Eigenschaften. Kein Wunder, dass Feldbusse oft zyklisch und deterministisch arbeiten, genau wie die Steuerungen (SPS), mit denen sie verbunden sind. Ein zyklisch funktionierendes System bietet einen definierten Jitter. Sie können sich sicher vorstellen, dass die Kombination mehrerer asynchroner zyklischer Systeme (wie eine SPS und ein Feldbus) ihre Jitter summiert. Die Synchronisierung des Buszyklus mit dem SPS-Zyklus ist eine einfache Lösung für dieses Problem.

Abbildung 2: Ansprechzeit und Jitter in der Automatisierung.

„Protokolle“ sind Vereinbarungen zwischen Kommunikationspartnern, die die Phasen und Verhaltensweisen während der Kommunikation definieren. Ein großes Problem ist die historisch gewachsene Vielfalt dieser Protokolle in der Automatisierung. Maschinen sprechen häufig verschiedene „Sprachen“ und es gibt eine ganze Branche, die an der Übersetzung dieser Sprachen beteiligt ist. Sehen wir uns nun einen der klassischen Feldbusse an, der in der Norm IEC 61784/EN 50170 definiert ist: der „Process Field Bus für dezentrale Peripheriegeräte“ (Profibus DP). Er verwendet ein digitales Differenzialsignal auf zwei Kabeln, basierend auf dem RS485-Standard, jedoch mit sehr hohen Bitraten (bis zu 12 Mbit/s). Er arbeitet mit einer strikten Master-Slave-Konstellation und der Protokollteil DP V0 übermittelt Daten zyklisch (siehe Abbildung 3). Die Steuereinheit (SPS) ist der Master, und periphere Eingabe-/Ausgabegeräte (E/As) sind Slave-Geräte, die nur auf Anfragen reagieren dürfen, die zyklisch vom Master kommen.

Während der Konfigurationszeit muss der Techniker in die Steuereinheit eingeben, wie viele und welche Typen von E/As angeschlossen sind. Nach einer Startsequenz („Parametrierung“ und „Konfiguration“), bei der jedes Slave-Gerät in das Netzwerk „eingebunden“ werden muss, fragt die SPS zyklisch alle E/As mit einer definierten Abfragerate ab („Anfrage-Frame“). Die Slaves (periphere E/As) bestätigen den Empfang ihrer Daten und antworten sofort mit ihren E/A-Zuständen („Response-Frame“).

Abbildung 3: Zyklischer Datenaustausch auf einem Profibus

Ich möchte diese kurze Einführung nicht verkomplizieren, daher erwähne ich nur, dass es eine Token-Ring-Kommunikation geben kann, um mehrere Master auf einem Profibus zuzulassen (nur der Master mit dem Token darf Abfragen senden und wenn er seinen Zyklus beendet hat, wird der Token an den nächsten Master übergeben). Dieser Aufbau ist naturgemäß sehr sicher: Wenn beispielsweise ein Slave nicht innerhalb einer vordefinierten Zeit abgefragt wird, ändert er seinen Ausgang in vordefinierte „sichere Zustände“. Wenn ein Slave eine Störung erkennt, kann er in seiner Antwort an die SPS ein Alarmbit („Diagnosebit“) senden, worauf der Master mit dem nächsten Abruf die Diagnosedaten anfordern kann.

Es gibt auch inhärente Methoden, um das „Konsistenzproblem“ eines seriellen Busses zu lösen: In Teil 1 habe ich bereits das „Prozessabbild“ erwähnt. Ich habe beschrieben, wie wichtig es in der Automatisierung ist, eine konsistente Momentaufnahme der Eingangszustände zu erhalten (bzw. die Ausgänge gleichzeitig zu schalten). Aber wie kann man eine solche Momentaufnahme erhalten, wenn die Eingangsinformationen mehrerer Sensoren nacheinander übertragen werden? Wenn der zweite Sensorwert seine Abfrage beantwortet, könnte sich der erste Sensorwert bereits geändert haben. PROFIBUS verfügt daher über einen „Freeze“-Befehl. Die SPS überträgt diesen Befehl und alle Slaves frieren ihre Eingangswerte ein, bis sie abgefragt wurden. Auf diese Weise erhalten Sie eine Momentaufnahme des Moments, in dem die SPS den „Freeze Frame“ (Telegramm) gesendet hat.

Durch die Bitrate des Busses ist allerdings die Abfragerate begrenzt und bei Übertragungsfehlern können Abfragezyklen auftreten, die nicht den tatsächlichen E/A-Status widerspiegeln. Doch letztendlich ist diese Art der Kommunikation außergewöhnlich zuverlässig und deterministisch. PROFIBUS wurde in den Neunzigerjahren eingeführt und mit über 40 Millionen zertifizierten Geräten ist es immer noch eines der am häufigsten verwendeten Kommunikationsprotokolle in der Automatisierungsbranche. Durch seine Zuverlässigkeit ist er perfekt für Sicherheitstechnik geeignet (in Teil 3 dieser Serie werden wir uns diesem Thema widmen).

Dieses zyklische Master-Slave-Konzept sieht für IT-Techniker vielleicht seltsam aus: Warum sollte eine Schalterstellung immer wieder abgefragt werden und warum sollte der Schalter der Steuereinheit ständig mitteilen, dass sein Status „ein“ ist, anstatt nur eine Meldung zu senden, wenn er seinen Zustand von „aus“ zu „ein“ ändert? Weil es schwierig wäre, ein deterministisches System zu erstellen, wenn eine solche ereignisbasierte Kommunikation verwendet wird.

Wenn ein Anwendungsprogramm mit einer Datenbank kommuniziert und beide auf unterschiedlicher Hardware ausgeführt werden, liegt häufig eine Server-Client-Architektur vor. Ein einzelner Server muss Daten für viele Clients verarbeiten. Sehen Sie den wesentlichen Unterschied? Viele Clients müssen in der Lage sein, die Kommunikation zu initiieren – sie sind Kommunikationsmaster – und der zentrale Server reagiert wie ein Slave-System. In einer solchen Umgebung fühlt sich die Verwendung eines durch eine Nachricht ausgelösten Dialogs viel natürlicher an. Ein deterministisches Netzwerk, das auf Nachrichten basiert (z. B. Token Ring), wäre denkbar. Aber aufgrund ihres extrem hohen statistischen Gesamtdatendurchsatzes haben probabilistische Netzwerke wie Ethernet das Rennen gemacht. Solche Netzwerke ermöglichen es jedem Teilnehmer, jederzeit bei Bedarf eine Nachricht zu senden. Diese Freiheit führt zu möglichen „Kollisionen“, wenn zwei Clients gleichzeitig damit beginnen. Aber mit einer schnellen Kollisionserkennung und Reaktionsstrategie erzielen Sie dennoch einen enormen Durchsatz. In modernen Netzwerktopologien (Stern statt Bus oder gemascht) vermeiden Sie Kollisionen durch leistungsstarke „Switches“, die Nachrichten zeitversetzt senden, um sie „hintereinander zu reihen“.

IT-Netzwerke und ihre Protokolle haben nicht nur eine Datenrate im Gigabit-Bereich pro Sekunde (statt nur Megabit wie Profibus), sie verfügen außerdem über eine flexible Topologie. Technisch gesehen ist es kein Problem, ein solches Netzwerk weltweit aufzuspannen – wie das Internet. Eine wesentliche Grundlage für diese Flexibilität ist die Protokollabstraktion in „Schichten“, die einen „Stapel“ bilden. Das OSI-Referenzmodell definiert sieben Schichten (siehe Abbildung 4). PROFIBUS definiert z. B. nur drei davon (Schichten 1, 2 und 7). Das Internet mit seinem TCP/IP-Protokoll verwendet alle Schichten.

Abbildung 4: OSI-Protokollschichten; Beispiel HTTP

Die Flexibilität einer solchen Kommunikationsarchitektur ergibt sich aus der Tatsache, dass zwei Partner über dieselbe Schicht kommunizieren können, aber in den unteren Schichten nichts über die Kommunikationsprozesse wissen müssen. Sie erhalten ihre Nachrichten von der nächstniedrigeren Ebene, als ob sie direkt mit ihrem Netzwerkpartner auf derselben Ebene kommunizieren würden (Abbildung 5). Man kann sich das als „virtualisierte Kommunikation“ mit der Nachbarschicht (Partner) vorstellen.

Abbildung 5: Schicht-zu-Schicht-Kommunikation mithilfe von Protokollstacks.

Die Verwendung einer Netzwerkschicht (OSI-Schicht 5) bietet die Möglichkeit des paketvermittelten Routings: Jeder Netzwerkknoten kann selbst entscheiden, an welchen Nachbarknoten er ein empfangenes Informationspaket weiterleitet, um es an die gewünschte Empfängeradresse (IP) zu bringen. Dies ist die Grundlage des Internets, und es bedeutet lediglich, dass Sie nie wissen können, wie Datenpakete von der Sender-IP-Adresse zur Empfänger-IP-Adresse übertragen werden.

Das Risiko dieser Flexibilität ist der Verlust der „Echtzeitfähigkeit“. Sie können die maximale Ansprechzeit Ihres Kommunikationspartners nicht mehr präzise vorhersagen oder definieren. Wenn Sie ein TCP/IP-basiertes Netzwerk verwenden, um eine Zustandsänderung eines Switches zu übermitteln, kann es einige Mikrosekunden oder Dutzende von Millisekunden dauern, bis die Steuereinheit die Nachricht erhält. „TSN“ (zeitkritische Netzwerke) gehen das Problem dieser Risiken an und zielen darauf ab, die Echtzeitfähigkeit auch in IT-Netzwerkprotokollen zu gewährleisten.

Die gute Nachricht ist, dass wir die Echtzeitfähigkeit für IIoT nicht benötigen. Latenz ist nicht das wichtigste Kriterium. Aber es gibt eine besondere Einschränkung bei der Planung, wenn eine Industriemaschine ins Netz gehen soll: Für ereignisgesteuerte Kommunikationsprotokollstapel benötigen Sie immer Threading- oder Multitasking-Betriebssysteme. Klassische SPS verfügen in der Regel nicht über ein solches Betriebssystem. Moderne, so genannte „Soft-SPS“ sind Anwendungen, die auf Linux-basierten IPCs („Industrie-PCs“.) ausgeführt werden. Das sind Computer, die häufig auf DIN-Schienen montiert sind und keine Tastaturen, Mäuse und Monitore verwenden. Obwohl solche Systeme TCP/IP-Protokollstapel effizient verwalten können, ist es ratsam, die meldungsbasierte IIoT-Kommunikation streng von der Steuerungssoftware zu trennen. Gateways sind ein perfektes Mittel zur Trennung von Netzwerk und Software. Ein Gateway kann sich wie jede Peripherie-E/A zur SPS (ihr Feldbus-Protokoll, um genau zu sein) verhalten und stellt auf der anderen Seite eine Verbindung zum meldungsbasierten Internet her. Gateways sind oft der Punkt, an dem Sicherheit auf Schutz trifft. Doch dies ist das Thema in Teil 3...

Volker de Haas started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and precise analogue electronics for neuroscience labs (and his MD grade). Later database engineering, C++, C#, hard- and software developer for industry (transport, automotive, automation). Ended up designing and constructing the open source PLC / IPC "Revolution Pi". Today engaged in advanced development as a service.

19 Jun 2019, 9:55

Kommentare