Kapitel 9: Fragen und Antworten

  1. Grundfließbild zur Prozessbeschreibung
  2. Verfahrensfließbild zur Spezifikation der Maschinen und Apparate
  3. Anlagenschema bzw. Rohrleitungs- und Instrumentenfließbild zum Einsatz der Sensoren und Aktoren
  4. Datenblätter zur Gerätespezifikation
  5. Signal- und Stromlaufpläne zur Planung der Verdrahtung

Das Vorgehensmodell (V-Modell) unterteilt den Engineeringprozess in folgende Abschnitte:

  • Für die Planung des Automatisierungssystems wird auf Basis einer betrieblichen Prozessbeschreibung ein Lastenheft erzeugt, das die zu automatisierenden Funktionen der Anlage sowie die Anforderungen an das Automatisierungssystem und das Projekt spezifiziert. Daraufhin erfolgt der Hard- und Softwareentwurf für das Automatisierungssystem im Pflichtenheft.
  • In der Realisierungsphase wird die Hardware des Automatisierungssystems bestellt, produziert und geliefert. Die Anwenderprogramme werden gemäß Pflichtenheft erstellt, getestet und dokumentiert. Mit Hilfe der Planungsunterlagen werden Modelle der Feldgeräte und Anlagenteile entwickelt, die eine virtuelle Inbetriebnahme ohne Anlage für Schulungs- und Testzwecke ermöglichen
  • Während der Installationsphase wird zunächst die Steuerungshardware aufgebaut und das Zusammenspiel zwischen Hard- und Software getestet. Nachdem die Sensoren und Aktoren angeschlossen wurden, kann die Funktion der Steuerung, also das Zusammenspiel mit der Anlage, geprüft werden. Abschließend wird die Produktion überprüft, d. h. das Zusammenspiel der automatisierten Anlage mit den vorgesehenen Einsatzmaterialien.

Unter Qualifizierung versteht man den Nachweis, dass die Anlage und ihre Komponenten so funktionieren wie in den entsprechenden Spezifikationen vorgegeben. Wie aus dem V-Modell hervorgeht, erfolgt die Prüfung der jeweiligen Ausführung gegen die entsprechende Spezifikation während der Inbetriebnahme. Der Nachweis der akzeptierten Prüfung erfolgt durch Testprotokolle und Prüfberichte.

Der digitale Zwilling stellt ein zu jedem Zeitpunkt aktuelles Abbild der Anlage dar. Die bei der Planung zusammengetragenen Sepzifikationsdokumente werden hierfür ebenso in einer Datenbank gespeichert wie die während der Inbetriebnahme und des Betriebs gesammelten Daten über das Verhaltend er Anlage und ihrer Feldgeräte. 

Der digitale Zwilling besteht aus Informations- und Simulationsmodellen. Simulationsmodelle beschreiben das Verhalten der Anlage. Informationsmodelle beschreiben die Eigenschaften der Anlage und ihrer Assets und enthalten z.B. das Anlagen- und Prozessmodell, Geräte- und Signalemodelle sowie Datenmodelle zu digitalen Repräsentation. 

Durch eine Verwaltungsschale werden Ablage und Zugriff auf die Daten des digitalen Zwillings standardisiert.

Das Lastenheft beschreibt im Wesentlichen, was automatisiert werden soll. Es enthält u.a. folgende Dokumente:

  • Anlagenschema mit Angabe aller Sensoren und Aktoren mit ihrer PCE-Kennzeichnung nach IEC 62424.
  • Gerätespezifikation: Grobbeschreibung der Funktionsweise der eingesetzten Feldgerätetypen (Klassen) und Zuordnung aller Feldgeräte zu den spezifizierten Typen.
  • Prozessspezifikation: Prozessphasendiagramm (s. Bild 6.17), Ablaufpläne in Form von Schrittketten und Cause-and-Effect-Matrizen für Verriegelungen und Verschaltungen aufeinander einwirkender Geräte (s. z. B. Tabelle 4.1).
  • Bedienphilosophie: Vorgaben hinsichtlich der Prozessgrafikbilder, des Betriebsartenkonzepts und der Behandlung von Störmeldungen. 
  • Sicherheitsanforderungen: Sicherheitsfunktionen, SIL-Stufe, explosionsgefährdete Anlagenbereiche, Anforderungen an Datenarchivierung und Produktqualität.
  • Verfügbarkeitsanforderungen: Redundanzkonzept, Berücksichtigung einer gewissen Kanalreserve, Schnittstellen zu anderen Rechnersystemen und Anforderungen an die Stromversorgung.

Das Pflichtenheft beschreibt, wie und womit die Automatisierungsaufgabe gelöst wird. Dabei sind insbesondere folgende Unterlagen zu erstellen, gegen die Hard- und Software später zu prüfen sind:

  • Hardwarestrukturplan (vgl. z. B. Bild 8.7), der die eingesetzten Hardwaremodule (z. B. Rechner, Peripheriegeräte) inklusive ihrer Verbindungskabel darstellt.
  • Softwarestrukturplan (s. Bild 8.8), der die zu programmierenden Softwaremodule und ihre Verknüpfungen überblicksartig aufzeigt.
  • PCE-Stellenliste und Signalliste (s. z. B. Bild 8.9), die den Softwarestrukturplan konkretisieren und die Programme und Signale aufführen, durch die die Feldgeräte in der SPS angesteuert werden. 
  • Typicalbeschreibung für die Funktionsbausteine, die zur Ansteuerung der Feldgerätetypen gemäß der Gerätespezifikation des Lastenhefts entwickelt werden.
  • Multi-User und Multi-Project-Engineering in der Cloud
  • orts- und plattformunabhängige Softwareentwicklung im Webbrowser
  • Gemeinsamer Zugriff mit Dateiversionsverwaltungssystemen, durch die nachverfolgt werden kann, wer wann welche Änderung an einem Softwaremodul vorgenommen hat.
  • Softwaremodule in verschiedenen Revisionsständen sind für das Social oder Collaborative Engineering zentral verfügbar.
  • Sensible Eingriffe sind nur mit entsprechender Zugriffsberechtigung und Datensicherheit in einer (privaten) Cloud möglich.
  • Verwaltung der Hardwarekonfiguration in der Cloud, so dass ein virtuelles Abbild des Automatisierungssystems in der Cloud ensteht und anzeigt, welche Steuerung aktuell läuft, gestoppt oder in Störung ist.

Um Teile der Software automatisch zu erzeugen. kann man die Funktionsbausteine der Feldgeräteklassen aus der SPS im PLCopenXML-
Format exportieren und in eine Datenbank wie MS Access importieren.

Gemäß der Objekt- und Klassenzuordnung der Feldgeräte in der PCE-Stellenliste erzeugt ein Visual-Basic-Programm eine xml-Datei für alle zu erstellenden Programme jeweils mit einem Verweis auf die zugeordneten Daten- und Funktionsbausteine.

Importiert man diese xml-Datei dann wieder in Codesys, wird für jedes Feldgerät automatisch das Ansteuerprogramm mit dem passenden Funktionsbaustein und ein Datenbaustein als globale Instanzvariable angelegt (s. Bild 8.10 und Übung 8.2).

Für jeden Feldgerätetyp wird nicht nur ein Funktionsbaustein zur Ansteuerung, sondern jeweils auch ein Funktionsbaustein zur Simulation und zur Visualisierung entwickelt. Die Funktionsbausteine lassen sich wie in Kapitel 6 erläutert zu Bausteinen für Anlagenteile und Teilanlagen zusammenfassen, die projektübergreifend verwendet werden können.
Die unten skizzierte Bausteinbibliothek reduziert den Engineeringaufwand erheblich, denn sie ermöglicht es, Simulationsbausteine generisch zu einem Simulationsmodell der Anlage zusammenzusetzen (s. Übung 8.3). Da der Testablauf meist dem programmierten Prozessablauf der Schrittketten entspricht, kann mit Hilfe dieser Simulationsbausteine die Steuerungssoftware weitgehend automatisiert getestet werden.

Eine virtuelle Inbetriebnahme mit Hilfe eines digitalen Zwillings der Anlage werden Simulationsbausteine verwendet, die die Sensoren und Aktoren der Anlage simulieren. Die virtuelle Inbetriebnahme erfolgt im Wesentlichen durch einen Black-Box-Test. Die Ausführung der Schrittketten (SFCs) testet das Zusammenspiel der Softwaremodule quasi automatisch, denn sie lesen Sensorsignale aus den
CFCs ein, steuern Aktoren über CFCs an und führen den Prozessablauf so schrittweise durch.

Wenn die Sensoren, Aktoren und Anlagenteile wie oben erläutert simuliert werden, schließt sich der Steuerkreis (Software in the Loop) und seine Funktion kann anhand der simulierten Sensorwerte und der Prozessvisualisierung überprüft werden. Falls einzelne von den Schrittketten angestoßene Aktionen nicht richtig ausgeführt werden, führt dies in der Regel zu einem nicht spezifizierten Prozessverhalten, d. h. die
von der folgenden Transition erwarteten Sensorwerte werden nicht erreicht und die Schrittkette bleibt stehen.

Durch White-Box-Tests wird sichergestellt, dass Schrittketten, Typicals und Verriegelungen entsprechend der Vorgaben vollständig und korrekt programmiert sind. Dies erfolgt oft durch Sichtkontrolle der Programmlistings gegen die entsprechenden Funktionsvorgaben und wird durch Abhaken protokolliert. Während beim White-Box-Test also auch die innere Struktur einzelner Modulen überprüft wird, erfolgt beim Black-Box-Test nur eine Beobachtung des Gesamtverhaltens. Dabei wird das System mit Testsignalen am Eingang stimuliert und das Verhalten anhand der resuktierenden Ausgangssignale überprüft, ohne zu überprüfen, wie das Verhalten zustande kam.

In der ersten Phase, der sog. Installationsprüfung, wird geprüft, ob die einzelnen Hard- und Softwaremodule spezifikationsgemäß installiert wurden. So ist beispielsweise der Hardwareaufbau des installierten Steuerungssystems gegen den Hardwarestrukturplan, d.h. die Aufstellungspläne, Kabellisten, etc., zu testen.

Die weiteren Prüfungen umfassen vor allem folgende Modultests:

  • Test der Funktionsfähigkeit der Hardwarekomponenten, wie z.B. der E/A-Karten, der CPU's, des PG's und der einzelnen ABK's,
  • Test der Funktionsfähigkeit der Typicals in der SPS,
  • Review der vollständigen Installation der Ansteuerprogramme (CFC's) und der Signale.

Im Rahmen der Funktionsprüfung werden die Steuerungsfunktionen im Zusammenspiel mit der Anlage überprüft. Dabei werden folgende Prüfungen ausgeführt:

  • Loop-Check: Test der Feldgeräte durch Ansteuerung und Beobachtung über die Anzeige- und Bedienkomponente (ABK). Somit wird nicht nur die Funktionsfähigkeit des Ansteuerbausteins, sondern auch die korrekte E/A-Belegung sowie die Verdrahtung der Feldgeräte mit der SPS überprüft.
  • Test der Zusatzlogik der Programme (CFC's), wie z.B. Verriegelungen, Alarmierungen, kontinuierliche Schaltungen.
  • Wasserfahrt: Test der Ablaufketten (SFC's) hinsichtlich des spezifizierten Prozessablaufs. Dabei wird die Anlage anstatt mit dem vorgesehenen Produkt mit Wasser durchlaufen, um Auswirkungen von Anlagenfehlern auf die z.T. wertvollen und/oder gefährlichen Produktionseinsatzstoffe zu vermeiden.

Schließlich gewährleistet eine erfolgreiche Produktionsprüfung das gewünschte Zusammenspiel zwischen Steuerung, Anlage und Produkt. Bei der PQ bleiben noch folgende mit dem Automatisierungssystem auszuführende Tests:

  • Einstellung bzw. Parametrierung materialabhängiger Sensoren und Regler,
  • Optimierung der Abläufe hinsichtlich Parametrierung, Protokollierung (Aufzeichnung von Messkurven qualitätsrelevanter Sensoren) und
  • organisatorische Maßnahmen zur Behebung von Störfällen (Desaster Recovery).

Das Condition Montitoring führt eine Zustandsüberwachung für ein Feldgerät oder einen Anlagenteil durch und bewertet den Zustand als sog. Asset Gesundheit. Die Zustandsüberwachung kann modellbasiert erfolgen. Abweichungen des Betriebsverhaltens vom modellierten Verhalten ermöglichen eine frühzeitige Störungserkennung und eine vorausschauende Wartung.

Weitere Möglichkeiten zum Condition Monitoring ergeben sich durch eine signalbasierte Zustandserkennung. Z. B. deuten unregelmäßige Vibrationen von Maschinen oder Windrädern frühzeitig auf Störungen oder Ausfälle hin. In der SPS können diese Messsignale überwacht werden und ggf. eine Alarmierung auslösen. Die Ursache dieser Fehler kann durch Analyse der Prozessdaten (Big Data) klassifiziert werden, so dass frühzeitige Instandhaltungsmaßnahmen durch ein Predictive Maintenance eingeleitet werden können.

Die Fernwartung der SPS kann heutzutage durch Cloud-Engineering erfolgen, so dass häufig ein Vor-Ort-Einsatz nicht mehr notwendig ist.
Bei Ausfall einer SPS kann der Benutzer aus der Ferne ein Ticket mit allen Daten der ausgefallenen Komponente erstellen und den Austausch durch einen Techniker vor Ort veranlassen. Mit einer Webcam kann er den Austausch über die Cloud überwachen und danach die Software in die neue SPS wieder hineinladen.

Ein anderes Prinzip der Fernwartung basiert auf einem VPN-Tunnel. Um die besonderen Anforderungen des Datenschutzes zu berücksichtigen, wird ein sog. Virtual Private Network (VPN) aufgebaut. Dabei wird jeweils ein Router im Segment des Servers
und im Segment des Clients eingesetzt. Die Router bieten Verschlüsselungssysteme für geschützte Verbindungen, wie das IPSec-Protokoll (Internet Protokoll Security). Mit dieser Verschlüsselung schafft man eine Verbindung zwischen den beiden Routern, die von außen geschützt ist und intern die Möglichkeit gibt, alle Teilnehmer über den Namen oder die lokale IP-Adresse anzusprechen. Nach der Konfiguration des VPN/IPSec-Tunnels ist das Handling genau so, als wären die Teilnehmer durch ein Netzwerkkabel miteinander verbunden. Da diese Verschlüsselung nicht auf Anwendungsebene arbeitet, untertunnelt sie gewissermaßen die Kommunikation und bleibt
für Angriffe auf bestimmte Anwendungsprogramme unsichtbar.

Die weitere Möglichkeit zur Durchführung einer Fernwartung ergibt sich über einen Remote-Desktop am Programmiergerät der SPS. Mit einer Fernwartungssoftware wie Teamviewer kann ein Wartungsingenieur über das Internet direkt auf den PC des Programmiergeräts zugreifen. 

Speicherprogrammierbare Steuerungen in der Industrie 4.0

5. Auflage erschienen im Hanser Verlag 2021