ingolstad university of applied sciences

INGOLSTADT UNIVERSITY OF APPLIED SCIENCES

DEVELOPMENT OF A MODEL-BASED DESIGN APPROACH FOR GENERIC CRASH FUNCTIONS BASED ON VARIOUS CUSTOMER REQUIREMENTS INCLUDING STANDARD TEST ENVIROMENT By

Ofelia Andrea Valdés Rodríguez A thesis submitted in partial fulfillment of the requirements for the degree of

Master in International Automotive Engineering

Issued on: August 26, 2006 Submitted on: January 20, 2007 First examiner: Prof. Dr. Robert Gold Second examiner: Prof. Dr. Lorenz Gaul

ABSTRACT

The development of a model-based design approach for generic

crash

functions

based

on

various

customer

requirements including standard test environment begins with the common inputs and outputs considered for crash algorithms and covers the trigger logic for the deployment of the system and the information stored based on different circumstances. The thesis presented uses Matlab Simulink and Stateflow for the modeling and opens the possibility for future projects in this industry by showing how applicable and easier is to implement complex algorithms by using these tools.

By Ofelia Andrea Valdés Rodríguez

Chairperson of the Supervisory Committee:

Prof. Dr. Robert Gold Software Engineering und Programmiersprachen

TABLE OF CONTENTS

ACKNOWLEDGMENTS .............................................................................................. v LIST OF FIGURES .......................................................................................................... vi LIST OF TABLES .......................................................................................................... viii GLOSSARY ........................................................................................................................ ix 1. INTRODUCTION ....................................................................................................... 1 1.1. Statement of the problem ................................................................................... 1 1.2. Motivation .............................................................................................................. 2 1.3. Objectives .............................................................................................................. 2 1.4 Approach................................................................................................................. 3 1.4.1. Approach methodology ................................................................................. 3 2. CONCEPTUAL FRAMEWORK .............................................................................. 5 2.1. Occupant crash protection systems .................................................................. 5 2.2. Seat belts and seat-belt pretensioners ............................................................... 5 2.2.1. Operating concept ........................................................................................... 5 2.2.2. Variants ............................................................................................................. 7 2.3. Airbags ................................................................................................................... 8 2.3.1. Operating concept ........................................................................................... 8 2.3.2. Variants ............................................................................................................. 9 2.4. Components of the safety systems.................................................................. 10 2.5. Principles of advanced airbag systems ............................................................ 10 2.6 Crash algorithms considerations ....................................................................... 11 2.7. Algorithm approaches for crash systems ....................................................... 13 2.7.1. Intrusion, deformation and crash severity ................................................ 13 2.7.2. Offset and crash severity.............................................................................. 14 2.7.3. Door slam protection in case of side crashes........................................... 14 i

3. MODEL-BASED DESIGN METHODOLOGY ............................................... 15 3.1. Model development principles ......................................................................... 15 3.1.1. Block diagrams ............................................................................................... 15 3.1.2. State diagrams ................................................................................................ 18 3.2. Crash model system design............................................................................... 19 3.2.1. Requirements analysis ................................................................................... 21 3.2.1.1. User requirements .................................................................................... 21 3.2.1.2. System requirements ............................................................................... 22 3.2.1.2.1. Initialization ......................................................................................... 22 3.2.1.2.2. Cyclic timing ........................................................................................ 23 3.2.1.2.3. Crash functions ................................................................................... 23 3.2.1.2.4. Implementation in Matlab Simulink ............................................... 24 3.2.2. Preliminary design ......................................................................................... 24 3.2.2.1. Crash occurrence detection.................................................................... 25 3.2.2.2. Safety detection ........................................................................................ 25 3.2.2.3. Determine sensor states .......................................................................... 26 3.2.2.4. System fault detection ............................................................................. 26 3.2.2.5. Deployment execution ............................................................................ 27 3.2.2.6. Register and store information .............................................................. 27 3.2.2.7. The Matlab model-based preliminary design...................................... 27 3.2.3. Detailed design............................................................................................... 28 3.2.3.1. Initial input requirements ....................................................................... 28 3.2.3.2. Detection requirements .......................................................................... 28 3.2.3.3. Safety detection requirements................................................................ 28 3.2.3.4. Sensor states requirements ..................................................................... 29 3.2.3.5. System fault detection requirements .................................................... 30 3.2.3.6. Output deployment requirements ........................................................ 30 3.2.3.7. Register and store information requirements ..................................... 31 3.2.3.8. Input data types definition ..................................................................... 32

ii

3.2.3.9. Output data types definition .................................................................. 33 4. IMPLEMENTATION ALGORITHM .................................................................. 35 4.1. Scope of the crash algorithm ............................................................................ 35 4.1.1. Frontal algorithm requirements .................................................................. 35 4.1.2. Algorithm frontal events .............................................................................. 35 4.1.3. Adaptive load limiter (ADLL)..................................................................... 36 4.1.4. Side algorithm requirements........................................................................ 36 4.1.5. Algorithm side events ................................................................................... 36 4.1.6. Rear algorithm requirements ....................................................................... 36 4.1.7. Rollover algorithm requirements................................................................ 36 4.1.8. Adaptability..................................................................................................... 37 4.1.9. Plausibility ....................................................................................................... 37 4.1.10. Crash recording ........................................................................................... 37 4.2. Crash algorithm interfaces ................................................................................ 37 4.2.1. Cyclic tests module........................................................................................ 37 4.2.2. Thresholds detection algorithm module ................................................... 38 4.2.3. Memory access ............................................................................................... 38 4.2.4. Ignition squibs................................................................................................ 38 4.3. Implementation in Matlab Stateflow .............................................................. 39 4.3.1. Charts definitions .......................................................................................... 39 4.4. State machines implementation ....................................................................... 40 4.4.1. Implementing the crash function initialization ........................................ 41 4.4.2. Implementing the crash handler ................................................................. 42 4.4.2.1. Initialization .............................................................................................. 42 4.4.2.2. Crash discrimination................................................................................ 44 4.4.2.3. Crash timers and firing control ............................................................. 48 4.4.3. Implementing the cyclic monitoring .......................................................... 49 4.4.4. Implementing the crash recording ............................................................. 51 4.5. Simulink model with the crash algorithm ...................................................... 51

iii

4.5.1. The Test_sequencer module ....................................................................... 51 4.5.2. The System_handler module....................................................................... 52 4.5.3. The generic Crash_functions module ....................................................... 53 4.6. Custom code integration ................................................................................... 55 5. RESULTS AND CONCLUSIONS ......................................................................... 57 5.1. Validation tests .................................................................................................... 57 5.2. Test procedure development............................................................................ 57 5.2.1. Excel interface................................................................................................ 58 5.2.2. Initial conditions ............................................................................................ 58 5.2.3. Input tables ..................................................................................................... 59 5.2.4. Simulink output tables .................................................................................. 60 5.3. The Matlab graphical user interface ................................................................ 63 5.4. Conclusions ......................................................................................................... 67 ABBREVIATIONS ......................................................................................................... 69 BIBLIOGRAPHY ............................................................................................................ 70 APPENDIX A. Input tests tables .............................................................................. A-1 A.1. Key words used in the test specifications converted to numeric values ... A-1 A.2. Frontal crash trigger logic .................................................................................. A-1 A.3. Offset crash trigger logic .................................................................................... A-6 A.4. Side crash trigger logic ........................................................................................ A-6 A.5. Rear crash trigger logic ....................................................................................... A-8 A.6. Rollover trigger logic........................................................................................... A-9

iv

ACKNOWLEDGMENTS

The author wishes to express her sincere appreciation to Professor Robert Gold for his assistance in the guide of this project. In addition, special thanks to Ulrich Haunschild for his dedication and time doing the updates of the project and helping with the organization of the tasks. Thanks also to Andreas Schmid for his valuable inputs. And my sincere thanks to Mr. Andreas Bernitt for supporting the project since the beginning up to then end. A special thanks to Conti Temic for giving me the opportunity to work and cooperate inside the company together with all the engineers involved in the crash algorithms.

v

LIST OF FIGURES

Number

Page

2.1. Three point seat belt where the support is provided by three points ......... 6 2.2. The belt retractor before and after the ignition .............................................. 7 2.3. Airbag and inflation system stored in the steering wheel.............................. 8 2.4. Components of safety systems......................................................................... 10 2.5. Overview of advanced airbag requirements .................................................. 12 3.1. Block diagram representing an amplifier with input and output ............... 15 3.2. Blocks with identifiable behavior .................................................................... 16 3.3. Subsystem that encapsulates adding signals operations .............................. 16 3.4. Hierarchy in a system. ........................................................................................ 17 3.5. The basic elements of a state diagram. ........................................................... 18 3.6. Parallel super states containing hierarchical sub states. ............................... 19 3.7. A V diagram of system development. ............................................................ 20 3.8. The generic crash algorithm expectations...................................................... 22 3.9. General crash model ......................................................................................... 24 3.10. General crash model with its main inputs ................................................... 28 3.11. General crash model with classified inputs and outputs........................... 32 3.12. Inside the Sensors States module ................................................................ 33 4.1 Crash functions initialization state inside the Init_crash module ............. 39 4.2. Stateflow states inside the Crash_functions module ................................. 40 vi

4.3. Initialization state for the crash algorithm ..................................................... 42 4.4. Initialization of the crash_handler state ....................................................... 43 4.5. Crash discrimination inside the crash handler .............................................. 45 4.6. Stage 1 discrimination for the crash algorithm ............................................. 46 4.7. Side crash discrimination for the crash algorithm ........................................ 47 4.8. Rollover discrimination for the crash algorithm ........................................... 47 4.9. Timing and firing control in the crash_handler ......................................... 48 4.10. The cyclic_monitoring state ........................................................................ 50 4.11. The crash_recording state ............................................................................ 51 4.12. Test sequencer chart for the generic crash algorithm................................ 52 4.13. System handler module ................................................................................... 53 4.14. Crash functions chart....................................................................................... 54 4.15. Custom code integration in Stateflow .......................................................... 55 4.16. Custom code integration in the general header .......................................... 56 5.1 Graphical user interface for the validation tests ............................................ 60 5.2 Generic crash graphical user interface ............................................................. 63 5.3 Belt buckles and LAP belt pretensioners input sensors ............................... 64 5.4 The safety sensors with their possible status .................................................. 64 5.5 Upfront sensors possible status ........................................................................ 65 5.6 Voltages in Battery and Autarchy ..................................................................... 65 5.7 Setting thresholds in the Threshold panel ...................................................... 66 5.8 Ignition loops triggered during a crash simulation ........................................ 67

vii

LIST OF TABLES

Number

Page

3.1. Triggered devices correspondence with ASIC outputs ............................... 34 5.1. Triggering specifications for the driver belt pretensioner ........................... 57 5.2. Test specs key words conversion to numeric values in the Excel tables . 58 5.3. Initial conditions for the crash tests ................................................................ 59 5.4. Excel input table for the shoulder belt pretensioner tests .......................... 59 5.5. Results table for the shoulder belt pretensioner tests .................................. 61 5.6. Recorded information from the crash algorithm simulation ..................... 62

viii

GLOSSARY

Airbag. Flexible membrane or envelope, inflatable to contain air or some other gas. Autarchy condition. Condition when the system no more depends on the battery voltage but on the reserve capacitors. Belt pretensioner. Restraint system to fix the occupant and prevent occupant movement in the vehicle during a crash situation. Ignition circle. Output for the device to be fired in case of a crash occurrence. Inflatable curtain. Special airbag designed to keep the head and upper part of the body inside the vehicle. Lap belt. The part of the seat belt that rests over the pelvis. Matlab. Computer program from The MathWorks that uses a high-level technical computing language and interactive environment for algorithm development, data visualization, data analysis, and numeric computation. Shoulder belt. The part of the seat belt, which extends across the chest. Simulink. Software package for modeling, simulating, and analyzing dynamic systems. Stateflow. Interactive design and simulation tool for event-driven systems.

ix

CHAPTER 1

INTRODUCTION

1. INTRODUCTION

1.1 Statement of the problem Automobile manufacturers face increasing legal requirements and customer demand for measures to protect vehicle occupants in collisions thus generating every day more complex algorithms which also depend on how every manufacturer wants to solve his expectations. With more complicated tasks to be achieved, the utilization of hand-coded software in the process of algorithm development causes longer time-consuming, and limits the visualization of the complete system. This in turn, requires designers to expend more time to be familiar with the models and longer time is invested to test different components of the complete logic, which may lead to detection and fixing design errors later in the product development phase, which is more expensive because vast portions of the system must be re-engineered. Besides all these problems, when source code is written by somebody else, even if a formal writing method was used to ensure software correctness, only a few experts worldwide can truly understand it due to the high level of complexity used in automotive control applications. A new approach is needed to improve the software development and reduce the time for its realization and tests in order to be competitive in today‟s automotive industry where the demand for fast and reliable products is a key to maintain a leadership in the market.

1

CHAPTER 1

INTRODUCTION

1.2 Motivation Considering how difficult and time consuming it is to understand at the beginning (generally with several thousand lines of code for only one source code file, plus many header files included) and to be able to modify or design the complete crash algorithms at the end from different requirements in the automotive industry; the necessity to use a more general and easier approach is remarkable and there is a high motivation for going to the next level of abstraction which may improve the current situation: the system-level design. The opportunity to use a model-based strategy where models can be graphically defined and tested against real models using simulation has not yet been applied for crash algorithms, besides that, there is a trace to change the traditional way of development by using this method together with automation code generation, as the demand for high integrity safety critical software intensifies.

1.3. Objectives The main objective is the development of a model-based algorithm for triggering advanced airbag systems in generic vehicle models, depending on different customer requirements and to provide a standard test environment for simulation. Provide a tool for the crash algorithm engineers to easily understand and modify the crash functions. Provide a template to implement different crash algorithms. Establish the basis for future model-based design developments.

2

CHAPTER 1

INTRODUCTION

1.4. Approach The Model-based Design is the approach selected to develop the generic crash algorithm and Matlab Simulink with Stateflow is the platform more suitable and available to work with because the crash algorithm is a state machine and Stateflow is designed to model finite-state machines. Simulink together with Stateflow are interactive graphical tools dedicated to model-based simulation where systems can be implemented and simulated under different conditions, like time settings, different input settings, creation of driven events, creation of failures, and so on, which enhance the possibilities to improve the software process where verification and validation can be performed in every step of the design cycle.

1.4.1 Approach methodology First of all a literature survey is performed in order to gather information of existing airbag algorithm concepts and the main aspects of airbag systems. The literature includes general approaches in the automotive industry and the software specifications with the source code from three different projects in the company taken as base for being from different customers and needing different hardware implementation. The results of the literature study and the analysis of the projects are used in order to develop a general algorithm concept. This new model is considered as a transparent interface between the relative crash software modules and the crash algorithm itself. This means that no more additional interfaces for hardware or communication of the vehicle parameters are needed.

The generic concept will be validated by using the crash specifications test data from one project, the most complete of the three for being the one which involves more variables and the highest complexity in hardware and software. 3

CHAPTER 1

INTRODUCTION

The platform must satisfy all the triggering requirements for different conditions indicated in the specifications together with the crash information that has to be stored during the events. At the end a user interface for testing different crash conditions and storing the simulations is developed together with an interface for Excel where the user can modify input parameters and write different test cases for validation of new modifications to the algorithm.

4

CHAPTER 2

CONCEPTUAL FRAMEWORK

2. CONCEPTUAL FRAMEWORK

2.1. Occupant crash protection systems Standards for occupant protection like the FMVSS No. 208 [8] define requirements for vehicles in crashes to protect the occupants against serious or fatal injuries, part of these means are the airbags and the belt pretensioners which will be briefly described as follows.

2.2. Seat belts and seat-belt pretensioners The function of the seat belts is to restrain the occupants of a vehicle in their seats when the vehicle hits an obstacle. Seat-belt tighteners improve the restraining characteristics of a three-point inertia-reel belt and increase the protection against injury. In the event of a frontal impact, they pull the seat belts tighter against the body and thus hold upper body as closely as possible against the seat backrest. This prevents excessive forward displacement of the occupants caused by mass inertia and the dangerous “submerging” effect [2].

2.2.1. Operating concept In a frontal impact with a solid obstacle at the speed of 50 km/h, the seat belts must absorb a level of energy comparable to the kinetic energy of a person in free fall from the 4th floor of a building. Because of the belt slack, the belt stretch and the delayed effect of the belt retractor (film reel effect), three point inertia-reel belts (see figure 2.1) provide 5

CHAPTER 2


only limited protection in frontal impacts with solid obstacle at speeds of over 40km/h because they can not longer safely prevent the head and body from impacting against the steering wheel or the instrument panel. 3

2

1

Figure 2.1. Three point seat belt where the support is provided by three points.

In an impact, the shoulder belt tightener compensates for the belt slack and the “film reel effect” by retracting and tightening the belt strap. At an impact speed of 50km/h, this system achieves its full effect within the first 20ms of the impact; and thus supports the airbag, which needs approx. 40ms to inflate completely. The occupant continues to move forward slightly until making contact with the deflating airbag and in this manner is protected from injury. A prerequisite for optimum protection is that the occupant‟s forward movement away from their seats remains minimal as they decelerate along with the vehicle. This is achieved by triggering the belt tighteners immediately upon initial impact to ensure that safe restraint of the occupants in the front seats starts as soon as possible. The maximum forward displacement with tightened seat belts is approx. 1cm and the duration of the mechanical tightening is 5-10ms.

6

CHAPTER 2


On activation, a pyrotechnical propellant charge is electrically fired. The explosive pressure acts on a piston, which turns the belt reel via a steel cable in such a way that the belt rests tightly against the body [5]. The figure 2.2 shows the effect of the pyrotechnical propellant before and after the explosion.

Figure 2.2. The belt retractor before and after the ignition [5].

2.2.2. Variants In addition to the above mentioned shoulder-belt pretensioners for retracting the belt-reel, there are variants to pull the belt buckle back (buckle pretensioners) and thus simultaneously tighten the shoulder and the lap belts. Buckle pretensioners improve the restraining effect and the protection afforded against occupants sliding forward beneath the lap belt still further. The tightening process in these 2 systems takes place in the same period of time as for the shoulder belt pretensioners. High performance pretensioners are able to pull back an extended belt approx. 18cm in length in roughly 5ms [5].

7

CHAPTER 2


2.3. Airbags Airbags are most commonly used for cushioning, in particular after very rapid inflation in the case of a collision. [1]

2.3.1. Operating concept When there is a moderate to severe frontal crash that requires the frontal airbag to deploy, a signal is sent to the inflator unit within the airbag module. An igniter starts a chemical reaction, which produces a gas to fill the airbag, making the air bag deploy through the module cover. The device is inflated to a certain volume (35 to 70 l for a driver‟s airbag, 70 to 150 l for a passenger airbag). The gases used to fill airbags are harmless. From the onset of the crash, the entire deployment and inflation process takes only about 1/20th of a second; triggering and deployment takes around 20ms and the inflation takes approximately 30 ms (depending on size of airbag). Because a vehicle changes speed so fast in a crash, airbags must inflate rapidly if they are to help reduce the risk of the occupant hitting the vehicle's interior.

Figure 2.3. Airbag and inflation system stored in the steering wheel [3]

8

CHAPTER 2


Airbags are typically designed to deploy in frontal and near-frontal collisions, which are comparable to hitting a solid barrier at approximately 13-22.5 km/h. Once an airbag deploys, deflation begins immediately as the gas escapes through vents in the fabric [3].

2.3.2. Variants Many airbag technologies are being developed to tailor airbag deployment to the severity of the crash, the size and posture of the vehicle occupant, belt usage and how close that person is to the airbag module. Many of these systems use multistage inflators that deploy less forcefully in stages in moderate crashes than in very severe crashes. Occupant sensing devices let the airbag diagnostic unit know if someone is occupying a seat in front of an airbag, whether the person is an adult or a child, whether a seat belt or child restraint is being used and whether the person is forward in the seat and close to the airbag module. Based on this information and crash severity information, the airbag is deployed at either a high force level, a less forceful level or not at all. Many new vehicles are also equipped with side airbags designed to reduce the risk of injury in moderate to severe side impact crashes. These airbags are generally located in the outboard edge of the seat back, in the door or in the roof rail above the door. Seat and door-mounted air bags all provide upper body protection. Some also extend upwards to provide head protection. Two types of side air bags, known as inflatable tubular structures and inflatable curtains, are specifically designed to reduce the risk of head injury and/or help keep the head and upper body inside the vehicle. A few vehicles are now being equipped with a different type of inflatable curtain designed to help reduce injury and ejection from the vehicle in rollover crashes [1].

9

CHAPTER 2


2.4. Components of the safety systems An airbag system contains several components and can be divided into four main components (figure 2.4).

1. Sensors

2. ECU

2. Ignition

3. Protection Devices

Figure 2.4. Components of safety systems.

1. Sensors: the sensors detect the type of impact (frontal, offset oblique or pole, side, rear and roll over) and send their signal to the electronic control unit (ECU). They are placed on several locations in the vehicle. 2. ECU: the electronic control unit (ECU) uses several triggering thresholds (depending on crash scenario, impact, belt usage and seat occupation) to analyse the data from the sensors to judge whether or not the device should be deployed. The ECU must also detect false-negative effects, e.g. driving over a kerbstone must not trigger the system. 3. Ignitions: one or more pyrotechnical igniters are used to inflate the airbag with (mainly) nitrogen or to tense the belt. Using multiple inflators will improve the effectiveness of the system with different size occupants. 4. Protection devices: such devices are in the case of the airbags: the front airbags, side air bags and inflatable curtains; and in the case of the seat belts: the shoulder-belt pretensioners and the lap belts described above [4].

2.5. Principles of advanced airbag systems Using “intelligent airbag systems” improves the sensing functions and control options for the airbag inflation process. Such improvement functions are: 10

CHAPTER 2


Deactivation switches. These switches can be used to deactivate the driver or passenger airbag. Special lamps indicate the airbag function states. Intelligent airbag systems. Sensing functions and control options for the airbag inflation process. Such functions are: Impact severity detection Seat-belt usage detection Seat position and backrest-inclination detection Introduction of different triggering thresholds o Stage 1, and stage 2 unbelted driver‟s airbag o Stage 1, and stage 2 belted driver‟s airbag o Stage 1, and stage 2 belted passenger‟s airbag o Stage 1, and stage 2 unbelted passenger‟s airbag o Rear-end impact stage 1 and stage 2. Use of airbags with two stage gas inflators or with a single stage gas inflator and pyrotechnically activated gas discharge valve. Use of seat-belt tighteners with occupant weight-dependent belt-force limitation. Occupant protection system.

This runs in a CAN bus network for the

communication of data (diagnostic information, warning lamp activation, etc.) and for the synergetic use of sensor data from other systems (driving speed, brake actuation, buckle switch and door- contact information) [2].

2.6 Crash algorithms considerations There are several considerations to take regarding airbag algorithms. Based on timing requirements, the airbag should not be deployed too early in order to collect enough information from the sensors to establish, with some level of accuracy, if it is needed or not. And at the same time the deployment should not occur too late in the crash event in order to make the airbag system to

11

CHAPTER 2


perform effectively. One of the factors involved in tuning of an airbag system is the determination of an optimal time of deployment that balances the two requirements outlined above [6].

Figure 2.5. Overview of advanced airbag requirements [7]

Based on the occupant protection requirements, the airbag system should consider the pre-existing crash situations for an average-size adult sitting on the front seats supplemented by a small adult sitting on the front seats and by out-ofposition and consider also the situation of a child or small adult who is sitting out of position at the time of a collision (see figure 2.5).

12

CHAPTER 2


These requirements prescribe specific conditions for both the driver seat and the passenger seat. For protection of a child sitting out of position on the passenger seat, an automaker may employ either of two options: (a) Automatic suppression feature or (b) Low risk deployment that does not completely disable the airbag but ensures that the airbag deploys in a way that minimizes the risk of airbaginflicted injuries [7]. Based on type of crash impact, the systems should determine if the impact was severe enough to require deployment of the airbag and which airbags should be deployed, to satisfy this requirement the system must determinate the velocity of the car and the direction of the impact to define which devices will be activated.

2.7. Algorithm approaches for crash systems There are several considerations to determine the severity of the crash and the risk of injure to the vehicle occupants, the mayor ones are described here.

2.7.1. Intrusion, deformation and crash severity This method considers that the crash severity and risk of injury are positively correlated with the amount of intrusion and deformation. The amount of intrusion depends on the available quantity and quality of the vehicle„s load paths through which energy can be absorbed in a specific crash. There is no intrusion in case of misuse. The possibility to sense intrusion (in time) depends also on the location of the sensors in the deformation zone. To implement the algorithm, a calculation of the intrusion must be done and determination of the possible influence on the trigger thresholds and the impact classification (soft/rigid).

13

CHAPTER 2


2.7.2. Offset and crash severity The crash severity and risk of injury depend significantly on the vehicle„s load paths through which energy is absorbed. In offset- and angle-type crashes not all load paths are used in full to absorb energy. Offset crashes, in general, show large differences between the deceleration of the left and right upfront sensor, such differences can be observed even in the initial phase of a crash. To implement the algorithm, calculation of the signal offset by taking the difference between left and right upfront sensors must be done. The influence of this difference may affect the thresholds and the impact classification (soft/rigid).

2.7.3. Door slam protection in case of side crashes. The status of the door: open/closed is obtained to influence on the trigger thresholds for side restraint systems. Higher thresholds are set when door is open or in process of closing.

14

CHAPTER 3

MODEL-BASED DESING METHODOLOGY

3. MODEL-BASED DESIGN METHODOLOGY

3.1. Model development principles The model-based design and the graphical simulation tools are used to create dynamic system models for the control algorithms and provide an abstract view of a component or system in a visual paradigm. In the graphical model design there are two basic paradigms: block diagrams and state diagrams. Both of them are often used as a means of documentation and specification [10].

3.1.1. Block diagrams Block diagrams emphasize the flow of data between units of computation. The lines on a block diagram are signals that represent data. Each line shows the direction from a source block that assigns values to one or more destination blocks that read those values. Visually, a path through a set of signals and blocks indicates a sequence of computations and intermediate results. An example can be a representative block diagram for an amplifier shown below in Figure 3.1

Figure 3.1. Block diagram representing an amplifier with input and output.

15

CHAPTER 3


Block diagrams design principles Some basic considerations can be done when designing with block diagrams: The basic blocks available in the diagram should have clear and unambiguous functionality. The key to a useful set of blocks is that each one should have an easily identifiable behavior based on its appearance like the ones shown in figure 3.2.

Figure 3.2 Blocks with identifiable behavior. To handle scalability groups of blocks and connections can be organized into a component that is represented as a single block, called a subsystem. This hierarchical representation improves clarity of a design by abstracting details at different levels.

Figure 3.3 shows an example of

one subsystem that performs adding operations.

Figure 3.3. Subsystem that encapsulates adding signals operations.

16

CHAPTER 3


To hide complexity on the computer screen blocks and systems should be organized into a hierarchy of subsystems. The figure 3.4 shows an example of hierarchies in a system.

Figure 3.4. Hierarchy in a system. The highest hierarchy corresponds to level 3 where the complete system is defined. Level 2 corresponds to middle complexity where basic blocks are located and the level 1 corresponds to basic decision states like the contents inside chart2.

The level of detail included in the modules can be adapted to the phase of design work. In early phases, simple subsystems revealing only a shell of the actual algorithms will be built. In later phases, detailed algorithms incorporating target-specific information will be included. But even at the final stages of a project, the team should still be able to view the initial, simple design at the high levels of the hierarchical model.

17

CHAPTER 3


3.1.2. State diagrams State diagrams emphasize the logical behavior of a system. State diagrams can be used to model a system with a finite set of modes, or states, that change from one mode or state to another. In Figure 3.5 rectangles with rounded corners represent the states in a system. The directed lines from one state to another are called transitions. These indicate the ability to change from one state to another. Transitions are usually labeled with the conditions that must be satisfied before the transition can be taken. Several transitions can originate or terminate on the same state [10].

Figure 3.5. The basic elements of a state diagram.

State diagrams design principles State diagrams are useful for visualizing logical paths through a series of states. A state diagram can help to clarify the exact sequence of logic that is needed to change from one state to another, particularly when each state has a small number of transitions that originate or terminate on it. Actions associated with states and transitions enable the state diagram to interact with its external environment. In Stateflow, constructs can handle hierarchy, parallelism, and transition re-use.

18

CHAPTER 3


Hierarchy allows states to be grouped together into a super state so that common transitions only need to be drawn once. Parallelism allows the diagram to be partitioned into several parallel states, each with its own hierarchy of active sub state(s). Parallelism prevents the state explosion that results when independent modes or attributes have numerous possible combinations. While hierarchy allows the states that represent the active modes of the controller to be grouped together in a natural manner; parallelism allows this logic to be combined in the same diagram with the contents of another parallel state. Figure 3.6 shows an example of parallel and hierarchical states.

Figure 3.6. Parallel super states containing hierarchical sub states.

3.2. Crash model system design The typical design process for a large system consists of a sequence of design and implementation steps that rely on documents produced at the output of a preceding step. This process is frequently depicted on a V shaped diagram to indicate the narrowing scope of the successive design steps followed by the increasingly wider scope of testing steps, as shown in Figure 3.7 [12] 19

CHAPTER 3


Use cases

Requirements Analysis

Acceptance Test

Test cases

Preliminary Design

System Test

Test cases

Detailed Design

Module Implementation

Test cases

Validation

Verification

Integration Test

Module Test

Figure 3.7. A V diagram of system development

The goals of software testing, starting at the lower right of the V diagram, include verifying the consistency of system and high level requirements. When high level requirements change there can be a considerable change in the underlying software. Without techniques to test requirements early in the design process errors propagate from one step to the next and become costly to fix. The goal of the model-based design is to find and debug as many as possible design mistakes before the hardware implementation by simulating the system. This V model is used in the development of the generic crash system to ensure that a correct sequence of design is performed. This chapter will cover from the “ Requirements Analysis” to the “Detailed Design” and the next chapter will cover the “Module Implementation” algorithm with the tests covered by the last chapter.

20

CHAPTER 3


3.2.1. Requirements analysis In order to obtain a better definition for the system the requirements analysis can be divided in two parts: user requirements and system requirements.

3.2.1.1. User requirements These requirements were established by the crash algorithm software department, which demands the following characteristics in the algorithm: A generic crash algorithm that can be applied to different customer needs. A plug and play type algorithm that does not affect the other modules involved in the crash detection. That means the source code integrated to control the ignition devices, to receive the values from the external sensors, and to store information in the memory is not affected by the crash algorithm itself, so that the transition from hand code to modelbased design can be as smooth as possible and without interference with the rest of the models involved which are seen as completely independent from each other. A model with the same code conventions like in the current projects, that means names of the macros, variables and header files used in the crash functions remain as they are set in the original projects to keep the conventions with the software specifications which are the guidelines for software development. From these requirements the first visual sketch can be done by showing the generic crash algorithm like a black box that must perfectly fit in the same place where the current projects are located to perform the required crash duties without any conflict between inputs and outputs (see figure 3.8). 21

CHAPTER 3


System handler

a b c

Current crash project

Inputs System handler

f g h Outputs

a b c

Generic Crash algorithm

Inputs

f g h Outputs

Figure 3.8. The generic crash algorithm expectations.

3.2.1.2. System requirements The system requirements are given by the software specifications. Since three different projects are involved and the algorithm pretends to be generic, the general parts needed for crash algorithms are considered first. Initialization Cyclic timing Crash functions

3.2.1.2.1. Initialization Every system needs an initialization part where the variables allocation is done, and the configuration parameters are set. In the case of crash functions, this part also has to contain Equipment settings Ignition variables settings Variables initialization 22

CHAPTER 3


Timers settings Documentation status

Equipment settings define which devices that are interacting with the crash functions are installed in the car and check their availability. Ignition variable settings determine the ignition cycles corresponding to the ECU and the status of them. Timer settings obtain the current time stored in the vehicle computer and clear the timers for the ignition variables. Variables initialization set all the required variables to their reset values. Documentation status verifies the status of the information needed to save in case of a crash event happens for documentation purposes.

3.2.1.2.2. Cyclic timing The cyclic timing defines the period of time for the functions to be called. The system assigns a segment of time for every function to run based on how fast the response to certain events has to be performed. The initialization part is called only one time at the beginning of the system startup. The crash functions are called every certain period of time defined in the system by interrupts. The crash algorithm receives the call as a trigger signal.

3.2.1.2.3. Crash functions Define which logic should be used to determine the type of crash, the severity of the crash and the triggering of the required devices. 23

CHAPTER 3


3.2.1.2.4. Implementation in Matlab Simulink The Matlab Simulink crash model is shown in figure 3.9. The functions inside the system handler module are represented inside a black box and the crash functions are represented by Stateflow graphs because they are event related.

Figure 3.9. General crash model. The stateflow graphs are defined as follows: 1. Init_crash. This module contains the initialization functions mentioned above. It will be called only one time indicated by the System_handler block. 2. Crash_functions. In this module the triggering logic for the crash events is handled. The functions inside the module will be called every period of time defined by the cyclic timing indicated in the System_handler module.

3.2.2. Preliminary design Once the system was defined in block diagrams; for the preliminary design this project considers the reasons for the crash algorithm to exist, “the mission requirements”. The performance of the algorithm itself has to satisfy all these requirements to be validated. Crash occurrence detection 24

CHAPTER 3


Safety detection Determine sensor states System fault detection Deployment execution Register and store information

3.2.2.1. Crash occurrence detection Determine when a crash has occurred and qualify the type of crash in o Front o Side o Rear o Rollover „crash events‟ based on the crash detection sensors/data and the end of a crash detection. Use the additional information of Subsystems (vehicle speed, door status) and „occupant sensors‟ (STS) to adapt the thresholds of the crash qualification classifying the crash into different crash severity levels.

3.2.2.2. Safety detection To prevent from an inadvertent crash occurrence detection Performing plausibility checks based on more „crash detection sensors / data‟ signals before qualifying a „crash event‟. Performing fault and readiness diagnostics on all „crash detection sensors / data‟, used „occupant sensors‟ and additional information of Subsystems before using the data for qualifying a „crash event‟.

25

CHAPTER 3


Usage of defined default strategies in case of faulty, not trustable or not ready „crash detection sensors / data‟

3.2.2.3. Determined sensor states The status of all the relevant sensors used for the trigger logic has to be determined. Determination of the „occupant states‟ based on „occupant sensor / data‟ (belt buckles, STS, OWS, PACOS) before using it for the trigger logic function (Sensor States) Determination of the „environment state‟ based on „environment sensors / data‟ (power supply) before using it for the trigger logic function (Environment Condition) Determination of the „equipment states‟ (System Precondition) Perform the Crash Trigger Logic function based on the o Occupant states o The environment states o The equipment states information o System information

3.2.2.4. System fault detection Safety on Determination of all Crash Trigger Logic relevant Sensor States / Data performing fault and readiness diagnostics on all „occupant sensors / data‟ before using the sensor data for a sensor occupant state determination

26

CHAPTER 3


Usage of defined default strategies and redundancies in case of faulty, not trustable or not ready „occupant sensors / data‟ Perform fault and readiness diagnostics on all „environment sensors‟ before using the sensor data for crash trigger logic function

3.2.2.5. Deployment execution Triggering of the devices on the determined severity class thresholds. Apply the safety on deployment execution by performing fault diagnostics on all components used for triggering the Outputs. Use of defined default strategies in case of faulty „Trigger Outputs‟

3.2.2.6. Register and store information Store all crash relevant data in NVRAM, regarding The crash occurrence detection The status of all Crash Trigger Logic relevant „Occupant sensor‟ and „Environment Sensor‟ States / Data The parameters that remain without change during the crash and the parameters that change during the crash.

3.2.2.7. The Matlab model-based preliminary design The figure 3.10 shows the model-based approach considering the added requirements. The first part of the first approach is kept, while the second part is enhanced by the classification of the inputs in five general groups depending on each requirement, and one output for triggering is added. 27

CHAPTER 3


crash_f unctions init_crash

Sensor Status

System_handler

Env ironment Status crash v ariables

inputs module1

Sensor_Status

Sensors

inputs

Init_crash

Env iroment_Status

Out_Deploy ment

Sy stem Faults

0 Triggered devices

Environment Sy stem_Faults

System Crash Occurrences

Crash Types Saf ety Dev ices

Crash_Occurrences Record_inf ormation Saf ety _Detection

Safety

0 Information registered

Crash_functions

Figure 3.10. General crash model with its main inputs.

3.2.3. Detailed design The previous model now can be defined in more detail regarding the requirements for its inputs and outputs.

3.2.3.1. Initial input requirements In this part the configuration stored in the EEPROM memory is read and the devices equipped are set as available or unavailable depending on the status. These devices are the Equipped ignition outputs Equipped occupant detection devices Equipped sensors

3.2.3.2. Detection requirements These requirements can be seen as big category for the input classification.

28

CHAPTER 3


The thresholds are provided by a separate module, which uses a complex differentiation approach to define the type of crash and the severity of the impact. So, the crash algorithm only receives the type of threshold or thresholds that were reached during a crash event and decides which actions shall happen in each crash type. The main crash thresholds reached during a crash event are: Front crash threshold Side crash threshold Rear crash threshold Stage 1 impact class threshold Stage 2 impact class threshold Rollover threshold Where the stage1 refers to a kind of light impact or low severity impact and stage 2 refers to a higher severity impact.

3.2.3.3. Safety detection requirements The special devices to verify a crash event and which have to be considered in the triggering logic are commonly named „trigger switches‟. Together with them, the fault detection is used for verification.

3.2.3.4. Sensor states requirements The sensors are very important to determine the logic for the deployment of every device in the crash algorithm. In this case most of the input requirements correspond to this class, and the definition for each requirement input is given as follows: Occupant Classification Status (OCS) define the occupant characteristics like the: 29

CHAPTER 3


Weight to determine if there is an occupant on the seat, a child seat or nothing. Size, to determine if the occupant is large, small or a child.

Passenger Airbag Cut Off Switch (PACOS) system determines when the passenger airbag should not be activated due to a child occupant. Power supply status defines the operating voltage level while running the system. This level can be: under voltage, normal voltage, over voltage, or running with the reserve voltage called Autarky or Autarchy. Seat Track Sensors (STS) determines the status of the belt buckles on the seats like belted, unbelted or defective for every occupant in the vehicle. Some vehicles may have equipped STS sensors and some not. The vehicle speed helps to determine the severity of the crash. Steer position is important to define the position of the driver

3.2.3.5. System fault detection requirements Faults related to the Airbag stages Accelerometer sensors Battery off condition are considered in this classification to complement the trigger logic.

3.2.3.6. Output deployment requirements Depending on the equipped detection and the status of the sensors, the triggering must be set for the following protection devices in the vehicle: 30

CHAPTER 3


Lap belt buckles Shoulder belt pretensioners Front airbags stage 1 and stage 2. Side airbags Inflatable curtains Adaptive steering column

According to the thresholds received in the crash algorithm every correspondent device must be triggered and the status of the deployment monitored.

3.2.3.7. Register and store information requirements For these requirements it must be verified that the correct status of the environment variables (sensors and system status), the crash occurrence and the triggered devices are registered in the ECU‟s EEPROM, so it can be checked after the unit is dismounted from the vehicle for a reference analysis of conditions. With the previous definition of requirements a third concept can be defined. In the figure 3.11 it can be seen that for the Init_crash chart, a set of static equipment is defined as input and for the crash_functions chart the inputs are classified now in several groups and the outputs are defined also in two categories: ASIC devices and information storage.

31

CHAPTER 3


crash f unctions init_crash

System handler Equipped dev ices

Equipment Initialization

Battery and Autarchy

Enviroment

Equipment

Init_crash

Voltage lev els

0

ASIC_0 Belt buckles status

ASIC 0 Belt buckles Occupant status

Occupant status PACOS status

Airbag supression speed Steer position

Sensors States Front crash Side crash

Vehicle speed status

0

ASIC_1

Steer position status

ASIC 1

Front crash detection Side crash detection Rear crash detection

0

ASIC_2

Rear crash Stage 1 Stage 2 Rollov er

Thresholds

Stage1 detection

ASIC 2

Stage 2 detection Rollov er detection Record inf ormation

Trigger switches

Trigger switches

Safety devices

Crash_funtions

0 Information registered status

Figure 3.11. General crash model with classified inputs and outputs.

3.2.3.8. Input data types definition The input information received by the crash module is provided by global variables that can be accessed for the different modules in the complete project. The data types are taken from the definition of the variables in the project‟s header files where variables are initially declared. For the simulation the input to Simulink is done via constant blocks where the data can be placed by external modules. Figure 3.12 shows an example for the input constants inside the Sensor

States module. 32

CHAPTER 3


In the charts the variables can be declared as “inherited” and the option “use strong data typing” is selected so there is not concern for the data types during the code.

Figure 3.12. Inside the Sensors States module.

3.2.3.9 Output data types definition The outputs have to be sent to several ASICs (Application-Specific Integrated Circuits) where every device to be triggered is mapped depending on the project configuration. The ASICs used in the company consist of 8 bit registers so the output data types are defined as unsigned bytes. In order to be generic, this project uses an excel data sheet where the codification for every project can be stored. The user interface reads the file, interprets the code and shows the correct assignment. The table 3.1 shows an example of codification for one project. Every output is identified by an ID macro definition that corresponds to the index. From the table index position the ASIC number and ASIC output can be determined. 33

CHAPTER 3


Name

Index

ID

ASIC #

ASIC Output

Ignition Cycle

Airbag stage 1 Driver Airbag stage 2 Driver Airbag Stage 1 Passenger Airbag Stage 2 Passenger Adaptive Steering Column Rear Belt Pretensioner Left Rear Belt Pretensioner Med Rear Belt Pretensioner Right Side Bag Left Side Bag Right Door Mounted Inflatable Curtain Left Door Mounted Inflatable Curtain Right Belt pretensioner passenger Adaptive Load Limiter Passenger Adaptive Load Limiter Driver Belt pretensioner driver Roll Over Bar Left Roll Over Bar Right Lap Belt Pretensioner Passenger Lap Belt Pretensioner Driver

0 1 2 3 4 5 6 7 8 9 10

AB1_D AB2_D AB1_P AB2_P ASC RBP_L RBP_M RBP_R SB_L SB_R DMIC_L

2 2 2 2 2 2 1 1 1 1 1

1 4 0 3 5 2 0 4 1 2 5

0 1 2 3 4 5 6 7 8 9 10

11 12 13 14 15 16 17 18 19

DMIC_R SHBP_P ADLL_P ADLL_D SHBP_D ROB_L ROB_R LAP_P LAP_D

1 0 0 0 0 0 0 0 0

3 0 1 2 3 4 5 1 2

11 12 13 14 15 16 17 18 18

Table 3.1. Triggered devices correspondence with ASIC outputs.

34

CHAPTER 4

IMPLEMENTATION ALGORITHM


4.1. Scope of the crash algorithm It is important to define what are the aim and the scope for a crash algorithm to delimitate its action feel. The limits are provided by the software specifications in the three different projects that indicate the main roll of the functions involved in the crash module.

4.1.1. Frontal algorithm requirements The algorithm has to be able to detect and respond to several events during a frontal collision, which can be dependent on the crash severity, crash direction and data that is statistically relevant to determine, in which cases a certain kind of protection is more likely needed in the field.

4.1.2. Algorithm frontal events The algorithm shall be able to create trigger commands for the following restraint systems: Belt pretensioner stages Airbag stage 1 for the driver Airbag stage 1 for the passenger Airbag stage 2 for the driver Airbag stage 2 for the passenger 35

CHAPTER 4


Adaptive load limiter for the driver Adaptive load limiter for the passenger

4.1.3. Adaptive load limiter (ADLL) To decide which value for the ADLL timers should be used for driver and passenger, the algorithm has to determine the crash‟s characteristic and its severity.

4.1.4. Side algorithm requirements The algorithm has to be able to detect and respond to several events during a side collision, which are dependent on the crash severity and crash direction.

4.1.5. Algorithm side events The algorithm shall be able to create the following trigger commands: Side Left: trigger restraint systems for the left side Side Right: trigger restraint systems for the right side

4.1.6. Rear algorithm requirements The rear algorithm shall be able to detect and respond by creating an event, which is used to trigger the belt pretensioners during a rear event.

4.1.7. Rollover algorithm requirements The roll over algorithm shall detect and create 2 events rollover left / rollover right to trigger the belt pretensioner and the rollover bar. 36

CHAPTER 4


4.1.8. Adaptability The algorithm shall be adaptable to different vehicles and or crash data by means of parameter configuration stored in the ROM or EEPROM.

4.1.9. Plausibility Each trigger decision shall require relevant signals on at least two independent crash sensors. One mechanical trigger switch is used as system‟s safety concept.

4.1.10. Crash recording The algorithm shall collect data during a crash event and provide this data for later storage in the systems crash record. The crash recording stores the value of the firing related information and the exceeded thresholds.

4.2. Crash algorithm interfaces In order to perform its duties, the crash algorithm needs to interact with external modules, which provide the information required for taking decisions. The main modules affecting the algorithm are described as follows.

4.2.1. Cyclic tests module The cyclic test checks all the components. The relevant data for the crash algorithm are the following parameters: Belt buckles and STS External sensors Low and over voltage 37

CHAPTER 4


Autarky capacitor voltage Crash output Rear belt buckles Warning lamps CAN signals Occupant Classification Sensors (OCS) Passenger Airbag Cut Off Switch (PACOS) Rollover sensors (ROS)

4.2.2. Thresholds detection algorithm module This module determines the occurrence of the crash events and set the proper threshold or thresholds for the crash algorithm to use them in the triggering logic. The thresholds were defined above in the frontal, side, rear and rollover events.

4.2.3. Memory access These are the sets of activities related to read configuration parameters or to set the recorded information from the crash events.

4.2.4. Ignition squibs The crash algorithm shall activate a number of squibs, which fire the occupant protection devices. The restrain system has to trigger the ignition loops depending on the output information from the algorithm, which is handled based on interface variables providing the status of the squibs, the information on the security switches states and on the trigger logic result.

38

CHAPTER 4


4.3. Implementation in Matlab Stateflow 4.3.1. Charts definitions With the help of all the previous requirements the Stateflow definition can be started for the main charts in the crash algorithm definition. Inside the Init_crash chart the state Crash_functions_initialization is located to store the logic for the initialization parameters. The figure 4.1 shows the implementation in Matlab Stateflow.

Figure 4.1. Crash functions initialization state inside the Init_crash module.

Inside the Crash_functions chart four states are defined, each one corresponding to one set of activities grouped as crash_handler to perform the frontal, side, rear and rollover crash events. Due to that the checking for all these conditions is done with the same trigger event and the same function defined in the software specifications. side_crash to process specially the side crash events because the period for these events requires a faster response. 39

CHAPTER 4


cyclic_monitoring to monitor all the signals relative to the sensors status and the environment variables in the system. crash_recording to perform the operations relative to register and save the crash parameters during the crash events.

The figure 4.2 shows the integration of the charts. Every state is started by an independent event to satisfy the different periods in which every function runs.

Figure 4.2. Stateflow states inside the Crash_functions module

4.4. State machines implementation States and boxes. As it was explained in 3.1.2. the transitions enable state diagrams to interact with its external environment. In this way a state can be seen

40

CHAPTER 4


like the equivalence of a function called in C language where the call is done by an interrupt event or another function from a higher level. On the other side; boxes in Stateflow are only drawn enclosures that help to visualization purposes by encapsulating the contents inside them to hide complexity. Boxes do not need transition events to be executed and do not perform additional actions during their execution like states do. For this reason, the crash algorithm approach uses boxes inside the main states where no additional interrupt events are required to run the different paths in the algorithm, making the code simpler when a code generator is used.

4.4.1. Implementing the crash functions initialization This state is activated by the event init_crash_event. The event is driven by the

System_handler module at the beginning of the simulation to initialize: Algorithm parameters stored in the EEPROM Configuration parameters stored in the EEPROM Installed equipment information from the EEPROM Crash record information stored in the EEPROM Clearing of the trigger variables for the crash algorithm Clearing of the crash record variables Squibs assignation Boxes that can be filled with different function calls separate the different parameters

to

copy

data

from

the

EEPROM,

while

the

box

initialize_crash_functions performs the clearing operations and the squibs assignation. The boxes are used to encapsulate the function implementations for

41

CHAPTER 4


the generic approach. States are not required because there is only one event driving this chart. The figure 4.3 shows the Stateflow implementation.

Figure 4.3. Initialization state for the crash algorithm

4.4.2. Implementing the crash_handler This state can be divided in several parts according to the duties it handles.

4.4.2.1. Initialization For the initialisation of this state, some additional requirements have to be considered. The requirements are: 42

CHAPTER 4


Initialise local variables Prevent for non re-entrance in the function. Prepare conditions and register the system time when a threshold is exceeded.

Figure 4.4. Initialization of the crash_handler state

In the figure 4.4 it can be seen that every requirement is assigned to a box where the custom code can be placed for every different model. The verify_no_re_entrance checks for the non re-entrance of the function by checking a system variable. This function is implemented to avoid that unexpected interrupts affect the performance of the crash algorithm. After checking non re-entrance, the first condition to start a crash event is done by checking all the alerts set by the thresholds module. The macro

IS_ANY_ALERT looks for the alerts received by the thresholds module. In case there is an alert, the algorithm has to register the system time and initialise the variables to prepare for a crash occurrence. These activities are being

43

CHAPTER 4


performed inside the box alert_settings. In case there is no such condition the „else‟ is taken. When a crash occurs, the threshold generated is detected by the macro

IS_A_THRESHOLD_EXCEEDED, and in case of a first time detection, the set_conditions_for_crash is executed to monitor the status of the system at the moment and to prepare hardware and software to respond to the crash.

4.4.2.2. Crash discrimination Since every different threshold has to be treated with special logic that only applies to that condition, every condition is separated by a macro that identifies the crash type and takes the correspondent actions. Inside every box, the actions executed for driver and passengers are also separated and grouped inside another level of encapsulation due that the responses are based in different algorithm requirements. The thresholds are grouped based on their origin. Figure 4.5 shows the decision paths for the crash discrimination. The belt_algo_settings box contains the logic for a belt threshold event. The response for a rear threshold event is performed also here when the belt pretensioners activation has to be done.

44

CHAPTER 4


Figure 4.5. Crash discrimination inside the crash handler.

45

CHAPTER 4


Figure 4.6. Stage 1 discrimination for the crash algorithm.

The stage1_settings and stage2_settings boxes contain the logic for the two levels of airbag deployment. In figure 4.6 the inside stage1_settings box is shown. Stage2_settings has the same discrimination like stage1. The side_crash_settings box takes care of the side crash thresholds right, left; crash with offset right or left; and the rear crash threshold for the activation of the side airbags and rear belt pretensioners. The rollover_settings box contains the actions during rollover situations for the activation of the left and right inflatable curtains and the rear threshold.

46

CHAPTER 4


Figure 4.7. Side crash discrimination for the crash algorithm.

Figure 4.8. Rollover discrimination for the crash algorithm. 47

CHAPTER 4


4.4.2.3. Crash timers and firing control Every triggered ignition loop is attached to one independent counter which starts when the ignition is determinate to be fired and is monitored until it reaches a delay set value pre-determined in the configuration parameters.

The disposal

timing control and the CRO_timer_control boxes control the delay monitoring activities.

Figure 4.9. Timing and firing control in the crash_handler

48

CHAPTER 4


The firing_time_control box monitor and control the interface variables where the triggered values are transported to the ASICs. The ASICs_control box performs the hands checking operations with the ASICs for the firing of the ignition cycles. In this function the redundant variables are checked to verify that both original and redundant data contain the same, otherwise an error flag is set in the system and the complete function is aborted. This box is also responsible for setting the flags to define when the record information can be start once all the triggered data was deployed. The verify_autarchy condition determines when the system runs in autonomous mode and set the proper flag to indicate in case there is not enough time to finish with all the operations. The end_crash_settings condition enters when the crash is ended to perform the last operations depending on the project, for example clearing flags. The last decision path checks the condition in the flag for not re-entrancy. This flag has to remain as it was set at the beginning of the state otherwise a system error has occurred and the system has to reboot. After all the operations the state waits for the next event, inside the crash_next sub-state. The crash_handler_event awakes the state and the cycle starts again.

4.4.3. Implementing the cyclic_monitoring This state monitors the sensor signals required for the decision triggering in case of crash events and for information stored in the Crash_record function. The state runs every cyclic time determined by the system and it is awaited by the

cyclic_monitor_event. Here, the sensors were categorized inside boxes for a better localization and visualization. The status of equipment and sensors can be

49

CHAPTER 4


set from external modules and read inside their respective box where they are assigned to global variables that can be accessed by any part of the project. Custom C code placed inside the call to the C function determines some trigger logic depending on the sensors. This function varies with every different project.

Figure 4.10. The cyclic_monitoring state

50

CHAPTER 4


4.4.4. Implementing the crash recording Inside this state the operations to register the system information and the triggering information at the moment of the crash event are performed in a sequence that is coordinated by the end of the triggering of all the devices and by the status of the voltage in the system together with the access time required for writing in the EEPROM. For the case of the simulation the information is also stored inside two arrays that are saved to the workspace where they can be copied to any other application interacting with Matlab.

Figure 4.11. The crash_recording state

4.5. Simulink model with the crash algorithm 4.5.1. The Test_sequencer module In order to test the performance of the crash algorithm a test sequencer was developed. Inside this module the thresholds and crash variations settings were placed because they are set according to different test requirements with variable time delays. That means the threshold settings are the main part of the tests that

51

CHAPTER 4


the algorithm has to satisfy. Figure 4.12 shows the Test_sequencer for the crash algorithm.

Figure 4.12. Test sequencer chart for the generic crash algorithm

4.5.2. The System_handler module In the real system there is a timer controller that determines the occurrence of every event that activates the different functions in a crash module. For the 52

CHAPTER 4


simulation case the System_handler module was created. This module contains the control for the timers, which defines the events inside every chart.

Figure 4.13. System handler module

4.5.3. The generic Crash_functions module The final approach is shown in figure 4.14 with all the inputs and outputs grouped and defined inside modules. The modules can grow or reduce its size for future requirements without affecting the others. The outputs consist of the ASICs, the delays and the timer‟s displays. All these variables are being sent to the Matlab workspace where they will be used by other applications like the user interface or Excel by instance.

53

CHAPTER 4


Figure 4.14. Crash functions chart

54

CHAPTER 4


4.6. Custom code integration The algorithm communication with the external interfaces is done by custom code, which varies from project to project. Stateflow provides an option to integrate custom C code to the models. By using this option a general header is included inside the . Inside a header named “general_model.h” the general macros and definitions for particular projects can be added, so that the generic model can be enhanced without interference from the new projects. Figure 4.15 shows the included definitions for Stateflow used for one specific project named VOLVO_P15.

Figure 4.15. Custom code integration in Stateflow

A segment from the general_model.h is shown in figure 4.15. The #define in the Stateflow options labelled as VOLVO_P15 is used here to place the custom code for this specific project inside the general header file. The header file “Volvo_stateflow_variables.h” contains all the headers and definitions to interact with the external modules. The decision flow macros are project specific definitions for the general macros used in the state crash_handler.

55

CHAPTER 4


// ---- definitions for project Volvo P15 -----------------

#ifdef VOLVO_P15 #include "Volvo_stateflow_variables.h" // decision flow macros #define IS_FIO_CRASH_SYS

IS_FIO_FRONT_CRASH_SYS

#define IS_A_THRESHOLD_EXCEEDED IS_ANY_THRESHOLD_EXCEEDED #define IS_FIRST_TIME_CRASH

IS_FIRST_RUN_CRASH

Figure 4.16. Custom code integration in the general header

56

CHAPTER 5

RESULTS AND CONCLUSIONS


5.1. Validation tests The validation tests for the generic crash algorithm model are the software test specification procedures applicable for projects development in the company. The model-based algorithm has to satisfy the same triggering and record information requirements like the C code algorithm has. In order to probe the same performance like the hand made code, a set of tests has to be performed for every threshold condition with its corresponding ignition outputs involved.

5.2. Test procedure development An example of a test specification for the triggering of the driver shoulder belt pretensioner is shown in table 5.1. The algorithm has to respond to the trigger threshold originated for the driver belt pretensioner based on the upfront sensors status and the security hardware device, the trigger switch. The test procedure is defined from this table. Belt pretensioner driver Open No Don‟t care Not faulty Closed Yes Shoulder Belt Faulty / not configured Yes Pretensioner Open No Driver Closed Faulty Closed Yes (SHBD) Faulty / not configured Yes Not closed Faulty Don‟t care No Threshold

Trigger switch status

Upfront sensors state

Belt buckle driver status

Table 5.1. Triggering specifications for the driver belt pretensioner 57

CHAPTER 5


5.2.1. Excel interface The number of tests to verify the correct algorithm triggering is around 165 for this reason, and also to provide a very well known tool for the future crash algorithm template users, a Matlab.m file and a user interface was developed to automate the testing process. The tests can be defined in an Excel sheet where they are being read by the Matlab‟s user interface and sent to the Simulink model that runs the set of simulations. The results are being sent back to Excel to compare and keep a record of them. The table specification is transported to an Excel file where it is arranged to conform the Simulink input parameters for the test simulation. A translation table was developed to define the values that Simulink can accept as valid inputs. Table 5.2 shows the translation for the meaning of the specification tables to the Excel tables. Devices´s states in specification tables

Numeric value in Excel tables

Open Closed Faulty Device/sensor not equipped Device/sensor equipped Output not triggered: No Output triggered: Yes

0 1 2 0 1 0 1

Table 5.2. Test specs key words conversion to numeric values in the Excel tables.

5.2.2. Initial conditions Some initial conditions to ensure that there are not other variables that may cause incorrect results in the triggering are added to the table. These conditions depend

58

CHAPTER 5


on the type of trigger and sensors involved in the test; the following table is a list for every case.

Device or sensor

Initial condition

Belt buckle

It has to be equipped to ensure the status open, closed and faulty will be considered correctly.

LAP belt pretensioner

It has to be equipped to be able to be triggered.

Adaptive load limiter

It has to be equipped to be able to be triggered.

Adaptive steering column It has to be equipped to be able to be triggered. Upfront sensor failure

Only one failure at a time has to be ensured.

Table 5.3 Initial conditions for the crash tests

5.2.3. Input tables A set of test input tables as a result of the translation from the original specification and the initial conditions for every threshold was developed. The table 5.4 shows the Shoulder belt pretensioner input table.

Initial conditions Belt Buckles/ BELT_BUCKLE _EQ_DR Sensor Faults/ Thresholds/ UFS_R_FAULT BELT_THR threshold

Values

1 0

Input1

Input2

Input3

Output 1

Trigger Belt Buckles/ Test Switches/ Sensor Faults/ BELT_BUCKLE Number TRIGGER_SW UFS_L_FAULT _DR SHBP_D 1 2 3 4 5 6 7

0 0 0 0 1 1 1

0 1 0 0 1 1 1

0 0 1 2 0 1 2

Table 5.4. Excel input table for the shoulder belt pretensioner tests.

59

0 0 1 1 0 1 1

CHAPTER 5


The complete set of tables is shown in appendix A. With these tables as inputs inside and Excel file the Matlab user interface was executed to verify that all the conditions to validate the algorithm were satisfied. Figure 5.1 shows the user interface.

Figure 5.1. Graphical user interface for the validation tests

5.2.4. Simulink output tables The simulation result for every test is written also in the same Excel sheet where the input table is located. For the record requirements the results are written in a separate sheet that the program appends to the Excel document because of its longer extension. The output table for the shoulder belt pretensioner set of test is shown in table 5.5. 60

CHAPTER 5


Test Name: Trigger logic for driver shoulder belt pretensioner frontal crash Test Initial Input1 Input2 Input3 Output 1 conditions Values Number Belt Buckles/ Trigger Belt Buckles/ BELT_BUCKLE Switches/ Sensor Faults/ BELT_BUCKLE _EQ_DR TRIGGER_SW UFS_L_FAULT _DR 1 SHBP_D Sensor Faults/ 0 1 0 0 0 0 Thresholds/ UFS_R_FAULT 2 0 1 0 0 BELT_THR 3 0 0 1 1 4 0 0 2 1 5 1 1 0 0 6 1 1 1 1 7 1 1 2 1 Threshold

Simulink Output

SHBP_D 0 0 1 1 0 1 1

Table 5.5. Results table for the shoulder belt pretensioner tests At the end of the input table Simulink adds another column where the simulation results are placed. For the validation all the conditions were satisfied test by test. The recorded information from the generated Excel sheet is shown in table 5.6. For this case, all the outputs were verified one by one comparing the conditions in every device or sensor to be registered at the time of the simulation with the stored information in the excel sheets.

61

CHAPTER 5


Test1 Test2 Test3 Test4 Test5 Test6 Test7 FIRST PART VARIABLES FIRST PART FIRST PART FIRST PART FIRST PART FIRST PART FIRST PART FIRST PART systime_ul 1 1 1 1 1 1 1 trigger_logic_ul 13239632 13239632 9307557 13239637 13239632 9307557 13239637 occupant_information_uw 0 0 1 2 0 1 2 ocs_messages_present_ocs.ocsstatus_ub 0 0 0 0 0 0 0 ocs_messages_present_ocs.occupantweightstatus_ub 1 1 1 1 1 1 1 ocs_messages_present_ocs.seatoccupationstatus_ub 1 1 1 1 1 1 1 ocs_messages_present_ocs.ocssystemsensorfault_ub 0 0 0 0 0 0 0 prev_one_ocs_message_ul.ocsstatus_ub 0 0 0 0 0 0 0 prev_one_ocs_message_ul.occupantweightstatus_ub 0 0 0 0 0 0 0 prev_one_ocs_message_ul.seatoccupationstatus_ub 0 0 0 0 0 0 0 prev_one_ocs_message_ul.ocssystemsensorfault_ub 0 0 0 0 0 0 0 prev_two_ocs_message_ul.ocsstatus_ub 0 0 0 0 0 0 0 prev_two_ocs_message_ul.occupantweightstatus_ub 0 0 0 0 0 0 0 prev_two_ocs_message_ul.seatoccupationstatus_ub 0 0 0 0 0 0 0 prev_two_ocs_message_ul.ocssystemsensorfault_ub 0 0 0 0 0 0 0 ocs_pab_pacos_state_uw 41601 41601 41601 41601 41601 41601 41601 pab_status_ocs_ul 0 0 0 0 0 0 0 ena_thr_door_state_ub 0 0 0 0 0 0 0 ufs_state_ub 0 3 0 0 3 3 3 sis_state_ub 0 0 0 0 0 0 0 fault_amount_ub 0 0 0 0 0 0 0 oldest_fault_uw 0 0 0 0 0 0 0 fault_active_uw[0] 0 0 0 0 0 0 0 fault_active_uw[1] 0 0 0 0 0 0 0 fault_active_uw[2] 0 0 0 0 0 0 0 fault_active_uw[3] 0 0 0 0 0 0 0 fault_active_uw[4] 0 0 0 0 0 0 0 u_batt_ub 188 188 188 188 188 188 188 u_vca_ub 179 179 179 179 179 179 179 SECOND PART SECOND VARIABLES PART SECOND PART SECOND PART SECOND PART SECOND PART SECOND PART SECOND PART system_information_uw 1 1 65 65 1 65 65 additional_info_uw 0 0 0 0 32 32 32 trigger_thresholds_ul 2 2 2 2 2 2 2 info_algo_ul 0 0 0 0 0 0 0 rollover_thresholds_ub 0 0 0 0 0 0 0 info_rosal_uw 0 0 0 0 0 0 0 t_thr_belt_ub 20 20 20 20 20 20 20 t_thr_AB1_driver_unbelted_ub 0 0 0 0 0 0 0 t_thr_AB1_passenger_unbelted_ub 0 0 0 0 0 0 0 t_thr_AB1_driver_belted_ub 0 0 0 0 0 0 0 t_thr_AB1_passenger_belted_ub 0 0 0 0 0 0 0 t_thr_AB2_driver_unbelted_ub 0 0 0 0 0 0 0 t_thr_AB2_passenger_unbelted_ub 0 0 0 0 0 0 0 t_thr_AB2_driver_belted_ub 0 0 0 0 0 0 0 t_thr_AB2_passenger_belted_ub 0 0 0 0 0 0 0 cpc_2_alert_ub 0 0 0 0 0 0 0 delay_trigg_ub 0 0 0 0 20 0 0 t_adll_thr_driver_ub 255 255 255 255 255 255 255 t_adll_thr_passenger_ub255 255 255 255 255 255 255 fired_squibs_ul 0 0 12 12 0 12 12 last_byte_ub 170 170 170 170 170 170 170

Table 5.6. Recorded information from the crash algorithm simulation.

62

CHAPTER 5


5.3. The Matlab graphical user interface The graphical user interface allows the code developer to debug and verify the performance of single tests under different input and environmental conditions before testing a complete set of tests with the Excel user interface. Figure 5.7 shows the picture of the graphical user interface. There the different initial conditions are grouped depending on their functionality.

Figure 5.2. Generic crash graphical user interface.

Input sensors status in the user interface This group contains the possible combination states for the input sensors, such as the belt buckle sensors, the lap belt pretensioner sensors, PACOS, OWS, seat track, ADLL, airbags, pillars and doors status. 63

Sensors are sub grouped

CHAPTER 5


according to their function inside the car. The sensor states were defined by the software specifications and their corresponding translated value can be seen in table 5.2. Every sensor by instance can be equipped or not equipped and if it is equipped it also can be open, closed, or faulty. Figure 5.3 shows a closer view from the belt buckles sensors and the selection of the “Belt Buckle Driver” sensor as “Equipped” and “Closed”.

Figure 5.3. Belt buckles and LAP belt pretensioners input sensors.

Safety sensors status in the user interface The sensors involved in the safety crash detection also known as “Trigger Switches” can be independently set to their two possible values: closed and open to verify the correct algorithm performance.

Figure 5.4. The safety sensors with their possible status.

64

CHAPTER 5


The upfront sensors status in the user interface The status in the upfront left and right sensors is also part of the specification tables to define the activation of the squibs, so the user interface provides the means to simulate the two possible states for these sensors, “Not Faulty” and “Faulty” status.

Figure 5.5. Upfront sensors possible status.

The environment status in the user interface This status is represented by the voltage in the battery and the Autarchy capacitor when there is not battery, and both of them can be programmed independently for the tests.

Figure 5.6. Voltages in Battery and Autarchy.

The threshold settings in the user interface The user interface provides the thresholds that define a crash occurrence inside the “Thresholds Settings” panel. The button “Clear all Thresholds” sets all the thresholds to “not occurrence” to ensure that previous values stored in the Matlab Simulink model are not present during a new test. Figure 5.7 shows the thresholds settings in the user interface.

65

CHAPTER 5


Figure 5.7. Setting thresholds in the Threshold panel.

The Ignition loops results panel in the user interface Once the test is performed by the Matlab Simulink model from the user interface, the results are shown in the “Ignition loops” panel. Here the outputs to the ASICs inside the model are decoded and presented by their identifiable name. Part of the ignition loops is shown in figure 5.8. The “System Time” represents the total time for the algorithm simulation, and the timer‟s windows show the delay values that the squibs require before being triggered.

66

CHAPTER 5


5.8. Ignition loops triggered during a crash simulation.

5.4. Conclusions Throughout the development of this document an enormous effort was done to satisfy the requirements and parameters involved in a generic crash algorithm used in the automotive industry to present a design as clear and simple as possible, so clear and easy to understand that this thesis seems to be a very easy going work; however it was the result of deep investigations and analysis applying model-based design techniques that are still not used in crash algorithms due to that they have to be the fastest algorithms running in the car during severe and extreme conditions where the execution of all the functions have to achieved in periods of micro seconds with a size in RAM memory limited by the cost. So, because of the good results obtained, this project has established the basis for the future development of crash algorithm in a visual paradigm for the software department in Continental Temic. This work in the first place has shown that by using a model-based design approach it is possible to develop generic crash algorithms applicable to different customer requirements. 67

CHAPTER 5


The algorithm has satisfied the software specification's triggering requirements from the biggest project under study, which was the most complex and extended from three under investigation. Hand code implementation can be added to the model to enhance the capabilities of the algorithm. Time simulation can be adjusted for different conditions to test different hardware performances. A set of model-based design guidelines has been established and delivered to Conti Temic for future development projects The generic algorithm itself is a template to develop new crash algorithms for different customer requirements

68

ABBREVIATIONS

ABBREVIATIONS

ASIC Application-Specific Integrated Circuit CAN Controller Area Network ECU Electronic Control Unit EEPROM Electrically Erasable Programmable Read-Only Memory IC Inflatable Curtain ms milli seconds NVRAM Non-Volatile Random Access Memory OWS Occupant Classification System RCM Restraint Control Module ROS Rollover Sensor SIS Side Impact Sensor SRS Safety Restrain System STS Seat Track Sensor UPS Upfront Sensor

69

BIBLIOGRAPHY

BIBLIOGRAPHY

1. “Airbag”, http://www.thebestlinks.com/Airbag.html 2. “BOSCH Automotive Handbook”, Bosch Handbooks (REP), 5° Edition, By Bosch GmbH. 3. “How Air Bags Work”, http://auto.howstuffworks.com/airbag1.htm 4. “Airbag Triggering in a Numerical Vehicle Fleet”, G.Y. Martin; Master thesis Mechanical Engineering TU/e – MT04.02, Eindhoven University of Technology, Faculty of Mechanical Engineering, The Netherlands, Jan 2004. 5. “The Pretensioner”, http://auto.howstuffworks.com/seatbelt4.htm 6. “Fundamental Relation Between Fire Time And Impact Severity Estimation”, Rabbiolo, G., Domenico, L. Di, Nusholtz, G.S., DaimlerChrysler Corp, U.S.A., paper number 481 ESV 2003. 7. “Development of Occupant Classification System for Advanced Airbag Requirements”, Shigeyuki Nozumi, New Technologies, Mitsubishi Motors Technical Review 2004 No.16. 8. “Federal Motor Vehicle Safety Standards and Regulations”, U.S. Department Of Transportation, National Highway Traffic Safety Administration, Standard No. 208, http://www.nhtsa.dot.gov /cars/rules/import/FMVSS/index.html 9. “Software Development Principles Applied to Graphical Model

Development”, Paul A. Barnard, American Institute of Aeronautics and Astronautics, The MathWorks News letter, http://www.mathworks.com /company/newsletters/index.html

70

BIBLIOGRAPHY

10. “Using

Model Coverage Analysis to Improve the Controls Development Process”, William Aldrich, The MathWorks News letter, http://www.mathworks.com/company/newsletters/index.html.

11. “V-Model, Lifecycle Process Model”, Brief description, IABG Information Technology, Version: February 1993, Release: 1995. 12. Balzert, H.: Lehrbuch der Software-Technik. Spektrum Akademischer Verlag, Vol. 1, 2. ed. 2000.

71

APPENDIX A

APPENDIX A

Input test tables developed in Excel for the Matlab Simulink simulation.

A.1. Key words used in the test specifications converted to numeric values. Words in specification tables

Numeric value in the Excel tables

Open Closed Faulty Don‟t care Device/sensor not equipped Device/sensor equipped Output not triggered: No Output triggered: Yes

0 1 2 0 or X 0 1 0 1

A.1. Test specs key words conversion to numeric values in the Excel tables.

A.2. Frontal crash trigger logic

A.2.1. Trigger logic for driver shoulder belt pretensioner: frontal crash.

A-1

APPENDIX A Initial conditions Belt Buckles/BELT_B UCKLE_EQ_PA Sensor Thresholds/ Faults/UFS_L_F BELT_THR threshold

Values

Test Number

1 1 2 3 4 5 6 7

0

Input1

Input2

Input3

Output 1

Trigger Sensor Belt Switches/TRI Faults/UFS_ Buckles/BELT_ SHBP_P GGER_SW R_FAULT BUCKLE_PA 0 0 0 0 0 0 1 1 0 0 2 1 1 1 0 0 1 1 1 1 1 1 2 1 0 1 0 0

A2.2. Trigger logic for passenger shoulder belt pretensioner: frontal crash.

threshold

Initial conditions

Values

Belt Buckles/BELT_BUCKL E_EQ_DR LAP Belt Pretensioners/LAP_BE Thresholds/ LT_EQ_DR BELT_THR Sensor Faults/UFS_R_FAULT ADLL/ADLL_EQ_DR

Test Number

Input1

Input2

Input3

Trigger Sensor Belt Switches/TRIG Faults/UFS_ Buckles/BELT GER_SW L_FAULT _BUCKLE_DR

1

Output 1

LAP_D

1

1

0

1

0

0

0 0

2 3 4 5 6 7

0 0 0 1 1 1

0 0 0 1 1 1

0 1 2 0 1 2

0 1 1 0 1 1

A2.3. Trigger logic for driver lap belt pretensioner: frontal crash.

threshold

Initial conditions Values

Belt Buckles/BELT_BU CKLE_EQ_PA LAP Belt Pretensioners/LA P_BELT_EQ_PA Thresholds/ Sensor BELT_THR Faults/UFS_L_FA ULT ADLL/ADLL_EQ_ PA

Test Number

Input1

Input2

Input3

Trigger Sensor Belt Switches/TRIG Faults/UFS_ Buckles/BELT_ GER_SW R_FAULT BUCKLE_PA

1

Output 1 LAP_P

1

1

0

1

0

0

0

2 3 4 5 6 7

0 0 0 1 1 1

0 0 0 1 1 1

0 1 2 0 1 2

0 1 1 0 1 1

0

A.2.4. Trigger logic for passenger lap belt pretensioner: frontal crash.

A-2

APPENDIX A

threshold

Initial conditions

Belt Buckles/BELT_BUC Thresholds/ KLE_EQ_DR AB1_DR_UN Adaptive Steer BELTED Col/ASC_EQ

Values

Test Number

Input2

Trigger Belt Switches/TRIG Buckles/BELT_B GER_SW_DR UCKLE_DR 1 0 1 1 1 2 0 X

1 1 2 3 4

1

Input1

Output 1

Output 2

AB1_D

ASC

1 0 1 0

0 0 0 0

A.2.5. Trigger logic for driver airbag stage 1 unbelted & adaptive steering column.

Initial Values conditions Belt Buckles/BELT_ BUCKLE_EQ_D Thresholds/ R 1 AB1_DR_B Adaptive Steer ELTED Col/ASC_EQ 1 threshold

Test Number

Input1

Input2

Trigger Belt Switches/TRIG Buckles/BELT_ GER_SW_DR BUCKLE_DR 1 0 1 1 1 2 0 X

1 2 3 4

Output 1

Output 2

AB1_D

ASC

0 1 0 0

0 1 0 0

A.2.6. Trigger logic for driver airbag stage 1 belted & adaptive steering column.

threshold

Initial conditions

Values

Sensor Faults/UFS_R _FAULT

0

Test Number

Input1

Input2

Input3

Input4

Output 1

Belt Trigger Sensor Belt Buckles/REAR_ Switches/TRIG Faults/UFS_L_ Buckles/REAR BUCKLE_EQ GER_SW FAULT _L_BUCKLE 1 2 3 4 5 6 7

Thresholds/ BELT_THR

1 1 1 1 1 1 1

1 1 1 0 0 0 0

X X X 0 0 0 1

RBP_L

0 1 2 0 1 2 X

0 1 1 0 1 1 0

A.2.7. Trigger logic for rear left belt pretensioners: front belt pretensioner.

Initial conditions Sensor Thresholds/AB1 Faults/UFS_L _DR_BELTED _FAULT threshold

Test Values Number 0 1 2 3

Input1 Input2 Input3 Input4 Belt Trigger Sensor Belt Buckles/REAR_ Switches/TRIGGER Faults/UFS_R Buckles/REAR BUCKLE_EQ _SW_DR _FAULT _L_BUCKLE 0 1 0 0 0 0 0 X 0 0 1 x

Output 1

A.2.8. Trigger logic for rear left belt pretensioners: AB1 driver belted. A-3

RBP_L 1 1 0

APPENDIX A

threshold

Initial conditions

Values

Test Number

Input1

Input2

Input3

Input4

Output 1

Belt Trigger Sensor Belt Buckles/REAR_ Switches/TRIG Faults/UFS_ Buckles/REAR BUCKLE_EQ GER_SW R_FAULT _R_BUCKLE 1 1 X 0 1 1 X 1 1 1 X 2 1 0 0 0 1 0 0 1 1 0 0 2 1 0 1 X

Thresholds/B ELT_THR 1 2 3 4 5 6 7

RBP_R 0 1 1 0 1 1 0

A.2.9. Trigger logic for rear right belt pretensioners: front belt pretensioner.

Initial conditions Sensor Thresholds/AB1 Faults/UFS_R_ _DR_BELTED FAULT threshold

Test Values Number

Input1

Input2

Input3

Input4

Output 1

Belt Trigger Sensor Belt Buckles/REAR_ Switches/TRIGGER Faults/UFS Buckles/REAR BUCKLE_EQ _SW_DR _L_FAULT _R_BUCKLE 0 1 0 0 0 0 0 X 0 0 1 X

0 1 2 3

RBP_R 1 1 0

A.2.10. Trigger logic for rear right belt pretensioners: AB1 driver Belted

Initial conditions Belt Thresholds/AB2_ Buckles/BELT_ DR_UNBELTED BUCKLE_EQ_D R threshold

Values

Test Number

Input1

Input2

Trigger Belt Switches/TRIG Buckles/BELT_B GER_SW_DR UCKLE_DR

1 1 2 3 4

0 1 1 1

Output 1 AB2_D

X 0 1 2

0 1 0 1

Input2

Output 1

A.2.11. Trigger logic for AB2 driver unbelted.

Initial Values conditions Belt Thresholds/AB2_ Buckles/BELT_ 1 DR_BELTED BUCKLE_EQ_D R threshold

Test Number

Input1

Trigger Belt Switches/TRIG Buckles/BELT_B GER_SW_DR UCKLE_DR 1 2 3 4

0 1 1 1

A.2.12. Trigger logic for AB2 driver belted. A-4

X 0 1 2

AB2_D 0 0 1 0

APPENDIX A Test Initial threshold conditions Values Number Input1 Input2 Input3 Belt Trigger PACOS/SW Thresholds/ Buckles/BELT_ PACOS/CCF 1 Switches/TRIG CE_EQ_PAC AB1_PA_U BUCKLE_EQ_P _EQ_PACOS GER_SW_PA OS NBELTED A 1 0 X X 1 0 0 2 3 1 0 0 4 1 0 0 5 1 1 1 1 1 6 1 7 1 1 1

Output 1 Input7 Belt PACOS/DE PACOS/PAC OWS/SWC Buckles/B TECTED_P OS_ENABLE AB1_P E_EQ_OCS ELT_BUC ACOS D KLE_PA X X X X 0 0 0 0 0 1 0 0 1 1 0 0 0 1 2 0 1 1 0 0 1 1 1 0 1 0 1 1 0 2 1 Input4

Input5

Input6

A.2.13. Trigger logic for AB1 passenger unbelted. The green cells represent the required combinations to enable/disable the passenger airbag (PAB) state.

Initial Test Output 1 Values Input1 Input2 Input3 Input4 Input5 Input6 Input7 Number conditions Belt Thresholds Trigger PACOS/SW PACOS/C PACOS/DE PACOS/P OWS/SW Belt Buckles/BELT_ /AB1_PA_ 1 Switches/TRIG CE_EQ_PAC CF_EQ_ TECTED_ ACOS_EN CE_EQ_ Buckles/BELT_ AB1_P BUCKLE_EQ_P BELTED GER_SW_PA OS PACOS PACOS ABLED OCS BUCKLE_PA A 1 0 X X X X X X 0 1 0 0 0 0 0 2 1 0 3 1 0 0 0 0 1 1 0 4 1 0 0 0 0 1 2 0 5 1 1 1 1 1 0 0 0 1 1 1 1 6 1 0 1 1 7 1 1 1 1 1 0 2 0 threshold

A.2.14. Trigger logic for AB1 passenger belted

threshold Initial conditions Values Thresholds Belt /AB2_PA_ Buckles/BELT_BU BELTED CKLE_EQ_PA

Test Number

1 1 2 3 4 5 6 7

Input1

Input2

Input3

Input4

Input5

Input6

Output 1

Input7

Trigger PACOS/CCF PACOS/DET PACOS/PAC Belt PACOS/SWCE OWS/SWC Switches/TRIG _EQ_PACO ECTED_PAC OS_ENABLE Buckles/BELT _EQ_PACOS E_EQ_OCS GER_SW_PA S OS D _BUCKLE_PA 0 X X X X X X 1 0 0 0 0 0 1 1 0 0 0 0 1 1 1 0 0 0 0 1 2 1 1 1 1 1 0 0 1 1 1 1 1 0 1 1 1 1 1 1 0 2

AB2_P 0 0 0 0 0 1 0

A2.15. Trigger logic for AB2 passenger belted.

Initial conditions threshold Belt Thresholds/ Buckles/BELT AB2_PA_U _BUCKLE_EQ NBELTED _PA

Test Values Number

Input1

Input2

Input3

Input4

Input5

Input6

Input7

Output 1

Belt Trigger PACOS/CCF PACOS/DET PACOS/PAC PACOS/SWCE OWS/SWC Buckles/B Switches/TRIG _EQ_PACO ECTED_PAC OS_ENABLE AB2_P _EQ_PACOS E_EQ_OCS ELT_BUC GER_SW_PA S OS D KLE_PA

1 1 2 3 4 5 6 7

0 1 1 1 1 1 1

X 0 0 0 1 1 1

X 0 0 0 1 1 1

X 0 0 0 1 1 1

X 0 0 0 1 1 1

A2.16 Trigger logic for AB2 passenger unbelted.

A-5

X 1 1 1 0 0 0

X 0 1 2 0 1 2

0 0 0 0 1 0 1

APPENDIX A

A.3. Offset crash trigger logic Initial Values conditions Belt Thresholds/OF Buckles/BELT_ 1 FSET_LEFT BUCKLE_EQ_P A Belt Buckles/BELT_ 1 BUCKLE_EQ_D R threshold

Test Number

Input1

Input2

Input3

Output 1

Output 2

Steer Belt Belt Position/STEER Buckles/BELT_ Buckles/BELT_ DMIC_L SB_L _POS_LEFT BUCKLE_DR BUCKLE_PA 1 2 3 4 5 6

1 1 1 0 0 0

0 1 2 x x x

x x x 0 1 2

1 0 1 1 0 1

1 0 1 1 0 1

A.3.1. Trigger logic for door mounted IC and side bag frontal of offset crash left side.

Initial conditions Belt Thresholds/OFF Buckles/BELT_ SET_RIGHT BUCKLE_EQ_ PA Belt Buckles/BELT_ BUCKLE_EQ_ threshold

Values

Test Number

1

1

Input1

Input2

Input3

Output 1

Steer Belt Belt Position/STEER Buckles/BELT_ Buckles/BELT_ DMIC_R _POS_LEFT BUCKLE_DR BUCKLE_PA 1 2 3 4 5 6

1 1 1 0 0 0

X x X 0 1 2

0 1 2 X X X

Output 2 SB_R

1 0 1 1 0 1

1 0 1 1 0 1

A.3.2. Trigger logic for door mounted IC and side bag frontal of offset crash right side

A.4. Side crash trigger logic threshold

Initial conditions

Values

Test Number

Thresholds/ SIDE_RIGHT

Output 1

Output 2

Output 3

Output 4

SB_L

DMIC_L

SB_R

DMIC_R

0

0

1

1

1

A.4.1. Trigger logic for AB2 passenger unbelted: side crash right.

A-6

APPENDIX A

Initial conditions

threshold

Values

Test Number

Output 1

Output 2

Output 3

Output 4

SB_L

DMIC_L

SB_R

DMIC_R

1

1

0

0

Thresholds/ SIDE_LEFT 1

A.4.2. Trigger logic for AB2 passenger unbelted: side crash left.

threshold

Test Number

Initial conditions Values

Belt Buckles/BELT_B Thresholds/S UCKLE_EQ_DR IDE_RIGHT Belt Buckles/BELT_B UCKLE_EQ_PA

Input1

Belt Belt Buckles/BELT_ Buckles/BELT BUCKLE_DR _BUCKLE_PA 0 0 1 0 2 1 0 2 1 1 2 2

1 1 2 3 4 5 6

1

Input2

Output 1 Output 2 SHBP_D

SHBP_P

0 1 1 0 1 1

0 0 1 1 1 1

A.4.3. Trigger logic for side crash belt pretensioners.

threshold

Initial conditions Belt Buckles/BELT_BUCKLE_ EQ_DR

Belt Buckles/BELT_BUCKLE_ EQ_PA Thresholds/ LAP Belt REAR Pretensioners/LAP_BELT_ EQ_DR LAP Belt Pretensioners/LAP_BELT_ EQ_PA ADLL/ADLL_EQ_DR ADLL/ADLL_EQ_PA

Values

Test Number

Input1

Input2

Output 1 Output 2

Belt Belt Buckles/BELT_ Buckles/BELT_ LAP_D BUCKLE_DR BUCKLE_PA

1

LAP_P

1

1

0

0

0

0

1

2

1

0

1

0

1 0 0

3 4

0 1

1 1

0 1

1 1

A.4.4. Trigger logic for side crash lap belt pretensioners.

A-7

APPENDIX A

A.5. Rear crash trigger logic Test Initial conditions Values Number

threshold

Input1

1

Belt Buckles/BELT_BU CKLE_EQ_PA

1

1

0

Thresholds/S LAP Belt IDE_RIGHT Pretensioners/LAP _BELT_EQ_DR

1

2

1 0

LAP Belt Pretensioners/LAP _BELT_EQ_PA ADLL/ADLL_EQ_ DR ADLL/ADLL_EQ_ PA

0

Input2

Belt Belt Buckles/BELT_ Buckles/BELT_ BUCKLE_DR BUCKLE_PA

Belt Buckles/BELT_BU CKLE_EQ_DR

Output 1 Output 2 LAP_D

LAP_P

0

0

0

1

0

1

0

3

2

1

1

1

4 5 6

0 1 2

2 1 2

0 1 1

1 1 1

A.5.1. Trigger logic for rear crash lap belt pretensioner.

threshold

Initial conditions

Belt Thresholds/ Buckles/BELT_B REAR UCKLE_EQ_PA Belt Buckles/BELT_B UCKLE_EQ_DR

Test Values Number

Input2

Output 1

Output 2

Belt Belt Buckles/BELT_ Buckles/BELT_ SHBP_D SHBP_P BUCKLE_DR BUCKLE_PA

1

1

Input1

1 2 3 4

0 1 0 1

0 0 1 1

A.5.2. Trigger logic for rear crash belt pretensioner

A-8

0 1 0 1

0 0 1 1

APPENDIX A

A.6. Rollover trigger logic Test Values Number

Initial conditions threshold Belt Buckles/BELT_BUCKLE_ Thresholds/R EQ_DR OLLOVER Belt Buckles/BELT_BUCKLE_ EQ_PA

1 1 2 3 4

1

Input1 Input2 Output 1 Output 2 Belt Belt Buckles/BELT_ Buckles/BELT_ SHBP_D SHBP_P BUCKLE_DR BUCKLE_PA 0 0 0 0 1 0 1 0 0 1 0 1 1 1 1 1

A.6.1. Trigger logic for rollover belt pretensioner.

threshold

Initial conditions

Values

Belt Buckles/BELT_B UCKLE_EQ_DR

1

Belt Buckles/BELT_B UCKLE_EQ_PA LAP Belt Thresholds/R Pretensioners/L OLLOVER AP_BELT_EQ_ DR LAP Belt Pretensioners/L AP_BELT_EQ_ PA ADLL/ADLL_EQ _DR ADLL/ADLL_EQ _PA

Test Number

Input1

Input2

Output 1 Output 2

Belt Belt Buckles/BELT_B Buckles/BELT_ LAP_D UCKLE_DR BUCKLE_PA

LAP_P

1

1

0

0

0

0

1

2

1

0

1

0

1

3

0

1

0

1

0

4

1

1

1

1

0

A.6.2. Trigger logic for rollover lap belt pretensioner.

Initial Test Values Input1 Input2 Input3 Output 1 conditions Number Belt Belt Belt Belt Buckles/BELT_ Buckles/REAR_ Buckles/REAR_ Buckles/REAR_ RBP_L BUCKLE_EQ_ BUCKLE_EQ L_BUCKLE R_BUCKLE Thresholds/R DR 1 OLLOVER Belt Buckles/BELT_ 1 1 0 0 0 BUCKLE_EQ_ 2 1 1 0 1 PA 1 3 1 0 1 0 4 1 1 1 1 5 0 X X 1 threshold

A.6.3. Trigger logic for rollover rear belt pretensioners. A-9

Output 2

RBP_R

0 0 1 1 1