-
Die Erfindung betrifft ein Verfahren zum Prüfen der Funktionsfähigkeit einer eingebetteten Komponente in einem eingebetteten System.
-
Aus dem Dokument
US 2007/0192076 A1 ist ein Validierungsverfahren für eingebettete Systeme bekannt. Dort wird vorgeschlagen, zur Prüfung der Funktionsfähigkeit einer eingebetteten Komponente diese mit bestimmten Anfragen, die von der Komponente erwartet werden, zu überprüfen. Es wird festgestellt, ob die vorgegebenen Antworten tatsächlich geliefert werden.
-
Die Druckschrift
EP 1 549 092 A1 betrifft die Analyse des Datenverkehrs in einem Netzwerk. Durch die Analyse sollen Probleme in einen Telekommunikationsnetzwerk identifiziert und anschließend so schnell wie möglich beseitigt werden.
-
In der
DE 100 57 651 C2 wird ein Verfahren zur Herstellung eines computergestützten Echtzeitsystems vorgeschlagen.
-
Die Druckschriften
US 2005/0025062 A1 ,
EP 1 401 147 B1 ,
US 2006/0120282 A1 und
DE 197 03 090 A1 betreffen den technologischen Hintergrund der vorliegenden Erfindung.
-
Bei einem eingebetteten System handelt es sich um einen elektronischen Rechner oder Computer, der in einem technischen Kontext eingebunden bzw. eingebettet ist. Dabei hat der elektronische Rechner die Aufgabe, das System, in welches er eingebettet ist, zu steuern, zu regeln oder zu überwachen.
-
Ein eingebettetes System verrichtet – weitestgehend unsichtbar für den Benutzer – den Dienst in einer Vielzahl von Anwendungsbereichen und Geräten, wie z. B. in Waschmaschinen, Flugzeugen, Kraftfahrzeugen, Kühlschränken, Fernsehern, DVD-Playern, Mobiltelefonen u. dgl.. Eine Vernetzung einer Vielzahl von ansonsten autonomen, eingebetteten Systemen wird auch als komplexes eingebettetes System bezeichnet.
-
Die elektronischen Rechner eines komplexen eingebetteten Systems sind in der Regel zum Datenaustausch mit einem Bus verbunden. Üblicherweise handelt es sich bei einer Komponente um eine gemischte Hardware/Software-Implementierung, welche eine vorgegebene Spezifikation erfüllt.
-
Auch wenn die Komponenten eines komplexen eingebetteten Systems für sich genommen, die vorgegebenen Spezifikationen erfüllen, kann es beim Zusammenwirken der Komponenten im komplexen eingebetteten System dennoch zu Funktionsstörungen kommen. Solche Funktionsstörungen können durch eine Nichteinhaltung von Reaktions- oder Antwortzeiten auf bestimmte Ereignisse, durch Aus- oder Überlastung von Prozessoren oder Bussen und dgl. hervorgerufen werden. Zur Beseitigung derartiger Funktionsstörungen ist es mitunter erforderlich, Hardware/Software-Implementierungen von Komponenten zu ändern. Das ist kosten- und zeitaufwendig.
-
Aufgabe der vorliegenden Erfindung ist es, die Nachteile nach dem Stand der Technik zu beseitigen. Es soll insbesondere ein Verfahren zum Prüfen der Funktionsfähigkeit einer eingebetteten Komponente in einem eingebetteten System angegeben werden, welches einfach und kostengünstig durchführbar ist. Nach einem weiteren Ziel der Erfindung soll das Verfahren schon in einem frühen Entwicklungsstadium eines eingebetteten Systems verlässliche Informationen über dessen Funktionsfähigkeit liefern.
-
Diese Aufgabe wird durch die Merkmale des Anspruchs 1 gelöst. Zweckmäßige Ausgestaltungen ergeben sich aus den Merkmalen der Ansprüche 2 bis 14.
-
Nach Maßgabe der Erfindung ist ein Verfahren zum Prüfen der Funktionsfähigkeit einer eingebetteten Komponente in einem eingebetteten System vorgesehen, bei dem die eingebettete Komponente und zumindest eine weitere eingebettete Komponente zum Datenaustausch über einen Bus verbunden sind,
wobei die zumindest eine weitere eingebettete Komponente und eine damit erzeugte Ausgabe erster Nachrichtenpakete auf den Bus mittels eines ersten Simulationsprogrammabschnitts simuliert wird,
wobei der erste Simulationsprogrammabschnitt einen Datenpaketerzeugungsabschnitt zur Erzeugung einer Abfolge von mit einer Priorisierung versehenen ersten Datenpaketen und einen Datenpaketumwandlungsabschnitt zur Umwandlung der ersten Datenpakete in die Abfolge der ersten Nachrichtenpakete und zur Ausgabe der Abfolge der ersten Nachrichtenpakete auf den Bus umfasst,
wobei die eingebettete Komponente, eine damit erzeugte Ausgabe zweiter Nachrichtenpakete auf dem Bus und/oder eine Verarbeitung von für die eingebettete Komponente vorgesehenen ersten Nachrichtenpaketen mittels eines zweiten Simulationsprogrammabschnitts simuliert wird, und
wobei die Funktionsfähigkeit der eingebetteten Komponente durch einen Vergleich des Zeitverhaltens von damit erzeugten Signalen gegenüber einem vorgegebenen Zeitverhalten ermittelt wird.
-
Im Sinne der vorliegenden Erfindung wird unter dem Begriff ”eingebettete Komponente” eine zu testende Hardware/Software-Implementierung verstanden. Unter dem Begriff ”weitere eingebettete Komponente” wird eine weitere Hardware/Software-Implementierung verstanden, welche zum Datenaustausch über einen Bus mit der ”eingebetteten Komponente” verbunden ist. Die ”eingebettete Komponente” und die über einen Bus damit verbundene zumindest eine ”weitere eingebettete Komponente” bilden das ”eingebettete System”.
-
In dem sowohl die eingebettete Komponente als auch die weitere eingebettete Komponente sowie die damit erzeugte Ausgabe erster und zweiter Nachrichtenpakete auf dem Bus und/oder eine Verarbeitung von für die eingebettete Komponente vorgesehene erste Nachrichtenpaketen mittels eines Simulationsprogramms simuliert wird, kann ohne großen Aufwand frühzeitig die Funktionsfähigkeit eines eingebetteten Systems geprüft werden. Sowohl die eingebettete Komponente als auch die weitere eingebettete Komponente werden mittels des vorgeschlagenen Simulationsprogramms simuliert. Es entfällt die Notwendigkeit der Bereitstellung entsprechender Hardware/Software-Implementierungen.
-
Unter dem Begriff ”Bus” wird im Sinne der vorliegenden Erfindung ein Kommunikationsweg verstanden, der eine Übertragung von Nachrichtenpaketen im Multiplexverfahren ermöglicht.
-
Im Sinne der vorliegenden Erfindung werden unter ”Nachrichtenpaket” Informationssequenzen verstanden, die in ihrem Volumen realen Nachrichtenpaketen entsprechen, und die weiterhin in exakt denselben zeitlichen Abständen wie in einem realen eingebetteten System auf den Bus ausgegeben werden. Die Nachrichtenpakete im Sinne der vorliegenden Erfindung können in Abhängigkeit einer Busbelastung auch verzögert auf den Bus ausgegeben werden. Sie können unter Vorgabe bestimmter Schranken stochastisch erzeugt werden, wobei sowohl das Volumen als auch der Ausgabezeitpunkt auf den Bus variiert werden kann. Ferner können Nachrichtenpakete im Sinne der vorliegenden Erfindung reelle Dateninhalte transportieren, welche mit der zu testenden eingebetteten Komponente verarbeitet und infolge dessen Funktionen ausgelöst werden können.
-
Als besonders vorteilhaft wird es angesehen, dass der Bus ein durch das Simulationsprogramm erzeugter virtueller Bus ist. In diesem Fall wird mit dem vorgeschlagenen Verfahren also das eingebettete System insgesamt durch das Simulationsprogramm simuliert. Das Vorsehen eines physischen Busses ist nicht erforderlich.
-
Die mit dem vorgeschlagenen Verfahren erzeugten ”Nachrichtenpakete” entsprechen zweckmäßigerweise den Nachrichtenpaketen, wie sie im späteren implementierten eingebetteten System verwendet werden.
-
Nach einer weiteren vorteilhaften Ausgestaltung wird mit dem Datenpaketerzeugungsabschnitt jedem der ersten Datenpakete ein vorgegebener Zeitstempel zugeordnet. Bei einem ”Zeitstempel” handelt es sich um eine Zeitinformation welche angibt, wann genau das betreffende erste Datenpaket auf den Bus ausgegeben werden soll.
-
Um eine besonders realitätsnahe Simulation zu gewährleisten ist nach einer weiteren Ausgestaltung vorgesehen, dass der weiteren Komponente eine lokale Uhr zugeordnet ist. Unter einer ”lokalen Uhr” wird eine absolute Zeitbasis verstanden, auf deren Grundlage ein der weiteren eingebetteten Komponente zugeordneter Taktgeber arbeitet. Eine solche lokale Uhr kann ebenfalls mit einem Programm simuliert werden. Es wird beispielhaft verwiesen auf den Offenbarungsgehalt der
DE 100 57 651 C2 , welche hiermit einbezogen wird.
-
Mit dem Datenpaketerzeugungsabschnitt ist es auch möglich mehrere weitere eingebettete Komponenten zu simulieren. In diesem Fall kann mit dem Datenpaketerzeugungsabschnitt jedem der ersten Datenpakete eine Information über die Art der weiteren eingebetteten Komponente zugeordnet werden. In diesem Fall kann jeder weiteren Komponente wiederum eine besondere lokale Uhr zugeordnet sein.
-
Nach einer weiteren Ausgestaltung ist vorgesehen, dass mit dem Datenpaketerzeugungsabschnitt bestimmte erste Datenpakete wiederholend erzeugt und mit einem Zeitstempel versehen werden. Damit können zyklisch wiederkehrende Prozesse im eingebetteten System simuliert werden.
-
Des Weiteren kann der Datenpaketerzeugungsabschnitt einen Scheduler umfassen, mit dem die ersten Datepakete entsprechend ihrer Zeitstempel und/oder gemäß einer Priorisierung an den Datenpaketumwandlugsabschnitt übergeben werden. Bei der ”Priorisierung” handelt es sich um eine Information, welche gemäß einer vorgegebenen Regel in Abhängigkeit eines Typs und/oder eines aktuellen Zustands des Busses erzeugt wird.
-
Nach einer weiteren besonders vorteilhaften Ausgestaltung wird mit dem Datenpaketumwandlungsabschnitt zur Simulation von Busstörungen die Ausgabe der ersten Nachrichtenpakete auf den Bus um zufällig erzeugte Verzögerungszeitabschnitte verzögert und/oder die Inhalte der ersten Nachrichtenpakete verändert. Damit wird weiter die Realitätsnähe des vorgeschlagenen Simulationsprogramms erhöht.
-
Bei den von der eingebetteten Komponente erzeugten Signalen kann es sich um auf den Bus ausgegebene zweite Nachrichtenpakete handeln. Es kann sich bei den Signalen aber auch um Funktionen handeln, welche durch die Verarbeitung von für die eingebettete Komponente vorgesehenen ersten Nachrichtenpaketen ausgelöst werden. Bei ”für die eingebettete Komponente vorgesehenen ersten Nachrichtenpaketen” handelt es sich um eine Teilmenge der ersten Nachrichtenpakete, welche explizit an die eingebettete Komponente adressiert sind. – Die Verarbeitung solcher an die eingebettete Komponente adressierter erster Nachrichtenpakete löst Funktionen aus. Das Zeitverhalten derartiger Funktionen und/oder das Zeitverhalten der von der eingebetteten Komponente auf den Bus ausgegebenen zweiten Nachrichtenpakete dient der Prüfung der Funktionsfähigkeit der eingebetteten Komponente. Dazu wird das jeweils beobachtete Zeitverhalten mit einem vorgegebenen Zeitverhalten, z. B. einem spezifizierten Zeitverhalten, verglichen.
-
Die Ausgabe der zweiten Nachrichtenpakete auf den Bus kann durch einen im zweiten Simulationsprogrammabschnitt vorgesehenen ereignisbasierten Simulator veranlasst werden. Derartige ereignisbasierte Simulatoren sind nach dem Stand der Technik allgemein bekannt. Es wird dazu beispielhaft verwiesen auf die für diesen Zweck definierten Simulationssprachen SystemC und VHDL.
-
Des Weiteren wird es als vorteilhaft angesehen, dass zur Ermittlung des Zeitverhaltens der zweiten Nachrichtenpakete und/oder des Zeitverhaltens von mit der eingebetteten Komponente ausgeführten Funktionen eine Protokolldatei erzeugt wird. Ferner kann die Funktionsfähigkeit der eingebetteten Komponente auch durch eine geeignete Grafik an einem Bildschirm dargestellt werden.
-
Nachfolgend werden Ausführungsbeispiele anhand der Zeichnung näher erläutert. Es zeigen:
-
1 Schematisch die Architektur eines erfindungsgemäßen Simulationsprogramms,
-
2 schematisch den Aufbau einer Einparkhilfe in einem Kraftfahrzeug und
-
3 eine Architektur eines Simulationsprogramms für das in 2 gezeigte Beispiel.
-
Mit dem Bezugszeichen 1 ist ein virtueller Bus bezeichnet, der eine oder mehrere zu testende eingebettete Komponenten 2 zum Nachrichtenaustausch mit zumindest einer weiteren eingebetteten Komponente 3 verbindet. Die weitere eingebettete Komponente 3 wird mit einem ersten Simulationsprogrammabschnitt 4 und die eingebettete Komponente 2 mit einem zweiten Simulationsprogrammabschnitt 5 eines Simulationsprogramms simuliert.
-
Der erste Simulationsprogrammabschnitt 4 umfasst eine Sollvorgaben-Tabelle 6, einen Datenpaketerzeugungsabschnitt 7, einen Insert-Algorithmus 8, einen Datenpaket-Speicher 9, einen Scheduler 10 und einen Datenpaketumwandlungsabschnitt 11. Dem Datenpaketerzeugungsabschnitt 7 sind hier eine lokale Uhr 12 sowie ein stochastischer Jitter 13 zugeordnet.
-
Der zweite Simulationsprogrammabschnitt 5 umfasst für jede zu testende eingebettete Komponente 2 jeweils einen ereignisbasierten Simulator 14 in Kombination mit einem weiteren Datenpaketumwandlungsabschnitt 15, mit welchem zweite Datenpakete in zweite Nachrichtenpakete umgewandelt und auf den virtuellen Bus 1 ausgegeben werden.
-
Die Funktion des ersten Simulationsprogrammabschnitts 4 ist folgende:
Jede simulierte weitere eingebettete Komponente 3 liefert eine vorgegebene Abfolge von jeweils mit einem Zeitstempel versehenen ersten Datenpaketen. Die ersten Datenpakete werden vom Datenpaketumwandlungsabschnitt 11 in erste Nachrichtenpakete, z. B. durch Hinzufügen eines Headers u. s. w., umgewandelt und auf den virtuellen Bus 1 ausgegeben.
-
In der Sollvorgaben-Tabelle
6 sind insbesondere die zu übertragenden Daten sowie die zugehörigen Zeitinformationen t
soll, d, wie beispielsweise Periode und Offset für zyklisch zu wiederholende erste Nachrichtenpakete enthalten. Die Sollvorgaben-Tabelle
6 kann beispielsweise in ihren Spalten die folgenden Angaben enthalten:
Versendemodus | Quelle | Varianzen lokale Uhr | Zeitinformationen | Verweis auf Nachrichtenpaket |
| | | | | | | |
- • Versende-Modus
gibt an, ob eine Nachricht einmal (kein Eintrag), mehrmals (Eintrag: Anzahl), zyklisch (Eintrag: zyklisch) oder in zufälligen Abständen (Eintrag: stochastisch) und Ausprägungen versandt werden soll;
- • Quelle,
gibt an, von welcher weiteren Komponente die Nachricht erzeugt wurde;
- • Varianzen lokale Uhr,
enthält Angaben, die benötigt werden, um die Zeiten auf eine systemglobale Zeitbasis transponieren zu können. Da im Allgemeinen jede weitere Komponente über genau eine lokale Uhr verfügt, kann diese Angaben auch in einer gesonderten Liste verwaltet werden, auf die z. B. über die Spalte Quelle (s. o.) verwiesen wird.
-
Zeitinformationen
sind zusätzliche Angaben für die zyklische oder stochastische Generierung von Nachrichten, wie z. B. Periode und Offset.
-
Wenn die Liste Angaben zu Abweichungen der lokalen Uhren enthält, kann die Zeitgenauigkeit der Simulation dadurch verbessert werden, dass die angegebenen Zeiten, insbesondere die Zeitstempel auf eine systemglobale Zeitbasis transponiert werden. Dazu kann ein Verfahren benutzt werden, wie es z. B. in der
DE 100 57 651 C2 beschrieben ist.
-
Aus Zeiteffizienz- und -genauigkeitsgründen ist es sinnvoll, die Zeiten gleich zu Beginn der Simulation zu transponieren und alle in die Sollvorgaben-Tabelle 6 neu einzutragenden Zeitstempel vor deren Eintrag auf die globale Zeitbasis umzurechnen.
- • Verweis auf Nachrichten-Paket,
stellt formal die Nachricht dar, die versendet werden soll, d. h. die Nachricht kann eine, vorzugsweise gleichlange, leere Hülle oder mit Original-Inhalt gefüllt sein, etwa folgendermaßen:
Message | ID | Datum 1 | Datum 2 | ... |
- – Message ID
vom simulierten Bus abhängiger Parameter;
- – Datum l bis n
Parameter, welcher die aktuelle Belegung mit Daten, die in Nachrichten verpackt werden sollen, anzeigt.
-
Aus den in der Sollvorgaben-Tabelle 6 enthaltenen Daten erzeugt der Datenpaketerzeugungsabschnitt 7 erste Datenpakete und ordnet jedem ersten Datenpaket einen Zeitstempel zu.
-
Die Zeitstempel tnom, d können dabei auf der Grundlage einer von der lokalen Uhr 12 gelieferten Zeit erstellt werden. Zur Simulationszwecken können die Zeitstempel tnom, d durch in der Sollvorgaben-Tabelle 6 enthaltene Varianzen modifiziert werden. Ferner ist es mit dem stochastischen Jitter 13 möglich, die Zeitstempel tnom, d so zu modifizieren, dass beispielsweise durch Verdrängung von Prozessen in den weiteren Komponenten bedingte Verzögerungen simuliert werden können.
-
Die vom Datenpaketerzeugungsabschnitt 7 erzeugten ersten Datenpakete werden mittels des Insert-Algorithmus 8 in eine damit erzeugte Abfolge gebracht und im Datenpaket-Speicher 9 gespeichert.
-
Der Scheduler 10 entnimmt der mittels der Zeitstempel chronologisch sortierten Abfolge der ersten Datenpakete den jeweils zeitlich nächsten Zeitstempel tnom, d und setzt damit seine Aufweckzeit im System. Danach begibt er sich in eine inaktiven Wartezustand. Sobald die Aufweckzeit erreicht wird, wählt der Scheduler 10 gemäß den Eigenschaften des virtuellen Busses 1 das nächste zu sendende erste Datenpaket aus und übergibt es an den Datenpaketumwandlungsabschnitt 11. Ist der virtuelle Bus 1 durch eine gerade laufende Übertragung belegt, so setzt der Scheduler 10 seine Aufweckzeit auf das Ende der gerade laufenden Übertragung.
-
Der Datenpaketumwandlungsabschnitt 11 wandelt das erste Datenpaket in ein erstes Nachrichtenpaket um, in dem beispielsweise dem ersten Datenpaket ein Header und andere übliche Komponenten zugefügt werden. Das erste Datenpaket wird sodann vom Datenpaketumwandlungsabschnitt 11 auf den virtuellen Bus 1 ausgegeben.
-
2 zeigt schematisch den Aufbau einer Einparkhilfe in einem Kraftfahrzeug. Das eingebettete System umfasst einen physischen Bus 16, z. B. Can, Flexray o. dgl.. Am physischen Bus 16 ist eine Einparkhilfe-Steuerung 17 mit Abstandssensoren 18 als zu testende eingebettete Komponente angeschlossen. Ferner sind als weitere Komponenten, welche nicht zu testen sind, am physischen Bus 16 u. a. eine Eingabe-/Ausgabe-Einheit 19 zur Erzeugung eines akustischen Alarms sowie eine Geschwindigkeits-Messeinheit 20 angeschlossen.
-
Hinsichtlich der zu testenden eingebetteten Komponente könnte im vorliegenden Beispiel die Spezifikation verlangen, dass
- a) die Einparkhilfe erst ab einer Geschwindigkeit < 25 km/h aktiv werden darf,
- b) ab einem Abstand < 30 cm ein Alarm in Form von Einzeltönen ausgelöst wird, wobei der Abstand der Töne mit dem gemessenen Abstand von einem Objekt korreliert und
- c) die Höhe des Alarmtones mit zunehmender Geschwindigkeit des Fahrzeugs höher und mit abnehmender Geschwindigkeit tiefer wird.
-
Im Hinblick auf die Funktionsfähigkeit der eingebetteten Komponente sind die Latenzzeiten zwischen dem Erkennen einer Abstands- oder einer Geschwindigkeitsänderung und dem tatsächlichen Auslösen des Alarms zu prüfen.
-
Infolge dessen sind auf dem Bus die folgenden Nachrichten zu simulieren.
- – Nachrichten von der Einparkhilfe-Steuerung 17 an die Eingabe-/Ausgabe-Einheit 19, welche als Dateninhalte Parameter für den Tonfolgen-Abstand und die Tonhöhe enthalten;
- – Nachrichten der Geschwindigkeits-Messeinheit 20 an die Einparkhilfe-Steuerung 17, welche bei einer Geschwindigkeitsänderung < 2 km/h gesendet werden und die Geschwindigkeit als Dateninhalt enthalten;
- – Nachrichten der sonstigen untereinander kommunizierenden weiteren eingebetteten Komponenten.
-
3 zeigt schematisch eine mögliche Architektur eines Simulationsprogramms für das in 2 gezeigte Beispiel. Der erste Simulationsprogrammabschnitt 4 simuliert die Funktionen der in 2 mit einer unterbrochenen Linie umgebenen weiteren eingebetteten Komponenten. Die damit erzeugten ersten Nachrichtenpakete werden über den Datenpaketumwandlungsabschnitt 11 auf den virtuellen Bus 1 ausgegeben. Mit dem zweiten Simulationsprogrammabschnitt 5 wird die in 2 gezeigte Einparkhilfe-Steuerung 17 simuliert. Es werden damit zweite Nachrichtenpakete erzeugt, welche an die in 2 gezeigte Eingabe-/Ausgabe-Einheit 19 adressiert sind.
-
Zur Prüfung der Funktionsfähigkeit der simulierten Einparkhilfe-Steuerung 17 wird das Zeitverhalten der damit erzeugten zweiten Nachrichtenpakete durch einen Vergleich mit einem spezifizierten Zeitverhalten geprüft und ausgewertet. Das spezifizierte Zeitverhalten wird vorteilhafterweise nach dem Stand der Technik auf der Basis von zeitbehafteten Ereignissen beschrieben. Zur Auswertung werden die Zeitstempel der Ereignisse zueinander in Beziehung gesetzt und mit den spezifizierten Zeitschranken verglichen.
-
Bezugszeichenliste
-
- 1
- virtueller Bus
- 2
- eingebettete Komponente
- 3
- weitere eingebettete Komponente
- 4
- erster Simulationsprogrammabschnitt
- 5
- zweiter Simulationsprogrammabschnitt
- 6
- Sollvorgabentabelle
- 7
- Datenpaketerzeugungsabschnitt
- 8
- Insert-Algorithmus
- 9
- Datenpaket-Speicher
- 10
- Scheduler
- 11
- Datenpaketumwandlungsabschnitt
- 12
- lokale Uhr
- 13
- stochastischer Jitter
- 14
- ereignisbasierter Simulator
- 15
- weiterer Datenpaketumwandlungsabschnitt
- 16
- physischer Bus
- 17
- Einparkhilfe-Steuerung
- 18
- Abstandssensor
- 19
- Eingabe-/Ausgabe-Einheit
- 20
- Geschwindigkeits-Messeinheit