Current automotive systems are still largely engineered as a set of discrete subsystems with minimal interactivity.
Current tools and processes do not support the inevitable growth of interconnectivity, interaction and optimization.

Safe, reliable and predictable operation must be ensured as the complexity of the systems increases.

Interactions between previously separate subsystems (e.g. brakes and powertrain) create coupled modes which must be assessed and managed with respect to safety, reliability and availability.

Powertrain Research and Advanced Engineering
Ford Motor Company

Home > Solutions > Automotive Systems > Verification > The Process of Comprehensive Verification

The Process of Comprehensive Verification

Single Plant + Controller, Subsystems, Vehicles, Systems of Systems

An Example - The Major Subsystems of a Vehicle’s Real-time Control System

From the formal specifications of a vehicle’s plant and real-time control system, each controller is extracted and mapped to a set of software control tasks that will be executed by a processor embedded in an electronic control unit (ECU). The individual ECUs are connected together via networks.

In the bottom part of the diagram below, the separate ECUs of the engine and transmission are connected together and to a panel display ECU, a monitoring ECU and programmable bridge ECU via a CAN network.

Elements of the Real-Time Control System of a Vehicle: Powertrain, Braking and Suspension
Elements of the Real-Time Control System of a Vehicle: Powertrain, Braking and Suspension

The network bridge is also connected to a FlexRay network that connects two further subsystem models – brakes plant with its ECU and chassis plant with its ECU. Both the CAN and FlexRay networks have appropriate monitors attached to them that enable them to both generate and monitor traffic.

The 3 interacting subsystems diagramed above, when included with the steering subsystem, constitute the 4 major real-time control subsystems of an automotive vehicle. This is the foundation of the vehicle’s control and therefore of its safety. If the real-time control system is poorly verified then the entire safety of the vehicle is compromised and nothing built on top of this system – such as active safety devices and functional safety monitors – can improve its safety.

Integrated Testing and Regression Testing to Facilitate the Verification Process

An additional capability is depicted in the diagram: the ability to insert InvirTest1 testing modules that enable black-box testing of ECUs and subsystems. The InvirTest modules use a testing database to inject signals into modules-under-test and examine their response in both function and time. The testing and synchronization of testing across multiple subsystems is readily achieved, as shown.

Building High Fidelity Vehicle Models – the Missing Models are not the Problem

An oft quoted objection to the pervasive deployment of model-based design - both the mathematical (specification) and the operational (design and development) levels are required – is that all the models of the real-time control system of a vehicle must be present from the outset to make the process economically viable. This is untrue.

The starting point for high fidelity modelling of an entire vehicle is a high fidelity vehicle dynamics model (VDM – a set of equations, finite state machines and table lookup models that accurately describe a vehicle), suitably calibrated using its plethora of parameters, to a desired vehicle type. Such models are available from many suppliers, including Mechanical Simulation Corporation (CarSim) of Ann Arbor, MI. Now high fidelity models of the subsystems of interest – such as drivetrain, braking, steering, suspension, engine, transmission, etc. - can be connected into the VDM (in the ESSE Workbench as separate processes running on separate cores) in a manner that usurps the approximate model (typically a table lookup model) embedded in the VDM. This process may be repeated and will eventually replace all of the real-time control systems + plant of the VDM, with high fidelity mathematical and/or operational models, leaving the VDM’s high fidelity model of the application of torque to the roadway as the residual. This process results in a high fidelity model of the entire vehicle, providing all of the high fidelity models replacing the low fidelity VDM models are properly calibrated and shown to be at least as accurate.

Verifying the Real-time Control System of a Vehicle – bottom-up

The full verification of a vehicle requires:

  • The full verification of all the function, timing and behaviour of each plant-ECU-software unit, such as the engine and its controller or the transmission and its controller. However, testing such an element in isolation is insufficient. Replacing the equivalent low fidelity model in the VDM with the high fidelity model, just unit tested, enables full system testing to be performed early in the engineering process.
  • Likewise, the networked units that form a subsystem of the real-time control, such as, powertrain and braking, require their combined function, timing and behaviour to be fully verified and, as well, verified under system testing when appropriately inserted into the VDM. This is especially true for electric and hybrid electric vehicles where regenerative braking is a feature of the energy and control subsystem that sits between the electric drivetrain motors and the mechanical braking subsystem.
  • At the next level of integration, all of the networked subsystems that constitute the real-time control system of a vehicle require their combined function, timing and behaviour to be fully verified in isolation and under system testing when appropriately inserted into the VDM.
  • Finally, the entire vehicle – real time control system + plant + active safety systems + communication systems, etc. – must be verified in the context in which the vehicle and its safety systems are designed to operate, in urban type traffic.

In this environment, many hundreds or thousands of traffic scenarios, which might be encountered in traffic, act as complex regression tests of the entire vehicle. This includes scenarios that result in fatalities. This last level of verification – of multiple high fidelity vehicle models cooperating in traffic and subject to traffic controls - is the verification of the interactions of each control system of every high fidelity vehicle model constituting the traffic.

Aggregate empirical measures of safety, emissions, fuel consumption, congestion, etc. can be made for each traffic scenario from the individual vehicle logs recorded during the scenario. When many scenario measurements are collected from traffic operating on particular traffic infrastructure – such as, an intersection, round-a-bout, linked intersections – statistics derived from the aggregate measure can be used to ascribe measures – for instance, of safeness and emissions - to infrastructure elements. These should become standard measures of infrastructure planning and should significantly influence their likelihood of realization as physical infrastructure. The accuracy of these measures is highly correlated with the level of fidelity of the models – vehicles and traffic control – represented in the verification using scenarios.

Comprehensive verification meets safety requirements

The ability to perform system-level verification, while also verifying the operation of each element and subsystem of a vehicle, meets the requirement of compliance with the ISO 26262 functional safety standard. This compliance requires a demonstration that no harm to humans, property and the environment will result from the vehicle containing the elements and subsystems under scrutiny. This level of compliance needs to be extended to the wider, general safety of the real-time control system of vehicles. This is not a level of compliance that can be achieved by unit testing an element, a subsystem, or even the complete real-time control system itself in isolation from the VDM.

Simulation Using EST’s ESSE Systems Engineering Workbench

Simulating the single controller + plant, subsystem, and system models in isolation, and when embedded in a VDM, using EST’s ESSE Systems Engineering Workbench is straightforward. The plant and ECU models are likely to be 3rd party and proprietary models written in a variety of notations, such as Simulink, SystemC , Synopsys (VaST), C/C++ and as software in the loop (SIL) models. The VDMs are proprietary models. All network models are required to be high performance, bit and timing accurate and compatible with the multi-core ESSE Distributed Simulation Engine - these are supplied by EST. The connection of the various models to the ESSE network models is done using an ESSE Active Interface and is specified as part of the specification of the entire system or system-of-systems. In the ESSE Workbench, any model, together with its native simulator and supporting analysis and debugger tools are supported.

1Invirtech™ is a product of Invirtech, LLC - developed with assistance from EST (

Continue on Verification: