Effective application of software safety techniques for automotive embedded control systems

SW Safety Analysis
Czerny, “Effective Application of Software Safety Techniques for
Automotive Embedded Control Systems”, SAE 2005

ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 2 / 17
목표
1. ISO26262의 SW Safety Analysis를 수행하기 위해 Delphi의 Safety analysis
approach에 대해 이해한다.

Contents
1. Introduction
2. Software Safety Cycle Overview
3. Concept Design Phase
a. Preliminary Hazard Analysis
b. Software Safety Program Plan
4. Software Requirement Analysis Phase
a. Software Hazard Analysis
b. Hazard Testing
c. Software Safety Requirement Review
5. Software Architecture Design Phase
a. Fault Tree Analysis
b. System Level Software FMEA
6. Software Detailed Design and Coding Phase
a. Detailed Software Fault Tree Analysis
b. Detailed Software FMEA Technique
c. Defensive Programming
7. Software Verification and Validation Phase
8. Summery and Discussion

1. Introduction
Software failure는 ?
any deviation from the intended behavior of the software of a system
시스템의 소프트웨어의 의도된 행동으로부터 벗어난 행동
Software failure mode의 잠재적인 원인의 3가지 핵심 카테고리
1) Hardware failures
a. Memory failures in either the code space or variable space
b. CPU failure(ALU, registers)
c. Peripheral failures(I/O ports, A/D, CAN, SPI, watchdog, interrupt manager, timers)
2) Software Logic errors
a. infinite loops
b. incorrect calculations
c. abrupt return
d. taking a longer time to complete routine execution
3) support software(e.g. compiler) errors
a. failed to configure tools correctly

2. Software Safety Lifecycle Overview
v

vSoftware development phase Typical Software Safety Tasks
Conceptual Design(System level) Preliminary Hazard Analysis
SW Safety Planning
SW Requirement Analysis SW Safety Requirements Analysis
SW Architectural Design SW Safety Architecture Design Analysis
SW Detailed Design and Coding SW Safety Detailed Analysis
SW Safety Code Analysis
SW Verification and Validation SW Safety Testing
SW Safety Test Analysis
SW Safety Case

3. Concept Design Phase(System Level)
Project Leader는 system safety program이 product concept을 위해 필요한지를 결정한다.
어떻게 판단을 해야 하지?
1. 과거의 제품 개발 경험을 바탕으로
2. Preliminary hazard analysis(PHA)의 결과를 기반으로

Preliminary Hazard Analysis(PHA)
1. PHA의 목표
a. high-level system hazard를 식별하기 위해서
b. 발생할 수도 있는 잠재적 mishap의 criticality를 판단하기 위해서
2. PHA를 수행하기 위한 basic step
a. system과 연관되어 있는 잠재적인 hazard를 식별하기 위해 브레인스토밍을 하거
나 기존의 잠재적 hazard list를 review한다.
b. 잠재적 hazard를 기술하고 그것과 연관되어 있는 잠재적 mishap 시나리오를 작성
한다.
c. 잠재적 hazard의 잠재적 cause를 파악한다.
d. 잠재적 hazard와 mishap scenario의 risk를 판단한다.
e. 잠재적 risk를 제거하거나 완화시키기 위해서 시스템 사양을 추가하기 위해 시스템
hazard-avoidance 요구사항이 필요한지의 여부를 판단한다.
time이 잠재적 hazard의 요소가 되거나 잠재적 mishap발생의 요소가 된다면,
설계상에 놓여있는 잠재적 hazard로서의 시간 제약이 조사되어야 할 필요가 있다.

Preliminary Hazard Analysis(PHA)
Control System의 example
Control System PHA의 example
High integrity ECU operation을 위해서,
design team은 software failure로 인한
의도되지 않은 시스템의 행동을 고려해야
한다.
Software의 fault는 hardware의 fault로도
발생할 수 있음
High integrity ECU operation을 위해서,
design team은 software failure로 인한
의도되지 않은 시스템의 행동을 고려해야
한다.
Software의 fault는 hardware의 fault로도
발생할 수 있음

Software Safety Program
1. 목표
a. 잠재적 software failure와 연관되어있는 potential hazard를 제거, 경감, 제어하기
위한 software safety requirement를 식별하기 위해서
2. Software Safety Goal을 만족시키기 위해 사용하는 methods
a. Software Hazard Analysis
b. Hazard Testing
c. Software Safety Requirement Review

Software Hazard Analysis
1. SHA에서의 주요 활동
a. 잠재적 system hazard로 이끌 수 있는 잠재적 software failure를 식별하기
system의 잠재적 hazard와 잠재적 software cause사이의 확립된 link를 기반으로 식별
된 system hazard-avoidance requirement가 software hazard-avoidance
requirement로 translate된다.
è 이 일을 달성하기 위해 주로 사용되는 방법은 fault tree analysis(FTA)이다.
FTA
• top-down(deductive) analysis method
• top level에서 undesired event에 대한 잠재적 cause를 식별한다.
현 단계에서 Software architecture나 detailed design에 대한 산출물이 없지만 FTA에
서 식별된 software state를 예상한다.
è 이 예상을 바탕으로 실제 architecture 설계나 detail design에서 FTA에서의 결과를
반영한다.

System 수준에서의 Fault Tree
현 단계에서 Software architecture나 detailed
design에 대한 산출물이 없지만 FTA에서 식별된
software state를 예상한다.
è 이 예상을 바탕으로 실제 architecture 설계나
detail design에서 FTA에서의 결과를 반영한다.
현 단계에서 Software architecture나 detailed
design에 대한 산출물이 없지만 FTA에서 식별된
software state를 예상한다.
è 이 예상을 바탕으로 실제 architecture 설계나
detail design에서 FTA에서의 결과를 반영한다.

System 수준에서의 Fault Tree

Hazard Testing
1. 목표
잠재적 hazard 환경에서의 시스템의 실제 행동에 대한 시험하는 요구사항을 개발한다.
이런 시험의 결과
a. fault response times
b. signal deviation level
잠재적 hazard가 발생하기 전에 회피
하기 위한 시스템 요구사항
잠재적 hazard가 발생하기 전에 회피
하기 위한 시스템 요구사항
Fault response timeFault response time
Software diagnostics의 설계를 할 수 있도록 한다.Software diagnostics의 설계를 할 수 있도록 한다.
Software task schedule의 설계에 매우 critical하다Software task schedule의 설계에 매우 critical하다
주어진 시간 이내에 선택한 controller가 충분한 성능이 있는지
를 판단하는 insight를 제공한다.
주어진 시간 이내에 선택한 controller가 충분한 성능이 있는지
를 판단하는 insight를 제공한다.
초기에는 simulation model이나 bench setup으로 수행될 수 있음초기에는 simulation model이나 bench setup으로 수행될 수 있음
식별된 fault response times는 가능하면 자동차의 실제 시스템에서 시
험함으로써 confirm이 되어야 한다.

Hazard Testing
1. 목표
초기에는 simulation model이나 bench setup으로 수행될 수 있음초기에는 simulation model이나 bench setup으로 수행될 수 있음
simulation을 사용한 hazard testing과 vehicle testing은 가상적인 요구
사항을 이끌어 낼 수 있음
“failure로 인한 vehicle에 유발된 undesired behavior는
x시간 이내에 y값을 넘기지 말아야 한다”

Hazard Testing
1. 목표
소프트웨어가 아직 존재하지 않지만 vehicle level에서 vehicle 및
simulation기반으로 Software Safety Requirement을 정량화하기 위해
정량적인 vehicle level requirement를 사용하는 것이 가능하다.
소프트웨어가 아직 존재하지 않지만 vehicle level에서 vehicle 및
simulation기반으로 Software Safety Requirement을 정량화하기 위해
정량적인 vehicle level requirement를 사용하는 것이 가능하다.
the ECU output command delivered to the actuator shall not
deviate from the desired value by X amount for more than Y ms.
the ECU output command delivered to the actuator shall not
deviate from the desired value by X amount for more than Y ms.

Software Safety Requirement Review
1. 목표
a. Software hazard analysis에 의해 식별된 software safety requirement(SSR)에 대해
complete하고 consistent한지를 검사한다.
b. Software functional requirement을 safety에 대한 영향(impact)관점에서 평가한다.
2. 수행 결과(Work product)
a. software design을 위한 software safety requirement(SSR)
SSR에는 coding guideline과 관련된 요구사항을 포함할 수 있음

Revised Software Safety Requirements
Software Safety Requirements

Req. No. Requirement Comment
SW-SAFETY-1 Software sensor diagnostics shall
detect deviations of actual vs.
measured sensor signals of TBD
amount within TBD ms.
Revised
SW-SAFETY-2 Software command diagnostics
shall detect deviations of computed
Actuator command of X amount
within Y ms.
Based on ECU integrity requirement
obtained from hazard testing
SW-SAFETY-3 Software communication/driver
diagnostics shall detect actuator
communication errors within Y ms
Determined by hazard testing
(Fault detect)
SW-SAFETY-4 Software failure management
routine shall initiate controlled
shutdown of the system
immediately after a diagnostic
detects a failure.
Fault handling
SW-SAFETY-5 All software shall conform to the
MISRA C coding guidelines

1. 목표
a. safety-critical software component와 function을 식별하는 것
b. 잠재적 hazard가 회피되거나 경감됨을 보이기 위해 식별된 component나 function
에 대해 적적한 high-level analysis method를 적용하는 것
2. 활동
a. software development team은 식별된 software requirement를 만족시키기 위해
서 생성할 필요가 있는 software component와 function들에 대해 명세 한다.
b. 기존의 software hazard analysis로부터 integrity와 criticality level이 각각의
component와 function에 대해 평가된다.
c. criticality level은 software component나 function의 malfunction으로부터 발생할
수 있는 잠재적 hazard에 의존적이다.
d. criticality가 높을수록 더 높은 analysis level이 요구된다.
e. 목표를 만족시키기 위해서
• 기존의 FTA를 확장하여 잠재적 hazard로 이끌 수 있는 소프트웨어의 state를
만드는 특정 software component나 function들을 식별한다.
• 잠재적인 failure에 대해 광범위하게 cover하기 위해 시스템 수준의 FMEA를
수행한다.
f. software component 및 function의 criticality는 개발된 fault tree에서 잠재적
software cause와 연결되어 있는 가장 높은 risk가 있는 잠재적 hazard를 기반으로
한다.

소프트웨어 아키텍처의 example
Architecture는 SSR을 기반으로 설계되어야 한다.Architecture는 SSR을 기반으로 설계되어야 한다.

Fault Tree Analysis
1. 활동
a. 기존의 fault tree가 revise되어 특정 software module이 fault tree에 포함된다.
• fault tree에 있는 기존의 software portion을 교체한다.
ü 필요한 소프트웨어 기능에 대한 지식을 기반으로 함
ü 소프트웨어의 구조를 기반으로 하지 않음
• 새롭게 생성된 software sub-tree와 교체되어 제거될 sub-tree를 비교하여 손실되는 부
분이 없도록 한다.

Fault Tree Analysis

Fault Tree Analysis actuator에 bad command가 들어가는 두
개의 immediate causes가 식별됨
1. Command delivered to actuator deviates
by X amount for Y ms and is not
detected
2. DetermineSystemMode() fails to initiate
shutdown when fault detected.
actuator에 bad command가 들어가는 두
개의 immediate causes가 식별됨
1. Command delivered to actuator deviates
by X amount for Y ms and is not
detected
2. DetermineSystemMode() fails to initiate
shutdown when fault detected.
12

Fault Tree Analysis
1. actuator에게 command를 produce, deliver할 필요
가 있는 software module 각각의 잠재적 failure
1. actuator에게 command를 produce, deliver할 필요
가 있는 software module 각각의 잠재적 failure
12
2. desired command로부터 deviation을 탐지할 의도
가 있는 관련된 diagnostics에서의 잠재적 failure
2. desired command로부터 deviation을 탐지할 의도
가 있는 관련된 diagnostics에서의 잠재적 failure
원인

Fault Tree Analysis
누가 더 criticality를 높아야 할까?
vs
DetermineSystemMode()는
the only single point failure이다.
그래서….
DetermineSystemMode()가
fail하는 것이 더 critical하다

System Level Software FMEA
1. 역할
• 소프트웨어 design의 구조적 weakness를 식별하는데 도움을 준다.
• weak 혹은 missing requirement를 찾는데 도움을 준다.
• latent software non-conformance를 찾는데 도움을 준다.
2. 목표
시스템의 구조와 기본 방어 설계를 점검하기 위해서
3. System level의 software FMEA를 수행하기 위한 핵심 자원
• PHA
• hazard testing
4. 관련 reference
• SAE ARP 5580
• SAE J-1739

5. 전제조건
• software FMEA를 수행하는 analyst는 다음에 대해 완벽하게 이해하여야 함
ü software design
ü hardware structure
ü interface between software and hardware
ü software language to be used
ü specifics of the software tools being used
6. 모든 component에 대한 failure mode
• Failure to execute
• Executes incompletely
• Executes with incorrect timing which includes incorrect activation and execution
time (including endless loop)
• Erroneous execution
6. Interrupt Service Routine(ISR)에 대한 failure mode
• Failure to return, thus blocking lower priority interrupts from executing
• Returns incorrect priority

5. 전제조건
• software FMEA를 수행하는 analyst는 다음에 대해 완벽하게 이해하여야 함
ü software design
ü hardware structure
ü interface between software and hardware
ü software language to be used
ü specifics of the software tools being used
6. 모든 component에 대한 failure mode
• Failure to execute
• Executes incompletely
• Executes with incorrect timing which includes incorrect activation and execution
time (including endless loop)
• Erroneous execution
7. Interrupt Service Routine(ISR)에 대한 failure mode
• Failure to return, thus blocking lower priority interrupts from executing
• Returns incorrect priority

8. 활동
• inductive reasoning을 수행하여 특정 mode에서 의도된 행동을 하는데 실패하는
component나 function에 대한 system 수준에서의 영향을 점검한다.
• Component에 대한 general failure mode를 정의한다.
• ISR에 대한 general failure mode를 정의한다.
• 각각의 functional subroutine에 대한 관련 failure mode의 effect를 평가한다.
• failure mode의 영향으로 인한 software output을 분석하고 hazardous outcome을
식별한다.
• 식별된 hazardous outcome에 대해 SSR 혹은 software design을 추가한다.
• 각각의 component나 function에 대해 failure mode를 적용하여 local 및 system
level의 영향을 분석하여 severity도 할당한다.

System-Level의 Software FMEA의 example

1. 목표
• detailed software design을 분석한다.
• 구현된 software를 분석하여 software safety requirement가 만족되었는지를 확인
한다.
2. 활동
• subsystem interface를 분석하여 subsystem과 관련있는 잠재적 hazard를 식별한
다.
• 잠재적 unsafe state를 체크한다. unsafe state는 다음에 의해 유발될 수 있다.
ü I/O timing
ü out-of-sequence event
ü adverse environment
• SW FMEA나 SW FTA의 방법을 수행한다.
• requirement와 architecture phase에서 수행한 high-level의 FTA를 이용하여
potential hazard를 software variable과 state수준으로까지 확장시킨다.
• input variables및 software 내부의 processing logic의 잠재적 failure를 tracing를
함으로써 detailed FMEA를 적용한다.
• analysis의 수준은 criticality level의 값에 의존적이다.

Example code for determining system mode
다른 routine에서 작성한 diagnostic flag를 검사한다.
failure가 발생하면 system을 safe한 상태로 이동시킨다.
(Source code에서는 controller를 shot down시킨다.)
다른 routine에서 작성한 diagnostic flag를 검사한다.
failure가 발생하면 system을 safe한 상태로 이동시킨다.
(Source code에서는 controller를 shot down시킨다.)

Detailed Software Fault Tree Analysis
software detailed design과 code가 available하기 때문에 fault tree의 내용을 상세화 시킬
수 있다.
Detailed Software FMEA Technique
시간이 많이 소모되고 very-high integrity system에만 적용된다.
Example Variable mapping
Software routine에 대해 input, output,
global variable mapping을 수행한다.
variable mapping이 완성되면 variable과
processing logic에 대한 failure mode를
개발한다.
Software routine에 대해 input, output,
global variable mapping을 수행한다.
variable mapping이 완성되면 variable과
processing logic에 대한 failure mode를
개발한다.

Variable Failure Modes
Variable의 종류는 3가지가 있다.
1) Analog
2) Boolean
3) Enumerated
Failure Modes for Different Variable Type

Software Processing Logic Failure Modes
Software Processing Logic의 Failure Mode는 operator fault가 있다.
x = a + b === > x = a – b (fault)
Integrating Results
Example of a set of top-level critical variables identified by a detailed hazard analysis
critical variables

Effective application of software safety techniques for automotive embedded control systems

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Viewers also liked

Viewers also liked (19)

Similar to Effective application of software safety techniques for automotive embedded control systems

Similar to Effective application of software safety techniques for automotive embedded control systems (20)

Effective application of software safety techniques for automotive embedded control systems