Specification and Design of Electronic Control Units

Jrgen Bortolazzi, Thomas Hirth, Thomas RaithDaimler-Benz AG F1M/E

D-70546 Stuttgarte-mail: bortolazzi@str.daimlerbenz.com

Abstract

Electronic control units (ECU) play a more and moreimportant role in the development of road vehicles.Forecasts lead up to 25% of the total vehicle value in2000. The increasing complexity and stringent qualityand cost requirements mandate tremendousimprovements in the specification and design process.This paper presents the cooperative activities at Daimler-Benz research and Mercedes-Benz developmentdepartments to install an optimized design process.

1 IntroductionIn order to improve safety, to reduce emmission and

fuel consumption or to improve comfort and driverinformation, a rapidly increasing number of vehiclecomponents are controlled by open-loop and closed-loopsystems, which consist of sensors, actuators andelectronic control units (ECU). Typical examples arepowertrain control systems such as engine andtransmission management, active suspension and brakingsystems such as ABS (Anti Blocking System) and ABC(Active Body Control) or navigation systems. Thedevelopment process of such systems is illustrated infigure 1, where three major levels can be identified:1. the mechatronic vehicle system, such as an engine

management consisting of the engine, sensors andactuators as well as the ECU

2. the ECU typically consisting of a standardmicrocontroller (e.g. Siemens 80C167), specificsignal processing and controller ICs as well as thenecessary packaging, power supply and powerelectronics components

3. the control software, consisting of open-loop andclosed-loop control algorithms, communication andmanagement functions as well as onboard diagnostics.

The requirements on the performance of ECUs haveincreased dramatically over the last ten years: Fromisolated control units simply controlling specific vehiclecomponents in the 80s to autonomous communicatingsystems in the 90s and finally fully integrated, higlyinterconnected systems executing distributed controlalgorithms for the next vehicle generation. In order tointelligently manage this evolution, the Mercedes-Benz(MB) strategy for electronic vehicle system designconsists of four major aspects:1. minimization of cost2. ability to manage complexity3. maximization of reliability4. optimization of functionality.

This strategy mandates a systematic design processwhich takes into account the workshare betweenmanufacurer and supplier. From the point of view of thecar manufacturer, system design is the essential key to anintelligent management of a design process which isheavily restricted by time-to-market, quality and costaspects as well as the recognition of competitiveadvantages. Therefore, a car manufacurer has to have asmuch information about a vehicle system as is necessaryto intelligently decide about system architecture anddevelopment depth of the components. Last but not least,system integration test as well as the preparation ofdiagnostics and service information has to be done underthe responsibility of the car manufacturer.

Traditional design cycles are characterized by anumber of aspects: nonformal descriptions of requirements and design

results heterogeneous and inconsistent design data long iteration cycles, typically mandating vehicle

validation tests and supplier involvement.Currently, new design methodologies provide the basis

for the optimized execution of existing and future vehicledevelopment projects. Major components are:

EURO-DAC 96 with EURO-VHDL 960-89791-848-7/96 $4.00 1996 IEEE

SystemSpecification

SystemSimulation

Development ofHW /SW

Specification

PrototypeDevelopment

CalibrationVehicle

Validation

Release toManufacturing Manufacturing

FunctionalTest Service

HWDesign

HWSimulation

PrototypeAssembly

DesignVerification

Release toManufacturing Manufacturing

FunctionalTest

AutocodePrototyping

SWCoding

Static andDynamic Test

Development ofControl Algorithms

and OnboardDiagnostics

Car programrequirements

Emmission lawsStrategic

requirements

10s + 10s+5+

-

+

Specification and Design Manufacturing Service

MechatronicVehicleSystem

ElectronicControlUnit (HW)

EmbeddedRealtimeSoftware

void main(){...}void initialization(){...}sta tic void control (input, states, output){...}

Figure 1. Concurrent development processes for mechatronic vehicle systems

Process reengineering and measurement based qualityimprovement methods

Sophisticated design data and documentationmanagement

Increasing formalization of specification and designdescriptions

Multi-level, mixed-mode system simulation underreal-time constraints including mechanical,hydraulical, pneumatical, electrical and electronicalparts

Continuous support for specification, design, rapidprototyping, test, manufacturing and service.

For automotive development processes, it is veryimportant to take into consideration the interactionbetween manufacturer and supplier. As described byClark and Fujimoto in [1], three major scenarios have tobe distinguished (figure 2): Detailed development of the ECUs is performed by

the supplier companies. The manufacturer selectscomponents based on his overal car concept and dueto cost, performance or strategic aspects. The know-how is mainly avalaible at the suppliers organization.

Detailed DevelopmentSupplier

CarConcept

CarManufacturing

ComponentConcept

Component

PrototypeImplementation

Production

ComponentSelection

SpecificationDesign

Black-BoxComponents

CarConcept

CarManufacturing Component

PrototypeImplementation

Production

SpecificationDesign

SpecificationDesign

Car Test

Detailed DevelopmentManufacturer

CarConcept

CarManufacturing

Component

PrototypesSupplier

Production

SpecificationDesign

Car Test

Implementation

Manufacturer Supplier Manufacturer Supplier Manufacturer Supplier

Figure 2. Scenarios of manufacturer/supplier interaction

In the case of black-box components, themanufacturer performs a detailed specification and avalidation (through simulation and test) of thecomponents, whereas the supplier implements theECU based on these specifications. Details about theimplementation are not available at themanufacturers organization.

Detailed development is performed by themanufacturer. The suppplier implements theprototypes based on the detailed specs or supplies abasic hardware/software level where the manufacturerimplements his algorithms.

Among the numerous ECUs integrated in modernvehicles, each of these development scenarios can befound. In every case, the level of detail of the informationthat is exchanged has to be clearly defined. In the MSRproject [2], several levels of information and productexchange are identified:1. requirements documentation, e.g. based on SGML

(Standard Generalized Markup Language)2. specifications on different levels, FMEA (Failure

Modes and Effects Analysis) /FTA (Fault TreeAnalysis ) data

3. prototypes (HW and SW) and functional test patterns4. source code5. object code6. ECUs and related test patterns.

Regarding the hardware and software components ofan ECU, one could distinguish between the scenariosillustrated in table 1. Black-box scenarios will be used forstandard functions like ignition control. The grey-box andwhite-box scenarios are the favorite strategies for futureelectronic vehicle system design in the case of functionsrelated to competitive advantages.

Black-Box Grey-Box White-BoxFunctionalSW Modules

Supplier Manu-facturer

Manu-facturer &SW suppliers

OperatingSystem & I/O

Supplier Supplier SW supplier

Hardware Supplier Supplier HW SupplierTable 1: HW/SW interfaces for different

cooperation scenarios

The following chapters will describe the developmentand installation of the specification and design process inmore detail. Chapter 2 will describe reengineeringactivities as the basis for a systematic optimization of thedesign process. Chapter 3 will describe methods and toolsused in already optimized processes. Chapter 4 willdescribe status and trends in electronic vehicle systemarchitectures and Chapter 5 will provide future directionsand a conclusion.

2 Process ReengineeringTo avoid local optimization of design processes

without taking into account the real problems in thedesign cycle, the introduction of new methods and toolsin the MB development departments is based on asystematic reengineering and quality improvementapproach. Design processes are analyzed and modelledwith respect to relevant activities, related parties as wellas necessary information, manpower and technologyresources. Dedicated metrics and questionnaires providesupport for the identification and realization of necessaryprocess improvement. Due to the lack of referenceprocesses for automotive system design, much effort isspend to develop a specific approach, particularily basedon approaches found in [3]-[7].

The first reengineering analysis obviously showedsignificant potential for improvement through theintroduction of system design methodologies and toolssuch as1. requirements capture and guided editing as well as

standard formats for requirements and designdocumentation

2. usage of formal, executable models as well as systemsimulation to detect problems early in the design cycle

3. establishing rapid prototyping the development ofpowerful prototyping platforms as well as codegeneration from executable specification models

4. systematic validation and verification activities forintegration and module test as well as vehiclevalidation.

The introduction of formal, executable specificationmodels showed to be the backbone of the newdevelopment process. However, the underlying methodswere not established in the development departments andthe tools significantly lack integration in the existingmethod and tool environment. The lack of an appropriatesystem design methodology for distributed realtimesystems lead to unsatisfying results. Furthermore,introducing these approaches into the complex concurrentengineering process performed by MB and its suppliersshowed to be the major problem. Due to this situation, anextended strategy is now established:1. A major effort concentrates on adapting the methods

and tools to vehicle specific aspects. This includes amodel schema representing the functional andarchitectural aspects specific to distributed electronicvehicle systems. Furthermore, vehicle specific modellibraries as well as interfaces for integrating existingfunctionality are developed.

2. Significant effort is spent to adapt the modelizationand description languages to vehicle specific needs. Astyle guide is under development that includes

a specific methodology for developing vehiclecontrol functionality and to distribute it among anoptimized architecture of electronic control units

readability and layout rules for modelization totake into account that models are stilldocumentation in the first place (readabilitybefore executability)

strictly formal semantics for language subsets usedfor safety critical applications such as steer-by-wire

integration into the infomation technology process,e.g. integration with SGML-based requirementsdocumentation including requirements traceabilityor integration with CAN (Controller AreaNetwork)-specific development tools, especiallybus simulation, communication matrix as well asspecific estimation and optimization tools

integration of code generation into a generalrealtime platform based on an scalable realtimeoperating system including autocode from othertools, realtime execution and communication aswell as test pattern databases and data recordingcapabilities

integration with diagnostics tools integration with man-machine interface

development tools.3. The adaption of code generation from executable

models showed to be too much restricted bytraditional vehicle system architectures. Therefore,new architectures including a standard realtimeoperating system and client/server approaches areunder development.

3 Methods and ToolsBased on proprietary activities in different vehicle

manufacturer and supplier companies, a joint cooperativeaction, the MSR project, was established to define aspecification, design and test methodology that providesdefinition of external actuators and sensors, interfaces ofthe system to be designed, the internal functionalstructure of the system as well as the realtime behavior ofthe single functions. This approach was realized using anintegrated environment including the tools commercialtools Statemate [8] and MatrixX [9]. Several pilotprojects have been performed:1. cruise control,2. transmission control3. engine management.

Based on these pilot applications, the methods andtools are currently used in several development projects: interconnected car body systems CAN gateway

central locking systems active gearbox systems transmission control active suspension systems active braking systems.

These applications mandate the consideration of openloop and closed loop control behaviour as well as systemcommunication. It is worth noting that analog modellingis used to represent both the internal controller behaviourand the engine and vehicle environment. In the MSRproject, a prototype coupling of Statemate and MatrixXwas developed to be able to simulate complex systemscontaining open-loop and closed-lop aspects as well as amodel of the vehicle, the engine or the transmission. Theintegration of tools is performed at several levels:1. Method integration: the combination of different tools

mandates a disciplined approach to modelling andinterfacing. In the MSR project, functionaldecomposition using data flow diagrams is separatedfrom behavioral modeling using state machines,differential or difference equations, lookup tables oralgebraic equations or any combination of these.

2. Tool integration: The combined simulation ofdifferent models mandates a coupling of the executingsimulation engines. In the MSR project, directcoupling or the usage of simulation backplanes (likesoftware busses) were considered. Coupling ofsimulators requires open interfaces as well assynchronization mechanisms.

3. Code integration: Tools providing code generation(AutoCode) can be used to integrate models on codelevel. Code generated from one tool can be integratedinto another tool and code generated from differenttools can be linked and executed on a PC, workstationor a prototype realtime platform.

The specification and design methodology is based onthe following aspects:1. continuous requirements tracing2. integrated approaches to model-based specification of

closed-loop and open-loop aspects (figure 3)3. a systematic approach for function- vs. component

oriented design4. rapid prototyping5. hardware-in-the-loop test.

The model based specification of the embeddedrealtime control functions is based on a specificmethodology consisting of functional specification of control aspects

independently from architectural aspects includingusage of reusable function models

distribution of control and datapath based on theselected architecture including generation of relatedcommunication prototcols based on the CANstandard.

INIT IDLE

ERROR

PROCESS

IDLE

ON

REQUEST

SUSPEND

ERR/OFF

OFFDIAGPROC

C/ERR RES

PROC

OFF

IR

OPEN LOOPCONTROL

ONBOARDDIAGNOSTICS

COMMUNICATION

10s + 10s+5+

-

+

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AA

AA

AA

AA

AA

AA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

AAAA

A

A

A

A

A

A

A

A

A

A

A

ENVIRONMENTVEHICLEDRIVER

CLOSED LOOPCONTROL

SIGNALPROCESSING

Figure 3. Integrated specification and test environment

4 System ArchitecturesThe design of an optimized system architecture for

electronic vehicle systems is influenced by function, cost,weight, packaging and placement and powerconsumption.

Motor CAN

Car Body CANGateway

Figure 4. Current network architecture fordistributed vehicle control functions

Traditional ECU development was very muchinfluenced by the mechanical units. As a result, numerousstandalone ECUs such as ignition control, injectioncontrol, or transmission control evolved. The nextgeneration, introduced in recent car models such as thenew E-class, system integration into major functionalunits such as complete transmission control unitsintegrated into the packaging of the mechanicaltransmission component are realized. Several bus systemsincluding high speed CAN for realtime functions likeengine and transmission control and low speed CAN forcar body and comfort functions are installed (fig. 4). Thenext generation will introduce integrated powertrainmanagement systems followed by autonomous drivingand brake-by-wire or steer-by-wire systems. A standard

realtime operating system will also be part of futureECUs.

A major improvement will be based on client/serverarchitectures (fig. 5), which allow an optimized usage ofthe resources available in the car. This approach enablesthe flexible implementation of a specified functionality onalternative constellations of processing power in the car.It is important to notice that safety critical applicationslike ABS and closed loop control applications mandatespecific strategies in this scenario.

...

Server

Cl ient 1

e.g., engine

management

Cl ient 2

e.g., transmission

management

N

Figure 5. Client-/Server architectures for futureelectronic vehicle systems

Rapid prototyping is a very important aspect in thevehicle development process. Although vehiclesimulation coupled with executable models of ECUspecifications provide significant improvement in theearly design phases, vehicle validation is absolutelynecessary due to two major facts: the complex nonlinearities found in vehicles and its

environments, e.g. combustion engines or varyingroad characteristics

The feeling of the driver that can only roughly berepresented by driver models.

To be able to provide a multi-level prototypingenvironment, powerful realtime systems consisting ofPowerPC processors, realtime operating system, VMEbased interconnection to sensors and actuators, anexisting ECU for existing functionality as well as online

simulation, calibration and measurement functionality isessential for vehicle prototyping (figure 6). It is importantto notice that especially the transfer of calibration datafrom specification to design and implementation is amajor risk factor in the ECU development process.

Calibration System

Development PlatformSUN SolarisPC WindowsNTMatrixXSTATEMATEAutoCodeGNU C Compiler/LinkerHardware Connection EditorData Acquisition Editor

VME-Bus

Ethernet-Controller

MS-DOS PCTAG System MonitorKleinknecht...

PCMCIA Shared Memory

PowerPC 604Microprocessor

PowerPCProgram Memory

LynxOS /OSEKSchedulingAutoCodeI/O Tasks

I/O Cards

ECUPrototypesProductionSystems

Figure 6. Integrated Rapid Prototyping environment for ECU development

5 Conclusions and Future WorkThis paper gives an overview over the current

activities in the area of electronic vehicle system design.The dynamic evolution of these systems with respect togrowing functionality and an increased number of safetycritical functions mandates new methods and tools for thedevelopment as well appropriate system architectures forprototyping and productions systems. Future applicationsheavily demand the following improvements: Library based reuse of functionality and software. A systematic process for design and test of safety

critical applications including clear formal semanticsand certification for components used in safety criticalprocesses.

Open interfaces for model exchange and data accessfor specific optimization and processing.

Production code generation and interaction withtarget system instrumentation and debugging.

Sophisticated metrics and optimization strategies foronline project control.

References[1] Clark, Fujimoto. Product Development Performance,

Harvard Business School Press, Boston, 1991[2] K.G. Besel , T Hirth. Werkzeuge im MSR Projekt, VDI

Berichte Nr. 1009, 1992, pp. 503-516[3] ISO 9000-3: Guidelines for the Application of ISO 9001 to

the Development, Supply, and Maintenance of Software,Intl Org. for Standardization, Geneva, 1991

[4] ISO 9001:Quality Systems - Model for Quality Assurance inDesign/Development, Production, Installation, andServicing, Intl Org. for Standardization, Geneva, 1994

[5] M. Paulk e.a. Capability Maturity Model for Software,Version 1.1, Tech. Report CMU/SEI-93-TR-24, SoftwareEng. Inst., Pittsburgh 1993

[6] M. Paulk e.a. Key Practices of the Capability MaturityModel, Version 1.1, Tech. Report CMU/SEI-93-TR-25,Software Eng. Inst., Pittsburgh 1993

[7] Development Guidelines For Vehicle Based Software,MISRA Consortium, November 1994.

[8] Statemate, Product of I-Logix Inc., Boston, Massachussetts[9] MatrixX, Product of Integrated Systems Inc., Santa Clara,

California

CDROM Home Page1996 Home PageEURO-DAC96 Home PageFront MatterTable of ContentsSession IndexAuthor Index