ISO26262-6 Software development process (Ver 3.0)

ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
Introduction to ISO 26262
• Product development – SW level
(ISO 26262 Part 6) Ver 3.0

ⓒ-Copyright 2014 Korea Testing Laboratory 2
본 과정의 목표
1. ISO26262에서 요구하는 Software 수준의 개
발 프로세스에 대해 이해
2. 각 단계에서 요구하는 기술적 개발 및 검증 방
법에 대해 이해

Contents
 Background
 Software 프로세스 overview
 프로세스 각각의 주요 활동들
1. Initiation of SW Development
2. Specification of Software Safety Requirements
3. Software architectural design
4. Software unit design and implementation
5. Software unit testing
6. Software integration testing
7. Verification of software safety requirements

Key Words
Item definition3-5
Initiation of the
Safety lifecycle
3-6
Hazard analysis and
risk assessment
3-7
Functional Safety
concept
3-8
Production7-5
Operation, service
and
decommissioning
7-6
Other
technologiesProduction planning7-5Operation planning7-6 Controllability
External
measures
Product development :
System level
4
Hardware
Level
5
Software
Level
6
Release for production4-11
ConceptphaseProductdevelopmentAfterSOP
Major activities
•Specification of SW safety
requirements
• SW architectural design
• SW unit design & implementation
• SW integration and testing

Background

Tables의 해석 방법
Consecutive entry – all methods shall be applied as recommended in accordance
with ASIL
Alternative entry – an appropriate combination of methods shall be applied in
accordance with ASIL

“++” – The method is highly recommended for the identified ASIL
“+” – The method is recommended for the identified ASIL
“o” – The method has no recommendation for or against for the identified ASIL

ASIL A의 시스템에서 요구하는 모델링 또는 코딩 가이드라인
(1a, 1b, 1c, 1h의 내용을 적절하게 포함시켜야 할 것)
ASIL C의 시스템에서 요구하는 모델링 또는 코딩 가이드라인
(1a, 1b, 1c, 1d, 1f, 1g, 1h의 내용을 적절하게 포함시켜야 할 것)

ISO26262 Development Process
"The item must not trigger
energy release of the storage
device below 15 km/h”
(ASIL C)
“The actuator shall not be
activated while the vehicle
speed is higher than 15km/h“
(ASIL C)
Concept Dev. phase
System Dev. phase

ISO26262 Development Process
"The item must not trigger
energy release of the storage
device below 15 km/h”
(ASIL C)
“The actuator shall not be
activated while the vehicle
speed is higher than 15km/h“
(ASIL C)
Concept Dev. phase
System Dev. phase
ASIL C
등급
Actuator Control ECU에 들어가는
Software는 ASIL C등급으로 개발해야 한다!

System level에서의 요구사항을 Software level의 요구사항으로 재정의한다.
Software의 구조를 설계 및 구현, 테스트를 수행한다.
이전 단계의 요구사항을 System level에서의 요구사항으로 재정의한다.
System의 구조를 설계한다.
System을 테스트 한다.
개발하고자 하는 시스템의 요구사항을 정의하고 ASIL등급을 정의한다.
ISO 26262 development process에서 SW개발
Concept Development phase
System Development phase
Hardware Development phase
Software Development phase

Software 프로세스 overview

Software development phase model
[Reference phase model for the software development]
4-7 시스템 설계
4-8 아이템 통합 및
시험
6-6 소프트웨어
안전 요구사항 명세
6-7 소프트웨어
아키텍처 설계
6-8 소프트웨어
유닛 설계 및 구현
6-9 소프트웨어
유닛 시험
6-10 소프트웨어
통합 및 시험
6-11 소프트웨어
안전 요구사항 검증
4부
범
위
6부
범
위
6부
범위
6-5소프트웨어수준의제품개발착수
4부
범위
아이템 시험
시험 단계 검증
소프트웨어 시험
소프트웨어 시험
소프트웨
어 시험
시험 단계
검증
시
험
단
계
설
계
단
계
설계 단계
검증
설계 단계
검증
설계 단계
검증

Initiation of SW Development
 Activities
1. Determination of appropriate methods
-SW개발 단계에서 사용할 methods에 대해 계획한다.
2. Tool application guideline
-SW개발 단계에서 사용할 tool을 적용하기 위한 가이드
라인을 준비한다.
3. Modeling and coding guideline
-SW개발 단계에서 사용할 Modeling및 coding에 적용하
기 위한 가이드라인을 준비한다.
4. The coordination with hardware development
-HW개발단계와 진행 상황을 조정하기 위한 계획을 세운
다.
5. Perform tool qualification
-SW개발 단계에서 사용할 tool에 대한 qualification을 수
행한다.
6. Software component qualification
-사용할 Software component를 qualification을 수행한다.
-SW개발 단계에서 사용할 Modeling및 coding에 적용하
기 위한 가이드라인을 결정한다.
8. Guidelines for the application of methods
-SW개발단계에서 사용할 Technical method에 대한 적용
가이드라인을 준비한다. (절차서)
5. Initialization of Product Development
Objectives To plan and initiate the functional safety activities
Prerequisites Project plan(Part 4)
Safety plan(Part 4)
Item integration and testing plan(Part 4)
Technical safety concept(Part 4)
System design specification(Part 4)
Further
supporting
Information
Design and coding guidelines for modeling and
programming languages(External)
Guidelines for application of methods(External)
Guidelines for application of tools(External)
Qualified software components available(Part 8)
Work
products
Safety plan
Software verification plan
Design and coding guidelines
Software tool application guidelines
Qualified software tools available(Part 8)

Specification of software safety requirements
 Activities
1. Specify software safety requirements
specification
-Software safety requirements specification을 명세
한다.
2. Verify Hardware-Software interface
specification
-HW개발자와 SW개발자가 합동으로 Hardware-
software interface specification을 기술하고 검증한
다.
3. Verify software safety requirements
specification
-Software safety requirements specification을 검증
한다.
6. Specification of software safety requirements
Objectives To specify the software safety requirements
Prerequisites Technical safety concept(Part 4)
Safety plan(Previous phase)
Hardware-software interface specification(Part 4)
Software verification plan(Previous phase)
Further
supporting
Information
Hardware design specification(Part 5)
Derived from the technical safety concept
Derived from the system design specification
Guidelines for application of methods(external)
Work
products
Software verification report
Software verification plan
Hardware-software interface specification
Software safety requirements specification

Software architectural design
 Activities
1. Develop a software architectural design
-Design guideline으로 software architectural
design을 수행한다.
2. Verify the software architectural design
-Dependent failure analysis, Safety analysis를 포함
하여 software architectural design을 검증한다.
Objectives To develop a software architectural design
Prerequisites
Software safety requirement specification(6.5.1)
Safety plan(5.5.1)
Design and coding guidelines for modeling and
programming languages(5.5.3)
Software verification report(6.5.4)
Further
supporting
Information
Technical safety concept(Part 4)
Qualified software components available(Part 8)
To verify the software architectural design
Guidelines for application of methods(extenal)
Software tool application guidelines(5.5.4)
Work
products
Safety analysis report
Software safety requirements specificaion
Safety plan
Software architectural design specification
Dependent failures analysis report
Hardware-software interface specification
(Part 4, 7.5.6)
Software verification plan(6.5.3)

Software unit design and implementation
Activities
1. Develop a software unit design
-Design guideline으로 software unit design을 수행
한다.
2. Develop the software unit
implementation
-Coding guideline으로 software unit
implementation을 수행한다.
Objectives To specify and implement the software units
Prerequisites Safety plan(7.5.2)
Software verification plan(6.5.3)
Software architectural design specification(7.5.1)
Software safety requirements specification(7.5.3)
Further
supporting
Information Technical safety concept (Part 4)
System design specification (Part 4)
To verify the design and implementation
Work
products
Software unit implementation
Software unit design specification
Software verification report(7.5.6)
Safety analysis report (7.5.4)
Guidelines for application of methods (external)
Software tool application guidelines (5.5.4)
Pre-existing software components (external)
Design and coding guidelines (5.5.3)

Software unit testing
 Activities
1. Verify the software unit design
-Software unit design을 검증한다.

Software integration testing
 Activities
1. Verify the software components

Verification of software safety requirements
 Activities
1. Validate the embedded software

1. Initiation of SW Development

소프트웨어 개발 계획

소프트웨어 개발 라이프사이클의 정의
요구사항 명세
아키텍처 설계
단위 설계
구현
단위 시험
통합 및 통합 시험
임베디드 소프트웨어 시험

소프트웨어 개발 라이프사이클의 정의
소프트웨어 개발 라이프사이클 요약

RASIC Chart
소프트웨어 개발 활동 별 RASIC 차트

Role & Responsibility
소프트웨어 개발활동 역할 및 책임

관련된 계획
1. 소프트웨어 개발 계획
2. 소프트웨어 검증 계획
3. 소프트웨어 품질 보증 계획
4. 소프트웨어 형상관리/변경관리 계획
Lifecycle의 각 phase에서 role의 activities

형상관리 계획 활동
1. 형상 식별: 식별할 예정인 경우 식별할 항목, 소프트웨어 수명 주기 데
이터에 대한 식별 방법(예를 들어 파트넘버 매기기), 그리고 소프트웨
어 식별과 시스템 또는 장비 식별의 관계.
2. 기준 및 추적성: 기준을 설정하는 방법, 설정할 기준, 해당 기준을 설
정할 시기, 소프트웨어 라이브러리 제어 및 형상항목과 기준 추적성.
3. 문제 보고: 소프트웨어 제품과 소프트웨어 수명 주기 프로세스에 대한
문제 보고서의 내용과 식별, 이들을 작성할 시기, 문제 보고서를 종결
하는 방법 및 변경 제어 활동에 대한 관계.
4. 변경 제어: 제어할 형상항목과 기준, 이들을 제어할 시기, 이들을 제어
하는 문제/변경 제어 활동, 승인 전 제어, 승인 후 제어, 그리고 기준과
형상항목의 무결성을 보존하는 수단.

형상관리 계획 활동
5. 변경 검토: 소프트웨어 수명 주기 프로세스에 대한 피드백 처리 방법,
문제 평가와 우선순위 설정, 변경 승인 및 문제 해결방법 또는 변경 구
현 처리, 그리고 문제 보고와 변경 제어 활동에 대한 이 방법의 관계.
6. 형상 상태 확인: 형상관리 상태를 보고할 수 있도록 하기 위해 기록할
데이터, 해당 데이터를 보존할 위치에 대한 정의, 보고에 대해 해당 데
이터를 검색할 방법, 그리고 해당 데이터를 사용할 수 있게 되는 시기.
7. 보관, 검색 및 배포: 무결성 제어, 배포 방법과 기관, 그리고 데이터 보
존.
8. 소프트웨어 로드 제어: 소프트웨어 로드 제어 안전장치와 기록에 대한
설명.
9. 소프트웨어 수명 주기 환경 제어: 소프트웨어를 개발, 빌드, 검증 및
로드하는 데 사용되는 도구에 대한 제어. 검증할 도구에 대한 제어도
여기에 포함된다.
10. 소프트웨어 수명 주기 데이터 제어: 형상 데이터 제어.

품질보증 계획 활동
 SQA 방법, 예를 들어 소프트웨어 수명 주기 프로세스에 대한 검사, 심
사, 보고, 검사 및 감시.
 문제 보고, 추적 및 시정 조치 시스템과 관련된 활동.
 소프트웨어 적합성 검토 활동에 대한 설명.

모델링 및 코딩 가이드라인

Modeling and Coding Guidelines
design과 implementation의 correctness를 support하기 위해서 design 및
coding guideline이 포함되어야 할 Topic들

Topics to be covered by modeling and coding
guidelines(1)
1. Enforcement of Low complexity
• 복잡도가 증가하면 구현이 어렵고, 오류가
발생했을 때 디버깅 하기가 어려우며, 테스트가
어렵고, 유지 보수가 어렵게 된다.
• Lines of Code – 함수당 한 화면에 보일 수 있도록
• Cyclomatic Complexity – 10 이하가 되도록
2. Use of language subsets
• C의 문법 체계가 모호하고 개발자가 실수하기
쉬운 표현들도 문법상 오류가 아니기 때문에
제한된 영역의 C언어를 사용하여야 한다.
• MISRA C의 규칙들을 적용한다.

guidelines(5)
3. Enforcement of strong typing
• 여러 데이터 타입으로 연산을 하게 되면 개발자가
의도하지 않은 결과가 발생할 수 있다.
• MISRA Rule적용

guidelines(5)
4. Use of defensive implementation techniques
• double및 float와 같은 부동 소수점 데이터 타입은
equality표현을 쓰면 개발자가 의도한 결과와 다른
결과가 나올 수 있으므로 주의하여야 한다.
• MISRA Rule적용

guidelines(5)
5. Use of style guides
6. Use of naming conventions

MISRA Rule로 cover할 수 있는 Table1의 topics
Rule Type # of Rules
Environment 5
Language extensions 4
Documentation 6
Character sets 2
Identifiers 7
Types 5
Constants 1
Declarations and definitions 12
Initialization 3
Arithmetic type conversions 6
Pointer type conversions 5
Control statement expressions 7
Control flow 10
Switch statements 5
Functions 10
Pointers and arrays 6
Structures and unions 4
Preprocessing directives 17
Standard libraries 12
Run-time failures 1
Total 128
MISRA Rule의 분류
MISRA Rule로 cover할 수 있는 topics

Coding rule과 관련된 table
Table 8. Design principles for software unit design and implementation
Topics
ASIL
A B C D
1a
One entry and one exit point in subprograms and functi
ons 1)
++ ++ ++ ++
1b
No dynamic objects or variables or else online test durin
g their creation 1), 2)
+ ++ ++ ++
1c Initialization of variables ++ ++ ++ ++
1d No multiple use of variable names 1) + ++ ++ ++
1e Avoid global variables or else justify their usage 1) + + ++ ++
1f Limited use of pointers 1) o + + ++
1g No implicit type conversions 1), 2) + ++ ++ ++
1h No hidden data flow or control flow 3) + ++ ++ ++
1i No unconditional jumps 1), 2), 3) ++ ++ ++ ++
1j No recursions + + ++ ++
1) Methods 1a, 1b, 1d, 1e, 1f, 1g and 1i may not be applicable for graphical modeling
notations used in model-based development.
2) Methods 1g and 1i are not applicable in assembler programming.
3) Methods 1h and 1i reduce the potential for modeling data flow and control flow thr
ough jumps or global variables.

MISRA C와 Table 8의 관계
01.01 01.02 01.03 01.04 01.05 02.01 02.02 02.03 02.04 03.01 03.02
03.03 03.04 03.05 03.06 04.01 04.02 05.01 05.02 05.03 05.04 05.05
05.06 05.07 06.01 06.02 06.03 06.04 06.05 07.01 08.01 08.02 08.03
08.04 08.05 08.06 08.07 08.08 08.09 08.10 08.11 08.12 09.01 09.02
09.03 10.01 10.02 10.03 10.04 10.05 10.06 11.01 11.02 11.03 11.04
11.05 12.01 12.02 12.03 12.04 12.05 12.06 12.07 12.08 12.09 12.10
12.11 12.12 12.13 13.01 13.02 13.03 13.04 13.05 13.06 13.07 14.01
14.02 14.03 14.04 14.05 14.06 14.07 14.08 14.09 14.10 15.01 15.02
15.03 15.04 15.05 16.01 16.02 16.03 16.04 16.05 16.06 16.07 16.08
16.09 16.10 17.01 17.02 17.03 17.04 17.05 17.06 18.01 18.02 18.03
18.04 19.01 19.02 19.03 19.04 19.05 19.06 19.07 19.08 19.09 19.10
19.11 19.12 19.13 19.14 19.15 19.16 19.17 20.01 20.02 20.03 20.04
20.05 20.06 20.07 20.08 20.09 20.10 20.11 20.12 21.01
ISO26262의 Table 8에서 요구하는 코딩 규칙은
MISRA Rule의 19.9%를 차지한다.
Table 8을 커버하는 MISRA Rules(노란색 표시)

Exercise
다음 코드에서 잘못된 부분이 있다면, 어디에 있을까?
No Code
1 if (x < y && ch=getchar()) != EOF)
2 while (evaluation = 1) { … }
3 double value;
…
if (value == 0.0)
{ … }
4 calculate(x, x=y+4)
5 long *member_ptr, group_ptr;
6 long *buf_ptr;
*buf_ptr = some_value;
7 #define MAX(x,y) (x>y)? x:y
up_limit = MAX(++i, j)

2. Specification of Software Safety
Requirements

요구사항 단계의 중요성 ?
매도 먼저 맞는 놈이 낫다
As good do it at first, as do it last.

Software Safety Requirement의 형식

Software Safety Requirement의 contents
Contents of Software safety requirement
a. safety requirement의 specification and management
b. system과 hardware configuration
(configuration parameter에는 gain control, band pass frequency, clock prescaler가 있다.)
c. hardware-software interface specification
d. hardware safety requirements와 hardware architecture
e. Timing constraints
(Execution 또는 reaction time은 system level에서 response time으로부터 도출한다.)
f. External interfaces
(Ex: communication and user interfaces)
g. software에 대한 impact를 가지고 있는 각각의 vehicle, system, hardware의
operating mode
(hardware device의 operating mode는 default, initialization, test, advanced mode를 포함할 수
있다.)
h. Safety goal을 위반할 가능성이 있는 function
(Next slide)

Software Safety Requirement의 contents
Safety requirement를 위반할 가능성이 있는 functions의 종류
• System이 safe state에 도달하거나 safe state를 유지하도록 하는 function
• 안전과 관련된 하드웨어 elements의 fault 또는 software fault를 detection,
indication, handling하는 것과 관계 있는 function들
• On-board 및 off-board테스트와 관련된 function
• Production 및 service동안 software의 modification을 허용하는 function
• performance또는 time critical operation과 관계된 function

SW safety requirements specification의 추적성
Bi-traceability Required
•Between Technical safety requirement and
Software safety requirement specification
•Between System design and Software safety
requirement specification
ASIL Inherit
Technical Safety requirement또는 System
design으로부터 파생된 Software safety
requirement는 ASIL등급도 상위 문서로부터 할
당 받는다.
ASIL decomposition
Software safety requirement가 ASIL
decomposition을 적용하고자 하는 경우
ISO26262-9, Clause 5 (Requirement
decomposition with respect to ASIL tailoring)
를 따라야 한다.
System Dev. Phase
Software Dev. Phase
Technical Safety
Requirement
System Design
derives
Software Safety
Requirement
derives
derives

Software Safety Requirement의 Verification
[Flow of safety requirements]
Traceability
required !

Safety requirement의 management를 support하기 위해서 적절한
requirement management tool의 사용을 추천한다.
Safety requirement의 structure및 dependency

Different hierarchical level에서의 safety requirement의 context를 고려한
specific requirement는 ISO 26262-2, ISO 26262-3, ISO 26262-4,
ISO 26262-5, ISO 26262-6이다.

Higher level의 safety requirement(e.g. functional and technical requirements)에 대
해 natural language가 더 적절하다. 반면에 lower level의 safety requirement(e.g.
software and hardware safety requirement)의 경우 Table 1에 나열된 방법들이
더 적절하다.
Natural language가
더 적절하다
Table 1에 나열된 방법
이 더 적절하다

Safety requirement가 가져야 하는 특성
a) Unambiguous and comprehensible
(requirement의 의미에 대해 공통의 이해가 있다면 unambiguous한 것이다.)
(stakeholder나 그 requirement의 consumer와 같은 adjacent level의 reader가 그 의미를 이해한다면
comprehensible한 것이다.)
b) Atomic
(safety requirement를 더 이상 잘개 쪼갤 수 없다면 atomic한 것이다.)
c) Internally consistent
(safety requirement간의 conflict가 없다면 internally consistent한 것이다.)
d) Feasible
(resource, state-of-the-art등으로 item development의 constraint내에서 구현이 될 수 있다면 feasible한 것이다.)
e) Verifiable

safety requirement의 set은 다음의 속성을 만족해야 한다.
a) Hierarchical structure
Note 1. hierarchical structure는 그림 2에 표현된 것과 같은 몇 개의 연속적인 레벨로 구조화된 safety
requirement를 의미한다. 이런 level들은 항상 그에 해당하는 design phase에 할당되어 있다.
b) 적절한 그룹 scheme에 따른 Organizational structure
Note 2. safety requirements의 organization은 서로 그룹된 각각의 level내의 safety requirement는
대개 그 architecture에 대응한다.
c) Completeness
Note 3. completeness는 한 level에서의 safety requirement가 이전 level의 모든 safety requirement
를 충분히 구현함을 의미한다.
d) External consistency
e) Hierarchical structure의 어떤 레벨 내에서도 no duplication of information
f) maintainability

Software Safety Requirement의 Verification
Software Safety Requirement는 다음의 문서들과 일관성이 있어야 한다.
• technical safety requirements
• system design
Hardware-software interface specification의 verification
• System, hardware, software 개발 책임자들이 공동으로 검증을 수행한다.

1. 설계원칙
2. 컴포넌트의 종류에 따른 ISO26262 개발
요구사항
3. Software Component에 ASIL 등급 할당
4. Safety Analysis
5. Verification of software architecture

설계 원칙

Software Architectural design을 표현하는 방법
software architectural design에서 고려되어야 할 요소
• software architectural design의 verifiability(bi-directional traceability)
• the suitability for configurable software
• the feasibility for the design and implementation of the software units
• the testability of the software architecture during software integration testing
• the maintainability of the software architectural design.

Formal Methods - “Use of mathematics in software development”
Main activities
1) Writing formal specifications
2) Proving properties about formal specifications
3) Constructing a program by mathematical manipulating a formal specification
4) Verifying a program by mathematical argument
Formal:
In a (fixed) language with mathematically defined syntax and semantics
Semi formal:
In a language with
• Syntax definition by mathematical methods
• Semantics definition in natural language or by tool
Non formal:
In natural language (open to arbitrary new symbols)
Formal, Semi-formal, and Non formal
59

Software architectural design principle
방법
ASIL
A B C D
1a 소프트웨어 컴포넌트의 계층적 구조 ++ ++ ++ ++
1b 소프트웨어 컴포넌트의 제한된 크기a ++ ++ ++ ++
1c 인터페이스의 제한된 크기a + + + +
1d 각 소프트웨어 컴포넌트 내 높은 응집도(cohesion)b + ++ ++ ++
1e 소프트웨어 컴포넌트 사이 제한된 결합도(coupling)a,b,c + ++ ++ ++
1f 적합한 스케줄링 속성 ++ ++ ++ ++
1g 인터럽트의 제한된 사용a,d + + + ++
a 1b, 1c, 1g 방법의 “제한된”의 의미는 기타 설계 고려로 조화롭게 최소화 하는 것을 말한다.
b 1d와 1e 방법은 특별한 개념, 목표, 태스크 또는 목적과 관련된 소프트웨어의 부품을 식별,
캡슐화, 조정하는 능력을 말하는 관심의 분리를 통해 구현될 수 있다.
c 1e 방법은 소프트웨어 컴포넌트의 외부 결합 제한을 다루고 있다.
d 사용되는 모든 인터럽트는 우선 순위를 기준으로 해야 한다.

Software architectural design principle
Hierarchical Structure의 5가지 원리
추상화(Abstraction): 문제를 이해하고 표현하기 위해 세부사항을 모두 기술하
지 않고도 추상화, 또는 개념화시켜 표현하는 원리이다.
정보은닉(Information Hiding): 각 모듈은 다른 모듈에 독립적이며 한쪽 모듈
의 변경이 다른 모듈의 세부내용에 영향을 미치지 않는다.
구조화(Structuring): 소프트웨어에 계층적인 구조를 부여하여 상위 모듈이 하
위 모듈을 활용하는 질서를 갖도록 한다.
단계적 상세화(Stepwise Refinement): 하향식으로 진행하면서 점차적으로 내
용을 구체화시켜가는 것이다.
모듈화(Modularization): 하나의 시스템을 서브시스템, 프로그램, 모듈 등으로
구분하여 정의하고 개별적으로 설계한다. 모듈이란 이름을 가지며 하나의 작업
단위를 처리할 수 있는 최소한의 프로그램 단위라고 볼 수 있다.
D. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, Communications of the ACM, 15 (12), 1972

Hierarchical Data flow diagram의 사례

Static design aspects
Hierarchical levels를 포함하는 software
structure
Data processing의 logical sequence
Data types, their characteristics
Software component의 interface
Software의 external interface
Architecture의 영역에 속한 제약과 external
dependencies
Dynamic design aspects
The functionality and behavior
The control flow and concurrency of processes
The data flow between the software components
The data flow at external interfaces
The temporal constraints
Contents of Software Architecture

컴포넌트의 종류에 따른 ISO26262 개발 요구사항

Software architecture design시에 발생할 수 있는 문제
안전과 관련된 소프트웨어 컴포넌트는 네 가지 종류가 있다.
1) Newly developed
2) Reused with modifications
3) Reused without modifications
4) COTS(Commercial off the shelf)
모든 컴포넌트를 ISO26262에 따라 개발해야 할 것인가?
COTS같은 컴포넌트들은 어떻게 해야 할까?

Software architecture design시에 발생할 수 있는 문제
Newly
developed
Reused with
modifications
Reused
without
modifications
A COTS
product
ISO 26262에 따라 개발
Software component
qualification을
수행해야 한다.
(ISO26262:8, Clause 12)
Safety-related software component의 분류
Lifecycle시작할 때,
software component
qualification에 대한 자료는
준비되어 있는 것이 좋다.
(Ref: Next slide)

Initiation of SW Development
 Activities
1. Determination of appropriate methods
-SW개발 단계에서 사용할 methods에 대해 계획한다.
2. Tool application guideline
-SW개발 단계에서 사용할 tool을 적용하기 위한 가이드라인
을 준비한다.
-SW개발 단계에서 사용할 Modeling및 coding에 적용하기
위한 가이드라인을 준비한다.
4. The coordination with hardware development
-HW개발단계와 진행 상황을 조정하기 위한 계획을 세운다.
5. Perform tool qualification
-SW개발 단계에서 사용할 tool에 대한 qualification을 수행
한다.
6. Software component qualification
-사용할 Software component를 qualification을 수행한다.
-SW개발 단계에서 사용할 Modeling및 coding에 적용하기
위한 가이드라인을 결정한다.
8. Guidelines for the application of methods
-SW개발단계에서 사용할 Technical method에 대한 적용 가
이드라인을 준비한다. (절차서)

소프트웨어 컴포넌트 요약 및 세부 명세 사례
Software component summary
Software component details

Software Component에 ASIL 등급 할당

Software Component의 ASIL등급 할당 방법
ASIL 할당 규칙
모든 SSR는 Software component에 할당되어야 함
Req1
Req2
Software
component A
Software
component B
allocation
allocation
SSRs(Software Safety Requirements)
ASIL A
ASIL A
ASIL C
ASIL C
SCs(Software Components)

ASIL할당 시에 발생할 수 있는 문제
Component A가 두 개 이상의 SSR로부터 ASIL을 할당 받는 경우
Component A의 ASIL등급은 무엇이 될 것인가?
Req1
Req2
Req3
Req4
Software
component A
Software
component B
allocation
allocation
SSRs(Software Safety Requirements)
ASIL 등급 ???

Req1
Req2
Req3
Req4
Software
component A
Software
component B
ASIL 등급 =
Max(Req1, Req2)
ASIL 등급 =
Max(Req2, Req3, Req4)
allocation
allocation
SSRs(Software Safety
Requirements)
Component의 ASIL할당 규칙

Embedded Software의 ASIL등급 할당 방법
Embedded Software도 ASIL등급을 할당 받아야 한다.
하지만 Embedded Software의 ASIL등급 할당은 Software Component와는 약간
다르다.
Embedded Software는 다음의 두 가지 중 하나로 구성되어 있다.
1) 서로 다른 ASIL을 가진 component로 구성되어 있다.
2) 안전관련 소프트웨어 컴포넌트와 안전 비 관련 소프트웨어 컴포넌트로 구성
되어 있다.
컴포넌트간 co-existence criteria를 만족하느냐의 여부에 따라 방법이 달라진다.
co-existence criteria?
 컴포넌트간 분리되어 있는가?
(분리된 영역에서는 다른 영역의 코드, 데이터, performance에도 영향을 끼쳐서
는 안된다)

Component간 Co-existence criteria에 속하지 않는 경우의 Embedded Software
의 ASIL 등급
Software
Component
SC_A
Software
component
SC_B
Embedded Software
Software
Component
SC_C
ASIL of Embedded Software = Maximum ASIL of (SC_A, SC_B, SC_C)
SC_A : ASIL C
SC_B : ASIL B
SC_C : ASIL A
Embedded Software의 ASIL등
급 ??

Component간 Co-existence criteria에 속하지 않는 경우의 Embedded Software
의 ASIL 등급
Software
Component
SC_A
Software
component
SC_B
Embedded Software
Software
Component
SC_C
ASIL of Embedded Software = Maximum ASIL of (SC_A, SC_B, SC_C)
SC_A : ASIL C
SC_B : ASIL B
SC_C : ASIL A
Embedded Software : ASIL C
ASIL C

Component간 Co-existence criteria에 속는 경우의 Embedded Software의 ASIL
등급
Software
Component
SC_A
Software
component
SC_B
Embedded Software
Software
Component
SC_C
ASIL of Embedded Software는 각 구역(partition)마다 서로 다른 ASIL등급을
가질 수 있다.
SC_A : ASIL C
SC_B : ASIL B
SC_C : ASIL A
급???

Component간 Co-existence criteria에 속는 경우의 Embedded Software의 ASIL
등급
Software
Component
SC_A
Software
component
SC_B
Embedded Software
Software
Component
SC_C
ASIL of Embedded Software는 각 구역(partition)마다 서로 다른 ASIL등급을
가질 수 있다.
SC_A : ASIL C
SC_B : ASIL B
SC_C : ASIL A
급???
ASIL A, B, C

Software partitioning

Software partitioning이란
Software elements간의 간섭이 없도록 설계하는 방법
Software partitioning의 목적
한 소프트웨어 partition에서 발생한 에러를 다른 소프트웨어 partition으로 전이
되는 것을 막기 위함
Software partitioning의 조건
- Software component간의 간섭이 없어야 한다.
- 다음의 속성을 보여야 한다.
- 공유 자원의 간섭이 없음
- 자기 영역(코드 및 데이터)이 다른 component에 의해 간섭이 없음
- Task performance가 다른 component에 의해 간섭이 없음
Software partitioning의 장점
동일한 resource를 사용하는 software partition들의 coexistence를 허용한다.
하나의 software partition을 변경하였을 때, 다른 software partition은 재검증하
지 않아도 된다.

Software partitioning의 사례
Partition을 하지 않은 경우(왼쪽 그림) – Task 전체가 같은 ASIL등급으로 묶인다.
Partition을 한 경우(오른쪽 그림) – Partition A와 Partition B는 서로 다른 ASIL등
급이 될 수 있다.
ASIL of Partition A = Max ASIL of (Task1, Task2, Task3)
ASIL of Partition B = Max ASIL of (Task4, Task5, Task6)

Safety Analysis

Safety Analysis
소프트웨어 아키텍처에 대해 안전 분석을 수행한다.
목적
• Safety goal을 위협할 수 있는 fault가 설계에 반영되었는지의 여부를 분석
방법
• FMEA(bottom-up approach)
• FTA(top-down approach)
결과
• 식별된 위험한 fault/failure는 아래의 방법을 이용하여 해당 fault/failure를
처리하기 위한 safety mechanism을 설계에 반영함(변경 사항 발생)
 error detection mechanism 또는
 error correction mechanism

FMEA 수행 절차
Base practice 1. FMEA Planning을 수행한다.
Base practice 2. 분석 단위 각각에 대한 failure mode 각각을 적용하고 failure에 의
한 시스템의 영향을 평가한다.
Base practice 3. BP2의 결과에서 식별된 안전 목표를 위반하는 어떤 대상의 failure
mode에 대해 이 문제를 해결하기 위한 detection strategy혹은 handling strategy를
결정한다
Work product Outputs
[1] FMEA 수행 계획서
[2] FMEA analysis report

FTA 수행 절차
Base practice 1. FTA Planning을 수행한다.
Base practice 2. 소프트웨어 아키텍처를 기반으로 각각의 최 상위 이벤트의 발생에
대한 발생 원인을 분석하되 발생원인이 최 하위 이벤트 수준 단계의 조합으로 식별
될 때까지 반복한다.
Base practice 3. BP2의 결과에서 식별된 위험한 fault/failure를 식별하여 이를 보완
하기 위한 전략을 결정한다.
Work product Outputs
[1] FTA 수행 계획서
[2] FTA analysis report

Error detection mechanisms
목적
• Safety analysis로부터 도출된 소프트웨어 아키텍처 모델의 위험을 detect하기
위해서
방법
ASIL
A B C D
1a 입출력 데이터 범위 확인 ++ ++ ++ ++
1b 타당성 확인(plausibility check)a + + + ++
1c 데이터 오류 검출b + + + +
1d 외부 모니터링 기능c o + + ++
1e 제어 흐름 모니터링 o + ++ ++
1f 다양한 소프트웨어 설계 o o + ++
a 타당성 확인은 요구되는 행위에 대한 기준 모델의 사용, 어서션(assertion) 체크 혹은 서로
다른 소스로부터의 신호 비교 등을 포함할 수 있다.
b 데이터 오류를 검출하는데 사용될 수 있는 방법의 종류는 오류 검출 코드와 다수 데이터
저장을 포함한다.
c 외부 모니터링 기능으로는 예를 들면 ASIC나 워치독(watchdog) 기능을 수행하는 다른 소
프트웨어 엘리먼트가 될 수 있다.

Error handling mechanisms
목적
• Safety analysis로부터 도출된 소프트웨어 아키텍처 모델의 위험을 handling하
기 위해서
방법
ASIL
A B C D
1a 정적 복구 메커니즘a + + + +
1b 적절한 데그러데이션(graceful degradation)b + + ++ ++
1c 독립적 병렬 중복c o o + ++
1d 데이터 정정 코드 + + + +
a 정적 복구 메커니즘은 복구 블록(recovery blocks), 백워드 복구(backward recovery), 포
워드 복구(forward recovery), 반복을 통한 복구(recovery through repetition)의 사용을
포함할 수 있다.
b 소프트웨어 수준의 적절한 데그러데이션(degradation)은 기능 안전성에 대한 잠재적인
고장의 역 효과를 최소화 하기 위한 기능의 우선 순위와 관련이 있다.
c 독립적 병렬 중복은 각 병렬 경로에서 다른 소프트웨어로 구현될 수 있다.

Verification of software architecture

Software architectural design의 verification방법
방법
ASIL
A B C D
1a 설계에 대한 워크스루(walk-through)a ++ + o o
1b 설계에 대한 인스펙션(inspection)a + ++ ++ ++
1c 동적 부품의 설계에 대한 시뮬레이션b + + + ++
1d 시제품 생성b o o + ++
1e 정형 검증 o o + +
1f 제어 흐름 분석c + + ++ ++
1g 데이터 흐름 분석c + + ++ ++
a 모델 기반의 개발(model-based development)인 경우 이 방법을 모델에 적용할 수 있다.
b 방법 1c는 소프트웨어 아키텍처의 동적 부분을 위해 실행 가능한 모델이 필요하다.
c 제어 및 데이터 흐름 분석은 안전관련 컴포넌트와 그 인터페이스로 제한될 수 있다.

Software unit design을 위한 표현 방법
방법
ASIL
A B C D
1a 자연 언어 ++ ++ ++ ++
1b 비정형 표기법 ++ ++ + +
1c 준정형 표기법 + ++ ++ ++
1d 정형 표기법 + + + +

Software unit design 및 implementation을 위한
design 원칙
방법
ASIL
A B C D
1a 서브프로그램과 함수에서 하나의 진입점과 하나의 종료점a ++ ++ ++ ++
1b
동적 개체 또는 변수를 사용하지 않음, 혹은 그렇지 않으면 동적 변수 생
성시 온라인 시험a,b
+ ++ ++ ++
1c 변수 초기화 ++ ++ ++ ++
1d 변수 이름을 다목적으로 사용하지 않음a + ++ ++ ++
1e
전역 변수를 사용하지 않음, 만약 사용해야 한다면 그 사용에 대해 정당
화한다.a
+ + ++ ++
1f 포인터의 제한된 사용a o + + ++
1g 암시적 형 변환 없음a,b + ++ ++ ++
1h 숨겨진 데이터 흐름이나 제어 흐름 없음c + ++ ++ ++
1i 무조건적 점프 없음a,b,c ++ ++ ++ ++
1j 재귀 없음 + + ++ ++
a 방법 1a, 1b, 1d, 1e, 1f, 1g, 1i는 모델 기반의 개발에서 사용되는 그래픽 모델링 표기법에 적용될 수 없다.
b 방법 1g와 1i는 어셈블러 프로그래밍에 적용될 수 없다.
c 방법 1h와 1i는 점프 혹은 전역 변수를 통해 숨겨질 수 있는 데이터 흐름이나 제어흐름의 가능성을 줄여준
다.

소프트웨어 unit design, implementation의 verification
방법
ASIL
A B C D
1a 워크스루a ++ + o o
1b 인스펙션a + ++ ++ ++
1c 준정형 검증 + + ++ ++
1d 정형 검증 o o + +
1e 제어 흐름 분석b,c + + ++ ++
1f 데이터 흐름 분석b,c + + ++ ++
1g 정적 코드 분석 + ++ ++ ++
1h 의미적 코드 분석(semantic code analysis)d + + + +
a 모델 기반의 소프트웨어 개발의 경우 소프트웨어 단위 명세서 설계 및 구현은 모델 수준에서
검증될 수 있다.
b 방법 1e와 1f는 소스 코드 수준에 적용될 수 있다. 이러한 방법은 수동 코드 개발과 모델 기
반의 개발 모두에 적용 가능하다.
c 방법 1e와 1f는 방법 1d, 1g 또는 1h의 일부가 될 수 있다
d 방법 1h는 변수들에 대한 가능한 값들을 추상화 표현을 사용함으로써 소스 코드의 수학적 분
석에 사용된다. 이를 위해서 소스 코드를 변환하거나 실행할 필요는 없다.

5. Software unit testing

Software unit testing에서 입증되어야 하는 속성들
단위 시험의 구성 요소
1) Test Driver
• Unit under Test를 구동시키는 프로그램
2) Stub
• Unit under test가 호출하는 모듈을 구현한 껍데기(혹은 깡통)
3) Unit under Test
• 시험 대상 모듈

단위 시험의 구성 요소
1) Test Driver
• 테스트 드라이버는 시험 대상 단위를 호출하는 프로그램이다. 시험 대
상 단위는 드라이버로부터 받은 입력 값과 함께 수행되고 종료될 때 드
라이버에게 결과값을 리턴 한다. 드라이버는 실제 결과값과 시험 대상
단위로부터 반환 받은 결과값을 비교하고 시험 결과를 보장하는 보고
서를 발행한다. 테스트 드라이버는 수행 프로세스에서 주요 단위로 기
능한다. 드라이버는 예상되는 형식으로 시험 대상 단위에게 입력 데이
터를 제공한다.
2) Stub
• 스텁은 시험 대상 단위에 의해 호출되는 단위를 교체한 “더미 서브 프
로그램”이다.스텁은 시험 대상 단위에 의해 호출되는 단위들을 대체한
다. 스텁은 두 가지의 작업을 수행한다. 하나는 스텁이 실제로 호출되
는 증거를 보여준다. 그런 증거는 메시지를 프린트함으로써 보일 수 있
다. 두 번째로, 스텁은 사전 계산된 값을 호출자에게 반환하여 시험 대
상 단위는 수행을 계속할 수 있도록 한다.

동적 시험(Unit/integration) testing을 위한
기초 지식
 시험을 수행하기 위한 전제조건
• 시험을 수행하는 대상 소스코드는 Compile이 가능해야 하고, Execution가능
해야 한다.
• 소스코드의 수행은 일반적으로 deterministic해야 한다.
 동적 시험에서 입력할 수 있는 입력의 종류
• UUT의 input parameters
• Dependent unit의 return value
• Global data
• Local data는 입력 데이터로 사용할 수 없다!

테스트 케이스 예제
Test cases

동적 시험 예제 소스
Source code의 Control flow graph
테스트 대상 Source code

Methods for software unit testing &
deriving test cases

a) Software unit design specification에 부합함
b) Hardware-software interface의 specification에 부합함
c) Functionality를 정확하게 구현함
d) 의도하지 않은 functionality가 없음
e) 소프트웨어의 강인성(Robustness)
(접근 불가능한 소프트웨어가 존재하지 않음, error detection, handling mechanism의 효과성)
f) Functionality를 지원하기 위한 충분한 리소스

Software unit level에서의 구조적 커버리지 메트릭 방법들
Coverage Level 설명
Statement 해당 문장(Statement)이 최소 한 번 이상 실행되는지의
여부
Branch 해당 문장의 조건문에서 참/거짓을 최소 1번 이상 실
행되는지의 여부
MC/DC 해당 문장의 조건문에서 리터럴 하나의 독립적인 변화
가 조건의 결과에 독립적으로 영향을 미치는 조합을
최소 1번 이상 실행했는지의 여부

Coverage Level 설명
Statement 해당 문장(Statement)이 최소 한 번 이상 실행되는지의
여부(TC1 ~ TC4중 어느 하나만 수행해도 만족함)
Branch 해당 문장의 조건문에서 참/거짓을 최소 1번 이상 실행되
는지의 여부. (TC1, TC4)중 하나 & (TC2,TC3)중 하나
MC/DC 해당 문장의 조건문에서 리터럴 하나의 독립적인 변화가
조건의 결과에 독립적으로 영향을 미치는 조합을 최소 1
번 이상 실행했는지의 여부
(TC1, TC2, TC3, TC4)
if ((a || b) && c) TC a b c Result
TC1 F F T F
TC2 T F T T
TC3 F T T T
TC4 F T F F

if ((a || b) && c)
TC a b c Result
TC3 F T T T
TC4 F T F F
TC a b c Result
TC1 F F T F
TC2 T F T T
TC a b c Result
TC1 F F T F
TC3 F T T T

유닛 테스트 환경에 대한 요구사항
software unit testing에 대한 test environment는 가능한 target environment
에 대응되어야 한다.
Test environment와 target environment사이의 차이는 무엇이 있을까?
Test의 scope에 의존하여 software unit testing을 target system의 processor위
에서 수행하는 것은 유용하다. 만약 이것이 불가능하다면 프로세서 에뮬레
이터가 사용될 수 있다. 그렇지 않다면 software unit testing은 개발 시스템
에서 수행된다.
Test 프로세서(PC)와 target 프로세서(FreeScale, etc) 사이의 차이
1) data word
2) address word의 bit width등

6. Software integration testing

integration testing의 목표
(1) 단위의 인터페이스에서 발생할 수 있는 결함을 감지하기 위해서;
(2) 개별 단위를 동작하는 서브 시스템으로 조립하여 최종적으로 시스템
테스트를 할 수 있는 완전한 시스템으로 만들기 위해
일반적인 테스터의 오해
1) 테스터는 드라이버와 스텁으로 단위 시험을 하는 동안 유닛이 이미 시험했
으므로 통합 시험 단계에서 다른 유닛과의 조합에 대해 다시 시험을 할 필
요가 없다고 생각함.
하지만 개별적으로 분리하여 시험을 한 모듈은 다른 모듈과 결합한 상황에
서 적절하게 시험된 것이 아니다.

통합 방법
1) Top-down approach
• M1부터 통합하는 방법
2) Bottom up approach
• M6, M7, M8 M9, M10, M11에서 상위의 모듈들로 통합하는 방법

통합 방법의 장단점
통합 방법 장점 단점
Top down 전체적인 시스템의 흐름을
확인하면서 시험할 수 있음
Stub을 구현하는 것이 복잡하고
어려울 수 있음
Bottom up 통합 과정이 단순하고 stub
을 만드는 수고가 거의 들지
않음
Test driver를 만드는 것의 부담
최상위 수준의 모듈이 통합될 때까
지 전체적인 프로그램의 흐름을 확
인할 수 없음

Software integration testing을 위한 방법들
위의 방법을 이용하여 다음을 입증해야 한다.
a) Software architectural design과 부합함
b) Hardware-software interface의 specification과 부합함
c) Functionality의 correct implementation
d) Robustness (ex. Absence of inaccessible software, effective error detection and handling)
e) Functionality를 지원하기 위한 충분한 리소스

Software integration testing을 위한
테스트 케이스 생성 방법
software integration method에 대해 test case가 적절하게 specification되었음
을 보이기 위해 Table 14에 나열된 방법을 이용하여 테스트 케이스를 생성
해야 한다.

Test case생성시 고려사항
test case의 completeness를 평가하고 unintended functionality가 없다는
confidence를 얻기 위해서 test case에 의한 software architecture level에서
의 requirement의 coverage가 결정되어야 한다. 만약 필요하다면 추가적인
테스트 케이스를 기술하거나 rationale이 제공되어야 한다.
테스트 케이스의 completeness를 평가하고 unintended functionality가 없다는
confidence를 얻기 위해 구조적 커버리지는 Table 15에 나열된 metric에 부
합되도록 측정되어야 한다(ASIL C,D). 만약 측정된 구조적 커버리지가 불충
분하다면 추가적 테스트 케이스를 기술하거나 rationale이 제공되어야 한다.

Software architectural level에서의
구조적 커버리지 메트릭
Function coverage = Executed software functions / Defined software functions
Call coverage = Executed software function calls / Defined software function calls

Function coverage = Executed software functions / Defined software functions
Call coverage = Executed software function calls / Defined software function calls
Main
input > 3
input = get_input();
put_output(output);
End
y n

Function coverage = Executed software functions / Defined software functions = 2/3
Call coverage = Executed software function calls / Defined software function calls = 1/4
Main
input > 3
put_output(output);
End
y n
프로그램의 수행 경로:

Software integration testing환경의 요구사항
software integration testing에 대한 test environment는 target environment와
최대한 가깝게 구현해야 한다.
Q) 테스트 환경과 타깃 환경 사이의 차이가 발생하는 원인은 무엇일까?
테스트 환경과 타깃 환경 사이의 차이가 발생하기 때문에 실제 환경에서 테스
트가 수행이 되지 못한다면 다음의 차이를 분석하여야 한다.
1) source code와 object code의 차이와
2) test environment와 target environment의 차이가 분석되어야 한다.

7. Verification of software safety
requirements

software safety requirement의
verification을 위한 테스트 환경
1a) 하드웨어에 주변 장치를 붙여서 가상의 환경을 만드는 방법.
위의 세가지 중에서 테스트 환경이 가장 가상적이다.
1b) 여러 ECU를 네트워킹 하여 1a)보다 더 실제적인 환경을 만드는 방법이다.
1c) 실제 차량으로 테스트를 하는 방법. 가장 실제적인 환경이다.

8. Configurable Software Development Lifecycle

Configurable Software 개발 프로세스 1
설정(Configuaration) 데이터와 캘리브레이션 데이터가 변경될 때

Configurable Software 개발 프로세스 1(계속)
설정(Configuaration) 데이터와 캘리브레이션 데이터가 변경될 때

Configurable Software 개발 프로세스 2
설정(Configuaration) 데이터는 고정되고 캘리브레이션 데이터가 변경될 때

Tool Qualification

Tool qualification
목적
-Software tool에 대해 ISO26262에서 요구하는 Confidence level을 판단 할 수 있는
criteria를 결정할 수 있도록 하기 위해
-안전 어플리케이션에 사용되는 SW tool이 의도된 목적에 사용할 수 있는지의 자격
을 부여하기 위함
방법
- ISO26262에서 요구하는 Tool Confidence Level(TCL)을 달성하면 SW tool은
qualification되었다고 할 수 있다.
TCL은 TI와 TD의 함수로 표현된다.
TCL = f(TI, TD)

Tool qualification
TI = Tool Impact factor
•TI1 = 안전 관련 기능에 영향을 미치지 않는 도구이다.
•TI2 = 이외의 경우
TD = Tool error Detection factor
•TD1 = malfunction이나 erroneous output을 prevent하거나 detect할 수
있는 high degree confidence를 가지고 있다.
•TD2 = malfunction이나 erroneous output을 prevent하거나 detect할 수
있는 medium degree confidence를 가지고 있다.
•TD3 = 이외의 경우
•TI와 TD를 선정하는데 있어서 약간의 자의적 판단이 가미될 가능성을 가지고 있다.
•TD1과 TD2를 구분하는 기준은 존재하지 않는다.
•다만 software tool이 process tailoring에 사용되어 ISO26262에서 요구하는 task가 빠
질 수 있는 경우 이런 software tool의 TD는 TD2가 되어선 안된다. (TD1 or TD3)

Determination of Tool confidence level(TCL)
TI, TD로부터 Tool confidence level(TCL)은 Table 3과 같이 정의된다.
Qualification of a software tool
TCL1로 분류된 Software tool의 Qualification – no methods
TCL2로 분류된 Software tool의 Qualification – Table 5사용
TCL3로 분류된 Software tool의 Qualification – Table 4사용(가장 엄격한 기준)

Qualification methods
1. Increased confidence from use
a. Software tool이 과거에 same purpose및 상당한 양의 use case를 가지고 있고, 상당
한 양의 운전환경과 기능 제약 사항들을 가지고 과거부터 사용되어 왔다.
b. Confidence를 위한 충분한 데이터를 가지고 있다.
c. Software tool의 specification이 변경되지 않았다.
d. Malfunction 및 erroneous output이 systematic한 방법으로 과거의 개발 동안에 수집
되었다.
2. Evaluation of the tool development process
a. 적합한 국내의 또는 국제표준으로 assessment가 수행된 도구이고 development
process의 evaluation이 제공된다.
3. Validation of software tool
a. 소프트웨어 도구가 명시된 요구사항에 부합하는지를 보여주기 위한 validation
measures가 있다.
b. Malfunction이 분석되었고 이를 detect하거나 avoid하기 위한 방법을 제공한다.
c. Anomalous operating condition에 대한 software tool의 reaction이 검사되었다.
4. Development in accordance with a safety standard
a. ISO26262, IEC 61508, RTCA Do-178B의 표준을 따름

Tool qualification의 Confirmation Review
확인 수단 대 상
applies to ASIL
A B C D
확인 검토
(confirmation Review)
Safety analysis
- 아이템 개발자, 프로젝트 관리자, work product 작성자들과의 독립성
I1 I1 I2 I3
Software tool qualification report
- software tool의 qualification을 수행한 사람과의 독립성
- I0 I1 I1
PIU 후보의 proven in use argument
- argument의 작성자들과의 독립성
I0 I1 I2 I3
Safety case의 완벽성
- safety case 작성자와의 독립성
I0 I1 I2 I3
Software tool qualification의 Confirmation Review의 독립성 수준은 I1으로 낮은 편
이다. (팀 구성원이 Review할 수 있다)
Software tool qualification의 Confirmation Review의 요구 수준은 I1으로
Mandatory이다.

Question
e-mail: hong300@ktl.re.kr

ISO26262-6 Software development process (Ver 3.0)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (16)

Ähnlich wie ISO26262-6 Software development process (Ver 3.0)

Ähnlich wie ISO26262-6 Software development process (Ver 3.0) (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

ISO26262-6 Software development process (Ver 3.0)