🐘 Phase
All releases are only valid if in writing with associated
documentation and signed off by authorized parties.
Upon completion of the TestCar qualification testing
including E/E Sub-System(s) and achievement of
the performance and safety strategies, such as fail
safe, safe live, and functional safety for series
production release, the vehicle manufacturer confirms
in writing the suitability for use of the item with
its hardware and software elements for electrical
assistance of the Steering System with level 2 of
automatic commanded steering functions [ACSF].
Type approvals are valid for all legal requirements,
of the intended worldwide sales markets. Hereby it is
proved that the specified E/E Sub-System conforms with
the legal regulations of the countries e.g. German such
as §29 StVZO regarding proper and safe installation and
functionality to operate the vehicle during its live
cycle including regular regular inspections. An approval
master list includes all valid legal requirements of the
countries. The content of the list is basis for official
legal approval documents and showes the latest maturity
level where legal requirements have been completely
planed, provided and implemented.
For failure prevention and vehicle reliability, all design
phases and manufacturing/assembly processes of all
involved supplier are organized in such a way to ensure no
complaints (= zero errors) while the vehicle is supplied to
the dealer organisations, and hereafter to the customer.
Note
Functional Safety is based on established technologies & best
practice and allow to review/audit safety without restrictions.
The E/E Sub-System is designed for the required service life
and will not lead to malfunctions or safety-related interferences
or to a shortening of the intended service life. If a malfunction
nevertheless occurs, the failure mode leads to an unproblematic
failure pattern in the vehicle and is clearly recognizable and
controllable for the driver regarding ISO26262 hazard analysis,
risk assessment and (A)SIL ratings.
a) If a person is injured or an object is damaged due to the
failure of the vehicle, the CarMaker is obliged to compensate
the injured party for the damage caused. The obligation period
is 10 years from the serial delivery of the vehicle that caused
the damage.
b) The suppliers obligation to compensate for an item with its
components is excluded if the damage was caused by the design
and/or manufacturing/assembly of the vehicle in which the item
with its components was installed or by the CarMakers instructions.
c) The injured party shall bear the burden of proof for the type
and form of the defect that caused the damage.
d) If the CarMaker has not officially released the vehicle for
the series delivery market and/or it can be ruled out that the
vehicle did not have the defect causing the damage when it was
delivered by the CarMaker to the series delivery market, the
CarMaker shall bear the burden of proof for the type and form
of the defect causing the damage.
Subject : Reduce Worldwide CO2 & NOx Emissions
Because the functionality on this Item and its Elements
can have an effect on the Emission Behavior of the car
(e.g. automatic engine start-stop function (MSA) or energy
recuperation in electric or hybrid vehicle version), the
the E/E Sub-System(s) are considered as OBD relevant as
defined by California Air Resources Board and U.S. Federal
OBD Regulation with diagnostic trouble codes DTCs.
Confidence Level
The following overviews deal with the steering system, focusing on the E/E Sub-System
as a Electrical Power Steering (EPS) incorporating an electrical permanent magnet a.c.
motor, while mechanical steering sub-assemblies comprises only a few sections.
In simple terms, the EPS Level 2 type steering depends on the desired Driver input and
• Hand Wheel coupled to Column
• Steering Sub-Assembly coupled to the EPS
• Steering Gear that converts the rotating column to a translational steering rack movement
• Specified Suspension with longitudinal hub force per 3 acting tire/road surface forces
• Road and Environmental Conditions
• Surrounded by Traffic Scenarios
Service Life
The EPS, Sub-Assemblies and Parts have to be durable for
• 15 years
• 300000 km
• 8000 operating hours
In addition full functional capability for
54000 cycles (MSA restarts)
without any maintenance (Engineered for 300000..400000 cycles)
Maintenance Intervals
The warranty time is
• 2 years after sales (failure propability: 0.348 cases per 100 vehicles for World Wide Market)
• 4 years after sales (failure propability: 0.960 cases per 100 vehicles for NAO Market)
Note
Cover breakdowns during 24 months operation after sales (propability of 0.96 cases per 100 vehicles)
The availability of tools and methods required for service & repair are defined in Service Levels.
Safety: Opening of the item and its elements leads to destruction of the E/E Sub-System.
EPS Simplified Graphical Overview
Mechanical Steering Sub-Assemblies
Hand Wheel
The driver command input is a small rotational torque to the hand wheel.
Column
The steering column connects the hand wheel and the steering sub-assemblies to modify in combination with the
E/E Sub-System the angular position of the wheels/tires. A small rotational torque is applied to the hand wheel
with a small angualar rotation of the column. For both mech. inputs transducers are required to provide the
necessary elec. input signals of the E/E Sub-System.
Steering Gear Ratio (C-Factor)
Constant ratio Cconst (°/mm) or variable ratios C1 (°/mm) and C2 (°/mm). Pinion used for column angular rotation to
translational rack displacmenet. Provide angle accuracy of ± 1° @ { 0, ± 360, ± 720 }° pinion angle in relation to
column angle α. α ≤ ± 1.5° according the linearity of gear rack position per pinion angle over life time. Max ± 5.0°
deviation between straight ahead column angle α and zero position for variable c-factor(s).
Rack and Tie Rods
These elements are the mech. forward path with the steering gear to the wheels.
Axle
The power drive shafts and the steerable front axle with suspension connected to the steering assemblies is the
transmission path between controlled system (car) and the wheels/tires.
Wheels/Tires
The tires with there road surface contact area is the transmission path to the vertical, lateral and longitudinal forces
E/E Sub-System external Assemblies
Torsion Bar with Transducer
The torsion bar with its transducer is used between manual mechanical torsion input to the column and electrical
output to the E/E Sub-System
Absolute Angulare Column Position with Transducer
The column angle transducer measures the angular displacement of the Hand-Wheel and provides an absolute
elec. value of the steering angle over the totoal angular range of the steering column (multi turn type sensor)
as an electrical output to the E/E Sub-System
E/E Sub-System Item as column drive or/and rack drive
This element is the elec. forward path from the transducer elec. signal to the syncronous a.c. motor output
which is that quantity or condition which the E/E Sub-System applies to the steering sub-assembly
Note for Safety Measures
Cooling air and/or heat sheets help to cool down undesirably high ambient temperatures affecting the
E/E subsystem with permanent magnet a.c. motor power output.
E/E Hardware Elements
All µC-I/Os are encapsulated in drivers as Basis SW-Components for adjustment and parametrisation. The Memory,
Register and Processor of the µC-ECU includes and processes different activated functional tasks and interrupts
and sends there computation message results per serial high-speed data bus interface to the motor drive with
its µC-Motor, Gateway-Driver and Logical-Bridge that activates the motor power output.
Features of µC
• stabilized 5v supply voltage input
• common ground
• I/O-Unit
• Control-Unit
• Processor-Unit
• Memory-Unit
• RTC 20MHz (Run through 20,000,000 cycles per second)
• port features for external RTC (redundant)
• port features for external Memory (redundant)
• port Redundancy features
• ports for Sleep-, Inhibit, Disable-, Enable-, WakeUp- feature
• ports for special I/O Channel features
• Pulse Width Modulation Module (PWM)
• General Purpose Timer Units (GPTs)
• Analog/Digital Converter (ADC)
• Digital/Analog Converter (DAC)
• Asynchronous/Synchronous Serial Interface (ASC)
• Interrupt Controller
• Peripheral Event Controller (PEC)
• Synchronous Serial Interface (SSC)
• port features for Watchdog
• Capture/Compare Units (CCi) (compare functional outputs & compare with preset value)
• CAN Tx/Rx
• FlexRay Tx/Rx
Note
Diagnostic coverage and safety mechanism are all provided in the safety concept.
A propability metric (PMHF) estimation is required for safety related logical &
discrete parts used on the circuit board(s).
EMC protection (ESD & EMI)
All electromagnetic compatibility (EMC) requirements of ISO 11452-8 regarding immunity to
magnetic fields for Road Vehicles and there component test methods for elec. disturbances
from narrowband radiated electromagnetic energy shall be taken into account an integrated
into the samples which going to be built and operated in the vehicle within the project
phases.
Quality per EMC Lab Tests
Test include emitted interferences such as narrow-band and broad-band interference
@ max. 17dB .. 10dB .. 3dB above limit values such as documented in e.g. ISO 7637
& DIN 40839 with line filtering of each terminal line to safegard specified safety goals.
The EMC test reports, clearly can be assigned to the individual sample with its EMC
features and corresponding integration level and EMC disturbance levels to
ensure proper signals.
Enable Secure and Safe Access to Resources
A reference voltages received per µC input pin is converted per A/D port of to the
CPU-Unit, that first checks whether the data can be stored to the register or data
memory cell
Ensuring that a process has exclusive access to resources such as to a return value
of a method
e.g.
•-> µC In-Pin_x (A)
•-> µC Port_x (A/D)
•-> Algorithm
•-> Port_y (D/A)
•-> µC Out-Pin_y (A)
is a very important functional safety requirement for the code piece of the RTOS.
Note
The code piece of the RTOS contained in the Register or Memory adress areas are linked to
the µC Processor-Unit, that controls HW-Tasks and enables each necessary I/O port.
Prevent Dead Locks with priority inheritance protocol
Avoidance of inconsistencies is handled with a special protocol that increases the priority of
a process for the access duration of the resource if there is a possibility that a process with
a higher priority could try to access the same resource.
E/E Software Elements (Control Algorithm)
Declare & Specify EPS SW-Groups with Input and Output Values
There are three cascaded Application Groups controlled by a Platform Software and monitored by a
Safety Module specified in a SW-Specification.
• Input Group with SW-Components
• Function Group with SW-Components
• Output Group with SW-Components
• Standard SW-Platform (Autosar) as RTE with Base SW-Components
• Safety Modul with SW-Components
Control Flow and Signal Flow are designated as data States and data Variables entering and leaving
Groups, RTE with RTOS and Safety Module.
• Input and Output States as Control Flow
• Input and Output Variables as Signal Flow
Selection and Processing of States as Control Flow
• Start State, were the Control Flow is at the beginning
• Control Flow can be at a Source State or at a Destination State
• Transition-Conditions that have to be fulfilled to change from a Source State to a Destination State
• Transition to a Destination State with Entry Action, internal Static-Action and Exit-Action
Nodes and Branches (sources, sinks)
Each input and output interface interface can be seen as a node. The control forward path is a path
from the input node to the output node. A feed-back path returns back to the input node.
Modules or classes can be seen as functional branches with there parametrization PAR1,2,k..n.
• source of a Module, Class or Statemashine as a node with outgoing branches
• sink of a a Module, Class or Statemashine as a node with incomming branches
Example: Signal Flow
Inport Signals to one Node per multiple branches
Output signals from one Node per multiple branches
Input and Output Data Types
• Literal (string that is interpreted as a value, e.g. logical expression)
• Variable
• Parameter
• Constant
• Enumeration
• Curve
• Map
• Array
• Timer
• Counter
• Comparator
• .....
Communication with NetWork Nodes
Communication Services using CAN and/or FlexRay Drivers to communicated
with other Nodes connected to the NetWork(s).
Timing
Variables and states are handled by
• Moduls with running processes between receive messages & send messages
• Classes that are calling methods between input & return values within a process
Time Critical Sampling Rates
Internal running processes or methods are processed by the µC in at least t ≤ 2 ms.
None Time Critical Sampling Rates
NetWork Messages are available in at least t ≤ 100 ms with the exception of the message frame
for the Vehicle Speed Vvehicle, that need to be cyclically received every t ≤ 20 ms. Necessary
control states are imported or exported every t ≤ 10 ms. Typically XCP application events to read
out data from the memory and send per CAN ervery t = { 2ms, 5ms, 10ms, 20ms or 50ms }.
With regard to the procurement of the safety relevant E/E Sub System,
a preliminary safety concept/measure (see ISO 26262 Part 3) resulting
from a hazard analysis and risk assessment [HARA] is required.
With a hazard and risk analysis (HARA), the
• severity level [S],
• controllability [C]
• exposure [E]
of a hazardous driving event are estimated.
A risk matrix with these assumptions results in a safety integration level
(A)SIL for the causative fault mode
All Safety Goals (SG) are derived from this.
All functional safety requirements (FSR) result from the defined safety goals.
Within the HW/SW architecture, functions with different (A)SIL ratings
are independent of each other. For example, a parent element with its
QM rated sub-element is independent and can not influence or disturb
other safety-relevant sub-elements within this parent element.
The item and its elements must be durable (MTBF, FIT). The probability of a
failure per hour (PFH) for often used operating modes or continuous safety -
related process needs with diagnostic coverage also provides an (A)SIL.
Failure probabilities and diagnostics of hardware circuits (BOM) for signal &
control flow processes.
(A)SIL D
PFH < 10 FIT = 10E-8 failure per operating hour
for infringement of an (A)SIL D rated element
(A)SIL C
PFH < 100 FIT = 10E-7 failure per operating hour
for infringement of an (A)SIL C rated element
(A)SIL C
PFH < 1000 FIT = 10E-6 failure per operating hour
for infringement of an (A)SIL B rated element
(A)SIL A
PFH < 10000 FIT = 10E-5 failure per operating hour
for infringement of an (A)SIL A rated element
All functional safety requirements result from the defined safety goals.
The delivered item and its elements are verified and validated to be
protected against the failure modes identified in the preliminary
hazard analysis and risk assessment [HARA]with help of Simulation Tools.
Verification is performed using appropriate and standardized methods,
such as an FMEA to show how elements can fail and evaluate the effects,
and an FTA to investigate undesirable events and determine their causes.
Dangerous Single Point Failures (SPF) within an FMEA are failures that
directly resulting in infringement of a Safety Goal(s) and for which the
diagnostic coverages is less or equal to 90 %. Such a single point failure
cause the malfunction of the entire system. Multiple point failures (MPF)
only violate a Safety Goal(s) if several independent failures occur.
Following Safe Failure Fractions SFF required to detect SPFs:
For (A)SIL D rated element > 99% for diagnostic coverage
For (A)SIL C rated element > 97% for diagnostic coverage
For (A)SIL B rated element > 90% for diagnostic coverage
Following PFH for SPFs:
For (A)SIL D rated element < 10E-10 failure per operating hour
For (A)SIL C rated element < 10E-9 failure per operating hour
For (A)SIL B rated element < 10E-8 failure per operating hour
Following Failure Fractions SFF required to detect MPFs:
For (A)SIL D rated element > 90% for diagnostic coverage
For (A)SIL C rated element > 80% for diagnostic coverage
For (A)SIL B rated element > 60% for diagnostic coverage
The preliminary safety concept/measure is extended to include
specific needs during all project phases.
Electrical Power Steering (EPS)
The E/E Sub-System (Item) with its HW- and SW- Elements mainly controls per µC-Motor the elec. motor drive
and provides per µC-ECU different customer functions while taking into account the sensors and construction
of mechanical steering components and there installation into the vehicle.
A small manual rotational torque applied to the Hand-Wheel is amplificated electrically, resulting in a rack force
adequate to modify the steering output, the angular position of the front wheels. The manual hand wheel input
torque applied by the driver (Nm) @ different vehicle speeds (km/h) affects the value (%) of the controlled
output torque (Nm) of the rotor shaft coupled to the Steering Sub-Assemblies. Hereby the actuating set value
is the algebraic sum consisting of Hand Wheel Torque plus elec. assist Torque that depends on vehicle speed
and on some desired input signals provided per µC-ECU to manipulate the actuating set value such as for
• steering effort and comfort
• steering direction
• reduce steering disturbances
• degrations
Functional Exceptions
However, there are following control exceptions :
• does not compensate a constant pull in the axle
• does not compensate a laterally inclined road
• does not compensate imbalanced wheels
• does not compensate imbalanced brake discs
Use Cases for assist level 2
Following main 3 Operators
• Driver per Hand Wheel to steer the car, in accordance with the activation of the elec. motor assist
• Different organisations that use garage mode session (manufacturing, work shops)
• Permitted Safety Level 2 Position-Control-Functions
Following overview of forward path in a simplified graphical presentation :
a.1) Some Automation Assist Topics
With conditional automation of Driver Assistance Level 3 the car steering will be controlled partial in
combination between automation functions or external overlays and human biological system. For
automation @ lower vehicle speeds or for position loops (e.g. lane passing on European High Ways
@ higher vehicle speeds ≤ 130 km/h), specified functional safety relevant transducers are required
as input nodes, that will replace the human biological node.
With high automation of Driver Assistance Level 4 the car steering need not use the human biological
system. Alternative sensor(s) e.g. optical or other technology such as laser or radar have to comply
with all required safety relevant function of monitoring the input and output. This level 4 car reducing
hand wheel and pedaling assemblies Note: No Release for autonomous lane passing on European
High Ways for Vehcile Speed ≥ 130 km/h).
Example for High Automation with Image Processing & Sensing
The traffic light controls the flow of traffic by successively confronting the vehicles in a particular
direction (e.g. north-south) with red (stop) and then a green (go) light. When one direction has the
green light, the cross traffic in the other direction (east-west) has the red light. The Pedestrians, the
traffic and the entire surrounding situation influence the operation of the vehicle. A highly automated
driver assistance system primarily takes on the task of avoiding a collision and at the same time stopping
or steering the car safely into the green lane road travel direction under very difficult traffic conditions.
Some tasks of a speed governor independent of the drive type (engine, hybrid, e-motor)
• Approaching a manual or automatic set target speed
• Keeping the target speed constant
• Manual or automatic changing the target speed
• Acceleration/Deceleration Tasks
• Consideration of other Sub-Systems (transmission, brake, clutch, steering, distance, ...)
• Consideration of the Environment via obtics (pedestrians, traffic, surrounding situation, ...)
• Turn Off and Resumee in all operation conditions
Vision SW
There are different concepts for integrating vision processing into the Sub-Systems. Essential elements
are Neurons that act as Nodes and pass on information depending on Input Data of the Scene. The nodes
are belonging to different Layers, such as a Input Layer, several Hidden Intermediate Layers, and Output
Layer. Nodes that belong to different layers are connected to each other through Synapses that provide
the data from lower nodes to higher nodes with there higher learning levels until finally a result is
available within the output layer (Deep Learning Process).
The goal is to dedect the image and to understand its content. Deep learning algorithms decompose images
into small interpretation elements and learn to recognize the content. In this process, the model needs
a time to learn to interpret points of the scene with the required accuracy and the correct probability.
Hereby the model learns from updates over time, and becomes closer and closer to the real image and to
the expected interpretation. In an End-To-End approach, a model processes all input data and generates
an output data as a set value or state required for a control action. To simplify the analysis, verification,
validation of the model, another approach splits the entire vision processing path into several functional
SW - Modules that can be individual approved.
Classify Accuracy of the DNN Model
The accuracy represents how close the model comes to the real image and expected interpretation. Deep Neural
Network (DNN) algorithms are considered to be error resistant. However; HW faults can lead to degradations of
the accuracy resulting in wrong outputs.
Vision HW
A type of integrated circuit (IC) chip with memory in CMOS technology designed to accelerate image
processing tasks and includes an interface for receiving data from an optical device. The integrated
circuit having both image processing and image sensing circuitries on the same die. Newer typ devices
integrate the image sensor and parallel processors, and eliminates the serial processing needs within
older types. The output message of the image process is an information based on the scene capture by
an qualified optic.
For the conversion of the wavelength originating from the radiation spectrum into electrical signals,
there are various detectors that work similarly to photodiodes. A single element of the detector matrix
represents a scene point, where one element integrally picks up a part of the scene imaged on it by the
optics and converts it into an elec./digital signal corresponding to the average value of the radiation
flux from that part of the scene and transmits it to the vision IC for comparison with a model.
Memory
Running Deep Neural Networks (DNNs) requires a lot of memory size, that stores millions of trained network
parameters, input activations, and other intermediate processes. The memory architecture consists of cells,
I/O Interface and Error Handling. To meet extreme computational requirements of DNN algorithms, a number
of accelerators chips have been designed, that use external and local memories. Parallel pixel processors are
used to accelerate low level image processing such as background subtraction, image filtering and thresholding,
to speed up and enhance the image details of interest by a simple arithmetic logic unit (ALU) for a simple
algorithm and a local memory with a small storage capacity. Here the image processing as well as resolution
depends on the number of memory processing elements (PE) that can be placed onto the cell matrix area. The
goal is to have a compact memory structure.
Qualification
To investigate the functional safety of the autonomous driving Sub-System (ADS) installed in the vehicle, faults
are inserted into the running forward path of the image processing application to determine
• Likelihood (operation @ error event)
• Probability (possibility of error occurrence)
• Error Handling & Prevention by the (A)SIL rated Safety Path
All functions of the device are verified and validated by (A)SIL qualified test tools.
a.2) Assist Level 2 Topics
The Feedback of the actual Car-Heading-Direction to the driver is necessary for a Level 2 type steering
The lateral force is perpendicular to the tire/road contact area while the resulding longitudinal force
points into the direction of travel (yaw vector). The negative feedback path received by the driver is
necessary in order to reduce the torque to zero when the desired wheel/tire angle position and/or travel
direction (yaw vector) have been reached.
a.2) Response of the Vehicle (Check TestCar responses with steering angle changes)
The response of the vehicle is the Heading Direction as a Function of Time, following a steering command as
an input signal under specific operation conditions such as the actual driving maneuver, weight, environment,
road surface pertubations, overall kinematic and dynamic transient stabilities. Steering Control Attemps and
there time responses of the TestCar (LabCar) has to ensure the specified Failure Tolerant Time Interval (ms)
for a Failure Mode that causes a serious functional safety problem.
a.3) Control and Feedback Paths
During the develoment phases, the Motor-Drive-Assembly have been adjusted to optimize the Motor-Assembly
design to meet required nominal motor torque ouput curves over speed. Parametrization for the Stator and
Magnetized Rotor Assembly have been tuned to reach optimal motor performance using 8bit A/D-Input and
A/D-Feedback signals such as for
• Column torque value (Nm)
• Column abs angle value (°)
• Rotor rel. angle value (°)
• Rotor turn counts value (_)
• Phase current value (A)
Motor Speed
The speed can be change by vary the frequency of the alternating voltage provided to the 3 phase clamps.
Following Simplified Illustration of steering and Star connected 3-Phase A.C. Syncronous Motor assemblied into the E/E Sub-System
a.4) Control Block Terminology
Following blocks between the input and the output including the Star connected 3-Phase A.C. Syncronous Motor.
Human Biological System
The Eyes represent the summing point of the Human Biological system to set the desired Road(Lane)-Heading.
Hereby the eyes perform a safety relevant function of monitoring the output of the actual driving situation.
With this information the driver applies a small manual steering torque to the Hand-Wheel in order to comand
a specified maneuver of the car.
Human Actuating Signal
The control signal (Error-Signal), is the algebraic sum consisting of the manual steering torque to the Hand-Wheel
Plus or Minus the actual Car Heading Direction.
Transducer (Torsion-Bar)
The manual steering torque applied by the driver to the column via Hand-Wheel is measured by a Torsion-Bar which
converts the mechanical input signal into an electrical input (reference) signal, which is the actual manual driver
torque input for the E/E Sub-System.
Electrical Error Signal
The control signal (Error-Signal), is the algebraic sum consisting of the electrical input (reference) signal from the
transducer plus or minus the actual feeback signal.
Controlled Output
The electrical error signal is introduced to the forward path of the Item and its HW/SW Elements and affects
the controlled angular position of the wheels.
Steering Angle
The column angle transducer measures the angular displacement of the Hand-Wheel and provides an absolute
value for the steering angle over the totoal angular range of the steering column (multi turn type sensor). The
previous stored absolute column and rotor angle data bits are read from coresponding memory cells and compared
with the actual angle provided by the angle transducer after switching terminal IGN Clamp 15N = ON (Wake Up Mode)
and is used to derive the angular column velocity (°/s).
Disturbances
All Disturbances are undesired input signals to the car steering, which affecting the required car direction
output (yaw vector).
The nominal rated a.c. motor power output is available with ambient temperatures between -40 °C and 120 °C. If never
the less a degradation is perceivable by the driver, this is indicated per warning object such as a MIL, to require a
significantly higher manual Hand-Wheel torque input to adapt the rack force for a necessary steering maneuver.
Note: Disturbances or Human Failures acting onto the vehicle and can cause a serious functional safety problem must
be taken into account as much as possible (see ISO26262 Work Products).
a.5) Onboard Electrical Supply Power Management (High Current)
The onboard electrical supply power management controls the power input between different nodes conected to the vehicle
network. It is used as a power source to generate the required low current voltage for the printed circuit board and the
high current switched clamp voltage Udrain at the 3 terminal clamps of the synchronous a.c. motor.
a.6) Principle Synchronous A.C. Motor with Permanent Magnets
Current and excitation field together generate the motor torque. The a.c. motor uses permanent magnets imbedded into the rotor.
The permanent-magnet a.c. motor design is paired with this specific motor drive connected per high current clamps to the stator
windings. The stator segments are elements that consist of wrapped conducting wire. L(H) and Ra(Ω) represents the inductance
and the resistance of this conducter. The flow of current through phase windings create magnetic fields in the stator segments with
a flux linkage to the rotor iron and the permanent magnets, which also create a magnetic field.
The magnetic torque is generated by the interaction between both fields and aligns the magnetized rotor pol pair to the stator
pol pairs. Changing the position of the stator pol pairs with respect to the magnetized rotor pol pairs causes the rotor to align
with the stator field. Due to the strong flux linkage, the magnetized rotor pole pairs are physically rotated synchronously with
the pseudo-rotating stator pole pairs. The rotor design with its permanent magnets determines the electromagnetic and mechanical
properties and thus the Torque-Speed-Characteristic-Curve of the synchronous a.c. motor output power.
Back e.m.f. (counter-electromotive force with Load Angle α)
The stator rotating field and the rotating rotor field are not completely in balance. A back e.m.f. (counter-electromotive force)
is built up in the stator amature, which counteracts to the applied conducter voltage U when there is a relative motion between
stator pols and rotor pols. Therefore, a revers voltage Eb can be induced within the stator segment windings whenever the
magnetized rotor turns. The specified geometric of the rotor determines the shape of the back e.m.f. voltage Eb waveforms.
As the load on the rotor shaft increases, the magnetized rotor pols fall back by some phase angle which depends on the amount of load
to be met by the motor. This so called load angle α is an indication of the stator amature torque transmitted to the rotor shaft @ a
synchronous speed (rad/s).
If the motor runs at idle it has low losses with a low amature current and a conductor input voltages U ~ Eb. If the rotor shaft
increases load, then the rotor pol pair will further fall back with a power loss, indicated by the load angle α. The resultant amature
voltage E which is the vector difference between conducter input voltage U and Eb is increased and the the amature draws more
Amps to keep up the mechanical output torque by the rotor shaft. The amature current I (A) is obtained by dividing the resultant
amature voltage (U - Eb) by the actual impetance Zs of the stator segment amature.
Load Angle
• Load angle α small: Low Load @ synchronous speed and no output torque loss
• Load angle α large: High Load @ synchronous speed while stator amature draws more Amps
Coordinate Systems for Stator (α and ß vector axis) and for Rotor (d and q vector axis)
The a.c. motor operates with 3 sinusoidal input signals. This results in complex relationships that are simplified by vectors.
The vector quantities are each defined for two specific coordinate systems. One for the stator field and one for rotor field.
The 1st coordinate system is oriented towards the fixed stator rotating field. It described two vectors that are at a right
angle (90°) to one another. Both fixed vector axes are labeled α and ß. The 2nd coordinate system is oriented towards
the rotating rotor field of the magnetized rotor. Both rotating vector axes are labeled d and q.
Rotor flux and torque
Following rotating vectors
d-axis (flux-Data)
Rotating flux vector is aligned along the rotor pol pair (Nrotor,Srotor) on which Rotor-Flux is generated within the conducter.
jq-axis (Torque-Data)
The torque vector leads the flux vector electrically by 90° and is the axis on which magnetic torque is generated by interaction
between stator field interacting with the rotor field.
Magnetic Saliency (d/q)
Magnetic saliency describes the relation between generated flux-data on the d-axis per generated torque-data on the q-axis.
The relation varies depending on the position of the stator pols to the rotor pols, were maximal magnetic torque occurs
per 90° (1/2π) ahead of the the magnetic flux @ 0 .. 180° (1π) .. 270° (3/2π) .. 360° (2π) .. ).
a.7) Net Mechanical Power Output corresponding to Iq (q-Vector)
The basis for the elec. output torque (Nm) at a certain rotor speeds (rpm) is related to the current consumption
I(A) per motor phase. These physical values I1,2,(3) have been pre-validated and converted to digital flux data
(vectors Id) and digital torque data (vectors Iq) describing a nominal output torque curve to be loaded
as a reference table into a specified Flash-EEPROM-Area of the µC-Motor.
The 3 alternating phase voltages applied by the bridge (MOSFETs) is controlled by this Feed-Back-Control, that uses
the phase current I(A) as feed back path that is measured per shunt and hereafter linked into the rotating rotor
coordinate systemdq with
• Id as actual rotating d-Vector of the rotor flux
• Iq as actual rotating q-Vector of the rotor torque provided to the drive shaft that is coupled to the gear actuation
The processor points to a data bit of the reference table copied to the RAM and compares this data to the actual Iq feedback data.
From this the quantity of the actuating signals U1,2,3 are computed and send to the Gate-Way-Driver.
The Gate Way Driver converts the actuating control signals U1,2,3 into sampled gate signals (PWM) applied to the bridge
(logic power stages), that quickly switchs On or Off the high current clamp voltage Udrain at the 3 phase clamps to generate
the current through the stator windings, creating the magnetic field within the stator that interacts with the magnetized rotor.
a.8) Bridge (MOSFETs) as Logic Power Stage
Each of the 3 terminal clamps of the synchronous a.c. motor can be different signed (+,-). In total, there are 2³ = 8 different high
current voltage combinations that can be applied to a terminal clamp. The used 6 options are illustrated in below table and define
the PWM Switching States from S1 to S6. The rating of the activated phase voltage is calculated with help of the MOSFETs, Diodes
and stabilized clamp voltage Udrain (Kirchhoff equation).
The Gate Way Driver quickly switch high current voltages u1,2,3 between several on/off States within a time interval T.
In the next column, all conductor voltages for
• uα = R · iα + dψα / dt
• uβ = R · iβ + dψβ / dt
are determined taking into account the fixed stator coordination systemαβ.
Thanks to the rapid timing and precise resolution it is possible to reach nearly all resulting
voltages u for an actual angual position within the switched hexagon area by various combinations
of switched states during the time interval T.
To avoid a short circuit between an upper and a lower switch, both must never be switched
on at the same time. Both signals are each shifted by a separation time Ts which ensures
that one is safely turned off before the other is turned on. Limited On and Off times Tmin
leading to limitation of the voltages within the switched hexagon area by various combinations
of switched states during the time interval T.
The resulting voltage u for an actual angual position is transfered to a switched hexagon area of
the rotating pol coordinate systemdq.
Different ud and uq voltages are transfered for actual positions of the rotor.
Following theoretically equations of the conducter voltage due to the magnetized rotor :
• ud = R · Id + dψd / dt − ω · ψd
• uq = R · Iq + dψq / dt − ω · ψq
a.9) Protection
The design and the operation of the motor drive and the a.c. motor assembly group has to protect against following errors:
Voltage Error
Voltage errors of uq and ud depends on the clamp voltage Udrain, current vectors Iq and Id, rotor
angle α, angular velocity ω , temperature ϑ and aging of the motor sub-assembly. Voltage errors
during the time interval T have been taken into account in the motor drive design.
Oscillation Error
As load is increased the rotor pols fall back in phase by the load angle. If the drive shaft is suddenly unloaded, the
speed can increase to find its new load angle that corresponds to that load and vice versa. The magnetized rotor
oscillates what have been prevented with the motor drive design and rotor design.
Saturration and magnetic field Error
By strengthening the magnetic fields, the a.c. synchron motor can temporarily increase the torque. A reduced magnet
field will limit the torque and can cause the rotor to run at higher speeds with more current consumption Idq. The
rotor iron is important to link stator and rotor fields. The permanent magnet slots geometrically reducing the available
iron to link stator and rotor fields (air gab losses). Only so much flux can be linked to the size of rotor iron to generate
torque. Eventually, the iron will saturate and no longer allow flux to be linked. The result is a limited flow of current
through phase windings.
Demagnitazion Error
A magnetic material can become demagnetized if there is excessive deformation of the material, if the operating
temperature is too high, or if it is affected by EMI. The magnetic properties of the permanent magnet material
have to be validated and stay constant during live time.
Electrical Error
Protection against electrical disturbance by conducting and coupling, electrostatic discharge ESD, or by electrical
disturbance by undesired electromagnetic radiation, EMI.
Environment
The environment has a significant impact on the steering sub-assembly and its operation with undesired signals
caused by low or high temperatures or friction or others. This affects the entire control and feedback path and enter
all steering parts by intermediate points with a summation with the steering output as the angular position of the
front wheels.
Combining physical model with embedded software
Based on the physical functional vehicle requirements, a Model is created of the forward- and feedback- paths,
that consist of graphical block diagrams and/or state machines representing the technical control processes.
Embedded Software
The forward and feedback paths of the E/E-Sub-Systm with its Function Frame that includes various SW-Components as
modules and classes that can be independent of the target µC implementation and therefore be tested off-line.
An off-line experimentation can be performed on a PC without the connection of any Hardware-Platform.
Following Example of specified SW Design structure in a simplified graphical presentation
Software Design Steps
The functionalities of modules are specified with processes and the functionalities of classes with methods. In
addition, the real time requirements and the integration requirements for the target µC are implemented. Then,
the model-based design is converted into standard C source code (Ansi C) and optimized with different test models
in the loop (MiL) to analyze whether the individual SW-Components work in the intended way. All instructions are
executed and tested. The test coverage in terms of functional safety must satisfied the risk assessment (A)SIL.
General Topics
• define the interfaces for the processes i.e. receive messages and send messages
• define the interfaces for the methods i.e. arguments and return values
• creating the processes of modules (Off-Line-Experimentation-Environment)
• creating the methods of classess (Off-Line-Experimentation-Environment)
• creating RTOS task scheduling and priorities (On-Line-Execution with Hex-File running on µC in Real Time)
After that the whole application code is compiled as binary object code. It is debugged and linked with standard
platform code as a µC specific program implementation. This is followed by verification and validation on the HW
platform. This proves that all functional and safety requirements have been implemented. The LabCar (HiL) and the
TestCar validation checks, whether the E/E Sub-System meets all vehcile performance and safety requirements.
Realtime Software
Software or Firmware applies to all programable components such as for µC, ICs or ASICs as well as for qualified SW-Tools
used during development phases (e.g. Behaviour Modeling Tools, OS-Modeller-Tool, Application Tools, Debugging Tool, Target-
Compiler, Emulator, Test-Tools, LabCar, .., etc.) or series supply (e.g. Diagnostic Scan Tools, Programming Tools, .., etc.).
The modular software design brakes down the SW-Components (Data Base) into different modules and classes which have been
developed according to the recognized design methods of software engineering (V-Model) and making use of the automotive
functional safety integration levels (A)SIL according ISO26262.
All SW-Componenents (Data Base) of the modular software design have been functionally off line tested, to prove that all
designed SW-Units work in the intended way as standard C source code.
That is where processes (SW-Units) have been assigned to
• Task-Configurations
• Task-Scheduling
• Task-Priorization of Interrupts
for the real time operation needs.
Herafter the standard C source code have been compiled to Binary Object Code and linked to specified µC Program Code with
resources, that provide real time operation conditions, such as for the µC in/output ports, the activation and configuration
of time segments of different processes per tasks or the access to memory allocations.
Then the compiled and linked binary program code has been loaded to the µC-Memory via boot loader software to test if every
instruction operates without errors on the running program.
The software design activities have been performed by different people and global teams or groups and carried out parallel or
at different times. The quality and safety of the software design has been controlled and confirmed by independent acessors
during official audits.
SW-Quality as required by MISRA regulations for standard C and C++ code.
a.1) Associated Programable Hardware Elements
A part is a HW component that is treated like a HW unit when assembling a programable µC. HW units can be composed of
individual HW-Elements. However, these elements are only released in conjunction with the HW unit. The µC is composed of
the following internal HW units:
• Control-Unit
• Processor-Unit with integrated circuits for Arithmetic-Bitwise-Logic and Memory-Unit
• Memory-Unit (16-Bit Data-Registers, NVRAM, Flash-EEPROM)
• Input-Unit for 16-Bit Input Data per serial high-speed bus
• Output-Unit for 16-Bit Output Data per serial high-speed bus
• RTC 20MHz (Run through 20,000,000 cycles per second)
Signal flow or data flow per components of the µC
• Ports
• Pulse Width Modulation Modules (PWM)
• General Purpose Timer Units (GPTi)
• Analog/Digital Converter (ADC)
• Digital/Analog Converter (DAC)
• Interrupt Controller
• Peripheral Event Controller (PEC)
• Asynchronous/Synchronous Serial Interface (ASC)
• Synchronous Serial Interface (SSC)
• Voltage regulator (Watchdog)
• Capture/Compare Units (CCi)
• CAN Tx/Rx
• FlexRay Tx/Rx
Drivers
All accesses to the above components of the µC are encapsulated
in SW-Components (modules, classes) and are described briefly below
• Digital In: read digital inputs (analog inputs can also function as digital inputs)
• Digital Out: set the digital outputs
• Analog In: read analog inputs
• PWM Out: set the sampling rate and frequency of PWM outputs
• PWM In: read the sampling rate and frequency of PWM signal applied to a port
Note
The µC operates with sufficient frequency (RTC). Communication between logical
elements are realized via high speed internal interfaces. The program code incl.
RTE with RTOS is loaded into the non-volatile memory (e.g. EEPROM) via a boot
loader (max speed up to 25Mbps). Steering functions utilize 70 % of memory.
In case a programmable hardware-unit had not been compatible with a newly compiled and linked binary program code (e.g. wrong
SW-Unit), the lates executable program code of the previous integration step has been further used until the current compiled
and linked piece code (SW-Units) have been compatible with the hardware.
a.2) Program Code Version ID as Content of SW-Delivery
Each supplied Version of the entire binary Program Code could be identified by an unambiguous ID. This ID with revisions
have been illustrated within the Hex File Header Name and readable per Diagnostic Service.
All activities in the context of the binary program code configuration have been subdivided into following type of versions :
• NetWork Communication Version (CI binary program code)
• Version for Basic Control Function (BCF binary program code)
• Versions for Release (RV binary program code)
• Version for special Releases (SV binary program code)
a.2.1) Network Communication Version (CI-Version)
The CI-Version is used for the HiL or TestCar preparation of integrated E/E Sub-Systems with a specified
integration level ( I-__ ). The integration check showed that all SW-Communication-Components have been
completed and communicating correctly together. Network Communication with all E/E Sub-Systems have been
realized via there Network interfaces. The CI-Version only provided SW-Components used with bus comunication
via a specified Message Catalog. With the CI-Version the entire Function Frame with all SW-Components did
not had to be completely fulfilled.
Following SW-Elements have been supplied with a CI-Version :
• Prototyping Design Version/Variant
• Message Catalog
• DTCs
• ODX Data Containers (SWFL, CAFD, BLUP, FLUP, BTLD, FLSL, SVT) and TAL
A sufficient number of E/E Sub-System B- and C-Samples with there HW-Elements have been built to test
NetWork message comunication between notes on Hil TestRigs. TestCars to validate CI-Versions have
been only tested by test drivers with appropriate training.
Approvals for CI-Version typically 7 weeks prior to a Road Approval.
a.2.2) Version for Basic Control Functions (FB-Version)
The FB-Version have been used to test Basic Control Functions and Safety Functions.
The FB-Version including following :
• Prototyping Design with Real Time Behaviour Version/Variant
• Instructions for the calibration of processes (application handbook)
• Info about DownWard or BackWard Compatibility (SW-Components that are compatible with previous Program-Versions)
Approvals for FB-Version typically 5 weeks prior to a Road Approval.
A sufficient number of B- and C-Samples have been built.
a.2.3) Version for Releases (RV-Version)
Version for formal approved driver assist type Levels (0,1,2,3,4 or 5)
All SW-Components have been formal approved after every program code instruction has been executed without errors.
Herafter used to validate the entire program code incl. data per TestCar (TestLab).
All Basic Control Functions (FB) and NetWork Communication (CI) have been available.
Following with the Release Version :
• SW-Specification (Function Frame)
• Error Handling (monitoring, diagnostics and safety mechanisms during code flow)
• Safety Concept with Functional Safety Integration according ISO 26262
• Complete Design Tools Version/Variant
• Complete Test Suite Version/Variant
• Compiler & Linker Version/Variant for Target µC incl. Memory
• Compiled and Linked Program Code (HEX-File Version/Variant)
• Data File (ASAM A2L Application File Version/Variant)
• Configuration (XML File Version/Variant)
• Diagnose (ODX ASAM MCD 2D File Version/Variant)
• Boot Loader Software
• µC (HW-Units incl. Memory) Version/Variant
• Memory resource allocation (EEPROM, RAM, Flash, NVRAM; run-time memory and register utilization)
• HW-Periphery (with external Memory and RTC) Version/Variant
• MISRA report
• Qualification Reports with Recommendations
A sufficient number of C- and D-Samples have been built.
a.2.4) Version for Special Releases (SV-Version)
Informal checked SW-Version for a quick solution of problems.
Since the development of the SW-Components have been an iterative process,
the program code have been revised several times before a complete and error
free SW-Version could be achieved for an official formal approval.
• Compiled and Linked Program Code (HEX-File Version/Variant)
• Data File (ASAM A2L Application File Version/Variant)
• Configuration (XML File Version/Variant)
• Diagnose (ODX ASAM MCD 2D File Version/Variant)
Approvals for informal bug fixing typically 24 Hours prior to a Re-Test.
a.3) SW-Architecture
With the compiled and linked program code the desired SW-Architecture is also implemented.
The compiled and linked binary Program Code includes following High & Low Level Software Layers :
• Application Layer as high level software
• Runtime Environment (RTE) with real time operation system (RTOS) and Basis-SW (BSW) as Low Level Software
The high and low level compiled and linked program code with default data has been loaded into the EEPROM
allocation (memory addresses) via a specified Boot-Loader-Software.
From the actuating input signal, the µC decodes binary program code pieces per binary-decoder to a controlled
ouput signal, applied to the HW-platform, of which the synchronous a.c. motor output is to be controlled.
Following overview of Application- & Platform Layers in a simplified graphical presentation :
a.3.1) Modules containing Processes
An Entity is an Object that exists within the complide and linked Program Code. Data can be stored with reference
to this Object.
A Module appears only once in the Program Code (1 instance) and contains one or more object typs.
The Object does not have to do anything; it just has to exist as a code piece within the program code.
An OBJECT KEYWORD can be used together with a number of identifiers for various commands.
In example an activated global object named OBJECT DTC with a certain ID could run a process that opens a window
with displaying a malfunction indication text to warn the driver such as PLEASE NOTE ELEC. STEERING ASSIST REDUCED !
The functional implementation of an SW-Module is known as a Process (functional piece code with assigned data).
Each single process is implemented by exactly one functional Unit or C-function.
Processes are the activated code pieces of a SW-Module that descibes the functional internal behavior of a SW-module.
The SW-Module may contain one single Process, as well as a larger number of Processes.
Inter-Process Communication is done per Receive-/Send Messages.
From or to a Module, the message is simply a variable that can be read or written to, or both.
a.3.1.2) Runtime of Processes
The activation of a Process within a module is done by setting an Event.
A Task refers to a Module-Event and contains a directory structure with a number of processes. With regard to the
piece code, these processes are the smallest units that can be activated by the TASK during runtime.
All process actvations during runtime are managed by the Real Time Operation System (RTOS SW-Comonent),
which starts processes per Tasks and either
• let a process (piece code) run until it ends
• or interrupt a running process (piece code)
All processes within one single Task are computed sequentially.
Processes can be activated concurrently, by mapping them to several Tasks.
A process contains at least two Event Points that are considered per RTOS configuration :
• 1st Process P#1 ENTRY-Point according to Task A
• 2nd Process P#1 EXIT-Point according to Task A
During a runtime the RTOS Task Trigger Mechanism, can be
• periodically-based
• application-based
• state-based
• safety-based
If the Process is activated by a Timing_Event, the Process will run periodically with a given time period.
If the Process is activated by a Received_Event, the Process will run after a message has been received.
With help of the RTE-Configuration all Process Events (Activation Interfaces) of a Module are mapped to Tasks.
Due to the reason that an SW-Module is not dividable, all its internal processes are activated by Tasks that are
triggered per RTOS are integrated to one target µC (binary code pieces stored in Registers or Memory-Units and
computed by the Processor-Unit)
a.3.1.3) Process Input/Output Handling
Modules with implemented processes have access to messages or global variables.
An indirect exchange of information between processes is possible by using Function with
there parameterization. But in this case, the data consistency must be ensured !
An exchange of information between moduls and there processes activated by a task can also
be handled by messages.
The data that need to be pass within and to and from a module is contained within an Objects that are named as MSGRECV and (MSGSEND).
All receive messages (MSGRECV) that are required to be read are received @ the beginning of a process computation.
A module instance has its own set of messages (type implicite, type explicite) that are needed to run the processes
called by a task triggered by the RTOS.
a.3.1.3.1) Data Consistency with Messages and Data In-Consistency with Global Variables
Messages or Global Variables can be used to pass data from one module to another module.
a.3.1.3.1.1) Global Variables
A Global Variable can be passed between many modules that do not have to be directly
connected to each other. This means, that Global Variables of a module can be acessed
by other modules within the program code. Global Variables can even be passed between
modules that belong to other program flows on the data bus. A Global Variable can be set
by a program flow, and be read by another module in any other program flow.
a.3.1.3.1.2) Implicit and Explicit Messages Implementation
A Message can only be passed from a module to another module to which it is connected.
Therefore, messages were preferred instead of global variables.
Following overview of Implicit Message Handling in a simplified graphical presentation :
The real time operation SW-Component creates a copy of each received messages msg (x) before
the process computation of the task is started.
At startup, process P#1 of task #1 copies its receive-implicit message (msgrec) msg : x = -1
into the private received message copy msg (1) : x = - 1. All subsequent read operations of
this original receive-implicit message for task #1 computations are performed with a private
copy msg (1) : x = - 1.
Even if the process P#1 is interrupted by the task B with an interupt routine, that changes the
contents of receive-implicit message (msgrec) msg : x = -1 to x = - 2, this change does not affect
the process P#1 of task #1.
Therefore, process P#1 is guaranteed to be unaffected during the entire computaion up to the
result y = -1 provided in send-implicit message (msgsend) that can be passed from a module to
another connected module
Due to the high rate of message transactions per second, the efficiency of the receiving messages
there process computation and sending messages is very important. In addition, the memory requirement
for message copies must be kept as low as possible, since memory handled by a Control-Unit is limited
and memory is still an important cost factor.
In more complex applications there is a transaction rate of 100.000 messages per second, which cannot be
achieved if the message receive and message send handling takes between 15ms..20ms..100ms which results
in a Processor-Unit load of 15% to 1000% for the messages communication only !
The number of running tasks receiving data from memory partitions and sending data to memory partitions,
that can be handled by a Control-Unit is limited compared to the possible number of process computations
within the Processor-Unit which rate is roughly 1HW / 10SW.
Memory Size and Runtime Optimization
The specified I/O Implementation of receive messages and send messages have to take into account if a copy
need to be available for a correct process computation.
Following optimization methods to reduce message copies and runtime:
In-line-expansion of receive, computation and send operations (source code analysis @ design phase)
Simplifying operation assignments will reduce the message length and therfore its runtime e.g. msg (1) for
process P#1 of Task A with a typical execution runtime of less than 1ms. The target compiler translates
in such a way that an pre-known equation content is copied msg (1) and is inserted directly to the running
process computation, and does not call the equation per sub-function (or nested procedure or subroutine).
Specify necessary message copies to protect against data inconsistency
Data inconsistencies can only occur between Receiver (Rx) and Transmitter (Tx) and vice versa. Copies of
messages therefore need to be provided only in these two specific cases which results in a significant
reduction in memory size and runtime.
1st Rx of a msg can be interrupted by Tx of the msg
2nd Tx of a msg can be interrupted by Rx of the msg while Tx does not declare msg as non-interruptible (atomic).
Pooling (collect) messages copies to reduce execution time
The sequence of processes within a task is executed sequentially, it is possible to pool all necessyry receive
messages into a local message area and all necessary send messages in a global message area during a sequence.
If a message is received by all processes (P#1, ..., P#x) in the sequence of a task A, it is sufficient to use
only one msg (1) copy and have this copy shared with all processes activated by the task which will save undesired
message copies and reduce runtime.
Note
By using above optimization methods, the estimated high rate of up to 100,000 message transactions per second
can be approximately reduced to 1/3 (30,000 message transactions per second) with lower Processor-Unit load.
a.3.1.3.1.2.1) Implicit Module Messaging for Real-Time-Control Data between µC
Implicit Receive Messages and Implicit Send Messages are used for time critical control
data, where fast internal data bus speed with low latency are paramount. Serial high-
speed interfaces of programable hardward are coupled by an synchronous serial data bus
interface. The software supports the data bus ports and the I/O ports of the programable
hardward.
Latency is the amount of the time for
• process activatation time
• response time for the process calculation
• time to communicate from one controller to the another controller
With the Implicit Message Format the Module Output Source of the µC-ECU-Code-Run creates a
connection with the Module Input Sink of the µC-Motor-Code-Run. The Implicit Bus Data to be
exchanged between both controllers is identified, when the communication connection has been
established. At this time the Bus Data is implicitly defined by a Connection ID.
For the implicit messaging, the µC-ECU that initiate motor drive command data is referred
to as master, and the µC-Motor that responds to this data bus communication is referred to
as slave.
a.3.1.3.1.2.2) Explicit messaging for Diagnostic-Services-Exchange with the Network
Explicit messaging treats each communication between notes connected to the NetWork with
a requests and responses. Each explicit send message contains a request information that
the receiving note has to respond to.
Each request includes a
• Connection ID
• Source Address
• Destination Address
The explicit messages are transmitted per Transmission Control Protocol (TCP), and because every
message includes a connection ID, a source address and a destination address, explicit messaging is
less efficient than implicit messaging, but it offers a higher flexibility.
A bus note that initiate an explicit message is referred to as a client, and a bus note that responds
to this communication referres to as server. Explicit messages can be sent by the client at any time,
and the server can respond when it is ready. Therefore, explicit messaging is used only for NetWork
data that is not time-critical, such as diagnostic service data or configuration service data.
• Explicit messaging that need to be synchronous
Example : A state message of a process (= piece code) which is needed on different bus notes, must
be synchronously with the specified CAN or FlexRay-Message-Slot, so that there can be a controlled
constant time-off-set (constant latency) causing less jittering.
a.3.1.4) Specification of Modules for Control Forward Path and Feedbacks
- Activation of processes (task scheduling)
- Have access to messages & passing messages (implicit & explicite)
- Processes computation (Algorithm described with SW-Units)
a.3.1.5) Specification of Classes (e.g. standard used mathematic expression from Libraries)
Classes are categorized as public or private and are characterized with there nested methodes such as
• Class : Encapsulated mathematic expressions that is called with arguments (= parametrization)
• Class : Memory-Container that contains read and write data
The use of a method is an Instance of a Class, which is independent from a Task and can be called several
times at a specified step of a running process which uses the return value of the method for computation.
For reasons of data consistency, the classes used here do not support real-time interprocess communication
via messages. Therefore special methods are provided to realize direct access e.g. to a data container. This
mechanism allows to use classes to read and write from a data container without using copied input variables,
such as copied messages for the process computations.
Methodes are activated code pieces of a SW-Class, descibing a standard mathematic expression or can consist
of a specified control operation to be performed on an input to yield the output, represented by a graphical
block diagram of a data flow e.g. for µC In-Pin (Analog)->Port (A/D)-Algorithm->Port (D/A)->Out-Pin (Analog)
A sequence call generally consists of three fields
• Name of the process calling
• Name of the method called
• Number determining the order of the called method in the calling process
a.3.1.6) Assigning a value to a return value
A special case is that of assigning a value to the return value to a process. Logical expressions are connected
to the control flow return values. The logical expression depends on the result and activates a return flow branch.
The following States for a returned value are used within the Input-, Control- and Output-Group
• If…Then
• If…Then…Else
• Switch
• While
a.3.2) Standard Low Level Software
AUTOSAR and OSEK are automotive low level software platforms.
One of the difference between the two platforms are the incompatible Network Management SW Modules.
However, the problem has been solved in the past applying AUTOSAR NM SW Modules on OSEK SW Modules.
AUTOSAR provides a standard Interface Syntax and Semantics with the Realtime Environment (RTE) incl.
a real time operation system (RTOS) that connects to the high level Application Layers with there
specific SW-Components.
AUTOSAR consists of low level Basis Layers (BSW) with a stack of SW-Components as a standard core that
is unaware of what specific high level application layer is provided and is functional safety approved.
The Communication Services using CAN and FlexRay Drivers to communicated per NetwWork to other nodes.
Further a Virtual Functional Bus (VFB) with communication paths to the Basis Layers, allows separation
between Standard-SW-Components and the infrastructure of the nodes for pre-design and testing.
Following OSEK & Autosar overview in a simplified graphical presentation :
Run Time Criticalities of Runables (Modules, CLasses) controlled by standard layers
In the software design phase, the Run Time Criticalities of Runables have been investigated
for the forward path design which is the transmission path from the actuation signal (driver
Hand Wheel torque input) to the controlled output (angular position of the wheels/tires) with
all feed-back path designs.
Standrad Layers for all E/E Sub-Systems connected to the Vehicle Network(s)
Layer 1
Layer 1 (Physical Layer) is the lowest layer that
provides mechanical, electrical and other functional
scopes to transmit and receive signals. The code of the
physical layer is specified for a selected communication
type such as CAN, FlexRay, Wireless, etc.
Note
To implement a reliable and a robust communication that is
protected agains potential functional failure modes leading
to the loss of communication by electrical disturbance by
conducting and coupling, electrical discharge [ESD], or by
elec. disturbance by undesired electromagnetic radiation,
[EMI] a detailed interface documentation and tested spec.
is furnished.
Note
Layer 2
Layer 2 (Data Link Layer) to ensure reliable and error
free transmission by dividing the bit data information
into blocks (message frames) and adding checksums as
part of the channel coding to detect incorrect frames
and to regulating access to the item. However, the 2nd
layer does not provide for a renewed request for a
defect message frame. A data flow control enables the
item to dynamically control the speed at which the other
side is allowed to transmit frames (Logical Link Control
and Media Access Control).
Layer 3, 4, and 5
Network, transport, session layers take care of process
communication between two or more nodes with Remote
Procedure Call Protocol [RPC] and provides services
for an organized and synchronized exchange of data
in order to deal with faults or breakdowns in the
session and similar problems. At restart or check
points a session can be synchronized again after
an transmission ERROR without starting again from
the beginning.
Layer 7 Application Programable Interface (API)
Layer 7 (application layer via instant messages) provides in/output functions for the specified
E/E Sub-System Application and realizes the link between High Level and Low Level Software part.
The Platform Software have been implemented as per Autosar-Release 4.2 or higher
(Automotive Open System Architecture).
a.3.2.1) Autosar Implementation Conformance Classes
The programmable HW and its SW-Elements use an Autosar stack in accordance with Implementation Conformance Class ICC3.
There are following Implementation Conformance Classes :
A) Integration-Conformance-Class 1 (ICC1)
An ICC1 cluster offers a SW-Component-Interface (SW-CI) and/or an Network-Interface (NWI) and provides an interface to
the boot loader. All SW-Components are handled as a black box.
B) Integration-Conformance-Class 2 (ICC2)
An ICC2 clusters offers a SW-Component-Interface (SW-CI) and related SW-Components (SW-C).
C) Integration-Conformance-Class 3 (ICC3)
ICC3 is the highest level of granularity for the Real Time Environment with all SW-Component (SW-C) and there SW-Component-
Interfaces (SW-CI) as well as Real Time Operation System. All SW-Components are handled as a white box.
a.3.2.2) Basis Software Layer (BSW)
Basis Software Layers (BSW) of the Autosar Standard Core providing low level interconnected SW-Components. The BSW is a stack
of SW-Components such as
• Real Time Environmental (RTE) with Real Time Operation System (RTOS)
• System Services and there drivers
• Memory Services and there drivers
• Communication Services and there drivers
• I/O HW ports and there drivers
• Complex drivers
To allow to have a Autosar Standard Core SW-Architecture integrated in all programmable HW (nodes) linked to the NetWork, the
BSW is configured with Autosar XML-files provided by the CarMaker. Test-tools have been used to proof the implementation and
functiopnality of the BSW-Layers.
For pre-design and pre-tests a Virtual Functional Bus (VFB) for simulated communication paths between SW Components and NetWork
allows the separation between these SW-Components and there HW-Infrastructure. That means more specifically that they are unaware
on what programable hardware (Node) they run.
With each integration step (I-xxx), peer reviews of the BSW-Layers and there functional content were carried out. Non-compliance
or derivations with the Autosar Standard Core requirements have not been accepted. If nevertheless code pieces could not be
implemented as Autosar standard services and drivers they have been implemented as Complex Drivers.
a.3.2.3) Runtime Environment (RTE)
The Autosar Runtime Environment (RTE) provides a standard application interface syntax (API) to the high level specific
Application Layer. The computation processes of unique modules are activated by a real time operating system (RTOS) per
Task events. The specified algorithm of processes (= functional code pieces) is part of the high level functional system
design and the activation of theses processes (task scheduling) is part of the RTOS design.
Application programmable interface (API) in accordance with the Autosar Interface Spec. for Inside Communication mechanism.
SW-Components for communication services as communication gate for all messages between different notes connected to the
NetWork. The HW-Abstration Layer with drivers have been configured to operate with FlexRay and CAN_FD protocolls.
a.3.2.4) Real Time Operating System (RTOS) with Kernel
The Low Level Software includes the Real Time Operation System with a Kernel, that includes a task trigger mechanism.
The kernel is a module that presents the interface between SW-Components and HW-Units & HW-Ports. The RTOS is
located in a memory area and receives control time from the Processor-Unit to control runtime activities such as
• Start & Exit the program run
• Task Scheduling for processes during program run time
• Handle memory access
• Handle inputs & outputs
Tasks
A task is a sequence of functional program code pieces (processes) that are activated by the RTOS. The smaller
part of the functions (modules, classes) are typically event-driven. The majority of activations of functions are
related to specific times. These time-controlled activations by RTOS can be divided into fixed periodic activations,
that remain unchanged throughout the operation, and variable or random activations of functions. Different priorities
and different attributes are assigned for activated tasks incorporated in a task scheduling, e.g. whether they are
cooperative or preemptive, whether they are cyclical or whether they are started at an external event or only initially.
The RTOS is configured on basis on following task topics :
• operating mode
• activation
• priority
• attribute
• scheduling
The Task Scheduling is pre-specified and configurated with an OS-Modeller-Tool (qualified per ISO 26262).
Processes
A process contains a piece of binary code that runs sequentially over time. During the program run time
a task activates one or more related or independent processes within a module. Processes are grouped
into a task and executed in the given order. Processes have receive_messages as inputs or send_messages
as outputs. These messages are used for direct data exchange between tasks. The process reads its input
data on receipt of corresponding receive_message at the beginning of an activated task or interrupt, then
it processes the data and on computation completion it provides the send_message as an output result.
Temporary and State Variables as well as Global Variables as Messages
Values can be stored and can be read as Variables for calculations. Temporary Variables are encapsulated
data of a process, i.e. access and visibility only as long as the process is active. State Variables are also
encapsulated data of a process, but save their data between an interrupt and read them at reactivation of
the process. Processes are invoked with there task and communicate by means of messages. They are
necessary for communication between processes and other moduls. All received messages are copied to protect
against wrong data exchange between concurrent processes. They behave like global Variables that can be stored
and read from the register or memory unit. In example within the processor-unit, the Receive_Message is used to
process the actual manual torque input data and use the Send_Message to adjust the motor drive output data. If
an interrupt service routine occurs, the critical messages that need to be protected against inconsistency are
saved so that they can continue to work with consistent messages after the interruption.
Parameters
In contrast to Variables or Messages, parameters are read-only values. They are fixed within the program code
and can only be changed from outside during runtime, e.g. adjust PID for new overall gains in the equation via
a calibrate session, but they cannot be overwritten by a running process computations.
a.3.2.5) µC-Task Priority Scheme
The µC-Circuitry is suitable to perform all runtime processes as binary program code pieces.
Hereby task scheduling with different priorities are taken into account.
Input & Output Assignments
The compiled and linked binary program code (Hex-File) supports the µC-ECU I/O ports
and allows the flow of data from and to the µC-Motor and other internal nodes per
data bus messages. Further allows communication via CAN and FlexRay Drivers from and
to the vehicle NetWork.
Control Unit
The Control-Unit manages the flow of I/O data as well as the acces to the Memory-
Unit and the Processor-Unit how both shall respond to instructions. It instructs
the Memory-Unit to provide data from an specified address areas to the Processor-
Unit and controls running tasks.
Arithmetic Logic
The Processor-Unit includes an Arithmetic Logic as integrated digital circuit.
The Inputs and Outputs are Data Words. The Arithmetic Logic performs integer
arithmetic and bitwise logic operations as well as status information. It may
generate constant operands or may receives dynamic operants from the register
or from the memory. The operation results and status informations as outputs
may be stored into the register or into the memory.
Memory Unit
The compiled and linked binary program code is loaded into memory as data bits. To
activate data for specific operations, they contain information about there memory
allocated address area. To store and fetching data from memory areas, the specified
addresses are calculated by special circuits that operate in parallel with other
computation cycles. Runtime Priorities between both depend on the µC-Architecture
design. For performance reasons there is a memory management unit (MMU), translating
Logical-Addresses that are generated during process executions providing virtual
memory into Physical-addresses that refers to the Memory Unit.
Drivers for I/O Components
I/O Components are adjusted by SW-Drivers (modules, Classes) and activated by HW-Tasks
to read and set digital and analog I/Os or set the sampling rate and frequency of PWM
I/Os or other I/Os of the µC
a.3.2.5.1) Priority Levels
Different Priority Levels for Cooperative Tasks and for 3 type of Preemptive Tasks are used
by the kernel for interrupt service routines (ISR). An actual task with its running processes
can only be interrupted by ISR that has a higher priority level than the current ISR. The
prioritization of HW-Interrupts is performed with help of the Contol-Unit interrupt logic.
Cooperative-Task-Changes with Lower Priorities
With a Cooperative-Task-Change, the running process PA1 is processed and during this
computation Task B will be activated. When the PA1 process finishes the computation,
it switches to Task B and the PB1 process starts its computation.
All Cooperative-Task-Changes with a different activation point and start point run on a
Control-Unit at a Interrupt Priority Level 0 for all Tasks running in the Software-Area.
With this, only SW-Tasks can be interreupted in this area with ISR prio level 0.
Preemptive-Task-Changes with Higher Priorities
With a Preemptive-Task-Change, the change to task B must occur during process PA1
in order to start process PB1.
All Preemptive-Task-Changes with process interruption will run on a Control-Unit at
a Interrupt Priority Level > 0 and are related to 3 different priority task areas.
Different Priority Areas of Preemptive-Task Types
The preemptive task area provides following 3 areas:
• HW-Tasks (In the HW Task area, only hardware related processes can be interrupted)
• Overlapping-Tasks (In the overlaid area both HW- and SW related processes can be interrupted)
• SW-Tasks (In the SW Task area, only software related processes can be interrupted)
SW-Task Interrupt Service Routines
The interrupt service routine (ISR) can be choosen for priority level 0 (Cooperative-
Task-Changes) or 1 (Preemptive-Task-Changes). The preemptive type interruption of a
process computation can only be activated on Interrupt Priority Level 1 for all Tasks
running in the Software-Area. With this, only SW-Tasks can be interrupted in this area
with ISR prio level 1.
Overlaid Interrupt Service Routines
HW-Tasks & SW-Tasks can be activated in combination by the kernel within the
overlaid area. Hereby the IRS with the highes priority level will be activated
by the kernel.
The upper and lower boundary of the overlaid area is defined by
• upper boundary by SW-Task with the highest ISR priority
• lower boundary by HW-Task with the lowest ISR priority
In example if a SW-Task is activated in the overlaid area, the kernel generates an ISR
with priority level of >= 1. If an actual running HW-Task has a higher ISR priority,
this HW-Task is interrupted and the SW-Task is processed. If the actual running
HW-Task has a lower ISR priority, this HW-Task would go on until the SW-Task and all
other actual running Tasks with higher ISR-Priorities have been interrupted
Note: In the overlaid area the kernel always executes the highest ISR priority as SW-Task.
If no Preemptive SW-Task is exists, a pseudo upper bound is created for the kernel.
HW-Task Interrupt Service Routines
Only HW-Task can be activated in the Hardware-Area. With the help of the Contol-Unit Interupt
logic, the decision is made whether HW-Tasks should be interrupted or not. The preemptive type
interruption of a HW-Task is processed with an ISR just like SW-Tasks. All ISRs remain pending
until all higher-priority ISRs have been processed.
a.3.2.6) Run Time Consumption or Latency for the Process Activatation
To operate the high level sw processes at run time, all proccesses called per tasks have been
pre-specified and pre-configurated.
With the RTOS-Modeller-Tool all Run Time Adjustments such as for
• Initialisation Tasks
• Activation Tasks
• Re-Start Tasks
• Periodically Tasks
• Alarm Tasks
• Cooperative Task Interrupts
• Preemptive Task Interrupts
• Multitasking for HW-Tasks and SW-Tasks
• Background Tasks
have been configurated and tested to handle runables with critical run time and non critical run time
Visualisation of the Run-Time situation with µC time consumption such as for
• process activatation time (ms)
• response time for the computation of processes (ms)
• time to communicate from one µC to the another µC (ms)
A distinction have been made between Gross and Net Run-Time.
• Gross Run-Time : Time between Start-Event (MSGRECV) and an End-Event (MSGSEND)
• Net Run-Time : Gross Run Time minus all ISRs during a processing
Example RTOS-Modeller-Tool
All values of the Time Analysis are stored in a specified Memory Area.
If requested per com service task the max µC-Utilization and Memory-Consumption can be provided by
explicit messages per com driver to the vehicle NetWork.
Generalized overview of realtime operation
The code for the µC-ECU and the µC-Motor and the code for the Gate Way Driver are runing in a time-discrete manner.
The output states from the gate way driver are being sent per PWM signals to the Bridge (MOSFETs) within a maximal
permitted time span T.
Delay Errors
The maximal time span T (~ 2ms or faster) must be taken into account in order to avoid time delay errors
with calculation of U1,2,3.
Following overview in a simplified graphical presentation :
Note for Integration Level ApprovalIn the implementation phase, the SW design is refined and converted into source-, object-, program-code.
The coded module-processes are first tested individually, hereafter integrated into the overall program
version/variant and realtime tested. The integration approval is intended to show that all high and low
SW-Components with Modules or Classes are complete and interact correctly.
The compiled and linked binary program code and data is integrated to the Memory-Code-Area and to the
Memory-Data-Area of the target µC.
Note for Integration Level Status
• SW-Specification (Function Frame)
• Error Handling (monitoring, diagnostics and safety mechanisms during code flow)
• Safety Concept with Functional Safety Integration according ISO 26262
• Complete Design Tools Version/Variant
• Complete Test Suite Version/Variant
• Compiler & Linker Version/Variant for Target µC incl. Memory
• Compiled and Linked Program Code (HEX-File Version/Variant)
• Data File (ASAM A2L Application File Version/Variant)
• Configuration (XML File Version/Variant)
• Diagnose (ODX ASAM MCD 2D File Version/Variant)
• Boot Loader Software
• µC (HW-Units incl. Memory) Version/Variant
• Memory resource allocation (EEPROM, RAM, Flash, NVRAM; run-time memory and register utilization)
• HW-Periphery (with external Memory and RTC) Version/Variant
• MISRA report
• Qualification Reports with Recommendations
a.4) Safety Relevant Functions according ISO 26262
SW-Components as modules with there processes and classes with there methods as well as coresponding
programable HW have been rated according ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for processes and interrupts were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SILs have been estimated from the following Risk Matrix:
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Safety Concept (ISO 26262 Part 3)
The approved Safety-Concept showes how safety related failures are detected and how there error handling
(control failure modes) safegards the specified safety goals. If an failure occurs a higher priority Task
emits an interrupt service routine (ISR) and the error handling functionality tries to recover from the
failure mode per specified safety concept.
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of hardware circuits (BOM) for signal & control flow processes.
a.4.1) Freedom from interference (FFI) according ISO 26262 Part 9
A process computation or an Interrupt Service Routine that together with other processes or nested
processes form a common functionality can only be released individually to a limited extent.
A validation in combination of all involved Tasks and there processes (SW-Elelemts) is essential
for a Functional Safety Series Release.
The ISO 26262 Part 9 guidance are of particular interest for mixed processes within one and the
same Task that contain different (A)SIL assignments for there processes.
Protect against cascading failures from processes with lower (A)SIL rating to a process with a higher
(A)SIL rating leading to the violation of the Functional Safety Requirement (FSR) of this Task.
Note
It can be an advantage to avoid raising the (A)SIL for a lower rated process to the highest (A)SIL by designing
more optimal circuits for HW/SW-Data flow and control.
Protect against cascading failures with following 2 Coexistence-Criterias (ISO 26262 Part 4)
For mixed (A)SIL assigned processes within one and the same task all processes should be rated with the highest
(A)SIL, unless the process meet the 2 Coexistence-Criterias:
1st Option avoiding raising QM to (A)SIL assigned processes
If there is a coexistence of QM assigned code pieces in combination with (A)SIL assigned code pieces within the same task,
then the QM risk level can remain with the process if the evidence is made available that this process cannot violate any
functional safety requirement (FSR) allocated to this task. This means that the QM rated process absolutely assures that its
possible Failure is independend and cannot influence or interfere with any other safety related process within this Task or
other safety related ISRs.
Otherwise, if freedom from interference can not be made available for this original QM rated process, the pice code would have
to be raised to the highest (A)SIL within this task.
2st Option for a nested Function with QM risk assignment
Only remains with QM, if evidence is made available that the functional safety requirement (FSR) for this process, cannot interfere
with any process with a higher (A)SIL assigned.
Otherwise, if freedom from interference can not be made available for this oiginal QM rated nested process, the pice code would
have to be raised to the highest (A)SIL within this task.
(A)SIL-Decomposition (ISO 26262 Part 9)
If a functional task is implemented by means of two or more independent functional processes with different (A)SIL assignments, both
have to be protected from each other by separated memory partitions (ISO 26262 Part 9).
a.4.2) Programmable Hardware Topics
The programmable µC consist of following main units :
• Control-Unit
• Processor-Unit with integrated circuits for Arithmetic-Bitwise-Logic and Memory-Unit
• Memory-Unit (16-Bit Data-Registers, NVRAM, Flash-EEPROM)
• Input-Unit for 16-Bit Input Data per serial high-speed bus
• Output-Unit for 16-Bit Output Data per serial high-speed bus
• RTC 20MHz (Run through 20,000,000 cycles per second)
Control-Unit
• Responds to 16-Bit I/O Data flow per serial high-speed bus
• Permits peripheral components to read from and write to specified memory address areas
• Activates the Processor-Unit to compute
• Instructs Processor-Unit to access specified Memory or Register Address Areas
Processor-Unit
• Receives data bits as input from specified register or memory address areas
• Perform integer arithmetic and bitwise logic operations
• Send data bits (operation results, status information) as outputs to specified register or memory address areas
Memory-Unit broken down in
• Nonvolatile Flash-EEPROM
• NVRAM
• volatile fast RAM (SRAM, DRAM)
• 16 bit Data Register (RRAM)
Note for Storage Classes
Some RAM-areas are copies of the Flash-EEPROM-area. RAM data areas can be re-fetched if data is corrupted
Storage classes (adress-areas, partitions) are assigned with the design of SW-Componenets (Sorce Code) and
compiled and linked as µC program code (target specific). NVRAMs is a relatively new type of memory that is
used as an intermediate layer between volatile memory layer and nonvolatile memory layer.
Simplified steps for µC I/Os
• Predefine Interfaces (How does the communication between peripheral component and µC takes place, port type with parameters baud rate,etc.)
• Adjust drivers for selected I/O components
• Selection of the 16 bit data with its allocated register or NVRAM or EEPROM address
• Control-Unit sents 16 bit data under this address number to receiving component per data bus
• Control-Unit converts the 16 bit data (Hex) in physical units (Volt) using a specified conversion rule
• Control-Unit sents pysical data under this address number to receiving pcb component per D/A output
Serious µC-Perfomance Issues
ISO 26262 Work Products recomend that non and safety related Tasks shall be assigned to different Memory Partions. However; the number of
memory partitions that can be controlled and processed by the µC is limited, compared to the total number of running multiple functional
tasks with there processes and ISRs (can be roughly 1HW : 10SW).
This limited µC-Performance means, that some processes that should be isolated, cannot be protected against interferences between each other.
In the case of limited µC-Performance following ISO 26262 part 9 recomendation to ensure FFI :
• Memory Partitioning not applicable for RTOS SW-Components
• FFI is not supported with Task-Scheduling
• FFI between Tasks is not fully assured
• Always highest (A)SIL assigned safety mechanism active
• SPF and LF can occure and must be investigated !
FFI Test Requirements
The Test Requirements and there Test Reports for Freedom from Interferences is high for series supply. ISO 26262 describes SW-Partitioning
as solution to ensure freedom from memory interference, which is supported by dedicated µC-Safety-Mechanism. Therefore the used µC provides
safety mechanism such as memory protection unit (MPU) to ensure Memroy FFI.
a.4.3) Memory Safety Topics
Implementation for Container Content
Individual approved units have been refined and converted into code pieces. Herafter different Data Blocks are created, combining all units
into an overall program code version/variant as HEX-File including ASAM-Default-Data for Paramterization and Diagnostics, XML-Default-Data
for Configuration as well as the standard Autosar platform code pieces. Each Data-Block declares specific code & data that is required by the
E/E Sub-System Configuration and Vehicle Configuration. With compiling and linking the desired Memory-Areas (Partitions) are implemented in
the Data-Blocks.
Integration of Container Content
There is no need to change the terminal input for flash programming. The Nonvolatile Flash-EEPROM is the main receiver for the Data Blocks.
The compiled and linked binary program code (Hex-File) is loaded per data bits into specified Flash-EEPROM-Areas (Partitions).
Session
With a Session, Data Blocks such as one SW-Unit or several SW-Units or all SW-Units can be loaded into the Nonvolatile Flash-EEPROM.
Note for special Session: In case that there is no valid session available or a mistake, the E/E Sub-System provides default assist data and
safety levels so that the vehicle remains maneuverable (special case). A DTC is set together with a yellow MIL for this default data set. No
teach in (turn count, etc.) is required.
The flash programming process exactly corresponds to one Session that references specified Data-Blocks that can be cleared or updated by means
of a re-flashing. This is followed by consistency checks that proves that the correct µC, ASIC, PIC, etc. requirements have been implemented.
The consistency check usually takes place within a AUTOSAR SW-Component as a check routine (Check_Programming_Dependencies).
Following consistency checks must be passed:
• The item checks whether all logical data-blocks stored to the memory area contain a valid signature
• The bootloder code piece provides a list of main modules and there processes as well as classes with there methods
• The bootloader code piece checks if the HW-Elements are capable to be booted with the Program Code Version/Variant
The consistency check delivers a negative-result-state (flag), if the combination HW/SW is wrong or a session for one or more HW-Elements
was not successful e.g. Data File does not fit to a certain HW-Elements. Otherwice a positive-result-state (flag) is set and the routine
sends a corresponding positive message to the programming system.
Session Time
Basis to estimate the max programming time are 10 variants per SW-Unit or process. A SW-Unit or process with variant-dependent parameters
can be flashed within approx. 30 seconds.
Following overview of different sessions in a simplified graphical presentation :
Safety Partition
• Non-safety-critical or safety-critical code pieces, that are activated by Tasks refer to as Processes or Runnables.
• The Processor-Unit runs processes simultaneous from different memory areas such as non-safety-critical or safety-critical
Activate different Partitions per Task Levels
If different processes require a safety protection from each other then they have to be placed into different Tasks per
RTOS-Kernel functionality. In example such as an Interrupt-Service-Routines (ISRs) on Task Levels.
RTOS as an adjustable code piece of the program code is responsible to manage the specified realtime activations of all HW-
and SW-Resources and have been rated according ISO 26262 Functional Safety Integration Levels (A)SIL that have been
estimated from the Risk Matrix.
RTOS code piece lenght is figgured out during the E/E Sub-System development phases and based on following features
• HW and SW Task Scheduling according priority scheme
• Inhibiting & Enabling Interrupts
• Process Activations and Time Management
• Memory and Register Partioning
• HW- and SW Resource Handling
• Error Handling
• Select desired Operating Mode
Memory Size RTOS (measured in Data Type = unsigned int = uint)
• typically 2 bytes on 16-bit µC targets
• Max possible number of access to nested resources (Data Type = unsigned int = uint)
• Required memory size to check code piece for RTOS
• Required memory size for specific target µC
Forwarth Path for Physical Atributes between input and controlled output
The transducer measures a physical attributes such as manual torque form the torsion bar and convert it into a elec. signal
proportional to the input or convert it into a 16 bit digital signal proportional to the input.
Note for Implizit Message Communication: In more complex applications, there is a transaction of 100.000 implizit messages
per second, that cannot be archieved if the send and receive operation take place between 10 ms and 100 ms such as for the
explicit communication. This results in a CPU-Load of 15 % to 1000 % only for implicit message communication.
Before a high priority HW-Task can be carried out, the peripheral HW-Components or external Note must be declared. That means,
to pre-specify the SW-Component that is connected with the relevant µC I/O ports receiving and sending the signals. Further
it is pre-specified, from what Memory Cell or Register to read these necessary inputs for Process-Computation as well in what
Memory Cell or Register to write the Computation-Result that gets sent out to the peripheral HW-Component per port or gets sent
out to a nother note per data bus.
A necessary peripheral component is a resource on the printed circuit board with predefined allocated physical cell addresses
(Memory-Mapped I/O) which are used to read data from and/or write data to. For example, a allocated physical cell address is
used as a control register, where the data bits in the cell corresponds to the certain behaviour of the peripheral component.
Or any data bits as operation results written to an allocated physical cell address gets sent off to the peripheral component.
Read data from and write data to Register or Memory Cell
To read data from and write data to a physical cell address of the Memory-Unit for process operations, the 16-bit Data (2-Byte Word)
contains information about its allocated physical cell address that is computated by special circuits in parallel with the functional
process computation cycles. A special reserved region of the NVRAM which stores temporary data during runtime can be a Stack that is
used for static memory allocation at compile and link time and/or a Heap that is used for dynamic memory allocation at runtime. Both
stored in NVRAM with two main principle operations:
• push (put): add data bits to cell addresses per pointer (16-Bit Data-Registers or NVRAM or Flash-EEPROM)
• pop (clear): remove data bits from cell addresses per pointer (16-Bit Data-Registers or NVRAM or Flash-EEPROM)
All processes activated by the RTOS stores the received and send messages by pushing them onto the 16-Bit Stack-Register. A Pointer
points to the actual topmost 16-Bit Stack-Register-Number. The 16-Bit Stack-Register-Data-Bits contains the address information.
Memory Partitioning
A computation result from a runing process or interrupt service routine send and modify a specified memory partition cannot modify a other
partition. All memory partitions are connected per data flow (messages) and are configurated per configuration file as following :
• at boot time with loading the program code and a assigned data with a fixed number of tasks
• automatically created during run time for a specific tasks
Memory Management Unit (MMU)
For performance reasons there is a memory management unit (MMU), translating Logical-Addresses that are generated
during process computation cycles into Physical-addresses that refers to the memory allocated physical cell address.
Risk
Register
With running tasks (Process receives data, performs processing actions and sends data),
Stack-Register-Overflows and Stack-Register-Underflows are serious problems, that can
lead to an infringement of the Safety Goals. Since these memory failures can occur while
modules and classes operating perfect, Stack-Register-Overflows and -Underflows are
difficult to trace by the Error-Handling.
Access the Code Memory Area
If required, the control unit instructs the program flow to write to the Code Memory Area.
Hereby the protection for the Code Memory Area must be deactivated. There is a Risk
that an error in a running process (code piece) could cause another safety relevant process
(code piece) to fail.
Access the Data Memory Area
If required, the control unit instructs the program flow to read data from the Data Memory
Area or to store data to the Data Memory Area. There is a Risk that Data within Code Memory
Address Areas related to a process is lost or wrong.
Memory related Failures that cause interference between SW-Components
• Corruption of Memory Cell Address Content or 16-Bit Data-Register Address Content
• Read from or write to wrong Memory or Register Address
Protection
HW-Protection-Mechanisms such as Memory-Partitioning
Memory partitioning protects different allocated memory cell address ranges (partitions) from each other.
• safety related memory segments
• read-only memory segments,
• memory-mapped I/O data from peripheral and external components
If the error handling detects a memory related error during task processes or interrupts,
the memory partitioning ensures that this error will not be transferred to other allocated
memory areas of high or low level Modules or Classes and thereby avoids unwanted
interference between SW-Components (see ISO 26262 part 9).
HW-Protection-Mechanisms such as Error Detecting Code (EDC)
Parity bit, or check bit, are a simple way of Error Detecting Code (EDC).
A transducer wants to send a 7 bit of data plus 1 parity bit to the µC.
A parity sum of the ones in the 7 bits is calculated as 0.
Following with an odd strategy :
If the sum of ones is even, the parity bit becomes 1
If the sum of ones is odd, the parity bit becomes 0
The parity check bit is set to 1.
The transducer sends 8 bits incl. the parity check bit to the receiver.
The receiver of the 8 bits also calculates a parity sum of the ones in
the same way and checks the odd parity strategy whether its party bit
matches.
Note: A parity bit is only guaranteed to detect an odd number of bit errors.
If an odd number of bits (including the parity bit) are transmitted incorrectly, the parity bit will be
incorrect, thus indicating that a parity error occurred in the data transmission. The parity bit is only
suitable for detecting errors; it cannot correct any errors, as there is no way to determine which
particular bit is corrupted. The register data must be re-fetched entirely, and re-transmitted from scratch.
Parity has the advantage that it uses only a single bit and requires only a number of XOR gates to generate.
Parity bit checking is used occasionally for transmitting 7 bits, leaving the 8th bit as a parity bit.
HW-Protection-Mechanisms such as Error Code Correction ECC-Memory
Error Code Correction (ECC) protects against undetected memory data corruption that refers to serious problems
that can occur during data transmissioning, data reading, data writing or data processing introducing undesired
bit changes to the original data bits. The data bits that is read from each Data-Word is always the same as the
data bits that had been written to it, even if one of a bit actually stored has been flipped to the wrong state.
Note (Filter Stage)
With no protection against electrical disturbance by conducting and coupling, electrostatic discharge, or by
electrical disturbance by undesired electromagnetic radiation per filter stage, successful transmission could
never occur.
HW-Protection-Mechanisms such as Dual Core
Units of the µC are duplicated and work in parallel, providing redundancy in case one should fail.
A Harware Failure Toleranc HFT: N = 1 or 2 that enables the processor-unit to continue operating
in the event of a serious µC-component error.
SW-Protection-Mechanisms agains Common Mode Failures
If the main processsor fails because of a code piece error, it is highly likely that also the
redundant processor will simply repeat the same code piece error and would fail in the same way
Take into account risk analysis for severity, exposure and control for Common Mode Failures (CMF).
SW-Protection-Mechanisms for Register Space
The RTOS SW-Component provides a way to monitor available Stack-Register-Space by checking for
Over-flows and Underflows.
a.4.4) Runtime Safety Topics
Sum of process timing
The elapsed time is the sum of process timing constraints that are met by running a task.
The elapsed time to run a task for Application & Basis SW-Components is important for the
control of the synronous a.c. motor outputs. IS0 26262 Functional Safety requires that all
processes receiving data, performing computations and sending data is performed within
a specified maximum time span.
Process timing
An instance of a module is called by a task that is triggered by the RTOS-Kernel code piece.
The RTOS-Kernel features a task trigger mechanism and ensures a proper timing to activate tasks.
Risk
A timing failure occurs when preemptive Tasks missing there Dead-Line at runtime. A Dead-Line violation may
be caused by a nother preemptive Tasks B or an ISR interfering with the actual running preemptive Task A.
Following activation-related and timing-related failures can cause serious problems:
Blocking of Tasks
A process that blocks prevents other tasks or interrupts from being executed, that can lead to
an infringement of the Safety Goals
Deadlocks
Process remains in a waiting state forever, that can lead to an infringement of the Safety Goals.
Deadlocks are operation states in which task A waits to take action such as sending the computation
result to the data register because Task B or other multi tasks activations
Livelocks
Two or more individual processes are active, but interfere with each other so that processes cannot finsh
there computations. Two functions which counteract each other in a system and try to avoid each other in
the same way, and thereby interfere with each other, that can lead to an infringement of the Safety Goals
Incorrect allocation of activation time
Wrong activation of ISR, that can lead to an infringement of the Safety Goals
Incorrect synchronization between SW-Elements
Wrong network-wide synchronization of messages, that can lead to an infringement of the Safety Goals
Protection
The error handling functionalities of the RTOS-Kernel SW-Componente protect against activation-related and
timing-related failures such as
• heavy Processor-Unit loads
• wrong task activations
• wrong time for processes while exceed Dead-Line
• wrong Dead-Lines
For safe and accurate timing the RTOS-SW-Component checks whether a preemptive task meets its Dead-Line
in a fixed priority scheme (cooperative-task -> preemptive-task -> HW-task) with following factors at runtime :
Computation Time of Preemptive Task
An upper Dead-Line for the computation time of a Preemptive Task is monitored per RTOS SW-Component to prevent a timing fault
Blocking Time of Preemptive Task
Preemptive Task suffers from lower priority Cooperative Tasks that locks shared resources or disable interrupts
An upper Dead-Line is monitored per RTOS SW-Component to prevent a timing fault
Inter-arrival Rate of Preemptive Task
Inter-arrival Rate = worst-case computation time / inter-arrival computation time =< 1
A lower upper Dead-Line between Preemptive Tasks is monitored per RTOS SW-Component to prevent a timing fault
a.4.5) Processing Safety Topics
Monitor flow of processes by Watchdog with recomended diagnostic coverage
The µC has an integrated watchdog timer that periodically check the processing of activated tasks.
External Timer
Especially for functional safety reasons the watchdog is independ from the µC. Alternative the Watchdog is started and
operated by a µC watchdog control out-port that provides a Timer Start Signal (Restart) to a Watchdog-Timer IC peripheral
component that provides the Timer Stop Signal (Timeout) to a µC watchdog control in-port.
Diagnose running processes
With an activated and running task, the watchdog checks, if the task is being called properly by the RTOS code pieced and
checkes if processing (receives data, perform processing actions and send data) is functioning.
Risk
Reset
In general, the µC is able to operate in real time during a controlled shutdown per Terminal IGN 15N = OFF (enable
sleep mode), all necessary data are saved before activating the sleep mode. With a undesired hard reset because of
a serious error this is not the case.
With reset all code-area and data-area contents are lost in RAM, some data contents are preserved in NVRAM and all
code-area contents and default data-area contents are preserved in EEPROM
.
With this Level 2 E/E Sub-System, the printed circuit board with µC and ICs initializes and the Program Code which
is composed of
• Application SW-Components with associated data
• Basis SW-Components (RTE, RTOS, Drivers, ..) with associated data
is restarted.
But this happens so fast, that the program can resume normal operation without the driver noticing the reset.
With a higer Level E/E Sub-System, it would be necessary, that the program resume the process at the interrupted
point (reset) and operates with previously register safe state. In this case the necessary data must be saved to
the register or memory in such a way, that they would be available after reinitializing of HW and SW reboot.
Watchdog functionality
Due to a hardware fault or program error, the µC can fail to start and operate the watchdog functionalities, the timer will
elapse and generates a Timeout that is used to initiate a corrective actions to protect against an infringement of the Safety
Goals
Note
A reset must not be commanded by a function by purpose (e.g. Sleep, Wake Up, Ini, Enable, Store, Call, Clear, Adjust, Process,... , etc.)
Process Performance
Periodic checking processes have constraints on the frequency with which process result can be send.
Protection
Watchdog features
• checks if a process runs not too frequently or not too rarely.
• protect against task is being called wrong
• protect against wrong processing
Assigned all Activations with an (A)SIL
• Initialization_Event
• Timing_Event
• Received_Event
Error Handling
If a failure is detected, the following Error handling can be activated by the watchdog code piece by setting specific data
bits into the register to recover from this failure and/or set a warning :
• activate diagnostc trouble codes (DTC)
• error displaying
• activate limp home (processes with 20% elec. assist)
• activate limp aside (processes with less than 20% elec. assist)
• activate phase isolation of synchronous a.c. motor (deactivate function with 0% elec. assist)
• reset and restart operation
a.4.6) Approve Resources and Runtimes
Prove that the safety related task including error handling processes do not activate any undesired functional risk in case of a
Failure such as wrong address mapping or a wrong memory cell access.
• Design of SW-Components (Moduls & Classes) as Units and/or Source Code with default Data
• Qualified Safety Mechanisms (Interrupt Service Routines or others)
• Qualified Target Compiler & Linker for Program Code
• Qualification of propper Down Load of Program Code per Boot-Loader-SW to Target µC
• Qualification (Code Coverage Value for specified SW Test Cases with underlying HW)
• SW Test Requirement Document [TRD]
• SW Test Description [STD]
• SW Test Results with Report [STR] incl. Test Coverage Value [%] and FIT-Tests
• Functional and physical Configuration Audit (FCA/PCA)
• Assessment & Release of QM and (A)SIL assigned Safety Mechanisms
Failure-Insertion-Test
Error Handling have been tested by inserting manipulated program code pieces and/or data.
• Activation of manipulated circuits with Error-Activation-Switches
• Activation of manipulated code pieces or data inserted via the XCP Interfaces
Example: NetWork Management per OSI Layer 3, 4 and 5
Receive and send explicit Message Frames per NetWork
The complete Message Frame as a Protocol Data Unit (PDU) contains
• PCI (Header) serves as Protocol Control Information for administration bits only [OSI]
• SDU (Data) serves as Service Data Unit for data bits only [OSI]
• Trailer (Footer) serves to prove CheckSum [OSI]
for
• PDUs (Message Frames) of OSI Layers
Each numbered (N) layer has its own tasks with a specified communication
protocol including administrative and usable data bits as well as a check
sum approval to be transmitted or rceived to or from a nother layer.
Following OSI Layers
• Layer 3: N-PDU for NetWork layer
• Layer 2: L-PDU for Data Link layer
During transmission the PDU (Message Frame) is passed from the the upper
layer to the lower layer, that is interpreted such as
N-PDU = PCI(N) + SDU(N) + Footer(N)
NetWorks
NetWork Nodes
A node is a logical element to which a communication access is possible.
A µC with a com driver such as e.g. FlexRay or CAN represents 1 x Node
from the realtime operating system (RTOS) point of view.
Note
It can be assumed that no network management (NM) is required for E/E control
units that are switched on and off via IGN terminal 15N. When the ECU enters
the Dwell state (intermediate state) during the shutdown process, it sends
all required messages similar to a network management before entering the
Sleep or Off mode.
E/E Sub-System is preliminary configured as an End-Node
Features of NetWork Management
• Interface (API) to interact with the application (function frame)
• Node Monitoring
• Internal interfaces (NM <-> COM, ...)
• Transition into sleep mode
• NM SW Unit (protocol adaptation to bus protocol specific requirements)
• Interpretation of the status information (overrun or error in CAN FD bus)
• Scaling of the NM as a requirement of the node
• Application specific usage of the NM Data Bits
• NetWork Configuration
• NetWork Parameters
• Initialization of NetWork Interfaces
• NetWork Start-Up
• NetWork Operating States
• Coordination different NetWork operation modes
• Manage NetWork monitoring mechanisms for Server and Client • Support of NetWork diagnostic services
NetWork Communication
The speed of messsage frame communication is controlled across the
NetWork by bus load and consumption of resources. All messages are
synchronized to avoide negative effects on data by message bursts.
NetWork Monitoring
Each node is monitored with its unique administrative data from every
other node in the network. Diagnostics provide error handling such as
for bus off or transmission line error or time-out as interpretation
as transmitter specific break down, etc.
NetWork Message Synchronisation
Direct node monitoring requires a network wide synchronization of all
network messages. For this purpose a logical network ring is used.
In a logical ring the communication sequence is defined independent from
the network structure. Therefore each node is assigned a logical successor.
The logically first node is the successor of the logically last node in the
ring. Thus the decentralized control of the overall amount of messages is
ensured and the bus load due to these messages is determined. This sequence
of the logical ring will synchronize communication. Every node is able to
send messages to all other nodes and receive messages from them. Two typ of
messages are received and transmited from one node to another node (successor)
to build the logical ring.
Alive Message
The Alive Message introduces a node to the logical ring algorithm and interpretes
a related specified registration
Ring Message
The Ring Message is synchronized to the logical ring algorithm and interpretes
specific alive data and synchronization to initiate transmission of node message
according to the logical ring algorithm.
NetWork Application
Integrate Network(s) in the Application by
Configuration of Bus Type
FlexRay, CAN, etc. related drivers
Definition of Bus Parameters
Addresses, Bus-sleep-timing, Initialization, Delay-Times, Counters, etc.
Timing
Scheduling NetWork Tasks within 5ms, 10ms, 20ms, .., .., 100 ms
With adjusting the NetWork Message Timing, the E/E Sub-System
State Repeat Message is omitted.
NetWork Message Catalog per XML-Files
All messages which are sent and received via NetWork are taken from a machine-readable
message catalog.
To ensure reliable changes of the integration scope of the messages, the program code (hex file)
with its data description file (ASAM MCD) is configured by a machine-readable message catalog
via XML file (FIBEX and/or Autosar XML).
To cover TestCar(LabCar) versions/variants, a Message Catalog of NetWork messages
via XML files is created for each integration HiL test levels. The machine-readable message
catalog is checked for correctness and consistency by means of test scripts via HiL I/O
signal simulation tests, taking into account all nodes connected to the NetWork.
Due to a modification of data bits, the length of a message frame can change. For this reason
the monitoring process of the input group is adjusted to handle new lengths and buffer sizes.
The time for delivery of an up-to-date machine-readable message catalog is 2 working days.
All communication takes place per Vehcile NetWork(s). All messages which are
sent and received via NetWork are taken from a machine-readable message catalog.
The availability of necessary messages for
• Park-State (Intermission)
• Dwell-State (Interim MSA)
• Rolling-State (Mission A)
• Drive-State (Mission B)
is base on communication states per machine-readable message catalog
CAN
A faster CAN FD with larger message frame sizes has been implemented
which is an extension to the original CAN bus protocol. As in the
classic CAN, CAN FD protocol is also designed to be reliable.
Fley-Ray
A safe communication according to FlexRay is realized for all nodes in the vehicle
such as for the power steering, gateway, brake, suspension, transmission or engine
A communication controller and driver with its layers and network parameters provides
all necessary means and is protected by a Cyclic Redundancy Checks (CRC with timeout
of 900 ms).
The communication on the FlexRay NetWork runs in cycles. A cycle is divided into one
static segments and a dynamic segment.
A static segments declares a fixed time shedule for a specified Slot such as for power
steering-, gateway-, brake-, suspension-, transmission- or engine- message frame.
For special long messages a dynamic segment (mini-slot) is used. Hereby the point in time
at which a nother node is able to send a message can be delayed.
Maximal 254 bits of 8bit or 16bit data fields can be received or transmitted per instance.
At this instance, a distribution of approximate 33 % for transmitting and receiving frames
can be realized for both sections. In order to support a high number of message frames, a
buffering of messages or storing messages during a cycle is applicable.
Downloads with Boot-Loader-SWC.
Neccessary code pieces with there default data are down loaded into a non
volatile memory area during a pre-programming at the supplier plant. Apart
from this pre-programmed part, the ECU is in a non-programmed state when
delivered to the vehicle manufacturer.
During vehicle assembly or in workshop organizations a down load of data is
possible with a standalone EPS without plugged sensors or without other nodes
used within the vehicle network. Beside the low current supply power terminal
signals and the data interface there are no specified signals to be applied for
programming.
Programming and/or down loading data to the non volatile memory area during EOL
or within a service organization is realized with qualified Tools released by
the CarMaker.
The entire data base inlcudes the individual application layer with there SW-
components (SWC) and Autosar platform layers with there SWCs as a standard core
integrated to all nodes connected to the Vehicle NetWorks.
The data base is partitioned into
• Program Code
• Data for Logistic
• Data for Configuration
• Data for Application
• Data for Error Handling
• Data for Safety Levels
• Data for Realtime Environmental
Program code, data and the runtime environment incl. RTOS is loaded into the
non-volatile memory via a boot loader code and flash tool (less than 3min).
If a Vehicle Identification Number (VIN) is invalid or does not match the
application layer, then safe default data are loaded. If the monitoring
detects that the E/E Sub-System or the Vehicle has changed e.g. due to a
missing signal, a diagnostic trouble code (DTC) for this change is set.
A non-volatile random-access memory (NV-RAM) is used with a signature mechanism
as a Key to protect wrong access or manipulation of specified data cells. Code
and data runing from NV-RAM cells that have been receiving the data from the
Flash EEPROM during initialization upon each IGN Clamp 15 cycle within a transfer
process time t ≤ 1s. This overwrites the old parameterization. Coding parameters
provide options for selecting specific memory areas. Data transferred to and from
memory areas is protected by Cyclic Redundancy Checks (CRC).
Flash EEPROM Timing_Parameter are identical for all applications. The total
programming time is adjusted to the needs of the vehicle. Programming delays
caused by other nodes are added to the time of the sequential programming
interval between the 1st program request until the last program response.
Following data stored to non volatile memory area prior to the commissioning
Logistic Data
Logistic data are used to declare the Vehicle and its E/E Sub-System and to
store manufacturing data and service activities.
E/E Sub-System Reference Data
• Serial Number of item and its elements
• Production Date of item and its elements
• Order Number
• Version/Variant of item and its elements configuration
• Supplier Number
• others
Vehicle Reference Data
• Vehicle Serial Number
• Production Date
• CarMaker E/E Sub-System Number
• Vehicle Version/Variant
• others
Service-Activity
• Declaration of Last Change
• Service Location
• Service Date
• others
Configuration Data
Configuration data is stored prior to commissioning and is used to declare a
specified function frame and to allocate and define the interface I/Os. This
stored information associates with the marking on the item enclosure housing
such as a barcode, a label or other at the time of commisioning.
Note
All programming specs declared by Semiconductor Manufacturer are strictly
followed for series delivery. Guaranteed number of programming cycles per
counter with pre manufacturer entry, one plant entry, ... , ..., and the
last flash procedure.
SW Units are code pieces derieved from moduls, classes or statemaschines
with there parameterization (A2L.file according ASAM Keyword Format). With
each compiled program code a default parameterization is made available
It is possible to generate and replace A2L-files without re-compiling a
new program code.
The data file is down loaded to the Flash Memory of the µC with tools
such as or CANape.
NetWork communication is realized by means of XCP Calibration Protocol
for different buses per specified protocol and transport layer (X), that
is integrated in the low level software (Autosar-SWC).
Following Software Components to support
• XCP messages on CAN-Bus
• XCP messages on FlexRay-Bus
• XCP messages on SxI (SPI-Bus, SCI-Bus)
• XCP messages on Ethernet-Bus (TCP/IP and UDP/IP)
XCP allows to access the Memory Content per ASAM A2L Key Word Format
using following procedures
• Polling Mode (per cylical query)
• Event Mode (per task scheduling)
XCP Master
• Session to activate XCP message communication
• XCP Message Events cycles at 2ms, 5ms, 10ms, 20ms and 50 ms
• At least 4 x XCP-messages (per messgae Catalog) with 100 bytes per slot
With series supply, the application interface is deactivated. Activation is
only possible via secure access per special authentication level.
With Power ON, all application parameters (constants) are coppied to a
specified RAM area and therefore changeable and accessible during runtime.
The transmission between the Non Volatile Memory and RAM areas is handled
by a Memory Management Unit (MMU) of the µC. This MMU allows the RTOS to
separate memory areas for multiple parallel processing.
If the program code matches the data file, modules, classes or statemshines
will immediately adopt new data per NetWork communication during a interrupt
service routine (ISR) followed by a validity check. Herafter automaticaly
follow up the current or specifed follow up task.
With controlled Power Off, all application parameters (constants) are
stored to a specified Flash EEPROM Memory area.
The parameterization is protected against unwanted changes with the help
of special procedures such as with error correction code (ECC), a type of
a memory procces in which an error correction code is used to detect and
correct corruptive data bits that occur in memory cells or with cyclic
redundancy checks (CRC) for data bits that occur in shift registers.
Measurement
Following during on-board & off board
• Adjust and measure functional parameter with inputs and outputs of functions
• Read from memory and write to memory
8 byte x 8 bit Message Frame
• Calibration-ID (CAL-ID)
• Calibration-Version-Number (CVN)
Preliminary check ID and if CVN is compatibe to the program code.
If valid, store CVN immediately or latest 120s to memory cell
Whenever a content of the message frame for a specified CAL-ID or
a CVN is changed, an Event-Message is triggered and transmitted.
If a message is bursted during transmission the sending is
repeated after t = 20 ms (2 FlexRay-Cycles).
Default XCP-ID
• Dec 63
• Hex 3F
• 0011 1111
Adaptive data is used to store
• individual driver setting(s)
• record driving behavior(s)
to the RAM at the start of each power on. With power off the adaptive data
is stored to a specified ROM area to compare this last driving cycle to all
previous stored driving cycles. It is possible to reset the memory area to
defaults per diagnostic session.
Note
A change of the memory layout will not lead to compatibility problem.
All adaptive data are protected against undesired changes via CRCs.
Following 3 modes prior to the commissioning
• manufacture/assembly
• transportation
• flash
The flash mode is used for programming the E/E Sub-System.
After reset and HW initialisation a programming state is
activated via programming session and flash communication
is permitted and kept while programming takes place from the
1st progarmming request until the last programming response.
Alternative modes are deactivated.
Operating mode with safety functions are available in a
limited way only.
Malfunction States
Malfunction evaluation per functional state A, B, C, D or E.
A Diagnostic-Handler provides a process to read and write failure
informations from or to a failure memory cell at runtime or during
a diagnostic session per tester.
Following general type of DTCs
• provide a Primary DTC for a Failure Mode that leads to a degration and/or repair
• provide a Secondary DTC for a Failure Mode that does not lead to a degradation
Primary DTCs
A primary DTC only and always occurs if there is a defect requiring a repair or a degradation
(e.g. CC message, warning light, function failure, driver is able to notice disturbance and
can not assign a reason to the degradation). All specified primary DTCs are linked to effective
and practicable workshop instructions.
Secondary DTCs
Has no impact on driving.
Event DTCs
Upon receipt of an wrong value (e.g. voltage amplitude) and in the case of a E/E Sub-System
degradation which the driver is able to notice the E/E Sub-System will execute a DTC as
classified as an Event DTC. These types are declared and stored in the primary failure
memory area.
Following general content of DTCs
- Failure Type
- Failure State
- Warnings (MIL, etc.)
Further
- Storing Conditions
- Clearing Conditions
- Memory Mapping (Perceptual Vehicle State, Safety, ...)
- Impact on Inputs, Processing and Outputs
- Interrupts to handle failure (degration, limp home, limp aside, etc.)
All DTCs, are referenced to an environmental condition.
Store environmental and vehcile conditions data synchronously while DTC is set.
Following Information for Workshop Instructions
All specified primary DTCs (repair requested) are linked to effective and
practicable workshop instructions.
Diagnostic Master
A diagnostic task can be send to one node or multiple nodes connected
to the NetWork. Hereby the E/E Sub-System which has the lead on the
functional task is specified as the Master. All others are second type
peripheral E/E Sub-Systems. The coresbonding functional task is splitted
between a 1st portion implemented in the master node and a 2st portion
that is implemented in participating other nodes. The master portion is
a functional task distributed throughout the NetWork and is divided into
the following 3 sections:
• 1st Section: Time Master Item
• 2nd Section: Centralized Fault Memory
• 3th Section: Fault Memory Status
Time Master Item
The time master item is located in the instrument panel (gateway) and
cyclically transmits every second an update of the main car time to all
items connected to the bus network of the car including the specified
car application as a time stamp in case of failure messages.
At the end of the series manufacturing process (End Of Line) the main
car time counter is set to zero and herafter expresses the time during
the car life cycle (max approx. 136 years) in seconds that have passed
since initialization in the factory. Because the counter is stored in
non-volatile memory (EEPROM) it will not be reset when battery supply
is disconnected or when the supply voltage to the instrument panel
(gateway) is switched off. The counter cannot be duplicated or modified
and is also redundantly stored as an object with its name and location
in a Content-Addressed Storage (CAS) to minimize the risk of data loss
e.g. by replacing the instrument panel similar to the mileage reading.
In the event of a hardware memory failure, a monitoring sets DTCs.
Centralized Fault Memory Typically a central gateway item is the master for centralized fault
memory tasks such as Control Change (CC) message checks or to store
failure codes for different ambient conditions with a time stamp in
addition to the untouched local failure memory concept and processes
of the items connected to the bus network which locally storing DTCs
along with the car mileage and main car time at which the fault occurred
(time stamp). The Centralized Fault Memory has a size of 18KB to store
between 250 and 1000 faults dependent upon how many faults occur
simultaneously as well as 26 ambient conditions including different
information on the global status of the car such as main car time,
milage reading, supply voltage, terminal status, ambiant temperature,
driving speed, etc. For sufficient fault analysis and to prevent the
Centralized Fault Memory from being overfilled each fault code and
each control message check is accepted up to 10 times. Preliminary
fault analysis continues to be performed by using the fault memory
DTC entries in each of the items connected to the bus network.
Hereby only the mandatory conditions such as milage reading and
main car time and possibly a few additional ambient conditions
could be found in the local fault memories of the items. The redundant
data from the central fault memory of the central gateway allows a more
precise diagnose with more ambient conditions e.g. detect item that
firstly had an error or entered an error reaction, etc. With a diagnostic
tester a full Centralized Fault Memory (fault codes) can be deleted.
Fault Memory Status
The fault memory status includes the centralized fault memory frame
for gateway error entries for specific scenarios as well as the
evaluation/application of the specified fault memory frame of the
item error entries.
At certain operating events such as car network wake up or low/high
supply voltage conditions with invalid gateway error entries can
occure (pseudo faults) as the item does not behave synchronously
during these events.
To prevent pseudo faults, a centrally communicated signal forbids
wrong error entries. Safety relevant faults will always be stored.
Simplified flow chart shows a general process to generate global Diagnostic Trouble Codes (DTC)
General Diagnostic Topics
Within the scope of a future requirements, 70 % of the available
memory map with 30 % reserve is standard.
Information of the Input Group such as for
• all signals collected from a sensor-source with/without DTCs
• all posible DTCs with there Error Handlings for the function frame
• all safety relevant DTCs with there Functional Safety Handlings
Classify DTCs such as
• for maintenance or service
• for cyclic runtime checks
• for hardware watchdog checks
• etc.
Store DTC for NetWork Communication Failures such as
• Time-Out such as check sum failure within a 1st Error Memory Area
• Message, Alive-, CRC-, .. Failure within a 2nd Error Memory Area
A maximum permissible time of 9 seconds from the detection
of an failure to store to the 1st or 2nd failure memory cell
can be realized.
Failure Memory Handler to provide
• write access to error memory cells
• read from error memory cells
• deny reading and/or writing from/to error memory cells
Documentation of TestCar (LabCar) corresponding
• Diagnostic Information (e.g. within OEM Mainframe System)
• Application version and its variant of function frames (Project Phases, Product Lines))
• Monitoring Functions (diagnostics, error handling) for integration maturity levels (I-Steps)
Diagnostic-Needs
Specified monitoring with diagnostics, failure handling, safety handling,
and warnings for malfunctions
Open circuits and short circuits at all connection lines to inputs, to
periphery elements and to outputs are monitored and checked by a cycle
time of not more than 20ms. If nevertheless a defective or wrong
external part is connected to the E/E Sub-System (e.g.by means of
a wrong harness length or connector during assembly or replacement)
this will be detected by the E/E Sub-System per self-diagnostic
features. Open circuits and short circuits at all connections to
inputs, periphery elements and outputs are monitored and checked by
a cycle time of not more than 20ms.
Efficient corrective action such as a degradation that can be noticed
by the driver. Realized a maximum permissible time of less than 20ms from
the detection and error reaction and less than 9s to store to the 1st or
2nd failure memory area.
Following Safety Levels :
• Safety Level 1 (correct program code flow with in- and output values)
• Safety Level 2 (check correct input values via monitoring)
• Safety Level 3 (independent question/answer plausibility checks)
Diagnostic Session (Diagnostic Services or Jobs)
With a diagnostic session the comunication between the E/E Sub-System and
other On-Board Nodes or a Off-Board Scan Tool is started to receive the
diagnostic service informations form the memory unit or to activate an
test action e.g. for a function with its safety mechanism.
For each job a request is send to the µC-ECU to respond with diagnostic data
stored in the Flash-EEPROM-area.
• Programming with Parametrization
• Commissioning E/E Sub-System
• Commissioning Car
• DTCs for field failure root causes
• Statistics Counter
• Others ...
Diagnostic Communication
Comunication works according to the request/respond principle of the
server/client model (transmit-TX/receive-RX).
Diagnostic services can be physically addressed between two items
(point to point per two NetWork nodes) or functional addressed to
all receiving nodes on the NetWork.
Following used Adresses
• Physical Address : Service requests answer only from one Client
• Functional Address : Broadcast to multiple Clients on the NetWork
The logical address is generated by the CPU in perspective of the scheduled
process whereas the physical address is a cell allocation that exists in the
register or memory unit. The µC Memory-Management-Unit (MMU) maps logical
addresses to its corresponding physical addresses, that is represented in the
form of a binary number on the bus circuitry, in order to enable the data bus
I/O driver to access the memory cell of the µC, that includes the actual 16bit
DTC data. The data bus driver as a transmitter converts the 16 bit data per
specified conversion rule to physical high/low voltage pattern and sents them
per D/A output port to the nodes (Receivers).
• Physical Address : Dec: 48 Hex: 30 Bi: 1100000
• Functional Address Dec: 215 Hex: DF Bi: 11010111
For diagnostic comunication, the µC behaves like a single Processor-Control-
Unit (CPU) that reads and writes different memory partitions assigned to DTCs
during time-critical runtime (On-Board) and non time-critical per Diagnostic
Tester (Off-Board)
• On-Board Diagnostics (logging e.g. time-stamp, signal condition during latency)
• Off-Board Diagnostics (primary & secondary DTCs per diagnostic scan tool)
Note
Read out different failure memory partitions assigned to special DTCs per sample
rate(s) or log files with the On_Board_Diagnose during a journey. If diagnostic
tools are unavoidable for error localization, then this can be done per CAN bus
with existing standard automotive diagnostic testers.
Store NetWork Failures to different Failure Memory Areas
Timeouts are stored to a 1st Failure Memory Area and Keep-Alive, CRC or Message
Failures are stored to a 2nd Failure Memory Area.
Safety Comunication Needs
Time-critical runtime diagnostic as explicit messages used between nodes on the
NetWork complies to ISO17458 (FlexRay comunication).
Standard Comunication Needs
Unified Diagnostic Services (UDS) per CAN bus protocol such as specified in
ISO14229, which allow a diagnostic tester (server) to comunicate and execute
implemented diagnostic functions within the client if connected to a serial
data link embedded in the vehicle. A server can access all unified diagnostic
services (UDS) that are specified by the CarMaker and loaded per Diagnostic
Description File (ASAM MCD-2 D). A measure for the client/server quality is
the compliance of request/response results as per ASAM MCD-2 D file.
The UDS individual message frame lenght is specified by the used transport
protocol and is always splitted into
• ID
• Parameter-Field
• Data-Field
The Client starts the Diagnostic Service with a Diagnostic Request received
from a Server. Hereafter the Client sends back a response.
• In the positive case this is always the SID of the server + a $40
• In the negative case this is a $7F.
If the process of the diagnostic requested takes to long, the Client sends
per regular intervals following information
• Client To Server Request Correctly Received But The Response Is Pending
• Server To Client Successfully Received Response.
With certain UDS message a negative response such as ERROR is possible
to all available nodes connected to the NetWork per functional addressing.
For special reasons it is possible to change a diagnostic sessions at a car speed
of less than 10 km/h taking into acount actual vehicle states.
Diagnostic communication with the Failure Memory is possible in all driving situations.
For some vehicle state reasons it is only possible to change a diagnostic session at a
car speed of less than 10 km/h.
Non Volatile Failure Memory Needs
The µC with its memory unit size complies with the specified failures and associated
DTCs necessary for the vehicle and the E/E SUb-System.
Two Memory Sections
Trouble shooting functions are stored to a 1st Non Volatile Failure Memory Section.
General field monitoring is stored to a 2nd Non Volatile Failure Memory Section.
Both sections can store at least 20 failures with at least 40 bytes of data. Thereby
each stored failure is counted by an error counter and assigned to a specific DTC
with its actual environment conditions.
DTC Counter
If a failure is detected and has been found valid by the Monitoring Function then the associated
DTC becomes valid and the counter is set to 1 if it is the first error or incremeted by 1. When the
DTC is detected for the first time, a first data record with environment conditions is created. The
second time the failure occurs, a 2nd record is created. Each time the failure occurs, the 2nd data
record will be overwritten including actual milage, vehicle speed and other environmental conditions.
Note
Store Time Of Failure Detection with the associated DTC and not simply the memory entry time, because
this would be to late for some variables, internal states or for task scheduling. Exceptions are variables
that only change very slowly, such as the outside temperature.
Following count features
• Counter and corresponding DTC must match to be valid
• Use physical and logical Terminal IGN 15N cycles
• Upon each new occurrence of an Failure Mode for a new Terminal IGN 15N cycle the counter is incremented by one step
• Initial and minimal counter value is 0
• The job CLEAR FAILURE MEMORY is used to reset the counter and set the counter to a default value (0)
• Increment counter by an configurable step value (FZ_step) for each DTC that activates a degration
• Max 40 DTC types that activates a degration per new Terminal IGN 15N cycle (FZ_step = 40)
• If counter is equal or greater (FZ_max) a degration type is set
• Freeze degration type if the DTC occurs 3 times in a row (requires a workshop visit)
• If DTC is cleared, then the counter is decremented by a step value (FZ_dec = 1)
• All counter value can be read by a specified diagnostic request (work shop)
DTC Status
A readiness flag may be withdrawn if a failure with associated DTC continues to be received.
After a failure with associated DTC have been cleared all remaining faults will be monitored
immediately again. With power off or in case a safety critical failure occurs, the actual
condition of the vehicle is stored. A safety critical failure with associated DTC is indicated
with the severity Immediately Attention.
DTC Environmental Conditions
The actual environmental condition data are stored at the time of error detection with the
associated DTC. During initialisation, the milage and the operation time as well as further
necessary specific data from the last power off cycle are loaded as past environmental
vehicle condition.
Environmental Conditions provided per NetWork
• Environment_NetWork: Dec: 1750 Hex: 6D6 Bi: 11011010110
• Environment_Sub_NetWork: Dec: 1751 Hex: 6D7 Bi: 11011010111
Some Vehicle State Conditions such as for
• Millage: Dec: 1700 Hex: 6A4 Bi: 11010100100
• Operation Time: Dec: 1701 Hex: 6A5 Bi: 11010100101
• Ambient Temperature: Dec: 2805 Hex: AF5 Bi: 101011110101
• Voltage Supply: Dec: 2866 Hex: B32 Bi: 101100110010
• Vehicle Speed: Dec: 2867 Hex: B33 Bi: 101100110011
Categories for DTC Corrective Action
• Corective Action for Failure with associated DTC according to a standard procedure
• Immediately Corective Action for DTC as soon as a specific operation mode is active
• Failure with associated DTC cannot be corrected
• Corective Action in case of Reference DTC
• Corective Action in case of legal or safety requirements
Reference DTCs for confidence level of 5 % for failure occurrence
To avoid unnecessary workshop services time, reference DTCs with an event flag
are used, if it can be assumed that this DTC occurcs in less than 5 % of the
vehicles entered the market per Year. These Reference DTCs enables a workshop
to quickly find and understand the malfunction, in order to be able to provide
the driver an easy explanation and fix of the situation taking into account
environmental conditions, operating states and limits that have led to this
functional impact, that does not require any special repaire. In addition,
Reference DTCs can also indicate wrong or misuse. Others are none service
relevant malfunctions where the driver can assign a reason to a degradation
that does not require a service such as e.g. warning light when slip control
is off.
Note
If it is above 5%, then the control and warning concept and the service plan
of the dealer organizations will be improved.
Primary DTCs requires a repair for failure occurrence
A primary DTC only and always occurs if there is a defect that requires a repair
with or without a degradation or warning that can be noticed by the diver.
Note
All wrong input variable or states for signals and qualifiers, that are not
functionally required, do not result in a primary DTC and are only used for
failure analysis such as to check conditions or debugging during development.
DTCs for commissioning, legal or safety relevant failure occurance
Incorrect commissioning conditions or operation that does not comply with the law
or functional safety deficiencies trigger a specified Error Handling Task within
a running process that can only be switched off by service organization.
Note
Degrated or wrong output signal that cause other nodes in the car to activate
there degradations are taken into account (cannot or can be noticed by the driver)
DTCs stored to memory area based on perceptual vehicle states (PWF)
Network-DTCs are generally not suitable to indicating mounting orinstallation
failures of mechanical parts or for HW or SW Failures which are independent of
vehicle states. For this reason, Network-DTCs are only stored to memory areas
based on active perceptual vehicle states such as following example
A DTC may be stored at a perceptual vehicle states such as e.g. terminal 15N ON
or for Warm Start Vehicle States or for Cold Start Vehicle States.
Example for Cold Start Vehicle State
If the engine is started in a warm state, e.g. MSA, a NetWork Failure can be excluded,
since stably running E/E Sub-Systems are to be expected in the vehicle network.
Example for Cold Start Vehicle State
If the engine is started in a cold state, there mide be NetWork Failure because
the engine stalls. For reasons of robustness, no Network-DTC or other DTC will
be stored.
A storing of this type of DTC is permitted if the Operational Readiness
of Server and Client is archieved at this perceptual vehicle states. The
operative readiness of the perceptual vehicle state is evaluation per Vehicle
State Condition Signal. DTCs for a pcb components or parts are always stored
independently of operational readiness of Server or Client if a Failure
occured.
A reasons of robustness, a delay time of 2s can occure to store a DTC after
perception of a vehicle state that includes a failure. There will be no delay
time if this failure was already active and stored in the previous vehicle
state.
If no readiness per Vehicle_State_Condition Signal is available, then only one
preliminary DTC is stored, that points to the specified PWF memory area.
Avoiding of cascading DTCs of follow up failures
It is ensured that only 1 X DTC is set per Failure case. Which means, if several
functional degradations occur due to a faulty NetWork message, only 1 associated
Network-DTC is set such as following example.
If transition states to set a DTC for NetWork Failure_A is not present due to a
further NetWork Failure_B, the DTC for Failure_A is not set. Instead, the DTC for
Failure_B is set. The DTC for Failure_A would be only set at a vehicle speed greater
than 10km/h. If the Vehicle Speed would not be available, the DTC for Failure_A is
not set. Instead, a DTC for Failure_B is set because of missing vehicle speed signal.
Monitoring Processes
• to detect Failure Modes
• provide a Primary DTC for a Failure Mode that leads to a degradation perceived by the driver
• provide a Primary DTC for a Failure Mode that leads to a repair
• provide a Secondary DTC for a Failure Mode that does not lead to a degradation
• Interrupt process by Error Handling Routines in case of a Failure Mode
• Interrupt process by Safety Handling Routines in case of a serious functional safety problem
Functional Monitoring
Monitoring of the Input Group can take place within the specified supply voltage
range whereby the program flow allows to detect explicit and implicit failures
of received messages and hereafter execute an Error Handling with specified
corective actions for the process output such as debouncing, redundancies,
degradations, warnings and others.
Note
Other monitoring operations such as for the DTCs belonging to parts, are not
part of the functional diagnostics.
With initiation of input variables or states within 500ms after a requst by
the Client, multiple monitoring processes are activated per RTOS and
failure DTCs are maped to different memory areas.
DTC Priorities
Clustering of more than one monitoring processes that detects only one DTC
is excluded.
If several failures are present at the same time or at different times due to
the same failure cause, only one DTC with the highest priority is set.
Following Prioritization of Failure Modes
1. Hardware Failure (highest priority)
2. Supply Voltage Failure (Under/Overvoltage)
3. NetWork Message Failure
4. Time-out (message absence) or Event Failure
5. CRC Failure
6. Alive Failure (signal is not up to date)
7. Failure because signal is invalid or qualifier is invalid
8. Failure because signal is undefined or qualifier is undefined
9. Signal quality or qualifier is not sufficient
10. Functional Failure (lowest priority)
DTC Handling
If the situation is such that an undesired NetWork shutdown event can only be
detected after a Time-Out (lower priority), the monitoring process checks, that
there is no NetWork Message Failure (higher priority) before setting a DTC for
the Time-Out. That is, before a Time-Out (lower priority) is acknowledged, the
specified time for checking a correct NetWork message (higher priority) must
have elapsed. In case this time-out is not confirmed, a temporary failure is
assigned. But if the Time-Out has occured as a result of the unwanted NetWork
shutdown event, it is ensured that a DTC for a NetWork Message Failure is set.
If a Time-Out has occurred due to a signal transient (threshold value), the
monitoring process result is delayed by a specified latency time to check if
the signal value transitions to the required stady state within an acceptable
response time. If an invalidity failure (Signal, Qualifier) occurs after the
response time the higher priority Time-Out is set.
When the associated DTC is set the Failure Handling is processed depending on
the integrated Failure-Reaction or specified safety goal for the failure mode.
Monitoring, Diagnostics, Failure Handling processes and Storing occur synchronously.
The delay time to send process output-results can be neglected (1ms...20ms).
To ensure the highest possible functional availability, possible causes
of degradation are reversible (e.g. after healing of undervoltage or an
overtemperature events), if this will not lead to a violation of the
specified safety goals.
Note
It must be ensured that the driver will not become irritated by multiple
withdrawals of degradations (e.g. On/Off or flickering MIL or etc.). This
is done by limiting the number of degradation withdrawals (e.g. trigger
mechanism with specified time response for withdrawals or hystereses).
Monitoring NetWork Messages
The Client provides the same monitoring level such as the Server.
A assignment of NetWork Messages for Modules or Classes, is taken from a
Message Catalog. Only if the Server is able to send a necessary NetWork
Message it is monitored by the Client. A default delay time of max 2s is
set to start up monitoring.
Note
An undefined failure with associated DTC is set, if a message has been received
that is not jet defined in the message catalog or the message data is outside
the defined value range referenced in the message catalog.
All types of Communication Failures remain active as long as the associated function
remains degraded as a result of the failure. If the full functionality is achieved
again, the failure is cleared and the associated DTC is not present any more.
From a quality aspect, all messages are monitored such as for
• definition of signal
• sufficient resolution of signal value
• tolerable range of signal value
• plausibility of signal while comparing to other signal sources or redundancies
as well as from a communication point of view such as
• CRC checks for CRC-Errors
• Keep alive checks for Alive-Errors
• Time-Out checks for Timeout-Errors (Ceck Sum Errors)
Signal Checks
All inputs are checked if invalid and/or inacceptable. If a message has no ID or
received with a specified invalidity identifier as per message catalog or received
with insufficient length of the message an Invalidity Failure with associated DTC
is set. Also evaluate the message content in accordance with functional criteria
depending on vehicle conditions that can lead to degradation, although all the
evaluated variables and states might be OK. Signal failures due to noise are
detected according to a threshold value check.
Signal Qualifier Checks
If a degraded qualifier is received by the Client according an functional
context between the Server and the Clinent a Qualifier Failure is
set with associated DTC.
Cyclic Redundancy Checks (CRC)
CRCs serve as end-to-end validation between nodes. The CRC is always
monitored if the Client is asked for CRC checks by the Server.
Keep Alive Checks
The value of an alive counter is always monitored if the Client is asked for
alive checks by the Server. The alive counter indicates if the signal is up
to date. A possible alive failure can be a transmitted per message failure. A
alive failure for cyclical messages is set, if they are received with unchanged
or invalid alive counters. If after three transmitting cycles the absence of a
message leads to a functional degration an alive failure is also set.
Failure Amplitudes
State of the art concepts in NetWork Diagnostics are the use of Failure Amplitudes.
Thereby a Server sends the tolerable deviation of a data value. The Client
monitors this tolerable derivation. If the running process (function) is interrupted
because the data value is out of range an corrective action with associated DTC is
executed.
Failure Amplitudes are evaluated by the client on the basis of the variables
and the associated qualifier. The evaluation can take place by means of comparison
with a defined threshold value or by means of other statistic methodes such as likeli-
hood or probability (e.g. likelihood used to generally maximize the operation at an
event or use probability to find the possibility of failure occurrence at an event).
The Client requests a data value from a node. If the Server of the data
value cannot respond to the request by means of a none sufficient qualifier,
the deviation of the data value as a Failure Amplitude will be send to the
Client as a respond result. The received message and the none sufficient
data quality will be evaluate by Client to check if the message might be
OK be used.
If the Server is able to respond to a request of a Client with a sufficient
qualifier, no evaluation of a Failure Amplitude by the Client takes place
and the computation of the processes starts.
Failure Amplitudes can lead to special process results such as a degradation with
accociated DTC and Driver Feed Back Message (CC-Message). Upon receipt of
a Failure Amplitude and in the case a degradation, that the driver is able
to notice, the Diagnostic Trouble Code is declared as Event-DTC. Only the
increase of an Failure Amplitude without a change of the associated qualifier
will not trigger a DTC.
Time-Out (message absence) or Event Failure
A protocol check sum failure causes a Time-Out. For cyclical messages an Time-Out
Failure is set, if the absence of one of the messages leads to degradation or if
a transmitted message have not been received after 3 transmitting cycles.
For a requested messages a Time-Out Failure is set, if a the corresponding response
message is not received within 500 ms after the first request. In case of an absent
response message is set, the query must repeat 2 more times within the current cycle.
If the data is send per protocol data unit (PDU) of the µC and the protocol check
sum is wrong a Time-Out Failure is set, if there is a resulting functional degradation
and only on receipt of the 3th consecutive protocol data with an CRC-Error.
Check between controlled Power Off or undesired Hard Reset
The monitoring process detects upon Terminal IGN 15N (ON/OFF) cycle whether the forward
path has received a controlled power off or received a Hard Reset due to an internal or
an external failure event that causes a special Reset-DTC with following exceptions
Special Reset-DTC is not activated if
• a Low Energy State is set because MSA activation
• a Voltage-Reset is executed in case of prolonged undervoltage due to a generator defect
If an Unplanned-Reset is detected during start-up, the Failure Mode Counter is adapted
taking into account the following requirements:
If an Unplanned-Reset is detected during start-up, the Failure Mode Counter is adapted
taking into account the following requirements:
• DTC that locks degration occured less than 3 times
• absolute vehicle speed signal (V_VEH_COG) is available
• Valid absolute vehicle speed qualifier (QU_V_VEH_COG)
• Quality of absolute vehicle speed > 20 km/h
• No MSA (Start/Stop) process present
Debounce Check
Input diagnostics to increase the robustness of processes such as for messages,
CRC-Checks, Keep Alive-Checks, Time-Outs or Qualifiers, that ensures no wrong
values of variables. The debouncing process is always synchron for signals and
their qualifiers.
A DTC or a degradation is only set after the repeated occurrence of an failure
within a certain debounce time. Within the debounce time, the last valid value
of the signal or state is held or a substitute value is provided for processing.
The maximal possible debounce time (parameter = debounce duration) does not
exceed 60s, in order to ensure a failure detection. The maximum debounce time
for a received message is derived from the required availability to send the
process output message. A cascading of several individual message debounces
do not result in an extension of the specified 60 Seconds. The minimal possible
debounce time (parameter = debounce duration) does not exceed 3 bus cycles for
FlexRay. These shorter times do not violate legal or safety requirements. The
reference check for the debounce time is the testing without debouncing.
Failure Debugging
Debuggging information is cyclically or event-driven stored in the failure
memory at runtime. With an EPS slot every 10ms a message frame with max
254 bytes of 8bit (1byte) of data fields for debugging information is send
to the FlexRay NetWork to be received by other nodes on the bus. The
information stored during power down is always sent during power up.
To inform per other NetWorks, the type of NetWork is selected by its name
and the stored debugging information is sent via the selected com-driver.
Specified bugs that are laid out in a failure list can be read out from the
failure memory and send per message frame to the CAN NetWork to be received
by a Off-Board Scan Tool (machine-readable debuged message frames)
As long as a valid vehicle driving distance of less than 255 km or a cumulative
operating time is less than 15 h, the transmission of debugging information can
be activated via a binary coding switch or per diagnostic service command.
A unique identification and the coding switch state is at the first data field
of the message frame. Coding parameter value > 0 = ON and for 0 = Off.
Field Data
Field failures are product quality problems. Depending on what caused the problem,
a problem-solving process is initiated
Despite the failure free series supply, deviations from the series release may
occur during service life of the vehicle. With SOP the field failure counter
value is set to 0 and the maximal range is set. Bot are store in the non volatile
failure memory area assigned to the diagnosed field failures. In case of an field
failure, the counter value is incremented by 1. During runtime the counter value is
stored in the RAM and during power off stored to the ROM. The actual counter value
is protected against data manipulation. A manipulation is marked by means of a DTC.
The failure memory area assigned to the diagnosed field failure is read out and the
fault is rectified by the service organizations. The memory area can be locked or
deactivated via a binary coding switch or per diagnostic service command. A entry in
the failure memory is retained until the next clearing of the failure memory.
Self-Diagnostics
Connected parts or circuit board parts can be diagnosed by self-diagnostics
e.g. open or short circuits or wrong cable lengths or a wrong plugs.
System failure memory stores failures in case of under- or overvoltage conditions such
as for wrong bus communication signals or wrong sensor signals or wrong actuator signals
as well as there resulding failure stages. Further a reliable distinguishing between a
causing error and cascading errors has been taken into acount for the memory entities
with an voltage error.
The causing error with the insufficient voltage supply will always be declared and stored.
If a operation readiness failure of a SW-component such as a module, class or statemashine
is accepted by the program flow during an engine start (IGN request), the storing of an
error is not permitted by the program code.
With the automatic engine start-stop function (MSA), the supply voltage for nodes on the net-
work can change a lot and very fast. This is different from a undervoltage. Therfore the global
voltage state is required by the E/E Sub-System via a bus message. Global refers to the vehicle
context, i.e. the voltage supply of all nodes. Local means the E/E Sub-System. With the MSA, the
E/E Sub-System checks to see whether a diagnose is done as a result of an error or as a result of
an infringed boundary voltage condition. Global boundary conditions include undervoltage during an
MSA engine start. With MSA the storing of an error is permitted by the
program code.
Following topics for the E/E Sub-System Error Memory entry:
• Each error memory entry declares the failure reason in order to explane the error as part of the
service and to rectify the problem.
• In some cases there is an error memory entry to fix a HW-Element during the next workshop visit.
• With the E/E Sub-System, an error cause is always an activated monitoring
• With the vehicle as a system, monitoring is always activated due to an actual error event or an
infringement of a global boundary condition that prevents a communication note from sending a required
signal which it is supposed to send via the network. In such cases, the actual reason is declared.
• Error memory entries are made if a SW Component detects an operation restriction or a need to carry
out a repair during a next workshop visit.
b) There are four types of incorrect voltage conditions:
• Local undervoltage
• Global undervoltage
• Local overvoltage
• Global overvoltage
b.1) Local Voltage
The item with its elements has a range of internal voltage-dependend monitoring features for sensing and
actuating that are :
• located within an element
• connected to an element
• directly supplied with voltage
Internal monitoring operations can be activated as a result of an voltage error (under or overvoltage).
In this case, there is no defect on the item or its elements and the cause is stored as under/overvoltage.
Malfunctions detected by these voltage-dependend monitoring features are called internal errors and DTC are
stored as voltage errors.
Note: Voltage-independent monitoring functions such as Coding checks or RAM/ROM checks are not part of this.
Local voltage measurement takes place on the items internal elements supply lines and pins.
If sensors or actuators are externally connected and supplied with supply voltage from an internal voltage
regulator IC, any voltage drop in the supply lines are monitored to check inadmissible voltage states.
If the item with its elements are supplied from external onboard sources, local thresholds are handled separately.
Any voltage drop is assigned separately to the internal voltage monitoring.
If an element is capable of tolerating an under or overvoltage for specified period of time, then a specified
critical voltage value will activate a voltage error.
Effects are :
Local under and overvoltage have an impact to external events. A corresponding deactivation or degradation is
declared with an executed event DTC with local over or undervoltage declaration. This only takes place if the
monitoring function is activated or if a system function is limited that can be perceived by the driver.
The item or its elements measures the local voltage supply by itself and is measured as long as this supply
voltage is needed for the specified element function. There can be multiple voltage thresholds for different
subfunctions of the element and the corresponding monitoring. However, in the element itself, there is only a
single local overvoltage DTC and a single local undervoltage DTC which can be read out.
b.2) Global Voltage
The item and its elements has many monitored signals that are made available via buses or lines by external
communication nodes. This includes monitoring functions such as range limits, plausibility checks, invalidities,
functional CRC checks, Alive checks, Time-Out Errors, etc.
Once a nother node enters an over or undervoltagestate, it will no longer be able to ensure the provision of
necessary signals. The E/E Sub-System is able to react to this communication error state and will set specifed
DTCs.
Since the voltage level is not the same throughout the total onboard network, certain nodes might determine
an under or overvoltage state while other nodes are unable to measure this which results in missing signals.
In order to prevent network error memory entries from being set in such cases, the E/E Sub-System and other
nodes are informed about an inadmissible voltage condition by means of a bus message.
The E/E Sub-System depends on the Central Voltage Monitoring Node with its power management function.
For undervoltage, a distinction is made between MSA engine start and Normal operation. For each of these
two cases, there can be a voltage drop which executes a evaluation whether the situation is normal because
of MSA or unnormal out of the specified voltage range.
For timing reasons, the voltage thresholds are permanently monitored and communicated by the Central Voltage
Monitoring function regardless of whether an engine start (MSA) is currently taking place or not. There is
only one specified over voltage threshold. This is also communicated and evaluated regardless of whether there
is an engine start or not. This signal is communicated on the vehicle bus to all nodes.
In addition to the standard dependent onboard nodes supplied by the common voltage supply system, there are
also independent nodes which are operated as primarily common voltage independent onboard electrical items
with their own voltage source.
These independent onboard electrical items also have an voltage monitoring function, which voltage status is
communicated via the onboard data network which influences the diagnostics of the standard dependent notes.
This voltage status is used accordingly in addition to the voltage status of the standard dependent onboard
nodes as an option.
All voltage message declarations are illustrated in the message catalog. Message file is also machine-readable.
In the case of a global voltage infringement, all items no longer enter their external errors because the error
is propably not caused by an item directly. Instead a DTC is set with thge info global under- or global overvoltage.
Global supply voltage measurement and main diagnose is carried out by the item on which the power
management functionality is implemented.
External Failures are :
• Local Voltage Errors
• Communication Errors of network monitoring
• Monitoring Errors of external electrical signals of items that have their own monitored voltage supply
b.2.1) Overvoltage
Voltages greater than 18 V and voltages between 16 V and 18 V for a specified period of time of more than
400 ms are considered to be overvoltages and will be noted by means of a bit.
b.2.2) Undervoltage
In some circumstances with a low battery supply voltage (Terminal 30) during normal operation when terminal
15N = On (IGN Switch behind supply power) and no engine start, not all items with there elements have
sufficient supply voltage to carry out all of their functions. A infringement of this thresholds is communicated
via a bit.
At an MSA start, the supply voltage (Terminal 30) is kept stable and thresholds are lower since not all functions
need to be available during the start process. A infringement of this thresholds is communicated via a bit.
b.2.3) Error Memory lock
As long as functions are not safety relevant and directly perceived by a driver. An error memory lock can
be overcome by precedence diagnostics.
c) Voltage threshold logic
Logic to be implemented for the detection and declaration of voltage infringements.
c.1) The following figure gives an overview of the voltage threshold item function :
Above Flow Diagram illustrates an example of logic architecture
Input Signals is an event DTC and some other specified data inputs. The output DTC is an event output according
to the input DTC.
The DTC flow is preliminary checked to see if it is dependent on a voltage state (1). If not, the DTC is passed
on without being changed, but can be blocked by an internal error memory lock (4) e.g. during start-up or terminal
change. If needed the DTC will be held back by the inhibitor (9) before passing on as an DTC output.
If the DTC is voltage depending error it is checked if it is an internal or external error (2).
If the central error memory barrier state is set and no driver perceivable degradation is present in
the E/E Sub-System an External Error can be blocked by the inhibitor (3). In this context, the degration
can be set by the driver input or an E/E Sub-System down stream input signal or an input from a nother
node. If not sure, a noticeable degradation of an external function is assumed and a CC Message and a
Error MIL indicates a degradation.
The internal error path and external error path is delayed by two delay blocks (5) & (6) and hereafter
stored into two separate error mapping blocks (7) & (8) (internal and external error mapping areas).
A Monitoring block (10) checks the local voltage supply U within the E/E Sub-System during a specified
caster time and provides an voltage infringement status of over or undervoltage to either of the both
mapping blocks.
All voltage thresholds are reseted if the caster time (11) & (12) expires.
c.2) Logical monitoring outputs :
• A logical output that specifies if the E/E Sub-System supply voltage is less than 9 V
• Furthr logical outputs for internal errors due to undervoltages that can cause functional problems
C.2.1) Voltage Status < 9 V (threshold limit 9 V)
Following figure for an undervoltage behavior example with a 9 V threshold limit.
Note the use of hysteresis for the voltage limits
as well as two debounce times and an additional
threshold with no debouncing.
The above behavior is specified by the E/E Sub-System as a SW-component type Statemachine.
The output voltage of the statemachine can be U < 9 V which would be specified in binary form and
reflects the logical undervoltage state with following topics :
C.2.1.1) Following fixed Threshold Parameters
In case the node with power manament implementation is replaced the parameters need to be adjusted.
Otherwise no change is required during run time or coding.
C.2.2) Specified Caster Time
A specified caster time delays a resets of logical voltage states.
For global voltage thresholds, the default time for a reset is 2000 ms.
For local voltage thresholds, the time is adjusted according the corrsponding functional needs.
C.2.3) Inhibitor
The Inhibitor (INH) will stop all Errors which have been detetected at the input if INH is assigned
as logical true :
• If an error is announced for the 1st time while INH is assigned True, the error it is not
passed on straight away.
• If an error is announced for the 1st time while INH is assigned False, it is passed on
straight away.
• If an error has been announced while INH = True, the error has not been withdrawn and
the INH is assigned to False and hereafter the error is passed on subsequently.
• If an error is reseted that has already been announced prior to INH = True, the error is
passed on and the error is no longer taken into account by the inhibitor.
• If an error is reseted that is actually being held back, then the error is no longer
considered by the inhibitor and is not passed on, even if the INH is reset to False.
C.2.4) Delay Time Block for internal errors and external errors
The E/E Sub-System and other nodes are informed about an inadmissible voltage condition by means of
a bus message. The global bits are sent at least 10 ms after the detection of the voltage state.
By taking into account the sub-delays via buses, gateways or the physical layers of the E/E Sub-System,
the worst-case communication delay from the occurrence of a voltage error to its detection by an element
of the item is less than 30 ms.
This means that the error memory element within the item is remapped to a global voltage state is
held back for at least 30 ms, even if the corresponding up stream monitoring element is much faster.
Thus, if the monitoring element will enter an undervoltage state itself which results in a reset,
the risk for the loss of the delayed and error memory entry is high. This is accepted because it is
better to have no error memory entry than an incorrect error entry.
Further the setting of errors with a debounce time of less or equal to 30 ms is delayed by this delay
block with a specified fixed delay of 30 ms. If the internal voltage measurement has even a higher
latency time, this duration is chosen for the delay when an voltage error is set.
The resetting of voltage errors is not changed by the Delay Time Block
C.2.5) Undervoltage thresholds for error mapping of internal and external errors
A monitoring element itself also has a voltage threshold. When the threshold is exceeded it can provide
a wrong detection due to this over or undervoltage.
Monitoring elements that are only useful in normal operation without engine starts, use the centrally
provided normal operation voltage threshold message to activate an undervoltage error situation.
Monitoring elements that are also active during MSA starts, use the central MSA start threshold message
to activate an undervoltage error situation.
Each of those voltage thresholds are considered and specified to individual DTCs.
The assignment to voltage thresholds is based on the specified monitored states or signals.
If a DTC cannot be clearly assigned to a MSA-Threshold or to a Normal-Operation-Treshold,
one DTC will be split into two unambiguous DTCs.
C.2.5.1) Error Mapping of Internal Errors
Internal errors are voltage-dependent. Monitoring functions within the item monitors elements
and power output stages. They do not including errors relating to coding monitoring or RAM/ROM
checks. Here the errors are detected within the scope of their active conditions and are declared
with no reference to voltage.
C.2.5.1.1) The following flow chart shows a general process to generate local and global DTCs:
C.2.5.1.2) Process how a error message (DTC IN) (event trigger) can be passed on in order to
replace error entries.
First (1) it is checked if the error is voltage dependent or not. If so, it is further checked
if an MSA Treshold (2) or Normal Operation Threshold (3) applies to it.
Then, the actual local voltage MSA threshold is evaluated if it is under (4) or over voltage (8)
or the threshold for normal operation is evaluated if it is under (5) or over voltage (8). If necessary,
this takes place in with different thresholds for (4) or (8) or (5).
If a local voltage infringement has been detected in (4) or (8) or (5), then it is further checked
whether this is due to a global or local voltage infringementin in (6) or (7) or (9).
Next the error is passed on and mapped to one of the following possible voltage errors:
• local undervoltage (10)
• local overvoltage (12)
• global undervoltage (internal) (11)
• global overvoltage (internal) (13)
An entry and correction monitor (14) pass on the DTC OUT after monitoring the time of error
entity with error replacement or error remaining needed after an MSA goes to normal operation
and vice versa.
C.2.5.2) Error mapping of External Errors
External errors are mostly network errors such as
• invalidities
• signal qualifier monitoring errors
• etc.
There can be other external errors, such as errors relating to the monitoring of a signal that is
physically transmitted via a dedicated path and has its own voltage supply. In the case of external
errors nothing is fixed directly on the entering item or its element (physical layer).
C.2.5.2.1) The following flow chart shows a general process to generate global DTCs:
C.2.5.2.2) Process how a error message (DTC IN) (event trigger) can be passed on in order to
replace global error entries.
First (1) it is checked if the error is voltage dependent or not. If so, it is further checked if an MSA Treshold (2) or Normal Operation Threshold (3) applies to it.
Global undervoltage thresholds are evaluated in (4) and global overvoltage thresholds are evaluated in (6).
If a global voltage infringement is perceived in (4) or (6), the error is stored to (7) global undervoltage
(external) or (8) global overvoltage (external). Otherwise, the error is directly passed on to an entry and
correction monitor (9).
An entry and correction monitor (9) pass on the DTC OUT after monitoring the time of error entity with error
replacement or error remaining needed after an MSA goes to normal operation and vice versa.
C.2.5.3) Entry and Correction Monitor
A DTC that has been set prior to an under or overvoltage DTC is always kept stored and it has been considered
that this DTC will not cause an additional voltage error because of an local or global under or overvoltage
state. In all cases only a voltage error will be stored if a voltage-dependent internal or external error is
out of the specified voltage range.
If an error has not been re-tested until the end of an specified caster time, it will be entered and re-tested
again. A re-test of an error during an undervoltage is permitted despite the following details:
• If the error itself has been entered prior to the voltage error it will be re-test
• If a voltage error is replacing a prior voltage error it will be re-test
C.2.5.4) Error Memory Entries
C.2.5.4.1) DTCs
There are 6 voltage-related DTCs with following error declarations:
• Local undervoltage • Global undervoltage - result of an internal error
• Global undervoltage - result of an external error
• Local overvoltage
• Global overvoltage - result of an internal error
• Global overvoltage - result of an external error
All voltage-related DTCs originate from the range of the item DTCs and its element DTCs.
Note for Event DTCs :
Upon receipt of an wrong voltage amplitude and in the case of a E/E Sub-System degradation which
the driver is able to notice the E/E Sub-System will execute a DTC as classified as an Event DTC.
They are declared and stored in the primary failure memory.
Note for Primary DTCs :
A primary DTC only and always occurs if there is a defect requiring a repair or a degradation
(e.g. CC message, warning light, function failure, driver is able to notice disturbance and
can not assign a reason to the degradation). All specified primary DTCs are linked to effective
and practicable workshop instructions.
Note for Functional degradation :
Functional degradation and Error Storing occurs synchronously.
C.2.5.4.2) Environmental Data for a Voltage Error
All voltage errors have at least the following environmental declaration :
• For a DTC that was re-mapped because of a voltage error can have both a DTC-Number
and an Internal-Error-Number. While using Internal-Error-Numbers, a list of all internal
Error Numbers have been specified for each program code version/variant.
• Pre state condition of vehicle supply voltage network (i.e. ST_CON_VEH) stored as default value
in E/E Sub-System before 1st voltage error detection.
• Starts with Voltage Dips (i.e. ST_UDP) at the time of voltage error detection
Status_Engine (i.e. ST_CENG_DRV) at the time of voltage error detection.
• Terminal voltages at the item withs elements used for local threshold determination.
• Number of the infringed local voltage threshold if there are versatile thresholds. Numbers have
been specified for each program code version/variant.
If environmental declaration is not available the E/E Sub-System sets Not Available.
a) Statistic Counters @ Service life
The program code includes code pieces as statistic counters. All counters will stop at a max. specified value without overflow.
When the E/E Sub-System receives a controlled turned off or during a soft reset the statistical data will be kept and stored in
the nonvolatile Flash-EEPROM. With a diagnostic service command all counters can be read by explicit messages per NetWork.
a.1) Voltage Statistics
• Absolute voltage counter value for HW-Elements
• 21 statistic voltage counters for HW-Elements
• 13 statistic Voltage counters for MSA Operation
a.2) Current Statistics
• Absolute currrent counter value for HW-Elements
• 11 statistic current counters for HW-Elements
• 7 statistic current counters for MSA Operation
a.3) Rack Endstop Statistics
• Store the max. measured value for the retention time within the right/left end stop limits
• 5 statistics retention time counters [%] for right end stop
• 5 statistics retention time counters [%] for left end stop
a.4) A.C. Motor Current Consumption Statistics
• Store the max. measured current per phase
• 5 statistics counters for max. phase current
• 5 statistics counters for degration current
a.5) Rotor Drive Shaft Speed Statistics
• Store the max. measured value for angular velocity of drive shaft
• 5 statistics counters for max. drive shaft speed
a.6) Thermal Statistics
• Store the max. and min. measured value for pcb temperature
• Store the max. and min. measured value for MOSFET Power Output Stage temperature
• 5 statistics retention time counters for max. pcb temperatures
• 5 statistics retention time counters for max. MOSFET Power Output Stage temperatures
a.7) Operation Statistics
• Store Overall operation time
• Store Overall operation milage
• Store operation time since last counter reset
• Store operation distance milage last counter reset
a.8) DTC Statistics
• Store DTCs
• Store DTC Counting
Following memory sizes are used:
Access Key for NV-RAM Data: 140 bytes
Authentication: Key Lenght 1024 bits
Signature: Key Lenght 1536 bits
Signature: Key Lenght 2048 bits for (A)-SIL D type
Signature: Key Lenght 2048 bits for immobilizer that prevents operation of the vehicle
a) A Public-Key encryption method is used to convert Plain-Text into Cipher- Text. Hereafter this encrypted message with the Public-Key is transmitted (Secure cryptographic protocol) to assigned recipients owning a Private-Key and the Plain-Text can be retrieved with this Private-Key by all E/E Sub-Systems which are owner of the Private-Key.
b) The RSA (Rivest-Shamir-Adleman as a asymmetric cryptographic procedure) consists of
3 elements (modulus N, public exponent e and private exponent d). Hereby the Public-Key is a pair of (N, e) and the
Private-Key is a pair of (N, d) with e as a public exponent and d as private exponents.
Both exponents are chosen in a way that every input number M is smaler than N [M < N],
meaning every result that is greater than N is divided by N and the rest is taken. The
modulus N = p · q is a large number that is a product of two prime factors (p, q).
c) The security of the RSA procedure relies on the fact that N is very hard to determine and that an attacker is not able to generate the factors p and q out of N to generate the Private-Key exponent d with the Public-Key exponent e. It is assumed that is practically impossible to find out about this secret Private-Key information.
d) Wit M < N the following main Equation is always true:
M = M(d · e) mod N = M(e · d) mod N.
The Private-Key exponent d can be determined with following known Information :
- Public-Key exponent e
- Prime Factors p
- Prime Factor q
Both exponents d and e have the relation d · e ≡ 1 (mod (p − 1)(q − 1))
e) Exampel :
If E/E Sub-System-A sends a message to E/E Sub-System-B, A needs the Public-Key pair (N, e) of B.
A encrypts the Message M with M < N by an operation E = M(e) mod N.
If B wants to decrypt the message M, B determines MD = E(d) mod N.
With the above main equation MD is equal M :
MD = (Md)e mod N = M(e·d) mod N = M
Now B wants to sign the message M received from A. Herby A can verify with the Public-Key of B that this signature message is trully from B.
B determines S = Md mod N
Herafter B sends M and S to A.
If A wants to decrypt this signature message M, A determines MV = Se = M(e·d) and can be sure that S was created with the Private-Key of B.
f) Basis for creating a digital signature is a Secure Hash Algorithm (SHA). The algorithm describes a group of standardized cryptological hash functions used to calculate a Check-Value for each digital message to ensures the integrity of a message.
The Hash-Function H = Hash(Message) is a one-way function mapping any input to an output of a fixed length. Now a collision resistance type Hash-Function has been implemented which means it is not possible for an attacker to generate two different inputs (M1, M2) which produce the same output Hash(M1) = Hash(M2) in a reasonable amount of time.
g) For public security feature a Hardware Security Module (HSM) has been implemented that safeguards and manages the keys and encryption/decryption functions for signatures and strong authentications. With the Hardware Security Module only secure onboard signals are used upon receipt. More specificaly the Signature of a Vehicle ID-Number is checked via a Sweeping Method (level SWT_LIGHT).
h) PSS (Probabilistic Signature Scheme) is a cryptographic signature scheme and RSA-PSS is an adaptation of this type.
PSS procedure takes the Input-Message and a Salt (Random Number) and runs both through a hash function.
This hash H is used as a preliminary beginning part of the output.
Then, a mask of H is determined, which has the length of the RSA modulus N minus the length of H.
This mask then compares the input with the salt and generates one output with an logical operator Xor that returns a true value if one, but not both, of its operands is true and call it maskedDB.
Hereafter maskedDB is appended to the hash H to generate the input for an adapted RSA function.
h.1) HW Relevant Security (PSS) for Tamper Protection and Resistance :
The HW is designed in a way that it is damaged, if you try to open it, so that it cannot be used anymore afterwards.
h.2) HW Relevant Security (PSS) for Back End :
A frontend program part and backend program part are used to describe layers where the driver has access to one level and the CarMaker has access to another level. Frontend components face the driver, while the rights for the backend only apply to CarMaker staffs. Functions have been implemented if the µC is needed to be uniquely identified via Backend.
h.3) HW Relevant Security (PSS) for Critical Code Pieces and Data
A Secure Hardware Module (SHM) is used for TEE (Trusted Execution Environment) as a secure area of the µC. Accessing critical code pieces and data within the operating system is isolated from others.
h.4) Security (PSS) for Dynamic and Static Data Protection
The µC securely stores static data for following base use cases :
- Secure Storage of VIN
- Secure serial number (Not changeable)
- Country
After initializing of static data during manufacturing or Service the data can be locked by using a Diagnostic Job (DIAG_LOCK_DATA). A DTC (DTC_DATA_NOT_LOCKED) is stored in case the data has not been locked. Protected data can be change by backend features.
h.5) Security (PSS) for Application Protection
A security monitor application is implemented to detect and protect against manipulation attacks at startup and run time. If any malfunction of the security monitor which runs as TEE occurs, the main function of the E/E Sub-System will remain normally and safe.
Security Monitoring with active and passive reaction for detected manipulations are part of the Security-Concept :
- Check the integrity of the security artifacts
- Check the integrity of software units and applications
- Monitor, if an application tries to consume more than max allowed resource defined for the application (e.g. RAM, Processing time, etc.).
- Secure Boot Errors with Hardware Security Module (HSM)
- Secure VIN on the Bus taht does not match with stored VIN
- Periodical checks of activated software units
Active Reaction :
- Manipulated code pieces are not used and run in emergency mode
- Limited vehicle functionalities (limp mode with 20% steering support)
- Appropriate error displaying
- Some Processes are terminated
- Some functions are disabled
- Some software units are deactivated
Code Switches
Different functional conditions are grouped together and can be activate or
passive per adjustable bit-code.
• functional condition passiv
• functional condition activated
Switch during Runtime
A corresponding parameter with the same coding exist for each code switch,
so that functional conditions can also be activated and deactivated during
runtime.
Functional Selection
A Word (unit8) will provide all conditional informations for following
5 main functional sub-groups
1. EPS steering functions
2. EPS protection functions
3. EPS compensation functions
4. EPS degration functions
5. EPS additional functions
EPS Steering Functions
Bit-coded switch (=parametrization)
Datatyp: Word (uint8)
Default : Binary 0000 1111 , 15 Decimal, Hex = F
Bit 0: Process Net Mechanical Power Output corresponding to Iq (q-Vector)
Bit 1: Process Active Return
Bit 2: Process not named
Bit 3: Manipulate steering hysteresis
Bit 4: not assigned
Bit 5: not assigned
Bit 6: not assigned
Bit 7: not assigned
EPS Protection Functions
Bit-coded switch (=parametrization)
Datatyp: Word (uint8)
Default : Binary 0011 0101 , 53 Decimal, Hex = 35
Bit 0: not assigned
Bit 1: not assigned
Bit 2: not assigned
Bit 3: Damping
Bit 4: Freezing
Bit 5: Thermal
Bit 6: Current
Bit 7: not assigned
EPS Compensation Functions
Bit-coded switch (=parametrization)
Datatyp: Word (uint8)
Default : Binary 0011 0111, 55 Decimal, Hex = 37
Bit 0: Compensate friction
Bit 1: Compensate pull and drift
Bit 2: Compensat hand wheel vibration
Bit 3: Compensate I-shaft torsion
Bit 4: Compensate inertia of steering assembly
Bit 5: Compensate hand wheel inertia
Bit 6: not assigned
Bit 7: not assigned
EPS Degration Functions
Bit-coded switch (=parametrization)
Datatyp: Word (uint8)
Default : Binary 0000 0111, 7 Decimal, Hex = BF
Bit 0: not assigned
Bit 1: not assigned
Bit 2: not assigned
Bit 3: not assigned
Bit 4: not assigned
Bit 5: not assigned
Bit 6: not assigned
Bit 7: not assigned
EPS Additional Functions
Bit-coded switch (=parametrization)
Datatyp: Word (uint8)
Default : Binary 1011 1111, 191 Decimal, Hex = BF
Bit 0: Manipulate command input as overlay
Bit 1: Manipulate net power output
Bit 2: Manipulate dynamic factors
Bit 3: Manipulate additional damping acting to the stearable front axle
Bit 4: Manipulate hand wheel vibration
Bit 5: The Race Is On
Bit 6: not assigned
Bit 7: MSA
Received Explicit Messages
All explicit messages can be received at least within T ≤ 30 ms.
Messages that need to be available per NetWork Messages
• per NetWork Message : IGN Clamp 15N = 1 (ON) or 0 (OFF)
• per NetWork Message : Absolute Vehicle Heading Speed Vvehicle
• per NetWork Message : Absolute Steering Angle αabs
• per NetWork Message : Vehicle Operation Modes
• per NetWork Message : Vehicle Degration Modes
Others
• per NetWork Message : Safety Conditions
• per NetWork Message : Environmental Conditions
• per NetWork Message : Road Conditions
• per NetWork Message : Others
Vehicle Speed Ranges
Logical expressions If…Then… are connected to the input variable Vvehicle.
They depend on the following 3 Vehicle Speed Ranges
• Near to Stop (absolute Vvehicle < 3 km/h)
• Rolling (3 km/h ≤ abssolute Vvehicle ≤ 10 km/h)
• Driving (absolute Vvehicle > 10 km/h)
Assignment for absolute Vvehicle
Only (+) assigned Speed Variables are accepted.
Gradient for VEPS
In order to exclude large jumps of the variable VEPS, the gradient is limited.
If VEPS is out of the limited range, a substitute for VEPS is selected.
External Input Signals
All external hardwired analog signals can be converted within a time span of at least T ≤ 2 ms.
The transducer provides an voltage that corresponds to a particular measurement value, such
as torque, angulare position, temperature or the phase current per shunt as a low-resistance
resistor that is connected in parallel to the phase clamps. These elec. signals are converted
to a binary 16 bit data per µC port (Voltage/Data Link) and hereafter provided and stored into
specified memory cell areas.
Off Mounted Transducer
The transducer provides an elec. reference voltage that corresponds to a
• column torque measurement value per torsion bar
• column absolute angle measurement value per angle sensor
The specified transducer I/O performance may be stated in following forms
• Frequency-Domain to specify stability
• Time-Domain to specify response and allowable error (accuracy)
Hand Wheel Torque Input incl. inertia (Command Signal)
The actual column torque affects the controlled activated Power Output. The column transducer is
required between the phys. column torque imput per torsion bar and the converted elec. reference
signal to the corresponding Voltage/Data Link (µC pin/port)
Absolute Steering Angular Input (absolute column rotation αAbs for Position Control-Path)
The column transducer is required between the phys. total angular rotation of the column and the
converted elec. reference signal to the corresponding Voltage/Data Link (µC pin/port). The
total turns of the column rotation αAbs compared to the rotor rotation δAbs.
Both are used to determine the absolute rack position YAbs corresponding to the angular
position of the wheels/tires.
Off-Line Approach for Tranducer-Model
Model both transducer behaviours by creating a Transducer-Module with 2 processes that specify both
conversion functionalities with characteristic convertion fields. The input variable for the process
is maped as an receive-message and the output value is maped as a send-message.
Note
The relationship between measured values and the voltage values are not always linear.
Therefore a characteristic transducer table is used to model this behaviour efficiently.
Time Critical Sampling Rates
To simulate the transducer signals, create and define module events per specified cyclical task for
both processes and send the reference data to the specified input port of the µC-ECU-Modul
• Periodically task TRQ_sampling (preemtive) within 2 ms and assign to the process TRQ_Transducer
• Periodically task CAA_sampling (preemtive) within 2 ms and assign to the process CAA_Transducer
Control Flow per Main EPS States
• Supply Voltage State
• Stabilized Supply Voltage State (enable hardware platform)
• Power Output Ready State (wake up with initialization of SW)
• Plausibility State of Terminal IGN 15N
• Near to Stop State (vehicle speed signal < 3 km/h)
• Rolling State (3 km/h ≤ (vehicle speed signal ≤ 10 km/h)
• Driving State (vehicle speed signal > 10 km/h)
• Detection State of an unavailable vehicle speed signal
• Detection State of an unavailable vehicle speed signal & a wrong operation mode
• Detection State of an unavailable speed signal & a wrong operation mode & no torque transducer signal
• Critical Failure Mode State
• Lock Primary DTCs State
• Clear Primary DTCs State
• Clear Degration State
• Lock Degrations State
• Internal State Messages
• Degration State
• Partial Availability States
• Failure States
EPS Implicit & Explicit States
All implicite state transitions can be set within a time span of T ≤ 1 ms,
while all explicit state transitions can be set within T = 20 ms.
Voltage Supply States
Battery Pols
• Common Ground per Negative Bat Clamp 31 (-)
Note
Galvanic isolation with resistance > 100 KΩ to the Common Vehicle Ground
• Permanent Voltage per Positive Bat Clamp 30 (+) for high current bridge supply voltage Udrain = ON)
• Battery Key Switch (IGN 15N) located behind supply power Bat 30 (+) and switch by a Relay.
Note
Relays are designed as semiconductor elements
IGN 15N considers the following Clamp States
• Bat Clamp 30 (12V Supply Power)
• Bat Clamp 30F (12V Supply Power switched off for Low Battery)
• Bat Clamp 30B (12V Supply Power switched on for Hazard Warning)
Voltage Regulator
IGN Clamp 15N = 1 (PCB ON) provides 6V … 12Vnominal … 15V to a Voltage-Regulator,
that supplies the µC and its peripheral circuit components and sensors with internal
stabilized 5V. The Voltage Regulator protects against irreparable damage as a result
of overvoltages or short power circuits.
Impetance of Terminal IGN Clamp 15N against ground is less than 5 KOhm
IGN Clamp 15N = 1 (PCB ON) is used to wake-up the Voltage Regulator
Following stabilized voltage bandwidth of the PCB supply
• ON : 4 V ... Voltage ... 5.5 V
• OFF : 2 V ... Voltage ... 3 V
Reverse polarity protection for Voltage Regulator
To protect the voltage regulator from damage, a transistor circuit is used. The FET with its own diode becomes conductive
when a specified supply voltage is applied to the gate input and blocks the current via the own diode in case of a wrong
polarity (short circuit) and is thus not conductive for all supplied components. The specifed inserting resistor and diode,
limits the max. voltage at sufficient current.
Check plausibility of an active IGN 15N = 1 (PCB = ON) with a State that indicates an activated or an deactivated motor drive.
With PCB = 1 (PCB ON) and Motor Drive = 0 (OFF), a counter starts counting a timer up to 60 min
• When timer reaches 60 min without Motor Drive = 1 (ON), the timer sets an Inactive State
• A DTC for an assumed Terminal IGN 15N plausible failure mode is set
• A warning object for No Power Output Ready State is send
• At the next initialisation, re-check plausibility again
Voltage States per NetWork Messages (Focus On Hardware)
Following switched voltage states, that can be send on the vehicle NetWork
• per NetWork Message : PCB OFF (Switched IGN Clamp 15N = 0 (OFF) with decoupled phase clamps = normally open)
• per NetWork Message : PCB ON (Switched IGN Clamp 15N = 1 (ON) with coupled phase clamps = closed)
• per NetWork Message : Power Output Ready State = 1OFF with a deactivated Motor Drive = OFF
• per NetWork Message : Power Output Ready State = ON with a activated Motor Drive = ON
States that need to be available for functionalities
All basic control functions require the following physically and logically switched voltage
states in order to operate
• Power Output Ready State = ON
• Motor Drive = ON
• Assist Off : Binary 1110 0000 , Decimal 224, Hex E0
• Assist _On : Binary 1001 0000 , Decimal 144, Hex 90
With Power Up the time scheduling for tasks are called by RTOS. Monitoring processes starting
and an Alive Message introduces the E/E Sub-System to the logical ring algorithm and interpretes
a related specified registration (wake up registration is an option).
A monitoring process POWER-LOSS P(mW) = U(V) @ I(mA) diagnoses the circuit during HW
and motor drive initialization.
• FET voltage drop between Source and Drain (V)
• FET drain current flow (mA)
• Current will only flow true the diode when the supply voltage is connected with correct polarity
Operation States
Power Up State (enable with initialization of HW)
Logical expressions If…Then…Else… are connected to input variables to detect
the actual operation state and select the specified control action.
Initialization State (enable with initialization of SW)
Boot up RTOS code piece and initialisation of SW processes defined by a set
of tasks that are active during the initialisation and consists of 2 phases.
The 1st phase is a wake-up task. With this the initialization routines of
the application layer is processed. During this phase, a self-diagnostic
check is processed to detect possible errors.
Power Output Ready State
If no error is detected, the 2nd phase starts with activation of Task A
with its power output ready processes (PCB = 1 (ON)) in combination with
interupt hardware sequences for the Motor Drive = 0 (Off) and the Phase
Isolation Relays (deactivated = phases normaly open = deactivated motor)
Operation States
Only one application mode with a set of tasks can be active at a time. If no Power
Output Degration is active, all related basic functions can be active and transfers
to following states
• Driver Comand Input State (torque applied to the hand wheel)
• Near to Stop State (abs Vvehicle < 3 km/h)
• Rolling State (3 km/h ≤ abs Vvehicle ≤ 10 km/h)
• Driving State (abs Vvehicle > 10 km/h)
Near to Stop State (vehicle speed signal < 3 km/h)
If Power Output Ready State is set and the absolute vehicle speed signal (V_VEH_COG) < 3 km/h the Near to
Stop State is set. Remain PCB = ON and transfers to the Motor Drive = OFF (deactivated a.c. motor power
output).
Rolling State (3 km/h ≤ (vehicle speed signal ≤ 10 km/h)
If Power Output Ready State is set and the absolute vehicle speed signal (V_VEH_COG) ≥ 3 km/h and the absolute
vehicle speed signal ≤ 10 km/h the Rolling State is set. Remain PCB = ON and transfers to the Motor Drive = ON
(activated a.c. motor power output).
Driving State (vehicle speed signal > 10 km/h)
If Power Output Ready State is set and the absolute vehicle speed signal (V_VEH_COG) > 10 km/h the Driving State
is set. Remain PCB = ON and transfers to the Motor Drive = ON (activated a.c. motor power output).
Caster State with controlled power down
If turned off, or in case of an serios error, transfers to one of following states
• Controlled Power Off State (store necessary data to Flash-EEPROM and Ramp Down to Sleep)
• Degration State (low energy)
• Reset State (undesired loss of RAM-Areas)
Configuration States
Activate or Deactivat basic functions can be handled per special code switches (data bits)
and/or alternative per specified parameter.
Failure Mode States
Detection State of an unavailable vehicle speed signal
If the absolute vehicle speed signal (V_VEH_COG) is not available but the speed qualifier (QU_V_VEH_COG) is valid,
then remain PCB = ON and transfers to the Motor Drive = ON (activated a.c. motor power output) as long as the Near
to Stop State is not set.
Detection State of an unavailable vehicle speed signal & a wrong operation mode
If no speed state and no operation state is available, then the torque transducer signal is taken into account.
If the transducer shows a manual hand wheel torque of ≤ 2 Nm or a torque gradient ≤ 2 Nm per Seconds, then remain
PCB = ON and Motor Drive = ON (activated a.c. motor power output).
Critical Failure Mode States
In case of a safety related failure the degration takes place per DTC priorities and is notified to the driver per
Warning (e.g. MIL). If a random HW error and/or SW error results in an incorrect torque signal that can cause a
serious functional safety problem, the Safety Module is activated.
Partial Availability State
If the power output is not within a range of 30 %, which results e.g. from an untypical handwheel behavior, a state
of partial availability is set. A message via the vehicle network to execute a yellow MIL is send (exception MSA).
Power Output Degration State
The basis for the elec. output torque (Nm) at a certain rotor speeds (rpm) is related to the current consumption I(A) per
motor phase. The phase current I(A) as feed back path is measured per shunt and hereafter converted into digital flux
data (Id) and digital torque data (Iq). In case of a safety related failure a degration of the power output takes place per
DTC priorities. A Degradation State value indicates whether a threshold value for Id or Iq has been undercut (power
output < 20 %). A message via the vehicle network to execute a yellow MIL is send (exception MSA).
I) For Failures that can be accommodated by the monitoring and were the error handling can still maintain a
safe operation a Limp-Home Task is provided that Remain PCB = 1 (ON) and transfers to the Motor Drive = 1 (ON)
with 20 % elec. power output, in order to reach a workshop
II) For Failures that can be accommodated by the monitoring but were the error handling cannot maintain a safe
operation a Limp-Aside Task is provided that remains PCB = 1 (ON) and transfers to the Motor Drive = 0 (OFF) with
~ 0 % elec. power output, in order to limp aside. If safety relevant failure is detected that can cause a serious functional
safety problem, a Safety Shut Off Interrupt Routine is activated per RTOS, that decouples the phase voltages by
deactivating the isolation relays (deactivated = phases normally open). A message via the vehicle network to execute
a yellow MIL is send.
Detection State of an unavailable speed signal & a wrong operation mode & no torque transducer signal
If no speed state and no operation state and no torque transducer signal is available for at least 5 minutes, then
remain PCB = 1 (ON) and Motor Drive = 0 (OFF) (deactivate a.c. motor power output).
States after Lock or Clear DTCs or Degrations
State after Lock Primary DTCs
Primary DTCs for specified failure modes such as Dead Battery or No Battery Connection, .., etc. is store to Flash-EEPROM
and can be read per diagnostic service request.
State after Clear Primary DTCs
If no error is detected during PCB = ON and Motor Drive = ON and if transmitted to Motor Drive = OFF the power output ready
state is set. With next Terminal IGN 15N cycle a corresbonding primary DTC is cleared.
State after Clear Degration
If no error is detected during PCB = ON and Motor Drive = ON and if transmitted to Motor Drive = OFF the power output ready
state is set. With next Terminal IGN 15N cycle a corresbonding degration is cleared.
State after Lock Degrations
If the monitoring process randomly detects toggling or bouncing that can be recogniced by the driver or detects a permanent
safety relvant failure, all associated restrictions calling for degration are set and permanent locked. This permanent 20 %
locked limp home degration improves emergency handling of the car for the driver and can only be diagnosed and cleared with
a workshop visit with following locking topics :
• Special DTC for permanent lock that can be read per diagnostic service request
• Counter for permanent locks that can be read per diagnostic service request
• Send global DTC-Object with a certain ID that can display a warning to the driver
Driver Actuating Signal required to Command the EPS Power Output
The control signal (Error-Signal), is the algebraic sum consisting of the manual steering torque to the Hand-Wheel
Plus or Minus the actual Car Heading Direction.
Required Power Supply States
• Battery Pols (+) (-) connected (Ground Bat Clamp 31 & Permanent Bat Clamp 30 for high current bridge supply voltage Udrain = ON
• PCB OFF (Switched IGN Clamp 15N = 0 (OFF) with decoupled phase clamps = normally open)
• PCB ON (Switched IGN Clamp 15N = 1 (ON) with coupled phase clamps = closed)
Note
• A permanent transducer supply is handled per 5 VDC Voltage Regulator
• EEPROM stored code and data may be lost if Bat Clamp 30 is interrupted for long time
• Supply power back up by permanent Bat Clamp 30
Status Driver Activity
The status of driver activity indicates Active_Driver by default without restrictions, and remains in this
Active_Driver state for the duration tSurplus_Driver_Active even without driver activity.
Input Variables
• EPS State
• Comand Input TRQ
• Driver-Hand-Wheel-Torque (Calculated)
• Status Driver Activity
• Degration State
• Freeze State
• Qualifier Vehicle Speed
• Vehicle Speed VVehicle
• Assist-Off Vehicle Speed VVehicle
• Vehicle State
Output Variables
• Motor Drive State
• ECU State (Voltage Regulator & µC & peripheral components)
• Qualifier_EPS_Function
Detect Driver Activity
If
....... the Relative Driver-Hand-Wheel-Torque has changed within a period of t = 100 ms by absolutely more than
........the value of Threshold TColumn_Rel [e.g. 0.2 Nm ]
........then
........Status Driver Activity indicates Active_Driver
Else
....... the Relative Driver-Hand-Wheel-Torque has not changed within a period of t = 100 ms by absolutely more than
........the value of Threshold
........then
........Status Driver Activity indicates Passiv_Driver after a duration tSurplus_Driver_Active
End If
EPS State
Total Torque = ∑Tcolumn = + Driver-Hand-Wheel-Torque - J×d²ω/dt² - Tμ×dω/dt + syncronous a.c. motor power output
IF
the Total Torque = ∑Tcolumn > Threshold TColumn_Abs [e.g. 2 Nm]
then
EPS_State Active
ELSE
EPS_State Passiv
END IF
ECU & Motor Drive Condition States (Focus On Software)
Following States
- ECU Off State
- ECU On State && Motor Drive Off State
- ECU On State && Motor Drive On State
Simplified state semantic:
If
Both Battery Pols Connected
then
Transition between Terminal 30 and Terminal 15N
........If
........Terminal 15N = 0 (open [+ 12 V] ign-switch behind battery)
........then
........ECU OFF State
........Output Qualifier_EPS_Function not jet send
........&& Output stage for the 3 motor phases is de-energized
........Else If
........Terminal 15N = 1 (close [+ 12 V] ign-switch behind battery)
........then
........Transition between ECU Off State and ECU On State
........• Wake-Up
........• Initialisation and activate ECU On State latest after t = 100 ms
........ECU ON State
........Transition between Motor Drive OFF State and Motor Drive ON State
.............If
.............Motor Drive OFF State
.............Output Assist_Off : Binary 1110 0000, Decimal 224, Hex E0
.............&& Output stage for the 3 motor phases is de-energized
.............then
....................If
....................EPS-State indicates Dec 1 (Failure)
....................then
....................Output Qualifier_EPS_Function sends string Function-Not-Available-EPS-Failure is interpreted as a value (Literal)
....................Else
....................EPS-State indicates Dec 0 (No Failure Dec)
....................then
....................Output Qualifier_EPS_Function sends string Function-Not-Available-EPS-OFF is interpreted as a value (Literal)
............................If
............................Vehicle State = Hex 0x8 (=Driving)
............................then
............................Transition between Motor Drive OFF State and Motor Drive ON State
............................Motor Drive ON State
............................Output Assist_ON : Binary 1001 0000 , Decimal 144, Hex 90
............................&& Output stage for the 3 motor phases is energized
....................................IF
....................................Freeze State sends string Steering-Not-Frozen interpreted as a values (Literal)
....................................&&
....................................Degration State sends string Degration-Not-Active interpreted as a value (Literal)
....................................&&
....................................Qualifier Vehicle Speed is valid
....................................&& VVehicle > Assist_Off_VVehicle
....................................then
....................................Output Qualifier_EPS_Function sends string Function-Available-EPS-ON-Motor-Drive-On-12V interpreted as a values (Literal)
....................................&& Output stage for the 3 motor phases is energized
....................................Else If
....................................Freeze State sends string Steering-Not-Frozen interpreted as a value (Literal)
....................................&&
....................................Degration State sends string Degration-Active interpreted as a value (Literal)
....................................then
....................................Output Qualifier_EPS_Function sends string Function-Temporary-Available-EPS-Degration is interpreted as a value (Literal)
....................................&& Output stage for the 3 motor phases is de-energized
....................................Else IF
....................................Freeze State sends string Steering-Frozen interpreted as a values (Literal)
....................................&&
....................................Degration State sends string Degration-Active interpreted as a value (Literal)
....................................then
....................................Output Qualifier_EPS_Function sends string Function-Temporary-Available-EPS-Thermal-Degration is interpreted as a value (Literal)
....................................&& Output stage for the 3 motor phases is de-energized
....................................Else IF
....................................Motor-Drive-State indicates a Failure
....................................then
....................................Transition between Motor Drive ON State and Motor Drive OFF State
....................................Else IF
....................................Qualifier Vehicle Speed is valid
....................................&& VVehicle ≤ Assist_Off_VVehicle
....................................&& Vehicle State ≠ Hex 0x8 (≠Ready to Drive)
....................................then
....................................Transition between Motor Drive ON State and Motor Drive OFF State
....................................Else IF
....................................Qualifier Vehicle Speed is replaced for car stoped (4d)
....................................&& Vehicle State ≠ Hex 0x8 (≠Ready to Drive)
....................................Transition between Motor Drive ON State and Motor Drive OFF State
....................................Else If
....................................Qualifier Vehicle Speed is replaced for no information (14d)
....................................&& Vehicle State ≠ Hex 0x8 (≠Ready to Drive)
....................................&& Status Driver Activity (Passiv)
....................................then
....................................Transition between Motor Drive ON State and Motor Drive OFF State
....................................Else
....................................Terminal 15N = 0 (open [+ 12 V] ign-switch behind battery)
....................................then
....................................Execute Brack State
....................................End If
............................End If
....................End If
.............End If
........End If
Break State = Return to Terminal 15N = 0 (open [+ 12 V] ign-switch behind battery)
During the Power Down transition necessary actual RAM data is stored to the non-volatile EEPROM.
End If
Formats & Parameters (ASAM A2l-File)
Assist Off
• Binary 1110 0000 , Decimal 224, Hex E0
Assist ON
• Binary 1001 0000 , Decimal 144, Hex 90
Parametrisation
Assist_Off_VVehicle
• Unit : (km/h)
• Default Value : 3 (km/h)
• Value Range : 0 ... + 10 (km/h)
• Minimum Resolution : 1 (km/h)
Threshold for Hand Wheel Torque TColumn_Rel
• Unit : (Nm)
• Default Value : 0.1 (Nm)
• Value Range : 0 ... + 2 (Nm)
• Minimum Resolution : 0.01 (Nm)
Threshold for Hand Wheel Torque ∑Tcolumn
• Unit : (Nm)
• Default Value : 3 (Nm)
• Value Range : 0 ... + 5 (Nm)
• Minimum Resolution : 0.1 (Nm)
Threshold for Hand Wheel Torque Duration tSurplus_Driver-Active
• Unit : (s)
• Default Value : 300 (s)
• Value Range : 0 ... +600 (s)
• Minimum Resolution : 1 (s)
Evaluation, Treatment, Quality, Safety and Parametrisation of Input Variables
• Absolute Vehicle Speed Vvehicle
• Rotor Angular Rotation δAbs
• Absolute Column Angle α for straight-ahead alignment
• Absolute Column Angle Velocity ω
• Column Torque Tcolumn
• Rack Force FEPS and FNetRack
• Friction Load Fμ acting on the steering assembly
• Command Input TQR to generate rotor drive shaft output TDrive-Shaft
• Battery Supply Voltage for High Current Consumption of synchronous a.c. motor
• Electrical Power Consumption Pelec = U(V) × I(A) × cos(φ)
• Mechanical Power Output Pout = T(Nm) × N(rpm)
• Rotor Drive Shaft Torque T(Nm)
• Rotor Drive Shaft Speed N(rpm)
1) Absolute Vehicle Speed Vvehicle
Message that need to be available per NetWork Messages T ≤ 20 ms
Required Power Supply States
• Battery Pols (+) (-) connected (Ground Bat Clamp 31 & Permanent Bat Clamp 30 for high current bridge supply voltage Udrain = ON
• PCB OFF (Switched IGN Clamp 15N = 0 (OFF) with decoupled phase clamps = normally open)
• PCB ON (Switched IGN Clamp 15N = 1 (ON) with coupled phase clamps = closed)
Note
• A permanent transducer supply is handled per 5 VDC Voltage Regulator
• EEPROM stored code and data may be lost if Bat Clamp 30 is interrupted for long time
• Supply power back up by permanent Bat Clamp 30
The Input Group checks, whether the data block for the Speed Vvehicle contains transmission
errors (CRC, Alive,..) and whether the input variable is qualified for the following speed ranges
• Vehicle Stoped with Speed VVehicle = 0 km/h
• Vehicle Near To Stop with Speed VVehicle less than 3km/h>
• Vehicle Rolling/Driving with Speed VVehiclegreater than 3 km/h
• No Speed VVehicle Information
Input Speed variable with 2 Input States
• Speed VVehicle
• Qualifier Speed VVehicle
• Qualifier Speed VRange
Output Speed Variable and 2 Output States
• Speed VVehicle
• Qualifier Speed VVehicle
• Parametrisation Speed VVehicle
Error Handling
Following diagnostic trouble codes (DTC) with following prioritization
1. Hardware Error (highest priority)
2. Under/Overvoltage Error
3. Bus Communication Error
4. Timeout Error or Event Error (absence time)
5. Cyclic Redundancy Check Error (CRC-Error)
6. Alive Error (variable is not up to date)
7. Variable is Invalid or Qualifier is Invalid
8. Variable is Undefined or Qualifier is Undefined
9. Variable Quality is Not Sufficient or Qualifier Quality is Not Sufficient
10. Functional Error (lowest priority)
Control Flow for 4,5,6,7,8 and 9
The control flow with its conditional statements is used to select an outgoing branch and writes the value of the output to an memory cell
if its own CRC calculated value matches the transmitter CRC value and the received data block contains no data errors.
Note: Timeout Error or Event Error (absence time)
If (4) occurs as a result of a Bus Communication Off, (3) as a Bus Communication Error is set.
If (4) occurs due to an undervoltage, error handling is delayed by an adjustable latency to check whether a global undervoltage is present.
If (7) occurs due to an timeout e.g. during initialisation of an transmitter node as a result of a power loss reset, only a Timeout Error is set.
Otherwise each input variable has branches assigned to Valid or Invalid or Quality is Not Suffcient with help of following possible
logical expressions
• If…Then
• ElseIf…Then
• Else…Then
• Switch…
• Case…
• Default…
• While…for
• Brake…
State Diagram (SW-Glass)to check the validity
If Motor Drive = OFF, the Start State with its Entry, Static, Exit values is in a waiting state. When Motor
Drive = ON, the Start State is enabled and a trigger event occurs every 20ms to check 7 different conditional
questions according to the priorities set there. If a condition is met, a transition is available to that segment
with its entry, static and exit action. If all conditions are met, the transition from the output junction to the
Start State has the condition [valid]/action per trigger event and the Start State provides its Exit action.
General form of simple conditional constructions of If…ElseIf…Else statements to check Speed VVehicle
The input variable is checked with different conditions of boolean expressions, that must be true for specified state transitions
Hex, Dec and Bin Speed Statse
__0d __13 ___000000000000 1101 n.a.
__1d __29 ___0000000000011101 Speed VVehicle is valide, proved and plausible
__2d __45 ___0000000000101101 Speed VVehicle is valide
__3d __61 ___0000000000111101 n.a.
__4d __77 ___0000000001001101 Speed VVehicle is replaced for Stop Situation
__5d __93 ___0000000001011101 n.a.
__6d _109 ___0000000001101101 n.a.
__7d _125 ___0000000001111101 n.a.
__8d _141 ___0000000010001101 n.a.
__9d _175 ___0000000010011101 Speed VVehicle is temporary valide with medium signal quality
_10d _269 ___0000000100001101 Speed VVehicle is temporary valide with medium signal quality, but Qualifier αRelAngularRotorShaft is Invalide
_11d _285 ___0000000100011101 n.a.
_12d _301 ___0000000100101101 Speed VVehicle is Near to Stop
_13d _317 ___0000000100111101 Speed VVehicle is Rolling/Driving
_14d _333 ___0000000101001101 Speed VVehicle is replaced for No Information
_15d _349 ___0000000101011101 n.a.
Conditions to check if Speed VVehicle is Valide
Speed VVehicle is Valide,
If
there is No TimeOut-Error on the Message Frame
Else If
there is No Alive-Error on the Message Frame
Else If
there is No CRC-Error on the Message Frame
Else If
the Qualifier Speed VVehicle is equal to 1d
Else If
the Qualifier Speed VVehicle is equal to 10d and Qualifier Relative Angle of Rotor Rotation αRelAngleRotorShaft is equal to 1d,2d,9d or 10d
Else If
the response time = 200ms to change the Qualifier Speed VVehicle from 10d to 1d
Else
the dwell time is 300ms for Qualifier Speed VVehicle is equal to 10d and Qualifier Relative Angle of Rotor Rotation αRelAngleRotorShaft is equal to 1d,2d,9d or 10d
End If
Conditions to check if Speed VVehicle is Invalide with a Error Tolerance Time = 100ms
Speed VVehicle is Invalide,
If
there is an TimeOut-Error on the Message Frame
Else If
there is an Alive-Error on the Message Frame
Else If
there is an CRC-Error on the Message Frame
Else If
the Qualifier Speed VVehicle is not equal to 1d
Else If
the Qualifier Speed VVehicle is not equal to 10d
Else If
t > 300ms for Qualifier Speed VVehicle is equal to 10d and Qualifier Relative Angle of Rotor Rotation αRelAngleRotorShaft is not equal to 1d,2d,9d or 10d
Else
Speed VVehicle is Invalide for 100ms then replace with last stored valid Speed VVehicle
End If
Conditions to check if Speed VRange is equal Near to Stop
Speed VRange is equal Near to Stop,
If
there is No TimeOut-Error on the Message Frame
Else If
there is No Alive-Error on the Message Frame
Else If
there is No CRC-Error on the Message Frame
Else
the Qualifier Speed VRange is equal to 12d for Near to Stop
End If
Conditions to check if Speed VRange is not equal Near to Stop with a Error Tolerance Time = 100ms
Speed VRange is not equal Near to Stop,
If
there is an TimeOut-Error on the Message Frame
Else If
there is an Alive-Error on the Message Frame
Else If
there is an CRC-Error on the Message Frame
Else If
the Qualifier Speed VRange is equal to 13d for Rolling/Driving
End If
Else
Speed VRange is Invalide for 100ms then replace with last stored valid Speed VRange
End If
Vehicle Speed Input- and Output Nodes
Speed VVehicle Stoped
Entry1 = Speed VVehicle = 0 km/h
Entry2 = Qualifier Speed VVehicle = 4d
Entry3 = Qualifier Speed VRange = 12d
Exit1 = Speed VVehicle = Replacement for Stop
Exit2 = Qualifier Speed VVehicle = 4d (Replacement)
Exit3 = Parameter
Speed Replacement = Speed VEPS parameter for Near to Stop (HonkyTonk) are used
Speed VVehicle Valid for Near to Stop
Entry1 = Speed VVehicle < 3 km/h
Entry2 = Qualifier Speed VVehicle = 1d
Entry3 = Qualifier Speed VRange = 12d
Exit1 = Speed VVehicle = Near to Stop (HonkyTonk)
Exit2 = Qualifier Speed VVehicle = 1d (HonkyTonk)
Exit3 = Parameter
Speed VVehicle Valid for Rolling/Driving
Entry1 = Speed VVehicle >= 3 km/h
Entry2 = Qualifier Speed VVehicle = 1d
Entry3 = Qualifier Speed VRange = 13d
Exit1 = Speed VVehicle = Rolling/Driving (HonkyTonk)
Exit2 = Qualifier Speed VVehicle = 1d (HonkyTonk)
Exit3 = Parameter
Speed VVehicle Invalid
Entry1 = Speed VVehicle = No Information
Entry2 = Qualifier Speed VVehicle = 14d
Entry3 = Qualifier Speed VRange = Invalid
Exit1 = Speed VVehicle = Replacement for No Information
Exit2 = Qualifier Speed VVehicle = 14d (Replacement)
Exit3 = Parameter
Speed Replacement = Speed VEPS parameter for Rolling/Driving (HonkyTonk) are used
EPS Internal Speed VEPS Input Node
Speed VEPS Valid for Near to Stop
if
• Speed VVehicle Valid for Near to Stop
• Qualifier Speed VVehicle = 1d
Speed VEPS Invalid with Replacement for Stop
if
• Speed VVehicle = 0 km/h
• Qualifier Speed VVehicle = 4d
Speed VEPS Invalid with Replacement for No Information
if
• Speed VVehicle = No Information
• Qualifier Speed VRange = Invalid
Note: It is ensured that VEPS is passed on at 10 % below the actual Longitudinal Vehicle Heading Speed Vvehicle
EPS Internal Speed VEPS Gradient GEPS
If VEPS is valid, and the difference between the value of VEPS and the value of Vvehicle is < 1 km/h then GV-EPS is valid.
If VEPS is invalid, then GV-EPS is invalid
Max. gradient treshhold value GEPS based on Vvehicle
Quality and Safety for Speed VVehicle
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Safety Concept (ISO 26262 Part 3)
The approved safety concept shows the risk assessment of safety related failures with the help of
the ISO 26262 Risk Matrix and shows how monitoring processes will detect failure modes within tasks
or functions and how the Error Handling safegards the specified Safety Goals with an interrupt safety
routine.
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of hardware circuits (BOM) for signal & control flow processes.
Risk Classification for VVehicle and VEPS
For safety relevant functions were a incorrect VEPS can cause a serious functional safety problem,
the input variable is classified as (A)SIL D due to the HRA (Risk and Hazard analysis).
Qualifier Speed(A)SIL-D
A valide Qualifier Speed(A)SIL-D for a safety relevant function requires following conditions
• No CRC Error
• No Alive Error
• Speed VVehicle is valide, proved and plausible
• Qualifier Speed VVehicle is valide
• Qualifier Speed VRange is valide
Conditional Operator for alternative Qualifier Speed(A)SIL-D
A valide Qualifier Speed(A)SIL-D with following special conditions
• Qualifier relative rotor angle δ provides special condition A
• Allows to switch to condition 1 as (A)SIL D classified, valide, proved and plausible
Delay Time: Changing from A to 1 takes less than 200 ms
Note
Process Safety Time (Failure Detection + Failure Reaction) t = 200 ms and does not include
• cycle time per NetWork message (ms)
• timeout e.g. cycle time expired (ms)
• time for an analog signal debounce at an input (ms)
EPS Internal Save Speed VEPS
The forwarding of the treated variable VEPS to the control group must always have been exported
from the cyclic EPS slot of the flexray network, including correct CRC and alive checks. In addition,
a valid Qualifier Speed VVehicle and the actual information of the Near to Stop as a the Qualifier
Speed VRange must be present. If this valide, proved and plausible VEPS is (A)SIL D classified,
it can be used as EPS Internal Save Speed VEPS for safety relevant functions.
Signal Flow for further transmisson functions
Cascaded follow up Connections of n-1 branches that incl. further transmission functions
Voutn = PAR21 * PAR32 PAR43 * PAR45 ... * PARn(n-1) * EPS Internal Save Speed VinEPS
Note
The same stipulations apply for the EPS Input Group Source 1 Vin as specified for follow
up EPS Control Group Sink 2 with following safety topics
• Expected Quality of Speed VVehicle
• Expected Qualifier Speed VVehicle
• Expected Qualifier Speed VRange
• Expected Error Tolerance Time
• Expected Safety Integrity Level (A)SIL
• Expected Safe State(s)
Formats & Parameters (ASAM A2l-File)
Vehicle Speed
• Unit (km/h)
• Default Value : n.a
• Value Range : 0 ... 350 (km/h)
• Minimum Resolution : 0.1 (km/h)
Qualifier Vehicle Speed
• Valid : Hex = 1d
• Replaced for Car Stoped : Hex = 4d
• Replaced for Car Moves : Hex = 12d
• Replaced for No Information : Hex = 14d
Parameterisation
Replacement for Vehicle Speed rolling or close to stop
• Unit (km/h)
• Default Value : 9 (km/h)
• Value Range : 0 ... 9 (km/h)
• Minimum Resolution : 1 (km/h)
Replacement for Vehicle Speed driving
• Unit (km/h)
• Default Value : 130 (km/h)
• Value Range : 10 ... 250 (km/h)
• Minimum Resolution : 1 (km/h)
Valid Vehicle Speed for Speed Gradient
• Unit (km/h)
• Default Value : 50 (km/h)
• Value Range : 0 ... 100 (km/h)
• Minimum Resolution : 1 (km/h)
Invalid Vehicle Speed for Speed Gradient
• Unit (km/h)
• Default Value : 50 (km/h)
• Value Range : 0 ... 100 (km/h)
• Minimum Resolution : 1 (km/h)
2) Rotor Absolut Rotation δAbs
Internal hardwired analog feedback signal that can be converted within a time span of at least T ≤ 1ms.
Required Power Supply States
• Battery Pols (+) (-) connected (Ground Bat Clamp 31 & Permanent Bat Clamp 30 for high current bridge supply voltage Udrain = ON
• PCB OFF (Switched IGN Clamp 15N = 0 (OFF) with decoupled phase clamps = normally open)
• PCB ON (Switched IGN Clamp 15N = 1 (ON) with coupled phase clamps = closed)
Note
• A permanent transducer supply is handled per 5 VDC Voltage Regulator
• EEPROM stored code and data may be lost if Bat Clamp 30 is interrupted for long time
• Supply power back up by permanent Bat Clamp 30
After initialisation the absolute angle of rotor rotation equals an calibrated
value for straight a head direction or equals a multiple of the rack segments as
the output variable.
Pick Up Sensors providing the elec. reference voltage corresponding to the relative
angle of rotation of the rotor shaft.
The actual absolute position of the rotor shaft as an output variable, is determined
with following five input variables
Input Position Variables
• Relative Rotor Angle δRel
• Qualifier Rotor Angle δRel
• MultiTurnintern
• MultiTurnextern
• Off-Set
Output Position Variables
• Absolute Position (Rotor Angle δAbs or Rack Travel YAbs)
• References for Absolute Position based on Unit [mm] or [°]
• Qualifier Absolute Position
• Total Transmission Ratio i
• References for Transmission Ratio based on Unit [mm] or [°]
• Absolute Position (Column Angle αAbs)
Time to receive input variable and to process and send the output variable
• Maximal Time required to achieve δRel is less than or equal to 1 ms.
• Maximal Time required to provide δAbs is less than or equal to 10 ms.
Note: Failure Tolerant according NetWork message ± 1 ms
Assigne the Input Variable
• Assigne +δ when steering to the right
• Assigne -δ when steering to the left
• Assigne + Turn Number steering to the right
• Assigne - Turn Number when steering to the left
Cycle time for NetWork message
After an initialization or a reset, the αAbs state is set invalid at the first discontinuity point
This is sent via the 1st flexray data frame cycle after 10 ms at the latest to the NetWork.
After that event, the αAbs, δRef, MultiTurn to provide δAbs and YAbs will be valid.
At least 300 ms later, all required positions with there qualifiers are sent per bus
data frame cycles to the NetWork.
All position are refered to rack travel YAbs
• Provide the unit [°] for rotation
• Provide the unit [mm] for rack travel
In the following RotorRotation Block, the received messages are used to process the input variables
to send the absolute steering position output variable
Error Handling
DTC for elec. reference voltage signals
If
the signal quality for the input variable is met, then Valid State Relative Rotor Angle δRel
Else
the signal quality for the input variable is not met, then Invalid State Relative Rotor Angle δRel
End If
General Signal Flow
The input node 1 (source) as Relative Rotor Angle δRel has the unit [°].
Outgoing branch as an transmission ratio i to the output node 2 (sink) as the column rotation α [°].
With the incoming branch as the C-Factor = constant [°/mm] the output node n (sink) becomes the
Absolute Rack Travel YAbs that has the unit [mm].
Positions that require to be related to the Rack Travel YAbs (mm).
The rotor shaft as part of the control forward path is mechanically connected to the column,
the angular actuation of which is performed by a constant or a transfer function.
An angle pick up disc with hall sensors is assembled onto the rotor shaft. The sensor provides
the reference signals δRel (..-180°.. 1Turn ..+180°..) and an indication for full revolutions to the control
feedback path.
The column is mechanically connected via gear pinion to the rack, which actuation is made via
the transmission ratio as C-Factor [°/mm].
The mechanical angle accuracy between δ and pinion output for
• 0°
• ± 360°
• ± 720°
with reference to a calibrated center point is ± 1°.
Note
With a specified sign convention, a negative signal value (-) on the torque setting
causes the rack to move to the right
Signal limiter by angular velocity ω (°/s)
The elec. reference voltage measurement for the input variable δRel is limited by the max angular column
(hand wheel) velocity ω of up to 400 (°/s) based on a stopped vehicle where the max steering load occures.
At higher angular velocities, the input variable δRel is no longer sufficient.
• Relative Angle δRel (°)
• Limiter by Angular Rotor Velocity ω(t) (°/s) as a time derivative of the relative angle δ(t)
• Absolute Rack Travel YAbs (mm)
• Limiter by Rack Travel Velocity Ẏ(t) (mm/s) as a time derivative of the relative rack travel Y(t)
Conditions to check if the Relative Rotor Angle δ is Valid or Invalid
If
Column Angular Velocity ω ≤ 400 °/s, then δRel is valide and can be used
Else
Column Angular Velocity ω is > 400 °/s, then replace with last stored valid δRel
End If
MultiTurnintern
Each time the rotor shaft has rotated 360 degrees from the calibrated center point, the number of
revolutions is stored in the 16-bit data register or memory unit.
At the discontinuity point a treshhold or an overflow from
• rotor shaft 360° to 0 occurs for δRel, and the MultiTurnintern value increases by 1
• rotor shaft 0° to 360° occurs for δRel, and the MultiTurnintern value decreases by 1
Absolute Rotor Angle δAbs = f(δRel , MultiTurn Count Value)
The rotation of the column with rotating pinion and the position of the rack is determined using
the δAbs = f(δRel , MultiTurnintern) value in relation to the calibrated off-set position.
Qualifier Absolute Rotor Angle δAbs
δAbs depends on following values :
• Relative Rotor Angle δRef
• MultiTurn
• Offset
Hex, Dec and 16bitData Speed-State
___0d ___13 __0000000000001101 Invalid center point steering angle α ≠ 0°
___1d ___29 __0000000000011101 δAbs is valide, proved and plausible
___2d ___45 __0000000000101101 δAbs is valide
Rack Travel Resolution
The actual absolute rack travel Y (mm) value is specified for a reduced Column Angular Velocity ω ≤ 400 °/s
between -100 mm & +100 mm The mechanical resolution of the entire lengh is ≤ 0.005 mm. The entire lengh
of 200 mm is divided into 200 equally wide segments. This results in an absolute resolution of 1 mm. A relative
resolution results for one measuring step related to all steps in the measuring range, the relative resolution
is here is 1/200 = 0.005 mm.
Rack Travel End Stops
16Bit Data resolution of ± 100 mm for mech. rack travel with following Software End Stops
• 95 % of the mech. possible nominal stroke for angular position of wheels
• 99 % of the mech possible nominal stroke for angular position of wheels with 8 Nm Hand Wheel Torque Input
Off-Set of Absolute Rack Travel YAbs
A long-term calibrated center point is a measure to compensate all steering assembly tolerances. The adjustment
value is the algebraic sum of the actual rack travel Y plus or minus the measured and determined output variable
of the absolute rack displacement YAbs
.
• Off-Set error of δRel is less than 0.05 mm
• Linearity error of δRel is less than 0.05 mm per 10 mm rack displacement
• Linearity error of δRel is less than 0.01 mm per 1 mm rack displacement
• Hysteresis error of δRelis less than 0.015 mm
• Noise error of δRel is less than 0.015 mm.
The output YAbs has a maximum error of ± 1 mm according to the entire lengh with respect to
linearity, sensitivity, drift over temperature, lifetime, ...
Note : Error applies to ω(t) as the time derivative of δ(t)
Quality of Calibrated Center Off-Set
• Off-Set δAbs = 0°
• Qualifier Center Point Off-Set [°] == Dec 2 , Hex 2 , DataBits 0000 0000 0000 0010 (valid)
• Qualifier Center Point Off-Set [mm] == Dec 1 , Hex 1 , DataBits 0000 0000 0000 0001 (valid)
Note
Due to E/E Sub-System installation tolerances, the rack center position is not necessarily the
same for all vehicles and recalibration of the center 0° + off-set as a reference for a real
straight ahead direction is required @ Commissioning
Quality of Manufacturing & Assembly Process
• Incorrect assembly is not possible
• Capable calibration for transducer manufacturing process
• Process parameter cpk is identical or creater than 1.67 (Failure Probability > 5σ)
• 10 % tolerance limited on one side, min. possible tolerance utilization has to be achieved
• Calibration & measuring tools (ISO26262-8 Confidence in the Use of SW Tools and there devices)
The Absolute Rack Travel YAbs Data is set to 0° @ 0 multi-turns, caused by a calibrated Off-Set value,
that provides the middle position of the rack, and complies with the wheel/tire straight ahead direction.
Following EEPROM Data with 16Bit resolution and read/write per Diagnostic Service Request
• Calibrated Steering Center Point as Absolute Rack Travel YAbs = 0 mm
• Calibrated Steering Center Point as Absolute Rotor Angular Rotation δAbs = 0°
• 1 Rotor-Turn (360°) = 4 mm nominal Rack Displacement (worst case 2.4 mm)
• 180° Pinion Angle = 2 Rack Segments
• Nominal Rack Travel = n * Segment ± (12% vom Segment) between Center and SW End Stop
Note: Segment = Area within one rotor revolution where YAbs can be detected
Position Values for Transport State
For the transport state following vehicle states are taken into account
• Vehicle Ready to Operate
• Vehicle Operates
• Vehicle Finsh to Operate
• Vehicle Diagnostic
1st Option : Enable Read Position for an Activated Vehicle State
2nd Option : Disable Read Position for an Deactivated Vehicle State
Commissioning
• Refresh EEPROM data from scratch, verify and store data as preliminary center point references
• Before commissioning the preliminary stored center point 0° is used as a measuring reference
• After commissioning an off-set is calibrated to the center point 0° + Off-Set as reference for real straight heading
Error Handling in case of a missing output variable δAbs = f(δRel , MultiTurnintern)
Note: An error handling is not applicable while
using a 16Bit true-power-on transducers
that provides an absolute position αAbs = δAbs
immediately after startup, restart or reset without
requiring a supply voltage buffering.
Option in case of loss of the MultiTurnintern input variable
The steering angle is based on the output variable δAbs = f(δRel , MultiTurnintern) in relation to
the calibrated center position. The output variable δAbs can get lost if the input variabes δRel
and/or MultiTurnintern gets lost. If the input variable δRel is present, but the MultiTurnintern
is lost, a redundant MultiTurnextern variable from the NetWork can be used. The condition of
the output variable δAbs is provided by the Qualifier δAbs State. The plausibility of rotor δAbs
is checked by comparing to the column transducer angle αAbs. This rotation is converted to the
absolute rack travel YAbs per transfer function for the gear pinion.
Redundance: The steering gear box (°/mm) can be equipped with an IndexSensor, that measures the gear pinion turns
Rotor Angle δAbs-Conditions provided by the Rotor Angle δAbs-Qualifier
The following describe different Qualifier States of δAbs if the MultiTurnintern Value gets lost.
With this failure mode, the MultiTurn value is discarded no later than t = 20 ms (2 FlexRay-Cycles).
and the MultiTurn value is determined by another node (control device) connected to the NetWork to
allow to change from MultiTurnintern to MultiTurnextern and to continue the process as δAbs = f(δRel , MultiTurnextern)
Qualifiers δAbs for different MultiTurnextern values send via the communication interface
State == Dec __2 , Hex 0X2 , DataBits 0000 0000 0000 0010 (Set Up per Tranducer)
State == Dec __3 , Hex 0X3 , DataBits 0000 0000 0000 0011 (Set Up per Model)
State == Dec __4 , Hex 0X4 , DataBits 0000 0000 0000 0100 (Set Up per both End Stops)
State == Dec __7 , Hex 0X5 , DataBits 0000 0000 0000 0111 (Corrected Off-Set)
State == Dec _11, Hex 0XB , DataBits 0000 0000 0000 1011 (Robust Set Up per Model)
Delay Time: Time Span were RTOS interacts per Com-Service, HW-Abstaction-Layer and
Com-Driver to receive the explicit message MultiTurnextern from the NetWork is t = 20 ms
(2 FlexRay-Cycles) at latest. The provision of the MultiTurnextern bus message can take
place in several steps. Therefore it is possible that this redundant value is corrected several
times. Note: Process Safety Time (Failure Detection + Failure Reaction)
Example:
Selection and Processing of the Qualifier Rotor Angle δAbs with Start or after Restart or Reset
If
δRef exists for less than 300ms (30 FlexRay-Cycles),
then set the following
• Qualifier Rotor Angle δAbs = Hex E (Invalide)
........If
........δRef exists for 20ms (2 FlexRay-Cycles),
........then set the following
........• Qualifier Rotor Angle δAbs = Hex FFFF (special DTC)
........End if
Else
δRef exists for more than 300ms (30 FlexRay-Cycles),
then check the following
.....If
........Vehicle States are Deactivated || there is a invalid Multi Turn Value || there is No MultiTurn Information
........then a MultiTurnextern Request is sent to the bus to process δAbs = f(δRel , MultiTurnextern)
........and the following is set:
........• Qualifier Rotor Angle δAbs === Hex 8 (Initialisation-State)
........• Rotor Angle δRel value is equal to 0
................If
................MultiTurnextern is Pending,
................then set the following
................• Qualifier Rotor Angle δAbs === Hex 4 (Status Temporary, Replacing per NetWork, Pending)
................• Output δAbs == δRel
........................If
........................Status_Offset === 3 (Set Up per Model)
.........................Then
.........................• Compare, Correct, Store and set MultiTurn
.........................• Qualifier Rotor Angle δAbs = Hex 2 (Valide per Model)
........................• Output δAbs is equal to δRel that have been corrected by the stored MultiTurn
........................Else If
........................Status_Offset === 4 (Set Up per End Stops),
........................Then
........................• Compare, Correct, Store and set MultiTurn
........................• Qualifier Rotor Angle δAbs === Hex 1 (Plausible, proved, Valide per End Stops)
........................• Output δAbs is equal to δRel that have been corrected by the stored MultiTurn
........................End If
................Else
........................If
........................MultiTurnextern is set to B,
........................then set the following
........................• Store MultiTurnset
........................• Qualifier Rotor Angle δAbs === Hex A (Status Temporary, Low Signal Quality, Store MultiTurn B)
........................Else If
........................MultiTurnextern is set to 3
........................then set following
........................• Store MultiTurnset
........................• Qualifier Rotor Angle δAbs === Hex 2 (Valide, Set Up per Model. Store MultiTurn 3)
........................Else If
........................MultiTurnextern is set to 4
........................then set following
........................• Store MultiTurn off set
........................• Qualifier Rotor Angle δAbs === Hex 1 (Set Up per both End Stops, Plausible, proved, Valide, Store MultiTurn 4)
........................Else
.............................If
.............................Status_Offset === 2 (Off Set Transducer)
.............................then set the following
.............................• Compare, Correct, Store and set MultiTurn to 5
.............................• Qualifier Rotor Angle δAbs === Hex 1 (Off Set Transducer, Store MultiTurn 5)
.............................End if
........................• Output δAbs is equal to δRel that have been corrected by the stored MultiTurn
.................End if
.....Else
........Vehicle States are Activated || there is a valid Multi Turn Value || there is MultiTurn Information
........then a MultiTurnintern Positive Response is sent to the bus to process δAbs = f(δRel , MultiTurnintern)
........and the following is set:
........• Qualifier Rotor Angle δAbs === Hex 2 (Valide)
........• Output δAbs is equal to f(δRel , stored MultiTurn)
.................If
.................Status_Offset === 2 (Off Set Transducer)
.................then set the following
.................• Qualifier Rotor Angle δAbs === Hex 1C (Off Set Transducer, Plausible, proved, Valide)
.................• Output δAbs is equal to f(δRel , stored transducer MultiTurn)
.................Else
.................Status_Offset === 7 (Corrected Off Set Transducer)
.................then set the following
.................• Qualifier Rotor Angle δAbs === Hex 0C (Correct Off Set Transducer, Plausible, proved, Valide)
.................• Output δAbs is equal to f(δRel , stored corrected transducer MultiTurn)
........................If
........................Qualifier Rotor Angle δAbs === Hex 0C is valide for 50ms (5 FlexRay-Cyles)
........................then set the following
........................• NetWork Message Bock for δAbs vis alide
........................End if
..................End if
..........End if
End If
Example:
If a valid input variable for the relative rotor angle δRef exists, then following
qualifiers δAbs can be set
Simplified Semantic: Transition between Qualifier State Hex 0xE and Qualifier State Hex 0x1
The control flow is in the start (source) state Hex 0xE and offers 2 transitions
to hierarchy destination state Hex 0x8 and Hex 0x1.
Transmission Conditions from Hex 0xE to Junction
Is there a valid transition from Hex 0xE available ?
The transition from Hex 0xE to the Junctions is valide, if following conditions are fulfilled:
δRef exists for more than 300ms (30 FlexRay-Cycles)
&& Vehicle States are deactivated || there is a invalid Multi Turn Value || there is No MultiTurn Information
&& Data registers with parameters such as default value, value range, value resolution, value unit, etc. are initialized correctly
Transmission Conditions from Junction to Hex 0x1
The code piece checks to see if there is a valid transition to DESTINATION STATE HEX_0X1 is available.
Following conditions must be fulfilled:
All receive messages are verified as valid && MultiTurnintern is verified as valid
Exit Action of Hex 0xE
Hex 0xE is deactivated and left while response message for δAbs is send to the NetWork
Entry Action of Hex 0x1
Hex 0x1 is activated and the entry action Qualifier Rotor Angle δAbs Plausible, proved and Valide per End Stops is executed and completed.
Transmission Conditions from Junction to Hex 0x8
The code piece checks to see if there is a valid transition to DESTINATION STATE HEX_0X8 is available.
No transmission conditions required to transfer to Hex 0x8
Exit Action of Hex 0xE
Hex_0xE is deactivated and left while response message for δAbs is send to the NetWork
Entry Action of Hex 0x8
Hex_0x8 is activated and the entry action Qualifier Rotor Angle δAbs Initialisation is executed and completed.
Simplified Semantic: Transition between Qualifier State Hex 0x8 and Qualifier State Hex 0x1
The transition between Hex 0x8 (Initialisation) and Hex 0x1 (Set Up per both End Stops, Plausible,
Proved, Valide, Stored MultiTurn Count Value) have conditions that triggers the transition to Hex 0x1;
it can have an action as well (e.g. DTC Counter) , that is executed when the transition is performed.
Conditions and actions are specified.
A) The Qualifier State Hex 0x8 is active
B) The control flow is initiated by a trigger event
C) Evaluate the Trigger Event to transfer from Hex 0x8 to Hex 0x1
C.1) Questionnaire for Qualifiere Hex 0x1 Transition Conditions
C.1a) Receive messages (implicite, explicite) are verified as valid
C.1b) MultiTurn Count Value is verified as valid
C.1c) δAbs Variable & Signal Quality
• 16Bit Data Resolution for µC port
• Time to response to input variable t = 10ms
• Error Tolerance Time t = 30ms
• Safe State is indicated per Qualifier δAbs or NetWork Message Timeout (absence time)
• (A)SIL (B)D with an PMHF < 5 FIT ~ 5 X E-9/h and DC_SPF ≥ 99% DC_LF ≥ 90% such as for Safety Goal 1
• δAbs Value Range 0°...400°...(max.500°)
• Linearity YAbs = Const. * (δAbs ± 1.5°) between rack and steering motion over the service life
C.2) Execute Qualifier Hex 0x1 Transition Action
If
Questionnaire for Qualifier Hex 0x1 Transition Conditions are True,
then
Transition is valid && following Transition Action is executed
• Qualifier Hex 0x8 is deactivated
• DTC_0x1_Counter is increased by 1
• Qualifier Hex 0x1 (hierarchy state) is activated
D) Evaluate the Transition from Qualifier Hex 0x1 to its Sub-States
Qualifier Hex 0x1 is a hierarchy state and has transitions to several other Sub-States
that are assigned to a priority. Once a condition evaluates to true, the associated
transition takes place, and all other conditions belonging to transition with
lower priorities are not executed. The Sub-State PCB-OFF is the start state in
the hierarchy and is evaluated first. If the condition for PCB OFF is not fulfilled,
the transition is invalid and the transition from PCB OFF to PCB ON is evaluated.
If no condition evaluates to true, the Hex 0x1 remains unchanged and a specified
static action .... is executed.
D.1) Questionnaire for Transition Conditions
D.1a) PCB OFF (Switched IGN Clamp 15N = 0 (OFF) during the initialisation Task)
D.1b) PCB ON = Power Output Ready (Switched IGN Clamp 15N = 1 (ON))
D.1c) Motor Drive = Power Output (Switched MotorDrive = 1 (ON))
D.2) Execute Transition Action
If
Questionnaire to trigger Sub-State PC=OFF is true, then Transition is valid && following entry action is executed and completed:
Check δAbs Qualification:
• αAbs can be provide via NetWork message
• δAbs Error ~ ± 7,5° related to gear pinion
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier Hex 0x1 or NetWork Message Timeout (absence time)
• (A)SIL B
&&
± Maximal YAbs Error [mm] < C-Factor [mm] * 7,5° / 360°
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier Hex 0x1 or NetWork Message Timeout (absence time)
• (A)SIL B
With above, provide Qualifier Hex 0x1 (Set Up per both End Stops, Plausible, Proved, Valide, Stored MultiTurn Count Value) and finsih evaluation.
Else If
Questionnaire to trigger Sub-State PC = ON is true, then Transition is valid && following entry action is executed and completed:
......If
......δAbs is processed via implicit & explicit input messages,
......then,
......• δAbs Error ~ ± 7,5° related to gear pinion
......• Error Tolerance Time is 100ms
......• Safe State is indicated per Qualifier Hex 0x1 or NetWork Message Timeout (absence time)
......• (A)SIL D
......Else
......δAbs is processed via implicit input messages,
......then
......• ± Maximal YAbs Error [mm] < C-Factor [mm] * 7,5° / 360°
......• Error Tolerance Time is 100ms
......• Safe State is indicated per Qualifier Hex 0x1 or NetWork Message Timeout (absence time)
......• (A)SIL D
......End If
With above, provide Qualifier Hex 0x1 (Set Up per both End Stops, Plausible, Proved, Valide, Stored MultiTurn Count Value) and finsih evaluation.
Else
Questionnaire to trigger Sub-State MotorDrive=ON is true, then Transition is valid && following entry action is executed and completed:
Check δAbs Qualification:
• δAbs Error as a algebraic sum consisting of 2 angle values δ(°) as time integrals of ω(°/s) during 1s < 7,5° related to gear pinion
• The hysteresis corresponds to : δAbs Max. hysteresis ~ Max. YAbs Error [mm] < C-Factor [mm] * 7,5° / 360°
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier Hex 0x1 or NetWork Message Timeout (absence time)
• (A)SIL D
With above, provide Qualifier Hex 0x1 (Set Up per both End Stops, Plausible, Proved, Valide, Stored MultiTurn Count Value) and finsih evaluation.
End If
If no condition evaluates to true, the Qualifier Hex 0x1 (hierarchy state) remains unchanged and a specified static action .... is executed.
E) Check Transition out of Qualifier Hex 0x1
E.1) Questionnaire for Transition Conditions
E.1a) EPS Failure Mode
E.1b) Activate Qualifier Hex 0x1 = OFF
E.2) Execute Transition Action
If
Questionnaire to trigger State EPS Failure Mode is true, then Transition to Hex 0x7 is valid && following entry action is executed and completed:
Check δAbs Qualification:
• Select and Process δAbs= f(αAbs) (alternative δAbs= f( δRef, IndexSensor))
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs Hex 0xE or NetWork Message Timeout (absence time)
• (A)SIL B
With above, provide Qualifier Hex 0x7 (Internal EPS Error that distorts δAbs) and finish evaluation.
End If
Else
Questionnaire to trigger Sub-State Hex 0x1=OFF is true, then Transition is valid && following entry action is executed and completed:
Check δAbs Qualification:
• Qualifier Hex 0x1 is deactivated with Exit Action
• Transition form Hex 0x1 to Hex 0x8 occurs
• Qualifier Hex 0x8 is activated with Entry Action
End If
Simplified Semantic: Transition between Qualifier State Hex 0x8 and Qualifier State Hex 0x4
The transition between Hex 0x8 (Initialisation) and Hex 0x4 (Status Temporary, Replacing per NetWork,
Pending) have conditions that triggers the transition to Hex 0x4; it can have an action as well (e.g.
DTC Counter) , that is executed when the transition is performed. Conditions and actions are specified.
A) The Qualifier State Hex 0x8 is active
B) The control flow is initiated by a trigger event
C) Evaluate the Trigger Event to transfer from Hex 0x8 to Hex 0x4
C.1 Questionnaire for Qualifiere Hex 0x4 Transition Conditions
C.1a Receive messages (implicite, explicite) are verified as valid
C.1b MultiTurn Count Value cannot be used
C.1c δAbs Variable & Signal Quality
• 16Bit Data Resolution for µC port
• Time to response to input variable t = 10ms
• Error Tolerance Time t = 30ms
• Safe State is indicated per Qualifier δAbs or NetWork Message Timeout (absence time)
• (A)SIL (B)D with an PMHF < 5 FIT ~ 5 X E-9/h and DC_SPF ≥ 99% DC_LF ≥ 90% such as for Safety Goal 1
• δAbs Value Range 0°...400°...(max.500°)
• Linearity YAbs = Const. * (δAbs ± 1.5°) between rack and steering motion over the service life
C.2 Execute Qualifier Hex 0x4 Transition Action
If
Questionnaire for Qualifier Hex 0x4 Transition Conditions are True,
then
Transition is valid && following Transition Action is executed
C.2.1 DTC_0x4_Counter is increased by 1
C.2.2 The Qualifier Hex 0x8 has no exit action that could be executed. Hex 0x8 is deactivated
C.2.3 Qualifier Hex 0x4 is activated
C.2.3.1 The Entry Action is executed
• MultiTurnextern is Pending
Check δAbs Qualification:
• δAbs is equal to δRel because MultiTurnextern Count is Pending and cannot be used
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs HEX 0XE or NetWork Message Timeout (absence time)
• (A)SIL A
• δAbs is equal to gear pinion index count at the time when the last discontinuity or overflow point occurred
• Error Tolerance Time is 100ms
• Safe state: terminate index as signal value and and set Qualifier δAbs to substitute value until a new offset is provided within Terminal 15 cycle
• (A)SIL A
• δAbs is compared to column transducer angle αAbs
• Error Tolerance Time is 100ms
• Safe State: Set send message δAbs invalid and set Qualifier δAbs to substitute value until a new offset is provided within Terminal 15 cycle
• (A)SIL A
• Offset_Center_Point must not deviate by more than 12 % of the segment size from the default value stored in the EEPROM
• Error Tolerance Time is 100ms
• Safe State: Set send message δAbs invalid and set Qualifier δAbs to substitute value until a new offset is provided within Terminal 15 cycle
• (A)SIL A
• δAbs Error is equal to [δ] - [Y related to calibrated center position] = N * Rack-Segment ± (12% of the Rack-Segment)
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs HEX 0XE or NetWork Message Timeout (absence time)
• (A)SIL A
With above, provide Qualifier Hex 0x4 (MultiTurnextern = Pending) and finsih evaluation.
Else
• No transition Hex 0x8 to Hex 0x4 is executed
End If
Simplified Semantic: Transition between Qualifier State Hex 0x4 and Qualifier State Hex 0xA
The transition between Hex 0x4 (Status Temporary, Replacing per NetWork,Pending) and Hex 0xA
(MultiTurnextern Count Value B), have conditions that triggers the transition to
Hex 0xA; it can have an action as well (e.g. DTC Counter) , that is executed when the transition
is performed. Conditions and actions are specified.
A) The Qualifier State Hex 0x4 is active
B) The control flow is initiated by a trigger event
C) Evaluate the Trigger Event to transfer from Hex 0x4 to Hex 0xA
C.1 Questionnaire for Qualifiere Hex 0xA Transition Conditions
C.1a) PCB ON = Power Output Ready (Switched IGN Clamp 15N = 1 (ON)
C.1b) Corrected MultiTurn Count Value B
C.2) Execute Qualifier Hex 0xA Transition Action
If
Questionnaire for Qualifier Hex 0xA Transition Conditions are True,
then
Transition is valid && following Transition Action is executed
C.2.1 DTC_0xA_Counter is increased by 1
C.2.2 The Qualifier State Hex 0x4 has no exit action that could be executed. Hex 0x4 is deactivated
C.2.3 Qualifier Hex 0xA is activated latest within t = 200ms
C.2.3.1 The Entry Action is executed
• Corrected MultiTurnextern Count Value B is Stored
Check δAbs Qualification:
• δAbs is equal to δRel but have been corrected by the stored MultiTurnextern Count Value B
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs Hex 0xA or NetWork Message Timeout (absence time)
• (A)SIL A
• δAbs is equal to gear pinion index count at the time when the last discontinuity or overflow point occurred
• Error Tolerance Time is 100ms
• Safe state: terminate index as signal value and and set Qualifier δAbs to substitute value until a new offset is provided within Terminal 15 cycle
• (A)SIL A
• δAbs is compared to column transducer angle αAbs
• Error Tolerance Time is 100ms
• Safe State: Set send message δAbs invalid and set Qualifier δAbs to substitute value until a new offset is provided within Terminal 15 cycle
• (A)SIL A
• δAbs Error as a algebraic sum consisting of 2 angle values δ(°) as time integrals of ω(°/s) during 1s < 7,5° related to gear pinion
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs Hex 0xE or NetWork Message Timeout (absence time)
• (A)SIL D
• The hysteresis corresponds to : δAbs Max. hysteresis ~ Max. YAbs Error [mm] < C-Factor [mm] * 7,5° / 360°
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs HEX 0XE or NetWork Message Timeout (absence time)
• (A)SIL D
• δAbs Error ~ ± 7,5° related to gear pinion
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs HEX 0XA or NetWork Message Timeout (absence time)
• (A)SIL A
With above, provide Qualifier Hex 0xA (corrected MultiTurnextern B) and finsih evaluation.
Else
• No transition Hex 0x4 to Hex 0xA is executed
End If
Simplified Semantic: Transition between Qualifier State Hex 0xA and Qualifier State Hex 0x1
The transition between Hex 0xA (MultiTurnextern Count Value B) and Hex 0x1 (Set Up per both
End Stops, Plausible, Proved, Valide, Stored MultiTurn Count Value), have conditions that triggers the
transition to Hex 0x1; it can have an action as well (e.g. DTC Counter) , that is executed when the
transition is performed. Conditions and actions are specified.
A) The Qualifier State Hex 0xA is active
B) The control flow is initiated by a trigger event
C) Evaluate the Trigger Event to transfer from Hex 0xA to Hex 0x1
C.1 Questionnaire for Qualifiere Hex 0x1 Transition Conditions
C.1a) PCB ON = Power Output Ready (Switched IGN Clamp 15N = 1 (ON)
C.1b) Corrected MultiTurn Count Value 4
C.2) Execute Qualifier Hex 0x1 Transition Action
If
Questionnaire for Qualifier Hex 0x1 Transition Conditions are True,
then
Transition is valid && following Transition Action is executed
C.2.1 DTC_0x1_Counter is increased by 1
C.2.2 The Qualifier State Hex 0xA has no exit action that could be executed. Hex 0xA is deactivated
C.2.3 Qualifier Hex 0x1 is activated latest within t = 200ms
C.2.3.1 The Entry Action is executed
• Corrected MultiTurnextern Count Value 4 is Stored
Check δAbs Qualification:
• δAbs is equal to δRel but have been corrected by the stored MultiTurnextern Count Value 4
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs Hex 0x1 or NetWork Message Timeout (absence time)
• (A)SIL A
If
......Offset Option is achieved from transducer
......then,
......• Status_Offset === Hex 0x5 (Set Up per Transducer)
......• δAbs is equal to δRel that have been corrected by Offset Value 5 (Transducer [or IndexSensor])
......Else If
......Offset Option is achieved by moving to left and right end stops
......then,
......• Status_Offset === Hex 0x4 (Set Up per End Stops)
......• δAbs is equal to δRel that have been corrected by Offset Value 4 (End Stops)
......Else If
......Offset Option is achieved from Model
......then,
......• Status_Offset === Hex 0x3 (Set Up per Model)
......• δAbs is equal to δRel that have been corrected by Offset Value 3 (Model)
End If
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs Hex 0xE or NetWork Message Timeout (absence time)
• (A)SIL B
• δAbs Error ~ ± 7.5° related to gear pinion
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs Hex 0xA or NetWork Message Timeout (absence time)
• (A)SIL A
• ± Maximal YAbs Error [mm] < C-Factor [mm] * 7,5° / 360°
• Error Tolerance Time is 100ms
• Safe State is indicated per Qualifier δAbs Hex 0xE or NetWork Message Timeout (absence time)
• (A)SIL D
With above, provide Qualifier Hex 0x1 (Set Up per Offset Option, Plausible, Proved, Valide, Stored MultiTurn Count Value4) and finsih evaluation.
Else
• No transition Hex 0xA to Hex 0x1 is executed
End If
Formats & Parameters (ASAM A2l-File)
Angle δ
• Unit : (°)
• Default Value : n.a
• Value Range : -1500 ... + 1500 (°) respectively -300 ... + 300 (mm)
• Minimum Resolution : 0.05 (°) respectively 0.005 (mm)
Qualifier Angle δ
• Valid : Hex = 1d
• Invalid : Hex = 0d
Angle Velocity ω
• Unit : (°/s)
• Default Value : n.a
• Value Range : -1500 ... + 1500 (°/s) respectively -300 ... + 300 (mm/s)
• Minimum Resolution : 1 (°/s) respectively 0.1 (mm/s)
Qualifier Angle Velocity ω
• Valid : Hex = 1d
• Invalid : Hex = 0d
Quality and Safety for Rotor Angular Rotation δAbs = f(δRel , MultiTurnintern, extern)
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Safety Concept (ISO 26262 Part 3)
The approved safety concept shows the risk assessment of safety related failures with the help of
the ISO 26262 Risk Matrix and shows how monitoring processes will detect failure modes within tasks
or functions and how the Error Handling safegards the specified Safety Goals with an interrupt safety
routine.
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of hardware circuits (BOM) for signal & control flow processes.
Risk Classification for Rotor Angular Rotation δAbs
For safety relevant functions within the Control Group, were a incorrect Rotor Angular Rotation δAbs = f(δRel , MultiTurnintern,extern)
can cause a serious functional safety problem, the variable is classified as (A)SIL D due to the HRA (Risk and Hazard analysis).
The forwarding of the MultiTurnextern to the input group is always imported as a explicit message (..20ms) from the cyclic
EPS slot of the flexray network, including correct CRC and Alive checks. In addition, an existing and valid δRef must
be present from the rotor rotation sensors as implicit message (..2ms). If this valide, proved and plausible δAbs is
(A)SIL D classified, it can be used as EPS Internal Absolute Angle Position of the a.c. motor for safety relevant functions.
Recommended Diagnostic Coverage (DC) Target Values
(A)SIL D
• DC_SPFM: > 99%
• DC_LFM: > 90%
(A)SIL A
• DC_SPFM: n.a.
• DC_LFM: n.a.
Recommended Failure Propability Rates per Hour
(A)SIL D
• PFH: ... 1 FIT < 3*E-9 Failure/h
(A)SIL A
• PFH: ... 1000 FIT < 1*E-6 Failure/h
Required Propability Metric for safety relevant hardward failures
PMHF if HW involved and Failure cannot be accommodated up by safety mechanism (no diagnostic coverage):
PMHF = PMHF(SPF) + PMHF(LF) = 10 FIT (<5 X E-8/h)
CRC-Value Failure, Alive-Count Failure and/or Timeout Failure
In case of a CRC- or Alive- or a Timeout- Failure, the received variables and there state are not used and the last
valid variables and there qualifiers remain.
Note A Failure Mode can be accommodated up by Safety Mechanism (diagnostic coverage)
• Safe State : No use of the explicit messages (value from the NetWork not accepted)
• Error Tolerance Time: 100 ms
• Risk : Safety integrity level (A)SIL B
Rotor Angle δAbs as explicit NetWork Message
All sent and received messages belonging to the rotor angle δAbs must contain a valid CRC Value and Alive Counter.
The safety requirement applies over the entire defined signal level range (1.5VDC..3.5VDC). Protect, that is outside the defined
voltage level, the E/E Sub-System does not go into an unsafe state.
Note A Failure Mode can be accommodated up by Safety Mechanism (diagnostic coverage)
• Safe State : Failure identification within associated Qualifier δAbs
• Error Tolerance Time: 100 ms
• Risk : Safety integrity level (A)SIL D
Protect against wrong qualifier δAbs state
Ensure that qualifier δAbs is not assigned with a wrong Hex Data.
Note A Failure Mode can be accommodated up by Safety Mechanism (diagnostic coverage)
• Safe State : Do not accept δAbs output variable as implicit or explicit message
• Error Tolerance Time: 100 ms
• Risk : Safety integrity level (A)SIL D
Protect against wrong qualifier δAbs State selection
Qualifier δAbs may only be selected per implemented safety levels of the Error Handling.
• Safe State: No Trigger Event (Transition between two states)
• Error Tolerance Time: 100 ms
• Risk : Safety integrity level (A)SIL D
A special state is Qualifier δAbs = Hex 0x4 for Pending. In case of signal loss, the failure would
be classified as E2 according to the risk matrix (ISO 26262-3). The exposure E of an pending
MultiTurnexternal NetWork signal can be reduced by a factor of 2 compared to a MultiTurn loss
classified as E2.
Note
A flash process does not represent an external event. Here a loss or pending of the MultiTurn value is not allowed.
Protect against wrong Units for the values
Ensure that Rotor Angle δAbs and Rack Displacment are not assigned with wrong units (°, mm).
Note A Failure Mode can be accommodated up by Safety Mechanism (diagnostic coverage)
• Safe State : Failure identification in associated qualifier δAbs
• Error Tolerance Time: 100 ms
• Risk : Safety integrity level (A)SIL D
Offset Options as explicit NetWork Message
The quality of the offset as reference for the center point is done by different optional offset values
which are received per NetWork message e.g. calibrated by model or by end stops or by transducer (index).
Note A Failure Mode can be accommodated up by Safety Mechanism (diagnostic coverage)
• Safe State : No use of the offset variable and its state (message not sent to the bus)
• Error Tolerance Time: 100 ms
• Risk : Safety integrity level (A)SIL B
Protect against wrong Gear Transmission i assignment
Ensure that the entire gear tramsmission i is not assigned with a wrong value.
Note Single Point Failure, that cannot be accommodated up by safety mechanism (no diagnostic coverage).
• Safe State : Failure identification per invalid or timeout state
• Error Tolerance Time: n.a.
• Risk : Safety integrity level (A)SIL D
Protect against wrong Unit to transmit to [°/°] or to [°/mm]
Ensure that gear tramsmission is converted according the coresponding unit.
Note A Failure Mode can be accommodated up by Safety Mechanism (diagnostic coverage)
• Safe State : Failure identification per invalid or timeout state
• Error Tolerance Time: n.a.
• Risk : Safety integrity level (A)SIL D
3) Absolute Column Angle α for straight-ahead alignment
Input Position Variables
• Absolute Rotor Angle δAbs
• Qualifier Rotor Angle δAbs
• References for Absolute Position based on Unit [°] or [mm]
• Off-Set
Output Position Variables
• Column angle αstraight-ahead-alignment
• Qualifier αstraight-ahead-alignment
• Offset αstraight-ahead-alignment
• Max Offset αstraight-ahead-alignment
• Max Gradient between boths offset values (αpinion, αstraight-ahead-alignment)
• Transmission Ratio i
Validy Check of Input Variable δAbs
A) The control flow checks if there is a invalid state Hex 0xE.
B) One of the two following conditions must be set to obtain a valid straight ahead column angle αAbs
• Qualifier Rotor Angle δAbs = Hex 1d = Valide, proved and plausible
• Qualifier Rotor Angle δAbs = Hex 2d = Valide
C) Evaluate the Trigger Event to transfer from Hex 0xE to Hex 2d or Hex 1d
C.1 Questionnaire for Hex 1d and Hex 2d Transition Conditions
If
δRef exists for more than 300ms (30 FlexRay-Cycles),
&& the MultiTurn Count value is available
&& δAbs is verified as valid
then Transition to Qualifier Hex 2d is valid
C.2.1 Hex 0xE is deactivated.
C.2.3 Qualifier Hex 2d is activated
C.2.3.1 The Entry Action Qualifier Hex 2d is executed
Qualifier αAbs for straight direction = Hex 2d (valid)
Finsih evaluation
Else If
δRef exists for more than 300ms (30 FlexRay-Cycles),
&& the MultiTurn Count value is available
&& δAbs is verified as valid, proved and plausible
then Transition to Qualifier Hex 1d is valid
C.2.1 Hex 0xE is deactivated.
C.2.3 Qualifier Hex 1d is activated
C.2.3.1 The Entry Action Qualifier Hex 1d is executed
Qualifier αAbs for straight direction = Hex 1d (valid, proved and plausible)
Finsih evaluation
Else
Qualifier αAbs for straight direction is invalid = Hex 0d (invalid)
End If
Off-Set Pinion Angle for α-straight-ahead-alignment
The value of the offset is either related to the α-pinion or to an actual valid substitute.
Error Handling
With PCB OFF (Switched IGN Clamp 15N = 0 (OFF)) the offset for α-straight-ahead-alignment
is stored as a parameter in the EEPROM. If no Offset message for α-straight-ahead-alignment
is receive per NetWork, the EEPROM value is used as a substitute.
If there is Failure identification per timeout, the last valid offset related to the pinion
is used. If this offset value is valid after this failure for the 1st time, the max gradient
is taken into acount.
α-straight-ahead-alignment
All input values are to be refered to the
• column angle α [°]
• pinion angle [°] (IndexSensor)
αstraight-ahead-alignment = δAbs - Offsetα-straight-ahead alignment
If the offset related to the pinion need to be related to the rack displacment [mm], the
value is converted.
Take into acount the transmission i if need to be related to the rack displacment [mm].
Ystraight-ahead-alignment = (δAbs - Offsetα-pinion) * i [mm/°]
Limits for α-straight-ahead alignment
The offsetα-straight-ahead alignment is limited by two parameters
• Max Offsetα-straight-ahead alignment
• Max gradient between boths Offset values (α-pinion, α-straight-ahead direction)
Tollerance for α-straight-ahead alignment
The column angle αstraight-ahead-alignment has a maximum relative failure of ± 5 ° for the center
point range @ 0 Nm column torque input (hand wheel) with respect to linearity, sensitivity, drift
over temperature, lifetime. The total failure may increase with increasing the column torque only
within the failure tolerance of the torsion bar.
Formats & Parameters (ASAM A2l-File)
αstraight-ahead-alignment
• Unit : (°)
• Default Value : n.a
• Value Range : -1500 ... + 1500 (°)
• Minimum Resolution : 0.05 (°)
Qualifier αstraight-ahead-alignment
• Valid : Hex = 1d
• Invalid : Hex = 0d
Parameterisation
Max Offsetα-straight-ahead alignment
• Unit : (°)
• Default Value : 0.04 (°)
• Value Range : 0 ... 100 (°)
• Minimum Resolution : 0.1 (°)
Max Gradient (α-pinion, α-straight-ahead alignment)
• Unit : (°/s)
• Default Value : 0.04 (°/s)
• Value Range : 0 ... 100 (°/s)
• Minimum Resolution : 0.1 (°/s)
Offset α-straight-ahead alignment
• Unit : (°/s)
• Value Range : 0 ... 100 (°/s)
• Minimum Resolution : 0.001 (°)
Transmission i
• Value Range : 40 ... 100 ()
4) Absolute Column Angle Velocity ω
Qualifier Absolute Column Angle Velocity ω
For Qualifier αstraight-ahead-alignment is valid = Hex 1d
If δAbs is known and therefore the transmission ratio i is known,
the angle velocity (°/s) or Rack Travel Velocity Ẏ(t) (mm/s) can be determined.
Therefore the Qualifier Absolute Column Angle Velocity ω is valid = Hex 1d
For Qualifier αstraight-ahead-alignment is invalid = Hex 0d
If δAbs (°) or YAbs (mm) and thus the transmission ratio i
is unknown when using a variable rack, a substitute value ω is used since the angular
velocity (°/s) or Rack Travel Velocity Ẏ(t) (mm/s) cannot be determined.
Therefore the Qualifier Absolute Column Angle Velocity ω is invalid = Hex 0d
Maximal Rack Travel Velocity Ẏ(t)
Y(t) = ω * i
Ẏ(t) = 1 m/s
Tollerance for Column Angle Velocity ω
All tolerances refer to the difference between angle variabe and the real value.
The max Offset Failure of the column angle velocity ω is less than 5 °/s and for the
entire relative displacement ± 20 °/s with respect to linearity, sensitivity, drift
over temperature, lifetime.
Unwanted dither signal value of 5 °/s as peak disturbance of noise (pid adjust D)
All tolerances refer to the difference between angle variabe and the real value.
Formats & Parameters (ASAM A2l-File)
Column Angle Velocity ω
• Unit : (°/s)
• Default Value : n.a
• Value Range : -1500 ... + 1500 (°/s)
• Minimum Resolution : 0.05 (°/s)
Qualifier Column Angle Velocity ω
• Valid : Hex = 1d
• Invalid : Hex = 0d
5) Column Torque Tcolumn
Column Torque Tcolumn has at least
• a value range between -8 Nm and +8 Nm
• a resolution of 0.005 Nm
Ttorsion-bar = + Tcolumn - J∗d²ω/dt² - Tμ∗dω/dt
Qualifier Column Torque Tcolumn is
• Valid, proved and plausible if the signal quality is fulfilled
• Invalid the signal quality is not fulfilled
Time to receive hard wired signal per input variable (receive message)
• Max Time required to achieve Tcolumn from Transducer is less than 2 ms
Signal quality
Required Gain & Phase Margin of the elec. torque signal Tcolumn
A low-pass filter circuit supresses and attenuate unwanted transducer output signal elements
such as an underdamped 1st order Butterworth-Filter specifying
• bandwidht
• cutoff frequency
• resonace peak
• resonant frequency
Pass-Band:
Open loop horizontal I/O relationship up to a cutoff frequency of 25 Hz and an attenuation of 3 dB
Tolerances for Column Torque Tcolumn
The overall failure for an offset error is less than 0.1 Nm
Relative failure is less than ± 0.5 Nm with respect to linearity,
sensitivity, drift over temperature, lifetime.
The linearity error of the output signal with respect to the real torque value
• 0.2 Nm output error per 1 Nm real torque
• 0.05 Nm output error per 0.01 Nm real torque
Max. hysteresis for entire elec. torque signal range is less than 0.1 Nm
Unwanted dither signal value of 0.02 Nm as peak disturbance of noise
Formats & Parameters (ASAM A2l-File)
Column torque Tcolumn Input per torsion bar
• Unit : (Nm)
• Default Value : n.a
• Value Range : -10 ... + 10 (Nm)
• Minimum Resolution : 0.005 (Nm)
Qualifier Column Torque Tcolumn
• Valid : Hex = 1d
• Invalid : Hex = 6d
• Initialisation : Hex = 8d
• Temporary : Hex = 14d
Net-Driver Hand Wheel Torque
The hand wheel torque (Nm) is the algebraic sum consisting of column
torque signal Tcolumn generated by the torsion-bar Minus the Inertia
Load J and the friction load Tμ acting on the steering assemblies.
Total Torque = ∑Tcolumn = + Driver-Hand-Wheel-Torque - J×d²ω/dt² - Tμ×dω/dt + syncronous a.c. motor power output
• Hard Wired Receive Message : Net-Driver-Hand-Wheel-Torque = ∑Tcolumn = + Ttorsion-bar - J×d²ω/dt² - Tμ×dω/dt
• NetWork Receive Message : Speed Vehicle VVehicle
Note for a.c. motor low energy state
After reaching a safety low energy state, the manual steering torque applied by the driver remains and acts on the
steering sub-assembly. Under all circumstances, this manual column torque applies sufficient rack force to change
the angular position of the wheel/tire.
Formats & Parameters (ASAM A2l-File)
Driver Hand Wheel Torque
• Unit : (Nm)
• Default Value : n.a
• Value Range : -10 ... + 10 (Nm)
• Minimum Resolution : 0.001 (Nm)
Parametrisation
Inertia Load
• Unit : (kgm²/s²)
• Default Value : n.a
• Value Range : 0 ... + 100 (kgm²/s²)
• Minimum Resolution : 0.1 (kgm²/s²)
Friction Load
• Unit : (N)
• Default Value : n.a
• Value Range : 0 ... + 2000 (N)
• Minimum Resolution : 0.1 (N)
Quality and Safety for Column Torque Tcolumn
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Safety Concept (ISO 26262 Part 3)
The approved safety concept shows the risk assessment of safety related failures with the help of
the ISO 26262 Risk Matrix and shows how monitoring processes will detect failure modes within tasks
or functions and how the Error Handling safegards the specified Safety Goals with an interrupt safety
routine.
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of hardware circuits (BOM) for signal & control flow processes.
Risk Classification for Column Torque Tcolumn
For safety relevant functions within the Control Group, were a incorrect Column Torque Tcolumn can cause a serious
functional safety problem, the variable is classified as (A)SIL D due to the HRA (Risk and Hazard analysis).
A dangerous failure consequence is a wrong Column Torque Tcolumn signal value. Within a process safety time
(Failure Detection + Failure Reaction) of less than 30ms, the safe state has to be reached.
• Safe State : No use of the input Variable Tcolumn and failure indication per invalid qualifier
• Error Tolerance Time: t.b.d.
• Risk : Safety integrity level (A)SIL B(D)
Recommended Diagnostic Coverage (DC) Target Values
(A)SIL (B)D
• DC_SPFM: > 99%
• DC_LFM: > 90%
Recommended Failure Propability Rates per Hour
(A)SIL (B)D • PFH: ... 1 FIT < 3*E-9 Failure/h
Required Propability Metric for safety relevant hardward failures
PMHF = PMHF(SPF) + PMHF(LF) = 5 FIT (<5 X E-9/h)
CRC-Value Failure, Alive-Count Failure and/or Timeout Failure
A violation of the signal quality is communicated via the associated qualifier or per signal timeout. The NetWork
and explicit message associated with the output variable Tcolumn is protected by the associated qualifier and
CRC-Value and Alive-Counter checks.
• Risk : Safety integrity level (A)SIL B(D)
6) Rack Force
Rack Performancce Points
Following curves are implemented per software function
• Upper Line ´(Max) for Zero Speed
• Upper Line (Max) for Vehicle Speed
When moving the rack (mm) per pinion, both force lines have 4 points
P1, P2, P3 and P4 for rack forces [N] per rack velocities [m/s]. The
Force line while rolling or driving is lower than the force line for
the stationary vehicle at zero speed. The rack velocity [m/s] will
increase, when the battery supply voltage becomes greater than 12 VDC.
This applies up to 13.5 VDC. Hereafter the rack velocity [m/s] stays
constant
• For P2 increase rack velocity [m/s] by 2 % per 1 VDC step
• For P3 increase rack velocity [m/s] by 8 % per 1 VDC step
• For P4 increase rack velocity [m/s] by 4 % per 1 VDC step
During MSA , the points of both curves are interpolated.
If required for the physical load, a higher force can be provided by
stretching the limits per SW measures.
A degration protects components against from overheating.
Following propability to meet required lines @ t = 80°C with V = 12 VDC.
• 99.9968 % of the EPS meets at least 90 % of the lines
• 99.725 % of the EPS meets at least 100 % of the lines
Left and Right Rack Forces
Steering gear that converts the torque of the rotating column generated by
the electric motor into a translational rack force via a pinion.
• - 25 KN .. 0 .. + 25 KN with 5 N resolution
Qualifier FNetRack is
• Valid, proved and plausible if the variable meets the specified values : Hex = 2d
• Invalid or temporay invalid if the variable does not meet the specified values : Hex = 15d or 14d
The Qualifier FNetRack will never be sent with the state invalid Hex = 15d
.
The Qualifier FNetRack is only set to Hex = 8d (initialization) if the FlexRay buffer has already
been initialized but no output value FNetRack has been processed and implicit send yet.
Time processing Hex = 8d (initialization)
• Max Initialisation Time is less than 300 ms
Time to process net power output per motor drive feed back path
• Max Time receiving implicit message to process and send FEPS is less than 2 ms
Tolerance FNetRack
The basis for the Rack Force per syncronous a.c. motor FEPS
(elec. output torque (Nm) at a certain rotor speeds (rpm)) is
related to the current consumption I(A) per motor phase. The
linearity error corresponds to the difference between the net
power output feed back path converted to FEPS and the
stored data values for real rack force, averaged over the
specified force range.
Formats & Parameters (ASAM A2l-File)
Static Rack Force FEPS proportional to rotor drive shaft torque output
• Unit : (KN)
• Default Value : n.a
• Value Range : -25 ... + 25 (KN)
• Minimum Resolution : 0.0084 (KN)
Net Rack Force FNetRack
• Unit : (KN)
• Default Value : n.a
• Value Range : -17 ... + 17 (KN)
• Minimum Resolution : 0.0084 (KN)
Qualifier Net Rack Force FNetRack
• Valid : Hex = 2d
• Initialisation : Hex = 8d
• Temporary invalid: Hex = 14d
• Invalid : Hex = 15d
7) Friction Load acting on the steering assembly
The Coulomb sliding or rolling friction that occurs between the contact
surfaces of the steering assemblies is learned for αAbs = +/-90(°).
Fμ = μR × FN
The friction load is pre-measured and determined in order to correct
small friction fluctuations in series production, thus achieving a
constant and ideal steering feel in every vehicle.
Hereafter, the frictional load acting on the steering system during
operation is estimated and compared to SOP default data.
When the PCB is switched off (Switched IGN Clamp 15N = 0 (OFF)), the
assumed frictional load is stored as a learned parameter to the EEPROM
and compared with the stored default data.
Fμ data are (+) assigned and stored independent of steering direction.
A high friction load is an undesired disturbance input which affects the value
of the manual steering torque applied by the driver and the controlled output.
Within a range of αAbs = +/- 90(°) the maximal deviation between the
assumed friction data Fμ-assumed during operation and the default
data Fμ-default is less or equal than 15 N.
Qualifier Friction Load Fμ-assumed
If
the Fμ-assumed can be determined after the hand wheel is turned 1 up to max 4 times for at least αAbs +/- 5°,
then
the qualifier Fμ-assumed indicates Hex = 2d (Assumed Friction Load is learned).
........If ........the deviation between Fμ-assumed and the Fμ-default is creater than 15 (N)
........then
........the qualifier Fμ-assumed indicates Hex = 4d (Substitute value for Learned Assumed Friction Load)
........&& qualifier Fμ-increased indicates Hex = 2d (Increased Friction Load detected)
........Else
........the deviation between Fμ-assumed and the Fμ-default is less than 15 (N)
........then
........the qualifier Fμ-assumed indicates Hex = 10d (Assumed Friction Load is yet not learned)
........End If
Else
Fμ-assumed cannot be determined due to missing or qualitatively insufficient necessary input values,
then
the qualifier Fμ-assumed indicates Hex = 6d (Fμ-assumed is Passive).
End If
Qualifier Friction Load Fμ-increased
If
the qualifier Fμ-assumed indicates Hex = 10d (Assumed Friction Load is yet not learned)
then
the qualifier Fμ-increased indicates Hex = 1d (Increased Friction Load is not yet learned)
Else If
the qualifier Fμ-assumed indicates Hex = 4d || qualifier Fμ-increased indicates Hex = 4d
then
........If
........the value of Fμ-assumed is between 0.75×2KN and 1×2KN of the threshold Fμ-increased
........then
........the qualifier Fμ-increased indicates Hex = 2d (75 % Threshold Exceeded)
........Else
........the value of Fμ-assumed is more than 1×2KN of the threshold Fμ-increased
........then
........the qualifier Fμ-increased indicates Hex = 3d (100 % Threshold Exceeded)
........End If
Else
Fμ-increased cannot be determined due to missing or qualitatively insufficient necessary input values,
then
the qualifier Fμ-increased indicates Hex = 0d (Fμ-increased is Passive)
End If
Formats & Parameters (ASAM A2l-File)
Assumed Friction Load Fμ-assumed
• Unit : (N)
• Default Value : n.a
• Value Range : 0 ... + 2000 (N)
• Minimum Resolution : 0.1 (N)
Qualifier Assumed Friction Load Fμ-assumed
• Assumed Friction Load Learned : Hex = 2d
• Substitute value for Learned Assumed Friction Load : Hex = 4d
• Assumed Friction Load Passive : Hex = 6d
• Assumed Friction Load Not Learned : Hex = 10d
Qualifier Increased Friction Load Fμ-increased
• Increased Friction Load Learned : Hex = 2d
• Increased Friction Load Learned : Hex = 3d
• Increased Friction Load Passive : Hex = 0d
• Increased Friction Load Not Learned : Hex = 1d
Parametrisation
Lerned Value Assumed Friction Load Fμ-assumed
• Unit : (N)
• Default Value : 0 (N)
• Value Range : 0 ... + 2000 (N)
• Minimum Resolution : 1 (N)
Threshold for Increased Friction Load Fμ-increased
• Unit : (N)
• Default Value : 2000 (N)
• Value Range : 0 ... + 2000 (N)
• Minimum Resolution : 0.1 (N)
Quality and Safety for Friction Load acting on the steering assembly
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Safety Concept (ISO 26262 Part 3)
The approved safety concept shows the risk assessment of safety related failures with the help of
the ISO 26262 Risk Matrix and shows how monitoring processes will detect failure modes within tasks
or functions and how the Error Handling safegards the specified Safety Goals with an interrupt safety
routine.
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of hardware circuits (BOM) for signal & control flow processes.
Safety risk associated with increased friction load
In case of an low energy state of the EPS, e.g. due to HW Failure or
Degration, the risk of an increased in hand wheel torque due to friction
compared to the released hand wheel torque (IEC R-79) must be low.
After reaching a safety low energy state, the manual steering torque
applied by the driver remains and acts on the steering sub-assembly.
Safety Strategy (Safe Life)
The probability of failure due friction within service life is small.
Increasing friction in the steering assembly can be perceived by
the driver to a sufficient extent to initiate a WorkShop Inspection.
8) Command Input TQR to generate rotor drive shaft output TDrive-Shaft
The electrical transducer signal TQR resulting from a small manual torque applied to the hand wheel is the main input
to the forward path of the feedback-controller, which regulates the power output of the synchronous a.c. motor.
A torque overlay Toverlay is an desired input signal which affects the output TDrive-Shaft. If no torque overlay is selected,
the received message includes No-Torque-Overlay as a string that is interpreted as a value (Literal).
Command Input TQR has at least
• a value range between -10 Nm and +10 Nm
• a resolution of less than 0.005 Nm
The feedback value is the torque output response TDrive-Shaft at a certain rotor speed N (rpm) under specified operation
conditions(e.g. duty cycles for power output @ different ambiant temperatures or permanent magnet temperatures),
and is related to the current consumption I(A) per motor phase (shunt). The steady-state error value, is the algebraic sum
consisting of the command input value TQR (Nm) plus or minus the feedback value for TDrive-Shaft (Nm), taking into acount
• output overshoot
• output delay time
• output rise time
• output settling time
• output predominant time constant
The delay time of the feedback path (phase current I1,2,(3)) to provide the message
power output (P = M×N ~ U×I) to the NetWork is less than 10 ms.
Tolerances for Command Input TQR
The max Command Input Failure with respect to linearity, sensitivity, driftover temperature, lifetime is
• less than +/- 0.1 Nm @ rack velocities Ẏ ≤ 70 (mm/s) for the entire torque range (-10 Nm .. +10 Nm)
• less than +/- 0.5 Nm @ rack velocities Ẏ > 70 (mm/s) for the entire torque range (-10 Nm .. +10 Nm)
9) Battery Supply Voltage (Clamp 30) for High Current Consumption of synchronous a.c. motor
The integrated Electrical-Supply-Power-Management controls the supply of the battery terminal 30 for the high
current switched terminal voltage Udrain at the 3 phase clamps of the synchronous AC motor. The basis for the
net mechanical power Pout (KW) at a given rotor speed N (rpm) is related to the PWM high and low side
switching states S1, S2, S3, S4, S5 and S6.
The phase current I1,2,(3) measured per shunt corresponds to the feedback variables Id,q, wereby the
feedback variable Iq represents the output torque Tdrive shaft (Nm).
The current measurement I1,2,(3) has at least
• a value range between 0 A and +120 A
• a resolution of 1 A
The delay time of the feedback path (phase current I1,2,(3)) to provide the message
power output (P = M×N ~ U×I) to the NetWork is less than 10 ms.
If the current consumption is unknown, a substitute value for Iq is used.
Tolerances for the current value
The max current Failure with respect to linearity, sensitivity, driftover temperature, lifetime is
less than +/- 5 A for the entire current range (0 A .. +120 A)
10) Electrical Power Consumption Pelec = U(V) × I(A) × cos(φ)
Electrical Power Consumption Pelec ~ U×I has at least
• a value range between -1.5 KW and +1.5 KW
• a resolution of 0.05 KW
The delay time of the feedback path (phase current I1,2,(3)) to provide the message
power output (P = M×N ~ U×I) to the NetWork is less than 10 ms.
If the Electrical Power Consumption is unknown, a substitute value for Pelec is used
Signal quality
Required Gain & Phase Margin of the elec. power signal Pelec
The relative stability for the gain and phase margin of the elec. power output signal
behaves such as an underdamped 1st order Butterworth-Filter specifying
• bandwidht
• cutoff frequency
• resonace peak
• resonant frequency
Pass-Band:
Open loop horizontal I/O relationship up to a cutoff frequency of 25 Hz and an attenuation of 3 dB
Tolerances for Electrical Power Consumption Pelec
The output failure is less than ± 0.1 KW with respect to linearity,
sensitivity, drift over temperature, lifetime.
11) Mechanical Power Output Pout = T(Nm) × N(rpm)
The output variable provides the net mechanical power output Pout incl. all elec. and mech. losses
and incl. all degrations applied to the output.
Mechanical Power Consumption Pout = T×N has at least
• a value range between 0 and +1.5 KW
• a resolution of 0.01 KW
The delay time of the feedback path (phase current I1,2,(3)) to provide the message
power output (P = M×N ~ U×I) to the NetWork is less than 10 ms.
If the Mechanical Power Output is unknown, a substitute value for Pout is used
Tolerances for Mechanical Power Output Pout
The output failure is less than ± 0.05 KW with respect to linearity,
sensitivity, drift over temperature, lifetime.
12) Available Rotor Drive Shaft Torque T(Nm)
The output variable provides the actual available Rotor Drive Shaft Torque TDrive-Shaft incl. all losses and
degrations compared to the synchronous a.c. motor maximal torque curve TDrive-Shaft = f(RPMDrive-Shaft)
stored in EEPROM.
Mechanical Torque TDrive-Shaft has at least
• a value range between 0 and +10 Nm
• a resolution of 0.005 Nm
The delay time of the feedback path (phase current I1,2,(3)) to provide the message
power output (Available TDrive-Shaft) to the NetWork is less than 10 ms.
If the Mechanical Torque is unknown, a string Torque-Not-Available is interpreted as a value (Literal).
Tolerances for Mechanical Torque TDrive-Shaft
The output failure is less than ± 0.1 Nm with respect to linearity,
sensitivity, drift over temperature, lifetime.
13) Rotor Drive Shaft Speed N(rpm)
The output variable provides the Rotor Drive Shaft Speed NDrive-Shaft.
Rotor Drive Shaft Speed NDrive-Shaft has at least
• a speed range between 0 and +4000 RPM
• a resolution of 10 RPM
The delay time to provide the rotor drive speed message to the NetWork is less than 10 ms.
If the Rotor Speed is unknown, a string Rotor-Speed-Not-Available is interpreted as a value (Literal).
Tolerances for Rotor Speed NDrive-Shaft
The output failure is less than 50 RPM with respect to linearity, sensitivity, drift over temperature, lifetime.
Quality and Safety for Command Input TQR to generate rotor drive shaft output TDrive-Shaft
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Program Flow Control (Technical Safety Concept)
The Safe States refer to all inputs, processes and outputs. A Safety Module is implemented as SW-Component to reduce
the risk for partial or total none compliance with the required Safety State with following SW based Safety Levels:
• Safety Level 1 [L1] for executing Functions (module processes, class methods)
• Safety Level 2 [L2] for monitoring program flow (receive messages, processes, send messages)
• Safety Level 3 [L3] for independent input, process and output checks
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of memory partions circuits for signal & control flow processes.
Safety risk associated with Power Output Forwarth- and Feedback-Path
Accesses to the units and components of the microcontroller are encapsulated in drivers as basic SW components (Autosar).
Communication with the Network interface is made via Rx/Tx communication ports. A input unit reads per hard wired circuit
line the analog signal supplied by the transducer corresponding to a specific measured torque command value. The Analog/
Digital Link of the input port converts the analog signal into binary data for a specified resolution and writes the data into
a register cell. The data is called from the processor-unit that processes different tasks and sends there computation results
per output port and/or communication port to the motor drive forward path that logical switches the 3 motor phases per high
and low side outputs S1, S2, S3, S4, S5 and S6.
Among others the following malfunction can appear
• Errors on Receive-Msg, Power Output Processing and Send Msg
• Wrong or mixed address/pointer/data lines
• Write & readability of the memory cells
• Data loss/corruption
• Errors during power up and down
• Error during initialization
• Errors on NetWork Messages
Safety Strategy by Complement
All inputs, processes and outputs are monitored by the program control flow, that cyclic executes read & write checks
and consistency checks of ROM- and RAM- data. A ROM test triggered by a safety task, compares the bit sum of affected
code pieces and its data with an associated default memory checksum. In case of an ROM defect, an interruped is triggered,
that tries to successfully complete the ROM test in order to resume a initialisation to normal operation.
RAM data is transferred to ROM cells. Errors that are transferred lead to ROM errors. Therefore, cyclic RAM tests are
executed. RAM cell content of Received Data is checked by Question/Answer-Control-Procedures for correct answers.
Computed data are written as result values and there complement values into RAM cells. One of both is checked per reading
back and comparing the result with the pre data bits. If both do not match, there is an error.
If there is wrong data or a loss of data, the Error Handling executes a reset in all Memory-Diagnose-Paths, and the power
output stage for the 3 motor phases is de-energized and a task triggers a SW-Reset such as PowerDown and PowerUp again.
Initilized RAM cells are checked by qualifiers, whose state indicate the data bit consistency before passed on to the data bus.
In the case of a permanent defective RAM cell that no longer permit writing or prevent the affected motor data from becoming
consistent, the Error Handling will remain to safegard the Safety Goal. No implicit or explicit data will be transfer to an
associated function.
Main Functions used by the Control Group
• Steering Comfort Levels
• Hand Wheel Vibration
• Active Return
• Damping
• Thermal
• Limit Power Output of Synchronous A.C. Motor
• Friction Compensation
• Software End Stop
• Energy Management for High Current Consumption
• Combustion Engine Start-Stop-Function (MSA)
• External Signal Applied per Interface to the Feedback Control Loops
• Interface used for EPS to act as a Position Loop
1) Steering Comfort Levels
There are 3 damping ratio ζ for overdamped response curves of the elec. steering assist incl. the return to the center
position.
A) Damping ratio ζ for Hard
B) Damping ratio ζ for Sport
C) Damping ratio ζ for Balanced
Following Simplified Examples
A case operator selects per variable (switch value) a curve that represents a damping ratio ζ
((Switch Value = 1) ? ζ = Curve 1 for Hard : ((Switch Value = 2) ? ζ = Curve 2 for Sport : ζ = Curve 3 for Balanced))
The damping values are faded in and out linearly in an adjustable time
If
Initialisation (or Reset)
then
....If
....Transducer output signal is available
....then
....Map Input Signal = Transducer output signal
....Else If
....Map Input Signal = Replacement value
....A DTC is set
....End If
Selct ζ = Curve 3 for Balanced Steering Response Characteristic
&& activate normal column angulare velocity to return to the center position
........If
........Power Output Ready Process is running
........Switch value debouncing time ≤ 3 FlexRay-Cycles (e.g. 30 ms)
................If
................A communication error occured (e.g. timeout)
................then
................use last valid switch value || replacement value until a new valid value is received per NetWork
................A DTC is set
................Else If
................the variable is not available
................then
................use last valid switch value || replacement value until a new valid value is received per NetWork
................A DTC is set
................Else
................Variable exsist
................then
....................If
....................the switch value is not 1 || the switch value is not 2
....................then
....................Selct ζ = Curve 3 for Balanced Steering Response Characteristic
....................&& activate normal column angulare velocity to return to the center position
....................Else If
....................the switch value is 2
....................then
....................Selct ζ = Curve 2 for Sport Steering Response Characteristic
....................&& additional column angulare velocity to return to the center position
....................Else
....................the switch value is 1
....................then
....................Selct ζ = Curve 1 for Hard Steering Response Characteristic
....................&& activate fast column angulare velocity to return to the center position
....................End If
.................End If
........End If
End If
Quality and Safety for Steering Comfort Levels
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Program Flow Control (Technical Safety Concept)
The Safe States refer to all inputs, processes and outputs. A Safety Module is implemented as SW-Component to reduce
the risk for partial or total none compliance with the required Safety State with following SW based Safety Levels:
• Safety Level 1 [L1] for executing Functions (module processes, class methods)
• Safety Level 2 [L2] for monitoring program flow (receive messages, processes, send messages)
• Safety Level 3 [L3] for independent input, process and output checks
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of memory partions circuits for signal & control flow processes.
Safety Strategy
The variable is sent with a QM classification. To prevent a violation of the
safety goals addressed to the EPS, the message is forwarded within the EPS
according to the functional safety concept.
Safe State
3 discrete switch values with 3 damp ratios for response curves that maintain
the internal functions of the EPS
Functional Safety Integration
Safety Integration Level (A) SIL with recommended Diagnostic Coverage (DC)
Target Values and recommended Failure Propability Rates per Hour according
to the Safety Goal specified for the EPS.
2) Hand Wheel Vibration
Warning function EVI (Elec. Vibration Indication) performed by the synchronous
a.c. motor that generates feedback a high-frequency sinusoidal torque output
to the column and its torsion bar at the current operating point, which
leads to a torque vibration (EVI_Torque) to the Hand Wheel as a feedback
for the driver.
The specified pattern as well as the intensity of the vibration is send per
Diagnostic Trouble Code (DTC).
Input Signals
Vehicle Speed
Qualifier Vehicle Speed
EPS_State (Off or On)
Reference Signals
Degration State
Executed DTC to select EVI-Patter with EVI-Intensity
Output Signals
EVI_Qualifier
EVI_Torque with specified EVI-Patter with EVI-Intensity (Signed)
If Both Battery Pols Connected
then
Transition between Terminal 30 and Terminal 15N
........If
........Terminal 15N = 0 (open [+ 12 V] ign-switch behind battery)
........then
........ECU OFF State
........EVI-State = 0
........EVI-Qualifier = Function Not Available
........Else If
........Terminal 15N = 1 (close [+ 12 V] ign-switch behind battery)
........then
........Transition between ECU Off State and ECU On State
........• Wake-Up
........• Initialisation and activate ECU On State latest after t = 100 ms
........ECU ON State
........Transition between Motor Drive OFF State and Motor Drive ON State
........EVI-State = 1
................If ................Debounced Communication Error
................Else If ................Binary Code 1101 = Function Not Avaialable
................Else If ................Binary Code 1110 = Functional DCT
................Else If ................Binary Code 1111 = Signal has no Number
................then
................EVI-Pattern = Invalid
................Else .......................If .......................Absolut EVI-Torque ≥ 0.01 Nm &&
.......................then
.......................EVI-Qualifier = Available Function is Active
.......................EVI-Start-Patter ...................................If ...................................Select EVI-Patter = 1
...................................then
...................................EVI-Start ...................................EVI-Active-Time = Duration 1 (s)
...................................EVI-Passiv-Time = Duration 1(s)
...................................EVI-Ramp = 1(Nm/s)
...................................EVI-Intensity = 1
...................................EVI-Torque = Factor 1
...................................EVI-Frequency = Factor 1
.........................................If
.........................................EVI-Active-Time < Duration 1(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 1
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else If ...................................Select EVI-Patter = 2
...................................then
...................................EVI-Active-Time = Duration 2(s)
...................................EVI-Passiv-Time = Duration 2(s)
...................................EVI-Ramp = 2(Nm/s)
...................................EVI-Intensity = 2
...................................EVI-Torque = Factor 2
...................................EVI-Frequency = Factor 2
.........................................If
.........................................EVI-Active-Time < Duration 2(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 2
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else If ...................................Select EVI-Patter = 3
...................................then
...................................EVI-Active-Time = Duration 3(s)
...................................EVI-Passiv-Time = Duration 3(s)
...................................EVI-Ramp = 3(Nm/s)
...................................EVI-Intensity = 3
...................................EVI-Torque = Factor 3
...................................EVI-Frequency = Factor 3
.........................................If
.........................................EVI-Active-Time < Duration 3(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 3
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else If ...................................Select EVI-Patter = 4
...................................then
...................................EVI-Active-Time = Duration 4(s)
...................................EVI-Passiv-Time = Duration 4(s)
...................................EVI-Ramp = 4(Nm/s)
...................................EVI-Intensity = 4
...................................EVI-Torque = Factor 4
...................................EVI-Frequency = Factor 4
.........................................If
.........................................EVI-Active-Time < Duration 4(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 4
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else If ...................................Select EVI-Patter = 5
...................................then
...................................EVI-Active-Time = Duration 5(s)
...................................EVI-Passiv-Time = Duration 5(s)
...................................EVI-Ramp = 5(Nm/s)
...................................EVI-Intensity = 5
...................................EVI-Torque = Factor 5
...................................EVI-Frequency = Factor 5
.........................................If
.........................................EVI-Active-Time < Duration 5(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 5
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else If ...................................Select EVI-Patter = 6
...................................then
...................................EVI-Active-Time = Duration 6(s)
...................................EVI-Passiv-Time = Duration 6(s)
...................................EVI-Ramp = 6(Nm/s)
...................................EVI-Intensity = 6
...................................EVI-Torque = Factor 6
...................................EVI-Frequency = Factor 6
.........................................If
.........................................EVI-Active-Time < Duration 6(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 6
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else If ...................................Select EVI-Patter = 7
...................................then
...................................EVI-Active-Time = Duration 7(s)
...................................EVI-Passiv-Time = Duration 7(s)
...................................EVI-Ramp = 7(Nm/s)
...................................EVI-Intensity = 7
...................................EVI-Torque = Factor 7
...................................EVI-Frequency = Factor 7
.........................................If
.........................................EVI-Active-Time < Duration 7(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 7
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else If ...................................Select EVI-Patter = 8
...................................then
...................................EVI-Active-Time = Duration 8(s)
...................................EVI-Passiv-Time = Duration 8(s)
...................................EVI-Ramp = 8(Nm/s)
...................................EVI-Intensity = 8
...................................EVI-Torque = Factor 8
...................................EVI-Frequency = Factor 8
.........................................If
.........................................EVI-Active-Time < Duration 8(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 8
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else If ...................................Select EVI-Patter = 9
...................................then
...................................EVI-Active-Time = Duration 9(s)
...................................EVI-Passiv-Time = Duration 9(s)
...................................EVI-Ramp = 9(Nm/s)
...................................EVI-Intensity = 9
...................................EVI-Torque = Factor 9
...................................EVI-Frequency = Factor 9
.........................................If
.........................................EVI-Active-Time < Duration 9(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 9
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................Else ...................................Select EVI-Patter = 10
...................................then
...................................EVI-Active-Time = Duration 10(s)
...................................EVI-Passiv-Time = Duration 10(s)
...................................EVI-Ramp = 9(Nm/s)
...................................EVI-Intensity = 10
...................................EVI-Torque = Factor 10
...................................EVI-Frequency = Factor 10
.........................................If
.........................................EVI-Active-Time < Duration 10(s)
.........................................then
.........................................Ramp up to EVI-Torque = Factor 10
.........................................Else
.........................................then
.........................................Ramp down to EVI-Torque = Factor 0
.........................................End If
...................................End If .......................Else If .......................Absolut EVI-Torque < 0.01 Nm
.............................If .............................EVI-Time > EVI-Active-Time + EVI-Passiv-Time .............................then .............................EVI-Restart-Patter .............................End If .......................Possible to Select a New EVI-Patter = 1 || 2 || .. || .. || 10 &&
.......................Possible to Select a New EVI-Intensity = 1 || 2 || .. || .. || 12
.......................Reset ton .......................Else If .......................EVI-Intensity = 0
.......................Else If .......................EVI-Malfunction-Indication = Nill
.......................Else .......................EVI-Qualifier = Not Available || EVI-Qualifier = Not Active
.......................then
.......................EVI-Qualifier = Available Function but Not Active
.......................Select EVI-Patter = 0
.......................EVI-Active-Time = Duration 0 (s)
.......................EVI-Passiv-Time = Duration 0 (s)
.......................EVI-Ramp = 0 (Nm/s)
.......................EVI-Intensity = 0
.......................EVI-Torque = Factor 0 = 0 Nm
.......................EVI-Frequency = Factor 0 = 0 Hz
.......................End If ........End If
Formats & Parameters (ASAM A2l-File)
Following parameters with specified intensity levels
Par EVI=f(Vehicle Speed)
• Unit : (km/h)
• Default Value : n.a.
• Value Range : 0 ... 250 (km/h)
• Minimum Resolution : 1 (km/h)
• Interpolation : 6 points
Par EVI=f(Driver Hand Wheel Torque)
• Unit : (Nm)
• Default Value : n.a
• Value Range : 0 ... + 10 (Nm)
• Minimum Resolution : 0.1 (Nm)
• Interpolation : 6 points
Par EVI-Torque-Frequency f(THand Wheel, VVehicle)
• Unit : (Hz)
• Default Value : n.a.
• Value Range : 15 ... 30 (Hz) = Factor 0 ... 10
• Minimum Resolution : 1 (Hz)
• 2-D Table: X-> VVehicle, Y-> THand Wheel
Note
The 2-D table has two inputs VVehicle and THand Wheel
and sets the recomended Torque-Frequency (Hz) for
an input pair. For 30 Hz, at least 7 interpolation
points per oscillation are used.
Par EVI-Torque f(THand Wheel, VVehicle)
• Unit : (Nm)
• Default Value : n.a.
• Value Range : 0 ... 10 (Nm) = Factor 0 ... 10
• Minimum Resolution : 0.01 (Nm)
• 2-D Table: X-> VVehicle, Y-> THand Wheel
Note
The 2-D table has two inputs VVehicle and THand Wheel
and sets the recomended Torque-Amplitude (Nm) for
an input pair.
Par EVI-Pattern-Active-Time
• Unit : (s)
• Default Value : n.a.
• Value Range : 0 ... 60 (s)
• Minimum Resolution : 0.01 (s)
Par EVI-Pattern-Passiv-Time
• Unit : (s)
• Default Value : n.a.
• Value Range : 0.05 ... 2 (s)
• Minimum Resolution : 0.01 (s)
Par EVI-Gradient_Ramp
• Unit : (Nm/s)
• Default Value : 20 (Nm/s)
• Value Range : 0 ... 1000 (Nm/s)
• Minimum Resolution : 0.1 (Nm/s)
Quality and Safety for Elec. Vibration Indication (EVI)
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Program Flow Control (Technical Safety Concept)
The Safe States refer to all inputs, processes and outputs. A Safety Module is implemented as SW-Component to reduce
the risk for partial or total none compliance with the required Safety State with following SW based Safety Levels:
• Safety Level 1 [L1] for executing Functions (module processes, class methods)
• Safety Level 2 [L2] for monitoring program flow (receive messages, processes, send messages)
• Safety Level 3 [L3] for independent input, process and output checks
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of memory partions circuits for signal & control flow processes.
Safety Strategy
The variable is sent with a QM classification. To prevent a violation of the
safety goals addressed to the EPS, the message is forwarded within the EPS
according to the functional safety concept.
Safe State
No actuation of EVI Vibration
Functional Safety Integration
Safety Integration Level (A) SIL with recommended Diagnostic Coverage (DC)
Target Values and recommended Failure Propability Rates per Hour according
to the Safety Goal specified for the EPS.
3) Active Return
Feature belongs to EPS steering functions
Coded parametrization
Datatyp: Word (uint8)
Default : Binary 0000 1111 , 15 Decimal, Hex = F
Bit 1: Process Active Return
The small hand wheel torque acting on the column Tmanual is amplified by the synchronous a.c. motor,
resulting in a total torque ∑T (Nm) = Tmanual + Telectric, which is sufficient to change the rack position
Y (mm) in order to turn the front wheels via the tie rods.
Interrupt Fade Out Hand Wheel Torque and Return to Center Position
When the desired steering direction is reached, the rack speed Ẏ (mm/s) ~ angular column velocity ω (°/s)
becomes 0 and a torque balance TColumn = TDrive-Shaft is created and causes the column to rotate back to the
center position αstraight ahead, while the opposite rack speed - Ẏ (mm/s) ~ angular column velocity - ω (°/s) is
linearly reduced to 0 (°/s).
TBalance = TColumn = TDrive-Shaft > 0.05 Nm
The SW-Component that generates the desired column return signal - ωOut (°/s) represents an proportional
behaviour related to the gain factor f (vehicle speed). With + ω = 0 (°/s) the reference return input − ωIn (°/s)
is applied to the SW-Component in order to set the desired column return − ωOut. The feedback signal is the
actual value of the column return − ωOut, which is algebraic summed with the reference input − ωIn to obtain
the desired column return control action.
- ωOut = gain factor f(vehicle-speed) × (-) ωIn
Note: see also Safety Goal 5
If
the torque direction and angle velocity direction are assigned the same || the qualifier αstraight ahead is invalid
then
the gain factor is 0
Else
the qualifier αstraight ahead is valid
then
the gain factor is ramped within 1 Second to its 100 % set value
End If
With 80 % max rack force F (N) the steady state ω error is absolutely less then 10 (°/s).
If
the reference input − ωIn > 100 °/s
then
the max transient ω error is ± 50 °/s
Else
the reference input − ωIn < 100 °/s
then
the max transient ω error ± 10 °/s
End If
Input Variables
• Vehicle Speed VVehicle
• TQR (Command Input)
• Column angle αstraight-ahead-alignment
• Qualifier αstraight-ahead-alignment
• Column angle αColumn
• Qualifier column angular velocity
• Column angular velocity ωColumn
• Rotor angle αRotor
• Drive Shaft Torque TDrive-Shaft
• Drive Shaft Speed NDrive-Shaft
Output Variables
• TBalance
• Gain Factor
• Return column angular velocity − ωIn
• Return column angular velocity − ωOut
Formats & Parameters (ASAM A2l-File)
Parameterisation
Return Angular Velocity ωReturn
• Unit : (°/s)
• Default Value : n.a
• Value Range : 0 ... 1000 (°/s)
• Minimum Resolution : 1 (°/s)
• 2-D Table: X-> ωReturn, Y-> αReturn
Gain Factor
• Unit : (Nm/°/s)
• Default Value : n.a
• Value Range : 0 ... 1 (Nm/°/s)
• Minimum Resolution : 0.000001 (Nm/°/s)
• 1-D Table: X-> Gain-Return = f(Vehicle Speed)
Par f(Vehicle Speed)
• Unit : (km/h)
• Default Value : n.a.
• Value Range : 0 ... 250 (km/h)
• Minimum Resolution : 1 (km/h)
• Interpolation : 8 points
Return Angle αReturn
• Unit : (Nm)
• Default Value : n.a
• Value Range : 0 ... 10 (Nm)
• Minimum Resolution : 0.01 (Nm)
Return Torque TReturn
• Unit : (Nm)
• Default Value : n.a
• Value Range : 0 ... 10 (Nm)
• Minimum Resolution : 0.01 (Nm)
4) Damping
Feature belongs to EPS protection functions
Coded parametrization
Datatyp: Word (uint8)
Default : Binary 0011 0101 , 53 Decimal, Hex = 35
Bit 3: Damping
The Hand Wheel Damping depends on the
• Input Variable angular column velocity ωcolumn
The paremeter defining a response curve is the
• Adjustable Damping Factor ζ
A family of different curves with different damping factors is given by the
• Input Variable Vehicle Speed VVehicle
The Scaling of the Damping depends on the assignment of
• TRQ (Column Torque)
The Damping of the column torque counteracts and increases with angular velocity ωcolumn
∑T = TQR ≥ Θinertia × α = Θinertia × ω²Rel + inertia × δRel + Const.
Input Variables
• Column angular velocity ωColumn
• Qualifier column angular velocity
• Vehicle Speed VVehicle
• Rotor angular velocity ωRotor
• TQR (Command Input)
• References for Position based on Unit [°]
Output Variables
• n.a.
Formats & Parameters (ASAM A2l-File)
Parametrisation
Par_Damping VVehicle
• Unit : (km/h)
• Default Value : n.a.
• Value Range : 0 ... 250 (km/h)
• Minimum Resolution : 1 (km/h)
• Interpolation : 8 points
Note
Linear interpolation means that the
two output points for ζ are connected
by a straight line, e.g. if the input
20km/h has the outut value ζ = 0.2 and
the input 40km/h has the output value
ζ = 0.6, the output result ζ for an input
value 30km/h will be ζ = 0.3.
Note
Rounded interpolation means that the
input values V between two output
points ζ, are always the same as an
shifted input value V at the smaller
output point ζ. With the both output
points ζ = 0.2 and ζ = 0.6, the output
would be 0.2 for every input Speed V
greater than 20km/h and smaller than
40km/h
Par_Damping ωColumn
• Unit : (°/s)
• Default Value : n.a.
• Value Range : 0 ... 3000 (°/s)
• Minimum Resolution : 1 (°/s)
• Interpolation : 6 points
Par_TColumn_Damping
• Unit : (Nm)
• Default Value : 0.1 (Nm)
• Value Range : 0 ... + 2 (Nm)
• Minimum Resolution : 0.01 (Nm)
• Interpolation : 7 points
Par_Damping Scale
• Unit : (-)
• Default Value : n.a.
• Value Range : 0 ... 1 (-)
• Minimum Resolution : 0.000001 (-)
• 1-D Table: X-> TColumn_Damping
Note
The 1-D table has one input and returns one output
value with its related ζ.
Par_Damping ζColumn
• Unit : (Nm/°/s)
• Default Value : n.a.
• Value Range : 0 ... 1 (Nm/°/s)
• Minimum Resolution : 0.000001 (Nm/°/s)
• 2-D Table: X-> VVehicle, Y-> ωColumn
Note
The 2-D table has two inputs with there related ζ
and returns one output value for each input pair.
´ 5) Thermal
Feature belongs to EPS protection functions
Coded parametrization
Datatyp: Word (uint8)
Default : Binary 0011 0101 , 53 Decimal, Hex = 35
Bit 5: Thermal
The Thermo Management protects the EPS from overheating.
NetWork Messages in terms of this Thermo Management are information about
• Temperature EPS housing parts: Hex 0x0
• Temperature EPS printed circuit board: Hex 0x1
• Temperature EPS output stage for the 3 motor phases: Hex 0x2
To lower the temperature of the housing parts, the vehicle fan is used.
All necessary instructions like
• Blow Request
• Fan Stage
are send via NetWork.
A high temperature of the output stage affects the temperatures of motor parts
(e.g. coil, permanent magnets, ..) and pcb parts (e.g. compacitor, ..).
To measure the temperature of the output stage 2 pick ups are used. A SW-Component
reduces the power output to cover all extreme situations caused by over temperature
such as
• Close to stalled motor (max. current in one phase)
• Continuously rotating (max. power dissipation)
• Duty cycle (different motor loads)
• Voltage range (min, nominal, max)
• Ambient temperature ranges
Transient Estimators consider temperature overshoots as a percentage of the final
steady-state temperature value during heat-up and cool-down phases.
All factors for thermal stability (transient and steady state behaviour) are stored
during power off. With a power up the power off time (e.g. parking) is considered to
adjust the the thermal factors during initialisation.
To measure the temperature of the pcb 2 pick ups are used. To lower the temperature
of the printed circuit board the output stage for the 3 motor phases is de-energized
by a ISR when the measured pcb temperature reaches a max value that could destroy
critical components prior to there Failure Propability Rates.
Input Variables
• Temperature Management
• Supply-Power-Management I(A)slow
• Phase current consumption I(A)fast
• Rotor angular velocity ωRotor (°/s)
Output Variables
• Elec. air blower stage (1, 2, ...)
• Overal temperatur pcb Tpcb
• Overal temperatur bridge Tbridge
6) Limit Power Output of Synchronous A.C. Motor
Feature belongs to EPS protection functions
Coded parametrization
Datatyp: Word (uint8)
Default : Binary 0011 0101 , 53 Decimal, Hex = 35
Bit 6: Current
If
Motor Drive OFF State
then
ramp down to 0 A
Else
Motor Drive ON State,
then
ramp up to the Min_Value while comparing the following signals
• Treshold_Current_Limit_Value
• Degradation_Temperature_Value
• Degradation_Vehicle_Speed_Value
• Degradation_Voltage_Supply_Value
• Degradation_MSA_Value
• Degradation_Malfunction_Value
The limitation of the Power Output is not greater than
the smallest value of the above signals
End If
Input Variables
• Treshold_Current_Limit_Value>
• Degradation_Temperature_Value
• Degradation_Vehicle_Speed_Value
• Degradation_Voltage_Supply_Value
• Degradation_MSA_Value
• TDrive-Shaft ~ Phase Current • Motor Drive State (True/False)
• Qualifier EPS_Function
• ECU_State (True/False)
Output Variables
• Current Limitation
Formats & Parameters (ASAM A2l-File)
Current Value
• Unit : (A)
• Default Value : n.a
• Value Range : 0 ... 120 (A)
• Minimum Resolution : 1 (A)
Parameterisation
Current Limit Range
• Unit : (A)
• Default Value : n.a
• Value Range : 60 ... 120 (A)
• Minimum Resolution : 1 (A)
Current Limit Activation Gradient
• Unit : (A/s)
• Default Value : 300 (A/s)
• Value Range : 10 ... 50000 (A/s)
• Minimum Resolution : 1 (A/s)
Current Limit Deactivation Gradient
• Unit : (A/s)
• Default Value : 300 (A/s)
• Value Range : 10 ... 50000 (A/s)
• Minimum Resolution : 1 (A/s)
7) Friction Compensation for Motor Torque TDrive-Shaft
Feature belongs to EPS compensation functions
Coded parametrization
Datatyp: Word (uint8)
Default : Binary 0011 0111, 55 Decimal, Hex = 37
Bit 0: Compensate Friction
Selection of Friction Compensation
• Friction Compensation Off : Binary = 0 0 0 0
• Coulomb or rolling friction compensation active : Binary = 0 0 0 1
• Rack Force depending friction compensation active : Binary = 0 0 1 0
• Static friction compensation active : Binary = 0 1 0 0 d
A) General Friction Compensation Condition
If
Bit for Friction-Compensation-Function is set Dec = 0
then
Disable the Friction Compensation Function && Friction Compensation for Motor Torque TDrive-Shaft = 0 Nm
.....If
.....Bit for Friction-Compensation-Function is set Dec = 1 for Static Friction Not Learned || Passiv Static Friction
.....then
.....Ready Friction Compensation Function Ready && Drive-Shaft Torque Friction Compensation = 0 Nm
.....Else
.....State_Manipulated_Friction_Compensation is set Dec = 0
.....then
.....Disable the Friction Compensation Function && Drive-Shaft Torque Friction Compensation = 0 Nm
.....End If
Else If
.....If
.....Bit for Friction-Compensation-Function is set Dec > 1 && Manipulated_Friction_Compensation = 1
.....then
.....Enable the Friction Compensation Function
.....Else
.....Bit for Friction-Compensation-Function is set Dec = 6
.....&& State_Assumed_Friction = Static Friction Learned || Replacement Value for Static Friction
.....&& Manipulated_Friction_Compensation = 1
.....then
.....Enable the Friction Compensation Function
.....End If
End If
Input Variables
• State Manipulated_Friction_Compensation Value
• Factor
• State Factor
• Actual Rack Force
• Assumed Friction
• State Assumed Friction
Output Variables
• Manipulated_Friction_Compensation Value
• State Manipulated_Friction_Compensation Value
B) Manipulated_Friction_Compensation
The process compensates for the increase in friction.
Normal Friction Condition is pre-tested as Normal_Friction Value = Parametrisation_Friction × Factor
If Manipulated_Friction_Compensation Value > Normal_Friction Value
then
Enable the Normal Friction Compensation
Else
the difference between Manipulated_Friction_Compensation Value and Normal Friction Value is less than 0.001
then
Disable the Friction Compensation Function, otherwise the steering will become tough
End If
Factors
If
the State_Factor indicates Factor Disable interpreted as a value ≠ Dec 1 (Literal)
then
Manipulated_Friction_Compensation Value = Normal_Friction Value
&& ramp Factor from actual Manipulated_Friction_Compensation to Normal_Friction Value = 1
Else
the State_Factor indicates Factor Enable interpreted as a value = Dec 1 (Literal)
then
&& ramp Factor from Normal_Friction Value = 1 to requested Manipulated_Friction_Compensation value
.....If
.....Abs(Manipulated_Friction_Compensation − Normal_Friction) is less than 0.01
.....then
.....Manipulated_Friction_Compensation = Parametrisation_Normal_Friction
.....End If
End If
C) Coulomb Friction Condition
The process compensates for the increase in coulom friction or rolling friction that occurs between
the contact surfaces of the steering assemblies.
Code Switching
If
Bit to compensate rolling friction is set then
.....If
.....Coulomb Friction Value < Parametrisation_Maximal_Coulomb_Friction
.....&& Coulomb Friction Value > Parametrisation_Coulomb_Friction
.....then
.....Compensation_Coulomb_Friction = Abs(Assumed Friction Value − Normal_Friction Value)
.....End If
Else
Compensation for rolling friction is not set
End If
D) Load Depending Friction Condition
The process compensates friction depending on the actual rack load.
If
Bit to compensate load depending friction is set then
Enable Compensation_Load_Depending_Friction = f(curve)
Note
The 1-D table has one input FRack and returns one output
value with its related μLoad.
Else
Compensation for load depending friction is not set (Disable)
End If
E) Static Friction Condition
The process compensates the static fricting between surfaces that are not in movement.
If
the State_Factor indicates Factor Disable interpreted as a value ≠ Dec 1 (Literal)
then
.....If
.....Bit to compensate static friction is set then
..........If
..........State_Assumed_Friction = Static Friction Learned || Replacement Value for Static Friction
..........then
..........Enable Compensation_Static_Friction = Parametrisation_Static_Friction × (Assumed Friction + Load_Depending_Friction)
..........Else If
..........State_Assumed_Friction = Static Friction Not Learned || Passiv Static Friction
..........Enable Compensation_Static_Friction = Parametrisation_Static_Friction × (Normal_Friction Value + Load_Depending_Friction)
..........Bit for Friction-Compensation-Function is set Dec = 1
..........End If
.....End If
Compensation for static friction is not set (Disable)
End If
Formats & Parameters (ASAM A2l-File)
Friction Compensation
• Unit : (Nm)
• Default Value : n.a
• Value Range : -10 ... 10 (Nm)
• Minimum Resolution : 0.001 (Nm)
State Manipulated Friction Compensation
• Friction Compensation Off : Hex = 0x0
• Friction Compensation Ready : Hex = 0x1
• Friction Compensation : Hex = 0x6
Qualifier Assumed Friction Load Fμ-assumed
• Assumed Friction Load Value Learned : Hex = 0x2
• Assumed Friction Load Value Replaced : Hex = 0x4
• Assumed Friction Load Value Passive : Hex = 0x6
• Assumed Friction Load Value Not Learned : Hex= 10
Parameterisation
Normal Friction Compensation
• Unit : (N)
• Default Value : n.a.
• Value Range : 0 ... + 500 (N)
• Minimum Resolution : 1 (N)
Min Normal Friction Compensation
• Unit : (N)
• Default Value : 0 (N)
• Value Range : 0 ... + 500 (N)
• Minimum Resolution : 1 (N)
Max Normal Friction Compensation
• Unit : (N)
• Default Value : n.a.
• Value Range : 0 ... + 2000 (N)
• Minimum Resolution : 1 (N)
Rack Load FRack depending Compensation
• Unit : (N)
• Default Value : n.a.
• Value Range : 0 ... + 25000 (N)
• Minimum Resolution : 1 (N)
• Interpolation X : 6 points
• 1-D Table: X-> FRack
Factor
• Unit : ()
• Default Value : n.a.
• Value Range : 0 ... + 2 ()
• Minimum Resolution : 0.001 ()
Factor to ramp in to compensation
• Unit : (1/s)
• Default Value : n.a.
• Value Range : 0 ... 1 (1/s)
• Minimum Resolution : 0.01 (1/s)
Factor to ramp out of compensation
• Unit : (1/s)
• Default Value : n.a.
• Value Range : 0 ... 1 (1/s)
• Minimum Resolution : 0.01 (1/s)
8) Software End Stop @ Vehicle Speed close to Stop
The right and left end stop is calculated separately, as both can be different.
The overdamped ζ end stop function acts as if a spring is compressed and becomes harder
Following values acting within the end stop region
• ΣF (N) is the sum of the forces applied to the rack
• c (kg/s²) as a pseudo-spring-constant
• ζ (kg/s) as a pseudo-damping ratio
• Y(t) (m) is the rack travel
• Ẏ(t) (m/s) is the rack velocity as a time derivative of the relative rack travel Y(t)
Note
To avoid possible noise, the mechanical stop is not reached. However, the function
does not cause the rack to be pushed back to the center position. When moving back
in the direction of the center position, the damping ζ is deactivated.
When the SW Stop Position is reached, a load balance is created. Hereby the sum of
the rack forces ΣFrack @ SW End Stop position is less than the specified
rack force F (N) required to move the rack with max speed Ẏ (m/s).
Input Variables
• Mechanical Right Stop Value
• State Mechanical Right Stop
• Mechanical Left Stop Value
• State Mechanical Right Stop
• Index Sensor Value
• Column angle αColumn
• Vehicle Speed VVehicle
• State Vehicle Speed VVehicle
Output Variables
• End Stop Motor Torque ± TEnd-Stop with opposite signed to the steering direction
SW End Stop Activation
If
αstraight-ahead = Invalid
then
ΣF ~ -TEnd-Stop = 0 Nm
Else If
the TQR and the αstraight-ahead variable have different signs
then
- TEnd-Stop = 0 Nm
Else
αstraight-ahead = Valid
then
F(ζ, c) < ± Abs(TEnd-Stop + 8 Nmcolumn)
End If
SW End Stop Position Y
SW Stop Position = (Mechanical Stop Position - Adjustable_Position_Gap_End_Stop)
SW End Stop Torque TEnd-Stop
If
YRack = SW Stop PositionRack
then
ΣFrack < 2-D Table: X-Coordinate -> F(Ẏ), Y-Coordinate -> Ẏ
• ΣFrack = + Frack-manual + Frack-assist - FEnd Stop
• ΣTpinion = + Tmanual + TDrive-Shaft - TEnd Stop
Else
- TEnd-Stop = 0 Nm
• ΣFrack = + Frack-manual + Frack-assist
• ΣTpinion = + Tmanual + TDrive-Shaft
End If
SW End Stop Damping Ratio ζ
If
Index Angular Velocity ≤ Max_ẎEnd_Stop
then
F(ζ) = 0 Nm
Else If
Index Angular Velocity > Max_ẎEnd_Stop
then
F(ζ) = Parametrisation_Damping_Ratio_End_Stop = f(Ẏ)
End If
Formats & Parameters (ASAM A2l-File)
End Stop Motor Torque TEnd-Stop
• Unit : (Nm)
• Default Value : n.a
• Value Range : -10 ... 10 (Nm)
• Minimum Resolution : 0.001 (Nm)
Parameterisation
Vehicle Speed close to stop
• Unit (km/h)
• Default Value : 9 (km/h)
• Value Range : 0 ... 9 (km/h)
• Minimum Resolution : 1 (km/h)
SW End Stop Position δ(°) ~ Y(mm)
• Unit : (°) or (mm)
• Default Value : n.a.
• Value Range : 0 ... 100 (°) or (mm)
• Minimum Resolution : 1 (°) or (mm)
FEnd-Stop
• Unit (N)
• Default Value : n.a.
• Value Range : 0 ... ? (N)
• Minimum Resolution : 1 (N)
• Interpolation : 8 points
• 2-D Table: X-Coordinate -> F(Ẏ), Y-Coordinate -> Ẏ
Angular velocity ω (°/s)
• Unit (°/s)
• Default Value : n.a.
• Value Range : 0 ... 3000 (°/s)
• Minimum Resolution : 1 (°/s)
SW End Stop Damping Ratio ζ
• Unit (kg/s)
• Default Value : n.a.
• Value Range : 0 ... 1 (kg/s)
• Minimum Resolution : 0.001 (kg/s)
9) Energy Management for High Current Consumption
The output variable provides the net mechanical power output Pout incl. all elec.
and mech. losses and incl. all degrations applied to the output. The basis for the
elec. output torque (Nm) at a certain rotor speeds (rpm) is related to the current
consumption I(A) per motor phase corresponding to Iq (q-Vector).
The maximal current consumption of the 12 Volt Coils is adjustable by coding and
application data. Default data Class 2 according the following three classes for
the peak current of the synchronous a.c. motor @ entire operation range and at all
times as a stored default parameter for transient and steady state responses
• Class 1 : Imax @ 12 VDCnominal < 85 A
• Class 2 : Imax @ 12 VDCnominal < 105 A
• Class 3 : Imax @ 12 VDCnominal < 125 A
Additional Degradation
In case a power output degradation is activated, the actual lowest operation current
limitation is selected (Least Detect as Par_Max_DC_current).
Driving State (vehicle speed signal > 10 km/h)
If Power Output Ready State is set and the absolute vehicle speed signal VVehicle > 10 km/h
is set. Remain Power Output Ready State (PCB) = ON and transfers to the Motor Drive = ON. Hereby
the EPS always adjusts to an optimal Imax (A).
MSA State (engine off/on)
Degration not applicable.
RCP State (remote control parking)
In all cases where an undervoltage below 10 VDC occurs, the motor drive is switched off within 1 ms.
• Power Output Ready State (PCB) = ON
• Motor Drive = OFF
External specified degradation message (Max_I_Spec_EPS)
The EPS 12-volt battery connector meets the Class 2 current requirements. The max. permitted current
draw Imax (A) between a lower and a upper adjustable current operation (40 A ≤ I ≤ 105 A) is provided via
a Flex-Ray Message to the SW-Component, that submits the actual drain current draw through the terminal
plug to the NetWork with an accuracy of ΔI = ± 5 A.
Accracy of Current Limitation
• Max_I_Spec_EPS = Imax ± ΔI, ΔI = ± 5 A
Adjustable Limitation of Current Gradient
• İmax = ± 20 A/s (Default)
Power Up
If
Initialisation Processing
then
use stored Max_I_Spec_EPS as replacement value as long as no valid value is received via the NetWork
End If
Mintoring
If
Vehicle speed signal > 10 km/h
then
Enable monitoring (e.g. wrong signals, time-out, etc.) with a Debouncing Time of 3 s
.......If
.......Max_I_Spec_EPS ≥ 40 A or Max_I_Spec_EPS ≤ 70 A
.......then
.......check failure memory
.............If
.............Message Max_I_Spec_EPS is Invalid
.............then
.......................If
.......................time ≤ 3 cycles (e.g. 30 ms)
.......................then
.......................Last Valid Message for Current Limit Value is used
.......................Else
.......................time > 3 cycles (e.g. 30 ms)
.......................then
.......................Ramp to an replacement value (e.g. 120 A)
.......................End If
...............Else
...............Message for Max_I_Spec_EPS is Valid
...............then
...............Ramp Max_I_Spec_EPS to a valid Imax while considering İmax
...............End If
.......End If
End If
Internal specified degradation message
Speed-related self-degradation
Allowing to select 6 × Vehicle speed dependent max current values as Max_Current_Vehicle_Speed
on a curve. This current limt value may decrease at higher vehicle speeds.
• 1-D Table: X-> Imax
Note
The 1-D table has 6 × VVehicle Inputs and returns 6 × Imax Outputs.
Voltage-dependent self-degradation
Two 2-D tables are provided with there voltage dependent max current values as Max_Current_Supply_Voltage
and there related Supply Voltages.
Default Values Imax:
• 1 : Imax @ 32 VDCnominal < 42.5 A
• 2 : Imax @ 10 VDCnominal < 42.5 A
• 3 : Imax @ 7 VDCnominal < 0 A
A table includes the NetWork Message for each pair (Max Current, Supply Voltage)
• Linear Interpolation : 8 points
Current Limit for Normal On-board 12 VDC Power Supply Operation
• 2-D Table
NetWork Messages t.b.d. with X-Coordinate -> Suply Voltage, Y-Coordinate -> Max Current
Current Limit for reduced operation of 12 VDC on-board power supply
• 2-D Table
NetWork Messages t.b.d. with X-Coordinate ->Suply Voltage, Y-Coordinate -> Max Current
Global supply voltage
Drain voltage from 8 VDC to 18 VDC with regard to 12V stator coils. The measured high current
clamp voltage Udrain is provided via the NetWork interface.
Ensure that the Max Current Limit (42.5 A) is not exceeded
If the transient response of the high current clamp voltage Udrain at the 3 phase clamps
decays below 9 VDC, than the relevant SW-Component keeps the actual current limit and
does not reduces the current vectors Iqd to recover from this situation. Instead the global
supply voltage measurement and main diagnose is carried out by the item on which the
power management functionality is implemented.
Voltage dependable limitation of regenerative Current
The synchronous a.c. motor draws energy from the vehicle electrical system (class II 105 A)
and feeds energy back into the vehicle electrical system, whereby the regenerative current
could exceed over 100 A when operated as a generator. This regenerative current can cause
excess energy in the vehicle electrical system, which can lead to overvoltages, where the
E/E-Sub-Systems with overvoltage protection can power down. The EPS reduces the
regenerative current to a permissible maximum to prevent overvoltages while allowing
safety-relevant steering maneuvers.
• regenerative current > - 15 A @ supply voltages > 15 VDC
Situation-dependent self-degradation (e.g. abrupt E/E Sub-System interruption)
In case of vehicle electrical system failures e.g. on-board power supply not available, the
max current supply voltage limitation is reduced within 3 s (default) to 42.5 A. In case of
remote control parking routine, the max current supply voltage limitation commands 42.5 A
within 100 ms according to an adjustable max Gradient between 200 A/s ... 50 KAs.
The Degration Status is provided by the EPS via the NetWork interface.
Quality and Safety for Energy Management functions
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Safety Concept (ISO 26262 Part 3)
The approved safety concept shows the risk assessment of safety related failures with the help of
the ISO 26262 Risk Matrix and shows how monitoring processes will detect failure modes within tasks
or functions and how the Error Handling safegards the specified Safety Goals with an interrupt safety
routine.
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of hardware circuits (BOM) for signal & control flow processes.
Safety risk associated with Energy Management
In case the EPS receives a failure mode (e.g. supply voltage not available, time-out, etc.) per NetWork,
the EPS is ramped to the low current limit at least within Failure Detection + Failure Reaction = 3 Seconds.
The
• Current consumption
• State of current degration
• Current diagnostics
is made available to the Energy Management Device via NetWork with a safety integrity level of (A) SIL B.
• Estimate Rate for Controlability in case of this Failure : C2 (Normal controllable)
• Estimate Rate for Exposure in case of this Failure : E4 (High Probability or almost every driving)
• Estimate Rate for Severity in case of this Failure : S2 (server injuries)
Safe State
Within the process safety time, the following safe state is reached
• Degradation of current consumption to 42.5 A
• The final value of Max_I_External_EPS must not be less than 42.5 A
Recommended Diagnostic Coverage (DC) Target Values
(A)SIL B
• DC_SPFM: > 90%
• DC_LFM: > 60%
Recommended Failure Propability Rates per Hour
• PMHF=PMHF(SPF)+PMHF(LF)= 100 FIT (<10 X E-7/h) ≧ (A)SIL B
Risk Classification for External-Current-Degradation-Function (see Safety Goal 6)
A incorrect external Speed-Related-Self-Degradation or a incorrect external Voltage-Dependent-Self-Degradation
set value is classified as (A)SIL B due to the HRA.
Safe State
Within a process safety time, the following safe state is reached
• Degradation of current consumption to 42.5 A
• Guarantee final value of Imax not be less than 42.5 A
Risk Classification for Situation-Dependent-Self-degradation (see Safety Goal 6)
For VVehicle > 10 km/h the Situation-Dependent-Self-Degradation is classified as (A)SIL B due to the HRA.
Safe State
With an interrupt caused by undervoltage ≤ 9 VDC @ VVehicle > 10 km/h the safety goal for a
undesired abrupt assist deactivation during driving applies, and the current limit must be kept
at 42 A while allowing safety-relevant steering maneuvers. All rrror commands are handled
per power management device.
• Lower Limit Max_I_External_EPS fixed to 42.5 A
Risk Classification for Current Gradient of self-degradation
The Current Gradient is classified as (A)SIL B due to the HRA.
Safe State
The Current Limitation I (A) = Imax ± ΔI is reached per current gradient İ (A/s).
• İmax = |dI/dt| > 1 kA/s
Risk Classification for Oscillation Error (see Safety Goal 6)
Oscillation is classified as (A)SIL B due to the HRA.
Safe State
Oscillating supply voltages are prevented with the Motor-Drive design.
• Unwanted dither signal ≤ 0.02 Nm as peak disturbance
10) Combustion Engine Start-Stop-Function (MSA)
The MSA function is not valid for HYBRID-Vehicles with a Recuperation System.
The detection of the vehicle/drive variant NO_HYBRID is done via code switches.
ISO 26262 applies to MSA.
Input signals FlexRay
• Vehicle-State
• Engine-State
• Electrical-System-Undervoltage-State
• MSA-State
• VVehicle via NetWork Message (20ms)
Input Signals EPS
• Adjustable IMax
• Adjustable IMax-MSA
• Adjustable İMax-MSA
• Adjustable Duration tMSA
• IPhase-Current via Feed Back Path (2ms)
The MSA process has following two states
• MSA State 1 : Active elec. steering assist during MSA process
• MSA State 2 : Deactive elec. steering assist during MSA process
A Function State A during the MSA Stop and MSA Start Phases
ensures following functions
• MSA State 1 : All functions with all data
• MSA State 2 : NetWork, available learned values such as steering angle
Process time t = 1 s to power down. In the case of Vehicle Speed
V <= 3 km/h (rolling)..(driving) <= 15 km/h a MSA command will be
triggered 750 ms before the vehicle comes to a stop.
Note
No stop delay time in case of automatic transmission
During Power Up all functions without degrations need to be available.
To protect against under voltages @ Power Up (cold and warm starts) a
special control process talkes place for the 12 VDC high current supply
voltage (Clamp 30) of the onboard elec. system architecture by the power
management device, that controls the max. current consumption of a device.
Note Degrations are stored in the failure memory and displayed per MIL
Trigger Event
An ISR for MSA is triggered by RTOS per specific task or program part if the Vehicle
speed VVehicle < 10 km/h and all relevant explicit and implicit receive
messages are present for the MSA process.
1st MSA Step
When the 1st MSA Step is activated, the actual current consumption I (A) is ramped down to a
certain value of IMax within at least 500 ms (e.g. 1st Step 0.7 × IMax).
• IMax-MSA = 50A (Default)
Trigger Conditions for 1st MSA Step
A trigger event is necessary for a transition from normal operation state to the 1st MSA state.
The activity or inactivity of the 1st MSA state, is based on the trigger event and conditions
as well as transition action.
If
Vehicle State ≠ Hex 0x8 (≠Ready to Drive) || Vehicle State ≠ Hex 0xA (≠Driving)
&& VVehicle < 10 km/h
&& Engine State = Dec 1 , Hex 1 , Binary 0000 0011 (Engine is turned off)
&& MSA_ENG_STOP = Dec 1 , Hex 1 , Binary 0000 0001 (valid)
then
Stop Notice is triggered
&& Actual Current Consumption I is ramped down to IMax within at least 500 ms
End If
2nd MSA Step
When the 2nd MSA Step is activated, the IMax-MSA is achieved and kept.
• IMax-MSA = const.
Trigger Conditions for 2nd MSA Step
A trigger event is necessary for a transition from I70% State to IMax-MSA state.
The activity or inactivity of the 2nd MSA state, is based on the trigger event and conditions
as well as transition action.
If
Vehicle State ≠ Hex 0x8 (≠Ready to Drive) || Vehicle State ≠ Hex 0xA (≠Driving)
&& VVehicle < 10 km/h
&& Engine State = Dec 1 , Hex 1 , Binary 0000 0011 (Engine is turned off)
&& MSA_ENG_STOP = Dec 1 , Hex 1 , Binary 0000 0001 (valid)
&& Engine State = Dec 0 , Hex 0 , Binary 0000 0000 (Engine off)
then
Stop Command is triggered
&& Standby for IMax-MSA
End If
Following overview of MSA in a simplified graphical presentation :
Note: no further investigation, since obsolete technology with combustion engine
11) External Signal Applied per Interface to the Feedback Control Loops
A state mashine output applied to the Feedback Control Loops in order to cammand following specified action of the steering
• Available Interface : Manipulate the Command Input (TQR = Transducer Signal)
• Available Interface : Manipulate the Comand Output (Drive Shaft Torque)
• Available Interface : Use EPS Position Loop
• Available Interface : Manipulate Active Return Functionality
Interface to Manipulate the Command Input (TQR = Transducer Signal)
The electrical transducer signal TQR resulting from a small manual torque applied to the
hand wheel is the main command input to the forward path of the feedback-controller, that
regulates the power output [%] of the EPS.
Note
The overlay torque of ± 3 Nm affects the steering feel. The external-overlay-signal is
summed with the transducer signal that is applied in front of the forward path. The resulting
control signal is the quantity or condition that the ECU, Motor Drive and the elec. Motor
applies to the output c. In contrast to the external-motor-signal, which is added behind
the control path and which can independently change the quantity or condition that the
Function-Frame and the boost curve applies to the motor drive.
∑TCommand = TTransducer + TOverlay
The TCommand value is limited per max. limit line TMax.
A overlay torque requested via the Interface Active Sub-State (Hex 0x23) leads to the same
behavior as if the additional torque would have been applied by the driver per tranducer.
Properties of manipulated command signal
When the driver holds the Hand Wheel in the straight-ahead position, the effect of
the interface (e.g. comfort levels) is independent of the power output.
Versatile ASAM MSD description files containing different data for the program code.
e.g. With a command input the angular position of the road wheels β (°) is greater with
the *.a2L file A data setting than with the *.a2L file B data setting.
An application set (*.a2L file) provides the same angular position of the road wheels β (°) for
• XCommand (Nm) + 0Offset (Nm)
• 0Command (Nm) + XOffset (Nm)
Set Overlay States
If
Qualifier Command Signal = Convert Manual Driver Set Value
&&
Sub-State Interface Active (Hex 0x23) = [Switched On]
then
........If
........EPS Error (Hex 0x60) = [Switched Off] after debounce-time && Threshold < Interface-Deactivation-Parametrisation
........then
........∑TCommand = TTransducer + 0Overlay
........Else
........EPS Error (Hex 0x60) = [Switched On] after debounce-time && Threshold ≥ Interface-Deactivation-Parametrisation
........then
........Interrupt Service Routine according specified Error Handling for Safety Issue
........End If
End If
If
Qualifier Command Signal = Standby (Do Not Convert Overlay Value)
&&
Sub-State Standby (Hex 0xE1) = [Switched On]
then
........If
........EPS Error (Hex 0x60) = [Switched Off] after debounce-time && Threshold < Interface-Deactivation-Parametrisation
........then
........∑TCommand = TTransducer + 0Overlay
........Else
........EPS Error (Hex 0x60) = [Switched On] after debounce-time && Threshold ≥ Interface-Deactivation-Parametrisation
........then
........∑TCommand = 0 Nm
........Interrupt Service Routine according specified Error Handling for Safety Issue
........End If
End If
Interface to Manipulate the Comand Output (Drive Shaft Torque)
The external-motor-signal, which is added behind the control path and which can independently
change the quantity or condition that the Function-Frame and the boost curve applies to the
motor drive, is used to provide an specified output torque ∑Toutput to changes the rack position Y (mm).
The interface is used to provide an externally requested actuating motor torque, resulting
in a specified output torque ∑Toutput to changes the rack position Y (mm).
A additional torque requested (±) via the Interface Active Sub-State (Hex 0x23) leads to the same
behavior as if a comparably rack force ± F (N) would act to the rack from the outside instead.
• Steering angle α (°) @ TQR (Nm) = Command Input per manual Hand Wheel Torque
• Rack Force F = 0 (N) ~ Rack Torque = tqRack = 0 (Nm)
• For TQR = 0 ~ tqRack = 0 = F = 0
• ∑F (N) moves the rack Y (mm) with max speed Ẏ (m/s)
• Power output P (KW) = ∑Ti (Nm) × N (rpm) ~ U (V) × I (A) × cos(φ)
• ∑TOutput (Nm) = ± TDrive-Shaft(Nm) ± TAdditional(Nm)
∑TOutput is limited per max. motor output torque TMax-Output, monitored by the control path.
Properties of manipulated drive shaft torque output ∑TOutput)
If the driver does not apply manual torque, the additional torque commanded per interface
∑TOutput = ± 0 (Nm) ± TAdditional(Nm) results to modify the angular position of the front wheels.
When additional torque ∑TCommand = ± W
the angular position of the wheels ß (°) remain the same.
Versatile ASAM MSD description files containing different data for the program code.
e.g. A command input with a counteracting Wheel Force that does not change the angular
position of the road wheels β (°) is smaller with the *.a2L file A data setting than with
an *.a2L file B data setting.
Set Additional Torque Output States
If
Qualifier Additional Output Signal = Convert Control Path Set Value
&&
Sub-State Interface Active (Hex 0x23) = [Switched On]
then
........If
........EPS Error (Hex 0x60) = [Switched Off] after debounce-time && Threshold < Interface-Deactivation-Parametrisation
........then
........∑TOutput (Nm) = ± TDrive-Shaft(Nm) ± 0Additional(Nm)
........Else
........EPS Error (Hex 0x60) = [Switched On] after debounce-time && Threshold ≥ Interface-Deactivation-Parametrisation
........then
........Interrupt Service Routine according specified Error Handling for Safety Issue
........End If
End If
If
Qualifier Additional Output Signal = Standby (Do Not Convert Manual Set Value)
&&
Sub-State Standby (Hex 0xE1) = [Switched On]
then
........If
........EPS Error (Hex 0x60) = [Switched Off] after debounce-time && Threshold < Interface-Deactivation-Parametrisation
........then
........∑TOutput (Nm) = 0 (Nm)
........Else
........EPS Error (Hex 0x60) = [Switched On] after debounce-time && Threshold ≥ Interface-Deactivation-Parametrisation
........then
........∑TOutput (Nm) = 0 (Nm)
........Interrupt Service Routine according specified Error Handling for Safety Issue
........End If
End If
Motor Drive Transmission Behavior
Signal Quality Frequency Domain
A additional torque requested via the Interface Active Sub-State (Hex 0x23) is taken into
account in all functions that use the rack force as an input variable.
Required Gain & Phase Margin
With a bandwidth up to f = 8 Hz the I/O relationship is essentially constant and does not differ
by more than ± 1 Nm. During operation the maximum value of the magnitude ratio of output to
input is maximal 0.5 dB.
Specified Frequency-Domain for a undervoltage of 9V @ a max current consumption of 60A
The motor torque output response for a sine sweep input F1,2(Ẏ1= 0 mm/s, Ẏ2= 40 mm/s) = 40 % rack
performance corresponds to a time discrete low pass PT1 behaviour with time constant T and grain margin K
• Bandwidth : Range of frequencies up to f = 200 Hz (cutoff)
• Magnitude Ratio : Flat frequency responses of the output value, which does not differ by more than 3 dB.
• Phase magin of 45°
Specified Frequency-Domain for a voltage of 11.5V @ a max current consumption of 120A
The motor torque output response for a sine sweep input F1(Ẏ1= 70 mm/s) = 30 % rack
performance corresponds to a time discrete low pass PT1 behaviour with time constant T and grain margin K
• Bandwidth : Range of frequencies up to f = 200 Hz (cutoff)
• Magnitude Ratio : Flat frequency responses of the output value, which does not differ by more than 3 dB.
• Phase magin of 45°
Specified Frequency-Domain for a voltage of 11.5V @ a max current consumption of 120A
The motor torque output response for a sine sweep input F1,2(Ẏ1= 0 mm/s, Ẏ2= Cutoff-Velocity mm/s) = 100 % rack
(max) performance corresponds to a time discrete low pass PT1 behaviour with time constant T and grain margin K
• Bandwidth : Range of frequencies up to f = 200 Hz (cutoff)
• Magnitude Ratio : Flat frequency responses of the output value, which does not differ by more than 3 dB.
• Phase magin of 45°
Overall Relative Stability (Mech. Steering Assembly)
The stability of the steering considering inertia, friction, viscosity, lubrication,
backlash, attachments, ...., temperature) is defined by the exponentially decaying
character with a damping ratio ζ = 0.7 of a PT2 overdamped behavior
without overshoot.
FDamping(ẎRack-Velocity) ≤ 1 Nm
Prove Robust Stability with following Responses
• Transducer Input Torque TColumn(Nm)
• Rotor Drive Shaft Torque TDrive-Shaft(Nm)
• Rotor Drive Shaft Angle δAbs(°)
Test Rig
Test Stipulations
Steady state operation output values
• steady state Rack Force ( [-50%, -40%, -30%, .20%, -10%, 0%, 10%, 20%, 30%, 40%, 50%] × FMax-Rack)
Adjust torque value per single operation output value
• Torque Steps ( [5%, 10%, 20%] × TMax-Motor)
Duty Cycles
• Torque Values Ti = [ 0, 05, 0,1, 0,2, 0,4, 0,8, 1,6 ] (Nm)
• Duration td = 0,01 (s)
• Temperature ϑi = [ Min, ..., Nominal, ..., Max ]
• Duty Steps ti = [ 0, T, T + td, 2 × T, 2 × T + td, 3 × T, 3 × T + td, 4 × T, 4 × T + td, 5 × T , 5 × T + td, 6 × T, 6 × T + td , 20] @ ϑi(°C)
12) Interface used for EPS to act as a Position Loop
For the NHTSA verification tests (see customer functions), the EPS is used as a position loop to check steering angle
changes. The EPS controls the behaviour between interface input and the rotor drive shaft angle δ (°), that sets the
angular position of the column angle α (°) or pinion angle, to receive the desired position of the road wheels.
The bandwidth up to the cutoff ferequency is the range of frequencies of the input over which the synchronous a.c. motor
will respond satisfactory. The torque generated by the motor is proportional to the current loop with its bandwidth of
stability, which has sufficient reserve for the speed- and position control loops. Torque fluctuations due to overshoots
of the rotor angle δ (°) are avoided by the damping ratio ζ, which is set taking into account the safety goals required
for the active damping and depends on the actual vehicle speed.
The rotor drive shaft position feedback δ (°) as a characteristic 1-D table is obtained by integrating the angular velocity
ω (°/s) ~ N (rpm) of the rotor shaft and is calculated in the same time shedule as the active damping function (see d.1.5.1.4.1)
Set Additional damping ratio ζ
If
Qualifier Additional Damping = Convert Additional Damping ζ
&&
Sub-State Interface Active (Hex 0x23) = [Switched On]
then
Set Factor for Additional Damping Ratio ζ
End If
Interface to Manipulate Active Return Functionality
Interrupt Fade Out Hand Wheel Torque and Return to Center Position
When the desired steering direction is reached, the rack speed Ẏ (mm/s) ~ angular column velocity ω (°/s)
becomes 0 and a torque balance TColumn = TDrive-Shaft is created and causes the column to rotate back to the
center position αstraight ahead, while the opposite rack speed - Ẏ (mm/s) ~ angular column velocity - ω (°/s) is
linearly reduced to 0 (°/s).
TBalance = TCommand = TDrive-Shaft > 0.05 Nm
The SW-Component that generates the desired column return signal - ωOut (°/s) represents an proportional
behaviour related to the gain factor f (vehicle speed). With + ω = 0 (°/s) the reference return input − ωIn (°/s)
is applied to the SW-Component in order to set the desired column return − ωOut. The feedback signal is the
actual value of the column return − ωOut, which is algebraic summed with the reference input − ωIn to obtain
the desired column return control action.
- ωOut = gain factor f(vehicle-speed) × (-) ωIn
A) Factor for Active-Return-Speed ωOut
The factor is used to scale the linear reduced absolute return rack speed ± Ẏ (mm/s), which is proportional
to the return angular column velocity ± ωOut (°/s) while reducing to to 0 (°/s).
With a chosen sign convention
• (+) torque setting causes the rack to move to the left
• (-) torque setting causes the rack to move to the right
FactorReturn-Speed = 1.0 does not affect the absolute return speed
FactorReturn-Speed < 1.0 reduces the absolute return speed
FactorReturn-Speed = 0 applies to Ẏ (mm/s) ~ ωOut (°/s) = 0
B) Factor for Active-Return-Torque
The factor is used to scale
• the torque balance TColumn = TDrive-Shaft causing the column to rotate back
• the damping torque TDamping = Θinertia × ω²Out × i = Damping Factor ζ × Scaling × ωcolumn
FactorReturn-Torque = 1.0 does not affect ∑T
FactorReturn-Torque < 1.0 affects ∑T = Θinertia × α = Θinertia × ω²Out + Θinertia × δRel + Const.
FactorReturn-Torque = 0 applies to ∑T = Θinertia × α = 0
C) Signal Quality Frequency Domain
Up to a cutoff ferquency of f = 8 Hz the I/O relationship of both factors is essentially constant.
Quality and Safety for Active Interface State
The safety concept content all probable hazards (HRA) and specified all type of functional
safety requirements (FSR) to achive all Safety Goals.
Signals and States are assigned with an ISO 26262 Functional Safety Integration Levels (A)SIL.
Risk Matrix for Driving Situations were a failure mode can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Program Flow Control (Technical Safety Concept)
The Safe States refer to all inputs, processes and outputs. A Safety Module is implemented as SW-Component to reduce
the risk for partial or total none compliance with the required Safety State with following SW based Safety Levels:
• Safety Level 1 [L1] for executing Functions (module processes, class methods)
• Safety Level 2 [L2] for monitoring program flow (receive messages, processes, send messages)
• Safety Level 3 [L3] for independent input, process and output checks
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of memory partions circuits for signal & control flow processes.
Safety Strategy
General safety strategy regarding the explicitly received messages for processing the
• Active Interface : Manipulate the Command Input (TQR = Transducer Signal)
• Active Interface : Manipulate the Comand Output (Drive Shaft Torque)
• Active Interface : Use EPS Position Loop
• Active Interface : Manipulate Active Return Functionality
as well as their safety mechanisms :
The Safety Concept of the EPS considers the interface states and there functionalities that are classified
with QM. This ensures that the Safety Goals of the EPS are met when the interface is activated.
The NetWork and explicit messages associated with the interface operation are
protected by the associated Qualifier and CRC-Value and Alive-Counter checks.
Safe State
Degradation of active interface operation to validated limit values.
The limit values were chosen in such a way that they do not
act as an undesired disturbance which affects the value of
the EPS functions.
Functional Safety Integration
Safety Integration Level (A) SIL with recommended Diagnostic Coverage (DC)
Target Values and recommended Failure Propability Rates per Hour according
to the Safety Goal 1 specified for the EPS.
Transition to destination sub-state Interface Active (Hex 0x23)
The sub-state Interface Active (Hex 0x23) = [Switched On] is only active via
transition from sub-state Interface Available (Hex 0x22) with its valid Qualifier
and CRC-Value and Alive-Counter.
• Safe State : No execution of Active Interface State. Activate Error State (Hex 0x60) with default limit values
• Error Tolerance Time: such as Safety Goal 1
• Risk : such as Safety Goal 1 classified as (A)SIL D
Active Interface State with Exit Action to manipulate torque generated by motor
The active interface state (Hex 0x23) can only provide its exit action to manipulate
• the Command Input (TQR = Transducer Signal)
• the Comand Output (Drive Shaft Torque)
• the EPS Position Loop
• the Active Return Functionality
• Safe State : No execution of Exit Action && Activate Error State (Hex 0x60) with default Limit Values
• Error Tolerance Time: such as Safety Goal 1
• Risk : such as Safety Goal 1 classified as (A)SIL D
Active Interface State with parallel path as an Exit Action
In active interface state (Hex 0x23) there is a parallel path as an exit action in which the signals are filtered.
The relative stability for the gain and phase margin of this exit signal behaves such as an overdamped 1st order
Butterworth-Filter with a Cutoff Frequency of 0.3 Hz
• Safe State : No execution of Active Interface State. Activate Error State (Hex 0x60) with default limit values
• Error Tolerance Time: such as Safety Goal 1
• Risk : such as Safety Goal 1 classified as (A)SIL D
Fail Safe Strategy
With divergent redundancy, the active interface status (Hex 0x23) immediately changes to the EPS error status (Hex 0x60)
if the conditions of Hex 0x23 (classified as QM) and the redundant conditions differ.
Note
(A)SIL D is implemented within the state machine, if there is no redundancy active.
Main Steering Functions assisted by elec. Power Steering
• Straight Ahead Driving
• Accelerated Driving
• Driving on test track with different Pave Way Density Spectrum
• Rotate around the tire contact area when the car is stationary (Shunting Characteristics)
• Parallel Parking
• U-Turn within 3 Steps
• Cornering on High Way Intersection
• Roundabout
• Curb Lane Push-Off
• Pass Journey
• Dynamic Steering Maneuvers
• Slalom Maneuvers
• Lane Change Maneuvers (ISO, VDA)
• Handling Maneuvers on Nürburgring Track
• NHTSA Verification Maneuvers
• Combined Dynamic Steering Maneuvers
• Press-Test or similar to Test-Driver-Training
• Combined Park Maneuver
A)Steering Maneuvers
Driving Maneuvers are affected by the
• Vehicle and its E/E Sub-System(s)
• Environment and Road Conditions
• Driver
• Vehicle Operating and Traffic Conditions
Driving maneuvers in accordance with the European UN ECE 79 and the U.S. NCAP
(= New Car Assessment Program, test for the safety integration of new vehicles).
A-1)Straight Ahead Driving
Required steering characteristics to be met for driving @ center point range.
Accelerated Driving
• Maneuver
Testing on a fast driving test track with approx. 50 km/h and increasing up to max speed limit (Vmax).
• Evaluation Criteria
- torsional vibration of hand wheel
- pulling
- losing track
- centering
- friction and sluggishness of the steering upon slight initial steering movement in the fine/correction range (< 3°)
• Aimed Conditions
- Good center point feeling with acceptable vehicle response
- Increasing from the center point takes place continuously and prior to the 1st pointing (yaw vectoring) reaction
- Steering friction is not too low and not too high
Driving on test track with different Pave Way Density Spectrum
• Maneuver
Steering in the 0 .. 3° steering range on roads with different road density spectrum
• Evaluation Criteria
- Correction Effort
- Accuracy
- Centering
- Losing track in case of bank inclination
• Aimed Conditions
The steering center point feeling is very important. For this it is essential that the steering torque matches
the car response (yaw vectoring), that no elastic center point feeling is generated and that the steering torque
is constant without center fluctuations.
With road iregulations such as alternating lateral inclinations, lane ruts, bumps, etc.) the steering adjustment
and parameterization had only little direct influence exception steering friction. However, it has been ensured
during Boost Curve Tuning that the driver is enabled to correct these iregulations via a good centering and/or
appropriate steering torque increase from the center.
In order to improve the center point feeling, an increased steering column friction (approx. 15 Ncm) was helpful.
Because a too low rigidity has a negative impact on the center point feeling (steering precision) an appropriate
rigid steering column have been ensured.
A-2) Rotate around the tire contact area when the car is stationary (Shunting Characteristics)
• Maneuver
The test between both right and left End-Stops have been taken with a standing TestCar while using the brake and
with max weight and following angular hand wheel velocity Ẏ (°/s).
• Aimed Conditions
The steering torque have been adjusted in a range between 3.5 - 4 Nm during slow continuous steering with the brakes
applied. Hereby the steering torque remained throughout the steering angle and gained not more than 1.5 times while
reaching the right or left End-Stops. In this case, steering torque and steering angle have been symmetrical with less
than 5% derivation. No acoustically disturbing effects or other interferences occured.
A-3) Parallel Parking
• Maneuver
Following parallel parking maneuver have been tested five times with some holding torque at the return points.
• Aimed Conditions
Following profile of the rack travel have been complied with
Note
Additional extended holding force against the curb may occur during the parking procedure (also see c.4.1.7 Curb Lane Push-Off)
A-4) U-Turn within 3 Steps
• Maneuver
The turn maneuver for a two lane road have been carried out 3 times with an initial speed of 30 km/h.
• Aimed Conditions
Following profile of the rack travel have been complied with
A-5) Cornering on High Way Intersection
• Maneuver
8 cornering procedures within a High Way Intersection with a steering maneuver at max possible speed and
worst environment conditions.
• Aimed Conditions
No malfunctions or abnormalities are allowed such as :
- No unexpected low or high hand wheel torque input
- Hand wheel torque changes have been within constant boundary conditions
- There have been no changes in the vehicle responses such as Ratio Changes
A-6) Roundabout
• Maneuver
Torque profile over vehicle speed = f(max lateral acceleration, max rack forces) for 5 min or 50 times
• Aimed Conditions
The hand wheel torque has been always correlate with the curve and thus with the lateral acceleration applied.
A-7) Curb Lane Push-Off
• Maneuver
Special Miss Use Test.
• Test Parameterization
- Hand wheel torque @ 80 Nm & 110 Nm
- Max. front axle load strain
- Max. tire sizes with correct pressure
- 140 mm curb height
• Test Configuration
- specified TestCar (LabCar)
- specified axle and suspension documented (Cinematic & Dynamic)
- specified steering design documented
- specified E/E Sub-System documented (Item with its HW- & SW-Elements)
• Test Setup
- TestCar have been located in parallel to the curb
- Front left wheel has parallel contacted the curb
- TestCar have been newly aligned after each test
• Test Execution
- Steering wheel angular velocity of 120 °/s
- Measure while hand wheel turned to the left up to 80 Nm and 110 Nm
- Both tests have been repeated 3 times
• Evaluation Criteria
The curb test is performed to ensure the mechanical strength of the axle components
• Aimed Conditions
- At 80 Nm there have been no plastic deformations and all parts stayed within specified tolerances
- For 110 Nm and above there have been no safetyrelevant defects
- No noticeable or audible vibrations @ 80 Nm or 110 Nm
A-8) Pass Journey
• Maneuver
TestCar speed, cornering radius and amount of curves have been not specified. However, possible
thermal degradation (worst case) have been tested.
• Aimed Conditions
There have been no difference between uphill and downhill in the elec. steering behavior.
B) Dynamic Steering Maneuvers
B-1) Slalom Maneuvers
• Maneuver
18 Meter slalom maneuver for dynamic performance measurements (press tests). Hereby the effects on the vehicle
behavior such as the phase lag has been evaluated with this dynamic drive test. The amount of time the TestCar
driving through the slalom track test has not been specified.
• Aimed Conditions
The 18 Meter slalom maneuver has been carried out at the maximum possible TestCar speed without contact to the
traffic cones.
B-2) Lane Change Maneuvers (ISO, VDA)
• Maneuver
TestCar can be
- 1st Comfort-Relevant such as parking @ zero speed or normal steering
- 2nd Safety-Relevant with Risk Maneuvers such as power Output with unacceptable assist fluctuations
Quick lane change. More specifcally a particularly first rapid hand wheel turn for initiating an evasive yaw maneuver assisted by EPS.
• Aimed Conditions
It have been possible to perform the maneuvers at max TestCar speed without abnormalities and with no contact with the traffic cones.
B-3) Handling Maneuvers on Race Track
• Maneuver
Test drivers hand wheel inputs in correlation to lateral displacements while cornering during lap. The amount of laps have
been not specified.
• Aimed Conditions
It have been possible to perform the track without abnormalities at max TestCar cornering speeds.
B-4) NHTSA Verification Maneuvers
• Maneuver
The NHTSA verification test is an approval relevant maneuver.
Steering angle amplitude profiles with an sine oscillation = 0.7Hz and a holding time = 1s before starting the second amplitude
has been applied per automatic Test-Hand-Wheel with an torque transducer adjusted to 60Nm.
Steering angle amplitudes have been tested from min = 30° to max = 270° with 30 ° increment steps.
Tested at a speed of 80km/h with Dynamic-Stability-Control = On and Dynamic-Stability-Control = Off.
• Evaluation Criteria
Check stability/handling characteristics of vehicle steering when carrying out a NHTSA maneuver @ 80 km/h and 60 Nm applied to
the column.
• Aimed Conditions
A minimum Transferse offset for a change in hand wheel angle with the correlation between angle and torque have been achieved
for specified TestCar properties. (Check TestCar responses with steering angle changes).
C) Combined Dynamic Steering Maneuvers
During combined maneuvering the hand wheel torque stayed within a specified range.
C-1) Press-Test or similar to Test-Driver-Training
• Maneuver
Repeate 18 m slalom steering maneuver 20 times in combination with 2 X three-point turns.
After the slalom has been completed, the test-driver performs a three-point turn, followed
by driving back and then performing another three-point turn.
Measuirng the steering angle amplitude profiles Y (°) with calculated time derivative Ẏ as
angle velocity (°/s) during precise traffic cone cornering @ maximum speed are mandatory.
The maximum speed at which the TestCar moves through the traffic cones does not differ between
the Slalom Speed IN and Slalom Speed OUT.
• Aimed Conditions
For 20 repetitions of the slalom test track incl. turns, there have been no abnormalities.
C-2) Combined Park Maneuver
• Maneuver
5 X slow combined steering angle profile, consisting of following three individual maneuvers :
1st parallel parking
2nd three-point turn
3rd parallel parking
• Aimed Conditions
Following profile of the rack travel have been complied with
Note
Additional extended holding force against
the curb may occur during the parking procedure
(also see Curb Lane Push-Off)
Availability of Technical Safety Concept (Program Flow Control)
The approved safety concept shows the risk assessment of safety related failures with the help of
the ISO 26262 Risk Matrix and shows how monitoring processes will detect failure modes within tasks
or functions and how the Error Handling safegards the specified Safety Goals with an interrupt safety
routine (ISR).
Types and Definition of Failure Modes
Fault-Type A
Failure Modes that can be accommodated up by the Monitoring Process and still ensure safe operation.
Operation may be degraded, but at an acceptable driving level.
Fault-Type B
Single point failures (SPS) and latent point failures (LF) that cannot be detected by the monitoring
process and therefore the syncronous a.c. motor power output cannot be technically guaranteed and
cannot be safely controlled. In case of a SPS , there is no diagnostic coverage as well as no safety
mechanism, that prevents this failure from violating the corresponding task or function. A LF will
not be noticed by the monitoring process as well as by the driver. The EPS design must be analysed
to see if SPS and/or LF can occur before series supply !
Fault-Type C
Several consecutive Terminal IGN 15N (ON/OFF) boot cycles whereby a SPF occured or a LF
could have occured.
Definition of Signal Failurs
The difference between OK-Signal and NOK-Signal is a Signal-Failure such as following example
• without an electrical failure and/or without an mechanical failure is referred to as the OK-Signal
• with an electrical failure and/or with an mechanical failure is referred to as the NOK-Signal
Total Failures
The change in total failures refers to cascading (branche) wrong signals.
Global and Local Failure Priorities
RTOS gives priority to global failure events such as
• prio A) IRS that receives an global error message (e.g. Bat Clamp 30 is interrupted)
• prio B) ISR that receives an local error messages (e.g. Parity bit is wrong)
Monitoring, DTCs and Error Handling to protect against Failures
Considering the real-time requirements of the program code, it is generally recommended to
perform as many failure checks as possible offline.
Monitoring, DTCs and Error Handling to protect against all type of failures that can cause serious
functional safety problems during runtime. They are preliminary tested per failure insertion tests for
all EPS terminal signals (HIL-Tests) and all integrated circuits and peripheral components (FIT).
The Safety Module with its Safety Levels acts on all inputs, processes and outputs to safeguard
against the risk of partial or total noncompliance with the performance.
• Safety Level 1 [L1] for executing Functions (module processes, class methods)
• Safety Level 2 [L2] for monitoring program flow (receive messages, processes, send messages)
• Safety Level 3 [L3] for independent input, process and output checks
Following overview of the safety levels in a simplified graphical presentation
Monitoring
Data from several running tasks are read from and written to physical cell addresses
of the Memory-Partition-Areas to operate the functions. All protection mechanism such
as interrupt events are running on task level. Periodic or permanent monitoring of runing
processes have constraints on the frequency with which the process result can be send.
For monetoring routines the max. permissible time span T(ms) must be taken into account.
Error Handling: Safety Level 1
Functions which are included in the released version of the Function Frame are
addressed, executed and calculated within Level 1.
Error Handling: Safety Level 2
The program flow is monitored within Level 2. Level 2 ensures a correct execution
of all the functions within level 1 via monitoring. Monitoring can be configured to
versatile version/variant of the Function Frame. Further more level 2 provides some
interfaces to check the configured RTOS Time schedules in example for the integrity
of com drivers, load drivers or others. All code data within memory address ranges
are checked for consistency. Functions addressed, executed and calculated within
Level 1 and monitored within Level 2 can be interrupted at any time via an API by
the RTOS in case of a diagnosed failure.
Error Handling: Safety Level 3
The central part of Level 3 is located in an independent safety loop. This safety loop
is independent and not part of the Level 1 and Level 2. It is possible to configure.
the diagnostics and the respective safety reaction via Safety Functions. Procedures
for specified frequently Question/Answer Checks are used to verify plausible and
proper function outputs. A watchdog constantly monitors the runtime environment of
Level 2. The pcb voltages and pcb temperatures can be monitored via Level 3. In the
event of a fault, level 3 triggers independent from Level 1 and 2 an Error Flag [E]
for a specified Fault Reaction. Hereafter the element(s) which have been qualified
as safety mechanisms are triggered within a specified safety time.
Failure tolerant time interval [FTTI]
Process Safety Time = Failure Detection Time + Failure Reaction Time
Required failure tolerant time interval [FTTI] to reach the low energy state from actual
normal operation is t ≤ 20 ms for this level 2 type steering.
Ability to turn to the required safe state => low energy state within max. 20 ms per
Interrupt Safety Routine that abrupt decouples the phase voltage Udrain acting
to the syncronous a.c. motor coils.
Controlled Type of Failure that can cause a functional safety problem
UN ECE 79 is a Europe-wide regulation concerning the approval of vehicles with regard to the
steering assembly. However, each European country may independently approve cars with there
E/E Sub Systems with there functionalities such as lane keeping (Level 2 type) or change lanes
automatically (Level 3 type). Active monitoring provides DTCs with Error Handling that satisfies
UN ECE 79 requirements for a Level 2 type steering.
Power Output Degration
If nevertheless one or more safety related failure modes are identified per specified DTC, then
the following power output degration with driver warning MIL can take place.
Limp Home
For Failures that can be accommodated by the monitoring and were the error handling can
still maintain a safe operation :
• Task that reduces 80 % of elec. power output, in order to reach a service organisation
Limp-Aside
For Failures that can be accommodated by the monitoring but were the error handling cannot
maintain a safe operation.
• Task with emergency process to stop the road trip
Priorities
In case of a failure mode that can cause a functional safety problem, the Error Handling
will preferably provide the Limp-Home ISR with at least 20 % of max. possible elec. power
output to limp to a service organisation that can eliminate the failure and determine the
reason for the failure as well as to elimination a failure repetition. The Limp-Aside ISR
is selected in a critical events when Limp-Home is not beneficial. When all DTCs are
cleared, no degradation is active and the control path corresponds to the ready state.
Specified Safety Goals according ISO 26262 Risk Matrix
The following safety goals are rated according the Risk Matrix to protect against failures
that can cause serious functional safety problem.
Measures to avoid and control safety relevant failures
The probability of E/E Sub-System failures that can cause a serious functional safety problem
can be minimized by taking all necessary ISO 26262 Work Products and other safety strategies
into acount.
Risk Matrix for Situations such as for
• Park-State (Intermission)
• Dwell-State (Interim MSA)
• Rolling-State (Mission A)
• Drive-State (Mission B)
were a failure mode can cause a functional safety problem.
(A)SILs have been estimated from the following Risk Matrix:
(A)SIL = f { Severity S , Exposure E , Controlability C }
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of hardware circuits (BOM) for signal & control flow processes.
Safe State as Low-Energy State of the EPS in combination with residual manual column torque
By definition, the safe state is the low-energy state (off-state) of the syncronous a.c. motor, regardless of
whether this is achieved by a ramped down degration controlled by the µC-Motor acting on the gate way
and/or per abrupt decoupling of the clamp voltage Udrain acting on the stator coils.
After reaching the low energy state, the manual steering torque applied by the driver remains and acts
on the steering sub-assembly. Under all circumstances, this manual column torque applies sufficient rack
force to change the angular position of the wheel/tire.
Safety Goal 1 (protect against an unmotivated elec. motor actuation)
An unmotivated syncronous a.c. motor actuation is an incorrect power output caused by the forward parth
that can lead to an wrong wheel/tire steering force or angle with an undesired travel direction.
This failure is classified as (A)SIL D due to the HRA (Risk and Hazard analysis) :
• Estimate Rate for Controlability in case of this Failure : C3 (Difficult to control or uncontrollable)
• Estimate Rate for Exposure in case of this Failure : E4 (High Probability or almost every driving)
• Estimate Rate for Severity in case of this Failure : S3 (fatal injuries and survival not expected)
Functional Safety Requirements (FSR_1) for Safety Goal 1
Limitation of the maximum stationary force generated by the synchronous a.c. motor
on the rack for both directions of rotation (sign +/-)
The specified limitation lines of the rack force F (N) over rack travel velocity Ẏ (mm/s) coresponds to the
syncronous a.c. shaft power output T (Nm) and rotor speed ω (°/s), which motor-boost-curve varies with
the manual steering torque applied by the driver Tdriver and the actual vehicle speed VVehicle.
The net hand wheel torque (Nm) is the algebraic sum consisting of column
torque signal Tcolumn generated by the torsion-bar Minus the Inertia
Load J and the friction load Tμ acting on the steering assemblies.
Total Torque = ∑Tcolumn = + Driver-Hand-Wheel-Torque - J×d²ω/dt² - Tμ×dω/dt + syncronous a.c. motor power output
• Hard Wired Receive Message : Net-Driver-Hand-Wheel-Torque = ∑Tcolumn = + Ttorsion-bar - J×d²ω/dt² - Tμ×dω/dt
• NetWork Receive Message : Speed Vehicle VVehicle
A slight overshoot of the maximal rack force value F (N) is permissible. The critical range
for resonances (ω/ωp) is analyzed and damped accordingly (δ=Damping Factor) to avoid
dangerous kinematic vibrations or dynamic rotor shaft occilations.
Note
With a specified sign convention, a positive signal value on the torque setting
causes the rack to move to the left
Tracebility FSR_1
Adjustable data for the max. stationary force (STAT_LIM) and the max. occilation amplitude (OSC_AMP) have
been defined to ensure traceability of this Functional Safety Requirements (FSR_1).
Diagnostic Coverage & Probabilistic Metric for Random HW-Failures (PMHF) of Safety Goal 1
PMHF of Single Point Failures (PMHF(SPF)) and Latent Failures (PMHF(LF)) of the Hardware Group with the required
diagnostic coverage (DC) :
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_SPF_M > 99 % ≥ (A)SIL D
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_LF_M > 90 % ≥ (A)SIL D
• Required Probability of safety relevant Random Hardware Faults PMHF=PMHF(SPF)+PMHF(LF)= 5 FIT (<5 X E-9/h) ≥ (A)SIL D
Safety Goal 2 (protect against an undesired reverse elec. motor actuation)
Unwanted reverse steering resistance (inverse sign) is caused by steering assemblies that are sluggish or even blocked.
This failure is classified as (A)SIL D due to the HRA (Risk and Hazard analysis) :
• Estimate Rate for Controlability in case of this Failure : C3 (Difficult to control or uncontrollable)
• Estimate Rate for Exposure in case of this Failure : E4 (High Probability or almost every driving)
• Estimate Rate for Severity in case of this Failure : S3 (fatal injuries and survival not expected)
Functional Safety Requirements (FSR_2) for Safety Goal 2
A safe-life design prevents situations that lead to uncontrollability due to component failures, and a fail-safe design ensures
component durability during the service life.
Fail-Safe
Design allows the wheels/tires to be rotated by manual torque input when the steering is sluggish or blocked (reverse signing).
If the rotor drive shaft of the synchronous a.c. motor for assisting the steering of the front axle is blocked, this can always
be overcome by a high manual hand-wheel torque from the driver.
Safe-Life
A locked rotor shaft caused by a defect in the linkage corresponds to a single point failure (SPF) that cannot be corrected by
a safety mechanism. Therefore, it is very important that the steering assemblies are durable throughout their service life so
that the probability of mechanical failure is excluded.
The sluggish or blocking revers actuating torque of the E/E Sub-System must be slightly lower than the posible maximal manual
actuating Hand-Wheel torque of the driver to steer into the desired heading direction.
Tracebility FSR_2
Adjustable data for the max. revers force (FTZ_INV_HMOM) and the max. revers amplitude (AMP_INV_HMOM) have been
defined to ensure traceability of this Functional Safety Requirements (FSR_2).
Diagnostic Coverage & Probabilistic Metric for Random HW-Failures (PMHF) of Safety Goal 2
PMHF of Single Point Failures (PMHF(SPF)) and Latent Failures (PMHF(LF)) of the Hardware Group with the required
diagnostic coverage (DC) :
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_SPF_M > 99 % ≥ (A)SIL D
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_LF_M > 90 % ≥ (A)SIL D
• Required Probability of safety relevant Random Hardware Faults PMHF=PMHF(SPF)+PMHF(LF)= 5 FIT (<5 X E-9/h) ≥ (A)SIL D
Safety Goal 3 (protect against an undesired impluses while activating the elec. motor)
Prevent undesired abrupt activations or re-starts of the elec. motor torque output.
This failure is classified as (A)SIL A due to the HRA (Risk and Hazard analysis) :
• Estimate Rate for Controlability in case of this Failure : C2 (Normal controllable)
• Estimate Rate for Exposure in case of this Failure : E4 (High Probability or almost every driving)
• Estimate Rate for Severity in case of this Failure : S1 (Minor and moderate injuries are rare)
Functional Safety Requirements (FSR_3) for Safety Goal 3
To prevent an undesirably high impulse on the steering wheel, abrupt activation or restarts of the synchronous a.c. motor
is prevented by ramping up the output power from the low-energy state to the controlled target output power calculated by
the Motor Drive. Interrupts caused by under-/overvoltage, ..., etc. will be taken over by means of a linear adjustments.
A undesired PowerDown/PowerUp (Reset) happens so fast, that the program can resume normal operation without the driver
noticing the reset.
Tracebility FSR_3 n.a.
Diagnostic Coverage & Probabilistic Metric for Random HW-Failures (PMHF) of Safety Goal 3
PMHF of Single Point Failures (PMHF(SPF)) and Latent Failures (PMHF(LF)) of the Hardware Group with the required
diagnostic coverage (DC) :
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: Not Specified
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: Not Specified
• Required Probability of safety relevant Random Hardware Faults PMHF=PMHF(SPF)+PMHF(LF)= 1000 FIT (<1 X E-6/h) ≥ (A)SIL A
Safety Goal 4 (protect against incorrect steering assistance)
Prevent incorrect computation-result for the actuation signals.
This failure is classified as (A)SIL C due to the HRA (Risk and Hazard analysis) :
• Estimate Rate for Controlability in case of this Failure : C2 (Normal controllable)
• Estimate Rate for Exposure in case of this Failure : E4 (High Probability or almost every driving)
• Estimate Rate for Severity in case of this Failure : S3 (fatal injuries and survival not expected)
Functional Safety Requirements (FSR_4) for Safety Goal 4
Insufficient elec. motor torque control with superimposed angular position control stands for Safety Risk.
A measure for the quality is the compliance of all product features with the drawings and specifications.
Incorrect elec. motor output deviates from documented and specified product features. For example partial
or total non-compliance with permissible thresholds thus generating a wrong output signal.
Tracebility FSR_4
Data for the computation results (GRD_UEB_LUK) have been defined to ensure traceability of this Functional Safety Requirements (FSR_4).
Diagnostic Coverage & Probabilistic Metric for Random HW-Failures (PMHF) of Safety Goal 4
PMHF of Single Point Failures (PMHF(SPF)) and Latent Failures (PMHF(LF)) of the Hardware Group with the required
diagnostic coverage (DC) :
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_SPF_M > 97 % ≥ (A)SIL C
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_LF_M > 80 % ≥ (A)SIL C
• Required Probability of safety relevant Random Hardware Faults PMHF=PMHF(SPF)+PMHF(LF)= 5 FIT (<5 X E-8/h) ≥ (A)SIL C
Safety Goal 5 (protect driver against rotating Hand-Wheel)
Prevent injury to driver due to a hand wheel rotation such as from active return.
This failure is classified as (A)SIL C due to the HRA (Risk and Hazard analysis) :
• Estimate Rate for Controlability in case of this Failure : C2 (Normal controllable)
• Estimate Rate for Exposure in case of this Failure : E4 (High Probability or almost every driving)
• Estimate Rate for Severity in case of this Failure : S3 (fatal injuries and survival not expected)
Functional Safety Requirements (FSR_5) for Safety Goal 5
Maximum rotational energy that may be used to turn the Hand-Wheel back to center position.
Tracebility FSR_5
Data for active return (FTZ_ENG_LRB) and (GMAX_ENG_LRB) to ensure traceability of this Functional Safety Requirements (FSR_5).
Diagnostic Coverage & Probabilistic Metric for Random HW-Failures (PMHF) of Safety Goal 5
PMHF of Single Point Failures (PMHF(SPF)) and Latent Failures (PMHF(LF)) of the Hardware Group with the required
diagnostic coverage (DC) :
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_SPF_M > 97 % ≥ (A)SIL C
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_LF_M > 80 % ≥ (A)SIL C
• Required Probability of safety relevant Random Hardware Faults PMHF=PMHF(SPF)+PMHF(LF)= 10 FIT (<10 X E-8/h) ≥ (A)SIL C
Safety Goal 6 (protect against abrupt reduction of elec. motor power output)
Protect against sudden reduction of synchronous a.c. motor power output.
This failure is classified as (A)SIL B due to the HRA (Risk and Hazard analysis) :
• Estimate Rate for Controlability in case of this Failure : C2 (Normal controllable)
• Estimate Rate for Exposure in case of this Failure : E4 (High Probability or almost every driving)
• Estimate Rate for Severity in case of this Failure : S2 (server injuries)
Functional Safety Requirements (FSR_6) for Safety Goal 6
The degree of elec. power output describes the limitation of the maximum available synchronous a.c. motor torque
as a percentage of the possible output torque (%) at the actual rotor speed (rpm) up to the cutoff point. A 100 %
power output corresponds to different specifed Boost Curves [f(column torue input) = motor drive output torque request],
that depends on the actual vehicle speed (km/h). A safety degration is independent of the actual set value of the Boost
Curve. If the diagnostic detection nevertheless lowers the boost curve due to a safety relevant failure, the error handling
ensures an max. gradient of <= 33 % per Seconds of the actual requested boost output until a maximum degradation of
80 % is reached (20 % motor output power). Here a warning is signaled to the driver by a yellow malfunction indicator (MIL).
A 20 % degradation (limp home task) corresponds to a supply voltage of Ubat ≧ 7V. However, a Hand-Wheel angular
speed of up to ω = 400 ° per Seconds is still possible.
FSR 6 according following gradient plot
Tracebility FSR_6
Data for degration (KNL_SLG_ASF) to ensure traceability of this Functional Safety Requirements (FSR_6).
Diagnostic Coverage & Probabilistic Metric for Random HW-Failures (PMHF) of Safety Goal 6
PMHF of Single Point Failures (PMHF(SPF)) and Latent Failures (PMHF(LF)) of the Hardware Group with the required
diagnostic coverage (DC) :
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_SPF_M > 90 % ≧ (A)SIL B
• Required Diagnostic Coverage for ΣFITHW-Platform in case of failue: DC_LF_M > 60 % ≧ (A)SIL B
• Required Probability of safety relevant Random Hardware Faults PMHF=PMHF(SPF)+PMHF(LF)= 100 FIT (<10 X E-7/h) ≧ (A)SIL B
Safety Concept Approval
Total compliance with the expected PMFH value (see ISO26262 part 5 & 9) shall be achieved
on basis of the E/E Sub-System design and/or (A)SIL Decomposition.
CarMaker declared release of technical safety concept according the Safety Goals for the
series car supply. The safety release statements have been signed by the FSM and other
relevant technical departments as well as independent official safety assessors for the
relevant countries.
Data Base Content with Test-Model
Following Example of specified SW Design including Test-Model in a simplified
graphical presentation
Introduction Test-Models
Different test phases are carried out according to the test needs.
Test-Equipment and Software Tools are used as far as possible for
maximum support of
• tests during the development phases
• tests during the manufacturing phases
• tests (diagnose) during the series phases
An apporval differentiation was made between
• Simulated Test-Model Behavior
• Rational TestCar Behavior
Before series release tests are carried out with
• MiL (Model in the Loop)
• SiL (SW in the Loop)
• LabCars as HiL (HW in the Loop)
• TestCars (Road Approvals)
with a qualified tool chain(s) according ISO 26262.
Test-Model
Maturity levels such as
• Model Base Design per Block Diagram and/or State Machine
• Converted as Standard C Source Code (Ansi C)
• Compiled Binary Object Code
• Linked µC specific Binary Program Code
can be tested with the Test-Model
Influences to the driving behavior because of global or local malfunctions
are sufficiently and accurate simulated with Test-Models. Test-Models help
to design Monitoring, Diagnostics and Failure Handling and are a necessary
part of the MiL-, SiL- and HiL- tests. They are considered as part of the
HW & SW Integration Level of delivered A-, B-, C-and D-Samples.
Disclosure of Test-Models
All relevant partners of Test Engineering or orthers will be given access to
Test-Models as far as necessary for the development and manufacturing tests
and approvals or safety investigations.
• White-Box
The Test-Model exists in the form of Source Code and its Documentation.
The functionality is completely visible to Test-Engineering.
• Black-Box
The Test-Model exists in the form of object or program code.
Input and output signals are documented.
Certain Test-Model parameters can be adjusted
and are visible.
• Gray-Box
The Test-Model structure is changeable
in some way and parameterization
is partially or completely disclosed
(object or program code). Suitable
documentation is available.
Test-Model Equations
All Equations, block diagrams or state machines for the dynamic and static tests
with their physical principles, relevant assumptions and simplifications as well
as illustrated in respective literature are documented.
Solvers
Solvers such as code pieces of equations in the form of SW-libraries, that solve
mathematical problems.
Mechanical Solvers
Dummy Models run at a fixed step size of t = 1 ms using the Euler integration
method (ode1) for model computations
Electrical Onboard Solvers
Onboard models run at a fixed step size of t = 1 ms using the Euler integration
method (ode1) for model computations
Logic Solvers
Logic runs with the original step size as in the hardware platform; however, if step
sizes are smaller than t = 1 ms Euler integration method (ode1) is supported.
Test-Model Parametrization & Configuration
Parametrization of the Test-Model per A2L-File according to ASAM Keywords. All
variables and states are named with labels and down loaded per XCP Protocol.
If required hard-coded signal data, such as the vehicle ground (Clamp 31) can
be be parameterized (adjusted for tests).
Note
Callbacks for Parameterization
Callbacks for Test-Model Parameterization
OEM-specific callback routines to determine receive messages (processes)
or return values (classes) created by the OEM as part of the test cases
ave been not used.
A test process of a Test-Model A calls a test process of another Test-Model B
with a callback. A reference is passed to this call, with which the process
of Test-Model B can respond to the call in its test sequence by transmitting
the required Parameter, which is used in the test process of Test-Model A.
Test-Model Configuration
Configuration per XML-File (FIBEX and/or Autosar XML) for each integration level.
Test-Model Version/Variant
All Test-Models are stored in a Library-Container with a common exchange format.
Test-Models are chronologically sorted by names and there version numbers with
variant suffix and release dates. A configuration management system ensures the
tracking of a Test-Model or Test-Models that are coupled togehter and fit to
E/E Sub-System Version/Variant.
Test-Model Types
Following modeling depths can be made available
Test-Model Type 0 (Dummy Model)
Compatible interfaces are realized in this dummy model so that it can communication
with other models Functionality is not available with the dummy model; however,
necessary signals and states can be taken over by other models from this dummy model
to fulfill there system characteristics.Quantization Process: Binary values from white box
digital signal processing are converted via integer quantization to physical output values of dummy model.
Test-Model Type 1 (Simple Model)
Dynamic and the stationary motion behavior of the system kinematic characteristics
are made via these models in a simplified form with the help of equations with
dynamics valid up to a frequency of 4 Hz.
Test-Model Type 2 (Complex Model)
Dynamics and kinematic characteristics in a more complex form.
• Nominal supply voltage 12 VDC
• Voltage range from 8 to 18 VDC with regard to drain voltage and motor coils
• Voltage derivation 7 V/ms with 0.5 V possible tolerance utilization
• Current derivation 60 A/ms with 10 A possible tolerance utilization
• Thermal Influences -40 to 120°C
• Recuperation behavior into the onboard electrical system
• Rotor dynamics 4 Hz
• ...
Test-Model Type 3 (Sophisticated Complex Model)
Characteristics with high accuracy up to 30 Hz with influences of the onboard
electrical system.
Test-Model Overview
Elements belonging to a Test-Model can be connected as physical parts to a LabCar.
or alternative available as a Simulation-Model such as
• Torsion Bar
• Torque Transducer
• Abs-Angle Transducer
• Battery Supply Power (High Current)
• IGN Key Supply Power (Low Current)
• Printed Circuit Board with Motor Drive
• Elec. Motor
• Rack displacement and velocity.
• NetWork communication per message catalog
• Poster excitations with different force amplitudes as sine shapes up to 30 Hz between 0.1 and 1 KN.
Mechanical Test-Models can be realized per white-box modeling. Associated parameters
are mapped as MATLABÆ Workspace variables.
The modeling of mechanical devices or parts is done in form of a transparent physical
white-box model with mathematical relationships between the input and output variables.
Inertia, rigity, friction, damping, etc. determined from measurements and configurated
as needed for prototyping.
Test-Model to simulate synchronous a.c. motor
The elec. a.c. motor can be simulated as a simplified dynamic model taking into acount
temperature and aging effects with a max. current derivation of 120 A per 10 ms during
some maneuvering.
Test-Model to simulate torsion bar
The torsion bar can be simulated with the help of two parallel springs representing
the stifness and the load during rotation with a fixed torsion bar input side as well
as a freely oscillating rotational inertia acting on the input side.
Note
Friction is an important element in the Steering System and therefore shall be measured
on test benches. Results are implemeted in test models.
Test-Model & Test-Object & Inserting Failures
Check functional interface between Test Object and Test-Model.
Repeatable Test Case has the following information
• Test-Object, Interface, Test-Model
• Necessary Inputs
• Necessary Outputs
• Necessary Environmental Conditions
• Test Steps with Inserted Failure (global or local malfunctions)
• Valid and expected data (Passed)
• Invalid and unexpected data (Failed)
• Test Result (Review, Audit)
All failure insertions can be verified by means of test bench measurements of
nominal Power Output Curves between min/max current consumption @ specified rpm.
Less than 5 % deviation between LabCar and TestCar test results are required.
Example
Message Catalog for Command Signal
• Ramp up to 5 Nm with different gradients @ { 0.5, 1, 2, 5, 10, 20, 50 } Nm/s
• Sinusoidal { 0.1, 0.2, 0.5, 1, 1.5, 2, 2.5, 3, 4, 5 } Nm from 0 to 15 Hz
Message Catalog for Vehicle Speed Signal
• Vehicle Speed: { 15, 40, 80, 120, 160 } km/h
Test-Model Execution
Models as runable Matlab (M-files) and Simulink Models (S-function).
Mil and Sil Block Diagrams and State Machines allowing non realtime
tests with continually calculation. HiL as Experimental Systems or
LabCar as Test Rig System allowing realtime tests with manual test
execution or automatic testruns per script. Message for NetWork bus
simulation are adjustable to handle new lengths and buffer sizes.
Test Execution with
• Power Output Ready State = ON
• Motor Drive = ON
• Adjust Command Values
• Adjust Vehicle Values
• Adjust Friction Values
• Adjust Thermal Values
and check influences such as
• Power Output
• Power Output Reduction (Degration)
• Safety Modul (Monitoring, Diagnostics and Failure Handling)
with failure insertion (e.g. signal failure).
LabCar Equipment
All required application tools used to work with the LabCar(s) are aivailable
in the same way as for the TestCar(s). With this E/E Sub-System working with
application tools does not require internet access. All calibration parameters
typically can be accessed during testruns.
Terminal signals and bus messages, that can be recorded in the TestCar are
documented and also measurable by the LabCar. The LabCar allows specific test
automations with scripts that are not timely possible with TestCar(s).
Application & Test PC using Windows or Linux as operating system.
Following example of test suit
• Windows (32-bit or/and 64-bit), Linux, RT_Linux
• Matlab 2015b 64-bit resolution
• TargetLink (dSpace). Currently DS 1005, DS 1006, DS 1007 and Scalexio
• dSpace Veos, ADTF
• Adams (incl. ADAMS/Controls Toolbox; integration via GSE).
• Component libraries corresponding to the Functional Mock-up Interface (FMI) standard as FMU
• Commercial AUTOSAR SW-Components
• Compilation: Executable files (_.exe) from Matlab/Simulink by providing component libraries (_.obj files)
Data Base incl. Test-Model can be integrated into special CarMaker Test Benche with
• dummy column incl. hand wheel (command input for HiL output rotating the wheels)
• dummy rack force against 3 load introductions from the steerable front axle (loads acting on the wheels)
• Realtime NetWork message simulation according message catalog
Following overview of MiL-Testing and HIL-Testing in a simplified graphical
presentation
Test-Model Depth
Modeling depth corresponds to project-phase and its required integration level.
Test-Model Validation (Qualification of Test-Model)
A Test-Model is typically revised several times (approx. 20 per model) before a usable
simulation Test-Model is achieved.
Note
All related changes typically communicated 6 months ahead.
Driving Maneuvers and Road Approvals (RA, Special Driver Trainee necessary)
Availability of
• Test Plan
• Test Requirements
• Test Description
• Test Definition
• Test Track or Facilities
• Test-Car incl. Equipment (Version/Variant)
• Test Procedures
Availability of EPS (Version/Variant)
• External Sensors, Transducers
• Internal Sensors, Transducers
• Connector and Harness
• Communication Bus Interfaces (CAN, FlexRay, ..)
• Cover & Housing, mech. parts
• ESD & EMI Filter Stage
• PCB with integrated circuits and peripheral components as well as test points
• µCs and ICs
• Gate Driver
• Power Stage as logical Bridge (MOSFETSs)
• Phase Isolation Relays or IC to Decouple/Isolate phase voltages
• Motor Phase Terminals
• Syncronous A.C. Motor with permanent magnet rotor incl. drive shaft
Availability of Engineering Tools Version/Variant
• Complete Design Tool(s)
• Complete Programming Tool(s)
• Compiler & Linker for target µC(s)
• Complete Application Tool(s)
• Complete Diagnose Tool(s)
• Complete Test Suite(s) with Test Tools
Availability of SW Version/Variant
• Boot Loader Software
• Program Code(s) (HEX-File)
• Data File(s) (ASAM MCD-File)
• Config File(s) (XML File)
Availability of Information Version/Variant
• Installation instructions and assembly flow charts
• Operating Manual
• Trouble shooting instructions according DTCs
Availability of Manufacturing/Assembly Tools Version/Variant
• Manufacturing tools, equipment and materials to build and to assembly
Note
Incorrect assembly is not possible
Availability of Safety Modul (Program Flow Control)
• Safety Level 1 [L1] for executing Functions (module processes, class methods)
• Safety Level 2 [L2] for monitoring program flow (receive messages, processes, send messages)
• Safety Level 3 [L3] for independent input, process and output checks
Availability after Test
• Test Report (Reviews/Audits)
EPS Garage Mode
The Garage Mode represents a Diagnostic-Sessions that leads to self steering movements.
Vehicle Self Steering Operation Modes
Following two specified self steering operations for the assemby plant or
for dealer organization are applicable
• Vehicle is Not Moving (Inactive)
• Vehicle is Slowly Rolling (Active)
Expected Quality of Global Signals and States
• Absolute vehicle speed VVehicle as Valide NetWork Message
• Corresponding Qualifier QVehicle
• Self Steering State (Inactive/Active)
Valide NetWork Message
VVehicle is valid if following checks for Bus Communication have passed
• Passed Alive-Check
• Passed Cyclic-Redundancy-Check (CRC)
• No Timeout
Note
NetWork Messages must be equal to Messages listed in the Message Catalog.
Qualifier QVehicle
A valid qualifier indicates that the signal quality is sufficient and that the
functional safety requirements (FSR) for VVehicle have been considered
as well as that the Vehicle is traveling less than 10 km/h (Rolling).
When the vehicle is in operation the following states can be present
• Park-State (Intermission)
• Dwell-State (Interim MSA)
• Rolling-State (Mission A)
• Drive-State (Mission B)
Entry Session for the Garage Mode
When the vehicle is not driving the following state can be set per Diagnostic Sessions
• Self Steering State (Inactive/Active)
To activate the Garage Mode, a diagnostic service request is received via NetWork
and is usually accepted,
if
Control path is in the ready state
&& Paired private key is known with required authentication to allow secure access
&& VVehicle is less than 10 km/h (slowly rolling) || not moving while inactiv
Herafter the self steering motion can be executed. Only 1 diagnostic service request
can activate the entry to the garage mode session. Changing to other sessions is possible
while canceling the ongoing garage mode session.
If 5 s have past since the receipt of the diagnostic request, the self steering motion
can not be executed.
Change Session
If the garage mode session is active and if the change to a driving session is desired
by means of a diagnostic service request, the ongoing garage mode session will
change to a the new session
if
VVehicle is Valide
&& Qualifier QVehicle is valid
&& VVehicle > 10 km/h
&& Self Steering State (Inactive)
&& Drive-State (Mission B)
Cancle or End Session
Cancle or End the garage mode session by means of a diagnostic service request or
if
VVehicle is Invalid
|| Qualifier QVehicle is Invalid
|| VVehicle > 10 km/h
|| Global or Local failure occurs
Safety Requirements for the Garage Mode
The Garage Mode Application with there SW-Components as well as
coresponding programable HW have been rated according ISO 26262
Functional Safety Integration Levels (A)SIL.
Risk Matrix for processes and interrupts were a failure mode
can cause a functional safety problem
(A)SILs have been estimated from the following Risk Matrix:
(A)SILs have been estimated from the following Risk Matrix:
• Estimate Rate for Controlability in case of Failure : C1 or C2 or C3
• Estimate Rate for Exposure in case of Failure : E1 or E2 or E3 or E4
• Estimate Rate for Severity in case of Failure : S0 or S1 or S2 or S3
Safety Concept (ISO 26262 Part 3)
The approved Safety-Concept showes how safety related failures are detected and how there error handling
(control failure modes) safegards the specified safety goals. If an failure occurs a higher priority Task
emits an interrupt service routine (ISR) and the error handling functionality tries to recover from the
failure mode per specified safety concept.
Diagnostic Coverages (DCSPFM, DCLFM) and Failure Propability Rates per Hour (PFH)
Failure probabilities and diagnostics of hardware circuits (BOM) for signal & control flow processes.
Functional Safety Requirements (FSR) for Garage Mode
• Monitoring with DTCs
• Error Handling
• Warning Objects
• PMFH value conforming with rated Risk (Safety Integrity Levels (A)SIL)
protecting against
• dangerous residual failures
• dangerous single point failures
• dangerous latent failures
Meet Safe State for Garage Mode
Once the EPS low-energy state has been reached by ISR, the
self steering task is not able to modify the angular position
of the front wheels.
Safety Job requirements for Diagnostic Service Request
Jobs, that lead to self steering movements, are all handled
by the Garage Mode Session. To activate the Garage Mode, a
diagnostic service request is received via NetWork and is
accepted with positive response message to the Server
.
• Safe State : Negative response message, Cancle or End Garage Mode Session
• Error Tolerance Time: 10 ms
• Risk : Safety Integrity Level = (A)SIL D
Recommended Diagnostic Coverage (DC) Target Values
(A)SIL D
• DC_SPFM: > 99%
• DC_LFM: > 90%
Safety Job requirements for Parameters
Jobs, that change safety-relevant parameters such as for
close to stop or rolling.
• Safe State : Negative response block, which does not allow to change parameters
• Error Tolerance Time : 10 ms
• Risk : Safety integrity level = (A)SIL D
Recommended Diagnostic Coverage (DC) Target Values
(A)SIL D
• DC_SPFM: > 99%
• DC_LFM: > 90%
Safety Job requirements for unguarded Hand Wheel Rotation
Protect against injuries cause by Hand Wheel column rotation during
self-steering motion (see also Safety Goals).
• Safe State : Low energy state prevents injuries
• Error Tolerance Time: 10 ms
• Risk : Safety integrity level (A)SIL A*
Note *
For absolute vehicle speed < 10 km/h and according provisional HRA.
For higher speeds (A)SIL D remains.
Recommended Diagnostic Coverage (DC) Target Values
(A)SIL A
• DC_SPFM: n.a.
• DC_LFM: n.a.
(A)SIL D
• DC_SPFM: > 99%
• DC_LFM: > 90%
To start up the E/E Sub-System, connect the positive pole of a 12VDC power
output voltage direct to Terminal Clamp 30 (battery positive pole direct input)
and to the Terminal 15N switching the positive voltage behind battery (relay out)
as well as the negative pole or common ground of the power supply to the Terminal
Clamp 31 (electronic common ground). Connect Sensor Signals and NetWork Interfaces
Terminal 15N used as Wake Up Signal
Note
Plastics/Elastomers used for conectors and sockets are free from halides because of
their thermal and flame properties. The max halide content in the enclosures material
used for open semiconductor components containing not more than 10 ppm and for the
encapsulated semiconductors not more than 100 ppm.
Color of connectors, sockets and wiring harness are black
Elements containing lead are not used at all.
Amount of Connectors and Sockets
2 connectors and sockets are used
• 1st with High Current battery supply voltage (Terminal 30) and Ground (Terminal 31)
• 2nd with Sensor Signals, NetWorks, Terminal 15N as Wake Up, Reserve
Both Harnesses with there plugs take into acount thermal length compensation
and stress during installation to both EPS connectors.
Installation Position of Connectors and Sockets
All mounting positions of external plugs and sockets are not directed
upwards. This ensures that no water can flow into the interior of the
housing and into the area of the printed circuit board in the event of
a leaky seal.
• Specified guidelines for connector insertion/removal
• Sufficient holding/locking force
Contact Pins of Connectors and Sockets
Silver-coated contact pins are used for all connections.
• Instal/replace pins per press-out & press-in forces
• 0.2 mm displacement of pins rel. to housing with connector insertion/removal
• Sufficient tensile strenght and temperature stability
• Sufficient passivation (coating) for Aluminium contacts
• Size of pols 12.0 mm x 0.8 mm (high current)
• Size of pins 1.2 mm x 0.6 mm (low current)
Quality of Plugs and Sockets
A measure of quality is compliance with all characteristics of elec.
connectivity, such as defined dimensions and specified properties.
• Sufficient wiring gages for high temperatures and high current flows
• Sufficient ESD and EMI protection in combination with filter stage
• Sufficient electrical conductivity
To quantify connectivity, 20 samples are cyclically tested 12 times
with the following load.
• Power Output Ready State = ON • Motor Drive = ON • Number of cycles = 400
• Vibration
• Mechanical shock
• Temperature ϑi = [ 20°C, ..., 115°C ]
• Temperature shock
• Aging such as for 2h under 85 °C. Hereafter cool down to 20°.
• Humidity tests on the Saturation and freezing curve
With an observation period of at least 20 days, the following results
can be detected
• Durable and functional
• Small scratches by insertion and removal only
• Tinned surfaces, but no nickel or copper
• No dimensional deviations outside the tolerance ranges
Visual inspection according DIN EN 60512-1-1
Following use of chemical substances or materials are excluded according legal restrictions
Permissible particle contamination specified to VDA QM Chapter 19 of part 1 and part 2.
HC Emissions for Climate Protection
Achieving the lowest possible level during the project phases and the entire service
life, taking into account metallic and non-metallic recyclates. The proportion of all
recycled plastics/elastomers is approx. 15 % based on the weight of all components made
of plastics/elastomers.
Corrosion Affects
Corosion protections according DIN EN ISO 8044.
All EPS materials used are guaranteed against rust-through for the entire
specified service life. Corrosive coatings applied to critical components.
Special attention is given to contact corrosion of various material pairings,
intergranular corrosion, and stress corrosion cracking. Resistance between
plastics/elastomers and ferrous materials is greater than 108 Ωcm. Standard
tools are used, if assemblies may have to become off for maintenance or for
repair purposes. Bold release torque [-Mrelease] is less than 1.5 X +Mpretightening]
after a corrsion test such as DIN EN ISO 9227
No changes in appearance within 3 years from SOP.
Enclosures against intrusion, dust, accidental contact, and water per IP 57.
Unwanted or unpleasant sounds are known as noise.
The generation of noises as a result of vibrations introduced from the exterior such as
uneven road proviles is taken into account with suitable measures on test rig.
Accepted Noise Level
max. 42dB
Unwanted Noise, Vibration and Harshness (NVH-Release)
When noise is transmitted by air, it is called airborne noise and when
transmitted by sub-assemblies or components such as rattling, etc., its
called structure-borne noise.
For approvals, all noise effects shall be compared with reference samples
that produced acceptable noises levels on a TestBenches, Test Cells or
TestCars over the frequencies of interest.
All reference noise samples produced during the design phases shall be stored
until SOP. The initial sample and three production runs of 5 vehicles each will
be NVH tested to detect continuous steering noise, rattles or other unwanted
sounds.
Frequency-Order-Analysises for coupled vibrations
With Frequency-Order-Analysises noticable noise from vibration signals of assemblies
or components can be analyzed over an relevant frequency spectrum.
Resonance Frequencies
Reduce vibration amplitudes of components and assemblies that produce undesired noise
to the passenger compartment, by damping resonant frequencies and design assemblies or
parts with ωR < 100 Hz or ωR > 250 Hz.
Dynamic Vibrations
Analyse power output of the elec. motor with associated noise characteristics. Take
into acount the power output between low and high idle torque at different speeds
(max. 2300 rpm) e.g. auto park assist function with increased rack velocity (P3-APA).
Acoustic Models
Dynamic noise Models & Static noise Models are provided for components and assemblies.
Following Vibration Types that can cause structure-borne noises
Unwanted noise during Service Life
During the development phases, noise evaluations shall be made prior to sample deliveries.
Following samples shall be made available for 75 % and 100 % of 300000 km noise evaluation.
• (A) Conecpt Samples for e.g. preliminary interference noise checks
• (B) Assembly Group composed Test Samples
• (C) Proposed Series Design Samples
• (D) Series Supply (First Off Sample)
TestBenches, Test Cells or TestCars
Sub-Assemblies and Components have to be tested on TestBenches, Test Cells or
TestCars for NVH evaluations.
Noise Changes during Endurance Runs
Following ratings of design changes shall be specified for noise issues found
during endurance runs for 0, 50, 75 and 100 % of 300000 km.
• HIGH (A design change can strongly influence the noise)
• MEDIUM (A design change can possibly influence the noise)
• LOW (A design change unlikely affects the noise)
• UNDEFINED (No affect of acoustic)
Note
Quality and safety restrictions are excluded due to an design change because of
undesired noise.
Noise Rating
An noise rating from 0 to 10 (best) can be used. During 75 %
of the 300000 km the noise shall be rated with 6. Hereafter
the value can slowly exceed but never abruptly or suddenly.
Achieved a Noise rating of at least 8 with a TestCar
A 1/3 octave (=major third) frequency Range can be specific
as a bandwidth-filter. In terms of frequency, a major third
(4 X half-notes) has a frequency range that fits three times
into an octave (12 X half-notes). Hereby the lower cutoff
frequency f1 and the upper cutoff frequency f2 are in the
same relationship to one another such as the major third.
Sound pressure levels over frequency band
Magnitude level expressed in dB(A)
dB = 20log10 between f = 12.5 Hz ..... 16 KHz
• Not Audible Infra-Sound < 16 Hz
• Audible-Sound from 16 Hz .... 20 kHz
• Not Audible Ultra-Sound from 20 kHz ... 1.6 GHz
• Not Audible Hypersonic-Sound creater than 1 GHz
Normal Noise Level Sound pressure dB for normal noise levels are expressed in dB(A)
High Noise Level Sound pressure dB for high noise levels are expressed in dB(C).
Following for both with the same audible frequency band
Four Sound Level step type curves [dB(A)] are measured for different
hand wheel velocities over mayor third center frequency intervals.
The center frequency fo is the geometric mean of the lower cutoff
frequency f1 and the upper cutoff frequencies f2 of the specified
bandwith (major third filter).
Steps of Noise Level
Within the bandwidth 42dB(A) shall never be exceeded.
Note
Both Steering-End-Stops with there worst case sound pressure noise
shall not be audible inside the passenger compartment and shall not
exceed 45dB(A).
The magnitude values shall not differ by more than 5dB(A) compaired
to the next neighboring 1/3 octave bandwidth.
Sound Level with Ratling, Dither or Impulse
Peak noise disturbance for single components caused by unwanted ratling, dither or impulses shall be less than 5dB(A)
Time Evaluation according to DIN 61672
Settling time to reduce 60dB(A) noise level
T60 <= 0.3 sec.
