Advertisement

Methoden und Werkzeuge in der Entwicklung

Chapter
Part of the ATZ/MTZ-Fachbuch book series (ATZMTZ)

Zusammenfassung

In diesem Kapitel werden Methoden und Werkzeuge zur durchgängigen Entwicklung von Fahrzeugfunktionen dargestellt, die durch Software realisiert werden. Dieses Kapitel orientiert sich an ausgewählten Prozessschritten nach Kap. 4. Die Auswahl umfasst Prozessschritte, die in der Entwicklung von Funktionen der Anwendungs-Software für elektronische Steuergeräte große Bedeutung haben oder Prozessschritte, welche die besonderen Anforderungen und Randbedingungen in der Fahrzeugentwicklung unterstützen.

In Abschn. 5.1 erfolgt zunächst ein Überblick über die unterschiedlichen Anforderungen und Möglichkeiten zur Realisierung der Offboard-Schnittstellen zwischen Entwicklungswerkzeugen und Steuergeräten. In den folgenden Abschnitten werden verschiedene Methoden und Werkzeuge dargestellt. Manche Methoden unterstützen mehrere Prozessschritte.

In der Entwicklung von Systemen und Software für Anwendungen mit hohen Sicherheits- und Zuverlässigkeitsanforderungen, wie sie im Fahrzeug häufig vorkommen, müssen in allen Phasen Maßnahmen zur Qualitätssicherung von Systemen und Software getroffen werden. Diese Anforderung wurde deshalb in diesem Kapitel besonders berücksichtigt.

In diesem Kapitel werden Methoden und Werkzeuge zur durchgängigen Entwicklung von Fahrzeugfunktionen dargestellt, die durch Software realisiert werden. Dieses Kapitel orientiert sich an ausgewählten Prozessschritten nach Kap.  4. Die Auswahl umfasst Prozessschritte, die in der Entwicklung von Funktionen der Anwendungs-Software für elektronische Steuergeräte große Bedeutung haben oder Prozessschritte, welche die besonderen Anforderungen und Randbedingungen in der Fahrzeugentwicklung unterstützen.

In Abschn. 5.1 erfolgt zunächst ein Überblick über die unterschiedlichen Anforderungen und Möglichkeiten zur Realisierung der Offboard-Schnittstellen zwischen Entwicklungswerkzeugen und Steuergeräten. In den folgenden Abschnitten werden verschiedene Methoden und Werkzeuge dargestellt. Manche Methoden unterstützen mehrere Prozessschritte.

In der Entwicklung von Systemen und Software für Anwendungen mit hohen Sicherheits- und Zuverlässigkeitsanforderungen, wie sie im Fahrzeug häufig vorkommen, müssen in allen Phasen Maßnahmen zur Qualitätssicherung von Systemen und Software getroffen werden. Diese Anforderung wurde deshalb in diesem Kapitel besonders berücksichtigt.

Zur Analyse der logischen Systemarchitektur und zur Spezifikation der technischen Systemarchitektur können die in Abschn. 5.2 dargestellten Methoden eingesetzt werden:

Steuerungs- und regelungstechnische Analyse- und Entwurfsverfahren,

Analyse der Zuteilbarkeit und Spezifikation der Ablaufplanung bei Echtzeit- und Kommunikationssystemen,

Analyse und Spezifikation der Kommunikation bei verteilten und vernetzten Systemen,

Zuverlässigkeits- und Sicherheitsanalysen sowie Spezifikation von Zuverlässigkeits- und Sicherheitskonzepten.

Zur Spezifikation von Software-Funktionen und zur Validierung der Spezifikation können modellbasierte Methoden eingesetzt werden, die neben der eindeutigen und interpretationsfreien Formulierung der Anforderungen auch die frühzeitige Validierung einer Software-Funktion ermöglichen. In Abschn. 5.3 werden geeignete Methoden dafür behandelt, wie

Formale Spezifikation und Modellierung,

Simulation und Rapid-Prototyping.

Der Schwerpunkt von Abschn. 5.4 liegt auf Methoden und Werkzeugen zur Unterstützung von Design und Implementierung von Software-Funktionen. Bei dieser Abbildung der Spezifikation auf konkrete Algorithmen müssen auch die geforderten nichtfunktionalen Produkteigenschaften berücksichtigt werden. Dazu gehören beispielsweise

Optimierungsmaßnahmen in der Software-Entwicklung bezüglich der notwendigen Hardware-Ressourcen,

Verwendung eingeschränkter Teilmengen von Programmiersprachen bei hohen Zuverlässigkeits- und Sicherheitsanforderungen. Ein Beispiel sind die MISRA-C-Richtlinien [88],

Standardisierung und Wiederverwendung von Software-Komponenten zur Verringerung von Qualitätsrisiken.

Integration und Test von Software-Funktionen werden unterstützt durch ausgewählte Verfahren, die in Abschn. 5.5 beschrieben werden. Dazu gehören

Entwicklungsbegleitende Tests wie Komponententest, Integrationstest oder Systemtest auf verschiedenen Systemebenen,

Integrations-, System- und Akzeptanztests im Labor, an Prüfständen und im Fahrzeug.

Die Kalibrierung von Software-Funktionen erfordert häufig eine

Schnittstelle zwischen Mikrocontroller und Werkzeugen für die so genannte Online-Kalibrierung sowie

Fahrzeugtaugliche Kalibrier- und Messverfahren für Software-Funktionen.

Auf dafür geeignete Methoden und Werkzeuge wird in Abschn. 5.6 eingegangen.

Die praktische Bedeutung der vorgestellten Vorgehensweisen wird anhand von Beispielen aus den Anwendungsbereichen Antriebsstrang, Fahrwerk und Karosserie verdeutlicht.

5.1 Offboard-Schnittstelle zwischen Steuergerät und Werkzeug

In den verschiedenen Entwicklungsphasen werden zahlreiche Werkzeuge eingesetzt, die eine Offboard-Schnittstelle zu einem Mikrocontroller des Steuergeräts benötigen. Dies sind beispielsweise:

Werkzeuge für das Laden und Testen des Programms (engl. Download und Debugging),

Werkzeuge für das Software-Update durch Flash-Programmierung,

Werkzeuge für Entwicklung und Test der Netzwerkschnittstellen von Steuergeräten,

Rapid-Prototyping-Werkzeuge,

Mess- und Kalibrierwerkzeuge für den Einsatz in der Entwicklung,

Werkzeuge zur Parametrierung der Software-Funktionen,

Offboard-Diagnosewerkzeuge.

An die Schnittstellen zwischen Werkzeug und Steuergerät, die auf Werkzeug- und Steuergeräteseite durch Hardware- und Software-Komponenten unterstützt werden müssen, werden in den einzelnen Entwicklungsphasen unterschiedliche Anforderungen gestellt.

Anforderungsmerkmale an Offboard-Schnittstellen sind beispielsweise:

Einsatzfähigkeit im Labor und/oder unter rauen Bedingungen im Fahrzeug,

Zugriff des Werkzeugs auf den Mikrocontroller mit oder ohne Unterbrechung der Programmausführung durch den Mikrocontroller,

Unterschiedliche Anforderungen an die Höhe der Übertragungsleistung der Schnittstelle,

Einsatz nur während der Entwicklung oder auch in der Produktion und im Service,

Zugriff des Werkzeugs mit oder ohne Ausbau des Steuergeräts aus dem Fahrzeug.

Die Entwicklung eines elektronischen Systems des Fahrzeugs endet mit der Produktions- und Servicefreigabe. Für die Steuergeräteentwicklung bedeutet dies, dass der Akzeptanztest am Ende der Entwicklung mit den Offboard-Schnittstellen und Werkzeugen erfolgen muss, die auch in der Produktion und im Service eingesetzt werden.

Die für den Einsatz im Fahrzeug gestellten Anforderungen an die Offboard-Schnittstelle unterscheiden sich in vielen Punkten grundsätzlich von Laborbedingungen. Für den Fahrzeugeinsatz werden etwa bezüglich Temperaturbereich, Erschütterungen, Versorgungsspannung oder EMV höhere Anforderungen gestellt. Der Einbauort des Steuergeräts im Fahrzeug führt zu Einschränkungen des Bauraums für die Offboard-Schnittstelle und außerdem oft zu einer größeren, räumlichen Distanz zwischen Steuergerät und Werkzeug.

Aus diesem Grund werden im Verlauf der Entwicklung meist verschiedene Schnittstellentechnologien eingesetzt. Eine Übersicht über die Komponenten eines Mikrocontrollers, die für die Auslegung einer Offboard-Schnittstelle relevant sind, zeigt Abb. 5.1. Dies sind der Mikroprozessor, internes und externes ROM bzw. Flash und RAM, der interne und ggfs. externe Bus des Mikrocontrollers sowie die verschiedenen seriellen Schnittstellen des Mikrocontrollers.
Abb. 5.1

Schnittstellen des Mikrocontrollers

Auf die besonderen Anforderungen und den Aufbau von Offboard-Schnittstellen für die Kalibrierung von Software-Funktionen wird in Abschn. 5.6 eingegangen. Die Offboard-Schnittstellen für den Einsatz in Produktion und Service werden in Kap.  6 behandelt.

5.2 Spezifikation der technischen Systemarchitektur

Der erste Entwurfsschritt ist die Festlegung der logischen Systemarchitektur, d. h. des Funktionsnetzwerks, der Schnittstellen der Funktionen in Form von Signalen und der Kommunikation zwischen den Funktionen für das gesamte Fahrzeug oder für ein Subsystem des Fahrzeugs.

Im nächsten Schritt erfolgt die Abbildung dieser abstrakten, logischen Funktionen auf eine konkrete, technische Systemarchitektur. Dies wird durch Analyse- und Spezifikationsmethoden der an der Entwicklung beteiligten Fachdisziplinen unterstützt. Damit kann einerseits frühzeitig die technische Umsetzbarkeit beurteilt werden, andererseits können verschiedene Realisierungsalternativen einander gegenübergestellt und bewertet werden. In den folgenden Abschnitten werden einige Analyse- und Spezifikationsmethoden vorgestellt, welche Einfluss auf die Realisierung von Software-Funktionen haben.

5.2.1 Analyse und Spezifikation steuerungs- und regelungstechnischer Systeme

Viele Funktionen des Fahrzeugs haben steuerungs- oder regelungstechnischen Charakter. Da die Umsetzung von Steuerungs- oder Regelungsfunktionen zunehmend durch Software erfolgt, haben die Analyse- und Entwurfsverfahren der Steuerungs- und Regelungstechnik, die von Werkzeugen beispielsweise mit numerischen Simulationsverfahren unterstützt werden, großen Einfluss auf die Entwicklung vieler Software-Funktionen.

In diesem Abschnitt soll nicht auf die zahlreichen Analyse- und Entwurfsmethoden eingegangen werden. Dazu wird auf die Literatur, beispielsweise [34, 35], verwiesen. Dieser Abschnitt konzentriert sich auf Kriterien, die bei der Analyse und beim Entwurf von steuerungs- und regelungstechnischen Fahrzeugfunktionen frühzeitig beachtet werden müssen, falls die Funktionen durch elektronische Systeme und Software realisiert werden sollen.

Die Lösung von Steuerungs- und Regelungsaufgaben ist von den konstruktiven Gesichtspunkten der Steuer- oder Regelstrecke unabhängig. Entscheidend ist in erster Linie das statische und dynamische Verhalten der Strecke. Steuerungs- und regelungstechnische Analyseverfahren konzentrieren sich deshalb im ersten Schritt auf die Untersuchung der Strecke. Nach der Festlegung der Systemgrenze für die Strecke werden die Ein- und Ausgangsgrößen sowie die Komponenten der Strecke bestimmt. Mit Hilfe von Identifikationsverfahren erfolgt die Aufstellung der statischen und dynamischen Beziehungen zwischen den Komponenten in Form von physikalischen Modellgleichungen. Diese Modellsicht auf die Strecke stellt die Basis für alle Entwurfsverfahren dar.

Alle Komponenten eines elektronischen Systems, die zur Lösung einer Steuerungs- oder Regelungsaufgabe notwendig sind – wie Sollwertgeber, Sensoren, Aktuatoren und Steuergeräte – werden dabei zunächst der zu entwerfenden Steuerung oder dem zu entwerfenden Regler zugeordnet. Dies vereinfacht die Systemsicht während dieser Phase auf die in Abb. 5.2 dargestellten Komponenten, Schnittstellen und Beziehungen. Erst beim Entwurf der technischen Systemarchitektur wird die konkrete technische Struktur der Steuerung oder des Reglers festgelegt.
Abb. 5.2

Sicht auf die logische Systemarchitektur in der steuerungs- und regelungstechnischen Analysephase

Betrachtet man z. B. einen Ottomotor auf diese Art und Weise als Strecke, so erkennt man rasch die Stellgrößen Y – wie Einspritzmenge, Zündzeitpunkt, Drosselklappenstellung und so fort. Die interne Struktur der Strecke ist häufig komplex, da zwischen den verschiedenen Komponenten meist zahlreiche Wechselwirkungen bestehen. Ein vergleichsweise einfacher Fall für eine Strecke ist in Abb. 5.3 dargestellt. Die Strecke besteht hier aus sieben Komponenten, die mit „Strecke 1“ … „Strecke 7“ bezeichnet sind. Auf dieser Basis wird die logische Architektur des Steuerungs- und Regelungssystems entworfen. Im Entwurf von Abb. 5.3 sind vier Reglerkomponenten „Regler 1“ … „Regler 4“ und drei Steuerungskomponenten „Steuerung 5“ … „Steuerung 7“ vorgesehen.
Abb. 5.3

Logische Systemarchitektur des Steuerungs- und Regelungssystems

Anschließend erfolgt schrittweise der Entwurf der Steuerungs- und Regelungsstrategie für die einzelnen Steuerungs- und Regelungskomponenten, schließlich der Entwurf der technischen Systemarchitektur, also der notwendigen Aktuatoren, Sollwertgeber und Sensoren sowie der elektronischen Steuergeräte und ihrer Software-Funktionen. Dieser Schritt ist in Abb. 5.4 beispielhaft für den „Regler 3“ dargestellt.
Abb. 5.4

Entwurf der technischen Systemarchitektur des Reglers 3

Methoden zur Spezifikation von Software-Funktionen werden in Abschn. 5.3 behandelt.

Bei diesem Entwurfsschritt muss beachtet werden, dass das Übertragungsverhalten der verwendeten Komponenten eines elektronischen Systems in vielen Anwendungsfällen im Kraftfahrzeug nicht als „ideal“ angenommen werden darf. Aus Kostengründen werden meist Sollwertgeber, Sensoren, Aktuatoren und Hardware-Bausteine mit begrenzter Auflösung und Dynamik verwendet. Außerdem muss die zeit- und wertdiskrete Arbeitsweise der Mikrocontroller berücksichtigt werden. Das bedeutet, dass bereits frühzeitig in der Entwurfsphase eines Steuerungs- und Regelungssystems

Effekte durch die wertdiskrete Arbeitsweise – etwa durch die begrenzte Auflösung –

Nichtlinearitäten – etwa durch Begrenzungen –

Verzögerungs- oder Totzeiten – durch die begrenzte Dynamik –

der eingesetzten Sollwertgeber, Sensoren, Aktuatoren sowie der A/D- und D/A-Wandler der Mikrocontroller berücksichtigt werden müssen.

Die Realisierung der Software-Funktionen wird vielfach durch die begrenzten Hardware-Ressourcen der eingesetzten Mikrocontroller beeinflusst. Die folgende Punkte müssen dabei beachtet werden:

Fehler durch Rundung und die Behandlung von Über- und Unterläufen – etwa bei Einsatz von Integerarithmetik –

Approximationsfehler – durch die eingeschränkte Genauigkeit der Algorithmen –

Effekte durch die zeitdiskrete Arbeitsweise der Mikrocontroller.

Die Zeitkonstanten der Strecke bestimmen die notwendige Abtastrate dT der Steuerung oder Regelung, und dadurch auch die Abtastrate dTn für eine Software-Funktion fn.

Abb. 5.5 zeigt die Außenansicht einer Software-Funktion in dieser Entwicklungsphase.
Abb. 5.5

Außenansicht einer Software-Funktion fn

Die in Abb. 5.3 dargestellten Steuerungs- und Regelungskomponenten können auch gemeinsam durch ein Steuergerät realisiert werden, wie in Abb. 5.6 dargestellt. Die Regelungs- und Steuerungskomponenten 1 … 7 sollen durch Sollwertgeber, Sensoren, Aktuatoren, A/D-Wandler, D/A-Wandler und die Software-Funktionen f1 … f7 realisiert werden.
Abb. 5.6

Entwurf der technischen Systemarchitektur des Steuerungs- und Regelungssystems

Wie in Abb.  2.60 dargestellt, kann diese Vorgehensweise auch für die Spezifikation der Überwachungs- und Diagnosefunktionen eingesetzt werden.

Als Ergebnis liegt für alle Software-Funktionen fn eine Spezifikation der Steuerungs-, Regelungs- und Überwachungsstrategie, der Ein- und Ausgangssignale und der notwendigen Abtastrate dT n vor. Die in den folgenden Abschnitten dargestellten Verfahren gehen von diesen Informationen aus.

5.2.2 Analyse und Spezifikation von Echtzeitsystemen

Sollen mehrere Software-Funktionen mit unterschiedlichen Abtastraten durch ein Steuergerät oder ein Steuergerätenetzwerk realisiert werden, so erfolgt die Aktivierung der Software-Funktionen durch verschiedene Tasks, an die unterschiedliche Echtzeitanforderungen gestellt werden.

Die Einhaltung der Echtzeitanforderung einer Task ist bei vielen Anwendungen im Fahrzeug von großer Bedeutung. Bei der Analyse und Spezifikation des Echtzeitsystems müssen in diesem Fall die Auswirkungen, die sich aus der Zuteilungsstrategie des Betriebs- und Kommunikationssystems ergeben, genau berücksichtigt werden.

Mit Verfahren zur Zuteilbarkeitsanalyse (engl. Schedulability Analysis) ist es möglich, die Einhaltung der Echtzeitanforderungen, wie sie in Abb.  2.18 definiert wurden, frühzeitig abzuschätzen und zu bewerten, also schon bevor das Echtzeitsystem zum Einsatz kommt.

Dabei kann zwischen einer Analyse der Zuteilbarkeit eines Prozessors an verschiedene Tasks und einer Analyse der Zuteilbarkeit eines Busses an verschiedene Teilnehmer eines Kommunikationssystems unterschieden werden. Die für beide Aufgabengebiete verwendeten Methoden sind recht ähnlich. In diesem Abschnitt wird eine mögliche Vorgehensweise anhand der Prozessorzuteilung behandelt. In praktischen Anwendungen werden diese Analyseverfahren durch geeignete Entwurfs-, Verifikations- und Überwachungsprinzipien ergänzt.

Als Ergebnis liegt eine Spezifikation des Echtzeitsystems vor, bei dem alle Software-Funktionen ggf. in Prozesse aufgeteilt und die Prozesse Tasks zugeordnet wurden.

Ohne Einschränkung der Allgemeingültigkeit wird zunächst angenommen, dass für alle Tasks des Echtzeitsystems die Echtzeitanforderungen in einheitlicher Weise definiert werden durch:

Die konstante oder variable Zeitspanne zwischen zwei Aktivierungen einer Task, in Abb. 5.7 als Aktivierungsrate bezeichnet, und
Abb. 5.7

Definition der Echtzeitanforderungen für die Zuteilbarkeitsanalyse am Beispiel der Task A

Eine zum Aktivierungszeitpunkt relativ vorgegebene Zeitschranke bis zu der die Ausführung einer Task abgeschlossen sein soll. Diese Zeitschranke wird als relative Deadline bezeichnet.

Eine Verletzung der Echtzeitanforderung für eine Task liegt dann vor, falls die Ausführung der Task nicht innerhalb dieser vorgegebenen Zeitschranke abgeschlossen wird – also falls:

Response-Zeit > relative Deadline.

Die Response-Zeit ist keine konstante Größe; sie wird durch verschiedene Faktoren beeinflusst. Eine typische Verteilung der Response-Zeit einer Task ist in Abb. 5.8 dargestellt. Kritisch für die Verletzung der Echtzeitanforderung ist der größte auftretende Wert der Response-Zeit (engl. Worst Case Response Time , kurz WCRT ).
Abb. 5.8

Wahrscheinlichkeitsverteilung der Response-Zeit für die Task A

Der Nachweis, dass die Echtzeitanforderungen eingehalten werden, ist durch Tests unter verschiedenen Randbedingungen und gleichzeitiger Messung der Response-Zeit mit einem ausreichend hohen Vertrauensniveau häufig nicht möglich. Mit zunehmender Anzahl von Tasks und komplexeren Echtzeitanforderungen und Zuteilungsstrategien ist dieser Nachweis durch Tests oft sogar unmöglich. Auch nach „erfolgreich“ abgeschlossenen Tests kann es möglich sein, dass die Ausführung einer Task in kritischen Situationen erst nach der Deadline abgeschlossen wird. In diesen Fällen wird dann die Echtzeitanforderung verletzt, da der in den Tests beobachtete und gemessene größte Wert der Response-Zeit nicht mit dem größten auftretenden Wert identisch ist.

Typischerweise wird deshalb in der Praxis eine Kombination aus dreierlei Maßnahmen eingesetzt:

Zuteilbarkeitsanalyse zur Bewertung von Realisierungsalternativen,

Verifikation der Ergebnisse der Zuteilbarkeitsanalyse durch Messungen nach der Realisierung,

Online-Überwachung der Deadline durch das Echtzeitbetriebssystem (Deadline-Monitoring ) und anwendungsspezifische Reaktion auf Deadline-Verletzungen.

5.2.2.1 Zuteilbarkeitsanalyse

Das Ziel der Zuteilbarkeitsanalyse ist, unter Verwendung aller bekannten Parameter die Einhaltung der Echtzeitanforderungen in allen Fällen vorab abzuschätzen.

Für ein Echtzeitsystem ergibt sich also die Anforderung:

Worst Case Response Time ≤ relative Deadline.

Dazu muss also die Worst Case Response Time (WCRT) bestimmt oder abgeschätzt werden.

Im einfachen Fall, wie in Abb. 5.7 dargestellt, wird die Response-Zeit zum einen durch die Zeitspanne zwischen Aktivierung und Start der Ausführung einer Task bestimmt, zum anderen durch die Ausführungszeit (engl. Execution Time) der Task.

Der allgemeine Fall ist schwieriger, da die Ausführung einer Task z. B. durch die Ausführung einer oder mehrerer anderer Tasks mit höherer Priorität, die zudem zeit- oder ereignisgesteuert aktiviert werden können, unterbrochen werden kann. Auch die dabei entstehenden Unterbrechungszeiten und die Ausführungszeit, die das Betriebssystem beispielsweise für einen Task-Übergang selbst benötigt, beeinflussen die WCRT.

Allgemein kann die WCRT einer Task in zwei Schritten bestimmt oder abgeschätzt werden.

Im ersten Schritt erfolgt eine Bestimmung oder Abschätzung der maximal notwendigen Ausführungszeit für jede Task (engl. Worst Case Execution Time, WCET). Außerdem müssen die Ausführungszeiten, die das Betriebssystem selbst benötigt, bestimmt oder abgeschätzt werden.

Im zweiten Schritt kann unter Berücksichtigung der Echtzeitanforderungen und der Zuteilungsstrategie eine Abschätzung erfolgen, ob die Bedingung (5.2) für alle Aktivierungen der entsprechenden Tasks erfüllt werden kann oder nicht.

Beispiel

Zuteilbarkeitsanalyse

Der geplante Tagesablauf eines Managers soll auf Zuteilbarkeit untersucht werden. Der Manager schläft alle 24 Stunden 8 Stunden lang. Er isst alle 8 Stunden für 30 Minuten. Alle 1,5 Stunden trinkt er 15 Minuten und alle 2 Stunden telefoniert er 30 Minuten.

Dabei darf das Essen um maximal 30 Minuten verzögert werden, das Trinken ebenfalls um 30 Minuten, Telefonieren dagegen nur um 15 Minuten. Das Schlafen soll innerhalb von 24 Stunden abgeschlossen sein. Daraus ergeben sich die Deadlines für Schlafen 24 Stunden, für Essen 1 Stunde, für Trinken 45 Minuten und für Telefonieren 45 Minuten.

Unter der Annahme einer präemptiven Zuteilungsstrategie nach dem Basis-Zustandsmodell für Tasks nach AUTOSAR (Abb.  2.20) soll geprüft werden, ob der Manager neben diesen Tätigkeiten weitere Termine wahrnehmen kann. Insgesamt muss der Manager bisher also 4 Tasks ausführen:

Task A: „Schlafen“

Task B: „Essen“

Task C: „Trinken“

Task D: „Telefonieren“

Die Prioritäten sind Telefonieren vor Essen vor Trinken vor Schlafen. Der geplante Tagesablauf kann in tabellarischer Darstellung mit den Prioritäten, Aktivierungs-, Deadline- und Ausführungszeiten zusammengefasst werden, Tab. 5.1.
Tab. 5.1

Task-Liste des Managers

Die Zuteilbarkeit kann anhand des folgenden Ausführungsszenarios untersucht werden (Abb. 5.9):
Abb. 5.9

Zuteilungsdiagramm vor der Optimierung

Task D – „Telefonieren“ – mit der höchsten Priorität wird – wie erwartet – ohne Verletzung der Echtzeitanforderungen alle 2 Stunden ausgeführt.

Task B – „Essen“ – wird um 6, 14 und 22 Uhr gleichzeitig mit Task D aktiviert, wegen geringerer Priorität aber erst nach Task D, also mit einer Verzögerung von 30 Minuten, ausgeführt. Die Deadline wird gerade noch eingehalten.

Task C – „Trinken“ – wird alle 90 Minuten aktiviert, wegen geringer Priorität kann die Ausführung jedoch durch Task B und Task D unterbrochen oder verzögert werden. In vier Fällen wird die Deadline von 45 Minuten gerade noch eingehalten. Der Worst Case tritt um 6 Uhr ein. Die Response-Zeit ist hier 75 Minuten und die Deadline wird verletzt. Bereits 15 Minuten nach Abschluss der Ausführung, wird die Task C erneut aktiviert.

Task A – „Schlafen“ – hat die geringste Priorität und wird erst mit einer Verzögerung von 75 Minuten gestartet und wie erwartet häufig unterbrochen. Von der Aktivierung bis zum Ende der Ausführung vergehen über 15 Stunden.

Die kritische Situation um 6 Uhr bei Task C sowie die Grenzsituationen bei Task B zur Verletzung der Echtzeitanforderungen können durch verschiedene Maßnahmen entschärft werden. In Abb. 5.10 ist ein Szenario dargestellt, bei dem Task B nicht zeitgleich mit Task D aktiviert wird, sondern jeweils um eine Stunde versetzt, also um 7, 15 und 23 Uhr. Dadurch können die Echtzeitanforderungen von Task B immer sicher erfüllt werden. Auch die kritische Situation von Task C um 6 Uhr wird so entschärft. Allerdings wird weiterhin in fünf Fällen die Deadline gerade noch eingehalten. Eine Erhöhung der Deadline von Task C auf beispielsweise 60 Minuten oder die Erhöhung der Priorität wären – falls möglich – weitere Maßnahmen zur Reduzierung kritischer Situationen. Wie erwartet wirken sich die getroffenen Maßnahmen nicht auf Task A mit der geringsten Priorität aus.
Abb. 5.10

Zuteilungsdiagramm nach der Optimierung

Auch die Lösung der eigentlichen Aufgabe, die Einplanung weiterer Termine in Form der Task E ist nun möglich. Wie Abb. 5.10 zeigt, lässt die Auslastungssituation die Einplanung weiterer täglicher Tasks zwischen 14 und 22 Uhr zu. Um eine gleichmäßigere Auslastung des Managers zu erreichen, könnte die Task „Schlafen“ auch auf zwei Tasks „Nachtschlaf“ und „Nachmittagsschlaf“ aufgeteilt werden. Es kann auch abgeschätzt werden, wie sich unvorhergesehene Unterbrechungen mit höherer Priorität, beispielsweise ein Anruf eines Kunden beim Manager, auswirken.

Dieses fiktive Beispiel wurde bewusst sehr abstrakt gewählt, verdeutlicht aber die möglichen Auslegungsfehler bei Echtzeitsystemen und die Auswirkungen von Optimierungsmaßnahmen.

Neben Aussagen zur Zuteilbarkeit für alle Tasks sind Aussagen zur Auslastung, also zu Überlast- und Unterlastsituationen, möglich, die für eine verbesserte Vorgabe der Echtzeitanforderungen genutzt werden können. Dadurch wird das Echtzeitsystem gleichmäßiger ausgelastet. Unter Umständen können bei gleichmäßigerer Auslastungssituation dann sogar die notwendigen Hardware-Ressourcen, wie etwa der Prozessortakt, reduziert werden.

Eine Idealisierung ist die Annahme, dass Tasks geringerer Priorität an jeder beliebigen Stelle durch Tasks höherer Priorität unterbrochen werden können. In praktischen Anwendungen treten hier häufig Einschränkungen auf – auf das Beispiel übertragen etwa in der Form, dass die Task „Schlafen“ nur alle zwei Stunden unterbrochen werden kann.

Eine weitere Idealisierung ist die Annahme, dass der Wechsel von einer Task zu einer anderen Task verzögerungsfrei erfolgt. Auch hier bestehen in realen Anwendungen Einschränkungen – im Beispiel wäre etwa beim Task-Übergang von „Schlafen“ zu „Telefonieren“ eine Verzögerungs- oder Aufwachphase vorzusehen.

Bei der Übertragung dieser Vorgehensweise auf eine praktische Fahrzeuganwendung müssen zusätzlich die Ausführungszeiten berücksichtigt werden, die das Echtzeitbetriebssystem selbst benötigt. Diese können beträchtlich sein und von vielen Parametern abhängen, insbesondere auch von der gewählten Zuteilungsstrategie.

Eine weitere Aufgabe ist die Abschätzung der maximal notwendigen Ausführungszeit WCET für eine Task. Auch diese hängt in der Regel von vielen Parametern ab.

Verfahren zur Berechnung oder Abschätzung der Ausführungszeiten, beispielsweise auf Basis der vom Compiler generierten Befehle, sind aufwändig und nur möglich, wenn sie auf einzelne Situationen zugeschnitten werden. Dieses Themengebiet ist Gegenstand vielfältiger Forschungsaktivitäten.

Generell muss die Verwendung aller Programmkonstruktionen, deren Bearbeitung beliebig lange dauern kann, wie etwa Wiederholungsschleifen oder Wartezustände, dabei stark eingeschränkt werden. Iterative Algorithmen sollten deshalb in einer Form realisiert werden, so dass pro Task-Aktivierung nur ein oder nur endlich viele Iterationsschritte berechnet werden [54]. Ist dies nicht möglich, kann eine Worst-Case-Abschätzung für die Ausführungszeit iterativer Algorithmen nicht erfolgen.

5.2.2.2 Verifikation der Zuteilbarkeit durch Messungen

Durch die Messung der Aktivierungs- und Ausführungszeiten am realen System und eine Darstellung in Form eines Zuteilungsdiagramms ist die Verifikation des Echtzeitverhaltens möglich. Damit können grobe Auslegungsfehler erkannt und die Einstellungen des Echtzeitsystems iterativ verbessert werden.

Trotzdem muss, wie in Abb. 5.8 dargestellt, beachtet werden, dass die gemessenen oder beobachteten Ausführungszeiten nur einen ungefähren Anhaltswert für die maximale Ausführungszeit und die Response-Zeit liefern.

Außerdem kann bei ereignisgesteuerten Systemen, bei denen beispielsweise variable Task-Aktivierungszeiten und Ereignisse – wie Interrupts – vorkommen können, meist nicht sichergestellt werden, dass das System sich während der Messung überhaupt in der kritischen Auslastungssituation befindet.

5.2.2.3 Überwachung und Behandlung von Deadline-Verletzungen im Betriebssystem

Die Gefahr von Deadline-Verletzungen kann für eine Task durch Änderung verschiedener Attribute reduziert werden, etwa der Priorität, der Deadline oder durch Einstellen eines Aktivierungsverzugs. Über Ausnahmebehandlungen kann das Verhalten in Überlastsituationen festgelegt werden. Dazu zählen beispielsweise „Entprellungsmaßnahmen“ (engl. Debouncing), wie die Definition einer maximalen Anzahl von Mehrfachaktivierungen für eine Task oder die Vorgabe einer minimalen Zeitspanne zwischen zwei Aktivierungen einer Task.

Um derartige Ausnahmesituationen möglichst während der Entwicklungsphase erkennen zu können, werden die Ausnahmebedingungen während der Entwicklungsphase häufig schärfer gewählt als später in der Serienproduktion.

Trotzdem kann auch im für die Serienproduktion freigegebenen Software-Stand bei Tasks, an die harte Echtzeitanforderungen gestellt werden, in vielen Fällen auf eine Online-Überwachung der Deadline durch das Echtzeitbetriebssystem und die anwendungsspezifische Behandlung von Deadline-Verletzungen nicht verzichtet werden.

Dies kann etwa durch funktionsspezifische Fehlerbehandlungsroutinen (engl. Error Hooks ) realisiert werden, die vom Echtzeitbetriebssystem bei erkannten Deadline-Verletzungen aufgerufen werden. Diese Software-Überwachungsmaßnahmen ergänzen dann die durch die Hardware realisierten Überwachungsmaßnahmen, etwa die Überwachung der Programmausführung mit einer Watchdog-Schaltung.

5.2.3 Analyse und Spezifikation verteilter und vernetzter Systeme

Die Erfassung der Eingangsgrößen der Software-Funktionen eines Steuergeräts kann durch Sensoren, die dem Steuergerät direkt zugeordnet werden, erfolgen. Alternativ können auch Signale von Sensoren, die anderen Steuergeräten zugeordnet sind, über das Kommunikationsnetzwerk des Fahrzeugs übertragen und gewissermaßen indirekt verwendet werden. Entsprechende Freiheitsgrade bestehen auch bei den Aktuatoren. Auch alle in den Steuergeräten intern berechneten Signale und Zustände können über das Kommunikationsnetzwerk übertragen werden.

Dadurch werden einerseits große Freiheitsgrade beim Funktionsentwurf ermöglicht, andererseits entstehen neue Entwurfsprobleme, nämlich die möglichst geschickte Verteilung von Software-Funktionen auf ein Netzwerk von Steuergeräten bzw. Mikrocontrollern und die Abstraktion beispielsweise von Sensoren und Aktuatoren. In diesem Abschnitt steht deshalb die analytische Bewertung verschiedener Verteilungs- und Vernetzungsalternativen im Mittelpunkt. Einige Freiheitsgrade, die durch die flexible direkte und indirekte Realisierung logischer Kommunikationsverbindungen zwischen den Komponenten elektronischer Systeme möglich werden, sind in Abb. 5.11 dargestellt. In der grafischen Darstellung wird zwischen Sensoren und intelligenten Sensoren und entsprechend auch zwischen Aktuatoren und intelligenten Aktuatoren unterschieden.
Abb. 5.11

Analyse der logischen Architektur verteilter und vernetzter Systeme

Auch die Einflüsse des Kommunikationssystems, wie die Wertediskretisierung der Signale bei der Übertragung durch Nachrichten oder die Übertragungszeiten des Kommunikationssystems, haben weitreichende Konsequenzen und sollten bei der Auslegung eines verteilten und vernetzten Systems bereits zu einem möglichst frühen Zeitpunkt berücksichtigt werden.

Methoden zur Analyse verteilter und vernetzter Systeme ermöglichen die Beurteilung dieser Einflussfaktoren. Dabei müssen zahlreiche Anforderungen und Randbedingungen – z. B. Bauraum-, Echtzeit-, Sicherheits- und Zuverlässigkeitsanforderungen – berücksichtigt werden.

Als einführendes Beispiel wird angenommen, dass die Software-Funktionen des in Abb. 5.6 dargestellten Steuerungs- und Regelungssystems auf verschiedene Mikrocontroller verteilt werden sollen. Zunächst soll festgehalten werden, welche Anforderungen bisher schon für die Software-Funktionen feststehen. Dies sind zum einen die Eingangs- und Ausgangssignale, zum anderen auch die Abtastrate dT. Eine tabellarische Darstellung dieser Anforderungen zeigt Abb. 5.12.
Abb. 5.12

Tabellarische Darstellung der Software-Funktionen mit Abtastrate dTn und Signalen

Zur Zuordnung dieser Software-Funktionen auf verschiedene Mikrocontroller wird in dieser Tabelle, wie in Abb. 5.13 dargestellt, eine neue Spalte eingeführt, in der vermerkt wird, wo welche Funktionen realisiert werden sollen. Funktion f1 wird auf Mikrocontroller μC1.1 berechnet, Funktion f2 auf Mikrocontroller μC2.1 und Funktion f3 auf Mikrocontroller μC1.2. Bei dieser Verteilung sind Randbedingungen der gegebenen Hardware-Architektur zu berücksichtigen – etwa in der Form, dass die Verteilung der Funktionen durch die bereits feststehende Zuordnung der Sensoren und Aktuatoren zu bestimmten Mikrocontrollern eingeschränkt wird. So wird man beispielsweise eine Funktion, die Sensorsignale vorverarbeitet, direkt dem Mikrocontroller zuordnen, dem auch der entsprechende Sensor zugeordnet ist.
Abb. 5.13

Zuordnung der Software-Funktionen zu Mikrocontrollern

Im Folgenden sind zwei Fälle zu unterscheiden:

Treten in der Tabelle in Abb. 5.13 Signale mehrfach und bei verschiedenen Mikrocontrollern auf, so müssen diese über das Netzwerk kommuniziert werden. Auf diese Weise erhält man die Menge aller Signale, die vom Kommunikationssystem zu übertragen sind. Im einfachen Beispiel von Abb. 5.13 ist das nur für Signal S1 der Fall, das von Mikrocontroller μC2.1 an Mikrocontroller μC1.1 gesendet werden muss.

Treten dagegen in der Tabelle von Abb. 5.13 Signale beim gleichen Mikrocontroller mehrfach bei verschiedenen Funktionen auf, für die unterschiedliche Abtastraten vorgegeben sind, so sind diese über Task-Grenzen zu kommunizieren. Auf diese Weise erhält man die Menge aller Signale, die die Inter-Task-Kommunikation übertragen muss.

Im erstgenannten Fall stellt sich sofort die Frage, mit welchen zeitlichen Anforderungen, beispielsweise mit welcher Zykluszeit, die Übertragung der Signale über das Netzwerk erfolgen soll. Im vorliegenden Beispiel, wo Funktion f2 das Signal S1 mit einer Zeitrate von 20 ms berechnet, macht es natürlich wenig Sinn das Signal S1 mit einer schnelleren Rate zu übertragen – auch wenn, wie in Abb. 5.13, die empfangende Funktion f1 mit der schnelleren Zeitrate von 10 ms berechnet wird. Man wird in diesem Fall deshalb festlegen Signal S1 mit der Rate von 20 ms zu übertragen.

Würde dagegen die empfangende Funktion f1 mit einer langsameren Zeitrate berechnet, kann das Kommunikationssystem entlastet werden, indem das Signal mit der Zeitrate der empfangenden Funktion übertragen wird. In jedem Fall ist also zwischen der Zeitrate der Signalübertragung (Übertragungsrate), der notwendigen Übertragungszeit für die Signalübertragung und der Zeitrat dT (Abtastrate) für die Berechnung der sendenden und empfangenen Funktionen zu unterscheiden.

Eine zweite Festlegung betrifft die Auflösung und den Wertebereich der Signale bei der Übertragung. Auch hier muss die Auflösung, die der Empfänger einer Nachricht erwartet, berücksichtigt werden.

Bereits mit diesen Festlegungen auf der Signalebene können die Kommunikationslast abgeschätzt und Verteilungsalternativen bewertet werden.

Im nächsten Schritt muss das Kommunikationssystem festgelegt werden. Dabei müssen auch die Nachrichten, die vom Kommunikationssystem übertragen werden, gebildet werden. Das bedeutet, es muss festgelegt werden, mit welcher Nachricht ein Signal übertragen wird.

Aus Effizienzgründen wird man versuchen, verschiedene Signale, die ein Mikrocontroller mit der gleichen Übertragungsrate an den gleichen Empfängerkreis senden muss, gemeinsam mit einer einzigen oder möglichst wenigen Nachrichten zu übertragen.

Dazu ist es zweckmäßig, die Tabelle in Abb. 5.13 spalten- und zeilenweise umzusortieren und zur Kommunikationsmatrix zu erweitern. Dann steht in der ersten Spalte der Mikrocontroller, der die Signale versendet. Die Signale sind nach aufsteigender Übertragungsrate und nach Empfängern geordnet.

Nach der Bildung der Nachrichten erhält man die Kommunikationsmatrix, wie sie in Abb. 5.14 dargestellt ist. Signal S1 wird mit der Nachricht N3 übertragen. In Abb. 5.14 sind einige weitere Signale und Nachrichten dargestellt, die sich etwa aus weiteren Funktionen ergeben könnten, welche bisher nicht betrachtet wurden.
Abb. 5.14

Kommunikationsmatrix

Bei der Analyse des Netzwerks eines realen Fahrzeugs sind viele weitere Aspekte zu berücksichtigen. Neben einer deutlich höheren Anzahl an Signalen, Nachrichten, Sendern und Empfängern als hier dargestellt, werden beispielsweise Signale eines Senders in der Regel von mehreren Empfängern mit unterschiedlichen Zeitraten verarbeitet. Auch der Spielraum zur Verteilung der Funktionen ist in der Regel durch zahlreiche weitere Randbedingungen eingeschränkt.

Umso wichtiger ist deshalb die frühzeitige Analyse der Anforderungen, eine Bewertung von Realisierungsalternativen und die iterative Verbesserung des Netzwerkentwurfs.

Liegen das Kommunikationssystem, die Nachrichten und die Netzwerktopologie fest, so können die Angaben in der Kommunikationsmatrix soweit erweitert werden, dass mit Hilfe von Simulationen erste Aussagen, beispielsweise über die Buslast oder die zu erwartenden Kommunikationslatenzzeiten, gemacht werden können.

Als Ergebnis liegt eine Spezifikation des verteilten und vernetzten Systems vor, bei dem alle Software-Funktionen einem Mikrocontroller zugewiesen sind und die Kommunikationsmatrix vollständig definiert ist.

5.2.4 Analyse und Spezifikation zuverlässiger und sicherer Systeme

Zuverlässigkeits - und Sicherheitsanforderungen an Fahrzeugfunktionen ergeben sich aus den Kundenwünschen unter Berücksichtigung der technischen, gesetzlichen und finanziellen Randbedingungen. Zuverlässigkeitsanforderungen werden beispielsweise in Form von kurzen Reparaturzeiten oder langen Serviceintervallen vorgegeben. Sicherheitsanforderungen legen dagegen das sichere Verhalten des Fahrzeugs im Falle von Ausfällen und Störungen von Komponenten fest. Die an Fahrzeugfunktionen gestellten Zuverlässigkeits- und Sicherheitsanforderungen legen von Anfang an auch Anforderungen an die technische Realisierung und Nachweispflichten fest.

Systematische Methoden zur Zuverlässigkeits- und Sicherheitsanalyse haben deshalb zunehmenden Einfluss auf die Software-Entwicklung, etwa auf die Realisierung der Überwachungs-, Diagnose- und Sicherheitskonzepte. Für komplexe elektronische Systeme müssen die Aktivitäten zur Absicherung der Zuverlässigkeit und Sicherheit frühzeitig geplant und in den gesamten Projektplan integriert werden.

Zuverlässigkeits- und Sicherheitsanalysen umfassen Ausfallraten- und Ausfallartenanalysen sowie die Untersuchung und Bewertung von konkreten Möglichkeiten zur Verbesserung der Zuverlässigkeit oder der Sicherheit. Zu den Ausfallartenanalysen gehören die Ausfallarten- und Wirkungsanalyse (engl. FMEA) [62] und die Fehlerbaumanalyse (engl. FTA) [56, 57].

5.2.4.1 Ausfallratenanalyse und Berechnung der Zuverlässigkeitsfunktion

Die systematische Untersuchung der Ausfallrate einer Betrachtungseinheit ermöglicht die Voraussage der Zuverlässigkeit für die Betrachtungseinheit durch Berechnung. Diese Voraussage ist wichtig, um Schwachstellen frühzeitig zu erkennen, Alternativlösungen zu bewerten und Zusammenhänge zwischen Zuverlässigkeit, Sicherheit und Verfügbarkeit quantitativ erfassen zu können. Außerdem sind Untersuchungen dieser Art notwendig, um Zuverlässigkeitsanforderungen etwa an Komponenten stellen zu können.

Infolge von Vernachlässigungen und Vereinfachungen sowie der Unsicherheit der verwendeten Eingangsdaten kann die berechnete, vorausgesagte Zuverlässigkeit nur ein Schätzwert für die reale Zuverlässigkeit sein, die nur mit Zuverlässigkeitsprüfungen und Feldbeobachtungen zu ermitteln ist. Im Rahmen von Vergleichsuntersuchungen in der Analysephase spielt jedoch die absolute Genauigkeit keine Rolle, so dass besonders bei der Bewertung von Realisierungsalternativen die Berechnung der vorausgesagten Zuverlässigkeit nützlich ist.

In diesem Abschnitt ist die Betrachtungseinheit immer ein technisches System oder eine Systemkomponente. Im allgemeinen Fall kann die Betrachtungseinheit auch weiter gefasst werden und beispielsweise auch den Fahrer des Fahrzeugs mit einschließen.

Die Ausfallratenanalyse unterscheidet die folgenden Schritte:

Definition der Grenzen und Komponenten des technischen Systems, der geforderten Funktionen und des Anforderungsprofils,

Aufstellen des Zuverlässigkeitsblockdiagramms (engl. Reliability Block Diagram),

Bestimmung der Belastungsbedingungen für jede Komponente,

Bestimmung von Zuverlässigkeitsfunktion oder Ausfallrate für jede Komponente,

Berechnung der Zuverlässigkeitsfunktion des Systems,

Behebung der Schwachstellen.

Die Ausfallratenanalyse ist ein mehrstufiges Verfahren und wird „top down“ von der Systemebene über die verschiedenen Subsystemebenen bis zur Komponentenebene der technischen Systemarchitektur durchgeführt. Die Ausfallratenanalyse muss nach Änderungen der technischen Systemarchitektur wiederholt werden.

Definition der Systemgrenzen, der geforderten Funktionen und des Anforderungsprofils

Für die theoretischen Überlegungen, die zur Voraussage der Zuverlässigkeit notwendig sind, müssen eingehende Kenntnisse des Systems und seiner Funktionen sowie der konkreten Möglichkeiten zur Verbesserung der Zuverlässigkeit und Sicherheit vorausgesetzt werden.

Zum Systemverständnis zählt die Kenntnis der Architektur des Systems und seiner Wirkungsweise, die Arbeits- und Belastungsbedingungen für alle Systemkomponenten sowie die gegenseitigen Wechselwirkungen zwischen den Komponenten. Dazu gehören die Eingangs- und Ausgangsgrößen der Komponenten sowie die Signalflüsse zwischen Komponenten.

Zu den Verbesserungsmöglichkeiten gehören die Begrenzung oder die Verringerung der Belastung der Komponenten im Betrieb, etwa der statischen oder dynamischen Belastungen, der Belastung der Schnittstellen, der Einsatz besser geeigneter Komponenten, die Vereinfachung des System- oder Komponentenentwurfs, die Vorbehandlung kritischer Komponenten sowie der Einsatz von Redundanz.

Die geforderte Funktion spezifiziert die Aufgabe des Systems. Die Festlegung der Systemgrenzen und der geforderten Funktionen bildet den Ausgangspunkt jeder Zuverlässigkeits- und Sicherheitsanalyse, weil damit auch der Ausfall definiert wird.

Zusätzlich müssen die Umweltbedingungen für alle Komponenten des Systems definiert werden, da dadurch die Zuverlässigkeit der Komponenten beeinflusst wird. So hat z. B. der Temperaturbereich großen Einfluss auf die Ausfallrate von Hardware-Komponenten. Im Fahrzeug gehören z. B. der geforderte Temperaturbereich, der Einsatz unter Feuchtigkeit, Staub oder korrosiver Atmosphäre, oder Belastungen durch Vibrationen, Schocks oder Schwankungen, wie etwa der Versorgungsspannung zu den Umweltbedingungen. Hängen die geforderten Funktionen und die Umweltbedingungen außerdem von der Zeit ab, muss ein Anforderungsprofil festgelegt werden. Ein Beispiel für gesetzlich vorgeschriebene Anforderungsprofile sind die Fahrzyklen zum Nachweis der Einhaltung der Abgasvorschriften. In diesem Fall spricht man auch von repräsentativen Anforderungsprofilen.

Aufstellen des Zuverlässigkeitsblockdiagramms

Das Zuverlässigkeitsblockdiagramm gibt Antwort auf die Fragen, welche Komponenten eines Systems zur Erfüllung der geforderten Funktion grundsätzlich funktionieren müssen und welche Komponenten im Falle ihres Ausfalls die Funktion nicht grundsätzlich beeinträchtigen, da sie redundant vorhanden sind. Die Aufstellung des Zuverlässigkeitsblockdiagramms erfolgt, indem man die Komponenten der technischen Systemarchitektur betrachtet. Diese Komponenten werden in einem Blockdiagramm so verbunden, dass die zur Funktionserfüllung notwendigen Komponenten in Reihe geschaltet werden und redundante Komponenten in einer Parallelschaltung verbunden werden.

Beispiel

Aufstellen des Zuverlässigkeitsblockdiagramms für ein fiktives Brake-By-Wire-System

Für ein fiktives Brake-By-Wire-System, wie in Abb. 5.15 dargestellt, wird zunächst die Systemgrenze festgelegt. Das System besteht aus den Komponenten Bremspedaleinheit (K1), Steuergerät (K2), den Radbremseinheiten (K5, K7, K9, K11) und den elektrischen Verbindungen (K3, K4, K6, K8, K10).
Abb. 5.15

Systemsicht für ein Brake-By-Wire-System

Bei Brake-By-Wire-Systemen besteht zwischen der Bremspedaleinheit und den Radbremseinheiten keine hydraulische, sondern eine elektrische Verbindung. Beim Bremsen wird der Fahrerbefehl, der durch die Bremspedaleinheit K1 vorgegeben und im Steuergerät K2 verarbeitet wird, und die zum Bremsen notwendige Energie „by wire“ zu den Radbremseinheiten K5 K7, K9 und K11 übertragen. Dabei muss sichergestellt werden, dass die Übernahme der Funktionen „Informations- und Energieübertragung“ zwischen Pedaleinheit und Radbremseinheiten, die bei konventionellen Bremssystemen mechanisch-hydraulisch realisiert sind, durch die elektrischen und elektronischen Komponenten K2, K3, K4, K6, K8 und K10 kein zusätzliches Sicherheitsrisiko bringt. Die vorhersagbare Übertragung der Bremsbefehle ist deshalb eine zwingende Voraussetzung. Ebenso muss die Sicherheit auch bei Störungen und Ausfällen von Komponenten gewährleistet sein.

Es soll die Funktion „Bremsen“ betrachtet werden. Dafür soll die Gesamtzuverlässigkeit des Systems bestimmt werden. Es wird angenommen, dass die Ausfallraten λ1 bis λ11 der Komponenten K1 bis K11 bekannt sind.

Dieses Beispiel wird im Weiteren sehr stark vereinfacht. Es soll die prinzipielle Vorgehensweise bei der Zuverlässigkeitsanalyse verdeutlichen. Deshalb wird nur die Informationsübertragung betrachtet, während die Aspekte der Energieversorgung und der Energieübertragung sowie fahrdynamische Randbedingungen, wie die Bremskraftverteilung auf Vorder- und Hinterachse, die auch bei der Zuverlässigkeitsanalyse berücksichtigt werden müssen, vernachlässigt werden.

Für die Erfüllung der Funktion „Bremsen“ ist bei dieser vereinfachten Sicht das Funktionieren der Komponenten Bremspedaleinheit K1, Steuergerät K2 sowie der Verbindungen zwischen Bremspedaleinheit und Steuergerät K3 zwingend notwendig.

Bei den Radbremseinheiten und den Verbindungen zwischen Steuergerät und Radbremseinheiten ist Redundanz vorhanden. Unter der stark vereinfachten Annahme, dass eine ausreichende Hilfsbremswirkung für das Fahrzeug mit nur einer Radbremseinheit erzielt werden kann, sind dann beispielsweise die Komponenten K4 und K5 notwendig, während die Komponenten K6 und K7, K8 und K9 bzw. K10 und K11 redundant vorhanden sind. Eine derartige Anordnung wird auch als 1-aus-4-Redundanz bezeichnet.

Das Zuverlässigkeitsblockdiagramm für die Funktion „Bremsen“ sieht wie in Abb. 5.16 dargestellt aus.
Abb. 5.16

Zuverlässigkeitsblockdiagramm für die Funktion „Bremsen“ des Brake-By-Wire-Systems

Berechnung der Zuverlässigkeitsfunktion für das System

Nach Festlegung der Belastungsbedingungen und der Bestimmung der Zuverlässigkeitsfunktionen Ri(t) für alle Komponenten Ki, kann unter Berücksichtigung der in Abb. 5.17 dargestellten Grundregeln für Zuverlässigkeitsblockdiagramme [57] die Zuverlässigkeitsfunktion des Systems RS(t) berechnet werden.
Abb. 5.17

Einige Grundregeln zur Berechnung der Zuverlässigkeitsfunktion für das System. (Isermann [57])

Für das Beispiel in Abb. 5.16 kann damit die Zuverlässigkeitsfunktion des Systems RS berechnet werden. Mit den Annahmen R4 = R6 = R8 = R10 und R5 = R7 = R9 = R11 folgt für RS:

RS = R1 R2 R3 [1 − (1 − R4 R5)4].

Wie dieses vereinfachte Beispiel zeigt, erhöht sich die Systemzuverlässigkeit für eine Funktion durch redundante Komponenten im Zuverlässigkeitsblockdiagramm gegenüber der Komponentenzuverlässigkeit. Dagegen verringert sich bei den seriell dargestellten Komponenten die Systemzuverlässigkeit gegenüber der Komponentenzuverlässigkeit. Man wird daher für die seriellen Komponenten im Zuverlässigkeitsblockdiagramm bereits eine hohe Zuverlässigkeit von den Komponenten fordern müssen oder eine technische Systemarchitektur einführen, die auch hier redundante Strukturen vorsieht.

5.2.4.2 Sicherheits- und Zuverlässigkeitsanalyse für das System

Für die Sicherheitsanalyse ist es unwichtig, ob eine Betrachtungseinheit die von ihr geforderten Funktionen erfüllt oder nicht, sofern damit kein nicht vertretbar hohes Risiko eintritt. Maßnahmen zur Erhöhung der Sicherheit werden als Schutzmaßnahmen bezeichnet und zielen auf die Verringerung des Risikos.

Zuverlässigkeits- und Sicherheitsanalyse sind iterative und zusammenhängende Prozesse mit mehreren Schritten, wie in Abb.  4.18 dargestellt [71]. Sie haben Einfluss auf Anforderungen an die Hardware, Software und den Software-Entwicklungsprozess für elektronische Systeme. Auch für die Sicherheitsanalyse eines Systems werden häufig Methoden zur Ausfallartenanalyse eingesetzt. Die Ausfallartenanalyse liefert eine Bewertung des Risikos für alle Funktionen des Systems.

Das zulässige Grenzrisiko wird in der Regel durch sicherheitstechnische Festlegungen, wie Gesetze, Normen oder Verordnungen, implizit vorgegeben. Aus dem ermittelten Risiko für die Funktionen des Systems und dem zulässigen Grenzrisiko werden dann – beispielsweise anhand von Normen wie der ISO 26262 [64] oder IEC 61508 [20] – sicherheitstechnische Anforderungen an das System abgeleitet, die oft großen Einfluss auf den System- und Software-Entwurf in der Elektronikentwicklung haben.

Für die durch die Ausfallartenanalyse bestimmten und abgegrenzten, so genannten sicherheitsrelevanten Funktionen des Systems müssen besondere Schutzmaßnahmen getroffen werden, die in Hardware und Software realisiert werden können. Der Nachweis der Sicherheit ist Voraussetzung für die Zulassung von Fahrzeugen zum Straßenverkehr. Entsprechende Verifikations- und Validierungsverfahren müssen deshalb schon während der Analysephase geplant werden.

Beispiel

Überwachungskonzept für ein E-Gas-System

In Kap.  2 wurde bereits die Anforderungsklasse für ein E-Gas-System bestimmt (Abb.  2.58). Als mögliche Gefahr wurde ungewolltes Gasgeben und ein daraus folgender Unfall angenommen. Für das Motorsteuergerät bedeutet dies, dass alle diejenigen Steuerungs- und Regelungsfunktionen fn sicherheitsrelevant sind, die zu einer unbeabsichtigten Erhöhung des Motordrehmoments führen können. Für diese Funktionen ist deshalb ein Überwachungskonzept notwendig.

In diesem Beispiel soll das Überwachungskonzept, wie es seit Jahren in Motorsteuergeräten eingesetzt wird [79], in vereinfachter Form bezüglich der Sicherheit und Zuverlässigkeit untersucht werden. Im Rahmen des Arbeitskreises „E-Gas“ des Verbandes der Automobilindustrie (VDA) wird dieses von der Robert Bosch GmbH entwickelte Basiskonzept derzeit zu einem standardisierten Überwachungskonzept für Motorsteuerungen von Otto- und Dieselmotoren weiterentwickelt (Abb.  2.62).

In Abb. 5.18 ist das Überwachungskonzept für sicherheitsrelevante Steuerungs- und Regelungsfunktionen fn dargestellt.
Abb. 5.18

Überwachungskonzept für sicherheitsrelevante Funktionen des Motorsteuergeräts. (Van Basshuysen und Schäfer [79])

Die sicherheitsrelevanten Steuerungs- und Regelungsfunktionen fn werden durch die Überwachungsfunktionen fÜn ständig überwacht. Die Überwachungsfunktionen fÜn verwenden die gleichen Eingangsgrößen wie die Steuerungs- und Regelungsfunktionen fn, arbeiten aber mit unterschiedlichen Daten und mit unterschiedlichen Algorithmen.

Die Funktionen zur Überwachung der Mikrocontroller prüfen neben RAM-, ROM- und Mikroprozessorfunktionen beispielsweise auch, ob die Steuerungs- und Regelungsfunktionen fn und die Überwachungsfunktionen fÜn überhaupt ausgeführt werden. Dies macht den Einsatz eines zweiten Mikrocontrollers im Motorsteuergerät, eines so genannten Überwachungsrechners, notwendig. Die Funktionen zur Überwachung der Mikrocontroller werden auf den Funktionsrechner und den Überwachungsrechner verteilt. Beide überwachen sich in einem Frage-Antwort-Spiel gegenseitig.

Als sicherer Zustand ist die Stromabschaltung für die elektromechanische Drosselklappe festgelegt. Die Drosselklappe ist so konstruiert, dass sie nach einer Stromabschaltung selbsttätig die Leerlaufposition einnimmt. Der Übergang in den sicheren Zustand kann deshalb dadurch eingeleitet werden, dass eine Abschaltung der Endstufen des Steuergeräts, die die Drosselklappe ansteuern, erfolgt. Der Motor kann so im Notlauf weiterbetrieben werden.

Sowohl die Überwachungsfunktionen fÜn, als auch die Funktionen zur Überwachung der Mikrocontroller auf dem Funktions- und auf dem Überwachungsrechner können also die Drosselklappenendstufen des Steuergeräts abschalten.

Im Falle eines erkannten Fehlers wird neben dieser Sicherheitsreaktion auch ein Eintrag im Fehlerspeicher vorgenommen. Außerdem wird meist auch eine Information an den Fahrer etwa über eine Anzeige im Kombiinstrument ausgegeben.

Soll die Zuverlässigkeit dieses Überwachungskonzepts beurteilt werden, so sind zunächst drei Arten von Funktionen zu unterscheiden:

die Steuerungs- und Regelungsfunktionen fn,

die Überwachungsfunktionen fÜn,

die Funktionen zur Überwachung der Mikrocontroller.

Die Zuverlässigkeitsblockdiagramme für diese verschiedenen Funktionen lassen sich dann wie folgt bestimmen (Abb. 5.19).
Abb. 5.19

Zuverlässigkeitsblockdiagramme für Funktionen der Motorsteuerung

Um die Systemzuverlässigkeit zu bestimmen, wird man alle drei Arten von Funktionen gleichzeitig fordern. Dann ergibt sich die Systemzuverlässigkeit durch eine Reihenschaltung dieser Blockdiagramme. Zusätzlich müssen auch die Komponenten K7 und K8, die in den Blockdiagrammen der einzelnen Funktionen nicht vorkommen, in Reihe geschaltet werden.

Die Systemzuverlässigkeit RS Zuverlässigkeit ergibt sich durch Multiplikation der Zuverlässigkeit der in Abb. 5.19 dargestellten drei Funktionen RX; X = A,B,C mit der Zuverlässigkeit der Komponenten K7 und K8 und ist wegen RX < 1 in jedem Fall geringer als die jeweilige Zuverlässigkeit der Funktionen RX. Bei der Berechnung der Systemzuverlässigkeit müssen die Regeln für das Rechnen mit mehrfach auftretenden Elementen in Zuverlässigkeitsblockdiagrammen beachtet werden [57].

Dagegen ist für die Sicherheit lediglich das zuverlässige Erkennen eines Ausfalls und der zuverlässige Übergang in den sicheren Zustand notwendig. Die Zuverlässigkeit RS Sicherheit dieser Sicherheitsreaktion wird durch die Zuverlässigkeit der Überwachungsfunktionen fÜn oder der Funktionen zur Überwachung der Mikrocontroller vorgegeben und ist deshalb höher als die Zuverlässigkeit der Funktionen RX. Zudem geht die Zuverlässigkeit der Komponenten K7 und K8 in die Berechnung von RS Sicherheit nicht ein.

Wie dieses Beispiel zeigt, können Maßnahmen zur Erhöhung der Sicherheit die Zuverlässigkeit des Systems verringern. Außerdem ist ersichtlich, dass Maßnahmen zur Erhöhung der Zuverlässigkeit zu einer Reduzierung der Sicherheit eines Systems führen können.

Obwohl nur Hardware-Komponenten betrachtet werden, haben die Zuverlässigkeits- und Sicherheitsanalysen großen Einfluss auf die Software-Entwicklung. Sie beeinflussen etwa die Zuordnung der Software-Funktionen zu den Mikrocontrollern in einem verteilten und vernetzten System oder die notwendigen Qualitätssicherungsmaßnahmen in der Software-Entwicklung. Für eine ausführliche Darstellung wird auf die Literatur, wie [53, 54, 80, 81], verwiesen.

5.3 Spezifikation von Software-Funktionen und deren Validierung

Nach der Festlegung der Schnittstellen und Abtastraten der Software-Funktionen und ihrer Zuordnung zu einem Mikrocontroller stellt sich die Frage, wie die Daten und das Verhalten der Software-Funktionen, wie die Verknüpfung der Eingangssignale in Algorithmen zur Berechnung der Ausgangssignale spezifiziert werden kann. Diese Themen stehen in den folgenden Abschnitten im Mittelpunkt.

Für die Spezifikation von Software-Funktionen können verschiedene Methoden eingesetzt werden. Eine Klassifizierung ist in Abb. 5.20 dargestellt. Zunächst kann zwischen formalen und informalen Spezifikationsmethoden unterschieden werden. Unter formalen Methoden werden mathematisch strenge Methoden zur Formulierung von Algorithmen verstanden, also Methoden, die die eindeutige Spezifikation von Algorithmen ohne Interpretationsspielraum erlauben. An informale Methoden werden Anforderungen dieser Art nicht gestellt. So ist beispielsweise die umgangssprachliche Formulierung von Algorithmen eine informale Methode; die Formulierung mit Programmiersprachen dagegen eine formale Methode.
Abb. 5.20

Einteilung der Spezifikationsmethoden für Software-Funktionen

Wie in Abschn.  4.6.2 bereits angesprochen, kann schon an einfachsten Beispielen erkannt werden, dass die informale Beschreibung von Algorithmen wegen des vorhandenen Interpretationsspielraums zu unterschiedlichen Implementierungen führen kann, die dann bei gleichen Eingangssignalen unterschiedliche Ergebnisse oder Ausgangssignale liefern. Aus diesem Grund werden im Folgenden nur formale Methoden näher betrachtet. Dabei kann zwischen programmiersprachlichen und modellbasierten Spezifikationsmethoden unterschieden werden. Beispiele für modellbasierte Spezifikationsmethoden, die häufig zur Beschreibung von Software-Funktionen in der Fahrzeugentwicklung eingesetzt werden, sind Blockdiagramme, Entscheidungstabellen oder Zustandsautomaten.

Ein drittes Unterscheidungskriterium ist die Abstraktionsebene der Spezifikation. Da Fahrzeugfunktionen in den meisten Fällen durch ein technisches System realisiert werden, das aus technisch völlig verschieden realisierten Komponenten aufgebaut ist, ist für die Spezifikation eine einheitliche Abstraktionsebene notwendig. Wie bei den steuerungs- und regelungstechnischen Modellbildungs- und Entwurfsmethoden ist deshalb im ersten Schritt auch die Spezifikation von Software-Funktionen auf der physikalischen Ebene sinnvoll. Verschiedene Methoden für die modellbasierte Spezifikation von Software-Funktionen werden in den folgenden Abschnitten ausführlich dargestellt. Dabei werden zunächst viele Details der Implementierung vernachlässigt, die erst in einem folgenden Design- und Implementierungsschritt festgelegt werden, auf den in Abschn. 5.4 näher eingegangen wird.

Um die Durchgängigkeit in die Design- und Implementierungsphase zu gewährleisten, müssen allerdings bereits bei der Spezifikation von Software-Funktionen einige software-spezifische Anforderungen und Randbedingungen berücksichtigt werden. In den folgenden Abschnitten wird beispielsweise bereits die Software-Architektur, die Festlegung des Echtzeitverhaltens oder die konsequente Unterscheidung zwischen Daten- und Kontrollfluss berücksichtigt.

Die formale Spezifikation von Software-Funktionen bietet weitere Vorteile in der Entwicklung. So kann etwa die Spezifikation in einer Simulationsumgebung bereits frühzeitig ausgeführt werden und ist mit Rapid-Prototyping-Systemen im Fahrzeug erlebbar. Dies ermöglicht die frühzeitige Validierung der Spezifikation. Dabei ist ein grafisches Modell einfacher verständlich als eine programmiersprachliche Beschreibung. Es kann als gemeinsame Verständigungsgrundlage für die verschiedenen Fachdisziplinen, die an der Entwicklung von Software-Funktionen beteiligt sind, dienen.

Ziel der Trennung zwischen physikalischer Ebene und Implementierungsebene ist auch die Abstraktion von möglichst vielen, teilweise hardwareabhängigen Implementierungsdetails. Daraus ergibt sich die Möglichkeit, die spezifizierten Software-Funktionen in verschiedenen Fahrzeugprojekten zu verwenden, etwa durch eine Portierung von Software-Funktionen auf Mikrocontroller mit unterschiedlicher Wortlänge.

5.3.1 Spezifikation der Software-Architektur und der Software-Komponenten

Ausgehend von dem erarbeiteten logischen Modell der Software-Funktionen mit definierten Echtzeitanforderungen sowie Ein- und Ausgangssignalen muss festgelegt werden, wie die Architektur einer Software-Funktion dargestellt werden soll. Dabei wird von einer Software-Architektur für die Mikrocontroller von Steuergeräten, wie in Abb.  1.22 dargestellt, ausgegangen. Da man bei umfangreicheren Software-Funktionen nicht ohne ein geeignetes Modularisierungs- und Hierarchiekonzept auskommen wird, ist eine konsequente Anwendung der Komponenten- und Schnittstellensicht auch auf der Software-Ebene notwendig. Die Spezifikation der Schnittstellen für alle Software-Komponenten, die zur Darstellung einer Software-Funktion verwendet werden, ist auch eine zentrale Voraussetzung für die verteilte Entwicklung eines solchen Software-Systems. Diese Anforderung wird bei gleichzeitiger Gewährleistung der Wiederverwendbarkeit der spezifizierten Software-Komponenten beispielsweise durch eine objektbasierte Modellierung erfüllt.

5.3.1.1 Objektbasierte Modellierung der Software-Architektur

An dieser Stelle sollen deshalb die wichtigsten Begriffe objektbasierter Software-Modelle eingeführt werden. Ein Software-System wird dabei in überschaubare, voneinander unabhängige und abgeschlossene Software-Komponenten, so genannte Objekte (engl. Objects ), gegliedert. Die Objekte interagieren miteinander, um eine bestimmte Aufgabe zu erfüllen. Objekte umfassen sowohl die Struktur als auch das Verhalten der Software [73].

Struktur bedeutet, dass Objekte Attribute (engl. Attributes ) enthalten können, welche die Daten des Objekts speichern. Attribute sind also die internen Speicher von Objekten. Struktur bedeutet auch, dass Objekte wiederum andere Objekte enthalten können. Eine solche Enthaltensbeziehung zwischen Objekten wird Aggregation (engl. Aggregation ) genannt. Die Struktur beschreibt also die statischen Eigenschaften eines Objekts.

Demgegenüber beschreibt das Verhalten die dynamischen Eigenschaften eines Objekts. Auf Objekte kann von anderen Objekten nur über Schnittstellen zugegriffen werden. Die Schnittstellen eines Objektes werden durch seine öffentlichen Methoden (engl. Public Methods ) definiert. Methoden können Eingangsdaten von außerhalb des Objektes übernehmen. Sie können Attribute des Objekts verändern oder Ausgangsdaten des Objekts bereitstellen. Alle Attribute eines Objekts können nur durch Aufrufen einer Methode des Objekts geändert werden. Dadurch werden Modularität, Flexibilität und Wiederverwendbarkeit von Objekten gewährleistet. Objekte können deshalb in verschiedenen Umgebungen ohne Seiteneffekte eingesetzt werden.

Eine Klasse (engl. Class ) ist die Abstraktion einer Menge von gleichartigen Objekten, welche die gemeinsamen Attribute und Methoden angibt, die von jedem Objekt bereitgestellt werden. Objekte stellen Exemplare oder Instanzen (engl. Instance ) einer Klasse dar. Eine Klasse ist also die Spezifikation einer Instantiierungsvorschrift für Objekte.

Beispiel

Berechnung von Raddrehzahl und Fahrzeuggeschwindigkeit beim ABS

Zur grafischen Darstellung objektbasierter Software-Modelle sind die Notationen der Unified Modelling LanguageTM (UML) [82] weit verbreitet. In Abb. 5.21 ist die Klasse „Rad“ mit dem Attribut „Drehzahl n“ sowie mit Methoden zur Initialisierung „init_n()“, zur Berechnung „compute_n()“ und zur Ausgabe „out_n()“ der Raddrehzahl in der Notation eines UML-Klassendiagramms dargestellt. Eine Software-Komponente dieser Art könnte etwa in einem Antiblockiersystem eingesetzt werden.
Abb. 5.21

Klasse „Rad“ mit Methoden zur Berechnung der Raddrehzahl. (UML [82])

Zur Berechnung der Fahrzeuggeschwindigkeit wird eine Klasse „Fahrzeug“ definiert. In der Klasse „Fahrzeug“ müssen die vier Räder des Fahrzeugs repräsentiert werden. Es entsteht eine 1:4-Aggregation zwischen der Klasse „Fahrzeug“ und der Klasse „Rad“.

In der Klasse „Fahrzeug“ soll auch der Motor des Fahrzeugs repräsentiert werden. Dazu wird die Klasse „Motor“ spezifiziert. Für die Klasse „Motor“ werden das Attribut „Drehzahl n“ für die Motordrehzahl sowie die Methoden zur Initialisierung „init_n()“, zur Berechnung „compute_n()“ und zur Ausgabe „out_n()“ der Motordrehzahl definiert.

In Abb. 5.22 ist das Klassenmodell für die Klasse „Fahrzeug“ in UML-Notation dargestellt. Für die Klasse „Fahrzeug“ werden die Attribute „Geschwindigkeit v“ und „Gangstufe g“ definiert und Methoden „compute_v()“ und „compute_g()“ zur Berechnung der Fahrzeuggeschwindigkeit und der eingelegten Gangstufe. Für diese Berechnungen werden die Methoden der Klassen „Rad“ und „Motor“ verwendet.
Abb. 5.22

Klassendiagramm für die Klasse „Fahrzeug“. (UML [82])

Software-Modelle dieser Art werden als Basis zur Darstellung der Zusammenhänge innerhalb von Software-Funktionen verwendet. Eine Software-Funktion f1 kann auf diese Art hierarchisch aus Software-Komponenten aufgebaut werden. Dazu werden die Klassen instantiiert. Durch die Instantiierung der Klasse „Fahrzeug“ entsteht das Objekt „Fahrzeug_1“. Das Objekt „Fahrzeug_1“ enthält vier Instanzen der Klasse „Rad“ und eine Instanz der Klasse „Motor“. Es entstehen die Objekte „Rad_v_r“ für das Rad vorne rechts, „Rad_v_l“ für das Rad vorne links, „Rad_h_r“ für das Rad hinten rechts, „Rad_h_l“ für das Rad hinten links und das Objekt „Motor_1“ für den Motor.

In den folgenden Abschnitten wird die grafische Darstellung wie in Abb. 5.23 für die Darstellung der Software-Architektur mit Objekten verwendet. Der Klassenname eines Objekts wird nach dem Objektnamen angegeben und durch „:“ getrennt.
Abb. 5.23

Grafische Darstellung der Software-Architektur mit Objektdiagrammen

5.3.1.2 Spezifikation der Schnittstellen zum Echtzeitbetriebssystem mit Modulen

Für die Software-Komponenten auf der obersten Hierarchieebene einer Software-Funktion müssen Schnittstellen zum Echtzeitbetriebssystem in Form von Prozessen und zum Kommunikationssystem in Form von Messages (Abb.  2.36) festgelegt werden. Durch Zuordnung der Prozesse zu Tasks ist die Vorgabe der Echtzeitanforderungen möglich. Durch die Abbildung der Ein- und Ausgangssignale der Funktion auf Messages kann die Kommunikation über Task-Grenzen oder auch über Mikrocontroller-Grenzen hinweg unterstützt werden.

Schnittstellen dieser Art sind für die darunter liegenden Ebenen einer Software-Funktion nicht notwendig. Die Software-Komponenten auf der obersten Ebene einer Funktion werden als Module bezeichnet. Module werden im Folgenden grafisch wie in Abb. 5.23 und 5.24 dargestellt. Die Prozesse P1 … Pm werden als Dreiecke dargestellt. Die Messages M1 … Mn als Pfeile, wobei anhand der Pfeilrichtung zwischen Empfangs- und Sende-Messages unterschieden wird.
Abb. 5.24

Grafische Darstellung von Modulen in der Spezifikation

5.3.1.3 Spezifikation von wiederverwendbaren Software-Komponenten mit Klassen

Auf den darunter liegenden Ebenen werden Objekte definiert, auf die über Methoden zugegriffen werden kann. Einer Methode können Schnittstellen in Form von mehreren Argumenten und eines Rückgabewertes zugeordnet werden. Die Unterscheidung zwischen Modulen und Objekten bei Software-Komponenten ermöglicht die Wiederverwendung von Objekten in unterschiedlichem Kontext durch Instantiierung von Klassen. Klassen und Objekte werden im Folgenden grafisch wie in Abb. 5.25 dargestellt [74]. Argumente werden als Pfeile dargestellt, die auf die Klasse oder das Objekt zeigen. Rückgabewerte werden als Pfeile dargestellt, die von der Klasse oder dem Objekt wegzeigen.
Abb. 5.25

Grafische Darstellung von Klassen und Objekten in der Spezifikation

Alternativ zur Darstellung der Software-Architektur nach Abb. 5.23 wird im Folgenden auch die Darstellung als Blockdiagramm, wie in Abb. 5.26, verwendet. In dieser Form können neben den Enthaltensbeziehungen und Hierarchieebenen zusätzlich die Daten- und Kontrollflüsse – in Abb. 5.26 mit Linien dargestellt – zwischen Messages und den Argumenten bzw. Rückgabewerten von Methoden der Objekte eingezeichnet werden.
Abb. 5.26

Grafische Darstellung der Software-Architektur mit Blockdiagrammen. (ETAS GmbH [74])

Abhängig von der Art des zu beschreibenden Zusammenhangs eignen sich verschiedene Modellierungstechniken zur Spezifikation des Verhaltens von Modulen und Klassen. Zu den wichtigsten Techniken gehören Blockdiagramme, Entscheidungstabellen und Zustandsautomaten.

5.3.2 Spezifikation des Datenmodells

Auch die Spezifikation der Daten einer Software-Komponente erfolgt zunächst auf der physikalischen Ebene. In der objektbasierten Modellierung werden die Daten durch Attribute der Objekte bzw. der Module repräsentiert.

5.3.3 Spezifikation des Verhaltensmodells mit Blockdiagrammen

Steht der Datenfluss bei der Formulierung des Verhaltens einer Software-Komponente im Vordergrund, eignen sich Blockdiagramme zur grafischen Darstellung. Dies ist beispielsweise auf den abstrakten Ebenen häufig der Fall. Zahlreiche Zusammenhänge zwischen Software-Komponenten wurden deshalb schon in den bisherigen Kapiteln dieses Buches in Form von Blockdiagrammen dargestellt.

Mit Blockdiagrammen können auch komplexe Algorithmen innerhalb einer Software-Komponente übersichtlich dargestellt werden. Dabei kann zwischen arithmetischen und Booleschen Funktionen unterschieden werden.

5.3.3.1 Spezifikation arithmetischer Funktionen

Als Beispiel für die Spezifikation arithmetischer Algorithmen soll das Integrationsverfahren nach Euler (Abb.  4.36) mit Blockdiagrammen fortgesetzt werden.

Beispiel

Spezifikation der Klasse „Integrator“

Das Integrationsverfahren nach Euler wird häufig als Approximationsverfahren für die Berechnung von Integralen eingesetzt.

Die Berechnung des bestimmten Integrals der Funktion f(t)

$$F(t_{n})=\int\limits_{t_{0}}^{t_{n}}{f(t)dt}$$
(5.4)
(5.4)

wird dabei durch die Summe

$$F^{*}(t_{n})=\int\limits_{i=0}^{n-1}{(t_{i+1}-t_{i})\cdot f(t_{i})}$$
(5.5)
(5.5)

approximiert.

Der Abstand (t i +1 − t i ) wird Schrittweite dT i genannt.

F *(t i +1) kann inkrementell berechnet werden mit der Gleichung:

F *(t i +1) = F *(t i ) + dT i  · f(t i ).(5.6)

Da dieses Integrationsverfahren mehrfach und in unterschiedlichem Zusammenhang eingesetzt wird, soll es als Klasse in Form eines Blockdiagramms spezifiziert werden. Dabei werden eine Reihe zusätzlicher Anforderungen an diese Software-Komponente gestellt:

Die Integration einer Eingangsgröße in soll mit einer Konstante K gewichtet werden können und der aktuelle Integrationswert soll in der Variable memory gespeichert werden.

Der Integrationswert memory soll nach oben mit der Schranke MX, nach unten mit der Schranke MN begrenzt werden.

Der Eingangswert in, die Integrationskonstante K sowie die Schranken MN und MX werden als Argumente der Methode „compute()“ vorgegeben. Die Methode „compute()“ berechnet damit den aktuellen Integrationswert nach der Gleichung:

memory(t i +1) = memory(t i ) + K · dT · in(t i )(5.7)

und begrenzt diesen anschließend durch die Schranken MN und MX.

Die Schrittweite dT ist die Zeitspanne, die seit dem Start der letzten Ausführung der Methode „compute()“ vergangen ist und in Abb.  2.18 auch als Ausführungsrate bezeichnet wurde. dT soll vom Echtzeitbetriebssystem für jede Task berechnet und bereitgestellt werden.

Über eine zweite Methode „out()“ soll der aktuelle Integrationswert memory unabhängig von der Integrationsberechnung ausgegeben werden können.

Eine Methode „init()“ ist zur Initialisierung von memory mit dem Initialisierungswert IV, der als Argument übergeben wird, notwendig.

Die Methoden „init()“ bzw. „compute()“ sollen in Abhängigkeit eines Booleschen Ausdrucks I bzw. E, der jeweils als zusätzliches Argument diesen Methoden übergeben wird, ausgeführt werden.

Eine Darstellung dieses Integrators als Blockdiagramm in ASCET [74] zeigt Abb. 5.27. Arithmetische Datenflüsse sind mit durchgezogenen Pfeilen dargestellt; Boolesche Datenflüsse mit gestrichelten Pfeilen; Kontrollflüsse mit strichpunktierten Pfeilen.
Abb. 5.27

Spezifikation der Klasse „Integrator“ als Blockdiagramm in ASCET. (ETAS GmbH [74])

Die Außenansicht dieser Software-Komponente zeigt Abb. 5.28. Die Zuordnung der Argumente zu den Methoden init(), compute() und out() ist aus Abb. 5.27 ersichtlich.
Abb. 5.28

Außenansicht der Klasse „Integrator“ in ASCET. (ETAS GmbH [74])

Zu beachten ist, dass die arithmetischen Algorithmen auf der physikalischen Ebene definiert wurden. So wurden in obigem Beispiel keinerlei Festlegungen über die spätere Implementierung, etwa eine Definition der Wortlänge oder eine Entscheidung bezüglich Festpunkt- oder Gleitpunktarithmetik getroffen. Eine so spezifizierte Software-Komponente kann deshalb auf unterschiedlichste Mikrocontroller portiert werden. Auch die Begrenzung des Integrationswertes erfolgt auf physikalischer Ebene. Sie wird auch bei einer Realisierung in Gleitpunktarithmetik durchgeführt und darf nicht mit eventuellen Begrenzungen im Zusammenhang mit der Realisierung von Über- oder Unterlaufbehandlungen in Integerarithmetik verwechselt werden. Die sequentielle Reihenfolge der einzelnen Rechenoperationen, der Kontrollfluss, wurde bereits vollständig festgelegt.

5.3.3.2 Spezifikation Boolescher Funktionen

Neben der Spezifikation von arithmetischen Operationen können Blockdiagramme auch zur Festlegung logischer, so genannter Boolescher Verknüpfungen verwendet werden. In vielen Fällen ist eine Kombination aus arithmetischen und Booleschen Verknüpfungen zur Beschreibung einer Funktion notwendig, etwa wenn Aktionen von Booleschen Ausdrücken abhängen in der Form von „Wenn-Dann-Beziehungen“.

Eine Boolesche Größe kann nur die Werte der zwei Elemente der Menge B = {TRUE, FALSE} einnehmen. Boolesche Größen können mit Booleschen Operatoren zu Booleschen Ausdrücken verknüpft werden. Für die Booleschen Operatoren Konjunktion – die logische UND-Verknüpfung –, Disjunktion – die logische ODER-Verknüpfung – und Negation – die logische NICHT-Verknüpfung – werden in den folgenden Abschnitten die in Abb. 5.29 dargestellten grafischen Symbole, die auch Schaltfunktionen genannt werden, verwendet.
Abb. 5.29

Grafische Symbole für Schaltfunktionen in ASCET. (ETAS GmbH [74])

Beispiel

Spezifikation Boolescher Ausdrücke mit Blockdiagrammen

Die Spezifikation Boolescher Ausdrücke unter Verwendung von Symbolen für Schaltfunktionen wird auch Schaltnetz genannt. Abb. 5.30 zeigt ein Schaltnetz zur Darstellung von zwei Booleschen Ausdrücken als Blockdiagramm im Werkzeug ASCET [74].
Abb. 5.30

Spezifikation Boolescher Ausdrücke als Blockdiagramm in ASCET. (ETAS GmbH [74])

5.3.4 Spezifikation des Verhaltensmodells mit Entscheidungstabellen

Alternativ können Aktionen, deren Ausführung von der Erfüllung oder Nichterfüllung mehrerer Bedingungen abhängt, übersichtlich und kompakt in Form von so genannten Entscheidungstabellen [73, 74] 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 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. In Abb. 5.31 sind die Booleschen Ausdrücke aus Abb. 5.30 in Form einer Entscheidungstabelle dargestellt. Die Spezifikationen in den Abb. 5.30 und 5.31 sind also äquivalent.
Abb. 5.31

Spezifikation Boolescher Ausdrücke als Entscheidungstabelle

Wie Boolesche Ausdrücke, können auch Entscheidungstabellen optimiert werden. So sind in Abb. 5.31 nur die letzten drei Regeln R6 bis R8 relevant, da nur in Abhängigkeit dieser Regeln eine der Aktionen Y1 oder Y2 ausgeführt werden soll (Abb. 5.32).
Abb. 5.32

Optimierung der Entscheidungstabelle

Tritt eine Aktion mehrfach bei verschiedenen Regeln auf, so kann die Entscheidungstabelle weiter optimiert werden, indem die Regeln dieser Aktion zunächst paarweise betrachtet werden. Beide Regeln können in einer ODER-Verknüpfung zusammengefasst werden. Deshalb können sie, wenn sich die beiden Regeln in nur einer Bedingung unterscheiden, vereinfacht werden, da dann die sich unterscheidende Bedingung irrelevant ist. In Abb. 5.32 treten die Aktion Y1 und die Aktion Y2 je zweimal auf. Bei der Aktion Y2 unterscheiden sich die beiden Regeln nur in Bedingung X3, die deshalb irrelevant ist. Hier kann deshalb weiter vereinfacht werden, indem die Regeln R7 und R8 zusammengefasst werden. Irrelevante Bedingungen werden mit * in der Entscheidungstabelle gekennzeichnet (Abb. 5.33). Bei Aktion Y1 kann dagegen nicht mehr weiter optimiert werden.
Abb. 5.33

Optimierung der Entscheidungstabelle für Aktion Y2

Verschiedene Entscheidungstabellen können auch sequentiell miteinander verknüpft werden, wie beispielsweise in Abb. 5.34 dargestellt.
Abb. 5.34

Sequentielle Verknüpfung von Entscheidungstabellen

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 beispielsweise in Überwachungsfunktionen häufig vor. Für eine ausführliche Darstellung zu Entscheidungstabellen wird auf die Literatur, wie [73, 74], verwiesen.

5.3.5 Spezifikation des Verhaltensmodells mit Zustandsautomaten

Bei vielen Software-Funktionen hängt das Ergebnis nicht nur von den Eingängen, sondern auch von einem Ereignis und der Historie, die bis dahin durchlaufen wurde, ab. Zum Beschreiben derartiger Zusammenhänge eignen sich Zustandsautomaten. Die hier behandelten Zustandsautomaten orientieren sich an den Zustandsautomaten nach Moore, Mealy und Harel [73, 74, 83].

Zustandsautomaten können als Zustandsdiagramme gezeichnet werden. Die Zustände (engl. States ) werden dabei durch beschriftete Rechtecke mit abgerundeten Ecken dargestellt. Die möglichen Übergänge (engl. Transitions ) werden durch beschriftete Pfeile dargestellt. Ein Übergang wird in Abhängigkeit einer Bedingung (engl. Condition ) durchgeführt, die dem Übergang zugeordnet ist.

5.3.5.1 Spezifikation flacher Zustandsautomaten

Beispiel

Spezifikation der Ansteuerung der Tankreservelampe mit Zustandsautomaten

Die Ansteuerung der Tankreservelampe (Abb.  2.9) soll als Beispiel für die Spezifikation von Software-Funktionen mit Zustandsautomaten fortgesetzt werden. Für die Ansteuerung der Tankreservelampe interessieren nur die Bedingungen „Signalwert > 8,5 V“ bzw. „Signalwert < 8,0 V“ und der bisherige Zustand „Lampe Aus“ bzw. „Lampe Ein“ (Abb. 5.35).
Abb. 5.35

Spezifikation von Zuständen, Übergängen und Bedingungen

Bisher wurde noch nicht festgelegt, wann die so genannten Aktionen (engl. Actions ) „Lampe einschalten“ bzw. „Lampe ausschalten“ ausgeführt werden sollen. Diese Aktionen können wie die Bedingungen den Übergängen zugeordnet werden. In diesem Fall spricht man von Übergangsaktionen (engl. Transition Actions ). Solche Zustandsautomaten werden als Mealy-Automaten bezeichnet. Alternativ können die Aktionen auch den Zuständen zugeordnet werden. Man spricht von Zustandsaktionen (engl. State Actions ). Solche Zustandsautomaten werden als Moore-Automaten bezeichnet. Moore- und Mealy-Automaten können auch kombiniert werden, d. h. Aktionen können Zuständen und Übergängen zugeordnet werden. Die Aktionen „Lampe einschalten“ und „Lampe ausschalten“ in diesem Beispiel sollen den Übergängen zugeordnet werden.

Es muss auch festgelegt werden, in welchem Zustand sich der Zustandsautomat beim Start befindet. Dieser Zustand wird Startzustand genannt. Im Fall der Tankreservelampe wird man als Überwachungsmöglichkeit für die Funktionsfähigkeit der Lampe festlegen, dass die Lampe bei jedem Start des Fahrzeugmotors für eine gewisse Zeitspanne eingeschaltet wird. Unabhängig vom Tankfüllstand kann so bei jedem Start des Fahrzeugs erkannt werden, ob die Lampe noch funktionsfähig ist. Der erste mögliche Zustandsübergang soll erst nach einer Verzögerung von zwei Sekunden erfolgen, d. h. die Lampe soll nach dem Start mindestens zwei Sekunden eingeschaltet bleiben. Deshalb wird ein neuer Zustand „Funktionskontrolle“ mit einem Übergang nach „Lampe Ein“ als Startzustand eingeführt. Der Startzustand in einem Zustandsautomaten wird mit (S) gekennzeichnet. Im Zustand „Funktionskontrolle“ wird die Aktion „Lampe einschalten“ durchgeführt.

Der so erweiterte Zustandsautomat ist in Abb. 5.36 dargestellt.
Abb. 5.36

Zuordnung der Aktionen und Definition des Startzustands

Bei der Zuordnung von Aktionen zu Zuständen kann unterschieden werden zwischen:

Aktionen, die nur beim Eintritt in den Zustand ausgeführt werden (Entry-Aktionen ),

Aktionen, die beim Verlassen des Zustands ausgeführt werden (Exit-Aktionen ),

Aktionen, die beim Verweilen im Zustand ausgeführt werden (Static-Aktionen ).

Wie in Abb. 5.37 dargestellt, ist eine Entry-Aktion eines Zustands äquivalent zu einer Übergangsaktion, die allen zu einem Zustand führenden Übergängen zugeordnet wird. Genauso ist eine Exit-Aktion eines Zustands äquivalent zu einer Übergangsaktion, die allen von einem Zustand wegführenden Übergängen zugeordnet wird.
Abb. 5.37

Äquivalente Aktionen in Zustandsautomaten

Zustandsautomaten verhalten sich deterministisch, wenn es von jedem Zustand aus zu jeder Eingabe von Eingangsgrößen nur höchstens einen Zustandsübergang gibt.

Nichtdeterministische Situationen könnten z. B. entstehen, falls mehrere Bedingungen verschiedener Übergänge, die von einem Zustand wegführen, gleichzeitig wahr sind. Situationen dieser Art können durch die Vergabe von Prioritäten ausgeschlossen werden, indem jedem von einem Zustand wegführenden Übergang eine unterschiedliche Priorität zugeordnet wird. Die Prioritäten werden in der Regel in Form von Zahlen spezifiziert. Im Folgenden definiert eine größere Zahl eine höhere Priorität.

In Abb. 5.38 führen drei Übergänge vom Zustand X weg. Im Falle, dass die Bedingung C2 wahr ist, wäre das Verhalten des im Bild links dargestellten Zustandsautomaten nicht deterministisch, da zwei Übergänge möglich wären. Durch die Einführung einer Priorität, wie auf der rechten Seite im Bild dargestellt, wird festgelegt, dass in diesem Fall der Übergang mit Priorität (3) und die Aktion A2 ausgeführt werden.
Abb. 5.38

Deterministische Zustandsautomaten durch Vergabe von Prioritäten

Für einen Zustandsautomaten muss außerdem das Ereignis festgelegt werden, bei dem die Bedingungen der vom aktuellen Zustand wegführenden Übergänge geprüft, und ggfs. die entsprechenden Aktionen und Übergänge ausgeführt werden. Dieses Ereignis zur Berechnung des Zustandsautomaten wird beispielsweise in Abb. 5.39 durch die Methode „trigger()“ vorgegeben, die jedem Übergang zugeordnet wird.
Abb. 5.39

Methode „trigger()“ zur Berechnung des Zustandsautomaten

Bei jedem Aufruf der Methode „trigger()“ werden die folgenden Berechnungen ausgeführt:

Prüfung der Bedingungen für die vom aktuellen Zustand wegführenden Übergänge nach absteigender Priorität

Falls eine Bedingung wahr ist:
  • Durchführung der Exit-Aktion des aktuellen Zustand,

  • Durchführung der Übergangsaktion des Übergangs,

  • Durchführung der Entry-Aktion des neuen Zustands,

  • Übergang in den neuen Zustand.

Falls keine Bedingung wahr ist:
  • Durchführung der Static-Aktion des aktuellen Zustands.

Es wird also bei jedem Aufruf der Methode „trigger()“ maximal ein Zustandsübergang durchgeführt.

5.3.5.2 Spezifikation von Übergängen mit Verzweigungen

Treten Bedingungen etwa der Form C1 & C2 bzw. C1 & C3 an Übergängen auf, die vom selben Zustand wegführen, kann dies übersichtlicher mit verzweigten Übergängen dargestellt werden. Die beiden Darstellungen in Abb. 5.40 sind äquivalent.
Abb. 5.40

Äquivalente Modellierung von Zustandsübergängen

Die Bedingungen und Aktionen in Zustandsautomaten können auf verschiedene Art und Weise spezifiziert werden, z. B. als Blockdiagramm, Entscheidungstabelle oder auch als unterlagerter Zustandsautomat. Alternativ ist auch die Spezifikation in einer Programmiersprache möglich.

5.3.5.3 Spezifikation hierarchischer Zustandsautomaten

Mit zunehmender Anzahl von Zuständen und Übergängen werden Zustandsdiagramme schnell unübersichtlich. Durch hierarchisch geschachtelte Zustände kann die Übersichtlichkeit erhalten werden. Es entstehen hierarchische Zustandsdiagramme mit Basiszuständen und Hierarchiezuständen .

Für jeden Hierarchiezustand wird ein Basiszustand als Startzustand festgelegt. Übergänge, die zu einem Hierarchiezustand führen, bewirken einen Übergang in diesen Startzustand.

Alternativ kann ein Hierarchiezustand mit Gedächtnis definiert werden. Bei jedem Übergang, der zu einem Hierarchiezustand führt, welcher mit einem „H“ für History gekennzeichnet ist, wird der zuletzt eingenommene Basiszustand in diesem Hierarchiezustand wieder eingenommen. Der Startzustand definiert dann den Basiszustand für den ersten Eintritt in den Hierarchiezustand.

Übergänge können auch über Hierarchiegrenzen hinweg festgelegt werden. Daher muss die Priorität von Übergängen, die von einem Basiszustand wegführen, gegenüber Übergängen, die von einem Hierarchiezustand wegführen, eindeutig geregelt werden. Entsprechendes gilt für die Reihenfolge der Durchführung der Aktionen, die für den Hierarchiezustand und den Basiszustand festgelegt sind.

Ein Beispiel für einen hierarchischen Zustandsautomaten ist in Abb. 5.41 dargestellt. Auf der obersten Hierarchieebene sind die Zustände X, Y und Z definiert. Der Startzustand ist der Zustand X. Die Zustände V und W sind Basiszustände des Hierarchiezustands Z. Der Basiszustand V ist der Startzustand des Hierarchiezustands Z. Der Übergang vom Zustand Y zum Hierarchiezustand Z führt also zu einem Übergang in diesen Startzustand V, genauso wie der direkte Übergang von Zustand X über die Hierarchiegrenze des Zustands Z zum Zustand V.
Abb. 5.41

Hierarchischer Zustandsautomat

Für eine ausführliche Darstellung wird auf die Literatur, z. B [74]., verwiesen.

5.3.6 Spezifikation des Verhaltensmodells mit Programmiersprachen

Die Festlegung des Verhaltens einer Software-Komponente in einer Programmiersprache wird häufig bevorzugt, wenn ein Verhalten zu formulieren ist, das nur umständlich oder unverständlich datenflussorientiert oder zustandsbasiert beschrieben werden kann. Ein Beispiel dafür sind Such- oder Sortieralgorithmen mit zahlreichen Schleifen und Verzweigungen.

Beispiel

Spezifikation der Software-Komponente „Integrator“ in der Programmiersprache C

Abb. 5.42 zeigt die Methoden der Software-Komponente „Integrator“ aus Abb. 5.27 in der Sprache C [84].
Abb. 5.42

Spezifikation der Methoden der Klasse „Integrator“ in der Sprache C. (Kernighan und Ritchie [84])

5.3.7 Spezifikation des Echtzeitmodells

Neben der Spezifikation des Daten- und Verhaltensmodells einer Software-Komponente muss das Echtzeitmodell festgelegt werden (Abb.  4.31 und  4.32). Wird ein Echtzeitbetriebssystem eingesetzt, so muss die Konfiguration des Echtzeitbetriebssystems definiert werden. Neben den verschiedenen Betriebszuständen, den Übergängen und Übergangsbedingungen muss die Zuteilungsstrategie sowie die Task-Prozess-Liste für jeden Betriebszustand spezifiziert werden.

Durch die Prozess- und Message-Schnittstellen der Module und die Berechnung von dT durch das Betriebssystem kann die Spezifikation der Echtzeitanforderungen von der Verhaltensspezifikation der Module und Klassen getrennt werden.

Für die verschiedenen Betriebszustände müssen die Initialisierungs- und die wiederkehrenden Prozesse festgelegt werden.

5.3.8 Validierung der Spezifikation durch Simulation und Rapid-Prototyping

Die Analyse der Software-Anforderungen und ihre formale Spezifikation, beispielsweise durch Software-Modelle, reichen oft nicht aus, um eine ausreichend klare Vorstellung von dem zu entwickelnden Software-System zu erhalten oder den Entwicklungsaufwand vorab abzuschätzen. Es werden deshalb häufig Anstrengungen unternommen, Methoden und Werkzeuge einzusetzen, die es erlauben, die formal spezifizierten Software-Funktionen zu animieren, zu simulieren oder auch im Fahrzeug erlebbar zu machen und so eine Software-Funktion frühzeitig zu validieren.

Die Nachbildung und Ausführung einer Software-Funktion auf einem Rechner wird als Simulation bezeichnet. Die Ausführung einer Software-Funktion auf einem Rechner mit Schnittstellen zum Fahrzeug, einem so genannten Experimentiersystem , wird Rapid-Prototyping genannt.

Soll das Modell der Software als Basis für Simulations- und Rapid-Prototyping-Verfahren verwendet werden, dann werden Modell-Compiler benötigt, die es ermöglichen, das Spezifikationsmodell direkt oder indirekt in Maschinencode zu übersetzen, der auf einem Simulations- oder Experimentiersystem ausgeführt werden kann. Die für den Modell-Compiler erforderlichen Designentscheidungen werden dabei entweder implizit im Modell festgelegt oder vom Modell-Compiler zunächst so getroffen, dass das spezifizierte Modell möglichst genau nachgebildet wird.

In Abb. 5.43 ist der Aufbau eines Rapid-Prototyping-Werkzeugs [74] dargestellt. Das mit einem Modellierwerkzeug spezifizierte Modell einer Software-Funktion wird von einem Modell-Compiler zunächst in Quellcode übersetzt. Im zweiten Schritt wird dieser Quellcode mit einem Compiler-Tool-Set in einen Programm- und Datenstand für das Experimentiersystem übersetzt. Mit einem Download- oder Flash-Programmierwerkzeug wird der Programm- und Datenstand auf das Experimentiersystem geladen und kann dann ausgeführt werden. Die Ausführung kann mit einem so genannten Experimentierwerkzeug gesteuert, parametriert, animiert und beobachtet werden.
Abb. 5.43

Aufbau von Rapid-Prototyping-Werkzeugen. (ETAS GmbH [74])

Neben der Basis für das spätere Design und die Implementierung stellen die Software-Modelle in diesem Fall auch die Grundlage für Simulations- und Rapid-Prototyping-Methoden dar. Bei Verwendung eines Experimentiersystems kann so die Validierung der Software-Funktionen frühzeitig und unabhängig vom Steuergerät erfolgen. Darüber hinaus kann das Experimentiersystem später als Referenz für die Steuergeräte-Verifikation verwendet werden.

5.3.8.1 Simulation

In vielen Fällen sollen in der Simulation nicht nur die Software-Funktion an sich nachgebildet werden, sondern es interessiert auch das Zusammenspiel der Software-Funktionen mit der Hardware, mit den Sollwertgebern, Sensoren und Aktuatoren sowie mit der Strecke.

Dann muss auch für diese aus Sicht der Software-Entwicklung so genannten Umgebungskomponenten eine Modellbildung durchgeführt werden. Es entsteht ein virtuelles Fahrer-, Fahrzeug- und Umweltmodell, das mit dem virtuellen Steuergeräte- und Software-Modell verbunden wird. Dieses Modell kann dann auf einem Simulationssystem, beispielsweise einem PC, ausgeführt werden (Abb. 5.44). Diese Vorgehensweise wird auch als Model-in-the-Loop-Simulation, kurz MiL-Simulation, bezeichnet und ist auch zur Entwicklung von Fahrzeugfunktionen geeignet, die nicht durch Software realisiert werden.
Abb. 5.44

Modellbildung und Simulation für Software-Funktionen und Umgebungskomponenten

Auf die Modellbildung und Simulation für Umgebungskomponenten wird nicht näher eingegangen. Für eine ausführliche Darstellung wird auf die Literatur, z. B. [35], verwiesen.

5.3.8.2 Rapid-Prototyping

Da der Begriff Prototyp in der Automobilindustrie in verschiedenen Zusammenhängen benutzt wird, ist eine genauere Definition und Abgrenzung des Begriffs bei Verwendung in Zusammenhang mit der Software-Entwicklung notwendig.

Im allgemeinen wird im Fahrzeugbau unter einem Prototyp ein erstes Muster einer großen Serie von Produkten, eines Massenprodukts, verstanden. Ein Software-Prototyp unterscheidet sich davon, denn die Vervielfältigung eines Software-Produktes stellt kein technisches Problem dar.

Im allgemeinen ist ein Prototyp ein technisches Modell eines neuen Produkts. Dabei kann zwischen nicht funktionsfähigen Prototypen, wie beispielsweise Windkanalmodellen, funktionsfähigen Prototypen, wie Prototypfahrzeugen, oder seriennahen Prototypen, wie Vorserienfahrzeugen, unterschieden werden.

Unter einem Software-Prototyp wird in diesem Buch immer ein funktionsfähiger Prototyp verstanden, der Software-Funktionen – durchaus mit unterschiedlichen Zielrichtungen und in unterschiedlicher Konkretisierung – im praktischen Einsatz zeigt. Unter Rapid-Prototyping werden in diesem Zusammenhang Methoden zur Spezifikation und Ausführung von Software-Funktionen im realen Fahrzeug zusammengefasst, wie in Abb. 5.45 in einer Übersicht dargestellt. Verschiedene Methoden unter Verwendung von Entwicklungssteuergeräten und Experimentiersystemen werden in den folgenden Abschnitten behandelt. Entwicklungssteuergeräte werden dabei grau dargestellt.
Abb. 5.45

Rapid-Prototyping für Software-Funktionen im realen Fahrzeug

Wegen der Schnittstellen zum realen Fahrzeug muss die Ausführung der Software-Funktionen auf dem Experimentiersystem unter Echtzeitanforderungen erfolgen. Als Experimentiersysteme kommen meist Echtzeitrechensysteme mit deutlich höherer Rechenleistung als Steuergeräte zum Einsatz. Damit sind Software-Optimierungen z. B. wegen begrenzter Hardware-Ressourcen zunächst nicht notwendig, so dass der Modell-Compiler das Modell unter der Annahme einheitlicher Design- und Implementierungsentscheidungen so übersetzen kann, dass das spezifizierte Verhalten möglichst genau nachgebildet wird.

Modular aufgebaute Experimentiersysteme können anwendungsspezifisch konfiguriert werden, beispielsweise bezüglich der benötigten Schnittstellen für Eingangs- und Ausgangssignale. Das ganze System ist für den Einsatz im Fahrzeug ausgelegt und wird z. B. über einen PC bedient. Damit können die Spezifikationen von Software-Funktionen direkt im Fahrzeug validiert und ggfs. geändert werden, wobei Änderungen am Programm- und Datenstand möglich sind.

5.3.8.3 Horizontale und vertikale Prototypen

Bei der Prototypenentwicklung können zwei verschiedene Zielrichtungen unterschieden werden:

Horizontale Prototypen zielen auf die Darstellung eines breiten Bereichs eines Software-Systems, stellen aber eine abstrakte Sicht dar und vernachlässigen Details.

Vertikale Prototypen stellen dagegen einen eingeschränkten Bereich eines Software-Systems recht detailliert dar.

Abb. 5.46 zeigt die Zielrichtungen horizontaler und vertikaler Prototypen anhand eines Ausschnitts aus dem Software-System.
Abb. 5.46

Horizontale und vertikale Prototypen eines Software-Systems

Beispiel

Entwicklung eines horizontalen Prototyps mit „Bypass

Eine neue Software-Funktion soll frühzeitig im Fahrzeug erprobt und validiert werden. Detailfragen der späteren Implementierung im Software-System des Seriensteuergeräts, wie die Software-Architektur des Seriensteuergeräts, interessieren deshalb zunächst nicht.

Diese Aufgabe kann durch die Entwicklung eines horizontalen Prototyps gelöst werden. Die Software-Funktion wird durch ein physikalisches Modell spezifiziert. Viele Aspekte der Prototypimplementierung werden entweder durch das Modell oder durch den Modellcompiler implizit vorgegeben.

Eine solche Vorgehensweise kann durch die so genannte Funktionsentwicklung „im Bypass“ unterstützt werden. Vorausgesetzt wird, dass ein Steuergerät eine bereits validierte Basisfunktionalität des Software-Systems zur Verfügung stellt, alle Sensoren und Aktuatoren bedient und eine so genannte Bypass-Schnittstelle zu einem Experimentiersystem unterstützt. Die Funktionsidee wird mit einem Rapid-Prototyping-Werkzeug entwickelt und auf dem Experimentiersystem „im Bypass“ ausgeführt (Abb. 5.47).
Abb. 5.47

Prototypentwicklung mit Bypass-System

Dieser Ansatz eignet sich auch zur Weiterentwicklung von bereits bestehenden Steuergerätefunktionen. In diesem Fall werden die bestehenden Funktionen im Steuergerät häufig noch berechnet, aber so modifiziert, dass die Eingangswerte über die Bypass-Schnittstelle gesendet und die Ausgangswerte der neu entwickelten Bypass-Funktion verwendet werden.

Die notwendigen Software-Modifikationen auf der Steuergeräteseite – mit modernen Werkzeugen automatisiert durchgeführt [100] – werden Bypass-Freischnitt genannt.

Die Berechnung der Bypass-Funktion wird in vielen Fällen vom Steuergerät über eine Kontrollflussschnittstelle, in Abb. 5.47 mit Trigger bezeichnet, angestoßen und die Ausgangswerte der Bypass-Funktion werden im Steuergerät auf Plausibilität überwacht. Steuergerät und Experimentiersystem arbeiten in diesem Fall synchronisiert. Alternativ kann auch eine unsynchronisierte Kommunikation ohne Trigger realisiert werden.

Bei sicherheitsrelevanten Funktionen kann das Steuergerät beim Empfang von unplausiblen Ausgangswerten des Experimentiersystems automatisch auf die bestehende interne Funktion oder auf Ersatzwerte als Rückfallebene umschalten. Dies ist beispielsweise der Fall, falls die Bypass-Funktion unzulässige Ausgangswerte liefert, aber auch falls die Kommunikation zwischen Experimentiersystem und Steuergerät ausfällt oder die Berechnung der Bypass-Funktion unzulässig lange dauert.

Durch ein derartiges Überwachungskonzept kann abgesichert werden, dass selbst bei Ausfall des Experimentiersystems nur eine begrenzte Gefahr für die Verletzung von Personen oder die Beschädigung von Fahrzeugkomponenten bei Versuchsfahrten besteht. Die Funktionsentwicklung im Bypass ist so auch für die Validierung von sicherheitsrelevanten Funktionen einsetzbar.

Bei der Bypass-Kommunikation muss berücksichtigt werden, dass eine Software-Funktion im Steuergerät häufig auf mehrere Prozesse, die in unterschiedlichen Tasks gerechnet werden, aufgeteilt wird. In solchen Fällen muss die Bypass-Kommunikation die verschiedenen Zeitraten der Tasks unterstützen. Der typische Ablauf der Bypass-Kommunikation zwischen Entwicklungssteuergerät und Experimentiersystem für eine Zeitrate ist in Abb. 5.48 dargestellt.
Abb. 5.48

Kommunikation zwischen Steuergerät und Experimentiersystem

Beispiel

Entwicklung eines vertikalen Prototyps mit „Fullpass

Soll eine völlig neue Funktion entwickelt werden oder steht ein Steuergerät mit Bypass-Schnittstelle nicht zur Verfügung, so kann ein vertikaler Prototyp mit dem Experimentiersystem entwickelt werden. In diesem Fall muss das Experimentiersystem alle von der Funktion benötigten Sensor- und Aktuatorschnittstellen unterstützen. Auch das Echtzeitverhalten muss festgelegt und vom Experimentiersystem gewährleistet werden (Abb. 5.49).
Abb. 5.49

Prototypentwicklung mit Fullpass-System

Bypass-Anwendungen werden vorzugsweise dann eingesetzt, wenn nur wenige Software-Funktionen entwickelt werden sollen und bereits ein Steuergerät mit validierten Software-Funktionen – eventuell aus einem Vorgängerprojekt – verfügbar ist. Dieses Steuergerät muss dann soweit modifiziert werden, dass es eine Bypass-Schnittstelle unterstützt. Auch dann, wenn die Sensorik und Aktuatorik eines Steuergeräts sehr umfangreich ist und nur mit hohem Aufwand durch ein Experimentiersystem zur Verfügung gestellt werden kann, wie etwa bei Motorsteuergeräten, eignen sich Bypass-Anwendungen.

Steht ein solches Steuergerät nicht zur Verfügung, sollen zusätzliche Sensoren und Aktuatoren validiert werden und hält sich der Umfang der Sensorik und Aktuatorik in Grenzen, so werden oft Fullpass-Anwendungen bevorzugt. In diesem Fall muss das Echtzeitverhalten vom Fullpass-Rechner des Experimentiersystems gewährleistet und eventuell überwacht werden. In der Regel wird daher ein Echtzeitbetriebssystem auf dem Fullpass-Rechner eingesetzt.

Wegen der erreichbaren höheren Flexibilität werden häufig Mischformen zwischen Bypass und Fullpass eingesetzt (Abb. 5.50). Damit können neue oder zusätzliche Sensoren und Aktuatoren eingebunden werden. Neue Software-Funktionen können auf dem Experimentiersystem erprobt und zusammen mit vorhandenen Software-Funktionen des Steuergeräts ausgeführt werden.
Abb. 5.50

Prototypentwicklung mit Experimentiersystem

Gegenüber einem Entwicklungssteuergerät steht bei einem Experimentiersystem meist eine wesentlich höhere Rechenleistung zur Verfügung. Viele Anforderungen, die bei der Implementierung einer Software-Funktion auf dem Steuergerät berücksichtigt werden müssen, wie Festpunktarithmetik oder die begrenzten Hardware-Ressourcen, können deshalb vernachlässigt werden. Änderungen an den Software-Funktionen sind so einfacher und schneller möglich. Die Einbindung zusätzlicher I/O-Schnittstellen bei Experimentiersystemen ermöglicht die frühzeitige Bewertung verschiedener Realisierungsalternativen etwa bei Sensoren und Aktuatoren.

5.3.8.4 Zielsystemidentische Prototypen

Bei Serienentwicklungen wird in vielen Fällen eine möglichst hohe Übereinstimmung des Verhaltens zwischen Experimentiersystem und Steuergerät angestrebt, da nur dann die Erfahrungen mit dem Prototypen gut mit dem zu erwartenden Verhalten der späteren Realisierung im Steuergerät übereinstimmen. Jede Abweichung zwischen Experimentiersystem und dem Steuergerät als Zielsystem stellt ein Entwicklungsrisiko dar.

So kann etwa eine hohe Übereinstimmung des Echtzeitverhaltens zwischen Experimentiersystem und dem Steuergerät dann erreicht werden, wenn auf beiden Plattformen ein Echtzeitbetriebssystem, beispielsweise nach AUTOSAR, eingesetzt wird. In diesem Fall spricht man auch von einem zielsystem-identischen Echtzeitverhalten des Prototypen. Auch die explizite Vorgabe von Designentscheidungen, wie bei der späteren Implementierung im Steuergerät, und ihre Berücksichtigung bei der Prototypimplementierung führen zu einer Reduzierung des Entwicklungsrisikos. Rapid-Prototyping-Methoden mit dieser Zielrichtung werden auch zielsystemidentisches Prototyping genannt.

5.3.8.5 Wegwerf- und evolutionäre Prototypen

Ein weiteres Unterscheidungskriterium ist, ob ein Prototyp als Basis für die Produktentwicklung verwendet werden soll oder nicht. Wird der Prototyp als Basis für das Produkt verwendet, so spricht man auch von einem evolutionären Prototyp . Falls nicht, wird der Prototyp als Wegwerfprototyp bezeichnet. Auch ein Prototyp, der nur innerhalb der Lasten- oder Pflichtenhefte verwendet wird, ist ein Wegwerfprototyp, da seine Ergebnisse nicht direkt als Teil des Produkts verwendet werden. Beide Vorgehensweisen sind in der Automobilindustrie verbreitet. Das bekannteste Beispiel für eine evolutionäre Entwicklungsweise stellen die A-, B-, C- und D-Muster für Steuergeräte-Hardware oder -Software dar (Abb. 5.51 und 5.52).
Abb. 5.51

Evolutionäre Prototypentwicklung mit Entwicklungssteuergeräten

Abb. 5.52

Evolutionäre Entwicklung mit Entwicklungssteuergeräten

Auch beim Einsatz von Experimentiersystemen erfolgt mit zunehmendem Entwicklungsfortschritt der Übergang auf ein Entwicklungssteuergerät. Die validierte Spezifikation stellt die Basis für Design und Implementierung unter Berücksichtigung aller Details des Mikrocontrollers dar.

Dieser Übergang wird zunehmend fließend, da mit Einsatz von Codegenerierungstechnologien aus ein und demselben Software-Modell Quellcode für das Experimentiersystem oder das Steuergerät generiert werden kann. Dabei können viele Implementierungsdetails bereits auf dem Experimentiersystem berücksichtigt werden.

5.3.8.6 Verifikation des Steuergeräts mit Referenzprototyp

Bei zielsystem-identischem Prototyping kann die im Bypass validierte Software-Funktion als Testreferenz für die Verifikation der mit Hilfe der automatisierten Codegenerierung implementierten Steuergerätefunktion verwendet werden. Dazu rechnen Steuergerät und Experimentiersystem eine Software-Funktion parallel und synchronisiert. Die im Steuergerät berechneten Zwischen- und Ausgangsgrößen einer Software-Funktion werden auf dem Experimentiersystem mit den Rechenergebnissen der Bypass-Funktion verglichen. Die Bypass-Kommunikation muss dazu wie in Abb. 5.53 dargestellt erweitert werden.
Abb. 5.53

Verifikation einer Funktion des Steuergeräts durch Vergleich mit der Bypass-Funktion des Experimentiersystems

Eine hohe Testabdeckung kann bei diesem Verfahren durch den zusätzlichen Einsatz von Werkzeugen zur Abdeckungsanalyse (engl. Coverage Analysis) auf dem Experimentiersystem nachgewiesen werden.

5.4 Design und Implementierung von Software-Funktionen

Bevor die auf der physikalischen Ebene spezifizierten Software-Funktionen auf einem Mikrocontroller implementiert werden können, müssen Designentscheidungen getroffen werden.

Dabei sind auch die geforderten nichtfunktionalen Produkteigenschaften für Seriensteuergeräte zu beachten, wie die Trennung von Programm- und Datenstand, die Realisierung von Programm- und Datenvarianten, die Unterstützung der notwendigen Offboard-Schnittstellen, die Implementierung von Algorithmen in Festpunkt- oder Gleitpunktarithmetik oder die Optimierung der notwendigen Hardware-Ressourcen. Diese nichtfunktionalen Anforderungen haben teilweise auch Rückwirkungen auf die Spezifikation, so dass eine iterative und kooperative Vorgehensweise zwischen Spezifikation und Design erforderlich werden kann. Ein Beispiel dafür wäre das Ziel, dass ressourcenintensive Kennlinien und Kennfelder, wie sie in Abschn. 5.4.1.5 behandelt werden, möglichst bereits in der Spezifikation zu vermeiden. In vielen Fällen muss beim Design ein Kompromiss zwischen der Genauigkeit einer Software-Funktion und den benötigten Hardware-Ressourcen (Speicher- und Laufzeitbedarf) gefunden werden.

In den folgenden Abschnitten werden Methoden und Werkzeuge für Design und Implementierung der Software-Architektur, des Datenmodells und des Verhaltensmodells von Software-Funktionen behandelt.

5.4.1 Berücksichtigung der geforderten nichtfunktionalen Produkteigenschaften

Als Beispiel für nichtfunktionale Produkteigenschaften werden zunächst ausführlich die Einflüsse von Kostenschranken für elektronische Systeme im Kraftfahrzeug auf die Software-Entwicklung betrachtet. Die daraus häufig folgenden begrenzten Hardware-Ressourcen schränken die möglichen Lösungen bei der Abbildung von physikalisch spezifizierten Software-Funktionen auf numerische Algorithmen vielfach ein. In diesem Abschnitt werden verschiedene Optimierungsmaßnahmen zur Verringerung der notwendigen Hardware-Ressourcen anhand von Beispielen dargestellt. Die Realisierung von Datenvarianten wird bei der Implementierung des Datenmodells behandelt.

5.4.1.1 Laufzeitoptimierung durch Berücksichtigung unterschiedlicher Zugriffszeiten auf verschiedene Speichersegmente

Die Zugriffszeiten auf die verschiedenen Speichersegmente eines Mikrocontrollers, wie auf RAM, ROM oder Flash, sind häufig unterschiedlich. Daraus kann sich ein nicht zu vernachlässigender Einfluss auf die Ausführungszeit eines Programms, kurz Laufzeit, ergeben. Eine laufzeitoptimierte Lösung kann beim Entwurf der Software dadurch erreicht werden, dass häufig ausgeführte Programmteile, etwa Interpolationsroutinen für Kennlinien und Kennfelder, in Speichersegmenten mit kurzer Zugriffszeit abgelegt werden. Bei Software-Komponenten, die für verschiedene Hardware-Plattformen eingesetzt werden, kann diese Anforderung durch entsprechende Konfigurationsmöglichkeiten berücksichtigt werden.

Beispiel

Architektur eines Echtzeitbetriebssystems [OS]

Die Architektur eines Echtzeitbetriebssystems berücksichtigt unterschiedliche Zugriffszeiten auf verschiedene Speichersegmente durch ihre modulare Struktur. Wie in Abb. 5.54 dargestellt, können die einzelnen Komponenten des Betriebssystems in verschiedenen Speichersegmenten des Mikrocontrollers abgelegt werden.
Abb. 5.54

Speicherkonfiguration eines Echtzeitbetriebssystems

Da die Ausführung von Programmcode aus dem ROM bei Mikrocontrollern meist schneller ist als die Ausführung aus dem Flash, werden häufig durchlaufene Betriebssystemroutinen in der Komponente Fast Code zusammengefasst und im ROM abgelegt. Seltener aufgerufene Routinen werden in der Komponente Standard Code zusammengefasst und können im Flash abgelegt werden. Entsprechend der Zugriffshäufigkeit können auch die Datenstrukturen des Betriebssystems den verschiedenen RAM-Segmenten, wie dem internen oder externen RAM, mit verschieden langen Zugriffszeiten, zugeordnet werden.

5.4.1.2 Laufzeitoptimierung durch Aufteilung einer Software-Funktion auf verschiedene Tasks

Eine Maßnahme zur Laufzeitoptimierung ist auch die Aufteilung einer Software-Funktion auf mehrere Tasks, denen unterschiedliche Echtzeitanforderungen zugeordnet sind. Die notwendige Zeitrate für die Ausführung einer Teilfunktion richtet sich nach dem physikalischen Verhalten der Regel- oder Steuerstrecke. So ändert sich beispielsweise die Temperatur der Umgebungsluft im Allgemeinen recht langsam, interne Systemdrücke dagegen recht schnell. In solchen Fällen können von der Umgebungslufttemperatur abhängige Teilfunktionen daher einer „langsamen“ Task zugeordnet werden; von internen Drücken abhängige Teilfunktionen müssen in einer „schnelleren“ Task ausgeführt werden.

Beispiel

Aufteilung einer Software-Funktion auf mehrere Tasks

Abb. 5.55 zeigt die Aufteilung einer Software-Funktion in drei Teilfunktionen a, b und c, die drei Tasks A, B und C zugeordnet werden. Die Aktivierungszeiten der Tasks sind unterschiedlich. Task A wird alle 100 ms aktiviert, Task B alle 10 ms und Task C alle 20 ms. In Teilfunktion a wird eine Zwischengröße berechnet, die mit Message X zur Task B kommuniziert wird und dort von der Teilfunktion b weiterverwendet wird. In Teilfunktion c wird die Message Y berechnet, die ebenso in Teilfunktion b verwendet wird. Gegenüber der Berechnung aller Teilfunktionen in der „schnellen“ Task B kann damit die für die Ausführung benötigte Laufzeit reduziert werden – unter der Voraussetzung, dass der Einspareffekt nicht durch die notwendige „zusätzliche“ Laufzeit für die Inter-Task-Kommunikation überkompensiert wird.
Abb. 5.55

Aufteilung einer Software-Funktion auf verschiedene Tasks und Spezifikation der Inter-Task-Kommunikation mit Messages. (ETAS GmbH [85])

Generell gilt bei vielen Optimierungsmaßnahmen, dass sie nur dann erfolgreich sind, wenn die gesamten „Kosten“ sinken. So führt beispielsweise eine Verringerung der Laufzeit in vielen Fällen zu einer Erhöhung des Speicherbedarfs und umgekehrt. Dies sollte bei allen folgenden Beispielen ein Hintergedanke sein.

5.4.1.3 Ressourcenoptimierung durch Aufteilung in Online- und Offline-Berechnungen

Für die Optimierung der Laufzeit werden auch viele Optimierungen „offline“, also vor der eigentlichen Ausführung, durchgeführt. Eine Unterscheidung zwischen Online- und Offline-Berechnungen ist aus diesem Grund hilfreich. Ein Beispiel aus dem Bereich der Echtzeitbetriebssysteme sind das dynamische „Online-Scheduling“ von Tasks gegenüber dem statischen „Offline-Scheduling“ von Tasks, wie in Abschn.  2.4.4.6 gezeigt wurde.

Beispiel

Offline-Optimierung nicht notwendiger Message-Kopien

Ein weiteres Beispiel ist die Offline-Optimierung nicht notwendiger Message-Kopien (Abb.  2.36). In Abb. 5.56 sind die Prioritäten der Tasks A, B und C eingetragen. Bei einer präemptiven Zuteilungsstrategie kann Task B mit der höheren Priorität 2 Task A mit Priorität 1 unterbrechen. Task B wiederum kann von Task C mit Priorität 3 unterbrochen werden. Da Task C den Wert der Message Y ändern kann, muss Task B beim Start eine lokale Kopie von Message Y anlegen, mit deren konsistentem Wert Task B während der kompletten Ausführung arbeitet. Da Task A infolge geringerer Priorität Task B nicht unterbrechen kann, ist eine Änderung des Werts von Message X während der Ausführung von Task B nicht möglich und eine lokale Kopie für Message X in Task B nicht notwendig. Bei bekannter Zuteilungsstrategie kann deshalb bereits offline entschieden werden, ob eine Message-Kopie notwendig ist oder nicht. Nicht notwendige Message-Kopien können vermieden und so Laufzeit- und Speicherbedarf eingespart werden.
Abb. 5.56

Offline-Optimierung nicht notwendiger Message-Kopien. (ETAS GmbH [85])

5.4.1.4 Ressourcenoptimierung durch Aufteilung in Onboard- und Offboard-Berechnungen

Weiteres Optimierungspotential bietet eine Aufteilung in Onboard- und Offboard-Berechnungen. Größen und Berechnungen, die nur für Offboard-Werkzeuge, wie für Kalibrier-, Mess- und Diagnosewerkzeuge und nicht onboard im Steuergeräteverbund benötigt werden, können vom Steuergerät in diese Werkzeuge ausgelagert werden. Dies führt zu Ressourceneinsparungen im Steuergerät. Beispiele dafür sind die Spezifikation von abhängigen Parametern oder berechneten Messgrößen , die nur offboard benötigt werden.

Beispiel

Abhängige Parameter

In Abb. 5.57 ist ein Beispiel für Abhängigkeiten zwischen Parametern dargestellt. Die physikalischen Gleichungen werden dabei in Onboard- und Offboard-Berechnungen aufgeteilt. Dazu werden im Steuergerät die Parameter d und U eingeführt, die von dem Parameter r und dem Festwert π abhängen und im Kalibrierwerkzeug berechnet werden. Dies führt zu einer Reduzierung der notwendigen Berechnungen im Steuergerät und damit zu einer Laufzeitverringerung.
Abb. 5.57

Abhängige Parameter. (ETAS GmbH [74, 86])

Ein weiterer Vorteil ist, dass im Kalibrierwerkzeug nur der Parameter r angepasst werden muss und die konsistente Verstellung der abhängigen Parameter d und U vom Werkzeug gewährleistet wird.

Beispiel

Berechnete Messgrößen

Ähnliche Optimierungen sind durch die Offboard-Berechnung von Messgrößen, wie in Abb. 5.58 dargestellt, möglich. Die Signale Moment M und Drehzahl n liegen im Steuergerät vor, während die Leistung P offboard im Messwerkzeug berechnet wird.
Abb. 5.58

Berechnete Messgrößen. (ETAS GmbH [86])

5.4.1.5 Ressourcenoptimierung bei Kennlinien und Kennfeldern

Im Bereich der Datenstrukturen sind vielfältige Optimierungsmaßnahmen verbreitet. Kennlinien und Kennfelder (Abb.  4.26) werden bei vielen Funktionen zahlreich eingesetzt. Entsprechend groß ist das Optimierungspotential zur Reduzierung von Speicher- und Laufzeitbedarf bei Kennlinien und Kennfeldern.

In den folgenden Beispielen werden einige in der Praxis eingesetzte Möglichkeiten anhand von Kennlinien vorgestellt. Alle Maßnahmen können in ähnlicher Weise auch bei Kennfeldern angewendet werden.

Ablageschema, Interpolation und Extrapolation von Kennlinien

Üblicherweise werden Kennlinien in einer tabellarischen Datenstruktur abgelegt, wie in Abb. 5.59 dargestellt. In der ersten Zeile der Datenstruktur werden die Stützstellen für die Eingangsgröße als streng monoton steigende Folge eingetragen. Wie die Kennlinieneingangsgröße werden die Stützstellen meist mit x bezeichnet. In der zweiten Zeile steht zu jeder Stützstelle der Wert der Kennlinie. Dieser wird, wie auch die Ausgangsgröße der Kennlinie, mit y bezeichnet.
Abb. 5.59

Ablageschema, Interpolation und Extrapolation von Kennlinien

Weitere Elemente der Kennlinienstruktur sind Hilfsgrößen zur Berechnung des Ausgangswertes wie beispielsweise die Anzahl der Stützstellen. Kennlinien werden auch häufig grafisch als x-y-Diagramm dargestellt.

Für Eingangsgrößen, die außerhalb der Stützstellenverteilung liegen, im Abb. 5.59 also für Werte von x < xmin = x1 oder x > xmax = x8 wird in der Regel extrapoliert. In Abb. 5.59 ist eine konstante Extrapolation dargestellt, wie sie in vielen Anwendungen zum Einsatz kommt. Für Eingangsgrößen, die zwischen zwei Stützstellen liegen, wird interpoliert. In Abb. 5.59 ist die lineare Interpolation dargestellt, die meistens verwendet wird.

Im Folgenden wird die Extrapolation nicht weiter berücksichtigt, sondern nur die Interpolation betrachtet. Der Interpolationsalgorithmus zur Bestimmung der Ausgangsgröße yi zu einer Eingangsgröße xi unterscheidet drei wesentliche Schritte.

Schritt 1: Stützstellensuche:

Es wird eine benachbarte, also die nächstniedrigere oder nächsthöhere Stützstelle zur Eingangsgröße xi bestimmt. Im Beispiel in Abb. 5.59 ist die nächstniedrigere Stützstelle xu die Stützstelle x3. Wegen der streng monotonen Ablage der Stützstellen ist damit auch die nächsthöhere Stützstelle xo = x4 bekannt.

Zur Stützstellensuche können verschiedene Suchalgorithmen eingesetzt werden. Beispiele sind „Suche ausgehend von der letzten, gültigen Stützstelle“, „Binäre Suche“, „Suche von der größten Stützstelle in Richtung kleinerer Werte“ oder umgekehrt (Abb. 5.60).
Abb. 5.60

Verschiedene Verfahren zur Stützstellensuche

Die Wahl des geeigneten Suchverfahrens hängt u. a. von der Stützstellenverteilung und von der Anwendung ab. Beispielsweise ist bei Motorsteuerungen die Laufzeit bei hohen Motordrehzahlen knapp. Hier bietet es sich deshalb an, bei Kennlinien mit Drehzahleingang von hohen zu niedrigeren Drehzahlen zu suchen. Bei niedrigeren Motordrehzahlen ist die damit in Kauf genommene längere Suchzeit weniger kritisch.

Bei knapper Laufzeit wird in manchen Anwendungsfällen yu = y(xu) oder yo = y(xo) als Ausgangsgröße der Kennlinie ausgegeben. Einen genaueren Wert erhält man bei Einsatz eines Interpolationsalgorithmus. In der Regel wird linear zwischen zwei Stützstellen interpoliert. Dabei können die Schritte 2 und 3 unterschieden werden.

Schritt 2: Berechnung der Steigung a:

Für die lineare Interpolation müssen folgende Differenzen berechnet werden:

dx = xi − xu (in Abb. 5.59: dx = xi − x3),

DX = xo − xu (in Abb. 5.59: DX = x4 − x3),

DY = yo − yu (in Abb. 5.59: DY = y4 − y3).

Die Steigung a der Kennlinie wird durch Division berechnet:

a= DY/DX.

Schritt 3: Berechnung des Kennlinienwerts y i durch lineare Interpolation:

yi = yu + a · dx (in Abb. 5.59: yi = y3 + a · dx)

Die Größe dx kann nur online berechnet werden. Werden auch DX, DY und a online berechnet, so müssen bei jeder Interpolation drei Subtraktionen, eine Division, eine Addition und eine Multiplikation online berechnet werden.

Alternativ können DX, DY und a offline und offboard berechnet werden. Dies wird für die Optimierung ausgenützt. Folgende Maßnahmen sind verbreitet:

Ablage der Steigung a in einer erweiterten Kennlinienstruktur

Das Ablegen der Steigung a in einer erweiterten Kennlinienstruktur spart Rechenzeit bei der Interpolation. Online muss dann nur eine Subtraktion, eine Addition und eine Multiplikation berechnet werden. Bei zeitkritischen Anwendungen wird der erhöhte Speicherbedarf für die erweiterte Kennlinienstruktur dafür in Kauf genommen (Abb. 5.61).
Abb. 5.61

Erweiterte Kennlinienstruktur mit Ablage der Steigung a

Festkennlinien

Der Abstand zwischen den Stützstellen DX = xo − xu wird konstant vorgegeben. Dann kann die Stützstelle xu berechnet werden. Ein Suchverfahren entfällt. Der Kehrwert zu DX kann offline und offboard berechnet und mit der Kennlinie abgelegt werden. Bei der Interpolation ist keine Division mehr notwendig. Online müssen zwei Subtraktionen, eine Addition und zwei Multiplikationen berechnet werden.

Die Stützstellenverteilung kann durch den Wert der minimalen Stützstelle xmin, der Stützstellenanzahl n und dem Stützstellenabstand DX abgelegt werden. Dieses Ablageschema bietet sich vor allem bei Kennlinien mit großer Stützstellenanzahl an (Abb. 5.62).
Abb. 5.62

Kennlinienstruktur für Festkennlinien

Gruppenkennlinien

Für verschiedene Kennlinien mit gleicher Eingangsgröße wird die Stützstellenverteilung einheitlich vorgegeben. Die Stützstellensuche und die Berechnung der Differenzen auf der x-Achse müssen nur einmalig durchgeführt werden. Die Interpolationsberechnung wird jeweils für jede Ausgangsgröße yi durchgeführt (Abb. 5.63).
Abb. 5.63

Kennlinienstruktur für Gruppenkennlinien

Auch Kombinationen zwischen Fest- und Gruppenkennlinien sind denkbar.

Weitere Optimierungsmaßnahmen sind die Anpassung bzw. Verringerung der Stützstellenanzahl nach der Kalibrierung. Dies spart Rechenzeit bei der Stützstellensuche und Speicherplatz. Nach der Kalibrierung kann auch der physikalische Wertebereich eventuell verkleinert, die Quantisierung vergrößert oder die Wortlänge für Stützstellen und Werte verringert werden.

Die zahlreichen Kombinationsmöglichkeiten der möglichen Wortlängen zur prozessorinternen Darstellung von Stützstellen und Werten bei Kennlinien führen zu einer hohen Anzahl von verschiedenen Interpolationsroutinen mit entsprechend hohem Speicherplatzbedarf. Zur Reduzierung der Anzahl der Kombinationsmöglichkeiten werden die zulässigen Ablageschemata für Kennlinien und Kennfelder in der Regel vorab eingeschränkt.

5.4.2 Design und Implementierung von Algorithmen in Festpunkt- und Gleitpunktarithmetik

In diesem Abschnitt steht der Entwurf von Algorithmen in Festpunkt- bzw. Gleitpunktarithmetik (engl. Fixed-Point bzw. Floating-Point Arithmetic) im Mittelpunkt. Dieser Abschnitt beschränkt sich dabei auf grundlegende Methoden, die heute in der Praxis online – also im Mikrocontroller des Steuergeräts – eingesetzt werden. Neben den arithmetischen Grundoperationen werden online vor allem Interpolationsmethoden für Kennlinien und Kennfelder, numerische Verfahren zur Differentiation und Integration von Signalen sowie numerische Filterverfahren verwendet. Eine Basisblockbibliothek mit diesem Funktionsumfang wurde zum Beispiel im Rahmen des Projekts MSR-MEGMA [78] standardisiert. Dieser Abschnitt beschränkt sich auf einige grundsätzliche Fragestellungen, die bei Design und Implementierung von Algorithmen in Maschinenarithmetik auftreten.

5.4.2.1 Darstellung von Zahlen in digitalen Prozessoren

Alle digitalen Prozessoren arbeiten mit Zahlen im Binärsystem, in dem die Koeffizienten ai der Binärzerlegung zur Darstellung einer Zahl x genutzt werden:

x  =  ±(an · 2n + an−1 · 2n−1 + … + a0 · 20 + a−1 · 2−1 + a−2 · 2−2 + …).

Beispiel

Binärdarstellung der Zahl x = 9

Die Zahl x = 9 besitzt nach der Zerlegung

9 = 1 · 23 + 0 · 22 + 0 · 21 + 1 · 20

die Binärdarstellung 1001.

Zur Unterscheidung zwischen Dezimal- und Binärdarstellungen werden Binärdarstellungen im Folgenden immer fett geschrieben.

Zur internen Darstellung einer Zahl steht bei digitalen Prozessoren nur eine feste endliche Anzahl n von Binärstellen zur Verfügung. Diese Anzahl wird als Wortlänge bezeichnet. Sie ist durch die Konstruktion des Prozessors festgelegt und kann meist auf ganze Vielfache 2n, 3n, … von n erweitert werden. Entsprechend werden Mikroprozessoren mit der Wortlänge 8 als 8-Bit-Mikroprozessoren bezeichnet, mit einer Wortlänge von 16 als 16-Bit-Mikroprozessoren usw.

Die Wortlänge von n Stellen kann auf verschiedene Weise zur Darstellung einer Zahl verwendet werden.

Bei der Festpunktdarstellung sind zusätzlich zur Zahl n auch die Zahlen n1 und n2 der Stellen vor bzw. nach dem Komma oder Punkt fest. Dabei gilt n = n1 + n2. Meist ist n1 = n oder n1 = 0.

Viele Mikroprozessoren, die in Steuergeräten eingesetzt werden, beschränken sich auch heute noch auf die Festpunktdarstellung von Zahlen und ihre Verarbeitung.

Im Folgenden wird ohne Beschränkung der Allgemeingültigkeit von n1 = n für die Festpunktdarstellung ausgegangen. Die Zahl n bestimmt dann die Menge der darstellbaren Zahlen.

Beispielsweise können für n = 8 die Zahlen 0 … 255 durch die Binärzahlen 0000 0000 … 1111 1111 dargestellt werden. Entsprechend wird eine solche Zahlendarstellung als 8-Bit-Darstellung ohne Vorzeichen (engl. 8-bit unsigned integer, kurz uint8) bezeichnet.

Zur Darstellung negativer Zahlen wird ein Bit zur Vorzeichenkodierung verwendet. Dieses Bit wird Vorzeichenbit genannt. Für n = 8 können dann die Zahlen −128 … 0 … + 127 dargestellt werden. Entsprechend wird diese Zahlendarstellung als 8-Bit-Darstellung mit Vorzeichen (engl. 8-bit signed integer, kurz sint8) bezeichnet.

In ähnlicher Weise werden 16- und 32-Bit-Darstellungen von Zahlen mit uint16, sint16, uint32 und sint32 bezeichnet. Die darstellbaren Wertebereiche sind in Tab. 5.2 aufgelistet.
Tab. 5.2

Festpunktdarstellung von Zahlen und darstellbare Wertebereiche

Bei der Gleitpunktdarstellung wird der Dezimalpunkt nicht für alle Zahlen vorab festgelegt. Dementsprechend muss bei jeder Zahl angegeben werden, an der wievielten Stelle nach der ersten Ziffer der Dezimalpunkt liegt. Dazu wird der so genannte Exponent verwendet. Dabei wird ausgenutzt, dass sich eine reelle Zahl x in der Form des Produktes

x = a · 2b

mit |a| < 1 und b als ganzzahliger Zahl darstellen lässt. Durch den Exponenten b wird die Lage des Dezimalpunktes in der Mantisse  a angegeben.

Beispiel

Binärdarstellung der Zahl x = 9,5

9,5 = 1 · 23 + 0 · 22 + 0 · 21 + 1 · 20 + 1 · 2−1 die Binärdarstellung 1001.1 oder 0.10011 · 2 100 .

In jedem digitalen Prozessor stehen auch für die Gleitpunktdarstellung von Zahlen nur eine endliche feste Anzahl m bzw. e von Binärstellen für die Darstellung der Mantisse a bzw. des Exponenten b zur Verfügung. Dabei gilt n = m + e.

Abhängig von den Anforderungen der Anwendung kommen in Steuergeräten Mikroprozessoren zum Einsatz, die die Gleitpunktdarstellung von Zahlen und deren Verarbeitung in Gleitpunktarithmetik unterstützen oder nicht.

Die Gleitpunktdarstellung einer Zahl ist im Allgemeinen nicht eindeutig. Im letzten Beispiel hätte man auch die Darstellungsform 0.010011 · 2 101 wählen können. Normalisiert heißt deshalb diejenige Gleitpunktdarstellung einer Zahl, für die die erste Ziffer der Mantisse a von 0 verschieden ist. Im Binärsystem gilt dann |a| ≥ 2−1. Als wesentliche Stellen einer Zahl werden alle Ziffern der Mantisse a ohne die führenden Nullen bezeichnet.

In den folgenden Abschnitten wird ohne Beschränkung der Allgemeingültigkeit immer von der normalisierten Gleitpunktdarstellung und der zugehörigen Gleitpunktrechnung ausgegangen.

Die Zahlen m und e bestimmen zusammen mit der Basis B = 2 der Zahldarstellung die Menge A der Zahlen, die in der Maschine exakt dargestellt werden können. Diese Menge A ist eine Teilmenge der reellen Zahlen ℝ (A ⊆ ℝ). Die Elemente der Menge A heißen Maschinenzahlen .

Für n = 32 und n = 64 sind Gleitpunktdarstellungen in IEEE standardisiert. Ähnlich zu den Festpunktzahlen werden 32-Bit-Gleitpunktzahlen mit real32 bzw. 64-Bit-Gleitpunktzahlen mit real64 bezeichnet.

Da die Menge A der in einer Maschine darstellbaren Zahlen für Festpunkt- und Gleitpunktzahlen endlich ist, ergibt sich bei Design und Implementierung des Verhaltens einer Software-Komponente sofort das Problem, wie man eine Zahl x ∉ A, die keine Maschinenzahl ist, durch eine Maschinenzahl approximieren kann. Dieses Problem stellt sich bei der Eingabe von Daten in den Prozessor, aber auch bei der internen Verarbeitung im Prozessor.

Wie anhand einfacher Beispiele gezeigt werden kann, gibt es Fälle, bei denen selbst das Resultat c der arithmetischen Grundoperationen zweier Zahlen a und b, also der Addition a + b, der Subtraktion a − b, der Multiplikation a · b und der Division a/b nicht zu A gehören, obwohl beide Operanden a und b Maschinenzahlen sind (a, b ∈ A).

Von einer Approximation für eine Zahl x, die keine Maschinenzahl ist (x ∉ A) durch eine Maschinenzahl rd(x) mit rd(x) ∈ A wird daher verlangt, dass

| x − rd(x) | ≤ | x − gk | für alle gk ≠ rd(x) und gk ∈ A (Abb. 5.64).
Abb. 5.64

Approximation von x durch rd(x)

rd(x) wird gewöhnlich durch Rundung oder die Begrenzung des Ergebnisses im Rahmen der so genannten Über- oder Unterlaufbehandlung bestimmt. Die folgenden Abschnitte behandeln Rundungsfehler sowie Über- und Unterläufe anhand von einfachen Beispielen. Im Vordergrund steht das Ziel zu einer möglichst hohen Genauigkeit des Ergebnisses zu kommen.

Bei vielen Operationen mit Zahlen in Festpunktdarstellung können Rundungsfehler, Überläufe und Unterläufe auftreten. In den folgenden Beispielen wird zur Vereinfachung des Verständnisses meist von Zahlen in uint8-Darstellung ausgegangen.

5.4.2.2 Rundungsfehler bei der Ganzzahldivision

Für die Ganzzahldivision (engl. integer division ) c = a/b ergibt sich ein Rundungsproblem, da es sein kann, dass das exakte Ergebnis der Operation a/b nicht ganzzahlig ist.

Beispiel

Ganzzahldivision und Rundung

Die Variablen a, b und c seien in uint8 dargestellt.

Für die Division c = a / b mit a, b, c ∈ A = {0, 1, 2, …, 255} ergibt sich im

Testfall 1:  – a = 100, b = 50 → c = 2 ∈ A

Testfall 2: – a = 19, b = 2 → c = 9,5 ∉ A

Testfall 3: – a = 240, b = 161 → c = 1,49… ∉ A

Testfall 4: – a = 100, b = 201 → c = 0,49… ∉ A

Testfall 5: – a = 100, b = 1 → c = 100 ∈ A (trivial)

Testfall 6: – a = 100, b = 0. Division durch 0 ist nicht definiert!

In Testfall 1 ist das Ergebnis ganzzahlig. Es kann in einer uint8-Zahl dargestellt werden. Es tritt kein Rundungsfehler auf.

Im Testfall 2 ist das Ergebnis nicht ganzzahlig. Es muss gerundet werden.

Man bildet dabei zur Darstellung von c = 9,5

in allgemeiner Binärdarstellung c = (an · 2n + an−1 · 2n−1 + … + a0 · 20 + a−1 · 2−1 + a−2 · 2−2 + …), im vorliegenden Testfall also

c = 9,5 = 1 · 23 + 0 · 22 + 0 · 21 + 1 · 20  + 1 · 2−1 oder 1001.1,

also a3 = 1, a2 = 0, a1 = 0, a0 = 1, a−1 = 1

den gerundeten Wert rd(c) durch

rd(c) = an an−1 … a0 falls a−1 = 0,

rd(c) = an an−1 … a0 + 1 falls a−1 = 1.

Im vorliegenden Testfall würde also rd(c) = 10 oder 1010 gerundet berechnet.

Bei vielen Mikroprozessoren werden bei der Ganzzahldivision anstatt der Rundung die Nachkommastellen einfach abgeschnitten (engl. truncated). Dabei wird betragsmäßig immer abgerundet:

rd(c) = an an−1 … a0 für alle Werte von a−1.

Im vorliegenden Testfall würde also rd(c) = 9 oder 1001 berechnet.

Im Testfall 3 wird rd(c) = 1 für Rundung und Abschneiden der Nachkommastellen bei der Integerdivision berechnet. Jedoch ist der für die Güte des Ergebnisses entscheidende, so genannte relative Rundungsfehler ε = (rd(c) − c)/c = (1 − 1,49) / 1,49 ≈ −1/3 hier schon beträchtlich groß.

Im Testfall 4 wird rd(c) = 0 berechnet. Der relative Rundungsfehler (0 − 0,49) / 0,49 = −1 ist hier besonders groß. Wie später deutlich werden wird, ist dieser Testfall für die Fehlerfortpflanzung, z. B. bei einer Weiterverarbeitung des Zwischenergebnisses in einer Multiplikation, deshalb besonders kritisch.

Die Division durch 1 im Testfall 5 ist trivial.

Die Division durch 0, wie im Testfall 6 ist nicht definiert und muss durch eine Ausnahmebehandlung im Algorithmus ausgeschlossen werden.

Für c > 1 ist der relative Fehler ε bei der Rundung

$$\left| \upvarepsilon \right|=\mathrm{\left| \frac{rd(c)-c}{c} \right|\le \frac{1}{3}}.$$
(5.19)

Für c > 1 gilt für den relativen Fehler ε beim Abschneiden

$$\left| \upvarepsilon \right|=\mathrm{\left| \frac{rd(c)-c}{c} \right|\le \frac{1}{2}}.$$
(5.20)

Für c > 1 ergibt sich damit rd(c) = c (1 + ε) mit |ε| ≤ 1/3 bei Rundung bzw. |ε| ≤ 1/2 beim Abschneiden der Nachkommastellen. D. h. der relative Fehler bei Rundung ist etwas geringer als beim Abschneiden der Nachkommastellen. In beiden Fällen wird der relative Fehler mit zunehmender Größe des Ergebnisses c kleiner.

5.4.2.3 Über- und Unterlauf bei der Addition, Subtraktion und Multiplikation

Liegen die Operanden a, b ∈ A als Maschinenzahlen in ganzzahliger Festpunktdarstellung vor, so sind auch die Resultate der Grundoperationen Addition a + b, Subtraktion a − b und Multiplikation a · b ganzzahlige Werte. Ein Rundungsfehler entsteht dabei nicht. Wegen der endlichen Anzahl n der Stellen gibt es aber immer Zahlen x ∉ A, die nicht Maschinenzahlen sind.

Beispiel

Addition, Subtraktion und Multiplikation

Die Variablen a, b und c seien in uint8 dargestellt.

Für die Addition c = a + b mit a, b, c ∈ A = {0, 1, 2, …, 255} ergibt sich im

Testfall 1: – a = 100, b = 100 → c = 200 ∈ A,

Testfall 2: – a = 100, b = 157 → c = 257 ∉ A.

Für die Subtraktion c = a − b mit  a, b, c ∈ A = {0, 1, 2, …, 255} ergibt sich im

Testfall 3: – a = 100, b = 100 → c =  0 ∈ A

Testfall 4: – a = 100, b = 102 → c = −2 ∉ A

In Testfall 2 ist das Ergebnis für c zu groß, um mit einer uint8-Zahl dargestellt werden zu können. Man bezeichnet dies als Überlauf .

In Testfall 4 ist das Ergebnis für c für eine uint8-Darstellung zu klein. Dies wird als Unterlauf bezeichnet.

Ähnliche Situationen können auch bei Multiplikationen auftreten.

Auch bei Implementierung in Gleitpunktarithmetik haben Fehler in den Eingangsdaten einer Rechnung sowie Approximationsfehler durch die gewählten Rechenmethoden die gleiche Auswirkung. Verglichen mit der Festpunktarithmetik sind die Rundungsfehler bei Verwendung von Gleitpunktzahlen und Gleitpunktarithmetik allerdings um Größenordnungen geringer.

5.4.2.4 Schiebeoperationen

Wegen der prozessorinternen Binärdarstellung können Multiplikationen der Form a · b und Divisionen der Form a/b, im Falle, dass der Operand b einen Wert aus der Menge {21, 22, …, 2n} annimmt, besonders effizient durch Schiebeoperationen (engl. Shift Operations ) durchgeführt werden.

Beispiel

Schiebeoperationen

Die Zahl x = 9 besitzt nach der Zerlegung

9 = 0 · 24 + 1 · 23 + 0 · 22 + 0 · 21 + 1 · 20

die Binärdarstellung 01001.

Das Produkt 9 · 2 kann durch die Schiebeoperation nach links 01001<<1 dargestellt werden. Man erhält das Ergebnis 10010 oder 18.

Die Division 9/2 kann entsprechend durch die Schiebeoperation nach rechts 01001>>1 berechnet werden. Das Ergebnis ist 00100 oder 4. Bei Schiebeoperationen nach rechts werden also die Nachkommastellen immer abgeschnitten.

Bei vorzeichenbehafteten Größen, wie sint8, sint16 oder sint32, muss beachtet werden, dass das Vorzeichenbit bei Rechts-Schiebeoperationen >> unter Umständen eine normale Stelle für die Zahldarstellung werden kann. Deshalb sollte in diesem Fall genau geprüft werden, ob stattdessen besser eine normale Division durchgeführt werden sollte.

5.4.2.5 Behandlung von Überläufen und Unterläufen

Die Aktionen beim Verlassen des Wertebereichs infolge Überlauf oder Unterlauf hängen vom Prozessor ab. Im Algorithmus kann darauf verschieden reagiert werden. Anhand des Beispiels für die Addition werden einige häufig eingesetzten Möglichkeiten für die Überlaufbehandlung dargestellt.

Beispiel

Überlaufbehandlung

Die Variablen a, b und c seien in uint8 dargestellt.

Für die Addition c = a + b mit a, b, c ∈ A = {0, 1, 2, …, 255} ergibt sich im

Testfall 1: – a = 100, b = 100 → c = 200 ∈ A,

Testfall 2: – a = 100, b = 157 → c = 257 ∉ A.

Auf den Überlauf im Testfall 2 kann mit folgenden Möglichkeiten reagiert werden:

Überlauf mit/ohne Überlauferkennung

Der Überlauf wird zugelassen. Bei den meisten Mikroprozessoren wird c = a + b − 256 = 1 ausgegeben. Anhand eines Vergleichs (c < a) && (c < b) kann ein Überlauf bei einer Addition von nicht vorzeichenbehafteten Größen im Algorithmus erkannt und behandelt werden.

Begrenzung des Ergebnisses

Der Überlauf wird im Algorithmus erkannt und das Ergebnis c wird auf den maximal darstellbaren Wert c = 255 begrenzt.

Erweiterung des Wertebereichs des Ergebnisses

Das Ergebnis c wird in einer Variable mit größerem Wertebereich, beispielsweise in einer uint16- oder sint16-Variable, dargestellt. Es ergibt sich
  1. c

    = a + b mit a, b ∈ Auint8 = {0, 1, 2, …, 255}

    und c ∈ Auint16 = {0, 1, 2, …, 65535}

    oder c ∈ Asint16 = {−32768, …, 0, 1, 2, …, 32767}.

    Ein Überlauf kann nicht mehr eintreten. Im Fall, dass c als Größe vom Typ sint16 dargestellt wird, kann bei einer Subtraktion auch ein Unterlauf nicht mehr eintreten.

     

Umskalierung des Ergebnisses

Der Überlauf wird erkannt und das Ergebnis c wird umskaliert zu rd(c). Dazu wird eine Quantisierung oder Auflösung q für c mit |q| > 1 eingeführt. Mit der Umskalierung des Ergebnisses c nach der Gleichung c = q · rd(c) kann der Wertebereich von c erweitert werden und es tritt kein Überlauf mehr auf. Umskalierungen mit Faktoren q aus der Menge {21, 22, …, 2n} können durch Schiebeoperationen realisiert werden. So ergibt sich etwa für

rd(c) = (a + b) / q mit – a, b, rd(c) ∈ Auint8 = {0, 1, 2, …, 255} und q = 2

c ∈ Ac = {0, 2, 4, …, 510}.

Ein Überlauf kann nicht mehr eintreten. Allerdings ist die Genauigkeit des Ergebnisses rd(c) = 256 reduziert. Der relative Fehler ε ist

$$\left| \upvarepsilon \right|=\mathrm{\left| \frac{rd(c)-c}{c} \right|\le \frac{q-1}{c}}.$$
(5.21)
(5.21)

Der relative Fehler nimmt wieder mit zunehmender Größe des Ergebnisses c ab.

5.4.2.6 Fehlerfortpflanzung bei Algorithmen in Festpunktarithmetik

Nun soll untersucht werden, wie sich Fehler innerhalb eines Algorithmus fortsetzen. Der Begriff Algorithmus wird dazu zunächst genauer definiert. Als Algorithmus wird im Folgenden eine der Reihenfolge nach eindeutig festgelegte Sequenz von endlich vielen „einfachen“ Operationen bezeichnet, mit denen aus gewissen Eingangsdaten die Lösung eines Problems berechnet werden kann.

Beispiel

Zur Definition des Algorithmusbegriffs

Als Beispiel wird der Ausdruck d = a + b + c verwendet.

Obwohl die Methoden d = (a + b) + c und d = a + (b + c) mathematisch äquivalent sind, können sie aus numerischen Gründen bei Festpunktrechnung zu unterschiedlichen Ergebnissen führen.

Der Algorithmus 1 unterscheidet folgende Schritte:

Schritt 1.1: η1 = a + b,

Schritt 1.2: d = η1 + c.

Der Algorithmus 2 unterscheidet folgende Schritte:

Schritt 2.1: η2 = b + c,

Schritt 2.2: d = a + η2.

a, b, c und d seien als sint8-Zahlen dargestellt. Es gilt also a, b, c, d ∈ A = {−128 … +127}

Überläufe und Unterläufe werden erkannt und auf die Werte −128 … +127 begrenzt.

Im Testfalle von a = 101, b = −51 und c = −100 ergibt sich bei

Algorithmus  1: η1 = a + b = 101 − 51 = 50,

d = η1 + c = 50 − 100 = −50,

Algorithmus 2: η2 = b + c = −51 − 100 = −128 (Unterlaufbegrenzung),

d = a + η2 = 101 − 128 = −27.

Untersucht man die Gründe, warum verschiedene Algorithmen im allgemeinen unterschiedliche Resultate liefern, erkennt man schnell, dass die Fehlerfortpflanzung der Rundungs- und Begrenzungsfehler eine wichtige Rolle spielt. Deshalb sollen im Folgenden einige Kriterien für die Beurteilung der Güte von Algorithmen aufgestellt werden.

Bei der Festpunktrechnung erhält man statt d einen Näherungswert rd(d). Für Algorithmus 1 kann rd1(d) bestimmt werden:

rd(η1) = (a + b)(1 + ε1.1),

$$ \begin{aligned} \mathrm{rd(d_{1})}&=(\mathrm{rd}({\upeta }_{1})+\mathrm{c})(1+{\upvarepsilon }_{1.2})=\left[ \mathrm{(a+b)}(1+{\upvarepsilon }_{1.1})+\mathrm{c} \right](1+{\upvarepsilon }_{1.2}) \\ & =\mathrm{(a+b+c)}\left[ 1+\mathrm{\frac{a+b}{a+b+c}}(1+{\upvarepsilon }_{1.2}){\upvarepsilon }_{1.1}+{\upvarepsilon }_{1.2} \right]. \end{aligned} $$
(5.23)

Für den relativen Fehler εd1 gilt damit

$${\upvarepsilon }_{\mathrm{d}1}=\mathrm{\frac{rd(d_{1})-d}{d}=\frac{rd(d_{1})}{d}-1}=\mathrm{\frac{a+b}{a+b+c}}(1+{\upvarepsilon }_{1.2}){\upvarepsilon }_{1.1}+{\upvarepsilon }_{1.2}.$$
(5.24)

In erster Näherung bei Vernachlässigung von Termen höherer Ordnung wie ε1.1 ε1.2 gilt für εd

$${\upvarepsilon }_{\mathrm{d}1}\approx \mathrm{\frac{a+b}{a+b+c}}{\upvarepsilon }_{1.1}+1\cdot {\upvarepsilon }_{1.2}.$$
(5.25)

Entsprechend erhält man für Algorithmus 2

$${\upvarepsilon }_{\mathrm{d}2}\approx \mathrm{\frac{b+c}{a+b+c}}{\upvarepsilon }_{2.1}+1\cdot {\upvarepsilon }_{2.2}.$$
(5.26)

Die Verstärkungsfaktoren (a + b) / (a + b + c) und 1 bzw. (b + c) / (a + b + c) und 1 geben an, wie stark sich die Rundungsfehler der Zwischenergebnisse im relativen Fehler εd des Resultats auswirken. Der kritische Faktor ist (a + b) / (a + b + c) bzw. (b + c) / (a + b + c). Je nachdem ob (a + b) oder (b + c) kleiner ist, ist es günstiger, „numerisch stabiler“, die Summe a + b + c nach der Formel (a + b) + c bzw. a + (b + c) zu berechnen.

Im obigen Testfall ist a + b = 50 und b + c = −151. Wegen der Begrenzung ist ε2.1 besonders groß, im obigen Testfall ε2.1 = (−128 + 151) / (−151) ≈ −0,15. ε1.1, ε1.2 und ε2.2 sind dagegen 0.

Damit erhält man für den Fehler εd2 = [(−151) / (−50)] · (−0,15) = −0,45.

Der relative Fehler ε2.1 von Rechenschritt 1 geht also mit dem Verstärkungsfaktor von ≈ 3 in das Endergebnis bei Algorithmus 2 ein, obwohl Rechenschritt 2 ohne einen relativen Fehler ausgeführt wird! Dies erklärt, warum Algorithmus 1 bei den Eingangswerten dieses Testfalls numerisch günstiger ist.

Diese Methode kann systematisch ausgebaut werden, wird aber rasch aufwändig. Man kann damit den Einfluss weniger Rundungsfehler noch abschätzen. Bei einem typischen Algorithmus ist jedoch die Anzahl der arithmetischen Operationen und damit die Anzahl der einzelnen Rundungsfehler zu groß, um auf diese Weise den Einfluss aller Rundungsfehler bestimmen zu können. In solchen Fällen bieten sich andere Techniken, beispielsweise die Intervallrechnung an [76]. Im Rahmen dieses Abschnitts soll darauf nicht näher eingegangen werden. In den folgenden Beispielen wird nur noch der relative Fehler εi eines Rechenschritts i eines Algorithmus angegeben.

Beispiel

Algorithmus 3

Wird das Zwischenergebnis in Algorithmus 2 des letzten Beispiels dagegen um den Faktor 2 umskaliert und nicht begrenzt, so ergibt sich der folgende Algorithmus 3:

Schritt 3.1: b1 = b / 2 = −51 / 2 = −25 ε3.1 = [−50 − (−51)] / (−51) = −1 / 51,

Schritt 3.2: c1 = c / 2 = −100 / 2 = −50 ε3.2 = 0,

Schritt 3.3: η2 = b1 + c1 = −75 ε3.3 = 0,

Schritt 3.4: a1 = a / 2 = 101 / 2 = 50 ε3.4 = [100 − 101] / (101) = −1 / 101,

Schritt 3.5: d1 = a1 + η2 = 50 − 75 = −25 ε3.5 = 0,

Schritt 3.6: d = d1 · 2 = −25 · 2 = −50 ε3.6 = 0.

Die gewählte Umskalierung liefert bei diesen Eingangswerten ein wesentlich genaueres Ergebnis als Algorithmus 2 mit Begrenzung des Zwischenergebnisses. Diese Art von Begrenzungen muss beachtet werden. Solche Begrenzungen können in Algorithmen beispielsweise durch die Übergabe von Argumenten bei Unterprogrammaufrufen implizit auftreten.

5.4.2.7 Physikalischer Zusammenhang und Festpunktarithmetik

Häufig tritt der Anwendungsfall auf, dass zwei physikalische Signale miteinander verrechnet werden sollen, die im Mikroprozessor als Größen mit unterschiedlicher Skalierung vorliegen. Im folgenden Beispiel wird die Addition zweier Signale behandelt. Operationen mit mehr als zwei Operanden können in mehrere Operationen mit je zwei Operanden zerlegt werden.

Beispiel

Addition zweier Signale mit unterschiedlicher Skalierung

Ein einfaches Beispiel ist die Addition zweier Signale a und b. Es soll der physikalische Zusammenhang cphys = aphys + bphys implementiert werden.

Im Mikroprozessor liegen die Signale a, b und c in Form der Festpunktgrößen aimpl, bimpl und cimpl in uint8-Darstellung vor.

Der Zusammenhang zwischen den physikalischen, kontinuierlichen Größen und der Implementierungsgrößen im diskreten Festpunktformat ist durch eine lineare Formel und die unteren und oberen Grenzwerte vorgegeben. In Abb. 5.65 ist dieser Zusammenhang für die Größe a dargestellt.
Abb. 5.65

Zusammenhang zwischen physikalischer Größe und Implementierung

Bei den Grenzwerten ist zum einen der Wertebereich, der sich aus der Darstellung auf der Implementierungsebene ergibt, zu beachten. Im Abb. 5.65 hat aimpl die Darstellung uint8 mit dem Wertebereich {0, 1, 2, …, 255} oder allgemein mit dem Wertebereich {aimpl MIN, …, aimpl MAX}. Entsprechend erhält man für dieses Beispiel für den physikalisch darstellbaren Wertebereich die oberen und unteren Grenzen:

aphys MIN = (aimpl MIN − K0a) / K1a = (−K0a) / K1a,(5.27)

aphys MAX = (aimpl MAX − K0a) / K1a = (255 − K0a) / K1a.(5.28)

Dieser Wertebereich darf nicht mit dem Bereich der physikalisch auftretenden Werte mit den Grenzen aphys min und aphys max verwechselt werden, dem auf der Implementierungsebene der Wertebereich {aimpl min … aimpl max} zugeordnet werden kann.

Für die Größen b und c gelten ähnliche Beziehungen. Im linearen Bereich gilt:

aimpl (aphys) = K1a · aphys + K0a,(5.29)

bimpl (bphys) = K1b · bphys + K0b,(5.30)

cimpl (cphys) = K1c · cphys + K0c.(5.31)

Da auf der Implementierungsebene nur Festpunktwerte dargestellt werden können, muss in jedem Fall noch eine Rundung durchgeführt werden, die in der Darstellung in Abb. 5.65 weggelassen wurde. 1 / K1i wird auch als Quantisierung oder Auflösung und K0i als Versatz oder Offset bezeichnet.

Die Addition der physikalischen Größen auf der Implementierungsebene kann nach dem folgenden Algorithmus erfolgen:

Schritt 1: Entfernen der Offsets von aimpl und bimpl

aimpl_1 = aimpl − K0a,(5.32)

bimpl_1 = bimpl − K0b.(5.33)

Schritt 2: Angleichen der Quantisierung von aimpl_1 und bimpl_1

aimpl_2 = aimpl_1 · K1b / K1a.(5.34)

Schritt 3: Addition

cimpl_1 = aimpl_2 + bimpl_1.(5.35)

Schritt 4: Angleichen an die Quantisierung von cimpl

cimpl_2 = cimpl_1 · K1c / K1b.(5.36)

Schritt 5: Einrechnen des Offsets von cimpl

cimpl = cimpl_2 + K0c.(5.37)

Alternativ kann ab Schritt 2 auch mit der Quantisierung von aimpl gerechnet werden. In diesem Fall muss bimpl an die Quantisierung von aimpl angeglichen werden. Schritt 4 ändert sich dann entsprechend. In der Regel wird man wegen der höheren Genauigkeit auf die feinere Quantisierung angleichen.

Eine dritte Alternative wäre, ab Schritt 2 direkt mit der Quantisierung des Ergebnisses cimpl zu rechnen.

Bei geschickter Auswahl einer dieser Alternativen kann die Anzahl der notwendigen Umquantisierungen gering gehalten werden.

Bei geschickter Wahl der Quantisierungen durch K1a, K1b und K1c können die notwendigen Umrechnungen durch Schiebeoperationen ausgeführt werden. Dazu empfiehlt es sich, die Quantisierungen so zu wählen, dass die Verhältnisse K1b / K1a, K1c / K1b, … Werte aus der Menge {21, 22, …, 2n} annehmen. Bei identisch gewählten Quantisierungen entfallen die Schritte 2 und/oder 4 vollständig.

Durch Intervallarithmetik mit den Schranken aimpl min und aimpl max kann vorab geprüft werden, ob die Zwischenergebnisse mit dem Wertebereich aimpl MIN und aimpl MAX der gewählten Darstellung des Operanden a ohne Überlaufbehandlung dargestellt werden können oder nicht. Durch Korrekturen der Parameter K1i und K0i können numerisch günstigere Intervalle vorgegeben werden, so dass die Genauigkeit der berechneten Ergebnisse höher ist.

Begrenzungen und Überlaufbehandlungen können vermieden werden, wenn die Zwischenrechnungen mit einer Darstellung größeren Wertebereichs ausgeführt werden.

Weitere Optimierungen sind durch eine Aufteilung in Online- und Offline-Berechnungen möglich. So können etwa die Divisionen in (5.34) und (5.35) offline berechnet werden. Optimierungen dieser Art wurden im letzten Beispiel zur Erleichterung des Verständnisses bewusst vernachlässigt.

5.4.2.8 Physikalische Modellebene und Implementierungsebene

Wie das letzte Beispiel zeigt, macht eine Unterscheidung zwischen der physikalischen und der Implementierungsebene für Algorithmen Sinn, da so physikalische Zusammenhänge und mikroprozessorspezifische Details der Implementierung, etwa die Wahl der Quantisierung, der Wortlänge und der Strategie für die Integerarithmetik getrennt betrachtet werden können.

Auf der physikalischen Ebene eines Modells kann zwischen wertkontinuierlichen, wertdiskreten und Booleschen Größen unterschieden werden:

Wertkontinuierliche Größen repräsentieren meist wertkontinuierliche, physikalische Signale – wie beispielsweise Temperaturen, Drehzahlen oder Drücke.

Wertdiskrete Größen repräsentieren natürliche Größen – wie die Anzahl der Zylinder in einem Motor oder die Anzahl der Gangstufen in einem Getriebe.

Boolesche Größen beschreiben Zustandspaare – wie etwa eine Schalterstellung, der ein Zustand des Paares {„Ein“, „Aus“}, {„Wahr“, „Falsch“}, {„1“, „0“} oder allgemein {TRUE, FALSE} zugeordnet werden kann.

Soll eine wertkontinuierliche Größe in Festpunktdarstellung implementiert werden, muss sie dazu diskretisiert werden. Dieser Aspekt der Wertediskretisierung gewinnt bei der Datenmodellierung deshalb häufig zentrale Bedeutung.

Das bedeutet, dass jedem physikalischen Wert Xphys genau ein diskreter Implementierungswert

Ximpl der Menge {X1, X2, X3, …, Xn} mit Ximpl min ≤ Ximpl ≤ Ximpl max

eindeutig zugeordnet werden muss.

Diese Abbildung wird in der Regel durch eine Umrechnungsformel und die Angabe von Minimal- und Maximalwerten auf physikalischer Modellebene oder Implementierungsebene beschrieben.

Während beim Design der Software-Komponenten die Transformation von der physikalischen Modellebene in die Implementierungsebene durchgeführt werden muss, ist beim Messen steuergeräteinterner Größen in späteren Entwicklungsphasen, aber auch in Produktion und Service die Umrechnung von Implementierungsgrößen in physikalische Einheiten notwendig.

5.4.2.9 Einige Hinweise zur Implementierung in Festpunktarithmetik

Entscheidend für die Güte des Resultats eines Algorithmus ist der relative Fehler. Wie in den letzten Abschnitten gezeigt, wird die numerische Genauigkeit durch Ganzzahldivisionen sowie durch Überlauf- und Unterlaufbehandlungen begrenzt. Für die Implementierung können davon eine Reihe von Hinweisen und Richtlinien abgeleitet werden:

Hinweise für Ganzzahldivisionen

Der relative Fehler von Ganzzahldivisionen ist groß. Ganzzahldivisionen sollten deshalb möglichst vermieden werden.

Divisionen durch 0 sind nicht definiert und müssen als Ausnahme behandelt werden. Eine Möglichkeit ist der Ausschluss über Begrenzungen oder Abfragen.

Divisionen durch 1 und −1 sind trivial und können mit einer ähnlichen Strategie vermieden werden.

Divisionen durch Werte aus der Menge {21, 22, …, 2n} können bei nicht vorzeichenbehafteten Größen effektiv durch Schiebeoperationen ausgeführt werden.

Können Divisionen nicht vermieden werden, so sollte möglichst am Ende eines Algorithmus dividiert werden, damit der relative Fehler erst spät in das Resultat eingeht.

Je größer das Ergebnis der Integerdivision, desto geringer ist der relative Fehler. Deshalb sollte der Zähler nach Möglichkeit wertmäßig wesentlich größer als der Nenner gewählt werden. Dies kann beispielsweise durch Vorgabe eines Offsets oder eine Umquantisierung mittels Schiebeoperation vor der eigentlichen Division erreicht werden. Nach der Division muss im Verlauf des Algorithmus der ursprüngliche Offset oder die ursprüngliche Quantisierung natürlich wieder hergestellt werden.

Beispiel:

Berechnung der Division c phys  = a phys  / b phys

Die Variablen aimpl und temp liegen in uint16-Darstellung vor; die Variablen bimpl und cimpl in uint8-Darstellung.

Die physikalischen Werte sind gegeben mit

aphys = 79, bphys = 5.

Der exakte Wert von cphys wäre 79 / 5 = 15,8.

Die Umrechnungsformeln sind gegeben mit

aimpl (aphys) = K1a · aphys + K0a = 1 · aphys + 0,(5.39)

bimpl (bphys) = K1b · bphys + K0b = 1 · bphys + 0,(5.40)

cimpl (cphys) = K1c · cphys + K0c = 1 · cphys + 0.(5.41)

Der Wertebereich ist gegeben mit

aimpl min = 0 und aimpl max = 255,

bimpl min = 2 und bimpl max = 10.

Für die Berechnung von cphys = aphys / bphys wird folgender Algorithmus gewählt:

Schritt 1: Schiebeoperation um 8 Stellen für aimpl, um den vollen 16-Bit-Wertebereich zu nutzen

aimpl = aimpl << 8 = aimpl · 28.

Für aphys = 79 erhält man

aimpl = 79 · 28 = 20 224.

Schritt 2: Durchführen der eigentlichen Ganzzahldivision

temp = aimpl / bimpl

Für bphys = 5 erhält man

temp = 20 224 / 5 = 4044.

Dies entspricht 15,7968… · 28.

Gegenüber der Integerdivision 79 / 5 = 15 kann durch die Umskalierung in der Größe temp eine wesentlich höhere Genauigkeit erreicht werden.

Schritt 3: Rückskalierung des Ergebnisses um 8 Stellen

Die Größe temp muss im weiteren Verlauf des Algorithmus wieder auf die Skalierung von cimpl gebracht werden:

cimpl = temp >> 8.

Dabei entsteht ein relativer Fehler und Genauigkeit geht verloren. Dieser Schritt sollte deshalb möglichst spät im Algorithmus durchgeführt werden. Weitere Rechenschritte sollten die genauere Zwischengröße temp verwenden.

Hinweise für Additionen, Subtraktionen und Multiplikationen

Für Additionen, Subtraktionen und Multiplikationen wird die Genauigkeit durch Überlauf- und Unterlaufbehandlungen begrenzt.

Es können verschiedene Strategien zur Über- und Unterlaufbehandlung gewählt werden. Möglich sind beispielsweise Umskalierung, Begrenzung, Erweiterung des Wertebereichs durch Typkonvertierung oder Zulassen des Überlaufs/Unterlaufs mit oder ohne Erkennung und Reaktion im Algorithmus.

Bei einer Umskalierung des Wertebereichs nimmt die relative Genauigkeit über den ganzen Wertebereich ab, auch wenn kein Über- oder Unterlauf auftritt.

Bei einer Begrenzung des Wertebereichs nimmt die relative Genauigkeit nur im Falle des Auftretens einer Über- oder Unterlaufsituation ab.

Über die Umrechnungsbeziehung von physikalischen Signalen in Implementierungsgrößen kann der Offset so eingestellt werden, dass die Berechnungen auf der Implementierungsebene überwiegend „in der Mitte“ des gewählten Wertebereichs stattfinden. Dies ermöglicht auch die prozessorinterne Darstellung mit geringerer Wortlänge. Dieser Vorteil schlägt sich besonders bei großen Datenstrukturen, wie offsetbehafteten Kennlinien und Kennfeldern, in geringerem Speicherbedarf nieder. Offsets führen u. U. aber zu zusätzlichen Umrechnungsoperationen bei der Verknüpfung verschiedener Signale. Von Kennlinien und Kennfeldern und einigen anderen Ausnahmen abgesehen, empfiehlt es sich daher meist, Offsets in Umrechnungsformeln möglichst zu vermeiden.

Multiplikationen und Divisionen mit Werten aus der Menge {21, 22, …, 2n} können effektiv durch Schiebeoperationen ausgeführt werden. Rechts-Schiebeoperationen sollten bei vorzeichenbehafteten Größen unter Umständen vermieden werden. Stattdessen sollte mit der normalen Division gearbeitet werden.

Hinweise zur Fehlerfortpflanzung

Selbst durch exakt ausgeführte Operationen, wie Additionen, Subtraktionen oder Multiplikationen, kann ein relativer Fehler der Eingangsgrößen rasch verstärkt werden.

In diesem Zusammenhang sollten insbesondere auch Begrenzungen, die etwa durch die Argumentübergabe bei Unterprogrammaufrufen implizit wirksam werden können, beachtet und ihr Einfluss auf Zwischenergebnisse abgeschätzt werden.

5.4.2.10 Einige Hinweise zur Implementierung in Gleitpunktarithmetik

Auch bei der Implementierung in Gleitpunktarithmetik muss beachtet werden, dass die Menge A der Maschinenzahlen für Gleitpunktzahlen endlich ist. Dies führt unvermeidlich zu Rundungsfehlern bei den arithmetischen Operationen. Genauso wie für die Festpunktarithmetik gelten auch hier die Assoziativ- und Distributivgesetze nicht, da die exakten arithmetischen Operationen durch Gleitpunktoperationen approximiert werden.

Obwohl nicht alle numerischen Probleme durch Gleitpunktarithmetik gelöst werden, bietet der größere numerische Wertebereich doch den Vorteil, dass die Einflüsse von numerischen Rundungsfehlern, Über- und Unterläufen wesentlich geringer sind und häufig vernachlässigt werden können. Die Skalierung von physikalischen Größen – eine häufige Fehlerquelle bei der Implementierung in Integerarithmetik – ist nicht notwendig.

Allerdings führt die höhere numerische Genauigkeit auch zu einer größeren Wortlänge und damit zu einem erhöhten Speicher- und Laufzeitbedarf. So kann etwa die Sicherung und Wiederherstellung von Gleitpunktdaten bei präemptiver Zuteilungsstrategie in Echtzeitbetriebssystemen zu beträchtlichen Laufzeiteinflüssen führen.

Für viele Anwendungen wird daher eine Lösung gewählt, bei der Festpunkt- und Gleitpunktarithmetik kombiniert werden. Das Bewusstsein und Verständnis der allgemeinen numerischen Methoden bleibt deshalb essentiell wichtig, um Probleme zu lösen wie [87]:

Konvertierung von Festpunktzahlen in Gleitpunktzahlen und umgekehrt.

Umgang mit „Division-durch-Null“-Bedingungen.

Fortpflanzung von Approximationsfehlern, die zum Beispiel durch Filter- und Integrationsalgorithmen entstehen können.

Fortpflanzung von Rundungsfehlern.

Hinweise für Vergleiche und Divisionen

Sind Vergleiche von Festpunktzahlen unkritisch, so sollten Vergleiche zweier Gleitpunktzahlen a und b auf Gleichheit in vielen Fällen vermieden werden. Stattdessen wird empfohlen, die Differenz delta = |a − b| gegenüber einer Schranke eps zu vergleichen, wobei auch die relative Genauigkeit berücksichtigt werden muss, etwa in der Form delta < |a · eps| oder delta < |b · eps|.

Divisionen durch 0 müssen durch Bedingungen oder Abfragen ausgeschlossen werden.

5.4.2.11 Modellierungs- und Implementierungsrichtlinien

Die Optimierungen für Seriensteuergeräte hängen zum einen von der Anwendung, zum anderen von der Hardware-Plattform ab. Deshalb ist eine enge Zusammenarbeit zwischen dem für die modellbasierte, physikalische Spezifikation verantwortlichen Funktionsentwickler und dem für das Design und die Implementierung zuständigen Software-Entwickler notwendig.

Eine wichtige Voraussetzung für zielführende Optimierungsmaßnahmen sind Modellierungs- und Implementierungsrichtlinien. Das Funktionsmodell muss die explizite Spezifikation aller software-relevanten Informationen ermöglichen, ohne dass das physikalische Verständnis unnötig erschwert wird. Ein Beispiel für Modellierrichtlinien sind die MSR-Standards [78], ein Beispiel für Implementierungsrichtlinien sind die MISRA-Richtlinien [88].

Durch eine Trennung von Spezifikation und Design wird auch eine später eventuell notwendige Portierung auf neue Hardware-Plattformen ermöglicht. Dazu müssen dann im Idealfall nur die hardware-spezifischen Design-Entscheidungen angepasst werden.

Die Konsistenz von Spezifikation und Design stellt ein grundsätzliches Problem bei der Funktionsentwicklung dar. Verschiedene Werkzeuge zur Daten- und Verhaltensmodellierung unterstützen diese Entwurfsschritte. Werkzeuge ermöglichen auch die Festlegung von Richtlinien in Form von Basisblockbibliotheken, Skalierungsempfehlungen und Namensbezeichnungen für Variablen sowie von Formelbibliotheken, Ablageschemata und Interpolationsroutinen für Kennlinien und Kennfelder.

5.4.3 Design und Implementierung der Software-Architektur

Auch die Software-Architektur muss unter Berücksichtigung der Merkmale des ausgewählten Mikrocontrollers und des Steuergeräts konkretisiert werden, so dass alle Anforderungen, die an das Seriensteuergerät gestellt werden, berücksichtigt werden. Die Architektur orientiert sich dabei zunehmend an AUTOSAR [3].

5.4.3.1 Basis- und Anwendungs-Software

Die Unterscheidung zwischen zwei Software-Schichten, der Basis- und der Anwendungs-Software, ist in AUTOSAR definiert. Bei der Spezifikation in Abschn. 5.3 wurde eine Architektur für die Software-Funktionen festgelegt. Die dort spezifizierten Software-Komponenten, die zur Darstellung einer Software-Funktion notwendig sind, können in der Design-Phase als Komponenten der Anwendungs-Software in die in Kap.  1 und  2 eingeführte Software-Architektur integriert werden. Abb. 5.66 zeigt beispielhaft einen Architekturentwurf, bei dem die Software-Funktionen durch Module realisiert wurden und über die AUTOSAR RTE untereinander oder mit Software-Komponenten auf anderen Steuergeräten kommunizieren. Für die Module wurde die in Abb. 5.24 eingeführte Darstellung verwendet.
Abb. 5.66

Software-Architektur mit Verwendung von standardisierten Software-Komponenten

In den folgenden Abschnitten werden Methoden zur Implementierung und Konfiguration von Software-Komponenten behandelt – insbesondere solche Methoden, die durch Werkzeuge automatisiert unterstützt werden können. Die dadurch mögliche Gewährleistung der Übereinstimmung zwischen Spezifikation und Implementierung einer Software-Komponente trägt entscheidend zu einer Verbesserung der Software-Qualität bei.

5.4.3.2 Standardisierung von Software-Komponenten der Basis-Software

Die Standardisierung der Basis-Software bietet viele Vorteile. Die Standardisierung ist möglich, da die Basis-Software-Komponenten aus Sicht eines Fahrzeugherstellers keine direkte Wettbewerbsrelevanz besitzen. Die Standardisierung erleichtert die Integration der von verschiedenen Lieferanten entwickelten Steuergeräte im Fahrzeug. Die Qualitätssicherung für diese Software-Komponenten kann zentral durchgeführt werden. Bereits standardisierte Software-Komponenten sind beispielsweise

Betriebssysteme nach AUTOSAR [3],

Kommunikation und Netzwerkmanagement für CAN, LIN, FlexRay und Ethernet nach AUTOSAR [3],

EEPROM/Flash Speichermanagement nach AUTOSAR [3],

Diagnoseprotokolle nach ISO [24, 25] und Fehlerspeichermanagement nach AUTOSAR [3],

Interpolations-,CRC-,Krypto- und Watchdogroutinen nach AUTOSAR [3],

Input Capture Unit- (ICU), PWM-, Analog Digital Converter- (ADC), Digital Input Output- (DIO), General Purpose Timer (GPT) Treiber nach AUTOSAR [3].

Die Anpassung dieser Software-Komponenten an verschiedene Anwendungen erfolgt durch Konfigurationsparameter.

Viele Vorteile bietet auch die Standardisierung der Flash-Programmierung einschließlich der notwendigen Software-Komponenten und der erforderlichen Sicherheitsmechanismen zum Schutz vor unbefugtem Zugriff. In diesem Bereich werden erhebliche Anstrengungen zur Standardisierung unternommen. Nach Einführung eines entsprechenden Konzepts wären alle Software-Komponenten, die zur Unterstützung der Offboard-Schnittstellen eines Seriensteuergeräts für

Diagnose,

Software-Parametrierung,

Software-Update,

in der Produktions- und Servicephase notwendig sind, standardisiert.

Während der Entwicklung müssen oft weitere Schnittstellen unterstützt werden, etwa für das Messen und Kalibrieren oder auch für Bypass-Anwendungen. Protokolle für Mess- und Kalibrieranwendungen sind durch ASAM [18] standardisiert, beispielsweise das CAN Calibration Protocol, kurz CCP oder das Extended Calibration Protocol, kurz XCP. Die dafür notwendigen Software-Komponenten müssen nur während der Entwicklungsphase in die Software-Architektur integriert werden. Sie entfallen wieder in der Produktions- und Servicephase.

Auch Komponenten der Anwendungs-Software bieten Potential zur Standardisierung, etwa die Elemente einer steuerungs- und regelungstechnischen System-Bibliothek, wie sie im Rahmen von AUTOSAR [3] oder ASAM [3, 18] festgelegt sind.

5.4.3.3 Konfiguration von standardisierten Software-Komponenten

Über Konfigurationsparameter können standardisierte Software-Komponenten an eine spezifische Anwendung angepasst werden. Dieser Konfigurationsschritt kann durch Konfigurationswerkzeuge automatisiert werden. Beispiele sind die Konfiguration des Echtzeitbetriebssystems oder auch die Konfiguration der Kommunikations- und Diagnose-Software-Komponenten der Basis-Software.

In Abb. 5.67 ist die automatisierte Generierung der Konfiguration für die Software-Komponenten zur Kommunikation im Steuergerätenetzwerk dargestellt. Die Kommunikationsmatrix des Steuergerätenetzwerks wird dazu in einer zentralen Datenbank abgelegt. Editoren ermöglichen die Bearbeitung der kommunikationsrelevanten Parameter durch verschiedene Sichtweisen auf die Kommunikationsmatrix – wie die Signalsicht, die Nachrichtensicht, die Bussicht, die Teilnehmersicht oder auch die Funktionssicht. Export-Schnittstellen unterstützen verschiedene Austauschformate – etwa in Form von Beschreibungsformaten für Entwicklungs- oder Messwerkzeuge – zur Verteilung der Kommunikationsmatrix an die verschiedenen Entwicklungspartner. Über Import-Schnittstellen können Teilumfänge zusammengeführt und auf Konsistenz geprüft werden. Die automatisierte Übernahme der Daten in Lasten- und Pflichtenhefte ist über eine Dokumentationsschnittstelle möglich.
Abb. 5.67

Automatisierte Konfiguration der Kommunikationsschicht

Dadurch kann die Konsistenz zwischen Implementierung, Dokumentation und Beschreibungsformaten für alle relevanten Daten zur Beschreibung der Kommunikation im Steuergerätenetzwerk sichergestellt werden. Übertragungsfehler, etwa durch die manuelle Konfiguration von Software-Komponenten, können vermieden werden.

Ähnliche Anforderungen bestehen im Bereich der Diagnosedaten (Abb. 5.68). Die zentrale Verwaltung der Diagnosedaten in einer Datenbank ermöglicht die automatisierte Konfiguration der Software-Komponenten für die Diagnose und gewährleistet beispielsweise die Konsistenz zwischen Fehlerspeicherbeschreibung für den Diagnosetester, etwa im Format ASAM-MCD 2D, und der Implementierung im Steuergerät. Eine weitere Aufgabe, die automatisiert werden kann, ist die Integration der Diagnosedaten verschiedener Steuergeräte zu einem Datenstand für das Fahrzeug und deren Prüfung auf Konsistenz.
Abb. 5.68

Automatisierte Konfiguration der Diagnoseschicht und Generierung der Diagnosebeschreibung

5.4.4 Design und Implementierung des Datenmodells

In der Produktion und im Service von Fahrzeugen führen länder- und kundenspezifische Ausstattungsoptionen zu einer Vielzahl von Fahrzeugvarianten, die beherrscht werden müssen. Diese Fahrzeugvarianten führen auch zu Software-Varianten für die Steuergeräte.

Verfahren zur Reduzierung der in Produktion und Service benötigten Vielfalt der Steuergeräte-Hardware-Typen sind zur Beherrschung der Varianten notwendig. Verfahren, die durch eine Variantenbildung des Datenstandes möglich sind, werden in diesem Abschnitt dargestellt.

Bei Verfahren, die in der Produktion eingesetzt werden, stellen die Anforderungen an die zeitliche Dauer zum Einstellen einer Programm- oder Datenstandsvariante eines Steuergeräts eine wichtige Randbedingung dar. Die maximal zulässige Zeitdauer wird durch die Taktzeit der Produktion vorgegeben. Die Verfahren können vor oder nach dem Einbau des Steuergeräts ins Fahrzeug eingesetzt werden.

Bei Verfahren, die im Service verwendet werden, verlangt die weltweite Ersatzteilelogistik nach einer möglichst geringen Anzahl verschiedener Steuergeräte-Hardware-Typen. Programm- und Datenvarianten können wesentlich kostengünstiger weltweit verteilt werden als Hardware-Komponenten. Ein Ausbau des Steuergeräts aus dem Fahrzeug im Service führt zu hohen Kosten. Deshalb ist ein Konzept zum Einstellen, Ändern oder Laden von Programm- und Datenvarianten vorteilhaft, bei dem ein Steuergeräteaustausch oder -ausbau nicht notwendig ist.

Auch die Fahrzeugbenutzer, etwa der Fahrer oder die weiteren Insassen, möchten selbst zunehmend ein persönliches Profil für viele Software-Funktionen über eine Benutzerschnittstelle vorgeben und abspeichern. Dazu gehören beispielsweise Einstellungen von Sitz-, Lenkrad- und Spiegelposition sowie Einstellungen der Radiosender, der Heizung und Klimaanlage. Diese personenbezogenen Parameter können beispielsweise über fahrerspezifische Kennungen, die im Schlüssel abgelegt werden, verwaltet werden.

Alle diese Anforderungen müssen beim Design und der Implementierung von Daten berücksichtigt werden.

In den Abschn. 5.4.4.2 und 5.4.4.3 werden zwei verschiedene technische Verfahren zur Einstellung von Datenvarianten ausführlicher dargestellt:

Die Einstellung durch Flash-Programmierung und

Die Einstellung über Konfigurationsparameter.

5.4.4.1 Festlegung des Speichersegments

Neben der Art der Darstellung im Prozessor muss für jedes Datum festgelegt werden, in welchem Speichersegment des Mikrocontrollers es abgelegt werden soll.

Es muss also definiert werden, ob eine Größe im flüchtigen Schreib-/Lesespeicher – beispielsweise im RAM –, im nichtflüchtigen Lesespeicher – etwa im ROM, PROM, EPROM oder Flash –, oder in einem nichtflüchtigen Schreib-/Lesespeicher – wie dem EEPROM oder dem batteriegepufferten RAM – gespeichert werden soll.

5.4.4.2 Einstellung von Datenvarianten durch Flash-Programmierung

Dieses Verfahren kann bei Steuergeräten mit Flash-Technologie eingesetzt werden. Hierzu kann der komplette Flash-Bereich – mit dem Programm- und dem variantenspezifischen Datenstand – oder nur ein Teilbereich des Flash-Speichers – etwa nur der Datenstand – beispielsweise am Ende der Fahrzeugproduktion programmiert werden. Davon ist die Bezeichnung Bandendeprogrammierung (engl. End of Line Programming) abgeleitet.

Dieses Verfahren wird zunehmend auch für Software-Updates für Fahrzeuge im Service eingesetzt. Im Service erfolgt die Programmierung zunehmend über die zentrale Diagnoseschnittstelle des Fahrzeugs, so dass das Steuergerät dazu nicht aus dem Fahrzeug ausgebaut werden muss. Auf das Verfahren zur Flash-Programmierung im Service wird in Abschn.  6.3 ausführlich eingegangen.

Zur Verkürzung der notwendigen Zeitdauer für die Flash-Programmierung werden Programm- und Datenstand häufig getrennt programmiert. In der Produktion kann dadurch beispielsweise der variantenunabhängige Programmstand bereits bei der Steuergeräteherstellung programmiert werden und nur der fahrzeugspezifische, variantenabhängige Datenstand wird am Ende der Fahrzeugproduktion programmiert.

Am Beispiel einer Kennlinie ist in Abb. 5.69 das Variantenmanagement durch Flash-Programmierung dargestellt.
Abb. 5.69

Datenstandsprogrammierung am Beispiel einer Kennlinie

5.4.4.3 Einstellung von Datenvarianten durch Konfigurationsparameter

Eine zweite Lösung ist die parallele Ablage unterschiedlicher Datenvarianten im nichtflüchtigen Festwertspeicher des Steuergeräts. Durch eine Parametrierung am Bandende wird nur eine der Datenvarianten über einen dafür vorgesehenen Software-Schalter oder Software-Parameter ausgewählt. Dieser Software-Parameter wird beispielsweise im EEPROM abgelegt. Da dadurch aus mehreren möglichen Versionen von Datenständen eine Konfiguration nach Abb.  3.12 erst am Bandende festgelegt wird, wird dieses Verfahren auch als Bandendekonfiguration (engl. End of Line Configuration) bezeichnet.

Alternativ kann diese Konfiguration auch erst beim Starten des Fahrzeugs festgelegt werden. In diesem Fall werden die Konfigurationsinformationen für alle Steuergeräte des Fahrzeugs mit dem beschriebenen Verfahren in einem zentralen Steuergerät abgelegt. Dieses Steuergerät sendet diese Information – beispielsweise nach Einschalten der Zündung – über eine Nachricht an alle betroffenen Teilnehmer im Netzwerk, die daraufhin die entsprechende Konfiguration auswählen.

Auch dieses Verfahren wird für die Software-Konfiguration für Fahrzeuge im Feld über die zentrale Fahrzeugdiagnoseschnittstelle verwendet. Es eignet sich auch zur Parametrierung von Funktionen durch den Benutzer selbst.

Abb. 5.70 zeigt das Konfigurationsmanagement durch Software-Parameter am Beispiel einer Kennlinie. Auch Kombinationen der verschiedenen Verfahren sind denkbar.
Abb. 5.70

Datenstandsparametrierung am Beispiel einer Kennlinie

5.4.4.4 Generierung von Datenstrukturen und Beschreibungsdateien

Durch die zentrale Verwaltung und die automatisierte Generierung von Datenstrukturen und Beschreibungsdateien für die Mess- und Kalibrierdaten kann ein weiterer Entwicklungsschritt automatisiert werden (Abb. 5.71).
Abb. 5.71

Automatisierte Generierung von Datenstrukturen und der Datenbeschreibung. (Visual Information Technologies GmbH [89])

In einer Datenbank werden die Mess- und Kalibrierdaten eines Mikrocontrollers zentral abgelegt. Dabei werden die physikalische Spezifikation, die Design- und Implementierungsentscheidungen für alle Daten sowie die Festlegung der Abbildungsvorschrift, etwa durch Umrechnungsformeln, zusammen verwaltet. Aus der Datenbank können dann einerseits Datenstrukturen für eine Entwicklungsumgebung, beispielsweise in der Sprache C, generiert werden. Andererseits stehen nach Einlesen der Adressinformation auch alle Informationen zur Verfügung, um eine Beschreibungsdatei im Format ASAM-MCD 2MC zu erzeugen, die von Mess-, Kalibrier- und Diagnosewerkzeugen verwendet wird. Dadurch wird die Konsistenz zwischen Datenbeschreibung für Mess- und Kalibrierwerkzeuge und der Implementierung der Daten gewährleistet.

5.4.5 Design und Implementierung des Verhaltensmodells

Die Konsistenz zwischen Spezifikation, Dokumentation und der vollständigen Implementierung von Software-Komponenten kann durch den Einsatz von Codegenerierungswerkzeugen gewährleistet werden (Abb. 5.72).
Abb. 5.72

Automatisierte Generierung von Software-Komponenten und des Programm- und Datenstands. (ETAS GmbH [74])

Die modellbasierte Spezifikation, die auch für die Simulation oder das Rapid-Prototyping verwendet wird, wird als Basis für die automatisierte Codegenerierung genutzt. Dazu müssen für die auf der physikalischen Ebene spezifizierten Daten und für die Algorithmen die notwendigen Designentscheidungen getroffen werden. Für die Daten sind die Festlegungen, wie in Abb. 5.73 dargestellt, notwendig. Für die Algorithmen ist die Festlegung der Darstellungsform für Argumente und Rückgabewerte sowie die Zuordnung zu den Speichersegmenten des Steuergeräts erforderlich. Bei Implementierung in Integerarithmetik müssen weitere Festlegungen, etwa bezüglich der Strategie zur Behandlung von Rundungsfehlern, Über- und Unterlaufsituationen wie in Abschn. 5.4.2 dargestellt, getroffen werden. Diese Definitionen werden durch ein Designwerkzeug unterstützt.
Abb. 5.73

Designentscheidungen für die Daten und Schnittstellen der Klasse „Integrator“

Mit diesen Informationen ist die automatisierte Generierung von vollständigen Software-Komponenten, z. B. in Quellcode, möglich, die dann in einer konventionellen Software-Entwicklungsumgebung weiterverwendet und zu einem Programm- und Datenstand des Mikrocontrollers integriert werden können. Diese Vorgehensweise wird daher auch als „Methode zusätzlicher Programmierer “ bezeichnet (Abb. 5.72).

Kann zusätzlich auch die Software-Architektur beschrieben werden und können die Komponenten der Basis-Software integriert und konfiguriert werden, so ist mit Integration eines Compiler Tool Sets für den jeweiligen Mikrocontroller auch die Generierung eines vollständigen Programm- und Datenstandes möglich (Abb. 5.72). Diese Vorgehensweise wird deshalb als „Methode Integrationsplattform “ bezeichnet.

Beispiel

Design und Implementierung der Klasse „Integrator

Die in Abb. 5.27 spezifizierte Klasse „Integrator“ soll implementiert werden. Dazu werden die folgenden Designentscheidungen für die Daten getroffen.

Eine mögliche Implementierung in der Sprache C der Methode „compute()“ in Festpunktarithmetik ist in Abb. 5.74 dargestellt. Für die Algorithmen werden dabei zusätzliche Designentscheidungen berücksichtigt, etwa in Bezug auf die Behandlung von Über- und Unterlaufsituationen.
Abb. 5.74

Implementierung der Methode „compute()“ der Klasse „Integrator“ als Funktion in der Sprache C

5.5 Integration und Test von Software-Funktionen

In diesem Abschnitt werden Verifikations- und Validierungsmethoden behandelt, die in der Integrations- und Testphase für Software-Funktionen eingesetzt werden. Wegen der unternehmensübergreifenden Integrations- und Testschritte in der Automobilelektronikentwicklung spielen Verfahren, bei denen nicht vorhandene reale Komponenten durch Modellierung und Simulation virtuell nachgebildet werden, eine wichtige Rolle.

Der Aufbau dieses Abschnitts orientiert sich an den folgenden Integrations- und Testumgebungen:

Simulationsumgebungen ,

Laborfahrzeuge und Prüfstände ,

Experimentier-, Prototyp- und Serienfahrzeuge .

Die Synchronisation der verschiedenen Verifikations- und Validierungsschritte zwischen allen Entwicklungspartnern und Entwicklungsumgebungen, etwa die Abstimmung der Komponentenmodelle und Testfälle, muss bereits bei der Projektplanung berücksichtigt werden.

Einige Validierungsverfahren, wie Rapid-Prototyping für spezifizierte Software-Funktionen, die bereits in der Spezifikationsphase eingesetzt werden können, wurden in Abschn. 5.3 behandelt. Diese Verfahren können mit den in diesem Abschnitt beschriebenen Verfahren kombiniert werden. Hier stehen Verfahren im Vordergrund, mit denen implementierte Software-Funktionen frühzeitig in einer teilweise virtuellen, teilweise realen Umgebung verifiziert und validiert werden können. Dabei werden verschiedene typische Zwischenschritte herausgegriffen. Ausgangs- und Zielsituation sind in Abb. 5.75 dargestellt.
Abb. 5.75

Ausgangs- und Zielsituation für die Integration und den Test von Software und Systemen

Ein Überblick über die verschiedenen Zwischenschritte bei der Integration zeigt Abb. 5.76. Die Modelle der logischen Systemarchitektur können als Grundlage für die Nachbildung nicht vorhandener Systemkomponenten dienen. Anhand beispielhaft ausgewählter Ausschnitte aus Abb. 5.76 werden in den folgenden Abschnitten verbreitete Integrations-, Verifikations- und Validierungsmethoden dargestellt.
Abb. 5.76

Zwischenschritte bei der Integration und beim Test von Software und Systemen

Der frühestmögliche Validierungsschritt ist die Simulation des Modells einer Steuerungs- und Regelungsfunktion zusammen mit einem Modell des zu steuernden oder zu regelnden Systems. Im Simulationsmodell können die Komponenten Sollwertgeber, Steuerung/Regler oder Überwachung, Aktuatoren, Strecke und Sensoren nachgebildet werden. Für viele Fahrzeugfunktionen interessieren bei der Simulation auch der Einfluss des Fahrers und der Umwelt auf das Systemverhalten. Fahrer und Umwelt können dazu als weitere Komponenten berücksichtigt werden, wie in Abb. 5.44 dargestellt.

Da alle Komponenten durch virtuelle Modelle repräsentiert werden, werden keine Echtzeitanforderungen an geeignete Modellbildungs- oder Simulationsverfahren gestellt. An dieser Stelle soll nicht weiter auf die Modellbildung für Fahrzeugkomponenten eingegangen werden. Eine ausführliche Darstellung findet sich z. B. in [35].

5.5.1 Software-in-the-Loop-Simulationen

Werden realisierte Software-Komponenten in einer simulierten Umgebung ausgeführt, so wird diese Vorgehensweise auch als Software-in-the-Loop-Simulation, kurz SiL-Simulation , bezeichnet.

Mit Blick auf eine Regelungsfunktion ist diese Bezeichnung schlüssig. Eine Software-Funktion, durch die beispielsweise eine Regelungsfunktion in der Anwendungs-Software realisiert wird, kann als eine Komponente im Regelkreis (engl. Loop) modelliert und ausgeführt werden, wie in Abb. 5.77 beispielhaft dargestellt.
Abb. 5.77

Software-in-the-Loop-Simulation

Diese Vorgehensweise ist jedoch auch für eine ganze Reihe weiterer Anwendungsfälle vorteilhaft, wo kein Regelkreis besteht. So können zum Beispiel auch Software-Komponenten durch die Steuerungs- oder Überwachungsfunktionen realisiert werden, oder Software-Komponenten der Basis-Software, etwa die Kommunikationsschicht, auf diese Art und Weise verifiziert und validiert werden.

Gegenüber Abb. 5.44 ändert sich in diesem Fall der Aufbau des Simulationsmodells nicht wesentlich. Jedoch müssen die Modellkomponenten viel konkreter festgelegt werden. So muss die Modellbildung für das Steuergerät so weit konkretisiert werden, dass die Analog-Digital-Wandlung und die Digital-Analog-Wandlung der Signale sowie das „Echtzeitverhalten“ möglichst genau berücksichtigt werden. Erst dann können, wie in Abb. 5.77 dargestellt, realisierte Software-Komponenten in diese Simulationsumgebung integriert und ausgeführt werden. Die implementierte Software-Komponente als Prüfling wird dann in einer virtuellen Umgebung auf einer Entwicklungs- und Simulationsplattform, z. B. auf einem PC, ausgeführt. Echtzeitanforderungen an die Ausführung der Simulation werden dabei nicht gestellt.

Mit Software-in-the-Loop-Simulationen können eine ganze Reihe dynamischer Software-Tests frühzeitig ohne reales Steuergerät durchgeführt werden, beispielsweise Komponententests mit Code-Abdeckungsanalysen (engl. Code Coverage Analysis).

5.5.2 Laborfahrzeuge und Prüfstände

Eine ganze Klasse von Methoden und Werkzeugen, die zur Verifikation und Validierung eingesetzt werden, sobald Hardware und Software eines Steuergeräts zur Verfügung stehen, werden unter den Bezeichnungen Laborfahrzeuge und Prüfstände zusammengefasst. Ziel kann dabei, wie in Abb. 5.78 dargestellt, der Betrieb eines realen Steuergeräts in einer teilweise virtuellen, teilweise realen Umgebung sein. Gegenüber den oben dargestellten Simulationsverfahren, müssen deshalb Echtzeitanforderungen bei der Modellbildung und Ausführung der Simulation der Umgebungskomponenten berücksichtigt werden.
Abb. 5.78

Betrieb des Steuergeräts in einer virtuellen Umgebung. (ETAS GmbH [90])

Steht die Verifikation und Validierung von Regelungsfunktionen im Vordergrund, so kann das Steuergerät, wie in Abb. 5.78, als Komponente im Regelkreis betrachtet werden. Aus diesem Grund wird diese Vorgehensweise häufig auch als Hardware-in-the-Loop-Simulation, kurz HiL-Simulation, bezeichnet. Ähnlich wie die SiL-Simulation ist diese Vorgehensweise jedoch nicht auf Regelungsfunktionen beschränkt, sondern kann für eine ganze Reihe weiterer Anwendungsgebiete eingesetzt werden, von denen nachfolgend einige beispielhaft herausgegriffen werden. Diese verschiedenen Verfahren werden unter der Bezeichnung Laborfahrzeuge zusammengefasst.

Mit Blick auf die Software eines Steuergeräts stehen verschiedene Aspekte im Vordergrund, beispielsweise die Verifikation und Validierung des Echtzeitverhaltens, des Onboard- und Offboard-Kommunikationsverhaltens im Netzwerk oder auch die Überprüfung der Steuerungs-/Regelungs- und Überwachungsfunktionen.

5.5.2.1 Prüfumgebung für ein Steuergerät

Das Laborfahrzeug kann als ein Software- und Hardware-Prüfstand für ein Steuergerät verwendet werden (Abb. 5.78). Statische und dynamische Vorgänge der Umgebung des Steuergeräts werden in Echtzeit simuliert.

Die Eingangssignale des Steuergeräts werden durch ein Umgebungsmodell nachgebildet und das Steuergerät damit stimuliert. Eingänge des Steuergeräts sind, wie in Abb. 5.78 dargestellt, die Signalvektoren W und R. Der Ausgangssignalvektor U wird als Eingangsgröße für die Simulation der Umgebung im Laborfahrzeug verwendet.

Abb. 5.79 verdeutlicht den Aufbau des Laborfahrzeugs LABCAR. Das Umgebungsmodell wird übersetzt und auf einem Echtzeitrechnersystem ausgeführt. Dort erfolgt neben der Ausführung der Modelle die Ausgabe der Signalvektoren W und R des Steuergeräts sowie die Erfassung des Signalvektors U. Über einen Bedienrechner können die Experimente interaktiv vom Benutzer oder automatisiert gesteuert werden. Modelländerungen an den Umgebungskomponenten werden durch Modellierwerkzeuge unterstützt.
Abb. 5.79

Aufbau des Laborfahrzeugs LABCAR. (ETAS GmbH [90])

Beispiel

Prüfumgebung für die Steuerungs- und Regelungsfunktionen eines Steuergeräts

Eine typische Anwendung ist die Prüfung des dynamischen Verhaltens der Steuerungs- und Regelungsfunktionen eines Steuergeräts. Dies schließt neben den Software-Funktionen in der Anwendungs-Software auch die Signalverarbeitung in der Basis-Software sowie in der Hardware des Steuergeräts ein.

Die beliebige Vorgabe der Eingangssignale des Steuergeräts ermöglicht große Freiheitsgrade bei der Durchführung von Experimenten:

Die Vorgabe der Umgebungsbedingungen für das Steuergerät, beispielsweise Temperatur, Luftdruck oder Luftfeuchtigkeit über die beliebige Stimulation der Eingangssignale ermöglicht die einfache Prüfung der Software-Funktionen unter extremen Bedingungen.

Extreme Fahrsituationen können ohne Gefährdung von Testfahrern oder Prototypenfahrzeugen nachgestellt werden.

Alterungs- und Ausfallsituationen an Sollwertgebern, Sensoren, Aktuatoren oder Kabelverbindungen können beliebig vorgegeben werden. Damit können z. B. adaptive Regelungsfunktionen durch Vorgabe von Alterungseffekten bei Signalen getestet werden.

Überwachungsfunktionen können durch Vorgabe unplausibler Signale systematisch geprüft werden.

Bauteiletoleranzen beispielsweise in Sollwertgebern, Sensoren und Aktuatoren können beliebig vorgegeben werden und ihre Auswirkungen auf die Robustheit von Steuerungs- und Regelungsfunktionen können überprüft werden.

Gegenüber Tests an Prüfständen oder im Fahrzeug können die Betriebspunkte ohne Einschränkungen beliebig vorgegeben werden, beispielsweise bei einem Motor im vollständigen Drehzahl-Last-Bereich.

Alle Prüfungen sind reproduzierbar und können automatisiert ausgeführt werden. Weitere Hardware-Komponenten, Aggregate oder Fahrzeuge sind dazu nicht notwendig.

Bei einem Aufbau des Laborfahrzeugs wie in Abb. 5.78 wird das Steuergerät als „Black Box“ betrachtet. Das funktionale Verhalten des Steuergeräts kann nur anhand seiner Ein- und Ausgangssignale bewertet werden. Für einfache Steuergerätefunktionen reicht diese Vorgehensweise zwar aus, zur Prüfung komplexerer Funktionen ist aber die Integration eines Messverfahrens für steuergeräteinterne Zwischengrößen erforderlich.

5.5.2.2 Inbetriebnahme und Prüfumgebung für Steuergerät, Sollwertgeber, Sensoren und Aktuatoren

Das im letzten Abschnitt dargestellte Verfahren kann auch auf die Prüfung der Sollwertgeber, Sensoren und Aktuatoren eines Steuergeräts ausgeweitet werden. Dazu werden die realen Sollwertgeber, Sensoren und Aktuatoren in den „Regelkreis“ eingebaut und gleichfalls als Prüflinge betrachtet (Abb. 5.80).
Abb. 5.80

Betrieb von Steuergerät, Sollwertgebern, Sensoren und Aktuatoren in virtueller Umgebung. (ETAS GmbH [90])

Die Modellbildung im Laborfahrzeug beschränkt sich dann auf Modelle der Strecke, des Fahrers und der Umwelt. Modelle für die Sollwertgeber, Sensoren und Aktuatoren sind nicht mehr notwendig. Das Laborfahrzeug muss in diesem Fall die Ausgangsgrößen W * und X sowie die Eingangsgrößen Y unterstützen und der Hardware-Aufbau entsprechend angepasst werden.

Auch Kombinationen zwischen simulierten und realen Aktuator- und Sensorkomponenten sind möglich.

Beispiel

Prüfumgebung für Steuerungs-/Regelungs- und Überwachungssysteme

Gegenüber dem vorigen Beispiel können mit diesem Aufbau komplette elektronische Steuerungs-/Regelungs- und Überwachungssysteme geprüft werden. Zur Prüfung der Sollwertgeber, Aktuatoren und Sensoren ist die Messung von verschiedensten Signalen in diesen Komponenten notwendig. Diese Signale werden meist durch eine zusätzliche Sensorik – die so genannte Instrumentierung – zum Beispiel an den Sensoren und Aktuatoren eines Fahrzeugsystems aufgenommen. Ebenso wird die Erfassung steuergeräteinterner Zwischengrößen als Instrumentierung des Steuergeräts bezeichnet.

Dazu kann eine Instrumentierung dieser Komponenten und des Steuergeräts mit einem Mess-, Kalibrier- und Diagnosesystem in das Laborfahrzeug integriert werden. Der Zugriff auf das Steuergerät kann über verschiedene Offboard-Schnittstellen erfolgen, etwa über die Offboard-Diagnoseschnittstelle.

Die darstellbaren Testfälle gehen an einigen Stellen über die Testsituationen des letzten Beispiels hinaus. Jedoch bestehen an anderen Stellen gegenüber der obigen Situation auch Einschränkungen, etwa bezüglich der Vorgabe von Alterungseffekten in Sensoren oder der Vorgabe von Extrem- und Fehlersituationen.

5.5.2.3 Inbetriebnahme und Prüfumgebung für ein Steuergerätenetzwerk

Sind die zu prüfenden Funktionen durch ein verteiltes und vernetztes System realisiert, dann ist die Erweiterung des Verfahrens auf die Prüfung mehrerer Steuergeräte erforderlich. Die Instrumentierung muss auf mehrere Steuergeräte erweitert werden (Abb. 5.81).
Abb. 5.81

Betrieb von mehreren Steuergeräten in virtueller Umgebung. (ETAS GmbH [90])

Häufig werden die Tests in Stufen durchgeführt. So können z. B. zunächst die Kommunikation zwischen den Steuergeräten über den Bus und die relevanten Komponenten der Basis-Software geprüft werden. Erst in einem weiteren Schritt werden die Komponenten der Anwendungs-Software getestet (Abb. 5.66).

In beiden Fällen können nicht vorhandene Steuergeräte durch simulierte Steuergeräte ersetzt werden, die dann Komponenten des Umgebungsmodells sind, das auf dem Echtzeitrechnersystem ausgeführt wird. Das Echtzeitrechnersystem benötigt dazu eine Schnittstelle zum Kommunikationssystem, dem Bus.

Die virtuelle Nachbildung des Kommunikationsverhaltens von Steuergeräten und die Kopplung zu einem realisierten Teilsystem des Netzwerks zur Prüfung der Kommunikation im Steuergerätenetzwerk wird auch als Restbussimulation bezeichnet [91]. Ein Anwendungsbeispiel ist in Abb. 5.82 dargestellt.
Abb. 5.82

Betrieb von realen und virtuellen Steuergeräten in virtueller Umgebung. (ETAS GmbH [90], Kühner et al. [91])

5.5.2.4 Prüfstand

Der Übergang von Laborfahrzeugen zu Prüfständen ist fließend. Reichen elektrische Signale zum Betrieb der Aktuatoren nicht aus, beispielsweise bei elektrohydraulischen Aktuatoren, dann wird eine dafür geeignete Testumgebung im allgemeinen als Hydraulikprüfstand bezeichnet.

Gegenüber Laborfahrzeugen werden also weitere, reale Komponenten des Gesamtsystems, beispielsweise der Strecke wie in Abb. 5.83 dargestellt, als Prüfling in die Prüfumgebung integriert. Auch die reale Vorgabe von Zustandsgrößen der Umwelt, beispielsweise der Umgebungstemperatur in Kälte- oder Wärmeprüfständen, ist möglich. Ähnliches gilt für die Vorgabe von Sollwerten durch einen realen Fahrer, beispielsweise in Rollenprüfständen.
Abb. 5.83

Betrieb eines Steuergeräts am Prüfstand

Nicht vorhandene reale Komponenten werden virtuell nachgebildet, etwa durch ein Fahrer- oder Umweltmodell, die ein dynamisches Belastungsprofil vorgeben. Diese virtuellen Komponenten können durchgängig bei Laborfahrzeugen und Prüfständen verwendet werden. Zur Nachbildung wird ein Echtzeitrechnersystem, beispielsweise ein Laborfahrzeug, in den Prüfstand integriert (Abb. 5.83).

Beispiel

Motorprüfstand

In dem in Abb. 5.83 dargestellten Motorprüfstand werden Steuergerät, Aktuatoren, Sollwertgeber, Sensoren und Motor als Prüflinge betrachtet. Die übrigen Fahrzeugkomponenten, Umweltbedingungen und Fahrprofile werden teilweise real und teilweise virtuell nachgebildet. Die Instrumentierung schließt jetzt auch den Motor ein.

5.5.3 Experimental-, Prototypen- und Serienfahrzeuge

Die Integration, Verifikation und Validierung elektronischer Systeme im realen Fahrzeug erfordert eine Instrumentierung der beteiligten Systemkomponenten des Fahrzeugs. Die Instrumentierung wird dabei auch häufig auf die Umwelt und den Fahrer ausgedehnt. Neben einem Mess- und Diagnosesystem ist dazu häufig auch ein Kalibriersystem für die Abstimmung steuergeräteinterner Parameter, wie in Abb. 5.84 dargestellt, notwendig.
Abb. 5.84

Instrumentierung im Experimentalfahrzeug. (ETAS GmbH [86])

Mess-, Kalibrier- und Diagnosesysteme müssen für die Integration von Funktionen, die auf verschiedene Steuergeräte verteilt sind, geeignet sein. Dazu müssen sie u. a. die gleichzeitige Instrumentierung und Kalibrierung mehrerer Steuergeräte unterstützen. Mess- und Kalibriersysteme werden in Abschn. 5.6 ausführlich behandelt.

Ein solches Mess-, Kalibrier- und Diagnosesystem kann auch mit einem Rapid-Prototyping-System, wie in Abb. 5.47 dargestellt, kombiniert werden.

Beim Übergang vom Prototyp- zum Serienfahrzeug ändert sich mit dem Wechsel vom Entwicklungs- zum Seriensteuergerät in vielen Fällen die für die Instrumentierung zur Verfügung stehende Offboard-Schnittstelle des Steuergeräts. Im Gegensatz zum Prototypfahrzeug steht beim Serienfahrzeug meist nur noch der Steuergerätezugang über die zentrale Offboard-Diagnoseschnittstelle des Fahrzeugs oder die Offboard-Diagnoseschnittstelle des Steuergeräts zur Verfügung, teilweise noch ein Zugang zu den Kommunikationssystemen.

Für die Messfunktionalität ist dieser Übergang meist mit einer Abnahme der Übertragungsleistung der Offboard-Schnittstelle verbunden, für die Kalibrierfunktionalität mit einer Einschränkung der verstellbaren Parameter und einer Änderung der Arbeitsweise.

5.5.4 Design und Automatisierung von Experimenten

Die Definition von Testfällen sollte bereits frühzeitig beim Entwurf berücksichtigt werden. Der Aufbau der Experimente kann sich an verschiedenen Kriterien orientieren – etwa an den Fahrzeugfunktionen, an den Komponenten eines Fahrzeugsystems oder an den Fahrsituationen.

Beispiele für funktionsorientiertes Testen von Software-Funktionen sind Testfälle für

Steuerungs- und Regelungsfunktionen,

Überwachungs- und Diagnosefunktionen.

Beispiele für system- und komponentenorientiertes Testen sind Testfälle für Software-Komponenten wie

Echtzeitbetriebssystem,

Kommunikationsschicht und Netzwerkmanagement,

Diagnoseschicht.

Beispiele für situationsorientiertes Testen von Software-Komponenten sind eine Aufteilung in

Normalfälle ,

Extremfälle ,

Fehlerfälle .

Die Automatisierung von Testaufgaben hängt mehr von der Prüfumgebung als vom Testfall ab. Sie erfordert eine formale Beschreibung der Experimente. Die Automatisierung ist am Laborfahrzeug oder Prüfstand natürlich einfacher möglich als im Fahrzeug.

Die Automatisierung von Tests bietet enormes Potential zur Kostenreduzierung. Im Rahmen dieses Buches wird jedoch nicht näher auf den Entwurf und die Automatisierung von Experimenten eingegangen. Für den Entwurf von Experimenten (engl. Design of Experiments) wird auf die Literatur, wie [30, 31], verwiesen.

5.6 Kalibrierung von Software-Funktionen

Die Einstellung der Parameterwerte der Software-Funktionen wird als Kalibrierung bezeichnet. Die Parameter liegen in der Regel in Form von Kennwerten, Kennlinien und Kennfeldern in der Software vor. Die Einstellung der Parameterwerte muss häufig für jeden Typ und jede Variante eines Fahrzeugs individuell erfolgen. Dazu werden Mess- und Kalibriersysteme eingesetzt.

Die unterschiedlichen Einsatzmöglichkeiten von Mess- und Kalibriersystemen an Laborfahrzeugen, an Prüfständen bis hin zum Einsatz im Fahrzeug wurden bereits in Abschn. 5.5 skizziert. In diesem Abschnitt wird die Arbeitsweise von Mess- und Kalibriersystemen dargestellt.

Ein Mess- und Kalibriersystem besteht aus einem Mess- und Kalibrierwerkzeug, einem oder mehreren Steuergeräten mit jeweils einem oder mehreren Mikrocontrollern mit geeigneten Offboard-Schnittstellen und einer Zusatzmesstechnik, die auch Instrumentierung genannt wird.

Alle mit der Instrumentierung erfassten Signale müssen im Messwerkzeug einheitlich dargestellt werden. Dies betrifft sowohl den Wertebereich als auch den Zeitbereich der erfassten Messsignale. Für die erfassten diskreten Signale des Mikrocontrollerprogramms bedeutet dies, dass eine Umrechnung von der Implementierungsdarstellung in die physikalische Darstellung im Messwerkzeug erforderlich ist.

Änderungen der Parameterwerte, etwa der Werte von Kennlinien und Kennfeldern, müssen im Werkzeug durch Editoren auf Implementierungsebene und – wie die Darstellung von Messsignalen – auf physikalischer Ebene unterstützt werden. Abb. 5.85 zeigt beispielhaft die physikalische Sicht und die Implementierungssicht auf eine Kennlinie KL und ein gemessenes Signal S.
Abb. 5.85

Onboard- und Offboard-Berechnungen bei Mess- und Kalibriersystemen. (ETAS GmbH [86])

Eine konsequente Unterscheidung zwischen Arbeitsschritten, die vom Mikrocontroller im Steuergerät, also onboard durchgeführt werden, und Arbeitsschritten, die durch das Mess- und Kalibrierwerkzeug, also offboard ausgeführt werden, ist sehr hilfreich (Abb. 5.85).

Ziel dieser Entwicklungsphase ist die Erstellung oder die Anpassung des Datenstandes, also der Parameterwerte, die in Form von Kennwerten, Kennlinien und Kennfeldern im Speicher des Mikrocontrollers abgelegt werden und mit denen das Programm des Mikrocontrollers arbeitet.

Zur Kalibrierung von Software-Funktionen, die durch verteilte und vernetzte Systeme realisiert werden, müssen Mess- und Kalibriersysteme ein Netzwerk von Mikrocontrollern und Steuergeräten unterstützen. In den folgenden Abschnitten wird vereinfachend nur ein Mikrocontroller und ein Steuergerät betrachtet.

Ausgangspunkt ist die Bereitstellung eines Steuergerätes, also eines Hardware- und Software-Standes. Der Software-Stand besteht aus einem Programmstand und einem initialen Datenstand für jeden Mikrocontroller des Steuergeräts. Das Mess- und Kalibriersystem benötigt zusätzlich eine Beschreibung des Software-Standes, die in der Regel in Form einer zusätzlichen Datei im Format ASAM-MCD 2 vorliegt. Neben Informationen zur Umrechnung zwischen physikalischer und Implementierungsebene für alle Mess-, Kalibrier- und Diagnosedaten sind darin auch Informationen zur Schnittstelle zwischen Werkzeug und Mikrocontroller abgelegt.

Ziel dieses oft aufwändigen Entwicklungsschritts ist die Anpassung des Datenstands. Dabei stehen verschiedene Aspekte im Vordergrund. Beispiele sind die Anpassung an verschiedene Betriebspunkte, der Langzeitbetrieb von Systemen – um Alterungseffekte durch Parameter und Algorithmen kompensieren zu können –, Flottenversuche – um Fertigungstoleranzen von Bauteilen beurteilen zu können – oder die Kalibrierung von Varianten.

5.6.1 Arbeitsweisen bei der Offline- und Online-Kalibrierung

Bei der Arbeitsweise mit Kalibriersystemen kann generell zwischen der Offline- und der Online-Kalibrierung unterschieden werden.

Bei der Offline-Kalibrierung wird die Ausführung der Steuerungs-/Regelungs- und Überwachungsfunktionen, des so genannten Fahrprogramms , während der Änderung oder Verstellung der Parameterwerte unterbrochen. Dadurch führt die Offline-Kalibrierung zu vielen Einschränkungen. Insbesondere beim Einsatz an Prüfständen und bei Versuchen im Fahrzeug muss dazu immer auch der Prüfstands- oder Fahrversuch unterbrochen werden.

Hier ist deshalb ein Verfahren sinnvoll, das die Online-Kalibrierung unterstützt. Bei der Online-Kalibrierung können die Parameterwerte verstellt werden, während das Fahrprogramm durch den Mikrocontroller ausgeführt wird. Das bedeutet, dass die Verstellung der Parameterwerte bei gleichzeitiger Ausführung der Steuerungs-/Regelungs- und Überwachungsfunktionen und damit beispielsweise während des regulären Prüfstands- oder Fahrzeugbetriebs möglich ist.

Die Online-Kalibrierung stellt höhere Ansprüche an die Stabilität der Steuerungs-/Regelungs- und Überwachungsfunktionen, da das Mikrocontrollerprogramm während des Verstellvorgangs durch das Werkzeug auch für eventuell auftretende Ausnahmesituationen, wie beispielsweise kurzzeitig nicht monoton steigende Stützstellenverteilungen bei Kennlinien, robust ausgelegt sein muss.

Die Online-Kalibrierung ist für langwierige und iterative Abstimmaufgaben der Parameter von Funktionen mit eher geringer Dynamik, beispielsweise zur Abstimmung von Motorsteuerungsfunktionen am Motorprüfstand, geeignet. Bei der Kalibrierung der Parameter von Steuerungs- und Regelungsfunktionen mit hoher Dynamik oder hoher Sicherheitsrelevanz werden Parameter zwar nicht während der aktiven Ausführung der Steuerungs- und Regelungsfunktionen verstellt, dennoch kann auch hier durch die Online-Kalibrierung eine iterative Vorgehensweise besser unterstützt und die Unterbrechung des Fahrprogramms vermieden werden.

Ein Beispiel ist die Abstimmung von ABS-Funktionen in Bremsmanövern. Hier wird zwar nicht während des eigentlichen ABS-Reglereingriffs verstellt. Dennoch kann die Zeitspanne zwischen zwei Fahrversuchen durch die Online-Kalibrierung reduziert werden.

Beispielhaft sind zwei mögliche Arbeitsweisen bei der Offline- und Online-Kalibrierung in Abb. 5.86 einander gegenüber gestellt.
Abb. 5.86

Unterschiedliche Arbeitsweisen bei Offline - und Online-Kalibrierung

Die Anforderungen an Online- und Offline-Kalibriersysteme sind also unterschiedlich. So kommen Offline-Kalibriersysteme mit den Funktionen Messen, Offboard-Verstellen von Parametern und Laden von Programm- und Datenstand, beispielsweise durch Flash-Programmierung, in den Mikrocontroller aus. Für Online-Kalibriersysteme sind zusätzliche Funktionen notwendig, die das Ändern von Parametern ohne Unterbrechung des Fahrprogramms ermöglichen. Die folgenden Abschnitte orientieren sich an den notwendigen Funktionen für die Offline- und Online-Kalibrierung.

5.6.2 Software-Update durch Flash-Programmierung

Zur Inbetriebnahme des Steuergeräts müssen zunächst der Programm- und Datenstand in den Programm- und Datenspeicher des Mikrocontrollers geladen werden. Entwicklungssteuergeräte werden in der Regel mit Flash-Speicher ausgerüstet, so dass ein Software-Update für den Programm- und Datenstand durch Flash-Programmierung erfolgen kann (Abb. 5.87).
Abb. 5.87

Flash-Programmierung von Programm- und Datenstand

Wie in Abb.  4.23 dargestellt, wird für das Software-Update durch Flash-Programmierung typischerweise ein eigener Betriebszustand der Software festgelegt, in dem die Ausführung der für den normalen Fahrzeugbetrieb notwendigen Steuerungs-/Regelungs- und Überwachungsfunktionen unterbrochen wird. Der Übergang in den Betriebszustand „Software-Update“ wird vom Flash-Programmierwerkzeug angestoßen und darf nur unter bestimmten Bedingungen erfolgen. Beispielsweise wäre eine solche Bedingung bei Motorsteuergeräten die Erkennung des Motorstillstands, also Motordrehzahl = 0.

Im Betriebszustand „Software-Update“ werden dann sowohl der Programmstand als auch der Datenstand in den Flash-Speicher des Mikrocontrollers übertragen. Für ein Update des Datenstands im Steuergerät nach Abschluss einer Kalibrieraufgabe wird die separate Flash-Programmierung des Datenstands unterstützt. Anschließend wird – wiederum angestoßen vom Flash-Programmierwerkzeug – der Betriebszustand „Software-Update“ vom Mikrocontroller wieder verlassen und es erfolgt der Übergang in den Betriebszustand „Normalbetrieb“, wo die Steuerungs-/Regelungs- und Überwachungsfunktionen des Fahrprogramms ausgeführt werden. Der Ablauf beim Software-Update durch Flash-Programmierung wird in Abschn.  6.3 behandelt.

Mit den aktuell eingesetzten Flash-Technologien können nur ganze Speicherbereiche, so genannte Flash-Segmente , entweder gelöscht oder neu programmiert werden. Das bedeutet, dass der Datenstand in anderen Flash-Segmenten als der Programmstand abgelegt werden muss, wenn Programm- und Datenstand getrennt programmiert werden sollen. Bei der Flash-Programmierung muss deshalb speicherorientiert gearbeitet werden. Einzelne geänderte Parameter können mit der derzeitigen Flash-Technologie nicht ins Flash programmiert werden.

5.6.3 Synchrones Messen von Signalen des Mikrocontrollers und der Instrumentierung

Die Auswirkungen von Parameteränderungen werden in der Regel anhand von Messungen beurteilt. Ziel ist, das Zusammenwirken aller Komponenten eines Fahrzeugsystems bei der Ausführung einer bestimmten Fahrzeugfunktion anhand verschiedenster Messsignale zu beobachten. Ein Beispiel für eine solche experimentelle Prüfung der Funktionen des Motorsteuergerätes ist etwa die Prüfung des Verhaltens der Lambdaregelung bei einem Kaltstart. Dieses Experiment kann an einem Kälteprüfstand oder auf einer Kaltlanderprobung im Fahrzeug durchgeführt werden.

Ohne eine Instrumentierung aller an der Funktion beteiligten Fahrzeugkomponenten durch eine geeignete Messtechnik und die synchrone Erfassung und Aufzeichnung von Messdaten im Mikrocontroller und den instrumentierten Komponenten ist eine Beurteilung der Funktion meist nicht möglich.

Das Mess- und Kalibriersystem muss dazu die Erfassung von sich ändernden Signalen im Mikrocontroller während der Ausführung des Programms – also die Messung von Größen, die im RAM des Mikrocontrollers abgelegt sind – synchron mit der Erfassung von zusätzlichen Signalen der Instrumentierung in der Umgebung des Steuergeräts durch eine geeignete Messtechnik unterstützen (Abb. 5.84). Dies kann auch die Erfassung von Signalen des Fahrers und der Umwelt einschließen.

Diese zusätzlichen Signale werden häufig an den Sensoren und Aktuatoren der Fahrzeugfunktion aufgenommen. In vielen Fällen interessieren auch die aktuellen Umgebungsbedingungen – wie Luftdruck oder Lufttemperatur – oder weitere Signale – wie Drehmomente, Drücke, Temperaturen oder Abgaswerte – an verschiedenen Messstellen im Fahrzeug. Auch der für eine Funktion relevante Datenverkehr im Kommunikationsnetzwerk des Fahrzeugs soll in vielen Fällen synchronisiert aufgezeichnet werden.

Sinnvollerweise wird für die Instrumentierung deshalb eine höhere Leistungsklasse als für die Fahrzeugsensoren verlangt. Für die Messtechnik stellt die zeitliche Synchronisation der verschiedenen Erfassungsraten von Signalen des Mikrocontrollers mit der Messwerterfassung der örtlich verteilten, dezentralen Instrumentierung besondere Anforderungen dar, etwa bezüglich der Vergabe von Zeitstempeln und der Synchronisation einer systemweiten Uhrzeit (Abb.  2.53).

5.6.4 Auslesen und Auswerten von Onboard-Diagnosedaten

Neben den Parametern von Steuerungs- und Regelungsfunktionen müssen auch die Parameter von Überwachungs- und Onboard-Diagnosefunktionen, beispielsweise Schwellwerte für Plausibilitätsprüfungen, eingestellt werden.

Für die experimentelle Überprüfung der Funktionsfähigkeit des Onboard-Diagnosesystems ist neben der beschriebenen Messtechnik auch das Auslesen und Auswerten der Diagnosedaten aus dem Fehlerspeicher des Mikrocontrollers erforderlich. Vor einem Experiment sollte der Fehlerspeicher auch gelöscht werden können. Das bedeutet, während der Kalibrierung ist bereits die Grundfunktionalität eines Offboard-Diagnosesystems erforderlich (Abb.  2.64).

Die erforderlichen Beschreibungsinformationen für die Klartextdarstellung der Fehlerspeicherinhalte und die Umrechnung von Signalen in die physikalische Darstellung durch das Mess- und Kalibrierwerkzeug sind Bestandteil der Beschreibungsdatei im Format ASAM-MCD 2. Auf den Aufbau von Offboard-Diagnosewerkzeugen wird in Kap.  6 etwas näher eingegangen.

5.6.5 Offline-Verstellen von Parametern

Mit den Informationen der Beschreibungsdatei können im Kalibrierwerkzeug die Werte der Parameter des Datenstands, also die Werte von Kennwerten, Kennlinien oder Kennfeldern, auf physikalischer Ebene dargestellt werden. Parameteränderungen können durch grafische oder tabellarische Editoren des Kalibrierwerkzeugs komfortabel unterstützt werden.

Der Datenstand im Flash-Speicher des Mikrocontrollers wird in den folgenden Abschnitten als Referenzstand oder auch Referenzseite des Mikrocontrollers bezeichnet, entsprechend der Datenstand im Kalibrierwerkzeug als Referenzseite des Werkzeugs (Abb. 5.88). Zum Verstellen von Parametern wird im Werkzeug eine Kopie der Referenzseite angelegt, die so genannte Arbeitsseite. Der Datenstand der Arbeitsseite kann verändert werden, während die Referenzseite unveränderbar ist.
Abb. 5.88

Offline-Verstellen von Parametern des Datenstands

Die Änderungen der Arbeitsseite können auf die Referenzseite des Werkzeugs gesichert werden. Die Referenzseite stellt somit eine Vergleichsbasis zu den weiteren Änderungen auf der Arbeitsseite dar.

Alternativ stellt die Referenzseite nach einem Laden der aktuellen Werte aus dem Mikrocontroller (engl. Upload) ein Abbild des aktuellen Zustandes im Steuergerät dar.

Erst bei erneuter Flash-Programmierung wird die Arbeits- oder die Referenzseite des Werkzeugs ins Flash des Mikrocontrollers geladen. Dazu muss wieder der Betriebszustand des Mikrocontrollers gewechselt und die Ausführung des Fahrprogramms unterbrochen werden.

5.6.6 Online-Verstellen von Parametern

Soll die Verstellung von Parametern auch online möglich sein, dann muss dazu das Konzept der Arbeits- und Referenzseite auf den Mikrocontroller ausgedehnt werden.

Dies erfolgt dadurch, dass für die Online-Kalibrierung die zu kalibrierenden Daten vom ROM- oder Flash-Bereich in einen vom Programm nicht verwendeten, freien RAM-Bereich kopiert werden, in dem die Arbeitsseite liegt (Abb. 5.89). Mikrocontroller und Kalibrierwerkzeug arbeiten synchronisiert mit den Kalibrierdaten in diesem RAM-Bereich, der auch Kalibrier-RAM (engl. Calibration RAM , kurz CAL-RAM ) genannt wird (Abb. 5.1, Abb. 5.89).
Abb. 5.89

Online-Verstellen von Parametern des Datenstands mit dem Werkzeug INCA. (ETAS GmbH [86])

Während auf der Referenzseite des Mikrocontrollers – im Flash – speicherorientiert und mit Unterbrechung der Ausführung des Fahrprogramms verstellt werden muss, kann auf der Arbeitsseite des Mikrocontrollers – im CAL-RAM – parameterorientiert und während der Ausführung des Fahrprogramms durch das Kalibrierwerkzeug verstellt werden.

Die Software des Mikrocontrollers muss dazu im Fahrprogramm auf die Arbeitsseite zugreifen, was durch Modifikationen in der Software oder Hardware des Mikrocontrollers erfolgen kann. Verschiedene Verfahren dafür werden im nächsten Abschnitt dargestellt.

5.6.7 Klassifizierung der Offboard-Schnittstellen für das Online-Verstellen

Auf den CAL-RAM-Bereich kann das Kalibrierwerkzeug über verschiedene Schnittstellen des Mikrocontrollers zugreifen. Grundsätzlich kann unterschieden werden, ob CAL-RAM im Mikrocontroller vorhanden oder nicht vorhanden ist und ob ein Werkzeug über den parallelen Bus des Mikrocontrollers oder über eine serielle Schnittstelle des Mikrocontrollers auf das CAL-RAM zugreift (Abb. 5.90).
Abb. 5.90

Klassifizierung der Schnittstellen zwischen Mikrocontroller und Werkzeugen

Bei den seriellen Schnittstellen ist ein weiteres Unterscheidungsmerkmal zu berücksichtigen. Es kann eine serielle Schnittstellentechnologie gewählt werden, die auch im Seriensteuergerät eingesetzt wird und dort beispielsweise für die Offboard-Diagnosekommunikation oder die Onboard-Kommunikation verwendet wird. Weit verbreitete Beispiele für eine solche Serientechnologie sind die K-Leitung [5] oder CAN [2]. Alternativ kann eine Schnittstelle verwendet werden, die nur in der Entwicklungsphase vorhanden ist und dort beispielsweise für Download und Debugging der Software verwendet wird. Beispiele sind JTAG [93] oder NEXUS [92]. Dagegen werden Zugriffe über den parallelen Bus des Mikrocontrollers nur in der Entwicklungsphase eingesetzt.

Für die Klassifizierung der Schnittstellen erhält man so die in Abb. 5.90 dargestellte Gesamtsicht. Alle in der Praxis auftretenden Schnittstellen können einer der dargestellten Methoden 1 bis 6 zugeordnet werden, die in den folgenden Abschnitten anhand vereinfachter Blockdiagramme kurz vorgestellt und bewertet werden.

Die Blockdiagramme sind beispielsweise dahingehend vereinfacht, dass nur zwischen im Mikrocontroller vorhandenem CAL-RAM und nicht im Mikrocontroller vorhandenem, also zusätzlichem CAL-RAM unterschieden wird. Dabei wird vernachlässigt, ob das CAL-RAM – sofern beide Varianten beim eingesetzten Mikrocontroller technisch möglich sind – durch internes oder externes RAM realisiert wird. Auch die Art der Realisierung – etwa durch eine Erweiterung des Steuergeräts oder durch eine Erweiterung des Mikrocontrollers in der Entwicklungsphase – wird vernachlässigt.

5.6.7.1 Serielle, seriennahe Schnittstelle mit internem CAL-RAM (Methode 1)

Die Methode 1 – also die Verwendung einer seriellen Schnittstelle, die auch im Seriensteuergerät eingesetzt wird – bietet in Verbindung mit internem CAL-RAM die Vorteile, dass auf Steuergeräteseite fast keine Hardware-Änderungen gegenüber dem Seriensteuergerät notwendig sind und die Technologie für den Einsatz im Fahrzeug geeignet ist (Abb. 5.91). Das CAL-RAM wird im Seriensteuergerät nicht mehr benötigt. Aus Kostengründen können in Entwicklungssteuergeräten Entwicklungsmuster der Mikrocontroller mit zusätzlichem CAL-RAM verwendet werden. Ist dies nicht möglich, führt dieses CAL-RAM unter Umständen zu zusätzlichen Hardware-Kosten im Seriensteuergerät.
Abb. 5.91

Serielle, seriennahe Schnittstelle mit internem CAL-RAM (Methode 1)

Die Übertragungsleistung der Serienschnittstelle ist aus Kostengründen begrenzt und erfüllt nicht immer die hohen Anforderungen, die an die Messtechnik in der Entwicklungsphase gestellt werden. Häufig werden die K-Leitung [5], die auch für die Offboard-Diagnosekommunikation verwendet wird, oder die CAN-Schnittstelle, die für die Onboard-Kommunikation und zunehmend auch für die Offboard-Diagnosekommunikation eingesetzt wird, dafür verwendet.

Wird die Schnittstelle parallel auch für die Onboard-Kommunikation eingesetzt, wie beispielsweise CAN, so ist sie oft schon zu einem hohen Grad ausgelastet. In vielen Fällen wird deshalb eine separate, zweite CAN-Schnittstelle ausschließlich für die Offboard-Kommunikation mit dem Entwicklungswerkzeug genutzt, so dass die Onboard-Kommunikation dadurch nicht zusätzlich belastet wird.

In beiden Fällen wird jedoch der Mikrocontroller dadurch belastet, dass die Kommunikation zwischen Mikrocontroller und Werkzeug durch Software-Komponenten realisiert wird, die zusätzliche Ressourcen, also Laufzeit und Speicher, belegen.

Für die Online-Kalibrierung ergeben sich in vielen Fällen Einschränkungen durch die begrenzte Größe des CAL-RAM-Bereichs. Die Anzahl der Kennwerte, Kennlinien und Kennfelder, die gemeinsam kalibriert werden können, wird dadurch begrenzt. Dieses Problem kann zwar durch eine dynamische Verwaltung und Zuteilung des CAL-RAM-Bereichs entschärft werden, das CAL-RAM-Management belegt aber wie die Offboard-Kommunikation in jedem Fall zusätzliche Ressourcen des Mikrocontrollers. Methoden zum CAL-RAM-Management werden in Abschn. 5.6.8 behandelt.

5.6.7.2 Serielle Entwicklungsschnittstelle mit internem CAL-RAM (Methode 2)

Auch die Methode 2 – also die Verwendung einer seriellen Entwicklungsschnittstelle in Verbindung mit internem CAL-RAM – bietet den Vorteil, dass auf Steuergeräteseite nur geringe Hardware-Änderungen gegenüber dem Seriensteuergerät notwendig sind. Die Entwicklungsschnittstellen, wie JTAG [93], sind jedoch zum Teil für andere Einsatzfelder – etwa für Debugging – konzipiert. Andere Entwicklungsschnittstellen sind spezifisch für den Mikrocontroller ausgeprägt. Meistens erfüllen diese nicht alle Anforderungen für den Einsatz im Fahrzeug unter rauen Bedingungen. Eine Wandlung auf eine für den Fahrzeugeinsatz ausgelegte Schnittstelle muss deshalb direkt im Steuergerät durchgeführt werden. Eine Lösung nach diesem Prinzip unter Verwendung eines so genannten seriellen ETKs [94] ist in Abb. 5.92 dargestellt.
Abb. 5.92

Serielle Entwicklungsschnittstelle mit internem CAL-RAM (Methode 2)

Die Übertragungsleistung der Entwicklungsschnittstellen ist meist wesentlich höher als die der Serienschnittstellen und erfüllt die höheren Anforderungen an die Messtechnik in der Entwicklungsphase.

Ist die Kommunikation zwischen Mikrocontroller und Werkzeug bei Verwendung einer solchen Entwicklungsschnittstelle durch Hardware realisiert, dann sind dafür keine Erweiterungen oder Änderungen in der Software des Mikrocontrollers notwendig. Entsprechend geringer ist in vielen Fällen auch der Einfluss dieses Verfahrens auf die Laufzeit.

Wie bei der Methode 1, ergeben sich jedoch weiterhin für die Online-Kalibrierung in vielen Fällen Einschränkungen durch die Begrenzung der Größe des CAL-RAM-Bereichs und der Mikrocontroller wird weiterhin durch das CAL-RAM-Management belastet.

5.6.7.3 Parallele Entwicklungsschnittstelle mit internem CAL-RAM (Methode 3)

Alternativ kann auch, sofern möglich, eine parallele Entwicklungsschnittstelle nach Methode 3 verwendet werden, wie in Abb. 5.93 dargestellt. Die Leistungsmerkmale sind ähnlich zu der Methode 2, jedoch sind die Hardware-Modifikationen im Steuergerät wesentlich umfangreicher als bei einem Zugriff über eine serielle Schnittstelle. In der Praxis hat diese Methode daher eine geringe Bedeutung.
Abb. 5.93

Parallele Entwicklungsschnittstelle mit internem CAL-RAM (Methode 3)

5.6.7.4 Serielle, seriennahe Schnittstelle mit zusätzlichem CAL-RAM (Methode 4)

Die Einschränkungen in der Online-Kalibrierung durch die Begrenzung der Größe des internen CAL-RAMs können durch den Einbau von zusätzlichem CAL-RAM in Entwicklungssteuergeräten oder die Verwendung von Entwicklungsmustern des Mikrocontrollers mit zusätzlichem CAL-RAM nach Methode 4 aufgehoben werden.

Bei Verwendung einer seriennahen Schnittstelle, wie in Abb. 5.94, bestehen natürlich die genannten Einschränkungen in Bezug auf Übertragungsleistung und Mikrocontrollerbelastung weiterhin.
Abb. 5.94

Serielle, seriennahe Schnittstelle mit zusätzlichem CAL-RAM (Methode 4)

5.6.7.5 Serielle Entwicklungsschnittstelle mit zusätzlichem CAL-RAM (Methode 5)

Die Einschränkungen bzgl. Übertragungsleistung und Mikrocontrollerbelastung können wieder durch die Verwendung einer seriellen Entwicklungsschnittstelle nach Methode 5 umgangen werden. Eine solche Lösung unter Verwendung eines seriellen ETKs [94] und zusätzlichem CAL-RAM ist in Abb. 5.95 dargestellt. Die Modifikationen in der Steuergeräte-Hardware sind bei diesem Verfahren aber recht umfangreich, da sowohl zusätzliches CAL-RAM als auch eine Schnittstellenwandlung notwendig sind.
Abb. 5.95

Serielle Entwicklungsschnittstelle mit zusätzlichem CAL-RAM (Methode 5)

5.6.7.6 Parallele Entwicklungsschnittstelle mit zusätzlichem CAL-RAM (Methode 6)

Methode 6 – die Verwendung einer parallelen Entwicklungsschnittstelle mit zusätzlichem CAL-RAM – bietet die Vorteile, dass hohe Übertragungsleistung, Online-Zugriff auf alle Kalibrierdaten sowie unabhängiger CAL-RAM-Zugriff von Mikrocontroller und Werkzeug bei geringer bis moderater Belastung des Mikrocontrollers kombiniert werden können. Eine Lösung nach dieser Methode mit einem so genannten parallelem ETK [95] ist in Abb. 5.96 dargestellt. Auch hier sind relativ umfangreiche Modifikationen in der Steuergeräte-Hardware notwendig.
Abb. 5.96

Parallele Entwicklungsschnittstelle mit zusätzlichem CAL-RAM (Methode 6)

5.6.7.7 Protokolle für die Kommunikation zwischen Kalibrierwerkzeugen und Mikrocontrollern

Für die Kommunikation zwischen Kalibrierwerkzeugen und Mikrocontrollern wurden verschiedene Protokolle standardisiert. Ein Überblick ist in Tab. 5.3 dargestellt.
Tab. 5.3

Standardisierung der Kommunikation zwischen Werkzeug und Mikrocontroller

5.6.8 Management des CAL-RAM

Unabhängig von der gewählten Methode arbeitet der Mikrocontroller nach der Initialisierung zunächst mit den Parametern der Referenzseite. So ist ein Betrieb auch ohne angeschlossenes Kalibrierwerkzeug möglich. Die Arbeitsseite wird bei der Initialisierung mit den Daten der Referenzseite überschrieben. Danach kann wahlweise mit den Parametern auf der Referenzseite oder auf der Arbeitsseite gearbeitet werden. Dazu ist die Umschaltung des Fahrprogramms von der Arbeits- auf die Referenzseite und umgekehrt erforderlich. Sie kann durch Software- oder Hardware-Modifikationen des Mikrocontrollers realisiert werden. Bei einigen Mikrocontrollern wird dies vollständig durch die Hardware unterstützt. Diese Umschaltung wird vom Kalibrierwerkzeug gesteuert.

Ein Überwachungskonzept auf der Mikrocontrollerseite kann so aufgebaut werden, dass bei unplausiblem Verhalten von Funktionen des Fahrprogramms nach Parameteränderungen auf der Arbeitsseite – beispielsweise bei eintretender und erkannter Instabilität von Regelungsfunktionen – automatisch in den Betriebszustand „Notlauf“ gewechselt wird.

Der Benutzer des Kalibrierwerkzeugs kann durch Umschalten auf die Referenzseite das System bei unplausiblem Verhalten nach Parameteränderungen auf der Arbeitsseite schnell wieder in einen funktionsfähigen Zustand bringen.

5.6.8.1 CAL-RAM-Management bei ausreichenden Speicherressourcen

Ist der zur Verfügung stehende CAL-RAM-Bereich ausreichend groß – d. h. mindestens so groß wie der gesamte Datenstand Speicherplatz im Flash des Mikrocontrollers benötigt –, so beschränkt sich der Aufwand für das CAL-RAM-Management auf der Seite des Mikrocontrollers im wesentlichen auf das Kopieren der gesamten Referenzseite auf die Arbeitsseite, auf das „Sichern“ der Arbeitsseite auf die Referenzseite durch Flash-Programmierung und auf das Umschalten zwischen diesen beiden Seiten (Abb. 5.97).
Abb. 5.97

CAL-RAM-Management bei ausreichenden Speicherressourcen

5.6.8.2 CAL-RAM-Management bei eingeschränkten Speicherressourcen

Ist dagegen die Größe des CAL-RAM-Bereichs eingeschränkt, so dass nicht der gesamte Datenstand ins CAL-RAM kopiert werden kann, dann muss das CAL-RAM-Management im Mikrocontroller und im Kalibrierwerkzeug um Funktionen zur Verwaltung eines Ausschnitts des Datenstands, also einer Teilmenge der Parameter, erweitert werden (Abb. 5.98).
Abb. 5.98

CAL-RAM-Management bei eingeschränkten Speicherressourcen

Nur für diese Teilmenge der Parameter sind dann die Funktionen Kopieren, „Sichern“ durch Flash-Programmierung und Umschalten, und damit auch das Online-Verstellen möglich.

Die Festlegung des Datenstandsausschnitts kann speicherorientiert oder parameterorientiert erfolgen. Bei der speicherorientierten Festlegung eines Ausschnitts können die Parameter eines zusammenhängenden Flash-Speicherbereichs, wie in Abb. 5.98 dargestellt, ins CAL-RAM kopiert und verstellt werden.

Die parameterorientierte Festlegung eines Ausschnitts ist komfortabler, da damit flexibler gearbeitet werden kann. Die Referenzseite ist dabei kein zusammenhängender Flash-Speicherbereich mehr, sondern ergibt sich, wie in Abb. 5.99 dargestellt, aus den Speicherbereichen der ausgewählten Parameter. Die Auswahl einer Parameterteilmenge kann im Kalibrierwerkzeug erfolgen und über eine Zeigertabelle auf den Mikrocontroller abgebildet werden. Das Mikrocontrollerprogramm greift dann nicht mehr direkt auf die Parameter der Referenzseite zu – in Abb. 5.99 mit ① markiert –, sondern indirekt über die Zeigertabelle – in Abb. 5.99 mit ② markiert. Vom Kalibrierwerkzeug kann bei dem dargestellten Verfahren zwischen dem Parameterzugriff auf die Referenzseite – über ③ – und auf die Arbeitsseite – über ④ – umgeschaltet werden.
Abb. 5.99

Zeigertabelle zur Verwaltung von Parameterteilmengen. (ETAS GmbH [86])

Wird die Zeigertabelle selbst im Flash des Mikrocontrollers abgelegt, dann ist bei jeder Änderung des Parameterausschnitts die Neuprogrammierung des entsprechenden Flash-Segments notwendig und die Parameterteilmenge ist während der Ausführung des Fahrprogramms statisch.

Alternativ kann die Zeigertabelle auch im CAL-RAM des Mikrocontrollers abgelegt werden. Sie kann dann dynamisch auch während der Ausführung des Fahrprogramms verändert werden.

5.6.9 Management der Parameter und Datenstände

Neben den bisher dargestellten Grundfunktionen von Mess- und Kalibriersystemen müssen auf der Werkzeugseite weitere Funktionen unterstützt werden. Beispiele sind Funktionen zum parameterorientierten Exportieren, Importieren und Zusammenführen (engl. Merge) von Datenständen, zum Zusammenführen von Programm- und Datenständen, zur Auswertung von Messdaten, zum Verstellen abhängiger Parameter (Abb. 5.57), zur Berechnung von virtuellen Messgrößen (Abb. 5.58) sowie Schnittstellen zu Werkzeugen für das Dokumentations- und Konfigurationsmanagement.

Abb. 5.100 zeigt einen Überblick über die Funktionen für das Management der Parameterwerte und Datenstände. Mit Hilfe der Beschreibungsdatei kann der Datenstand im Werkzeug in die physikalische Darstellung umgerechnet und in einer Datenbank abgelegt werden. Diese physikalischen Parameterwerte können editiert werden und stehen zur Weiterverwendung in verschiedenen Anwendungen zur Verfügung. Mit Hilfe der Spezifikation des Datenmodells einer Software-Komponente kann damit das Datenmodell der Software-Komponente parametriert werden; mit Hilfe des Designs des Datenmodells einer Software-Komponente kann auch die Software-Komponente in Quellcode parametriert werden. Auch die umgekehrten Vorgehensweisen sind möglich.
Abb. 5.100

Management der Parameterwerte und Datenstände

5.6.9.1 Parametrierung der binären Programm-/Datenstandsdatei

Es wird schließlich ein finaler Datenstand erzeugt und eine Parametrierung der Binärdatei durchgeführt. Programm- und Datenstand werden in dem für Produktion und Service notwendigen Binärdateiformat weitergegeben.

Diese Vorgehensweise hat den Vorteil, dass die notwendige Funktionalität komplett durch das Kalibriersystem bereitgestellt werden kann und dort zum Standardumfang gehört. Die Kalibrierung kann auch über Unternehmensgrenzen hinweg aufgeteilt werden. Der Programm- und Datenstandsaustausch ist dabei nur in der Richtung vom Lieferant zum Fahrzeughersteller notwendig.

Der Umgang mit Binärformaten schränkt jedoch die Verwaltung der Datensätze auf physikalischer Ebene und die einfache, projektübergreifende Verwendung ein. Außerdem können Optimierungen, die den Programmstand betreffen, nach der Kalibrierung nicht mehr durchgeführt werden. Die eventuell für das Kalibrierverfahren notwendigen Anpassungen der Software-Strukturen sind zumindest teilweise im Serienstand vorhanden.

5.6.9.2 Parametrierung des Modells oder des Quellcodes und Optimierung

Diese Nachteile können mit einer Vorgehensweise umgangen werden, bei welcher der ermittelte Datenstand vom Kalibriersystem exportiert und mit Hilfe von Informationen zum Datenmodell zur Parametrierung auf der Quellcode- oder Modellebene verwendet wird.

Anschließend können umfangreiche Optimierungsmaßnahmen durchgeführt werden. Diese können von einer bezüglich Laufzeit- oder Speicherplatzanforderungen optimierten Ablage, über die Anpassung der Stützstellenanzahl bis hin zur Optimierung von Quantisierung, Wertebereich oder Speichersegment von Kennlinien und Kennfeldern reichen. Das optimierte Modell oder der optimierte Quellcode wird anschließend mit eventuell angepassten Optionen des Compilers neu übersetzt und nach Durchführung der entsprechenden Qualitätsprüfungen an Produktion und Service ausgeliefert. Da danach Parameteränderungen nicht mehr oder nur noch eingeschränkt möglich sind, ist dieser Optimierungsschritt erst kurz vor der Übergabe des Programm- und Datenstands an Produktion und Service möglich.

5.6.10 Design und Automatisierung von Experimenten

Über eine Automatisierungsschnittstelle, wie ASAM-MCD 3 [18], können vielfältige Funktionen von einem übergeordneten Automatisierungssystem gesteuert werden. Damit ist sowohl die Automatisierung von Offline-Aufgaben – beispielsweise die Auswertung von aufgezeichneten Messdaten –, aber auch die Automatisierung von Online-Aufgaben – wie die Durchführung langwieriger Abstimmaufgaben am Laborfahrzeug oder Prüfstand, wie in Abschn. 5.5.4 dargestellt – möglich [29, 30, 31].

Viele Aufgabengebiete, etwa die Automatisierung der Messdatenanalyse oder die Bestimmung optimierter Parameterwerte, sind Gegenstand aktueller Forschungs- und Entwicklungsanstrengungen.

Trotz der hohen Bedeutung kann in diesem Buch nicht weiter auf dieses umfangreiche Themengebiet eingegangen werden.

Copyright information

© Springer Fachmedien Wiesbaden 2016

Authors and Affiliations

  1. 1.ErligheimDeutschland
  2. 2.StuttgartDeutschland

Personalised recommendations