DE102011076821A1

DE102011076821A1 - Simulation von Echtzeitsystemen unter Ausnutzung vonAufrufstellen (Access Points)

Info

Publication number: DE102011076821A1
Application number: DE102011076821A
Authority: DE
Inventors: Stefan Resmerita; Prof. Dr. Pree Wolfgang
Original assignee: Wolfgang Pree GmbH
Current assignee: Wolfgang Pree GmbH
Priority date: 2011-05-31
Filing date: 2011-05-31
Publication date: 2012-12-06
Also published as: US20120310620A1

Abstract

Die Erfindung bezieht sich auf eine Methode zur Computer-basierten Simulation eines Echtzeitsystems. Ein solches Echtzeitsystem umfasst eine Anwendungs-Software, die auf einer Ziel-Hardware-Plattform (Hardware und Betriebssystem) auszuführen ist; und die Anwendungs-Software besteht aus zumindest zwei Tasks mit unterschiedlicher Priorität, und jede Task beinhaltet eine Menge von Anweisungen. In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung gehört die Definition von zumindest einem Access Point für jede Task zur Methode dazu, und zwar bei einer Anweisung, die eines der folgenden Punkte darstellt: – den Anfang einer Task, – das Ende einer Task, – einen Zugriff auf einen gemeinsamen Speicher (= Shared Memory), – einen Zugriff auf ein Register der Ziel-Hardware-Plattform, – einen Aufruf einer Betriebssystem-Funktion (Systemaufruf) oder einer Treiber-Funktion der Ziel-Plattform (Treiber-Funktions-Aufruf), wodurch die Tasks in aufeinanderfolgende Anweisungs-Blöcke aufgeteilt werden (die durch interne Access Points getrennt sind). Zur Methode gehört weiters die Zuweisung der Ausführungszeit auf der Zielplattform, also wie lange die Ausführung des Anweisungsblocks auf dem Zielsystem dauert (Ziel-Ausführungszeit = Target Execution Time), zu jedem Anweisungsblock. Eine diskrete Ereignissimulation wird unter Benutzung einer Ereignis-Warteschlange durchgeführt, wobei jedes Ereignis mit einer Task, dem Access Point einer Task, und einem Ereignis-Zeitstempel assoziiert ist. Während der Verarbeitung eines Ereignisses wird der Anweisungsblock, der dem Access Point, der mit dem Ereignis assoziiert ist, entspricht, ohne Unterbrechung ausgeführt.

Description

Technischer Kontext
Die vorliegende Erfindung bezieht sich auf das Gebiet der Simulation von Systemen, die strikte Echtzeitanforderungen erfüllen müssen (Echtzeitsysteme), insbesondere auf eine verbesserte Methode zur Software-im-[Regel-]Kreis (Software-in-the-Loop)-Simulation und ein System zur Simulation von Echtzeitsystemen.
Hintergrund
Echtzeitsysteme werden oft bei Regelungssystemen benutzt, um Regelungsgesetze zur Steuerung von technischen Prozessen zu implementieren. Bei vielen Anwendungen dieser Echtzeitsysteme inkludiert das verteilte Hardware, das heißt, dass die Software für verschiedene Funktionen, die für Regelungszwecke notwendig sind, auf verschiedenen Prozessoren ausgeführt wird. Bestehende Systeme zur Ausführung verteilter Software können eine Vielzahl von Knoten und einen Kommunikationskanal umfassen, wobei das System so konfiguriert wird, dass die Knoten Daten über den Kommunikationskanal übertragen können. Beispiele für solche Systeme sind unter anderem sogenannte eingebettete Systeme, bei denen die Knoten auch als elektronische Steuergeräte (Electronic Control Units, abgekürzt als ECU) bezeichnet werden. Eine ECU kann die Software-Funktionen ausführen und kann in das Gerät eingebettet sein, das es steuert. Beispiele für eingebettete Systeme sind Automobile, Automatisierungssysteme und Flugzeuge. Ein Automobil kann zum Beispiel aus einer Vielzahl von Geräten bestehen, die die Bremsen betätigen, einer Vielzahl von Geräten, die die Umdrehungszahl der Räder messen, einem Gerät, das die Geschwindigkeit misst, etc., und alle diese Geräte kommunizieren über einen Kommunikationskanal und sind so konfiguriert, dass sie die Funktionalität eines Anti-Blockiersystems (ABS) erfüllen. Da die Funktionalität eines Anti-Blockiersystems für das Fahrzeug und dessen Insassen sicherheitskritisch ist, ist es erforderlich, dass wiederholtes Einlesen von Sensoren, Berechnungen und die Aktualisierung von Aktoren periodisch erfolgen, zum Beispiel alle fünf Mikrosekunden. In der Praxis muss ein derartiges System strikte Echtzeitanforderungen erfüllen, was bedeutet, dass die Korrektheit einer Regelungsfunktion nicht nur von der Korrektheit eines Regelungswertes abhängt, der an das zu steuernde Gerät übertragen wird, sondern auch vom Zeitpunkt, wann das erfolgt. Eine Funktion, die später als zu einem Zeitpunkt, der innerhalb des Systems als der spätest mögliche definiert wurde (= Deadline), ist per definitionem falsch und hat üblicherweise keinen Nutzen. Das bedeutet, dass das Regelungssystem die Erfüllung vordefinierter Zeit-Anforderungen garantieren muss.
Konventionelle Software, die für Echtzeitsysteme entworfen wurde, ist typischerweise so konfiguriert, dass die Software in mehrere Funktionen (= Tasks) aufgeteilt ist, die das System auszuführen hat. Diese Tasks können von einer ECU (also einem Knoten), oder von verschiedenen Knoten ausgeführt werden, wobei jeder einzelne Knoten eine oder mehrere Tasks ausführen kann. Manche Tasks erhalten eventuell die Ausgabe-Signale von Sensoren als ihre Eingabe, andere Tasks stellen eventuell Ausgabe-Signale an Aktoren (= Actuators) bereit. Verschiedene Tasks kommunizieren eventuell untereinander durch Datenaustausch. Solch ein Datenaustausch kann eventuell durch einen Speicherzugriff auf einen mehreren Tasks gemeinen Speicher erfolgen. Ein Ausführungsplan (= Schedule) und die Ausführung von Tasks hängen eventuell von externen Ereignissen (= Events) ab, die vom System durch einen oder mehrere Sensoren erfasst werden.
Es ist wohl bekannt, dass die Entwicklung von eingebetteten Systemen mit harten Echtzeitanforderungen schwierig, fehleranfällig und daher teuer ist. Das gilt sowohl für Ein-Knoten-Systeme als auch für verteilte eingebettete Systeme. Deswegen ist die Simulation essentiell im Entwicklungsprozess von eingebetteten Systemen. Es sind verschiedene Arten von Systemsimulatoren bekannt. Eine Simulation von nur der Funktionalität lässt die Tatsache außer Acht, dass eine Task eine ausführungsspezifische Zeit benötigt, die von der Hardware abhängt, die die Task ausführt. Obwohl eine rein funktionale Simulation schnell und günstig ist, ist sie in vielen Fällen nutzlos oder zumindest von eingeschränktem Wert, um den Entwurf eines Echtzeitsystems zu validieren. Ausgefeilte Hardware-Simulatoren (= Anweisungssatz-Simulatoren = Instruction Set Simulators, abgekürzt ISS) hingegen erlauben eine detaillierte Simulation sowohl der Software als auch der Hardware. Allerdings sind ISS extrem langsam und teuer.
Es gibt daher einen Bedarf an einer verbesserten Simulationsmethode und an einem zugehörigen Simulationssystem zur Simulation von Echtzeitsystemen. Insbesondere sollte eine verbesserte Simulation ein Zeitverhalten zeigen, das so nahe wie möglich an dem Verhalten der Ausführungsplattform, aber viel schneller als ein ISS ist.
Zusammenfassung
Es wird eine Methode zur Simulation von Echtzeitsystemen offen gelegt. Das Echtzeitsystem besteht aus einer Anwendungs-Software, die auf einer Ziel-Hardware-Plattform auszuführen ist, wobei die Anwendungs-Software aus zumindest zwei Tasks besteht. Jede Task besteht aus einer Menge von Anweisungen. Entsprechend einem Beispiel der Erfindung inkludiert die Methode die Definition von zumindest einer Aufrufstelle (Access Point) für jede Task bei einer Anweisung, die zumindest eines der Folgenden repräsentiert:

– den Einstiegspunkt (= Anfang) einer Task,
– den Ausstiegspunkt (= das Ende = Exit) einer Task,
– den Zugriff auf einen gemeinsamen Speicher,
– den Zugriff auf ein Register der Ziel-Hardware-Plattform,
– den Aufruf einer Funktion des Betriebssystems oder einer Treiberfunktion, die von der Zielplattform bereitgestellt wird,

Kurze Beschreibung der Zeichnungen
Die zuvor erwähnten als auch weitere vorteilhafte Eigenschaften der Erfindung werden durch die nachfolgende detaillierte Beschreibung von beispielhaften Ausprägungen der Erfindung mit Verweis auf begleitende Zeichnungen verdeutlicht. Es wird darauf hingewiesen, dass nicht alle möglichen Ausprägungen der vorliegenden Erfindung notwendigerweise jeden, oder auch nur irgendeinen der identifizierten Vorteile zeigen.
zeigt die grundlegende Struktur einer Hardware-in-the-Loop-Simulation;
zeigt die grundlegende Struktur einer Software-in-the-Loop-Simulation;
zeigt das Konzept der diskreten Ereignissimulation;
zeigt die Task-Ausführung auf einer Zielplattform und während der Simulation anhand von Zeitdiagrammen;
zeigt die diskrete Ereignissimulation, den Inhalt der Ereignis-Warteschlange und die zugehörigen Zeitstempel gemäß einem Beispiel der vorliegenden Erfindung.
Detaillierte Beschreibung
Echtzeitsysteme findet man typischerweise bei Automobil-, Eisenbahn-, Luft- und Raumfahrts- sowie militärischen Anwendungen. Eingebettete Software, die solche Echtzeitsysteme steuert, umfasst üblicherweise eine Menge von Funktionen, die üblicherweise als ”Tasks” bezeichnet werden. Wenn eine Task ausgeführt wird, verarbeitet eine Task Eingabewerte und stellt Ausgabewerte bereit. Bei eingebetteter Software stellen manche der Eingabewerte Messungen physikalischer Grössen dar (wie zum Beispiel die Position, den Druck, die Temperatur, etc.), die durch Sensoren durchgeführt werden. Ähnlich stellen einige der Ausgabewerte die erwünschten Größen physischer Eigenschaften (zum Beispiel die erwünschte Position, die erwünschte Temperatur, die erwünschte Spannung, etc.) dar, die durch Aktoren auf das physische Umfeld übertragen werden. Weiters werden Task-Ausführungen von Sensoren ausgelöst, die diskrete Bedingungen in der physischen Umgebung detektieren. Das gilt sowohl für periodische, zeitgesteuerte Tasks als auch für sporadische, ereignisgesteuerte Tasks. Eingebettete Echtzeitsysteme sind üblicherweise dadurch charakterisiert, dass Zeit eine zentrale Rolle im Verhalten des Systems spielt. In diesem Fall hängt die Korrektheit des Systems nicht nur von der richtigen Transformation der Eingabewerte zu den Ausgabewerten ab (was eine Eigenschaft der Software per se ist), sondern auch von den korrekten Zeitpunkten, wann die Ausgabewerte bereitgestellt werden. Dieses Verhalten ist eine Eigenschaft des ganzen eingebetteten Systems, das aus der Software und der Zielplattform (Hardware und Betriebssystem), die die Tasks ausführt, besteht. Solch ein Rechnersystem wird als reaktiv bezeichnet, weil es auf Stimuli seiner Umgebung reagiert.
Ein eingebettetes System arbeitet üblicherweise in einer physichen Umgebung, mit der es über Sensoren und Aktoren interagiert. Eine wichtige Kategorie von Echtzeitsystemen sind daher Regelungssysteme. In diesem Fall besteht die Software aus einer Menge von (Regler-)Tasks und das physische System, das zu regeln ist, wird als Anlage (= Plant) bezeichnet. Um den Entwicklungsprozess schnell und kostengünstig zu gestalten, ist es sehr erwünscht, eingebettete Systeme im Entwicklungsprozess simulieren zu können, um das Verhalten des eingebetteten Systems validieren zu können, ohne die tatsächliche Anlage zu verwenden. Regelungsingenieure erhalten oft einen Anlagen-Simulator (zum Beispiel als MATLAB/Simulink-Modell), der das Verhalten der Anlage so gut wie nötig simuliert, indem ein Software-Programm auf einem PC oder einem spezialisierten Echtzeitrechner ausgeführt wird. Ein eingebettetes System kann in einem geschlossenen Kreis (= Closed Loop) mit einem Anlagenmodell sowohl durch Hardware-in-the-Loop (HIL) als auch durch Software-in-the-Loop (SIL)-Methoden ausgeführt werden.
veranschaulicht die allgemeine Struktur einer HIL-Simulation. Die Regler-Software wird in das Zielsystem geladen, das im allgemeinen ein (zB eingebettetes) Rechnersystem ist, und welches für eine bestimmte Art von Regleranwendungen zugeschnitten ist. Diese dedizierte Hardware, die in als ”Control Unit 20” bezeichnet wird, führt die eingebettete Software aus, was das Verhalten der Control Unit 20 bestimmt. Die Control Unit 20 empfängt eine Reihe von Sensor-Signalen, die zu verarbeiten sind, und gibt eine Reihe von Aktor-Signalen (zB eine erwünschte Motorspannung) an einen Plant Simulator 10 aus, der die zu steuernde Anlage emuliert (zB einen Servo-Motor, eine Verbrennungskraftmaschine, die Ruder eines Flugzeuges, etc). Der Plant Simulator 10 simuliert das Verhalten der tatsächlichen Anlage, indem er entsprechende Sensor-Ausgaben bereit stellt (zB eine Winkelposition, einen Temperaturwert, etc). Da die eingebettete Software auf einer Zielplattform ausgeführt wird, hängt die Genauigkeit (Qualität) der HIL-Simulation nur von der Genauigkeit (Qualität) der Anlagensimulation ab. Selbstverständlich ist eine HIL-Simulation auch für Einzel-Eingaben und/oder Einzel-Ausgaben-Systeme möglich.
veranschaulicht die allgemeine Struktur einer SIL-Simulation. Üblicherweise werden sowohl die Anlagensimulation (Plant Simulator 10) als auch die eingebettete Software (Control Unit 20) auf derselben Hardware ausgeführt, die ein PC (Host Computer) sein mag. Da die eingebettete Software nicht auf der Zielplattform ausgeführt wird, hängt die Genauigkeit (Qualität) der SIL-Simulation nicht nur von der Genauigkeit (Qualität) der Anlagensimulation ab, sondern auch signifikant vom Detailierungsgrad der Simulation der Control Unit 20.
Das SIL-Simulationsmodell eines eingebetteten Systems umfasst die Anwendungssoftware (eingebettete Software) wie auch eine Abstraktion der Zielplattform (die eingebettete Hardware samt dem Betriebssystem). Die Abstraktionsstufe bestimmt, wie nahe die Software-Ausführung am Host Computer an die HIL-Simulation herankommt (für dasselbe Anlagenmodell). SIL-Simulationsmodelle können von einer minimalen Repräsentation der Zielplattform, die im wesentlichen lediglich das Testen der funktionalen (transformierenden oder verarbeitenden) Eigenschaften der Software erlaubt, bis hin zu sehr ausgefeilten Hardware-Simulatoren (sogenannten Instruction Set Simulatoren, ISS) reichen, die zu einem Systemverhalten führen, das nahe an der HIL-Simulation ist, während eine bessere Beobachtbarkeit der Software-Ausführungen (zB zum Zweck der Fehler-Auffindung und -Beseitigung = zum Debugging) geboten wird. Rein funktionale Simulationen sind schnell, erlauben aber nicht das Testen der Zeiteigenschaften eines eingebetteten Systems. ISS sind extrem langsam und teuer.
Ein neues SIL-Simulations-System und eine SIL-Simulations-Methode umfassen ein Simulationsmodell, das SIL-Simulationen von eingebetteten Systemen ermöglicht, die nützlich zum Testen der Echtzeiteigenschaften einer Anwendung sind, ohne auf eine detaillierte Hardware-Simulation (wie es ISS tun) zurückgreifen zu müssen. Dadurch wird eine rasche Simulationsgeschwindigkeit und gleichzeitig eine signifikant verbesserte Genauigkeit, nahe einer HIL-Simulationen, bereitgestellt.
Bevor auf die Details der neuen Simulations-Methode und des neuen Simulations-Systems eingegangen wird, werden kurz die Eigenschaften einer diskreten Ereignissiumlation, Coroutinen und die Schätzung der Ausführungszeit diskutiert. In einer diskreten Ereignissimulation wird der Ablauf eines Systems durch die chronologische Abfolge von Ereignissen repräsentiert. Jedes Ereignis findet zu einem Zeitpunkt statt, und stellt eine Änderung des Systemzustands dar. Die Simulation muss die aktuelle Simulationszeit speichern (welche [Zeit-]Einheit auch immer für die Systemmodellierung nötig ist). In diskreten Ereignis-Simulationen, im Gegensatz zu Echtzeitsimulationen, ”springt” die Zeit, weil die Ereignisse augenblicklich stattfinden. Die Uhr springt auf die nächste Ereigniszeit, wenn die Simulation voranschreitet. Ein Ereignis ist mit einer oder mehreren Funktionen des simulierten Systems assoziiert, die ausgeführt werden müssen, wenn das Ereignis verarbeitet wird. Außerdem kann ein Ereignis Daten enthalten, die den Funktionen zum Zeitpunkt, wann das Ereignis eintritt, bereitgestellt werden.
Ein diskreter Ereignis-Simulator hält eine Liste von Ereignissen, die nach Zeitstempel geordnet sind, die sogenannte Ereignis-Warteschlange, und eine Simulationszeit, die der Zeitstempel des gerade verarbeiteten Ereignisses ist. Nach der Verarbeitung eines Ereignisses stellt der Simulator die Simulationszeit auf den Zeitstempel des nächsten Ereignisses in der Warteschlange und verarbeitet dieses Ereignis. Neue Ereignisse können zur Warteschlange aufgrund der Verarbeitung bestehender Ereignisse oder während der Initialisierungsphase der Simulation hinzugefügt werden. Die grundlegende Funktionsweise diskreter Ereignisse wird durch ein Beispiel in veranschaulicht. In diesem Beispiel enthält die Ereignis-Warteschlange drei Ereignisse E1, E2 und E3. Die Simulation ”springt” von einem Ereignis zum nächsten. Unter der Annahme, dass gerade E1 verarbeitet wird, ist die Simulationszeit auf 3 gesetzt. Nach dem Beenden der Verarbeitung von E1 (und unter der Annahme, dass kein neues Ereignis mit einem Zeitstempel kleiner als 6 eingefügt wird), stellt der Simulator die Simulationszeit auf 6 vor, und verarbeitet Ereignis E2. Wenn die Verarbeitung von E1 ein neues Ereignis vor E2 einfügen würde, würde die Simulation zu diesem neuen Ereignis springen und die Simulationszeit entsprechend setzen.
Coroutinen können als Verallgemeinerung des Konzepts von Subroutinen wie zum Beispiel Prozeduren, Methoden und Funktionen gesehen werden. Coroutinen sind Programmkomponenten, die mehrere Einsprungpunkte zum Unterbrechen und Fortsetzen der Ausführung an bestimmten Stellen erlauben. Der Hauptunterschied zwischen Coroutinen und Subroutinen ist, dass die Ausführung von Coroutinen unterbrochen und später fortgesetzt werden kann, wobei der interne Zustand gewahrt bleibt. Um dieses Konzept zu verstehen, ist es hilfreich, zuerst zu diskutieren, was eine gewöhnliche Subroutine (das heisst eine Funktion in C oder eine Methode in Java) tut, und das dann mit Coroutinen zu vergleichen. Der Beginn einer Subroutine ist der einzige Einsprungpunkt, und Subroutinen können nur einmal zurückkehren. Im Gegensatz dazu können Coroutinen mehrere Male zurückkehren (was in diesem Fall als ”Ergebnis” = ”yield” bezeichnet wird). Der Start einer Coroutine ist der erste Einsprungpunkt. Wenn die Coroutine das nächste Mal aufgerufen wird, beginnt die Ausführung nicht am Beginn der Coroutine, sondern gerade dort, wo die Ausführung der Coroutine das letzte Mal gestoppt wurde.
Eine SIL-Simulation muss auch die Schätzung der Ausführungszeit von Tasks und Teilen einer Task berücksichtigen. Allgemein wird eingebettete Software (das heißt Anwendungs-Software) auf einem Host Computer ausgeführt, der im allgemeinen mächtiger als die eingebettete Zielplattform ist. Deswegen wird am Host Computer derselbe Code-Teil viel schneller ausgeführt als auf der Zielplattform (das heißt dem eingebetteten System). Um die tatsächliche Ausführungszeit, die vergehen würde, wenn der Code-Teil auf der Zielplattform ausgeführt wird, zu simulieren, wird der Code-Teil mit der Zeitspanne annotiert, die nötig ist, um den Code-Teil auf der Zielplattform auszuführen. Diese Annotation erfolgt vor der Simulation des Systems. Man beachte, dass die Grund-Blöcke (= Basic Blocks) des Quelltextes annotiert werden.
Der Code in einem Basic Block hat einen Einsprungpunkt (was bedeutet, dass keine Zeile Code innerhalb des Basic Blocks das Ziel einer Spunganweisung irgendwo im Programm ist) und hat einen Aussprungpunkt (was bedeutet, dass nur die letzte Anweisung eines Basic Blocks bewirken kann, dass das Programm einen Code in einem anderen Basic Block ausführt). Unter diesen Umständen, wann auch immer die erste Anweisung in einem Basic Block ausgeführt wird, werden die übrigen Anweisungen notwendigerweise exakt einmal der Reihe nach ausgeführt.
Die Ausführungszeit eines Stückes Quelltext hängt stark von der Plattform (Taktung der Prozessor-Uhr, Pipelining, Caching, Scheduling durch das Betriebssystem, etc.) ab. Grundsätzlich gibt es zwei Ansätze zum Schätzen der Ausführungszeit: (1) statische (Objekt-)Code-Analyse und (2) Messung der Code-Ausführungszeit auf der Zielplattform. Viel Forschung wurde für beides durchgeführt. Der erste Ansatz benötigt oft ein detailliertes Modell der Plattform (Prozessor, Pipelining, Caching, Scheduling durch das Betriebssystem, etc.). Solche Modelle sind mühsam zu beschreiben und oft gar nicht verfügbar. Zum Beispiel veröffentlicht Intel seine Prozessorarchitekturen nicht. Der zweite Ansatz ist durch seine Skalierbarkeit eingeschränkt: um die Ausführungszeiten von allen Code-Teilen (zum Beispiel von allen Basic Blocks) zu messen, müssten die Basic-Code-Teile möglicherweise mehrmals ausgeführt werden, um einen angemessenen Wertebereich von bester, schlechtester und durchschnittlicher Ausführungszeit zu erhalten.
Das Simulationsmodell des neuen SIL-Simulations-Systems und der SIL-Simulations-Methode, die hier beschrieben werden, bekommt die Ausführungszeiten von Code als Eingabe, unabhängig davon, welcher Ansatz und welches Werzeug benutzt werden. Selbstverständlich hängt die Genauigkeit der Simulation von der Genauigkeit der Schätzungen oder der Messungen der Ausführungszeit ab.
Code-Instrumentierung (= Annotation) bezieht sich auf das Hinzufügen von zusätzlichem Code (bezeichnet als Instrumentierung) zum ursprünglichen Anwendungscode, aus dem die eingebettete Software besteht. Der Zweck der Instrumentierung kann sein, die Code-Ausführung an spezifischen Stellen im Code zu unterbrechen oder fortzusetzen und die Ausführungszeiten mit den Code-Teilen zwischen solchen Stellen zu assoziieren.
Beispiele für die vorliegende Erfindung kombinieren die obigen Techniken der Code-Annotation und der diskreten Ereignis-Simulation und wenden diese nutzbringend in einem neuen SIL-Simulationsmodell an. Dementsprechend wird eine exakte Definition der Unterbrechungs-/Fortsetzungsstellen – die nachfolgend als ”Access Points” bezeichnet werden – gegeben, um eine entsprechende Code-Instrumentierung zu ermöglichen. Es wird angenommen, dass es genügt, die Task-Ausführung so zu simulieren, als ob ein Wechsel zwischen Tasks (aufgrund von Unterbrechungen und von unterberechendem Scheduling) nur bei Access Points auftritt. Coroutinen können verwendet werden, um die Simulation des Task-Wechsels und das Behandeln von Unterbrechungen zu implementieren. Die oben erwähnte Annahme erlaubt eine schnelle und kostengünstige SIL-Simulation der eingebetteten Software und der Zielplattform, wobei gleichzeitig eine hohe Genauigkeit vergleichbar mit HIL-Simulationen erreicht wird. Das Verhalten der Zielplattform wird durch die Instrumentierung des Anwendungscodes mit Ziel[plattform]ausführungszeiten berücksichtigt. Unten wird ein Beispiel eines SIL-Simulationsmodells genauer erklärt.
Eine ”Task” einer Anwendungs-Software ist entweder eine allgemeine Funktion, die vom Betriebssystem aufgerufen wird, oder eine Funktion, die aufgerufen wird, wenn eine Unterbrechung (= Interrupt) auftritt (das heißt, eine Interrupt Service Routine). Speicher, auf den von unterschiedlichen Tasks aus (lesend oder schreibend) zugegriffen wird, wird als ”Shared Memory” bezeichnet. Beispiele für Shared Memory sind globale Variablen, auf die von unterschiedlichen Tasks zugegriffen wird. Ein ”externes Register” ist ein Register eines Peripherie-Ein-/Ausgabe-Geräts (= Input/Output-Device = I/O-Device) oder die Speicherstelle, der ein I/O-Device zugeordnet ist. Beispiele für externe Register sind Daten und Kontroll-Register für Bus Controllers, Zeitgeber (= Timers), analog-digital- und digital-analog-Wandler. Ein ”Access Point” ist, wie oben erwähnt, eine Zeile Quelltext, die eines der folgenden Punkte darstellt

(a) den Anfang einer Task, das heißt die erste Zeile Quelltext einer Einheit,
(b) das Ende einer Task, das heißt die Return-Anweisung einer Task,
(c) einen Zugriff (lesend oder schreibend) auf einen gemeinsamen Speicher (= Shared Memory),
(d) einen Zugriff (lesend oder schreibend) auf ein externes Hardware-Register, oder
(e) einen Aufruf einer Betriebssystem-Funktion (oft als ”Systemaufruf” bezeichnet) oder einer Funktion der Ziel-Hardware-Plattform (oft als ”Treiber-Funktions-Aufruf” bezeichnet).

Access Points (b) bis (e) bezeichnen wir als ”interne Access Points”. Im allgemeinen ist ein interner Access Point eine Menge von Quelltextzeilen, die eine Interaktion mit einer Information initiieren, die von externen Ressourcen (Speicher, anderen Tasks, Peripherie-Schnittstellen, Betriebssystem, etc.) bereitgestellt oder benötigt wird. Eine Coroutine kann für jede Task definiert werden. Eine Coroutine wird von Beginn weg ausgeführt, wann immer die [zugehörige] Task eine neue Ausführung starten muss, was durch die simulierte Scheduler-Komponente des Betriebssystems (für Tasks) oder durch einen simulierten Interrupt-Controller (für Interrupt-Service-Routinen) bestimmt wird. Immer wenn eine Coroutine aufgerufen wird, wird die Coroutine entweder vom Beginn weg oder von einer Yield-Stelle (die mit einem internen Access Point zusammenfällt) weiter ausgeführt. Die Coroutine wird von einer spezialisierten Komponente des simulierten Systems aufgerufen, die Programm-Ausführungs-Manager (= Program Execution Manager = PEM) genannt wird. Der PEM steuert eine diskrete Ereignissimulation mit folgender spezifischer Funktionalität: Der PEM verfolgt die ablaufende Ausführungszeit für den ausgeführten Anwendungscode und implementiert die Prozessor-Reaktion auf Interrupt-Anforderungen wie unten näher beschrieben.
Übereinstimmend mit einem Beispiel der vorliegenden Erfindung wird der Anwendungs-Code (das ist der Quell-Code aller Tasks und Interrupt-Service-Routinen) mit einer Coroutine-Yield-(Return-)Anweisung instrumentiert, die unmittelbar vor jedem internen Access Point eingefügt wird. Daher geht, wenn der instrumentierte Code ausgeführt wird, die Ausführungskontrolle unmittelbar vor jedem internen Access Point an den PEM zurück. Der Code-Teil zwischen zwei aufeinanderfolgenden Access Points wird als ”synchron ausgeführter Block” (= Synchronously Executed Block = SEB) bezeichnet. Der PEM simuliert das Fortschreiten der Ausführungszeit entsprechend einem SEB. Basierend auf Eingaben des (simulierten) Betriebssystem-(= Operating System = OS)Schedulers und des Interrupt Controllers, kann der PEM entscheiden, ob mit der Ausführung derselben Task fortgesetzt wird, oder ob er zu einer anderen Task wechseln muss, die zum Beispiel eine höhere Priorität hat. Der PEM setzt die Ausführung einer Task bei der letzten Yield-Stelle fort, indem er einfach die entsprechende Coroutine (wieder) aufruft. Es ist anzumerken, dass jeder SEB mit einem Access Point beginnt und ohne Eingriff von anderen simulierten Komponenten ausgeführt wird.
Um die Ziel[plattform]-Ausführungskomponenten zu berücksichtigen, kann jeder Basic Block des Anwendungs-Quell-Codes mit der Ausführungszeit auf der Zielplattform annotiert werden. Eine weitere Instrumentierung kann dazu verwendet werden, um zur Laufzeit die Ausführungszeiten der ausgeführten SEBs, die mehrere aufeinanderfolgende Basic Blocks mit jeweiligem Kontrollfluss enthalten können, zu ermitteln. Für die aktuelle Diskussion ist jedoch die Annahme ausreichend, dass für jeden SEB die Ziel[plattform]spezifische Ausführungszeit verfügbar ist. Am Ende eines jeden SEB geht die Kontrolle an die PEM-Komponente zurück, wobei die jeweilige SEB-Ausführungszeit als Parameter mitgegeben wird.
Die Details der Programm-Ausführungs-Manager-(= Program Execution Manager = PEM) Komponente, die die Task-Ausführung während der Simulation steuert, und die die oben erwähnte diskrete Ereignis-Simulations-Technik benutzt, werden nachfolgend im Detail diskutiert. Diskrete Ereignis-Simulation wird als Methode verwendet, um effizient das Fortschreiten der Zeit entsprechend der Code-Ausführung und der Interaktion mit der Anlage zu simulieren. In Übereinstimmung mit dem Prinzip der diskreten Ereignis-Simulation ”springt” die (simulierte) Zeit von Ereignis zu Ereignis. Die Ausführung von Code auf einer performanten Rechnerplattform wie einem PC ist typischerweise viel schneller als als die tatsächliche Ausführung desselben Codes auf einer spezifischen Zielplattform (das heißt, einem eingebettetem System). Die zu verarbeitenden Ereignisse können in zwei Kategorien eingeteilt werden:

(1) Ereignisse, die sich auf die Ausführung der Anwendungs-Software beziehen (die Tasks), und
(2) Ereignisse, die sich auf die Simulation des Plattformmodells beziehen.

Ein Ereignis der ersten Kategorie ist entweder eine Access-Point-Ausführung oder das Auftreten eines externen Interrupts. Das korrekte Verarbeiten dieser Ereignisse stellt sicher, dass die Software-Ausführung in der Simulation nahe an der Realität ist. Die Ereignisse der zweiten Kategorie werden durch Komponenten der Ziel-Plattform generiert, und werden in der (Simulationszeit-)Reihenfolge verarbeitet, um das Verhalten der Ziel-Plattform soweit zu simulieren, wie es als relevant erachtet wird. Ziel-Plattform-Ereignisse führen zur Generierung von Interrupt-Ereignissen, die die Ausführungen der Anwendungs-Software auslösen können, und so eine Access-Point-Ausführung bewirken.
In Übereinstimmung mit einem Beispiel der vorliegenden Erfindung bietet das SIL-Simulationsmodell eine Abstraktionsstufe, sodass alle Zeilen Code in einem SEB denselben Ausführungszeitstempel haben, der gleich mit dem Zeitstempel der SEB-Access-Point-Ausführung ist. Dieses Konzept wird durch das Beispiel in veranschaulicht.
skizziert zwei Task-Funktionen T und T', die beide auf die globale Variable v, die eine [Task T] lesend und die andere [Task T'] schreibend darauf zugreifen. Der Quell-Code der Tasks ist, wie in schematisch dargestellt, aufgeteilt. Dabei bezeichnen die Zeitspannen δ₁ bis δ₄ die Ausführungszeiten (eines spezifischen SEBs einer spezifischen Task) auf der Zielplattform, auf der die entsprechenden SEBs letzlich ausgeführt werden sollen. Es sollte erwähnt werden, dass die Zeitspannen δ₁ bis δ₄ typischerweise unterschiedliche Werte haben. Die strichlierte Linie, die jeweils die Tasks T und T' in zwei Segmente teilt, veranschaulicht den Access Point, der unmittelbar vor dem Zugriff auf die globale Variable gesetzt ist. Somit besteht jede der zwei Tasks aus zwei SEBs, wobei die Ziel[plattform]-Ausführungszeitspannen (δ₁ bis δ₄) jeweils jedem SEB zugewiesen werden.
veranschaulicht als Beispiel die Ausführung der zwei Tasks T und T' auf der Zielplattform: T wird zum Zeitpunkt t₀ gestartet und T' zum Zeitpunkt t₁. Da angenommen wird, dass Task T' eine höhere Priorität hat, unterbricht diese die Ausführung des ersten Code-Teils von Task T (unter der Annahme dass t₁ < t₀ + δ₁). Daher wird der Wert der globalen Variable v, der von T' zum Zeitpunkt t₂ (t₂ = t₁ + δ₂) bereitgestellt wird, von der ersten Task T zum Zeitpunkt t₄ (t₄ = t₀ + δ₁ + δ₂ + δ₃) gelesen. Die kleineren Rechtecke innerhalb der Rechtecke, die die Tasks T und T' repräsentieren, stellen schematisch die Ausführung einzelner Code-Zeilen im Quell-Code jeder Task dar. Unten wird auf die Quell-Code-Zeilen x und y der Task T Bezug genommen. Eine weitere relevante Stelle im Quell-Code beider Tasks ist jene, wo auf die globale Variable v zugegriffen wird. Diese Stelle wird durch die schraffierten Rechtecke hervorgehoben, wobei der Wert der globalen Variable v in Task T' geschrieben wird und die Variable v in Task T gelesen wird. Es soll beachtet werden, dass die Position im Quell-Code (zu Beginn des zweiten SEBs einer jeden Task) und der entsprechende Zeitpunkt, wann diese Zeile Code ausgeführt wird, unabhängig voneinander sind, da die Ablaufplanung der Tasks (= das Scheduling der Tasks) bestimmt, wann eine Task unterbrochen wird, und wann dessen Ausführung fortgesetzt wird.
veranschaulicht eine reine funktionale (SIL) Simulation der zwei Tasks auf einem Host Computer, bei der die Ausführungszeit überhaupt nicht berücksichtigt wird. In diesem Fall wird die ganze Task-Funktion zu dem Zeitpunkt, zu dem sie angestoßen wird, ausgeführt. Daher wird die Variable v zuerst von T gelesen, und dann von T' aktualisiert; ein Verhalten das offensichtlich vom Verhalten der eingebetteten Software, die auf der Zielplattform ausgeführt wird, abweicht (siehe ). Im Beispiel der ändert Task T' den Wert, nachdem er von T gelesen wurde. Wenn der Wert, der von T' geschrieben wurde anders als der ist, den die Variable zum Zeitpunkt t₀ hatte, ist das beobachtbare Verhalten von T möglicherweise nicht dasselbe in der (SIL) Simulation als in Wirklichkeit (oder in der HIL Simulation).
Der Effekt des verbesserten (SIL) Simulationsmodells wie es übereinstimmend mit dem Beispiel der vorliegenden Erfindung benutzt wird, wird in veranschaulicht.
Die Simulation der Ausführung der Tasks T und T' mittels diskreter Ereignissiumlation wird in veranschaulicht, wobei angenommen wird, dass die Ereignis-Warteschlange zu Beginn zwei Ereignisse enthält: ein Ereignis Ev0 mit Zeitstempel t₀ zum Anstossen von Task T (bezeichnet als Ev0(t₀, T)), und ein Ereignis Ev1 mit Zeitstempel t₁ zum Anstossen von Task T' (bezeichnet als Ev1(t₁, T')). In diesem Beispiel benötigt jede Ereignisverarbeitung die Ausführung der PEM-Komponente und jedes Ereignis hat ein Datenfeld, das die zugehörige Task beschreibt (T oder T' im vorliegenden Beispiel). Der diskrete Ereignis-Simulator verarbeitet das erste (frühere) Ereignis (hier Ev0 (t₀, T)), indem die Simulationszeit auf t₀ gesetzt wird, und das Datenfeld (hier T) des Ereignisses an eine Eingabe-Schnittstelle der PEM-Komponente übergeben wird, und die PEM-Komponente ausgeführt wird. Der PEM startet die Ausführung der Task T, indem die entsprechende Coroutine aufgerufen wird. Entsprechend wird der SEB, der den ersten Teil der Task T darstellt, als ganzes ausgeführt (hier SEB1); dann geht die Kontrolle an den PEM zurück (wobei auch die benötigte Ausführungszeit auf der Zielplattform δ₁ an den PEM weitergegeben wird). Dann registriert der PEM ein neues Ereignis Ev2 mit dem Zeitstempel t₀ + δ₁. Ev2 zeigt einen möglichen Zeitpunkt für eine Wiederaufnahme der Ausführung von T an, genauer gesagt für die künftige Ausführung von SEB4. Der PEM markiert auch Task T als laufend (= running) und speichert den Wert δ₁ als die initial verbleibende Ausführungszeit, die zu Lasten von SEB1 der Task T verbraucht werden muss, bevor T die Ausführung fortsetzen kann. Die nächsten Ereignisse in der Ereignis-Warteschlange sind

(1) Ev1: der Auslöser für T' mit dem Zeitstempel t₁ und
(2) Ev2: die Ausführung des SEB, der dem zweiten Teil der Task T mit dem Zeitstempel t₀ + δ₁ entspricht.

Da gilt, dass t₁ < t₀ + δ₁, ist das früheste nicht verarbeitete Ereignis (1) und daher wird Ev1 als nächstes verarbeitet.
Wenn die diskrete Ereignissimulation fortgesetzt wird, wird die Simulationszeit auf t₁ gesetzt und der PEM wird mit T' als Parameter aufgerufen. Der PEM aktualisiert die verbleibende Zeit für den ausgeführten SEB1 der Task T. Die verbleibende Zeit für SEB1 ist daher δ₁ – (t₁ – t₀). Da im vorliegenden Beispiel Task T' die Task T unterbricht, speichert der PEM die verbleibende Zeit von SEB1 in einer internen Datenstruktur und ruft die Coroutine für T' auf, was zur Ausführung des SEBs führt, der dem ersten Teil der Task T' entspricht (hier SEB2), der die Kontrolle zurückgibt, bevor auf die Variable v zugegriffen wird, und der eine Ausführungszeit von δ₂ an den PEM meldet. Als Ergebnis wird ein Ereignis Ev3 für die Ausführung des zweiten Teils (SEB3) der Task T' mit dem Zeitstempel t₂ = t₁ + δ₂ in die Warteschlange eingefügt, Task T wird als unterbrochen (= preempted) markiert, Task T' als laufend (= running), und die Ausführung des PEMs endet. Zu diesem Zeitpunkt enthält die Ereigniswarteschlange die Ereignisse Ev2 und Ev3. Im vorliegenden Beispiel wird angenommen, dass Ev3 das frühere Ereignis ist (das heißt, dass t₂ < t₀ + δ₁). Daher ist das nächste Ereignis in der Warteschlange die Ausführung des zweiten Teils, also von SEB3, der Task T'. Ein Ergebnis dieser Verarbeitung ist das Einfügen von Ereignis Ev4 in die Warteschlange mit dem Zeitstempel t₃ = t₂ + δ₃, was die Terminierung der Ausführung von Task T' bedeutet.
Nun sind die Ereignisse Ev2 und Ev4 in der Warteschlange. Da im vorliegenden Beispiel Ev2 das frühere Ereignis in der Warteschlange ist, das heißt, dass t₀ + δ₁ < t₃, wird Ev2 verarbeitet, indem der PEM zur Simulationszeit t₀ + δ₁ mit der Anforderung, die Ausführung von T fortzusetzen, ausgeführt wird. Der PEM erkennt, dass die gerade laufende Task T' eine höhere Priorität hat, und die gerade angemeldete Ausführungszeit (δ₃) nicht verbraucht hat, weshalb die Anfrage für T ignoriert wird. Nun ist Ev4 das einzige Ereignis in der Warteschlange, daher wird die Zeit auf t₃ gesetzt und der PEM ausgeführt. Da Ev4 mit einem Access Point assoziiert ist, der einem Ausstiegspunkt von T' entspricht, erkennt der PEM, dass T' beendet ist, und markiert T' als ausgesetzt (= suspended). Dann nimmt der PEM T als die unterbrochene Task mit der höchsten Priorität, und, da T noch die verbleibende Ausführungszeit von δ₁ – (t₁ – t₀) zu verbrauchen hat, ändert der PEM die Markierung von T von preempted auf running und fügt ein Ereignis Ev5 in die Warteschlange mit dem Zeitstempel t₄ = t₃ + δ₁ – (t₁ – t₀) ein. Dieses Ereignis wird als nächstes verarbeitet, da es das einzige in der Warteschlange ist. Zum Zeitpunkt t₄ ruft der PEM die Coroutine von T auf, wodurch die Ausführung vom Access Point an fortgesetzt wird (also SEB4). Nachdem SEB4 ausgeführt wurde, geht die Kontrolle an den PEM zurück, der das Event Ev6 in die Warteschlange mit dem Zeitstempel t₄ + δ₄ einfügt, welcher mit dem Ausstiegspunkt von T assoziiert ist, und so den Zeitpunkt der Beendigung von T anzeigt. Wenn bis dahin keine anderen Ereignisse in die Warteschlange eingefügt werden, wird die Warteschlange leer, sobald Ev6 verarbeitet wurde, und die Simulation endet. Andernfalls würde die Simulation mit dem nächsten Ereignis in der Warteschlange fortsetzen.
Man kann sehen, dass jeder Access Point zur richtigen Zeit ausgeführt wird, und zwar bezogen auf das Ausführungszeitverhalten, wenn die Zielhardware wie in veranschaulicht, verwendet wird. Daher bewahrt das Simulationsmodell der vorliegenden Erfindung im gerade diskutierten Beispiel die Reihenfolge der Zugriffe auf dieselbe, von unterschiedlichen Tasks gemeinsam genutzte, Ressource. veranschaulicht die oben beschriebene Simulationsabfolge von mit Hilfe einer Tabelle, die den Inhalt der Ereigniswarteschlange während der Simulation, die Aktionen zur Ereignisverarbeitung durch den diskreten Ereignis-Simulator und die entsprechende Funktionsweise der PEM-Komponente enthält.
Es ist anzumerken, dass im obigen Beispiel in den und die Ausführungsreihenfolge beliebiger Zeilen Quell-Code nicht notwendigerweise erhalten bleibt. Im Beispiel in wird Task T' ausgeführt, nachdem die Zeile x von Task T ausgeführt worden ist, und bevor die Zeile y von Task T ausgeführt wird. Im Simulationsmodell, das im Beispiel in den und verwendet wird, wird Task T' nach der Ausführung des SEBs, der dem gesamten ersten Teil der Task T entspricht, ausgeführt. Um die Auswirkungen einer Unterbrechung (= Preemption) auf Datenabhängigkeiten zwischen parallelen Komponenten zu berücksichtigen, genügt es, die Ausführungen nur bei Access Points zu unterbrechen. Mit anderen Worten formuliert, macht es nichts aus, in welcher Zeile Code genau eine Unterbrechung auftritt. Die einzige relevante Frage ist, zwischen welchen Access Points eine Unterbrechung auftritt. Diese Beobachtung erlaubt eine schnelle Simulation unter gleichzeitiger Beibehaltung des relevanten Echtzeitverhaltens des Systems.
Das oben vorgestellte Simulationsmodell kann im Closed-Loop mit den Anlagenmodellen mit unterschiedlichen Werkzeugen unter Anwendung der Auflösung in variablen Schritten (= Variable Step Solvers) simuliert werden. Das neue Simulationsmodell erlaubt auch, dass beim Fehlersuchen und Fehlerentfernen (= Debuggen) über Unterbrechungsstellen hinweg vorwärts und rückwärts gegangen wird. Man kann eine Simulation von einem zuvor gespeicherten Zustand beginnen. Der Simulator, der als Ganzes in einer imperativen Programmiersprache wie zB der Programmiersprache C implementiert ist, kann leicht mit bestehenden Anlagen-Simulationswerkzeugen (wie Matlab/Simulink) integriert werden.
Schlußendlich werden wichtige Aspekte der vorliegenden Erfindung zusammengefasst. Diese Zusammenfassung ist jedoch nicht als vollständig zu betrachten. Die Erfindung bezieht sich auf eine Methode zur Computer-basierten Simulation eines Echtzeitsystems. Ein solches Echtzeitsystem umfasst eine Anwendungs-Software, die auf einer Ziel-Hardware-Plattform (Hardware und Betriebssystem) auszuführen ist; und die Anwendungs-Software besteht aus zumindest zwei Tasks mit unterschiedlicher Priorität, und jede Task beinhaltet eine Menge von Anweisungen. In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung gehört die Definition von zumindest einem Access Point für jede Task zur Methode dazu, und zwar bei einer Anweisung, die eines der folgenden Punkte darstellt:

– den Anfang einer Task,
– das Ende einer Task,
– einen Zugriff auf einen gemeinsamen Speicher (= Shared Memory)
– einen Zugriff auf ein Register der Hardware-Plattform,
– einen Aufruf einer Betriebssystem-Funktion (Systemaufruf) oder einer Treiber-Funktion der Ziel-Plattform (Treiber-Funktions-Aufruf),

Ein neues Ereignis, das mit dem nächsten Access Point der Task assoziiert ist, kann in die Ereignis-Warteschlange mit einem Zeitstempel hinzugefügt werden, der vom Zeitstempel des aktuellen Ereignisses und der Target Execution Time, die dem auszuführenden Anweisungsblock zugeordnet ist, abhängt. Weiters kann, vor der Ausführung einer Task, die mit einem Ereignis assoziiert ist, die mit der höchsten Priorität zum Ereignis-Zeitstempel auszuführende Task bestimmt werden. Wenn die so bestimmte Task diejenige ist, die mit dem gerade verarbeiteten Ereignis assoziiert ist, und wenn der assoziierte Access Point nicht eine Ausstiegs-(= Termination-)Stelle ist (was die Aussetzung der Ausführung der Task erfordern würde), kann der Anweisungsblock, der beim Access Point beginnt, der mit dem Ereignis assoziiert ist, ohne Unterbrechung ausgeführt werden. Ein neues Ereignis kann zur Ereignis-Warteschlange hinzugefügt werden, wann immer eine externe Bedingung eine erneute Ausführung einer Task, oder die Fortsetzung einer zuvor ausgesetzten Task-Ausführung erfordert. Das neue hinzuzufügende Ereignis wird mit einem Zeitstempel versehen, der dem Zeitpunkt entspricht, zu dem die Task-Ausführung starten soll (was sich aus dem externen Ereignis ergibt, zB einem Interrupt).
Während der Verarbeitung des gerade verarbeiteten (das heißt simulierten) Ereignisses, kann die assoziierte Task als ”laufend” markiert werden, wenn ein Anweisungsblock der Task ausgeführt wird. Alternativ dazu kann die assoziierte Task als ”bereit” markiert werden, wenn es eine andere ”laufende” Task mit höherer Priorität gibt. Alternativ dazu kann die assoziierte Task als ”ausgesetzt” markiert werden, wenn die vorige Markierung laufend war, und das Ereignis entweder mit einer Ausstiegs-(= Termination-)Stelle der Task oder mit einem Access Point, der einen Systemaufruf (oder einen Treiberfunktionsaufruf) darstellt, der erfordert, dass die Task wartet, bevor die Ausführung fortgesetzt wird, assoziiert ist.
Ähnlich ist eine Task, die nicht mit einem gerade verarbeiteten Ereignis assoziiert ist, als ”unterbrochen” markiert, wenn die Markierung der Task unmittelbar vor dem Ereignis laufend war, und wenn die Task, die mit dem aktuellen Ereignis assoziiert ist, als ”laufend” markiert ist. Die verbleibende Ausführungszeit, die für den unterbrochenen Anweisungsblock benötigt wird, kann für eine künftige Nutzung gespeichert werden. Die Information, wieviel Zeit verbleibt, wird benötigt, wenn die Wiederaufnahme einer unterbrochenen Task simuliert werden muss. Weiters kann eine Task, die nicht mit dem aktuellen Ereignis assoziiert ist, als ”laufend” markiert werden, wenn (1) die vorige Markierung der Task ”unterbrochen” oder ”bereit” war, (2) die Task die höchste Ausführungspriorität unter allen unterbrochenen oder bereiten Tasks hat, und (3) die Task, die mit dem aktuellen Ereignis assoziiert ist, als ”ausgesetzt” markiert ist.
Ein neues Ereignis, das mit der (zuletzt unterbrochenen und) gerade als ”laufend” markierten Task assoziiert ist, wird in die Ereignis-Warteschlange hinzugefügt, und zwar mit einem Zeitstempel, der vom Zeitstempel des aktuellen Ereignisses und von der gespeicherten verbleibenden Ausführungszeit der Task, die gerade als ”laufend” markiert ist, abhängt.
Eine Ausprägung der vorliegenden Erfindung kann eines oder mehrere der oben zusammengefassten technischen Merkmale beinhalten. Allen Ausprägungen ist jedoch folgendes gemein: das allgemeine Konzept der Access Points, wie es oben beschrieben wird, die Aufteilung des Codes von Tasks an diesen Access Points in Anweisungsblöcke, wobei das Ziel-Plattform-Verhalten dadurch simuliert wird, dass jedem Anweisungsblock die Ausführungszeit auf der Ziel-Plattform zugewiesen wird. Zu Simulationszwecken wird daher ein Anweisungsblock ohne Unterbrechung ausgeführt. Allgemein ist ein interner Access Point eine Menge von Quelltextzeilen einer Task, die die Interaktion mit Information auslösen, die von Task-externen Ressourcen (Speicher, anderen Tasks, Peripherie-Schnittstellen, Betriebssystem, etc.) bereitgestellt oder benötigt wird.
Obwohl die vorliegende Erfindung und ihre Vorteile im Detail beschrieben worden sind, sollte verstanden werden, dass diverse Änderungen, Ersetzungen, und Umgestaltungen gemacht werden können, ohne sich von der Idee und dem Rahmen der Erfindung, wie sie in den nachfolgenden Ansprüchen definiert ist, zu entfernen.
Weiters ist es nicht die Intention, den Rahmen der vorliegenden Einreichung auf spezifische Ausprägungen von Prozess, Maschine, Fertigung, Zusammensetzung, Mittel, Methoden, und Schritte, wie in der Spezifikation beschrieben, einzuschränken. Jemand mit üblichen Fachkenntnissen wird sofort durch die Veröffentlichung der vorliegenden Erfindung erkennen, welche Prozesse, Maschinen, Fertigung, Zusammensetzung, Mittel, Methoden, oder Schritte, die aktuell exisitieren oder entwickelt werden, diesselbe Funktion oder im wesentlichen dasselbe Ergebnis liefern wie entsprechende Ausprägungen, die hier beschrieben werden, gemäss der vorliegenden Erfindung genutzt werden können. Demgemäß ist die Intention der angefügten Ansprüche, in ihrem Rahmen solche Prozesse, Maschinen, Fertigung, Zusammensetzung, Mittel, Methoden, oder Schritte zu inkludieren.

Claims

Ein Verfahren zur Computer-basierten Simulation eines Echtzeitsystems, das eine Anwendungs-Softwareumfasst, die auf einer Ziel-Hardware-Plattform auszuführen ist, die Anwendungs-Software besteht aus zumindest zwei Tasks mit unterschiedlicher Priorität, und jede Task beinhaltet eine Menge von Anweisungen; das Verfahren umfasst: das Definieren von zumindest einem Access Point für jede Task bei einer Anweisung, die zumindest einen der folgenden Punkte repräsentiert: – den Einstiegspunkt einer Task, – den Ausstiegspunkt einer Task, – einen Zugriff auf einen gemeinsamen Speicher (Shared Memory), – einen Zugriff auf ein Register der Ziel-Hardware-Plattform, – einen Aufruf einer Betriebssystem-Funktion oder einer Treiber-Funktion der Ziel-Plattform, sodass die Tasks in Anweisungs-Blöcke aufgeteilt werden; das Zuordnen einer Ausführungszeit auf der Zielplattform (Target Execution Time) zu jedem Anweisungsblock, wobei die Ausführungszeit jene Zeit ist, die benötigt wird, um den Anweisungsblock auf dem Zielsystem auszuführen; das Durchführen einer diskreten Ereignissimulation mittels einer Ereignis-Warteschlange, wobei jedes Ereignis mit einer Task, einem Access Point einer Task und einem Ereignis-Zeitstempel assoziiert ist; wobei während der Verarbeitung eines Ereignisses der Anweisungsblock, der mit dem dem Ereignis zugeordneten Access Pointkorrespondiert, ohne Unterbrechung ausgeführt wird.
Das Verfahren gemäß Anspruch 1 wobei während der Verarbeitung eines Ereignisses: ein neues Ereignis, das mit dem nächsten Access Point der Task assoziiert ist, zur Ereignis-Warteschlange hinzugefügt wird, und zwar mit einem Zeitstempel, der vom Zeitstempel des aktuellen Ereignisses und der Target Execution Time, die dem ausgeführten Anweisungsblock zugeordnet ist, abhängt.
Das Verfahren gemäß Anspruch 1 oder 2, wobei vor der Ausführung der Task, die mit dem Ereignis assoziiert ist: die Task, die mit der höchsten Priorität auszuführen ist, zum Ereignis-Zeitstempel ermittelt wird, und wenn die ermittelte Task die Task ist, die mit dem Ereignis assoziiert ist, und wenn der assoziierte Access Point kein Ausstiegspunkt ist, der das Aussetzen der Ausführung der Task erfordert, wird der Anweisungsblock, der beim Access Point, der mit dem Ereignis assoziiert ist, ohne Unterbrechung ausgeführt.
Das Verfahren gemäß Anspruch 1, 2 oder 3, wobei ein neues Ereignis zur Ereignis-Warteschlange hinzugefügt wird, wann immer eine externe Bedingung eine neue Ausführung einer Task oder die Fortsetzung einer zuletzt ausgesetzten Task-Ausführung erfordert, wobei das Ereignis mit einem Zeitstempel assoziiert wird, der dem erforderlichen Startzeitpunkt der Task-Ausführung entspricht.
Das Verfahren gemäß einem der Ansprüche 1 bis 4, wobei während der Verarbeitung des aktuellen Ereignisses: die assoziierte Task als ”laufend” markiert wird, wenn ein Anweisungsblock der Task ausgeführt wird, oder die assoziierte Task als ”bereit” markiert wird, wenn es eine andere ”laufende” Task mit höherer Priorität gibt, oder die assoziierte Task als ”ausgesetzt” markiert wird, wenn die vorige Markierung laufend war, und das Ereignis entweder mit einer Ausstiegs-(= Exit-)Stelle der Task oder mit einem Access Point, der einen Systemaufruf darstellt, der erfordert, dass die Task wartet, bevor die Ausführung fortgesetzt wird, assoziiert ist.
Das Verfahren gemäß einem der Ansprüche 1 bis 5, wobei während der Verarbeitung des aktuellen Ereignisses: eine Task, die nicht mit einem gerade verarbeiteten Ereignis assoziiert ist, als ”unterbrochen” markiert wird, wenn die Markierung der Task unmittelbar vor dem Ereignis auf laufend war, und wenn die Task, die mit dem Ereignis assoziiert ist, als ”laufend” markiert ist.
Das Verfahren gemäß Anspruch 6, in der die verbleibende Ausführungszeit, die für den unterbrochenen Anweisungsblock benötigt wird, für eine künftige Nutzung gespeichert wird.
Das Verfahren gemäß einem der Ansprüche 1 bis 7, wobei während der Verarbeitung des aktuellen Ereignisses: eine Task, die nicht mit dem aktuellen Ereignis assoziiert ist, als ”laufend” markiert wird, wenn die vorige Markierung der Task ”unterbrochen” oder ”bereit” war, die Task die höchste Ausführungspriorität unter allen unterbrochenen oder bereiten Tasks hat, und die Task, die mit dem Ereignis assoziiert ist, als ”ausgesetzt” markiert ist.
Das Verfahren gemäß Anspruch 8, in der ein neues Ereignis, das mit der laufenden Task assoziiert ist, in die Ereignis-Warteschlange hinzugefügt wird, und zwar mit einem Zeitstempel, der vom Zeitstempel des aktuellen Ereignisses und von der gespeicherten verbleibenden Ausführungszeit der gerade laufenden Task abhängt.
Ein Computer-Programm, das auf einem Informationsverarbeitungsgerät gespeichert ist, wobei das Computer-Programm Anweisungen enthält, die, wenn sie ausgeführt werden, eine der Verfahren gemäß den Ansprüchen 1 bis 9 durchführen.
Ein Computer-basiertes System zur Simulation eines Echtzeitsystems, das Anwendungs-Software umfasst, die auf einer Ziel-Hardware-Plattform auszuführen ist, wobei die Anwendungs-Software aus zumindest zwei Tasks mit unterschiedlicher Priorität besteht, und jede Task eine Menge von Anweisungen beinhaltet; wobei zumindest ein Access Point für jede Task definiert ist, und zwar bei einer Anweisung, die eines der folgenden Punkte darstellt – den Anfang einer Task, – das Ende einer Task, – einen Zugriff auf einen gemeinsamen Speicher (= Shared Memory), – einen Zugriff auf ein Register der Ziel-Hardware-Plattform, – einen Aufruf einer Betriebssystem-Funktion oder einer Treiber-Funktion der Ziel-Plattform, sodass die Tasks in Anweisungs-Blöcke aufgeteilt werden; wobei die Ausführungszeit auf der Zielplattform, die die Zeit repräsentiert, wie lange die Ausführung des Anweisungsblocks auf dem Zielsystem dauert, jedem Anweisungsblock zugewiesen wird; wobei das System Mittel zur Durchführung einer diskreten Ereignissimulation unter Benutzung einer Ereigniswarteschlange umfasst, wobei jedes Ereignis mit einer Task, dem Access Point einer Task, und einem Ereignis-Zeitstempel assoziiert ist, wobei während der Verarbeitung eines Ereignisses: die Task, die mit dem Ereignis assoziiert ist, ohne Unterbrechung ausgeführt wird, beginnend beim Access Point, der mit dem Ereignis assoziiert ist, und ein neues Ereignis, das mit dem nächsten Access Point der Task assoziiert ist, zur Ereignis-Warteschlange hinzugefügt wird, und zwar mit einem Zeitstempel, der vom Zeitstempel des aktuellen Ereignisses und der Target Execution Time, die dem ausgeführten Anweisungsblock zugeordnet ist, abhängt.