IEC 61131-1 Allgemeine Informationen
Definitionen, Anwendungsbereich, Klassifizierung von SPS.
IEC 61131
Speicherprogrammierbare Steuerungen
IEC 61131 ist die internationale Norm fuer speicherprogrammierbare Steuerungen. Teil 3 standardisiert die 5 Programmiersprachen der industriellen Automatisierung (LD, FBD, SFC, ST, IL) und ermoeoelicht Codeportabilitaet zwischen PLC-Plattformen sowie ein gemeinsames Fachvokabular fuer Automatisierungsingenieure weltweit.
Dokumentstruktur
IEC 61131-2 Betriebsmittelanforderungen und Pruefungen
Hardwareanforderungen: Umgebung, EMV, Mechanik, elektrische Sicherheit.
IEC 61131-3 Programmiersprachen
DER bekannte Teil. Definiert 5 Programmiersprachen (Kontaktplan LD, Funktionsblockdiagramm FBD, Ablaufsprache SFC, Strukturierter Text ST, Anweisungsliste IL — seit 2013 zurueckgezogen). Ausserdem Datentypen, POE (Programm-Organisationseinheiten), Tasks.
IEC 61131-4 Benutzerhandbuch
Auswahl und Anwendung von SPS (informativ).
IEC 61131-5 Kommunikation
Konzepte zur Kommunikation zwischen SPS (in der Praxis weitgehend durch OPC UA abgeloest).
IEC 61131-6 Funktionssicherheit
Sicherheitsrelevante Aspekte beim Einsatz von SPS in Sicherheitsanwendungen (Verknuepfung mit IEC 61508).
IEC 61131-7 Programmierung mit Fuzzy-Logik
Nischenthema: Standardisierung der Fuzzy-Logik. Selten eingesetzt.
IEC 61131-8 Leitfaden zur Anwendung und Umsetzung der Programmiersprachen
Best Practices fuer die Verwendung der IEC 61131-3-Sprachen.
IEC 61131-9 Einkanal-Digitalkommunikationsschnittstelle (IO-Link)
Standardisiert IO-Link, das dominante Protokoll fuer intelligente Sensoren/Aktoren in modernen Fabriken.
IEC 61131-10 PLCopen XML-Format fuer Programme
PLCopenXML: Standard-XML-Schema zum Speichern von IEC 61131-3-Programmen. Ermoeoelicht herstellerneutralen Programmaustausch.
Schlüsselbegriffe
- Die 5 Sprachen
- Kontaktplan (LD): sieht aus wie ein elektrotechnischer Relaissschaltplan, intuitiv fuer Elektriker. Funktionsblockdiagramm (FBD): sieht aus wie miteinander verdrahtete Schaltbloecke, intuitiv fuer Verfahrensingenieure. Ablaufsprache (SFC): Zustandsautomaten / GRAFCET. Strukturierter Text (ST): aehnelt Pascal, intuitiv fuer Programmierer. Anweisungsliste (IL): assemblerartig, seit 2013 zurueckgezogen.
- Programm-Organisationseinheit
(POE) - Wiederverwendbare Codeeinheit. Drei Typen: Programm (Toplevel, besitzt Speicherzustand), Funktionsbaustein (instanzbasiert, besitzt Speicherzustand), Funktion (zustandslos, wie eine mathematische Funktion). Kompositionsfaehigkeit ist in die Sprache integriert.
- Standard-Datentypen
- BOOL, BYTE, WORD, DWORD, LWORD, SINT/INT/DINT/LINT, USINT/UINT/UDINT/ULINT, REAL, LREAL, TIME, DATE, TIME_OF_DAY, DATE_AND_TIME, STRING. Abgeleitete Typen (ARRAY, STRUCT, Aufzaehlungen, Typ-Aliasnamen) fuer ingenieurmaessige Strukturierung.
- Tasks und Ausfuehrungsmodell
- Zyklische Tasks (alle N ms), ereignisgesteuerte Tasks, freilaufend. Mehrtasking-SPS mit Prioritaetsstufen. Definiertes Verhalten bei Preemption.
- PLCopen
- Branchenverband (Hersteller + Integratoren), der praktische Leitlinien und Referenzbibliotheken auf Basis von IEC 61131-3 veroeffentlicht. Bemerkenswert: PLCopen Motion Control (PLCopen MC) standardisierte Funktionsbausteine fuer die Servosteuerung, die von jedem modernen Motion-Controller verwendet werden.
- Variablenbereich
- VAR / VAR_INPUT / VAR_OUTPUT / VAR_IN_OUT / VAR_GLOBAL / VAR_EXTERNAL. Striktes Typsystem, explizite Deklarationen. Foerdert disziplinierten Code gegenueber den unstrukturierten Gewohnheiten der fruehen SPS-Programmierung.
Notes & guidance
Warum die Sprachenstandardisierung bei SPS 20 Jahre dauerte
Die industrielle Automatisierung der 1970er und 80er Jahre war ein Turmbau zu Babel: Jeder SPS-Hersteller (Modicon, Allen-Bradley, Siemens, Mitsubishi, Omron, Telemecanique…) hatte seine eigene Programmiersprache, seine eigene Entwicklungsumgebung und sein eigenes Konzept der Speicheradressierung. Ein auf Siemens ausgebildeter Ingenieur konnte ohne monatelange Umschulung nicht an einer Allen-Bradley-SPS arbeiten.
IEC 61131-3 (1993, grosse Uberarbeitung 2013) hat das geaendert. Die definierten 5 Sprachen werden heute von jedem grossen SPS-Hersteller in irgendeiner Form unterstuetzt. Ingenieure koennen mit intaktem Vokabular die Plattform wechseln. Codemuster sind prinzipiell portierbar (in der Praxis schaffen herstellerspezifische Erweiterungen noch immer Abhaengigkeiten).
Warum 5 Sprachen und nicht eine einzige?
Jede spricht eine andere Ingenieurstradition an:
Elektriker Verfahrensingenieure Programmierer
\ / /
\ / /
\ / /
[LD] Relaissschaltbild [FBD] Blockschaltbild [ST] Pascal-artig
Verfahrensingenieure
[SFC] Zustandsautomat
(IL war assemblerartig, seit 2013 zurueckgezogen)
Ein modernes Industrieprogramm MISCHT typischerweise:
- ST fuer rechenintensive Logik (PID-Berechnung, Alarme, Rezeptverwaltung)
- FBD fuer die Verschaltung von Regelkreisen (Zusammenbau von PID + Filter + Skalierungsbausteinen)
- LD fuer sicherheitskritische Verriegelungen (Pruefer und Elektriker koennen es ohne Schulung lesen)
- SFC fuer Chargensequenzen und Anlaufprozeduren
Dieser mehrsprachige Code ist normale IEC 61131-3-Praxis und kein Zeichen von Verwirrung.
Was in der Praxis portierbar ist (und was nicht)
Portierbar: Datentypen, grundlegende Algorithmen, einfache Funktionsbausteine, Standard-Motion-FBs (PLCopen MC).
Nicht portierbar:
- E/A-Adressierung (jeder Hersteller hat sein eigenes Schema)
- Hardwarekonfiguration (PROFINET vs. EtherCAT vs. EthernetIP)
- HMI/SCADA-Integration (proprietaer)
- Diagnosefunktionen (herstellerspezifische Erweiterungsbausteine)
- Leistungsmerkmale (Zykluszeit-Garantien)
Das bedeutet, dass der PLCopenXML-Import/Export (Teil 10) ca. 70% eines Automatisierungsprojekts abdeckt; der Rest erfordert noch herstellerspezifische Konfiguration. Fuer eine vollstaendig herstellerneutrale Codebasis ist CODESYS der praktische Marktfuehrer — seine Laufzeitumgebung ist von ca. 50 SPS-Herstellern lizenziert (Beckhoff, WAGO, Lenze, ABB usw.) und bietet echte plattformubergreifende Portabilitaet.
Sicherheitsvariante: IEC 61131-6 + IEC 61508
Standard-SPS sind NICHT sicherheitsgeeignet. Fuer Sicherheitsfunktionen benoetigt man eine Sicherheits-SPS (Pilz PNOZ, HIMA HIMax, Siemens S7-1500F, Allen-Bradley GuardLogix, Beckhoff TwinSAFE), die kombiniert:
- IEC 61131-3-Programmierung fuer die Standard-Logik
- Dedizierte Sicherheitssprache fuer die Sicherheitslogik (Einschraenkungen, eingeschraenkter Satz von Funktionsbausteinen)
- Nach IEC 61508 zertifizierte Laufzeitumgebung (SIL 2 oder SIL 3 faehig)
- Hardware-Redundanz + interne Diagnoseabdeckung
Moderne Sicherheits-SPS werden in IEC 61131-3 mit Sicherheitserweiterungen programmiert, sodass die Erfahrung des Ingenieurs einheitlich ist. Der Sicherheitscode wird jedoch separat auf Werkzeugkettenebene zertifiziert (TUV-/exida-Zertifizierung der IDE + Laufzeitumgebung + Hardwareplattform).
Die Zukunft: IEC 61131-3 und objektorientierte Programmierung
Ausgabe 3 (2013) fuehrte objektorientierte Merkmale ein: METHODEN auf Funktionsbausteinen, SCHNITTSTELLEN, VERERBUNG. Damit naeherte sich die SPS-Programmierung modernen Software-Engineering-Praktiken an, aber die Ubernahme ist uneinheitlich:
- Beckhoff TwinCAT 3: vollstaendige OOP-Unterstuetzung, weit verbreitet
- CODESYS: vollstaendige OOP-Unterstuetzung
- Siemens TIA Portal: partielle OOP (verbessert sich mit jeder Version)
- Rockwell Studio 5000: eingeschraenkt
Bei neuen Projekten gilt die behutsame Nutzung von OOP (Vererbungskomplexitaet vermeiden, aber Methoden + Schnittstellen fuer Testbarkeit nutzen) als anerkannte gute Praxis. Aelterer “alles global” SPS-Code wird zunehmend als Altsystem betrachtet.
Betroffene Branchen
- Diskrete Fertigung (Automobil, Elektronik, Verpackung)
- Prozessindustrien mit SPS-basierter Steuerung (oft hybrid mit DCS)
- Gebaeudeautomation
- Energiemanagement
- Wasser und Abwasser (haeufig SPS-basiert)
- Maschinenbau (jede CNC-Anlage, jeder Roboter, jede Verpackungsmaschine)