Die Entwicklung von SPS-Software hat ihren Hintergrund:
- als ergänzender Teil des Lösungsraums für die mechanische und elektrische Modellierung (des gesamten Prozessablaufs)
- verstärkter Rückgriff auf PLC als sinnvollere alternative Implementierung, aber ohne unabhängige Modellierungstechnik
- IEC61499, die UML als Entwurfstechnik für die SPS-Programmierung empfiehlt.
Um das zu erläutern:
-
Als ergänzende Komponenten wurden SPS als Ablauf-/Zustands-/Regelungssteuerungen, Schutzverriegelungen, Signalaufbereitung usw. eingesetzt, die die in IEC61131 vorgeschriebenen Merkmale aufweisen. Die Anforderungen sind in den mechanischen und elektrischen Modellen gut erfasst, eine unabhängige Modellierung ist nicht erforderlich.
-
Durch den verstärkten Einsatz von SPS bei der Festlegung von Anforderungen an Prozessausnahmen, Wiederherstellungsverfahren, mehrstufige Fehlermöglichkeitsanalysen und Folgenmanagement wurde eine unbewusste Übernahme der Musterentwurfstechnik entwickelt. Die verschiedenen Branchen und Prozessunternehmen verwenden jedoch unterschiedliche Ansätze. Im Allgemeinen stützen sie sich auf traditionelle Modelle, funktionale Design-Spezifikationsliteratur, durchgängige Ursache-Wirkungs-Listen, bedingtes Management von Situationen unter Verwendung von Logikdiagrammen. Die Grundprinzipien sind umfangreiche Tests, kontinuierliche Anwendung und Korrektur, Wiederverwendbarkeit, um ihren Designansatz zu perfektionieren.
-
In Anbetracht des Mangels an SPS-Softwaremodellierung und des Scheiterns der IEC61158 (Foundation Fieldbus Distributed Object/Data/Dependency Modeling) wurde 2006 die IEC61499 mit der Empfehlung der UML als Entwurfstechnik eingeführt. Die Tendenz war und ist jedoch, einen funktionalen Objektmodellierungsansatz zu verfolgen, der zu komplizierten Objektabhängigkeiten aufgrund von Zeit- und Zustandsbindungen führt, die typischerweise in Prozessanwendungen auftreten, die logiklastig sind und nicht datenlastig wie in der IT-Branche. Daher werden Analysewerkzeuge für die Prüfung von logischen und logischen Widersprüchen, für die getrennte Modellierung von Zeit und Zustand usw. entwickelt, was die Dinge nicht gerade einfacher macht und vom technischen Prinzip der Problemraumreduzierung abweicht. Dem Ansatz mangelt es auch an Affinität zu und Kontinuität von mechanischen, elektrischen und Prozessmodellierungsdokumentationen.
Die aktuelle Situation ist:
a. IEC61131 und IEC61499 sind Herstellerstandards und entbinden Steuerungs- und Regelungsingenieure von der Notwendigkeit, sich mit Echtzeit-Betriebssystemen zu befassen; sie sollten noch lange Zeit als Anwendungsstandards gelten.
b. UML als sehr möglicher Entwurfsansatz
c. Entwurfsmuster auf der Grundlage von UML sollten sicherstellen, dass Objektmodelle den Prozessmodellen ähnlich/gleich/nahestehen (Datenfluss anstelle von Produktfluss, Datenmodell als praktische Objekteigenschaften), Bindermuster, Fehlereskalationsmuster, Verriegelungseskalationsmuster, implizite Anlagen- und Objektmuster usw. Ein gutes Datenmodell bei der SPS ist auch der Schlüssel zum erfolgreichen UI- oder SCADA-Design.
Ich habe erfolgreich Systeme implementiert, indem ich eine vollständig rationalisierte Reihe von Entwurfsmustern für eine Wasseraufbereitungsanlage und ein Fabrikband mit Be- und Entlademaschinen entwickelt habe. Ich benötige die Umgebung, um die Entwurfsmuster auszuarbeiten. Es gibt zu viel zu besprechen, den konzeptionellen Hintergrund der Mess-/Ausrüstungs-/Teilsystem-/Prozess-/Anlagenobjekte, ihre Abhängigkeiten bei geringstem Aufwand, ihre impliziten Beziehungen, einige einfache Regeln zur Begrenzung und Verwaltung der Ausbreitung von Änderungen usw.