DE10026387B4

DE10026387B4 - Verfahren zur Ausführungszeitoptimierung für Umsetzungen von zustands- bzw. ablauforientierten Modellen, wie Petrinetze oder Automaten

Info

Publication number: DE10026387B4
Application number: DE10026387A
Authority: DE
Inventors: Jens Von Aspern
Original assignee: Aspern Jens Von Dipl-Ing
Current assignee: Aspern Jens Von Dipl-Ing
Priority date: 2000-05-27
Filing date: 2000-05-27
Publication date: 2007-04-19
Anticipated expiration: 2020-05-28
Also published as: DE10026387A1; WO2001093114A3; AU2001267443A1; WO2001093114A2

Abstract

Verfahren zur Ausführungszeitoptimierung für Umsetzungen von zustands- oder ablauforientierten Modellen, wie Petrinetzen oder Automaten, in reale Lösungen der Automatisierungstechnik für softwarebasierte Lösungen,
dadurch gekennzeichnet, dass
– eine Kausalkettenoptimierung sowie eine Elementoptimierung jeweils einzeln oder gemeinsam mindestens auf einen Teil des Modells durch Abbildung in einer Programmiersprache unter Nutzung der Eigenschaften der Zielsprache angewandt wird,
– wobei bei der Kausalkettenoptimierung eine Kausalkette, ein Teil einer langen Kette oder eine Gruppe von Kausalketten nur bedingt bearbeitet werden, wobei die Bedingung(en) auf der Auswertung des aktuellen Zustands des Modells beruhen und nur im Falle mindestens eines aktiven Zustands innerhalb der Kausalkette, eines Teils einer Kausalkette oder einer Gruppe von Kausalketten, die Bearbeitung ermöglichen,
– wobei das Modell funktionale Modellelemente, die jeweils aus einer oder mehreren Bedingungen und aus einem oder mehreren bedingungsabhängigen Teilen bestehen, aufweist,
– und wobei Verzweigungsstellen in einem oder mehreren bedingungsabhängigen Teilen eines Modellelementes zwecks...

Description

Die Erfindung betrifft ein Verfahren zur Ausführungsoptimierung für Umsetzungen von zustands- oder ablauforientierten Modellen, wie Petrinetzen oder Automaten, in reale Lösungen der Automatisierungstechnik für softwarebasierte Lösungen.

1. Anwendungsgebiete

Anwendungsgebiete der Ausführungszeitoptimierung für Umsetzungen von zustands- bzw. ablauforientierten Modellen in reale Lösungen sind alle Automaten (Begriff der Automaten- bzw. Grafentheorie) und Petrinetze (petrinetzähnlichen), die typischerweise genannt werden, deren Arbeitsweise zustands- bzw. ablauforientiert ist, dazu gehören auch die Modelle der IEC 61131, IEC 61499 und Grafcet. Diese werden in diesem Patentanspruch kurz Modell genannt. Dabei ist es unbedeutend, ob eine Realisierung (Umsetzung in eine realisierte Lösung) in Software oder Hardware, beidem oder anderen Umsetzungen erfolgt. Es ist jedoch insbesondere geeignet zur Lösung von softwarebasierten Steuerungsaufgaben, die mittels Programmgenerator und/oder Compiler bzw. Assembler, Interpreter, durch ein spezielles Betriebssystem bzw. Laufzeitbibliotheken (Runtime) wie beispielsweise bei einer SPS (Speicherprogrammierbare Steuerung) und/oder prozessornahen Sprachen, realisiert werden. Ein mit Ao erzeugter Quellcode (Lösungen) ist demnach insbesondere die Basis für ein Programm, dessen Bearbeitungszeit (Zeit die ein Prozessor benötigt um es auszuführen) sich deutlich verkürzt. Dies ist insbesondere für die Echtzeitfähigkeit von Steuerungslösungen (Automatisierungstechnik) von großem Interesse. Die tatsächlich erreichte Geschwindigkeitszunahme ist abhängig von der Topologie des Modells und letztendlich von der gewählten Platfform (Compiler Werkzeug, Hardware, auf der die Steuerungslösung implementiert wird, der gewählten Programmiersprache, wie C, Pascal, Assembler, Programmiersprachen der DIN EN 61131-3, wie AWL, ST und ggf. weiterem).

1.1 Stand der Technik und deren Probleme

Petrinetze (kurz: Netz oder Petrinetz (PN)) sind bereits seit 1962 (Automatentheorie besteht bereits länger) als typische Vertreter von zustands- bzw. ablauforientierten Modellen für diskrete Abläufe bekannt. Es gibt div. Varianten und Klassen der Theorien, die ausführlich in div. Veröffentlichungen diskutiert sind. Die Theorie findet nur in Ausnahmefällen praktische, industrielle Anwendung, obwohl die Zahl der Anwendungen in den letzten Jahren zunimmt. In der Steuerungstechnik können diese Modelle jedoch effektiv plattformunabhängig eingesetzt werden. Eine mit der DIN EN 61131-3 stark abgewandelte Form der Petrinetze ist seit 1995 bzw. 1993 (International) als Ablaufsprache (AS) bzw. Sequential Function Chart (SFC) genormt.

Die Abbildung bzw. Umsetzung eines Modells auf eine Programmiersprache erfolgt bisher in linearer Form. Lineare Form meint hier nicht einen Verzicht auf Unterprogrammtechniken. Vielmehr ist die Abbildung nach bestimmtem Schema, das die Modellelemente oder das Modell weitgehend zusammenhängend abbildet und keine Strukturierung bietet, die eine verbesserte Performance ergibt. Es sind zwei lineare Formen zur Modellelementabbildung bekannt, eine arbeitet vorwiegend mit speichernden und speicherlöschenden Befehlen ([vA93]: v. Aspern, J.: SPS-Softwareentwicklung mit Petrinetzen. Heidelberg: Hüthig (1993). ISBN 3-7785-2197-7, [vA94]: v. Aspern, J.: SPS-Softwareentwicklung: Petrinetze und Wortverarbeitung. Heidelberg: Hüthig (1994). ISBN 3-7785-2279-5 und [F94]: Friedrich, A.: Mit SPS erfolgreich Automatisieren. Poing: Franzis-Verlag (1994). ISBN 3-7723-6813-1) die andere mit Befehlen, die im Wesentlichen die boolesche Algebra nutzt und weitgehend auf speichernde und speicherlöschende Befehle verzichtet ([A94]: Auer, A.: Steuerungstechnik und Synthese von SPS-Programmen. Hüthig (1994). ISBN 3-7785-2215-9 beispielsweise Seiten 135–137). Wohl dem Stand der Technik zuzurechnen, obwohl kein veröffentlichter Nachweis bekannt ist, ist die Abbildung der Modellelemente mittels so genannter Hochsprachen (C, Pascal), die über Wenn-Dann-Anweisungen verfügen. Hier ist bereits eine Strukturierung der Modellelemente durch die Plattform gegeben, diese unterliegt nicht dem Anspruch gemäß Patentanspruch 3, insofern das dies eine (die einzige) Methode der Programmiersprache ist. Jedoch unterliegt eine weitere Strukturierung der Bedingung Aufteilung in mehrere Teilbedingungen dem Patentanspruch.

Ferner ist bekannt, dass die Abbildung von Kausalketten ([vA93], [vA94], [A94] und [F94]) durch Aneinanderreihung des Programmcodes der Ketten, ohne zusätzliche Überprüfung der Notwendigkeit einer generellen Bearbeitung durchzuführen, erfolgt. Hier unterliegt daher die Abbildung auf Hochsprachen gemäß Patentanspruch 2 dem Patentanspruch.

Hardwarebasierte Lösungen sind in König, R.; Quäck, L.: Petri-Netze in der Steuerungs- und Digitaltechnik. München und Wien: R. Oldenburg Verlag (1988). ISBN 3-486-20735-0 zu finden.

Zur überflüssigen Verlängerung der Bearbeitungszeit durch Prozessoren bei linearer Codeerzeugung führen zwei Aspekte bzw. Probleme, die je nach Plattform gemeinsam oder einzeln wirken.

1. Linear abgebildete Modelle werden meist vom Prozessorsystem komplett (gesamtes Modell) abgearbeitet, womit die Kausalstruktur der Modell-Topologie unberücksichtigt bleibt. Ein Zustandswechsel in einem Modell kann nur an aktiven Zuständen (markierte Zustände) erfolgen. Gerade längere Kausalketten oder Teile einer solchen Kausalkette, die keinen aktiven Zustand zur Zeit der aktuellen Programmausführung besitzen, müssen demnach nicht bearbeitet werden, was die lineare Abbildung des Modells nicht berücksichtigt.
2. SPS-Plattformen (z.B. AWL der DIN EN 61131-3 oder die SPS-Sprache Step 5^® (AWL) der Firma Siemens^®) oder ähnliche bearbeiten meist den Code Zeile für Zeile. D.h., dass abgebildete Modellelemente ([vA93], [vA94], [A94] und [F94]), die häufig über eine Ausführungsbedingung (hier verallgemeinert Schaltbedingung genannt) verfügen, und einem von ihr abhängigen bedingt auszuführenden Teil (hier verallgemeinert Schalthandlung genannt), komplett bearbeitet werden, obwohl dies für die Schalthandlung nur im Falle der erfüllten Schaltbedingung nötig wäre.

Die Erfindung wird im Folgenden anhand weiterer Abbildungen noch genauer beschrieben.

Die Erfindung bezieht sich auf ein Verfahren zur Ausführungszeitoptimierung für Umsetzungen von zustands- oder ablauforientierten Modellen, wie Petrinetze oder Automaten.

Derartige Verfahren sind bekannt.

Greim, Th.: Ein Beitrag zur steuerungstechnischen Anwendung von Petri-Netzen. In: at-Automatisierungstechnik 44 (1996) 6, S 274–280
beschreibt die Einführung zusätzlicher Netzelemente: (Vollkomponenten), deren wesentliche Aufgabe es ist, ein technisch interpretiertes Netz In ein Standardnetz zu überführen, für das analytische Methoden anwendbar sind. Die eingeführten Vollkomponenten bilden das Verhalten der Ein- und Ausgangsvariablen der Steuerung ab, die die Kopplung zwischen Prozessnetz und Steuerungsnetz bilden. Es wird nichts über eine Codierung geschweige denn von einer optimierten Codierung gesagt, die auch nicht Ziel (Analyse technisch interpretierter Netze) der Arbeit ist. Für eine Codierung des so gewonnenen Netzes führen die zusätzlichen Elemente zu einer verlängerten Ausführungszeit. Die Umsetzung zur Simulation und Konstruktion des Erreichbarkeitsgrafen scheint mittels einer Matrix zu erfolgen. Die notwendige Beeinflussung der Reihenfolge führt ebenfalls zu einer vergrößerten Abarbeitungszeit.

Moßig, Kai: Steuerungsynthese mit kontrollierten Free-Choice Petri-Netzen zu, Prozessbeschreibung. In: at-Automatisierungstechnik 43 (1995) 11, S. 506–513
befasst sich mit dem methodischen Entwurf von Steuerungen auf Basis eines Prozessmodells (Petrinetz), das die Steuerungsstrecke abbildet. Ziel ist, ein Steuerungsprogramm zu finden, das den Steuerungsvektor generiert, welches unzulässige (verbotene) Prozesszustände verhindert. Unter Optimierung wird hier verstanden, dass der Steuerungsvektor möglichst wenig Zustandsübergänge blockiert, um einen hohen Durchsatz im Prozess zu erreichen. Die Steuerung wird mittels boolescher Funktionen realisiert. Leider ist im Beispiel nicht angegeben, wie die Funktionen zur Steuerungsvektorgenerierung aussehen. Es soll aber eine Pfadvariable existieren, die den Markierungszustand des Vorpfades bezogen auf eine bestimmte Stelle wiedergibt. Pfadvariable dienen ausschließlich der Konstruktion komplexer boolescher Funktionen mit dem Ziel, den Steuerungsvektor zu finden. Sie besagt weder, dass die Steuerung noch die Prozesssimulation die Pfadvariablen nutzt, um die Bearbeitung (Ausführung) einer Kette zu steuern. Die Pfadvariable hingegen bestimmt nie, ob die Kette zu bearbeiten ist, vielmehr ist sie Teil der Bedingung im Sinne eines Sensors der Steuerung, die dann den Markenfuss beeinflusst.

2. Aufgabe der Erfindung

Es ist Aufgabe der Erfindung, die Ausführungszeit für Umsetzungen von zustands- oder ablauforientierten Modellen, wie Petrinetzen oder Automaten in reale technische Lösungen für softwarebasierte Lösungen zu optimieren.

Die Aufgabe wird durch ein Verfahren zur Ausführungszeitoptimierung für Umsetzungen von zustands- oder ablauforientierten Modellen, wie Petrinetzen oder Automaten, in reale Lösungen der Automatisierungstechnik für softwarebasierte Lösungen gelöst, wobei,

– eine Kausalkettenoptimierung sowie eine Elementoptimierung jeweils einzeln oder gemeinsam mindestens auf einen Teil des Modells durch Abbildung in einer Programmiersprache unter Nutzung der Eigenschaften der Zielsprache angewandt wird
– wobei bei der Kausalkettenoptimierung eine Kausalkette, ein Teil einer langen Kette oder eine Gruppe von Kausalketten nur bedingt bearbeitet werden, wobei die Bedingung(en) auf der Auswertung des aktuellen Zustands des Modells beruhen und nur im Falle mindestens eines aktiven Zustands innerhalb der Kausalkette, eines Teils einer Kausalkette oder einer Gruppe von Kausalketten, die Bearbeitung ermöglichen,
– wobei das Modell funktionale Modellelemente, die jeweils aus einer oder mehreren Bedingungen und aus einem oder mehreren bedingungsabhängigen Teilen bestehen, aufweist,
– und wobei Verzweigungsstellen in einem oder mehreren bedingungsabhängigen Teilen eines Modellelementes zwecks Elementoptimierung hinzugefügt werden, die von einer Bedingung abhängig festlegen, ob die Bearbeitung des bedingungsabhängigen Teils oder dieser Teile eines Modellelementes weitergeführt oder beendet wird.

Die Kettenoptimierung (Ko) ist anwendbar auf alle Abbildungen eines Modells und kann mit der Elementoptimierung (Eo) gleichzeitig angewendet sein, wobei die Strategien innerhalb einer Abbildung beliebig wechseln, mehrfach und gleichzeitig anzuwenden sind.

Ko geht davon aus, dass zusammenhängende Kausalketten (unverzweigte Folge von Modellelementen) (1(3)) in denen es keinen aktiven (markierten) Zustand gibt, nicht bearbeitet werden müssen. Dies begründet sich damit, dass nur von einem aktiven Zustand ein Zustandswechsel ausgehen kann. Ein aktiver Zustand wird aufgefasst, als ein Zustand der eine Markierung aufweist, die zu mindestens einem Zustandswechsel (schalten einer Transition) beitragen kann. Demnach müssen nur Kausalketten bearbeitet werden, in denen es eine Markierung (Menge aller aktiven Zustände) gibt. Je mehr Modellelemente sich in einer Kausalkette befinden, desto höher ist der Einsparungseffekt. Zur Koordinierung der Ausführung von Kausalketten wird beispielsweise sobald eine Marke in die Kette eintritt ein oder mehrere Flags (versteckter Zustand) (1(1)) gesetzt.

Anhand des Flags ist zu entscheiden, ob die Kette bearbeitet wird oder nicht. Im Moment des Verlassens der letzten Marke einer Kette wird das Flag wieder zurückgesetzt (Tn), wodurch die Bearbeitung danach ausbleibt. Das hier verwandte Flag ist eine Variante der Elementverwaltung.

Können in einer Kausalkette mehrere Zustände markiert sein, kann das Flag auch ein FIFO, ein Zähler oder ein anderer Mechanismus sein. Das Flag wird hier nur beispielhaft verwendet.

Eine Erweiterung dieses Prinzips führt zu einem Optimierungsnetz, das die Ausführungsverwaltung des eigentlichen Steuerungsnetzes übernimmt.

Sehr lange Kausalketten (1(3)) können unter dem Gesichtspunkt der gesteigerten Performance über mehrere Ko-Flags (1(1)) verfügen, die jeweils einen Teil der gesamten Kette kontrollieren, somit wird auch noch ein Einsparungseffekt erzielt, wenn ein aktiver Zustand sich in einem Teil einer Kette befindet.

Da der Grad der Optimierung im wesentlichen von der Länge der Kausalketten (1(4)) abhängt und ggf. von der Zeit, die eine Kausalkette markenfrei ist, und der Eigenschaften, die die Zielsprache (z.B. Sprünge mit dynamischen Zielen) bietet, kann eine Berechnung (ggf. empirisch) erfolgen, deren Ergebnis eine Auskunft gibt, ob eine Ko einer Kette lohnt oder nicht. Damit kann die Abbildung eines Modells Ketten mit und ohne Ko enthalten.

I.d.R. werden Ko-Flags, auch wenn sie durch Modellelemente dargestellt werden können, nicht im Modell explizit mit angegeben, da sie lediglich die Funktion der Codeoptimierung übernehmen. Ggf. kann die explizite Darstellung in Software-Werkzeugen (Tools) als eine Betriebsart dieser Tools hilfreich sein.

Eine effiziente Variante, sofern die Programmiersprache und/oder das Betriebssystem und/oder die Entwicklungsumgebung dies unterstützt, ist, dass ein Vorgänger-Element (beim Schalten) alle Nachfolger-Elemente, die anschließend aufgrund des Modellzustandes einen Zustandswechsel herbeiführen können, in eine dynamische Liste einträgt und sich selbst und ggf. weitere aus dieser Liste entfernt. Die Liste enthält alle Modellelemente, die Aufgrund des Modellzustandes bearbeitet werden müssen, oder nicht bearbeitet werden müssen, je nach dem was nutzbringender ist. Oft ist der Verwaltungsaufwand der Listen sehr hoch, so dass der Nutzen erst ab einer bestimmten Netzgröße gegeben ist. In diesem Fall können die Flags einen Pointer oder ähnliche Mechanismen darstellen.

Der obere Programmcode zeigt, dass nur die Programmzeilen bis zum Befehl RET der ständigen Bearbeitung unterliegen, während der Teil von T2 bis zur letzten Zeile nur bearbeitet wird, wenn das Ko-Flag es gestattet.

Der untere Programmcode unterliegt vollständig (jede Zeile) der Bearbeitung.

Die Elementoptimierung (Eo) ist im Wesentlichen für SPS und SPS-ähnliche Bearbeitungsmechanismen geeignet. Lässt sich neben den Modellelementen die für die Zustandsübergänge zuständig sind auch für Zustände (Lupen) und Aktionen (IEC61131) und andere Modellelemente anwenden.

Dabei erfolgt die Abbildung der einzelnen Modellelemente strukturiert.

D.h., die Schaltbedingung (oder ähnliche Mechanismen) wird von der Schalthandlung (oder ähnliche Mechanismen) getrennt.

Abbildung des Modells aus 1 mit der SPS-Programmiersprache AWL genormt mit DIN EN 61131-3. oben mit Ko und unten ohne Ko (Auf die notwendige Variablendeklaration wurde verzichtet).

In diesem Beispiel ist die durch Ko kontrollierte Kausalkette (kurz Ko-Kette) zwar immer markiert, wenn auch P2 markiert ist, so dass der Einsparungseffekt nur bei einer Markierung von P1 eintritt, aber zur Erläuterung der Wirkungsweise ist es hinreichend. Ferner wurde auf komplexere Schaltbedingungen der Einfachheit halber verzichtet.

Letztere wird nur bearbeitet, wenn die Bedingung der Schalthandlung erfüllt ist und das so genannte Schalten (oder ähnliches) stattfindet. Dies könnte beispielsweise mit einem Sprungverteiler, einer Liste oder Tabelle erfolgen.

Realisierte Umsetzung des Modellelementes T1 aus 3 (oben mit Eo und unten ohne Eo) mit der SPS-Programmiersprache AWL, genormt mit DIN EN 61131-3

Da die Einführung eines Programmsprungs (Programmverzweigung) hin zur Schalthandlung und wieder zurück zum Sprungverteiler zusätzlich Rechenzeit kostet, kann eine plattformabhängige Berechnung einer möglichen Optimierung erfolgen. Diese ermittelt, ob das Modellelement besser linear oder strukturiert abgebildet wird. Ausschlaggebende Faktoren einer solchen Berechnung sind die Anzahl der Kanten (Kante: (Baumgarten, B.: Petri-Netze: Grundlagen und Anwendungen. Mannheim, Wien, Zürich: Wissenschaftsverlag 1990. ISBN 3-411-14291: Seite 17) bzw. deren benötigte Rechenzeit, die benötigte Rechenzeit der Programmverzweigung (Sprünge). In ungünstigen Fällen kann es auch zu einer Verschlechterung der benötigten Rechenzeit kommen.

Somit kann die Abbildung der Elemente ein und desselben Modells, je nach dem ob die lineare oder die strukturierte Abbildung schneller ist, beide Abbildungsvarianten beinhalten.

Die gesamte Netzoptimierung (Ko und Eo) lässt sich auch als Baumstruktur abbilden, in der Elemente tieferer Ebenen über mehr Kontrollstrukturen verwaltet (ausgeführt) werden als Elemente in höheren Ebenen. Elemente der höchsten Ebene werden immer bearbeitet.

3. Optimierung

3.1 Optimierung, was ist das?

Der Vorgang einer gezielten Auswahl, eines gezielten Entwurfs oder beidem von Anweisungssequenzen, Algorithmen und Daten bzw. Datenstrukturen zur Erzeugung kleiner, schneller Programme, heißt Optimierung.

Bedeutend für die Auswahl von Compiler und Codegeneratoren kann die Fähigkeit der automatischen Optimierung unter Berücksichtigung zielsystemspezifischer Merkmale (Hardware, Betriebssystem, Runtime) und Eigenschaften der jeweiligen Sprache (grafisch, textuell), sein. Gerade durch die Normung der SPS-Sprachen suchen Anbieter immer wieder nach Differenzierungsmerkmalen ihrer Produkte zu denen der Mitbewerber. Die Leistungsfähigkeit automatischer Optimierungen stellt eine nützliche und vor allem vergleichbare Differenzierung, ohne große Verfärbungsmöglichkeit des Marketing, dar, sofern einheitliche Benchmarks existieren.

Aspekte der Optimierung sind auch vom Anwendungsprogrammierer zu berücksichtigen. Er ist dabei oft auf Herstellerangaben bezüglich der Bearbeitungszeiten von Operatoren in Verbindung mit bestimmten Datentypen, von Schnittstellen, vom Adressierungsschema, dem Speicherbedarf und anderem angewiesen. Herstellerangaben sind jedoch nur selten zu finden. Leider existieren häufig nur pauschale und allgemeine Angaben, die nur über eine sehr begrenzte Tauglichkeit hinsichtlich einer präzisen Analyse aufweisen.

Effiziente Optimierung muss als ein kontinuierlicher, entwicklungsbegleitender Prozess verstanden sein. Optimierungsbemühungen am Ende der Entwicklung sind häufig aufwendiger und weniger effektiv. Optimierung ist gleichermaßen Wissenschaft und Kunst. Die Wissenschaft stellt die Methoden der Optimierung, und die Kunst ist die Beherrschung und der effiziente Einsatz der Methoden. Bereits vor Entwicklungsbeginn sollte das Optimierungsziel bestimmt sein. Allgemeine Zielsetzung besteht hinsichtlich

der Reaktionsgeschwindigkeit (Echtzeitverhalten),
des Kommunikationsaufwandes (Flaschenhals Feldbus), sowie
des Speicherbedarfs (Programm und Daten),

für Steuerungen und zusätzlich für Applikationen mit visueller Oberfläche in

der Anzeigegeschwindigkeit (Schnelligkeit des Bildschirmaufbaus),
der subjektiven Geschwindigkeit (Wirkung auf den User) und,
dem Speicherbedarf für Grafiken.

Leider wirken Optimierungen des einen Merkmals oft zu Lasten des anderen. Es besteht selten die Möglichkeit, alle Merkmale zu optimieren. Häufig wirkt sich beispielsweise die Optimierung der Bearbeitungszeit ungünstig auf den Speicherbedarf aus. Verkleinern oder Beschleunigen der Anwendung kann auch eine Transparenz durch Erzeugung kompakter, aber schwer lesbarer Codes mindern. Eine eindeutige Zielsetzung hilft, die Widersprüche der Optimierungsverfahren zu entscheiden.

Zeit ist Geld. Indirekt gilt dies auch für Programme. Ist der Source so ausgelegt, dass er nur minimale Rechenzeit beansprucht, steht bei gleicher Rechenleistung mehr Raum für die Implementierung weiterer Aufgaben zur Verfügung, bzw. die Reaktionsgeschwindigkeit steigt an. Mit erhöhter Reaktionsgeschwindigkeit lässt sich ggf. aber auch ein erhöhter Ausstoß der automatischen Fertigung erreichen, was sich direkt in den betriebswirtschaftlichen Kennzahlen ablesen lässt oder eine oder eine schnellere Systemreaktion in Gefahrensituationen. Letztendlich gibt es noch ein weiteres Argument, von dem die ganze Branche lebt und das für eine Optimierung spricht. Gemeint ist die Psychologie bzw. Werbung, die das gute Gefühl der Sicherheit auslöst, dadurch, dass das Bewusstsein besteht, die Aufgabe hervorragend gelöst zu haben. Die ständig steigende Leistung moderner Prozessoren ist wohl Ursache der Auffassung, Systemressourcen (Programm- und Datenspeicher, logische Programmlänge, usw.) seien verschwenderisch zu nutzen, und damit sei das Geizen der Vergangenheit zuzuschreiben. Nicht jede Steuerung kann aus Kostengründen mit großzügigen Ressourcen ausgestattet sein. Mann denke da an Klein- und Kleinststeuerungen. Moderne Automatisierungskonzepte beinhalten eine Verteilung der Steuerungen, sowie der I/O's im Feld. Immer häufiger sind mehrere Kommunikationsschnittstellen (Feldbus, LAN, WAN) gleichzeitig in Betrieb. Der Kommunikationsaufwand steigt deutlich an. Die benötigten Rechenkapazitäten sind durch den Prozessor mit zu erbringen. Ferner verfügen moderne Applikationen über ein deutlich größeres Datenaufkommen, da einige Aufgaben (Qualitätssicherung, Protokollierung) zusätzlich in die SPS verlagert wurden und nicht zuletzt werden aus verschiedensten Gründen (Datenerfassung für Statistik, Historische Daten) mehr Daten erfasst, als es früher üblich war. Nicht zuletzt werden die verwendeten Datentypen immer komplexer. Reichten vor wenigen Jahren noch BOOL und BYTE, kommen heute immer häufiger STRING, REAL und Datums- und Zeit-Typen zum Einsatz. Im Allgemeinen ist der Aufwand für Optimierungen nicht zu unterschätzen. Neben der Aufwandsabschätzung ist die anzuwendende Strategie ein Risikofaktor.

Leistungsfähige Tools, die automatisch geeignete Strategien vorschlagen und mögliche Feinjustierungen erlauben, sind hier hilfreich.

3.2 Allgemeines zur optimierten Codeerzeugung

Im Vordergrund der Analyse zur Codeoptimierung sind Codestellen zu lokalisieren, die hohe Effizienz erwarten lassen. Ineffizient und sinnlos zeigen sich Optimierungen, sind sie auch extrem effektiv, deren Bearbeitung nur selten erfolgt. Im besonderen Maße gilt dies für Codes mit zeitabhängiger Ausführungskontrolle und gleichzeitig großen Intervallen (z.B. 2 Stunden). Effektiv ist die Optimierung da, wo es gelingt, mit minimalem Aufwand eine möglichst deutliche Verbesserung zu erzielen.

3.2.1 Geschwindigkeitsoptimierung

Starke Wirkung besitzen insbesondere die Codezeilen, die öfter durchlaufen werden als andere, wie Schleifen (Iterationen: z.B. FOR, UNTIL, usw.). Mehr Durchläufe stellen sich aber auch ein für Codesequenzen, die nicht mittels Auswahlkonstrukten (Selektionen: z.B. IF, CASE, usw.) ausgeblendet sind. Für Schleifen mit vielen Iterationen (Wiederholungen) greift der Multiplikatoreffekt für jede Einsparung.

Für Codesegmente im Schleifenrumpf gilt:
Codezeilen, die nicht zwingend der Wiederholung bedürfen, gehören nicht in den Schleifenrumpf. Auch harmlos anmutende Bausteinaufrufe sind diesbezüglich zu untersuchen, verbirgt sich doch ggf. viel Code hinter diesem. Aufwendige Berechnungen lassen sich häufig in einen iterationsabhängigen und einen unabhängigen zerlegen. Der unabhängige Teil steht außerhalb des Schleifenrumpfs. Sein Ergebnis wird zwischengespeichert. Die Vereinigung mit dem schleifenabhängigen Teil findet im Rumpf mittels der Variablen statt. Sind Bausteinaufrufe (FB) innerhalb von Schleifen unumgänglich, lässt sich auch die Parameterübergabe in einen iterationsabhängigen und einen unabhängigen Teil zerlegen.

Vielfach gibt es systemeigene Datentypen. Diese besitzen dann Geschwindigkeitsvorteile.

Oft kann eine grundsätzliche Aussage in Form einer Rangliste der Verarbeitungsgeschwindigkeiten für Datentypen bestehen. So beanspruchen Ganzzahloperationen immer weniger Rechenzeit als Gleitkommaoperationen. Um die vermeintliche Genauigkeit der Nachkommastellen zu erreichen, erfolgt die Darstellung und die Interpretation des Ganzzahlwertes als vielfaches (Kilo, Mega) oder als Bruchteil (Milli, Mikro). Prozessoren verwenden auf Grund ihrer Konstruktion Adressierungschemata. Speicherzugriffe im prozessoreigenen Format bieten Geschwindigkeitsvorteile. Direkte Speicherzugriffe (%M...) sollten, sofern nicht zwingend, die Adressierungsspezifika der Prozessoren berücksichtigen (beispielsweise nur gerade Adressen oder durch 4 teilbare).

Auch hinsichtlich arithmetischer Berechnungen sind Verbesserungen möglich. Der Austausch einer Multiplikation mit zwei durch eine Schiebeoperation um ein Bit bringt meistens Vorteile. Unbedingt zu vermeiden sind arithmetische Berechnungen, die ausschließlich aus Konstanten und Literalen bestehen (INT#10 + INTKonstante15). Wesentlich schneller ist zur Entwurfzeit das Ergebnis manuell zu ermitteln und nur das Ergebnis in den Code einzusetzen.

Allgemein sollten auch wiederkehrende Berechnungen oder Teile von Berechnungen nur ein einziges Mal durchzuführen sein, um die Ergebnisse in Variablen zwischenzuspeichern. Dies erleichtert die Wartung und steigert die Performance, da Variablenzugriffe oft deutlich schneller sind als Berechnungen.

Bestehen systemspezifische Unterschiede hinsichtlich der Verarbeitungszeit von Konstanten und Variablen, sollten entsprechende Erkenntnisse die Codierung beeinflussen. Gleiches gilt für Daten mit temporärem oder statischem Charakter.

Bedeutend kann auch die Schnittstellenwahl sein. Beispielsweise kann die VAR_IN_OUT-Schnittstelle, je nach Implementierung, einen Zeiger auf die eigentliche Variable darstellen oder eine mehrfache Datenkopie (VAR_INPUT und VAR_OUTPUT).

Die Kenntnis der Auswirkungen auf das Zeitverhalten der Prinzipien der Überladung und der Typisierung von Operationen und Parametern sind nutzbar.

Einen Überblick, wenn auch nicht mit Anspruch auf Vollständigkeit, vermittelt Tabelle 3.1.

Tabelle 3.1 Möglichkeiten der Optimierung zur verbesserten Ausführungsgeschwindigkeit

3.2.2 Kompakter Code, Minimierung des Datenspeichers

Im Gegensatz zu vielen EDV-Anwendungen, die üppige Hardwareressourcen verlangen, sind diese für Steuerungen oft stark begrenzt. Für die Unterbringung umfangreicher Funktionalität auf begrenzten Ressourcen entsteht die Forderung nach Kompaktheit des ausführbaren Codes.

Kompakter Code ist häufig von der Sprachwahl abhängig. Die Erzeugung ausführbaren Codes, aus grafischen Sprachen (KOP; FBD, AS) und Hochsprachen (ST) nutzt oft Zwischenvariablen, die dem Anwender verborgen bleiben. Bei Verwendung von AWL hingegen kontrolliert der Entwickler Code und Speicherbedarf.

Kompakter Code entsteht auch durch wiederverwendbare Bausteine. Ihr Code existiert nur einmal, auch bei Mehrfachaufrufen.

Kompaktheit unterstützende Maßnahmen beruhen im Wesentlichen auf dem Entfernen überflüssigen Codes. Dieser ist manchmal schwierig und aufwendig aufzufinden. Das Entwicklungssystem sollte entsprechende Dienste anbieten. Wünschenswert sind Funktionen wie

• Finden nicht benutzter Variablen,
• Codesequenzen, die mehrfach auftreten, lokalisieren,
• Aufspüren toter Anweisungen (Anweisungen, die aufgrund logischer Fehler niemals zur Ausführung gelangen),
• Analyse bezüglich zu großer String-Deklarationen (Maximale Stringgröße 45 Zeichen, alle Stringvariablen sind jedoch als STRING[150] vereinbart),
• Entdecken von Variablen, die nur einmal benutzt sind (Indiz für überflüssigen Code) und
• Ermitteln ungenutzter Datenelemente in Arrays, Strukturen und Aufzählungsvariablen.

Die IEC 61131 sieht für Multielementvariablen eine aufeinander folgende Speicherbelegung der einzelnen Elemente vor. Analoges gilt für Instanzen (Programme und Funktionsbausteine), sie verwalten ihre Daten prinzipiell wie Strukturen. Ausgenommen sind vielfach Variablen unterschiedlicher Speicherbereiche (RETAIN, NON_RETAIN), einiger Klassen (VAR_GLOBAL, VAR_IN_OUT, VAR_TEMP) und lokalisierte Variablen. Die Berücksichtigung der Adressierungsspezifika (nur gerade Adressen oder durch 4 teilbare) der Prozessoren kann zu erheblicher Speicherverschwendung führen. Oft bietet eine Sortierung der Deklarationsreihenfolge von Variablen innerhalb der POE und der Elemente in der Typvereinbarung einer Struktur verbesserte Speichernutzung. Die Sortierung erfolgt in Gruppen. Entweder sind alle Platzhalter mit gleichem Speicherbedarf (1, 8, 16, 32, 64 Bit) zusammengefasst oder die Anordnung erfolgt so, dass eine weitgehend lückenlose Speicherbelegung entsteht. Es sind insbesondere hier, wie für einige andere Optimierungsvorschlägen auch, detaillierte Systeminformationen des Anbieters erforderlich.

Ohne Einfluss auf die Kompaktheit des ausführbaren Codes, da vom Compiler automatisch entfernt, sind die Längen (Anzahl der Zeichen) für Bezeichner, Leerzeilen, Leerzeichen zwischen den Syntaktischen Elementen und alle Kommentare. Es gibt also keinen Grund, hier zu geizen.

3.2.3 Kommunikationsverhalten verbessern

In der Vergangenheit entstanden Grenzen des Realisierbaren häufig durch die Leistungsfähigkeit der Steuerungsprozessoren. Heute tritt immer mehr die Leistungsfähigkeit der Feldbusse als Flaschenhals in den Vordergrund. Die Mechanismen, der sich unterschiedliche Bussysteme bedienen, sind vielfältig. Möglichkeiten der Optimierung sind weitgehend durch Feldbus-Konzept vorgegeben. Dem Anwender bleibt oft nur die Reduzierung des Datenaufkommen um eine Minimierung des Kommunikationsaufwands zu erreichen. Entscheidend ist die gewählte Projektstruktur eines dezentralen Automatisierungssystems, die zu einer Reduzierung der Anzahl und der Größe der übertragenen Daten führt.

Besteht die Wahl zwischen den Verfahren Polling und Event, ist oft das Eventverfahren, insbesondere für Daten mit azyklischen und großen Änderungsintervallen geeignet. Nur bei tatsächlicher Veränderung der Daten erfolgt im ereignisorientierten (Event) Verfahren eine Übertragung der betroffenen Daten. Das zyklische Pollen hingegen überträgt intervallmäßig Daten ohne Berücksichtigung dessen, dass die Daten bereits in großem Umfang, da absenderseitig unverändert, im Empfänger vorliegen.

Übertragene Daten, die zu Datenpaketen, mit Anpassung an die spezifischen Pakete des Kommunikationssystems, zusammengeschnürt sind, erhöhen den Datendurchsatz. Überträgt ein System beispielsweise maximal 8 Byte pro Nachricht ist für 64 Bit nur eine Nachricht erforderlich, für 65 Bit hingegen zwei. Die Verbesserung des Kommunikationsverhalten bei einer Reduzierung um ein Bit, sofern möglich, ist offensichtlich.

Für Eventsysteme ist eine weitere Optimierung gegeben, sofern entsprechende Einflussmöglichkeit besteht, in dem Daten mit annähernd gleichen Änderungsintervallen im selben Datenpaket zusammengefasst sind. Datenpakte deren Daten selten eine Wertänderung erfahren sind so getrennt von Daten mit schnelleren Änderungszyklen übertragbar.

Eine Informationsanalyse ist Basis diskreter Informationsübertragung von analogen Basisdaten. Die Untersuchung zielt auf den tatsächlichen Informationsbedarf. Muss empfängerseitig der Analogwert vorliegen oder reicht eine charakteristische Information. Verfügt der Absender beispielsweise über die analoge Information einer Helligkeit, ein Empfänger soll abhängig einer fixen Größe reagieren (z.B. 200 Lux), so ist es ausreichend nur das erreichen dieser Größe und nicht die Größe selbst zu übertragen. Damit tritt eine Reduzierung der Datenübertragung von eventuell 16 Bit auf ein Bit ein. Erhöhte Wartungsfreundlichkeit ist auch immer dann gegeben, wenn es mehrere Empfänger der diskreten Information gibt und sich der Schwellwert (200Lux) häufig ändert.

3.2.4 Automatische Optimierung

Bei der automatischen Optimierung führt der Compiler standardisierte Optimierungsstrategien durch. Erwähnt wurde bereits, dass einige Optimierungen nicht gewünscht bzw. zur Verschlechterung anderer Eigenschaften führen. Bestandteil der Anwenderunterstützung durch das System sollte die Integration von Steuermechanismen, die den Übersetzungsvorgang beeinflussen, bieten. Diese Steuermechanismen sind auch als Compilerschalter bezeichnet. Compilerschalter, die die Übersetzung als ganzes beeinflussen wirken global für alle Bausteine. Der gezielte Einsatz, bestimmter Übersetzungsmodi erfordert das Compilerschalter direkt in der Source für die Umschaltung sorgen. Die 2^nd Ed. der IEC 61131-3 definiert das Pragma, ohne jedoch eine explizite Syntax vorzugeben, als eine implementierungsabhängige Eigenschaft. Das Pragma gestattet Grundsätzlich die benötigte Funktion des Compilerschalters, ist jedoch nicht standardisiert und lässt zusätzliche Aufgaben zu. Gute Compiler sollten zumindest einige automatische Optimierungen bieten. Neben den in Abschnitt 3.2.2 diskutierten sind folgende automatische Optimierungen hilfreich.

Mehrfach verwendete Literale und Konstanten nur einmal speichern

Die Eigenschaft von Literalen und Konstanten, über die gesamte Laufzeit keine Änderungen ihrer Inhalte zuzulassen, gestattet es, Literale und Konstanten, die mehrfach vorkommen, nur einmal zu speichern. Von besonderem Nutzen ist dies für speicherintensive Datentypen wie Strings und 32-Bit-Datentypen oder bei sehr häufig auftretenden von Literalen und Konstanten. Besitzt beispielsweise eine Applikation Unmengen von Zeitgliedern, deren Zeitwert identisch ist, ist es ausreichend, den identischen Zeitwert einmal abzulegen.

Multiplikationen durch Schiebebefehle ersetzten

Auch diese Optimierung, die unter Abschnitt 3.2.1 vorgeschlagen ist, lässt einen Automatismus zu.

Datentypoptimierung

PC-basierte Steuerungssysteme, bzw. die verendeten Prozessoren verfügen nicht über schnelle Bitoperationsunits. Die Folge: Bitoperationen sind langsam. Deutliche Geschwindigkeitszunahmen sind erreichbar, sofern der Compiler jede Boolesche Variable im systemeigenen Datentyp ablegt (z.B. Byte, Word, Integer). Andererseits muss die Möglichkeit hinsichtlich des Speicherbedarfs zu optimieren gegeben sein.

Datenausrichtung gemäß Adressierungsschema

Die Speicherverwaltung, die die Adressierung symbolischer Variablen übernimmt, sollte die Adressierungsspezifika (nur gerade Adressen oder durch 4 teilbare) der Prozessoren unter dem Aspekt Geschwindigkeit und Speicheroptimierung berücksichtigen.

Toten Code entfernen

Toter Code sollte beim Übersetzen erkannt und nicht in den ausführbaren Code übernommen werden. Eindeutig tot ist Rumpf der folgenden IF-Anweisung. IF FALSE THEN ...Rumpf... END_IF.

Baussteinintegration

Nicht aufgerufene Bausteine haben im ausführbaren Code nichts zu suchen.

Unbenutzte Variablen

Analoges gilt für deklarierte, aber in der Source nicht benutzte Variablen. Sie sind ebenfalls auszusortieren. Schwieriger, aber nicht unmöglich, ist die Erkennung von unbenutzten Elementen abgeleiteter und zusammengesetzter Variablen. Hierzu zählen Arrayfelder, Strukturelemente und Werte der Aufzählungstypen.

Je nach System und Aufgabenstellung sind weitere Optimierungsmaßnahmen denkbar, so dass hier keineswegs ein vollständiges Bild aller Strategien vorliegt. Eine kritische Prüfung (bzw. Befragung des Herstellers) der grafischen Sprachen hinsichtlich der Optimierung ist immer angebracht. Häufig transformiert ein Codegenerator das grafische Netzwerk in AWL. Hier ist oft noch Spielraum für Optimierungen erkennbar. Neben den vorgestellten allgemeinen und modellunabhängigen Verbesserungsmöglichkeiten zielen die folgenden Abschnitte auf Optimierungsstrategien ablauf- und zustandsorientierter Modelle, wie Petrinetze, SFC, Grafcet, Zustandsmaschinen, Automaten und teilweise IEC 61499. Diese Modelle zeichnen sich durch hervorragende Eigenschaften der Mächtigkeit, reale Prozesse, einfach durch Zustände und deren Übergänge abzubilden, aus. Insbesondere birgt die zustandsorientierte Abbildung große Optimierungspotentiale in sich.

3.3 Optimierung für ablauf- und zustandsorientierte Modelle

Gerade durch die Topologie der Netze (Petrinetze, SFC, Grafcet, Zustandsmaschinen, Automaten, IEC 61499)), die bestimmte (Markierung) Zustände einnehmen, ergeben sich eine Reihe von Möglichkeiten zur Minimierung beanspruchter Rechenzeit. Allen gemeinsam ist, dass sich die Netzelemente (hier im wesentlichen Transitionen, aber auch Aktionen bzw. Schrittlupen) abhängig von der Markierung selbstständig zur Bearbeitung an- bzw. abmelden, oder von anderen Netzelementen ab- oder angemeldet werden. Ferner kann ein Netzelement selbst bzw. dessen Bearbeitungszeit, insbesondere, wenn es in AWL realisiert ist, im einen oder anderen Fall deutlich verkürzt werden. Es tritt dabei eine Verkleinerung der logischen Programmlänge ein. Als Folge vergrößert sich der Programmumfang (Speicherbedarf und Anzahl der Zeilen).

Eine ideale Optimierung wäre gefunden, wenn ein System automatisch, ohne zusätzlichen Aufwand, anhand aktiver Schritte schaltfähige Transitionen erkennt und nur diese bearbeitet. Dann wäre die prozentuale Verbesserung das Verhältnis der Zeitverbräuche der schaltfähigen Transitionen zur Summe aller Transitionen eines Netzes. Beispielsweise existieren zwei schaltfähige Transitionen in einem Netz von 100 gleichartigen Transitionen. Die Verarbeitungszeit wäre dann um einen Faktor 50 schneller (entspricht einer Verbesserung auf 2% des nicht Optimierten Zeitverbrauchs). Real sind jedoch, wie erwähnt, zusätzliche Befehle zur Verwaltung aufzunehmen, so dass dieser Faktor als sehr theoretisch aufzufassen ist.

Welche Strategie der Minimierung anzuwenden ist, und damit auch der Grad der Minimierung, hängt von vielen Faktoren ab.

Die wichtigsten Faktoren sind:

• Befehlsausführungszeiten der Plattform (Prozessoren und Runtime-Umgebung)
• Features, die die Zielsprache der Codierung bietet (z.B. dynamische Sprungziele)
• Häufigkeit der Bearbeitung (Aktionen 2 mal, Transitionen 1 mal)
• Häufigkeit des Schaltens bzw. des Nicht-Schaltens von Transitionen
• Anzahl der Standard-Prekanten, sonstiger Prekanten, Postkanten, Umfang sonstiger Schaltbedingungen, Umfang des Anweisungsblocks
• Zeitdauer, die eine Teilbedingung der Schaltbedingung erfüllt bzw. nicht erfüllt (Stark unterschiedlich, nahezu gleich) (Zeitlicher Abstand zwischen Erfüllung einer Teilbedingung und der Erfüllung der ganzen Bedingung)
• Anzahl der Marken (Ein-Marken-Netz)
• Vermaschung
• Länge unverzweigter Ketten
• Aufenthaltswahrscheinlichkeit der Marken in (Teil-)Netzen und Ketten
• Anzahl der Marken in einer unverzweigten Kette
• Stellung der Transition (vorn, mittig oder hinten) in einer unverzweigten Kette oder in einem Ein-Marken-Netz
• Zeit, die für das Schalten bzw. Nicht-Schalten benötigt wird
• Anzahl der nebenläufig schaltenden Transitionen während einer Bearbeitung zur Gesamtzahl der Transitionen
• Kausalitätsgrad
• Tote Netze bzw. tote Teilnetze (BK z.B. initialisiert)
• Konfliktgrad (möglichst klein bei Dispatcher) möglichst klein
• Konfliktanzahl (möglichst klein bei Dispatcher) möglichst klein

Dieses sind so viele Parameter, die eine minimierte Umsetzung allein durch die Denkleistung des Entwicklers und den erforderlichen Zeitaufwand nicht rechtfertigen. Eine Analyse dieser komplexen Zusammenhänge sollte mittels Software erfolgen. D.H. der Compiler muss einen entsprechenden Code erzeugen.

In vielen Fällen kann eine Berechnung entscheiden, welche Minimierungsstrategie oder Kombinationen von Strategien geeignet sind, in anderen Fällen muss der Anwender durch zusätzliche Angaben die Auswahl der richtigen Strategie unterstützen bzw. verfeinern. Ebenso denkbar sind Verfahren, die im Probebetrieb, also zur Laufzeit das Netzmodell auf dynamische Spezifika untersuchen. Die so entstehende Datensammlung dient als Basis der Ermittlung entsprechender Strategien. Gerade letzteres ist für die Mehrzahl der Prozesse meist nicht erforderlich. Die vorgenannte Berechnung aus der

Topologie heraus, unterstützt durch die Feinabstimmung des Entwicklers, bietet im Allgemeinen ein hinreichend gutes Ergebnis.

3.3.1 Grundsätzliche Optimierungsprinzipien

Nutzbare Potentiale zur Minimierung beruhen auf folgenden Überlegungen.

Steuerungssysteme (SPS) bearbeiten ihre Programme derart schnell, dass ihre sequentielle Bearbeitung für den Außenstehenden (zu steuernder Prozess) wie eine Parallelverarbeitung wirkt. D.h. dass im Prozess das Verhältnis gleichzeitig auftretender Ereignisse zur Summe der möglichen Prozessereignisse häufig deutlich kleiner ist, als das Verhältnis der SPS-Zyklen ohne Zustandsänderung zur Summe der SPS-Zyklen mit Zustandsänderung. Mit anderen Worten: Die meiste Zeit liegt eine Transition faul in der Bearbeitungsschleife des Programms herum. Sie arbeitet nur selten, nämlich während des Schaltens. Natürlich gibt es auch hier Ausnahmen, einige Transitionen schalten häufiger.

Nahe liegend ist es daher, die untätigen Transitionen aus der Bearbeitungsschleife herauszunehmen, bzw. eine Beschränkung ihre Bearbeitung auf ein notwendiges Maß zu reduzieren (nur Schaltbereitschaft prüfen).

Für dieses Vorhaben sind weitere Befehle einzufügen, damit wächst die Anzahl der Programmzeilen und ggf. ist auch etwas mehr Datenspeicher erforderlich. Diese verlängern die einzelne Befehlssequenz derart, dass entweder das Schalten oder das Nicht-Schalten betroffen ist. Die Gesamtheit der Programmbearbeitung verkürzt sich jedoch deutlich, da entweder schaltende oder nicht schaltende Transitionen in der Überzahl sind. Eine Verkürzung der logischen Programmlänge tritt ein. Eine weitere Überlegung geht dahin, dass der Source der Schalthandlung und ggf. Teile der Schaltbedingung übersprungen werden, sobald sich beim Prüfen eines Teils der Schaltbedingung herausstellt, dass die Transition nicht schaltet. So ist beispielsweise im Allgemeinen in Transitionsbedingungen eine Verriegelung erfüllt. Nicht erfüllt ist sie hingegen häufig in Fehlersituationen. Somit kann die Verriegelung als letztes geprüft werden. Daraus ergibt sich für das Nichtschalten eine verkürzte und für das Schalten eine geringfügig verlängerte Bearbeitungszeit. Genau dies ist gewünscht, da das Nichtschalten von Transitionen im Allgemeinen deutlich häufiger vorkommt als das Schalten. Stichwort: „faule Transition".

Je nach Art und Einfluss der o.g. Faktoren sind Optimierungen zwischen 98% und 50% erzielbar.

Drei grundsätzliche Strategien sind zu unterscheiden:

• Elementabhängig: Ausschlaggebend ist der Umfang (Anzahl Pre-, Postkanten und der Programmzeilen für zusätzliche Bedingung), sowie die daraus resultierende Rechenzeit des Systems
• Prozeßabhängig: Ausschlaggebend ist die Kürze der zeitlichen Dauer, die einzelne Signale vor dem Schalten erfüllt sind (letztes Signal)
• Topologieabhängig: Unverzweigte Ketten, Einmarken Netze oder Teilnetze, Tote Netze oder Teilnetze, usw.

Zur Nutzung aller Potentiale sind Kombinationen aller Strategien, die gleichzeitig, einzeln und mehrfach zur Abbildung (Codierung) eines Netzes auf einem Zielsystem, unter Verwendung aller Systemeigenschaften, anwendbar.

3.3.2 Kennzahlen

Da einige Systeme (gängige Praxis) für Netze (IEC 61131, IEC 61499, Automaten, Grafcet, usw.) und in den folgenden betrachteten Fällen Petrinetze eine Codierung in AWL durchführen, sind folgende Betrachtungen ebenfalls als IEC 61131-Abbildung erfolgt.

Um Vergleiche der Effekte unterschiedlicher Strategien anzustellen, ist eine einheitliche Bezugsgröße zu nennen. Geeignet ist die Zeit (Schalten bzw. Nicht Schalten), die für die Bearbeitung eines linear codierten Netzes bzw. einer linear codierten Transition, veranschlagt werden muss. Kennzeichen eines solchen Codes ist der Verzicht auf Programmverzweigungen (bedingte Sprünge) hinter den Teilbedingungen der Schaltbedingung oder der Schaltbedingung als ganzes (vgl. Beispiel....???). Daher ist das Passivverhältnis von besonderem Interesse, gelegentlich kann auch das Aktivverhältnis von Interesse sein.
Passivverhältnis = NS_Prüfling/NS_Linear sowie Aktivverhältnis = S_Prüfling/S_Linear
NS_Prüfling Zeit für die Bearbeitung des Nichtschaltens eines Prüflings T_Prüf
NS_Linear Zeit für die Bearbeitung des Nichtschaltens einer Transition T_Linear die dem Prüfling T_Prüf entspricht, jedoch linear codiert ist.
S_Prüfling Zeit für die Bearbeitung des Schaltens eines Prüflings T_Prüf
S_Linear Zeit für die Bearbeitung des Schaltens einer Transition T_Linear die dem Prüfling T_Prüf entspricht, jedoch linear codiert ist.

Transitionen, die über mehr als eine Programmverzweigung innerhalb der Schaltbedingung verfügen, besitzen dann auch entsprechend viele Stellen im Code an denen ggf. ein Nichtschalten festgestellt wird. Damit gibt es eine minimale, eine maximale NS-Zeit und im Allgemeinen einige Zwischenwerte. Diese sind in der Excel-Tabelle auf der CD-zum Buch berechnet.

Meist nur am Rande ist von Interesse, wie sich das Aktiv-Passiv-Verhältnis S/NS (AP-Verhältnis) verändert. Dieses Verhältnis ist für eine linear codierte Transition immer 1.
S Zeit für die Bearbeitung einer schaltenden Transition T_n
NS Zeit für die Bearbeitung einer nicht schaltenden Transition T_n

3.3.3 Transition und ihre erweiterte Begriffswelt

Bekannte Netzklassen erweitern die grundlegenden Eigenschaften der eingeführten Begriffe um spezifische Definitionen. Am häufigsten sind klassenspezifische Definitionen für die Begriffe Schaltregel, Schaltbereitschaft, Schalthandlung, Lebendigkeit, Deadlock, Sicherheit, Konflikt, usw. zu finden. Um die im Folgenden stattfindende Diskussion mit eindeutig definierter Basis zu führen, gibt es einige Festlegungen zu bekannten und neuen Begriffen. Soweit notwendig, sind die Elemente einem Begriff in Tabelle 3.2 zugeordnet.

Tabelle 3.2 Begriffe und ihre Netzelement

Schaltbereitschaft (schwache oder unsicher)

Eine Transition ist schaltbereit, wenn alle Vorgängerplätze mit ausreichender Markenanzahl belegt sind, so dass ein Schalten möglich ist. (Allgemein: durch das Schalten entstehen keine negativen Zustände). Die starke oder sichere Schaltregel verlangt zur Erlangung der Schaltbereitschaft, dass die Nachfolgerplätze genügend Kapazitäten für die Aufnahme der Marken bereitstellen. Dieses Verhalten wird hier punktuell durch die Sonderkante bereitgestellt.

Erweiterte Schaltbereitschaft umfasst z.B. die Prekanten, SPS-Eingang bzw. POE-Eingänge (auch negiert), Abfrage (negiert) von Plätzen und Sonderkanten. Sie ist erfüllt, wenn alle ihre Kanten erfüllt sind.

Bedingte Schaltbereitschaft beinhaltet sonstige Bedingungen auch besondere Schaltbedingung genannt (Vergleiche, Zeitbedingungen usw.).

Schaltregel (Konzessionsregel)

Schaltbedingung

Prüfen der Schaltbedingung

Prüfen der Standard-Prekanten (Aktivierung der Transition). Erfüllt: Entspricht der Schaltbereitschaft
Prüfen sonstiger Prekanten (Freigabe der Transition durch sonstige Prekanten). Erfüllt: Entspricht der erweiterten Schaltbereitschaft
Prüfen sonstiger Bedingungen (Bedingte Freigabe der Transition durch sonstige Bedingungen). Erfüllt: Entspricht der bedingten Schaltbereitschaft

Schalthandlung

Schalten wenn:
Schalten = Schaltbereitschaft & erweiterte Schaltbedingung & bedingten Schaltbereitschaft dann

Anweisungsblock spezialisierter Transition (Lösch, Anweisung..) bearbeiten
Ausführungsverwaltung (Verwaltung der Variablen zu Optimierung)
Räumen der Vorgängerplätze (Input- oder Eingangs-Plätze)
Belegen der Nachfolgerplätze (Output- oder Ausgangs-Plätze)

Schaltverhältnis (SV) einer Transition gibt an, das Verhältnis der Häufigkeit des Schaltens zur Häufigkeit des Nicht-Schalten. Die Summe aus Nicht-Schalten und Schalten ergibt die Anzahl der gesamten Bearbeitungen der Transition (oder des Netzes) bzw. der Source, der das Netz repräsentiert. Eine Transition, die nie schaltet (ist meist unsinnig) hat ein Schaltverhältnis von 0.

Eine Transition, die genau so häufig schaltet wie nicht, hat ein Schaltverhältnis von 1. Eine Transition, die einmal weniger schaltet als nicht-schaltet besitzt ein Schaltverhältnis von 0,5.

SV_T = Anzahl Schalten/Anzahl Nichtschalten	Basis: Transitionsbearbeitungen
SV_N = Anzahl Schalten/Anzahl Nichtschalten	Basis: Netzbearbeitungen

Im Folgenden werden die wesentlichsten Strategien vorgestellt. Kombinationen und weitere Gliederungen sind möglich und sinnvoll.

Angemerkt sei noch, dass der Anweisungsblock und/oder die Schalthandlung oder sogar sie gesamte Transition (SpV-codiert) auch in eigenen Programmbausteinen untergebracht sein können. Für IEC 61131 ist dies gegenwärtig jedoch nicht zu empfehlen, da die vorgeschriebene Datenkapselung für POE zusätzliche Anweisungen der Parameterübergabe erzwingt. Im Einzelfall kann solches Vorgehen nützlich sein; im Allgemeinen jedoch ist der Bedarf an Rechenzeit eher zu groß.

Geeignet ist die Realisierung der Schalthandlung bzw. der zugehörige Anweisungsblock mittels Unterprogrammtechniken, sofern diese auf Datenkapselung ganz oder teilweise verzichten, wie dies einige Umgebungen unterstützen. Ein bekannter Vertreter solch einer Technologie ist der Programmbaustein der Step 5-Syntax. In Fällen, in denen identische oder ggf. auch weitgehend identische Anweisungsblöcke bei mehreren Netzelementen (z.B. Transition) auftreten, sind kapselungsfreie Bausteine hervorragend geeignet (z.B. Löschtransition).

Für die Codierung von Transitionen erfolgt zur vereinfachten Diskussion die folgende PN-orientierte Benennung von Codeteilen.

Die Schaltbedingung besteht aus Codes für die Umsetzung

• der Prekanten, die ausschließlich Plätze mit Transitionen verbinden (Eigentliche Bedingung der klassischen Schaltbereitschaft (ggf. inkl. der Sonderkante)),
• der Prekanten (Signalprekanten), die Repräsentanten von SPS-und POE-Eingängen und gesonderte Abfragen von Plätzen darstellen und
• einer oder mehreren zusätzlichen Bedingungen.

In den folgenden Abbildungen werden die 3 Sourceteile der Schaltbedingung mit Bedingung 1 bis 3 bezeichnet. Eine weitere Aufteilung im gegebenen Einzelfall ist möglich und ggf. sinnvoll.

Die Schalthandlung besteht aus Code für die Umsetzung

• der Postkanten,
• der Prekanten, die ausschließlich Plätze mit Transitionen verbinden und
• der Anweisungsblöcke von den speziellen Transitionsarten, wie Löschtransition, Anweisungstransition, Bedingungstransition

In den folgenden Abbildungen ist der Sourceteil der Schalthandlung durch den Kasten, betitelt mit „Schalthandlung", repräsentiert.

Je nach Netzklasse und Transitionsart können Teile entfallen ggf. können auch weitere Sourceteile hinzukommen.

Für die Codierung sind viele Varianten denkbar, die in dem einen oder anderen Fall nützlich sind. Daher zeigen die folgenden Flussdiagramme jeweils die Variante, die standardmäßig gute Ergebnisse liefert. Varianten könnten beispielsweise die erste, zweite oder alle Bedingungen (1–3) zu einer zusammenzufassen, oder die letzte Programmverzweigung (letzte Bedingung) unmittelbar vor der Schalthandlung weg lassen, usw.

Generell ist es nicht zwingend erforderlich, alle Netzelemente der gleichen Optimierungsstrategie zu unterwerfen. Es kann jeweils je Netzelement oder je Teil eines Netzes (Unverzweigte Kette) die beste Strategie bzw. die beste Kombination von Strategien zur Anwendung kommen.

3.3.4 Geeignete Strategien für Steuerungssysteme

Oben genannte Eigenschaften des Netzes, des Prozesses und der Plattform sind zur Wahl der geeigneten von Bedeutung. Einige Strategien erfordern gewisse Eigenschaften der Zielsprache. Diese werden von der AWL unterstützt. Ferner stellt AWL eine effiziente Sprache dar, zumindest was den optimierten Code betrifft. Daher beziehen sich im Weiteren die meisten Beispiele und Betrachtungen auf AWL-Code. Wenige Ausnahmen legen Hochsprachenkonstrukte, wie If-Then, Case und andere, zugrunde.

Transformation der Codierungsvorschläge von AWL hin zu ST folgen einer einfachen Regel: Sprünge sind durch IF-Anweisungen zur ersetzen. Dabei sind die logischen Zusammenhänge, vorgegeben in der AWL, unverändert auf die ST-Syntax zu übertragen.

Einen Überblick über die im Folgenden diskutierten Strategien beinhaltet die Tabelle 3.3.

Tabelle 3.3 Strategien im Überblick

²T_NZeit, die für das Ermitteln des Nichtschaltens notwendig ist.
T_SZeit, die für das Schalten notwendig ist.

3.3.4.1 Strategien zur Optimierung von Netzelementen

Netzelemente sind alle elementaren Elemente, aus denen ein Netz bestehen kann, wie Knoten (Platz und Transition), Kanten, Task, Aktion, Schrittlupen, usw.

3.3.4.1.1 Optimierung boolescher Gleichungen

Jeder Befehl, der im Source steht, benötigt Rechenzeit, sofern er in der aktuellen Bearbeitungsschleife liegt. Insbesondere sollten Befehlssequenzen in Wiederholanweisungen einer kritischen Betrachtung unterliegen. Grundsätzlich ist daher jeder nicht notwendige Befehl zu entfernen. Zunächst gibt es geeignete Minimierungsverfahren, die neben der Minimierung der booleschen Gleichung auch seine Bearbeitungszeit verkürzt, da eine Reduzierung der benötigten Befehle eintritt. Häufig sind jedoch Transitionsbedingungen einfacher Art und bestehen aus wenigen Verknüpfungen, so dass eine weitere Minimierung unmöglich oder nicht wirtschaftlich vertretbar ist.

Ohne Gefährdung des logischen Gehalts kann jedoch eine weitere Reduzierung benötigter Rechenzeit erfolgen. Der Erfolg des im Folgenden vorgestellten Verfahren hängt im starken Maße von der Bearbeitungszeit für einzelne Befehle ab, die ein Zielsystem (Prozessor, Laufzeitumgebung, Codierung des ausführbaren Codes) beansprucht und kann ggf. auch eine Verschlechterung bedeuten. In jedem Einzelfall ist zu ermitteln, ob der Nutzen der Codierungsmaßnahme gegeben ist. Dies kann von vielen Parametern abhängen, wie eingangs in Abschnitt 3.3.4 diskutiert.

Elementare Operationen sind die UND- und ODER-Verknüpfung, die im Wesentlichen für die Bildung von Transitionsbedingungen eingesetzt werden.

Ausführungszeit optimierte Codierung einer UND-Verknüpfung

Wesentliches Merkmal einer UND-Verknüpfung ist, dass für eine WAHRE-Aussage (TRUE) am Ausgang für alle Eingänge ebenfalls WAHR erforderlich ist. Umgekehrt bedeutet dies: Führt auch nur ein Eingang FALSCH (FALSE), muss auch das Ergebnis entsprechend sein. Damit ist die Entscheidung bereits ursächlich durch ein Signal bestimmt und eine Umsetzung mit je einem Sprung je Eingang gegeben.

Die folgende Transitionsbedingung mit 4 Variablen wird mit Sprüngen realisiert. Positive Auswirkungen auf die Bearbeitungsgeschwindigkeit ist nur zu erwarten, wenn die Teilbedingungen (E1 bis E4) entsprechend umfangreich sind, und die zusätzlichen Sprünge weniger Zeit beanspruchen.

Bedingung: E1 UND E2 UND E3 UND E4

Tabelle 3.4 Transitionsbedingung und UND-Verknüpfung nach dem wired-and-Prinzip codiert

Ist das Verknüpfungsergebnis im Sinne einer vollständigen UND-Verknüpfung einer Variablen zuzuweisen, sind 2 Maßnahmen erforderlich. Anstelle der Schalthandlung steht die Zuweisung (TRUE) mit der Zeile ST Ergebnis. Zusätzlich sind die folgenden Zeilen LD FALSE und ST UNDErgebnis direkt vor den Code zu stellen. Die Bildung des Ergebnisses erfolgt äquivalent zu einer wired-and-Verknüpfung einer elektrischen Schaltung.

Ausführungszeit optimierte Codierung einer ODER-Verknüpfung

Wesentliches Merkmal einer ODER-Verknüpfung ist, dass für eine WAHR-Aussage (TRUE) am Ausgang nur ein Eingang WAHR erforderlich ist. Umgekehrt bedeutet dies, führt auch nur ein Eingang WAHR (TRUE), muss auch das Ergebnis entsprechend WAHR sein. Damit ist die Entscheidung bereits ursächlich durch ein Signal bestimmt und eine Umsetzung mit je einem Sprung je Eingang gegeben.

Die folgende Transitionsbedingung mit 4 Variablen wird mit Sprüngen realisiert.

Bedingung: E1 ODER E2 ODER E3 ODER E4

Ist das Verknüpfungsergebnis im Sinne einer vollständigen ODER-Verknüpfung einer Variablen zuzuweisen, sind 2 Maßnahmen erforderlich. Anstelle der Schalthandlung steht die Zuweisung mit den Zeilen LD TRUE und ST Ergebnis. Zusätzlich sind die folgenden Zeilen LD FALSE und ST ODERErgebnis direkt vor dem Code zu stellen. Die Bildung des Ergebnisses erfolgt äquivalent zu einer wired-or-Verknüpfung einer elektrischen Schaltung.

Tabelle 3.5 Transitionsbedingung und ODER-Verknüpfung nach dem wired-or-Prinzip codiert

Auflösung komplexer boolescher Gleichungen

Komplexe boolesche Gleichungen lassen sich in die so genannte Konjunktive bzw. Disjunktive Normalform (KNF bzw. DNF) überführen. Es entstehen Therme, die entweder UND- bzw. ODER verknüpft sind. Somit sind die oben erwähnten Prinzipien im Sinne der wired-and bzw. wired-or-Verknüpfungen auf die Therme anwendbar.

3.3.4.1.2 Implementierungsabhängige Besonderheiten der IEC 61131-Codierung

Die IEC-Spezifikation für AWL beinhaltet keine Festlegungen zum Verhalten des Aktuellen Ergebnis (Früher Vke – Verknüpfungsergebnis -) nach einem Sprung. Je nach Implementierung kann es, wie im Folgenden erläutert, zu unterschiedlichen Verhalten der SPS kommen.

Sprünge

1. Wird der Sprung nicht ausgeführt steht das AE, das direkt vor dem Sprung ermittelt wird, hinter dem Sprung zur Verfügung. Im Fall von JMPC ist das AE FALSE und im Fall von JMPCN ist das AE TRUE. Damit muss nicht zwangsläufig hinter einem Sprung eine LD-Operation stehen.
2. Am Sprungziel muss die erste Anweisung eine LD-Operation sein (Einschränkung gegenüber der IEC).

3.3.4.1.3 Lineare Codierung

Lineare Codierung ist die Standardcodierung. Besonderes Kennzeichen ist, die Zeit, die für das Schalten benötigt wird, ist genauso lang wie die für das Nichtschalten.

Sie eignet sich für eine reduzierte Inanspruchnahme von Rechenzeit nur im Falle der Transition, die annähernd so häufig schaltet wie nicht schaltet oder wenn die Schalthandlung soviel Zeit oder weniger benötigt, wie die notwendigen zusätzlichen Befehle der anderen Optimierungslösungen, wobei häufig auch nur eine Bedingung vorhanden ist.
[siehe 1.1 Flussdiagramm zur linearen Codierung Transitionen]

3.3.4.1.4 Getrennte Codierung (Splitting)

Das Splitting zerlegt die komplette Schaltbedingung in Teilbedingungen. Bei der Codierung wirkt das Verknüpfungsergebnis jeder Teilbedingung auf einen Sprung, der bei nicht erfüllter Transitionsbedingung die Bearbeitung beendet.

Das Nichtschalten einer Transition T_n verkürzt sich dadurch erheblich, dass hinter einer Teilbedingung eine Programmverzweigung (bedingter Sprung) entscheidet, ob die nächste Transition T_n+1 oder weitere Programmzeilen der Transition T_n der Bearbeitung unterliegen.

Das Splitting könnte annähernd als eine Zerlegung einer Transition in Teiltransitionen aufgefasst werden. Wobei jede Teiltransition eigentlich nur eine Teilbedingung darstellt (vgl.).

Die getrennte Codierung ist einfach zu realisieren und kann automatisiert oder ggf. manuell erfolgen. Die Größe des zeitlichen Gewinns an Bearbeitungszeit ist im Wesentlichen von der Anzahl der Kanten, des Umfangs der zusätzlichen Bedingungen und der Feingliedrigkeit der Trennung abhängig. In Grenzbereichen ist auch die Zeit, die für die zusätzlichen Sprünge benötigt wird, ausschlaggebend, um festzustellen, ob diese Codierungsart vorteilhaft ist.

In einigen Fällen kann die Reihenfolge, in der die einzelnen Bedingungen der Schaltbedingung im Source platziert sind von Bedeutung sein. Automatisch erzeugter Code sollte eine Reihenfolge wählen, bei der die Teilbedingung von der zeitlich kürzesten Bearbeitungszeit zur längsten verläuft. Hiervon ist ggf. abzuweichen, wenn dadurch zusätzliche Klammern benötigt würden. Dieses Prinzip kann auf alle weiteren Strategien, die im Folgenden diskutiert sind, zusätzlich angewandt sein. Tabelle 3.6 Splitting Codierung für Transitionen

[siehe 1.3 Flussdiagramm zur getrennten Codierung von Transitionen]

3.3.4.1.5 Sprungverteilercodierung

Der Sprungverteiler (SpV) führt zunächst je Transition einen virtuellen Platz (Transitionsflag) ein. Was zunächst einmal zusätzliche Rechenzeit kostet. Der Einsparungseffekt wird dadurch erzielt, dass grundsätzlich nur der übergeordneten Sprungverteiler bearbeitet wird (d.h. 2 Anweisungen je Transition; Flag-Abfrage und Sprung). Nur diejenige Transition, deren Flag gesetzt ist, unterliegt der weiteren Prüfung der Schaltbedingung. Grundsätzlich kann dann zusätzlich die getrennte Codierung implementiert sein. Es ist also nicht zwingend das lineare Codierungsprinzip anzuwenden.

Ist die Transition nicht schaltfähig, erfolgt der Rücksprung zum Sprungverteiler. Für den Fall, dass sie schaltfähig ist gibt es 2 Varianten. a) nach dem Schalten wieder zum SpV zu verzweigen und b) die Schaltbedingung der Nachfolgetransition zu prüfen. Letzteres ist jedoch nur sinnvoll, wenn die Nachfolgetransition möglicherweise durch das Schalten ihrer Vorgängertransition schaltfähig wird.

Unter der Kontrolle eines einzigen Sprungverteilers besteht die Möglichkeit der gemeinsamen Transitionscodierung beider Varianten.

Die Schalthandlung einer Transition im Sprungverteiler muss ihr Flag zurücksetzen und die Flags der Nachfolgertransitionen setzen, die durch das Schalten gemäß Netztopologie schaltfähig werden könnten. Das sind alle Transitionen, die einen Nachfolgerplatz der geschalteten Transition als Vorgängerplatz besitzen.

SpV-codierte Transitionen werden immer in Kombination mit einem übergeordneten SpV gebraucht.

Erfordernisse der Netztopologie führen ggf. auch zu ineinander verschachtelte SpV-Strukturen.

Die SpV-Codierung ist nicht zwingend für alle Transitionen eines Netzes. Innerhalb des SpV lassen sich problemlos Transitionen anderer Codierungsmechanismen einfügen. Beispielsweise sind die ersten 10 Transitionen SpV-codiert, dann folgen linear oder getrennt codierte Transitionen und anschließend wieder SpV-codierte.

Die Größe des zeitlichen Gewinns an Bearbeitungszeit ist im Wesentlichen von der Anzahl der Kanten, des Umfangs der zusätzlichen Schaltbedingung abhängig. In Grenzbereichen ist auch die Zeit, die für die zusätzlichen Sprünge benötigt wird ausschlaggebendes Kriterium für die Anwendung dieser Codierungsart.

Auch die Netztopologie muss berücksichtigt werden. Stark vermaschte Netze führen zum erhöhten Verwaltungsaufwand der Transitionsflags. In Ausnahmefällen kann die Anzahl der Marken im Netz so groß sein, dass zu viele Transitionsbedingungen zu prüfen sind.

Eine automatische Codeerzeugung ist möglich.
[siehe 1.4 Flussdiagramm zur Sprungverteiler Codierung von Transitionen]

Tabelle 3.7 Codierung Sprungverteiler

Tabelle 3.8 Codierung der Transition für den Sprungverteiler³

³Nur der Sprungverteiler unterliegt der regulären, zyklischen Bearbeitung. Die Bearbeitung des Transitionscode steht vollständig unter seiner Kontrolle.

3.3.4.1.6 EinmarkenSprungverteiler ESpV

Eine besondere Form des SpV kann für die Codierung spezieller Netzklassen oder bestimmter Netztopologien nützlich sein.

Netze, die als so genannte Ein-Marken-Netze bezeichnet sind, verfügen, wie der Name schon vermuten lässt, über nur eine Marke im gesamten Netz.

Kann die Transition, deren Vorgängerplatz die Marke besitzt nicht schalten, so kann auch keine andere Transition in diesem Netz schalten. Für die Codierung bedeutet dies, das beim Nichtschalten einer Transition der Rest des Codes auch nicht bearbeitet werden muss. Der Markentransport bleibt aus. Es entsteht keine neue Markierung, die ein Schalten ermöglicht.

Dieses Verfahren lässt sich auch auf Teilnetze oder Netzteile anwenden, sofern sich nur eine Marke innerhalb des Betrachteten befindet. Als Beispiel soll ein IEC 61131-SFC-Netzwerk die Diskussion untermauern. Es verfügt über eine Kette (10 Schritte), gefolgt von einer Simultanverzweigung (insgesamt 40 Schritte). Die Kette (10 Schritte) ist ein typischer Vertreter für einen Einmarken-Bereich, er kann also ESpV-codiert⁴ sein. Ketten sind als eigenständige ESpV interpretiert. Hier erfolgt der Sprung nicht ans Ende des Netzes sondern an den Beginn der Simultanverzweigung. Die Codierung der Simultanverzweigung, ebenfalls bestehend aus zwei Ketten, nutzt ebenfalls jeweils einen Sprungverteiler.

⁴Der Begriff Einmarken meint, dass es nur eine Transition gibt, die schalten könnte.

Eine besondere Codierungsvariante, stützt die per Definition spezifizierte Verfügbarkeit nur einer Marke im gesamten Netz. Außerdem steht der Code in nur einer POE. Hier kann bei jedem Nichtschalten ein Return-Befehl (Verlassen der POE) benutzt werden. Die Nutzung des Return-Befehl innerhalb der Codierung beendet die POE-Ausführung jeweils durch Registrierung des Nichtschaltens der Transition. Untauglich ist diese Verfahren jedoch für SFC der IEC 61131. Da das durch die Norm vorgegebene kontrollierte Beenden der POE durch das System (Aktionsbearbeitung) erfordert. Ferner ist die Return-Variante unter Betrachtung des Aspektes einer Ausgangszuweisung nur bedingt tauglich.

Die geringere Beanspruchung von Rechenzeit ist im starken Maße von der Markierung abhängig. Befindet sich die Marke am Anfang der Kette bzw. des Netzes, ist die Einsparung größer als am Ende. Dies liegt daran, dass der Sprungverteiler immer bis zu der Transition, deren Vorgängerschritt über die Marke verfügt, abzuarbeiten ist.
[siehe 1.5 Flussdiagramm zur Sprungverteiler Codierung im Einmarkenbereich von Transitionen]

Tabelle 3.9 Codierung Sprungverteiler für Einmarkenbereich

Tabelle 3.10 Codierung der Transition für den Sprungverteiler im Einmarkenbereich⁵

⁵Nur der Sprungverteiler unterliegt der regulären, zyklischen Bearbeitung. Die Bearbeitung des Transitionscode steht vollständig unter seiner Kontrolle.

3.3.4.1.7 Feinoptimierung Signaldauer

Eine weitere Verringerung der Rechenzeit ist erreichbar unter Berücksichtigung dynamischer Prozesseigenschaften. Dieses kann von einem Compiler nicht vollautomatisch geleistet werden, da ihm die dynamischen Zusammenhänge weitgehend unbekannt sind. Diese pfiffige Strategie begründet sich darauf, dass es immer ein Signal gibt, dass das letzte ist, das zur Erfüllung der Schaltbedingung beiträgt. Häufig ist es immer das gleiche Signal. Als Signal wird jede Kante und ggf. auch die Zusatzbedingung (z.B. Vergleich) betrachtet, die zu einer Schaltbedingung gehören.

Beispielsweise existiert eine Transition mit einem Vorgängerplatz (Motor dreht) und einem Eingang (Endschalter erreicht). Hier ist es meist der Eingang, der letztendlich das Schalten auslöst.

Welches Signal sich eignet, muss der Programmierer auf Grund seiner Erfahrung oder empirisch bestimmen. Grundsätzlich gibt es auch die Möglichkeit der Messung oder des Protokollieren durch die SPS.

Für den ECC (Execution Control Chart) der IEC 61499, der eine Zustandsmaschine (Petrinetz) darstellt, eignet sich das Ereignissignal einer Transition als erstes abzufragen. Da es nur kurzzeitig auftritt und sich das letzte Signal ist das zur Erfüllung der Schaltbedingung zum Schalten noch fehlt. Angewandt auf die getrennte-, Sprungverteiler- und Einmarken-Sprungverteiler-Codierung wird das Signal (maximal sollten nicht mehr als 2 Signale), das letztendlich das Schalten auslöst, als erste Bedingung geschrieben. Wobei auch hier mindestens zwei Varianten denkbar sind. A) Der Rest der Bedingung, aus der das Signal herausgelöst wurde, bleibt ggf. als eigenständige Teilbedingung mit

Programmverzweigung bestehen, oder b) der Rest wird mit einer anderen Teilbedingung zu einer neuen verbunden. Es findet also eine teilweise oder totale Neuordnung der bisher als Einheit aufgefassten Bedingungsgruppen (Prekanten, Signalprekanten, Zusatzbedingung) statt. Diese zerfallen in der Analyse hinsichtlich der Signaldauer um anschließend neue Gruppen zu schaffen. Wahlfreiheit besteht sowohl in der Zusammensetzung als auch in der Anzahl neuer Gruppen. Bei den Sprungverteilern steht das Signal anstelle des Flags und das Flag kann ganz entfallen. Das verringert zusätzlich die Zeit, die für die Realisierung des Schaltens benötigt wird, da die Flagverwaltung entfällt. Schwieriger ist die Anwendung veroderte Kanten. Am einfachsten ist hier die gesamte ODER-Verknüpfung als ein Signal zu betrachten.

Gibt es zwei letzte Signale, die in der Bewertung annähernd gleiches Zeitverhalten aufweisen oder bestehen diesbezüglich zeitliche Schwankungen, hilft gelegentlich ein Vergleich der Rechenzeit, die zur Ermittlung des Ergebnisses beiträgt (z.B. Rechenzeit für booleschen Eingang und der Vergleich zweier Integer).

In der Feinoptimierung erfolgt eine Neuordnung der Signale zu Teilbedingungen. Die Letzte Bedingung enthält häufig die aufwendigsten Bedingungen (z.B. Vergleicher) und/oder Signale, die eigentlich immer im Sinne der Schaltbedingung erfüllt sind. Anzahl der Bedingungen ist beliebig.
[1.6 Feinoptimierte Splittingcodierung]

Tabelle 3.11 Codierung des feinoptimierten Sprungverteilers

Tabelle 3.12 Codierung der Transition des feinoptimierten Sprungverteilers⁶

⁶Nur der Sprungverteiler unterliegt der regulären, zyklischen Bearbeitung. Die Bearbeitung des Transitionscode steht vollständig unter seiner Kontrolle.

3.3.4.2 Strategien der Netzoptimierung

Neben einer Optimierung der Transitionscodierung lässt sich ein ganzes Netz ebenfalls optimiert codieren. Der SpV wurde bereits erwähnt. Natürlich können die Strategien der Transitionscodierung zusätzlich angewandt werden.

Basis der Strategien zur Netzoptimierung ist die Erkenntnis, dass nur Netzteile bearbeitet werden müssen, in denen es auch eine Marke gibt, denn die Marke ist die Grundvoraussetzung des Schaltens.

Die erste und einfachste Konsequenz hieraus ist: Tote Netze bzw. Teilnetze werden nicht bearbeitet. Dies kann zum Teil automatisch generiert werden. Als typisches Beispiel sei hier eine Fehlerüberwachung (Maximale Belegungszeit überschritten) eines Platzes angeführt. Diese muss nur bei markiertem Platz bearbeitet werden.

Einen Nachteil des SpV-Konzeptes brachte die vorherige Diskussion hervor. Es ist die Eigenschaft, unterschiedliche Bearbeitungszeiten des Netzes allein durch die Positionsabhängigkeit einer Transition (Anfang, Mitte, Ende) innerhalb des SpV-Codes und der Markierung zu erzeugen.

Sprünge mit dynamischen Sprungzielen zeigen eine Verbesserung. Leider finden diese sich in der IEC 61131 nicht wieder, so dass folgende Strategien anzuwenden sind.

3.3.4.2.1 Kettenflag

Eine unverzweigte Kette wird nur bearbeitet, wenn sich mindestens eine Marke in der Kette befindet. Effiziente Lokalisierung vorhandener Marken innerhalb einer Kette bedient sich spezieller Transitionen, die Ketteneintritts- und Kettenaustrittstransition.

Die Eintrittstransition sorgt durch ihr Schalten für eine Marke in dieser Kette und setzt gleichzeitig ein Kettenflag. Können mehrere Marken eintreten, wird ein Zähler als Flag benutzt.

Die Kettebearbeitung ist nur durchzuführen bei gesetztem Kettenflag bzw. bei Kettenflag größer null. Verlässt eine Marke die Kette, setzt die Austrittstransition das Kettenflag zurück bzw. dekrementiert der Zähler.

Letztendlich lässt sich die Gesamtheit aller Kettenflags, die die Ausführung eines Steuerungsnetzes verwalten, auch wieder als Verwaltungsnetzwerk auffassen, welches eng an das Steuerungsnetz gekoppelt ist.

Softwarewerkzeuge sind grundsätzlich in der Lage, das Kettenflag vollautomatisch unter Berücksichtigung voreingestellter Parameter zu verwalten. Ein weiterer Performance-Gewinn ist durch manuelle Eingriffe erzielbar, die den dynamischen Eigenschaften Rechnung tragen. Besondere Aufmerksamkeit ist der Wahl der Ein- und Austrittstransitionen und der Kettenlänge (vgl. Abschnitt 3.3.4.2.2) zu widmen. Hier können statistische Verfahren zur Laufzeit die Wahrscheinlichkeit bezüglich Dauer und Häufigkeit einzelner Marken helfen, sofern dies nicht durch Prozesskenntnis vom Entwickler festzustellen ist. Als Eintrittstransitionen eignen sich solche, deren Schaltbedingung entsprechend selten erfüllt ist. Als Beispiel seien hier Transitionen genannt, deren Schaltbedingung ein Datum, eine Uhrzeit, eine große Verzögerungszeit oder ein eher seltenes Prozesssignal beinhaltet.

Oder es sei der Fall eines Motorstop besonders zeitkritisch. Der Übergang vom Zustand „Laufender Motor" zum Zustand „Motor steht" ist in einer langen unverzweigten Kette modelliert. Die Kette wird in 3 Bereiche eingeteilt. Die Transitionen vor und nach der zeitkritischen Transition sind durch Flags kontrolliert, während die zeitkritische Transition immer bearbeitet wird, um immer in kürzester Zeit schalten zu können.
[1.7 Flussdiagramm zur Kettenflag Codierung von Netzen oder Teilnetzen]

3.3.4.2.2 Segmentierung

Das Mittel der weiteren Segmentierung erweitert das Kettenflag zum strukturierten Kettenflag-Mechanismus und eignet sich für sehr lange Ketten. Dazu erfolgt eine Aufteilung langer Ketten in Bereiche, die Segmente. Jedes Segment verfügt über ein eigenes Segmentflag. Das Prinzip der Segmentverwaltung ist dem des Kettenflags gleich. Es gibt je Segment eigene Ein- und Austrittstransitionen. Ein Extremfall der Segmentierung führt zur Sprungverteilercodierung der Transitionen. Damit ist ebenfalls eine automatische sowie eine manuelle Verwaltung, wie bereits in Abschnitt 3.3.4.2.1 beschrieben ist, möglich.

Ggf. erfolgt eine Kombination aus Kettenflag und Segmentierung, wobei weitere Ebenen der Segmentierung durchaus zulässig sind. Somit entsteht eine Struktur. Auf oberster Ebene steht das Kettenflag, darunter die erste Ebene der Segmente. Eine weitere Segmentierung führt dazu, dass ein Segment die Segmente seiner unteren Ebene kontrolliert. Es wirkt dann wie das Kettenflag, das die nächste Segmentebene kontrolliert. Je mehr Kontrollinstanzen (Segmentebenen) zu durchlaufen sind, desto seltener sollten diese Netzelemente bearbeitet werden müssen bzw. die Wahrscheinlichkeit einer Bearbeitung nimmt ab. Die oberste Ebene besteht entweder nur aus Verwaltungscode oder zusätzlich bereits funktionellen Code im Sinne der Applikation.
[siehe 1.8 Flußdiagramm zur segmentierten Codierung von Netzen oder Teilnetzen]

Prinzip des Kettenflags mit weiterer Segmentierung

Eine Schrittkette, wie in 1 schwarz dargestellt, muss nur bearbeitet werden, wenn sie auch über mindestens einen aktiven Schritt verfügt. D.h. bleibt die Bearbeitung aus, weil es keinen aktiven Schritt gibt, lässt sich die Verarbeitungszeit der gesamten Kette einsparen. Das Potential der Performancesteigerung ist abhängig von der Länge der Kette. Je länger eine unverzweigte Kette ist, desto größer ist der Leistungszuwachs, sofern sich kein aktiver Zustand in ihr befindet. Softwaretools bilden häufig jedoch ablauforientierte Sprachen ab, als handle es sich um ein verknüpfungsorientiertes Modell und verschwenden somit einen Teil der Leistung, um zu ermitteln, dass keine Zustandsänderung erfolgen kann, was jedoch von vornherein klar gewesen ist.

Gibt es einen aktiven Zustand innerhalb einer Schrittkette, stellt sich die Frage, ob die Kette über die gesamte Länge zu bearbeiten ist. Lässt sich die Kette in Teilsegmente gliedern, die wiederum nur dann zu bearbeiten sind, wenn sich aktive Schritte innerhalb eines Segmentes befinden.

Wann sich eine derartige Kettenoptimierung lohnt, hängt wie bereits erwähnt wesentlich von der Länge einer solchen Kette ab, die die Summe der Zeiten der benötigten Befehle und von der Summe der benötigten Zeiten der Befehle, die zur Koordinierung nötig sind, gegenüberstellt.

Optimierte Kettenbearbeitung

Nahe liegend ist eine Optimierung eines Ablaufmodells auch mit den Mitteln des Modells zu implementieren. Dadurch können bereits implementierte Funktionen des Compilers genutzt werden oder eine manuelle Realisierung ist ggf. auch möglich und vor allem lässt sich Normkonformität herstellen. Die 1 zeigt, wie das Verhalten einer Kettenoptimierung (mittels Petrinetzen rot gekennzeichnet) mit einfachen Mitteln gestaltet werden kann. Dazu wird, sobald die Aktivierung des ersten Schritts einer Kette oder eines Segmentes durch die Transition erfolgt, zusätzlich ein oder mehrere Ketten-Flag gesetzt. Das Flag wird wieder zurückgesetzt, sobald der letzte Schritt der Kette oder des Segmentes wieder deaktiviert wird.

Hier wird mit einem Flag (LeerFlag) gearbeitet, das angibt, ob die Schritte der gesamten Kette deaktiviert sind und jeweils einem Flag, das angibt, ob ein Segment (SgFlag1...n) über einen aktiven Zustand verfügt. Auf das LeerFlag kann ggf. verzichtet werden, es dient dazu, dass nur eine Abfrage im Falle einer deaktivierten Kette, anstatt 3 (SgFlag1...n) erfolgen muss. In diesem Fall wird fast die gesamte Bearbeitungszeit der Kette eingespart. Die Bearbeitungszeit verkürzt sich nahezu auf ein drittel bei Vorhandensein eines aktiven Schrittes innerhalb der Kette unter der Annahme, daß alle Segmente gleiche Bearbeitungszeit in Anspruch nehmen.

Dieses einfache Verfahren lässt sich sogar mit den Mitteln, die AWL zur Verfügung stellt realisieren.

Feinabstimmung

Unter Ausnutzung dynamischer Effekte ist eine zusätzliche Performanceverbesserung zu erwirken. Jeder Platz verfügt über spezifische, prozessabhängig Verweildauern der Marken. Eine Segmentierung, deren Segmente die Aufteilung der Zonen gemäß der Verweildauer widerspiegelt bringt zusätzlichen Nutzen. Es sind Bereiche in denen sich Marken bevorzugt aufhalten (am längsten) zu bilden und Zonen mit geringerer Aufenthaltswahrscheinlichkeit. Die Nutzung dynamischer Eigenschaften ist nicht automatisch zu leisten. Die Segmentierung kann somit automatisch (vorgegebene Segmentgröße) und manuell (Anwendervorgabe für einzelne Segmente) erfolgen.
[siehe 1.9 Ausschnitt einer unverzeigten AS-Kette deren Bearbeitung durch Kettenflags koordiniert wird]

3.3.4.2.3 Einmarkendispatcher

Befindet sich nur eine Marke in einem (Teil-)Netz kann auch eine CASE-Anweisung genutzt werden. Jede Transition stellt dann einen CASE-Fall dar. Daraus ergibt sich, dass von allen Transitionen einer CASE-Anweisung immer nur eine schalten darf. Beim Schalten einer Transition trägt sie ihre Nachfolgertransition in den CASE-Selektor ein. Diese Variante ist geeignet für Zielsysteme die nicht über AWL oder eine ähnliche Sprache verfügen. Nachteilig ist hier, dass je Bearbeitung nur eine Transition schalten kann, es sei denn es wird eine weitere Schleife um die CASE-Anweisung gelegt. Sie kann Vorteile gegenüber den IF-Anweisungen der Transitionen haben.

3.3.4.2.4 Dispatcher

Der Dispatcher ist sehr aufwendig. Er eignet sich insbesondere für solche Netze, deren Anzahl von Transitionen, die aufgrund der Netzmarkierung schalten könnten sehr viel kleiner sind als die der nicht schaltbereiten. Dabei muss die Anzahl der Transitionen, die den gleichen Vorgängerplatz haben, möglichst klein sein (Kleiner Konfliktgrad).

Das Grundprinzip ist recht einfach. Es gibt eine Liste (z.B. Array) der Transitionen die aufgrund der Netzmarkierung schalten könnten. Transitionen, die schalten, löschen sich aus dieser Liste und tragen alle Transitionen in die Liste ein, die einen ihrer Nachfolgerplätze als Vorgängerplatz besitzen. Besitzen mehrere Transitionen den gleichen Nachfolgerplatz ist es ratsam, diesen zusätzlich mit Flags zu verwalten, damit die entsprechenden Transitionen nicht zu früh in die Liste der schaltfähigen Transitionen gelangt, da die Listenverwaltung ziemlich rechenintensiv ist. Die Liste kann aus Sprungzielen bestehen oder aus Zeigern (Pointer).

Als nachteilig kann hier sein, dass bei Verwirklichung bester Ergebnisse nicht mehr alle Platzzustände in booleschen Variablen abgelegt sind. Bei verzicht auf Performance ist dies zusätzlich möglich. Daher muss z.T. aus der Liste schaltfähiger Transitionen auf Platzzustände geschlossen werden, was ggf. den Debug-Modus komplexer gestaltet. Generell könnten zu lasten der Rechenzeit alle Plätze mit booleschen Variablen abgebildet sein. Gerade der Dispatcher eignet sich für eine Implementierung direkt in der SPS-Runtime, kann aber durchaus auch im IEC-Code realisiert sein

3.3.4.2.5 Dynamischer Sprungverteiler (Nicht für IEC 61131-Systeme)

Der dynamische Sprungverteiler (DSpV) kann als Alternative den einfachen Sprungverteiler oder auch den Dispatcher ersetzten oder zum Teil ergänzen. Ersetzt man den gesamten Sprungverteiler durch eine Variable und einen Sprungbefehl mit dynamischem Sprungziel, muss jede Transition, in ihrer Schalthandlung, anstatt der Verwaltung der Transitionsflags, die Folgetransition in die Variable ein. Eine Segmentierung kann entfallen. Die Verwaltung paralleler schaltfähiger Transitionen darf nicht ohne weitere Maßnahmen auf diese Weise erfolgen. Er eignet sich nur für unverzweigte Ketten mit maximal einer Marke. Aufwendiger ist die Verwendung dynamischer Sprungverteiler für parallel schaltfähige Transitionen. Entweder sind Listen oder Schleifen zu verwalten oder für jede mögliche parallel stattfindende Schaltung muss ein Sprungverteiler stehen. Bei steigender Vermaschung steigt die Komplexität deutlich an. Auch wenn das Auftreten von Einschränkungen erkennbar ist, lohnt eine genauere und tiefer gehende Betrachtung, sobald dynamische Sprungziele in der IEC Spezifikation zu finden sind. Einige IEC-Systeme nutzen bereits heute dynamische Sprungziele zur effektiven Transformation von CASE-Anweisung in AWL, verbergen jedoch diese Eigenschaft vor dem Anwender.
[siehe 1.10 Dynamischer Sprungverteiler]

Tabelle 3.13 Mögliche Codierung des dynamischen Sprungverteilers

Tabelle 3.14 Codierung der Transition des dynamischen Sprungverteilers

3.3.5 SFC Optimierung

Bedingt durch die vorgeschriebenen komplexen Abläufe (Aktionsauswertung, Netzweite Ausbreitung eines Schrittzustandes, Schrittzeiten), die im Hintergrund während der SFC-Abarbeitung, stattfinden, entsteht, was die Reaktionsgeschwindigkeit angeht, der Eindruck einer „lahmen Ente" in im Vergleich zu den anderen Sprachen. Mittels einer Optimierung kann auch SFC sich zu einem „road runner" entwickeln und in vielen Fällen die Lösung mit der kleinsten Reaktionsgeschwindigkeit darstellen. SFC wird damit weiter an Bedeutung zunehmen.

Zwei denkbare Ansätze stehen zur verbesserten Performance eines SFC zu gelangen zur Verfügung. Idealerweise Unterstützt ein SFC-System bereits automatisch die Optimierung. Im anderen Fall bleibt dem Anwender nur die optimierte manuellen Gestaltung der Lupen (Transition, Aktion). Jedoch ist der alleinige Gewinn, der so zu erzielen ist, immer deutlich schlechter, als bei den automatischen oder dem Mix aus automatisch und manuellem Verfahren. Beide Ansätze werden im Folgenden kurz diskutiert.

3.3.5.1 SFC-Systeme

Transitionen

Von Bedeutung für die automatische Codeerzeugung sind das Splitting, der Sprungverteiler, und die Einmarkenbetrachtungen, sowie das Kettenflag, die Segmentierung und der Dispatcher. Sofern eine Systeminterne Unterstützung dynamischer Sprungziele gegeben ist, kann auch der DSpV zum tragen kommen. Ebenso kann die halbautomatische Feinoptimierung zur Verfügung stehen.

Bestimmung der Aktionsausführung

Gerade bei Konzeption von Aktionen und deren Aufrufen ist besondere Sorgfalt angebracht. Da diese bekanntlich nach IEC 61131 immer mindestens zweimal bearbeitet werden müssen, von einigen Ausnahmen abgesehen. In letzter Konsequenz bedeutet dies, dass eine Aktion häufig doppelt so viele Bearbeitungen erfährt wie eine Transitionsbedingung, vorausgesetzt, es findet eine Bearbeitung statt.

Zur Bestimmung der Ausführung kann grundsätzlich die Verwendung der Mechanismen zur Optimierung von Transitionen Anwendung finden. Splitting, Feinoptimierung über die Signaldauer und ggf. der Dispatcher kommen insbesondere zum tragen.

3.3.5.2 Lupen Gestaltung durch den Anwender

Anwender haben, wenn auch eingeschränkt, Einfluss auf die Performance, sofern entsprechenden Lupen (z.B. Transitionsbedingung, Anweisungen der Aktionen) einer optimierten Codierung unterliegen. Einschränkungen sind hinsichtlich der genormten nicht beeinflussbaren Eigenschaften festzustellen. Damit sind im Allgemeinen die in Abschnitt 3.3.4.2 vorgestellten Strategien zur Netzoptimierung nicht zugänglich.

Transitions- und Aktionslupe

Transitionsbedingungen sollten möglichst in AWL, unter Verwendung der Splitting bzw. Feinoptimierungsmethode oder beidem geschrieben sein. Damit kann der Anwender direkten Einfluss auf die Ausführungszeit nehmen, auch wenn sein System ansonsten keine Codeoptimierung bietet. Der Einsparungseffekt ist stark von der Codeumsetzung des Systems abhängig. Wird die Transitionsbedingung unabhängig vom Vorgängerschritt immer bearbeitet, ist die Einsparung am größten. Erfolgt die Abarbeitung hingegen nur bei aktivem Schritt, so unterstützt das System bereits eine Optimierungsform. Die Performance erfährt eine weitere Steigerung.

Die Häufigkeit mit der eine Aktion ausgeführt wird (vgl. Abschnitt 3.3.5.1), wenn sie aktiv ist kann u.U. erheblich zur Zykluszeit beitragen.

Eine Aktion sollte daher immer nur auf das wesentliche beschränkt bleiben und wenn möglich in AWL und ggf. mit Sprüngen koordiniert werden. Dabei sollte die Vermeidung von schwer lesbaren Spaghetticodes im Vordergrund stehen. Außerdem kommen die allgemeinen Optimierungsmaßnahmen des Abschnitts 3.2 in Frage.

3.3.6 Petrinetz-Codeoptimierung durch Faltung

Allgemein üblich in der Programmiertechnik ist die Wiederverwendung von Softwaremodulen, Makros oder durch Verwendung von Vorlagen (Objekte) und deren Instanzierung. Die Instanzierung ist ein wirkungsvoller Mechanismus einen kompakten, transparenten Code zu erzeugen, wobei jede Instanz ein identisches kausales Verhaltensmuster mit individuellem Status zeigt. Hinsichtlich der Geschwindigkeit (insbesondere bei IEC 61131-Systemen) sind keine wesentlichen Vorteile zu verzeichnen. Der nur einmal vorhandene Bausteinrumpf (Source) ist für jede Instanz abzuarbeiten.

Ganz oder teilweise identische Petrinetze (SFC-Norm lässt dies nicht zu) lassen sich zu einer kompakten Darstellungsform falten. Die ursprünglichen binären Netze (Platz ist durch boolesche Variable abgebildet) werden mittels Faltung zu Bitfolgenetzen (8 Plätze sind durch eine Byte-Variable abgebildet). So lassen sich bis zu 8, 16, 32 oder 64 binäre Netze durch einen Source abarbeiten, der sich nur hinsichtlich der Datentypen (Byte, Word, Doppelwort, Langwort) unterscheidet. Der Code ist ebenfalls sehr kompakt und lässt sich als ganzes zusätzlich bei Bedarf instanzieren und zeichnet sich durch hohe Performance aus.
[siehe 1.11 Gefaltetes Netz]

3.4 Schlussbemerkung

Insbesondere wurde darauf geachtet, dass eine Implementierung mittels des IEC-Befehlssatzes (vorzugsweise AWL) möglich ist. Damit besteht Kompatibilität, eine Implementierung ist sowohl manuell als auch automatisch möglich und nicht zuletzt Altprojekte lassen sich einfach anpassen (meist nur neu übersetzen), sofern eine automatische Optimierung besteht.

Wie gezeigt, sind die Möglichkeiten der Optimierung vielseitig und von vielen Parametern abhängig. In vielen Fällen lässt sich jedoch ein optimierter Code automatisch generieren. Dem Nutzer bleiben so viele Berechnungen und Abschätzungen erspart. Die Notwendigkeit einer Feinoptimierung unterliegt der Betrachtung jedes Einzelfalls und ist manuell durchzuführen. Die vorgestellten Strategien lassen sich auf Petrinetze, SFC, ggf. IEC 61499, Grafcet sowie Automaten und ablauforientierte Modelle anwenden. Bedingt durch das vorgeschriebene Verhalten von SFC-Netzwerken (Berechnung der Actionsflags (Q und A), Ausbreitung des Schrittzustandes über das gesamte Netz, Bestimmungszeichen, Schrittzeiten) ist die erreichbare Reaktionszeit im Allgemeinen etwas größer, als sie für Petrinetze zu erwarten ist.

Je nach Topologie, Netzklasse und Markierung eines Netzes ist eine Reduzierung auf 5% bis 60% (Einsparung 95%–40%) durchaus möglich. Das heißt ein Programm, das linear codiert 100ms benötigt, wäre optimiert in 5ms bzw. 60 ms abgearbeitet. Dies sind hervorragende Ergebnisse. Dieses rechnerisch unter der Annahme, dass jede Programmzeile gleiche Bearbeitungszeit beansprucht (vgl. Excel-Tabelle auf dem beiliegenden Datenträger). Die wundersame Wandlung von der „lahmen Ente" zum „road runner" lässt Petrinetze zu einem der Lösungsmodelle mit den wohl kleinsten Reaktionszeiten werden, wenn nicht sogar der schnellsten Steuerungssoftware werden, die es je gab.

Die entstandene Minderung der erforderlichen Rechnerleistung erhöht die Reaktionsfähigkeit oder kann helfen, die ständig wachsenden Forderungen nach Steigerung des Funktionsumfangs zu erfüllen bzw. kann neue Anwendungsgebiete für Petrinetze und SFC erschließen. Ferner ist die Optimie rungsmöglichkeit, wie hier vorgestellt, ein weiteres schwerwiegendes Argument, wie die vielen Vorzüge auch, die Petrinetze bieten für ihren Einsatz in der Steuerungstechnik. Verknüpfungsorientierte Modelle lassen derart deutliche Optimierungsmöglichkeiten nicht zu.

4 Glossar

Konflikt (vorwärts)

Ein vorwärts Konflikt entsteht, wenn mehrere Transitionen über eine Prekante (Standardkante) mit dem gleichen Vorgängerplatz verbunden sind. Damit kann das Schalten einer Transition die Schaltbereitschaft der übrigen aufheben.

Unverzweigte Kette oder unverzweigte Transitionsfolge beschreibt eine Aneinanderreihung von Transitionen, deren Nummerierung vollständig und lückenlos, jedoch nicht zwingend fortlaufend beinhaltet innerhalb der nebenläufig schaltenden Transitionen nicht existieren.

Ein Fall ist ein ganz bestimmter Markierungszustand eines Netzes. So sind zwei Markierungen, die sich dadurch unterscheiden, dass bereits ein Platz eine veränderte Belegung aufweist zwei unterschiedliche Fälle.??

Schaltbereitschaft (schwache oder unsicher)

Schaltregel (Konzessionsregel)

Schaltbedingung

Prüfen der Schaltbedingung

Schalthandlung

Schaltverhältnis (SV) einer Transition gibt an, das Verhältnis der Häufigkeit des Schaltens zur Häufigkeit des Nicht-Schalten. Die Summe aus Nicht-Schalten und Schalten ergibt die Anzahl der gesamten Bearbeitungen der Transition (oder des Netzes) bzw. der Source, der das Netz repräsentiert. Eine Transition, die nie schaltet (ist meist unsinnig) hat ein Schaltverhältnis von 0. Sie muss jedoch nicht Tod sein, das Schaltverhältnis einen bestimmten Zeitraum betrachtet.

Konfliktanzahl

Anzahl aller Konflikte in einem Netz

Konfliktgrad

Kennzeichnet die Anzahl von Transitionen, die um den gleichen Platz in Konflikt stehen.

Kausalitätsgrad einer Transition gibt an, wie viele direkte Vorgängertransitionen schalten müssen, damit die Schaltbereitschaft gegeben ist. Dabei reduzieren ODER-verknüpfte Standard-Prekanten den Kausalitätsgrad. Transitionen, die denselben Ausgangsplatz besitzen, der Eingangsplatz der untersuchten Transition ist, zählen jeweils mit.

Selten schaltende Transitionen oder Kausalketten, wie die Fehlererkennung an einem Platz, kann die Bearbeitung direkt von dem Platz abhängig machen.

logische Programmlänge

Anzahl der tatsächlich bearbeiteten Zeilen in einem ausgewählten Programmzustand. Übersprungene Zeilen verkürzen die logische Programmlänge, während jeder Schleifendurchlauf eine Verlängerung bedeutet.

Benchmarks

Ursprünglich bezeichnet der Begriff die Einkerbungen auf der Werkbank (workbench) des Handwerkers zur Längenmessung. Übertragen auf die Technik ist der Benchmark eine bestimmte Aufgabenstellung, die Rechnersystemen zur Leistungsmessung auferlegt wird, um die Messergebnisse zu vergleichen

Claims

Verfahren zur Ausführungszeitoptimierung für Umsetzungen von zustands- oder ablauforientierten Modellen, wie Petrinetzen oder Automaten, in reale Lösungen der Automatisierungstechnik für softwarebasierte Lösungen, dadurch gekennzeichnet, dass – eine Kausalkettenoptimierung sowie eine Elementoptimierung jeweils einzeln oder gemeinsam mindestens auf einen Teil des Modells durch Abbildung in einer Programmiersprache unter Nutzung der Eigenschaften der Zielsprache angewandt wird, – wobei bei der Kausalkettenoptimierung eine Kausalkette, ein Teil einer langen Kette oder eine Gruppe von Kausalketten nur bedingt bearbeitet werden, wobei die Bedingung(en) auf der Auswertung des aktuellen Zustands des Modells beruhen und nur im Falle mindestens eines aktiven Zustands innerhalb der Kausalkette, eines Teils einer Kausalkette oder einer Gruppe von Kausalketten, die Bearbeitung ermöglichen, – wobei das Modell funktionale Modellelemente, die jeweils aus einer oder mehreren Bedingungen und aus einem oder mehreren bedingungsabhängigen Teilen bestehen, aufweist, – und wobei Verzweigungsstellen in einem oder mehreren bedingungsabhängigen Teilen eines Modellelementes zwecks Elementoptimierung hinzugefügt werden, die von einer Bedingung abhängig festlegen, ob die Bearbeitung des bedingungsabhängigen Teils oder dieser Teile eines Modellelementes weitergeführt oder beendet wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass abhängig vom Zustand des Modells Modellelemente selbst sich zur Bearbeitung an- oder abmelden und abhängig vom Zustand des Modells, Modellelemente andere Modellelemente zur Bearbeitung an- oder abmelden.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet. dass die Bedingungen in Teilbedingungen zerlegt werden, wobei diejenige Bedingung, die als letzte die Gesamtbedingung erfüllt, zuerst geprüft wird.
Verfahren nach einem der Ansprüche 1 bis 3, gekennzeichnet durch den Einsatz auf farbige Netze, Prädikatsnetze und Netze mit Platzkapazitäten > 1.