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 Kai.hoefig@siemens.com Michael.armbruster@siemens.com Reiner.schmid@siemens.com

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 do not scale up to the configurations that might be infinite. Seite 1 May 2014 Kai Höfig (CT RTC SYE)

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. Seite 2 May 2014 Kai Höfig (CT RTC SYE)

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 endto-end interface complexity. RACE project AutoSAR + Vehicle Controlcomputers Generic safety up to fail-operational + + Adaptivity = future ICT system platform *) to further reduce the dependancy from automotive functions to HW, topology, communication links but also to SW-functionality ensuring non-functional qualities. Seite 3 May 2014 Kai Höfig (CT RTC SYE)

Development roadmap of vehicle E/E-architecture: Today and mid-term Today CGW Central Gateway CGW VCC SW Domain Control Unit Vehicle Control Computer Switch Electronic Control Unit Lin Mid-term CAN FlexRay CGW SW SW SW 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. Seite 4 May 2014 Kai Höfig (CT RTC SYE)

Development roadmap of vehicle E/E-architecture: Long-term with backbone network variants Long-term Safety Motion Chassis Infotainment SW SW Long-term with redundant backbone-network CGW VCC SW Central Gateway Domain Control Unit Vehicle Control Computer Switch Electronic Control Unit Lin CAN FlexRay SW SW 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. Seite 5 May 2014 Kai Höfig (CT RTC SYE)

Two major evolutionary steps facilitating scalability, adaptivity Long-term approach using ethernet within functional domain SW SW Long-term with middleware-based abstraction of physical arch Logical central platform computer Ethernet within functional domain CGW VCC SW Central Gateway Domain Control Unit Vehicle Control Computer Switch Electronic Control Unit Lin CAN FlexRay Ethernet Most VCC VCC VCC SW SW Seite 6 May 2014 Kai Höfig (CT RTC SYE)

ICT architecture based on central platform computer realizing five core properties Logical central platform computer Smart Sensors Driver Assistance Driver Interface Drive train Infrastructure Logical data-interface to vehicle functionality Hardware, Safety, Security Abstraction Passenger Management Smart Actuators P1 Central platform computer with access to all sensors and actuators P2 Fail-operational wrt. power distribution, communication, steering, braking, vehicle control P3 Failure-detection to given safety requirements. P4 Scalability wrt operational availability and performance. P5 HW-efficient implementation of fail-operational behavior using dynamic resource sharing Seite 7 May 2014 Kai Höfig (CT RTC SYE)

Ethernet-Ring based vehicle topology realizing property P1 and P2 EBS(fr) P1 P2 Central platform computer with access to all sensors and actuators Fail-operational wrt. power distribution, EBS : communication, Electronic brake controller steering, braking, vehicle control SbW : Steer-by-Wire controller Ethernet ring: redundant logical links Ethernet branch: single logical link camera camera SbW(red) ultrasonic SbW(red) PB(red) ultrasonic EBS(fl) SbW(blue) SbW(blue) PB(blue) Conceptual view as basis for project-specific adaption Seite 8 May 2014 Kai Höfig (CT RTC SYE)

Duplex Control-Computer realizing property P3 and P4 P3 Failure-detection to given safety requirements. P4 EBS(fr) Scalability wrt operational availability and performance. Master sender Slave receiver CPU lane a camera voting CPU lane b voting SbW(red) CPU lane a voting CPU lane b lane votingb PB(red) camera Eth-Sw ultrasonic Eth-Sw Eth-Sw Eth-Sw ultrasonic SbW(blue) SbW(blue) PB(blue) EBS(fl) Seite 9 May 2014 Kai Höfig (CT RTC SYE)

Duplex Control-Computer realizing property P3 and P4 P3 Failure-detection to given safety requirements. P4 EBS(fr) Scalability wrt operational availability and performance. sender receiver Master CPU lane a camera CPU lane b Passive voting voting SbW(red) CPU lane a voting CPU lane b lane votingb PB(red) camera Eth-Sw ultrasonic Eth-Sw Eth-Sw Eth-Sw ultrasonic SbW(blue) SbW(blue) PB(blue) EBS(fl) Seite 10 May 2014 Kai Höfig (CT RTC SYE)

ICT core requirements Req.: Platform shall ensure a fail-operational behaviour [Hazard analysis and risk assessment: missing safe state] 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] What does this mean for the sketched platform-data consistency and the data-exchange between s? SEooC consideration Seite 11 May 2014 Kai Höfig (CT RTC SYE)

Extended and strengthened safety-requirements SEooC consideration 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 Seite 12 May 2014 Kai Höfig (CT RTC SYE)

Managing multiplicity-complexity [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 for vehcile functions based on simplified fault-hypthesis and virtual network nodes Seite 13 May 2014 Kai Höfig (CT RTC SYE)

The Race Fault-Hypothesis 1. Thus, each fault will lead to an effect acc. to the folllowing effect-classes: Correct timing Correct CRC Correct update Correct Value FEC(1) FEC(2) FEC(3) FEC(4) FEC(5) All characteris tics correct Incorrect value Incorrect update Incorrect crc Incorrect timing T T T T F T T T F - T T F - - T F - - - See also [1] T: True F: False 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 Seite 14 May 2014 Kai Höfig (CT RTC SYE)

Fault-containment-region based analysis Fault-containment-regions: Duplex Control Computer (): Elementary Fault-containment region per lane PSU CPU/ Core Switch: common part Switch: CPU-port Switch: X-Lane port Switch X-Port (communication within inner and outer ring) Seite 15 May 2014 Kai Höfig (CT RTC SYE)

Fault-containment-region based analysis Considered efcrs: CPU, PSU, Eth-Port(CPU), Eth-Port(X-Lane). Eth-Port(X) without FEC(2) undetected l 5-6 korrekt faulty faulty in efcr. Considered efcrs: Eth-Port(X) àfec(2) undetected Considered efcrs: Eth(Common) àfec(5) FEC(2) correct frame, incorrect value FEC(5) communication disturbance à no frame Seite 16 May 2014 Kai Höfig (CT RTC SYE)

Fault-model splitting Z k () To reduce analysis complexity, one complex fault model can be split up to several smaller ones. Z f () Simplified fault-models for Z fp () Z fooc () Loss of platform consistency Z fooc () Loss of communicationlink Z fdormant () link-integrity platform-consistency Z k () Z k () Z k () Z f () Z f () Z f () Z fp () Z fooc () Loss of communicationlink Z fooc () Loss of platform consistency Seite 17 May 2014 Kai Höfig (CT RTC SYE)

summary Simplified fault-hypothesis Z k () l 5-6 Z fp () P{Passivation of \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 faulthypothesis: P{Loss of link-integrity \h} < 1E -5 Benefits: Z k () Zk() l 5-10 l 1-5 Zfooc() Zfp() Simplified function-specific safety assessment. Independence from Plug n Play. Seite 18 May 2014 Kai Höfig (CT RTC SYE)

How to go on? 1 Is the fault-hypothesis and the failure-effect-assumption valid? 2 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 3 Does the vehicle state-management implement the states of the markov-model? 4 Will it be possible to add SW onto the RACE platform without loosing certification? Seite 19 May 2014 Kai Höfig (CT RTC SYE)

Thank you for your interest!