Vorlesung „Embedded Software-Engineering im Bereich Automotive“

Transcrição

Vorlesung
„Embedded Software-Engineering im Bereich
Automotive“
Technische Universität Dresden, Fakultät Informatik,
Professur Softwaretechnologie
WS 2008/2009
Dr. rer. nat. Bernhard Hohlfeld
[email protected]
Dr. B. Hohlfeld: Embedded Software-Engineering im Bereich Automotive, TU Dresden, WS 2008/2009
1
Inhalt
1. Motivation und Überblick
2. Grundlagen Fahrzeugentwicklung, KFZ-Elektronik und Software
3. Übersicht Automotive Elektrik/Elektronik-Entwicklung (E/E)
4. Protokolle und Bussysteme
5. Betriebssysteme und standardisierte Systemarchitekturen
6. Verfahren für die Embedded Software Entwicklung
7. Unterstützungsprozesse für die Embedded Software Entwicklung
8. Wichtige Normen/Standards/Empfehlungen für die Embedded Software Entwicklung
2
1. Motivation und Überblick
1. Bedeutung der Automobilindustrie für die deutsche Volkswirtschaft
2. Motivation Automotive Software Engineering
3. GI-Fachgruppe Automotive Software Engineering
4. Software Entwicklungsprozess
5. Standards zur Softwareentwicklung
6. Software Architekturen
7. AUTOSAR
8. Lessons Learned
3
1. Bedeutung der Automobilindustrie für die
deutsche Volkswirtschaft
• Beispiele
• Daimler Nutzfahrzeuge
• MercedesBenz
• BMW Group
4
Daimler Nutzfahrzeuge
Umsatz 2003
Deutschland
6.942
24%
USA
7.969
28%
Übrige Märkte
13.606
48%
Gesamt 28.517 Mio. €
5
Daimler Nutzfahrzeuge
Mitarbeiter 31.12. 2003
Deutschland
47.473
50%
USA
17.651
19%
Rest der Welt
29.938
31%
Gesamt 95.062
6
MercedesBenz
Umsatz 2003
Übrige Märkte
6.557
13%
Japan
2.399
5%
USA
10.932
21%
Deutschland
16.875
33%
Westeuropa (ohne D) 14.683
28%
Gesamt 51.445 Mio. €
7
MercedesBenz
Mitarbeiter 31.12. 2003
Übrige Länder
8.204
8%
USA
2.191
2%
93.756
90%
Deutschland
Gesamt 104.151
8
Zum Vergleich: BMW-Group im Jahr 2004
• BMW Group
wichtigste Automobilmärkte 2004 in % vom Absatz
• USA
24,5%
• Deutschland
23,5%
• Grossbritannien
12,0%
• Rest
40,0%
• Automobilproduktion der BMW Group im Jahr 2004 in Tsd.
• Dingolfing
304,3
• Regensburg
262,5
• München
172,2
• Deutschland
739,0 (59%)
• Ausserhalb
Deutschland
511,5 (41%)
• Quelle: Geschäftsbericht 2004 (Kurzfassung)
9
2. Motivation Automotive Software Engineering
10
A nice car
Source: Dr. Michael Reinfrank, Siemens VDO Automotive
11
A powerful engine
12
A look inside
13
Software is the intelligent “glue” for systems
Engine
ECU
Piezo
Common Rail
Injector
Electrohydraulic
Shift Gear
Actuator
Camshaft
Phasing
Adjuster
Optimization of
Shift Comfort and
Engine Set Point
Lower Fuel
Consumption and
Raw Emissions,
Improved Torque
Conical
Metal
Substrate
Integrated
Air Fuel
System
HPDI Pump
ProdMod
Transmission
ECU
Improved
Emission Treatment
NOx Sensor
Pressure
Supply
SINOx Catalytic
Converter
Heated
Catalytic
Converter
14
The intelligence inside: 5000 pages Software
15
Add code to add functions
16 bit ECU
Sequential
Injection
Knock control
Lambdasensor
8 bit ECU
electonic
ignition ECU’s
St. Cylinder-bank
detection
Hall based speed
sensor
Closed coupled
catalyst
FBS3
C-Language
programming
ETC/ Safety
TLEV
Emissions
OBD-2
Diaggnostics
VANOS (inlet
and outlet)
Cruise
control / ASC
FBS3
torque
structure
FTK & AAD
HPDI option
VLC option
SULEV
ETC / Safety concept
ACC
ULEV Emissions
32 bit ECU
OSEK operating
system
HPDI
stratified
System
16
Steigender Software Anteil
Bei modernen Fahrzeugen wird die
Funktionalität zunehmend durch Software
bereitgestellt. Das Spektrum reicht von der
Motorsteuerung bis hin zum Allradantrieb und
vielleicht schon bald zu X-by-Wire-Systemkomponenten. Die zugrundeliegende
Rechnerarchitektur ist ein verteiltes System, das
je nach Fahrzeugtyp aus 20 – 80 Steuergeräteknoten besteht. Die Knoten sind mit bis
zu vier verschiedenen Bussystemen
verbunden. Der Programmcode umfasst
mehrere hunderttausend bis zu mehreren
Millionen Zeilen. Über zwei Drittel aller
Innovationen im Automobil sind schon heute
softwarebasiert. Ein Anstieg der Softwareentwicklungskosten an den gesamten
Entwicklungskosten von derzeit ca. 4% auf über
10% wird prognostiziert. Ein Automobil bündelt
so auf ca. 5m x 2m viele Fragestellungen der
Informatik, insbesondere der Entwicklung
komplexer und zuverlässiger Softwaresysteme.
17
3. GI-Fachgruppe
Automotive Software Engineering
http://www.gi-ev.de/fachbereiche/softwaretechnik/ase/
18
Ziele der Fachgruppe (1)
• Motivation
• Das Thema „Automotive Software Engineering“ ist insbesondere in Deutschland und Europa von ständig
wachsender Bedeutung, die Automobilindustrie ist bereits heute ein entscheidender Innovationstreiber im
Bereich der eingebetteten Systeme.
• Langfristig sind intensive Anstrengungen erforderlich, um den deutschen Wettbewerbsvorsprung bei
software-basierten Innovationen im Automobil zu halten.
• Die Automobilindustrie wird deswegen in weiter zunehmendem Maße ein wichtiger Anwender der Informatik
und ein wichtiger Arbeitgeber für Informatiker sein.
• Das Gebiet wirft spezifische interessante Forschungsfragen auf.
• Die stärkere Berücksichtigung des Gebiets in der Lehre ist zu erreichen.
19
Ziele der Fachgruppe (2)
• Vorgeschichte
• Workshops zum Thema „Automotive Software Engineering“ auf der ICSE und der GI-Jahrestagung (jeweils
seit 2003) ermöglichten einen intensiven Austausch zwischen der Automobilindustrie und der
wissenschaftlichen Community.
• Insbesondere die Darstellung und Diskussion des State-of-the-Art im Software-Engineering in der
Automobilindustrie lieferte wertvolle Anforderungen an die zukünftigen Handlungsbedarfe und
Forschungsschwerpunkte auf diesem Gebiet, und aktuelle Forschungsergebnisse konnten einer breiten
automobilen Öffentlichkeit vorgestellt werden.
• Die Fachgruppe „Automotive Software Engineering (ASE)“ wurde auf Antrag von Dr. Klaus Grimm im Februar
2005 vom Präsidium Gesellschaft für Informatik eingerichtet. Die FG ist dem
Fachbereich Softwaretechnik zugeordnet. Sie hatte am 21. September 2005 im Rahmen
der GI-Jahrestagung in Bonn ihre Gründungsversammlung.
• Ziel der Fachgruppe „Automotive Software Engineering“ im Fachbereich Softwaretechnik der Gesellschaft für
Informatik (GI) ist der intensive fachliche Austausch zwischen der Automobilindustrie und der wissenschaftlichen
Community.
20
Leitungsgremium (LG)
der FG „Automotive Software Engineering"
Universitäten
Industrie
• Prof. Dr. Manfred Broy
TU München
Stellvertretender Sprecher der Fachgruppe
•
Dr. Klaus Grimm
DaimlerChrysler AG
Sprecher der Fachgruppe
• Prof. Dr. Stefan Jähnichen
TU Berlin und FhG FIRST
•
Dr. Alexandre Saad
BMW Group
• Prof. Dr. Dieter Rombach
TU K‘lautern und FhG IESE
•
Dr. Michael Reinfrank
Siemens VDO
• Prof. Dr. Stefan Kowalewski
RWTH Aachen
•
Dr. Thomas Kropf
Robert Bosch GmbH
21
WS Automotive Software Engineering
• Die Fachgruppe veranstaltet regelmässig den Workshop „Automotive Software Engineering“ im Rahmen der
Jahrestagungen der Gesellschaft für Informatik.
• 11. September 2008 in München
Organisation: Dr. Reinhard Stolle, BMW Car IT
• 27. September 2007 in Bremen
Organisation: Dr. Michael Reinfrank, Siemens VDO
• 5. Oktober 2006 in Dresden
Organisation: Dr. Michael Daginnus, Volkswagen AG
• 21. September 2005 in Bonn
Organisation: Dr. Thomas Kropf, Robert Bosch GmbH
• 23. September 2004 in Ulm
Organisation: Dr. Bernhard Hohlfeld, DaimlerChrysler AG
• 30. September 2003 in Frankfurt
Organisation: Dr. Alexandre Saad, BMW Group
22
4. Software Entwicklungsprozess
23
Software Entwicklungsprozess
Produkt-Entwicklungsprozess
24
25
Systemsicht
26
Abbildung auf V-Modell
27
Detaillierung V-Modell
28
Einordnung in Produktentstehungsprozess
29
Softwareentwicklung in der Produktentwicklung
Vorleistungsphase
InitialPhase
60
Serienentwicklung
Vorber.Phase
Konzeptphase
54
38
AbstimmPhase
Monate
30vor SOP
BestätigungsPhase
ReifePhase
23
8
Serie
0
SoftwareEntwicklung
SoftwareModifikation
Komponenten-/Teilsystementwicklung E/E
I-400
LH-Entwicklungsziel
Anforderungsmanagement
A-TS
Funktions-Anforderungen
VS
SW-Anforderungen
Funktionsentwicklung
Softwareentwicklung
SIL bestimmt
Funktionsarchitektur
SW-Entwicklungsprozess
definiert
SW-Architektur
I-300
A-TS
BBG
I-200
A-TS
I-100
A-TS
EBG
IX.Y: Integrationsstufe
A-TS: Abgabe Teilsystem
BN-KSP: Bordnetz-Konzept-System-Prototyp
EBG: Entwicklungsbaugruppe
BBG: Bestätigungsbaugruppe
VS: Vor-Serie
BNKSP
30
Prototyp und Produkt
31
Rapid Prototyping und Test in realer Umgebung
32
Testvarianten im Integrationsprozess
• MIL
Model in the Loop
• SIL
Software in the Loop
• PIL
Prozessor in the Loop
• HIL
Hardware in the Loop
• K-HIL
Komponente
• S-HIL
System
• VIL
Vehicle in the Loop
• EFP
Erweiterte Funktionsprüfung
33
Konsequenzen für die Softwareentwicklung
34
Anforderungen an Entwickler
35
5. Standards zur Softwareentwicklung
36
Reifegrad-Standards / Qualitätsstandards
• CMMI
• Bewertung durch Level, sehr generisch
• Beschreibung was zu geschehen hat, aber nicht wie es zu geschehen hat
• ISO 15504 SPICE / Automotive SPICE
• Level direkt vergleichbar mit CMMI
37
Entwicklungsstandards
• ISO 12207 AMD 1
• international
• sehr generisch
• Detaillierung erforderlich
• V-Modell 97, V-Modell XT
• national
• konkret
• anleitend
• beschreibt Dokumente
• VDA AK 13
• gute Definitionen
• informativ
• unverbindlich
38
Sicherheitsstandards
• IEC 61508 / ISO 26262
• weite Verbreitung
• Detaillierung erforderlich
• MISRA Guidelines
• Spezifika des Automobilsektors
• RTCA DO-178B
• konkret
• präziser als IEC 61508
• luftfahrtspezifisch
• EN 50128
• pragmatisch
• benutzerfreundlich
• Def Stan 00-55
• klares Rollenkonzept
39
ISO WD 26262
(Automotive E/E Sicherheitsengineering)
• Ziele
• Die ISO WD 26262 ist ein Normentwurf von Vertretern der Automobilindustrie für Sicherheit elektronischer
Fahrzeugsysteme.
• Nächste Folie:
• Gesamter Lebenszyklus nach ISO WD 26262
• Quelle
• http://keng.ke.ohost.de/ISOWD26262(AutomotiveE.ESicherheitsengineering).html
40
Lebenszyklus nach ISO WD 26262
41
Anpassung der Standards für Automotive
• Ziele
• verbindlicher Standard für die Entwicklung von Steuergeräte-Software beim OEM wie bei den Lieferanten;
• Berücksichtigung von Sicherheitsanforderungen;
• Formulierungen von Prozessen, Aufgaben und Produkten;
• Gewährleistung des internationalen Stands der Technik.
• Vorgehen
• Gewährleistung des internationalen Stands der Technik durch Abstützung auf internationale Normen, wie z.
B. CMMI, ISO 12207 und IEC 61508;
• Anpassung und ggf. Ergänzung an die OEM-Belange.
• Ergebnis
• Wichtige Basis für das SW-Qualitätsmanagement
• Planungsgrundlage für SW-Entwicklungsprojekte
• Verbesserung der SW-Qualität
42
Anpassung der Standards für Automotive
• Beispiel
• BMW Group Standard embedded Software (GSeSW)
• Quelle
• http://www.dspace.de/ww/de/gmb/home/company/events/4ankon/bmw_riedesser_rissling.cfm
43
BMW Group Standard embedded Software (GSeSW)
• ist eine Anpassung der internationalen Normen an die Rahmenbedingungen beim OEM und den Lieferanten;
• muss für die Anwendung in Projekten beim OEM und den Lieferanten weiter konkretisiert werden;
• fasst Anforderungen an die Software-Entwicklung aus unterschiedlichen Quellen zusammen;
• stellt Anforderungen an die eigentliche Software-Entwicklung und Anforderungen an begleitende Prozesse;
• gewährleistet den internationalen Stand der Technik.
Der GSeSW
• beschreibt keine Systementwicklung;
• gibt keine technischen Lösungen vor;
• ist keine vollständige Sicherheitsnorm, sondern deckt nur die Anforderungen an die Software ab.
44
HIL-FlexRay
BMW Group
EE-40
Page 4
Regulations to Take into Consideration
BMW Group Standard embedded Software
Informational
1. Application area
2. Normative links
3. Definitions/abbreviations
4. Structure of this standard
5. Key processes
6. Supporting processes
6.1 Project management
5.1 Project preparations
6.2 Filling of roles
6.3 Documentation
6.4 Configuration management
5.2 Software development
6.5 Quality assurance
6.6 Verification process
6.7 Test process
5.3 Software modification
6.8 Carrying out reviews
6.9 Problem resolution process
7. Organizational processes
7.1 Selection and qualification of SW tools
7.3 Continual improvement
7.2 Selection and qualification of SW libraries
7.4 Training and qualification
Appendix
A. Guideline for the selection of methods and measures
B. Assigning the SIL to the software
C. Literature
Each chapter of the “key processes” section relates to chapters of ISO 12207 and IEC 61508.
45
• ist eine Anpassung der internationalen Normen an die Rahmenbedingungen beim OEM und den
Lieferanten;
• stellt Anforderungen an die eigentliche Software-Entwicklung und Anforderungen an begleitende Prozesse;
Der GSeSW
46
Generische Ebene
SW-Engineering
OEM-Ebene
Rollen
Modelle
Capability & Maturity
(CMMI)
SW-Safety
ergänzende
ergänzende
Standards:
MindestAnforderunge
Methoden
OEM-spezifischer Standard
Für Lieferanten
Hausintern
Projektebene
Zulieferer Projekt
OEM Projekt
SW Tools and
SW Safety
Requirements
SW System
SW Safety
Validation Plan
47
• ist eine Anpassung der internationalen Normen an die Rahmenbedingungen beim OEM und den Lieferanten;
• stellt Anforderungen an die eigentliche Software-Entwicklung und Anforderungen an begleitende
Prozesse;
Der GSeSW
48
IEC 61508
ISO 12207
CMMI
Generische Ebene
OEM Group Software
Embedded Software
OEM Methoden- und WerkzeugeHandbücher
Spezielle Methoden und
Werkzeuge
GS Emb SW
MW HB
OEM SoftwareDokumentations-Standard
SDS
DokumentationsVorlagen
Annex A-E
Annex A-O
OEM Ebene
z.B. Anforderungen, Architektur,
Modulentwurf, …
Spezifikationen
Pläne
Berichte
OEM Projekte
z.B. SW-Projektplan, ModulTestplan…
z.B. Modul-Testbericht, …
49
6. Software Architekturen
50
Software Architekturen
Voraussetzung für Software Wiederverwendung
51
Evolution der Software Architekturen
52
Was ist Softwarearchitektur?
53
Was ist Softwarearchitektur?
•
Architektur beschreibt den Aufbau eines Systems aus seinen Komponenten und deren Wechselwirkungen
•
•
Architektur gibt Systemen Struktur und Gestalt
Architektur strukturiert komplexe Systeme mit vielen Komponenten und macht sie überschaubar
•
Die Fahrzeug Software Architektur beschreibt den im Rahmen einer definierten Zielvorstellung besten Aufbau
eines Fahrzeug Software Systems.
54
Wozu Softwarearchitektur?
•
•
•
•
•
Software Architektur macht die Komplexität zukünftiger Software Systeme mit vielen wechselwirkenden
Funktionen durchschaubar und beherrschbar
• ... und begünstigt damit den Bau zuverlässiger Systeme
Software Architektur zeigt mehrfach verwendbare Komponenten eines Software Systems auf
• ... und schafft damit eine Grundlage für baureihenübergreifende Software Systeme
Software Architektur zeigt Wechselwirkungen und Schnittstellen zwischen den Teilen des Software Systems auf
und beschreibt diese
• ... und schafft damit u.a. die Grundlage für die Plug&Play-Fähigkeit zukünftiger Architekturkomponenten
Software Architektur liefert die Grundlage für
• flexible,
• updatefähige und
• erweiterbare
Software Systeme im Fahrzeug.
55
Ziel von Softwarearchitekturen
Komponentenbasierte Software Architektur
Mehrplatzsysteme
Freies Deployment
Hot Code Loading
Load Balancing
Auftrennen von
Hardware und Software
Qualität
Ressourcen Management
Legacy System
Support
Auftrennung von Spezifikation
und Implementierung
Kosten
Entwicklungszeit
56
Komponenten Architekturen
Monolithische
Applikation
Applikation
Verteilte Applikation
V/C
Komponenteninfrastruktur
M
Kommunikationsinfrastruktur
“Plattform”
V/C...View/Control
M...Model
Gestern
Heute:
Vernetzte Systeme
Morgen: Dynamische
Komponentensysteme
57
Offene System Architektur
58
7. AUTOSAR
59
AUTOSAR
An industry-wide initiative to manage the complexity of emerging Automotive E/E-Architectures.
The Partnership intends to establish a
de-facto standard for an Automotive
Open System Architecture (AUTOSAR)
for all functional domains across the
automotive industry to which all partners
are committed.
60
OEM 1
Exchangeability
between
manufacturer’s
applications
Platform 1.1
Platform 1.2
Platform 1.n
Exchangeability
Supplier A
 Chassis
 Safety
OEM 2
Supplier B
 Chassis
 Safety
 Body/Comfort
 Telematics
 Multimedia
 Multimedia
between
supplier’s
solutions
Supplier C
OEM m
 Chassis
 Body/Comfort
 Telematics
 Multimedia
Exchangeability
Platform 2.1
Platform 2.2
Platform 2.n
between
vehicle
platforms
Platform m.1
Platform m.2
Platform m.n
Our vision is an improved complexity management of highly integrated E/E architectures through an
increased reuse and exchangeability of SW modules between OEMs and suppliers.
Dr. B. Hohlfeld: Embedded Software-Engineering im Bereich Automotive, 61
TU Dresden, WS 2008/2009
59
AUTOSAR
as
sis
Ch
t*
ilo
top
Ma Man
Int chi
erf ne
ac
e
a
*
Body
Comfort
Au
tiv
e
Ac
y )
fet ssive
e/p
tiv
ia
ed s
ltim tic
Mu lema
Te
r gt.
ive M
Dr tion
ma
or
Inf
Implementation
of OEM-specific
applications
based on AUTOSAR
Sa
(ac
Su
sp
en
Engine
n
itio
nd ’
Co ion
le nit
hic og
Ve Rec
sio
n*
Valve Control *
Personalization*
* Example of domain specific application
Future transferability of functions
The primary objective of AUTOSAR is to create an infrastructure
which encourages cooperation on E/E standards while maintaining competition on innovative applications.
62
AUTOSAR Abstraktionsstufen
Physical Interface:
Car velocity
Car
functionality
Electrical Interface:
Isensor [0..200mA]
ECU
Electronics
Sensor
get_v( )
Application
SW-C
Electrical Interface:
UECU [0..5V]
ECU_get_I(SensorPin)
Sensor
SW-C
µC
Peripherals
DIO_set(Multiplexe)
ECU
SW-C
SPAL
(HAL Driver)
ADC_get(MultiplexCh)
API X
could be standardizable but
standardisation of lower
API’s is meaningful anyway
API Y
could be standardizable
API Z
should be standardizable
63
AUTOSAR Komponenten
Automotive Open System Architecture:
•
Standardized, openly disclosed
interfaces
•
•
•
HW independent SW layer
Transferability of functions
Redundancy activation
AUTOSAR RTE:
by specifying interfaces and their
communication mechanisms, the
applications are decoupled from the
underlying HW and Basic SW, enabling
the realization of Standard Library
Functions
*
for example: OSEK, QNX, VxWorks, Windows CE, …
64
AUTOSAR Architekturkonzept
65
8. Lessons Learned
66
Standardisierungspotential
Baureihenübergreifende Entwicklung
Baureihenspezifische
Entwicklung
Standard
Software
Funktions bibliothek
Funktions integration
HW-unabhängige
SW-Plattform
Funktionsmodule
Adaption
und
Ergänzung
Innovation
Adaption und
Integration
OEM mit
SG- oder SW- Zulieferer
OEM mit
SG- Zulieferer
67
Auswirkungen Qualitätsmängel
Fahrzeug /
Komponenten
Lastenhefte
Start
Erprobung/
Dauerlauf
Fahrzeugentwicklungsphase
Start
Pilotserie
Anlaufphase
SOP
Erstes Kundenfahrzeug
Serienphase
Steigende Fehlerfolgekosten „Zehner-Regel“
68
Auswirkungen Qualitätsmängel
• Fahrzeugentwicklungsphase
• Verzögerungen Integrationstest
• Nacharbeit im Prototypenaufbau durch Flashen bzw. Teiletausch
• Kompensation von entfallenen Erprobungsumfängen
• Anlaufphase
• Software-Reifegradprobleme,
• Verbau nichtkompatibler SW-Versionen
• mangelndes Zusammenspiel zwischen Onboard- und Offboardsystemen
• Erhöhung der Montagezeiten sowie erhebliche Nacharbeitsumfänge (Flashen, Gerätetausch)
• Kompensation von entfallenen Erprobungs-/Dauerlaufumfängen
• Serienphase
• Hohes Änderungsaufkommen
• Kundenunzufriedenheit
• Rückrufe
•
Produkthaftungsfälle
69
Top 5 Risiken Embedded Software
• Optimierte Verteilung und Vernetzung von Systemen im Fahrzeug
• Funktionsspezifikation verteilter Systeme
• Qualitäts- und kostenorientierte Kooperation mit n Lieferanten für m Module
• Gestaltung des Entwicklungs- und Integrationsprozesses
• Software-Updates/Upgrades im Feld
70
Reihenfolge Top 3 Maßnahmen
Ordnung schaffen
• Software-Entwicklungsprozesse mit Fahrzeug- und SG-Entwicklungsprozessen koppeln
• Releasemanagement bezüglich der Einsteuerung von SW-Versionen in Fahrzeug-Baulose
• Konfigurationsmanagement bei Software
Änderungswesen organisieren
• Änderungsmanagement fahrzeugseitig
• Änderungsmanagement lieferantenseitig
• Änderungsstopps klar kommunizieren, ggf. eskalieren
Transparenz schaffen
• Objektive Meßgrößen zur Bewertung des SW-Reifegrades einführen
• Anflugkurven zur Beschreibung der Erwartungswerte definieren
• Nicht nur das Fehleraufkommen, auch die Testabdeckung, die Fehlerbehebungszeiten bzw. die Zuverlässigkeit
der Fehlerbehebung liefern wichtige Erkenntnisse
71
Zusammenfassung
• Durch steigende Komplexität wird Software-Qualitäts-und Prozeßmanagement zum elementaren Bestandteil des
Fahrzeugentwicklungsprozesses.
• Die Schwerpunkte des Fahrzeugherstellers liegen hierbei auf den Spezifikations-, Integrations- und Testschritten
• Grundlegende Voraussetzungen für die effiziente Durchführung sind:
• Synchronisation der SW-Entwicklungstände aller Steuergeräte mit den Meilensteinen und
Freigabeprozessen der Fahrzeugentwicklung.
• Konsequente Durchführung Änderungsmanagement.
• Bewertung und Steuerung des Software-Reifegrades auf Basis eines Reifegradbewertungsprozesses mit
objektiven Meßgrößen.
• Wichtige Grundlage ist die Standardisierung nicht wettbewerbsrelevanter Software Umfänge.
72

Vorlesung „Embedded Software-Engineering im Bereich Automotive“

Transcrição

Documentos relacionados

Starten auch Sie mit uns in eine erfolgreiche Partnerschaft

- Eissmann Automotive

Vorlesung „Embedded Software-Engineering im Bereich Automotive“

Bundeswehr im Standort Dresden,vertreten durch die Offizierschule

Zulieferer Interieur Deutschland/Österreich

Elektronik im Kraftfahrzeug

Zahlen und Fakten - IAA 2015 Media Information

Wegbeschreibung Hotel Residenz Alt Dresden

Flyer 4 Seiten.indd

Grundlagen des Testens Kapitel 1 Einführung