DE102019216684A1

DE102019216684A1 - Verfahren zur Timinganalyse von Anwendungssoftware für ein eingebettetes System, Vorrichtung zur Datenverarbeitung, Computerprogramm und Computerlesbarer Datenträger

Info

Publication number: DE102019216684A1
Application number: DE102019216684.9A
Authority: DE
Inventors: Matthias Glück
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2019-10-29
Filing date: 2019-10-29
Publication date: 2021-04-29
Anticipated expiration: 2039-10-30
Also published as: DE102019216684B4

Abstract

Verfahren (40) zur Timinganalyse von Anwendungssoftware für ein eingebettetes System, die mindestens einen Task (1, 10) aufweist, welcher mehrere Software-Komponenten (2-5, 11-15, 31) aufweist, umfassend:Erzeugen (41) eines Hardware-Modells der Anwendungssoftware, welches zur Timinganalyse der Anwendungssoftware mittels eines Hardware-Timinganalysators verwendbar ist.

Description

Die Erfindung betrifft ein Verfahren zur Timinganalyse von Anwendungssoftware für ein eingebettetes System, eine Vorrichtung zur Datenverarbeitung, Computerprogramm und computerlesbarer Datenträger.
Eingebettete Systeme bestehen typischerweise aus Hardware und Software, die in ein komplexes technisches System eingebettet sind, wie z.B. Steuergeräte in Kraftfahrzeugen. Die eingebetteten Systeme können in dem technischen System verschiedene Steuerungs-, Regelungs- und Datenverarbeitungsaufgaben übernehmen.
Es ist bekannt, dass eingebettete Systeme typischerweise ein bestimmtes Echtzeitverhalten aufweisen müssen, um eine korrekte Funktionalität des technischen Systems zu gewährleisten. Der Zeitdauer für die Signalaufnahme und deren Verarbeitung können im Allgemeinen enge Grenzen gesetzt sein. Zum Beispiel muss eine Steuerung für einen Airbag, die Messwerte mehrerer Sensoren aufnehmen und verarbeiten, um innerhalb einer vorgegebenen Reaktionszeit eine Entscheidung zu treffen, ob der Airbag ausgelöst wird oder nicht. In solchen Beispielen ist ein hartes Echtzeitverhalten erforderlich (harte Echtzeitanforderungen), womit generell das Bereitstellen von korrekten Ergebnissen innerhalb einer vorgegebenen Zeitdauer gemeint sein kann.
Im Kraftfahrzeugumfeld, insbesondere für autonome Kraftfahrzeuge, werden daher im Rahmen der funktionalen Sicherheitsentwicklung nach ISO 26262 („Road vehicles - Functional Safety“) Timinganalysen der Software gefordert. Bei einer Timinganalyse wird das Zeitverhalten bzw. der Zeitablauf (Timing) der Software auf dem eingebetteten System für verschiedene Bedingungen untersucht und verifiziert. Eine vollständige Timinganalyse von Software ist sehr komplex und zeitaufwändig und daher kostenintensiv. Heutige Werkzeuge zur Timinganalyse von Software für eingebettete Systeme arbeiten typischerweise auf statischen Analyseverfahren, die dynamische Eigenschaften und/oder Zeitbedingungen möglicherweise nur unzureichend modellieren können.
Hingegen sind im Halbeleiterbereich Timinganalysen essentiell und es existieren dort umfangreiche und genaue Timinganalysatoren, die auch als Signoff-Werkzeuge bekannt sind. Ein Werkzeug aus diesem Bereich ist beispielsweise Synopsys PrimeTime® Software. Weitere Verfahren zur Untersuchung des Zeitverhaltens sind im Bereich der Hardware-Entwicklung bekannt.
Aus der Übersetzung der europäischen Patentschrift DE 692 29 889 T2 ist beispielsweise ein System zur automatischen Erzeugung von Simulationsmodellen, insbesondere für digitale Logikschaltkreise, bekannt. Unter anderem werden automatisch zeitablaufbezogene Parameter aus einem Schaltkreisebenen-Simulationsergebnis bereitgestellt, welche automatisch in Logik- und Zeitablaufmodelle eingegliedert werden können. Die Funktions- und Zeitablaufgenauigkeit der erzeugten Modelle kann überprüft werden.
Des Weiteren ist z.B. in der europäischen Patentschrift EP 0 563 597 B1 ein in Hardware ausgeführter elektronischer ASIC-Prototyper (Application Specific Integrated Circuit) gezeigt, der es ermöglicht integrierte Schaltkreise bzw. ASIC's zu emulieren, sodass ein Testen des zu schaffenden Bauteils in der späteren Hardware-Umgebung (Zielplattform) möglich ist. Die Emulation kann dabei unter Einbeziehung des Zeitverhaltens der zu entwickelnden Schaltung erfolgen.
Eine Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur Timinganalyse von Anwendungssoftware für ein eingebettetes System, eine Vorrichtung zur Datenverarbeitung, ein Computerprogramm und einen computerlesbaren Datenträger bereitzustellen, das die obengenannten Nachteile wenigstens teilweise überwindet.
Diese Aufgabe wird durch das erfindungsgemäße Verfahren nach Anspruch 1, der Vorrichtung zur Datenverarbeitung nach Anspruch 13, dem Computerprogramm nach Anspruch 14 und dem computerlesbaren Datenträger nach Anspruch 15 gelöst.
Gemäß einem ersten Aspekt stellt die vorliegende Erfindung ein Verfahren zur Timinganalyse von Anwendungssoftware für ein eingebettetes System, die mindestens einen Task aufweist, welcher mehrere Software-Komponenten aufweist, umfassend:

Erzeugen eines Hardware-Modells der Anwendungssoftware, welches zur Timinganalyse der Anwendungssoftware mittels eines Hardware-Timinganalysators verwendbar ist.

Gemäß einem zweiten Aspekt stellt die vorliegende Erfindung eine Vorrichtung zur Datenverarbeitung, umfassend Mittel zur Ausführung der Schritte des Verfahrens nach dem ersten Aspekt.
Gemäß einem dritten Aspekt stellt die vorliegende Erfindung ein Computerprogramm, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das Verfahren nach dem ersten Aspekt auszuführen.
Gemäß einem vierten Aspekt stellt die vorliegende Erfindung einen computerlesbaren Datenträger, auf dem das Computerprogramm nach dem dritten Aspekt gespeichert ist.
Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen und der folgenden Beschreibung bevorzugter Ausführungsbeispiele der vorliegenden Erfindung.
Wie erwähnt, betreffen manche Ausführungsbeispiele ein Verfahren zur Timinganalyse von Anwendungssoftware für ein eingebettetes System, die mindestens einen Task aufweist, welcher mehrere Software-Komponenten aufweist, umfassend:

Wie eingangs ausgeführt, werden in heutigen Werkzeugen zur Timinganalyse von Software für eingebettete Systeme (bspw. Steuergeräte in einem Kraftfahrzeug) typischerweise statische Analyseverfahren eingesetzt. Bei diesen Verfahren kann ein Modell der Hardware zugrunde gelegt werden, auf denen die Timinganalyse erfolgt. Das Modell der Hardware kann eine händische Laufzeitmessung auf den Zielplattformen (bspw. Zielsteuergeräte oder Zielhardware) sein. Dabei können einzelne Softwareinstruktionen (Software-Komponenten) laufzeitmäßig vermessen werden. Diese können anschließend mittels einer Programmflussanalyse zu einem WCET (Worst Case Execution Timing) Pfad zusammengesetzt werden. Allerdings werden möglicherweise die dynamischen Eigenschaften und/oder Zeitbedingungen nicht oder nur unzureichend modelliert bzw. berücksichtigt. Das hierin vorgestellte Verfahren geht darüber hinaus und ermöglicht auch die Analyse des Einflusses eines Betriebssystems („Operating System“), Unterbrechungen („Interrupts“), Ausnahmen („Exceptions“) und anderen dynamischen Eigenschaften des eingebetteten Systems.
Daher wird das Verfahren in manchen Ausführungsbeispielen zur Timinganalyse von Anwendungssoftware für ein eingebettetes System verwendet und bspw. für Steuergeräte im Kraftfahrzeugumfeld eingesetzt, ohne das die Erfindung auf diese Fälle beschränkt ist. Dabei kann die Anwendungssoftware grundsätzlich zunächst als Quelltext vorliegen, ohne das die Erfindung auf diese Fälle beschränkt ist.
Eine Timinganalyse kann in manchen Ausführungsbeispielen eine vollständige Analyse und/oder Simulation bzw. ein vollständiger Bericht des Zeitverhaltens einer oder mehrerer Funktionalitäten (auch Tasks im Folgenden genannt) bedeuten, die durch eine Anwendungssoftware für ein eingebettetes System bereitgestellt werden kann. Dabei können bei manchen Ausführungsbeispielen kritische Pfade im Programmablauf aufgezeigt werden. In anderen Ausführungsbeispielen kann dies nur einen Teil der Funktionalität umfassen.
Eine Anwendungssoftware kann in manchen Ausführungsbeispielen ein Programm bzw. ein Quelltext des Programms sein, welches eine oder mehrere Tasks aufweist und auf einem eingebetteten System laufen kann, um dem eingebetteten System seine Funktionalität verleihen zu können. Die Anwendungssoftware kann bei manchen Ausführungsbeispielen als grafische Modellierung vorliegen (ein bekanntes Werkzeug in diesem Bereich ist beispielsweise ANSYS® SCADE® Software). In solchen Ausführungsbeispielen kann der Quelltext aus dem grafischen Modell erstellt werden. Insbesondere in Ausführungsbeispielen, die sich auf Software im Kraftfahrzeugumfeld beziehen, kann Anwendungssoftware die Anwendungsschicht in der AUTOSAR (AUTomotive Open System ARchitecture) bedeuten, ohne das die Erfindung auf diese Fälle beschränkt ist.
Ein eingebettetes System kann grundsätzlich ein System sein, welches aus Hardware und Software besteht, welches in ein größeres komplexes technisches System eingebettet ist, um Steuerungs-, Regelungs- und Datenverarbeitungsaufgaben zu übernehmen. Bei manchen Ausführungsbeispielen kann das eingebettete System ein Betriebssystem aufweisen, was grundsätzlich bekannt ist. In manchen Ausführungsbeispielen kann das eingebettete System ein Steuergerät oder ein Bordcomputer in einem Kraftfahrzeug sein. Das eingebettete System kann bei manchen Ausführungsbeispielen auch auf mehrere Steuergeräte, Bordcomputer oder dergleichen verteilt sein, wobei in solchen Ausführungsbeispielen Daten über eine Kommunikationsschnittstelle ausgetauscht werden können. Das eingebettete System kann dabei einen oder mehrere Prozessoren mit einen oder mehreren Kernen, Speicherelemente, Kommunikationsschnittstellen (drahtgebunden oder drahtlos) und dergleichen aufweisen. Das eingebettete System kann ein FPGA (Field Programmable Gate Array), ein DSP (digitaler Signalprozessor) oder dergleichen sein bzw. aufweisen. Das eingebettete System weist dabei in manchen Ausführungsbeispielen eine vorgegebene Taktrate auf zur zeitlichen Koordination und Synchronisation auf, wobei mit der Taktrate ein Clock-Signal (Taktsignal) erzeugt wird, was grundsätzlich bekannt ist.
Ein Task kann in manchen Ausführungsbeispielen ein Prozess bzw. Funktion oder ein Thread bzw. ein Quelltext des Prozesses bzw. Funktion sein, der eine Funktionalität des eingebetteten Systems bereitstellen kann. Im Kraftfahrzeugumfeld bei autonomen Fahrzeugen kann z.B. ein erster Task eine Überprüfung sein, ob ein Bremsvorgang des Fahrzeugs eingeleitet werden muss. Diese kann bspw. auf Daten einer Objekterkennung beruhen, welche durch einen zweiten Task ausgeführt wird, die bspw. eine Datenaufnahme und -verarbeitung verschiedener Sensorsignale (z.B. optische Kameras) zur Objekterkennung aufweist und ein Ergebnis (z.B. eine Distanz und/oder eine Veränderung der Distanz) an den ersten Task übergibt. Ein Task kann in manchen Ausführungsbeispielen einen oder mehrere Eingangswerte und einen oder mehrere Ausgangswerte haben. Mehrere Tasks können bei manchen Ausführungsbeispielen untereinander Daten austauschen, welche z.B. berechnete Werte sind, die von einer Task an eine andere übergeben werden. Ein oder mehrere Tasks können in manchen Ausführungsbeispielen von einem Betriebssystem aufgerufen, neu initialisiert („Reset“) oder unterbrochen werden. Ein Task kann bei manchen Ausführungsbeispielen eine oder mehrere Software-Komponenten aufweisen, wobei die einzelnen Software-Komponenten der Task nacheinander abgearbeitet werden können. Eine Laufzeit, welche eine Zeitdauer beschreibt, die benötigt wird, um ein Ausgangswert bereitzustellen, kann in manchen Ausführungsbeispielen von Task zu Task sehr unterschiedlich sein.
Eine Software-Komponente kann in manchen Ausführungsbeispiel eine Teil-Funktionalität bzw. ein Quelltext der Teil-Funktionalität der zugehörigen Task sein. Eine Software-Komponente kann in manchen Ausführungsbeispielen ein in sich geschlossener Bearbeitungsstrang sein. Dies kann z.B., wie oben erwähnt, eine Datenaufnahme verschiedener Sensorsignale sein oder die Verarbeitung dieser Sensorsignale sein oder das Abspeichern eines Ergebnisses (z.B. eine Distanz bei einer Objekterkennung) in einem Speicherelement oder dergleichen sein. Eine Software-Komponente kann bei manchen Ausführungsbeispielen einen oder mehrere Befehle bzw. eine Abfolge von Befehlen aufweisen, wobei ein Befehl eine einzelne Anweisung eines Programms sein kann wie bspw. ein Speicherzugriff, eine Berechnung (Addition, Multiplikation, etc.), eine Zuweisung, ein Vergleich zwischen zwei Werten oder dergleichen, die von einem eingebetteten System ausgeführt werden kann. Eine Software-Komponente kann einen oder mehrere Eingangswerte und einen oder mehrere Ausgangswerte haben. Mehrere Software-Komponenten einer Task können bei manchen Ausführungsbeispielen untereinander Daten austauschen, welche z.B. berechnete Werte sind, die von einer Software-Komponente an eine andere übergeben werden.
Wie oben erwähnt, existieren im Halbleiterbereich umfangreiche und genaue Werkzeuge zur Timinganalyse, die bei ihrer Analyse auf Hardware-Beschreibungssprachen (HDL) wie bspw. Verilog oder VHDL (Very High Speed Integrated Circuit Hardware Description Language) basieren. Hingegen wird typischerweise eine Anwendungssoftware für ein eingebettetes System, insbesondere im Kraftfahrzeugumfeld, in einer höheren Programmiersprache (bspw. C, C++, C#, Java, Python und/oder dergleichen) geschrieben. Daher sind die Werkzeuge zur Timinganalyse aus dem Halbleiterbereich zunächst nicht für eine Anwendungssoftware eines eingebetteten Systems zugänglich.
Daher wird in manchen Ausführungsbeispielen ein Hardware-Modell der Anwendungssoftware erzeugt, welches zur Timinganalyse der Anwendungssoftware mittels eines Hardware-Timinganalysators verwendbar ist.
Das erzeugte Hardware-Modell kann in manchen Ausführungsbeispielen eine Abbildung der einzelnen Tasks und deren Software-Komponenten durch mehrere einfache Logikgatter sein. Dabei kann das erzeugte Hardware-Modell bzw. die Abbildung der einzelnen Tasks und deren Software-Komponenten grundsätzlich durch eine Hardware-Beschreibungssprache derart dargestellt werden, dass das Zeitverhalten der Anwendungssoftware für das eingebettete System genau modelliert ist und durch ein entsprechenden Hardware-Timinganalysator analysiert werden kann (Timinganalyse). Hierin kann daher „aufweisen“ in manchen Ausführungsbeispielen als entsprechende Abbildung/Modellierung in einer Hardware-Beschreibungssprache aufzufassen sein. Bei manchen Ausführungsbeispielen kann das erzeugte Hardware-Modell mehrere Zeitbedingungen (Time Constraints) aufweisen. In solchen Ausführungsbeispielen kann das Hardware-Modell die Zeitbedingungen bspw. als SDF-Datei (Standard Delay Format) aufweisen. In weiteren Ausführungsbeispielen kann das erzeugte Hardware-Modell einen Multiplexer aufweisen, um Unterbrechungen durch ein Betriebssystem des eingebetteten Systems zu modellieren. In solchen Ausführungsbeispielen können auch Ausnahmen modelliert werden, welche z.B. bei einer Berechnung auftreten können. Das erzeugte Hardware-Modell kann in manchen Ausführungsbeispielen ein oder mehrere logische Speicherelemente aufweisen, die einen oder mehrere Signaleingänge aufweisen können. In solchen Ausführungsbeispielen kann an einem Signaleingang ein Taktsignal anliegen und an einem anderen ein berechneter Ausgangswert einer Software-Komponente oder einer Task, wodurch das Zeitverhalten einer Wertübergabe und eine entsprechende Synchronisation modelliert werden kann.
Wie oben erwähnt, kann ein Hardware-Timinganalysator in manchen Ausführungsbeispielen ein umfangreiches Programm sein, welches eine genaue Timinganalyse eines Hardware-Modells durchführen kann. Durch eine genaue Abbildung einer Anwendungssoftware eines eingebetteten Systems auf ein Hardware-Modell kann somit bei manchen Ausführungsbeispielen eine sehr genaue Timinganalyse der Anwendungssoftware durchgeführt werden.
Grundsätzlich kann das Verfahren daher als eine Erzeugung eines Hardware-Modells einer Anwendungssoftware für ein eingebettetes System aufgefasst werden, um es den aus dem Halbleiterbereich bekannten Werkzeugen (Hardware-Timinganalysatoren) zugänglich zu machen bzw. durch einen Hardware-Timinganalysator verwendbar ist. In manchen Ausführungsbeispielen kann die Timinganalyse der Anwendungssoftware für das eingebettete System mittels eines Hardware-Timinganalysators durchgeführt werden.
Dies ist vorteilhaft, da die Hardware-Timinganalysatoren sehr umfangreich und genau sind. Dadurch ist die Timinganalyse der Anwendungssoftware in manchen Ausführungsbeispielen deutlich genauer möglich. Des Weiteren können durch die Nutzung der Hardware-Timinganalysatoren Pfade der Anwendungssoftware, die durch die Dynamik der Anwendungssoftware von den aktuellen bekannten statischen Analyseverfahren nicht berechnet würden, erkannt und berichtet werden. Im Allgemeinen kann dadurch die Robustheit und Zuverlässigkeit der Anwendungssoftware verbessert und somit die Funktionalität des eingebetteten Systems. In Ausführungsbeispielen im Kraftfahrzeugumfeld lässt sich damit Anwendungssoftware bspw. für autonom fahrende Kraftfahrzeuge genauer analysieren und absichern.
Dabei kann, wie oben erwähnt, die Anwendungssoftware grundsätzlich zunächst als Quelltext vorliegen. Die oben beschriebenen Merkmale der Anwendungssoftware, der Tasks und der Software-Komponenten sind dann zunächst als Merkmale des Quelltexts im Kontext des eingebetteten Systems aufzufassen, welche in ein Hardware-Modell transformiert werden. Die Anwendungssoftware für das eingebettetes System muss aber auf dem eingebetteten System bzw. der Zielplattform ausführbar sein, um die durch den Quelltext beschriebene Funktionalität bereitzustellen und um in manchen Ausführungsbeispielen Laufzeiten der Software-Komponenten auf der Zielplattform für verschiedene Startwerte zu ermitteln, um das Hardware-Modell zu erzeugen.
In manchen Ausführungsbeispielen weist das Erzeugen des Hardware-Modells ein Erzeugen je eines Software-Komponenten-Modells von jeder der Software-Komponenten basierend auf einer kombinatorischer Logik und mindestens einem ersten logischen Speicherelement auf.
Ein Software-Komponenten-Modell kann dabei bei manchen Ausführungsbeispielen eine Abbildung/Modellierung der Software-Komponente (bzw. dessen Quelltext) in einer Hardware-Beschreibungssprache sein, die die Logik der Abfolge von Befehlen der Software-Komponente basierend auf einer kombinatorischen Logik und mindestens einem ersten logischen Speicherelement wiedergibt. In anderen Ausführungsbeispielen kann das Software-Komponenten-Modell eine durch Text und/oder Zeichen und/oder grafischen Darstellungen oder dergleichen wiedergegebene Abbildung/Modellierung der Logik der Abfolge von Befehlen der Software-Komponente basierend auf einer kombinatorischen Logik und mindestens einem ersten logischen Speicherelement sein. Das Software-Komponenten-Modell kann dabei grundsätzlich von einem Computer gelesen und bearbeitet werden. Für jede der Software-Komponenten kann ein entsprechendes Software-Komponenten-Modell erzeugt werden.
Eine kombinatorische Logik kann dabei in manchen Ausführungsbeispielen eine Menge an logischen Verknüpfungen (AND, OR, NOT, NAND, NOR, XOR, etc.) zwischen Eingangswerten, die an einer Eingangskomponente der kombinatorischen Logik erhalten werden, und Ausgangswerten, die an einer Ausgangskomponente bereitgestellt werden, sein. In solchen Ausführungsbeispielen entsprechen die Eingangswerte den an die Software-Komponente übergebenen Werten, wenn diese auf einem eingebetteten System ausgeführt wird, und die Ausgangswerte den durch die Software-Komponente berechneten/ermittelten Werten. Die Eingangswerte und Ausgangswerte (Datensignale) können in manchen Ausführungsbeispielen durch eine Abfolge von binären Werten dargestellt werden und aus den logischen Verknüpfungen können kompliziertere Befehle/Berechnungen abgebildet werden, was grundsätzlich bekannt ist, sodass die kombinatorische Logik die Logik der Abfolge von Befehlen der Software-Komponente wiedergeben kann.
Ein erstes logisches Speicherelement kann dabei in manchen Ausführungsbeispielen ein Latch, ein Flipflop oder dergleichen sein, welches eindeutig in dem Software-Komponenten-Modell abgebildet ist. Dadurch kann in solchen Ausführungsbeispielen ein Speichern der Ausgangswerte modelliert werden, um eine Übergabe von Werten bzw. Datenaustausch zwischen mehreren Software-Komponenten wiederzugeben. In manchen Ausführungsbeispielen können dadurch Speicherzugriffe (bspw. DMA (Direct Memory Access)) abgebildet werden. Die ersten logischen Speicherelemente können einen oder mehrere Signaleingänge und Signalausgänge aufweisen, wie oben erwähnt, an denen bspw. ein Taktsignal, ein Reset-Signal (Rücksetzsignal) oder Ausgangswerte (Datensignal) der kombinatorischen Logik anliegen. An den Signalausgängen können Datensignale ausgegeben werden. Insbesondere können in solchen Ausführungsbeispielen Einstell- und Haltezeiten (Setup- und Hold-Time) modelliert werden.
Wie oben ausgeführt, weist die kombinatorische Logik in manchen Ausführungsbeispielen in jedem Software-Komponenten-Modell eine Eingangskomponente zum Erhalten von Eingangswerten und eine Ausgangskomponente zum Bereitstellen von Ausgangswerten auf.
In manchen Ausführungsbeispielen ist mindestens eines der ersten logischen Speicherelemente ein D-Flipflop.
Ein D-Flipflop kann typischerweise mehrere Signaleingänge und Signalausgänge aufweisen, insbesondere einen Dateneingang an dem ein Datensignal anliegt, einen Taktsignaleingang an dem ein Taktsignal anliegt, einen Rücksetzeingang an dem ein Rücksetzsignal anliegt und einen Datenausgang zum Speichern des am Dateneingang anliegenden Datensignals. In manchen Ausführungsbeispielen können daher Einstell- und Haltezeiten durch einen Zeitunterschied zwischen Änderungen an den Signaleingängen und Änderungen am Signalausgang modelliert werden, um eine genauere Abbildung und Analyse des Zeitverhaltens der Software-Komponente zu ermöglichen. Dies ist vorteilhaft, da dadurch problematische Verletzungen der Einstell- und Haltezeiten entdeckt werden können und somit eine fehlerhafte Übergabe von Werten bzw. Daten in der Anwendungssoftware behoben werden kann. Dadurch kann die Zuverlässigkeit und Robustheit der Anwendungssoftware verbessert werden.
In manchen Ausführungsbeispielen weist das Erzeugen des Hardware-Modells ein Erzeugen eines Task-Modells der Task basierend auf den Software-Komponenten-Modellen und mindestens einem zweiten logischen Speicherelement auf.
Wie oben für das Software-Komponenten-Modell ausgeführt, kann ein Task-Modell dabei bei manchen Ausführungsbeispielen eine Abbildung/Modellierung der Task (bzw. dessen Quelltext) in einer Hardware-Beschreibungssprache sein, die die Logik der Abfolge von Befehlen der Task basierend auf den Software-Komponenten-Modellen und mindestens einem zweiten logischen Speicherelement wiedergibt. In anderen Ausführungsbeispielen kann das Task-Modell eine durch Text und/oder Zeichen und/oder grafischen Darstellungen oder dergleichen wiedergegebene Abbildung/Modellierung der Logik der Abfolge von Befehlen der Task basierend auf den Software-Komponenten-Modellen und mindestens einem zweiten logischen Speicherelement sein. Das Task-Modell kann dabei grundsätzlich von einem Computer gelesen und bearbeitet werden. Für jede der Tasks kann ein entsprechendes Task-Modell erzeugt werden.
Wie oben für die ersten logischen Speicherelemente ausgeführt, kann ein zweites logisches Speicherelement dabei in manchen Ausführungsbeispielen ein Latch, ein Flipflop oder dergleichen sein, welches eindeutig in dem Task-Modell abgebildet ist. Dadurch kann in solchen Ausführungsbeispielen ein Speichern der Ausgangswerte modelliert werden, um eine Übergabe von Werten bzw. Datenaustausch zwischen mehreren Tasks und/oder Software-Komponenten wiederzugeben. In manchen Ausführungsbeispielen können dadurch Speicherzugriffe (bspw. DMA (Direct Memory Access)) abgebildet werden. Die zweiten logischen Speicherelemente können einen oder mehrere Signaleingänge und Signalausgänge aufweisen, wie oben erwähnt, an denen bspw. ein Taktsignal, ein Reset-Signal (Rücksetzsignal) oder Ausgangswerte (Datensignal) der Software-Komponenten-Modelle anliegen. An den Signalausgängen können Datensignale ausgegeben werden. Insbesondere können in solchen Ausführungsbeispielen Einstell- und Haltezeiten (Setup- und Hold-Time) modelliert werden.
In manchen Ausführungsbeispielen ist mindestens eines der zweiten logischen Speicherelement ein D-Flipflop, welches die oben für das erste logische Speicherelement ausgeführten Merkmale aufweisen kann.
In manchen Ausführungsbeispielen ist ein Signalausgang eines der zweiten logischen Speicherelemente in dem Task-Modell mit der Eingangskomponente der kombinatorischen Logik einer der Software-Komponenten-Modelle verbunden.
Dies ist vorteilhaft, da dadurch modelliert werden kann, dass Ausgangswerte einer Task aus einer vorherigen Berechnung für die aktuelle Berechnung benutzt werden können, wodurch bspw. eingebettete System, die in einem Regelkreis eingesetzt werden, abgebildet werden können.
In manchen Ausführungsbeispielen weist das Erzeugen des Hardware-Modells ein Erhalten von Ausführungszeiten von jeder der Software-Komponenten auf.
Eine Ausführungszeit einer Software-Komponente kann in manchen Ausführungsbeispielen eine Zeitdauer sein, die die Software-Komponente auf einem eingebetteten System benötigt, um alle Befehle abgearbeitet zu haben und einen Ausgangswert bereitzustellen. Im Allgemeinen kann die Ausführungszeit einer Software-Komponente in einem eingebetteten System abhängig von den Startparametern, den Ausführungszeiten anderer Software-Komponenten, Speicherzugriffszeiten, Taktraten und/oder dergleichen abhängen. Daher kann bei manchen Ausführungsbeispielen eine Menge von Ausführungszeiten erhalten werden, die für verschiedene Startparameter ermittelt wurden. In solchen Ausführungsbeispielen kann aus der Menge an Ausführungszeiten minimale und maximale Ausführungszeiten bestimmt werden. Aus den Ausführungszeiten der Software-Komponenten können bei manchen Ausführungsbeispielen verschiedene Zeitbedingungen (bspw. Bedingungen an Verzögerungszeiten zwischen verschiedenen Software-Komponenten, minimal und maximal erlaubte Ausführungszeit der Software-Komponente und dergleichen) ermittelt werden. In solchen Ausführungsbeispielen können diese als SDF-Datei abgespeichert werden und Teil des erzeugten Hardware-Modells sein.
Das Erhalten kann bei manchen Ausführungsbeispielen ein Einlesen aus einer Datei, einem Speicher oder dergleichen sein. In anderen Ausführungsbeispielen werden die Ausführungszeiten während der Durchführung des hierin beschriebenen Verfahrens ermittelt und dem Verfahren bereitgestellt.
In manchen Ausführungsbeispielen werden die Ausführungszeiten von jeder der Software-Komponenten auf einer Zielplattform des eingebetteten Systems für verschiedene Startwerte ermittelt.
Eine Zielplattform kann grundsätzlich ein konkretes eingebettetes System sein (bspw. ein Steuergerät in einem Kraftfahrzeug), welches eine vorgegebene Hardware aufweist wie bspw. Taktrate, Speicherelemente, Signaleingänge und -ausgänge und dergleichen.
Die Ausführungszeiten können bei manchen Ausführungsbeispielen dadurch ermittelt werden, dass einzelne Software-Komponenten ausgeführt werden und die Ausführungszeit basierend auf einer Messung von Signalen in dem eingebetteten System bestimmt wird, was grundsätzlich bekannt ist.
Wie oben erwähnt, können die Ausführungszeiten einer Software-Komponente in einem eingebetteten System bei manchen Ausführungsbeispielen abhängig von den Startparametern sein. Daher werden in solchen Ausführungsbeispielen verschiedene Startparameter verwendet, um die Ausführungszeiten auf der Zielplattform zu ermitteln.
In manchen Ausführungsbeispielen weist das Erzeugen des Hardware-Modells ein Erzeugen einer Hardware-Modell-Beschreibung in einer Hardware-Beschreibungssprache basierend auf dem Task-Modell und den erhaltenen Ausführungszeiten auf.
Die Hardware-Modell-Beschreibung kann bei manchen Ausführungsbeispielen dadurch erzeugt werden, dass das oder die Task-Modelle in einer Hardware-Beschreibungssprache vorliegen und die Zeitbedingungen (bspw. minimale und maximale Ausführungszeiten) aus den gemessenen Ausführungszeiten der Software-Komponenten ermittelt wurden, wie oben ausgeführt, und in einer SDF-Datei vorliegen. Die Hardware-Modell-Beschreibung kann in solchen Ausführungsbeispielen in Verilog oder VHDL oder dergleichen vorliegen.
In manchen Ausführungsbeispielen weist das Erzeugen des Hardware-Modells ein Ersetzen der kombinatorischen Logik in der Hardware-Modell-Beschreibung durch Logikgatter auf, um das Hardware-Modell zu erzeugen.
Die kombinatorische Logik der einzelnen Software-Komponenten der Tasks bzw. Anwendungssoftware, die in manchen Ausführungsbeispielen in einer Hardware-Beschreibungssprache vorliegen, kann durch einfache Logikgatter ersetzt werden, was grundsätzlich bekannt ist.
Die Logikgatter können bspw. AND-, OR-, NOT-, NAND-, NOR-, XOR-Gatter oder dergleichen sein. In manchen Ausführungsbeispielen können die Logikgatter durch TTL-Bausteine (Transistor-Transistor-Logik) oder CMOS-Bausteine (Complementary Metal-Oxide-Semiconductor) oder dergleichen modelliert sein. Diese Vereinfachung kann man nutzen und das komplexere und der Anwendungssoftware für das eingebettete System nähere Verhalten zu beschreiben, da das erzeugte Hardware-Modell durch einen Hardware-Timinganalysator verwendbar ist. Dies ist vorteilhaft, da dadurch die Anwendungssoftware in eine Halbleiter-Modellierung transformiert wird und somit den genauen und umfangreichen Hardware-Timinganalysatoren zugänglich gemacht werden, um eine Timinganalyse der Anwendungssoftware durchzuführen.
In manchen Ausführungsbeispielen enthält das Hardware-Modell einen Multiplexer, um Unterbrechungen und Ausnahmen im Ablauf der Anwendungssoftware zu modellieren.
Ein Multiplexer, der grundsätzlich bekannt ist, kann in manchen Ausführungsbeispielen mehrere Signaleingänge aufweisen. In solchen Ausführungsbeispielen kann ein Unterbrechungssignal eines Betriebssystems oder ein Ausnahmesignal an einem der Signaleingänge anliegen und das Unterbrechen der Ausführung einer Task modellieren. Dabei kann in manchen Ausführungsbeispielen der Multiplexer zwischen zwei Software-Komponenten-Modellen liegen, der eine Verlängerung der Ausführung einer Task modelliert. In solchen Ausführungsbeispielen kann ein Unterbrechungssignal am Multiplexer die Ausführung der Task unterbrechen. Dabei kann ein Software-Komponenten-Modell in einem Task-Modell eingefügt werden, welches modelliert, dass für N Taktsignale (N ist positiv ganzzahlig und dabei die Anzahl der möglichen rekursiven Unterbrechungen oder Ausnahmen) die Task unterbrochen wird.
Damit kann in manchen Ausführungsbeispielen das dynamische Verhalten durch Eingriffe Betriebssystems und Unterbrechungen und dergleichen mit dem hierin ausgeführten Verfahren ebenfalls modelliert werden. Dabei können Tasks, die in Suspend gehen (unterbrochen werden), am Taktsignaleingang eines zweiten logischen Speicherelements, bspw. ein D-Flipflop, keine positive Flanke sehen. Dadurch kann ein komplexes Zeitverhalten der Anwendungssoftware für ein eingebettetes System modelliert und durch einen Hardware-Timinganalysator analysiert und berichtet werden.
Manche Ausführungsbeispiele betreffen eine Vorrichtung zur Datenverarbeitung, umfassend Mittel zur Ausführung des hierin beschriebenen Verfahrens.
Eine Vorrichtung zur Datenverarbeitung kann dabei ein Computer, Server, Rechnerverbund (Computercluster, Cloud, etc.) oder dergleichen sein. Ein Mittel kann dabei ein Prozessor, Speicherelemente, ein elektronischer Schaltkreis oder elektronische Komponenten sein, die typischerweise eingesetzt werden, um die hierin beschriebenen Funktion auszuführen.
Manche Ausführungsbeispiele betreffen ein Computerprogramm, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das hierin beschriebene Verfahren auszuführen.
Das Programm kann dabei auf einem Computer, Server, Rechnerverbund und/oder in einer Cloud ausgeführt werden. Der obengenannte Computer kann daher allgemein als Vorrichtung zur Datenverarbeitung aufgefasst werden. In manchen Ausführungsbeispielen, insbesondere bei Ausführungsbeispielen bei denen das Computerprogramm auf einem Rechnerverbund ausgeführt wird, können Schritte des hierin beschriebenen Verfahrens parallel ausgeführt werden. In solchen Ausführungsbeispielen kann eine höhere Komplexitätsanalyse durch parallele Berechnungen erreicht werden.
Manche Ausführungsbeispiele betreffen ein computerlesbaren Datenträger, auf dem das obige Computerprogramm gespeichert ist.
Ein computerlesbarer Datenträger kann dabei ein Halbleiterspeicher, eine magnetische Festplatte, ein optischer Speicher (bspw. DVD, etc.) oder dergleichen sein.
Ausführungsbeispiele der Erfindung werden nun beispielhaft und unter Bezugnahme auf die beigefügte Zeichnung beschrieben, in der:

1 in einem Blockdiagramm ein Ausführungsbeispiel zweier Tasks veranschaulicht;
2 in einem Blockdiagramm ein Ausführungsbeispiel zum Erzeugen eines Software-Komponenten-Modells von einer Software-Komponente veranschaulicht;
3 in einem Blockdiagramm ein erstes Ausführungsbeispiel eines Task-Modells veranschaulicht;
4 in einem Blockdiagramm ein Ausführungsbeispiel eines Hardware-Modells veranschaulicht;
5 in einem Blockdiagramm ein zweites Ausführungsbeispiel eines Task-Modells veranschaulicht;
6 in einem Blockdiagramm ein drittes Ausführungsbeispiel eines Task-Modells veranschaulicht;
7 in einem Blockdiagramm ein viertes Ausführungsbeispiel eines Task-Modells veranschaulicht;
8 in einem Ablaufdiagramm ein Ausführungsbeispiel eines Verfahrens zur Timinganalyse von Anwendungssoftware für ein eingebettetes System; und
9 in einem Blockdiagramm ein Ausführungsbeispiel einer Vorrichtung zur Datenverarbeitung veranschaulicht.
1 veranschaulicht in einem Blockdiagramm das Ausführungsbeispiel zweier Tasks (1, 10).

Jeder der beiden in 1 veranschaulichten Tasks (1, 10) einer Anwendungssoftware (im AUTOSAR-Kontext) weist mehrere Software-Komponenten (2-5, 11-15) auf. In diesem Ausführungsbeispiel ist der erste Task 1 eine Funktion in einem Bordcomputer eines autonomen Kraftfahrzeugs, welche überprüft, ob ein Bremsvorgang eingeleitet werden muss. Das autonome Kraftfahrzeug wird in diesem Ausführungsbeispiel zunächst durch einen Fahrer gefahren, aber kann grundsätzlich auch automatisiert betrieben werden. Der zweite Task 10 ist eine Funktion in dem Bordcomputer des Kraftfahrzeugs, welche eine kontinuierliche Erkennung von Objekten in einer Umgebung des autonomen Kraftfahrzeugs durchführt.
Der erste Task 1 ist in mehrere Software-Komponenten 2-5 unterteilt, die verschiedene Teilberechnungen der Task 1 ausführen. Dabei geht der Programmfluss von oben nach unten durch, d.h. für den ersten Task 1 von 2 über 3 nach 4 und nach 5. Ein Datenaustausch ist durch die Verbindungslinien und Pfeile veranschaulicht. Jede im ersten Task 1 aufgerufene Software-Komponente 2-5 übernimmt Werte/Daten aus der vorherigen Software-Komponente 2-5. Die Software-Komponenten 2, 4 und 5 erhalten Werte von anderen Software-Komponenten, die extern zum ersten Task 1 laufen. Die Software-Komponenten 3-5 erzeugen Werte für andere Software-Komponenten 2 und 3.
Der zweite Task 10 ist in mehrere Software-Komponenten 11-15 unterteilt, die verschiedene Teilberechnungen der Task 10 ausführen. Dabei geht der Programmfluss von oben nach unten durch, d.h. für den zweiten Task 10 von 11 über 12 nach 13 nach 14 und nach 15. Ein Datenaustausch ist durch die Verbindungslinien und Pfeile veranschaulicht. Jede im zweiten Task 10 aufgerufene Software-Komponente 11-15 übernimmt Werte/Daten aus der vorherigen Software-Komponente 11-15. Die Software-Komponenten 11, 13 und 14 erhalten Werte von anderen Software-Komponenten, die extern zum zweiten Task 10 laufen. Die Software-Komponenten 13 und 14 erzeugen Werte für andere Software-Komponenten 11 und 13. Die Laufzeiten der beiden Tasks (1, 10) sind unterschiedlich, was unter anderem durch die unterschiedliche Anzahl an Software-Komponenten (2-5, 11-15) der beiden Tasks (1, 10) veranschaulicht wird.
2 veranschaulicht in einem Blockdiagramm ein Ausführungsbeispiel zum Erzeugen eines Software-Komponenten-Modells 2a von einer Software-Komponente 2.
In 2 wird exemplarisch anhand von der Software-Komponente 2 aus 1 ein Erzeugen eines Software-Komponenten-Modells 2a basierend auf einer kombinatorischen Logik 20 und einem ersten logischen Speicherelement veranschaulicht. In diesem Ausführungsbeispiel ist das erste logische Speicherelement ein D-Flipflop 21. Die kombinatorische Logik 20 enthält eine Menge an logischen Verknüpfungen, die Teilberechnung der Software-Komponente 2 abbildet und liegt in einer Hardware-Beschreibungssprache vor. Die kombinatorische Logik 20 hat eine Eingangskomponente (nicht gezeigt), um die Werte anderer Software-Komponenten zu erhalten und eine Ausgangskomponente (nicht explizit gezeigt), die einen berechneten logischen Wert an einen Dateneingang 22 des D-Flipflops 21 ausgibt (illustriert durch den Pfeil). Das D-Flipflop 21 erhält das Taktsignal des Bordcomputers an einem Taktsignaleingang 23 und übernimmt den Ausgangswert der kombinatorischen Logik, der am Dateneingang 22 anliegt, um ihn an einem Datenausgang 24 bereitzustellen. Die Software-Komponente 2 wird in dem Software-Komponenten-Modell durch ein Rücksetzsignal an einem Rücksetzeingang 25 neu initialisiert. Das Software-Komponenten-Modell 2a erlaubt somit eine Modellierung der Software-Komponente 2 in einer Hardware-Modell-Beschreibung.
3 veranschaulicht in einem Blockdiagramm das erste Ausführungsbeispiel eines Task-Modells 1a.
In dem Task-Modell 1a sind alle Software-Komponenten 2-5 aus 1 durch ihre zugehörigen Software-Komponenten-Modelle 2a-5a gemäß 2 ersetzt. Das Task-Modell 1a weist ein zweites logisches Speicherelement auf, welches in diesem Ausführungsbeispiel ebenfalls ein D-Flipflop ist 21. Das D-Flipflop 21 erhält das Taktsignal des Bordcomputers an einem Taktsignaleingang 23 und übernimmt den Ausgangswert aus dem Software-Komponenten-Modell 5a, der am Dateneingang 22 anliegt, um ihn an einem Datenausgang 24 bereitzustellen. Der Task 1 wird in dem Task-Modell 1a durch ein Rücksetzsignal an einem Rücksetzeingang 25 neu initialisiert. Der Datenausgang 24 des D-Flipflop 21 ist mit der Eingangskomponente (nicht gezeigt) der kombinatorischen Logik 20 des Software-Komponenten-Modells 2a verbunden, sodass der Ausgangswert des Task-Modells 1a einer vorherigen Ausführung der Task 1 für eine aktuelle Ausführung zur Verfügung steht. Das Task-Modell 1a entspricht somit einer Modellierung der Task 1 in einer Hardware-Modell-Beschreibung.
4 veranschaulicht in einem Blockdiagramm das Ausführungsbeispiel eines Hardware-Modells 35.
In 4 ist ein Hardware-Modell 35 der Task 1 aus 1 veranschaulicht. Das Hardware-Modell 35 wurde basierend auf dem Task-Modell 1a und erhaltenen Ausführungszeiten der einzelnen Software-Komponenten 2-5 erzeugt. Die Ausführungszeiten wurden auf dem Bordcomputer für verschiedene Startwerte ermittelt, wodurch Zeitbedingungen erhalten wurden, die in dem Hardware-Modell 35 als SDF-Datei (nicht gezeigt) hinterlegt sind. In den Software-Komponenten-Modelle 2a-5a wurde die kombinatorische Logik 20 durch einfache Logikgatter ersetz, um eine Hardware-Modell-Beschreibung 2aa-5aa zu erzeugen. Das Hardware-Modell enthält ein D-Flipflop 21.
Mit diesem Hardware-Modell 35 haben die Hardware-Timinganalysatoren aus dem Halbleiterbereich die Möglichkeit, die Timinganalyse des Tasks 1 selber über alle Kombinationsmöglichkeiten der kombinatorischen Logik 20 und deren ersten logischen Speicherelementen zu berechnen.
Die Taktsignal-zu-Datenausgang Verzögerung entspricht dabei der Verzögerung bei Anliegen einer Flanke des Taktsignals am Taktsignaleingang 23 bis sich die Änderungen am Dateneingang 22 am Datenausgang 24 bemerkbar machen. Dadurch lassen sich Verletzungen der Einstell- und Haltezeiten mit dem Hardware-Timingsanalysator auffinden.
In der Anwendungssoftware, die in diesem Ausführungsbeispiel im AUTOSAR-Kontext Anwendung findet, lässt sich mit dem Hardware-Modell 35 ebenfalls das Abspeichern der Ausgangswerte der Task 1 in Speicherelementen über die Taktsignal-zu-Datenausgang Verzögerung modellieren. Die Taktsignal-zu-Datenausgang Verzögerung ist das bei dem Speichervorgang der Ausgangswerte in der Anwendungssoftware im AUTOSAR-Kontext bevor die Berechnung der Kette im Task selber startet. Der finale Speichervorgang am Ende der Kette kann in dem Hardware-Modell 35 durch einen zusätzlichen Kreis eingefügt und modelliert werden.
5 veranschaulicht in einem Blockdiagramm das zweite Ausführungsbeispiel eines Task-Modells 10a.
In dem Task-Modell 10a sind alle Software-Komponenten 11-15 aus 1 durch ihre zugehörigen Software-Komponenten-Modelle 11a-15a gemäß 2 ersetzt. Das Task-Modell 10a weist ein zweites logisches Speicherelement auf, welches in diesem Ausführungsbeispiel ebenfalls ein D-Flipflop ist 21. Das D-Flipflop 21 erhält das Taktsignal des Bordcomputers an einem Taktsignaleingang 23 und übernimmt den Ausgangswert aus dem Software-Komponenten-Modell 15a, der am Dateneingang 22 anliegt, um ihn an einem Datenausgang 24 bereitzustellen. Der Task 10 wird in dem Task-Modell durch ein Rücksetzsignal an einem Rücksetzeingang 25 neu initialisiert. Der Datenausgang 24 des D-Flipflop 21 ist mit der Eingangskomponente der kombinatorischen Logik 20 des Software-Komponenten-Modells 11a verbunden, sodass der Ausgangswert des Task-Modells 10a einer vorherigen Ausführung der Task 10 für eine aktuelle Ausführung zur Verfügung steht. Das Task-Modell 10a entspricht somit einer Modellierung der Task 10 in einer Hardware-Modell-Beschreibung.
6 veranschaulicht in einem Blockdiagramm das dritte Ausführungsbeispiel eines Task-Modells.
In diesem Ausführungsbeispiel fährt das autonome Kraftfahrzeug aus 1 automatisiert, sodass die beiden Tasks 1 und 10 Werte zwischen einzelnen Software-Komponenten austauschen. Die Objekterkennung der Task 10 übergibt Distanzwerte des autonomen Kraftfahrzeugs zu Objekten und die Veränderung dieser Distanzwerte an den Task 1, welche überprüft, ob ein Bremsvorgang eingeleitet werden muss. Der Task 1 übergibt ein Bremssignal an den Task 10. Diese Abhängigkeiten sind in dem Task-Modell dieses Ausführungsbeispiels durch Verbindungen zwischen den Task-Modell 1a und 10a dargestellt.
Die zu den Task-Modellen 1a und 10a korrespondierenden Tasks 1 und 10 laufen auf unterschiedlichen Kernen eines Prozessors des Bordcomputers, die kein ganzzahliges Vielfaches einer Aufruffrequenz durch den Prozessor haben. Dadurch wird das Alter (Datums- und Signalalter) der durch die Tasks berechneten Werte verletzt und es kommt zu falschen berechneten Zwischenergebnissen. Eine Erzeugung eines Hardware-Modells basierend auf den Task-Modellen 1a und 10a und Ausführungszeiten der Software-Komponenten (2-5, 11-15) gemäß 4 ermöglicht dann den Halbleiter-Timinganalysatoren diese problematischen Pfade in der Anwendungssoftware zu berichten. Dies ist vorteilhaft, da dadurch die Robustheit und Zuverlässigkeit der Anwendungssoftware verbessert werden kann.
7 veranschaulicht in einem Blockdiagramm das vierte Ausführungsbeispiel eines Task-Modells.
Dabei zeigt 7 wie Unterbrechungen und Ausnahmen, die einen Task unterbrechen, modelliert werden. Die Software-Komponenten-Modellen etc. entsprechen denen aus vorgehenden Figuren. Zwischen den Software-Komponenten-Modellen 11a und 12a des Task-Modells 10a ist ein Multiplexer 30 eingefügt. Ein Software-Komponenten-Modell 31 modelliert, dass für N Taktsignale der Task unterbrochen wird (veranschaulicht durch den Pfeil, der ausgehend von dem Software-Komponenten-Modell 31 wieder zu sich selbst zurückführt). Der Multiplexer 30 schaltet zwischen dem Software-Komponenten-Modell 11a und dem Software-Komponenten-Modell 31, falls ein Unterbrechungssignal an Multiplexer 30 anliegt (unterer Pfeil am Multiplexer 30) oder eine Ausnahme in der Software-Komponente 11 auftritt, die durch das Software-Komponenten-Modell 11a modelliert wird. Ohne Unterbrechung oder Ausnahme geht es mit dem Software-Komponenten-Modell 12a weiter.
8 veranschaulicht in einem Ablaufdiagramm das Verfahren 40 zur Timinganalyse von Anwendungssoftware für ein eingebettetes System.
Bei 41 wird ein Hardware-Modell der Anwendungssoftware erzeugt, welches zur Timinganalyse der Anwendungssoftware mittels eines Hardware-Timinganalysators verwendbar ist, wie hierin ausgeführt.
Bei 42 wird je ein Software-Komponenten-Modell von jeder der Software-Komponenten basierend auf einer kombinatorischer Logik und mindestens einem ersten logischen Speicherelement erzeugt, wie hierin ausgeführt.
Bei 43 weist die kombinatorische Logik in jedem Software-Komponenten-Modell eine Eingangskomponente zum Erhalten von Eingangswerten und eine Ausgangskomponente zum Bereitstellen von Ausgangswerten auf, wie hierin ausgeführt.
Bei 44 ist mindestens eines der ersten logischen Speicherelemente ein D-Flipflop, wie hierin ausgeführt.
Bei 45 wird ein Task-Modell der Task basierend auf den Software-Komponenten-Modellen und mindestens einem zweiten logischen Speicherelement erzeugt, wie hierin ausgeführt.
Bei 46 ist mindestens eines der zweiten logischen Speicherelemente ein D-Flipflop, wie hierin ausgeführt.
Bei 47 ist ein Signalausgang eines der zweiten logischen Speicherelemente in dem Task-Modell mit der Eingangskomponente der kombinatorischen Logik einer der Software-Komponenten-Modelle verbunden, wie hierin ausgeführt.
Bei 48 werden Ausführungszeiten von jeder der Software-Komponenten erhalten, wie hierin ausgeführt.
Bei 49 werden die Ausführungszeiten von jeder der Software-Komponenten auf einer Zielplattform des eingebetteten Systems für verschiedene Startwerte ermittelt, wie hierin ausgeführt.
Bei 50 wird eine Hardware-Modell-Beschreibung in einer Hardware-Beschreibungssprache basierend auf dem Task-Modell und den erhaltenen Ausführungszeiten erzeugt, wie hierin ausgeführt.
Bei 51 wird die kombinatorischen Logik in der Hardware-Modell-Beschreibung durch Logikgatter ersetzt, um das Hardware-Modell zu erzeugen, wie hierin ausgeführt.
Bei 52 enthält das Hardware-Modell einen Multiplexer, um Unterbrechungen und Ausnahmen im Ablauf der Anwendungssoftware zu modellieren, wie hierin ausgeführt.
9 veranschaulicht in einem Blockdiagramm das Ausführungsbeispiel einer Vorrichtung 62 zur Datenverarbeitung.
Ein Computerprogramm 60 ist auf einem computerlesbaren Datenträger 61 gespeichert, welcher in diesem Ausführungsbeispiel eine magnetische Festplatte ist. Das Computerprogram enthält Befehle, die bei der Ausführung des Programms durch eine Vorrichtung 62 zur Datenverarbeitung diesen veranlassen, das hierin beschriebene Verfahren auszuführen. In diesem Ausführungsbeispiel ist die Vorrichtung 62 zur Datenverarbeitung ein Computer.
Bezugszeichenliste

1, 10: Task
1a, 10a: Task-Modell
2-5, 11-15, 31: Software-Komponente
2a-5a, 11a-15a: Software-Komponenten-Modell
2aa-5aa: Hardware-Modell-Beschreibung
20: kombinatorische Logik
21: D-Flipflop
22: Dateneingang
23: Taktsignaleingang
24: Rücksetzeingang
25: Datenausgang
30: Multiplexer
35: Hardware-Modell
40: Verfahren zur Timinganalyse von Anwendungssoftware für ein eingebettetes System
60: Computerprogramm
61: computerlesbarer Datenträger
62: Vorrichtung zur Datenverarbeitung

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

DE 69229889 T2 [0006]
EP 0563597 B1 [0007]

Claims

Verfahren (40) zur Timinganalyse von Anwendungssoftware für ein eingebettetes System, die mindestens einen Task (1, 10) aufweist, welcher mehrere Software-Komponenten (2-5, 11-15, 31) aufweist, umfassend: Erzeugen (41) eines Hardware-Modells (35) der Anwendungssoftware, welches zur Timinganalyse der Anwendungssoftware mittels eines Hardware-Timinganalysators verwendbar ist.
Verfahren (40) nach Anspruch 1, wobei das Erzeugen des Hardware-Modells (35) aufweist: Erzeugen (42) je eines Software-Komponenten-Modells (2a-5a, 11a-15a) von jeder der Software-Komponenten (2-5, 11-15, 31) basierend auf einer kombinatorischer Logik (20) und mindestens einem ersten logischen Speicherelement.
Verfahren (40) nach Anspruch 2, wobei die kombinatorische Logik (20) in jedem Software-Komponenten-Modell (2a-5a, 11a-15a) eine Eingangskomponente zum Erhalten von Eingangswerten und eine Ausgangskomponente zum Bereitstellen von Ausgangswerten aufweist (43).
Verfahren (40) nach Anspruch 2 oder 3, wobei mindestens eines der ersten logischen Speicherelemente ein D-Flipflop (21) ist (44).
Verfahren (40) nach einem der Ansprüche 2 bis 4, wobei das Erzeugen des Hardware-Modells (35) aufweist: Erzeugen (45) eines Task-Modells (1a, 10a) der Task (1, 10) basierend auf den Software-Komponenten-Modellen (2a-5a, 11a-15a) und mindestens einem zweiten logischen Speicherelement.
Verfahren (40) nach Anspruch 5, wobei mindestens eines der zweiten logischen Speicherelement ein D-Flipflop (21) ist (46).
Verfahren (40) nach Anspruch 5 oder 6, wobei ein Signalausgang eines der zweiten logischen Speicherelemente in dem Task-Modell (1a, 10a) mit der Eingangskomponente der kombinatorischen Logik (20) einer der Software-Komponenten-Modelle (2a-5a, 11a-15a) verbunden ist (47).
Verfahren (40) nach einem der Ansprüche 1 bis 7, wobei das Erzeugen des Hardware-Modells (35) aufweist: Erhalten (48) von Ausführungszeiten von jeder der Software-Komponenten (2-5, 11-15).
Verfahren (40) nach Anspruch 8, wobei die Ausführungszeiten von jeder der Software-Komponenten (2-5, 11-15) auf einer Zielplattform des eingebetteten Systems für verschiedene Startwerte ermittelt wurden (49).
Verfahren (40) nach Anspruch 8 oder 9 soweit dieser von Anspruch 5 abhängt, wobei das Erzeugen des Hardware-Modells (35) aufweist: Erzeugen (50) einer Hardware-Modell-Beschreibung (2aa-5aa) in einer Hardware-Beschreibungssprache basierend auf dem Task-Modell (1a, 10a) und den erhaltenen Ausführungszeiten.
Verfahren (40) nach Anspruch 10, wobei das Erzeugen des Hardware-Modells (35) aufweist: Ersetzen (51) der kombinatorischen Logik (20) in der Hardware-Modell-Beschreibung (2aa-5aa) durch Logikgatter, um das Hardware-Modell (35) zu erzeugen.
Verfahren (40) nach einem der vorherigen Ansprüche, wobei das Hardware-Modell einen Multiplexer (30) enthält, um Unterbrechungen und Ausnahmen im Ablauf der Anwendungssoftware zu modellieren (52).
Vorrichtung (61) zur Datenverarbeitung, umfassend Mittel zur Ausführung der Schritte des Verfahrens nach einem der Ansprüche 1 bis 12.
Computerprogramm (60), umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das Verfahren nach einem der Ansprüche 1 bis 12 auszuführen.
Computerlesbarer Datenträger (62), auf dem das Computerprogramm (60) nach Anspruch 14 gespeichert ist.