A study of the current series projects together with the use of development capacities demonstrate that approximately 60% of the time spent on ECU development has to be devoted to creating the necessary software. For this reason, it is absolutely essential that modern tools and processes be used.
Development Process
Definition of Development Process A depiction of the development steps in the form of a V-model (Figure 1) serves as the basis for all software-development activities.
This model is used to detail the process steps which facilitate implementation within a product-development department.
Quality Assessment
Quality assessments are scheduled at defined points of the development process (Figure 2) for the purpose of process monitoring:
QA1
When: At the start of the project
What: Resource check (capacity, develop-ment environdevelop-ment, responsibility) QA1F
When: Prior to function implementation What: Function specification check
QA2F
When: After function implementation What: Review of each individual function
and checking of following docu-ments:
specification,
function description,
source code,
data definitions, and
test documentation.
QA2
When: Prior to software delivery What: Review of all QA2F documents QA3
When: Prior to start of series production What: Series-production review for
hardware and software
An essential part of the development process is also the distinction between specification and implementation. This separation allows programming by contract, whereby project teams use the software knowledge of ReUse teams who implement the functions (e.g.
Keyword 2000 protocol) for various cus-tomers. To this end, the project teams write out function contracts which establish the boundary conditions of implementation.
The scopes and levels of testing of the indi-vidual functions are determined in the pro-ject-specific quality plan (PQSP) with the customer requirements in mind.
78 Electronic Control Units (ECUs) Software Development
Specification Function analysis specification
Function initialization Function analysis specification Development process in detail
2
æ
UTS0326EThis also includes determining the QA x F scopes.
The PQSP is a central element of project im-plementation and should be fully discussed between vehicle manufacturer and supplier.
It lays down, among others things, the re-sponsibilities, the customer relationships, the development tools, the scopes of testing and documentation, etc.
The process in the ReUse team is set out as follows:
In order to ensure that the created software can be reused to the greatest possible extent, there are C-programming guidelines bind-ing an all programmers which are called up in the relevant reviews (e.g. QA2F).
Programming Guidelines
In any heterogeneous system of develop-ment that is spread over countries and continents, a standardized procedure for creating software is a vital and integral part of the time to market process. These guide-lines address the following points and are binding for all programmers:
general guidelines (terminology, vocabu-lary, variation handling),
guidelines for software developments in C (templates, structure),
definitions and declarations (include, defines, typedefs),
check instructions (if, for, while, break, return ...),
coding specifications and instructions (typecast, arithmetic, pointer),
particular features when using variables (alignment, address),
instructions on data consistency (preemptive), and
instructions on resource relief.
These guidelines also serve as a source of knowledge for effective code configuration in order to counteract the limitations in relation to memory capacity and run time in the programming of microcontrollers.
Electronic Control Units (ECUs) Software Development 79
The person in charge of the project formulates the task (if necessary, adoption of customer request).
The function contract is drawn up (with details of task, project, desired date, scope, and reference documents) and given to the ReUse teams.
The persons in charge of ReUse and the project discuss the application and establish the scopes and deadlines together.
The person in charge of ReUse decides on the variant and version handling and implements the task.
All documents are handed over to the person in charge of the project on completion.
Tools for Creating Software
As well as the formal aspects such as process and programming guidelines, it is crucially important to ensure that the tools are subject to constant support in the interests of product quality. Figure 3 provides an overview of the tools currently used for the various development phases. Significant features of this tool chain are:
constant support throughout the entire development process and
product-specific, optimized solutions with tools partly developed in-house.
As the wide variety of tools demonstrates, the process involved in creating the software for an ECU of the latest generation is highly complex. Figure 4 provides a simplified overview of the interplay between the indi-vidual tools from the specification through to the finished ECU program.
By way of example, two component parts of the tool chain will now be explained in closer detail:
Design with ASCET-SD and
Vehicle simulation with TCM-Simutec.
80 Electronic Control Units (ECUs) Software Development
ASCET-SD StP
Proto-typing Implemen-tation
Design Test
Organization: MS Project
ASCET-SD
ESPRIT Innovator Codewright DAMOS++
ASCET-SD INCA-PC TCM- LabCar ASCET-LabCar
Documentation: MS Word Tools in the development process
3
æ
UTS0327EKey:
ASCET: advanced simulation and control engineering tool
ASCET-SD: ASCET software developer StP: software through pictures
(Aonix) for OO modeling ESPRIT: engineering software-production
user interface for tools Innovator: Software-development
environment (MID) Codewright: Software-development
environment (Premia) DAMOS: database for
microcontroller-oriented systems
INCA-PC: integrated car application system TCM-Simutec: Vehicle simulator
ASCET-LabCar: Vehicle simulator for HiL simulation ClearCase: Configuration-management tool
ASCET-SD Function model
Object model
Source files
ETC program ASCET-SD
ESPRIT
INCA/PC Prototyping
Code generation Design
Test/application Simplified process sequence
4
æ
UTS0328EFunction design with ASCET-SD
5
æ
UTS0329YDesign with ASCET-SD
ASCET-SD (Figure 5) offers the following functions for designing software:
interactive creation of function descriptions and function models,
a graphical user interface,
support of object-oriented design, data-flow-oriented design and state machines.
The ERCOSEKoperating system is an inte-gral part of the development environment, and facilitates real-time simulation of the function model.
ASCET-SD offers the following support for the rapid prototyping of functions:
ASCET-SD operates as a bypass computer for the series ECU, i.e., individual ECU functions run on the PC, while the other functions continue to be executed by ETC (Figure 6).
The connection is established via the CAN or the INCA probe.
The next step is the automatic C-code cre-ation and the crecre-ation of the corresponding data files for the application from the models.
For further information, log on to http://www.etas.de
Vehicle simulation with TCM-Simutec To test the functions of a transmission-control system in the laboratory, there is a simulator for the vehicle and transmission environment which provides the input signals for ETC. One such simulator is shown in Figure 7.
The front panel of the simulator is equipped with assorted rotary potentio-meters, switches, and pushbuttons which enable input variables such as output speed, selector-lever position, transmission temperature, etc., to be specified.
The top of the simulator accommodates a breakbox which permits access to every ECU pin. Measuring instruments can be easily connected to these sockets to enable, for example, a PWM signal of a pressure-regula-tor output to be viewed on an oscilloscope.
The laboratory car also contains com-puter cards which simulate the other ECUs in the vehicle network (e.g. ECUs for engine management, for ABS, etc.) and also their signals.
Process and Maturity Model A clear definition of the development process and the corresponding implementa-tion in the projects are made possible by a software development which can be evalu-ated with a maturity model such as CMM (capture maturity model).
Electronic Control Units (ECUs) Software Development 81
Fig. 6
1 ASCET-SD and INCA-PC 2 ASCET hardware
(ETAS ES 1000.2) 3 ETK
4 ETC-Simutec (laboratory car) 1
2
3 4 Test setup for ASCET-SD in bypass
6
æ
UTS0330YTCM-Simutec (laboratory car)
7
æ
UTS0311YSoftware Structure
The software structure described in closer detail in the following is implemented within the transmission-control system.
This layer model (Figure 8) comprises
the application software (transmission software) with program library provided by the vehicle manufacturer or supplier (in this case by Bosch),
the operating system,
the component driver, and
the hardware.
The separation of hardware and application software ensures that the software can be easily ported to new hardware platforms.
Only the second layer, consisting of the operating system and component driver (BIOS), has to be adapted.
The contents of the individual layers will now be broken down in the following:
The ECU hardware, the first layer of the software layer model, consists of the micro-controller (here, by way of example, the MPC555), the memory, the interfaces (SPI, CAN and UART), and the peripheral chips (ASICs):
The operating system with its services and the hardware-compatible software are implemented on this hardware:
The interface layer and program library for the application software contain:
The application software (customized software) comprises:
Operating System
It is absolutely essential to use an OSEK-conforming operating system to fulfill the current real-time demands on an ECU. The ERCOSEKoperating system from ETAS is used in Bosch transmission control units (available for all kinds of microcontroller).
An operating system is subdivided into processes and tasks (Figure 9):
A process is a function which has no call or return parameters.
A task consists of different processes and is characterized by
the sequential execution of processes,
the allocation of processes task,
each task being assigned a priority,
tasks being assigned to a time base.
For task changing, there is either cooperative scheduling or preemptive scheduling (task management):
Cooperative Scheduling
In the case of cooperative scheduling, a task can only be interrupted between two processes by a higher-priority task (Figure 10).
82 Electronic Control Units (ECUs) Software Development
CPU core timer and
SPI TPU MIOS CAN
(2) UART (2) Memory, hardware, driver, etc.
Operating system Program
library Transmission software from vehicle manufacturer or Bosch
Component driver
Hardware Software layer model
8
Device Device Device
driver driver driver
Diagnosis
EEPROM KWP2000 Shift by wire
handling application functions
e.g. ASIS (RB/ZF) AGS (BMW)
Transmission software
Software sharing (interface)
The advantages of this procedure are low memory requirement (register banks, stack), simple management, and data consistency.
The disadvantages are the limited response time (dependent on the process run time) and the jitter over the task period.
Preemptive Scheduling
Owing to the drawbacks of cooperative scheduling, preemptive scheduling is used in operating systems which operate as real-time systems.
With this form of scheduling, a higher-priority task can interrupt a lower-higher-priority task at any time (Figure 11). The advantages of this procedure are the very short response times, the minimal jitter over the task
period, and a response time that is not dependent on process implementation.
The disadvantages are increased memory requirement (stack, register banks) and data-consistency problems.
Mixed Scheduling
ERCOSEKoffers the option of mixing both types of scheduling in one application.
A combination of hardware and software scheduling serves this purpose. Figure 12 shows the distribution between cooperative and preemptive using the priorities assigned to the tasks.
A software call starts the operating sys-tem. It can support different application modes (e.g. different task sets for
initializa-Electronic Control Units (ECUs) Software Development 83
Time t
Task
Task A
Task B p1B p2B p3B p4B
p1Ap2A p3A p4A
Activation Task B Start Task B Cooperative task change
10
æ
STS0333Ecooperative preemptive
Distribution Hardware-based scheduling
Software-based scheduling
Priority
Priority distribution
12
æ
STS0335EProcess 1 Task
Process 2 Process 3
…
Prozess n Processes and task
9
æ
STS0332ETask A
Task B p1B p2B p3B p4B
p1A p3A p4A
Time t Activation
and start Task B
Task
Preemptive task change
11
æ
STS0334Etion, operation and ECU run-on, Figure 13).
Each application mode consists of an initial-ization phase and an execution phase. Inter-rupts are prohibited during initialization of an application mode.
Further documents on the subject of ERCOSEK/ OSEK can be found on the Internet at:
http://www.etas.de http://www.osek-vdx.org Acquisition of Input and Output Variables
Access to the hardware is obtained within the framework of the software layer model in accordance with three layers (Figure 14):
user layer,
configuration layer, and
hardware layer.
The first implementation example to be featured is access (A) via global RAM cells.
Table 1 describes the name of the RAM cell, the signal direction (input or output), the signal type (analog, digital, frequency, or PWM), the description, and the physical conversion.
The second example featured is access via (B) function interfaces. Table 2 is structured along the same lines as Table 1, but here the global RAM cell is replaced by a function call.
The objective in the configuration layer is to obtain independence from platform and project in the conversion of the hardware accesses into real software. This is achieved on the one hand by using tools which auto-matically create the C-code for access to the hardware, and on the other hand by using C-macros which are then resolved on a processor-specific basis.
84 Electronic Control Units (ECUs) Software Development
User layer
Configuration layer
Hardware layer
"Low-level"-channels Configuration:
Access to hardware channels
Filtering:
Elimination of malfunctions
Coherence:
Data timing Scaling:
Conversion into physical variables
ADC DIO PWM SPI Serial Freq Access to hardware capsule:
via global RAM cells
as direct access (function call) Hardware access in the layer model
14
æ
STS0337EApplication
Mode n+1 Mode n
Mode ExecutionInit
Zeit t
Execution Init
Application-mode change
13
æ
STS0336EA further signal-acquisition component involves the exchange of signals via the communication interface. The CAN bus (controller area network) has gained acceptance in this field in the last few years.
CAN replaces the conventional wiring harness or the previously standard network of ECUs (Figure 15). The bus system must satisfy the following requirements here:
Real-time updating for
safety functions: 10 ms Convenience functions: 10...100 ms Maximum cable length: 40 m
Electronic Control Units (ECUs) Software Development 85
Fig. 15 a Conventional b With CAN Table 2 Table 1 Hardware access via global RAM cells
1
RAM cell I/O Type Content Scaling
ugt_Batt In ANA 16 bit Battery voltage 0...25 000 mV
CGT In ANA 8 bit Oil temperature –40...+215°C
ccu_Chip In ANA 8 bit Substrate temperature –40...+215°C
fgt_Fet Out DIG 8 bit Status HSD-Fet 0.. 1 (On/Off)
fpo_L1 In DIG 8 bit Selector lever pos 1 0..1 (On/Off)
fpr_PinM In DIG 8 bit M button 0..1 (On/Off)
NAB In FREQ 16 bit Output speed 0...20 000 rpm
NAB32 In FREQ 8 bit Output speed/32 0...255 rpm/32
NTU In FREQ 16 bit Turbine speed 0...20 000 rpm
NTU32 In FREQ 8 bit Turbine speed/32 0...255 rpm/32
hmv1 Out PWM 16 bit Solenoid-valve output 0...1000 per mil
idr1s Out ANA 16 bit Nominal current 0..12 000 mA
pressure regulator
Hardware access via functions
2
Software function I/O Return value Content Scaling
GetHWIO_U_IgnRunCrnk() In ANA Battery voltage 0...32 V
16 bit
GetHWIO_T_TransOil() In ANA Oil temperature –40...+215°C
16 bit
GetHWIO_b_HSD() In ANA Status HSD-Fet 0...1 (on/off)
8 bit
GetHWIO_e_TapUpDwnReq() In ENUM Tip (+/–) function 0 x 00...0 x 40 8 bit
TsHWIO_PRNDL In DIG Transmission control panel 0...1
GetHWIO_s_PRNDL(void) 8 bit
TsHWIO_FreqParams In FREQ Turbine speed Time stamp +
GetHWIO_s_NTU(void) struct counter value
TsHWIO_NAB_DualEdgeParams In FREQ Output speed, Time stamp +
GetHWIO_s_NAB_DualEdge() struct edge can be changed over counter value + operating edge
SetHWIO_e_NAB_DualEdgeCptr Out – nout Rising, falling, both
Mode( BYTE ) Edge changeover
b
ECU 3 ECU 2
CAN - Bus
ECU 1 ECU 4
a
ECU 3 ECU 2
ECU 1 ECU 4
ECU network
15
æ
STS0338EThe system must also be resistant to temper-ature and moisture. The CAN bus has also gained acceptance in the field of automation technology. Table 3 lists the maximum pos-sible data rates for different cable lengths.
Figure 16 shows the circuit-engineering implementation of the CAN interface in an ECU.
In the microcontroller itself, message handling is conducted via a dual-port RAM (Figure 17). Since this RAM chip, as the name suggests, can be described from two sides (CAN transceiver and microcon-troller), the CPU workload is substantially relieved for signal transfer.
Complete arbitration (message organization, who sends what when) on the CAN bus is performed automatically by the CAN trans-ceiver. It does not require any computing power in the microcontroller (Figure 18).
A distinction is made within CAN messages between standard and extended data frames (Figures 19 and 20).
86 Electronic Control Units (ECUs) Software Development
Table 3
Maximum bit rate kbit/s Use of dual-port RAM with the CAN bus
17
æ
UTS0340ENODE A
NODE B
loses the arbitration switches to receive mode
Standard Data Frame Inter Frame Space
Arbitration Field
Data Length Code(reserved (D))IDE Bit(D)RTR Bit (D)
Identifier Field
Start of Frame Data Field CRC Sequence CRC Delimiter ACK Slot ACK Delimiter End of Frame Intermission Bus idle recessive dominant CAN standard data frame
19
Extended Data Frame Inter Frame Space
Arbitration Field
Data Length Code
RTR Bit(D) (2 reserved (D))
IDE Bit(R)SRR Bit (R)
Identifier Extended Identifier
Start of Frame Data Field CRC Sequence CRC Delimiter ACK Slot ACK Delimiter End of Frame Intermission Bus idle recessive dominant CAN extended data frame
20
æ
UTS0343EBit rates as a function of cable (bus) length
3
The standard data frame is characterized by the following data (Figure 19):
Data capacity: 0...8 bytes Identifier length: 11 bits Message length: max. 130 bits In contrast, the extended data frame (Figure 20) has the following characteristic data:
Data capacity: 0...8 bytes Identifier length: 29 bits Message length: max. 150 bits
Gear Selection and Adaptive Functions Transmission control has undergone various phases or expansion stages within the framework of development.
The basic functions and the adaptive programs for shifting points and pressure control are now standard in the field of electronic transmission control (ETC).
Where the various marques and vehicles differ is in the different strategies employed in the automatic adaptation of the trans-mission to the driving style and the traffic situation. This also represents an area of software which is being increasingly taken up by the vehicle manufacturer directly and which is no longer in the hands of a sup-plier. The adaptive functions for shifting-point control and pressure control have al-ready been discussed in the chapter sections entitled Shifting-Sequence Control and Adaptive Pressure Control.
The following text will now deal with Bosch-specific implementations of auto-matic adaptations (learn functions). The adaptive shifting strategy determines a gear cyclically from the driver command, the vehicle status, and the driving situation.
It is adaptive in relation to the driver type (sportiness) and also takes into account automatic or manual gear preselections (tip/nudge operation, as is familiar, for example, from Porsche Tiptronic©or BMW Steptronic©). The complete software package has been modeled with an object-oriented approach for optimum reuse.
Object-Oriented Approach Vehicle Control
As an introduction, Figure 21 shows the 1-2 US and 2-1 DS shift curves for a driving program.
The shift curves shown in Figure 22 extend this system for different driving programs from super economy (XE) to super sport (XS). They clearly show that the upshift point in the sporty driving program moves towards higher vehicle speed or higher engine speed and thereby achieves optimum utilization of engine performance.
Electronic Control Units (ECUs) Software Development 87
Fig. 21 and 22 1 Upshift 1
Accelerator-pedal position
0 50 100
%
Vehicle speed υF
0 30 km/h
2-1 RS 1-2 HS
1-2 US shift curve
21
æ
STS0344EAccelerator-pedal position
0 50 100
%
Vehicle speed υF
0 50 km/h
1
2-1 RS XE 2-1 RS XS 1-2 HS XE 1-2 HS XS
1-2 curve with several driving programs
22
æ
STS0345ETo select a shift curve using the driver type and the total running resistance, it is neces-sary for them first to be recorded and evalu-ated once. The overall structure of vehicle con-trol shown in Figure 23 serves this purpose.
On the one hand, there are the variables which determine the vehicle and its status:
transmission control panel (TCP),
the transmission itself,
the engine,
the accelerator-pedal position, and
the vehicle variables (e.g. vehicle speed,
the vehicle variables (e.g. vehicle speed,