Delphi Models and Simulates a Safety-Critical Automotive Subsystem

Delphi Models and Simulates a Safety-Critical Automotive Subsystem


By Padma Sundaram and Joseph D'Ambrosio, Delphi Innovation Center
Send email to Jon Friedman

Electronically controlled automotive safety systems contribute significantly to vehicle safety, and they present a unique set of engineering challenges as well. Software interacts with hardware such as electronic control units, hydraulic modules, and motor controllers, often behaving dynamically under real-time conditions. Unexpected interactions among software, hardware, and the environment may lead to situations of concern.
Discovering and managing such unexpected interactions helps determine the potential safety risks associated with system design and identify factors that minimize or eliminate these risks. This process is known as hazard analysis. It has qualitative and quantitative aspects, and the results of these analyses are typically confirmed and strengthened by engineers employing precise simulation models.
Using tools from The MathWorks and third parties, we developed a modeling and simulation method that supports a safety program for a critical vehicle subsystem. This method accurately models the vehicle and subsystem behavior in a cosimulation environment, and was successfully used during preliminary hazard analysis and hazard testing.
Simulation Model and Environment

The subsystem considered in this article is critical to the safety of vehicles equipped with it, and consists of a software component that resides in an electronic control unit (ECU), and a hydraulic actuator component. The ECU receives signals such as vehicle speed, vehicle attitude, and driver intent from on-board sensors, using the input signals to compute an actuator command.
To build a simulation model that depicts a real-time system involves simulating the actual dynamic conditions to which the vehicle’s subsystem is exposed. As such, the simulation environment should include:

• A simulated vehicle that closely represents the actual vehicle in which the subsystem will be active
• A subsystem model that captures the functionality of the actual software logic and is able to closely imitate the software behavior
• An actuator model that emulates the actuator dynamics

To achieve fast, high-fidelity simulation of all components, and to perform an accurate control system simulation that includes legacy models or codes, we decided to concurrently link and run several simulation packages. In addition to MATLAB, we used:

• Simulink, to facilitate cosimulation among the different simulation tools and to model the subsystem control algorithm
• CarSim, to model the vehicle environment
• AMESim, to model the actuator system

Simulink provides a platform that can integrate the three system blocks of the simulation model into a single environment. Simulation models from third-party applications can execute within the Simulink shell as S-functions (system functions that you compile to run in the Simulink environment, see Simulink documentation). On a Microsoft Windows platform, you can compile S-functions into dynamically linked libraries (DLLs). CarSim and AMESim provide DLLs to represent the vehicle model and the actuator model, respectively. We included these DLLs in the Simulink environment as S-functions.


Figure 1. Closed-loop cosimulation model in Simulink. Click on image to see enlarged view.
By cosimulating the three applications we were able to perform closed-loop modeling of the vehicle control system, validating the individual blocks of the simulation model against real test data. Figure 1 shows a high-level view of the cosimulation model components.
Vehicle Model

We based our vehicle model, which closely matched the actual test vehicle, on a default CarSim model, relying on CarSim software to provide the equations for simulating vehicle dynamics. To acquire test vehicle data, we tested the actual development vehicle's performance, including lateral and longitudinal tire characteristics, suspension characteristics, brake and steering system parameters, vehicle measurements such as sprung and unsprung vehicle mass parameters, vehicle linear measurements, and aerodynamic characteristics.
We tested the vehicle with average drivers to measure driver response time, and used this time factor in the simulation model to simulate the driver steering delay time.
We validated the vehicle simulation model against real test data during steady-state and transient maneuvers on surfaces with different environmental conditions. The validation process compares the simulation results to the actual vehicle data. Throughout all maneuvers and surfaces, the simulated results were very close to the actual vehicle behavior, so the model is considered valid. Figure 2 shows some of the vehicle validation results we obtained, showing an overlay of actual vehicle data against simulation data.


Figure 2. Validation results for the vehicle simulation model. Click on image to see enlarged view.
CarSim provides vehicle DLLs for different axle configurations and lets you create custom DLLs. Any changes to a CarSim data set are exported as vehicle and/or driver parameters in a configuration file that the CarSim DLL reads. For example, CarSim provides predefined S-functions usable in Simulink. All vehicle and driver settings and inputs are passed to the DLL as parameters and interfaces in a configuration file, so there is no need to change the design of the current DLLs. To use the appropriate vehicle configuration DLL in the Simulink model, we associated it with a user-defined S-function block. In this article, we refer to the vehicle model in Simulink as the vehicle S-function.
Subsystem Software Model

To accurately capture the behavior of subsystem software in real time, we modeled the software in the simulation setup using Simulink, and converted the C-based software into custom S-functions. As the software was in fixed-point format, we converted the model inputs from Simulink to appropriate fixed-point data types and, similarly, converted the model output from fixed-point to floating-point engineering units. We then compiled and built a DLL for the software component using the MATLAB MEX Function library. We associated the DLL with a custom S-function, which we here refer to as the subsystem software S-function.
Actuator Model

To model the actuator system, we used the AME-function block, which is similar to the subsystem software S-function. We refer to this actuator simulation model as the actuator S-function.
Validating the Closed-Loop Simulation

After connecting our three S-functions in Simulink to provide a closed-loop simulation model of the target subsystem (Figure 1), we validated the model’s operation by comparing simulation outputs with real data from the test vehicle. The plots in Figure 3 show our validation results.

Figure 3. Validation results for the closed-loop simulation, comparing subsystem and actuator outputs between the simulation model and the actual data for a given maneuver. The plots indicate that the modeled behavior is nearly identical to the actual vehicle behavior. Click on image to see enlarged view.
System-Safety Analysis

Preliminary Hazard Analysis (PHA) helps researchers identify potential high-level system hazards and determine the criticality of potential mishaps that may arise, so that safety requirements for controlling identified potential hazards can be determined and incorporated into the initial design [1, 2]. In the early stages of system development, engineers analyze potential hazards by the following steps:

1. Brainstorm or review existing lists of potential hazards to identify potential hazards associated with the system.
2. Describe potential hazards and the potential mishap scenarios associated with them.
3. Identify potential causes of the potential hazards.
4. Determine the risk of the potential hazards and mishap scenarios.
5. Determine whether system hazard-avoidance requirements must be added to the system specification to eliminate or mitigate the potential risks.
6. If time is a factor for a potential hazard or potential mishap occurrence, investigate the timing constraints that the potential hazard places on the design.

The qualitative aspect of hazard analysis involves determining the severity and assessing the risk of each potential hazard identified during PHA. This process also involves evaluating concept design configurations for instances of decreased or increased risk posed by system parameters or architecture components of a configuration [1]. Quantitative analysis involves determining the magnitude of a potential system fault and the length of time the potential fault can be safely tolerated in the system before the potential fault leads to potential hazard.
Simulation-Based Hazard Analysis

During the concept design phase of the subsystem, we conducted a preliminary PHA during which we identified the following system-level potential hazards:

• Unwanted system activation
• Incorrect system activation
• Excessive system activation
• Inadequate system activation

Following the identification of these potential hazards, we used the simulation model to determine the severity, and hence, the risk posed by each potential hazard. We then introduced faults into the subsystem to trigger system behavior that produced each of the identified potential hazard conditions in simulation. This process helped us understand the behavior of the system and the vehicle under failure conditions, and helped determine the metrics for evaluating acceptable unwanted system behavior.
We then quantitatively analyzed the potential hazards identified above in a process engineers refer to as hazard testing activity. It involves evaluating the test vehicle under several subsystem failure conditions, and leads to determining the magnitude of a potential output error from the subsystem actuator and the time that potential error can be safely tolerated by the vehicle before the it leads to a potential system hazard. When available, we adopted as safety metrics for hazard testing existing industry standards and government regulations for vehicle-level safe tolerances. For example, FMVSS 135 [3] specifies the allowed stopping distances for US vehicles. For those situations where standards or regulations do not exist, we initially based our safety metrics on published safety studies and past experience. The metrics can then be refined in accordance with hazard testing results for the specific vehicle and subsystem. In the case of our example subsystem, we used a “maximum allowed path deviation of 25 cm” safety metric, basing it on published safety studies and past experience [4].
We next simulated unwanted system activation in the vehicle, based on the vehicle-level safety metric, and measured the magnitude and time of the unwanted activation pulse that the subsystem could safely tolerate. The safe duration of this unwanted pulse was the subsystem’s worst-case fault response time. This fault response time is typically a function of vehicle speed and actuator response time: the faster the actuator response, the shorter the subsystem fault response time must be.
Figure 4 shows the hazard test process results, with the lateral offset produced in the vehicle when we simulated unwanted activation of the subsystem.
Figure 4. Path deviation in a straight maneuver. The plots show the path deviation due to unwanted activation of the subsystem at different vehicle speeds. The activation lasted about 4 seconds, beginning at time = 20 seconds in the simulation run. Click on image to see enlarged view.
Figure 5 shows an animation snapshot of the hazard test in a turning maneuver. As shown, the vehicle with diagnostics not enabled violates the path deviation requirement, while the vehicle with diagnostics enabled does not.
Figure 5. Snapshot of the simulated hazard test in animation. The yellow vehicle (left) is deviating from the desired path because of unwanted activation of the subsystem. The red vehicle (right) shows the case where subsystem diagnostics are enabled, the fault is detected, and the subsystem transitions to a safe state. Click on image to see enlarged view.
This article discussed the development of a simulation model for a vehicle subsystem safety analysis. Simulation-based engineering tasks, such as those for robustness studies and system-safety analyses, require a simulation model of high fidelity and precision.
A significant advantage of simulation-based vehicle analysis is the ability to perform vehicle tests at various limit-handling conditions. Performing such activities in a real vehicle may involve risk to the driver and can increase costs due to the needed additional vehicle safety devices. In these cases, substituting simulation for in-vehicle testing can greatly reduce associated risks and costs.
Selecting the appropriate tools for development of a cosimulation platform can be a challenging task. Using Simulink and flexible third-party products, however, we were able to integrate simulation and modeling tools without requiring additional development.
Acknowledgement

The authors thank Aleksander Hac, Edward Bedner, Chester Gryczan, Kevin O’Dea and Nicole Anderson from Delphi for their support in the development and validation of the simulation model.
References

1. FAA System Safety Handbook, Dec. 2000.
2. Sanket Amberkar et al., "A System-Safety Process for By-Wire Automotive Systems", in Design and Technologies for Automotive Safety-Critical Systems SP-1507, SAE 2000, pp. 69-74.
3. Federal Motor Vehicle Safety Standard No. 135 – Light Vehicle Brake Systems, NHTSA.
4. Sanket Amberkar et al., Diagnostic Development for an Electric Power Steering System, SAE 2000 World Congress.

更多...