Method Based on OSEK/VDX Platform Using Model-based and ...

Method Based on OSEK/VDX Platform Using Model-based and Autocode Technology for Diesel ECU Software Development MU Chunyang, SUN Lining and DU Zhijiang Robot Research Institute, Harbin Institute of Technology Harbin, Heilongjiang Province, 150001, P. R. China [email protected], [email protected], [email protected] CHEN Yanchun Science Research Dept., R&D Center, China FAW Group Corporation Changchun, Jilin Province, 130011, P. R. China [email protected] Abstract Recently, model-based and autocode technology has become mature and brings many advantages in automotive software development. In order to take advantage of these changes, organization must adjust development process. This paper proposes a “V+v” method, in which the process of code design and implementation are divided into two development processes (controller algorithms and software platform) in contrast to traditional “V” development process. Control engineers develop algorithm based on model, generate codes with autocoding tools and carry out tests with the same model via different kinds of simulations. Platform engineers design software development platform based on OSEK-compliant RTOS according to results of system functional analysis. During software integration & test phase, algorithm codes are “installed” into the platform and then they are linked and built together to create whole ECU software. The method has been used for diesel ECU software development in China FAW Group Corporation and the results demonstrate benefits.

1. Introduction More and more electronic devices are being used on automotive. ECUs are becoming more and more complexity, which brings challenges in time-to-market, cost, performance and reliability etc. And for the deeply embedded automotive application, there are many development tools to be used in ECU software development. ECU software engineers have to face a

big challenge during the process of design and integration of software [1]. In recent years, model-based and autocode technology has become more popular in automotive software development process [2][3]. It can reduce ECU development cycle and improve software quality. Reference [4] compared 3 kinds of tools for code generation and the analysis shows that efficiency and quality of generated c-code could compare with hand code. When developing a complex system, the integration with RTOS needs engineers with special design experiences and more skills. However, all ECU codes couldn’t be automatically generated during development process, e.g. low-level APIs, startup codes, debug codes and assemble codes etc. And there are lots of legacy codes still could be used. How to rapidly develop ECU software using new technology and existing resources has become one problem. Since it is necessary to make a reasonable development process. There are several software process models that are suit for different cases, e.g. waterfall model is used for the development process that has clearly and constantly requirements and evolutionary model considers iterative feature of development process and adapts to the requirement changes. In automotive domain traditional V-model is typically adopted, however, it doesn’t take into account the development of new technologies and tools. Reference [6] proposed a method that using “foundation software” accelerates development of embedded system. OSEK/VDX standard aims at an industry standard for an open-ended architecture for distributed control units in vehicles [5]. ECU software based on OSEK-compliant has little dependency with

31st Annual International Computer Software and Applications Conference(COMPSAC 2007) 0-7695-2870-8/07 $25.00 © 2007

hardware and has a good portability. So the reusability of codes could be improved. This paper proposes a “V+v” development method in contrast to the traditional “V” development process. We divide the process of code design and implementation into two parts: one is to develop new algorithms of controller, another is to build software platform. The method has been used for the software development of diesel ECU in China FAW Group Corporation. The following sections will show our development experiences learned from the project.

via different types of simulations; (b) software platform engineers design software development platform based on OSEK-compliant OS according to results of system functional analysis, which includes OSEK OS/COM, system boot code, exceptions handling code, hardware driver (API library) and calibration code etc. The software of platform and the generated codes will be integrated at “Software Integration & Test” process with other existing codes if existing. System Requirements

2. Fundamental method Different project and team need different software process model. And appropriate methods and tools can provide the capability for the success of project. The traditional V-model is shown as Figure 1. Functional analysis, software design, implementation and various kinds of tests are assigned to system engineers, control engineers, software engineers and test engineers respectively. There must have detailed and unambiguous interfaces described with a large number of documents. The algorithms from control engineers would not be verified until the complete of coding and some extent software integration. If there exists difference between the design of control algorithm and code implementation, it usually would occur a repeat process. And development cycle would become longer. Sometimes the work products of previous activity (rapid prototyping models) cannot be used in the next activity. So it will make a waste of intelligent labor. System Requirements

Functional Analysis Software Design

Test cases

Test cases

Test cases

System Integration Test

Verification & Validation Software Integration & Test

Implementation & Test

Figure 1 Traditional “V” development process

When model-based and autocode technology is used in diesel ECU development, the process should be suitable for the change. Figure 2 is the modified development process called “V+v” development process, which has two main differences from the old one: (a) control engineers develop controller algorithm based on model, generate code with the same model using autocoding tools and carry out tests for the code

System Integration Test

Test cases Test cases

Functional Analysis

Test cases

Modeling Autocode & Test

Verification & Validation Software Integration & Test

Development Platform Implementation & Test

Figure 2 “V+v” development process During the “V+v” development process, control engineers can do their works independently without intervention from other team members. Though TargetLink also provides OSEK interface, special OIL tools for configure OS provided by RTOS vendors still cannot be avoided [4]. And the configuration of RTOS is left for platform engineers who are better at this kind of work than control engineers. The following sections will describe the two-development processes in details.

3. Control algorithm development using new method During development process of new control algorithm, control engineers will need following tools shown in Table 1. Table 1 List of development tools used by control engineers Development process Modeling & Simulation Autocode & Test Algorithm Validation

Tools name Matlab/Simulink/Stateflow Matlab/Simulink/TargetLink/CME-555 Matlab/Simulink/Autobox

Figure 3 shows development process of new control algorithm with model-based and autocode method.

3.1 Modeling and model validation According to results of system requirements and functional analysis, control engineers break down the functions and design the control algorithm with modeling tools. This time the design of control

31st Annual International Computer Software and Applications Conference(COMPSAC 2007) 0-7695-2870-8/07 $25.00 © 2007

algorithm is executable. The model can be used in subsequent development activities with complete intention of control engineers and don’t need descriptive documents any more. In early period of development, control engineers can verify their artifacts compared with the specification of design requirements under the Matlab/Simulink environment via Hardware-in-the-loop simulation on Autobox of dSPACE. Thus the development speed is improved evidently. Simulink model

TargetLink model

Conversion

z

So it is necessary to convert data types. TargetLink provides the means to meet this requirement. Control engineer can use auto-scaling tool to scale all data automatically according to the ranges of data gained through simulations or maximum/minimum information from the inputs of engineers. (d) Partition the model into desired modules and specify the files that will contain generated codes. TargetLink provides a “Function” block with which control engineers can divide the total model into several functions and specify their parameters. Control engineers also can specify which file they will be written during generating process. (e) Generate product code with model. After having done all above steps, control engineer can generate the codes just by press one key.

3.3 Simulations and Tests

Hardware-in-the-loop Rapid Prototyping .c

.h

Unit testing with MIL, SIL & HIL simulation

Figure 3 Development process of new control

algorithm

3.2 Autocode generation TargetLink is a production code generator from dSPACE. Before generate the codes from the algorithm model, control engineers need do the following steps: (a) Model should be converted from Simulink model to TargetLink one. TargetLink provides block sets that are suitable for code generation and an automatic conversion tool with which the two kinds of model can convert each other. If the control algorithm model has already set up with TargetLink block sets, this step could be ignored. (b) If possible, make the best of data dictionary tool of TargetLink. The data dictionary is a container where engineers can maintain variables, data type definitions, scalings etc [7]. Control engineers should edit all data needed for the model in the data dictionary beforehand and then set up the mapping relations between the model and the data dictionary. The data dictionary separates the model from its data and can keep variables’ definitions consistent. Thus all control engineers could work independently without waiting for the artifacts from others. (c) Convert the data from float types to integrate arithmetic. In our project, MPC555, the microprocessor of diesel ECU, is used as fix-point arithmetic processor.

TargetLink provide 3 kinds of simulation modes including model-in-loop (MIL), software-in-loop (SIL) and hardware-in-loop (HIL) to support code test [7]. Control engineers can verify the generated codes according to all simulation results. If the codes couldn’t meet the specification of design, code generation and simulations should be done again. Thus the development of new control algorithm has been finished. We have made preparation for the whole software integration now.

4. Setup of development platform 4.1 Overview of development platform Application of Diesel ECU New Algorithm Code

Existing Algorithm Code

OSEK-Compliant OS Kernel

Boot Code

Exceptions Handling Code

Diagnostics Code

Calibration Code

OSEK COM Application Programming Interface Library

Diesel ECU (MPC555)

Software Development Platform

Figure 4 Structure of software development

platform for diesel ECU The embedded software development platform is made up of 5 basic elements: diesel ECU hardware; boot code and exceptions handling code; OSEKcompliant OS kernel and OSEK COM; API (application programming interface) library; and

31st Annual International Computer Software and Applications Conference(COMPSAC 2007) 0-7695-2870-8/07 $25.00 © 2007

diagnostic code and calibration code. They belong to 3 different layers (see Figure 4). (a) Diesel ECU hardware It is the physical base of embedded software development platform. At present, Flash memory is widely used in ECU hardware design. This has changed development method of calibration tools for ECU. And now production ECU could completely take the place of development ECU during designing control algorithms. We use directly diesel production ECU as ECU hardware in the platform. It gains the advantage over using simulator’s hardware because it can provide a real time environment and avoids the differences produced by different CPU at run-time. (b) Boot code and exceptions handling code Boot code is responsible for booting and loading system after power-on until OS gets the system control authority. Exceptions are handled by RTOS. So exceptions handling code means the interrupt vector. Here it is obligatory and will be used to build software development platform. (c) OSEK-compliant OS kernel and OSEK COM OSEK-compliant OS kernel is the basis of embedded software development platform and other OSEK/VDX components. Determinability, interrupt latency and context switch are the most important performances for OSEK OS. RTOS used by the platform is OSEKturbo OS for MPC5xx that is a commercial product from Metrowerks. OSEKturbo provides OSEKBuilder software for building OIL files and Ds-Design Tool for time analysis [8]. OSEKturbo has OSEK COM module, with which data in ECU can be transferred among tasks and consistency of data can be assured. (d) API library In the platform a set of low-level drivers are developed for various devices, including discrete or analog input/output (I/O), controller area network (CAN), serial communication interface (SCI), watchdog, memory (Flash and EEPROM) and drivers used as diagnosing actuators etc. These low level drivers are packed into high-level drivers that have standard interface definition in light of actual application purpose. And all these high-level drivers are organized one API library, which are a suit of object files. API library separates application software from ECU hardware and improve portability of application code. (e) Diagnostic code and Calibration code Testing, diagnosing and calibrating are important aspects of ECU software development. Diagnostic code occupies a large proportion of the whole ECU software. So reusability of it would effect the time of release. Calibration code is implemented according to

CAN calibration protocol (CCP). The host software of calibration tools is CANape that is a commercial product from Vector. The calibration tools can be used for test, modify and calibrate application in run-time and can prompt software development efficiency.

4.2 Design of development platform All elements described above can be linked and compiled without algorithm code and the target file can run directly if we program it into ECU hardware. So this platform can be used as engineering build during development process. It conceals all codes in relation with hardware from algorithm development personnel. The key issue of the platform design is to configure OSEK-compliant OS. Control Algorithms

Diesel Engine Software Architecture TASK(TenmsTask) { Input Processing(); Output Processing(); } TASK(FuelMassCalTask) { Fuel_Mass_Calculation(); Timing_Compensate(); }

OS Configuration CPU Container

T

I

!

12

3

. OS . Task . ISR . Alarm . Resource . Com . Counter . Event . Message

Figure 5 Software framework design process

The design procedures of platform are as follows (see Figure 5): (a) Acquire software architecture requirements. According to diesel engine and functional analysis results platform engineers set down the design requirements of software architecture. (b) Design specification of software architecture. Platform engineers should know how many modules required by the new algorithm and how to invoke them could meet control requirements. (c) Configure OSEK OS statically. It includes the following steps: Step 1: Determine the number of tasks ECU software needs. In order to decrease the CPU total load, the number of tasks should be less. Step 2: Specify properties for each task, e.g. whether it belongs to task level or ISR level. If one task were ISR level, it would run in an interrupt service routine, otherwise in a task. Step 3: Select scheduling policy. OSEKturbo OS provides 3 types of scheduling policies, which are nonpreemptive scheduling, full-preemptive scheduling and

31st Annual International Computer Software and Applications Conference(COMPSAC 2007) 0-7695-2870-8/07 $25.00 © 2007

mixed-preemptive scheduling [8]. To some extent, fullpreemptive scheduling can increase the CPU’s utilization. Step 4: Allocate priorities for each task. Each task should have and only have one priority level. Step 5: Analyze the relations among all tasks, for example, whether a task has auto-start property and uses alarm, message and event objects or not. And also need to determine whether there exist relations of “activate”, “suspend” or “chain” between tasks or not. Step 6: At last, allocate system timer source for generating OS tick. (d) Time analysis. If the scheduling results could meet requirements, the whole configuration is finished and the configuration file of OSEK OS is obtained, which should be a file written in OIL. Otherwise, need go to (c), or (b) or even (a) and repeat again.

5. Software integration and test Software Development Platform Do nothing, but can run in ECU. OIL File

OSEK OS/COM

System Generator

Boot &

API

SysGen

Exceptions

Library

Source

Code

Code

Existing

7 1

6 4

3

2

Figure 7 Photo of diesel ECU embedded

development platform The platform used by diesel ECU software development project is shown as Figure 7. Descriptions of this figure is as follows: 1- personal computer, in which installs PC software tools that platform needed (see Figure 8); 2 production ECU hardware; 3 - BDI2000, the hardware debugger; 4 – actuator, electronic unit pump; 5 - signal generating box; 6 - Labview tools that is also a signal generator from NI Company and can be used to generate some complex signals such as crank sensor signal and cam sensor signal etc; 7 - high resolution scope.

(1)

(3)

(2)

(4)

Calibration Code

Compiler Linker

Code

Application of Diesel ECU

5

Diagnostics &

Algorithm Code

New Algorithm

from Axiom Company) and then debug their codes at run-time in the real hardware environment.

Executable file

Figure 6 Integration process of whole ECU

software Figure 6 is the integration process of whole ECU software. Firstly, build OIL file with System Generator (OSEKBuilder) and get source codes with extension .c and .h. CodeWarrior is an integrated development environment (IDE) from Metrowerks. System engineers will set up a project with the IDE, which includes OSEK OS system configuration codes, OSEK OS kernel and API library etc. The project could be built, linked and then generate an executable file with CodeWarrior. After get the executable file, it can be downloaded and programmed into ECU’s memory via tools, like BDI2000 (high speed BDM/JTAG Debug Interface

Figure 8 Third partner software tools used in

development process Figure 8 is third partner software tools used in the development platform: (1) OSEKBuilder - System Generator used to build OIL file; (2) Ds-Design Tool time analysis tools; (3) CodeWarrior IDE Compiler/Linker/Debugger; (4) CANape - Calibration tools software installed in host terminal. The platform has been used to develop ECU software for 6DE serial diesels of China FAW Group Corporation and has demonstrated benefits to the development process.

31st Annual International Computer Software and Applications Conference(COMPSAC 2007) 0-7695-2870-8/07 $25.00 © 2007

6. Conclusion A “V+v” development process method that combines the software platform with model-based and autocode technology is proposed. The method has been used for the diesel ECU software development in China FAW Group Corporation. According to the method a platform is set up and the results demonstrate the following merits: (1) Development cycle of new requirements was shortened with model-based and autocode technology. Work products of previous activity could be used in the next activity. And software quality of ECU can be guaranteed with autocoding tools. (2) The portability and reusability of codes can be improved due to the use of OSEK-compliant RTOS in the platform, especially for the application based on the uniform hardware. (3) The production ECU is used as the hardware of software development platform directly. Thus differences of the hardware environment are avoided and can find defects of ECU control algorithm at runtime at early development stages. (4) The diagnostics tools and calibration tools can help to design, test and calibrate ECU application. And the quality of software can be improved. (5) The method based on platform can guarantee the ability of durative developing new automotive electronic products.

Acknowledgment

This work is supported by the High Technology Research and Development Programme of China (grant No. 2003AA1Z2141).

References [1] Marek Jersak, Kai Richter and Rolf Ernst, “Formal Methods for Integration of Automotive Software”, IEEE Inc., Proceedings Design, Automation and Test in Europe Conference and Exhibition, 2003, pp. 45-50

[2] Michael Beine, Rainer Otterbach and Michael Jungmann, “Development of safety-critical software using automatic code generation”, SAE International, SAE World Congress Detroit, Michigan, March 8-11, 2004, 2004-01-0708 [3] Mark Hsu, Maher El-Jaroudi and Eric Bender, “Accelerated life cycle development for electronic throttle control software using model-based auto-code technology”, SAE International, SAE World Congress Detroit, Michigan, March 8-11, 2004, 2004-01-0276 [4] Jayakumar Nair, Ning Lu, Pradeep Atraya and Johannes Reuter, “Analysis and Comparison Of 3 Code Generation Tools”, SAE International, SAE World Congress Detroit, Michigan, March 8-11, 2004, 2004-01-0702 [5] OSEK/VDX Operating System, Version 2.2.3, February 17th, 2005 [6] Joseph J. Lemieux, “Foundations for rapid embedded development”, SAE International, SAE World Congress Detroit, Michigan, March 5-8, 2001, 2001-01-0022 [7] TargetLink Production Code Generation Guide TargetLink 2.1, dSPACE GmbH. August 2005 [8] OSEKturbo OS/MPC5xx v.2.2.1 Technical Reference, MOTOROLA, Inc. June 2003

31st Annual International Computer Software and Applications Conference(COMPSAC 2007) 0-7695-2870-8/07 $25.00 © 2007