-
Stand der Technik
-
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 Standardization of Automation- and Measuring Systems: XCP The universal measurement and calibration protocol. April 2003
-
Aus der Schrift Verwendung von Zusicherungen in einem modellbasierten Entwicklungsprozess. In: it+ti – Informationstechnik und Technische Informatik 44 (2002) 3, Oldenbourg Verlag, 2002 S. 137–144 von Andreas Rau und aus der Diplomarbeit „Implementierung von Test- und Diagnosefunktionen für Fahrwerksteuergeräte” von Joachim Boensch, Universität Tübingen, 1999, S. 1–91 sind Verfahren zur automatischen Codegenerierung aus MATLAB/Simulink bekannt, bei denen die Qualität des erzeugten Codes durch Zusicherungen als Mittel der Laufzeitkontrolle verbessert wird.
-
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.
-
Das Verfahren mit den Merkmalen des unabhängigen Anspruchs 1 hat den Vorteil, dass der generierte Code besonders speichereffizient ist.
-
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 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, die bei elektronischen Systemen häufig angewendet werden, sind beispielsweise:
-
a) 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
-
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 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
-
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 oder Fehlerbehandlungsmaßnahmen sind beispielsweise:
-
A) Verwendung von redundanten Werten
-
Wie für die Fehlererkennung ist 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
-
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 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
-
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 dem 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
-
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
-
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 Fahrzeugdiagnoseschnittstelle diagnostiziert werden.
-
• On-Board-Diagnosefunktionen
-
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 Austrage 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
-
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
-
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
-
Von den On-Board-Diagnosefunktionen erkannte Fehlersymptome werden in der Regel im Fehlerspeicherdes 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, 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 (engl. Malfunction Indicator Light, 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 ü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
-
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
-
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.
- • Darüber hinaus werden Verfahren zur automatisierten Abbildung des durch Zusicherungen spezifizierten abnormalen Verhaltens in Software-Überwachungsfunktionen durch die automatisierte Codegenerierung beschrieben
- • Des weiteren werden Verfahren zur optimierten Abbildung des durch Zusicherungen spezifizierten normalen Verhaltens in Software-Steuerungs- und Regelungsfunktionen durch die automatisierte Codegenerierung beschrieben.
- • 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.
-
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 automatisierte 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 dem 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
o Der Name der Zusicherung im physikalischen Modell
o Die physikalische Einheit der Zusicherung im Modell
o Der physikalische Typ der Zusicherung, z. B. kontinuierlich, diskret, logisch, ...
o Der erforderliche physikalische Wertebereich für die Zusicherung
o 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, ...
o Eine Fehlermeldung die beim Eintreten des abnormalen Funktionsverhaltens (beim Erkennen eines so genannten Fehlersymptoms) ausgegeben wird
o 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_Luft/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 [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 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 R dar, von deren Wahrheitswert die Ausgangsgrößen Y1 ... Ym, auch Aktionen 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 oben 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 muss.
-
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 oben 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 oben aufgeführten Beispiel 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 müsste 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 das entsprechende Beispiel).
-
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 oben beschrieben, können, um die genannte Abbildung zu beschreiben, für jede Zusicherung die folgenden Eigenschaften angegeben werden:
- o Der Name der Zusicherung im physikalischen Modell
- o Die physikalische Einheit der Zusicherung im Modell
- o Der physikalische Typ der Zusicherung, z. B. kontinuierlich, diskret, logisch
- o Der zulässige physikalische Wertebereich der Zusicherung (Minimum und Maximum)
- o 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 dem 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 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.
