-
Betrachtet
wird die Erzeugung von Code (Programm- und Datenteil), sowie die
Handhabung flüchtiger oder
nichtflüchtiger
Daten für
Mikroprozessor basierte Steuergeräte (im folgenden ECU [Electronic
Control Unit] genannt), wie sie z. B. in Fahrzeugen eingesetzt werden,
durch Entwicklungswerkzeuge. Dabei ist nachfolgender Stand der Technik
zu beachten.
- [2] ISO International Organization
for Standardization: ISO 14230 – Road
Vehicles – Diagnostic
Systems – Keyword
Protocol 2000. 1999.
- [3] ISO International Organization for Standardization: ISO
15765 – Road
Vehicles – Diagnostic
Systems – Diagnostics
on CAN. 2000.
- [6] Matlab-Simulink: Using SIMULINK Version 2, MathWorks Januar
1997
- [7] Statemate-Magnum User Guide Version 1.3, 1998
- [8] ASCET-SD: ETAS GmbH: ASCET-SD V4.2 User's Guide 2002
- [9] OSEK Open systems and the corresponding interfaces for automotive
electronics, Version 2.2.1, 16.01.2003.
- [10] CAN: ISO International Organization for Standardization:
ISO 11898: Austausch digitaler Informationen; CAN für schnellen
Datenaustausch, 1994.
- [11] ASAM Association for Standardisation of Automation-and
Measuring Systems: XCP The universal measurement and calibration
protocol. April 2003
-
Betrachtet
wird ein in physikalischen Begriffen (z. B. als physikalisches Modell
in Modellierungswerkzeugen wie Matlab-Simulink [6], Statemate [7]
oder ASCET-SD [8]) vorliegendes Softwaremodell sowie die auf dem
Modell basierende Erzeugung von Code (bestehend aus Programmteil
und Datenteil) zur Realisierung einer Funktion (z. B. Funktion eines
Fahrzeugs) durch Software. Der Code wird für Mikroprozessor basierte Steuergeräte (im folgenden
ECU genannt), wie sie z. B. in Fahrzeugen eingesetzt werden, entweder
von Hand oder durch Entwicklungswerkzeuge automatisiert generiert.
-
Eine
wesentliche Funktionalität
von Werkzeugen zur automatisierten Codegenerierung ist die Umsetzung
eines in physikalischen Zusammenhängen beschriebenen Modells
einer Funktion in Code, der auf einem Mikroprozessor einer ECU ablauffähig ist
und ausgeführt
werden kann.
-
Fehlerüberwachung, Fehlererkennung,
Fehlerbehandlung
-
Das
Versagen vieler Fahrzeugfunktionen, beispielsweise der Bremsen oder
der Lenkung im Straßenverkehr,
kann zu schweren Unfällen
mit Toten und Verletzten führen.
An die Zuverlässigkeit
und Sicherheit solcher Fahrzeugfunktionen werden daher – unabhängig von
der technischen Realisierung – hohe
Anforderungen gestellt. Systeme, durch die Fahrzeugfunktionen realisiert
werden, an die derartige Sicherheitsanforderungen gestellt werden,
werden auch als sicherheitsrelevante Systeme bezeichnet.
-
Kann
ein sicherheitsrelevantes System seine Funktion nicht mehr zuverlässig erfüllen, da
sonst eine Gefahr bestehen oder zugelassen werden würde, muss
eine Reaktion nach einer festgelegten Sicherheitslogik erfolgen.
Voraussetzung zur Auslösung
einer solchen Sicherheitsreaktion ist, dass Störungen und Ausfälle oder
auch Fehler zuverlässig
erkannt werden. Die Fehlererkennung ist deshalb ein zentraler Bestandteil
von Überwachungsmaßnahmen.
Die Fehlererkennung spielt eine große Rolle sowohl für die Zuverlässigkeit
als auch für
die Sicherheit von elektronischen Systemen.
-
Die Überwachung{XE "Überwachung"} von technischen Systemen dient dazu,
den gegenwärtigen Systemzustand
anzuzeigen, unerwünschte
oder unerlaubte Systemzustände,
z. B. Fehler, zu erkennen und ggfs. entsprechende Gegenmaßnahmen
einzuleiten. Die Abweichungen vom „normalen" Systemzustand entstehen durch eine
Störung
oder einen Ausfall, für
die verschiedene Fehler die Ursache sind. Fehler haben also ohne
Gegenmaßnahmen
nach kürzerer
oder längerer
Zeit Störungen
und Ausfälle
zur Folge. Eine Überwachung
soll dazu dienen, Fehler möglichst
frühzeitig,
also möglichst
vor einer Störung
oder einem Ausfall, zu erkennen und dann so zu behandeln, dass Ausfälle und
Störungen
möglichst
vermieden werden.
-
Ein
möglicher
Aufbau von Überwachungsfunktionen
durch Blöcke
und Signale ist in Bild 1 dargestellt.
-
Fehlererkennung
-
In
einem Verfahren zur Fehlererkennung – auch Fehlerdiagnoseverfahren
(kurz Diagnoseverfahren) genannt – wird deshalb überprüft, ob zwischen
mindestens zwei Werten oder Signalen die zwischen diesen Werten
oder Signalen bestehenden Zusammenhänge erfüllt werden oder nicht. Unzulässige Abweichungen von
den bestehenden Zusammenhängen
werden als Fehlersymptom eingestuft.
-
Fehlererkennungs-
oder Fehlerdiagnoseverfahren {XE "Fehlerdiagnoseverfahren, Fehlererkennungs- oder"}, die bei elektronischen
Systemen häufig
angewendet werden, sind beispielsweise:
-
a) Referenzwertüberprüfung{ XE "Referenzwertüberprüfung" }
-
Eine
Frage mit bekannter Antwort wird gestellt (Frage-Anwort-Spiel).
Um die Antwort zu bestimmen, muss das System Funktionen oder Teilfunktionen
ausführen,
die auch im regulären
Betrieb verwendet werden. Falls die so bestimmte Antwort nicht mit
der a priori bekannten Antwort übereinstimmt,
wird dies als Fehler interpretiert.
-
b) Überprüfung anhand redundanter Werte{
XE "Wert, Überprüfung anhand
redundantem" }
-
Zwei
oder mehr vergleichbare Ergebnisse sind verfügbar und deren Vergleich ermöglicht die
Feststellung von Fehlern. Dies kann in Software auf verschiedene
Art und Weise realisiert werden:
Zwei oder mehr prinzipverschiedene
Algorithmen werden auf die gleichen Eingangswerte angewendet. Prinzipverschiedenheit
wird auch als Diversität{
XE "Diversität" } bezeichnet. Bei
der Realisierung eines derartigen Verfahrens in Software zur Erkennung
von Software-Fehlern
ist Diversität
zwingend erforderlich, da alle Software-Fehler systematische Fehler
sind.
-
Die
Algorithmen können
auf dem gleichen Mikroprozessor ablaufen – dann liegt nur Software-Diversität vor – oder auf
verschiedenen Mikroprozessoren ausgeführt werden – man spricht dann von Software-
und Hardware-Diversität.
-
Der
gleiche Algorithmus kann wiederholt auf dem gleichen Mikroprozessor
ausgeführt
werden, um vorübergehende
Fehler erkennen zu können.
Der gleiche Algorithmus wird dabei also auf unterschiedliche Eingangswerte
angewendet.
-
c) Beobachtung von physikalischen
Eigenschaften{ XE "physikalische
Eigenschaft, Beobachtung von" }
-
Ein
typisches Beispiel ist ein Temperatursensor, bei dem eine hohe gemessene
Temperatur ein Anhaltspunkt für
fehlerhafte Sensorsignale ist. Ein weiterer Anwendungsfall ist die
Kombination aus der Überprüfung eines
Signalwerts bezüglich
der Einhaltung bestimmter Grenzwerte und der Überprüfung der zeitlichen Änderung,
der Ableitung, des Signalwerts.
-
1.1.2 Fehlerbehandlung
-
In
einem Verfahren zur Fehlerbehandlung wird festgelegt, wie auf erkannte
Fehlersymptome reagiert wird.
-
Fehlerreaktionen{
XE "Fehlerreaktion" } oder Fehlerbehandlungsmaßnahmen{
XE "Fehlerbehandlungsmaßnahme" } sind beispielsweise:
-
A) Verwendung von redundanten
Werten
-
Wie
für die
Fehlererkennung ist Redundanz{ XE "Redundanz" } auch für die Fehlerbehandlung eine der
mächtigsten
Maßnahmen.
Für die
Fehlerbehandlung muss ein Kriterium vorhanden sein und festgelegt werden,
das es ermöglicht,
den korrekten Wert zu bestimmen und zu verwenden. Hierzu gibt es
mehrere Möglichkeiten:
Die
Fehlererkennung liefert bereits die Information, welche Ergebnisse
fehlerhaft sind.
-
In
manchen Fällen
kann auf die Fehlersituation mit einem fehlertoleranten Algorithmus „auf der
sicheren Seite" reagiert
werden, z. B. durch Verwendung des ersten oder höheren Wertes, Mittelwertbildung
oder ähnliche
Algorithmen.
-
B) Abschaltung von Subsystemen
oder Abschaltung des Gesamtsystems
-
C) Verharren im Fehlerzustand
oder Strategiewechsel,
-
- z. B. durch Umschalten auf einen Ersatzwert
-
C) Fehlerspeicherung,
-
- z. B. im Fehlerspeicher des Steuergeräts.
-
D) Fehlerbeseitigung
-
- z. B. durch Reset des Mikroprozessors durch eine Watchdog-Schaltung.
-
Auch
Kombinationen dieser Maßnahmen
sind möglich.
-
Aufbau des Überwachungssystems
elektronischer Steuergeräte{
XE "Steuergerät, Überwachungssystem elektronischen" }
-
Die
Realisierung des Überwachungssystems
elektronischer Steuergeräte
erfolgt häufig
durch eine Kombination aus Hardware- und Software-Maßnahmen.
Hardware-Maßnahmen
sind etwa der Einsatz „intelligenter" Endstufenbausteine
oder eine Watchdog-Schaltung. Durch Realisierung der Überwachungsfunktionen in
Software können
sehr flexible Konzepte zur Erkennung und Behandlung von Fehlern,
Störungen
und Ausfällen
umgesetzt werden.
-
Gegenüber rein
mechanisch oder hydraulisch realisierten Komponenten können durch
die Kombination mit elektronischen Komponenten auch Fehler, Störungen und
Ausfälle
in den mechanischen oder hydraulischen, aber auch in den elektronischen
Komponenten selbst erkannt und behandelt werden.
-
Der
Entwurf geeigneter Überwachungsfunktionen
nimmt deshalb heute bei vielen Anwendungen eine genauso hohe Bedeutung
ein wie der Entwurf von Steuerungs- und Regelungsfunktionen. Insbesondere
beeinflusst die zunehmende Realisierung der Überwachungsfunktionen durch
Software die gesamte System- und Software-Architektur in der Elektronik.
Die Entwicklung von Überwachungsfunktionen
muss deshalb bereits frühzeitig
berücksichtigt
werden und betrifft alle Entwicklungsphasen.
-
Im
Folgenden soll auf das Software-Überwachungssystem,
wie es häufig
in Steuergeräten
realisiert wird, eingegangen werden. Es ist in Bild 2 beispielhaft
dargestellt und unterscheidet zwei Ebenen. Die untere Ebene übernimmt
die Überwachung
der Mikrocontroller des Steuergeräts. In der oberen Ebene werden
Funktionen zur Überwachung
der Sollwertgeber, Sensoren, Aktuatoren und der Steuerungs- und
Regelungsfunktionen realisiert.
-
Für die Überwachung
eines Mikrocontrollers ist in der Regel ein zweiter so genannter Überwachungsrechner{
XE "Überwachungsrechner" } notwendig. Die
Software-Funktionen zur Überwachung
der Mikrocontroller werden dann auf Funktions- und Überwachungsrechner
verteilt realisiert. Beide Rechner überwachen sich auf diese Weise
gegenseitig, z. B. in einem Frage-Antwort-Spiel.
-
Werden
Fehler erkannt, so werden von beiden Software-Schichten auf Funktions-
und Überwachungsrechner
entsprechende Fehlerbehandlungen ausgelöst. Diese Fehlerbehandlungen
können
wiederum durch Software- und Hardware-Maßnahmen realisiert werden.
Die erkannten Fehlersymptome stehen dazu als Ausgangsgrößen der Überwachungsfunktionen
zur Verfügung,
um z.B. abhängig
davon Hardware-Fehlerreaktionen einzuleiten.
-
• Funktionen zur Überwachung
des Mikrocontrollers{ XE "Mikrocontroller, Überwachung
der" }
-
Die
Funktionen zur Überwachung
eines Mikrocontrollers überprüfen die
einzelnen Komponenten, wie die Speicherbereiche des Mikrocontrollers – z. B.
Flash, EEPROM oder RAM –,
die Ein- und Ausgabeeinheiten oder den Mikroprozessor.
- • Viele Überprüfungen werden
sofort nach dein Einschalten des Steuergeräts bei der Initialisierung
durchgeführt.
- • Einige Überprüfungen werden
während
des normalen Betriebs in regelmäßigen Abständen wiederholt, damit
der Ausfall eines Bauteils auch während des Betriebs erkannt
werden kann.
- • Prüfungen,
die viel Rechenzeit erfordern, wie beispielsweise die Überprüfung des
EEPROM, werden häufig
im so genannten Nachlauf, also nach Abstellen des Fahrzeugs, durchgeführt. Auf
diese Weise werden andere Funktionen nicht beeinträchtigt und
es wird eine zeitliche Verzögerung
beim Start vermieden.
-
Außerdem wird
der Programmablauf überwacht.
Dabei wird beispielsweise geprüft,
ob eine Task [9], wie erwartet, regelmäßig aktiviert und auch ausgeführt wird,
oder ob notwendige Nachrichten, etwa über CAN [10], in den erwarteten,
regelmäßigen Abständen eintreffen.
-
Derartige
Funktionen zur Überwachung
des Mikrocontrollers werden im Folgenden nicht weiter betrachtet.
-
• Funktionen zur Überwachung
der Sollwertgeber, Sensoren, Aktuatoren und der Steuerungs- und
Regelungsfunktionen
-
Die
Funktionen zur Überwachung
der Sollwertgeber und Sensoren überprüfen z. B.
alle Sollwertgeber und Sensoren auf intakte Verbindungsleitungen
und auf Plausibilität.
Dies kann beispielsweise durch Ausnützen bekannter physikalischer
Zusammenhänge
zwischen verschiedenen Sollwertgeber- und Sensorsignalen erfolgen.
Unplausible Signalwerte führen
zu einer Fehlerbehandlung, wie beispielsweise zur Vorgabe von Notlaufwerten
(Bild 3).
-
Auch
die Aktuatoren müssen
laufend auf korrekte Funktion und intakte Verbindungsleitungen überwacht
werden. Einerseits können
dazu Testsignale ausgegeben werden und die Reaktion darauf überprüft werden.
Dabei müssen
natürlich
bestimmte Randbedingungen vorausgesetzt werden, damit es dadurch
nicht zu gefährlichen
Situationen kommen kann. Andererseits können z. B. die Stromwerte der
Aktuatoren, die während
der Ansteuerung aufgenommen werden, mit fest abgelegten Stromgrenzwerten
verglichen und aus Abweichungen entsprechende Fehler erkannt werden
(Bild 4).
-
Auch
die Berechnung der Steuerungs- und Regelungsfunktionen wird überwacht.
Die berechneten Ausgangswerte einer Steuerungs- und Regelungsfunktion
werden z. B. häufig
anhand der Ausgangswerte einer vereinfachten Überwachungs-funktion auf Plausibilität überprüft (ähnlich zur
Darstellung in Bild 4)
-
Derartige
Funktionen werden im Folgenden näher
betrachtet.
-
Aufbau des Diagnosesystems
elektronischer Steuergeräte{
XE "Diagnosesystem,
elektronisches Steuergerät" }
-
Das
Diagnosesystem als Teilsystem des Überwachungssystems gehört zum Grundumfang
eines Seriensteuergeräts.
Bei den Fehlerdiagnosefunktionen wird zwischen On-Board- und Off-Board-Diagnosefunktionen
unterschieden (Bild 5).
-
• Off-Board-Diagnosefunktionen{
XE "Off-Board-Diagnosefunktion" }
-
Wird
zur Fehlererkennung das Steuergerät an einen Diagnosetester angeschlossen,
der Fehlererkennungsfunktionen ausführt – beispielsweise in der Produktion
oder im Service –,
so werden diese als Off-Board-Diagnosefunktionen bezeichnet. Der
Diagnosetester wird in der Regel in der Servicewerkstatt an eine
zentrale Fahrzeugdiagnoseschnittstelle, auch Diagnosestecker genannt,
angeschlossen, der mit den verschiedenen Steuergeräten des
Fahrzeugs verbunden ist. Alle diagnosefähigen Steuergeräte können so über diese
zentrale Fahrzeugdiagnose-schnittstelle diagnostiziert werden.
-
• On-Board-Diagnosefunktionen{
XE "On-Board-Diagnosefunktion" }
-
Falls
die Fehlererkennungsfunktionen im Steuergerät ausgeführt werden, so werden diese
auch als On-Board-Diagnosefunktionen bezeichnet. Im Falle, dass
ein Fehler, ein Ausfall oder eine Störung erkannt wird, stößt die On-Board-Diagnosefunktion
eine entsprechende Fehlerbehandlung an und nimmt meist auch einen
Eintrag im Fehlerspeicher des Steuergerätes vor, der dann später z. B.
mit einem Diagnosetester in der Servicewerkstatt ausgelesen und
ausgewertet werden kann. Je nach Anwendungsfall werden die Fehlererkennungsfunktionen – wie oben
beschrieben – nur
beim Systemstart oder auch zyklisch während des Betriebs oder auch
im Nachlauf durchgeführt.
-
Ein
möglicher
Aufbau des On-Board-Diagnosesystems eines Steuergeräts ist in
Bild 6 dargestellt.
-
Die
On-Board-Diagnosefunktionen umfassen neben Software-Funktionen für die Sollwertgeber-Sensor- und Aktuatordiagnose,
Funktionen zur Diagnose der Steuerungs- und Regelungsfunktionen.
Der Fehlerspeichermanager, der unter anderem Ein- und Austräge in den
Fehlerspeicher vornimmt, sowie die Software-Komponenten für die Off-Board-Diagnosekommunikation
mit dem Diagnosetester gehören
ebenso zum Diagnosesystem.
-
Die
On-Board-Diagnosefunktionen überprüfen beispielsweise
während
des normalen Betriebs die Eingangs- und Ausgangssignale des Steuergeräts.
-
• Sollwertgeber- und Sensordiagnosefunktionen{
XE "Sensordiagnosefunktion,
Sollwertgeber- und" }
-
Die
Sollwertgeber, Sensoren und die Verbindungsleitungen zum Steuergerät können anhand
der ausgewerteten Eingangssignale überwacht werden. Mit diesen Überprüfungen können neben
Sollwertgeber- und Sensorfehlern auch Kurzschlüsse zur Batteriespannung oder
zur Masse, sowie Leitungsunterbrechungen festgestellt werden.
-
Hierzu
können
folgende Verfahren eingesetzt werden:
- • Überwachung
der Versorgungsspannung des Sollwertgebers oder Sensors
- • Überprüfung des
erfassten Werts auf den zulässigen
Wertebereich
- • Plausibilitätsprüfung bei
Vorliegen von Zusatzinformationen
-
Die
Sollwertgeber- und Sensordiagnose wird ermöglicht durch das Messen von
Steuergeräteeingangssignalen
und steuergeräteinternen
Größen. Diese
Signale werden über
die Off-Board-Diagnosekommunikation an den Diagnosetester übertragen.
Im Diagnosetester können
die übertragenen
Daten als physikalische Größen online
dargestellt werden. Für
Plausibilitätsprüfungen können im
Diagnosetester auch die Signale auf den Bussen des Fahrzeugs mitgemessen
werden (engl. Bus Monitoring). Ergänzend können auch zusätzliche
Diagnosemessmodule ins Fahrzeug eingebaut und so weitere Signale
für Plausibilitätsprüfungen verwendet
werden.
-
• Aktuatordiagnosefunktionen
{ XE "Aktuatordiagnosefunktion" }
-
Die
Funktionen zur Aktuatordiagnose ermöglichen im Fahrzeugservice
die gezielte Aktivierung einzelner Aktuatoren des Steuergeräts, um damit
ihre Funktionsfähigkeit
zu überprüfen. Dieser
Testmodus wird mit dem Diagnosetester angestoßen. Er funktioniert in der
Regel nur bei stehendem Fahrzeug unter festgelegten Bedingungen,
beim Motorsteuergerät
beispielsweise unterhalb einer bestimmten Motordrehzahl oder bei
Motorstillstand. Dabei werden die Steuerungs- und Regelungsfunktionen
nicht ausgeführt.
Stattdessen werden die Ausgangsgrößen der Steuerung oder des
Reglers für
die Aktuatoren online durch den Diagnosetester vorgegeben. Die Funktion
der Aktuatoren wird akustisch – beispielsweise
durch Klicken eines Ventils –,
optisch – etwa
durch Bewegen einer Klappe – oder
durch andere einfache Methoden überprüft.
-
• Fehlerspeichermanager{ XE "Fehlerspeichermanager" }
-
Von
den On-Board-Diagnosefunktionen erkannte Fehlersymptome{ XE "Fehlersymptom" } werden in der
Regel im Fehlerspeicher{ XE "Fehlerspeicher" } des Steuergeräts eingetragen.
Der Fehlerspeicher wird meist im EEPROM abgelegt, da so die Einträge dauerhaft
gespeichert werden können.
Der Fehlerspeicher ist bei Motorsteuergeräten in etwa so aufgebaut, wie
in Bild 7 dargestellt. Gesetzliche Anforderungen legen bei Motorsteuergeräten fest,
dass für
jeden Fehlereintrag neben dem Code eines Fehlersymptoms (engl. Diagnostic
Trouble Code{ XE "Diagnostic
Trouble Code" },
DTC{ XE "DTC" }) zusätzliche
Informationen abgespeichert werden müssen. Dazu gehören z. B.
die Betriebs- oder Umweltbedingungen, die beim Auftreten des Fehlersymptoms
herrschten. Ein Beispiel ist die Motordrehzahl, die Motortemperatur
oder der Kilometerstand zum Zeitpunkt der Fehlererkennung. Als weitere
Informationen werden häufig
Fehlerart, wie Kurzschluss oder Leitungsunterbrechung bei elektrischen
Fehlern, und der Fehlerstatus, wie statischer Fehler oder sporadischer Fehler,
sowie weitere Merkmale des Fehlersymptoms abgespeichert. Dazu gehören etwa
Hinweise, ob und wie häufig
das Fehlersymptom bereits früher
aufgetreten ist und abgespeichert wurde oder ob es zum aktuellen
Zeitpunkt auftritt. Der Fehlerspeichermanager übernimmt das Ein- und Austragen
von Fehlersymptomen in den Fehlerspeicher.
-
Insbesondere
im Motormanagement sind die oft länderspezifischen Abgasgesetze
zu beachten. Darin sind für
viele Fehler, die Einfluss auf die Abgasemissionen haben, die Fehlercodes
(DTC) und die Blinkcodes der so genannten Fehlerlampe{ XE "Fehlerlampe" } (engl. Malfunction
Indicator Light{ XE "Malfunction
Indicator Light" },
MIL{ XE "MIL" }) zur Information
des Fahrers vorgeschrieben. Unter vorgegebenen Bedingungen können manche
Fehlersymptome vom Fehlerspeichermanager auch wieder aus dem Fehlerspeicher
ausgetragen werden, etwa wenn sie während einer bestimmten Anzahl
von Fahrzyklen nicht mehr auftreten.
-
Bei
der Fahrzeuginspektion in der Servicewerkstatt können diese gespeicherten Informationen
mit dem Diagnosetester{ XE "Diagnosetester" } über die
Off-Board-Diagnoseschnittstelle des Fahrzeugs ausgelesen werden.
Damit kann die Suche der eigentlichen Fehlerursache und die Reparatur
erleichtert werden. Zur Übertragung
vom Steuergerät
zum Diagnosetester müssen
die in Bild 7 grau hinterlegten Fehlerspeicherinhalte mittels Nachrichten
der Off-Board-Diagnosekommunikation
transportiert werden. Auch alle diese Aufgaben in Zusammenhang mit
Anforderungen des Diagnosetesters übernimmt der Fehlerspeichermanager.
Im Diagnosetester werden die Fehlerspeicher-inhalte dargestellt.
Dies kann durch direkte Darstellung der Fehlercodes erfolgen. Verständlicher
ist aber eine Anzeige der Fehlersymptome als Klartext, wie in Bild
7 dargestellt, und eine Anzeige der Umwelt-bedingungen als physikalische
Größen. Dazu
benötigt
der Diagnosetester eine Fehlerspeicherbeschreibung des jeweiligen
Steuergeräts.
Nach der erfolgreichen Fehlerbehebung kann über ein entsprechendes Kommando
vom Diagnosetester an den Fehlerspeichermanager der Fehlerspeicher
komplett gelöscht
werden.
-
• Off-Board-Diagnosekommunikation{
XE "Off-Board-Diagnosekommunikation" }
-
Für die Kommunikation
zwischen Diagnosetester und Steuergerät wurden Standards [2, 3] definiert. In
der Regel wird die Off-Board-Diagnosekommunikation unter Berücksichtigung
dieser Standards vom Fahrzeughersteller für alle Steuergeräte des Fahrzeugs
einheitlich festgelegt.
-
Modellbasierte Fehlererkennung{
XE "Fehlererkennung,
Modellbasierte" }
-
Die
modellbasierte Fehlererkennung, auch modellbasierte Diagnose genannt,
wird zunehmend in elektronischen Steuergeräten eingesetzt. Eine prinzipielle
Darstellung zeigt Bild 8.
-
Zur
Fehlererkennung können
die im statischen oder dynamischen Systemverhalten vorhandenen,
bekannten Abhängigkeiten
zwischen verschiedenen messbaren oder berechenbaren Signalen durch
Einsatz von Modellen der Aktuatoren, der Strecke und der Sensoren
ausgenutzt werden. Dazu können
die bekannten Methoden aus der Regelungstechnik – wie Modellgleichungen, Zustandsgrößenschätzung oder
Zustandsbeobachter – eingesetzt
werden.
-
Aufgrund
der vorhandenen Eingangsgrößen, meist
die Reglerausgangsgrößen U und
die Rückführgrößen R, manchmal
auch die Führungsgrößen W und
die Stellgrößen Y, können Fehler
in der Steuerung oder im Regler, in den Sensoren, in der Strecke
und in den Aktuatoren erkannt werden.
-
Die
modellbasierte Fehlererkennung vergleicht beispielsweise das Verhalten
der realen Komponenten mit dem Verhalten der modellierten Komponenten
und erzeugt mit geeigneten Methoden Merkmale. Weichen diese Merkmale
vom hinterlegten normalen Verhalten ab, dann bilden sich Fehlersymptome
aus, die die Basis für
die Fehlerbehandlung und die Suche der Fehlerursache darstellen.
-
Optimale Codegenerierung
-
Für die Abbildung
der physikalischen Darstellung einer Funktion auf den ablauffähigen Code
eines Mikroprozessors werden Informationen benötigt, die diese Abbildung und
deren Eigenschaften beschreiben, und die im folgenden Implementierung
genannt werden. Ein Nachteil bestehender Modellierungswerkzeuge
ist, dass Implementierungen nur für Datenelemente oder für die Übertragungsdarstellung
auf einem Kommunikationskanal möglich
sind. Es ist damit nicht möglich,
physikalische Zusammenhänge
zu spezifizieren, die dem Werkzeug zusätzliche Hinweise auf mögliche Optimierungen
des erzeugten Codes geben, ohne dass damit eine dauerhafte oder
vorübergehende
Speicherung eines Zwischenergebnisses im Modell verbunden ist.
-
Beschreibung der Ausführungsbeispiele
und Vorteile
-
Die
Erfindung beschreibt Verfahren und Vorrichtung sowie Computerprogramm
und Computerprogrammprodukt für
die Spezifikation des normalen und abnormalen oder Fehlverhaltens
in einem physikalischen Funktionsmodell, sowie die damit mögliche Spezifikation
der Fehlerdiagnosefunktionen, sowie die damit mögliche automatisierte Generierung
von Fehlerdiagnosefunktionen, sowie die automatisierte optimierte
Generierung von Steuerungs- und Regelungsfunktionen.
-
Vorteilhafter
Weise wird dazu ein Verfahren, eine Vorrichtung, ein Computerprogramm
und ein Computerprogrammprodukt dargestellt zur Erzeugung von Code,
der auf einem Mikroprozessor ablauffähig ist und aus einem in physikalischen
Zusammenhängen
beschriebenen Softwaremodell erzeugt wird, wobei Datenelemente aus
dem Softwaremodell in Code implementiert werden, wobei im Softwaremodell
ein vorgebbarer Signalfluss vorliegt, wobei zusätzlich zu den Datenelementen
Zusicherungen an vorgebbaren Stellen im Signalfluss implementiert
werden, durch welche normales und abnormales Verhalten des Softwaremodells
dargestellt oder überwacht
wird indem vorgebbare Eigenschaften des Softwaremodells definiert
oder überwacht werden.
-
Bevorzugt
ist dabei, dass die Zusicherungen als Boolsche Bedingungen ausgebildet
sind und in einer Ausführungsform
als Boolsche Bedingungen in wenigstens einer Entscheidungstabelle
definiert sind.
-
Vorteilhafter
Weise besitzen die Zusicherungen im Softwaremodell selbst keine
speichernde Wirkung.
-
Dabei
enthält
die Zusicherung zweckmäßiger Weise
wenigstens eine der folgenden Eigenschaften:
- – einen
Namen der Zusicherung im Softwaremodell
- – eine
physikalische Einheit der Zusicherung
- – ein
physikalischer Typ der Zusicherung
- – ein
erforderlicher physikalischer Wertebereich der Zusicherung
- – ein
maximaler Gradient des Signalflusses
-
Weiterhin
von Vorteil ist, dass durch die Zusicherungen eine Fehlererkennungsfunktion
realisiert wird und bei der Erzeugung von Code wenigstens eine der
folgenden Einstellungen vorgenommen wird:
- – ob Fehlererkennungsfunktion
on-board oder off-board realisiert wird
- – ob
die Fehlererkennungsfunktion on-board als Teil einer Sollwertgeber/Sensorüberwachung,
einer Aktuatorüberwachung
oder einer Überwachung
von Steuerungs- und
Regelungsfunktionen realisiert werden soll
- – ob
eine Überwachung
von Steuerungs- und Regelungsfunktionen on-board nach dem Einschalten
oder während
des normalen Betriebs oder nach dem normalen Betrieb durchgeführt werden
soll
- – ob
bei Erkennen eines Fehlers eine Fehlerbehandlung erfolgen soll
- – falls
bei Erkennen eines Fehlers eine Fehlerbehandlung erfolgen soll eingestellt
wird welche Fehlerbehandlung erfolgen soll
-
Zweckmäßig ist
weiterhin, dass als Implementierung für Zusicherungen wenigstens
eine der folgenden Eigenschaften definiert wird:
- – Einstellungen
zur Benennung der Zusicherung im Code,
- – ein
im ausführbaren
Code benötigte
Datentyp der Zusicherung
- – eine
Umrechnungsformel, die die Umrechnung von der physikalischen Darstellung
in die Darstellung der Zusicherung im Code beschreibt
- – ein
zulässiger
Wertebereich der Zusicherung während
der Ausführung
im Code.
-
Vorteilhaft
ist weiterhin, dass für
eine Zusicherung Parameter festgelegt werden, wobei für diese
wenigstens eine der folgenden Eigenschaften definiert wird:
- – Ob
die Parameter der Zusicherung durch einen Eingriff auf den Mikroprozessor
von außen
unter bestimmten Bedingungen und Voraussetzungen modifizierbar sind
oder nicht
- – Ob
die Parameter der Zusicherung auf dem Mikroprozessor für ein bestimmtes
Kalibrier- oder
Parametrierverfahren in folgenden Entwicklungsschritten, in der
Produktion oder im Service zugänglich
gemacht werden soll oder nicht
- – Ob
Parameter der Zusicherung in einem dem Mikroprozessor zugeordneten
Speicher mehrfach angelegt werden soll oder nicht
-
Überblick über die
Erfindung
-
Die
folgende Erfindung beschreibt
- • die Spezifikation
des normalen und abnormalen oder Fehlverhaltens in einem physikalischen
Funktionsmodell,
- • sowie
die damit mögliche
Spezifikation der Fehlerdiagnosefunktionen,
- • sowie
die damit mögliche
automatisierte Generierung von Fehlerdiagnosefunktionen,
- • sowie
die automatisierte optimierte Generierung von Steuerungs- und Regelungsfunktionen.
-
Im
Folgenden sollen deshalb folgende Verfahren dargestellt werden:
- • Modellierverfahren,
die die übersichtliche
Spezifikation des normalen und abnormalen Verhaltens im Funktionsmodell
von Steuerungs- und Regelungsfunktionen durch die Festlegung der
Abhängigkeiten
zwischen verschiedenen Signalen im Modell durch so genannte Zusicherungen
unterstützen
(Kapitel 2).
- • Darüber hinaus
werden Verfahren zur automatisierten Abbildung des durch Zusicherungen
spezifizierten abnormalen Verhaltens in Software-Überwachungsfunktionen
durch die automatisierte Codegenerierung beschrieben (Kapitel 3).
- • Des
weiteren werden Verfahren zur optimierten Abbildung des durch Zusicherungen
spezifizierten normalen Verhaltens in Software-Steuerungs- und Regelungsfunktionen
durch die automatisierte Codegenerierung beschrieben (Kapitel 4).
- • Zuletzt
wird darauf eingegangen, wie der Anwender die Information zur Umsetzung
eines in physikalischen Zusammenhängen beschriebenen Modells
in Code spezifizieren kann, wenn dieses Zusicherungen enthält, und
welche besonderen Aspekte sich aus der Anwendung dieser Information
auf Zusicherungen ergeben (Kapitel 5).
-
Spezifikation von Zusicherungen
im physikalischen Modell
-
Typischerweise
hat der Anwender Kenntnis über
bestimmte physikalische Eigenschaften des normalen und abnormalen
Verhaltens z. B. einer Steuerungs- und Regelungsfunktion (z. B.
Eigenschaften der Werte von Zwischenergebnissen im Signalfluss),
die sich nicht oder nur indirekt aus dem Modell der Steuerungs-
und Regelungsfunktion selbst erschließen.
-
Dies
kann aus verschiedenen Gründen
der Fall sein, z. B.
- • Entweder, weil die Zusammenhänge außerhalb
des Modells liegen. Z. B. könnte
durch physikalische Zusammenhänge
sichergestellt sein, dass bei der Auswertung zweier örtlich nahe
beieinander liegenden Temperatursensoren und normalem Verhalten
die Temperaturdifferenz einen bestimmten Betrag nicht überschreiten
kann (Referenzwertüberprüfung).
- • Oder
weil die Zusammenhänge
im Modell zu komplex sind. Beispielsweise könnte ein Signal, dessen Gradient
begrenzt ist, im Modell einen Filteralgorithmus mit bekannter Zeitkonstante
durchlaufen. Damit ergibt sich aus dem Modell nur sehr indirekt,
dass die Differenz zwischen dem ursprünglichen und dem gefilterten Wert
bei normalem Verhalten einen bestimmten Betrag nicht überschreiten
kann (Referenzwertüberprüfung).
- • Oder
weil das Modell vorsätzlich
zu Überwachungszwecken
redundant ausgelegt ist (Redundanzwertüberprüfung).
-
In
vielen Fällen
kann es erforderlich sein, diese Eigenschaften des normalen und
abnormalen Verhaltens im Modell einer Funktion ausdrücklich darzustellen,
z. B.
- • weil
für die
Funktion im normalen und abnormalen Fall ein unterschiedlicher Algorithmus
spezifiziert werden soll
- • um
basierend auf dieser Unterscheidung Fehlerdiagnosefunktionen automatisiert
oder manuell zu erzeugen oder
- • um
eine auf der Darstellung des normalen Verhaltens beruhende anschließende automatisiere
oder manuelle Erzeugung optimierten Codes für ECUs zu ermöglichen.
-
Modellierungswerkzeuge
nach dem Stand der Technik erlauben eine solche ausdrückliche
Darstellung
- • entweder nur mit Hilfe von
Datenelementen, d. h.
a) die Behandlung des abnormalen Verhaltens
muss ausdrücklich
mit Hilfe der vorhandenen Spezifikationsmittel dargestellt werden
und
b) die Beschreibung des normalen Verhaltens ist nur in
Verbindung mit einer dauerhaften oder vorübergehenden Speicherung eines
Zwischenergebnisses möglich.
Für eine
optimierte Umsetzung des Modells in Code (vor allem eine automatisierte
Umsetzung) kann jedoch eine Darstellung von physikalischen Eigenschaften
bestimmter Zwischenergebnisse ausdrücklich ohne Speicherung des
Wertes von wichtiger Bedeutung sein.
- • oder
mit explizit spezifizierten Bedingungen, die die Übersichtlichkeit
des Modells beeinträchtigen.
-
Im
Gegensatz zu diesen bekannten Mechanismen zur physikalischen Modellierung
wird hier ein Verfahren beschrieben, das dem Anwender die einfache
Darstellung des normalen und abnormalen Verhaltens durch Boolesche
Bedingungen im physikalischen Modell ohne Zwischenspeicherung von
Werten im Signalfluss erlaubt.
-
Das
Verfahren beruht auf der Bereitstellung einer neuen Art von Modellierungselement
(z. B. in graphischer oder textueller Beschreibung) durch das Modellierungswerkzeug.
Diese Elemente werden im folgenden als Zusicherungen bezeichnet,
da der Anwender mit ihrer Hilfe für bestimmte Stellen im Signalfluss
bestimmte physikalische Eigenschaften (die sich typischerweise auf
das normale Modellverhalten beziehen) zusichert. Diese Zusicherungen
werden im wesentlichen in Form von Booleschen Bedingungen festgelegt
und können
zwei grundsätzlich
verschiedenen Zwecken dienen, nämlich
- a) zur Unterscheidung zwischen dein normalen
und dem abnormalen Verhalten und
- b) als zusätzliche
Informationsquelle für
die Schritte im Softwareerzeugungsprozess, die der Modellierung nachfolgen,
z. B. der Codegenerierung.
-
Die
mögliche
Umsetzung von Zusicherungen im physikalischen Modell ist in Bild
9 (graphische Beschreibung) und im folgenden Beispiel (textuelle
Beschreibung) dargestellt:
-
Beispiel:
-
return Zusicherung(Sensor1.1 – Sensor1.2);
-
Zusicherungen
haben folgende Eigenschaften:
- • Sie haben
im Modell selbst keine speichernde Wirkung, d. h. sie eignen sich
nicht dazu, Werte dauerhaft oder vorübergehend zu speichern
- • Sie
erlauben dem Anwender die Spezifikation von physikalischen Eigenschaften
an bestimmten Stellen im Signalfluss. Dies können sein
– Der Name
der Zusicherung im physikalischen Modell
– Die physikalische Einheit
der Zusicherung im Modell
– Der
physikalische Typ der Zusicherung, z. B. kontinuierlich, diskret,
logisch,...
– Der
erforderliche physikalische Wertebereich für die Zusicherung
– Weitere
physikalische Eigenschaften des Signalflusses, die sich durch Boolesche
Bedingungen beschreiben lassen, z. B. ein maximaler Gradient, das
Nichtenthaltensein des Werts 0 in der Menge aller physikalisch möglichen
Werte,...
– Eine
Fehlermeldung die beim Eintreten des abnormalen Funktionsverhaltens
(beim Erkennen eines so genannten Fehlersymptoms) ausgegeben wird
– Funktionen
zum Eintragen eines Fehlersymptoms in einen Fehlerspeicher auf dem
Steuergerät
- • Ggf.
Kommentare
-
Je
nach Anwendungsfall müssen
nicht alle genannten Eigenschaften definiert sein.
-
Je
nach Konfiguration des Entwicklungswerkzeugs ist es möglich,
- • dass
Zusicherungen das physikalische Verhalten des Modells, z. B. in
der physikalischen Simulation, nicht direkt beeinflussen.
Sie
können
dann jedoch z. B. dazu dienen,
– den Anwender während einer
Simulation durch Warnungen darauf hinzuweisen, falls die zugesicherten Eigenschaften
verletzt werden
– Funktionen
zur Fehlerbehandlung auf der ECU auszulösen. In diesem Fall wird natürlich das
Gesamtverhalten der ECU durch diese Ausnahmebehandlung verändert.
– Eingangsgrößen für Fehlererkennungs-
und Fehlerbehandlungs-funktionen bereitzustellen
- • Dass
Zusicherungen das durch sie angegebene physikalische Verhalten des
Modells erzwingen, z. B. durch Begrenzung eines Zwischenergebnisses
auf einen durch die Zusicherungsbedingung spezifizierten Wertebereich.
Das kann z. B. in nicht sicherheitsrelevanten Fällen sinnvoll sein, falls dies
als Fehlerbehandlungsmaßnahme
auf der ECU ausreicht.
-
Auch
für komplexere
physikalische Zusammenhänge,
wie z. B. die Differenz zwischen zwei Signalflüssen, sind Zusicherungen möglich, indem
die mathematische Darstellung einer Zusicherung auf andere Elemente
des Modells (Datenelemente oder ebenfalls Zusicherungen) Bezug nimmt.
-
Beispiel:
-
Der
Anwender könnte
an einer Stelle im physikalischen Modell seine Kenntnis über einen
Wert, der eine Luftdruckdifferenz beschreibt, durch die folgende
Zusicherung darstellen:
Name
der Zusicherung: | Delta_p_Luft |
Berechnung
der Zusicherung: | Delta_p_Luft
= Sensor1.1 – Sensor1
.2 |
Physikalische
Einheit der Zus.: | 1
Hpa |
Physikalischer
Datentyp der Zus.: | kontinuierlich |
- • Boolesche Zusicherungsbedingung
1, im folgenden X1 genannt:
(–10 <= Delta_p_Luft) && (Delta_p_Luft <= 20)
oder
durch Parameter
(P1_min <=
Delta_p_Luft) && (Delta_p_Luft <= P1_max)
- • Boolesche
Zusicherungsbedingung 2, im folgenden X2 genannt:
Delta_p_Luft/dT < 2
oder durch
Parameter
Delta_p_Lufb/dT < P2_max
-
Für die Zusicherung
Delta_p_Luft werden keine weiteren Eigenschaften definiert.
-
Verwendung der Zusicherungsbedingungen
in Entscheidungstabellen sowie Spezifikation und automatisierte Generierung
von Fehlerdiagnosefunktionen
-
Aktionen,
deren Ausführung
von der Erfüllung
oder Nichterfüllung
mehrerer Bedingungen abhängt, können übersichtlich
und kompakt in Form von so genannten Entscheidungstabellen [5, 8]
definiert werden. Die Ein- bzw. Ausgangsgrößen einer Entscheidungstabelle
sind Boolesche Größen X1 ...
Xn bzw. Y1... Ym.
-
Die
Eingangsgrößen X1 ...
Xn, auch Bedingungen{ XE "Bedingung" } genannt, werden
jeweils als Spalten der Entscheidungstabelle dargestellt. Jede Zeile
der Eingangsgrößen der
Entscheidungstabelle steht für
eine Konjunktion oder logische UND-Verknüpfung der Eingangsgrößen in den
Spalten. Eine Zeile stellt also einen Booleschen Ausdruck, eine
so genannte Regel{ XE "Regel" } R dar, von deren
Wahrheitswert die Ausgangsgrößen Y1 ...
Ym, auch Aktionen{ XE "Aktion" } genannt, abhängen. Diese
Ausgangsgrößen werden
als weitere Spalten in der Entscheidungstabelle dargestellt.
-
Maximal
können
daher 2n Kombinationen zwischen den n Eingangsgrößen gebildet
werden. Die vollständige
Entscheidungstabelle hat also 2n Zeilen
oder Regeln. Die Ausgangsgrößen werden
einer oder mehreren Regeln zugeordnet. Im Falle, dass eine Ausgangsgröße mehreren
Regeln zugeordnet ist, entspricht dies einer Disjunktion oder logischen
ODER-Verknüpfung
dieser Regeln.
-
Ein
Beispiel ist in Bild 10 dargestellt.
-
Verschiedene
Entscheidungstabellen können
auch sequentiell miteinander verknüpft werden, wie beispielsweise
in Bild 11 dargestellt.
-
Entscheidungstabellen
können
vorteilhaft überall
dort zur Spezifikation von Funktionen eingesetzt werden, wo eine
Reihe von Bedingungskombinationen zur Ausführung einer Reihe von verschiedenen
Aktionen führen.
-
Zusammenhänge dieser
Art kommen in Überwachungsfunktionen
häufig
vor.
-
Die
unter Kapitel 1 und 2 beschriebenen Zusicherungsbedingungen X1 ...
Xn können
deshalb übersichtlich
in Form von Entscheidungstabellen verknüpft werden. Den so definierten
Regeln können
entsprechende Fehlerbehandlungsaktionen zugeordnet werden. Über Attribute,
die den Regeln der Entscheidungstabelle zugeordnet werden, können dann
beispielsweise die folgenden Einstellungen für die Codegenerierung der Fehlererkennungs-
und Fehlerbehandlungsfunktionen festgelegt werden:
- – ob
die Fehlererkennungsfunktion on-board oder off-board realisiert
werden soll
- – ob
die Fehlererkennungsfunktion on-board als Teil der Sollwertgeber-/Sensorüberwachung,
der Aktuatorüberwachung
oder der Überwachung
der Steuerungs- und Regelungsfunktionen realisiert werden soll
- – ob
die Überwachung
der Steuerungs- und Regelungsfunktionen on-board nach dem Einschalten
oder während
des normalen Betriebs oder nach dem normalen Betrieb (z. B. Abstellen
des Fahrzeugs) durchgeführt
werden soll
- – ob
bei Erkennen eines Fehlers eine Fehlerbehandlung erfolgen soll und
falls ja welche Fehlerbehandlung erfolgen soll.
-
Beispiel:
-
Im
oben dargestellten Beispiel kann festgelegt werden, dass
- • die
Zusicherungsbedingung X1 on-board und zyklisch während des Betriebs ausgewertet
wird.
- • die
Zusicherungsbedingung X2 off-board ausgewertet wird, wozu ein Diagnosetester
im entsprechenden Betriebszustand mit der ECU verbunden werden muß.
-
Im
Falle der Verletzung der Zusicherungsbedingung X1 wird zur Laufzeit
des Steuergeräts
ein Fehler erkannt und eine Fehlerbehandlung durchgeführt:
-
Berücksichtigung der Zusicherungen
bei der Generierung von optimiertem Code für Steuerungs- und Regelungsfunktionen
-
Wie
in Kapitel 2 beschrieben, kann der Anwender Kenntnis über bestimmte
physikalische Eigenschaften von normalem Verhalten (z. B. Eigenschaften
von Werten von Zwischenergebnissen im Signalfluss), die sich nicht
oder nur indirekt aus dem Modell selbst erschließen, nach dem Stand der Technik
bereits heute im physikalischen Modell ausdrücklich darstellen. Diese Darstellung
ist jedoch nur mit Hilfe von Datenelementen, d. h. in Verbindung
mit einer dauerhaften oder vorübergehenden
Speicherung eines Zwischenergebnisses, oder mit explizit spezifizierten
Bedingungen, die die Übersichtlichkeit
des Modells beeinträchtigen,
möglich.
-
Für eine optimierte
Umsetzung des Modells in Code (v. a. eine automatisierte Umsetzung)
kann jedoch eine Darstellung von physikalischen Eigenschaften bestimmter
Zwischenergebnisse ausdrücklich
ohne Speicherung des Wertes von wichtiger Bedeutung sein (z. B.
um Laufzeit- oder
Speicherbedarf zu optimieren).
-
Beispiel:
-
In
Ergänzung
zum Beispiel unter Kapitel 1 wird angenommen, dass das physikalische
Modell Delta_p_Luft als Differenz der über die Sensoren Sensor1.1
und Sensor1.2 ermittelten Signalen p_Luft_innen und p_Luft_aussen
spezifiziert. Beide Sensoren haben jeweils einen Wertebereich von
960 Hpa bis 1040 Hpa.
-
In
diesem Fall musste ein nachfolgender Schritt im Entwicklungsprozess
(z. B. automatisierte oder manuelle Codeerzeugung) ohne das Vorhandensein
der Zusicherung Delta_p_Luft von einem Wertebereich für die Luftdruckdifferenz
von –80
bis + 80 Hpa ausgehen. Durch Delta_p_Luft wird jedoch der eingeschränkte physikalische
Wertebereich von –10
bis +20 Hpa zugesichert.
-
Der
manuelle Codierer oder der automatische Codegenerator kann die in
der Zusicherung festgelegte Information über den kleineren physikalischen
Wertebereich zur Optimierung des Codes verwenden, z. B. indem er
auf der ECU entsprechend kleinere Datentypen zur Darstellung verwenden
kann (siehe auch Beispiel in Kapitel 5).
-
Implementierung von Zusicherungen
-
Wie
bereits beschrieben, ist die Umsetzung des in physikalischen Zusammenhängen (d.
h. als physikalisches Modell) beschriebenen Softwaremodells in Code
(bestehend aus Programmteil und Datenteil), der auf einem Mikroprozessor
einer ECU ablauffähig
ist, eine wesentliche Funktionalität entsprechender Werkzeuge.
-
Für die Abbildung
der physikalischen Darstellung auf den ablauffähigen Code eines Mikroprozessors oder
auf die Übertragungsdarstellung
auf einem Kommunikationskanal werden Informationen benötigt, die
diese Abbildung und deren Eigenschaften beschreiben, und die im
folgenden Implementierung genannt werden.
-
Wenn
z. B. der Mikroprozessor einer ECU keine Fließkommarecheneinheit besitzt
oder der ablauffähige
Code eine vorhandene Fließkommarecheneinheit
nicht oder nur teilweise verwenden soll (z. B. aus Effizienzgründen), muss
der physikalisch spezifizierte Zusammenhang auf Datendarstellungen
und Algorithmen abgebildet werden, die ausschließlich mit der Festkommarecheneinheit
arbeiten. Eine solche Datendarstellung wird Festkommadarstellung
genannt.
-
Während die
Angabe von Implementierungen zur Beschreibung der Abbildung von
Datenelementen und Kommunikationskanälen und deren jeweiligen Eigenschaften
Stand der Technik sind, ergeben sich durch die Definition von Implementierungen
für Zusicherungen
wesentliche neue Aspekte, die Gegenstand dieser Erfindung sind:
Wie
in Kapitel 1 beschrieben, können,
um die genannte Abbildung zu beschreiben, für jede Zusicherung die folgenden
Eigenschaften angegeben werden:
- – Der Name
der Zusicherung im physikalischen Modell
- – Die
physikalische Einheit der Zusicherung im Modell
- – Der
physikalische Typ der Zusicherung, z. B. kontinuierlich, diskret,
logisch
- – Der
zulässige
physikalische Wertebereich der Zusicherung (Minimum und Maximum)
- – Weitere
physikalische Eigenschaften des Signalflusses, die sich durch Boolesche
-
Bedingungen
beschreiben lassen, z. B. ein maximaler Gradient, das Nichtenthaltensein
des Werts 0 in der Menge aller physikalisch möglichen Werte,...
-
Die
Parameter, die zur Beschreibung der physikalischen Eigenschaften
durch Zusicherungsbedingungen verwendet werden, werden im Folgenden
die Parameter einer Zusicherung genannt.
-
Beispiel:
-
Die
im oben dargestellten Beispiel definierte Zusicherung ist durch
die zwei Booleschen Zusicherungsbedingungen definiert:
- • Boolesche
Zusicherungsbedingung 1:
(–10 <= Delta_p_Luft) && (Delta_p_Luft <= 20)
oder
durch Parameter
(P1_min <=
Delta_p_Luft) && (Delta_p_Luft <= P1_max)
- • Boolesche
Zusicherungsbedingung 2:
Delta_p_Luft/dT < 2
oder durch Parameter
Delta_p_Luft/dT < P2_max
-
Die
Parameter P1_min, P1_max und P2_max werden Parameter der Zusicherung
genannt.
-
Über die
dargestellten Informationen hinaus, können als Implementierung für Zusicherungen
beispielsweise die folgenden Eigenschaften definiert werden:
- – Einstellungen
zur Benennung der Zusicherung im Code, z. B. Regeln zur Ableitung
des Namens aus dem physikalischen Modell und seiner Struktur (z.
B. durch Präfix
oder Postfix; Alias-Name,...)
- – Der
im ausführbaren
Code ggf. benötigte
Datentyp der Zusicherung (z. B. Bit, Festpunktzahl oder Fließkommazahl,
benötigte
Wortbreite und bei Festpunktzahlen die Information, ob ein Vorzeichen
dargestellt werden soll oder nicht)
- – Die
Formel, die die Umrechnung von der physikalischen Darstellung in
die Darstellung der Zusicherung im Code beschreibt (die so genannte
Umrechnungsformel)
- – Der
zulässige
Wertebereich der Zusicherung während
der Ausführung
im Code (Anmerkung: Der physikalische Wertebereich und der Wertebereich
im Code sind über
die Umrechnungsformel voneinander abhängig)
-
Diese
Abbildung ist beispielhaft in den Bildern 12 und 13 dargestellt.
-
Desweiteren
kann für
jede Zusicherung festgelegt werden,
- – Ob die
Parameter der Zusicherung durch einen Eingriff auf das Steuergerät von außen unter
bestimmten Bedingungen und Voraussetzungen modifizierbar (d. h.
kalibrierbar oder parametrierbar) sind oder nicht
- – Ob
die Parameter der Zusicherung auf der ECU für ein bestimmtes Kalibrier-
oder Parametrierverfahren in folgenden Entwicklungsschritten, in
der Produktion oder im Service zugänglich gemacht werden soll
oder nicht (z. B. für
das CAN Calibration Protocol, kurz CCP [11], oder das Extended Calibration
Protocol, kurz XCP [11],...)
- – Die
Eigenschaften der Zusicherung hinsichtlich des verwendeten Entwicklungs-,
Produktions- und
Serviceprozesses, z. B. ob sie Bestandteil einer automatisch erzeugten
Dokumentation sein soll; ob und wie sie in einer Beschreibungs-
oder Konfigurationsdatei für
Kalibrier-, Parametrier- und Software-Update-Werkzeuge für die weitere
Entwicklung, die Produktion und den Service dargestellt werden soll;
ob die Zusicherung nur unter bestimmten Bedingungen verwendet werden
soll, z. B. nur im Fall einer bestimmten Softwarevariante
- – Ob
Parameter der Zusicherung ggfs. im Speicher der ECU mehrfach angelegt
werden soll oder nicht.
-
Ein
erster Anwendungsfall dafür
ist die Ablage von Varianten für
Parameter, die z. B. in ROM-, FLASH- oder EEPROM-Bereichen durch
jeweils separate Datenstrukturen parallel abgelegt werden können, um
durch Umschaltung eines Konfigurationsparameters zwischen diesen
verschiedenen Parametervarianten verschiedene Datenvarianten betreiben
zu können.
Ein Beispiel dafür
ist in Bild 14 dargestellt. Alternativ kann der Parameter auch nur
einmalig z. B. im Flash-Speicher angelegt werden, wie in Bild 15
dargestellt. Die Variantensteuerung erfolgt dann durch Neuprogrammierung
des Speicher-Bereichs in dein der Parameter liegt. In beiden Fällen muss
eine Beschreibung für
den Parameter erzeugt werden, in der das jeweils realisierte Variantenkonzept
für die
verwendeten Parametrierwerkzeuge beschrieben ist.
- – weitere
spezifische Eigenschaften des Mikroprozessors und Steuergeräts, die
die Darstellung der Zusicherung betreffen.
- – ggfs.
Kommentare und Steueranweisungen, die im Code abgebildet werden
und für
weitere Entwicklungsschritte verwendet werden (z.B. zum Konfigurationsmanagement,
zur Compilersteuerung, zum Test, zur Änderungsdokumentation,...).
-
Je
nach Verwendungszweck (z. B. verwendeter Mikroprozessor, Mikrocontroller
oder Signalprozessor in der ECU, verwendetes Kommunikationssystem,...)
werden jedoch nicht immer die gesamten oben für die Implementierung genannten
Informationen für
die Abbildung benötigt.
Insbesondere für
logische Größen und Fließkommagrößen ist
eine Teilmenge davon ausreichend.
-
Das
physikalische Modell legt also nur soweit die Daten und das Verhalten
der Software fest, dass durch Eingabe der Implementierung in das
Entwicklungswerkzeug die Abbildung des physikalischen Modells auf
Code für
verschiedene, spezifische Anwendungsfälle automatisiert durch das
Entwicklungswerkzeug erfolgen kann. Das Modell an sich muss so bei
einem neuen Anwendungsfall nicht oder nur geringfügig verändert werden,
da sich alle wesentlichen Änderungen
auf die Implementierung beschränken.
Die Eingabe der Implementierung ist deshalb komfortabel im Entwicklungswerkzeug
zu unterstützen.
-
In
Erweiterung des obigen Beispiels ergibt sich durch die Implementierung
von Zusicherungen der wesentliche Vorteil, dass das Codegenerierungswerkzeug
zusätzliche
Information über
physikalische Randbedingungen erhält, die sich nicht oder nur
indirekt aus dem Modell ergeben, aber zur Optimierung des Codes
herangezogen werden können.
-
Beispiel:
-
In
Erweiterung des oben genannten Beispiels
Name
der Zusicherung: | Delta_p_Luft |
Berechnung
der Zusicherung: | Delta_p_Luft
= Sensor1.1 – Sensor1.2 |
Physikalische
Einheit der Zus.: | 1
Hpa |
Physikalischer
Datentyp der Zus.: | kontinuierlich |
-
Boolesche
Zusicherungsbedingung 1, im folgenden X1 genannt:
(–10 <= Delta_p_Luft) && (Delta_p_Luft <= 20)
sei die
Zusicherung Delta_p_Luft wie folgt implementiert:
- – Formel
f(phys) = 1·phys,
d. h. der implementierte Wert entspricht dem physikalischen Wert
- – Zulässiger Wertebereich
der Zusicherung während
der Ausführung
im Code:
(–10 <= Delta_p_Luft) && (Delta_p_Luft <= 20)
-
(Anmerkung:
Da der physikalische Wertebereich und der Wertebereich im Code sind über die
Umrechnungsformel voneinander abhängig sind, ist der implementierte
Wertebereich gleich dem physikalischen Wertebereich)
-
Betrachtet
wird ein physikalisches Modell
return(3·(Sensor1.1 – Sensor1.2));
-
Ist
die Zusicherung Delta_p_Luft mit dem genannten Wertebereich im Modell
nicht spezifiziert, so muss für
die Umsetzung in Code (vgl. Beispiel am Ende von Kapitel 4) aufgrund
der Vorschrift und den genannten Wertebereichen für Sensor1.1
und Sensor1.2 für
das Gesamtergebnis von einem Wertebereich von 3·(–80) bis 3·(+80), d. h. –240 bis
+240 ausgegangen werden. Dafür
wird für
den Rückgabewert
der Funktion eine 16 Bit breite vorzeichenbehaftete Größe benötigt.
-
Wird
die Berechnung dagegen wie folgt um die Zusicherung ergänzt
return
(3·Delta_p_Luft
(Sensor1.1 – Sensor1.2));
(wodurch
sich keine funktionale Änderung
des physikalischen Verhaltens ergibt, da der Anwender mit der Zusicherung
Delta_p_Luft lediglich einen Zusammenhang darstellt, der physikalisch
bereits existiert, sich dem Modell selbst aber nicht entnehmen lässt), so
kann für
das Gesamtergebnis bei der Umsetzung in Code der eingeschränkte implementierte
Wertebereich von 3·(–10) bis
3·(+20),
d. h. –30
bis +60 angenommen werden, so dass eine 8 Bit breite vorzeichenbehaftete
Größe ausreicht.
Im Beispiel kann also durch die Zusicherung eine Ersparnis von 8
Bit im Speicherbedarf erreicht werden, ohne das physikalische Verhalten
des Modells zu verändern
und ohne für
die Modellierung der zugesicherten Eigenschaften eigene Speicherzellen
zu benötigen.