DE102016107527A1

DE102016107527A1 - Echtzeitumgebung und speicherprogrammierbare Steuerung

Info

Publication number: DE102016107527A1
Application number: DE102016107527.2A
Authority: DE
Inventors: Marko Tscherepanow; Dirk Janssen; Andre Folkers
Original assignee: Beckhoff Automation GmbH and Co KG
Current assignee: Beckhoff Automation GmbH and Co KG
Priority date: 2016-04-22
Filing date: 2016-04-22
Publication date: 2017-10-26
Also published as: CN109074279B; CN109074279A; US20190033814A1; US10782667B2; WO2017182467A1; EP3446216A1

Abstract

In einer Echtzeitumgebung wird wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt, wobei wenigstens eine Funktion innerhalb der vorgegebenen Task-Laufzeit abgearbeitet werden soll. Die Abarbeitung der Funktion erfolgt, indem eine Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Funktion innerhalb der vorgegebenen Task-Laufzeit festlegt, gestartet und dann die Funktion ausgeführt wird. Die Zeitüberwachungsfunktion überwacht die Funktionslaufzeit, wobei bei Überschreiten des vorgegebenen Abbruchszeitpunktes ein Funktionsabbruch veranlasst wird. Anschließend wird die Zeitüberwachungsfunktion beendet.

Description

Die Erfindung betrifft eine Echtzeitumgebung und eine speicherprogrammierbare Steuerung.
Die Steuerung von Aktoren und Sensoren einer Produktionsanlage erfolgt in der Regel mit Hilfe einer speicherprogrammierbare Steuerung (SPS), welche sowohl als externes Gerät als auch als Software-SPS vorliegen kann. Die SPS steuert über eine geeignete Kommunikationsschnittstelle, wie beispielsweise einen Feldbus, die jeweiligen Aktoren und Sensoren an.
Die Steuerung von Aktoren und Sensoren erfolgt auf der SPS in Form von Aufgaben, sogenannten Tasks. Die Tasks werden dabei häufig zyklisch ausgeführt. Zur schnelleren Verarbeitung kann eine SPS die Tasks auch auf mehrere Kerne eines Prozessors oder mehrere Prozessoren verteilen. Eine zentrale Aufgabe der SPS bei der Steuerung der Aktoren und Sensoren ist die Synchronisation mit dem Produktionsprozess.
Um eine Echtzeitsteuerung zu realisieren, muss sichergestellt werden, dass die auszuführende Task innerhalb einer vorgegebenen Maximalzeit, beispielsweise innerhalb der für einen Zyklus zur Verfügung stehenden Zeit, abgearbeitet wird. Weiterhin muss die zyklische Ausführung der Task ohne zeitliche Schwankungen (Jitter) mit einer vorhersehbaren Antwortzeit (Latenzzeit) durchgeführt werden.
Aus der EP 2 568 346 B1 ist bekannt, eine Task abzubrechen, wenn die Ausführungszeit der Task länger als eine vorher definierte maximale Ausführungszeit ist. Wenn die Task wegen Zeitüberschreitung nicht ausgeführt wurde, werden die Eingangsvariablen als Ausgangsvariablen der Task ausgegeben.
In der DE 102 43 856 B4 wird ferner einen Regler mit Funktionsblöcken beschrieben, wobei die Funktionsblöcke eine Echtzeitfunktion enthalten können. Die Echtzeitfunktion wird abgebrochen, wenn die benötigte Rechenzeit eine vorgegebene Referenzzeit überschreitet.
Die DE 10 2009 055 752 A1 offenbart weiter ein Verfahren, bei dem eine Task zugunsten einer anderen Task unterbrochen werden kann.
Neben den Aktoren und Sensoren, deren Steuerung mit Hilfe der SPS erfolgt, sind bei einer Produktionsanlage in der Regel noch eine Vielzahl weiterer Systeme vorhanden, deren Funktionen mit dem Produktionsprozess und dessen Steuerung durch die SPS synchronisiert werden müssen.
So sind beispielsweise Vision-Systeme ein wesentlicher Bestandteil zeitgemäßer Produktionsanlagen. Sie dienen zur Objekterkennung, Oberflächeninspektion, Vermessung oder Identifikation. Bei Vision-Systemen müssen eine Vielzahl von Bildverarbeitungs- und Bildanalyse-Operationen ausgeführt werden, die vorzugsweise synchron mit dem Produktionsprozess durchgeführt werden sollen.
Eine weitere mit dem Produktionsprozess zu synchronisierende Zusatzfunktion ist die Zustandsüberwachung (Condition Monitoring), bei der eine regelmäßige oder permanente Erfassung und Bewertung des Zustandes der Produktionsanlage durch Messung und Analyse von Maschinenparametern, die den aktuellen Zustand des Produktionsprozesses widerspiegeln, durchgeführt wird. Auch im Bereich des maschinellen Lernens ist eine Synchronisation von Zusatzfunktionen mit dem Produktionsprozess wünschenswert. Gleiches gilt für die numerische Steuerung, bei der ein Programmcode in Arbeits- bzw. Bewegungsabläufe für eine Maschine umgesetzt wird.
Vision-Systeme wie auch die anderen genannten Zusatzsysteme Zustandsüberwachung, maschinelles Lernen und numerische Steuerung liegen in der Regel in Form eigenständiger, von der SPS getrennter Softwarekomponenten vor. Bei Vision-Systemen werden üblicherweise separate Bildverarbeitungsrechner oder intelligente Kameras eingesetzt, die mit der SPS über ein Kommunikationsmedium beispielsweise über Ethernet, I/Os oder einen Feldbus verbunden sind, um die Berechnungsergebnisse an die SPS zu übermitteln.
Wenn die Vision-Funktion auf einem Bildverarbeitungsrechner läuft, übermitteln die angeschlossenen Kameras die Bilder oder Bildregionen an den Bildverarbeitungsrechner, der dann die problemspezifische Bildanalyse durchführt. Die Vision-Funktion kann aber auch direkt auf der Kamera ausgeführt werden. Die Kameras können ferner eigene I/Os besitzen, um nach entsprechender Konfiguration direkt mit den Aktoren und Sensoren der Produktionsanlage zu kommunizieren. Es besteht dann für die Aktoren und Sensoren der Produktionsanlage die Möglichkeit, über Hardware-Trigger die Bilderfassung durch die Kameras auszulösen oder die Beleuchtung anzusteuern.
Bei der Verwendung einer Software-SPS können für die Steuerung und die Bildverarbeitung dieselbe Hardware genutzt werden. Beim Einsatz einer intelligenten Kamera kann zusätzlich zur Vision-Funktion auch noch die Software-SPS auf der Kamera laufen, was jedoch die in der Regel begrenzte Rechenkapazität der intelligenten Kamera zusätzlich einschränkt. Dieser Ansatz ist folglich nur für einfache Steuerungs- und Vision-Aufgaben durchführbar.
Zur Übermittlung der Berechnungsergebnisse der Bildanalyse von der Vision-Komponente an die SPS wird üblicherweise eine Datenübertragung zwischen einer normalen Nutzerumgebung, in der die Software der Vision-Komponente läuft, und der Echtzeitumgebung der SPS durchgeführt. Es sind dann aber aufwändige Kommunikations- und Synchronisationsschritte bei der Datenübertragung erforderlich. Ferner erfolgen die für die Bildanalyse erforderlichen Berechnungen außerhalb der Echtzeitumgebung der SPS und damit auch asynchron zum Produktionsprozess.
In der EP 1 312 990 A2 ist ein Datenverarbeitungsverfahren beschrieben, mit dem auf den Bewegungsablauf einer Maschine bezogene Bild- und Audiodaten mit den Daten der Bewegungsund Antriebssteuerung der Maschine verknüpft werden können. Hierzu werden die Bild- und Audiodaten mit einem von der Bewegungs- und Antriebssteuerung generierten Zeitstempels versehen. Die auf die Daten der Bewegungs- und Antriebssteuerung der Maschine zeitsynchronisierten Bild- und Audiodaten können dann weiterverarbeitet oder angezeigt werden.
Ein wesentliches Problem bei der Synchronisation von Zusatzfunktionen, wie der der Vision-Systeme, mit dem Produktionsprozess besteht darin, dass ihre Laufzeit stark durch die Eingabedaten beeinflusst wird. Grund hierfür können bei der Bildanalyse durch die Vision-Systeme beispielsweise die Weiterverarbeitung nach der Erkennung relevanter Strukturen, die iterative Anwendung eines Algorithmus in Abhängigkeit eines Konvergenzkriteriums, alternative Suchstrategien oder sogenannte Regions-of-Interest im Bild mit variabler Größe sein. Die Berechnungsergebnisse liegen dann zu variablen Zeitpunkten vor. Dies widerspricht jedoch der Anforderung an die SPS, eine zyklische Ausführung der Task ohne zeitliche Schwankungen (Jitter) mit einer vorhersehbaren Antwortzeit (Latenzzeit) zu gewährleisten, wodurch eine einfache Integration der Vision-Funktion in die Echtzeitumgebung der SPS verhindert wird.
Gleiches gilt auch bei den anderen genannten Zusatzfunktionen. Bei der Zustandsüberwachung werden oft mit Hilfe iterativer Verfahren, deren Laufzeit vom Erreichen eines Gütekriteriums abhängig ist, Zeitreihen analysiert. Auch beim maschinellen Lernen hängt die benötigte Rechenzeit beispielsweise für das Training und die Anwendung von Klassifikatoren oder Funktionsapproximatoren wesentlich von den Eingabedaten ab. In der numerischen Steuerung werden komplexe iterative Optimierungsalgorithmen eingesetzt, deren Laufzeit variiert.
Aufgabe der vorliegenden Erfindung ist es, ein Echtzeitumgebung und eine speicherprogrammierbare Steuerung bereitzustellen, die eine Integration von Zusatzfunktionen mit unbestimmter Funktionslaufzeit in die Echtzeitumgebung ermöglichen.
Diese Aufgabe wird mit einem Echtzeitsystem gemäß Anspruch 1 und mit einer speicherprogrammierbaren Steuerung gemäß Anspruch 10 gelöst. Bevorzugte Weiterbildungen sind in den abhängigen Ansprüchen angegeben.
Erfindungsgemäß wird in der Echtzeitumgebung wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt, wobei wenigstens eine Funktion innerhalb der vorgegebenen Task-Laufzeit abgearbeitet werden soll. Die Abarbeitung der Funktion erfolgt, indem eine Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Funktion innerhalb der vorgegebenen Task-Laufzeit festlegt, gestartet und dann die Funktion ausgeführt wird. Die Zeitüberwachungsfunktion überwacht die Funktionslaufzeit, wobei bei Überschreiten des vorgegebenen Abbruchszeitpunktes ein Funktionsabbruch veranlasst wird. Anschließend wird die Zeitüberwachungsfunktion beendet.
Durch Vorsehen der Zeitüberwachungsfunktion ist die Ausführung der Zusatzfunktion so ausgestaltet, dass die Funktionslaufzeit in Abhängigkeit der im aktuellen Zyklus der Task noch verfügbaren Rechenzeit gesteuert werden kann. Die Zusatzfunktion kann deshalb direkt in der Echtzeitumgebung der SPS ausgeführt werden. Eine Datenverarbeitung der Zusatzfunktion außerhalb der Echtzeitumgebung und die damit einhergehenden Kommunikations- und Synchronisationsschritte entfallen. Weiterhin wird eine zeitgenaue Kopplung von Zusatzfunktion an das Timing des Produktionsprozesses erreicht.
In der Echtzeitumgebung ist ferner eine Abbruchsfunktion vorgesehen, die bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit aufgerufen wird, um den Funktionsabbruch auszuführen. Bei einer solchen Vorgehensweise wird die innerhalb der vorgegebenen Task-Laufzeit abzuarbeitende Zusatzfunktion zeitgenau nach Überschreiten des Abbruchszeitpunktes beendet.
Alternativ kann die Funktion eine Abbruchsbedingung umfassen, die bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit das Ausführen der Funktion abbricht und ein Bearbeitungsergebnis rückmeldet. Bei einer solchen Vorgehensweise wird ein kontrollierter Funktionsabbruch gewährleistet. Die Ergebnisse der Zusatzfunktion beim Abbruchszeitpunkt können dann uneingeschränkt weiter verwendet werden.
Die Zeitüberwachungsfunktion kann den vorgegebenen Abbruchszeitpunkt beim Aufruf als Summe aus der aktuellen Zeit und einer maximal erlaubten Zeitspanne bestimmen. Der Abbruchszeitpunkt lässt sich dann dynamisch bestimmen und flexibel anpassen.
Ferner kann die Zeitüberwachungsfunktion beim Beenden eine Kenngröße ausgeben, die den Anteil der erfolgten Funktionsausführung angibt. Alternativ oder zusätzlich kann die Kenngröße die Anzahl akkumulierter Funktionselemente anzeigen. Die Kenngröße stellt ein Maß für das Vertrauen in die korrespondierenden Berechnungsergebnisse der Zusatzfunktion dar. Die Kenngröße kann auch herangezogen werden, um eine Anpassung der Zusatzfunktion durchzuführen.
Die Funktion kann eine Mehrzahl von Funktionselementen aufweisen, wobei die beim Beenden der Zeitüberwachungsfunktion ausgegebene Kenngröße den akkumulierten Anteil der erfolgten Ausführung der Funktionselemente anzeigt. Mit dieser Vorgehensweise besteht die Möglichkeit Funktionselemente zu bündeln, um deren Laufzeit gemeinsam zu überwachen. Ferner lassen sich beispielsweise auch Schleifen, die Funktionselemente iterativ aufrufen, auf einfache Weise in die Laufzeitüberwachung mit einbeziehen. Die Akkumulation verrechnet dann die Kenngrößen der Laufzeitüberwachung der einzelnen Funktionselemente zu einem Gesamtergebnis über die gesamte überwachte Zeitspanne.
Weiterhin kann die Zeitüberwachungsfunktion beim Beenden einen Zeitwert ausgeben, der die Zeitdifferenz zwischen der aktuellen Zeit und dem vorgegebenen Abbruchszeitpunkt anzeigt. Diese ermittelte Restzeit kann beispielsweise zur Optimierung der Ausführung der Zusatzfunktion in der Echtzeitumgebung eingesetzt werden. Weiterhin ist eine Nutzung eines Rechenzeitintervalls in der Länge der Restzeit durch andere Komponenten des Echtzeitsystems denkbar.
Die Zeitüberwachungsfunktion kann beim Beenden ferner einen Fehlercode ausgeben, der einen Fehlerzustand bei der Ausführung der Zeitüberwachungsfunktion wiedergibt.
Die Zeitüberwachungsfunktion kann wenigstens ein untergeordnetes Zeitüberwachungsfunktionselement aufweisen, das einen Abbruchszeitpunkt für eine zugeordnete Funktion innerhalb der vorgegebenen Task-Laufzeit vor dem Abbruchszeitpunkt der Zeitüberwachungsfunktion festlegt. Mit solchen verschachtelten Zeitüberwachungsfunktionselementen lassen sich einzelne Funktionselemente der Zusatzfunktion, also Programmcodebereiche wie Schleifen, in Bezug auf ihre Laufzeit getrennt überwachen.
Die Zeitüberwachungsfunktion wird unter Verwendung eines Stacks verwaltet. Der Stack bildet eine einfache Möglichkeit, Hierarchieebenen der einzelnen Zeitüberwachungsfunktionselemente durch eine entsprechende Positionierung auf dem Stack auszubilden.
Eine speicherprogrammierbare Steuerung ist über einen Feldbus mit Aktoren und Sensoren einer Produktionsanlage verbunden. Die speicherprogrammierbare Steuerung umfasst dabei eine Echtzeitumgebung in der vorher erläuterten Form, deren Task zur Steuerung von Aktoren und Sensoren dient, wobei die Ausführung der Funktion durch die Zeitüberwachungsfunktion mit der Steuerung synchronisiert ist.
Die speicherprogrammierbare Steuerung kann mit einer Funktionseinheit zur Bilderfassung verbunden sein, um deren Bilddaten in die Echtzeitumgebung zu übertragen, wobei die Funktion eine Vision-Funktion zur Verarbeitung und/oder Analyse der Bilddaten ist.
Die Erfindung wird anhand der beigefügten Zeichnungen näher erläutert.
1 zeigt schematisch einen Aufbau einer erfindungsgemäßen speicherprogrammierbaren Steuerung für eine Produktionsanlage, die Aktoren und Sensoren und eine Bilderfassungseinheit aufweist.
2 zeigt einen Aufbau einer Datenstruktur einer Zeitüberwachungsfunktion, die in einer erfindungsgemäßen Echtzeitumgebung ausgeführt wird.
3 zeigt einen Aufbau eines Stacks mit Zeitüberwachungsfunktionen.
4 zeigt einen möglichen Programmablaufplan zum Start einer Zeitüberwachungsfunktion, der in einer erfindungsgemäßen Echtzeitumgebung ausgeführt wird.
5 zeigt einen möglichen Programmablaufplan zum Ausführen einer Vision-Funktion, die in einer erfindungsgemäßen Echtzeitumgebung ausgeführt wird.
6 zeigt einen möglichen Programmablaufplan zum Start einer Zeitüberwachungsfunktion, der in einer erfindungsgemäßen Echtzeitumgebung ausgeführt wird.
7 zeigt ein Beispiel für das Propagieren der Restzeit beim Ausführen mehrerer verschachtelter Zeitüberwachungsfunktionen.
In einer Produktionsanlage wird zur Steuerung von Sensoren 1 und Aktoren 2 eine speicherprogrammierbare Steuerung (SPS) 3 eingesetzt, die, wie 1 zeigt, über einen Feldbus 4 mit den Sensoren 1 und Aktoren 2 verbunden ist. Die SPS kann als eigenständige Datenverarbeitungseinheit beispielsweise in Form eines Industrie-PCs 5, wie in 1 dargestellt, ausgeführt sein oder auch als Software-SPS zusätzlich auf einer bereits vorhandenen Einheit der Produktionsanlage laufen. Alternativ zu einem Feldbus 4 kann eine anders ausgestaltete Kommunikationsverbindung zum Datenaustausch zwischen den Sensoren 1 und Aktoren 2 und der SPS 3 eingesetzt werden.
Die Verarbeitung der Daten von bzw. für die Sensoren 1 und Aktoren 2 erfolgt auf der SPS 3 in Form von Aufgaben, sogenannten Tasks. Die Tasks werden zur Steuerung der Sensoren 1 und Aktoren 2 in der Regel zyklisch ausgeführt, wobei sichergestellt werden muss, dass die Tasks garantiert innerhalb einer vorgegebenen Maximalzeit, beispielsweise innerhalb der für einen Zyklus zur Verfügung stehenden Zeit, abgearbeitet werden. Weiterhin muss die zyklische Ausführung der Tasks ohne zeitliche Schwankungen (Jitter) mit einer vorhersehbaren Antwortzeit (Latenzzeit) gewährleistet werden. Diese Anforderungen an die SPS 3 werden durch eine Echtzeitumgebung implementiert.
Neben den Aktoren 2 und Sensoren 1 weisen Produktionsanlagen in der Regel noch eine Vielzahl weiterer Systeme auf, deren Funktionen mit dem Produktionsprozess und dessen Steuerung mit der Hilfe der Sensoren 1 und Aktoren 2 durch die SPS 3 synchronisiert werden müssen. Vision-Systeme stellen ein solches Zusatzsystem dar. Mit Vision-Systemen kann beispielsweise eine Objekterkennung, eine Oberflächeninspektion, eine Vermessung oder eine Identifikation durchgeführt werden. Um diese Aufgaben zu lösen, müssen die Vision-Systeme eine Vielzahl von Bildverarbeitungs- und Bildanalyse-Operationen ausführen. Solche Bildverarbeitungs- und Bildanalyse-Operationen können beispielsweise Filter, Schwellwerte, morphologische Operatoren, geometrische Transformationen, Farbraumtransformationen, Segmentierungsverfahren, Konturensuche sowie Methoden zur Textur- und Formanalyse umfassen.
Erfindungsgemäß ist die SPS 3, wie 1 zeigt, dahingehend erweitert, dass Bilddaten einer Funktionseinheit 6 zur Bilderfassung beispielsweise einer Kamera des Vision-Systems direkt in einen Speicherraum der SPS 3 gelangen. Die Funktionseinheit 6 zur Bilderfassung wird im Folgenden auch als Bilderfassungseinheit 6 bezeichnet. In der in 1 gezeigten beispielhaften Implementierung, welche Ethernet 7 als Kommunikationsmedium zwischen der Bilderfassungseinheit 6 und der SPS 3 nutzt, werden Ethernet-Pakete der Bilderfassungseinheit 6 direkt von einem Netzwerkadapter in die Echtzeitumgebung der SPS 3 übertragen. In der Echtzeitumgebung der SPS 3 erfolgt eine protokollspezifische Bearbeitung der Ethernet-Pakete, um die Bilddaten dann in der Echtzeitumgebung mit Hilfe von Vision-Funktionen zu verarbeiten und zu analysieren. Statt dem Einsatz von Ethernet 7 zur Bilddatenübertragung können auch andere Datenbussystem eingesetzt werden.
Bei den Vision-Funktionen hängen die Funktionslaufzeiten wesentlich von der vorliegenden Datenmenge ab. So kann die Verarbeitungszeit beim Erkennen relevanter Strukturen im Rahmen einer topologischen Strukturanalyse beispielsweise einer Konturensuche stark variieren. Auch die iterative Anwendung eines Algorithmus in Abhängigkeit eines Konvergenzkriteriums beispielsweise ein iteratives Filter oder eine Subpixeloptimierung kann zu einer schwankenden Funktionslaufzeit führen. Gleiches gilt für die Verwendung alternativer Suchstrategien beispielsweise, dass, wenn ein erster Teilalgorithmus nicht erfolgreich ist, ein zweiter Teilalgorithmus versucht wird. Auch eine sogenannte Region-of-Interest mit variabler Größe führt zu unterschiedlichen Funktionslaufzeiten. Folglich liegen die Ergebnisse der jeweiligen Funktionsoperationen zu variablen Zeitpunkten vor. Dies widerspricht jedoch der Anforderung an die Echtzeitumgebung der SPS 3, die die zyklische Ausführung der Task ohne zeitliche Schwankungen (Jitter) mit einer vorhersehbaren Antwortzeit (Latenzzeit) gewährleisten muss.
Auch einer Integration anderer Zusatzfunktionen, die mit dem Produktionsprozess und dessen Steuerung durch die SPS 3 synchronisiert werden sollen, in die Echtzeitumgebung der SPS 3, steht die unbekannte Funktionslaufzeit entgegen. Eine solche Zusatzfunktion ist beispielsweise die Zustandsüberwachung (Condition Monitoring), bei der eine regelmäßige oder permanente Erfassung und Bewertung des Zustandes der Produktionsanlage durch Messung und Analyse von Maschinenparametern, die den aktuellen Zustand des Produktionsprozesses widerspiegeln, durchgeführt wird. Bei der Zustandsüberwachung werden oft iterative Verfahren zur Analyse der erfassten Daten eingesetzt, wobei die Laufzeit vom Erreichen eines Gütekriteriums abhängig und damit nicht von vornherein festgelegt ist. Auch im Bereich des maschinellen Lernens und der numerischen Steuerung und weiteren mit dem Produktionsprozess zu synchronisierende Zusatzfunktionen, variiert die Funktionslaufzeit.
Um eine Zusatzfunktion mit unbestimmter Funktionslaufzeit in eine Echtzeitumgebung, in der wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt wird, integrieren zu können, ist erfindungsgemäß eine Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Funktion innerhalb der vorgegebenen Task-Laufzeit festlegt, vorgesehen. Wenn eine Funktion innerhalb der vorgegebenen Task-Laufzeit abgearbeitet werden soll, wird die Zeitüberwachungsfunktion gestartet. Die Zeitüberwachungsfunktion überwacht dann die Funktionslaufzeit, wobei bei Überschreiten des vorgegebenen Abbruchszeitpunktes einen Funktionsabbruch veranlasst wird.
Durch Vorsehen der Zeitüberwachungsfunktion ist die Ausführung der Zusatzfunktion so ausgestaltet, dass die Funktionslaufzeit in Abhängigkeit der im aktuellen Zyklus der Task noch verfügbaren Rechenzeit gesteuert werden kann. Die Zusatzfunktion kann direkt in der Echtzeitumgebung der SPS 3 ausgeführt werden, da mit Hilfe der Zeitüberwachungsfunktion die zyklische Ausführung der Task mit einer vorhersehbaren Antwortzeit garantiert werden kann. Weiterhin wird eine zeitgenaue Kopplung der von der Zusatzfunktion ausgeführten Algorithmen an das Timing des Produktionsprozesses erreicht.
Im Weiteren wird die Erfindung am Beispiel der Vision-Funktion erläutert. Die Ausführungen lassen sich aber auch auf andere Zusatzfunktionen, insbesondere die vorstehend genannten weiteren Zusatzfunktionen, übertragen.
Die Zeitüberwachungsfunktion, im Weiteren auch als Watchdog bezeichnet, kann als Wrapper-Funktion ausgebildet sein, die die Zusatzfunktion umhüllt. Die Zeitüberwachungsfunktion ist dabei als Programmcode ausgeführt, welcher die Funktionssoftware umgibt. Mit der Ausbildung der Zeitüberwachungsfunktion als Wrapper besteht die Möglichkeit, die Software der Zusatzfunktion auf einfache Weise zu erweitern, ohne umfangreich in den Programmcode der Zusatzfunktion eingreifen zu müssen. Der Programmcode der Zusatzfunktion läuft dann innerhalb des Programmcodes der Zeitüberwachungsfunktion.
Der Watchdog kann sowohl präemptiv als auch kooperativ realisiert werden. Bei einem präemptiven Watchdog wird die innerhalb der vorgegebenen Task-Laufzeit abzuarbeitende Zusatzfunktion zeitgenau nach Überschreiten des Abbruchszeitpunktes beendet. Der Watchdog sorgt dabei für eine fortlaufende Überwachung der Funktionslaufzeit. Bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit wird eine Abbruchsfunktion aufgerufen, um den Funktionsabbruch auszuführen. Hierzu kann außerhalb des Watchdogs und der jeweiligen Zusatzfunktion ein Unterbrechungsprogramm eingerichtet sein, das zum Abbruchszeitpunkt ausgeführt wird. Alternativ kann die Abbruchsfunktion auch Teil des Watchdogs sein, in die der Watchdog-Programmcode abzweigt, wenn die Abbruchbedingung durch Überschreiten des vorgegebenen Abbruchszeitpunktes erfüllt ist.
Der Abbruch der Ausführung der Zusatzfunktion kann beispielsweise über Interrupts erfolgen. Beim präemptiven Watchdog wird beim Starten beispielsweise ein Timer gestartet, der beim Ablauf den Interrupt auslöst, der die zu überwachende Zusatzfunktion abbricht. Beim präemptiven Watchdog erfolgt der Abbruch der Zusatzfunktion in der Regel an einer unbekannten Programmposition innerhalb der Zusatzfunktion, so dass die Zusatzfunktion sich in einem undefinierten Zustand befinden kann, wodurch die Ergebnisse der Zusatzfunktion zum Abbruchszeitpunkt oft nur eingeschränkt verwendbar sind.
Im Gegensatz zum präemptiven Watchdog ermöglicht der kooperative Watchdog einen kontrollierten Funktionsabbruch. Dazu wird vorzugsweise der Programmcode der Zusatzfunktion erweitert, indem eine Zusatzbedingung beispielsweise an funktionsspezifisch zentrale Bearbeitungsschleifen eingefügt wird. Die Zusatzbedingung überprüft die für den Algorithmus der Zusatzfunktion verbrauchte Rechenzeit zu festgelegten Zeitpunkten, beispielsweise am Ende der zugeordneten Bearbeitungsschleife. Wird bei der Überprüfung festgestellt, dass die Funktionslaufzeit den Abbruchszeitpunkt überschritten hat, wird die zugeordnete Bearbeitungsschleife der Zusatzfunktion verlassen.
Bereits vorliegende Ergebnisse der Zusatzfunktion können genutzt werden, da die Zusatzfunktion kontrolliert durch Herauszweigen am Ende einer Bearbeitungsschleife abgebrochen wird. Der Abbruch der Zusatzfunktion beim kooperativen Watchdog ist im Vergleich zum präemptiven Watchdog aber in der Regel weniger zeitgenau, da nur zu durch die Zusatzfunktion festgelegten Zeitpunkten abgebrochen wird.
Die Zeitüberwachungsfunktion kann den vorgegebenen Abbruchszeitpunkt t_Abbruch beim Aufruf als Summe aus der aktuellen Zeit t_aktuell und einer maximal erlaubten Zeitspanne Δt_max bestimmen. Die aktuelle Zeit t_aktuell kann dabei auf den Beginn des laufenden Taskzyklus bezogen werden: t_Abbruch = t_aktuell + Δt_max (1)
Watchdogs, die ihre Abbruchszeit entsprechend der Gleichung (1) dynamisch bestimmen, werden im Weiteren auch als Zeitspannen-Watchdogs bezeichnet.
Die Zeitüberwachungsfunktion kann ferner beim Beenden eine Kenngröße ausgeben, der den Anteil der erfolgten Funktionsausführung anzeigt. Als Kenngröße kann dabei ein numerischer Wert von der Zeitüberwachungsfunktion verwendet werden, der den Anteil a_f der bereits erfolgten Bearbeitungsschritte im Verhältnis zur vollständigen Bearbeitung einer Zusatzfunktion f widerspiegelt. Die Berechnung der Kenngröße hängt vom Algorithmus der Zusatzfunktion f ab.
Beispielhafte Varianten zur Berechnung des Anteils a_f für eine Vision-Funktion als Zusatzfunktion sind a_f = aktueller Anteil der verarbeiteten ROI / Gesamtgröße der verarbeiteten ROI (2) a_f = gewünschte Genauigkeit / max(gewünschte Genauigkeit, aktuelle Genauigkeit) (3) a_f = Anzahl ausgeführter Teilalgorithmen / Anzahl möglicher Teilalgorithmen (4)
Die Gleichung (2) ist dabei für Algorithmen geeignet, die alle Bildpunkte einer Region-of-Interest (ROI) sequenziell verarbeiten, wobei die ROI auch das gesamte Bild umfassen kann. Die verwendeten Algorithmen können beispielsweise einfache Faltungsfilter oder Schwellwertoperatoren sein. Auch für komplexere Algorithmen wie Labelling oder Konturensuche ist die Gleichung (2) zur Berechnung des Anteils a_f geeignet.
Das Anwendungsgebiet von Gleichung (3) sind vor allem iterative Algorithmen, bei denen solange weitere Iterationen durchgeführt werden, bis eine gewünschte Genauigkeit erreicht ist. Die Genauigkeit kann hierbei beispielsweise durch den absoluten Betrag der Veränderung einer oder mehrerer zu optimierender Größen zwischen zwei aufeinanderfolgenden Iterationen des Algorithmus angegeben werden.
Die Gleichung (4) ist für komplexe Algorithmen geeignet, die alternative Verarbeitungsstrategien in Abhängigkeit der Ergebnisse durchführen. Beispielsweise kann ein Algorithmus zur Kennzeichenerkennung erst versuchen Datamatrix-Codes zu ermitteln und, falls dies fehlschlägt, dann eine weitere Suche nach QR-Codes und anschließend gegebenenfalls nach eindimensionalen Barcodes durchführen.
Auch Kombinationen der vorstehenden Gleichungen zur Ermittlung des Anteils a_f für eine Vision-Funktion sind denkbar. Die ermittelte Kenngröße, die den Anteil der erfolgten Funktionsausführung beim Funktionsabbruch angibt, steht dann zusätzlich zu den Berechnungsergebnissen der Zusatzfunktion zur Verfügung. Die Kenngröße stellt dabei ein Maß für das Vertrauen in die korrespondierenden Berechnungsergebnisse dar. Anhand des jeweiligen Anteil a_f der bereits erfolgten Bearbeitungsschritte im Verhältnis zur vollständigen Verarbeitung der Zusatzfunktion f können beispielsweise weniger vertrauenswürdige Berechnungsergebnisse von der weiteren Verarbeitung ausgeschlossen werden oder in diese mit einer geringen Gewichtung einfließen.
Alternativ kann die ermittelte Kenngröße, die den Anteil der erfolgten Funktionsausführung beim Funktionsabbruch angibt, auch herangezogen werden, um eine Anpassung der Zusatzfunktion durchzuführen. Ein geringerer Bearbeitungsanteil a_f bei einer Vision-Funktion könnte beispielweise durch eine Anpassung der Bildaufnahmeparameter oder der Bearbeitungsstrategie im nächsten Taskzyklus erhöht werden. Der Programmierer der SPS erhält durch die Ausgabe der Kenngröße, die Möglichkeit schon während eines laufenden Taskzyklus Probleme bei der Ausführung der Zusatzfunktion zu erkennen und durch eine anschließende Modifikationen Abbrüche von Vision-Funktionen und Zeitüberschreitung in der Zukunft zu verhindern.
Die Zeitüberwachungsfunktion als Wrapper-Funktion kann unmittelbar vor der zu steuernden Vision-Funktion und unmittelbar danach aufgerufen werden. Eine mögliche Befehlsstruktur ist: err = StarteWatchdog(t_Abbruch) VisionFunktion (); (n, a, Δt_Rest, err) = StoppeWatchDog()
t_Abbruch gibt dabei den Abbruchszeitpunkt relativ zum aktuellen Taskzyklus an. err bezeichnet einen Fehlercode, dessen Werte dazu dienen, Fehlerzustände bei der Ausführung der Zeitüberwachungsfunktion anzuzeigen. In einer möglichen Implementierung kann err = 0 bedeuten, dass kein Fehler bei der Ausführung der Zeitüberwachungsfunktion aufgetreten ist, wohingegen err ≠ 0 einen Fehler signalisiert.
Das Element n des Tupels (n, a, Δt_Rest, err) gibt die Anzahl der ausgeführten Funktionselemente der Zusatzfunktion an. Die Bedeutung der Funktionselemente wird in Zusammenhang mit 2 noch erläutert werden.
Ferner ist im Tupel (n, a, Δt_Rest, err) weiter neben dem Bearbeitungsanteil a (in Prozent) die Zeitdifferenz Δt_Rest von aktueller Zeit t_aktuell zu Abbruchszeitpunkt t_Abbruch: Δt_Rest = t_Abbruch – t_aktuell (5)
Wird eine Zusatzfunktion, im Beispiel die Vision-Funktion, vorzeitig abgebrochen, sind 0% ≤ a_f < 100% und Δt_Rest ≤ 0. Wenn eine Zusatzfunktion vollständig ausgeführt, also vor Erreichen des Abbruchszeitpunktes t_Abbruch beendet wird, sind a_f = 100% und Δt_Rest > 0.
Neben der Kenngröße a_f, die den Anteil der erfolgten Funktionsausführung beim Funktionsabbruch angibt, eignet sich die vom Watchdog ermittelte Restzeit Δt_Rest zur Optimierung der Ausführung der Zusatzfunktion in der Echtzeitumgebung. Die Restzeit Δt_Rest kann insbesondere zur Bewertung der Ausführung der Zusatzfunktion durch Softwarekomponenten außerhalb der aktuellen Task eingesetzt werden. Beispielsweise kann ein SPS-Programm, das Teil einer weiteren Task der Echtzeitumgebung ist, die vom Watchdog ermittelte Restzeit Δt_Rest abfragen, um festzustellen, welcher Anteil der zur Verfügung stehenden Rechenzeit tatsächlich durch die Ausführung der Zusatzfunktion verbraucht wurde. Falls noch ungenutzte Rechenzeit zur Verfügung steht, kann dann diese Rechenzeit dynamisch für andere, weniger zeitkritische Aufgaben eingesetzt werden, beispielsweise den Export von Bildern der Vision-Funktion an eine Mensch-Maschine-Schnittstelle außerhalb der Echtzeitumgebung.
Durch die Implementierung des Watchdogs als die Zusatzfunktion ergänzendes Funktionselement beispielsweise in Form einer Wrapper-Befehlsstruktur können die Watchdogs standardisiert aufgebaut werden, was eine einfache Modifikation und Anpassung ermöglicht. Die Überwachung des Zeitverhaltens einer spezifischen Zusatzfunktion beispielsweise der Vision-Funktion kann so ohne Veränderung der Zusatzfunktion selbst bzw. deren Funktionsparameter angepasst werden.
Eine mögliche Datenstruktur für einen Watchdog 200 ist in 2 dargestellt. Die Watchdog-Datenstruktur weist mehreren Datenfeldern auf, die Watchdog-Parameter enthalten. Ein erstes Datenfeld 210 kann dabei den Watchdog-Typ anzeigen. Der Watchdog-Typ kann beispielsweise anzeigen, ob ein präemptiver Watchdog oder ein kooperativer Watchdog eingesetzt wird. Als weiteres Datenfeld 220 enthält die Watchdog-Datenstruktur den Abbruchzeitpunkt t_Abbruch. Ferner ist ein Datenfeld 230 für die Anzahl der akkumulierten Funktionselemente n, ein Datenfeld 240 für den akkumulierten Bearbeitungsanteil a und ein Datenfeld 250 für die akkumulierte Restzeit Δt _Rest vorgesehen.
Mit der in 2 gezeigten Watchdog-Datenstruktur lässt sich eine Überwachung größerer Programmcodebereiche einschließlich Schleifen und Verzweigungen, im Weiteren als Funktionselemente bezeichnet, bei einer Zusatzfunktion realisieren. Dabei ist es vorteilhaft, zu Beginn der Ausführung jedes Funktionselements der Zusatzfunktion zu überprüfen, ob der Abbruchzeitpunkt t_Abbruch überschritten wurde. Wenn dies der Fall ist, unterbleibt dann die Bearbeitung weiterer Funktionselemente.
Funktionselemente, die keine partielle Bearbeitung unterstützen, gehen entweder mit Bearbeitungsanteil a_f = 0% oder a_f = 100% in die Berechnung ein.
Falls die Ergebnisse der überwachten Zusatzfunktionselemente weitgehend unabhängig voneinander sind, kann der akkumulierte Bearbeitungsanteil a näherungsweise als inkrementeller Mittelwert der Bearbeitungsanteile aller aufgerufenen Funktionselemente ermittelt werden, wobei a_f den Bearbeitungsanteil des aktuellen Funktionselements f und n die Anzahl der vorher aufgerufenen Funktionselemente angibt:
Falls die Berechnungsergebnisse der Funktionselemente der überwachten Zusatzfunktion dagegen aufeinander aufbauen, liefert die Gleichung (6) zur der Verrechnung der Berechnungsanteile zu optimistische Werte für den akkumulierten Berechnungsanteil a, da das aktuelle Funktionselement nur auf den erfolgreich berechneten Anteil an Resultaten der vorhergehenden Funktionselemente zurückgreifen kann. In diesem Fall ist eine multiplikative Verrechnung geeignet, wie sie in der nachstehenden Gleichung (7) angeben ist:
Alternativ zu den Gleichungen (6) und (7) sind auch andere Berechnungsarten zur Bestimmung des akkumulierten Bearbeitungsanteils a denkbar. Welche Berechnungsart im jeweiligen Fall verwendet werden soll, kann durch die Auswahl eines zugeordneten Watchdog-Typs entschieden werden. WatchdogTypA kann beispielsweise den akkumulierten Bearbeitungsanteil a mit der Gleichung (6) und WatchdogTypB mit der Gleichung (7) ermitteln. Die Wahl des zu nutzenden Watchdogs kann beispielsweise mit Hilfe der Befehle zum Starten und Stoppen realisiert werden. So können die Befehle StarteWatchdogTypA und StoppeWatchdogTypA zum Starten und Stoppen eines Watchdogs vom Typ A und die Befehle StarteWatchdogTypB und StoppeWatchdogTypB zum Starten und Stoppen eines Watchdogs vom Typ B verwendet werden.
Ferner kann die Zeitüberwachungsfunktion (Watchdog) wenigstens ein untergeordnetes Zeitüberwachungsfunktionselement, im Weiteren auch als untergeordneter Watchdog bezeichnet, aufweisen, das einen Abbruchzeitpunkt für ein Zusatzfunktion innerhalb der vorgegebenen Task-Laufzeit vor dem Abbruchzeitpunkt der Zeitüberwachungsfunktion festlegt. Durch eine solche Verschachtelung können die Watchdogs eine Hierarchie ausbilden, die eine genauere Zeitüberwachung der Zusatzfunktion ermöglicht.
Bei einer Verschachtelung werden während der Ausführung eines Watchdogs mit Hilfe der Befehle zum Starten und Stoppen ein oder mehrere untergeordnete Watchdogs aufgerufen. Die Anzahl bereits ausgeführter Befehle zum Starten von Watchdogs, für die noch kein entsprechender Befehl zum Stoppen des gestarteten Watchdogs erfolgt ist, gibt die Hierarchieebene des jeweiligen Watchdogs an.
Eine mögliche Implementierung kann beispielsweise ein LIFO (last in, first out), auch Stack genannt, sein, wie er in 3 dargestellt ist.
Im Beispiel in 3 weist der Stack zwei Watchdogs auf, wobei der übergeordnete Watchdog ein Watchdog vom Typ A ist und der untergeordnete Watchdog ein Watchdog vom Typ B ist. Überwacht werden soll das Zeitverhalten einer Vision-Funktion, die drei Funktionselemente VisionFunktion1 VF1, VisionFunktion2 VF2 und VisionFunktion3 VF3 umfasst. 3 zeigt im linken Teil den Programmablauf zur Überwachung der Vision-Funktion mit den beiden verschachtelten Watchdogs und parallel zu den einzelnen Programmschritten im rechten Teil die jeweils aktiven Watchdogs im Stack.
Nach dem Programmstart wird im Programmschritt 100 mit dem Befehl StarteWatchdogTypA der übergeordnete Watchdog Typ A gestartet. Der Watchdog Typ A ist ein Zeitspannen-Watchdog, der die Abbruchszeit entsprechend Gleichung (1) aus der aktuellen Zeit t_aktuell und der maximal erlaubten Zeitspanne Δt_max,, die beispielsweise 5000 µs ist, bestimmt. Nach dem Start des Watchdogs Typ A wird die Vision-Funktion aufgerufen und dann nacheinander die Vision-Funktionselemente VisionFunktion1 VF1, VisionFunktion2 VF2 und VisionFunktion3 VF3 abgearbeitet.
Zwischen den Vision-Funktionselementen VisionFunktion1 VF1 und VisionFunktion2 VF2 wird weiter im Programmschritt 200 der untergeordnete Watchdog Typ B mit dem Befehl StarteWatchdogTypB gestartet. Der untergeordnete Watchdog Typ B ist wiederum als Zeitspannen-Watchdog ausgebildet, der die Abbruchzeit beim Aufruf aus der Summe der aktuellen Zeit t_aktuell und der maximal erlaubten Zeitspanne Δt_max,, die beispielweise 4000 µs ist, bestimmt. Der untergeordnete Watchdog Typ B dient zur Überwachung der Funktionslaufzeiten der Vision-Funktionselemente VisionFunktion2 VF2 und VisionFunktion3 VF3. Danach wird im Programmschritt 300 der untergeordnete Watchdog Typ B mit dem Befehl StoppeWatchdogTypB angehalten. Anschließend wird dann im Programmschritt 400 mit dem Befehl StoppeWatchdogTypA auch der übergeordnete Watchdog Typ B beendet.
Im in 3 weiter gezeigten Watchdog-Stack sind zu den einzelnen Programmschritten jeweils die aktiven Watchdogs angezeichnet. Mit dem Befehl StarteWatchdogTypA wird im Programmschritt 100 der übergeordnete Watchdog Typ A im Watchdog-Stack abgelegt und bleibt aktiv bis zum Befehl StoppeWatchdogTypA im Programmschritt 400. Auf den aktiven übergeordneten Watchdog Typ A wird im Programmschritt 200 mit dem Befehl StarteWatchdogTypB im Watchdog-Stack dann der untergeordnete Watchdog Typ B aufgesetzt. Der untergeordnete Watchdog Typ B bleibt über dem übergeordneten Watchdog Typ A aktiv liegen bis zum Befehl StoppeWatchdogTypB im Programmschritt 300.
Mit dem Watchdog-Stack und den darin enthaltenen verschachtelten Watchdogs lassen sich einzelne Funktionselemente der Zusatzfunktion, also Programmcodebereiche wie Schleifen, in Bezug auf ihre Laufzeit getrennt überwachen. Bei dem in 3 gezeigten Programmablauf überwacht der untergeordnete Watchdog Typ B das Zeitverhalten der Vision-Funktionselemente VisionFunktion2 VF2 und VisionFunktion3 VF3, während der übergeordnete Watchdog Typ A das Zeitverhalten der gesamten Vision-Funktion einschließlich des vor Start des untergeordneten Watchdogs Typ B ausgeführten Vision-Funktionselements VisionFunktion1 VF1 überwacht.
In der Echtzeitumgebung erhält jede Task, die Watchdogs unterstützt, einen eigenen Stack. Die Hierarchieebene der einzelnen Watchdogs wird durch die Position des Watchdogs auf dem Stack repräsentiert. Aus Effizienzgründen besteht dabei die Möglichkeit für die Zeitüberwachung einer Zusatzfunktion immer nur den obersten und damit den hierarchisch am höchsten eingestuften Watchdog im Stack der Task heranzuziehen. In einer alternativen Implementierung kann aber auch der Abbruchzeitpunkt aller Watchdogs auf dem Stack überprüft werden.
Bei der Verschachtelung von Watchdogs können die Bearbeitungsanteile der einzelnen Watchdogs miteinander verrechnet werden. In einer möglichen Implementierung können dabei die Bearbeitungsanteile aller Watchdogs auf dem Stack angepasst werden. Neben einer möglichen Redundanz von durchgeführten Berechnungen kann eine solche Implementierung aber bei unterschiedlichen Verrechnungsvorschriften für den akkumulierten Bearbeitungsanteil der verschiedenen Watchdogs, wie sie beispielsweise in den Gleichungen (6) und (7) angegeben sind, zu inkonsistenten Ergebnissen führen.
Alternativ kann die Verrechnung auch so ausgestaltet sein, dass nur der Bearbeitungsanteil des obersten und damit des hierarchisch am höchsten eingestuften Watchdogs auf dem Stack anpasst wird. Der akkumulierte Bearbeitungsanteil a und die Anzahl der akkumulierten Funktionselemente n der Zusatzfunktion werden dann beim Aufruf des Befehls zum Stoppen des Watchdogs zum darunter liegenden und damit hierarchisch tiefer eingestuften Watchdog propagiert. Auf diese Weise werden mehrfache und gegebenenfalls unterschiedliche Verrechnungen des Bearbeitungsanteils einzelner Funktionselemente der Zusatzfunktion vermieden.
Die Propagierung der akkumulierten Bearbeitungsanteile kann analog zu der Verrechnung der Bearbeitungsanteile, wie sie in den Gleichungen (6) und (7) angegeben ist, erfolgen. Bei der Propagierung der akkumulierten Bearbeitungsanteile von einem Watchdog W₁ zu einem darüber liegenden und damit einem hierarchisch höheren Watchdog W₂ wird der akkumulierte Bearbeitungsanteil von W₂ beispielsweise wie folgt angepasst:
oder
Die Notation W_X.Y bezeichnet dabei das Datenfeld Y von Watchdog W_X. Die Gleichung (8) entspricht einer Verrechnung analog zur Gleichung (6) und die Gleichung (9) einer Verrechnung analog zur Gleichung (7).
Zusätzlich zur Propagierung der Bearbeitungsanteile kann auch die Anzahl der akkumulierten Funktionselemente n von dem Watchdog W₁ zu dem darunter liegenden und damit hierarchisch tieferen Watchdog W₂ propagiert werden: W₂.n = W₂.n + W₁.n (10)
Neben der Überwachung des Zeitverhaltens von Zusatzfunktionen eignen sich die Watchdogs, wie erläutert, auch zur Optimierung der SPS. Dies gilt insbesondere für die vom Watchdog zusätzlich ermittelte akkumulierte Restzeit Δt _Rest, die in der Watchdog-Datenstruktur, die in 2 gezeigt ist, in einem Datenfeld gespeichert ist und von extern abgefragt werden kann.
In der akkumulierten Restzeit Δt _Rest kann dabei die ungenutzte Rechenzeit der Watchdogs der verschiedenen Hierarchieebenen in einem Stack gesammelt werden. Beim Aufruf des Befehls zum Stoppen des Watchdogs W₁ kann die Restzeit Δt _Rest, die sich als W₁.Δt _Rest = Δt_Rest ergibt, an den Watchdog W₂ der darunter liegenden Hierarchieebene propagiert werden. Die Propagierung der Restzeit von dem Watchdog W₁ zu dem Watchdog W₂ kann dabei folgendermaßen durchgeführt werden: W₂.Δt _Rest = W₁.Δt _Rest (11)
Für Zeitspannen-Watchdogs, die den Abbruchszeitpunkt beim Aufruf als Summe aus der aktuellen Zeit und einer maximal erlaubten Zeitspanne bestimmen, ist diese Art der Berechnung jedoch nicht ausreichend, da eine Zeitersparnis bei einem vorher ausgeführten Watchdog automatisch in die Berechnung der Abbruchzeitpunkte t_Abbruch der folgenden Zeitspannen-Watchdogs einfließt, wie sich aus der vorstehenden Gleichung (1) ergibt. Die Restzeit vorhergehender Watchdogs muss bei Zeitspannen-Watchdogs deshalb explizit gesammelt werden. Dafür kann die folgende Vorschrift zur Propagierung von dem Zeitspannen-Watchdog W₁ zu dem Watchdog W₂ genutzt werden: W₂.Δt _Rest = W₂.Δt _Rest + W₁.Δt _Rest (12)
Die Summe der akkumulierten Restzeit Δt _Rest aller Watchdogs auf dem Stack gibt in beiden Varianten die ungenutzte Rechenzeit an und kann dann von Softwarekomponenten anderer Tasks aus der Watchdog-Datenstruktur ausgelesen und weiterverarbeitet werden, um das Verhalten der Echtzeitumgebung der SPS zu optimieren.
In den 4 bis 6 ist ein möglicher Programmablauf einer Zeitüberwachungsfunktion mit einem Watchdog-Stack, die als Wrapper-Funktion für eine Vision-Funktion ausgeführt ist und die die bereits erläuterte Befehlsstruktur mit den Befehlen err = StarteWatchdog(t_Abbruch); VisionFunktion (); (n, a, Δt_Rest, err) = StoppeWatchDog() nutzt, gezeigt. Im Programmablauf stellt ein Oval einen Kontrollpunkt wie Start und Stopp dar, ein Rechteck gibt einen Programmschritt wieder und eine Raute ist ein Verzweigungsschritt, bei dem eine Entscheidung getroffen werden muss. Ferner geben Pfeile die Verbindungen zwischen den Programm- und Verzweigungsschritten wieder. In den 4 bis 6 steht |S| außerdem für die Anzahl der Watchdogs auf dem Watchdog-Stack und W_S für den obersten Watchdog auf dem Watchdog-Stack.
4 zeigt beispielhaft für den Befehl err = StarteWatchdogTypA (t_Abbruch) den Programmablauf, wobei ein Watchdog W vom Watchdog Typ A im Rahmen eines Watchdog-Stacks gestartet werden soll.
In einem ersten Programmschritt SP1 initialisiert der Watchdog W seine in 2 gezeigte Datenstruktur. Der Watchdog W, der ein Zeitspannen-Watchdog ist, bestimmt dabei den Abbruchszeitpunkt t_Abbruch aus der aktuellen Zeit t_aktuell und der maximal erlaubten Zeitspanne Δt_max. Ferner werden die Datenfelder Anzahl akkumulierter Funktionselemente n, akkumulierter Bearbeitungsanteil a und akkumulierte Restzeit Δt _Rest auf 0 gesetzt.
In einem ersten Entscheidungsschritt SZ1 wird dann ermittelt, ob im Watchdog-Stack bereits Watchdogs aktiv sind.
Wenn bei der Abfrage festgestellt wird, dass bereits ein Watchdog aktiv ist, also |S| > 0 ist, wird in einem zweiten Entscheidungsschritt SZ2 geprüft, ob im Vergleich zur Abbruchzeit des obersten Watchdogs W_S im Watchdog-Stack die Abbruchzeit des Watchdogs W kleiner oder gleich ist.
Wenn dies zutrifft, legt sich der Watchdog W in einem zweiten Programmschritt SP2 oben auf den Watchdog-Stack.
Optional bereitet der Watchdog W dann, wenn es sich um einen präemptiven Watchdog handelt, in einem dritten Programmschritt SP3 eine Abbruchfunktion vor.
Anschließend wird in einem vierten Programmschritt SP4 ein Fehlercode err = 0 gesetzt, um anzuzeigen, dass kein Fehler bei der Programmausführung aufgetreten ist.
Wenn im ersten Entscheidungsschritt SZ1 festgestellt wird, dass kein Watchdog im Watchdog-Stack aktiv ist, also |S| = 0, zweigt das Programm ab und umgeht einen zweiten Entscheidungsschritt SZ2 und fährt direkt mit dem zweiten Programmschritt SP2 fort.
Wenn in einem zweiten Entscheidungsschritt SZ2 festgestellt wird, dass die Abbruchzeit des Watchdogs W größer ist als die Abbruchzeit des obersten Watchdogs W_S im Watchdog-Stack, also der Abbruchszeitpunkt des oberste Watchdogs W_S im Watchdog-Stack vor dem Abbruchszeitpunkt des zu startenden Watchdogs W liegt, wird aus dem Programm abgezweigt und in einem fünften Programmschritt SP5 ein Fehlercode err = 1 gesetzt, um anzuzeigen, dass ein Fehler beim Watchdog-Start vorliegt.
Nach dem vierten Programmschritt SP4, bei dem der Fehlercode err = 0 gesetzt wird, oder dem fünften Programmschritt SP5, bei dem der Fehlercode err = 1 gesetzt wird, wird der Programmablauf des Befehls err = StarteWatchdog(t_Abbruch) beendet.
5 zeigt beispielhaft den Programmablauf des Befehls VisionFunktion () zur Ausführung und Zeitüberwachung des Vision-Funktionselements VisionFunktion, der nach dem Befehl err = StarteWatchdog(t_Abbruch), dessen Programmablauf in 4 gezeigt ist, aufgerufen wird.
Im Programmablauf des Befehls VisionFunktion () erfolgt in einem ersten Programmschritt VP1 eine Initialisierung, bei der der Bearbeitungsanteil a_f auf 0 und der Abbruchzeitpunkt t_Abbruch auf unendlich gesetzt wird.
Im einem nachfolgenden ersten Entscheidungsschritt VE1 wird dann geprüft, ob sich im Watchdog-Stack ein aktiver Watchdog befindet.
Wenn bei der Abfrage festgestellt wird, dass ein Watchdog aktiv ist, also |S| > 0 ist, wird in einem zweiten Entscheidungsschritt VE2 geprüft, ob die aktuelle Zeit t_aktuell zeitlich vor dem Abbruchszeitpunkt t_Abbruch des obersten aktiven Watchdogs W_S im Watchdog-Stack liegt.
Wenn dies zutrifft, wird in einem zweiten Programmschritt VP2 die Abbruchszeitpunkt t_Abbruch auf den Abbruchszeitpunkt t_Abbruch des obersten aktiven Watchdogs W_S festgelegt.
Anschließend wird dann der Vision-Algorithmus VA des Vision-Funktionselements VisionFunktion ausgeführt. Dabei wird am Ende jeder Schleife des Vision-Algorithmus die jeweilige Schleifenbedingung im Entscheidungsschritt VA1 überprüft. Gleichzeitig wird fortlaufend die aktuellen Zeit t_aktuell mit dem Abbruchszeitpunkt t_Abbruch verglichen. Der Vision-Algorithmus wird so lange ausgeführt, bis eine Schleifenbedingung erfüllt ist oder die aktuelle Zeit dem Abbruchzeitpunkt entspricht.
Wenn der aktive Watchdog ein präemptiver Watchdog ist, wird bei Überschreiten des Abbruchszeitpunktes durch die Funktionslaufzeit des Vision-Algorithmus VA eine Abbruchsfunktion aufgerufen, um den Vision-Algorithmus VA abzubrechen. Bei einem kooperativen Watchdog als aktiver Watchdog ist der Programmcode des Vision-Algorithmus VA um eine Zusatzbedingung erweitert. Die Zusatzbedingung vergleicht im Entscheidungsschritt VA1 die aktuellen Zeit t_aktuell mit dem Abbruchszeitpunkt t_Abbruch am Ende jeder Bearbeitungsschleife. Wird bei der Überprüfung festgestellt, dass der Abbruchszeitpunkt überschritten ist, wird die Bearbeitungsschleife verlassen und der Vision-Algorithmus VA so kontrolliert beendet.
Wenn die Ausführung des Vision-Algorithmus VA des Vision-Funktionselements VisionFunktion beendet ist, wird in einem dritten Entscheidungsschritt VE3 erneut geprüft, ob sich im Watchdog-Stack ein aktiver Watchdog befindet.
Falls dies der Fall ist, wird in einem dritten Programmschritt VP3 der Bearbeitungsanteil a_f des Vision-Funktionselements VisionFunktion bestimmt. Die Berechnungsvorschrift wird vom Vision-Algorithmus VA vorgeben, wobei beispielsweise die Gleichungen (2), (3) oder (4) herangezogen werden können.
Der Bearbeitungsanteil a_f wird dann in einem vierten Programmschritt VP4 mit den im Watchdog-Stack akkumulierten Bearbeitungsanteilen verrechnet, um den Bearbeitungsanteil für die gesamten Vision-Funktion bestimmen zu können, wobei beispielsweise die Gleichungen (8) oder (9) herangezogen werden können. Anschließend wird dann der Programmablauf des Befehls VisionFunktion () beendet.
Wenn im ersten Entscheidungsschritt VE1 festgestellt wird, dass kein Watchdog aktiv ist, also |S| = 0 ist, wird direkt zur Ausführung des Vision-Algorithmus VA des Vision-Funktionselements VisionFunktion übergegangen. Da dann keine Zeitüberwachung mit einem Watchdog ausgeführt wird, bleibt der ursprünglich initialisierte Abbruchzeitpunkt auf unendlich stehen und nur die Schleifenbedingung wird bei der Ausführung überprüft.
Wenn im zweiten Entscheidungsschritt VE2 festgestellt wird, dass die aktuelle Zeit t_aktuell zeitlich nach dem Abbruchszeitpunkt t_Abbruch des obersten aktiven Watchdogs W_S im Watchdog-Stack liegt, wird der Vision-Algorithmus VA des Vision-Funktionselements VisionFunktion nicht ausgeführt und der Programmablauf mit dem vierten Programmschritt VP4 fortgesetzt. Der initialisierte Bearbeitungsanteil a_f = O wird dann mit dem im Watchdog-Stack akkumulierten Bearbeitungsanteilen verrechnet und anschließend der Programmablauf des Befehls VisionFunktion () beendet.
Wenn im dritten Entscheidungsschritt VE3 festgestellt wird, dass im Watchdog-Stack kein weiterer aktiver Watchdog enthalten ist, zweigt das Programm ab und der Programmablauf des Befehls VisionFunktion () wird sofort beendet.
6 zeigt beispielhaft für den Befehl (n, a, Δt_Rest, err) = StoppeWatchDogTypA() den Programmablauf, mit dem der Watchdog W vom Watchdog Typ A wieder beendet wird. Der Befehl (n, a, Δt_Rest, err) = StoppeWatchDogTypA() wird nach dem Befehl VisionFunktion (), dessen Programmablauf in 5 gezeigt ist, aufgerufen.
In einem ersten Entscheidungsschritt EE1 wird überprüft, ob sich ein zu beendender Watchdog im Watchdog-Stack befindet.
Wenn bei der Abfrage festgestellt wird, dass ein Watchdog im Watchdog-Stack aktiv ist, wird in einem zweiten Entscheidungsschritt EE2 geprüft, ob es sich um einen Watchdog vom Typ A handelt.
Wenn festgestellt wird, dass der im Watchdog-Stack aktive Watchdog W_s solch ein Watchdog vom Typ A ist, wird der Watchdog in einem ersten Programmschritt EP1 aus dem Stack entfernt.
In einem zweiten Programmschritt EP2 wird dann die Datenstruktur des aus dem Stack entfernten Watchdogs W aktualisiert. Der Bearbeitungsanteil a wird dabei auf den Wert gesetzt, der im vierten Programmschritt VP4 des Programmablaufs des Befehls VisionFunktion () bestimmt wurde, wie es anhand von 5 beschrieben wurde. Die Restzeit Δt_Rest wird mit der Gleichung (5) ermittelt, welche die Zeitdifferenz von aktueller Zeit t_aktuell zu Abbruchszeitpunkt t_Abbruch bestimmt.
Wenn es sich beim Watchdog W um einen präemptiven Watchdog handelt, wird in einem dritten Programmschritt EP3 dann noch die Abbruchsfunktion entfernt.
Anschließend wird in einem dritten Entscheidungsschritt EE3 geprüft, ob nach Entfernen des Watchdogs W noch weitere Watchdogs im Watchdog-Stack liegen.
Wenn im dritten Entscheidungsschritt EE3 festgestellt wird, dass weitere Watchdogs im Watchdog-Stack aktiv sind, also |S| > 0 ist, wird in einem vierten Programmschritt EP4 die akkumulierte Restzeit Δt _Rest für den Watchdog W auf die im zweiten Programmschritt EP2 ermittelte Restzeit Δt_Rest festgestellt.
In einem fünften Programmschritt EP5 wird dann vom Watchdog W die Anzahl akkumulierter Funktionselemente W.n, der akkumulierten Bearbeitungsanteil W.a und die akkumulierte Restzeit W.Δt _Rest auf den obersten sich im Watchdog-Stack befindenden aktiven Watchdog W_S propagiert.
Anschließend wird in einem sechsten Programmschritt EP6 ein Fehlercode err = 0 gesetzt, um anzuzeigen, dass kein Fehler bei der Programmausführung aufgetreten ist.
Wenn im ersten Entscheidungsschritt EE1 festgestellt wird, dass kein Watchdog im Watchdog-Stack aktiv ist, also |S| = 0, zweigt das Programm ab und setzt in einem siebten Programmschritt EP7 ein Fehlercode err = 1, um anzuzeigen, dass ein Fehler beim Watchdog-Stop aufgetreten ist.
Wenn im zweiten Entscheidungsschritt EE2 festgestellt wird, dass der im Watchdog-Stack oben liegende aktive Watchdog W_s kein Watchdog vom Typ A ist, wird der Programmablauf ebenfalls mit dem siebten Programmschritt EP7 fortgesetzt, der den Fehlercode err auf 1 setzt, um einen Ausführungsfehler anzuzeigen.
Wenn im dritten Entscheidungsschritt EE3 festgestellt wird, dass kein Watchdog im Watchdog-Stack mehr aktiv ist, also |S| = 0, wird anschließend der sechste Programmschritt EP6 ausgeführt und ein Fehlercode err = 0 gesetzt.
Nach dem sechsten Programmschritt EP6, der den Fehlercode err = 0 setzt, oder dem siebten Programmschritt EP7, bei dem der Fehlercode err = 1 festgelegt wird, wird der Programmablauf des Befehls (a, Δt_Rest, err) = StoppeWatchDogTypA() beendet.
7 zeigt ein Beispiel für die Propagierung der Restzeit in einem Watchdog-Stack mit fünf Watchdogs 701 bis 705, die auf drei Hierarchieebenen 1, 2, 3 verteilt sind, wobei zu einem Zeitpunkt auf jeder Hierarchieebene höchstens ein Watchdog aktiv ist. In der Darstellung in 7 sind die drei Hierarchieebenen 1, 2, 3 auf der Y-Achse eingetragen. In der hierarchisch tiefsten Hierarchieebene 1 befindet sich der Watchdog 701. In der nächst höheren Hierarchieebene 2 sind der Watchdog 702, der Watchdog 703 und der Watchdog 705 angeordnet. Auf der obersten Hierarchieebene 3 liegt der Watchdog 704.
Auf der X-Achse in 7 ist die zeitliche Abfolge der fünf Watchdogs 701 bis 705 im Watchdog-Stack angezeigt. Die Nummerierung der Watchdogs entspricht dabei dem Startzeitpunkt des jeweiligen Watchdogs. Der Pfeil von der tieferen Hierarchieebene zu der nächst höheren Hierarchieebene zeigt jeweils den Aufruf des Watchdogs an. Der Pfeil von der höheren Hierarchieebene zu der nächst tieferen Hierarchieebene zeigt das Beenden des Watchdogs an.
Der sich in der Hierarchieebene 1 befindende Watchdog 701 startet zum Zeitpunkt 0ms und beendet seine Ausführung zum Zeitpunkt 100ms. Der sich in der Hierarchieebene 2 befindende Watchdog 702 startet zum Zeitpunkt 10ms und beendet seine Ausführung zum Zeitpunkt 20ms. Der sich in der Hierarchieebene 2 befindende Watchdog 703 startet zum Zeitpunkt 40ms und beendet seine Ausführung zum Zeitpunkt 70ms. Der sich in der Hierarchieebene 2 befindende Watchdog 705 startet zum Zeitpunkt 80ms und beendet seine Ausführung zum Zeitpunkt 90ms. Der sich in der Hierarchieebene 3 befindende Watchdog 704 startet zum Zeitpunkt 50ms und beendet seine Ausführung zum Zeitpunkt 60ms.
Die fünf Watchdogs 701 bis 705 sind jeweils Zeitspannen-Watchdogs, wobei in 7 die tatsächliche Laufzeit des Watchdogs, die sich aus den angegebenen Start- und Stop-Zeiten ergibt und die durch die Funktionslaufzeit der zugeordneten zu überwachenden Funktionselemente bestimmt wird. Der Watchdog 702 hat eine Abbruchszeitspanne von 15ms, der Watchdog 703 hat eine Abbruchszeitspanne von 11ms, der Watchdog 704 hat eine Abbruchszeitspanne von 37ms und der Watchdog 705 hat eine Abbruchszeitspanne von 18ms. Es bleiben somit Restzeiten für den Watchdog 702 von 5ms, für den Watchdog 703 von 7ms, für den Watchdog 704 von 1ms und für den Watchdog 705 von 8ms.
Wenn eine Propagierung der Restzeit zum Beispiel zum Zeitpunkt 65 ms, der als gestrichelte Linie in 7 angezeigt ist, durchgeführt werden soll, ergibt sich auf der Hierarchieebene 3 eine Zeitersparnis durch den Watchdog 704 von 1ms und auf der darunter liegenden Hierarchieebene 2 eine Zeitersparnis von 5ms durch den Watchdog 702, sodass bei einer Restzeitpropagierung zum Zeitpunkt 65ms die akkumulierte Restzeit 6ms beträgt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

EP 2568346 B1 [0005]
DE 10243856 B4 [0006]
DE 102009055752 A1 [0007]
EP 1312990 A2 [0015]

Claims

Echtzeitumgebung, in der wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt wird, wobei wenigstens eine Funktion innerhalb der vorgegebenen Task-Laufzeit abgearbeitet werden soll, mit den Schritten: Starten einer Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Funktion innerhalb der vorgegebenen Task-Laufzeit festlegt, Ausführen der Funktion, wobei die Zeitüberwachungsfunktion die Funktionslaufzeit überwacht und bei Überschreiten des vorgegebenen Abbruchszeitpunktes ein Funktionsabbruch veranlasst wird, und Beenden der Zeitüberwachungsfunktion.
Echtzeitumgebung nach Anspruch 1, wobei eine Abbruchsfunktion vorgesehen ist, die bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit aufgerufen wird, um den Funktionsabbruch auszuführen.
Echtzeitumgebung nach Anspruch 1, wobei die Funktion eine Abbruchsbedingung umfasst, die bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit das Ausführen der Funktion abbricht und ein Bearbeitungsergebnis rückmeldet.
Echtzeitumgebung nach einem der Ansprüche 1 bis 3, wobei die Zeitüberwachungsfunktion den vorgegebenen Abbruchszeitpunkt beim Aufruf als Summe aus der aktuellen Zeit und einer maximal erlaubten Zeitspanne bestimmt.
Echtzeitumgebung nach einem der Ansprüche 1 bis 4, wobei die Zeitüberwachungsfunktion beim Beenden eine Kenngröße ausgibt, der den Anteil der erfolgten Funktionsausführung anzeigt.
Echtzeitumgebung nach Anspruch 5, wobei die Funktion eine Mehrzahl von Funktionselementen aufweist und wobei die beim Beenden der Zeitüberwachungsfunktion ausgegebene Kenngröße den akkumulierten Anteil der erfolgten Ausführung der Funktionselemente und/oder die Anzahl akkumulierter Funktionselemente angibt.
Echtzeitumgebung nach einem der Ansprüche 1 bis 6, wobei die Zeitüberwachungsfunktion beim Beenden einen Zeitwert ausgibt, der die Zeitdifferenz zwischen der aktuellen Zeit und dem vorgegebenen Abbruchszeitpunkt anzeigt.
Echtzeitumgebung nach einem der Ansprüche 1 bis 7, wobei die Zeitüberwachungsfunktion beim Beenden einen Fehlercode ausgibt, der einen Fehlerzustand bei der Ausführung der Zeitüberwachungsfunktion anzeigt.
Echtzeitumgebung nach einem der Ansprüche 1 bis 7, wobei die Zeitüberwachungsfunktion wenigstens ein untergeordnetes Zeitüberwachungsfunktionselement aufweist, das einen Abbruchszeitpunkt für eine zugeordnete Funktion innerhalb der vorgegebenen Task-Laufzeit vor dem Abbruchszeitpunkt der Zeitüberwachungsfunktion festlegt.
Echtzeitumgebung nach Anspruch 9, wobei die Zeitüberwachungsfunktion unter Verwendung eines Stacks verwaltet wird.
Speicherprogrammierbare Steuerung (3), die über einen Feldbus (4) mit Aktoren (2) und Sensoren (1) einer Produktionsanlage verbunden ist, wobei die speicherprogrammierbare Steuerung (3) eine Echtzeitumgebung nach einem der Ansprüche 1 bis 10 umfasst, deren Task zum Steuerung von Aktoren (2) und Sensoren (1) dient, wobei die Ausführung der Funktion durch die Zeitüberwachungsfunktion mit der Steuerung synchronisiert ist.
Speicherprogrammierbare Steuerung (3) nach Anspruch 11, die mit einer Funktionseinheit (6) zur Bilderfassung verbunden ist, um deren Bilddaten in die Echtzeitumgebung zu übertragen, wobei die Funktion eine Vision-Funktion zur Verarbeitung und/oder Analyse der Bilddaten ist.