-
Die
Erfindung betrifft ein Verfahren zur Entwicklung einer technischen
Komponente, insbesondere Software-Komponente, eines Verkehrsmittels.
-
Der
Anteil von Software bzw. Software-Komponenten nimmt in technischen
Komponenten immer mehr zu. Insbesondere hat sich die Zahl elektronischer
Systeme im Kraftfahrzeug in den letzten Jahren erhöht. Der
Umfang und die Komplexität
der Software erfordert, dass die elektronischen Systeme auch sicherheitsrelevante
Aufgaben übernehmen.
Es ist deshalb wichtig durch ein geeignetes Software-Sicherheitssystem
zu gewährleisten,
dass sich alle elektronischen Systeme im Fahrzeug trotz der gestiegenen
Komplexität
sicher verhalten. Zur Gewährleistung
der Sicherheit wird die Integrität
und Verfügbarkeit
der sicherheitsrelevanten elektronischen Systeme durch geeignete
Fehlererkennungs- und Fehlerbehandlungsmaßnahmen sichergestellt.
-
Die
Entwicklung von technischen Komponenten, insbesondere Software-Komponenten,
erfolgt mittels graphischer Entwicklungswerkzeuge, welche eine Erhöhung des
Abstraktionsniveaus sowie die Möglichkeit
der automatischen Codegenerierung erlauben. Die graphischen Entwicklungswerkzeuge
erlauben die Modellierung einer technischen Komponenten anhand der
für diese
Komponente vorgegebenen Eigenschaften. Diese Modellierung erfolgt
beispielsweise anhand eines sogenannten Zustandsautomaten.
-
Ein
Zustandsautomat (finite state machine) zur Modellierung von technischen
Komponenten besteht aus Zuständen
und Zustandsübergängen (Transitionen).
Zustandsdiagramme zeigen an, bei welchem Ereignis ein Objekt von
einem bestimmten Zustand in einen Nachbarzustand übergeht.
Ein Nachfolgezustand hängt
vom Ausgangszustand und vom eintretenden Ereignis ab.
-
Mit
Hilfe der Verifikationstechnik "Model
Checking" ist es
möglich,
die Modellierung eines Systems (das sogenannte Modell, beispielsweise
ein ein System beschreibendes Programm oder ein Zustandsautomat)
daraufhin zu überprüfen (Checking),
ob sie die Eigenschaften aus einer bestimmten Spezifikation (Beschreibung
der Eigenschaften des Modells, beispielsweise durch logische Formeln)
erfüllt.
-
Ein
wesentlicher Vorteil des Model Checking ist die Automatisierung
des Verifikationsprozesses, wodurch es möglich ist, Systeme größerer Komplexität behandeln
zu können,
die mit Hilfe anderer Methoden nicht verifizierbar wären. Beispielsweise
kann durch die Model Checking mittels eines Model Checkers alle
mathematisch möglichen
Szenarien untersucht werden, die durch Simulation und Testen nicht (oder
nur mit unverhältnismäßig hohem
zeitlichen Aufwand und damit Kosten) erfasst werden
-
Für eine erfolgreiche
Anwendung des Verifikationsverfahrens mittels eines Model Checkers muss
dem Model Checker eine formal eindeutige Spezifikation der zu modellierenden
technischen Komponente vorliegen. Dies bedeutet, dass die vom Model
Checker nachzuweisenden Eigenschaften der technischen Komponeten
dem Model Checker als logische Formel in einer formal vom Model
Checker zu verarbeitbaren Sprache vorliegen muss. Damit muss der
Anwender die Spezifikation formal, d.h. eindeutig mathematisch,
spezifizieren. Es gibt verschiedene An sätze, wie die Erstellung der
logischen Formeln für eine
zu überprüfendes System,
hier technischer Komponente, erfolgt.
-
Die
Ansätze
versuchen mittels graphischer Benutzeroberflächen die Eingabe der logischen
Formeln zu erleichtern.
-
Bei
der Modellierung von technischen Komponenten, insbesondere Software-Komponenten
ist es vorteilhaft, die Software der technischen Komponente in Funktions-
und Sicherheitsmodule aufzuteilen. Die Funktionsmodule realisieren
die funktionalen Anforderungen des technischen Systems. Die Sicherheitsmodule
setzen Fehlererkennung- und Fehlerbehandlung-Maßnahmen um, wie dies in „Softwarearchitektur
für sicherheitsrelevante
Systeme im Automobil",
M. Cossy, F. Hepperle in Extra Automotive Electronics (03/2003))
bereits veröffentlich
wurde.
-
Aufgabe
der Erfindung ist es, das Verfahren zur Entwicklung einer technischen
Komponente, insbesondere Software-Komponente, zu verbessern.
-
Diese
Aufgabe wird erfindungsgemäß durch die
Merkmale des Anspruchs 1 gelöst.
Danach wird eine Aufteilung des Modells der technischen Komponente
in Funktionsmodule und Sicherheitsmodule derart vorgenommen, dass
die Sicherheitsmodule als Steuergröße die Betriebsart der Funktionsmodule ausgeben
und die Modellinformationen der Sicherheitsmodule vom Software-Entwicklungswerkzeug an
der Schnittstelle bereitgestellt werden. Diese Modellinformationen
werden zur Festlegung der formal eindeutig spezifizierten Eigenschaften
eingesetzt.
-
Die
Erfindung ermöglicht
die formale, d.h. die mathematisch vollständige, Verifikation der Spezifikation
der technischen Komponente, insbesondere der Sicherheitsmodule,
eines komplexen elektronischen Systems. Es wird mathematisch nachgewiesen,
dass die Spezifikationen der Sicherheitssoftware wichtige sicherheitsrelevante
Eigenschaften besitzt. Spezifikationsfehler werden erkannt und können frühzeitig
vor der Umset zung eines Systems korrigiert werden. Die Kosten für eine Fehlerbehebung werden
dadurch minimiert. Mit Hilfe der formalen Verifikation lässt sich
die Qualität
und Korrektheit der Spezifikationen ohne zeitaufwändige manuelle
Reviews nachweisen. Eine qualitativ hochwertige Spezifikation führt zu einer
erhöhten
Softwarequalität
und damit zu einer Reduzierung der Zahl von Fehlern, die erst im
Feld erkannt werden.
-
Bevorzugt
werden Modellinformationen wie zulässige Betriebsarten und/oder
benötigte
Komponenten in der jeweiligen Betriebsart der Sicherheitsmodule
vom Software-Entwicklungswerkzeug zur Verfügung gestellt.
-
Die
Sicherheitsmodulen bestehen aus Fehlererkennungsmodulen, Softwareschnittstellen-Modulen
und Softwarekontroll-Modulen. Wird ein Fehlverhalten einer Hardware-
oder Software-Komponente
erkannt, entscheiden die Funktionsmodule nicht selbstständig, wie
auf dieses Fehlverhalten reagiert werden muss, sondern die Sicherheitsmodule geben
den einzelnen Funktionsmodulen eine passende Betriebsart als Steuergröße vor.
Funktionsmodule realisieren die funktionalen Anforderungen.
-
Werden
die Modellinformationen in Form von einheitlichen Tabellen zur Verfügung gestellt,
wird die formale Spezifikation deutlich vereinfacht, da die Identifikation
der gewünschten
Eigenschaften und die Analyse, wie diese Eigenschaften vollständig und formal
verifiziert werden können,
nicht mehr erforderlich ist. Bevorzugt ähneln die Tabellen Dokumenten, die
bereits im Rahmen des Entwicklungsablaufs bestehender Systeme erstellt
und verwendet werden. Dadurch wird die Akzeptanz erhöht und die
Hemmschwelle erniedrigt, formale Methoden einzusetzen. Ein etwaiger
Zusatzaufwand wird minimiert.
-
Werden
entsprechende Tabellen zu den aktuellen Sicherheitsmodulen automatisch
an einer Schnittstelle generiert, wird der Aufwand weiter vermindert.
Soll eine konkrete Spezifikation formal verifiziert werden, können aufgrund
des einheitlichen Aufbaus der Tabellen die benötigten Tabellen passend zu
den aktuellen Spezifikationen automatisch generiert und Toolunterstützt ausgefüllt werden.
-
Dies
gilt ebenso, wenn die Tabellen in eine formale Spezifikationssprache
transformiert werden. Bevorzugt wird als formale Spezifikationssprache eine
Baumlogik CTL (Computation Tree Logic) verwendet. Die tabellarische
Darstellung der sicherheitsrelevanten Eigenschaften kann automatisiert
in die formale Spezifikationssprache transformiert werden, so dass
es mit Hilfe eines Mittels zur Überprüfung, insbesondere
eines so genannten Model Checkers, möglich ist, einen mathematisch
vollständigen Sicherheitsnachweis
zu erbringen.
-
Zweckmäßigerweise
erfolgt die Ergänzung der
Modellinformationen mit einem Graphical User Interface (GUI). Dadurch
wird dieser Schritt besonders benutzerfreundlich.
-
Vorzugsweise
wird nach der Erkennung eines Spezifikationsfehlers zur Ursachenanalyse
eine Trennung zwischen einem Fehler in der Modellierung mittels
des Software-Entwicklungswerkzeugs und einem Fehler der ergänzten sicherheitsrelevanten Spezifikationsinformationen
durchgeführt.
-
Eine
Vorrichtung zur Entwicklung einer technischen Komponente, insbesondere
Software-Komponente, eines Verkehrsmittels, sieht Mittel zur Ergänzung der
Modellinformationen um sicherheitsrelevante Spezifikationsinformationen
vor.
-
Vorzugsweise
umfassen die Sicherheitsmodule Fehlererkennungs- und Softwareschnittstellen- und Softwarekontroll-Module,
wobei Mittel zur Ausgabe von Modellinformationen der Sicherheitsmodule
bezüglich
Betriebsart und benötigter
Komponente in der Betriebsart vorhanden sind.
-
Bevorzugt
sind Mittel zur automatischen Generierung von Tabellen mit den Modellinformationen zu
den aktuellen Sicher heitsmodulen an einer Schnittstelle vorgesehen,
wobei die Tabellen von dem Software-Entwicklungswerkzeug generiert
werden.
-
Zudem
sind Mittel zur Transformation der Tabellen in eine formale Spezifikationssprache
vorgesehen, damit diese vom Model Checker bearbeitbar sind.
-
Es
gibt nun verschiedene Möglichkeiten,
die Lehre der vorliegenden Erfindung in vorteilhafter Weise auszugestalten
und weiterzubilden. Dazu ist einerseits auf die untergeordneten
Ansprüche
und andererseits auf die nachfolgende Erläuterung einer Ausführungsform
zu verweisen. Es sollen auch die vorteilhaften Ausgestaltungen einbezogen
sein, die sich aus einer beliebigen Kombination der Unteransprüche ergeben.
-
Im
Folgenden wird die Erfindung anhand eines in einem Flussdiagramm
dargestellten Ausführungsbeispiels
beschrieben. Dabei zeigt:
-
1 den Verfahrensablauf in
einem Flussdiagramm.
-
Das
Ausführungsbeispiel
betrifft ein Verfahren zur Entwicklung einer technischen Komponente, insbesondere
Software-Komponente,
eines Verkehrsmittels, bei dem mittels eines Software-Entwicklungswerkzeugs
ein Modell der technischen Komponente anhand vorgegebener Eigenschaften erstellt
wird. An einer Schnittstelle des Software-Entwicklungswerkzeugs
werden Modellinformationen bezüglich
des Modells der modellierten technischen Komponente bereitgestellt,
wobei mittels der an der Schnittstelle bereitgestellten Modellinformationen eine Überprüfung der
modellierten Eigenschaften anhand von formal eindeutig spezifizierten
Eigenschaften erfolgt.
-
Eine
Aufteilung des Modells der technischen Komponente in Funktionsmodule
und Sicherheitsmodule wird derart vorgenommen, dass die Sicherheitsmodule
als Steuergröße die Betriebs art
der Funktionsmodule ausgeben und Modellinformationen der Sicherheitsmodule
vom Software-Entwicklungswerkzeug an der Schnittstelle bereitgestellt
werden. Diese Modellinformationen werden zur Festlegung der formal
eindeutig spezifizierten Eigenschaften eingesetzt.
-
Als
technische Komponente ist beispielhaft eine technische Komponente
aus dem Kraftfahrzeugbereich wie beispielsweise ABS (Anti-Blockier-System),
ASR (Anti-Schlupfregelung), ESP (Elektronisches Stabilitätsprogramm)
oder elektronisches Gaspedal usw. beispielhaft angeführt.
-
Das
Software-Entwicklungswerkzeug weist ein Werkzeug zur Modellierung
eines Zustandsautomaten auf. Das Software-Entwicklungswerkzeug ist von der Fa.
MATHWORKS. Das Werkzeug hat den Namen MATLAB-Simulink-Stateflow.
-
Als
Mittel zur Überprüfung der
modellierten Eigenschaften wird ein SMV-Model-Checker (Symbolic
Model Verifier) eingesetzt, welcher über das Internet (http://www-cad.eecs.berkeley.edu)
frei zugänglich
ist.
-
Die
Modellierung der technischen Komponente erfolgt in Funktionsmodulen
und Sicherheitsmodulen wie dies in dem eingangs zitierten Stand
der Technik sowie in dem im Mai 2003 in dem Konferenzband "Entwicklerforum Kfz-Elektronik,
Ludwigsburg" unter
dem Titel "Software-Sicherheitsarchitektur
für Steuergeräte im Fahrzeug" veröffentlicht
wurde.
-
Bei
dieser Art der Modellierung werden, um die sicherheitsrelevanten
Eigenschaften zu definieren, Sicherheitsmodule eines elektronischen
Systems mit einem Software-Sicherheitssystem spezifiziert. Mit diesem
Software-Sicherheitssystem werden die Funktionsmodule von Sicherheitsmodulen
getrennt. Mit Hilfe von Überwachungen,
Sicherheitsschnittstellen-Modulen und Sicherheitskontroll-Modulen
wird eine korrekte Fehlererkennung und Fehlerbehandlung durchgeführt. Das
Verhalten der Sicherheitsschnittstellen-Module und Sicherheitskontroll-Module wird durch
Zustandsautomaten beschrieben.
-
In
dem Flussdiagramm gemäß 1 ist dargestellt, dass
nach der Erkennung eines Spezifikationsfehlers zur Ursachenanalyse
eine Trennung zwischen einem Fehler in der Modellierung mittels
des Software-Entwicklungswerkzeugs und einem Fehler der ergänzten sicherheitsrelevanten
Spezifikationsinformationen durchgeführt wird.
-
Die
Funktionssoftware wird durch Funktionsmodule realisiert. Funktionsmodule
realisieren die funktionalen Anforderungen. Ein typisches Fahrzeugregelsystem
besteht beispielsweise aus drei Funktionsmodulen „Input", „Control" und „Output", wobei das Funktionsmodul „Input" beispielsweise zur
Erfassung von Sensorgrößen dient,
das Funktionsmodul „Output" zugehörige Aktoren
steuert oder regelt und das Funktionsmodule „Control" eine auf diesen Basisfunktionen aufbauende
höhere
Funktion realisiert.
-
Durch
die verschiedenen Arten der Funktionserfüllung des Funktionsmoduls wird
bestimmt, welche Hardware-Ressourcen zur Erbringung der Funktion
verwendet werden.
-
Die
Zustandsautomaten für
die verschiedenen Module (Funktions- und/oder Sicherheitsmodule)
werden mittels des Werkzeugs MATLAB-Simulink-Stateflow generiert.
-
Die
Sicherheitssoftware wird durch Softwaremodule zur Fehlererkennung
und Fehlerbehandlung realisiert.
-
Nach
der Fehlererkennung einer Hardware- oder Softwarekomponente wird
mit Hilfe der Sicherheitssoftware zur Fehlerbehandlung den jeweiligen Funktionsmodulen
eine entsprechende Betriebsart vorgegeben.
-
Für die Fehlerbehandlung
werden Sicherheitsschnittstellen-Module
und Sicherheitskontroll-Module generiert. Mit den Sicherheitsschnittstellen-Modulen
wird der Status der Hardware- und
Softwarekomponente erfasst. Die Sicherheitskontroll-Module bestimmen
die aktuellen Betriebsarten der Funktionsmodule.
-
Für die formal
eindeutige Spezifikation der Eigenschaften der Sicherheitssoftware
der technischen Komponenten werden einheitliche Tabellen verwendet.
Die Tabellen werden aus den an einer Schnittstelle des Werkzeugs
MATLAB-Simulink bereitgestellten Daten erstellt. Diese Tabellen
werden mittels einer graphischen Benutzeroberfläche (Graphical User Interface – GUI) ausgefüllt. Anschließend werden
die Tabellen in eine formale Spezifikationssprache transformiert.
Es wird beispielsweise eine temporale Logik CTL (Computation Tree
Logic) für die
Generierung der formalen Sicherheitseigenschaften verwendet.
-
Anschließend werden
die formale Repräsentation
der Modellinformationen der Zustandsautomaten und die ergänzten sicherheitsrelevanten
Spezifikationsinformationen einer Syntaxprüfung unterzogen. Nach erfolgreicher
Syntaxprüfung
wird mit Hilfe eines Model Checkers eine Überprüfung zwischen modellierter
Komponente und formal eindeutig spezifizierter Eigenschaften durchgeführt. Hierbei
werden alle mathematisch möglichen
Szenarien, welche aufgrund des modellierten Zustandsautomaten möglich sind,
durchgespielt. Dies reduziert den Testaufwand deutlich, da alle
möglichen
Szenarien automatisch, also ohne manuelle Steuerung von Eingangsdaten, überprüft werden.
-
Aus
der nachweisbar korrekten Spezifikation kann mit Hilfe eines Codegenerators
der lauffähige Code
der technischen Komponente generiert werden. Zudem kann die nachweisbar
korrekte Spezifikation als ausführbare
Spezifikation zum Test der technischen Komponente in ihrem weiteren
Umfeld eingesetzt werden. Dies reduziert den Testaufwand deutlich,
insbesondere wenn eine Einbindung der ausführbaren Spezifikation in die
Testumgebung, z.B. einem Software-in-the-Loop Prüfstand erfolgt.
-
Entsprechend
der Erfindung wird die Sicherheitssoftware bzw. die Sicherheitsmodule
eines elektronischen Systems auf zwei Arten mit unterschiedlichen
Schwerpunkten definiert. Zum eine werden mit den modellierten Zustandsautomaten
alle Details der Sicherheitslogik beschrieben und zum anderen werden
mit den aus den Tabellen generierten CTL Formeln alle sicherheitsrelevanten
Eigenschaften definiert. Die Konsistenz dieser zwei Spezifikationsformen
wird mittels eines Model Checkers formal sichergestellt.
-
Es
ist vorteilhaft, wenn die zwei Spezifikationsformen von unterschiedlichen
Teams erstellt werden. Eine Variante ist, dass die Zustandsautomaten von
einem Software-Entwicklungsteam
modelliert werden und die Tabellen von einem Team erstellt werden,
das für
das Sicherheitskonzept des Gesamtssystems verantwortlich ist. Die
unterschiedlichen Spezifikationsformen werden gegeneinander geprüft. Eine
weitere Variante ist, dass von einem Automobilhersteller die Tabellen
und von einem Zulieferer die Zustandsautomaten spezifiziert werden,
wobei die zeitliche Reihenfolge dieser Tätigkeiten entweder sequentiell
oder parallel erfolgen kann.
-
Beispielhaft
wird das Verfahren in der Entwicklung eines elektronischen Gaspedal
ausgeführt. Das
elektronische Gaspedal besteht aus vier Funktionsmodulen. Das erste
Funktionsmodul ermittelt mit Hilfe von zwei Pedalwegsensoren die
aktuelle Gaspedalstellung. Das zweite Funktionsmodul regelt die Drosselklappe
mit Hilfe eines Gleichstrommotors entsprechend des Fahrerwunsches.
Das dritte und vierte Funktionsmodul realisieren Zusatzfunktionen.
Das dritte Funktionsmodul ermittelt, ob der Fahrer sehr schnell
vom Gaspedal geht. Das vierte Funktionsmodul berechnet mit Hilfe
der Motortemperatur, die durch einen Temperatursensor ermittelt
wird, einen Offset, der zur gewünschten
Drosselklappenstellung addiert und subtrahiert wird. Diesen vier
Funktionsmodulen ist jeweils ein Sicherheitskontrollmodul zur Ermittlung
seiner aktuellen Betriebsart zugeordnet.
-
Die
Betriebsartenkombinationen, die als Betriebszustände eines elektronischen Gaspedals
zulässig
sind, werden als sicherheitsrelevante Spezifikationsinformationen
ergänzt
und anschließend
mathematisch formal mittels des Model Checkers verifiziert.
-
Um
den Anwender bei der Definition der zulässigen Betriebsartenkombinationen
zu unterstützen,
werden aus dem Software-Entwicklungswerkzeug
die Modellinformationen der Sicherheitskontroll-Module extrahiert,
welche die Informationen über mögliche Betriebsarten,
mögliche
Betriebsartenkombination sowie benötigter Komponenten enthält. Diese
Modellinformationen werden in Tabellen bereitgestellt. Die Werkzeugunterstützung stellt
sicher, dass in jede Spalte der Tabelle nur Betriebsarten eingetragen
werden, die das von dem Sicherheitsmodul gesteuerte Funktionsmodul
besitzt. Vorteilhaft ist hier, dass der Anwender lediglich die erreichbaren
Betriebsartenkombinationen bezüglich
ihrer Zulässigkeit
zu beurteilen hat.
-
Zur
Definition der notwendigen Betriebsarten wird der Informationsfluss
zwischen den Funktionsmodulen automatisch analysiert, modelliert
und für den
Anwender aufbereitet.
-
Um
optimale Funktionserbringung nachweisen zu können, werden die zulässigen Betriebsartenkombinationen
priorisiert. Mit Hilfe der benötigten Komponenten
wird festgestellt, welche Kombinationen in der aktuellen Situation
zulässig
sind. Anschließend
wird überprüft, ob die
Priorisierung eingehalten wird.
-
Mittels
sicherheitsrelevanter Eigenschaften wird außerdem überprüft, wie viele Fehler toleriert werden
dürfen,
ohne das gravierende Einschränkungen
der Funktionalität
stattfinden. Um formal nachzuweisen, dass ein bestimmte Anzahl von
Fehlern toleriert wird, werden die möglichen Betriebsartenkombinationen
entsprechen dem Kriterium „Funktion
erfüllt" klassifiziert.