Model-based System Development : System Development in the Automotive Industry

System Development in the Automotive Industry

It has long been recognized that ambiguous and inconsistent requirements are the primary cause of design errors in system designs. This is not helped by the fact that most specifications are still produced as paper documents and then subject to an inadequate review process. A rigorous review might catch many of these errors, but all too often the review is cursory due to lack of time or experience. Written requirement specifications are often completed after the design as a documentation exercise, often containing errors and ambiguities.

Model-based system development moves away from the written specification approach towards a dynamic representation of the system, which is constantly being reviewed as it is constructed.

Through the model-based approach, design errors are detected much earlier in the development process where the cost to fix them is much less. Customer change requests can be more efficiently assessed and responded, thus providing more timely feedback.

The greatest benefit from a model-based approach is increased communication, not only between the engineering disciplines but also between the technical and non-technical parties involved in the system development process; thus supporting Concurrent Engineering. This is possible due to the inherent ability to produce models at different levels of abstraction thereby avoiding the detailed overload that often occurs when data is passed between different domains.

But modeling should not be seen as a stand-alone task. It should be embedded within the overall system development process.

A widely used and accepted process model is the “V” Development Lifecycle illustrated in the following figure.

The left leg of the V describes the top-down design process over time while the right leg of the V corresponds to the bottom-up synthesis path over time, where smaller components are integrated to build the complete product.

It is important to note the creation of test data all along the design path (left leg). With this approach it is no longer good enough to say that the system shall meet a particular requirement. Rather, it is necessary to also define how the requirement shall be tested. As can be seen from the above figure, these test data can be re-used either at the next design level or during the bottom-up integration.

In a model-based development process test-data are derived directly from the simulation of respective models. These data are input to or later exported from a Test/Parameter Database, e.g. an ORACLE database.

To understand the model-based design process further, the left-hand side of the “V” is illustrated in more detail in the following figure. It describes a specific approach applied in the Automotive Industry - the so-called “Feature-based Design Process.”

In modern body electronics development, functional requirements are captured and analyzed by means of a special class of models called “feature models.” These models describe either one basic functionality like window control, mirror control, etc., or an ensemble of basic functionalities (“feature interaction models”) like seat positioning / seat heating / seat venting. Feature (interaction) models are purely functional and do not reveal implementation details. They are designed as re-usable objects (“Feature Library Components”), that allow an easy “plug & play” design of new body electronics systems.

The results of the Feature Analysis Phase are:

Both are re-used in the following System Functional Design Phase.

The integration of all vehicle-specific feature (interaction) models into one common model defines the Conceptual System Model. It is the basis for the overall Verification & Validation (V&V) of systems requirements in the System Functional Design Phase. V&V will be performed through model execution. The respective test scenarios form the basis of the later validation tests of the synthesized system architecture.

Sometimes a “Soft Prototype”, automatically generated from the Conceptual Model, together with a graphical user interface is used as a first proof of concept - or for marketing presentations.

The Automotive “Feature-based System/Software Design

The results of the Functional System Design Phase are:

The Conceptual System Model is the entry point to the System (Architectural) Design Phase. At this stage of the development, the system is first partitioned into subsystems (i.e. ECUs) and then the feature (interaction) models or respective sub-functions are distributed among them. Although the resulting model is still pure functional, the partitioning will be determined almost by implementation considerations, e.g.:

In some cases, architectural design criteria might also be derived from additional Performance Models. These models are based on queuing theory and typically used for throughput analysis and identification of potential communication bottlenecks.

The subsystem partitioning and feature/function parsing is an iterative process. The particular architectural system design will be verified by means of test scenarios previously used for the verification of the Conceptual Model. For each ECU the respective I/O will be recorded.

The final step in the System (Architectural) Design Phase will be the definition of the hardware attributes of the logical interface, i.e. which information will be hardwired and which will be provided via bus.

The results of the System (Architectural) Design Phase are:

Based on the particular hardware interface definition, additional I/O-functionality has to be added to each ECU model of the Architectural System Model in the Subsystem Design Phase (e.g. in case of hardwired input: switch debouncing, low pass filtering, etc.). As the respective Architectural Subsystem Model is still purely functional, the later ECU Operating System / Scheduler will be excluded, i.e. all functions will “run in parallel.” If the ECU is to be connected via the bus, the respective bus protocol will not be modeled. Rather, only the bus-related logical interface (“Communication Matrix”) will be defined and verified based on test vectors derived in the previous System (Architectural) Design Phase.

At this stage of the development Rapid Prototyping might be used as an additional means of validation. A “Soft Prototype” - automatically generated from a particular Architectural ECU Model - might be rehosted to a Rapid Prototyping Hardware platform for “on-board” and/or “man-in-the-loop” validation of the design concept prior to the implementation.

In the case of Model-based Software-development the results of the Systems Analysis and Design Phase (see the figure) are:

Normally the Architectural Subsystem Model is the entry point to the Software Design Phase. Now target specifics, the Operating System/Scheduler, the sequencing and timing of functions, and the bus protocol have to be considered. The respective Implementation Model essentially becomes a design model for the code implementation. It is validated by re-using test patterns generated during the previous development stages.

However, the transition to the Software Design Phase is not distinct. It might also start from the Architectural System Model, leaving the I/O processing and the verification and validation through Rapid Prototyping as an implementation task to the Software Design. It should be defined with close co-operation between those responsible for the implementation, such as sub-contractors or members of a software department. Nevertheless, wherever the transition within the process takes place, the deliveries should be model-based with respective test vectors included for cross-validation.