The usage of electronic systems in automotive industry is continuously expanding, even at at faster pace. Compare with a previous model, every new vehicle model has more vehicle functions, meant to improve connectivity, security, driveability and comfort.
More vehicle functions means more electronic control modules (ECU) with more and complex software. Due to the complexity and size of the control software, it’s mandatory to use a development process which shall improve the overall quality of the software, increase development efficiency and eliminate systematic software bugs.
The standard software development process used in the automotive industry is the V-cycle. The V model splits the software development process into two main phases. The left side of the V is the part of requirement analysis, function/software design and change management. The right side of the V concentrates the main verification and validation activities.
Image: V-cycle process for software development
Function Requirements
The process starts with the analysis of the function requirements. This is a very important step because it defines what is expected from the control software in terms of functionality. There is an entire engineering area dedicated to requirements, which is called requirements engineering. Some companies have dedicated requirements engineers working on a daily basis defining requirements. Most of the time, the system engineer is responsible with requirement definition.
The function requirements describes what the software should do from the functional point of view. When defining requirements, the author will use dedicated keywords, which have a precise meaning. The keywords are defined in the document RFC2119 as:
| Keyword | Meaning |
| MUST | This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification. |
| MUST NOT | This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification. |
| SHOULD | This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. |
| SHOULD NOT | This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. |
| MAY | This word, or the adjective “OPTIONAL”, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) |
Source: RFC2119
Example: In case of an engine managements system (EMS) software development, there should be a protection function which doesn’t allow the engine to exceed the maximum possible value (e.g. 6500 rpm). The requirement will be written as:
“The engine control software MUST limit the engine speed at 6500 rpm.”
A function requirement, most of the time, describes what should happen and doesn’t necessarily give details regarding the exact implementation. If you notice, the above requirement specifies what the engine controls should do, but not how it should be achieved. It’s often to the function developer to decide on the implementation details.
When defining requirements, the requirements/systems engineer must work closely with the function developer to make sure that the requirements are clearly defined and implementable. Most of the cases the requirement come in a form of a document (*.pdf) or managed in a dedicated requirements database like DOORS.
Function Development
Once the function requirements are clearly defined and agreed between the developer (function engineer) and requirements/systems engineer, the function development can start. The function development is performed by the function developer and consists in using a model based development (MBD) environment to design and test the required functionality.
A model based development environment uses tools as Matlab/Simulink or Scilab/Xcos to implement control functions. The control function is developed as a block diagram which has the capability to be simulated and highlight potential errors of the design.
For the requirement above the engine speed limiting function can be designed as:
Image: Engine Speed Limit Function Xcos (MBD)
Notice that the function developer has also defined how the speed limitation is going to be achieved. When the measured engine speed (EngN_rpm) is bigger than the limit (EngNMaxLim_Cal_rpm) the requested engine torque (EngTqReq_Nm) will be set to 0 Nm. Otherwise, if the engine speed is below maximum limit, the requested engine torque will be equal to the raw engine torque (EngTqRaw_Nm). We will assume that the raw engine torque is calculated based on accelerator pedal position.
After the function design is complete, the function developer will run a series of tests. These tests are called Model in the Loop (MiL) tests since they are using models (block diagrams) to simulated the required functionality.
Once the MiL test are complete and the results are meeting expectations, the model (*.mdl, *.xcos) will be send to the software developer for the software design phase.
Software Development
The actual software development is performed by the software developer. Almost all electronic control units (ECUs) within a modern vehicle are programmed in C language. The input for the software developer is either the model developed by the function developer or a document with detailed description of the function.
At this stage of development there are more details regarding the functionality. In addition to the algorithm which needs to be coded, the software developer needs to know what data types needed for each of the software variables. The software developer is also responsible in delivering an optimized C code, in terms of memory resources and CPU loading.
For the engine speed limitation function, an equivalent C code for the block diagram above could be:
#include <EngNCalc.h>
#include <EngTqPedlCalc.h>
void EngSpdLimFct(void)
{
extern float EngN_rpm;
extern float EngTqRaw_Nm;
extern float EngTqReq_Nm;
float EngNMaxLim_Cal_rpm;
if (EngN_rpm > EngNMaxLim_Cal_rpm)
{
EngTqReq_Nm = 0;
}
else
{
EngTqReq_Nm = EngTqRaw_Nm;
}
} Modern software development processes are using model based design tools which automatic code generation capabilities. This means that the function developer can generate C code automatically from the block diagram. Therefore, in this situations, the role of function and software development are combined for the same engineer.
Examples of automatic code generations tools:
- Embedded Coder (needs Simulink to be pre-installed) from Mathworks
- Target Link (needs Simulink to be pre-installed) from dSpace
- ASCET from ETAS
With automatic code generation capabilities the developer can perform Software in the Loop (SiL) test. This technique allows to compile and run the production intent C code on the development laptop/computer. By doing SiL tests, the function developer can check if the software is providing the required functionality (compared to the model). Also it is possible the see the rounding errors in case of fixed point implementation of the C code.
The output of the software development phase are the corresponding C code files (*.c and *.h) for the required functionality.
Software integration
The software integration is the process of combining together all software modules required for a particular projects. A particular function can have impact on several software modules, developed by different software developers. Integration means compiling and linking all the files (*.c, *.h) for a specific application and turning them into a machine code file (*.hex and *.a2l).
At this stage, the testing of the required functionality is done at system level (complete ECU software). The purpose of the integration test is to verify the interaction between the software modules and to check the impact of the functional changes on the legacy code (through non-regression tests).
Most of the time, integration test are performed using Hardware in the Loop (HiL) techniques.
 Image: dSpace Scalexio Simulator for HiL systems |  Image: ETAS Labcar Simulator for HiL systems |
A HiL environment consists of using a simulator which has the role of replacing the real vehicle. The simulator will have all the electrical connections (battery supply, sensors and actuators) required by the electronic control module (ECU). Also it will simulate the dynamic behavior of the vehicle in order to be able to test closed loop control scenarios.
The main purpose of the HiL environment is to replicate, in an indoor environment, the behavior of a vehicle so that the ECU can be tested without the need of a real vehicle.
HiL environments can be at the component level (engine, transmission, etc.) or at the vehicle level. A vehicle level HiL usually connects in a network several simulators and ECUs. The advantage of the vehicle level HiL is the possibility to test a distributed function (e.g. Adaptive Cruise Control).
The HiL tests are verification tests. Verification confirms that the software properly reflect the specified requirements. In other words, verification ensures that ”you built it right.”
Function integration
The function integration is usually performed by the function developer or by a test engineer. The purpose is to test the developed function at the vehicle level (production model or a prototype). The purpose of the vehicle test is to validate the correct implementation of the requirements and the integration with the other control modules (e.g Transmission Control Module, Anti-lock Braking System control module, etc.).
The function integration is performed with a computer connected at the target ECU. The target electronic control unit can be the Powertrain Control Module (PCM), Transmission Control Module (TCM), Body Control Module (BCM), etc.
Image: Vehicle testing using laptop with logging and calibration software tools
Credit: Bosch (vehicle)
The laptop must be equipped with proper tools for accessing software variables (INCA, Canape) and network bus messages (Canalyzer). These tools connect to the target ECU using different communication standards (ETK, CAN, etc.)
Vehicle testing is performed after a defined test scenario. The test engineer will drive the vehicle in certain operating condition suitable for the activation of the function subject to test. For example, in order to test the engine speed limit, the engine needs to be accelerated until it reaches the maximum speed. For this particular example it is recommended that this function is tested on a simulation environment (HiL) before vehicle testing.
The function integration tests are validation tests. Validation confirms that the product, as provided, will fulfill its intended use. In other words, validation ensures that ”you built the right thing.”
Function calibration
The last step in software development is the function calibration. This task is performed by a calibration/tuning engineer.
Most of the software control function are generic, they are suitable for different vehicle applications (variants). The role of the calibration engineer is to set the right parameters for the software functions. For our example, the calibration is the value of the maximum speed limit. Depending on the engine type, it can have different values (e.g. 6500 rpm for gasoline engines, 4500 rpm for diesel engines).
The calibration engineer will tune the software parameters so that it achieves best performances in terms of driveability, performance, emissions, etc.
The function calibration activities, most of the time, are performed on a vehicle with the same setup as for a function integration.
The main advantages and disadvantages of the V-cycle for software development process are listed in the table below:
| Advantages | Disadvantages |
|
|
For any questions or observations regarding this tutorial please use the comment form below.
Don’t forget to Like, Share and Subscribe!
asp
very clear explanations for absolute beginners.
Thanks a lot.