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.

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.