Why is MATLAB so bad

Development and testing of electronic body systems at Jaguar

By Rich Humphrey, Jaguar Cars and Alexandros Mouzakitis, Jaguar Cars

A well-performed body electronics (Electronic Body System, EBS) is an important factor for the acceptance of an automobile, because functions such as lighting, window cleaning and central locking are the first things that catch the customer's eye. An excellently designed locking system will not convince him to buy a particular car; a poorly designed one will certainly deter him from choosing the right brand again in the future.

Intuitive, logical and clearly structured EBS systems underline the impression of having a high-quality vehicle in front of you, but are increasingly difficult to develop. More and more control functions are automated for reasons of convenience, with the control elements being distributed more and more in order to require less wiring and thus gain more free interior space.

The conventional development approach at Jaguar came under increasing pressure due to these requirements and it became increasingly difficult for the developers to complete EBS systems on time. The solution was an automated virtual integration and test laboratory.

The conventional development process at Jaguar

In the first step in the development of EBS software at Jaguar, the system engineers usually formulate the requirements and pass them on as a written specification to their suppliers, who develop the modules as hardware and software. After the supplier has tested a module against this specification, he hands the finished module over to Jaguar, where it is first tested by engineers on a breadboard (test model) and then in a prototype vehicle.

There are three basic problems with this approach:
  • Written specifications are incomplete and can be misinterpreted.
  • Meaningful system tests can only begin late in the course of the project.
  • The system tests are complex and extremely labor-intensive.

While development departments are generally aware of the first problem, the other two problems are largely caused by the fundamental limitations of the breadboard approach.

All electrical modules, sensors, switches and actuators of the vehicle are grouped together on a breadboard (Fig. 1) and connected to one another with the standard wiring harness.

There are several fundamental flaws in this approach. First, you can only begin meaningful tests when all components and the wiring harness are available. (The wiring harness is usually finished last, often two weeks before the first prototype is built.) Second, all tests have to be done manually with the real switches, sensors and actuators. Thirdly, it is difficult to test the system behavior under fault conditions, for example a blown fuse or a short circuit, because every single fault has to be built in with great effort. Finally, breadboard tests only show behavior under static conditions. Systems that change their behavior while driving, such as automatic door locking when moving off, are difficult to test in this way.

Especially towards the end of the development cycle, these problems place a high burden on the engineers. Defects in the written specifications are therefore usually only discovered shortly before the prototype is built. From this moment on, the engineers are constantly lagging behind and struggling through countless software errors and the tiring manual verification that lasts for weeks.

Fig. 1: A conventional breadboard. Click to enlarge the image.

Introduction of model-based design

Jaguar Cars' Simulation and Control Group is responsible for promoting and supporting the use of model-based development and test methods for software in all of Jaguar's and Land Rover's electrical engineering departments. Until then, Jaguar had mainly focused on chassis and powertrain applications, particularly hardware-in-the-loop testing.

From March 2003, Jaguar's support for model-based design was extended to include the EBS area. The heart of the methodology is the ‘EBS Virtual Integration and Test Automation Laboratory’ (EBS-VITAL). With the EBS-VITAL (Fig. 2), the simulation-supported version of the traditional breadboard, the engineers can automatically test the EBS software at a very early stage of development.

Fig. 2: Topology of the EBS-VITAL. Click to enlarge the image.

Automated tests with EBS-VITAL

In EBS-VITAL, all EBS control modules are connected to a special real-time simulator (RTS) developed by dSPACE. The team can use it to simulate Simulink models of the EBS sensors and actuators and even simple models of the vehicle's drive and entertainment systems in real time. The modules are connected to the EBS-VITAL via a simple cable harness that connects all module I / Os directly to the RTS.

The early construction of models significantly increases the chance of discovering problems in the system design or faulty module specifications.

The EBS-VITAL has many advantages compared to conventional breadboards. The entire test plan for the security software can be processed in 36 hours (usually over the weekend). In addition, there are two person days for the evaluation. Performed by hand, these tests would take over four person weeks. The tests can now start much earlier because the wiring of the EBS-VITAL does not have to be as compact as the real wiring harness. Modules that are not yet finished can also be replaced in the simulation with Simulink models.

Dynamic functions can easily be tested by simulated test drives. The EBS-VITAL also simplifies the testing of the system behavior in error and borderline situations: The sensor and actuator models can be easily modified for this purpose and the entire RTS-I / O is connected to an error generator, which means that error scenarios can be incorporated into the automatic tests at any time can.

One of the greatest advantages of EBS-VITAL is that functions can also be changed late in the project. The engineers can simply replace the module models with models with new functionality and then automatically and thoroughly re-test not only the modified module, but all system functions. In this way, unexpected side effects of a modification can be identified and corrected before suppliers change the software. The time and costs involved in installing new functions have thus been drastically reduced.

Development in a completely new guise

The tests with the EBS-VITAL and Model-Based Design consist of three phases:

In phase one, all EBS modules are replaced by Simulink and Stateflow models that reflect the system requirements. The module suppliers develop the hardware and software using these models and test the module against the specification.

Phase two begins as soon as a module is ready. In this phase, the EBS-VITAL is a mixture of real modules and models.

As soon as the last module is finished, phase three begins. The EBS-VITAL then only contains real EBS modules.

In practice, all of the EBS control modules are rarely replaced by models. The majority of systems at Jaguar contain at least one module from a previous project. The creation of a model for it then makes little sense. Instead, the real hardware will be installed as soon as possible. The EBS-VITAL then immediately goes into hybrid phase two.

If you already create models in a leading development stage, this significantly increases the chance of discovering problems in the system design or faulty module specifications. Using the models, engineers can demonstrate the new functions to decision-makers at the beginning of a program and thus receive early feedback that helps avoid last-minute changes. Some models were even worked out in such detail that the software for the module could easily be generated automatically with the Stateflow Coder.

In addition to its many advantages, model-based design is also associated with new challenges. The creation of the models for all modules is relatively complex. If a model-based project is run in parallel with conventional projects that use enormous resources, especially towards the end of the program, this can cause problems. In addition, system engineers with little programming experience need time and support to develop skills in using Simulink and Stateflow and to be able to create models from which production code can be automatically generated.

Fortunately, these are hurdles that get lower with every new project, and the benefits of adopting model-based design far outweigh any investment required, in our opinion.

Released 2006 - 91419v00

Show articles for similar areas of application

View articles for related industries