Proceedings of ESDA 2006

8th Biennial ASME Conference on Engineering Systems Design

Proceedings and Analysis
of ESDA2006
8th Biennial ASME Conference on Engineering Systems Design andTorino,
July 4-7, 2006, AnalysisItaly
July 4-7, 2006, Torino, Italy

ESDA2006-95660
ESDA 2006-95660

CONTROL DEVELOPMENT PROCESS OF THE BRAKE-BY-WIRE SYSTEM

Francesco Canuto Patrizio Turco Davide Colombo

Vehicle Control System Vehicle Control System Vehicle Control System
Centro Ricerche Fiat Centro Ricerche Fiat Centro Ricerche Fiat
Orbassano (TO), Italy Orbassano (TO), Italy Orbassano (TO), Italy

ABSTRACT
The main goal of brake by wire technology is the development
of compact, cheap and flexible braking systems. Since neither
brake fluid nor hydraulic lines are used, brake by wire electro-
mechanical actuation is a favourable solution both for
production process and environmental aspect, and offer a
precise control of braking torque amplitude. One of the most
critical aspect is the lack of traditional link between brake pedal
and brakes (calliper); this mean a potential safety problem to be
correctly managed through the system architecture,
redundancies, diagnosis and recoveries. During CRF brake by
wire system development several architectures were deeply
analysed using PHA, FMEA, and FTA methodology to identify
the best configuration for production intent. The selected one is
a fault-tolerant architecture based on a time-triggered
communication network connecting fail-silent nodes. From
safety analysis were defined critical events and system
diagnosis and recovery requirements specifications. This paper
describes the steps followed in the brake by wire software
development, and its validation with respect to safety needs. For
this purpose a three levels design and validation process was
exploited. First of all, it was defined the complete simulation
template including calliper electro-mechanical actuators and
theirs ECU, time-triggered communication network and vehicle
control ECU. The brake by wire system was interfaced to a
complete vehicle dynamics model specifically developed for
control design and validation purpose. Within this environment
the control software was developed and the strategies were
verified applying Software In the Loop technique. Then the
ECU software was automatically generated using a customised
tool chain based on Real Time Workshop Embedded Coder.
Than, Hardware In the Loop testing was adopted to deeply
verified high level software (application), low level software
(OS, API, drivers,…) and hardware. HIL bench include the
complete brake by wire system and a real time platform running
the same vehicle model used during previous phase. Finally,
vehicle testing phases complete the evaluation in the real
environment and allows the system control development and
tuning toward performances and subjective aspects. In each
phase the system is tested both in normal and faulty conditions;
a fault injection campaign was carried on to verify system
response to fault with respect to the expected one. The process
is cyclical, and a new loop has to be activated for each changes
in the system. At the same time, testing complexity increases in
order to guarantee the system safety.
INTRODUCTION
Recently, ten years after aeronautical and industrial
applications, in automotive research centre a lot of resources are
devoted to the exploration of X-by wire technology based on
electromechanical actuation. The goal of these studies is the
development of compact, cheap and flexible systems with high
integration potentiality.
Actually, in modern car, we can already found expression of
both electromechanical and by-wire technologies. For example
in mass production vehicles by FIAT, Toyota, BMW, Honda,
Peugeot, Opel, etc, the EPS (Electric Power Steering), is taking
the place of the conventional hydraulic power steering systems
with advantages in costs, fuel consumption and with enhanced
capabilities of integration with other system like the brake
stability control (ESP).
By-wire technology is also used in production car. In several
vehicle the gas pedal is linked to the engine control ECU by
electrical connections decoupling the driver request from actual
engine generated torque. This degree of freedom is used to

1 1 Copyright © 2006 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a

 optimise consumptions, reduce emission and to easy introduce • Missing brake when request;
new services like traction control and cruise control. • Braking without request.
But if from one side by-wire technology represents a good
opportunities for the vehicles of the future, not only in terms of FMEA and FTA determines the fault causing the critical events.
performances, but also for an ecological and economical point For each item identified in this phase, diagnosis for detection
of view, on the other side it requires a reassessment of the whole and identification are defined. Time and modes for the recovery
system architecture and specifications. For instance the actions follow from Vehicle Dynamic analysis.
hardware architecture must be conceived to be flexible, cheap
and with the faculty to operate in case of fault. The software Safety Requirements Software Control Design
architecture has to be designed looking at the possible PHA
interaction with other system and with the capability of reaction Critical Events Process definition FDIR Design
to faults. FTA
But one of the most critical aspects of by-wire technology is Severity
Occurrency
Diagnosis design
- Fault Detection
safety. From this point of view the by-wire systems ought to be FMEA - Fault Identification

as reliable as the traditional ones or even more. - Diagnosis validation

Critical
The concept of safety is connected to the notion of risk. Risk is component faults Process definition
Recovery design

a combination of the likelihood and the severity of an identification - Recovery states

- Recovery modes
unplanned, undesirable event. A system is generally considered FMEA analysis Diagnosis
safe if the level of risk is reasonable. So engineers have to solve List of Fault modes &
effects
Request

two new problems: Status Vehicle

1. how to evaluate the level of risk of the system & Diagnosis Parameters
Allowed Time & Mode
2. how to set the value of acceptance for the risk level of Disturbance

To solve these problems standard methodologies, such PHA System Analysis in System Control
(Preliminary Hazard Analysis) FMEA (Failure Mode and Faulty Condition
Fault Management
System Recovery Design

Effects Analysis) FTA (Faul Tree Analysis) are used.

Figure 1: Safety Oriented Design

The Brake-by-Wire system developed in CRF is based on Safety analysis sets guidelines for the SW control development
electromechanical technologies: structured in the following subsystems:
• Electromechanical Braking Corner: • Brake Control Task:
- No more oil; - Vehicle Dynamics Control task (Normal condition)
- Easy to assembly; • Base brake;
- Fine torque control. • Electrical Parking Brake;
• X-By-wire architecture: • Electronic Brake Distribution;
- Decoupling driver request from torque • . . . . .;
actuation; - Braking Function (Faulty Condition);
- Integration with the other vehicle dynamics • Recovery Action;
control. • Transient Management;
• Diagnosis Task:
A Brake-by-Wire system, because of the lack of the hydraulic - Software algorithm for Fault Detection Identification
and mechanical links between brake pedal and callipers, needs and Recovery;
more safety requirements than a traditional electro-hydraulic - Finite State Machine for the system State
braking system. Management;
Therefore developing the control of a Brake-by-Wire system
needs a structured methodology to guarantee safety This paper describes the methodology used to develop and
requirement. The safety design must be integrated with the validate the control software with respect to safety (Diagnosis
control design in an iterative process where the output is the and Recovery) requirement by checking step by step the control
tested and certificated control SW. software and system functionality.
The first step consists in checking the Control Software in a
Starting from safety analysis, performed with the above virtual environment on simulation platform. Then the complete
mentioned standard methodologies, diagnosis and recovery brake-by-wire system with the actual hardware is tested on a
requirement are defined. bench. Finally the system and its integration with other system
The most critical events for a braking systems, derived from is tested on the prototype. With this procedure only tested and
PHA (Preliminary Hazard Analysis), are:

2 2 Copyright © 2006 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a

 HMI
WSpeed WSpeed

RHF RHR
EMB2_RHF EMB4_RHR

BRK2 VCS_A BRK4

RHF BCU2_RHF BCU4_RHR RHR

Power A
Power BUS

TTP-BUS

CANService-BUS

Power B
BCU1_LHF BCU3_LHR

EMB1_LHF BRK1
WSpeed
BRK3 EMB3_LHRWSpeed
LHF LHF LHR LHR

Figure 2: CRF Brake-By-Wire Architecture

certified software is used on the vehicle, saving time and
money. Driver and vehicle safety is improved as well.
ARCHITECTURE
The Brake-by-Wire architecture include the following parts
(Figure 2):
• Four electro-mechanical actuators: each actuator is
composed by an electro-mechanical calliper with its
own sensors, wheel speed sensor and the ECU, for the
local corner management;
• ECU for the Vehicle Dynamic Control and integration
with the other vehicle systems;
• HMI (Human Machine Interface), where are installed
brake command sensors;
• Time Triggered Communication Net;
• Redundant power supply
The Brake-by-Wire system is subdivided into two functional
layer:
• Vehicle Layer, which includes the Vehicle Control
functions;
• Local Layer, which includes the EMBs functions.
A distributed software architecture allows a deep integration
between Local Layer and Vehicle Layer and guarantees a safe
braking action though a functional redundancy.
The vehicle layer implements the following functions:
• Vehicle Dynamic Control:
- Vehicle State Estimations;
- Brake Management;
- Electrical Parking Brake Strategies;
- Control Strategies in recovery states;
• System Diagnostic:
- Fault Detection;
- Fault Identification and isolation;
- Recovery management.
The local layer implements the following functions:
• Brake Control
- The purpose of this function is to control the
braking of each single wheel, according to the
brake torque set points aligned with the vehicle
control system. The function is responsible to
provide proper braking force.
• Parking Brake drive:
- The purpose of this function is to activate /
deactivate the parking brake.
• System Diagnosis:
- The purpose of this function is to continuously
perform the diagnostics of the system, its
components and its interfaces. There are a number
of sub-functions performed:
- Fault detection
- Fault information storage and management
- Information to the Vehicle Control Layer
• System self-test.
SAFETY REQUIREMETS
As more and more automotive systems can no longer relay on
mechanical backup, they have to provide deterministic
behaviour even in the presence of faults. While today approach
toward fail-safe operation is based on each system unit (ECU)
redundancies, Brake-by-Wire uses the inherent distributed
redundancy of the brake system in order to provide fail-
safe/fault tolerant operation.

3 3 Copyright © 2006 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a

 System Architecture
Design System Calibration

Modelling
Identification Revision
Phase Safety assessment
(eg. Fault injection)

Control System SW Control

Design
Preliminary
Tuning

Recovery Design

System CIL (Component In the Loop)

Recovery
Set-up & Debug HIL (Hardware In the Loop)
Design
Design Flow

Code Generation

Figure 3: Software Control Development Methodology

Using this distributed redundancy opportunity it is possible to BRK3_LHR Brake Component for X
obtain a Fail Safe System dealing with fail operational mode Wheel "Left Hand Rear":.
BRK4_RHR Brake Component for X
and an appropriate system architecture. Wheel "Right Hand
Rear":.
Brake-by-wire systems belong to the category of the Safety VCS_A Vehicle Control System A. X
Critical System (SCS). These systems must guarantee their
functionality when a fault occurs. The SCS components have HMI (1) Human Machine Interface X
(1): Sensors Blocks
been divided into two classes of “fault robustness”:

• Fail Operational (FO): components that must tolerate

SOFTWARE CONTROL DEVELOPMENT
at least one fault guaranteeing safe functionality. The
METHODOLOGY
breakage have to be detected and signalized..
The methodology used in Brake-by-Wire control software
development follow the well known V-cycle approach.
• Fail Safe (FS): components that, under faulty
Figure 3 shows the V-cycle approach.
condition, must modify their behaviour without
damaging functionalities carried out by the
It’s possible to identify three phases:
components causing the missing of safe of the system.
• SW Formulation and Design Phase according to PHA,
FMEA, FTA analysis.
The table 1 shows the attributes of the main components of the
• Code generation phase (Tool Chain for code
Brake-by-Wire systems:
generation).
Table 1: Brake-by-Wire Components Safety attributes • SW Debugging, Validation and certification, using
three levels of checking (SIL, PIL and HIL)
Component Description FO FS
BRK1_LHF Brake Component for X The method is iterative and continuously upgrades when control
Wheel "Left Hand Front":.
BRK2_RHF Brake Component for
software doesn’t meet safety and functional requirements.
X
Wheel "Right Hand
Front":

4 4 Copyright © 2006 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a

 Debugging and validation method It is a fundamental phase for testing on the actual vehicle and
environment. A deeper level of validation and a system setup
Software debugging, validation and certification are performed
toward driver perception are reached.
by way of SIL, PIL and HIL techniques. The main steps
followed in Brake-by-Wire system debugging and validation Simulation in the Loop:
- Code Generation
were, according to the level validation goals: - Upgrade Hardware
- SW Debugging
- Preliminary Tuning
• SIL, Software in the Loop Validation; SIL Iteration - Fault Injection (via SW)

• HIL, Hardware in the Loop Validation; - Fast execution test

- Functional Validation
• Test on track, prototype validation. - Low Cost
Data Analysis

Hardware in the Loop

Table 2 shows advantages and drawbacks of the three validation - Control Tuning

methods. HIL iteration - Fault Injection

- Fast Execution Test - FDIR checking
- System Validation
Table 2: Advantages and drawbacks - Medium Cost
Data Analysis

Test on
SIL HIL
Track Test on Track
Test on Tarck
HW - Long Execution Test
Enviroment Simulated - + Real ++
Real - Prototype Validation
- High Cost
Data Analysis
Test Flexibility High + High + Low -
Data
Low - Good + High ++ Figure 4: SIL, HIL, Test on Track iteration phases
Reliability
Timings and
Low ++ Low + High -
costs
Test
SIL
High ++ High + Low -
Repeatability Software in the Loop validation method needs a platform to
Scene Low High
simulation
No limits ++
limits
+
Limits
- simulate manoeuvres and fault injections.
Operator This platform is made by:
High ++ High + Low -
Safety • Vehicle Model;
• Brake-by-Wire System Model;
The choice of a validation method depends on the validations • Fault Injection Generator Box Model;
process goals. Figure 4 shows the iterative steps used in the Vehicle model used in our Simulation in the Loop is a
validation processes. functional modular model for control design purpose.

Software in the Loop Simulation: it’s the first and the more
frequently used method since does not need the actual
Hardware. It’s useful in the preliminary phase when hardware
and architecture is not yet defined. Through this analysis is
possible to explore different architectures and hardware
solutions and debug control software on a PC platform.

Hardware in the Loop: It needs the complete hardware of the

system, but it is possible to check the actual behaviour of
hardware and software. It is possible to simulate a lot of
dangerous scenarios without any risks for people and things.
While the system is the actual one, vehicle and operating
Figure 5: Vehicle Model Library
condition are emulated by a virtual model.
Changes in system architecture are still possible without the Main vehicle parts are Vehicle body, Chassis and suspension,
complexity of an intervention on the real vehicle. Tyres, Engine, Driveline (Figure 5).
As well as the mechanical part, the vehicle model is completed
with the sensors and communication network models (CAN-
Test on track with Prototype: It needs the complete Prototype Bus, TTP-Bus, …).
with complex acquisition systems. Cost and time for preparing
this phase are generally high and represents the last step in the Brake-by-Wire model includes (Figure 6) :
system development . • Four electromechanical unit including:

5 5 Copyright © 2006 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a

 BRAKE
INPUT CONTROL

OUTPUT
DIAGNOSIS

Figure 6: Brake-by-Wire Model

- Brake Control Unit; the ECU controlling the

calliper;
- Electro-mechanical Brake; the electro-mechanical
brake elements (electrical motor gear and ball
screw);
• Vehicle Control System ECU;
• Power Supply System;
• HMI, command brake sensors;
• Time Triggered and CAN communication net.
Each system ECU contains the Software to be tested:
• VCS control software (Vehicle Layer);
• Corner Control Software (Local Layer)
Figure 6 shows where the control software are inserted.
The code is checked by simulating:
• Normal Status; no faults present;
- All Control Functions are checked.
• Recovery Status; at least one fault present;
- Diagnosis, Validation time, Recovery action are
checked.
HIL
The HIL system includes the vehicle brake-by-wire system, the
real time computer and the vehicle model, the same used in SIL
validation.
Different from a conventional bench tester which lend itself
better to test static or state driven scenarios, the HIL allows
testing dynamic scenarios. This kind of simulation require a
careful synchronization of major signals (such as vehicle speed,
steering wheel angle, engine speed, yaw rate, and lateral
acceleration, etc.) and can be performed by means of the real
time vehicle model. The HIL approach offers as well the
capability to execute ECU dynamic tests with real time
feedback signals for any close-loop controllers.
Guided by the graphical user interface, calibration and test
engineers can easily specify test events such as lane change
manoeuvres, step or ramp steering manoeuvres, slalom steering,
braking under split-µ conditions, driving on a fixed path, or
using measured signals, such as steering wheel angle, and
vehicle longitudinal speed, as vehicle inputs. These definitions

6 6 Copyright © 2006 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a

 Real Time Simulator User Interface (1) Real Time Simulator
1 2 Standard dSpace µ-autobox
Real Time Vehicle Model (standard
modeling used in control development and SIL)
C-CAN vehicle network emulation
I/O software emulation interface
Bench auxiliary managing

(2) User Interface

Custom Interface in Control Desk for:
• signals acquisition
Test Bench Hardware • system monitoring
3
Signal analysis by Matlab tools
Sensing of
physical BBW Sensor (3) Test Bench Hardware
feedback Emulator Sensing of physical feedback (Forces);
(Forces) BBW sensors & command emulation;

(4) Hardware In the Loop

Component/System to be analyzed:
Brake By Wire System

Results and Key Features

• Control software testing with “Hardware In
the Loop” technique to reduce system
development time
4 • Fault injection capability to develop/verify
Hardware In the Loop system safety

Figure 7: Brake-by-Wire HIL Bench Model

can be stored, recalled, and combined with other events so that - Interface devices from Hardware in the Loop to
a whole suite of tests can be run using the automated testing Real time software (i.e. Brake Force Sensor);
features of the HIL. At the end of these phase the engineers - Interface devices from Real-Time Software to
have grown a deep knowledge on brake by wire system and they Hardware in the Loop (i.e. Wheel Speed Sensor
can precisely plan the final track tests Emulator);
While the tests are running, interactive signal analysis as well as - Brake Request Emulation.
real-time vehicle animation are available to monitor and • Data computation and visualization:
evaluate the experiment. - Experiment panel built with dSpace Control Desk
- Matlab
The HIL method has allowed to validate control software on
brake-by-wire hardware. In this way all the brake-by-wire
system are tested in an environment similar to real one The HIL Benchmark phase
test bench designed for the brake-by-wire control software
validation is composed by: One of the goal of the Brake-by-Wire project is to develop a
Brake System at least having the same features and the same
• complete Brake-by-wire system with all the
performances of the traditional Electro-Hydraulic Brake
components, power system and communication
System.
net;
In order to objectively classify its characteristics a braking
• Real-Time simulation model, the key enabler for
system has to be probe in a large panel of tests. Furthermore, if
the HIL virtual vehicle simulation is the real-time
is needed a comparison with other similar system a strong
simulation hardware.
repeatability is mandatory. For these tasks HIL is most suitable
The CRF Brake-by-Wire HIL bench test utilises as
approach. Using the same virtual vehicle and the same group of
real time processor a dSpace Micro Autobox
manoeuvres it was possible to compare Brake-by-Wire system
fulfilling the following tasks:
with the traditional one. To do that a HIL bench with the
- Vehicle Model calculation;
standard electro-hydraulic brake control hardware has been
- Vehicle CAN network emulation;
built (Figure 8).
- I/O analog and digital management;
- sensors emulation;
• Bench tools:

7 7 Copyright © 2006 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a


Figure 8: Electro-Hydraulic HIL Bench
The following example shows some tests on the standard
electro-hydraulic HIL simulator .
In the Figure 9 is presented a braking maneuver in µ-jump
condition.
Figure 9: Braking on µ-jump friction
The Figure 10 shows how EBD works during a braking
maneuver when ABS is in fault (Wheel Speed LHF Sensor
switched off).
The Figure 11 shows how EBD works during a braking
maneuver with a double fault of the two rear Wheel Speed
sensors (Wheel Speed LHR and RHR Sensors are switched off).
Although EBD is ON (is possible to see an initial modulation
on the rear axle), electro-hydraulic modulator can’t avoid the
blockage of the rear axle.
These examples shows how is easy to simulate a lot of scenarios
to check system functionalities using HIL method.
8 8
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a
Figure 10: Braking with ABS OFF and EBD ON
Figure 11: ABS OFF – EBD ON – Double Fault
FAULT INJECTION APPLICATION
Fault injection procedure consists in a sequence of tests where
predefined failure modes are injected into the system. While
applying the faults it is verified the correctness of detection and
recovery action.
FMEA defines:
- methods for injecting faults;
- diagnosis subset that must be activated by the fault
- item identification (if possible)
- recovery to be taken (timings and system state
evolution towards safe state have to be defined as
well)
In order to speed up data post processing, software tools have
been developed which automatically acquire data, comparing
actual state with FMEA expected results
Fault injection approach was used both in SIL and HIL phases.
Copyright © 2006 by ASME
 During SIL development phase, algorithm correctness is The following example shows a Fault Injection test on the
checked by simulating fault events in input variables (out of Brake by Wire HIL simulator . A breakage in the Rear Right
range, drift, intermittent value…). In this way, a functional fault EMB force sensor is simulated.
injection is performed. As shown in the Figure 10 after a validation time the Rear
Figure 9 shows a Software Fault Injection application in the Brake shut-down itself according with fail safe requirement.
triple redundant validation of the brake sensor. Sensors signals
and status pass through the Fault Injection Box where are added
offset or noise. The outputs are connected to the diagnosis
block.

SENSORS SIGNALS
SENSORS
STATUS

BRAKE SENSORS
FAULT INJECTION VALIDATION BLOCK
BOX

FAULT
PARAMETERS

Figure 12: SIL - Fault Injection Box Figure 13: Rear Right EMB behaviour

During HIL development phase, a step ahead is performed: Vehicle behaviour is analyzed during the transition from normal
verified software from previous phase is coupled to the status to recovery status.
hardware which mainly consists in ECUs, sensors and
actuators, in order to test the correct system behaviour on a real
bench which is just one step below the final vehicle set-up.
Here, fault injection is focuses onto the hardware: electrical
faults (open circuits, short circuits to ground and power supply,
…) are injected into the system and the hardware behaviour,
together with software fault detection capability is considered
(verified).

Once the list of faults has been defined, developer must

consider the method to be used to make a perturbation of the
system with faults: with SIL, this is just a definition of a test
pattern for the inputs or the introduction in the Matlab
simulation environment of virtual boxes which interrupt
variable flow or force desired values onto the signals as well.

When considering HIL, such virtual subsystems provide the

basis for the design of the so-called Fault Injection Boxes; the Figure 14: Wheel Speed Measurements
latter behave as gateways on the wirings close to special points,
such as ECUs connectors, actuators connectors, sensors
connectors. In normal condition the harness is completely
working, but user can easily force electrical fault by acting on
the boxes.

9 9 Copyright © 2006 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a


Figure 15: Vehicle Behaviour
CONCLUSION
A safety process for developing control software for safety
critical application has been presented.
The main elements include:
• analysis using PHA, FMEA, and FTA methodology to
identify the best configuration for production intent , to
define architecture and safety requirement,
• V-cycle method to design architecture and function of
the control software,
• control software validation and certification using
Software in the Loop and Hardware in the Loop
methods with fault injection tests to obtain a safe
software for test on track.
• track test with a prototype for a final on road
verification and for a subjective control tuning.
REFERENCES
1. A.T. van Zanten, et al : “Simulation for the
Development of the Bosch-VDC”, SAE Paper
No.960486;
2. A.T. van Zanten : “Bosch ESP Systems: 5 Years of
Experience”, SAE Paper No.2000-01-1633;
3. K. Ahlström, J. Torin, P. Johannessen, “Design
Method for Conceptual Design of By-Wire Control:
Two Case Studies”, Proceedings of the Seventh IEEE
International Conference on Engineering of Complex
Computer Systems, Skövde, 2001, pp.133-143.
4. H. Kopetz, M. Braun, C. Ebner, A. Kruger, D. Millinger,
R. Nossal, and A. Schedl, “The design of large real-
time systems: the time-triggered approach”,
Proceedings of 16th IEEE Real-Time Systems
Symposium, 1995, pp 182 -187.
10 10
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/esda2006/71295/ on 04/10/2017 Terms of Use: http://www.asme.org/a
5. G.J. Rushton and A. Zakarian, “Modular Vehicle
Architectures: A System Approach”, Proceedings of
INCOSE 2000, Minneapolis, July 16-20 2000.
6. H. Kopetz, “Should Responsive Systems be Event-
Triggered or Time Triggered?”, IEICE Transactions on
Information and systems, Vol. E76-D No. 11,
November 1993, pp. 1325-32.
7. K. Ahlström, J. Torin, and R. Johansson, “Future
Electrical Flight Control Systems: Analysis of
Distributed Architectures”, Technical report No.99- 25,
Department of Computer Engineering, Chalmers
University of Technology, Göteborg, Sweden, 2000.
8. A. T. van Zanten, R. Erhardt, G. Pfaff, “The Vehicle
Dynamics Control System of Bosch”, SAE paper
950759 (1995).
9. The Math Works Inc. “Using Simulink: Modeling,
Simulation, Implementation”, 1999.
10. Bakker, E., Nyborg, L. and Pacejka, H.B. “Tyre
Modeling for Use in Vehicle Dynamics Studies.” SAE
Technical Paper Series, Paper No. 870421, 1987
11. Quan-Zhong Yan, John M. Williams, Jim Li, “Chassis
Control System Development Using Simulation:
Software in the Loop, Rapid Prototyping, and
Hardware in the Loop”, SAE paper, No. 2002-01-
1565.
12. Klaus Lamberg, Peter Wältermann,"Using HIL
Simulation to Test Mechatronic Components in
Automotive Engineering", dSPACE GmbH, Munich,
15/16 Nov. 2000.
13. Jonner, W.-D.; Winner, H.; Dreilich, L. and Schunck,
E.: Electrohydraulic Brake System – “The First
Approach to Brake-By-Wire Technology”, SAE
960991, Detroit, 1996
Copyright © 2006 by ASME