Traitement en cours

Veuillez attendre...

Paramétrages

Paramétrages

Aller à Demande

1. WO2001075535 - PROCEDE POUR REGULER DES MECANISMES ET DES SYSTEMES TECHNIQUES, DISPOSITIF ET LOGICIEL DE COMMANDE APPROPRIES

Note: Texte fondé sur des processus automatiques de reconnaissance optique de caractères. Seule la version PDF a une valeur juridique

[ DE ]

Verfahren zum Steuern von Mechanismen und technischen Systemen, Einrichtung und Steuerungssoftware

Beschreibung

Die Erfindung bezieht sich auf ein Nerfahren zum Steuern von Mechanismen und technischen Systemen sowie auf die dafür zu gestaltenden Einrichtungen einer elektronischen Steuerung und ein Nerfahren zur Erstellung der Steuerungssoftware.
Aus der DE 44 07 334 AI ist ein Nerfahren zum Erstellen und Darstellen von Steuerungen bekannt, mit dem sich Steuerungen auf einfache Weise graphisch entwerfen lassen. Die gewünschte Funktion der Steuerung wird als ereignisgesteuertes Netzwerk von Symbolen mit frei wählbaren Verbindungen graphisch in einen Computer eingegeben oder von einem Computer dargestellt. Das Netzwerk in maschinenlesbarer Form umgewandelt kann von dem Computer oder einem separaten Steuerungsrechner als Steuerungsprogramm verwendet werden. Das Verfahren eignet sich für speicherprogrammierbare Steuerungen sowie DDC- Anlagen.
Aus der DE 195 13 801 AI ist ein Verfahren zur automatischen Erzeugung einer Steuerung für einen Prozess bekannt, bei dem ein nicht deterministischer Automat, der alle physikalisch möglichen Verhaltensweisen der Steuerung beschreibt, festgelegt wird, bei dem die erlaubten Zu-standsübergänge des von der Steuerung zu beeinflussenden Prozesses beschrieben werden, bei dem der Automat so eingestellt wird, dass er vorgegebene Sicherheitsbedingungen erfüllt, bei dem der Automat so eingestellt wird, dass er die Funktion des aus der Steuerung und Prozess bestehenden Systems erfüllt. Das Verfahren macht von der Programmiersprache CSLxt Gebrauch, um die Komponenten der Spezifikation des Systems zu beschreiben. Für die Spezifikation des Prozessmodells werden nicht die Zustandsübergänge detailliert beschrieben, sondern sogenannte vordefinierte qualitative Constraints verwendet, die zur automatisches Generierung der Steuerung dienen.
Nachteilig ist, dass die Beschreibung von Zustandsübergängen auf einem höheren Sprachniveau fehlerhaft sein kann, und eine nachträgliche Korrektur der Steuerung nicht ohne weiteres möglich ist.
Darüber hinaus sind Speicherprogrammierbare Steuerungen SPS
Hardware-SPS
Software-SPS
Programmiersysteme und Programmiersprachen
Simatic S7
Programmierung nach IEC 1131-3 Norm
Standardprogrammiersprachen: Kontaktplan, Funktionsplan, AWL, Structured Text
bekannt.
Nachteilig bei dem Stand der Technik ist, dass im Prinzip mit Boolscher Algebra Bedingungen aus Eingängen (Sensoren) für das Setzen von Ausgängen (Aktoren) formuliert werden, die ständig zyklisch neu durchgerechnet werden. Dieser Programmieransatz ist historisch entstanden. Beleg oder Indiz für diesen Zustand ist die Tatsache, dass nach der allgemein akzeptierten Norm der „Konta tplan" noch als Programmiersprache verwendet werden kann.
Trotz aller CAE-Unterstützung durch Grafikoberflächen und Hochsprachen bleiben prinzipbedingte Grundmängel, wie die Unübersichtlichkeit des Programms und dessen individuelle Prägung vom Programmierer, nie vollständige Prüfbarkeit des Programms in seiner Funktionalität, da das Ergebnis der zyklischen Berechnungen von kombinatorischen und zeitlichen Zufälligkeiten beein-flusst werden kann und die schwierige Gestaltung von difFerenzierten Fehlerreaktionen.
Die Aufgabe der Erfindung besteht darin, eine Steuerung für Mechanismen oder technische Systeme anzugeben, die die Steuerungsaufgabe ohne den Einsatz Boolscher-Algebra-Bedingungen löst, wobei ein übersichtliches Programm, frei von individueller Prägung und mit vollständiger Prüfbarkeit vorliegen soll.
Erfindungsgemäß wird die Aufgabe durch ein Verfahren mit den im Anspruchs 1 genannten Merkmalen gelöst. Die Aufgabe wird weiterhin durch ein Verfahren zur Erstellung einer Steuerungssoftware mit den im Anspruch 11 und durch eine Einrichtung mit den im Anspruch 16 aufgeführten Merkmalen gelöst.
Vorteilhafte Ausgestaltungen und Weiterbildungen sind Gegenstand zugehöriger Unteransprüche.

Das Wesen der Erfindung besteht darin, dass abgeleitet von der Funktionalität des zu steuernden Mechanismus oder technischen Systems, insbesondere mit dessen Entwicklung, mit technischen Mitteln die Funktionalität der zu steuernden Einrichtung in einem als Steuerung gestalteten Steuerungscomputer als ein vollständiges Abbild des befehlsgemäßen Sollzustand des Systems abgelegt, verwaltet und aktualisiert wird und ein Vergleich dieses Sollzustandes über die gemeldeten Sensorsignale mit dem Ist-Zustand der technischen Einrichtung erfolgt. Dieser Soll-Ist- Vergleich erfolgt ständig für alle Sensorsignale des zu steuernden Systems. Bei Abweichungen des Ist-Zustandes zum Sollzustand werden vorbereitete Algorithmen abgearbeitet und ebenso vorbereitete zweckmäßige Entscheidungen aktiviert. Jedes Sensorsignal wird damit nur mit genau einem Sollsignal verglichen und dieser Vergleich dient ausschließlich der Zustandsidentifikation des technischen Systems. Zustandsänderungen erfolgen ausschließlich über Befehle auf sprachlich-funktionellem Niveau. Diese Befehle werden in einem besonderen Bereich der Steuerung verwaltet, bei Start eines Befehls wird der Sollzustand im Abbild aktualisiert und die dem Befehl entsprechende Änderung des Ist-Zustandes des technischen Systems innerhalb einer vorgegebenen Zeit kontrolliert.
Die zu steuernden Einrichtungen sind in ihren Elementarfunktionen mit deren befehlsgemäß definierten Zuständen und den zugehörigen Signalbildern der Sensoren und Aktoren in der Steuerung gespeichert, wobei ausgehend von einem definierten Referenzzustand zu Beginn der Steuerungsaktivierung ein ständiger Vergleich der von der technischen Anlage durch die Sensoren gemeldeten Ist-Zustände mit dem in der Steuerung gespeicherten Sollzustand für alle Elementarfunktionen erfolgt und damit jede Abweichung im zu steuernden System vom befehlsgemäßen Sollzustand erkannt wird, wobei ein den Zustand des technischen Systems verändernder neuer Befehl mit seinem Start den Sollzustand für den Vergleich aktualisiert und auf der Grundlage ebenfalls gespeicherter zulässiger Übergangszeiten die Zeit bis zur Rückmeldung des befehlsgemäßen neuen Zu-standes überwacht, wobei Sensorsignale und vergleichbare Informationen ausschließlich der Zustandsidentifikation dienen und Zustandsänderungen ausschließlich über den Start von dafür auf logisch-funktionellem Sprachniveau frei definierten Befehlen erfolgt, denen die mit Sensor- und Aktor-Signalen definierten Elementarbefehle zugeordnet sind.
Vorteilhaft werden in einem als EF-Cόntroler bezeichneten Programmbaustein die Zustände aller Elementarfunktionen als aktueller Sollzustand mit den zugehörigen Aktoren und Sensoren geführt und damit jede über die Sensoren erkannte Zustandsänderung des technischen Systems auf Übereinstimmung mit dem in der Steuerung geführten Sollzustand bewertet.
Ein nicht dem Soll entsprechender Zustand einer Elementarfunktion des zustandsbeschreibenden Signalbildes wird vorteilhaft an einen als „Nichtsollbewerter" bezeichneten Programmbaustein übergeben, in dem für ausgewählte Zustände von Elementarfunktionen Reaktionsbefehle gespeichert sind, die bei Übereinstimmung mit dem zur Prüfung übergebenen Zustand gestartet werden, wobei in allen Fällen differenzierte Fehlermeldungen erzeugt werden.
Einem Befehl als Befehlssatz werden sowohl die neuen Sollzustände der Sensoren und Aktoren, die Übergangszeiten zum neuen Sollzustand als auch die bei Abweichungen zu startenden Reaktionsbefehle, jeweils unterschieden in vor dem Start und nach erfolgter Ausführung zu löschende und zu setzende Reaktionsbefehle auf ausgewählte Zustandsmeldungen zugeordnet, wobei vorteilhaft ein als „Befehlsaufbereiter" bezeichneter Programmbaustein die dafür erforderliche Organisation im System übernimmt und in diesem Programmbaustein auch die Freigabe eines nächsten Befehls bei Befehlsfolgen nach Erfüllungsmeldung des vorhergehenden sowie die Organisation von Parallelbefehlen durch je nach Bedarf temporäres Eröffnen von parallelen Abarbeitsfolgen realisiert wird.
Vorteilhaft werden dem organisierten Steuerungssystem Sensorsignale und weitere zu kontrollierende Informationen in einem hier als „Zustandsüberwacher" bezeichneten Programmbaustein zu einem lückenlosen Datenwort zusammengezogen, wobei den Signalen die Adresse der zugehörigen Elementarfunktion im EF-Controler zugeordnet bleibt und für den Vergleich jedem Sollsignal das Ist-Signal in gleicher Struktur gegenübersteht, was einen programmtechnisch sehr effektiven Soll-Ist- Vergleich ermöglicht, wobei eine aufgetretene Abweichung eines Signals nach der Übergabe zur Auswertung als neuer Vergleichszustand eingetragen wird und damit ein Vergleich immer zum letzten ausgewerteten Zustand erfolgt und jede Zustandsänderung damit nur einmal ausgewertet wird, wobei der Vergleich der Soll-Ist-Signale gerichtet erfolgt und nach einer Unterbrechung für die Auswertung einer Abweichung der Vergleich bei dem der Unterbrechungsstelle folgenden Signal fortgesetzt wird, wodurch gesichert ist, dass jede zeitlich hinreichend lange Zustandsänderung erfasst und ausgewertet werden kann.
Bei einem so organisierten Steuerungssystem wird jede im Programmbaustein Zustandsüberwacher erfasste Zustandsänderung in einem Ereignis-Zeit-Protokoll gespeichert, wodurch auf ein- fachstem Weg damit beschriebene Prozessparameter zugänglich werden, damit auch beispielsweise Signalschwingungen erkannt und gegebenenfalls ausgefiltert werden können.
Die den Echtzeitforderungen unterliegenden Programmbausteine Befehlsaufbereiter, EF-Controler, Zustandsüberwacher und Nichtsollbewerter werden vorteilhaft zu einer Funktionseinheit zusammengefasst, die als „Ausführungsrechner" bezeichnet wird, wozu ein spezieller Prozessor eingesetzt wird, während die nur auf logisch-fünktionellem Sprachniveau formulierten Befehle der eigentlichen Nutzungsprogramme in einer zweiten, nicht Echtzeitforderungen unterliegenden Funktionseinheit, die als „Befehlsrechner" bezeichnet wird, organisiert werden, wobei der Befehlsrechner zweckmäßigerweise bei größerem und variablen Befehlsumfang über einen eigenen Prozessor verfügt und hier auch die Kommunikation komfortabel gestaltet werden kann.
Vom Befehlsrechner an den Ausführungsrechner übergebene Befehle werden dort vorteilhaft ohne Prüfung ausgeführt, wobei der Ausführungsrechner jeweils die auszuführende Aktion autark realisiert. Deshalb werden im Befehlsrechner auf logisch-funktionellen Befehlsniveau zu den sich ausschließenden Zuständen Sperrenverzeichnisse geführt und verwaltet, die den prozess- und raa-schinenseitig determinierten Anteil von Verriegelungen übernehmen, wobei hier im Befehlsrechner mit einem Nutzungs-Prozessbefehl außer den Informationen, welche Befehle dem Ausführungsrechner zu übergeben sind, auch festgelegt wird, für welche anderen Nutzungsbefehle Sperren während oder nach der Ausführung zu setzen oder aufzuheben sind.
Der Ausführungsrechner kann einen erhaltenen Befehl autark ausführen, wobei der Befehlsrechner dem Ausführungsrechner den nächstfolgenden geprüften Befehl in einem Befehlspuffer als Zwischenspeicher bereitstellt und nach dem Bereitstellen den Zustand im Befehlsrechner auf den Stand aktualisiert, der nach der Ausführung dieses bereitgestellten Befehls eintreten wird und damit eine Prüfung des nachfolgenden Befehls im Befehlsrechner bereits während Befehlsausführung des vorhergehenden Befehls im Ausführungsrechner erfolgt und damit in der Regel ein schnellerer Programmablauf realisiert werden kann. Nicht verträgliche Befehle werden bereits im Befehlsrechner als nicht zulässig erkannt und ausgewiesen und es erfolgt kein Start eines solchen Befehls. Ist der vorbereitete Befehl zulässig, tritt bei fehlerfreier Ausführung der für die Prüfung des Befehls im Befehlsrechner erwartete Zustand ein und der Ablauf wird fortgesetzt, während bei einem Fehler ein Rücksetzen auf den Zustand zum laufenden Befehl als Fehlerzustand vorgenommen wird.

Der Anwender dieser Steuerung wird bei der Erstellung eines Steuerungsprogramms vorteilhaft durch ein Entwicklungsprogramm dialoggeführt unterstützt, wobei die erste Beschreibung des zu steuernden Systems die Angabe der hierarchischen Funktionsstruktur des Systems verlangt, das jeweils untere Ende dieser Struktur als Elementarfünktion betrachtet wird und jede Elementarfunktion ebenfalls im Dialog in ihren Befehlszuständen zu definieren ist und diesen definierten Befehlen die Sensorsignale, die Aktoren, die Kontrollzeiten für den Übergang zwischen den befehlsgemäßen Zuständen und ein Referenzzustand für den Beginn zuzuordnen sind, gleichermaßen die Definition der Einbindung komplexerer Teilsysteme erfolgen kann, wobei der Anwender des Steuerungssystems nur die hier genannten primären Angaben macht und das Steuerungs-Entwicklungsprogramm daraus den System-Elementarfünktionsspeicher, den EF-Controler und den Signal- Vektor für den Zustandsüberwacher generiert und damit das technische System bereits inbetriebgenommen. auf fehlerfreie Signaldefinition im Referenzzustand überprüft, mit den definierten Elementarfunktionen gesteuert und soweit zulässig in Einzelbefehlen getestet und geprüft werden kann.
Für ein solches dialoggestütztes System werden die Nutzungsbefehle vorteilhaft derart erarbeitet, indem in einer Befehlsbibliothek prozessnah zu definierenden Nutzungsbefehlen aus den vorher definierten Elementarbefehlen solche einzeln, parallel oder als Folge zugeordnet werden, dazu die Sperrbedingungen auf Befehlsniveau im Befehlsrechner und für den an den Ausführungsrechner zu übergebenden Befehlssatz auch die in den Nichtsollbewerter einzutragenden Reaktionsbefehle auf ausgewählte Abweichungen, verbunden mit geeigneten Fehlermeldungen, festgelegt werden.

Für ein so aufgebautes Steuerungssystem bleiben Änderungen an Elementarfunktionen lokal begrenzt. Es können jederzeit und ebenfalls mit überschaubarer lokaler Wirkung neue Nutzungsbefehle, Sperrbedingungen oder Fehlerreaktionen erweitert oder geändert werden oder ohne jede Rückwirkung auf schon definierte Programme, dazu unterschieden durch die Vergabe von Statu-sinformationen für das System, eine neue Zuordnung von Befehlen und Befehlsbedingungen erfolgen.
Jedes so erstellte Programm ist in seiner logisch-fünktionellen Struktur vollständig prüfbar. Über das Ereignis-Zeit-Protokoll werden wichtige zusätzliche Prozessinformationen zugänglich, zu jeder Störung ist ohne zusätzliche Maßnahmen stets eine eindeutige Ursache diagnostiziert, der Systemzustand kann zu jeder Zeit vollständig und definiert ausgewiesen werden, eine gleichermaßen zum Zustand des zu steuernden Systems aussagefähige Kopie kann an einem zur Anlage ver- netzten externen Steuerungscomputer geführt werden, die Elementarfunktionen und die definierten Befehle können direkt als funktioneile Basis für eine Visualisierung der zu steuernden Systeme und Prozesse dienen und in einfacher Weise kann die Kommunikation des Steuerprogramms mit anderen intelligenten Programmmodulen, wie beispielsweise Simulationen zur Prozessoptimierung, organisiert werden.
Für Kleinsteuerungen mit einem begrenzten Befehlsumfang können bei grundsätzlich gleichem Aufbau und gleicher Arbeitsweise der Steuerung in einem Steuerungs-Hardwarebaustein die Module des Ausführungsrechners und des Befehlsrechners mit festen Befehlssätzen eingebracht werden, die mit einfachen Bedienelementen aufgerufen werden, wobei über eine geeignete Schnittstelle ein externer Computer angekoppelt werden kann, womit das Einbringen der Steuerungssoftware und im Bedarfsfall auch eine komfortable Kommunikation und Diagnose realisierbar sind und damit vergleichbare Steuerungseigenschaften und vergleichbarer Komfort bei geringen Kosten erreicht werden.
Die erfindungsgemäße Lösung vermeidet die Mängel nach dem Stand der Technik durch einen bisher unüblichen Programmieransatz, der von der gestalteten und damit eingeprägten Funktionalität des Systems Gebrauch macht. Eine Signalverknüpfung mit Boolscher Algebra in Bedingungsgleichungen für das Setzen von Ausgängen wird vollständig durch neue Mittel ersetzt.

Nachfolgend wird die Erfindung an Hand von Ausführungsbeispielen näher erläutert. In den Zeichnungen zeigen:
Fig. 1 eine Darstellung einer grundlegenden Gliederung der Aufgabenbereiche in der Struktur
der Steuerung
Fig. 2 eine hierarchisch gegliederte Funktionsstruktur eines technischen Systems
Fig. 3 für die Elementarfunktionen festzulegende Informationen an einem allgemeinen Beispiel

Fig. 4 eine einfache technische Anlage in schematischer Darstellung
Fig. 5 eine der Fig. 4 entsprechende Funktionsstruktur
Fig. 6 eine der Fig. 4 entsprechende Definition der Elementarbefehle
Fig. 7 eine Darstellung von Eingabe und Aufbau eines Datengerüsts zur Realisierung der Steuerung Fig. 8 einen Aufbau eines Ausführungsrechners
Fig. 9 einen Inhalt eines Befehls als Befehlssatz für den Befehlspuffer
Fig. 10 eine Darstellung der Arbeitsweise eines Befehlsstarters
Fig. 11 eine Darstellung der Arbeitsweise eines EF-Controlers
Fig. 12 eine Darstellung der Arbeitsweise eines Nichtsoll-Bewerters
Fig. 13 eine Darstellung der Arbeitsweise eines Zustandsüberwachers
Fig. 14 einen Aufbau eines Ereignis-Zeit-Protokolls
Fig. 15 ein Beispiel einer Bildungsgrundlage formaler Befehlsnamen
Fig. 16 ein Beispiel für das Definieren von Nutzungsbefehlen
Fig. 17 ein Beispiel eines in einer Steuerung geführten Sperrenverzeichnisses
Fig. 18 ein Beispiel zur Festlegung von Fehlerbefehlen
Fig. 19 ein Beispiel einer Steuerung mit komplexeren Aufgaben
Fig. 20 eine Struktur und Namensdefinition nach Fig. 19
Fig. 21 alle Angaben für eine Befehlsbibliothek eines Befehlsrechner nach Fig. 19 und 20

Fig. 22 Merkmale einer Ausführung als Kleinsteuerung

Fig. 1 zeigt die grundlegende Gliederung der Aufgabenbereiche in der Struktur 1 der neuen Steuerung. Dem Ausführungsrechner 2 sind die zeitkritischen Aufgaben Soll-Ist- Vergleich, Reaktionen auf Abweichungen des Ist- zum Soll-Zustand und der befehlsgemäße Aufruf von zustand-sändernden Aktoren zugeordnet. Vom Befehlsrechner 3 erhaltene Befehle werden vom Ausführungsrechner 2 ohne Prüfung umgesetzt, wobei die Ausführung eines Befehls und die Reaktion auf Abweichungen des Soll-Ist-Zustandes autark vom Ausführungsrechner 2 realisiert werden. Es ist zweckmäßig bzw. für kürzeste Reaktionszeiten der Steuerung bei komplexeren Systemen zwingend, dem Ausführungsrechner 2 eine eigene Hardware mit einem eigenen Prozessor zuzuordnen.
Im Befehlsrechner 3 werden alle Steuerungsoperationen auf logisch-funktionellem Niveau verwaltet. Hier werden aus geräteorientierten Elementarbefehlen prozessnahe Nutzungsbefehle als Einzelbefehle, als parallele oder serielle Befehlsfolgen definiert, abgelegt und aufgerufen. Hier erfolgt auch auf logischem Befehlsniveau die Verwaltung von Sperren für sich gegenseitig ausschließende Zustände als Alternative zu bisherigen Verriegelungen und Bedingungsformulierungen über Boolsche Signalverknüpfungen. Dem Anwendungsrechner 4 obüegen in diesem Steuerungskonzept alle Aufgaben, die nicht dem Ausführungs- oder dem Befehlsrechner zugeordnet sind. Das betrifft vor allem prozessnahe Probleme, wie sie beispielsweise im Bereich der Werkstückprogrammierung einer CNC-Steuerung vorliegen.
Die Steuerung kann dabei für unterschiedlichen Umfang und unterschiedliche Aufgabenkomplexität angemessen konfiguriert werden, wobei für alle Konfigurationen gleiche Prinzipien im Entwicklungssystem gelten. Bei sehr geringem Umfang an Befehlen kann der Anteil des Befehlsrechners 3 dem Ausführungsrechner 2 als Softwarebereich zugeordnet sein. Bei heute typischen SPS-Aufgaben kämen Ausführungs- und Befehlsrechner mit eigenen Prozessoren zur Anwendung, wobei die Systembedienung sowohl über Bedien- und Signalelemente bis zur Monitorausstattung erfolgen kann. In allen Ausführungen ist es darüber hinaus möglich, über eine einfach zu gestal-tende Schnittstelle ein komfortables Kommunikationssystem - beispielsweise einen transportablen Computer - anzukoppeln und damit Programmierung und Inbetriebnahme oder Diagnose im Fehlerfall auszuführen.
Fig. 2 zeigt beispielhaft die hierarchisch gegliederte Funktionsstruktur 5 eines technischen Systems. Es ist entwicklungsmethodisch begründet, dass eine solche Systemstruktur von der Funktionseinheit für das Gesamtsystem 6 über unterschiedliche Funktionseinheiten der Teilsysteme 7 bis zu den Funktionseinheiten Elementarfunktionen 8 spezifisch für jedes technische System aufgestellt werden kann. Die Endzweige dieser Baumstruktur stellen im Sinne der neuen Steuerung Elementarfunktionen dar, die dadurch charakterisiert sind, dass diese Funktionseinheiten unterschiedliche Zustände einnehmen können und sich nicht zweckmäßig weiter untergliedern lassen, deren steuerungsseitig interessierende Funktionszustände also nicht mehr eine Repräsentation kombinierter Zustände anderer elementarer und zu steuernder Funktionsgruppen sind, wie es für übergeordnete nicht elementare Funktionseinheiten 6 und 7 in der Struktur charakteristisch ist. Entscheidend ist dabei die Stellung im zu steuernden System, so dass auch ein durch wenige elementare Befehle eingebundenes intelligentes Teilsystem als Elementarfünktion eingeordnet wird.

Fig. 3 beschreibt an einem allgemeinen Beispiel die für Elementarfunktionen festzulegenden Informationen in einem „Datenblatt zu Elementarfunktionen" 9. In 10 wird der Name für die Ele-mentarfünktion festgelegt, der diese Elementarfünktion identifiziert. Zweckmäßigerweise zeigt eine Funktionsskizze 11 die Merkmale der Zustände der Elementarfunktion mit der Zuordnung von Aktoren 12 und Sensoren 13. In dem gekennzeichneten Bereich für die Zustandsdefinitionen 14 werden die für die Steuerung notwendigen Informationen datenverarbeitungsgerecht systematisiert und definiert. Die Zustandsdefinitionen 14 zeigen die Zustände, die die Elementarfünktion einnehmen kann und die Definition der den Zuständen zugeordneten Signalvektoren 15 für die Aktoren 12 und Sensoren 13. Gleichermaßen werden hier die Befehle 16 definiert, die einen Übergang in einen bestimmten Zustand auslösen. Für jeden dieser Übergänge wird eine Kontrollzeit 17 vorgegeben, die in der Regel ein mehrfaches der wahrscheinlichen Funktionszeit sein kann und nur für das Erkennen von Ausführungsfehlern bei Nichterreichen des befohlenen Zustandes verwendet wird. Mit der Markierung wird von den möglichen Zuständen einer als Referenzzustand 18 festgelegt.
Fig. 4 zeigt eine einfache technische Anlage, für die in Fig. 5 die Funktionsstruktur und in Fig. 6 die Definition der Elementarbefehle dargestellt sind.
Die hier beschriebene hierarchische Funktionsstruktur und die Definition der zugehörigen Elementarfunktionen sind vom Wesen her primäre Entwicklungsinhalte, die mit nur geringem zusätzlichem Aufwand und bereits in einer relativ frühen Phase bei der Produktentwicklung dokumentiert werden können.
Fig. 7 zeigt Eingabe und Aufbau des Datengerüsts bei der Anwendung der neuen Steuerung. Die Editierebene 19 beinhaltet die beiden Hauptbestandteile hierarchische Funktionsstruktur 5 und die Datenblätter der Elementarfunktionen 9. Jede Funktionseinheit Elementarfunktion 8 in der Struktur muss mit einem entsprechenden Datenblatt zu Elementarfunktionen 9 beschrieben sein. Diese Vollständigkeit der Angaben und deren formale Korrektheit wird in der Editierebene automatisch geprüft. Bei positivem Prüfergebnis und Bestätigung des Nutzers für den Abschluss der Systembeschreibung wird die Eingabe geschlossen und aus den vorliegenden Angaben die Datenbasis der Steuerung für das beschriebene System generiert. Als erster Schritt erfolgt das Generieren des Elementarfünktions-Speichers 20. Dieser Elementarfünktions-Speicher 21 enthält alle Elementarbefehle des Systems, alle Systemzustände und die dazu festgelegten Informationen, wie sie mit Fig. 3 beschrieben wurden. Die formalen Namen der Elementarfunktionen werden aus der Struktur abgeleitet, so dass Elementarfunktionen auch bei Verwendung eines gleichen Datenblattes einen unverwechselbaren Namen erhalten. Im zweiten Schritt erfolgt das Generieren des EF-Controlers 22. Dazu wird im EF-Controler 23 der Referenzzustand des Systems aus den festgelegten Referenzzuständen 18 aller Elementarfunktionen aufgebaut. Für den hier ebenfalls geführten Istzustand der Elementarfunktionen wird durch Doppeln der Datenstruktur des Soll-Zustandes der Elementarfunktionen 24 die Datenstruktur zum Speichern des Istzustandes der Elementarfunktionen 25 angelegt. Es wäre damit hier bereits möglich, beim Betreiben der Steuerung einen Vergleich zwischen dem Soll- und dem Ist-Zustand der Sensoren der Elementarfunktionen vorzunehmen. Größere Effektivität ermöglicht aber der mit 26 gekennzeichnete dritte Schritt zum Generieren des (ebenfalls später noch genauer beschriebenen) Zustandsüberwachers 27. Dabei werden aus den Soll-Signalvektoren der Elementarfunktionen 28 und gleichermaßen aus den Ist-Signalvektoren der Elementarfunktionen 29 der Sollsignalvektor des Systems 30 und der Istsignalvektor des Systems 31 gebildet. Jedem Sensor im System-Signalvektor bleibt seine Herkunftsadresse als Name der Elementarfünktion 10 im EF-Controler 23 zugeordnet.
Fig. 8 zeigt den Aufbau des Ausführungsrechners 2 und das Zusammenwirken mit dem Befehlsrechner 3. Der Ausführungsrechner 2 erhält vom Befehlsrechner 3 einen auszuführenden Nutzungsbefehl 32. Dieser wird in einem Baustein Befehlsaufbereiter 33 decodiert. Dabei werden Nutzungsbefehle in ihre entsprechenden Elementarbefehle überführt und diesen wird aus dem Elementarfunktions-Speicher 21 der vollständige zugeordnete Informationsinhalt des Befehlssatzes übergeben. Dieser Befehlssatz wird in dem Befehlspuffer 34 des Ausführungsrechners eingetragen. Nach Quittung, dass der vorhergehende Befehl abgeschlossen wurde, startet der Baustein Befehlsstarter 35 den im Befehlspuffer 34 wartenden Befehl und führt alle damit verbundenen Aktivitäten aus. Das betrifft das Aktualisieren im Baustein EF-Controler 36, im Baustein Zustandsüberwacher 37 und im Baustein Nichtsoll-Bewerter 38. Vom Baustein Befehlsstarter 35 wird im Baustein EF-Controler 36 für die betreffende Elementarfunktion der neue Sollzustand für die Sensoren eingetragen und durch das befehlsgemäße Setzen der Ausgänge der entsprechende Aktorbefehl gestartet. Ebenso wird die der Befehlsausführung zugeordnete Kontrollzeit 17 gestartet. Im Nichtsoll-Aktionsspeicher 39 werden die Bestandteile des Befehlssatzes „Nichtsoll-Befehle und -Meldungen" eingetragen.

Nach Ausführung der Start-Aktivitäten vom Befehlsstarter 35 übernimmt der Baustein Zustandsüberwacher 37 wieder den Vergleich des Soll-Signalvektors des Systems 30 mit dem Ist-Signalvektor des Systems 31. Bei einer in diesem Vergleich erkannten Abweichung zwischen Soll und Ist wird im EF-Controler 36 der Ist-Zustand des abweichenden Signals im Ist-Signalvektor der Elementarfunktion 29 aktualisiert. Im EF-Controler 36 erfolgt die Bewertung der Abweichung (in Fig. 11 näher beschrieben), entweder a) ohne weitere Reaktion durch den über das laufende Zeitglied erkannten Status „beim Ändern" und damit Rückgabe der Aktivitäten an den Baustein Zustandsüberwacher 37, b) über das Erkennen eines ausgeführten Befehls bei Übereinstimmung von Sollsignalvektor der Elementarfunktion 28 und Ist -Signalvektor der Elementarfunktion 29 im EF-Controler 36 und damit Aufruf des Bausteines Befehlstarter 35, oder - wenn beides nicht zutrifft - c) die Übergabe des Ist-Signalvektors der Elementarfunktion 29 an den Baustein Nichtsoll-Bewerter 38. Dort wird dieser Ist-Signalvektor 29 mit den im Nichtsoll-Aktionsspeicher 39 stehenden Signal vektoren verglichen und bei Übereinstimmung der diesem Fall zugeordnete Nichtsoll-Befehl 40 über den Baustein Befehlsstarter 35 gestartet. Gibt es keine Übereinstimmung, erfolgt eine Rückkehr zum Zustandsüberwacher 37. In allen Fällen wird eine entsprechende Meldung 41 erzeugt. Der mit 42 gekennzeichnete Bereich markiert die zeitkritischen Aktivitäten.

Fig. 9 zeigt den Inhalt eines Befehls 43, wie er als Befehlssatz in den Befehlspuffer 34 des Ausführungsrechners 2 eingetragen wird. Zeile (1) enthält die Bezeichnung der zur Änderung angewiesenen Elementarfunktion 10, Zeile (2) und Zeile (3) beinhalten den neuen Sollzustand der Sensoren bzw. der Aktoren und damit den Soll-Signalvektor der Elementarfünktion 28, Zeile (4) gibt die Kontrollzeit 17 vor, in der die Änderung des Zustandes auf die neue Vorgabe erfolgt sein muss, Zeile (5) beinhaltet die Angaben zur Aktualisierung der ab Start des Befehls geltenden Einträge im Nichtsoll-Aktionsspeicher 39 für Reaktionen mit Nichtsoll-Befehlen 40, und Zeile (6) beinhaltet gleiches für die Aktualisierung nach erfolgreicher Befehlsausführung. Die Angaben der Zeilen (1) bis (4) entsprechen dabei direkt den Definitionen aus der Editierebene 19 zu den Elementarfunktionen 8. Die Zeilen (5) und (6) können darüber hinaus Nichtsoll-Befehle 40 aus Festlegungen zu prozessbezogenen Vorgaben über die Nutzungsbefehle 32 beinhalten.
Fig. 10 beschreibt die Arbeitsweise des Bausteins Befehlsstarter 35 und die Behandlung von Folgebefehlen 44 sowie von Parallelbefehlen 45. Der Befehlspuffer 34 wird vom Befehlsrechner 3 immer mit dem der laufenden Befehlsausführung folgenden Befehl geladen. Definierte Befehlsfol- gen (=Folgebefehle 44) unterscheiden sich dabei nicht von einzeln definierten, voneinander unabhängigen Befehlen.
Parallelbefehle 45 sind dadurch charakterisiert, dass sie fünktionell wie zeitlich voneinander unabhängig ausgefiihrt werden können und für einen zeitlich optimalen Ablauf auch parallel ausgeführt werden müssen. Für jeden als parallel definierten Befehl wird deshalb ein eigener Befehlspuffer 46 an der Schnittstelle zwischen Befehlsrechner 3 und Ausführungsrechner 2 definiert, aus dem voneinander unabhängige parallele Befehlsfolgen 45 abgearbeitet werden können. Stehen nach Abarbeitung von Parallelbefehlen 45 keine solchen mehr an, werden die eröffneten Speicherbereiche wieder geschlossen, so dass nur aktuell benötigte Pufferspeicher 46 geführt werden. Fig. 10 zeigt ein Beispiel für drei eröffnete Parallelbefehle 45, aus denen nacheinander die eingetragenen Befehle 43 gestartet werden. Sollte die Prüfung 47 zeigen, dass kein weiterer Befehl im Speicherpuffer ansteht, wird der entsprechende Parallel-Befehlspuffer 46 geschlossen und der Baustein Zustandsüberwacher 37 aufgerufen. Bei positivem Prüfergebnis 48 wird entsprechend Befehlsinhalt 43 aktualisiert und gestartet. Nach Abschluss dieser Operationen wird der Baustein EF-Controler 36 aktiviert 49. Nach dem Erreichen des befehlsgemäßen Zustandes 50 werden vom Befehlsstarter 35 die dafür im Befehlssatz 43 festgelegten Aktualisierungen ausgeführt und danach der nächste Befehl ermittelt und gestartet.
Fig. 11 zeigt die Arbeitsweise des Bausteins EF-Controler 36. Der Start 51 für eine Aktivität des EF-Controlers wird stets von einer aktuellen Änderung angestoßen. Das ist entweder ein neuer Sollsignalvektor einer Elementarfünktion 28, den der Baustein Befehlsstarter 35 bei einem neuen Befehl einträgt 52, oder eine vom Baustein Zustandsüberwacher vorgenommene Aktualisierung 53 des vorliegenden Ist-Zustandes 29. Die erste Prüfung 54 vergleicht den Soll- mit dem Ist-Zustand. Bei Übereinstimmung wird geprüft, ob der Änderungsstatus 55 gesetzt war. Ist das der Fall 56, wurde ein laufender Befehl abgeschlossen, andernfalls 57 wurde der befohlene Zustand nach einer fehlerhaften Abweichung wieder erreicht. In beiden Fällen wird eine entsprechende Meldung erzeugt und der Baustein Befehlsstarter 35 gestartet 58 - Stimmen Ist- und Sollzustand nicht überein, wird der Zweig 59 abgearbeitet. Wieder wird der Änderungsstatus geprüft 60. Liegt der Änderungsstatus bei dieser Elementarfunktion vor 61, wird die Meldung „EF beim Ändern" 62 erzeugt und der Baustein Zustandsüberwacher 37 gestartet. Liegt jedoch kein Änderungsstatus vor 63, werden der Name und der vorliegende Nichtsoll-Istsignalvektor 64 der Elementarfünkti- on in den Auswertungsspeicher des Nichtsoll-Bewerters 65 eingetragen und der Nichtsoll-Bewerter 38 wird gestartet.
Fig. 12 zeigt die Arbeitsweise des Nichtsoll-Bewerters 38. Der Start 66 des Nichtsoll-Bewerters wird durch den EF-Controler 36 nach Übergabe eines Nichtsoll-Signalvektors 64 ausgelöst. Im ersten Schritt wird geprüft, ob unter dem Namen der Elementarfünktion 10 Eintragungen im Nichtsoll-Aktionsspeicher 39 vorhanden sind. (Wie schon bei Fig. 10 beschrieben, werden diese Einträge vom Befehlsstarter 35 als Informationsbestandteile eines Befehls 43 aktualisiert.) Sind für die Elementarfunktion keine Festlegungen im Nichtsoll-Aktionsspeicher 39 enthalten 67, wird nur eine Fehlermeldung 67a mit der Bezeichnung der Elementarfünktion und dem Nichtsoll-Istsignalvektor 64 mit Kennzeichnung des fehlerhaften Signals an die übergeordnete Steuerungsebene - dem Befehlsrechner 3 - zur Auswertung übergeben. Dann wird der Baustein Zustandsüberwacher 37 wieder gestartet.
Liegt im Nichtsoll-Aktionsspeicher 39 ein NichtsoU-Signalvektor zu der Elementarfünktion vor 68, wird als nächster Schritt der Nichtsoll-Istsignalvektor 64 auf Übereinstimmung mit dem gespeicherten Signalvektor verglichen 69. Liegt keine Übereinstimmung vor 70, wird wieder nur eine konkrete Fehlermeldung 67 erzeugt und ebenso der Zustandsüberwacher 37 wieder gestartet. - Liegt jedoch eine Übereinstimmung des Signalvektors mit Eintragungen im Aktionsspeicher vor 71, werden für diesen Fall festgelegten Reaktionsbefehle 72 dem Befehlsstarter 35 zur sofortigen Ausführung übergeben. Parallel dazu wird für die zu erzeugenden Meldung geprüft 73, ob eine Ereignissteuerung 74 vorliegt. Bei einer Ereignissteuerung 74 bewegt sich das System in dem normalen fünktionellen Rahmen, ein erkanntes Ereignis ruft eine entsprechende Aktion auf (beispielsweise das Abschalten einer Pumpe bei Erreichen des oberen Füllstandes). In diesem Fall weist die entsprechende Meldung 75 den Ereignisbefehl der Elementarfunktion 76 in deutlicher Unterscheidung zu Fehlerzuständen aus. Handelt es sich nicht um eine Ereignissteuerung 77, wird eine entsprechende Fehlermeldung 78 erzeugt.
Fig. 13 zeigt Arbeitsweise und Merkmale des Bausteins Zustandsüberwacher 37. Wenn keine anderen Baustein- Aktivitäten laufen, startet der Zustandsüberwacher ständig den Vergleich 80 des Sollsignalvektors 30 und des Istsignalvektors 31 des Systems. Dieser Vergleich erfasst immer den gesamten System-Signalvektor und wird bei Übereinstimmung der verglichenen Zustände ständig wiederholt 81. Bei einer erkannten Abweichung wird zunächst geprüft, ob das System den Warte- zustand verlassen und einen neuen Befehl ausführen soll. Ist das der Fall 82, wird der Baustein Befehlsstarter 35 gestartet. Im anderen Fall wird das abweichende Ist-Signal in den Ist-Signalvektor der betreffenden Elementarfünktion im EF-Controler eingetragen 83 und dort - wie zu Fig. 11 erläutert - ausgewertet. Entstehen kann eine Abweichung entweder durch Vorgabe eines neuen Sollzustandes bei Start eines neuen Befehls und erfolgtem Eintrag in den Sollsignalvektor 30 des Systems durch den EF-Controler 36, oder im anderen Fall durch ein geändertes Sensorsignal im Istsignalvektor 31 des Systems. Nach dem Eintrag des abweichenden Ist-Signals in der betroffenen Elementarfünktion im EF-Controler wird dieser gemeldete Ist-Zustand als neuer Vergleichszustand in dem Soll- Vergleichsvektor eingetragen 84. Damit wird erreicht, dass jede Veränderung nur einmal ausgewertet wird. Der Soll- Vergleichszustand des System-Signalvektors ist damit als Vergleich mit „dem letzten ausgewerteten Zustand" des Systems 84 definiert. Damit ist es möglich und sinnvoll, das erkannte Ereignis in ein Ereignis-Zeit-Protokoll einzutragen 85, auf das in Fig. 14 näher eingegangen wird. Nach den genannten Aktionen des Zustandsüberwa-chers 37 startet dieser den Baustein EF-Controler 36. Nach erfolgter Auswertung wird wieder -wie bei der Arbeitsweise von EF-Controler bzw. Befehlsstarter beschrieben - der Baustein Zustandsüberwacher aufgerufen. Dieser setzt dann den Soll-Ist- Vergleich im Systemsignalvektor bei dem Signal fort, das dem zuletzt nicht übereinstimmenden Signal folgt. Damit wird gesichert, dass nacheinander alle Signale des Systemsignalvektors verglichen werden und nicht ein schwingendes Signal eine Endlosschleife verursachen kann. Ein solches Phänomen wäre bei Wiederaufnahme des Vergleiches bei dem gerade ausgewerteten Signal denkbar, wenn dieses Signal seinen Zustand im Takt der Signallaufzeit ändern würde.
Fig. 14 soll den Aufbau eines Ereignis-Zeit-Protokolls 85 in Form einer Liste verdeutlichen. Die erste Spalte nimmt die Bezeichnung der vom Ereignis betroffenen Elementarfünktion auf, die Spalte 2 das von der Änderung betroffenen Signal, die Spalte 3 den geänderten Signalzustand. Das sind Kopien der Informationen, die der Zustandsüberwacher dem EF-Controler übergibt. Wird in Spalte 4 die aktuelle Systemzeit beim Erkennen des Ereignisses eingetragen, entsteht ein in vielfacher Hinsicht nutzbares Ablaufprotokoll. Im Beispiel ist mit dem ersten und dem letzten Eintrag markiert, dass die Elementarfünktion Al l mit dem Signal El wieder den ersten Zustand erreicht hat. Die den Ereignissen zugeordneten Zeiten könnten gegebenenfalls als genaues Maß für eine solche Periode dienen. Mit diesem Protokoll ist es auch möglich, Signalschwingungen zu erkennen und im Bedarfsfall Filter zu aktivieren, die beispielsweise die Abtasthäufigkeit für das schwingende Signal verringern können. Je nach Prozess und Bedeutung der Informationen sowie zur Verfügung stehendem Speicher können längere Zeiten erfasst und gespeichert werden, was für Diagnosezwecke hinsichtlich Langzeitveränderungen genutzt werden kann, oder nur mit fest begrenztem Speicher der jeweils letzte Abschnitt beispielsweise für eine Havarieauswertung zur Verfügung stehen.
Fig. 15 zeigt für das in Fig. 4 bis 6 ausgeführte Beispiel die Bildungsgrundlage der formalen Befehlsnamen 86, die aus der Funktionsstruktur 5 abgeleitet werden und für eine eindeutige Bezeichnung der Elementarfunktionen in Nutzungsbefehlen verwendet werden können.
In Fig. 16. ist an dem Anwendungsbeispiel von Fig. 4 - 6 das Definieren von Nutzungsbefehlen und das Festlegen von Befehlssperren 88 zu den Nutzungsbefehlen dargestellt.
Fig. 17 zeigt als Beispiel das in der Steuerung geführte Sperrenverzeichnis 89 des Systems Schließanlage und soll das dynamische Wirken der in Fig. 16 festgelegten Sperrbedingungen deutlich machen. Bei der Fig. 17 muss betont werden, dass es eine Hilfs-Darstellung ist und eine solche Tabelle in der Steuerung nicht existiert. Vorhanden ist immer nur ein Speicherbereich, in den zu unterschiedlichen Zeiten (hier mit tl bis t8 ausgewiesen) durch die bis dahin wirkenden Befehle unterschiedliche Bedingungen eingetragen sind.
In der Spalte 1 sind alle Befehle des Systems aufgelistet. Enthält ein aktivierter Nutzungsbefehl eine Sperrbedingung für einen anderen Befehl, wird der verursachende Befehl als Sperrbedingung bei dem anderen Befehl eingetragen. Hier im Beispiel sperrt mit seiner Aktivierung zur Zeit t7 der Befehl EF2-B2 (verriegeln) den Befehl EF1-B1 (Türbeweger öffnen). Der Riegel soll - wie festgelegt - nur bei geschlossener Tür eingelegt werden können, deshalb der Eintrag der Sperre bei EF2-B2 mit Erteilen des Befehls „(Tür öffnen) EF1-B1" zur Zeit t3.
Für die Wirkungsweise der Steuerung ist wichtig, dass der Befehlsrechner 3 nach Übergabe eines Nutzungsbefehls 32 in den Befehlspuffer 34 des Ausführungsrechner 2 - den dieser dann wie beschrieben autark ausführen kann - seinen Zustand so aktualisiert, wie er nach ordnungsgemäßer Ausführung dieses Befehls eintreten wird. Für diesen Zustand wird die Zulässigkeit des nächsten Befehls noch während der Ausführung des vorhergehenden Befehls geprüft und ggf. freigegeben. Im Beispiel befindet sich während der Ausführung „Riegelschloss entriegeln" zu tl im Befehlspuffer, der Befehl „Tür öffnen", der zum Zeitpunkt t3 gestartet werden wird und dann gleichzeitig die Prüfung des Befehls „Tür schließen" für den Zeitpunkt t5 nach den Bedingungen vom Zeitpunkt t4 aktiviert.
Damit wird zeitoptimal erreicht, dass mit dem Abschluss eines Befehls sofort der schon geprüfte Folgebefehl starten kann oder gleichermaßen noch während der Laufzeit eines Befehls erkannt wird, dass der nächste vorbereitete Befehl für den kommenden Systemzustand nicht zulässig ist. Wenn ein Fehler bei dem im Ausführungsrechner laufenden Befehl auftritt, wird der Befehlsrechner auf den Fehlerzustand aktualisiert zurückgesetzt.
Fig. 18 (auf Blatt 12) soll ein Beispiel zur Festlegung von Fehlerbefehlen zeigen. Es sei als kritisch angenommen, wenn die Tür beim Schließen - aus welchen Gründen auch immer - auf einen eingelegten Riegel trifft. Fig. 18 zeigt die Formulierung eines Fehlerbefehls als Bestandteil des Befehlssatzes „Türbeweger schließen". Aus dem Zustand der Elementarfünktion Riegelschloss El=l wird „Riegel nicht frei" geschlussfolgert und als Fehlerreaktion im Nichtsollbewerter der Vorgang „Tür schließen" „in Tür öffnen" umgesteuert.
Analysen zeigen, dass in der Regel zu einem bestimmten Zeitpunkt nur wenige Fehlerbefehle benötigt werden. Grundsätzlich ist es möglich, auf ein beliebiges Ereignis mit jedem Befehl zu reagieren.
Fig. 19 soll als weiteres Beispiel die Möglichkeiten der Steuerung bei komplexeren Aufgaben und unterschiedlichen Nutzungsanforderungen einer -Anlage zeigen. Für solche unterschiedlichen Nutzungsanforderungen und daraus resultierende unterschiedliche Befehls- und Sperrbedingungen in einer Anlage soll der Begriff „Status" 90 verwendet werden.
Es sei angenommen, dass zwei Türanlagen gesteuert werden sollen, die einzeln dem bisherigen Beispiel gleich sind. Hinzu kommt ein Anlagenschalter für den jeweils gewünschten Betriebsstatus: im Status Sl können die Türen unabhängig voneinander bedient werden, in S2 werden beide synchron geöffnet oder geschlossen und in S3 als Schleuse bleibt immer eine von beiden Türen geschlossen.
Figur 20 zeigt die Struktur und Namensdefinitionen, wie sie die Steuerung hier nach den in der Editierebene 19 gemachten Angaben aufbaut.
Figur 21 zeigt alle Angaben für die Befehlsbibliothek 92 des Befehlsrechners, um die gestellte Aufgabe zu lösen. Die für die Schließanlage einer Tür erarbeiteten Festlegungen werden für die unmittelbare Türsteuerung eines Exemplars beim Generieren unter dem neuen Systemnamen gedoppelt. Alle Festlegungen zum Steuerungs-Status beider Türen werden über neu definierte Statusbefehlsblätter 91 realisiert, die über den Statusschalter ausgewählt werden. Bei dem Status S3-* Befehlsblatt wurde für die Sperrenformulierung nicht eine Elementarfünktion sondern mit „Tür x" eine höhere Hierarchieebene in der Funktionsstruktur benutzt. Damit können sehr effektiv ganze Funktionsbereiche gegen Zustandsveränderungen gesperrt oder auch mit Formulierungen „alle außer XXX" sehr effektiv selektiert werden.
Figur 22 zeigt Merkmale einer Kleinsteuerung 94 bei einem technischen Gerät 95. Der relativ kleine und feste Befehlsumfang der Kleinsteuerung 95 ist in einem Steuerungs-Hardwarebaustein angeordnet, der die Funktionalität des Ausführungsrechners 2 und des Befehlsrechners 3 beinhaltet. Die Bedienung erfolgt mit üblichen Schalt- und Anzeigegeräten 96. Über eine Schnittstelle 97 kann ein Computer 98 angekoppelt werden, womit alle Funktionalität der Steuerung zum Einbringen der Steuerungssoftware und komfortable Kommunikation und Diagnose möglich sind.

Bezugszeichenliste
1 Struktur der Steuerung ASS
2 Ausführungsrechner
3 Befehlsrechner
4 Anwendungsrechner
5 Funktionsstruktur
6 Funktionseinheit Gesamtsystem
7 Funktionseinheit Teilsystem
8 Funktionseinheit Elementarfünktion
9 Datenblatt zu Elementarfunktionen
10 Name der Elementarfünktion
11 Funktionsskizze
12 Aktoren
13 Sensoren
14 Zustandsdefinitionen
15 Signalvektoren
16 Elementarbefehle
17 Kontrollzeit
18 Referenzzustand
19 Editierebene
20 Generieren des Elementarfünktions-Speichers

21 Elementarfünktions-Speicher
22 Generieren des EF-Controlers
23 EF-Controler
24 Soll-Zustand der Elementarfunktionen Ist-Zustand der Elementarfunktionen
Generieren des Zustandsüberwachers
Zustandsüberwacher
Soll-Signalvektor der Elementarfünktion
Ist-Signalvektor der Elementarfunktion
Sollsignal vektor des Systems
Istsignalvektor des Systems
Nutzungsbefehl
Befehlsaufbereiter
Befehlspuffer
B austein B efehlsstarter
Baustein EF-Controler
Baustein Zustandsüberwacher
Baustein Nichtsollbewerter
Nichtsoll-Aktionsspeicher
Nichtsoll-Befehl
Zustandsmeldung
Zeitkritischer Funktionsbereich
Inhalt eines Befehls
Folgebefehle
Parallelbefehle
Befehlspuffer für Parallelbefehle
Prüfungsergebnis Befehlspuffer "nein"
Prüfungsergebnis Befehlspuffer "ja"
Aktivierung EF-Controler
Aktivitäten Befehlsstarter bei Erreichen "befehlsgemäßer Zustand" Aktivitätsstart EF-Controler
Änderung Sollzustand im EF-Controler durch Befehl
Änderung Istzustand im EF-Controler durch Sensormeldung
Vergleich Soll- und Ist-Zustand im EF-Controler
Änderungsstatus im EF-Controler
Alternative " Änderungsstatus"
Alternative "Kein Änderungsstatus"
Aufruf Befehlsstarter vom EF-Controler
Alternativen bei Nichtübereinstimmung Soll- und Istzustand im EF-Controler
Prüfung Änderungszustand bei Nichtübereinstimmung Soll- und Istzustand im EF-Controler
Aktivität bei Änderungszustand und Nichtübereinstimmung Soll- und Istzustand im EF-Controler
Meldung vom EF-Controler "Elementarfunktion (Name der Elementarfunktion) beim Ändern"
Alternative im EF-Controler bei Ist-Zustand ungleich Sollzustand und keinem Änderungszustand
Nichtsoll-Istsignalvektor
Auswertungsspeicher Nichtsoll-Bewerter
Start Nichtsollbewerter
Aktion, wenn Nichtsoll-Elementarfunktion keinen Eintrag im Nichtsoll-Aktionsspeicher hat
Fehlermeldung zu Nichtsoll-Elementarfünktion
Aktion, wenn Nichtsoll-Elementarfünktion einen Eintrag im Nichtsoll-Aktionsspeicher hat
Vergleich Nichtsoll-Istsignalvektor mit gespeichertem NichtsoU-Signalvektor im Nichtsollbewerter
Aktion bei fehlender Übereinstimmung Nichtsoll-Istsignalvektor mit NichtsoU-Signalvektor im Nichtsoll-Bewerter 71 Aktion bei Übereinstimmung NichtsoU-Istsignalyektor mit NichtsoU-Signalvektor im
Nichtsoll-Bewerter
72 Reaktionsbefehle im Nichtsoll-Aktionsspeicher
73 Prüfung, ob Nichtsoll-Istsignalvektor zu einer Ereignissteuerung gehört
74 Ereignissteuerung
75 Meldung Ereignissteuerung
76 Inhalt der Meldung Ereignissteuerung
77 Fehlermeldung, wenn keine Ereignissteuerung
78 Inhalt der Fehlermeldung
79 Start des Bausteins Zustandsüberwacher
80 Vergleich SoUsignalvektor des Systems mit dem Istsignalvektor des Systems
81 Programmschleife zum Vergleich SoUsignalvektor des Systems mit dem Istsignalvektor des Systems
82 Übergabe der Aktivität vom Zustandsüberwacher an Befehlsstarter
83 Eintrag geändertes Ist- Sensorsignal vom Zustandsüberwacher im EF-Controler

84 Vergleichs- Sollvektor "letzter ausgewerteter Zustand" im Zustandsüberwacher

85 Ereignis-Zeit-Protokoll
86 formale Befehlsnamen
87 Befehlssperren
88 Sperrenverzeichnis im Befehlsrechner
89 Sperrenverzeichnis des Beispiels Schließanlage
90 Status einer Anlage
91 Status-Befehlsblätter
92 Befehlsbibliothek
93 Nutzungsprogramme
94 Kleinsteuerung
95 Technisches Gerät mit Kleinsteuerung 96 Schalt- und Anzeigegeräte
97 Schnittstelle für Computeranschluss

98 Transportabler Computer