Der moderne Funktions- und Softwareentwicklungsprozessnosper/public/Download/Kapitel 2.6... · Moderne Tools wie z.B. MATLAB/Simulink bei dSpace oder ASCET-SD von ETAS benutzen dazu

Mechatronische Systemtechnik im KFZ Kapitel 2: Funktionsentwicklung Prof. Dr.-Ing. Tim J. Nosper

Bild 2.6_1 Quelle: ETAS

Der moderne Funktions- und Softwareentwicklungsprozess

ECU = Electronic Control Unit = Elektronisches Steuergerät


Zeitlicher Ablauf der Softwareentwicklung

SW-QB = Software-Qualitätsbewertung

Bild 2.6_2 Quelle: Bosch


Grundmodell aus den Anfangstagen der SW-Entwicklung:

1) Beschreibe die Aufgabe in Prosa

2) Schreibe ein Programm

3) Finde und behebe die Fehler in dem Programm

Der Softwerker als „kreativer Künstler“ !

Diese Vorgehensweise wird heutigen Anforderungen nicht gerecht.

Deshalb: „Software ist Hardware !!“ -> klar strukturiertes Vorgehen

Für die Softwareentwicklung wurden deshalb verschiedene Prozessmodelle entwickelt. Als wichtigstes wird hier das V-Modell behandelt.

Bild 2.6_3 Quelle: Wrede

Prozess- Modelle der Funktions- und Softwareentwicklung


Labor: Einführung in Simulationstool MATLAB/Simulink

Quelle: Matlab Bild 2.6_4


Funktions- und Softwareentwicklungsprozess (V- Modell)

Produkt/Projekt planen:Lastenheft, Projektplan

Produkt/Funktion definieren:Pflichtenheft,

formale Spezifikation

Programm entwerfen:SW-Architektur

Progr.-Module codieren:z.B. C-Sourcecode

Seriencode erzeugen:compilierter, gelinkter Maschinencode

Modultest, Code-Review:Ergebnisprotokolle

Integrationstest:Ergebnisprotokolle

Systemtest: Prüfstand, FahrversuchVersuchsberichte,

Parameterfestlegung

Feldtest, Kundentest:Feldberichte, Garantiestatistik

Anwendungsszenarien

Testfälle

Testfälle

Testfälle


Val

idat

ion

Ver

ifik

atio

n


Verifikation ist die Überprüfung der Übereinstimmung zwischen einem Software-Produkt und seiner Spezifikation.

Verifikation: Wird ein korrektes Produkt entwickelt ?

Validation ist die Eignung bzw. der Wert eines Produktes bezogen auf seinen Einsatzzweck.

Validation: Wird das richtige Produkt entwickelt ?


Verifikation und Validation


Am Anfang jeder (Software-)Produktentwicklung steht nach der Idee oder der Kundenanfrage die Planungsphase, in der folgende Fragen zu beantworten sind:

• Ist das Produkt technisch-funktionell machbar ? (z.B. Simulation)

• Wie hoch sind schätzungsweise die Entwicklungskosten ?

• Mechatronische Systeme: wie hoch sind schätzungsweise die Fertigungskosten ?

• Bis zu welchem Serientermin kann das Produkt entwickelt werden ? (time-to-market)

• Läßt sich das Produkt unter obigen Randbedingungen gewinnbringend vermarkten ?

Ergebnis der Planungsphase: Entscheidung über Projektstart

Dokumente: Machbarkeitsstudie, grobes Lastenheft, Projektplan


Planungsphase


Als nächster Schritt wird ein detailliertes Pflichtenheft als strukturiertes Textdokument erstellt. Teilweise ergänzt durch grafische Darstellungen. Das Pflichtenheft beschreibt das was ?, nicht das wie ? (Wirk- nicht Bauvorschrift !)

Moderne Tools wie z.B. MATLAB/Simulink bei dSpace oder ASCET-SD von ETAS benutzen dazu eine grafische, blockorientierte Darstellung.

Die formale Spezifikation geht einen Schritt weiter und beschreibt

• Daten

• Funktionen

• (zeitabhängige) Algorithmen

• Software-Schnittstellen

in einer von konkreten Programmiersprachen unabhängigen Form.


Definitionsphase: Pflichtenheft und formale Spezifikation


Die Entwurfsphase beantwortet neben dem wie ? z.B. folgende Fragen, falls nicht schon im Pflichtenheft festgelegt:

• Auf welcher Hardware muß die Software laufen ?

• Wird ein (Echtzeit)-Betriebssystem eingesetzt ?

• Welche Programmiersprache dient zur Implementierung ?

• Wie wird die Gesamtfunktion auf mehrere Steuergeräte verteilt ?

• Wie sind die Ein- und Ausgabeschnittstellen zu bedienen, z.B. CAN ?

• In welchen Speichern werden welche Daten abgelegt ?

• Wie wird das Gesamtprogramm in einzelne Software-Module (z.B. Unterprogramme) gegliedert ? Spezifikation der Module und Komponenten.


Entwurfsphase: Festlegung der Softwarearchitektur


Moderne Software-Architektur z.B. für Kfz-Steuergeräte

Stecker zu Sensoren und Aktoren

Anwendungsfunktionen z.B. ABS-, ASR-, ESP-Algorithmen

Funktion 1 Funktion 2 Funktion 3

Plattform-Software-Komponenten

Echtzeit-Betriebs-system

Basis-Sicherheits-Funktionen

CAN-Kommunikation

DiagnoseSensor-Signal-

aufbereitung

BetriebssystemSeriell ADC Digital I/O CAN

Schnittstellentreiber

Hardware

Quelle: Wrede Bild 2.6_10


Funktionsentwicklung und Offline-Simulation



Produkt definieren:Pflichtenheft,






Progr.-Module codieren:C-Sourcecode








Systemtest: Prüfstand, Fahrversuch:Ergebnisprot., Versuchsberichte,

Parameterfestlegung


Parameterfestlegung


Feldtest, Kundentest:Feldberichte, GarantiestatistikFunktions-

entwicklung + Offline-Simulation



Funktionsentwicklung+

Offline-Simulation(z.B. mit MATLAB/Simulink)


Offline-Simulation(z.B. mit MATLAB/Simulink)

SW-Funktionsmodell in grafischer Blockstruktur

z.B. Leerlaufregelung

SW-Funktionsmodell des umgebenden Systems

z.B. Motor und Fahrzeug

Entwicklungssystem, z.B. PC

Anwendung:

Funktion schnell und kostengünstig entwickeln und prüfen ohne Hardware !


















IntegrationstestErgebnisprotokolle



Parameterfestlegung


Parameterfestlegung



Rapid Prototyping


Rapid Prototyping


Rapid Prototyping(Übersetzung in C-Code

für Prototypentest)



Zielsystem,z.B. realer Prototyp

des Motors oder Fahrzeugs

Zielsystem,z.B. realer Prototyp

des Motors oder Fahrzeugs

Einschubkarte mit Hochleistungsrechnerund Input/Output


SW-Funktionsmodell in Prototypen-C-Code

SW-Funktionsmodell in Prototypen-C-Code


Anwendung:

Schnell die Funktion auf realen Prototypen testen und weiterentwickeln !

I/O

SW-Funktionsmodell in grafischer Blockstruktur,z.B. Leerlaufregelung

SW-Funktionsmodell in grafischer Blockstruktur,z.B. Leerlaufregelung


Rapid Prototyping


Simulation: MATLAB/Simulink/StateflowSimulation: MATLAB/Simulink/Stateflow

Codegenerierung: Real-Time WorkshopCodegenerierung: Real-Time Workshop

Linker + Compiler (hardwarespezifisch)Linker + Compiler (hardwarespezifisch)

Real-Time Hardware

Experiment Software (hardwarespezifisch)Experiment Software (hardwarespezifisch)

I/O

Reale Welt

Modell als C-Code + Treiber teilweise hardwareabhängig

Modell als Blockdiagramm hardwareunabhängig

Single-board modular Entwickl.-SG 2. PC (xPC)

externer C-Code

externer C-Code

z.B. schon vorhanden


Rapid Prototyping: Notwendige Software und Hardware (Beispiel)


Eine PCI-Einsteckkarte für PC enthält Hochleistungs-Echtzeitrechner sowie Input/Output-Schnittstellen.

Vorteil: relativ preisgünstig (ca. 5-10 T€)

Nachteil: Flexibilität und Leistung begrenzt

I/O

Sensoren Aktoren

Download, Messdaten Parameter


Rapid Prototyping mit Single-board Hardware


• Modularer Aufbau mit verschiedenen Einschubkarten für Rechner und Input/Output in einer Box.

• Anbindung an Simulationsrechner z.B. über Ethernet oder seriell

• Vorteil: Flexibel, universell, erweiterbar

• Nachteil: relativ teuer je nach Umfang

z.B. EthernetI/O

Download, Messdaten Parameter

Sensoren Aktoren


Rapid Prototyping mit modularer Hardware


I/O

• Laptop (oder auch Desktop), über Ethernet oder serielle Schnittstelle mit Entwicklungs-Steuergerät verbunden.

• Entwicklungs-Steuergerät enthält Hochleistungs-Echtzeitrechner und Input/Output-Schnittstellen.

• Optimal für mobile Anwendungen.

Download Messdaten Parameter

Sensoren Aktoren


Rapid Prototyping mit Notebook und Entwicklungs-Steuergerät


Automatische Generierung von Seriencode


















Parameterfestlegung


Parameterfestlegung






SW-Funktionsmodellin grafischer Blockstrukturz.B. Leerlaufregelung

SW-Funktionsmodellin grafischer Blockstrukturz.B. Leerlaufregelung

Generierter Funktions-C-Code+Treiber + externer C-Code

Generierter Funktions-C-Code+Treiber + externer C-Code

Ausführbarer Seriencode .hexAusführbarer Seriencode .hex

Generierung von Maschinencode für die Serie (Seriencode)

Generierung vonSeriencode



Anwendung:

Funktion schnell und fehlerfrei vom Blockdiagramm in Seriencode umsetzen.

Echtzeitbetriebssystem + Seriencode,


Echtzeitbetriebssystem + Seriencode,


Zielhardware, z.B. Motronic-Steuergerät

Download

10010011

Linker und Compiler

C-Code-Generator

Weitere Software-Kompo-nenten



Implementierungssphase: Codierung der Softwaremodule

Die sogenannte Implementierungsphase, also die eigentliche Codierung des Sourcecodes der Software-Module (= Software-Komponenten) mit einem Editor, wird oft fälschlicherweise als die Haupttätigkeit eines Programmierers angesehen.

Sie ist vom Aufwand her gesehen jedoch nur ein kleiner Teil des Gesamtaufwands, z.B. 10-20%, und wird zunehmend durch automatische Codegenerierungstools ersetzt.

Typische Aufwandsverteilung vor, für, nach Codierung: 40/20/40

Typische Aufwandsverteilung bei modernem Vorgehen: 60/15/25

Der erstellte Sourcecode wird i.a. mit einem Inspektionstool auf formale syntaktische Korrektheit getestet.



Konventionelle Vorgehensweise

µC-Zielsysteme mit begrenzten Resourcen

Datenflußdiagramme, Text

Iterationen

Funktionsentwickler:erstellt Algorithmus, Offline-Simulation

Softwarespezialist:Fachkenntnisse über µC

Codierung von Hand


Vorteile automatischer Seriencode- Generierung


Funktionsentwickler:erstellt Algorithmus

Softwarespezialist:Fachkenntnisse über µC,spezifiziert Implementierungs-information (z.B. Auflösung und Wertebereiche für Integerarithmetik)

Moderne Vorgehensweise

µC-Zielsysteme mit begrenzten Resourcen

Codegenerator Iterationen

Modellspezifikation,Implementierungsspezifikation


Vorteile automatischer Seriencode- Generierung


Generierung von Serien-Code für Steuergeräte

2 wesentliche Schritte bei der Generierung von Serien-C-Code:

1) Umwandlung der hardwareunabhängigen Modellbeschreibung (z.B. Blockdiagramme oder textuelle Modellbeschreibungssprache) in C-Code. Durch die Implementierung für einen bestimmten Rechner (Integer-Arithmetik, Treiber in C, Echtzeit-Betriebssystem) ist dieser Code nicht hardwareunabhängig, sondern spezifisch für den Zielrechner (Target). Vorteilhaft ist die Trennung in einen hardware-unabhängigen (und damit auf andere Rechner portierbaren) und einen hardwareabhängigen C-Code-Teil. Auch externer, z.B. schon vorhandener C-Codekann eingebunden werden.

2) Alle C-Quell-Code-Teile werden dann durch einen hardwarespezifischen Linker und Compiler zusammengebunden und in Maschinencode (.hex-File) übersetzt. Dieser kann z.B. in einen Flash-EEPROM im Steuergerät geladen werden und ist dann lauffähig.



Unterschiede zwischen Prototypen- C-Code und Serien- C-Code

Prototyp: Experimental-Hardware

• nicht laufzeit- und speicheroptimiert, optimiert für Messzwecke/Parameterverstellung

• Fließkomma-Arithmetik: Floating point -> quasikontinuierlich

• Überwachungs- und Sicherheitsfunktionen fehlen (zum Teil)

• reduzierte Qualitätsanforderungen

Serien-Steuergerät:

• laufzeit- und speicheroptimiert für verwendeten µC

• Integer-Arithmetik: Integer, Fixed point

• Vollständige Überwachungs- und Sicherheitsfunktionen

• Vollständige Qualitätsanforderungen



Hardware-in-the-Loop Simulation

















Systemtest: HiL, Fahrzeugversuch:Ergebnisprot., Versuchsberichte,

Parameterfestlegung


Parameterfestlegung



HW in the Loop



Hardware-in-the-Loop Simulation (HiL)

Hardware-in-the-Loop-Simulation mit Seriencode

Hardware-in-the-Loop-Simulation mit Seriencode




Seriencode, z.B. Leerlaufregelung

Seriencode, z.B. Leerlaufregelung

Zielhardware, z.B. Motronic-Steuergerät im Labor

Anwendung:

Seriencode zusammen mit Zielhardwareschnell, umfassend und kostengünstig testen.

I/O

SW-Funktionsmodell des umgebendenSystems in Echtzeit (= „SW-Loop“)z.B. Motor, Fahrzeug



Parameteroptimierung


















Parameterfestlegung


Parameterfestlegung



Parameter-Optimierung



Parameteroptimierungbereits in der

Funktionsentwicklungs- undPrototypenphase



Parameter sind „Variable“ in der Funktion (also auch im Programm), die der Anpassung an verschiedene Randbedingungen dienen.

z.B. Unterschiedliche Zündwinkel und Einspritzmengen einer Leerlaufregelung für verschiedene Motoren.

Die Parameter können bereits im frühen Entwicklungsstadium (Funktionsentwicklungs- und Prototypenphase) voroptimiert werden.

Im aufwendigen Motor- bzw. Fahrversuch (Applikation) erfolgt dann nur noch die Feinabstimmung und Überprüfung.




Grundsätze bei der Softwareentwicklung

• Software = Hardware, d.h. Software bei der Entwicklung wie Hardware behandeln und nicht darauf bauen, dass schnelle Änderungen in der Serie möglich sind.

• Gute Dokumentation ! Nicht nur das wie, sondern auch das warum !

• Möglichst durchgängige Kette von CASE-Tools (Computer Aided Software Engineering) von Spezifikation bis zur Generierung des Maschinencodes (z.B. von dSpace, ETAS).

• Gutes Projektmanagement mit sauberer Spezifikation und Software-Freeze(Änderungsstop).


Grundsätze


Bild 2.6_31 Quelle: Bosch

Film Steuergeräteentwicklung (13 min)


Funktionsentwicklung und Offline-Simulation FGR

FGR = Fahrgeschwindigkeitsregelung



SW- Modell der Regelstrecke: Fahrzeug mit Straße/Fahrwiderstand



SW- Modell des Reglers: PID- Geschwindigkeitsregler














Prototypen- oder Seriencode erzeugen:compilierter, gelinkter Maschinencode







Parameterfestlegung


Parameterfestlegung


Feldtest, Kundentest:Feldberichte, GarantiestatistikFunktions-

entwicklung + Offline-Simulation





Offline-Simulation(mit MATLAB/Simulink)


Offline-Simulation(mit MATLAB/Simulink)

SW-Reglermodell in grafischer Blockstruktur:

v-Regelung (PID)

SW-Streckenmodell des geregelten Systems:

Fahrzeug und Straße

Entwicklungssystem PC (Host)

Anwendung:

Funktion schnell und kostengünstig entwickeln und prüfen ohne Hardware !



Realer Fahrgeschwindigkeitsregler (Tempomat)

Bedienhebel

El. Steuergerät mit Regler

Drosselklappen-steller + Poti

Geschwindigkeits-sensor

+ -

Zündschalter

12 V

Schalter Bremse

Schalter Kupplung



Erstes Simulink- Modell für FGR

-Regler (PID)Fahrzeug-

und Straßenmodell

Sollwert-bildung

Stellgröße

Antriebs- und Bremskraft ZSollx&

Istx&

x&



Erweiterung des Simulink- Modells für FGR

-Regler

Fahrzeug-und

Straßenmodell

Sollwertbildung,Ein/Aus

Bedienhebel

StellgliedAntrieb/Bremse

-Sensor

Bedienhebel/ Schalterstellung

Stellgröße Antriebskraft ZSoll

Stellgröße Antriebskraft Zist

FahrerGaspedalvorgabe

Zsoll,Gas/Bremse

ZündschalterBremsschalter

Kupplungsschalter

Schalterstellung

htheoretisc,Istx&

gemessen,Istx&

Sollx&

x&

Istx&














Prototyp- oder Seriencode erzeugen:compilierter, gelinkter Maschinencode







Parameterfestlegung


Parameterfestlegung



Parameter-Optimierung








Parameter sind bei der FGR z.B. die Regler-Parameter für den PID-Geschwindigkeitsregler (Kp, Ki ,Kd).

Die optimale Kombination dieser Reglerparameter kann ermittelt werden, indem in einem Batch-Durchlauf (z.B. über Nacht) sehr viele Varianten systematisch durchsimuliert werden.

Optimierungskriterien können dabei sein z.B. stationäre Regelabweichung, Schnelligkeit des Einschwingens bei Sollgeschwindigkeitssprung oder die Amplitude unerwünschter Überschwinger.



Rapid Prototyping


















Parameterfestlegung


Parameterfestlegung



Rapid Prototyping



Rapid Prototyping: Notwendige Software und Hardware (Beispiel)

Simulation: MATLAB/Simulink/StateflowSimulation: MATLAB/Simulink/Stateflow

Codegenerierung: Real-Time WorkshopCodegenerierung: Real-Time Workshop

Linker + Compiler (hardwarespezifisch)Linker + Compiler (hardwarespezifisch)

Real-Time Hardware

Experiment Software (hardwarespezifisch)Experiment Software (hardwarespezifisch)

I/O

Reale Welt

Modell als C-Code + Treiber teilweise hardwareabhängig

Modell als Blockdiagramm hardwareunabhängig

Single-board modular Entwickl.-SG 2. PC (xPC)

externer C-Code

externer C-Code

z.B. schon vorhanden



Rapid Prototyping





Zielsystem:reales Fahrzeug

auf der Teststrecke

Zielsystem:reales Fahrzeug

auf der Teststrecke

Entwicklungs-Steuergerät mit Input/Output(CAN, digital I/O,...)

Entwicklungs-Steuergerät mit Input/Output(CAN, digital I/O,...)

Prototypen-C-Source-CodePrototypen-C-Source-Code


Anwendung:

Schnell die Funktion auf realen Prototypen testen und weiterentwickeln !

I/O

SW-Funktionsmodell des FGR grafischer Blockstruktur

SW-Funktionsmodell des FGR grafischer Blockstruktur

Download

+-Compil. Prototypen C-CodeCompil. Prototypen C-Code 1001

0011



FGR - Prototyp im Entwicklungssteuergerät im Fahrzeug

Bedienhebel

Entwicklungs-Steuergerät mit FG-Regler

Motronic-SGGeschwindigkeits-sensor

+ -

Zündschalter

12 V

Schalter Bremse

Schalter Kupplung

CAN

Rapid Prototyping Software

(compilierter C-Code)

Rapid Prototyping Software

(compilierter C-Code)

- Download C-Code - Parametereinstellung - Messdatenerfassung

Notebook:





















Parameterfestlegung


Parameterfestlegung






Optimiertes SW-Funktionsmodelldes FGR in graf. Blockstruktur

Optimiertes SW-Funktionsmodelldes FGR in graf. Blockstruktur

Serien-C-CodeSerien-C-Code

Compilierter SeriencodeCompilierter Seriencode

Generierung von Maschinencode für die Serie (Seriencode)




Anwendung:

Funktion schnell und fehlerfrei in Seriencodeumsetzen.

Compilierter Seriencode der FGR

Compilierter Seriencode der FGR

Zielhardware: Serien-FGR - Steuergerät

Download10010011



FGR im Ziel-(Serien)-Steuergerät im Fahrzeug

Bedienhebel

Serien-SG mit FG-Regler

Motronic-SGGeschwindigkeits-sensor

+ -

Zündschalter

12 V

Schalter Bremse

Schalter Kupplung

CAN

- Download Serien-Code - Parametereinstellung -Messdatenerfassung

Notebook: über Diagnose-Schnittstelle

CompilierterSerien-CodeCompilierterSerien-Code



Beispiel Fahrgeschwindigkeitsregelung


















Parameterfestlegung


Parameterfestlegung



HW in the Loop



Hardware-in-the-Loop Test des FGR – Systems: Hardware

Bedienhebel/ Schalterstellungen

CAN-Schnittstelle

HW-Nachbildung der Schaltsignale von•Bedienhebel•Zündschalter•Bremsschalter•Kupplungsschalter

FGR - SG

Host, Bedienrechner

xPC(Echtzeit-Simulation)

+ -

Digital Output

CAN

I/O-Karte



Hardware-in-the-Loop-Prüfstand für Bremssystem


Documents

Der moderne Funktions- und Softwareentwicklungsprozessnosper/public/Download/Kapitel 2.6... · Moderne Tools wie z.B. MATLAB/Simulink bei dSpace oder ASCET-SD von ETAS benutzen dazu