Traum von einem plattformunabhängigen SPS-Programm

Artikel#: 00092

Datum: 2024-05-26

Autor: Radim

Es ist doch eine schöne Idee, ein Programm zu schreiben, das wir auf jeder beliebigen SPS laufen lassen können und so eine völlige Unabhängigkeit vom SPS-Anbieter gewährleisten, oder?
Und warum sollten wir vom SPS-Anbieter unabhängig sein wollen?
Denn wir können leicht den SPS-Anbieter wechseln, wenn wir mit dem aktuellen nicht mehr zufrieden sind (z.B. weil es den Anbieter nicht mehr gibt, die Materiallieferung zu lange dauert, die Preise gestiegen sind, Qualität und Leistung unbefriedigend sind, der Support schlecht ist, sich unsere Anforderungen geändert haben, die Konkurrenz bessere Konditionen bietet usw.). Ein Wechsel des SPS-Anbieters ist jedoch nicht einfach, wenn unser Entwicklungsteam Hunderte von Stunden in die Entwicklung eines Programms investiert hat, das nur auf der spezifischen SPS ausgeführt werden kann, für die das Programm entwickelt und getestet wurde.

Also, warum schreiben wir das Programm nicht universell, damit es einfach auf allen möglichen SPSen ausgeführt werden kann? Weil es unmöglich ist. :-(
Es gibt praktische Herausforderungen und Einschränkungen:

1. Herstellerspezifische Hardware-Merkmale:
Jede SPS-Hardwareplattform verfügt über einzigartige Fähigkeiten, Leistungsmerkmale, E/A-Module und proprietäre Funktionen.

2. Herstellerspezifische Software-Funktionen:
Zwar unterstützen viele SPS-Anbieter die IEC 61131-3, doch verfügen sie oft über proprietäre Erweiterungen und Funktionen, die nicht portabel sind.

3. Unterschiede in der Leistung:
Verschiedene SPSen haben unterschiedliche Prozessorleistungen und Speicherkapazitäten.

4. Integration in bestehende Systeme:
In jeder Maschine oder Anlage müssen SPSen mit anderen Geräten und Systemen integriert werden, die über herstellerspezifische Schnittstellen und Protokolle verfügen.

5. Diagnose und Fehlerbehebung:
Herstellerspezifische Diagnose- und Fehlerbehebungswerkzeuge sind oft fortschrittlicher und auf die eigene Hardware zugeschnitten.

6. Sicherheitsprojekt:
Jeder SPS-Anbieter hat seine eigene spezifische Sicherheitshardware, seinen eigenen Sicherheits-Projekteditor und seine eigene Programmiermethode für das Sicherheitsprojekt.

Ich finde es eigentlich völlig in Ordnung, dass es Unterschiede zwischen den SPSen in Bezug auf ihre Hardware- und Software-Fähigkeiten gibt. Denn jeder kann diejenige SPS wählen, die seinen Anforderungen entspricht. (Wie man die richtigen elektrischen Komponenten auswählen kann, ist in diesem Artikel zum nachlesen: Hardwarekonzept)


Nun, es ist nicht möglich, ein plattformunabhängiges SPS-Programm zu schreiben. Es ist jedoch möglich, einen solchen Ansatz zu wählen, damit das Programm leichter auf eine andere SPS portiert werden kann. Dies beinhaltet mehrere Strategien:

1. Modularer Aufbau:
Zerlege das SPS-Programm in modulare Komponenten, wobei die Kernlogik plattformunabhängig ist, und hardwarespezifische Module die Interaktion mit der SPS-Hardware übernehmen. Auf diese Weise kann die Menge des Codes, der für verschiedene Plattformen angepasst werden muss, minimiert werden.

2. Einhaltung von Normen:
Halte dich an Industrienormen wie IEC 61131-3. Dies gewährleistet ein gewisses Mass an Übertragbarkeit und eine einfachere Anpassung an Plattformen, die diese Standards unterstützen.
Um aus einer vordefinierten Reihe von kompatiblen SPSen auszuwählen, können wir auch herstellerunabhängige Programmierumgebungen wählen: Einige Programmierumgebungen und -werkzeuge sind für die Arbeit mit SPSen verschiedener Marken konzipiert. Z.B.:
Codesys: Eine hardware-unabhängige IEC 61131-3 Entwicklungsumgebung. Sie unterstützt eine breite Palette von SPS-Hardware verschiedener Hersteller.
PLCopen: Eine Organisation, die die Standardisierung der Programmierung zwischen verschiedenen SPS-Anbietern fördert. Sie stellt Richtlinien und Funktionsblöcke zur Verfügung, die zur Erstellung portabler Anwendungen verwendet werden können.

3. Plattform-spezifische Optimierungen:
Füge bei Bedarf plattformspezifische Optimierungen als separate Module oder bedingte Codeabschnitte ein. Mit diesem Ansatz kann man eine hohe Leistung beibehalten und spezifische Funktionen nutzen, ohne die Gesamtportabilität der Anwendung zu beeinträchtigen.

4. Standard-Kommunikationsprotokolle:
Verwendung von Standard-Kommunikationsprotokollen (z.B. OPC UA, Modbus, EtherCAT) für die Interaktion zwischen SPS und anderen Systemen verbessert die Interoperabilität und verringert die Abhängigkeit von herstellerspezifischen Protokollen.

5. SPS-Anbieter-unabhängige Visualisierungs- und Sicherheit-Projekte:
Wähle eine SPS-unabhängige Lösung und Standard-Kommunikationsschnittstellen für die Visualisierung- und Sicherheit-Projekte.

Die Befolgung dieser Strategien bringt eine saubere Struktur und Klarheit in den Code. Es ist sinnvoll, die meisten dieser Strategien zu befolgen, auch wenn man nicht beabsichtigt, das SPS-Programm auf eine SPS eines anderen Anbieters zu übertragen.
Darüber hinaus lohnt es sich auf jeden Fall, die in diesem Artikel genannten Grundsätze für das Schreiben von sauberem Code zu befolgen: Pflege Ordnung im Programmkode

Um sicherzustellen, dass der Code auf verschiedene Plattformen übertragbar ist, ist zusätzlicher Aufwand bei Entwurf, Implementierung und vor allem beim Testen erforderlich. Wir können zwei oder drei geeignete SPS-Lieferanten auswählen und portable Software für deren Plattformen entwickeln, wenn unser Projekt ein gewisses Mass an "Plattformunabhängigkeit" oder eher Plattformredundanz erfordert.

© Radim-Automation, 2020–2025. Alle Rechte vorbehalten.
Die Verbreitung dieses Artikels ist mit Angabe der Quelle (Link zur Originalseite) ausdrücklich gestattet.

Verwandte vorherige Artikel:

• Mache Backups, nehme kleine Änderungen vor und teste viel
• Codeformatierung
• Pflege Ordnung im Programmkode
• SPS-Netzwerkdiagramm
• Versionskontrollsystem
• Diagnosetools
• Ereignislogger als allererste im Programm implementierte Funktion
• Software-Update
• Sicherheitsrelais versus Sicherheits-SPS
• Wahl der Programmiersprache
• Variablennamen
• Maschinenmodularisierung
• Modulare Softwarearchitektur
• Hardwarekonzept
• Ein gutes Konzept = Kompletter Satz geeigneter Lösungen
• Gibt es auch Nachteile?
• Denke kritisch!
• Warum scheitern Automatisierungsprojekte?
• Sammelt alle Anforderungen und sortiert sie!
• Funktionelles und intuitives HMI
• Verwende einen nützlichen Styleguide!
• Schreibe und akzeptiere nur lesbaren Code!
• HMI- und SPS-Anwendungen sollen zusammenwachsen
• Willst du damit wirklich beginnen?
• Mehr als nur starten und stoppen
• Sicherheit zuerst!
• Industrielle Evolution - Höre eurem Kunden zu und folge neuen Trends!
• Hab einen Experten zur Hand!
• Konzentriere dich auf das Ziel!
• Überprüfe das Ergebnis!
• Halte es einfach!
• Wähle das richtige Werkzeug!
• Entwicklung ist Evolution
• Transparenz und Zuverlässigkeit

Verwandte nächste Artikel:

• High Performance HMI
• Auswahl eines HMI-Displays
• HMI-Layout und richtige Displaygrösse

Kommentar#: 00001

Datum: 2024-05-28

Benutzer: Christian

Je höher der Grad der Unabhängigkeit sein soll, desto geringer ist die Differenzierung und die Spezialisierung und umso grösser ist der Aufwand für die Pflege der Entwicklungsumgebung.

Wer alles standardisiert und nur mit open source tools arbeitet, der muss die Verantwortung für seine Entwicklungsumgebung und die Target-Hardware selbst übernehmen. Das bedeutet permanenten Aufwand und verursacht wiederkehrende Kosten.

Wer sich auf eine Partnerschaft mit einem spezifischen Anbieter einlässt, profitiert von einer Systemlösung (alles aus einer Hand), was nicht nur ökonomisch ist, sondern es einem auch ermöglicht, sich auf die eigene Applikation zu konzentrieren, anstatt sich immer wieder auch mit der Pflege der Entwicklungsumgebung beschäftigen zu müssen.

Beide Wege sind möglich, aber man muss konsequent sein und immer die Vor- und die Nachteile akzeptieren.

Kommentar#: 00002

Datum: 2024-05-30

Benutzer:

Man merkt aber auch, das man in der heutigen Zeit von der SPS eigentlich eine Rolle rückwärts betreibt. Man geht auch wieder zurück in die alte gute Microcontroller-Welt. Nun nennt man es "als aller Heilmittel gegen die Lieferschwierigkeiten durch Corona". Man hat totalvergessen, warum man früher umgestiegen ist auf die SPS. Denke mal, die Erfahrungen und Aspekte warum man vom Microcontrollern zur SPS gegangen ist, werden sich bald wiederholen. Also wird der Hund sich mal wieder in den Schwanz beissen. Und es beginnt wieder von Neuem.

Kommentar#: 00003

Datum: 2024-05-30

Benutzer:

Ich habe noch einen anderen Fokus, der hier nicht angesprochen wurde.
Man kann durchaus eine Applikation(Programm) für viele Platformen schaffen. Die Hardwarverknüpfung muss nur auf einer vorherigen Ebene machen.
Ich spreche hier von Docker, laut Toradex(deren mini-OS) wird geworben, dass es RealTime fähig ist. Das bedeutet, überall wo Docker drauf läuft ist RealTime fähig und somit auf vielen Hardware-Strukturen verfügbar.
Also eigentlich das was im Hauptteil angesprochen wurde.
Zudem kann man es noch weiter ausweiten und die HMI auch in einem Container setzen. Somit wäre alles individuell austauschbar. Was denke ich der heutigen Zeit recht und gut kommt.

Kommentar#: 00004

Datum: 2024-07-03

Benutzer: Radim

Meistens bietet jeder SPS-Hersteller einige eigene Bibliotheken oder Funktionen an, die etwas Besseres oder Zusätzliches als die Standardbibliotheken und -funktionen leisten. Ich finde es schade, die Vorteile der von uns gewählten Plattform auf Kosten der Portabilität aufzugeben. Wir sollten die Vorteile der von uns gewählten Plattform nutzen, um leichter zur richtigen Lösung zu gelangen.