-
Technisches Gebiet
-
Die
Erfindung betrifft ein Verfahren und eine Vorrichtung zur Verifizierung
von Funktionsabläufen in einem Steuergerät.
-
Stand der Technik
-
Aus
der
DE 101 44 050
A1 ist ein Verfahren und ein System zur Verifikation von
Softwarefunktionen für eine Steuereinheit mit Verwendung
eines Simulationsmodells zur Abbildung der Softwarefunktionen und
der Steuereinheit bekannt.
-
Aus
dem identischen Simulationsmodell wird zum einen für eine
erste Experimentalsteuereinheit und zum zweiten für eine
zweite Seriensteuereinheit der Softwarecode für die Softwarefunktionen
automatisch generiert.
-
Es
kommen identische Eingangsgrößen für die
Softwarefunktionen auf beiden Steuergeräten zum Einsatz.
Die sich daraus ergebenden Ausgangsgrößen beider
Steuereinheiten werden zeitsynchron erfasst. Durch Vergleich der
Ausgangsgrößen beider Steuereinheiten werden die
Softwarefunktionen verifiziert. Hierfür muss ein Simulationsmodell,
in welchem die Funktionalität der Software abgebildet ist, bekannt
sein, so dass ausgehend vom Simulationsmodell ein jeweils für
das Seriensteuergerät und das Entwicklungssteuergerät
geeigneter Softwarecode erzeugt wird. Das Verfahren eignet sich
insbesondere für Steuergerätesoftware, die aus
einer Simulationsumgebung heraus in Software überführt
wird. Diese Informationen bzw. Simulationsmodelle sowie der Softwarecode
selbst liegen in unverschlüsselter zugreifbarer Form letztlich
nur dem Hersteller der Software offen. Die finale Prüfung
der Software hinsichtlich deren Funktionalität und die
Freigabe der Software wird hingegen selten vom Hersteller selbst vorgenommen.
Die Prüfung wird vielmehr durch vom Hersteller beauftragte,
externe oder gesetzlich vorgeschriebene Prüfinstanzen vorgenommen,
denen der Softwarequellcode oder dahinterliegende Simulationsmodelle
nicht bekannt sind und auch nicht zur Verfügung gestellt
werden. Weiterhin ist es für Hersteller komplexer Produkte,
beispielsweise für Fahrzeughersteller, notwendig, extern
entwickelte Zulieferbaugruppen und deren Steuersoftware für
eine Integration in das Fahrzeugsteuersystem zu überprüfen
und hinsichtlich der aus einer Spezifikation oder einem Lastenheft
generierten Funktionalität zu untersuchen. Hierfür
ist letztlich der Softwarequellcode selbst nicht von entscheidender
Bedeutung, vielmehr soll die Eignung der Baugruppe getestet werden,
welche sich letztlich in der originalgetreuen Erfüllung
der Anforderungen des Lastenheftes widerspiegelt. Ist beispielsweise
aus einem Lastenheft ein falsches Simulationsmodell generiert worden,
so führt die Prüfung gemäß dem
o. g. Stand der Technik zu einer fehlerfreien Funktion, da die Software
ausgehend vom Simulationsmodell fehlerfrei programmiert wurde. Die
im Lastenheft geforderte Funktionalität ist dabei jedoch
nicht eingehalten. Das Verfahren nach dem Stand der Technik ist
nicht in der Lage, einen solchen Fehler zu erkennen.
-
Im
praktischen Entwicklungsprozess erfolgt oft die Vergabe einzelner
Baugruppen bzw. die Programmierung von Softwarefunktionalitäten
an Dritte. Der Hersteller/Nutzer der Baugruppe beschreibt hierfür
in einem Lastenheft/einer Spezifikation die geforderte Funktionalität
der Software/Baugruppe. Wird die Baugruppe/Software zur Integration
in das Gesamtsystem dem Hersteller übergeben, besteht ein vitales
Interesse, diese einzeln oder im Verbund auf das Einhalten der geforderten
Spezifikation aus dem Lastenheft zu testen.
-
Aufgabe der Erfindung
-
Der
Erfindung liegt die Aufgabe zugrunde, ein Verfahren oder eine Vorrichtung
anzugeben, um ein vorhandenes Steuergerät ohne Kenntnis
von dessen Softwarequellcode hinsichtlich seiner Funktionsabläufe
zu verifizieren.
-
Lösung der Aufgabe
-
Die
Aufgabe wird durch ein Verfahren gemäß Anspruch
1 und eine Vorrichtung gemäß Anspruch 6 gelöst.
-
Vorteile der Erfindung
-
Ein
Vorteil der Erfindung besteht darin, dass der Softwarecode für
das zu verifizierende elektronische Steuergerät nicht bekannt
sein muss. Das Steuergerät kann somit als „black
box" angesehen werden. Für die Verifizierung der Funktion
des Steuergerätes muss lediglich die Spezifikation/das
Lastenheft, welches die geforderte Funktionalität des Steuergerätes
beschreibt, bekannt sein. Die Funktionalität der Software
des Steuergerätes wird gesondert, parallel zur Softwareumsetzung
im Steuergerät, in Form einer Zustandsmaschine beschrieben.
Zustandsmaschinen werden auch als endliche Automaten bezeichnet
und stellen eine modellhafte Abbildung eines Prozesses dar, der
mit Hilfe von Zuständen, Bedingungen für Zustandsübergänge
und Aktionen beschrieben wird. Erfindungsgemäß wird
die Zustandsmaschine, d. h. deren Eingabealphabet, Ausgabealphabet,
die Menge der Zustände, Übergangsbedingungen sowie
Start- und Endzustand, anhand eines Lastenhefts/einer Spezifikation
generiert. Der endliche Automat stellt dabei die Grundfunktionen
des zu verifizierenden Steuergerätes dar. Gebräuchliche Darstellungen
für Zustandsmaschinen sind sog. Petri-Netze. Hierbei werden
verschiedene Zustände mittels Pfeilen verbunden, welche
die Zustandsübergänge symbolisieren, wobei Transitionen
die Schaltbedingungen für den Zustandsübergang
charakterisieren und beim Zustandsübergang eine Aktion
ausgelöst wird. Die Zustandsmaschine läuft erfindungsgemäß parallel
zu dem zu testenden Steuergerät auf einem Entwicklungssteuergerät.
Die Hardwarebasis des Entwicklungssteuergerätes ist dabei
beliebig. Es kann sich hierbei um ein speziell gestaltetes, in seiner
Hardware am Seriensteuergerät angelehntes Entwicklungssteuergerät
handeln. In einem einfachen Fall kann jedoch bereits ein PC beliebiger
Plattform genügen. Entscheidend ist, dass die Zustandsmaschine
auf der gewählten Hardwareplattform lauffähig
ist und die zum Steuergerät führenden Eingänge
verarbeiten und entsprechende Ausgangszustände erzeugen
kann. Der Begriff Entwicklungssteuergerät wird im Sinne
der Erfindung für jede Hardware verwendet, welche diese
Funktionen aufweist.
-
Zur
Verifikation der Funktionsabläufe des Steuergerätes
sind die Eingangsgrößen des Steuergerätes
und des Entwicklungssteuergerätes identisch. Die erzeugten
(berechneten) Ausgangsgrößen des Steuergerätes
und des Entwicklungssteuergerätes werden mittels eines
Komparators verglichen und anschließend von einer Auswerteeinheit
ausgewertet. Die Berechnung der Ausgangsgrößen
anhand der Eingangsgrößen erfolgt innerhalb des
Entwicklungssteuergerätes parallel zum zu testenden Steuergerät.
Die Ausführung der Algorithmen auf dem Steuergerät
und der Ablauf der Zustandsmaschine, der Vergleich der Ausgänge
und die Auswertung des Vergleiches erfolgen ebenfalls in Echtzeit.
-
Als
Eingangsgrößen können beliebige Eingangsbeschaltungen
dienen, welche beispielsweise durch ein Simulationssystem erzeugt
werden. Weiterhin können vorher aufgenommene, aus einer
realen Umgebung stammende Testdaten Verwendung finden. Im Fahrzeugbereich
sind dies beispielsweise simulierte Testabläufe oder Fahrzeuglogfiles.
-
Zeichnungen
-
Es
zeigen:
-
1:
eine schematische Darstellung einer erfindungsgemäßen
Vorrichtung;
-
2:
ein Petri-Netz eines Entwicklungssteuergerätes;
-
3:
ein Flussdiagramm eines Ablaufes eines erfindungsgemäßen
Verfahrens.
-
In 1 ist
eine erfindungsgemäße Vorrichtung 1 zur
Verifikation von Funktionsabläufen eines zu testenden Steuergerätes 2 dargestellt.
Das Steuergerät 2 ist beispielsweise ein Fahrzeugsteuergerät. Die
Vorrichtung 1 umfasst weiterhin ein Entwicklungssteuergerät 3,
welches als Hardwarebasis für einen endlichen Automat/eine
Zustandsmaschine ZM dient. Die Zustandsmaschine ZM ist in 2 in Form
eines Petri-Netzes näher dargestellt.
-
Das
Entwicklungssteuergerät 3 ist parallel zu dem
Steuergerät 2 angeordnet. Die Eingänge 2.1.1–2.1.n des
Steuergerätes 2 und die Eingänge 3.1.1–3.1.n des
Entwicklungssteuergerätes 3 sind mit den jeweiligen
Ausgängen einer Simulationsvorrichtung 4 derart
verbunden, dass dem Steuergerät 2 und dem Entwicklungssteuergerät 3 identische
Signale an deren Eingängen 2.1.1–2.1.n, 3.1.1–3.1.n anliegen.
Die Ausgänge 2.2.1–2.2.m des
Steuergerätes 2 und die Ausgänge 3.2.1–3.2.m des
Entwicklungssteuergerätes 3 sind mit einem Komparator 5 verbunden.
Der Komparator 5 ist mit einer Auswerteeinheit 6 verbunden.
-
2 zeigt
ein Beispiel einer Zustandsmaschine ZM, die als Software in das
Entwicklungssteuergerät 3 – nicht dargestellt – implementiert
ist. Die Zustandsmaschine ZM ist in Form eines Petri-Netzes angegeben.
Erfindungsgemäß wird die Zustandsmaschine ZM ohne
Kenntnis der Software des Steuergerätes 2 aus
einem Lastenheft bzw. einer Spezifikation 7 für
die geforderte Funktionalität des Steuergerätes 2 entwickelt.
-
Ein
beispielhafter Auszug aus einem Lastenheft 7 für
eine adaptive Geschwindigkeitsregelung (ACC, adaptive cruise control)
ist nachfolgend ausgeführt. Die Punkte beschreiben dabei
in Anforderungen untergliederte, einzelne vom Gesamtsystem geforderte
Funktionalitäten.
- 0.0.1 Das ACC-System
soll, wenn es im Status aktiv ist und der Schalter ACC von aktiv
auf passiv wechselt, sofort in den Status passiv wechseln.
- 0.0.2 Ist der Status des ACC aktiv und der Status des ESP wechselt
von aktiv auf passiv, soll die Akustik für 1 Sekunde angesteuert
werden und im Anschluss der Status des ACC auf passiv gesetzt werden.
- 0.0.3 Ein Einschalten des ACC darf nur möglich sein,
wenn der Status des ESP auf aktiv gesetzt ist.
- 0.0.4 Ein Ausschalten der ACC-Funktion erfolgt über
den Schalter des ACC mit aus.
- 0.0.5 Ein Einschalten der ACC-Funktion erfolgt über
den Schalter des ACC mit ein.
-
Aus
dem Lastenheft 7 werden nunmehr die benötigten
Zustände, Aktionen und Schaltbedingungen für das
Petri-Netz identifiziert.
-
Die
einzelnen Zustände des Petri-Netzes sind der Status des
ESP, der Status des ACC und die Position des Schalters des ACC.
Die Status des ESP und des ACC sind dabei aktiv oder passiv. Die
ausgelösten Aktionen sind das Schalten des Zustandes ACC
bzw. das Schalten der Akustik. Transitionen des Petri-Netzes entsprechen
den Schaltbedingungen und sind hier durch die Zustandsänderungen
der Status ACC, ESP sowie den Timerablauf Akustik angegeben. Als
variable Ausgangsgrößen werden der Status des
ACC und die Ansteuerung der Akustik verwendet. Eingangsgrößen
sind der Status des Schalters ACC, der Status ESP und der Status
ACC.
-
Aus
den Vorgaben des Lastenheftes 7 resultieren für
das Petri-Netz als Darstellung der Zustandsmaschine ZM die nachfolgend
definierten Zustände. Zustände werden im Petri-Netz
als Stellen (Kreise in der Darstellung) beschrieben. Das Petri-Netz
weist daher die Stellen s0 = Initialisierung, s1 = ACC passiv, s2
= ACC aktiv, s3 = Akustik ein und s4 = Akustik aus auf. Weiterhin
werden die Schaltbedingungen des Lastenheftes 7 in den
Transitionen des Petri-Netzes formuliert. Hierbei entspricht t1
der Bedingung ESP = aktiv und Schalter ACC = ein, t2 der Bedingung
ESP = passiv, t3 der Bedingung Timer 1s abgelaufen und t4 Schalter
ACC = aus.
-
Ausgehend
von der jeweiligen Position in der Zustandsmaschine ZM, d. h. der
Lage des Prozesses an der jeweiligen Stelle s0–s4 in der
Zustandsmaschine ZM, erzeugt die Erfüllung einer Weiterschaltbedingung
das Ausführen einer Aktion verbunden mit dem Einnehmen
eines neuen Zustandes im Petri-Netz.
-
Anhand
des Beispieles wird die Arbeitsweise der auf dem Entwicklungssteuergerät 3 implementierten
Zustandsmaschine ZM beschrieben.
-
Nach
einer Initialisierungsroutine s0 mit dem Setzen der Startwerte gelangt
der Prozess ohne Weiterschaltbedingung zur Stelle s1. Hier ist der
Status des ACC passiv (S1–ACC passiv). Ausgehend von der
Stelle s1 kann der Prozess lediglich zu s2 weitergeschalten werden.
Hierfür muss die Weiterschaltbedingung der Transition t1
erfüllt werden. An diesem Übergang wird die Lastenheftbedingung
für das Einschalten des ACC abgebildet. Der Schalter ACC
wird hierbei auf ein Aktivsetzen überwacht, wobei gleichzeitig
der Status ESP abgefragt wird. Der Status des ACC wird dann aktiv
gesetzt (Weiterschalten zu s2), wenn sowohl der Status des ESP aktiv,
als auch der Schalter des ACC ein ist (Transition t1). Hierdurch werden
die Anforderungen 0.0.3 und 0.0.5 des Lastenheftes 7 abgebildet.
-
Ausgehend
von der Stelle s2 kann der Prozess über die Transitionen
t2 und t4 verzweigen. Wird an dieser Stelle s2 der Status des ESP
passiv (Transition t2), so wird die Akustik eingeschaltet (Stelle s3).
Ausgehend von s3 muss die Weiterschaltbedingung der Transition t3
erfüllt werden. Der Prozess verbleibt so lange (Timerablauf
1s) in diesem Status. Nach Timerablauf ist die Weiterschaltbedingung
der Transition t3 erfüllt. Die Akustik wird in den Zustand aus
geschaltet (Stelle s4) und der Prozess geht zum Status ACC = passiv
(Stelle s1). Die Anforderung 0.0.2 des Lastenheftes 7 ist
hierdurch abgebildet.
-
Ist
der Status des ACC aktiv (Stelle s2) und die Weiterschaltbedingung
der Transition t4 Schalter des ACC = aus, so wechselt der Status
des ACC auf passiv. Der Prozess befindet sich wieder an der Stelle
s1. Hierdurch erfolgt eine Abbildung der Anforderungen 0.0.1 und
0.0.4 des Lastenheftes 7.
-
Somit
sind in der durch 2 dargestellten Zustandsmaschine
ZM alle Anforderungen des Lastenheftes 7 abgebildet.
-
Erfindungsgemäß sind
die einzelnen Status der Zustandsmaschine ZM den Ein- und/oder Ausgängen
des Entwicklungssteuergerätes 3 zugeordnet. Weiterhin
sind die Schalterstellungen, z. B. Schalter ACC, welche als Weiterschaltbedingung
in den Transitionen des Petri-Netzes verwendet werden, Eingängen
des Entwicklungssteuergerätes 3 zugeordnet und
werden der Zustandsmaschine ZM zugeführt. Dies ermöglicht
die Verifikation des Systemverhaltens, indem als Ausgänge
des Entwicklungssteuergerätes 3 die variablen
Zustände des Prozesses ausgegeben werden. Im angegebenen Beispiel
wird der Status ACC und der Status Akustik als Ausgang am Entwicklungssteuergerät 3 angelegt. Der
Prozess kann hinsichtlich dieser Ausgänge mit dem auf dem
zu testenden Steuergerät 2 laufenden Prozess verglichen
werden.
-
In 3 ist
ein Flussdiagramm eines Ablaufes eines Verfahrens zur Verifikation
von Funktionsabläufen des Steuergerätes 2 dargestellt.
Anhand eines Lastenheftes 7 oder einer Spezifikation wird
die Zustandsmaschine des Entwicklungssteuergerätes 3 generiert.
Hierbei werden aus dem Lastenheft 7 die Systemzustände
in Zustände der Zustandsmaschine ZM überführt,
wobei anhand der annehmbaren Systemzustände (z. B. ACC
= aktiv, ACC = passiv) eine zugehörige Anzahl von Zuständen
(zwei Zustände im angegebenen Beispiel) für die
Zustandsmaschine formuliert wird. Die Bedingungen für die
Statusänderungen des Prozesses werden als Weiterschaltbedingungen
für die in der Zustandsmaschine generierten Zustände
formuliert. Die Status der Zustandsmaschine sind sowohl als Ein-
als auch als Ausgänge dem Entwicklungssteuergerät 3 angeschalten.
Gleichzeitig werden Prozessschalter als Eingänge für
das Entwicklungssteuergerät 3 bereitgestellt.
Die Simulationsvorrichtung 4 liefert identische Eingangsgrößen für
das Steuergerät 2 und das Entwicklungssteuergerät 3.
Die Verarbeitung der Eingangsgrößen erfolgt im Steuergerät 2 und
im Entwicklungssteuergerät 3 in Echtzeit. Die
aus den Eingangsgrößen generierten Ausgangsgrößen
werden mittels des Komparators 5 in Echtzeit verglichen.
Das Vergleichsergebnis wird in Echtzeit mittels der Auswerteeinheit 6 ausgewertet.
Die Eingangsgrößen können anstelle einer
von der Simulationseinheit generierten Eingangsbelegung aus vorher
aufgenommenen Testdatensätzen bestehen. Hierbei können für
ein Fahrzeugsteuergerät beispielsweise aufgenommene Daten
im Fahrbetrieb, sog. log files (Protokolldateien), des Fahrzeuges
genutzt werden.
-
Weiterhin
besteht die Möglichkeit, dass anhand der Auswertung durch
die Auswerteeinheit 6 die Eingangsgrößen,
die von der Simulationsvorrichtung 4 generiert werden,
modifiziert werden.
-
- 1
- Vorrichtung
- 2
- Steuergerät
- 2.1.1–2.1.n
- Eingänge
- 2.2.1–2.2.m
- Ausgänge
- 3
- Entwicklungssteuergerät
- 3.1.1–3.1.n
- Eingänge
- 3.2.1–3.2.m
- Ausgänge
- 4
- Simulationsvorrichtung
- 5
- Komparator
- 6
- Auswerteeinheit
- 7
- Lastenheft
- ZM
- Zustandsmaschine
- s0
Stelle
-
- s1
Stelle
-
- s2
Stelle
-
- s3
Stelle
-
- s4
Stelle
-
- t1
Transition
-
- t2
Transition
-
- t3
Transition
-
- t4
Transition
-
-
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
-