|
Multitarget modeling reduces ECU software costs
Here are the techniques, tools, and benefits of a multitarget modeling approach, as used by Visteon to develop power train ECUs
|
|
By
Walt Stuart, Visteon and Tom Erkkinen, The MathWorks
|
Page 1 of 2
|
Automotive DesignLine
(10/12/2006 6:49 PM EDT)
|
|
|
Multitarget modeling is an Electronic Control Unit (ECU) development technique that uses Model-Based Design with automatic embedded code generation. With multitarget modeling, algorithm models are adapted, with code automatically generated for a wide variety of embedded DSPs, microprocessors, and microcontrollers. As a result, software can save development teams significant time and effort because they do not have to write, test, and rewrite code for each embedded target device.
Visteon uses multitarget modeling for developing automotive electronic power train control systems. Their developers' approach relies on the creation of a data dictionary that handles the data types used during model simulation and embedded code generation. With this approach, Visteon engineers can simulate design trade-offs and experiment with various processor schemes for algorithms based on a wide variety of embedded processor options.
The simulation environment helps to determine the effects of data resolution and quantization on system performance prior to software implementation. Once the appropriate embedded processor is selected, code is automatically generated, built, and integrated into the production ECU. The simulation and code generation environment is provided by Simulink® and Real Time Workshop® Embedded Coder tools from The MathWorks.
Multitargeting using a manual approach—challenges
The traditional method of supporting a variety of hardware architectures is to develop code manually that is easily ported, and can be changed from one architecture to another. The challenge with this approach is that engineers cannot easily convert their floating-point algorithms into fixed-point designs. The conversion process requires that scale factors and other fixed-point information be provided for all variables and parameters—making it difficult to create and maintain a software layer that provides adequate abstraction between the high-level algorithm and fixed-point software implementation in a manner that is easy to use.
Design and porting software from floating-point to fixed-point architectures introduces other issues to the development process, including:
Significant time is needed to establish the scaling information.
Testing fixed-point overflow and underflow is tedious. Every mathematical operation requires analysis and testing with minimum and maximum values to establish the need for overflow and underflow checks.
Manual design and coding techniques are prone to errors.
Multitargeting using Model-Based Design
In the late 1990s, Visteon began to investigate the use of models and automatic code generation for power train applications. This search led the company to move from a manual development approach to Model-Based Design. The change occurred over the past six years as existing hand-coded production modules were gradually converted to Simulink models as needed. Automatic code generation using Real-Time Workshop Embedded Coder was also introduced during that time and used to automatically produce code from the models for implementation in production ECUs.
The use of Model-Based Design has now gained wide acceptance in the automotive industry, and the virtues of using modeling, simulation, and automatic code generation are well known. As an early adopter of Model-Based Design, Visteon has amassed a large amount of expertise in this area#151;establishing a complete modeling environment that facilitates quick deployment on different hardware architectures using a multitarget, automatic code generation approach. This approach relies on the use of external data dictionaries to constrain the format and structure of the code generated from the model architecture.
Design environment
A multitarget model is independent of the data type. Initially the data type used for the model is the maximum word size available (i.e. double-precision real) for the host machine performing the simulation—providing the ideal behavior of the proposed algorithm. If the behavior is satisfactory, target implementation-specific constraints are then added to make the model suitable for a production ECU.
To make the model target-specific, a data dictionary is loaded into the MATLAB workspace with hardware-specific information. Mechanisms are provided to link the data dictionary to the baseline generic model. Automated scaling tools facilitate the conversion and verification process. Automatic code generation completes the process by translating the fixed-point design into production code. Visteon engineers then integrate the software and hardware components into the final production ECU for further verification and validation exercises.
The figure below shows the generic model architecture that Visteon Powertrain engineers use and how target-specific details are provided using multiple data dictionaries.
View a full-size image
Once the behavior is deemed satisfactory, the generic model is checked into Visteon's configuration management system and placed in the "bookshelf" as a component in the power train algorithm library. Engineers are then able to build new algorithms by reusing the model components stored in the algorithm library.
|
|
|
|
CAREER CENTER
|
Ready to take that job and shove it?
|
|
SPONSOR
|
|
|
|
RECENT JOB POSTINGS
|
|
|
For more great jobs, career related news, features and services, please visit EETimes' Career Center. |
|
