Automotive Software Engineering at Hella KGaA. Software Engineering for Software Intensive Systems,

Automotive Software Engineering at Hella KGaA

Overview

„Automotive Software Engineering“

Hella body electronics

The process of product development

Software-Engineering of mechatronic/embedded systems

Vehicle centric domains

Powertrain

Engine management and transmission control

Only a few powerful ECUs (often with floating point unit)

Many sensors and actuators

Robust due to rough environmental conditions

Suspension (Vehicle Dynamics)

Antilock braking system, tire pressure control, power steering

Also: brake-by-wire or steer-by-wire

High level of safety requirements

Rough environmental conditions

Chassis

Comfort: head lamps, air conditioner, central locking system, seat- and exterior mirror control

Passive safety: airbag, restraint system

Many ECUs with low(er) performance

Widely spreaded, often only small installation space

Many variants (optional equipment)

Business Division Automotive Electronics GE

Product Lines and Business Divisions

PLE-4: Lighting Electronics

PLE-8: : Actuators PLE-6: Sensors

PLE-7: Relays, Horns and Fanfares

PLE-2: Special Manufacturing PLE-3: Body Electronics PLE-1: Body Electronics

BHTC

INTEDIS

Spanning functionalities: Driver Assistance

Example: „Parking Assistance

System“

Uses ultrasonic sensors

Steers the car

No linear

acceleration/decelaration

(yet)

Here: simulation which uses the

Software Development Process

ISO 15504 / SPICE Processes

ENG 1.4 Software construction ENG 1.6 und 1.7 System integration and testing Engineering proccesses ENG 1.1 System requirements analysis and design

ENG 1.3 Software design ENG 1.2 Software requirements analysis ENG 1.5 Software integration Review Review Review Review Review Review

MAN 2 SW Project Management Management process Support Life cycle processes Customer process

SUP 2 SW Configuration Management

SUP 3 SW Quality Assurance

CUS 1.3 Sub-supplier Management

SUP 8 Problem Resolution

Review Review Review Review Review

Product Development Process

Phase 7:

Qualifification of Product / Process

SOP Offer/ order Phase 2: Quotation-Phase Requests

Development & Detailing Phase Phase 5:

Means of Production Build

Phase 6:

Qualification of MoP and Components Phase 8: Pre-Series Launch / SOP G a te 1 G a te 2 G a te 3 G a te 4 G a te 5 G a te 9 G a te 6 G a te 7 G a te 8 Produkt Release Phase 9:

Relieve of Proj. Team Phase 1: Bid/No-Bid Decision

Structured content

Parallel in timeline

Milestone oriented

QCT-/ target-oriented

Bid:

• Financial bidding

• Description as exactly as possible • Deadlines (Releaseplan)

Prerequisite:

• Coarse grain architecture

• Information/data of former projects • Constraint Solver ??

Decision:

• In the meantime further development

(Phase 3)

Releaseplan:

• A Sample: Prototype

• B Sample (B1..Bn): growing functional range/testing depth

analysis Software Software System qualification Software design integration System and test Implementation of software and test System analysis Integration of modules M Real loads Emulator Doors CTE/Tessy HMI Simulation Model Based Development Code-Generator PDM MKS

Product quality by process quality

(

Tool centric) Overview: SW engineering of mechatronic systems

CANoe

Exchange of requirements and specifications

User-requirements Software Hardware Construction

System-requirements Test-specifications

Customer

External DOORS-DB

Import/Export

Shared Parts

Hella-internal Parts

Hardware HW-Teil 3 HW 3 .... ... HW-Teil 2 HW 2 HW-Teil 1 HW 1 Beschreibung ID System-Requirements Pflicht Z UR 9 .... ... Pflicht Y UR 7 Pflicht X UR 6 Beschreibung ID

Requirementsmanagement

Representation and tracing of dependencies

User-Requirements Anforderung C UR 3 .... ... Anforderung B UR 2 Anforderung A UR 1 Beschreibung ID Software SW-Teil 3 SW 3 .... ... SW-Teil 2 SW 2 SW-Teil 1 SW 1 Beschreibung ID

Modules

(Documents)

Objects

(Requirements)

Links

:

A

B means

„A satisfies B“

„A verifies B“

etc.

Objectives of requirements management

Particular objectives: Handle complexity:

Detect indirect dependencies

Estimate effort

Plan realization

Trace requirements (in both directions):

Check completeness

Complete documentation

Test coverage on requirements level

Impact analysis Requirements

Requirements DesignDesign ImplementationImplementation

Example: Part of Standard Core

• appprox. 200 Requiremtns

• appprox. 50 SW-analysis objects • appprox. 30 SW-design objects • appprox. 20 SW-functions

• 3 SW-modules

• more than 1.000 Dependencies!

Example: Part of Standard Core

• Only 4 documents

• appprox. 200 Requiremtns

• appprox. 50 SW-analysis objects • appprox. 30 SW-design objects • appprox. 20 SW-functions

• 3 SW-modules

• more than 1.000 Dependencies!

Developing an analysis model

Refinement of Requirements

SysML

analysis Software Software System qualification Software design integration System and test Implementation of software and test System analysis Integration of modules M Real loads Emulator Doors CTE/Tessy HMI Simulation Model Based Development Code-Generator PDM MKS

Product quality by process quality

(

Tool centric) Overview: SW engineering of mechatronic systems

CANoe

(Shell-)Model of an ECU

CPU Core

RAM

ROM, EPROM, Flash Serial/parallel IO-Channles Counter/ Timer Watch-dog RT-channels Extension -bus Sleep-mode DMA & Interrupts A/D-Converter

Driver

Driver

Handler

Handler

Application/Manager

Application/Manager

A typical software-architecture

Layered architecure

• Reusable software components

• HW-independent

• Represents functionality of periphal devices

• Project and HW-specific configuration

• ECU-specific

• Often: (runtime-)optimized code

• but mainly standardized interface

Software architecture

Modular architecture - concept for ECU - software at Hella

(Physical) Hardware OSEK

I/O Driver _{CAN NM CCP Flash E²PROM}

Boot-loader

OEM functions

ECU-functions

Standard-components Monitoring level (optional)

Standard-diagnosis

Driver and Handler ECU-specific diagnosis Library-routines Logcal Actors Hardware Abstraction Layer

Logical Sensors B a s e S o ft w a re A p p li c a ti o n S o ft w a re

analysis Software Software System qualification Software design integration System and test Implementation of software and test System analysis Integration of modules M Real loads Emulator Doors CTE/Tessy HMI Simulation Model Based Development Code-Generator PDM MKS

Product quality by process quality

(

Tool centric) Overview: SW engineering of mechatronic systems

CANoe

Functional Analysis

• Better understanding of WHAT we

have to to

• Innovator (SA)

• Telelogic TAU, Rhapsody (UML)

• Simulink, ASCET

• Statemate

• ...

• Reduction of complexity

• Better undestanding of the

depedencies in terms of data-/control-flow • SA, SA/RT • UML • Block-Diagrams

Objectives:

Methods / Notations:

Tools:

Structure Ediotr

Traditional vs. Model Based Design/Implemetation

Innovator Simulink

Simulation (by using models of

the environment)

Interactive testing by

employing user interfaces

Model Based Software Engineering

analysis Software Software System qualification Software design integration System and test Implementation of software and test System analysis Integration of modules M Real loads Emulator Doors CTE/Tessy HMI Simulation Model Based Development Code-Generator PDM MKS

Product quality by process quality

(

Tool centric) Overview: SW engineering of mechatronic systems

CANoe