Passenger cars — Simulation model classification — Part 1: Vehicle dynamics

A systematic framework has been created that facilitates the definition of the requirements of simulation models for certain applications and driving manoeuvres in a standardized manner. For this purpose, the proposed framework systematically divides the vehicle model into model classes and all model classes into different model types, corresponding to various model characteristics and common modelling methods. The vehicle dynamics manoeuvres have been additionally structured and clustered. Manoeuvres can be assigned to model classes and model types using an allocation and requirements table. This document thus also creates the basis for model recommendations relevant to vehicle dynamics with regard to advanced driver assistance systems and automated driving (ADAS/AD). The application of the framework and the specification of the model requirements are the responsibility of the user. Alternatively, they may be determined by other regulations and standards. This document contains recommendations for selectable model characteristics in terms of adequate simulation quality with respect to performance tests and associated application patterns. The recommendations can be adapted accordingly to be applied to functional testing.

Voitures particulières — Classification des modèles de simulation — Partie 1: Dynamique du véhicule

General Information

Status
Published
Publication Date
14-Apr-2022
Current Stage
6060 - International Standard published
Start Date
15-Apr-2022
Due Date
28-Jan-2022
Completion Date
15-Apr-2022
Ref Project

Relations

Standard
ISO 11010-1:2022 - Passenger cars — Simulation model classification — Part 1: Vehicle dynamics Released:4/15/2022
English language
32 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


INTERNATIONAL ISO
STANDARD 11010-1
First edition
2022-04
Passenger cars — Simulation model
classification —
Part 1:
Vehicle dynamics
Voitures particulières — Classification des modèles de simulation —
Partie 1: Dynamique du véhicule
Reference number
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3  Terms and definitions . 1
4 Model designation numbers . 3
4.1 General . 3
4.2 Physical system . 3
4.3 Controller . 4
5 Model classes . 5
5.1 General . 5
5.2 Vehicle/body . 7
5.3 Aerodynamics . 9
5.4 Brake . 11
5.5 Powertrain . 14
5.6 Steering . 17
5.7 Suspension . 20
5.8 Tyre . 23
5.9 Road surface . 26
6 Driving manoeuvres .28
6.1 Driving manoeuvre classes .28
6.2 Classification of standardized driving manoeuvres .28
7  Classification matrix .30
Bibliography .32
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 33,
Vehicle dynamics and chassis components.
A list of all parts in the ISO 11010 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
This document has been developed in response to worldwide demand for the standardization of
simulation models and their requirements for use in specific applications and driving manoeuvres.
During the development and testing of road vehicles questions arise around which simulation models
should be applied and how well matched they need to be for performing certain applications with
related driving manoeuvres. In the absence of standards it is common practice that experts in different
organizations develop their own methods and processes as response to these questions. This causes
obstacles when it comes to comparability and model exchange between project partners. Currently,
unless the requirements for simulation models undergo extensive elaboration and coordination among
the experts involved, there will be major uncertainty with their implementation and quality.
The main purpose of this document is to provide a framework that enables a systematic assignment
of certain applications and driving manoeuvres to suitable simulation models and their elements
and characteristics. This document classifies the simulation models into certain model classes, their
designation number and related elements, characteristics and common modelling method. Assigning
models to classes related to specific applications is the responsibility of the user or other regulations
and standards. This document contains recommendations in the sense of an appropriate simulation
quality in terms of performance tests, thus enabling the user to specify the requirements for the models
with reference to this document. This document thus also creates the basis for model recommendations
relevant to vehicle dynamics with regard to advanced driver assistance systems and automated driving
[19]
(ADAS/AD) .
v
INTERNATIONAL STANDARD ISO 11010-1:2022(E)
Passenger cars — Simulation model classification —
Part 1:
Vehicle dynamics
1 Scope
A systematic framework has been created that facilitates the definition of the requirements of
simulation models for certain applications and driving manoeuvres in a standardized manner.
For this purpose, the proposed framework systematically divides the vehicle model into model classes
and all model classes into different model types, corresponding to various model characteristics and
common modelling methods. The vehicle dynamics manoeuvres have been additionally structured
and clustered. Manoeuvres can be assigned to model classes and model types using an allocation and
requirements table. This document thus also creates the basis for model recommendations relevant to
vehicle dynamics with regard to advanced driver assistance systems and automated driving (ADAS/
AD).
The application of the framework and the specification of the model requirements are the responsibility
of the user. Alternatively, they may be determined by other regulations and standards. This document
contains recommendations for selectable model characteristics in terms of adequate simulation quality
with respect to performance tests and associated application patterns. The recommendations can be
adapted accordingly to be applied to functional testing.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 3833, Road vehicles — Types — Terms and definitions
3  Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 3833 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
simulation model
mathematical model for the calculation of the system state variables based on equations describing a
vehicle or vehicle sub-system
Note 1 to entry: The vehicle’s environment is only modelled as far as required, i.e. friction of the road surface,
wind, etc. Models in this context are both, the unit under test (UuT) as well as models to supplement or complete
the simulation loop.
3.2
model class
mathematical model based on the vehicle or vehicle sub-systems
3.3
model designation number
gradation of model type and depth with associated model characteristics, represented effects and
minimal model inputs and outputs
3.4
steady state model
physical model representing the definitions of steady state equilibrium mentioned in ISO 8855
Note 1 to entry: The model represents the transfer function between model input and output for steady-state
equilibrium. The model is not capable of representing the correct time behaviour. Effects caused through small
changes in time may be neglected. The model is usually mathematically described by a gain.
3.5
first order model
model, in addition to the steady state model (3.4), capable of representing the transient behaviour
Note 1 to entry: The physical model is usually described mathematically by a differential equation with a first
order lag force element such as PT1 behaviour with a first order.
3.6
second order model
model defined by a second order force element such as PT2 behaviour with second order
Note 1 to entry: Due to its conjunct complex poles, a time variant input results in an oscillatory output.
3.7
model-in-the-loop
MiL
testing method in which the controller is integrated as a unit under test (UuT) with a full-function
controller (3.12) into the simulation model (3.1) as a controller model
3.8
software-in-the-loop
SiL
testing method whereby the controller is integrated as a UuT with complete controller functionality as
application software from the ECU into the simulation model (3.1)
Note 1 to entry: See Figure 1.
3.9
processor-in-the-loop
PiL
testing method whereby the controller together with processor emulation is integrated as UuT into the
simulation model (3.1)
3.10
open-loop control
controller that influences a system’s behaviour without a feedback loop, for example based on maps
3.11
principal logic closed-loop controller
controller that influences a system’s behaviour with a feedback loop
Note 1 to entry: For principal logic, the controller is implemented in a simplified form, for example, with a PID
controller, to demonstrate the control logic.
3.12
full-function controller
controller that is implemented with complete functionality, but with operation restricted to the
function control algorithm under test
Note 1 to entry: The controller is realized as either MiL (3.7) or SiL (3.8).
3.13
ECU-in-the-loop
test method whereby the controller is integrated as a UuT into the simulation model (3.1) as a real ECU
(Figure 1)
Note 1 to entry: In this document it refers primarily to the controller. The controller is typically implemented in
hardware-in-the-loop (HiL).
3.14
full-function virtual ECU
vECU
controller that is implemented as a UuT with the whole ECU software with application and base
software (Figure 1)
Note 1 to entry: The controller is realized virtually via emulation in SiL mode. Full-function architecture means
software modules such as AUTOSAR connect the virtual ECU to the vehicle's communication network.
3.15
electric brake booster
brake booster that has the ability to amplify the braking force applied by the driver through electrical
actuation and autonomously build up pressure without driver actuation
[20]
Note 1 to entry: Electric brake boosters consist of a control unit, electric actuator and transmission device .
4 Model designation numbers
4.1 General
Each model class may consist of a physical system, including hydraulics and pneumatics, and a controller.
This segmentation can be extended to sensor and actuator.
4.2 Physical system
The model of a physical system shall have a model designation number from Table 1, according to the
definitions in Clause 3. The force element characteristic ranges from level 0 – no model – to level 3 –
second order model and within the sub-designation levels 1.x to 3.x. If a model requires a deeper sub-
categorization, the dot notation and a second digit starting from 1 shall be used.
NOTE The model designation numbers are valid for all vehicle sub-systems from 5.1 except the suspension
model, since its designation numbers 1 and 2 lack body masses. Nevertheless, the suspension model designation
numbers are adapted reasonably.
Table 1 — Model characteristic and designation number of a physical system
Force element characteristic Model designation number
None 0
Steady state model 1
First order model 2
Second order model 3
4.3 Controller
The controller model shall have a model designation number from Table 2 according to the definitions
in Clause 3. The model characteristics range from level 0 – no model – to level 4 – ECU-in-the-loop (HiL).
For level 2 and 3, a deeper subcategorization “3.x” is used.
The subcategorization “.x” of level 2 and 3 defines the range of subsets of the target software (see
Figure 1), being included in the test bench. This depends on the scope of investigation, mostly in the
context of model-based testing. While level 1 and 2.1 controller models contain a simplified principal
logic, level 2.2 models map the target function (MiL) – that is the original control structure function
and application. Model level 2.3 (SiL) is based on the compiled target code of the application software
(see Figure 1). A level 3.1 model is restricted to the application software (e.g. implementation of control
functions and application parameter) as well as the base software such as a virtual ECU (vECU). A
level 3.2 model additionally includes the emulation of the processor and the software is compiled for
the target processor. Model 4 is the typical HiL as ECU-in-the-loop with hardware-specific software,
communication and diagnosis.
Table 2 — Model characteristic and designation number of controllers
Model designation num-
Description
ber
None 0
Open-loop control 1
Principal logic closed-loop controller 2.1
Target function: model-in-the-loop (MiL) – application software model only 2.2
Target software: software-in-the-loop (SiL) – application software only 2.3
Target software: full-function virtual ECU (vECU) – application + base software 3.1
Target software: processor-in-the-loop (PiL) 3.2
Target ECU: ECU-in-the-loop (HiL) 4
Figure 1 — Subsets of a controller
Figure 1 illustrates a typical software architecture of a real or virtual control unit in reference to
Table 2 with the levels: application software, base software and interfaces to actuators, sensors and
network.
NOTE The performance of a closed-loop controller can be significantly influenced by the time latency of
sensor signals.
Compared to the model designation number of the physical system (see 4.2), the designation number of
the controller is not mainly influenced by the driving manoeuvre, but by the scope of the investigation.
In predevelopment stage, a simple principal logic might be sufficient to evaluate the overall vehicle
behaviour; for functional development and safeguarding, the original function should be used. Some
exemplary types of investigation concerning the choice of the controller designation number are given
in Table 3.
Table 3 — Examples for the selection of controller designation number
Type of investigation Controller designation number
Preliminary design physical system 0/1/2.1
Functional development (preliminary design) 2.2/2.3
Homologation 2.3/3.1/4
Safeguarding of software implementation 2.3/3.1
Safeguarding of function including operation system 3.1/3.2/4
Systematic functional safeguarding in spite of a lack of a virtual
controller model
5 Model classes
5.1 General
The vehicle model is structured in the following model classes according to Figure 2: vehicle / body
(VH), powertrain (PT), brake (BR), steering (ST), suspension (SU), aerodynamics (AE) and tyre (TY)
and the road with road surface (RS) and road wind (RA). Some model classes consist only of a physical
system XXM, others as combination of a physical system XXM and a control system XXC. The models
refer to common vehicle systems as currently used in passenger cars. The user can create model
prototypes of future systems accordingly.
Independently of the above-mentioned structure of the models, a controller is not necessarily mapped to
a single ECU. An ECU will likely host more than one single controller. In addition, a controller algorithm
might be distributed over multiple ECU. This is of importance especially for higher model designation
numbers, where base software or other properties of the ECUs shall be considered.
NOTE It is possible that there are differing allocations and interfaces defined in Clause 5. In this document,
the axial rotation of wheels is calculated in the powertrain (PTM) and is passed to the tyre (TYM) and brake
(BRM).
Key
signalbus (bidirectional)
actor
sensor
forces
kinematics
Figure 2 — Top-level model architecture
The control systems XXC are specific for their components XXM. Sometimes a “central controller”
coordinates the component-specific controller. For ADAS a sensor-based environment detection and
trajectory planning is necessary as well as a trajectory control. Trajectory control generates target
values for the component-specific controllers: in longitudinal direction for the powertrain (PTC)
and brake (BRC) and in the lateral direction for the steering (STC). Due to the fact that the “central
controller” is very specific to the manufacturer it is not classified in this document.
NOTE The “central controller” can be partitioned into separate control unit(s) or added to the control unit of
the specific controller(s).
The capital letters in parenthesis are the model classes’ abbreviations. The selected designation number
of a model class shall be written in the following syntax:
M
C
The actual names and numbers shall replace the placeholders in angled brackets. For the
the specified abbreviation shall be used. The syntax resembles that in the following examples:
STM2
PTM2 PTC4
BRM2.1 BRC3.1
NOTE This can be extended to sensor and actuator via the syntax:
S
A
5.2 Vehicle/body
The model class vehicle (VH), with the architecture in Figure 3, is actually targeted to describe the
modelling of the vehicle body. However, depending on the designation number, it is possible that the
vehicle body is not isolated from the whole vehicle model. The higher the designation number, the better
the vehicle body can be isolated.
The model class vehicle (VH) shall have a designation number of the physical system (VHM) in
accordance with Table 4.
The designation numbers for class vehicle does not follow exactly the classification as described in
Table 1. Here the principle “best practice” applies. Thus, the models are clustered into three groups:
VHM1: one body model;
VHM2: multi-body model split sprung mass, unsprung mass, rigid bodies and look-up table for
suspension;
VHM3: multi-body model split sprung mass, unsprung mass, multi-body suspension.
In the group VHM1 the tyre is combined with the vehicle, while in the groups VHM2 and VHM3, the
vehicle body can be isolated from suspension and tyre. As an example, the widely used single-track
model belongs to VHM1, and VHM3 has the 3D-vehicle body model with local stiffness/stiffness matrix
within its scope.
Figure 3 — Vehicle architecture
Table 4 — Vehicle system
Common modelling methods / typical Minimal model Minimal model
Model type Model description Description Effects
application area input output
VHM0 None
Single mass, one dimen- Forces (braking,
VHM1.1 Single mass 1-DoF Starting, braking (ODE) differential equation (1-DoF) ax
sional accelerating)
Lateral dynamics model (ODE) differential equation / function test for
VHM1.2 Single track model Understeer/oversteer Steering angle ay, yaw
with constant velocity controller
Load transfer due to
VHM1.2+ lateral load trans-
Single track model with lateral vehicle lateral acceler- VHM1.2+ load dependent tyre forces due to
VHM1.3 fer due to ay, load depend- VHM1.2 VHM1.2, roll
load transfer ation tyre character- roll
ent tyre model required
istics
VHM1.2+ longitudinal Load transfer due to
Single track model with longitu- load transfer due to ax, vehicle longitudinal VHM1.2+ load dependent tyre forces due to
VHM1.4 VHM1.1+ VHM1.2 VHM1.1+ VHM1.2
dinal dynamics load dependent tyre model acceleration tyre char- pitch/ function test with controller (e.g. ACC)
required acteristics
MBD mechanics
3D-model with rigid bodies and 3D-model with rigid bodies 3D-model with suspension + tyres/ function Forces moments / Motion of bodies and
VHM2.1 (split sprung mass,
look-up table suspension including wheel bounce and performance test of controller aero hard points
unsprung masses)
MBD mechanics
3D-model with rigid bodies and 3D-model with rigid bodies 3D-model with suspension + tyres/ function Forces moments / Motion of bodies and
VHM3.1 (split sprung mass,
MBD suspension including wheel bounce and performance test of controller aero hard points
unsprung masses)
VHM3.1. and global stiff-
3D-model with flexible elements VHM3.1+ global stiffnesses lumped in concen-
VHM3.2 nesses (torsional stiffness, VHM3.1 VHM3.1 VHM3.1
(global stiffnesses) trated spring-damper elements
bending)
3D-model with flex bodies (local VHM3.2 + local defor- VHM3.2 + parts flexible modelled or full flex-
VHM3.3 VHM3.2 + local stiffnesses VHM3.2 VHM3.2
stiffnesses) mation body (stiffness matrix)

5.3 Aerodynamics
The model class aerodynamics (AE), with the architecture in Figure 4, shall have a model designation
number of the physical system (AEM) in accordance with Table 5. The modelling of aerodynamic effects
is divided into three subgroups. Aerodynamic effects in the vehicle models discussed in this document
are modelled by forces and sometimes by moments. The first effect considered is in general the drag
force, see AEM1.1. The next level includes vertical forces described by the sublevel AEM1.2. Sublevel
AEM1.3 is included in order to take sidewind effects into account in the model.
Figure 4 — Aerodynamics architecture
Table 5 — Aerodynamics system
Common modelling methods /
Model type Model description Description Effects Minimal model input Minimal model output
typical application area
AEM0 No aerodynamics
Only longitudinal drag Force from constant factor or
AEM1.1 Drag Drag-forces Vehicle velocity Long force
forces are considered. curve
Vertical forces which
Additionally, front and rear influence limit Force from constant factor or Long and vertical forces,
AEM1.2 AEM1.1 + vertical Vehicle velocity
lift forces are considered. under-/oversteer curve pitch moment
balance.
Forces and moments (or a pair
All three dimensions are AEM1.2 + yaw, roll mo-
AEM1.3 AEM1.2 + sidewind Sidewind sensitivity of forces) from constant factor Vehicle and air velocity
considered. ment
or fields
5.4 Brake
The model class brake (BR) with the architecture in Figure 5 contains the brake controller (BRC)
and the physical system (BRM) is specified as hydraulic service-brake system. The hydraulic service-
brake system allows the driver to reduce speed or to stop the vehicle completely. Therefore, the driver
activates the braking effect by pressing on the brake pedal. A vacuum booster amplifies the force. It is
transmitted to the wheel brake cylinders via the tandem master brake cylinder to two independent
hydraulic circuits.
For active systems like ABS, TCS or ESC, a hydraulic unit is attached between master brake cylinder
and brake pipes. This hydraulic unit contains valves and a pump, either for modulating the wheel
cylinder pressure, or to actively build up the pressure for stabilizing the vehicle. A related algorithm,
also responsible for the brake force distribution between front and rear axles, controls the valves and
pump.
Nowadays electric brake boosters are becoming more commonplace, either as a substitute for vacuum
boosters in electrical vehicles, or with combined usage in hybrid and electrical vehicle as well as for
autonomous pressure build-up for advanced driver assistance systems functions (ADAS). Alternatively,
[20]
electric brake booster and ESC-unit can be combined in an aggregated solution.
The model class brake (BR) with the architecture shown in Figure 5 shall have a model designation
number of the physical system (BRM) in accordance with Table 6 and a designation number of the
controller (BRC) in accordance with Table 7.
The model class brake (BR) contains the mechanical and hydraulic part (BRM) as well as the related
controller (BRC). BRM1.0 is a pure algebraic calculation of the pressure in the wheel brake cylinder.
BRM2.1 calculates the pressure of the wheel brake cylinder in dependency of the master cylinder
pressure as an input. Depending on elasticities in the pipes and wheel brake cylinder, a volume flow
is calculated and integrated as a final pressure in the wheel brake cylinder. BRM2.2 is based on the
same principle, considering the flow through valves based on pre-calculated characteristic maps
or polynomial and the volume flow induced by the pump. In addition, BRM3.1 considers pressure
oscillations in the brake pipes and wheel brake cylinders up to about 40 Hz, whereas BRM3.2 includes
the dynamics of pump and valve bodies. Booster functions are considered purely algebraically in
BRM3.3 and in BRM3.4 with a feedback control function (oscillatory) using pedal position, pedal force
or requested deceleration as input. The ESC and electric brake booster controller (BRC) are available as
MiL-, SiL-, PiL- and HiL-versions. The interface between the controller of the electric brake booster and
[20]
ESC is specified .
The BRM-block is linked by kinematic and kinetic quantities to the PTM-block. The BRC-block is linked
to the vehicle controller network by a bus-system (CAN, FlexRay). VHM- and PTM-block provide some
sensor signals to the BRC-block hardwired. Blocks BRC and BRM exchange actuation and sensor
feedback signals.
NOTE It is possible that there are differing allocations and interfaces. In this document, the axial rotation of
wheels is calculated in the powertrain (PTM) and is passed to the tyre (TYM) and brake (BRM).
Figure 5 — Brake architecture
Table 6 — Brake system
Common modelling methods /
Model type Model description Description Effects Minimal model input Minimal model output
typical application area
No brake pressure mod-
BRM0
ulation
Pressure in wheel brake Pressure in wheel brake
Pressure in wheel brake cylinder, cylinder proportion- cylinder as a function of target For example, target Pressure in wheel brake
BRM1 Steady-state behaviour
system oriented al to master cylinder deceleration, vehicle mass, tyre deceleration cylinders
pressure radius, brake friction coefficient
Volume flow and pres- Bernoulli-characteristic curves
First order behaviour Pressure in wheel brake cylinder, Pressure in the master Pressure in wheel brake
BRM2.1 sure due to elasticity in and lines, (Typ1), pV-character-
without control system oriented brake cylinder cylinders
the brake system istics; <10 DGLs 1. Ord.
BRM2.1with valve current and Pressure in the master
First order behaviour Pressure in wheel brake cylinder, BRM2.1 with valve and Pressure in wheel brake cylin-
BRM2.2 pump voltage >10 DGLs 1. Ord., brake cylinder, valve and
with control system oriented pump actuation ders, voltage of pump motor
1 DGL 2. Ord. pump actuation
First order behaviour Brake pedal force, or ac-
BRM2.2, actuation of motor and Booster-travel, pressure in
ESC with algebraic Pressure in wheel brake cylinder, BRM2.2 with algebraic tuation of booster motor,
BRM2.3 motion of the booster- and valve wheel brake cylinders voltage
electric brake booster system oriented Booster function actuation of valves and
bodies of pump motor
function pump
Pressure in the master
Second order behaviour Pressure in wheel brake cylinder, BRM2.x with brake pipe BRM2.x with brake pipe dynam- Pressure in wheel brake cylin-
BRM3.1 brake cylinder, valve and
without control system oriented dynamics up to 40 Hz ics based on acoustic theory ders, voltage of pump motor
pump actuation
Pressure in the master
Second order behaviour Pressure in wheel brake cylinder, BRM3.1 with dynamics Characteristic curves and lines, Pressure in wheel brake cylin-
BRM3.2 brake cylinder, valve and
with control component oriented of valve and pump body (Type 2), Newton- Euler-Eq. ders voltage of pump motor
pump actuation
Second order behaviour Brake pedal force, or ac-
BRM3.2 actuation of motor and Booster-travel, pressure in
ESC with oscillatory Pressure in wheel brake cylinder, BRM3.2 with dynamic tuation of booster motor,
BRM3.3 motion of the booster- and valve wheel brake cylinders voltage
electric brake booster system oriented booster function actuation of valves and
bodies of pump motor
function pump
Table 7 — Brake controller
Common modelling
Model type Model description Description Effects methods / typical ap- Minimal model input Minimal model output
plication area
No regulation, no
BRC0
control
BRC1 Open-loop control
Stabilisation of wheel Vehicle-, wheel velocities, steering
Control based on idealized and
BRC2.1 Principle logic rotation and/or yaw rate of ABS-, FZR-PID-controller angle, yaw rate, pressure in the Brake torque at wheels
complete signals
vehicle body master cylinder
Wheel speed signals, steering
Model of ECU-ASW-code of the Actuation of valves and pump,
MiL: ABS, TCS, yaw con- angle, yaw rate, pressure in the
BRC2.2 Full function MiL ESP-function controller, signal conditioning, interventions into powertrain
trol-function modelled master cylinder, reduced set of
observers management
BUS signals
Wheel speed signals, yaw rate, Actuation of valves and pump,
ECU-ASW-code of the con- SiL: ABS, TCS, yaw con-
lateral acceleration, steering interventions into power-
BRC2.3 Full function SiL ESP function troller, signal conditioning, trol 1:1-code compiled
angle, pressure at master cylinder, train management, controller
observers for WINx
reduced set of BUS signals network
Wheel speed signals, yaw rate, lat- Actuation of valves and pump,
SiL: complete code of
ECU-code (no real time eral acceleration, steering angle, interventions into power-
BRC3.1 Full function SiL ECU-ASW and BSW-code ECU-SW (CSW) compiled
capability) pressure at master cylinder, CAN/ train management, controller
for WINx
FlexRay network
Wheel speed signals, yaw rate, lat- Actuation of valves and pump,
Emulated ECU (in control PiL: complete code of
Performance concerning eral acceleration, steering angle, interventions into power-
BRC3.2 Full function PiL network of ECU(s) or) ECU-SW (CSW) on emu-
processor pressure at master cylinder, CAN/ train management, controller
static restbus lated target-ECU
FlexRay network
Wheel speed signals, yaw rate, lat- Actuation of valves and pump,
HiL: complete code of
ECU-code (real time capa- eral acceleration, steering angle, interventions into power-
BRC4 Full function HiL Real ECU ECU-SW (CSW) on tar-
bility) pressure at master cylinder, CAN/ train management, controller
get-ECU
FlexRay network
5.5 Powertrain
The model class powertrain (PT) with the architecture in Figure 6 contains the powertrain controller
(PTC) and the physical system (PTM). The PTM mostly consists of a motor, a gear box and an axle gear
box. Additional further components might be included to perform torque splitting (e.g. transfer case,
differential lock) or electrical support (hybrid drive). The PTC consists principally of a motor control
unit and a gear control unit; additional control units might have a share in torque splitting depending
on the physical system PTM.
The PTC evaluates the engine target torque and the gear as a result of accelerator pedal and gear lever.
In case of (A)DAS or stability control, additional motor torque requests have to be included. The PTM
represents the physical system from actors to wheel speeds. The wheel speeds are transferred to the
tyre and break model (TYM, BRM) for slip/force calculation.
Figure 6 — Powertrain architecture
Various model detailing and the associated designation numbers are presented in Table 8 and Table 9.
The model PTM1 is an exception, due to the fact that it does not need a PTC and TYM. It describes directly
the correlation between accelerator pedal and driving force. The model designation number PTM2 is a
transient model with rigid components, PTM3 is an oscillatory model with an elastic powertrain.
NOTE 1 Since there is an innumerable number of combinations concerning torque splitting and electric
components, 5.5 restricts itself to a generic interface. Nevertheless, it is essential to consider all torque splitting
components in order to obtain valid results in driving dynamics. In this case the modelling method is similar to
the controller defined in Table 9. The torque distribution can be given as boundary condition (open loop) or can
be calculated by a controller (-> PTC) and friction model (-> PTM) in the case of a clutch.
NOTE 2 In case of torque split components (e.g. transfer case, differential lock) the torque distribution can be
given as boundary condition or can be calculated by an (inverse) model using constraints, if the torque split is
realized by a clutch.
Table 8 — Powertrain system
Common modelling meth-
Model type Model description Description Effects ods / typical application Minimal model input Minimal model output
area
The superordinate model does
not need the velocity as a state
PTM0 None
or uses a constant velocity as
boundary condition.
Motor torque full load/ drag;
Steady state
Static correlation accelerator Sum of driving forces(longitudi-
gear ratio (maybe reduced);
PTM1 Look up table Accelerator pedal
pedal to sum of driving forces nal)/torque
behaviour
AT: torque converter
Motor transfer function(s);
PTM1 +
Engine target torque
fixed torque distribution;
Model includes all driving torque
(PTC); gear (PTC);
First order Wheel speeds;
generator (combustion/electric) inertia (may be reduced)
PTM2 rigid drive components; brake (BRM) and
and converter and the calcula-
behaviour engine speed
tyre reaction torques
motor dynamics; efficiency
tion of wheel speeds.
idealized shifting operation;
(TYM)
factors/power loss
efficiency factors.
PTM2 + MKS
Second order Formula PTM2 but with
Non-steady motor torque; pow- important: adequate sus-
PTM3 Formula PTM2 Formula PTM2
behaviour elastic powertrain ertrain stiffness and inertia and pension and tyre model has
friction/damping to be used.
Table 9 — Powertrain controller
Common modelling methods Minimal model
Model type Model description Description Effects Minimal model input
/ typical application area output
PTC0 No control
Accelerator pedal,
Engine target
Realization of torque request by
Realization of torque request,
torque,
PTC1 Open-loop control the driver (accelerator and brake Look up tables gear lever,
AT: gear shifting program
pedal and the gear lever)
gear
engine speed (ptm).
PTC1 +
PTC1 +
requests motor torque from,
PTC2.1 Closed-loop control Principal logic / PID Transfer functions Formula PTC1
requests motor torque, e.g. (A)
e.g. stability control, (A)
DAS
DAS …
PTC2.2 Target function Full-function logic Test of target function MiL Input signals Output signals
Target-application soft- Original software restricted to
PTC2.3 Validation of software SiL Input signals Output signals
ware application software only
Original ECU software (applica- Output bus mes-
PTC3.1 Target-ECU software Validation of software SiL Input bus messages
tion and basis software) sages
Emulated ECU (in control net- Performance concerning Output bus mes-
PTC3.2 Target-ECU software PiL Input bus messages
work of ECU(s) or) static restbus processor sages
Hardware ECU in control net- Output bus mes-
PTC4 Target ECU Hardware ECU test HiL Input bus messages
work of ECU(s) or static restbus sages

5.6 Steering
The model class steering (ST), as mechanical coupled steering system, with the architecture in Figure 7
shall have a model designation number of the physical system (STM) in accordance with Table 10 and
a model designation number of the controller (STC) in accordance with Table 11. The STC evaluates a
required torque/force as a result of the external input, e.g. the steering wheel angle and torque, velocity
and acceleration, the vehicle velocity and the torsion bar torque. In case of stability control and ADAS/
AD, additional torque/angle requests have to be included. The STM represents the physical system from
steering wheel to the steering rack or steering arm at the steering knuckle (tie rods and bearing in the
wheel carrier are excluded). The rack or steering arm forces or positions are transferred to the SUM +,
e.g. via ball joints.
Figure 7 — Steering architecture
Table 10 — Steering system
Common modelling methods / typical appli- Minimal
Model type Model description Description Effects Minimal model input
cation area model output
Fixed wheel position or steering
STM0 No model
angle input
Steady-state behav- Function between steering wheel Steering ratio without com-
STM1.1 Factor or lookup table for steering ratio Steering wheel angle Rack position
iour angle and steering angle pliance
Function between steering wheel
Steady-state be- Steering ratio without
angle and steering angle and Factor or lookup table for steering and torque Steering wheel angle /
STM1.2 haviour with boost compliance and steering Rack position
steering angle and steering torque ratio steering wheel torque
function assistance
(Boost curve)
Elasto-kinematic steering func-
Steering
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...