Anwenderspezifische Steuerungslösungen werden bislang häufig als Embedded Systeme auf PC-Basis realisiert. Wären nicht in vielen Fällen Embedded Systeme auf SPS-Basis eine Alternative?

Grundsätzlich sind Entwicklungen auf Embedded-Basis für den Anwender eine interessante Möglichkeit, seine Steuerungslösung speziell auf die jeweilige Applikation zuzuschneiden. Dabei begegnen ihm bei den herkömmlichen Lösungen allerdings zunehmend Unwägbarkeiten: Nicht eingehaltene Termine und überzogene Projektkosten belegen, dass proprietäre CPU-Entwicklungen immer aufwendiger, teurer und riskanter werden. Ursächlich dafür sind die stetig steigenden Anforderungen an das Betriebssystem und die Programmierwerkzeuge. Die Investitionen in eine CPU-Entwicklung müssten auf eine entsprechend breite Kundenbasis umgelegt werden - diese fehlt jedoch meistens. Selbst Anbieter von SPS-Systemen bleiben von dieser Entwicklung nicht verschont, wie das Outsourcing der Entwicklung für Programmierwerkzeuge an spezialisierte Softwarefirmen - Stichwort IEC 1131-3 belegt. Erschwerend kommt der Druck des Endkunden hinzu, der keine proprietären Steuerungskonzepte akzeptiert, die sich nur schwer in eine bestehende Infrastruktur integrieren und weder warten noch pflegen lassen.

SPS-Programmierung - besser als ihr Ruf

Eine weitere Schwierigkeit liegt darin, dass die Programmierung von Embedded Systemen meist in Hochsprache beziehungsweise C erfolgt. Diese aus der EDV-Welt stammenden Sprachen eignen sich nur bedingt für den Einsatz in Steuerungssystemen; die hardwarenahe und zeitkritische Programmierung fördert nicht gerade die Lesbarkeit der entsprechenden Programme. Die Hochsprachen-Technologie fördert ein Spezialistentum, bei dem das Know-how letztlich nur noch in den Köpfen weniger Programmierer existiert, die kaum ewig im Unternehmen bleiben. Anders sieht es aus - entgegen allen Vorurteilen - beim Rückgriff auf eine standardisierte SPS-Programmierung, beispielsweise Step7 von Siemens. Bei an Hochsprachen gewöhnten Programmierern von Embedded Systemen hat die SPS-Programmierung allerdings oft ein hausbackenes Image: Grafische Programmiermethoden wie Kontaktplan und Funktionsplan gelten als sekundär; zwangsläufig kommt es zu Vergleichen mit der Programmierung in Anweisungsliste, die in der Vergangenheit einer Assembler-Programmierung gleichkam. Mit Rückblick auf die S5-Ära sind diese Bedenken kaum verwunderlich, häufen sich doch hier Erinnerungen beispielsweise an umständliche Bearbeitungs-Befehle, wenn der Zugriff auf Variablen indirekt erfolgen sollte, oder an das schlichte Fehlen lokaler Variablen mit all den Problemen wegen doppelt adressierter Variablen ("Schmiermerker"). Diese Unzulänglichkeiten führten zum Aufkommen der IEC 1131-3, deren neue Ansätze mittlerweile auch in die Step7-Programmierung eingeflossen sind: Unter dem Blickwinkel der Steuerungstechnik in punkto Datenstrukturen und Datenverwaltung, Rechenoperationen sowie Programmstrukturierung steht sie den Hochsprachen in nichts nach. Step7-Anwendern sind die neuen Möglichkeiten im Vergleich zu Step5 häufig gar nicht bewusst: die indirekte Adressierung, die Pointertechnik, Multi-Instanzen von Funktionsbausteinen sowie lokale Variable.

Indirekte Adressierung und Pointertechnik
Bei den meisten Step7-Befehlen sind die Operanden indirekt adressierbar. Hierbei kann der Index in den SPS-Daten hinterlegt sein ( zum Beispiel Merkerwort) und so einfach manipuliert werden. Dadurch lassen sich Tabellen oder Matrizen berechnen, oder auch nur ein Ergebnis aus einer vorberechneten Tabelle laden, um aufwendige Berechnungen während der Laufzeit zu vermeiden. Für denselben Zweck gibt es zusätzlich spezielle Adressregister. ANY-Pointer ermöglichen ebenfalls den Zugriff auf sämtliche SPS-Daten. Bei all diesen Adressierungsarten ist gewährleistet, dass die Zugriffe sich auf den Datenbereich beschränken. Das SPS- Betriebssystem überprüft bei jedem Zugriff die zulässigen Bereichsgrenzen, was im Gegensatz etwa zur C-Programmierung ein versehentliches Schreiben in das Programm oder gar in die Betriebssystemdaten verhindert.

Multi-Instanzen von Funktionsbausteinen
Die Multi-Instanz-Technik von Step7 dient zur Generierung von "wiederverwertbarem Code" (Programmteilen): Bei jedem Aufruf eines Funktionsbausteins öffnet sich bei Step7 ein individueller Datenbaustein. In diesem Datenbaustein werden bausteininterne Daten hinterlegt, die bis zum nächsten Aufruf des Funktionsbausteins erhalten bleiben müssen. Dies entspricht etwa den statischen Variablen in der C-Programmierung. Da der Funktionsbaustein bei jedem Aufruf mit einem anderen Datenbaustein parametriert wird, ist der gleiche Funktionsbaustein mehrmals im Steuerungsprogramm für unterschiedliche Aufgaben verwendbar. Für jede Verwendung (Instanz) ist nur ein separater Datenbaustein zu wählen. Dieser Datenbaustein stellt das Gedächtnis der Instanz dar und speichert die internen Zustände des Funktionsbausteines. Bei konsequenter Anwendung dieser Technik lässt sich eine Datenkapselung erzielen, die die Wartbarkeit und Wiederverwendbarkeit auch in anderen Steuerungsprogrammen erleichtert.

Lokale Variable
Lokaldaten sind Daten, die nur während eines Funktionsbaustein-Aufrufs gültig sind. Bei jedem Bausteinaufruf werden die jeweiligen Lokaldaten an der nächsten freien Stelle in einem Stack angelegt - der Stack wächst; nach Verlassen des Funktionsbausteins werden sie verworfen - der Stack schrumpft. Dadurch bleiben diese Daten auch bei einem Wechsel der Bearbeitungsebene erhalten (zum Beispiel bei einem zyklischen Zeitinterrupt oder Weckalarm). Unliebsame Seiteneffekte durch Überschneidungen in den Variablen lassen sich damit vermeiden - "Schmiermerker" gibt es nicht mehr.

Blockdiagramm des SPS-Moduls Smart7: Der auf die elementaren SPS-Funktionen reduzierte CPU-Kern ist die Grundlage einer Embedded-Lösung auf SPS-Basis.

Hochsprachen- oder SPS-Programmierung?

Diese Merkmale sind zwar auch in der Hochsprachenprogrammierung bekannt. Darüber hinaus gibt es jedoch Gründe, die für ein SPS-Betriebssystem bei einer Embedded-Lösung sprechen. Diese betreffen zum einen die Betriebssicherheit und Zuverlässigkeit eines SPS- Betriebssystems im Vergleich mit einem herkömmlichen Echtzeit- oder gar Microsoft-Betriebssystem: Durch die enge Verquickung von SPS-Hardware und Betriebssystem sowie die permanente Überwachung der Programmbearbeitung lässt sich ein Großteil von Laufzeitfehlern erfassen und diagnostizieren. Ein Stack-Überlauf oder das ungewollte Schreiben in sensible Speicherbereiche werden abgefangen. Die SPS schaltet ab, bevor Gefahrensituationen entstehen können. Die Diagnosefähigkeit bei Laufzeitfehlern macht die Verwendung einer SPS auch für den Programmierer komfortabel, da Laufzeitfehler oft die Ursache besonders hartnäckiger sporadischer Ausfälle sind. Auf der anderen Seite stehen die Turn-around-Zeiten: Da Hochsprachenprogramme kompiliert und komplett in die Steuerung geladen werden müssen, bedeutet dies für jeden Download eine Unterbrechung des Steuerungsprozesses. Programmänderung, Kompilierung und Download addieren sich zu beträchtlichen Turn-around-Zeiten - nur um vielleicht zu Testzwecken ein Detail im Programm zu ändern. Bei länger andauernden kontinuierlichen Prozessen, die keine Unterbrechung erlauben - wie etwa in der Verfahrenstechnik - kann dies zu beträchtlichen Problemen führen. Aber auch bei der Inbetriebnahme "harmloserer" Anwendungen ist es ärgerlich, nach jeder Änderung eine Pause einlegen zu müssen.
Ein SPS-Programm hingegen ist in einzelne Programmbausteine unterteilt, die sich losgelöst vom Rest des Programms bearbeiten lassen. Da die Datenbereiche klar definiert und entflochten sind, ist bei Änderungen nur ein Baustein zu laden, was selbst bei laufender Maschine geschehen kann. Während der alte Baustein noch läuft, wird der geänderte Baustein in den Programmspeicher geladen und so an das bereits geladene Programm angefügt. Erst wenn der geänderte Baustein komplett geladen ist, wird er beim nächsten Aufruf angesprungen und der alte Baustein gelöscht. Auch Embedded-SPS-Systeme wie etwa Smart7 von Saia-Burgess wenden die Methode der Kompilierung an und beschleunigen so die Programmbearbeitung. Im Gegensatz zum Hochsprachenansatz entsteht hier aber nicht eine einzige, grosse Programmdatei, sondern jeder Programmbaustein wird entsprechend der SPS-Programmierung einzeln übersetzt, so dass auch Testmöglichkeiten bei laufendem Programm gegeben sind. Das Speicher-Management des SPS-Betriebssystems ist speziell darauf hin ausgelegt, dass die Programmabarbeitung parallel zu Programm-Download und Testfunktionen stattfinden kann. Die Kompilierung selbst erfolgt im Gegensatz zur Hochsprache nicht auf einem PC, sondern automatisch in der SPS-CPU und ist für den Programmierer völlig transparent. Entsprechend minimiert sind die Turn-around-Zeiten bei Programmänderungen.

Stärler an das Automatisierungsumfeld angepasst als Embedded Systeme auf Hochsprachenbasis: Das Step7-programmierbare Betriebssystem des CPU-Kerns Smart7.

Zweierlei Testphilosophie

Eine grundlegende Diskrepanz zwischen Hochsprachen-Programmierung und SPS-Programmierung gibt es auch in punkto Testmöglichkeiten und Debug- Werkzeuge. Sie beruht auf den zugrundeliegenden Testphilosophien:
Bei den Hochsprachen mit ihrem Ursprung in der EDV-Welt geht es in stark abstrahierter Sichtweise um Berechnungen in jedweder Form, die gespeichert, weiterverarbeitet oder auch nur ausgedruckt werden. Diese Art der Datenverarbeitung ist entkoppelt von der realen Umwelt zu betrachten - das heißt, sie hat keine Interaktion mit einem realen System. Ziel ist, soviel wie möglich in kürzester Zeit zu berechnen. Das Endergebnis ist letztlich unabhängig von der Rechengeschwindigkeit. Daher stört es auch nicht, wenn der Programmlauf zu Testzwecken unterbrochen wird, um Zwischen ergebnisse zu untersuchen. Hochsprachenprogramme werden daher mit Methoden wie Breakpoints und Einzelschrittbetrieb getestet, wobei der Programmablauf gezielt stoppt.
Bei Steuerungsanwendungen sind diese Testmethoden hingegen kaum geeignet: Geht es um den Test von Steuerprogrammen für Maschinen oder Prozesse, ist es nicht möglich, den Programmablauf an x-beliebiger Stelle zu unterbrechen, da eine Steuerung in Interaktion mit einem realen System, der Maschine, steht.
Ist beispielsweise der Positioniervorgang eines Antriebes, mit dem von Punkt A nach Punkt B zu fahren ist, einmal in Gang, darf nicht einfach die Programmabarbeitung unterbrochen werden: Die unkontrollierte Fahrt des Antriebes hätte schwere Schäden zur Folge.
Aber nicht nur die Vermeidung von Schäden widerspricht der Verwendung der Testmethoden aus der Hochsprachenprogrammierung dynamische Vorgänge lassen sich auf diese Weise überhaupt nicht wahrnehmen: denn gerade die Konstellation in der Maschine, die ein eventuelles Fehlverhalten hervorruft, lässt sich ohne laufendes Programm gar nicht erfassen. Bei solchen dynamischen Problemstellungen greifen die Online- Testmethoden der SPS. Online heißt, dass sämtliche Tests parallel zum laufenden Programm durchführbar sind, ebenso wie der Download von Programmteilen. Parallel zur Programmbearbeitung lassen sich interne SPS-Daten oder Variable sowie Ein- und Ausgänge direkt anzeigen und modifizieren. Die Funktion Programmstatus zeigt zu jeder Programmzeile verschiedenste Statusinformationen und interne Zustände an und zwar genau so, wie sie zum Zeitpunkt der Abarbeitung der jeweiligen Programmzeile tatsächlich sind. Parallel zur Programmbearbeitung zeichnet das SPS-Betriebssystem Fehlerzustände in interne auslesbare Diagnosepuffer auf. Generell sind sämtliche Testfunktionen der SPS darauf ausgelegt, den zu steuernden Prozess am Laufen zu halten.
Ein CPU-Kern, der derart mit Step7 programmiert ist und die komplette SPS- Funktion bereitstellt, bietet folgende Vorteile:
Eine teure CPU-Entwicklung entfällt, das Entwicklungsrisiko ist reduziert, das Produkt ist schneller auf dem Markt verfügbar, die CPU-Funktion braucht keine Wartung und Pflege, die Flexibilität in der Adaption an die Anwendung bleibt erhalten. Auch Fachpersonal mit Automatisierungs-Kenntnissen ist ausreichend vorhanden. 

STEP und Siemens sind eingetragene Warenzeichen der Siemens AG

Veröffentlicht in:

Computer & Automation, Ausgabe 4, 2002