See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/235420619

A MODEL-BASED DESIGN APPROACH FOR AUTOMOTIVE CRASH SAFETY

SYSTEMS

Conference Paper · October 2007

CITATIONS READS

0 202

2 authors:

Ofelia Andrea Valdés Rodríguez Caupolican Munoz

El Colegio de Veracruz Metropolitan Autonomous University
119 PUBLICATIONS   192 CITATIONS    18 PUBLICATIONS   33 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Collecting Meteorological Information View project

Algorithms, Models and Metrics View project

All content following this page was uploaded by Ofelia Andrea Valdés Rodríguez on 03 June 2014.

The user has requested enhancement of the downloaded file.

ITCH - ELECTRO 2007 Octubre 17-19, Chihuahua, México

A MODEL-BASED DESIGN APPROACH FOR AUTOMOTIVE CRASH SAFETY

SYSTEMS

Ofelia Andrea Valdés Rodríguez, Caupolicán Muñoz Gamboa

Universidad del Istmo, UAM Iztapalapa
Ave. Cd. Universitaria s/n Santo Domingo, Tehuantepec, Oax.
Ave. Michoacán y la Purísima, Colonia Vicentina, México, D. F.
valdesandrea@yahoo.com.mx, cmg@xanum.uam.mx

ABSTRACT 2. METHODOLOGY
A model-based design approach for generic
automotive crash safety systems is developed. The 2.1. V model methodology
main objective of the system is to be used as a The V-Model is a software development standard
tool for developer engineers working in safety by the German Federal authorities, designed as
systems to test and verify control algorithms guidance for planning and executing development
without the need for any hardware involved. The projects, taking into account the entire system life
design methodology is a novel combination of a cycle [5]. A simplification for this model can be
“V” diagram lifecycle process model together seen in Fig. 1 showing the process composed of:
with the model-based design process. 1) Development: starting at the left part of the V
Comparative simulation is used to show that the diagram and integrated by the Requirement
model is complete and satisfies expectations. analysis, Preliminary analysis, Detail design
and Module integration.
1. INTRODUCTION 2) Verification and validation (V&V):
In the automotive industry hardware-based consisting of module, integration, system, and
simulation systems are known for being expensive acceptance tests.
and for this reason they are subjected to limited
quantities. This means that many engineers in Arrows show the emphasis on process iterations
software development areas have to design or and early testing throughout the processes prior to
modify their control strategies and wait until the a final build. Development blocks are
required hardware is available in order to test their fundamental in this methodology since they
performance. In this study, the modeling of the include all the design parameters to be tested by
crash detection environment is developed to the V&V blocks. For that reason, test cases, from
provide a tool for crash algorithms design test specifications, are generated in this part of the
engineers to test their control algorithms and process, since changes in development stages are
obtain simulated responses. An investigation of less expensive than changes in the V&V where
the required elements to consider a crash situation physical devices are involved.
and automotive safety standards and regulations
like the FMVSS No. 208 [1], which specifies Requirements
Use cases
Aceptance
performance requirements for occupant crash Analysis Test
protection is performed and applied to the
generation of the model in a way that the designer Test cases
Preliminary System Test
can get a general overview of the complete system Design
without the need for any hardware
implementation. Test cases
Considering the crash protection devices as safety Detailed Integration
Design Test
critical systems inside vehicles, this model-based
Test cases
design addresses IEEE software engineering
standard 730 [2] combined with a V diagram Module Module
Implementation Test
methodology from [3] and [4] adapted to the
particular cases involved in a crash simulation
environment. Figure 1. A V diagram process cycle [3]

181
ITCH - ELECTRO 2007
2.2. V model and model-based design
The steps involved in the development process of
the V methodology, are used to design a visual
model for the crash detection systems as follows:
2.3. Requirement analysis
This part considers the system requirements and
its environment and delivery of user level model
of functions/data/objects considering hardware
(HW) and software (SW) elements [5].
In terms of HW, a crash safety system requires
several components which can grouped into four
main blocks [6] like in Figure 2; these ones are: 1)
The sensors, involved in the impact detection,
sending data to the 2) Electronic Control Unit
(ECU), which processes the information to judge
whether or not to trigger the proper outputs for the
correspondent 3) pyrotechnical ignition devices
used to activate the 4) protection devices, like the
restraint belts and airbags.
Sensors ECU Ignition Protection
Devices
Figure 2. Hardware components in safety devices
SW specifications in a crash detection system
determines that this is divided in three general
blocks visualized by the ECU and interacting and
communicating with the external environment,
these blocks are: 1) initialization, to start the
system, 2) cycle tests, to verify the system
periodically, and 3) crash functions to detect
crashes and activate the protection devices.
General software requirements from the user point
of view are considered to determine interactions
with the blocks. These specifications establish
that:
a) These blocks run inside a segment of time
provided by a system handler which
determines the periods when the functions are
called. Figure 3 shows a diagram with the
blocks starting at fixed periods: ti for the
initialization block, tct for the cycle tests
functions, and tcf for the crash functions
block.
b) Cycle tests and crash functions have to be
executed periodically during vehicle
operation, whereas the initialization part has
to be executed only one time during vehicle
operation, at the turning on of the machine to
verify and test the input and output devices in
182
Octubre 17-19, Chihuahua, México
the equipment. Figure 3 shows the SW
modules for the requirement analysis.
Cycle Cash
Initialization
Tests Functions
ti tct tcf time
System Handler
Figure 3. Modular SW requirements in a crash
safety system. ti, tct, and tcf represent the times
when blocks are called by the system handler.
2.4. Preliminary design
For the preliminary design the structuring of
components inside the modules has to be specified
together with the interfaces and interaction
between elements [5]. Software design description
is used to define the three general SW modules
with inputs and outputs.
The Initialization module is responsible for testing
the system components and loads configuration
parameters at the beginning of the vehicle
operation. In order to perform its duties this
module requires basically two input modules one
for the configuration data and another one for the
sensors status data.
The Cycle Tests module has to perform a periodic
verification of sensors, igniters, and protection
devices, for these reasons, it also requires the
sensors status data module, plus the environment
status and the vehicle system’s status data as
inputs.
The Crash Functions module contains several
functions with the following input requirements:
1) Crash detection: impact detection is required
to be detected by exceeding a set of
thresholds that define when an impact is high
enough to consider a crash occurrence.
2) Safety detection requirements involve the use
of additionally independent input devices
besides the thresholds which only react to
high impacts to avoid false positives.
3) Sensor status for vehicle and occupants (size,
weight, seat belts use, etc.): are required to be
verified to define the trigger logic during
collisions.
4) System failures are required to be monitored
in order to define sensor correct performance.
ITCH - ELECTRO 2007
5) Triggering of the protection devices: the
system has to trigger the required protection
devices depending on the information
received and control algorithms.
6) Information register: Crash records have to be
registered and stored in ECU’s memory due
to the fact that regulations establish post
analysis of all crash events on the roads.
The model based design for the preliminary
design is established with the help of MATLAB
Simulink from The Matworks Corp. which
provides a simulation test environment suitable
for this type of system. Figure 4 shows the
approach to the preliminary design. Block
modules are used to represent the system handler
and input and output data, the functions
Initialization, Cycle_Tests and Crash_-Functions
are represented by state charts since they are
executed by the events generated in the System
Handler module. For visualization purposes input
and output data (Input_data and Output_data) are
indicated in the charts, however they will be
defined in the next design step. The control
algorithm will be located inside the
Crash_Functions chart and for this reason, there
is an output terminal (Output_Data) to satisfy the
above mentioned requirements in 5) for the
triggered signals and 6) for information
registering.
Figure 4. Requirement analysis for the crash
system.
183
Octubre 17-19, Chihuahua, México
2.5. Detail design
Description of the components and modules with
respect to the real implementation of their
functions, the data administration and error
handling specifications has to be considered here
[5]. Components in the previous design are
detailed by defining their internal characteristics
and their input and output variables in order to be
able to interact with each other and with the
external environment under the different
conditions a crash occurrence may have.
In order to be compatible with external modules
operating in the automotive environment,
requirements for the Initialization, Cycle_Tests
and Crash_Functions modules establish that input
data will be read from registers defined as global
variables stored in shared files, this way, the input
modules are defined containing sets of identifiers
depending on their source. Figure 5 is an example
of an input data definition, the Occupant Sensors
block, which contains two inputs: Occupant
Status to contain vehicle’s occupant status and
Doors Status to contain vehicle’s doors status. All
this type of input registers are defined as blocks of
constants in Simulink because they can be linked
to external files where the information to be
transferred can be placed by different
applications.
Figure 5. Occupant Sensors block definition.
Requirements to detect impacts for the crash
functions module are analyzed in detail to define
the threshold levels and crash classification for:
front, side, rear, rollover crash, and crash severity
type I (severe) and type II (very severe). Crash
classification is important to determine the type of
protection device to be activated depending on the
circumstances which are based on:
1) Occupant classification system (OCS) to
determine occupants’ size, weight, and
position; seat monitor sensors, Passenger cut
ITCH - ELECTRO 2007
of airbag (PACOS) to define deactivation of
passenger airbags; power supply status;
vehicle speed, and wheel position.
2) Requirements to detect failures due to
protection devices, accelerometers, and
battery conditions also define the trigger
logic.
3) Requirements to define which protection
devices will be activated depending on their
status and availability, together with the use
or not of seat belts by the occupants. These
devices are: lap belt pretensioners, belt
pretensioners, front airbags in level I or II,
side airbags, and inflatable curtains.
4) Information requirements consider storing the
crash relative information into the DVRAM
memory. All sensor status, crash type and
severity, passenger status, system vehicle and
devices activated have to be stored as the last
part of the process.
Figure 6 shows the detailed design for the Crash
Functions chart with its classified blocks inputs
according to their sources. Outputs are grouped
and classified according to their destination:
igniters, crash records, emergency for system
errors, and timers for the actuators. Figure 7
shows a segment detailed design from the cycle
test. Inside the chart status changes in sensors and
environment variables are stored in C type
variables that can be sent to the workspace
MATLAB environment.
Figure 6. Crash_Functions chart for the detailed
design.
184
Octubre 17-19, Chihuahua, México
Figure 7. Cycle Tests segment chart for the
detailed design.
2.6. Module integration
This part defines the conversion of programming
specifications to statements in the chosen
programming language, and integration of the
modules and subsystems to the system [5]. The
specifications given by different customers
require diverse algorithms which are implemented
in C language. These algorithms are integrated as
“Target Builder Code “, in the MATLAB
Stateflow charts. Variable names were
homogenized by typedef and define statements in
a general header file. Due to the fact that the
system is inside a microcontroller environment,
time periods to run the system are simulated by
sample based variables and transition data from
inputs and outputs are placed in C type register
variables. Input data are defined as constant
blocks which can be modified by workspace
variables interfacing with external applications
like Excel or GUIDE, the MATLAB Graphical
User Interface Development Environment.
2.7. Verification and Validation
Verification and Validation (V&V) consist of the
testing of the simulation environment by the test
cases developed from specification requirements.
Modules tests were conducted to verify the correct
module implementation by loading the
corresponding control algorithms inside the charts
(initialization, cycle tests, and crash functions
routines). Algorithms were loaded without
modifications and monitored to perform the same
as in their C original project.
ITCH - ELECTRO 2007 Octubre 17-19, Chihuahua, México

An integration test was carried out with all model- simulation allows a better understanding of the
based modules plus the C header files from system behavior and 100% visualization of all the
external modules transferring the vehicle parameters involved in the simulation, which is
parameters. Data integrity between internal and more complicated for the complete system due to
external modules were correlated to prove that the the fact that all the inputs and outputs implicated
system runs reliably. have to be measured with a high quantity of
hardware involved.
The system test is evaluated by using three
different algorithm concepts loaded into the Traditional automotive software development
modeled system. Each concept belonging to a time required for the design of a new model for
separate project with different monitor and control one specific application takes an average of 18
algorithms was linked to the generic system by the months to be completed [7], considering the
mentioned “Target code”. Test specifications from V&V, versus this generic model which took
each project were tested by using combinational approximately 6 months including V&V. This
tables loaded by the program from Excel files. All shows a development time reduction of more than
the possible inputs from all the blocks were 50%.
executed and verified that the correct outputs were
performed by the system. Figure 8 shows an The designed model was able to detect and correct
example of these tables: the table for the case of a logic failures before any physical implementation
“side crash” where the LAP belt pretensioners for is done, so it improves the design cost reduction
driver and passenger igniters are tested. Twenty due to time. Besides time, the hardware required
eight combinational tables were tested to satisfy to simulate crash detection systems has costs in
the integration and system test specifications. the order of the tens of thousand dollars and can
be used only by one user at a time, whereas the
Output Output
Initial
Values
Test
Input 1 Input2 1 2
license required for the software simulation for
conditions case
commercial use costs around US $7500 [8] and
Belt_Driv Belt_Pass
Belt_Driver_
er enger
LAP_D LAP_P several engineers can work with the same model
Equipped Yes
Belt_Passen
in parallel without interference.
gr_Equippe
d Yes 1 No No No fired No fired 4. CONCLUSIONS
LAP
Belt_Driver_ This project has demonstrated that the model-
Equipped Yes 2 Yes No fired No fired based software approach we have implemented
LAP
Belt_Passen
for crash detection systems provides a basis for
ger_Equipp software development for multiple targets because
ed Yes 3 Defective Yes fired fired it is not hardware oriented. The model has proven
ADLL_Drive
r Not 4 No Defective No fired fired to be a powerful visual tool to generate quality
ADLL_Pass software in less time because design engineers can
enger Not 5 Yes Yes fired fired
get a general overview of all the elements
Figure 8. Input/output table for LAP belt involved in safety critical systems, particularly for
pretensioner case side crash occurrence. crash occurrences, which otherwise would mean
higher costs in hardware and time setup. The
To satisfy acceptance tests, five software advantage is faster and lower cost implementation
engineers unfamiliar with model-based design by also "re-using" the model with different control
were taken to a 30 min. slide show presentation algorithms without modification.
and after that they were required to operate the
simulated model to verify the user requirements, The use of the combined V model methodology
finding no problems to either understand the proposed has demonstrated to be applicable for
model’s behavior or perform simulations. model-based design in critical systems to facilitate
engineers’ design of complex systems considering
3. RESULTS the entire life cycle of the development process.
The model-based crash system simulation and
analysis was compared with the current hardware The project can also be used as a basis for future
implementation in terms of user visualization and safety systems development like crash level
measurement capabilities, showing that system estimation, rollover type determination, and

185
 ITCH - ELECTRO 2007 Octubre 17-19, Chihuahua, México

control of protection devices deployment by Development. American Institute of Aeronautics

detailing and including new blocks to the system and Astronautics, The MathWorks News letter.
without modifying the existing ones. Available:
http://www.mathworks.com/company/newsletters/
5. BIBLIOGRAPHY index.html
[1] Federal Motor Vehicle Safety Standards [12] Langenwalter J., Erkkinen T. Embedded
and Regulations, Standard No. 208. U.S. Steer-by-Wire System Development. Embedded
Department Of Transportation, National Highway World, The MathWorks News letter. Available:
Traffic Safety Administration. Available: http://www.mathworks.com/company/
http://www.nhtsa.dot.gov/cars/rules/import/FMVS newsletters/index.html
S/index.html [13] Nozumi S. Development of Occupant
[2] IEEE Std. 730-1998 IEEE Standard for Classification System for Advanced Airbag
Software Quality Assurance Plans –Description. Requirements. Mitsubishi Motors Technical
Available: Review 2004, No.16 pp 61-64. Available:
http://standards.ieee.org/reading/ieee/std_public/d http://www.mitsubishi-
escription/se/730-1998_desc.html motors.com/corporate/about_us/technology/revie
[3] Balzert H. Lehrbuch der Software- w/e/index.html.
Technik. Spektrum Akademischer Verlag. p 101
Vol. 1, 2. ed. 2000.
[4] Valdés O. A. Development of a Model-
Based Design Approach for Generic Crash
Functions Based on Various Customer
Requirements Including Standard Test
Enviroment. Master thesis International
Automotive Engineering. University of Applied
Sciences. Ingolstadt, Germany. January 2007.
[5] IABG Information Technology. The V-
Model as Software Development Standard. IABG
Industrieanlagen, Germany, pp 1-8. Release 1995.
[6] Martin G.Y. Airbag triggering in a
numerical vehicle fleet. Master thesis Mechanical
Engineering. Eindhoven University of
Technology, Faculty of Mechanical Engineering,
The Netherlands. p. 9. Jan 2004.
[7] Elof Frank. VSPs spur on-time delivery
of embedded automotive systems software: Part
2. Embedded.com. Available:
http://www.embedded.com/showArticle.jhtml?arti
cleID=193401990&pgno=2
[8] The MathWorks Products and Prices
North America Individual, April 2007. Available:
http://www.mathworks.com/store
[9] Allen W. J. et al. Development of a
Model-Based Powertrain and Vehicle Simulator
for ECU Test Benches. Society of Automotive
Engineers World Congress, Detroit, MI, vol. 1,
pp. 1062–8, 2006
[10] Zhang H. et al. Integrated Optimization
System for Airbag Design and Modeling by
Finite Element Analysis. Society of Automotive
Engineers World Congress, Detroit, MI, vol. 1,
pp. 0506–7, 2003.
[11] Barnard P. A. Software Development
Principles Applied to Graphical Model

186

View publication stats