A Safe Basis. Safety Functions Status and Challenge V

Transcription

1 A Safe Basis Safety Functions Status and Challenge V

2 Agenda 1. Introduction 2. MICROSAR Safe 3. Status and Outlook 4. Challenges 2

3 Introduction Evolution of Safety Concepts Partitioning fail-safe Enhancing driver actions High Performance Integrity Redundancy (redundant functions) increase availability fail-operational 3 Taking over driver decision

4 Agenda 1. Introduction 2. MICROSAR Safe 3. Status and Outlook 4. Challenges 4

5 MICROSAR Safe Today: Partitioning SafeOS Wild pointers Stack overflow Endless loops Longer execution times due to unexpected input SafeE2E SafeRTE Loss of Communication Message masquerading Message corruption SWC ASIL SafeOS SafeWDG E2E SafeWDG SWC SafeRTE Hardware QM SWC BSW MCAL SWC The program flow of a code differs from the expected behavior Deadlines are not met for safety mechanisms Parts of Basic Software are available up to ASIL D Software faults are prevented by memory protection and logic monitoring Hardware faults are detected by hardware Overhead due to partition switching 5

6 MICROSAR Safe Choosing the Right Approach BSW in QM Partition BSW in ASIL Partition ASIL Partition QM Partition ASIL Partition QM Partition SWC1 SWC2 SWC3 SWC4 SWC1 SWC2 SWC3 SWC4 SafeRTE RTE SafeRTE RTE OS BSW SafeBSW OS BSW Calls to QM partition Calls to ASIL partition Calls to BSW are necessary for e.g. external communication, notifications, runtime overhead ASIL BSW (Safe) QM BSW (Partitioning Solution) # ratio ASIL [ # ] If the majority of application software has the same ASIL, performance can be boosted by having an ASIL BSW that allows to coexist in the same partition. 6

7 MICROSAR Safe Improving Performance Speedup of ASIL SWC Comm. Speed-up of QM SWC Comm. No partition switch necessary if ASIL SWCs communicate with BSW Reduced overhead for scheduling of ASIL tasks Direct access to protected registers possible from ASIL drivers QM SWC can use trusted-function calls to call BSW functions There is a mode-switch, but no context switch The code is executed on the stack of the caller Resulting time to cross partition boundary is reduced It is faster to access from QM application into ASIL than from ASIL application into QM ASIL Partition QM Partition ASIL Partition QM Partition SWC1 SWC2 SWC3 SWC4 SWC1 SWC2 SWC3 SWC4 SafeRTE RTE SafeRTE RTE SafeBSW OS SafeBSW OS 7

8 MICROSAR Safe In many cases we see mixed-asil Systems QM ASIL QM ASIL QM ASIL ECU Software ECU 1 ECU 2 ECU 3 ECU 4 Adequate Safety Concepts: Partitioning High Performance Integrity 8

9 MICROSAR Safe High Performance Integrity BSW and ASIL application are executed in the same partition The BSW has to be developed acc. ISO26262 ASIL D Following the Methods based on ISO26262 Part 6 Semiformal Design Code Coverage Programming rules Analyzing tools Considering safety requirements Safety analysis 9

10 MICROSAR Safe High Performance Integrity Silent Analysis is a static code analysis to identify potential memory corruptions by e.g. array out-of-bounds access, dangling pointers, etc. Gen. configuration data (Cfg1) Gen. configuration data (CfgN) Static code Additional to the process measures for static code we perform Tool-based review regarding memory corruption on Vector side Dedicated tests regarding memory corruption on Vector side Tool based check of generated data reading memory corruption on customer side Silent methodology was developed by Vector and certified by TÜV Nord for ASIL D. Silent Analysis using internal tool (Review Helper) to identify potentially dangerous code Runtime check Vector Customer Generated configuration data for the project Test case MICROSAR Safe Silence Verifier (MSSV) Safety manual Review (inspection) by peer Safety manual MSSV plugin MSSV plugin plugin plugin Report with result: passed or failed 10

11 MICROSAR Safe Challenges Introduce the culture of Safety Modules with Safety requirements Modules without Safety requirements Define a process following the ISO26262 Introduce new features in our Lifecycle Management System How to combine the AUTOSAR Standard with the ISO26262 What is the role of configurators and generators Definition of Tool Confidence Level (TCL) 11

12 Agenda 1. Introduction 2. MICROSAR Safe 3. Status and Outlook 4. Challenges 12

13 Status and Outlook Safety Requirements for BSW 1. Safe partitioning 2. Safety requirements 3. Potentially more safety requirements SCHM Scheduling OS SYS DIAG MEM Memory Partitioning COM Deadline Alive Monitoring CAN Monitoring Application RTE Timing Partitioning Logic Monitoring LIN FR ETH V2G 1 IO Killing LIBS Inter ECU Communication Intra ECU Communication AMD Mode Management Initialization Self-Test Complex Driver AVB 1 Reset Non-volatile Read Non-volatile Write Input / Output MCAL Cryptographic Integrity Verfication Application Shutdown Fault Management EXT Microcontroller 13

14 Status and Outlook Layered Architecture SafeBSW 1. Safe partitioning 2. Safety requirements E2E Protection Wrapper SCHM Application RTE 3. Potentially more safety requirements SafeBSW (status quo, more modules will follow) OS SYS DIAG MEM OS BSWM COMM CSM CRY (SW) DET ECUM STBM TM WGDIF WGDM DCM DEM FIM J1939DCM DRM AMD DBG DLT RTM 1 XCP EA FEE MEMIF NVM COM IO COM LDCOM IPDUM NM PDUR DIOHWAB 1 COMXF SOMEIPXF E2EXF SECOC SENT 1 CAN J1939TP LIN LINXCP 1 FR FRXCP ETH ETHXCP V2G 1 DNS J1939NM LINTP FRTP UDPNM EXI J1939RM LINNM FRARTP SD HTTP CANXCP LINSM FRNM DOIP SCC CANTP LINIF FRSM SOAD XML Security CANNM FRTSYN ETM 1 CANSM FRIF TLS AVB 1 CANTSYN TCPIP CANIF ETHSM AVTP ETHTSYN PTP 3 ETHIF SRP LIBS CAL (CPL) CRC E2E Complex Driver MCAL EXT ADCDRV CANDRV CORTST EEPDRV ETHDRV ETHSWTDRV FLSTST FRDRV GPTDRV IICDRV 1 PORTDRV LINDRV PMWDRV Input / Output MCUDRV RAMTST SPIDRV WDGDRV CANTRCV DRVEXT 2 ETHTRCV LINTRCV SBC 1 PSI5 DRV DIODRV FLSDRV ICUDRV OCUDRV CRY (HW) 1 FRTRCV Microcontroller 14

15 Status and Outlook Summary AUTOSAR BSW as ASIL or QM depends on Your safety concept ASIL share on application level Available hardware mechanisms A guideline on the different safety concepts you will find at the ZVEI homepage 15

16 Agenda 1. Introduction 2. MICROSAR Safe 3. Status and Outlook 4. Challenges 16

17 Challenges Fail-Operational Actuator Actuator Increase availability Error detection Error avoidance Hardware fault Radar Required Safety Requirements: Radar Safe scheduling Switch off applications (killing) Availability of communication Kamera!! The number of safety requirements will increase Kamera The Basic Software will be a part of the safety concepts 17

18 Challenges Safety as the Basic for the Future ADAS, will increase the complexity of safety Redundancy is required to increase the availability (fail-operational) Increasing data volumes and complex algorithms requires Bigger and complex hardware POSIX Operating Systems The system will be more than the car (Car2X, 5G, Backend,) Upcoming standards have to consider security in combination with safety Today SafeBSW reduces the complexity and runtime... safety concepts Tomorrow it is the basis for new 18

19 For more information about Vector and our products please visit Author: Rein, Jochen Vector Germany Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V

20 Challenges Fail Operational Actuator Actuator Increase availability Error detection Error avoidance Example: Hardware fault communication does not work! Radar Required Safety Requirements: Radar Safe scheduling Switch off applications (killing) Availability of communication Kamera!! Redundancy Communication has to work! The number of safety requirements will increase Kamera The Basic Software will be a part of the safety concepts 20