PROZESSPROGRAMMEN EINES VERTEILTEN ECHTZEITSYSTEMS AUF EINER VERTEILTEN ENTWICKLUNGSHARDWARE

Die Erfindung liegt im Bereich der Computertechnik. Sie betrifft eine verteilte Entwicklungshardware und ein Verfahren zur verteilten Entwicklung von Prozessprogrammen eines verteilten Echtzeitsystems, insbesondere eines umfangreichen verteilten Echtzeitsystems, wobei eine gegebene Aufgabenstellung in eine Vielzahl von parallel ablauffähigen Prozessen aufgeteilt ist, deren Abhängigkeiten in Form eines markierten Prozessgraphen dargestellt sind, und wobei für jeden Prozess eine funktionale Prozessspezifikation vorliegt, und wobei für die Ausführung von jedem Prozess eine Maximalanzahl von Instruktionen Nwc auf der Zielhardware vorgegeben ist.

Im Rahmen der Entwicklung eines Echtzeitsystems muss ein Hardware/ Softwaresystem erstellt werden das vorgegebene funktionale Eigenschaften innerhalb spezifizierter Echtzeitschranken realisiert.

In vielen Projekten der Echtzeitverarbeitung wird zwischen der Zielhardware (ZHW) und der Entwicklungshardware (EHW) unterschieden. Der Begriff Zielhardware bezieht sich auf die Hardwareumgebung, die in einem geplanten Produkt zum Einsatz kommt. Um die Produktkosten zu minimieren, wird die Zielhardware nur die für das fertige Produkt absolut notwendigen Funktionen unterstützen. Der Begriff Entwicklungshardware bezieht sich auf die Hardwareumgebung, die im Rahmen der Systementwicklung verwendet wird. Um die Programmentwicklung zu erleichtern, unterstützt die Entwicklungshardware normalerweise wesentlich mehr Funktionen als die Zielhardware, z.B. zusätzliche Funktionen zur interaktiven Simulation des Ablaufs der Programme. Normalerweise ist die Entwicklungshardware, gemessen in ausführbaren Instruktionen/Zeiteinheit, wesentlich leistungsfähiger als die Zielhardware.

Entsprechend dem Stand der Technik wird die Entwicklung eines umfangreichen Echtzeitsystems in einem Drei-Phasen-Verfahren durchgeführt. In der ersten Phase, dem Architekturentwurf, wird die gegebene Aufgabenstellung in eine Anzahl von Komponenten unterteilt. Die Ausführung der Software einer Komponente bezeichnet man als einen Prozess. Im Rahmen des Architekturentwurfs wird für jeden Prozess eine funktionale Prozessspezifikation erstellt.

Eine funktionale Prozessspezifikation umfasst die Syntax und Semantik der Eingabedaten, die Syntax und Semantik der Ausgabedaten und die Syntax und Semantik des inneren Zustandes des Prozesses, sowie einen Algorithmus, der beschreibt, wie ein Prozessprogramm aus den Eingabedaten und dem anfänglichen inneren Zustand die Ausgabedaten und den nächsten inneren Zustand zu errechnen hat. Die kausalen Abhängigkeiten der Prozesse werden mittels eines Prozessgraphen veranschaulicht. Die Prozesse bilden die Knoten des Prozessgraphen, während die Kanten des Prozessgraphen den Datenfluss, d.i. den Fluss von Nachrichten, zwischen den Prozessen darstellen. Ein Prozess B ist dabei kausal abhängig von einem Prozess A, wenn das Ergebnis von Prozess A den Ablauf und damit das Resultat von Prozess B beeinflussen kann.

In der zweiten Phase der Systementwicklung, der Programmierphase, werden aus den funktionalen Prozessbeschreibungen die Prozessprogramme entwickelt und auf der Entwicklungshardware individuell getestet. Eine funktionale Prozessbeschreibung ist die Dokumentation, die das beabsichtigte beobachtbare Ergebnis eines Prozesses festlegt. Sie legt nicht fest, wie dieses beobachtbare Ergebnis durch den Aufbau und den Ablauf der Programme im inneren eines Prozesses realisiert wird.

In der dritten Phase der Systementwicklung, der Integrationsphase, werden die in der zweiten Phase entwickelten Prozessprogramme integriert und gemeinsam getestet. Erfahrungsgemäß erfordert die Integrationsphase einen hohen Aufwand, da entsprechend dem gegenwärtigen Stand der Technik wesentliche temporale Randbedingungen der Zielhardware erst im Rahmen der Integrationsphase erkannt werden. In mehrfachen Iterationen müssen dann die Prozessprogramme modifiziert werden, um erkannte temporale Randbedingungen der Zielhardware zu respektieren.

Es ist eine Aufgabe der vorliegenden Erfindung, die parallele Entwicklung und Integration der Prozessprogramme eines Echtzeitsystems, insbesondere eines umfangreichen Echtzeitsystems, signifikant zu verbessern. Ein umfangreiches Echtzeitsystem liegt vor, wenn eine Vielzahl (insbesondere mehr als 10) Entwickler gleichzeitig an dem System arbeiten müssen, um es bis zu einem vorgegebenen Termin fertig zu stellen.

Es ist daher vorgesehen, dass im Rahmen der Softwareentwicklung eines umfangreichen verteilten Echtzeitsystems für jeden Prozess eine maximale Prozessdauer dwcE auf der Zielhardware aus NW A-ZH errechnet wird, wobei LZH die Leistungsfähigkeit der Zielhardware (in Instruktionen/Zeiteinheit) angibt, und aus LID = A/Lc die Übertragungsdauer LID der Ausgabedaten A (gemessen in Bytes) von einem vorgelagerten Prozess zu einem nachgelagerten Prozess auf der Zielhardware errechnet wird, wobei Lc die Leistungsfähigkeit des Kommunikationssystems in (Bytes / Zeiteinheit) angibt, und wobei jeder Prozess des Prozessgraphen mit seiner Prozessdauer dwcE auf der Zielhardware annotiert wird, und wobei jede Kante des Prozessgraphen mit der Übertragungsdauer LID auf der Zielhardware annotiert wird, und wobei, ausgehend von einem Anfangszeitpunkt eines Startknotens, den beispielsweise der Zeitpunkt t=0 zugewiesen ist, jeder Markierung des Prozessgraphen der Zeitpunkt zugewiesen wird, der sich durch Addition der Prozessdauern und Übertragungsdauern auf dem Pfad von dem Startknoten bis zu dieser Markierung ergibt, wobei im Falle, dass mehrere Pfade zur gleichen Markierung führen, der jeweils größte Zeitpunkt gewählt wird.

Die Entwicklung eines Prozessprogramms auf der Basis der funktionalen Prozessspezifikation und den aus dem Prozessgraphen ermittelten Zeitpunkten der Anfangs-Markierung und End- Markierung des Prozesses kann auf einem Entwicklungssystem unabhängig von der Entwicklung jedes anderen Prozessprogramms erfolgt.

Nach Fertigstellung der Prozessprogramme wird die Integration der Prozessprogramme in das Gesamtsystem vorgenommen. Dies wird mit der eingangs erwähnten Vorrichtung dadurch gelöst, dass eine verteilte Entwicklungshardware EHW aufgebaut wird, die isomorph mit der verteilten Zielhardware ZHW ist.

Die Zielhardware (ZHW) eines verteilen Echtzeitsystems besteht aus einer Anzahl von für die gegebene Aufgabenstellung kostenoptimierten Komponenten, die über ein Kommunikationssystem Nachrichten austauschen. Wenn in einem verteilten Echtzeitsystem periodische zeitkritische Nachrichten zwischen den Komponenten ausgetauscht werden, so sind im Zeitplan eines zeitgesteuerten Kommunikationssystem der Zielhardware die periodisch wiederkehrenden Zeitpunkte, vor denen eine zeitkritische Nachricht von einer Komponente beim Kommunikationssystem eintreffen muss, bestimmt. Diese Zeitpunkte können aus dem oben beschriebenen annotierten Prozessgraphen abgeleitet werden.

Das isomorphe zeitgesteuerte Kommunikationssystem der Entwicklungshardware (EHW) enthält den gleichen Zeitplan wie das Kommunikationssystem der ZHW. Die leistungsfähigen Komponenten der EHW müssen daher zu den gleichen Zeitpunkten die Nachrichten an das Kommunikationssystem der EHW übergeben wie in der ZHW. Damit wird sichergestellt, dass das temporale Verhalten der EHW dem temporalen Verhalten des ZHW entspricht. Da die EHW leistungsfähiger ist als die kostenoptimierte ZHW, ist die rechtzeitige Bereitstellung der Resultate auf der EHW kein Problem.

Die Lösung der vorliegenden Aufgabe wird mit der erfindungsgemäßen Vorrichtung also dadurch gelöst, dass wesentliche temporale Randbedingungen der Zielhardware frühzeitig ermittelt und bereits beim Aufbau der Entwicklungshardware berücksichtigt werden.

Durch den Entfall der mehrfachen Iterationen in der Integrationsphase werden der Entwicklungsaufwand und die Dauer des Entwicklungsprozesses wesentlich reduziert.

Bevorzugte Ausführungsformen des erfindungsgemäßen Verfahrens, welche für sich alleine oder in beliebiger Kombination miteinander realisiert sein können, sind im Folgenden beschrieben:

*) ein Prozessprogramm wird in Form eines Anytime Algorithmus realisiert;

*) auf einem Entwicklungssystem läuft ein Simulationsprogramm ab, das zum Zeitpunkt der Anfangs-Markierung eines Prozesses die Eingabedaten für den Prozess bereitstellt und zum Zeitpunkt der End-Markierung des Prozesses die Ausgabedaten übernimmt und überprüft, ob die vom Prozess errechneten Ausgabedaten korrekt sind;

*) mehrere Entwicklungssysteme kommunizieren über ein zeitgesteuertes Netzwerk, dessen Zeitverhalten der Zielhardware entspricht, und wobei die Entwicklungssysteme entsprechend der Topologie eines Teils oder des gesamten Prozessgraphen vernetzt sind, und wobei ein Prozess zum Zeitpunkt seiner End-Markierung die Ausgangsdaten an das zeitgesteuerte Kommunikationssystem übergibt und das Kommunikationssystem zum Zeitpunkt der Anfangs-Markierung des folgenden Prozesses die Daten für den folgenden Prozess bereitstellt;

*) der gesamte Prozessgraph wird durch eine Anzahl von Entwicklungssystemen nachgebildet, die über ein zeitgesteuertes Kommunikationsnetz kommunizieren, und wobei die Daten der Prozesse entsprechend der Topologie des Prozessgraphen von einem Prozess an die Folgeprozesse übertragen werden, und wobei zwischen einer Endmarkierung eines Terminie- rungsknotens und einer Anfangsmarkierung der Startknoten des Prozessgraphen ein Simulationsmodell einer zu regelnden Produktionsanlage eingebunden wird.

Im Folgenden ist die Erfindung an Hand der Zeichnung an Hand einer beispielhaften Realisierung näher erörtert. Es zeigt

Fig. 1 die Komponenten eines beispielhaften verteilten Echtzeitsystems, die über ein zeitgesteuertes Kommunikationssystem Nachrichten austauschen, und

Fig. 2 einen einfachen Prozessgraphen einer konkreten beispielhaften Anwendung.

Das folgende konkrete Beispiel zeigt eine der vielen möglichen Realisierungen der neuen Vorrichtung und des neuen Verfahrens. In diesem konkreten Beispiel wird ein System zur Erkennung des Umfeldes und Aktivierung der Notbremsung eines autonomen Fahrzeugs dargestellt und die Erfindung in diesen Zusammenhang erläutert.

Fig. 1 zeigt die Systemstruktur der gegebenen Anwendung, d.h. die relevanten Komponenten der Zielhardware. Der für die gegenwärtige Betrachtung relevante Teil des Systems besteht aus den fünf Komponenten 110, 120, 130, 140 und 150, sowie einem zeitgesteuerten Kommunikationssystem 160, über das die Kommunikation zwischen den fünf Komponenten abgewickelt wird.

In der Architekturphase wird die gegebene Aufgabenstellung auf die fünf Komponenten der Zielhardware aufgeteilt. Die Komponente 110 verfügt über eine Kamera, die das Umfeld des Fahrzeugs 100 beobachtet. Die Komponente 110 nimmt periodisch ein Bild des Umfelds auf und führt die Vorverarbeitung der erfassten Rohdaten, die Perzeption, durch, um charakteristische Merkmale, wie Kanten und Flächen im erfassten Bild zu erkennen. Die vorverarbeiteten Daten werden über die zeitgesteuerte Nachrichtenverteilereinheit 160 an die Komponenten 130 und 140 übertragen. Die Komponente 130 realisiert einen speziellen Algorithmus, um in den von Komponente 110 erhaltenen vorverarbeiteten Daten Verkehrszeichen zu erkennen, und sendet die erkannten Verkehrszeichen über die zeitgesteuerte Nachrichtenverteilereinheit 160 an die Komponente 150. Die Komponente 120 ist mit einem Radarsystem ausgestattet, um den Abstand zu Objekten in der Umgebung 100 des autonomen Fahrzeugs zu ermitteln. Die Komponente 120 erfasst periodisch Radarsignale und führt die Vorverarbeitung der erfassten Rohdaten durch, um die Entfernung zu den erfassten Objekten zu ermitteln. Die vorverarbeiteten Daten werden über die zeitgesteuerte Nachrichtenverteilereinheit 160 an die Komponente 140 übertragen. Die Komponente 140 fusioniert mittels eines Fusionsalgorithmus die von den Komponenten 110 und 120 erhaltenen Daten, um ein dreidimensionales Bild der Umgebung des Fahrzeugs mit den Entfernungen zu den erkannten Objekten aufzubauen. Dieses Bild wird über die zeitgesteuerte Nachrichtenverteilereinheit 160 an die Komponente 150 übertragen, um das Bild mit den erkannten Verkehrszeichen zu annotieren. Am Ende dieser Verarbeitungsfolge verfügt die Komponente 150 über eine Datenstruktur, die das Umfeld des Fahrzeuges einschließlich der erkannten Objekte und Verkehrszeichen beschreibt. Die Komponente 150 verfügt über einen Algorithmus, der aus dieser Datenstruktur den notwendigen Bremsdruck errechnet.

Im Folgenden wird ein erfindungsgemäßes Verfahren zur verteilten Entwicklung der Prozessprogramme eines oben beschriebenen Echtzeitsystems auf einer verteilten Entwicklungshardware näher beschrieben.

Ein Prozessprogramm umfasst die Anweisungen an die Hardware einer Komponente, die angeben, wie die beabsichtigten Ergebnisse aus den gegebenen Eingangsdaten zu errechnen sind. Die Ausführung eines Prozessprogramms, d.h. die Ausführung der Software einer Komponente, bezeichnet man als einen Prozess. Ein Prozess beginnt zu einem Anfangszeitpunkt und endet zu einem Endzeitpunkt.

Nach Festlegung der Systemstruktur wird für jede der fünf Komponenten eine funktionale Prozessspezifikation erstellt. Die kausalen Abhängigkeiten der Prozesse, werden mittels eines Prozessgraphen veranschaulicht. Ein Prozessgraph besteht aus Knoten (d.s. die Kreise), die die Bearbeitung der Daten durch den auf der Komponente ablaufenden Prozess darstellen, und Kanten (d.s. die gerichteten Linien zwischen den Knoten,) die den Transport der Daten von einem vorgelagerten Knoten zu einem nachgelagerten Knoten darstellen. Wenn den Knoten und/ oder Kanten eines Prozessgraphen Attribute zugeordnet werden, so bezeichnet man dies als eine Annotation des Prozessgraphen.

Die Markierung eines Knotens (eine Form der Annotation), z.B. des Knotens 210, gibt an, wann der auf dem Knoten 110 ablaufende Prozess 210 beginnt (Markierung 211) bzw. endet (Markierung 212).

Erfindungsgemäß haben der Prozessgraph der Zielhardware und der Prozessgraph der Entwicklungshardware die gleiche Form.

Fig. 2 zeigt einen Prozessgraphen der beschriebenen Anwendung bestehend aus fünf Knoten 210, 220, 230, 240, und 250, die über Kommunikationskanäle 215, 216, 225, 235 und 245 miteinander verbunden sind. Der Knoten 210 übernimmt die Daten von einer angeschlossenen Kamera. Der Knoten 210 übergibt die vorverarbeiteten Daten über den Kanal 216 an den Knoten 230 und über den Kanal 215 an den Knoten 240. An den Knoten 220 ist das Radarsystem angeschlossen, um den Abstand zu Gegenständen in der Umgebung des autonomen Fahrzeugs zu ermitteln. Diese Rohdaten werden im Knoten 220 vorverarbeitet und über den Kanal 225 an den Knoten 240 weitergeleitet. Der Knoten 240 führt eine Datenfusion durch, um aus den Daten der Kamera und den Daten des Radarsystems ein Modell der Umgebung des Fahrzeugs zu erstellen, und teilt dieses Modell über den Kanal 245 dem Knoten 250 mit. Der Knoten 230 erkennt die Verkehrszeichen und teilt sie über den Kanal 235 dem Knoten 250 mit. Der Knoten 250 berechnet aus den empfangenen Daten den neuen Sollwert für die Bremskraft.

Die Zuordnung der Prozesse der Fig. 2 zu den Komponenten der Fig. 1 ergibt sich aus der folgenden Tabelle:

Tab. 1: Zuordnung von Prozessen zu Komponenten Die Algorithmen zur Erkennung des Umfelds eines autonomen Fahrzeugs müssen innerhalb einer vorgegebenen Zeit ein brauchbares (jedoch nicht notwendigerweise ein optimales) Ergebnis liefern. In diesem Bereich der Artificial Intelligence haben Anytime Algorithmen eine besondere Bedeutung [3] erlangt. Da die Dauer einer Berechnung durch einen Algorithmus in vielen kognitiven Anwendungen stark von der Struktur der Eingabedaten abhängt, kann das Finden einer optimalen Lösung lange dauern. Ein brauchbares Ergebnis, das rechtzeitig vorliegt, ist in vielen Anwendungen von größerem Wert als ein optimales Ergebnis, das später bereitgestellt wird.

Ein Anytime Algorithmus ist ein Algorithmus, der aus einem Wurzelsegment, das einmal durchlaufen wird und einem iterativen Segment, das normalerweise mehrfach durchlaufen wird, besteht [4, p.246]. Nach Durchlaufen des Wurzelsegments wird ein erstes grobes Resultat bereitgestellt, das mit jedem Durchlauf des iterativen Segments verbessert wird. Im Rahmen einer theoretischen Analyse und von experimentellen Messungen eines Anytime Algorithmus wird festgestellt, wieviele Instruktionen im Durchschnittsfall NAvg und im Maximal (Worst Case) Fall Nwc erforderlich sind, um das Wurzelsegment zu durchlaufen und ein erstes brauchbares Ergebnis zu liefern. Im Normalfall ist die Anzahl der Befehle NAvg viel kleiner als die Anzahl der Befehle Nwc-

Über die bekannte Leistungsfähigkeit der Zielhardware, gemessen in Instruktionen pro Sekunde LZH, kann nun die Zeitdauer dwcz, die erforderlich ist, um in jedem Fall das Wurzelsegment des gewählten Anytime Algorithmus abzuschließen, wie folgt errechnet werden

Diese Zeitdauer, die minimale Verarbeitungszeit dwcz des analysierten Anytime Algorithmus auf der Zielhardware, bildet eine untere Schranke für die Zuweisung der Rechenzeit auf der Zielhardware. Nach dieser Zeitdauer ist die Verfügbarkeit eines brauchbaren Resultats des Anytime Algorithmus sicher gestellt.

Da viele Algorithmen zur Bilderkennung und Bildverarbeitung in der beschriebenen Anwendung Anytime Algorithmen sind, ist bevorzugt vorgesehen, im Rahmen der Analyse der zur Anwendung gelangenden Algorithmen unter Kenntnis der Leistungsfähigkeit der Zielhardware die minimale Verarbeitungszeit dwcz für jeden der Prozesse 211, 221, 231, 241 und 251 bereits in der Architekturphase der Systementwicklung zu errechnen.

Wenn in einem Projekt kein Anytime Algorithmus eingesetzt wird, so muss die Worst Case Exemtion Time (WCET) des gewählten Algorithmus auf der Zielhardware ermittelt werden. Ein Überblick über gängige Verfahren zur Ermittlung der WCET eines Algorithmus findet sich in [5].

Im Prozessgraph von Fig. 2 sind der Anfangszeitpunkt und der Endzeitpunkt jedes Prozesses eingetragen, d.h. der Prozessgraph ist mit den Anfangszeitpunkten und den Endzeitpunkten der Prozesse markiert. Die Markierung des Prozessgraphen errechnet sich wie folgt: Die Anfangszeitpunkte der Startknoten 210 und 211 des Prozessgraphen der Fig. 2 werden a priori mit t = 0 festgelegt. Die Endzeitpunkte 212 und 222 ergeben sich aus der Summe der jeweiligen Anfangszeitpunkte und der Verarbeitungszeit dwz des jeweiligen Prozesses auf der Zielhardware. Diese Endzeitpunkte 212 und 222 legen auch den frühesten Zeitpunkt fest, zu dem das zeitgesteuerte Kommunikationssystem 160 der Zielhardware die Daten übernehmen kann. Die Übertragungsdauer UD der Ausgabedaten 216 vom Prozess 210 zum Prozess 230 errechnet sich aus der Bytelänge A der Ausgabedaten des Prozesses 210 an den Prozess 230 und der Leistungsfähigkeit Lc des Kommunikationssystems, gemessen in Bytes/ Sekunde, wie folgt:

UD = A/Lc.

Die Summe des Endzeitpunktes 212 und der Übertragungsdauer UD (216) ergibt den Startzeitpunkt 231 des Prozesses 230. Wenn ein Prozess Eingangsdaten von zwei vorgelagerten Prozessen empfängt, z.B. der Prozess 240 erhält Eingangsdaten vom Prozess 210 und vom Prozess 220, so wird der größere der beiden errechneten Zeitpunkte als Startzeitpunkt des Prozesses 240 genommen. Das beschriebene Berechnungsverfahren wird schrittweise angewendet, bis das Ende des Prozessgraphen, d.i. im gegebenen Fall der Zeitpunkt 252 von Prozess 250 erreicht wird. In der Folge wird jeder Prozess des Prozessgraphen (d.s. die Knoten) mit der Rechenzeit des Prozesses, d.i. die Differenz zwischen dem Endzeitpunkt und dem Anfangszeitpunkt des Prozesses, und jede Kante mit der Übertragungszeit, das ist die Differenz zwischen dem Endzeitpunkt des vorgelagerten Prozesses und dem Anfangszeitpunkt des nachgelagerten Prozesses annotiert. In der zweiten Phase des Systementwurfs, der Programmierphase, werden die den Prozessen auf der Entwicklungshardware bereitgestellten Verarbeitungszeiten dwcE entsprechend der Formel berechnet, wobei Nwc die Maximalanzahl (Worst Case) der notwendigen Instruktionen z.B. für das Wurzelsegment des Anytime Algorithmus angibt und LEH die bekannte Leistungsfähigkeit der Entwicklungshardware in Instruktion pro Sekunde angibt. Um sicherzustellen, dass im Entwicklungssystem der iterative Teil eines Anytime Algorithmus gleich oft ausgeführt wird wie im Zielsystem, wird jeder Prozess im Entwicklungssystem nach seinem Zeitintervall dwcE unterbrochen. Das Zeitintervall dwcz- dwcE verbringt das Entwicklungssystem im Wartezustand. Durch diese Maßnahmen wird gewährleistet, dass die temporale Struktur des Entwicklungssystems identisch ist mit der temporalen Struktur des Zielsystems. Es können somit die einzelnen Prozesse unabhängig voneinander auf verschiedenen Entwicklungssystemen parallel entwickelt werden, wobei die temporale Struktur des Zielsystems erhalten bleibt.

Wenn die unabhängigen Entwicklungssysteme mit einem zeitgesteuerten Kommunikationssystem, dessen Zeitpläne den Parametern des Zielsystems entsprechen, verbunden werden, so kann eine verteilte Simulation des Gesamtsystems auf den verteilten Entwicklungssystemen unter den gleichen temporalen Bedingungen wie im Zielsystem realisiert werden. Damit lassen sich die Prozesse schrittweise im Entwicklungssystem integrieren. So können zum Anfangszeitpunkt eines Prozesses die Eingabedaten für den Prozess von einem Simulationsprogramm bereitgestellt und zum Endzeitpunkt des Prozesses die Ausgabedaten übernommen und überprüft werden, ob die vom Prozess errechneten Ausgabedaten korrekt sind.

In weiterer Folge kann das Simulationsprogramm durch eine zu steuernde Produktionsanlage (Hardware in the Loop) ersetzt und überprüft werden, ob das Gesamtsystem, bestehend aus der Produktionsanlage und dem verteilten Echtzeitsystem das beabsichtigte Verhalten zeigt.

Zitierte Dokumente:

[1] US 8,533,658. Patten, et al. System and Methodfor Teaching Software Development Processes. Granted Sept. 10, 2013. [2] US8340,363. Sarkar, et al. System and Methodfor efficient Interpretation of Images in terms of objects and their parts. Granted Dec. 25, 2012.

[3] Zilberstein, S., Using Anytime Algorithms in Intelligent Systems. Artificial Intelligence Magazine, Vol.17. No. 3. 1996.

[4] Kopetz, H., Real-time Systems-Design Principles for Distributed Embedded Applications. Springer Verlag, 2011.

[5] Wilhelm, R. et al. (2008). The Worst-Case Execution Time Problem— Overview of Methods and Survey of Tools. ACM Trans, on Embedded Computer Systems, Vol. 7(3). (pp. 1-53).