MODEL MANUAL

FORTE
Framework for Occupant Restraint Testing and Evaluation

This material contains trade secrets or otherwise confidential information owned by Siemens Industry
Software Inc. or its affiliates (collectively, ''SISW''), or its licensors. Access to and use of this information is
strictly limited as set forth in the Customer's applicable agreements with SISW.

Unpublished work Copyright 2021 Siemens

Version 4.1
December 2021
CONTENTS

1 Introduction and objectives.................................................................................................................... 3

2 Generic model description ..................................................................................................................... 4
2.1 Vehicle model................................................................................................................................. 7
2.1.1 Overall description.................................................................................................................. 7
2.1.2 Vehicle interior ....................................................................................................................... 9
2.1.3 Seat .......................................................................................................................................11
2.1.4 Pedal box ...............................................................................................................................14
2.1.5 Steering column.....................................................................................................................15
2.1.6 Steering wheel .......................................................................................................................18
2.2 Restraint system model .................................................................................................................20
2.2.1 Airbag ....................................................................................................................................20
2.2.2 Seat belt ................................................................................................................................22
2.3 Occupant model ............................................................................................................................31
2.4 Loading representation .................................................................................................................31
3 Input parameters ..................................................................................................................................33
3.1 Load case ......................................................................................................................................33
3.2 Restraint system ............................................................................................................................33
3.3 Human response control ...............................................................................................................34
4 Output description ................................................................................................................................37
4.1 Pre-crash occupant outputs ...........................................................................................................37
4.2 In-crash occupant outputs .............................................................................................................37
4.3 Belt outputs...................................................................................................................................38
5 Model use .............................................................................................................................................39
5.1 File system ....................................................................................................................................39
5.2 Occupant positioning & belt fitting ................................................................................................39
5.3 Running load case simulations .......................................................................................................41
6 Restraint system robustness .................................................................................................................43
6.1 Restraint system configuration ......................................................................................................43
6.2 Result overview .............................................................................................................................43
7 List of publications related to FORTE .....................................................................................................44
8 Appendix – Results of the performance check .......................................................................................45
8.1 FMVSS208 Rigid Wall 35mph belted load cases .............................................................................45
8.2 FMVSS208 Rigid Wall 25mph unbelted load cases .........................................................................48
8.3 USNCAP Rigid Wall 35mph belted load cases .................................................................................51
8.4 EuroNCAP Offset Deformable Barrier 64kph belted load case ........................................................53
8.5 EuroNCAP Rigid Wall 50kph belted load case .................................................................................55

P age |2
1 INTRODUCTION AND OBJECTIVES
Integrated Safety is a relatively new domain in automotive safety, generally considered as an integrator of
systems working before and during a collision. Although Integrated Safety has turned into a commonly used
term in the industry over the past years, it is not yet fully adopted in the actual design processes of production
level implementations. Safety systems are still designed to meet passive and active safety requirements and
tested separately.

The FORTE application models described in this manual enable the user to analyze the safety system functions
in an integrated manner. As presented in Figure 1, the system variables (e.g. motorized seat belt parameters,
airbag deployment …) can be set as user parameters in the model and the effect of their functioning can be
analyzed during all phases of the investigated event. Figure 1 shows the system parameters and loading
conditions as user input, affecting both vehicle and occupant motion, which on their turn can be evaluated via
pre-defined model output (in both pre- and in-crash phases).

The simulation package consists of:

• Simulation model for a driver – a model that enables to run a complete pre- and in-crash simulation
analysis with user-definable occupant/loading/system parameters
• Simulation model for a passenger – similar model as for a driver, yet suited for front seat passenger
simulations

The objective of the application model is to:

• Provide engineers a quick start for the Madymo Active Human Model(AHM) in ready-made
applications
• Demonstrate engineering best-practices for Madymo modelling techniques
• Provide engineers a fully functioning simulation platform that enables measuring the effects of pre-
crash deployed safety functions on occupant injury risk

Figure 1. Schematic description of application model inputs and outputs for pre- and in-crash phases

P age |3
2 GENERIC MODEL DESCRIPTION
The delivery package contains a directory where all the include files are located that are referenced in the four
main model files; two for settling and two for load case simulations, each for driver or passenger.

Figure 2. Delivery package

Two Madymo models are available, one for driver side and one for passenger side. Three different traffic
incident scenarios are readily implemented in these models:
• Constant speed driving followed by vehicle crash
(impact against a rigid wall at 56 km/h)
• Autonomous emergency braking (AEB) followed by vehicle crash
(initial speed of 77 km/h, braking towards 56 km/h just before impact against a rigid wall)
• Evasive vehicle maneuver
(lane change)
The load case models are defined in the following files:

a_act50fc_forte_drv.xml [ driver ]
a_act50fc_forte_psg.xml [ passenger ]

Besides the load case models, separate models for driver and passenger settling are provided:

a_act50fc_forte_drv_settling.xml [ driver settling ]

a_act50fc_forte_psg_settling.xml [ passenger settling ]

In the settling models, the human model is unbelted and pre-positioned close to seating equilibrium using
DEFINE-based positioning parameters. If the user wants to simulate other sitting positions, these models will
be used; once the settling simulation is completed, the human model equilibrium state (posture + muscle
activation) can be imported as initial state for the new load case.

All these models make use of the Simcenter Active Human Model (AHM) include file from the Madymo
installation directory.

The Madymo application input decks consist of 9 main sections as shown in Figure 3 on the next page.

P age |4
 Figure 3. Madymo Input-deck for both driver and passenger sides

Simulation settings
Parameters like load case, simulation time, restraint system configurations (under the global GROUP_DEFINE)
and simulation output requests (CONTROL_OUTPUT) can be edited in this section.

Vehicle Interior
The Madymo model of the vehicle interior is divided into several SYSTEM.MODELs:
• Interior: door trim, A- and B-pillars, floor, firewall, windscreen and center console
• Dashboard
• Seat
• Steering column
• Steering wheel
• Pedals
The geometry of the dashboard, the steering column, the steering wheel and the pedals are defined as
INCLUDE files so that the user can create other designs and exchange them easily within the application model.

Restraint System - Seat Belt

The entire seat belt system is defined under one single SYSTEM.MODEL, however each subcomponent of the
seat belt system is defined as INCLUDE file so that other designs can be created and easily exchanged.
The retractor Madymo model contains, by default, a standard Automatic Locking Retractor (ALR) with dual
stage load limitation, a pretension unit and a Motorized Seat Belt (MSB) unit.
Each subcomponent of the seat belt system can be individually activated or deactivated by the user with the
Time-To-Fire parameters under the global GROUPE_DEFINE.

Restraint System – Airbag

The module of the driver airbag (DAB) is attached to the steering wheel’s hub, and the module of the passenger
airbag (PAB) to the dashboard.

Occupant - Driver/Passenger
The occupant, represented by the 50th percentile male active human model, in a usual sitting position is
defined under one SYSTEM.MODEL. The initial state of the occupant was obtained by importing the positions

P age |5
and the muscle activations resulting from the settling simulations (settling models provided). If the user wants
to simulate another sitting position, the occupant will have to be resettled using the settling model.

System Interactions
The interactions between the different system models are defined inside a separate SYSTEM.MODEL. This
SYSTEM.MODEL includes all contact interactions between the different systems. The representation of hand
grip is also included; for the driver the hands hold on to the steering wheel and for the passenger the hands
rest on the upper legs. A user-definable parameter allows the user to tune the threshold force level that will
release the hand grip during load case simulations (time- and/or force-based).

Gravity
All systems in the model are exposed to an acceleration field representing earth’s gravity.

Vehicle Prescribed Motion

The prescribed motion for the vehicle is set in the SYSTEM.MODEL “VehicleMotion_sys”, where a few load
cases are already pre-defined. Load cases can be selected by the end user via the DEFINE-based parameters,
under the global GROUP_DEFINE that is found in the first section of the input deck. The user is of course free
to define and simulate other load cases.

Energy output
Energy output is defined per SYSTEM.MODEL as well as for the complete MADYMO model. This output can be
used to assess simulation integrity (total energy drift, artificial energy contributions).

As an example, Figure 4 shows the sequence of events in the “AEBandCrash” simulation load case. The vehicle
undergoes a pre-crash braking deceleration followed by a collision; the restraint systems operate throughout
the event, either triggered by a dedicated controller or by the deceleration load. The effect of the loading onto
the occupant posture and position is also displayed.

Figure 4. Sequence of event – AEB + crash load case

P age |6
2.1 VEHICLE MODEL
2.1.1 Overall description

The vehicle interior is mainly modelled with Multi-Body surfaces (planes, cylinders and ellipsoids) for better
computation efficiency. The airbags and parts of the seat belt webbing potentially in contact with the occupant
are represented with finite elements. Figure 5 depicts an overview of the model geometry with colors to
indicate the rigid and non-rigid entities:
• In blue, FE deformable entities (airbags and belts)
• In orange, MB surfaces with no contact compliance (considered as rigid)
• In grey, MB surfaces with contact compliance
• In green, FE rigid surfaces (used for visual purpose only)

Figure 5. Vehicle MB Model

In the following sections, a distinction is made between:

• Design parameters which affect the performances of the component. These parameters are design -
specific and are defined on a local level. They are found inside the SYSTEM.MODEL of the component,
under the GROUP_DEFINE element. Examples of Design parameters include: vent diameter for airbag,
load limiter level for seat belts or pretension performances for seat belt pretensioners…
• Activation parameters which trigger the activation of the component. These parameters are load case
- specific and are defined on a global level, in the global GROUP_DEFINE below
CONTROL_ANALYSIS.TIME. Examples of Activation parameters include: time-to-fire for airbag and
pretensioners, switch time for switchable load limiter…
In Table 1 on the next page, the INCLUDE structure of the application model is shown for both driver and
passenger models.

P age |7
 Parametrized Under main GROUP_DEFINE "LoadCaseParameters_gde"
Level 0 Level 1 include (default) Alternative definitions Version Description yes/no VAR_NAME VALUE VAR_NAME VALUE VAR_NAME VALUE
a_act50fc_forte_drv.xml 4.1 Main file for driver simulations N/A
interior_generic_inc.xml 1.0 Interior generic model no
dashboard_generic_inc.xml 1.0 Dashboard generic model no
steeringcolumn_generic_inc.xml 1.0 Steering column generic model no
steeringwheel_generic_inc.xml 1.0 Steering wheel generic model no
pedalbox_MT_generic_inc.xml 1.0 MT generic pedal layout (3 pedals) yes PedalsSelect_def MT_generic
pedalbox_AT_generic_inc.xml 1.0 AT generic pedal layout (2 pedals) yes - AT_generic
seat_generic_inc.xml 1.0 Seat generic model no
belt_3p_buckle_generic_inc.xml 1.0 buckle generic model for 3 point belt yes BeltSelect_def 3p BPSelect_def generic
belt_3p_anchor_generic_inc.xml 1.0 anchor generic model for 3 point belt yes BeltSelect_def 3p APSelect_def generic
belt_3p_retractor_generic_inc.xml 1.0 retractor generic model for 3 point belt yes BeltSelect_def 3p RPSelect_def generic
belt_3p_heightadjuster_generic_inc.xml 1.0 height adjuster generic model for 3 point belt yes BeltSelect_def 3p DLSelect_def generic
beltmaterial_generic_inc.xml 1.0 belt generic material no
DAB_45l_inc.xml 1.0 DAB model, 45 liters yes ABSelect_def 45l
DAB_35l_inc.xml 1.0 DAB model, 35 liters yes ABSelect_def 35l
DAB_55l_inc.xml 1.0 DAB model, 55 liters yes ABSelect_def 55l
motion_posCrash_inc.xml 1.0 Position based vehicle motion for crash scenario yes LoadCase_def Crash MotionType_def pos
motion_posEvasive_inc.xml 1.0 Position based vehicle motion for evasive maneuver scenario yes LoadCase_def Evasive MotionType_def pos
motion_posAEBandCrash_inc.xml 1.0 Position basedvehicle motion for AEB & crash scenario yes LoadCase_def AEBandCrash MotionType_def pos
motion_posSettling_inc.xml 1.0 Position based vehicle motion for settling run yes LoadCase_def Settling MotionType_def pos
Position based vehicle motion for user defined scenario
motion_posUserDefined_inc.xml 1.0 yes LoadCase_def UserDefined MotionType_def pos
(functions to be updated, currently all to zero)
motion_accCrash_inc.xml 1.0 Acceleration based vehicle motion for crash scenario yes LoadCase_def Crash MotionType_def acc
motion_accEvasive_inc.xml 1.0 Acceleration based vehicle motion for evasive maneuver scenario yes LoadCase_def Evasive MotionType_def acc
motion_accAEBandCrash_inc.xml 1.0 Acceleration based vehicle motion for AEB & crash scenario yes LoadCase_def AEBandCrash MotionType_def acc
motion_accSettling_inc.xml 1.0 Acceleration based vehicle motion for settling run yes LoadCase_def Settling MotionType_def acc
Acceleration based vehicle motion for user defined scenario
motion_accUserDefined_inc.xml 1.0 yes LoadCase_def UserDefined MotionType_def acc
(functions to be updated, currently all to zero)
a_act50fc_forte_psg.xml 4.1 Main file for passenger simulations N/A
interior_generic_inc.xml 1.0 Interior generic model no
dashboard_generic_inc.xml 1.0 Dashboard generic model no
seat_generic_inc.xml 1.0 Seat generic model no
belt_3p_buckle_generic_inc.xml 1.0 buckle generic model for 3 point belt yes BeltSelect_def 3p BPSelect_def generic
belt_3p_anchor_generic_inc.xml 1.0 anchor generic model for 3 point belt yes BeltSelect_def 3p APSelect_def generic
belt_3p_retractor_generic_inc.xml 1.0 retractor generic model for 3 point belt yes BeltSelect_def 3p RPSelect_def generic
belt_3p_heightadjuster_generic_inc.xml 1.0 height adjuster generic model for 3 point belt yes BeltSelect_def 3p DLSelect_def generic
beltmaterial_generic_inc.xml 1.0 belt generic material yes BeltMatSelect_def generic
PAB_103l_inc.xml 1.0 PAB model, 103 liters yes ABSelect_def 103l
PAB_120l_inc.xml 1.0 PAB model, 120 liters yes ABSelect_def 120l
Table 1. INCLUDE structure of driver and passenger models

motion_posCrash_inc.xml 1.0 Position based vehicle motion for crash scenario yes LoadCase_def Crash MotionType_def pos
motion_posEvasive_inc.xml 1.0 Position based vehicle motion for evasive maneuver scenario yes LoadCase_def Evasive MotionType_def pos
motion_posAEBandCrash_inc.xml 1.0 Position based vehicle motion for AEB & crash scenario yes LoadCase_def AEBandCrash MotionType_def pos
motion_posSettling_inc.xml 1.0 Position based vehicle motion for settling run yes LoadCase_def Settling MotionType_def pos
Position based vehicle motion for user defined scenario
motion_posUserDefined_inc.xml 1.0 yes LoadCase_def UserDefined MotionType_def pos
(functions to be updated, currently all to zero)
motion_accCrash_inc.xml 1.0 Acceleration based vehicle motion for crash scenario yes LoadCase_def Crash MotionType_def acc
motion_accEvasive_inc.xml 1.0 Acceleration based vehicle motion for evasive maneuver scenario yes LoadCase_def Evasive MotionType_def acc
motion_accAEBandCrash_inc.xml 1.0 Acceleration based vehicle motion for AEB & crash scenario yes LoadCase_def AEBandCrash MotionType_def acc
motion_accSettling_inc.xml 1.0 Acceleration based vehicle motion for settling run yes LoadCase_def Settling MotionType_def acc
Acceleration based vehicle motion for user defined scenario
motion_accUserDefined_inc.xml 1.0 yes LoadCase_def UserDefined MotionType_def acc
(functions to be updated, currently all to zero)

* the entire model is switchable to LHD/RHD

* The position and acceleration based motion for each default loadcase represent similar vehicle motion

P age |8
Note:

Switching from left hand drive to right hand drive traffic has been made easy for the user, in both driver and
passenger models. Symmetrical models can be produced by changing two define parameters (TrafficType_def
and xHD), which can be found in the global GROUP_DEFINE.

Figure 6. LHD/RHD design switch and model

Figure 7. LHD/RHD models

2.1.2 Vehicle interior

The interior trim panels of the vehicle interior are divided into two SYSTEM.MODELs, Vehicle_sys and
Dashboard_sys (in blue and green respectively in Figure 8). Each part of the vehicle interior is defined in an
INCLUDE file, allowing the user to easily simulate different designs.

Figure 8. Model of vehicle interior

P age |9
 Interior trims

The figure below shows the structure of the SYSTEM.MODEL of the interior trims.

Figure 9. Structure of Vehicle_sys SYSTEM.MODEL

The design of the interior trims is defined in the INCLUDE marked in dark blue in Figure 9. The entire interior
is attached to the reference body Vehicle_bod so that the interior moves with the vehicle when a load case is
simulated. Positions of other components of the interior, and restraints systems connected directly to the
vehicle are set within the local GROUP_DEFINE (marked in green in the Figure 9).

Figure 10. Pre-defined attachment points in the vehicle

Dashboard

Figure 11 below shows the structure of the SYSTEM.MODEL of the dashboard.

Figure 11. Structure of Dashboard_sys SYSTEM.MODEL

P a g e | 10
The design of the dashboard is defined in the INCLUDE highlighted in dark blue in Figure 11. The dashboard is
attached to the body DB_Attachment_bod, so that the entire model moves in one block when the position of
the dashboard is shifted. The local GROUP_DEFINE contains the position of the steering column’s and the
passenger airbag module’s attachment points in the dashboard’s coordinate system (marked in green above).
If the positions of these components need to be changed, the positions must be changed in this
GROUP_DEFINE(marked in green in the Figure 11).

Figure 12. Pre-defined attachment points on the dashboard (MB surfaces masked on the picture)

The knee bolsters were separately modelled for the driver and the passenger sides, so that the user can change
the geometries independently. The contact characteristics are equal on both sides, by default. However, they
are individually defined to allow the user to specify different stiffnesses for each side.

Figure 13. Knee bolster geometry and contact definitions

2.1.3 Seat

The seat is modelled with MB surfaces and rigidly connected to the vehicle.

Figure 14. MB Madymo generic seat model

P a g e | 11
The figure below shows the structure of the seat’s SYSTEM.MODEL.

Figure 15. Structure of Seat_sys SYSTEM.MODEL

The design of the seat is defined in the INCLUDE marked in dark blue, above. The entire seat is attached to the
body called Seat_Attachment_bod.
The local GROUP_DEFINE contains seat adjustment parameters (marked in light blue) and the position of the
seat belt component’s attachment points, in the seat’s coordinate system (marked in green).

Figure 16. Pre-defined attachment points on the seat

Four different contact characteristics are assigned to the MB surfaces:

• One for the anti-submarining bar (in orange) – calls specific functions
• One for the seat cushion (in blue) – seat functions scaled
• One for the seat back (in green) – seat functions scaled
• One for the side bolsters and head rest (in grey) – seat functions scaled

P a g e | 12
 Figure 17. Contact characteristics defined in the seat

Important note:
Modifying the seat characteristic, moving the seat up/down, OR changing the seat back angle will require
repositioning, and therefore resettling, of the occupant.

The seat model contains two deformation characteristics; one for the seat back deformation and the other for
the seat lower structure. For the seat back deformation, a tuning parameter SeatBackStiffness, found under
the local GROUP_DEFINE, is available for the user to quickly increase or decrease the deformability of the seat
back.

Figure 18. Deformation characteristics defined for the seat cushion and seat back

Note:
In the global GROUP_DEFINE, a parameter called SEATDEFO_def allows the user to LOCK, or set to FREE, the
deformation joints of the seat. This option is useful for settling runs when you need ensure the seat is fully rigid.

Figure 19. Option for seat deformation’s joints locking

P a g e | 13
The seat model features a recline-able seat back for which the user can define a rotation angle versus time
function. This function (Seatbackmotion_fun) is specified with respect to the nominal seat back position,
defined by the SeatBackAngle parameter.

Figure 20. Active seat back option

2.1.4 Pedal box

Figure 22 shows the structure of the pedal assembly’s SYSTEM.MODEL. The pedal box is attached to the vehicle
via a body (PB_Attachment_bod). The pedals are not deformable entities; however, they can rotate around
their own rotation axis until they reach their end-stop (modelled with RESTRAINT.JOINTs). These deformation
characteristics can be adjusted, if required by the user. When adjustments are made, it is recommended to
save the new include file under a new name. The analysis can be conducted with the pedals set to LOCK or
FREE, by using the PedalsState_def under the global GROUP_DEFINE (by default set to LOCK). The “Lock”
setting is particularly useful during settling runs.

Figure 21. Structure of Pedals_sys SYSTEM.MODEL and available parameters

The PedalsSelect_def design parameter, located in the global GROUP_DEFINE, allows the user to switch
between the manual transmission pedal layout (3 pedals) or the automatic transmission pedal layout (2
pedals).

P a g e | 14
 Figure 22. Manual (left) and automatic pedal (right) layouts

Note:
It is not necessary to resettle the driver occupant if the pedals layout is switched between manual and
automatic transmissions, because the accelerator pedal is at the same position for both pedal layouts.

2.1.5 Steering column

Figure 23 shows the structure of the SYSTEM.MODEL of the steering column assembly.

Figure 23. Structure of SteeringColumn_sys SYSTEM.MODEL and available parameters

The steering column is attached to the dashboard via the body SC_Attachment_bod. The local GROUP_DEFINE
contains steering column design and adjustment parameters. These parameters include: adjustable ranges
and offsets for both the length and angle of the steering column (marked in blue above). As well as, a
parameter that allows the user to adjust the position of the steering wheel’s attachment point, that is in the
steering column hub’s coordinate system (marked in green above). If the position of the steering wheel needs
to be changed, the position must be changed here.

P a g e | 15
 Figure 24. Steering Column MB model

The steering column consists of a chain of rigid bodies linked together with joints. A revolution joint is used
for the steering input as a prescribed rotation; the function used for the steering input is defined for each
scenario in the time function *-Steering_fun under the SYSTEM.MODEL VehicleMotion_sys.
The revolution-translation joint is used to set the steering column in the desired position. The motion of the
joint is restricted in translation and rotation with bottoming-out deformation characteristics. The friction loads
in the RESTRAINT.JOINT are defined to model the locking mechanism threshold; above these values, the
adjustment mechanism will move within the pre-defined adjustment ranges.

Figure 25. Steering column adjustment’s deformation characteristics

The translation joint is used to represent the deformation of the steering column’s collapsing device. For the
deformation of the steering collapsing device, the relevant function is CollapsingDevice_defo_load_fun
(ID=30741) for which the user can adjust the existing force-deflection profile. It is recommended to save the
new steering column under a new name to avoid undesired overwriting.

P a g e | 16
 Figure 26. Steering column collapsing device’s deformation characteristics

For the steering column joints, deformation characteristics are pre-defined but can be adjusted by the user if
required.
An additional feature in the steering column was implemented: it is possible for the user to collapse the
steering column, if required, at a predetermined time. For example, locking the steering column’s collapsing
feature may be useful, although this is dependent on the restraint system adaptiveness, in order to prevent
high injury scores in an unbelted scenario.

These tuning parameters are listed in the global GROUP_DEFINE, as shown in Figure 27.

Figure 27. Activation parameters of steering column collapsing device

Important note:
As mentioned in the description of the parameter SCTTF_def, it is important to ensure that its value is set to
0.000 when the steering column collapse is deactivated (SC_ACT=OFF).

P a g e | 17
2.1.6 Steering wheel

Figure 28 shows the structure of the steering wheel’s SYSTEM.MODEL.

Figure 28. Structure of SteeringWheel_sys SYSTEM.MODEL and available parameters

The steering wheel is attached to the steering column hub via the body SW_Attachment_bod. The local
GROUP_DEFINE contains the steering wheel design parameters, such as: the rim outer diameter, rim thickness,
position of the rim spokes etc. (marked in blue in Figure 28). Also available is the driver’s airbag’s (DAB)
attachment point position that is in the steering wheel hub’s coordinate system (marked in green above). If
the position of the driver’s airbag in the steering wheel’s hub needs to be changed, the position must be
changed here.

The geometry of the steering wheel can be easily changed with the design parameters. Figure 29 shows a few
examples of possible geometries.

Figure 29. Parametrized steering wheel geometry with a few examples

P a g e | 18
Important note:

• Changing the position of the spokes modifies the position of the joints representing the rim
deformation. The deformation characteristics for the lower and upper steering rims are also
automatically scaled on X depending on the position of the spokes.
Example: if both LS_angle and US_angle is equal to zero, the scaling factor applied is 1 (maximum)
• If the inner diameter of the driver airbag (DAB) module is changed (parameter defined in the DAB’s
SYSTEM.MODEL), the same value will also need to be updated in the steering rim’s SYSTEM.MODEL,
under the local GROUP_DEFINE. Making the change in this location will ensure that the dimensions of
the spokes are also updated. If this is not done, initial penetrations with the DAB nodes may occur, and
lead to numerical instabilities.
• Modifying the steering wheel geometry, especially the outer diameter, means that the position of the
AHM’s arms and hands must also be modified. As a result, a settling run will be needed if the geometry
has changed.
The steering wheel model is made of MB ellipsoids, for which a contact characteristic is defined. To represent
the possible deformation of the steering wheel, three joints have been implemented:
• A Universal joint is used to model the connection between the steering column and the steering wheel
hub.
• Two revolution joints are used to represent the deformation of the steering wheel rim: one for the
upper rim, and the other for the lower rim.

Figure 30. Steering Wheel MB model

The steering wheel’s deformation characteristics are pre-defined in the model and can be adjusted by the user.

P a g e | 19
2.2 RESTRAINT SYSTEM MODEL

The restraint system built in the application model consists of a 3-point seat belt and an airbag.

2.2.1 Airbag

Figure 31 shows the structure of the SYSTEM.MODELs for both the driver airbag (DAB) (top) and the passenger
airbag (PAB) models (bottom).

Figure 31. Structure of Airbag_sys SYSTEM.MODEL

For both airbag models, the Time-To-Fire activation parameter (AB_TTF) is defined in the GROUP_DEFINE,
below CONTROL_ANALYSIS.TIME. However, it is also possible to tune the Time-To-Fire parameter as a sub-
parameter, at the local level. The design parameter ‘airbag vent diameter’ (ABVENT_def) is defined at a local
level and not inside the include file of the airbag. This enables the user to easily change the vent diameter, for
a given airbag design, without creating unnecessary include files. These parameters are indicated in blue in
Figure 31.
For the driver airbag model, two additional design parameters are listed – marked in pink in Figure 31, they
define the height and inner diameter of the airbag module.

Important note:
When choosing your required driver airbag design, do not forget to use the module’s recommended value for
its inner diameter. Otherwise, the initial penetration between the module and the airbag edge nodes may occur.
Also, be aware that, the inner diameter must be updated in both the Airbag_sys and the SteeringWheel_sys
SYSTEM.MODELs.

Both DAB and PAB use the Uniform Pressure formulation in combination with a scaled mesh, for their initial
state. Both airbags contain internal straps to restrain the forward deployment towards the occupant. For the
DAB, four 1D MB straps connect the front side of the cushion to the airbag module. While for the PAB, a 2D
FE Y-shape strap is modelled that restrains the airbag deployment in the direction that is towards the head
and the lower thorax region.
For the DAB, MB_FE contact is defined between the airbag, the steering wheel, and the instrument cluster.
For the PAB, the FE_FE contact is defined between the airbag and the facet Dashboard IP surface. For both
airbags, MB_FE contacts are defined between the cushion, the windscreen, roof beam and the A-pillar.

P a g e | 20
 Figure 32. DAB and PAB present in the vehicle

By default, a 45 and a 103 liter airbag is used for the driver and passenger sides respectively.

Figure 33. Airbag design selection parameter

A range of airbag sizes are made available for the user. The user can choose a smaller or larger driver airbag
(35 or 55 liters), as well as, a larger passenger airbag (120 liters). The airbag design selection is easily done by
changing the value of the parameter ABSelect_def, in the global GROUP_DEFINE. Below, you can see the
available airbags that are in static deployments.

Figure 34. Available airbag designs

The user is free to add more design parameters to their model. Below, is a none exhaustive list of
possibilities:

• Define a scaling factor on the mass flow rate as a variable

• Define an entire inflator definition as INCLUDE referred by a variable
• Define strap length of DAB as a variable
• Define airbag fabric as INCLUDE referred by a variable
• Etc.

P a g e | 21
2.2.2 Seat belt

The seat belt consists of many different sub-components, as listed below:

• Height adjuster including D-loop, always attached to the vehicle

• Buckle MB model, including a pyrotechnical pretension unit, always attached to the seat
• Anchor MB model, including a pyrotechnical pretension unit, attached to the vehicle by default
• Retractor MB model that is attached to the vehicle by default, which itself contains:
o A retraction/extraction spring
o A Motorized Seat Belt (MSB) - (acting in pre-crash)
o A dual stage load limitation - (acting in in-crash)
o A pyrotechnical pretension unit - (acting in in-crash)
Below, in Figure 35, the structure of the Belt_sys SYSTEM.MODEL is shown. Apart from the belt fit, which is
occupant position dependent, all the above-mentioned sub-components of the seat belt system are defined
within an INCLUDE (marked in blue on Figure 35). This structure allows, components to be easily modified and
exchanged by the user. The belt material is also defined as an INCLUDE file.

Figure 35. Structure of Belt_sys SYSTEM.MODEL

The components’ design types are defined at the main level, in the global GROUP_DEFINE, as shown on Figure
36.

P a g e | 22
 Figure 36. Design version selection defined in the global GROUP_DEFINE

Depending on the user’s needs, the user can choose to attach the D-loop, the lower anchor and the retractor
to either the vehicle or to the seat. To alter this, the user needs to change the value of the variable
BeltAttachment_def, in the global GROUP_DEFINE. The buckle, however, is always connected to the seat.

Figure 37. Change of seat belt component’s attachments

If the user wants to change the position of each seat belt’s components. They can do this with respect to their
respective attachments, but the coordinates must be changed in the seat or vehicle’s local GROUP_DEFINE, as
shown below (location marked in green on the Figure 38). By default, all seat belt components, except the
buckle, are attached to the vehicle.

Figure 38. Pre-defined position of the seat belt components

Important note:
If the user changes the position or settings of any of the following, a belt refit will be required: the height
adjuster, D-loop when the D-loop is on the seat, the buckle or lower anchor, or the posture of the occupant
Therefore, the belt fit is not defined as part of the INCLUDE because it is load case/settings/ and occupant
posture specific.

P a g e | 23
 Height Adjuster

The height adjuster is rigidly connected to the vehicle and located on the B-pillar. The height adjuster’s design
is also defined as an INCLUDE, this enables the user to create and exchange designs easily. A translation joint
is used to translate the slider, in the rail. This allows the position to be adjusted by the user, in the global
GROUP_DEFINE. This translation joint must always remain locked during simulations. A revolution joint
models the attachment of the D-loop to the slider that is free to rotate around its own axis, with a low friction
torque defined. By default, the D-loop joint remains locked during the simulation.

Figure 39. Height adjuster MB model and available parameters

Figure 40, shows the structure of the height adjuster that is inside the Belt_sys SYSTEM.MODEL. The position
of the height adjuster is defined in the local GROUP_DEFINE, of the Vehicle_sys. However, the orientation of
the height adjuster is defined inside the Belt_sys SYSTEM.MODEL, marked with pink in Figure 40.

Figure 40. Structure of the height adjuster MB model include file

Note:
If the user defines the seat belt components attached to the seat, the height adjuster will still be present in the
model. However, the belt segment will go through the D-loop of the seat and not through the D-loop of the
height adjuster. The D-ring of the seat is not adjustable and is modelled as a routing point.

P a g e | 24
 Buckle

The buckle is always connected to the seat. The buckle assembly is also defined as an INCLUDE, so the user
can create and exchange designs easily. If an attachment position change is required, it can be done via the
design parameter, defined in the seat’s local GROUP_DEFINE. In Figure 41, the structure of the buckle
component inside the SYSTEM.MODEL Belt_sys is shown.

Figure 41. Structure of the buckle assembly MB model

The buckle is articulated via a spherical joint. Additionally, it has deformation characteristics that define the
flexibility of the connection between the buckle and its bracket. These characteristics can be changed by the
user to fit the physical counterpart and are indicated in blue on the Figure 41 above. The deformation joint is,
by default, locked in the model. If the user does not wish to activate the pretension, setting the Time-To-Fire
to a value larger than the simulation end time, will ensure the pretensioner does not fire during the simulation.
Figure 42 and Figure 43 show the design and activation parameters made available to the user at both global
and local level.

P a g e | 25
 Figure 42. Available parameters for the buckle in the global GROUP_DEFINE

Figure 43. Available parameters for the buckle in the local GROUP_DEFINE

The built-in pretension unit can be activated with the Time-To-Fire activation parameter, at the global level.
Pre-tensioning is done with a pre-tensed spring model for which, the initial force and stroke can be adjusted
at the local level. Figure 44 below, shows the buckle assembly MB model in red, on the seat.

Figure 44. Buckle assembly MB model

Anchor

The lower anchor is built in a similar way as the buckle. The anchor assembly is also defined as an INCLUDE so
that the user can create and exchange designs easily. The anchor can be either connected to the seat or the
vehicle. Moreover, if the attachment position is required to be changed, it can be done via the design
parameter, defined in the local GROUP_DEFINE of the seat or the vehicle. In Figure 45, the structure of the
anchor component inside the SYSTEM.MODEL Belt_sys is shown.

P a g e | 26
 Figure 45. Structure of the anchor assembly MB model

Like the buckle, the anchor is articulated via a spherical joint. It has deformation characteristics defined that
model the flexibility of the connection between the anchor and the bracket. These characteristics can be
changed by the user to replicate the physical counterpart. They are indicated in blue in the anchor structure
in Figure 45. The deformation joint is locked, and the Time-To-Fire is set larger than the simulation end time,
by default, in this model. Figure 46 and Figure 47 show the design and activation parameters made available
to the user at both global and local level.

Figure 46. Available parameters for the anchor in the global GROUP_DEFINE

P a g e | 27
 Figure 47. Available parameters for the anchor in the local GROUP_DEFINE

The built-in pretension unit can be activated with the “Time-To-Fire” activation parameter at the global level.
The pre-tensioning is done with a pre-tensed spring model for which, the initial force and stroke can be
adjusted at the local level.
Figure 48 below shows the anchor assembly MB model in red, on the seat.

Figure 48. Anchor assembly MB model

Retractor

The retractor MB model can be either connected to the seat or the vehicle. Like the other components of the
seat belt system, the retractor assembly is defined as an INCLUDE, allowing the user to create and exchange
designs easily. If the attachment position needs to be changed, it can easily be done via the design parameter,
defined in the local GROUP_DEFINE of the seat or the vehicle. The choice of using the seat or vehicle is
dependent on, upon which it is attached. Below, in Figure 49, the structure of the retractor inside the
SYSTEM.MODEL Belt_sys is shown.

Figure 49. Location of the retractor assembly in the SYSTEM.MODEL Belt_sys

P a g e | 28
This retractor MB model contains the following features:

• Retraction/extraction spring
• Motorized Seat Belt (MSB)
• Dual stage load limitation
• Pyrotechnical pretension unit
The activation parameters are listed in the global GROUP_DEFINE as shown in Figure 50.

Figure 50. Activation parameters defined in the global GROUP_DEFINE

The MB model consists of an assembly with a series of translation joints. Each joint representing a functionality
of the retractor. A deformation characteristic is defined for each joint, so, the retractor model will work in the
desired way. The list below shows the order of the joins in the series:
• retraction/extraction spring joint
• pyrotechnical pretension unit joint
• first level of the load limitation joint
• second level of the load limitation joint
• Motorized Seat Belt joint
• film spool effect joint
For further information, the activation sequence (lock/unlock of the joints) is described in the model.

All the design parameters for the retractor are listed in the local GROUP_DEFINE, as shown on Figure 51. The
user is free to change any of these design parameters or characteristics (film spool, load limitation etc.) to
replicate the physical components they are modelling.

P a g e | 29
 Figure 51. Design parameters available defined in the local GROUP_DEFINE

A constant load limiter is already built into the model. However, the model was built so that the user can
simulate more complex load limiter designs, such as: dual stage, electronically or mechanically switchable
designs that can be switched from one level to the other.

In the example settings below (Figure 52), the load limiter will switch from the first (high level, value set with
R_LL1F) to the second one (low level, value set with R_LL2F) after a certain amount of belt extraction (value
set with R_LL1S).

Figure 52. Example of settings for a mechanical dual stage load limitation

Therefore, R_LL1S is 0.080, meaning 0.080m of webbing payout to switch to the second level AND
R_LL2ACT=1.000, meaning the load limiter will switch 1.000s after the crash begins from the higher to the
lower level (act as not triggered).

In the example settings below (Figure 53), an electronically switchable dual stage load limiter is shown.

Figure 53. Example of settings for a switchable dual stage load limitation

For a switchable load limiter, R_LL1S must be set to a large value (1.000 m for example). This ensures that the
load limitation never switches by itself from one level to the other. R_LL2ACT must be set to the desired switch
time, for example 0.040ms after the crash begins.

For a digressive or progressive load limitation, the characteristic representing the load limitation must be made
digressive or progressive. The variable R_LL1F will not be used anymore. R_LL1S and R_LL2ACT must also be
set to large values (e.g. 1.000 m and 1.000 s respectively) so that the load limiter never switches to the second
level.
For a single stage constant load limitation, set R_LL1S and R_LL2ACT as described above and set R_LL1F to the
desired value.

Note:
All the load limitation force levels defined in the retractor represent the theoretical force that would result from
the torsion bar deformation and would be measured at the retractor outlet. It is not exactly the force often
given as “shoulder belt force” which is mostly higher due to the friction build-up in the D-ring.

P a g e | 30
2.3 OCCUPANT MODEL
Both driver and passenger models use the Simcenter Madymo Active Human Model (AHM) 50th percentile,
Version 3.3. For more information on the occupant model, the user is referred to the Madymo Model Manual
of the respective release version.

2.4 LOADING REPRESENTATION

The motion of the vehicle is prescribed via MOTION.JOINT_POS if working with position or the
MOTION.JOINT_ACC if working with acceleration signals. The import or translation of vehicle kinematics from
physical tests or car driving simulation is straight forward. The 6 degrees of freedom are defined with 6
functions (acceleration or displacement functions versus time).

The application model already contains four pre-defined scenarios; one scenario for settling the occupant
model in the seat (zero signals for vehicle motion) and three load case scenarios:

• “Settling” - occupant settling in seat under gravity load, running from -5.000 to 0.000 s
• “Crash” - constant speed driving (no braking) followed by 50km/h rigid wall impact,
running from -0.750 to 0.180 s (or 0.000 to 0.180 s if no prior-to-crash activation of the restraint
system is done)
• “AEBandCrash” - autonomous emergency braking followed by 50km/h rigid wall impact,
running from -0.750 to 0.180 s
• “Evasive” lane change maneuver (no impact), running from -3.000 to 0.000 s
Figure 54 shows the structure of the SYSTEM.MODEL for the vehicle motion.

Figure 54. Position based definition of the load case

Important note:
The names of these functions start with a name (underlined in the Figure 54) which, is the actual name of the
load case to be simulated. By assigning the correct value to the variable named LOADCASE (under
GROUP_DEFINE, below CONTROL_ANALYSIS.TIME), the solver will automatically refer to the desired load case.
For driver applications, a 7th function needs to be defined. This additional function represents the rotation
input of the steering wheel. Furthermore, the nature of the prescribed motion (position or acceleration based)
can be set using the DEFINE parameter named ‘#MotionType_def’.

Use the following procedure if a different type of load case is required:

P a g e | 31
• Set the variable called Veh_sensor_pos to the correct value. This variable represents the position of
the vehicle sensor mounted in the vehicle, expressed in the vehicle’s coordinate system. In some cases,
when several sensors were used, an equivalent vehicle sensor position must be calculated.

Figure 55. Sensor location/Joint position of prescribed motion

• The include file “motion_UserDefined_inc.xml” contains ‘zero’ functions. To define a new load case,
either change the pre-defined functions or create a new include file using the same naming convention
e.g. motion_scenario1_inc.xml, scenario1_TranX_fun etc.

Figure 56. Vehicle motion position-based definition for user defined scenario

• Set the value of the variable called LoadCase_def, under the global GROUP_DEFINE, below
CONTROL_ANALYSIS.TIME to scenario1 (or any other load case name). The user may choose
prescribed motion to be position based or acceleration based by modifying ‘MotionType_def’ to pos
or acc, as shown in figure 57.

Figure 57. Load case and prescribed motion type definition

• Make sure that the DEFINE parameters StartTime_def and EndTime_def are consistent with the time
frame on which the simulation is supposed to be run.
P a g e | 32
3 INPUT PARAMETERS
By selecting specific input parameters, the user can customize the generic model as desired. The main input
parameters can be selected by using the DEFINE elements present in the generic model and following the
instructions reported in the sections below.

3.1 LOAD CASE

To simulate new load case scenarios, the following steps need to be followed:
• Define an additional scenario in a new motion include file. Call the new include file in the
SYSTEM.MODEL called VehicleMotion_sys (see the previous section 2.4)
• Set StartTime_def and EndTime_def accordingly
• If the scenario also contains a crash phase, set CrashTime_def to the time when the crash occurs. If no
crash occurs, set CrashTime_def > EndTime_def.
• Set the variable called LoadCase_def and MotionType_def to the corresponding scenario and
prescribed motion type (‘pos’ or ‘acc’), respectively.

Figure 58. Setting-up a load case

3.2 RESTRAINT SYSTEM

The activation parameters available, to be modified by the user, are in the global GROUP_DEFINE and include:
• Triggering time of the airbag (in-crash parameter)
• Triggering time of the buckle pretensioner (in-crash parameter)
• Triggering time of the anchor pretensioner (in-crash parameter)
• Triggering time of the retractor pretensioner (in-crash parameter)
• Triggering time of the Motorized Seat Belt (pre-crash parameter)
• Triggering time of the steering column collapse (in-crash parameter, driver load case only)
P a g e | 33
 Figure 59. Setting-up the restraint system

For all the other design parameters available in the model, please refer to the section dedicated to each
component.

3.3 HUMAN RESPONSE CONTROL

Many parameters can be edited to simulate different muscle behavior, awareness or reactiveness of the
occupant. All these parameters, as well as the positioning parameters, can be found in the local
GROUP_DEFINE, defined under the occupant’s SYSTEM.MODEL.

In Table 2, the activation parameters of the Active Human Model and their respective description are listed
with recommended value settings.

Important note:
Changing some of the positioning parameters will affect the theoretical equilibrium of the occupant and the
position of the belt on the occupant. Therefore, it is recommended to perform a settling run (using the settling
models) and a belt refit whenever changes are made to the occupant’s position. A belt refit can be performed
with the XMADgic Belt Fitting Tool (hotkey: F10).

P a g e | 34
 Table 2. DEFINE’s for the AHM’s response control
DESCRIPTION
NeckActivation_def Activation of the neck muscles
SpineActivation_def Activation of the spine
ShoulderActivation_def Activation of the shoulder
Muscle
Activation
ElbowActivation_def Activation of the elbow muscles
HipActivation_def Activation of the hip muscles
KneeActivation_def Activation of the knee muscles
Attempt for the neck controller to
HeadRef_def
Head control the head orientation
Orientation
Body that is used for relative
HeadRelBod_def
head control
Isometric pre-tension of the neck
Neck_CCR_def muscles (co-contraction) as a
reaction to danger (bracing)
Constant or variable neck muscle
VarNeckCCR_def
co-contraction over time
AHM
awareness
and bracing
parameters Time delay after which muscles
ReactionTime_def
respond to stimulus
Enables/disables the delay in the
DelayEnable_def
muscles’ reaction
Strength scale factor that applies
StrengthFactorGlobal_def to all muscles and actuators in
model
Strength scale factor that applies
StrengthFactorNeck_def
to neck muscles only
Muscle Strength scale factor that applies
StrenghtFactorSpine_def
strength to spine actuators only
scaling Strength scale factor that applies
StrengthFactorShoulders_def
to shoulder actuators only
Strength scale factor that applies
StrengthFactorArms_def
to arm muscles only
Strength scale factor that applies
StrengthFactorLegs_def
to leg muscles only
VALUE/RANGE
0 => passive response
1 => active response
0 => passive response
1 => active response
0 => passive response
1 => active response
0 => passive response
1 => active response
0 => passive response
1 => active response
0 => passive response
1 => active response
0 => head straight (no head
rotation w.r.t. reference
space)
1=> neck straight (no head
rotation w.r.t. to T1 or other
body)
T1_bod => default
Any body element
[0.05 - 0.20] => relaxed
[0.40 - 0.60] => braced
0 => constant co-contraction
1 => variable co-contraction
[0 – 25ms] => reaction time of
a person aware of the
upcoming stimulus
[60 – 160ms] => reaction time
of a person unaware of the
upcoming stimulus
0 => no delay (settling only)
1 => delay
1 => strength for average
male
1 => strength for average
male
1 => strength for average
male
1 => strength for average
male
1 => strength for average
male
1 => strength for average
male
P a g e | 35
Figure 60 shows the human response parameters which can be edited under the local GROUP_DEFINE of the
occupant’s SYSTEM.MODEL.

Figure 60. Parameters available for the Active Human model’s response control

P a g e | 36
4 OUTPUT DESCRIPTION
Typically, in the FORTE simulation there are two relevant phases: Pre-crash with highly dynamic maneuver
loading and in-crash loading. Both phases are characterized by different result parameters. For the pre-crash
phase, analysis of occupant displacement is the most relevant. Whereas for in-crash, acceleration and force-
based injury criteria are of more importance.

To assist in defining correct outputs for pre- and in-crash analysis, the tables below summarize which signals
could be used for the analysis of each phase.

4.1 PRE-CRASH OCCUPANT OUTPUTS

The linear velocities and displacements monitor the occupant’s motion in the passenger compartment and are
expressed in the vehicle’s reference system (the outputs are referred to a body called Vehicle_bod). The
recommended outputs are listed in Table 3.
Table 3 Occupant Signals for Pre-Crash analysis

DESCRIPTION REFERENCE
Linear velocity of the head center of gravity
HeadCGcorrect_vel Vehicle coordinate system
- res., x, y, z components
Linear displacements of the head center of
HeadCGcorrect_dis Vehicle coordinate system
gravity - res., x, y, z components
Relative angle between the head center of T1 body coordinate
HeadT1correct_ang
gravity and the T1 vertebra – 3 rotations system
Linear velocity of the T1 vertebra –
T1correct_vel Vehicle coordinate system
res., x, y, z components
Linear displacements of the T1 vertebra -
T1correct_dis Vehicle coordinate system
res., x, y, z components
Linear velocity of the pelvis - res., x, y, z
Pelvis_correct_vel Vehicle coordinate system
components
Linear displacements of the pelvis –
Pelvis_correct_dis Vehicle coordinate system
res., x, y, z components

4.2 IN-CRASH OCCUPANT OUTPUTS

The recommended output injuries for the analysis of the in-crash phase have been selected according to the
Euro NCAP and US NCAP protocols.

Important note:
The injury risk results should not be interpreted and directly compared to results coming from simulations run
with the Hybrid III 50% dummy or critical values from crash protocols; they are meant for relative comparisons
to evaluate the performance of different safety system solutions only.

P a g e | 37
 Table 4. Occupant Injuries for In-Crash analysis

DESCRIPTION Euro NCAP US NCAP

BrIC_inj Brain injury criterion - BrIC X
HIC15_inj HIC - 15 ms time window X
HIC36_inj HIC - 36 ms time window X
H3MS_inj Cumulative Acceleration in a 3 ms time window X
HeadCG_acc (peak Peak value of the resultant head linear
X
value) acceleration
NecktensZpeak_inj Peak value of the Neck tension force X
NeckcompZpeak_inj Peak value of the Neck compression force X
FNICshear_inj NIC shear - positive and negative X
FNICtension_inj NIC tension X
FNICbending_inj NIC extension X
ThCC_inj Chest Deflection [mm] X X
VC_CFC180_inj Viscous Criterion [m/s] X
FFCL_inj Left Femur compression force [kN] X X
FFCR_inj Right Femur compression force [kN] X X
kneesliderL_inj Left Knee slider compressive displacement [mm] X
Right Knee slider compressive displacement
kneesliderR_inj X
[mm]
TIUpL_inj Left top Tibia Index [-] X
TIUpR_inj Right top Tibia Index [-] X
TILowL_inj Left bottom Tibia Index [-] X
TILowR_inj Right bottom Tibia Index [-] X

4.3 BELT OUTPUTS

For the analysis of belt forces and payouts for both driver and passenger sides, the following signals were
predefined:

Forces:
BPillarBelt_frc force on shoulder belt measured between retractor and D-ring
SchoulderBelt_frc force on shoulder belt measured after D-ring
AnchorLapBelt_frc force on lap belt measured on anchor side
BuckleLapBelt_frc force on lap belt measured on buckle side

Pay-outs/-ins:
RetractorMSB_pos pay-in resulting from MSB actuation (pre-crash)
RetractorMSB_vel pay-in velocity resulting from MSB actuation (pre-crash)
RetractorPT_pos retractor pre-tensioner pay-in
RetractorLL1_pos Load limiter level 1 pay out
RetractorLL2_pos Load limiter level 2 pay out
RetractorFS_pos payout resulting from film spool effect

The output block under SYSTEM.MODEL Retractor_sys, contains additional output definitions for a more
detailed analysis, e.g. acceleration recorded at retractor locking ball etc.

P a g e | 38
5 MODEL USE
Models are available for both driver and passenger simulations, with pre-defined pre-crash and in-crash
scenarios. The models can be further adjusted, combined or replaced with user defined braking, evasive
profiles or crash pulses. Simulations can be run for the driver or for the passenger separately. However,
simulation results can be overlapped and analyzed together, if the load case parameters have been set
identically, for both models.

5.1 FILE SYSTEM

Model files for settling simulations:

a_act50fc_forte_drv_settling.xml [user file to execute driver side settling simulation]

a_act50fc_forte_psg_settling.xml [user file to execute passenger side settling simulation]

Model files for load case simulations:

a_act50fc_forte_drv.xml [user file to execute driver side load case simulation]

a_act50fc_forte_psg.xml [user file to execute passenger load case side simulation]

Active human model include file:

h_act50fc_sitting_inc.xml [include file; not to be modified; place in directory of user files]

5.2 OCCUPANT POSITIONING & BELT FITTING

The driver and passenger models available for settling simulations have the same vehicle setup as the load
case models, but the seat belt and airbag system models have been disabled. The human model is pre-
positioned as close as possible to the expected equilibrium posture. Pre-positioning variables are defined in
the local GROUP_DEFINE of the Active Human Model. Human model activation parameters (DEFINEs) shall be
set in the same configuration as intended for the load case simulations that follow, but with a few exceptions:
• ‘Delay_enable_def’ shall be set to 0 to minimise the ‘time-to-equilibrium-state’.
• ‘<Shoulder|Elbow|Hip|Knee>Activation_def’ shall be set to 0 to maintain flexibility of the extremities
during settling
In the settling models, the load case parameters have been pre-set as shown in Figure 61and Figure 62.
After running the settling simulations, the occupant joint positions and the muscle/actuator activation levels
shall be imported into the load case models. More information on the settling procedure for the active human
model is given in the modelling guidelines document ‘h_act50fc _Guidelines.pdf’.

Important notes:
• The supplied load case models already have the initial equilibrium state imported from simulations
performed with the settling models. For simulations with the current human posture and activation
settings, the user does not need to perform the settling procedure.
• Changing the occupant positioning parameters will affect the equilibrium of the occupant in the seat
and the routing of the belt webbing on the occupant. Therefore, it is recommended to re-execute the
settling procedure and re-fit the seat belt when changing the occupant’s position in alternative load
case simulations.

P a g e | 39
 Figure 61. Correct load case parameters for settling simulations

Figure 62. Example of set for positioning parameters for settling simulations

P a g e | 40
Note:
Once the posture resulting from the settling run is imported into the load case model, the values set in the
DEFINEs after the ‘Human H-point placement’ block, shown above, are obsolete. This is because the formulas
and expressions defined under each INITIAL.JOINT_POS elements will be overwritten by the import tool.

5.3 RUNNING LOAD CASE SIMULATIONS

The load case models contain three pre-defined load case scenarios and an additional user defined load case
(apart from the “Settling” option):
• Constant speed driving followed by crash load-case – “Crash”
• Emergency braking followed by crash – “AEBandCrash”
• Evasive steering maneuver – “Evasive”
To run one of these configurations, the user needs to set the DEFINE parameters, found in the global
GROUP_DEFINE LoadCaseParameters_gde. For each of the DEFINEs, the description attribute provides
guidelines on how to set them, for the pre-defined load cases. Airbag inflator and seat belt pre-tensioner
triggering can be de-activated by setting their fire times to a time later than simulation end time (e.g. 1.000 s).

Figure 63. Load case and restraint system activation parameters

Note:
Under the global GROUP_DEFINE, mainly activation parameters can be found. If the user desires to change
specific components such as: the load limiter level or the vent diameter of the airbag, these can be edited in
their respective local GROUP_DEFINE.
The user is of course free to move or copy these parameters from the local level to the global level for better
access, from the model complexity perspective. To move one parameter from the local to the global level,
simply cut and paste the parameter from the local GROUP_DEFINE to the global GROUP_DEFINE.
To duplicate a given parameter and rename it, follow the below two steps:

P a g e | 41
Step 1 – Create a new DEFINE with the desired variable name in the global GROUP_DEFINE, for instance
VENTHOLEDIAMETER

Step 2 – Refer the newly created parameter in the local GROUP_DEFINE containing the original variable under
VALUE. Note that the variable name must start with # when it is called in the VALUE cell.

P a g e | 42
6 RESTRAINT SYSTEM ROBUSTNESS
The default restraint system defined in the model features:
• A retractor with constant load limiter and pretension unit
• Driver and passenger airbags with internal straps, two vent holes
• Buckle with pretension unit
• Steering column collapsing device with unlocking pin – locked for unbelted cases, unlocked for
belted cases.
• No further active systems or adaptivity

6.1 RESTRAINT SYSTEM CONFIGURATION

Below is shown the configuration of the restraint system for both driver and passenger.

Table 5. Restraint system definition

6.2 RESULT OVERVIEW

The restraint system was optimized to:

• Pass FMVSS208 Rigid Wall 25mph unbelted load case, driver and passenger, both Hybrid III 5th and
50th percentile dummies
• Pass FMVSS208 Rigid Wall 35mph belted load case, driver and passenger, both Hybrid III 5 th and 50th
percentile dummies
• Perform at least 4 stars for US NCAP Rigid Wall 35mph, driver Hybrid III 50th and passenger 5th
percentile dummies
• Perform at least 4 stars for Euro NCAP:
o Rigid Wall 50kph, Hybrid III 5th percentile driver and passenger dummies
o Offset Deformable Barrier 64kph, Hybrid III 50th percentile driver and passenger dummies
The appendix (section 8) presents the results of the performance check, of the restraint system, described in
Table 5.

P a g e | 43
7 LIST OF PUBLICATIONS RELATED TO FORTE
1. Roy Bours, Ruud Verhoeve, Kajetan Kietlinski, Martijn Tideman, Enhancing Real-life Safety by
Integration of Active and Passive Safety System Simulation, JSAE Annual Congress, Japan 2012, ref no.
68-20125200
2. Martijn Tideman, Roy Bours, Kajetan Kietlinski, Ruud Verhoeve, Hao Li, Integration of active and
passive safety system simulation to enhance a vehicle’s real-life safety, VTI 2012, Changchun, China
3. Robin van der Made, Roy Bours, Martijn Tideman, Kajetan Kietlinski, Enhancing real-life safety by
integration of Active and Passive Safety System Simulation, Airbag 2012 Symposium, Karlsruhe,
Germany, December 2012, ref no. P26
4. Salvatore Battaglia, Kajetan Kietlinski, Michiel Unger, Robin van der Made, Roy Bours, Occupant
behavior during a one-lane change maneuver resulting from autonomous emergency steering, ESV
2013, Seoul, Korea. May 27th-30th, Paper Number 13-0383
5. Mauro Velardocchia, Michiel Unger, Alessandro Vigliani, Nicola Leone, Kajetan Kietlinski, Enrico
Galvagno; Integrated Active and Passive Systems for a Side Impact Scenario, SAE World Congress 2013,
doi: 10.4271/2013-01-1162
6. Salvatore Battaglia, Kajetan Kietlinski, Michiel Unger, Robin van der Made, Roy Bours;
Insassenverhalten während eines Spurwechsels durch Notfall bedingte autonome Lenkung, VDI-
Tagung mit Fachausstellung “Fahrzeugsicherheit”, 20. und 21. November 2013 Berlin, Germany.
7. Martin Tijssens, F. Bosma, K. Kietlinski, A methodology and tool chain to design integrated safety
system, JSAE Annual Congress, Japan 2015, ref no. 327-20155327
8. Salvatore Battaglia, Kajetan Kietlinski, Michiel Unger, Occupant protection in rear-end collisions
preceded by autonomous emergency breaking deployment, ESV 2015, Gothenburg, Sweden, June 8-
11, Paper Number 15-0246
9. Nicola Leone, Kajetan Kietlinski, Michiel Unger, Occupant protection performance in side impact
collisions preceded by pre-crash deployment of on-board safety systems, ESV 2015, Gothenburg,
Sweden, June 8-11, Paper Number 15-0310
10. Krauns, F., Kietlinski, K. Henze, R., Tijssens, M., Prof. Küçükay, F., Analyse von Fahrerbewegungen unter
dem Einfluss von Automatisierungsstufen und einer Pre -Crash Maßnahme Crash Maßnahme, VDI 2017
11. Bosma, F., van Hooijdonk, P.A., Tijssens, M.G.A., Kietlinski, K. and Unger M., A simulation study on the
effect of AEB on injuries on 50% occupants, ESV 2017, Detroit, USA, June 5-8, Paper number 17-0281
12. Tijssens, M.G.A., Bosma, F., van Hooijdonk, P.A., Kietlinski, K. and Unger M., A methodology to study
the effect of AEB on injuries on 50% occupants, JSAE Annual Congress, Japan 2017, ref no. 2017259

P a g e | 44
8 APPENDIX – RESULTS OF THE PERFORMANCE CHECK
This appendix presents the results of the performance checks, of the restraint system, described in Table 5.
The used tests were previously described in section 6 of this manual.

8.1 FMVSS208 RIGID WALL 35MPH BELTED LOAD CASES

Table 6. FMVSS208 Rigid Wall 35mph belted load cases, Hybrid III 5th and 50th dummies

P a g e | 45
Figure 64. FMVSS208 Rigid Wall 35mph belted load cases, Hybrid III 5th dummy

P a g e | 46
Figure 65. FMVSS208 Rigid Wall 35mph belted load cases, Hybrid III 50th dummy

P a g e | 47
8.2 FMVSS208 RIGID WALL 25MPH UNBELTED LOAD CASES

Table 7. FMVSS208 Rigid Wall 25mph unbelted load cases, Hybrid III 5th and 50th dummies

P a g e | 48
Figure 66. FMVSS208 Rigid Wall 25mph unbelted load cases, Hybrid III 5th dummy

P a g e | 49
Figure 67. FMVSS208 Rigid Wall 25mph unbelted load case, Hybrid III 50th dummy

P a g e | 50
8.3 USNCAP RIGID WALL 35MPH BELTED LOAD CASES

Figure 68. USNCAP Rigid Wall 35mph load case

P a g e | 51
Figure 69. USNCAP Rigid Wall 35mph load case

P a g e | 52
8.4 EURONCAP OFFSET DEFORMABLE BARRIER 64KPH BELTED LOAD CASE

Table 8. EuroNCAP Offset Deformable Barrier 64kph load case

The salmon colored injury criteria are duration-based injuries: in the result column, only the maximum
values are listed. The maximum values are lower than the minimum values of the corridors specified by Euro
NCAP, these criteria pass. However, the duration plots are not presented in this performance overview.

P a g e | 53
Figure 70. EuroNCAP Offset Deformable Barrier 64kph load case

P a g e | 54
8.5 EURONCAP RIGID WALL 50KPH BELTED LOAD CASE

Table 9. EuroNCAP Rigid Wall 50 kph load case

Figure 71. EuroNCAP Rigid Wall 50 kph load case

P a g e | 55