A vehicle control platform as safety element out of context

A vehicle control platform

as safety element out of

context

Kai Höfig Michael Armbruster Reiner Schmid

Siemens AG Siemens AG Siemens AG

Corporate Technology Corporate Technology Corporate Technology

Research & Technology Center New Technology Fields Research & Technology Center

CT RTC SYE DAM-DE CT NTF CAR CT RTC SAD AQC-DE

Problem Statement

Cyber-physical systems provide potential for impact in domains such as mobility, home automation and healthcare,

but

Ensuring their dependability is currently infeasible since they

• are loosely coupled and

• come together temporarily.

State-of-the art dependability analysis techniques

• are applied during the design phase,

• require a priori knowledge of the configurations that are present at runtime and

Major Challenges for Dependability Assurance

of (Automotive) CPS

1. Exchange dependability-related information across domains and complex value chains.

• Common language: there is much progress in model-based design and analysis, but no common language to express dependability related information exist.

• Interoperability: heterogeneous dependability information has to be synthesized but unified development methodologies cannot be expected in industry.

• IP protection: interoperability mechanisms should also protect the intellectual property of the provider of information.

2. (Semi-)Automated dependability assurance.

• Complexity: automations provide consistency and completeness.

• Fast change impact analysis: changes should be possible without larger effort.

3. Enable and automate dependability assurance for CPS integration in the field.

• Dependability cannot be assured prior to deployment.

• Systems dynamically interconnect and build systems of systems with unforeseeable consequences.

• Systems are developed independently from each other and no single company is responsible for the final integration.

The vision of the future ICT system platform

§ The future ICT system platform facilitates fully automated driving and dynamic extensibility/ adaptivity in field.

§ The concept is based on an enlarged modularisation *) concept that leads to less end-to-end interface complexity.

AutoSAR Generic safety up to fail-operational Adaptivity

+

+

=

future ICT system platform

Vehicle Control-computers

+

*) to further reduce the dependancy from automotive functions to HW, topology, communication links but also to SW-functionality ensuring non-functional qualities.

Development roadmap of vehicle E/E-architecture:

Today and mid-term

Today ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU CGW ECU Mid-term CGW Central Gateway

DCU Domain_{Control Unit}

VCC Vehicle Control_Computer

SW Switch

ECU Electronic_{Control Unit}

Lin CAN FlexRay Ethernet Most ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU SW SW CGW SW

According to reference: Burkhard Triess (ETAS GmbH); Thomas Hogenmüller (Robert Bosch GmbH): Ethernet Gateway for Automotive. 2nd Ethernet and IP@Automotive Technology Day, 2012.

Long-term

Long-term with redundant backbone-network

Development roadmap of vehicle E/E-architecture:

Long-term with backbone network variants

ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU SW SW DCU DCU DCU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU SW SW DCU DCU DCU CGW Central Gateway

DCU Domain_{Control Unit}

VCC Vehicle Control_Computer

SW Switch

ECU Electronic_{Control Unit}

Lin CAN FlexRay Ethernet Most

According to reference: Burkhard Triess (ETAS GmbH); Thomas Hogenmüller (Robert Bosch GmbH): Ethernet Gateway for Automotive. 2nd Ethernet and IP@Automotive Technology Day, 2012.

Safety Motion Chassis Infotainment ……

ECU ECU ECU SW SW ECU ECU ECU ECU ECU ECU ECU ECU ECU VCC ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU SW DCU DCU DCU ECU ECU ECU ECU ECU ECU SW ECU ECU ECU

Long-term approach using ethernet within functional domain

Long-term with middleware-based abstraction of physical arch

CGW Central Gateway

DCU Domain_{Control Unit}

VCC Vehicle Control_Computer

SW Switch

ECU Electronic_{Control Unit}

Lin CAN FlexRay Ethernet Most

Logical central platform computer

Ethernet within functional domain ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU ECU VCC VCC

Two major evolutionary steps

facilitating scalability, adaptivity

Hardware, Safety, Security Abstraction

Logical data-interface to vehicle functionality Driver

Assistance

Driver

Interface Drive train

Infra-structure

Passenger Management

ICT architecture based on central platform computer

realizing five core properties

Smart

Sensors

Smart

Actuators

Central platform computer with access to all sensors and actuators

P1

Fail-operational wrt. power distribution, communication, steering, braking, vehicle control

P2

Failure-detection to given safety requirements.

P3

Scalability wrt operational availability and performance.

P4

HW-efficient implementation of fail-operational behavior using “dynamic resource sharing”

P5

Logical central platform

Ethernet-Ring based vehicle topology

realizing property P1 and P2

DCC ECU DCC DCC SbW(red) SbW(blue) PB(red) PB(blue) EBS(fr) EBS(fl) camera ultrasonic camera ultrasonic ECU DCC SbW(blue)

• EBS : Electronic brake controller • SbW : Steer-by-Wire controller Conceptual view as basis for project-specific adaption Ethernet ring: redundant logical links Ethernet branch: single logical link

Central platform computer with access to all sensors and actuators Fail-operational wrt. power distribution, communication, steering, braking, vehicle control

P1

P2

Duplex Control-Computer

realizing property P3 and P4

DCC ECU DCC DCC SbW(red) SbW(blue) PB(red) PB(blue) EBS(fr) EBS(fl) camera ultrasonic camera ultrasonic ECU DCC SbW(blue)

Failure-detection to given safety requirements.

P3 sender DCC CPU lane a CPU lane b voting voting Eth-Sw Eth-Sw receiver DCC lane b voting voting CPU lane a CPU lane b Eth-Sw Eth-Sw

Scalability wrt operational availability and performance.

P4

Duplex Control-Computer

realizing property P3 and P4

DCC ECU DCC DCC SbW(red) SbW(blue) PB(red) PB(blue) EBS(fr) EBS(fl) camera ultrasonic camera ultrasonic ECU DCC SbW(blue)

Failure-detection to given safety requirements.

P3 sender DCC CPU lane a CPU lane b voting voting Eth-Sw Eth-Sw receiver DCC lane b voting voting CPU lane a CPU lane b Eth-Sw Eth-Sw

Scalability wrt operational availability and performance.

P4

Passive

Req.: Platform shall ensure a fail-operational behaviour

ICT core requirements

ASIL Single-point fault metric (SPFM)

Latent fault metric (LFM)

Random HW

failure rate targets

B ≥ 90 % ≥ 60 % < 10-7 _h-1

C ≥ 97 % ≥ 80 % < 10-7 _h-1

D ≥ 99 % ≥ 90 % < 10-8 _h-1

[ISO 26262-5, Tables 4, 5, 6]

[Hazard analysis and risk assessment: missing safe state]

SEooC

consideration

What does this mean for the sketched platform-data consistency

and the data-exchange between DCCs?

Extended and strengthened safety-requirements

Top-Level safety-requirement (assumed for SEooC):

•P{loss of platform consistency\h} < 1E-10

•∆T_{fault.-tolerance-passive}<= 50ms

•∆T_{fault.-tolerance-out-of-control} <= 10ms • opt.: no single-point failure

Derived design-requirements:

-Multi-path data-exchange

-X-Lane Data-exchange with self-monitoring

SEooC

Managing multiplicity-complexity – DCC[1..N]

Challenge:

■ Complexity due to multiplicity

■ Impact of faults onto data-consistency and communication QoS Goal

■ Simplification of fault-state model

■ Independence from PnP Approach:

■ Faults leading to

■ Loss of platform consistency

■ Link integrity

are summarized within generic „virtual network nodes“

■ Two-step safey-assessment

■ Step 1: function generic part for virtual network nodes

■ Step 2: functions specific part

The Race Fault-Hypothesis

1. Thus, each fault will lead to an effect acc. to the folllowing effect-classes:

2. Finally we assume, that each fault can be detected based on the above mentioned failure effect class model.

[1] M. Armbruster: Eine fahrzeugübergreifende X-by-Wire Plattform zur Ausführung umfassender Fahr- und Assistenzfunktionen

FEC(1) FEC(2) FEC(3) FEC(4) FEC(5) All characteris tics correct Incorrect value Incorrect update Incorrect crc Incorrect timing Correct timing T T T T F Correct CRC T T T F -Correct update T T F - -Correct Value T F - - -T: True F: False See also [1]

Fault-containment-region based analysis

Fault-containment-regions:

– Duplex Control Computer (DCC):

Elementary Fault-containment region per lane

– PSU

– CPU/ Core

– Switch: common part – Switch: CPU-port – Switch: X-Lane port

– Switch XDCC-Port (communication within inner and outer ring)

Fault-containment-region based analysis

Considered eFCRs:

CPU, PSU, Eth-Port(CPU), Eth-Port(X-Lane).

Eth-Port(XDCC) without FEC(2) undetected Considered eFCRs: Eth(Common) àFEC(5) Considered eFCRs: Eth-Port(XDCC) àFEC(2) undetected FEC(2) – correct frame, incorrect value

FEC(5) – communication disturbance à no frame

korrekt faulty 6

5

-£

l

Fault-model splitting

Zk(DCC)

Zfp(DCC)

Zf(DCC)

Zfooc(DCC) Loss of platform consistency

Zfooc(DCC)

Loss of communication link Zf dorm ant(DCC)

Z_k(DCC) Z_fp(DCC) Zf(DCC) Z_k(DCC) Z_f(DCC) Z_fooc(DCC)

Loss of communication link

Z_k(DCC) Z_f(DCC)

Z_fooc(DCC)

Loss of platform consistency

Simplified fault-models for

DCC link-integrity platform-consistency

To reduce analysis complexity, one “complex”

fault model can be split up to several smaller

ones.

summary

Simplified DCC fault-hypothesis

■ P{Passivation of DCC \h} < 5E-6

Platform-consistency can be modeled with the following fault-hypothesis:

■ P{Loss of platform consistency \h} < 5E-10

Communication-link influence on system-operation can be modeled with the following fault-hypothesis:

■ P{Loss of link-integrity \h} < 1E-5

Benefits:

•

Simplified function-specific safety assessment.

•

Independence from Plug’n’Play.

Z_k(DCC) Zfooc(DCC) 10

5

-£

l

1

-£

l

5

-£

l

How to go on?

Is the fault-hypothesis and the failure-effect-assumption valid?

1

Does the SW-architecture follow the safety-design with regard to - fault-detection and defined fault-hypothesis,

- fault-management.

- data-invalidation through all SW-layers including timing

2

Does the vehicle state-management implement the states of the markov-model?

3

Will it be possible to add SW onto the RACE platform without loosing certification?