ISO 26262 정리

Part 2 Management of functional safety

- 안전 수명 주기(Safety life cycle)에 대한 설명

- 안전 문화에 대한 설명

- 인원의 적격성 및 자격인정 기준

- 프로젝트 관리자와 안전 관리자

- 안전 계획서

- 안전 활동 조정 ( 아이템 신규 개발, 개선 변경)

- Safety case

- Confirmation measure

- Verification review

- 양산 이후 안전 경영 ( Safety management)

Part 3 Concept phase

- item definition

- Initiation of the safety life cycle ( 신규 아이템 or 개선 아이템)

- 영향 분석

-  Hazard analysis and risk assessment

- Functional Safety Concept

Part 4 Product development at the system level

- Initiation of product development at the system level

- Technical safety requirements

- System design : HSI 등

- item integration and testing

- safety validation : 안전 타당성 확인

- functional safety assessment

- release for production

Part 5 Product development at the hardware level

- Initiation of product development at the hardware level : 하드웨어 제품 개발 과정

- Specification of hardware safety requirement : 하드웨어 요구사항 도출 과정 및 고려 사항

- Hardware design : 하드웨어 아키텍처 설계시 고려 사항

- Evaluation of the hardware architectural metrics : 결함 계산 방법 및 평가 방법

- Evaluation of safety goal violation due to random hardware failures : 안전 목표 훼손 평가 방법

- Hardware integration and testing : 하드웨어 통합 및 테스트 방법

Part 6 Product development at the software level

- Initiation of product development at the software level : 소프트웨어 제품 개발 과정

- Specification of software safety requirement : 소프트웨어 안전 요구사항

- Software architectural design : 아키텍처 설계 시 고려사항

- Software unit design and implementation : 유닛 설계 구현시 고려사항

- Software unit testing : 유닛 테스팅 방법

- Software integration and testing : 소프트웨어 통합 및 시험에 관한 고려사항

- Verification of software safety requirements : 검증 시 고려 사항

- Software configuration : 소프트웨어 형상에 대한 고려사항

- Freedom from interference between software elements : 엘리멘트 간 상호 간섭 최소화에 대한 것

Part 7 Production and operation

- Production : 생산 기획, 생산 공정, 생산 계획, 선행 생산 등등

- Operation, service(maintenance and repair), and decommissioning : 운전, 서비스(보전 및 수리),폐기 계획

Part 8 Supporting processes

- interfaces within distributed developments :협력 개발 인터페이스 관련 사항, RFQ

- Specification and management of safety requirements : 안전 요구사항

- Configuration management    : 형상 관리

- Change management : 변경 관리

- Verification : 검증( 각 단계에서의 검증에 대한 설명)

- Documentation : 문서화 목적, 문서화 범위

- Confidence in the use of software tools : 소프트웨어 사용 신뢰(TI , TD -> TCL 결정)

- Qualification of software component : 재개발을 피하기 위한 자격 인증 요구사항

- Qualification of hardware component : 재사용을 위한 요구사항

- Proven in use argument : 사용으로 입증된 주장 , candidate, 필드 데이터

Part 9 ASIL-oriented and safety-oriented analyses

- Requirements decomposition with respect to ASIL tailoring : ASIL decomposition,

- Criteria for coexistence of element : 간섭 부재 미증명시 가장 높은 ASIL 지정

- Analysis of dependent failures : 발생 가능성이 동시 혹은 연속의 경우에 대한 고장 분석 요구사항

- Safety analyses : 안전 분석의 목적 및 방법

PART 1

---

1-2 기능 안전성과 ASIL

---

1. 기능 안전성( Functional Safety)

- Absence of unreasonable risk due to hazards caused by mulfunctioning behaviour of E/E systems

-  전장 시스템 오작동으로 인한 위험원으로부터 비합리적인 리스크가 없는 상태

2. Hazard analysis and risk assessment (H&R)

- method to identify and categorize hazardous events of items and to specify safety goals and ASILs related to the prevention or mitigation of the associated hazards in order to avoid unreasonable risk

- item의 위험 사건을 식별하고 분류하는 방법 및 불합리한 리스크를 방지하기 위해 관련된 위험원의 예방 또는 완화와 관련하여 안전 목표와 ASILs을 명세하는 방법

3. Automotive Safety Intergrity Level(ASIL)

- one of four levels to specify the item's or element's necessary requirments of ISO-26262 and safety measures to apply for avoiding an unreasonable residual risk, with D representing the most stringent and A the least stringent level

- ASIL은 item 혹은 element에 요구되는 불합리한 잔류 위험을 피하기 위한 안전대책에 대한 등급으로서  ISO 26262에서는 4개의 등급이 있으며, A가 가장 낮고, D가 가장 높음

- Item 정의로부터 차량 수준의 위험원 분석 및 리스크 평가( H&R) 를 통해 Item의 작동 불량으로 인한 피해의 심각성(Severity), 발생 가능성(Exposure), 통제 가능성 ( Controllability)에 의거 등급을 결정하며, 이를 ASIL이라고 함

- ASIL 등급 결정 방법은 Part 3에 명시되어 있음

---

1-3 기능 안전성과 관련 표준

---

- IEC 61508 : 기능 안전의 모(母) 표준이며, 이를 근거로 산업별 기능 안전 표준으로 발전

<발췌 : ISO26262 기본 실무 가이드, 저자 김병철, 김성수, 조진희> 

CMMI (Capability and Maturity Model Integration) : 프로세스 능력과 성숙도를 측정하고 개선하는 방법으로서 프로세스 개선 기반, 목표 중심의 프레임워크이며, L0부터 L5까지 능력 및 성숙도 수준이 있음

CMMI and ASPICE : 기본저으로 '조직'의 프로세스 성숙도를 측정하고 심사하는 모델로서 고품질의 제품을 공급하기 위해 필요한 지속적이고 체계적인 프로세스 개선을 이루기 위한 전반적인 틀을 제공

-ISO 26262는 자동차 분야 전기전자 시스템의 본래 기능 뿐 아니라 관련된 안전 요구사항을 충족하여 개발 및 공급될 수 있도록 하기 위한 체계적인 방법 및 절차에 대한 요구사항을 정의하고 있음

RAMS (Reliability, Availability, Maintainability, Safety) : 

---

1-5 ISO 26262 추진 방안

---

1단계 : 계획 수립 - 표준 도입 목적 정의, 갭 분석, 조직 결성 및 활동 계획 수립, 경영층의 지원 확인 및 도입 프로젝트 착수

2단계 : 개선 단계 - 현 프로세스 개선, 템플릿 및 체크리스트 준비, 프로세스 요소 정의, 집중 교육/컨설팅, 전문가 양성, 절차-기준-규칙 준비, 중간 성취도 평가, 사내 품질경영시스템/안전경영시스템의 개선

3단계 : 전사 보급 단계 - 프로젝트에 개선 프로세스 도입, 안전 전문가 조직체계 구성, 점진적으로 적용, 적합성 평가

4단계 : 내재화 단계 - 프로세스 지속 개선을 위한 전문팀 보유, 사업 영역 변화 및 고객 요청에 대응하여 프로세스 개선, 정기적으로 성숙도 확인을 위한 평가 수행

---

1-6 ISO 26262 개요

---

ISO26262 적용 범위 

1) 3,500Kg 이하의 승객용 차량에 설치되는 하나 이상의 E/E(전기 전자) 시스템을 포함하는 안전 관련 시스템

2) 직접적인 전기/전자 안전 관련 시스템의 작동 불량 원인이 되지 않는다면, 전기충격, 화재, 연기, 열, 방사능, 유독성, 가연성 화학적 반응, 부식, 에너지 유출 및 유사 잠재 위험에는 적용하지 않음

3) 전기/전자 시스템을 위한 기능 성능 표준이 있다 하여도 전기/전자 시스템의 명목상의 성능에는 적용하지 않음

4) 표준 발표 이전에 개발된 차량은 적용 제외, 하지만 ISO 26262 표준 제정후 개발된 차량은 적용 대상

ISO 26262 표준 공식 명칭 : Road vehicle - Functional Safety

<ISO 26262 전체 구성도>

Table에서 0, +, ++ 의미

1) 0 : 적용하지 않아도 됨

2) + : recommendation(추천) 의미지만, 권고 사항이 아닌 의무 사항으로 해석해야 함 (Should : 합리적인 방법론이 있다면 다르게 수행해도 됨)

3) ++ : High recommendation(적극 추천) 의미지만, 권고 사항이 아닌 의무 사항으로 해석해야 함 (Shall : 강제 요구사항(mandatory)

1-7 용어

1) system

- set of elements that relates at least a sensor, cotroller, and actuator with one other

- 적어도 하나 이상의 센서, 제어기, 엑추에이터가 연결된 element의 조합

- 센서와 엑추에이터는 시스템 내부 혹은 외부에 있어도 가능하며, 시스템의 요소가 다른 시스템이 될 수도 있음

- 시스템은 아이템에 포함됨

2) Item

- system or array of systems to implement a function at the vehicle level, to which ISO 26262 is applied

- ISO 26262 적용 대상으로 차량 레벨에서 기능이 수행되는 시스템 혹은 시스템 Array

3) Element

- system or part of a system including componets, hardware, software, hardware part, and software units

- 시스템 혹은, 컴포넌트, 하드웨어, 소프트웨어. 하드웨어 파트, 소프트웨어 유닛을 포함하는 시스템의 파트

4) Component

- non-system level element that is logically and technically separable and is comprised of more than one hardware part or one or more software units

- 논리적 및 기술적으로 분리된 시스템 레벨이 아닌 element이고 두개 이상의 하드웨어 파트 혹은 하나 이상의 소프트웨어 유닛으로 구성된다.

5) Hardware part

- hardware which cannot be subdivided

- 더 이상 나눌 수 없는 하드웨어

6) Software component

- one or more software units

- 하나 혹은 그 이상의 소프트웨어 유닛

7) software unit

- atomic level software component of the software architecture that can be subjected to standalone testing

- 독자적으로 테스팅이 가능하며, 더 이상 분류할 수 없는 소프트웨어 아키텍처의 소프트웨어 컴포넌트

8) Harm

- physical injury or damage to health of person

- 사람에게 발생한 물리적인 상해 혹은 피해

9) Hazard

- Potential source of harm caused by malfunctioning behavior of the item

- 아이템의 오작동으로 인해 위해의 잠재적 원인 제공원

10) Risk

- combination of the probability of occurrence of harm and the severity of that harm

- 위해의 심각성 및 발생 가능성(확률)의 조합

- harm의 정의에 의해 사람에게 발생할 수 있는 위해만 고려함

11) Fault

- abnormal condition that can cause an element or an item to fail

- element 혹은 item에 이상을 일으키는 비정상적인 조건

12) Error

- discrepancy between a computed, observed or measured value or condition, and the true, specified, or theoretically correct value or condition

- 계산된, 관찰된 혹은 측정된 값이나 조건과 실제, 규정된 혹은 이론적으로 정확한 값이나 조건 사이의 편차(차이)

13) Failure

- termination of the ability of an element, to perform a function as required

- 요구되는 기능을 수행하기 위한 element 능력의 종료

14) Phase

- the safety lifecycle that is specified in a distinct part of ISO 26262

15) Subphase

- subdivision of a stage in the safety lifecycle the is specified in a distinct clause of ISO 26262

16) Work product

- result of one or more associated requirements of ISO 26262

- ISO 26262의 하나 이상 관련된 요구사항의 결과

17) Safety activity

- activity performed in one or more subphases of the safety lifecycle

- 안전 수명 주기의 하나 이상의 subphase에서 수행된 활동

18) Safety culture

- policy and strategy used within an organization to support the development, production, and operation of safety-related systems

19) Safety manager

- role filled by the person responsible for the functional safety management during the item development

20) Safety plan

- plan to manage and guide the execution of the safety activities of a project including dates, milestones, tasks, deliverables, responsibilities and resources

- 날짜, 이정표, 과업, 상품, 책임 및 자원을 포함한 프로젝트의 안전 활동 실행을 관리하고 안내하기 위한 계획서

21) Safety Case

- argument that the safety requirements for an item are complete and satisfied by evidence compiled from work products of the safety activities during development

- 개발 중에 안전 활동의 산출물을 점진적으로 개발한 증거에 의해 아이템의 안전 요구사항이 완전하고 만족되었다는 주장

22) confirmation measure

- confirmation review, audit, or assessment concerning functional safety

23) Functional concept

- specification of the intended functions and their interactions necessary to achieve the desired behaviour

- 의도된 기능 및 희항하는 행위를 달성하기 위해 필요로하는 상호작용의 명세

24) functional safety concept

- specification of the functional safety requirements, with associated information, their allocation to architectural elements, and their interaction necessary to achieve the safety goal

- 관련된 정보, 아키텍처 엘리멘트에 할당 및 안전 목표 달성에 필요한 상호작용을 가진 기능 안전성 요구사항의 명세(시방)

25) functional safety requirement

- specification of implementation-independent safety behaviour, or implementation-independent safety measure, including its safety-related attributes

- 안전 관련 속성을 포함하여 독립적으로 실행되는 행위 혹은 독립적으로 실행되는 안전 대책의 명세

26) 안전 메커니즘 (Safety mechanisms)

- technical solution implemented by E/E functions or elements, or by other technologies, to detect faults or control failures in order to achieve or maintain a safe state

- 안전한 상태를 달성하거나 유지하기 위해 결함을 감지하고 고장을 제어하기 위한 E/E 기능이나 엘리멘트에 의해 또는 기타 기술에 의해 구현된 기술적 해결

27) Safety goal

- top-level safety requirement as a result of the hazard analysis and risk assessment

- 위험원 분석 및 리스크 평가 결과로 최상위 수준의 안전 요구 사항

28) Safe state

- operating mode of an item without an unreasonable level of risk

- 불합리한 수준의 리스크가 없는 아이템의 가동 상태

29) redundancy

- existence of means in addition to the means that would be sufficient for an element to perform a required function or to represent information

- 엘리멘트가 요구된 기능을 수행하거나 정보를 표시하는 충분한 방법에 추가한 수단의 존재

30) warning and degradation concept

- specification of how to alert the driver of potentially reduced functionality and of how to provide this reduced functionality to reach a safe state

31) technical safety concept

- specification of the technical safety requirements and their allocation to system elements for implementation by the system design

- 기술적 안전 요구사항의 명세이며, 시스템 설계에 의한 구현을 위해, 시스템 엘리멘트에 할당한 명세

32) technical safety requirement

- requirement derived for implementation of associated functional safety requirements

- 관련된 기능 안전 요구사항의 구현을 위해, 도출된 요구사항

중요한 용어

Development interface agreement(DIA) : 협력 개발 협약서

Redundancy : 다중화

Safety case : 기능안전을 준수하며, 안전하게 설계했다는 요약본, 법원 제출용, 고객 제출용, 우주 항공의 경우 300~350페이지로 만듬

diversity : 다양하게 설계하라

diagnostic coverage : 진단 범위

candidate : 재사용을 위해 검증을 요청하는 아이템 또는 엘리멘트

proven in use : 필드 데이터를 기반으로 사용을 통한 입증 

single point fault

FMEA(FMECA) : Failure modes effect critical analysis

FMEDA : Failure modes, Effects, and Diagnostic Analysis

FTA : Fault Tree Analysis

PMHA : Probabilistic Metric for random Hardware Failures

ETA : Event Tree Analysis

- Confirmation measure

- review

- audit

- assessment

PART 2

 

안전 수명 주기에서 표현된 subphase 내용 정리

a) Item definition

- 안전 수명 주기의 최초 과업으로 개발하고자 하는 아이템에 관련한 기능성, 인터페이스, 환경 조건, 법적 요구사항, 알려진 위험원(Hazard) 등에 관한 설명을 정의

- 아이템의 경계(boundary)와 인터페이스뿐만 아니라 다른 아이템, 엘레멘트, 시스템 및 컴포넌트에 관련한 가정(assumption)도 결정

b) 안전 수명 주기 착수(Initiation of the safety lifecycle)

- 아이템 정의를 기반으로, 신규 개발인지, 혹은 기존 아이템의 개선인지 구별하여, 안전 수명 주기를 초기화

- 기존 아이템 개선(modification)의 경우, 영향 분석(impact analysis)의 결과가 안전 수명 주기의 조정(tailoring)에 사용됨

c) 위험원 분석 및 리스크 평가 ( Hazard analysis and risk assessment)

- 안전 수명 주기 초기화 이후, H&R 수행

- H&R은 아이템에 관련한 위험스러운 사건에서 노출 가능성( probability of exposure), 통제 가능성(controllability) 및 심각성(severity)를 평가

- 위험스러운 사건(hazardous event)의 이러한 변수들로 ASIL 결정

- Item을 위한 최상위 레벨의 안전 요구사항에 관련된 아이템의 안전 목표(safety goal)를 결정

- 위험스러운 사건을 위해 결정된 ASIL은 상응하는 안전 목표에 지정

- 후속되는 phase와 subphase를 진행하는 동안 상세화된 안전 요구사항은 안전 목표로부터 도출

- 안전 요구사항은 상응하는 안전 목표의 ASIL와 연계

d) 기능 안전성 개념( Functional Safety Concept)

- 안전 목표를 기반으로, 기능 안전성 개념이 초기 아키넥처 가정(preliminary architectural assumption)을 고려하여 명시

- 아이템의 엘리멘트에 할당된 기능 안전성 요구사항에 의해 명시

- 기타 기술(other technology) 혹은 외부 대책(external measure)과의 인터페이스 포함

- 기대되는 작동의 타당성 확인

- 기타 기술 구현은 ISO26262의 적용 범위에 제외되며, 외부 대책의 구현은 아이템 개발의 범위에 속하지 않음

e) 시스템 레벨에서 제품 개발(product development at the system level)

- 기능 안전성 개념 획득 후, 아이템은 system 레벨 관점으로 개발됨

- 시스템 개발 프로세스는 기술적 안전 요구사항 시방, 시스템 아키텍처, 시스템 설계 및 구현, 통합, 검증, 타당성 확인 및 기능 안전성 평가의 시방을 가진 V- Model 개념을 기반으로 수행

- 하드웨어-소프트웨어 인터페이스(HSI)는 이 단계에서 명시

- 기타 기술에 의해 수행된 기능 안전성 개념 측면에서의 타당성 확인

- 외부 대책 효과 성과에 관련한 가정의 타당성 확인

- 통제 가능성과 운전 과업( Operational task)을 포함하여 인간의 반응에 관련한 가정의 타당성 확인

f) 하드웨어 레벨에서 제품 개발 ( product development at the hardware level)

- 시스템 설계 시방을 기반으로 아이템은 하드웨어 레벨의 관점으로부터 개발됨

- 하드웨어 개발 프로세스는 하드웨어 요구사항 시방과 설계 및 구현, 통합, 시험을 가진 V-model 개념을 기반으로 수행

g) 소프트웨어 레벨에서 제품 개발(product development at the software level)

- 시스템 설계 시방을 기반으로 아이템은 소프트웨어 레벨의 관점으로 개발

- 소프트웨어 개발 프로세스는 소프트웨어 요구사항 시방, 아키텍쳐 설계 및 구현, 통합, 시험 검증을 가진 V-model 개념을 기반으로 수행

h) 생산 기획 및 운전 기획 (production planning and operation planning)

- 생산과 운전을 위한 기획, 관련된 요구사항의 시방은 시스템 레벨에서의 제품 개발 중 시작됨

i) 생산과 운전, 서비스 및 폐기(production and operation, service and decommissioning)

- 이 단계는 아이템의 기능 안전성 목표, 즉 안전 관련 특별 특성을 위한 적절한 생상 프로세스, 양산 이후 기능 안전성 보장을 위한 아이템의 보전, 수리 및 폐기에 대해 다룸

j) 통제 가능성 (controllability)

- 위험원 분석 및 리스크 평가에서 위험 상황을 관리하기 위하여 리스크에서 운전자 혹은 보행자의 능력에 대한 평가를 수행

- H&R 그리고 기능 및 기술적 안전 개념에서 통제 가능성 관련한 가정은 안전 타당성 확인시 타당성 확인됨

k) 외부 대책 (external measure)

- 외부 대책은 '아이템으로부터 발생된 리스크를 감소시키거나, 완화하는 아이템 외부의 대책'임

- dynamic stability controller 혹은 run-flat tyres와 같은 자동차 내의 추가 장치 뿐만 아니라, crash barriers 혹은 tunnel fire-fighting system과 같은 자동차 외부 장치를 포함

- 아이템 정의, H&R 그리고, 기능 및 기술적 안전 개념에서 외부 대책에 관련한 가정은 타당성 확인 시 확인됨

- 외부 대책은 H&R에서 고려됨

- 만약 H&R에서 외부 대책이 활용 되었다면, 이러한 외부 대책은 기능 안전성 개념에서 하나의 리스크 감소 대책으로 고려될 수 없음

- ISO26262의 범위내에 있는 외부 대책(예,전기전자 시스템)은 ISO 26262가 적용됨

i) 기타 기술(other technology)

- 기타 기술은 기계 및 유압 기술과 같이 ISO 26262 적용 범위인 전기/전자 기술과는 다른 기술을 말함

- 기타 기술은 안전 요구사항 할당(concept phase 및 product development at system level)시 기능 안전성 개념의 시방으로 혹은 외부 대책으로 고려될 수 있음

j) 조정(tailoring)

- 조정은 다음과 같은 경우에 수행

1)  subphase, 활동(activity) 혹은 과업(task)의 병합 및 분리

2) 다른 phase 혹은 subphase에서 활동 혹은 과업의 수행

3) 추가된 phase 혹은 subphase에서 활동 혹은 과업의 수행

4) phase 혹 subphase에서 또는 내부에서 반복

- 안전 관리자(Safety Manager)의 역할

- 기능 안전성 활동 기획, 코디네이션 

- 안전 계획서 유지 및 계획서에 따른 안전 활동의 진행 사항 모니터링

- 안전 활동의 기획과 코디네이션 책임은 다음 사항을 포함

1) ISO26262-4에 따라 아이템 통합과 시험

2) ISO26262-4에 따라 타당성 확인 계획

3) ISO26262-6에 따라 소프트웨어 검증 계획

4) 기능 안전성 평가 계획

- Safety argument의 일반적 형태

1) 제품 논거 ( product argument) : 구현된 제품의 특징(즉 시간적으로 관찰된 행위)에 직접 거론하여 안전을 논의한 안전 논거

2) 프로세스 논거( process argument) : 개발 및 평가 프로세스의 특징(즉 적용된 설계 표기법)을 거론하여 안전을 논의한 안전 논거

- Safety Case 개발 수명 주기

1) 초기 safety case 보고서 ( preliminary safety case report ) : 아이템 정의 및 시스템 요구사항 명세서 검토 후 작성

2) 중간 safety case 보고서 ( interim safety case report) : 초기 시스템 설계 및 초기 타당성 확인 활동 후 작성

3) 작동(운전) 전 safety case 보고서(pre-operational safety case report) : 시스템 요구사항을 충족하도록 구현되었다는 증거를 포함하여 제품 서비스 이전 단계에서 작성

- Safety Case 유지

- safety case 논거는 시스템이 널리 사용되어 문제가 발생하기 이전에 구축되고 설명됨

- 이러한 safety case는 관찰된 증거보다는 시스템과 운전 행위의 평가 및 예측에 기초

- Safety case 검토 및 승인

- 완전성 평가는 논거의 적절성, 범위 및 무결성, 그리고 현존하는 증거를 고려

- 잼재적으로 기존의 논거를 저해하거나 반박할 수 있는 반대 증거가 있다면, 기존 논거에 대한 검토가 필요

- 연역적 분석(가정->실험)의 증거에 기초한 논거는 귀납적 논거(사실->결론)에 기초한 논거보다 종종 무리한 것으로 여겨짐

- 프로세스 논거에만 기초한 Safety case는 제품 논거보다 약한 것으로 간주

- Confirmation measure

- Review 

- confirmation that a work product meets the requirements of ISO 26262 with the required level of independence of the reviewer

- ISO26262의 상응하는 요구사항에 대하여 선택된 산출물의 적합성을 확인

- Audit

- examination of an implemented process

- 기능 안전성 심사는 기능 안전성 활동을 위하여 요구된 프로세스의 준수성을 평가

- 산출물, 기능 안전 프로세스 및 구현된 안전 대책의 효과성과 적설성에 대해 검토

- Assessment

- examination of a characteristic of an item or element

- 기능 안전성 평가는 아이템에 의해 달성되는 기능 안전성을 평가

- Verification Review

- work product가 프로젝트 요구사항, 사례 및 고장 형태 사용에 관한 기술적 요구사항을 충족하는지를 검증

- I0 : Confirmation measure 수행되어야함. 그러나 만일 수행된다면, 다른 인원에 의해 수행되어야함

- I1 : 다른 인원에 의해 반드시 수행되어야 함

- I2 : 동일 팀 직접적인 상사에 보고되지 않는 다른 팀원에 의해 수행되어야 함

- I3 : 경영, 자원 및 양산의 권한 관련하여 고려된 산출물에 책임있는 부서와 독립된 다른 부서 혹은 다른 조직 인원에 의해 수행되어야 함

PART 3

 - Item Definition

- 아이템과 환경 사이의 의존성뿐만 아니라 아이템의 기능 및 성능이나 시간 제약 등의 비기능 요구사항은 문서화 되어야하며, 아래 정보가 포함되어야 한다.

1) 운전 상태와 아이템의 동작상태를 포함한 목적과 기능성

2) 운전과 환경의 제약사항

3) 법적 요구사항(법과 규정), 알려진 경우 해당 국가 및 국제 표준

4) 유사 기능, 아이템 및 엘리멘트에 의해 달성된 행위

5) 아이템 정의 기술시 가정하는 사항들( 다른 아이템과의 연관성)

6) 과거 경험(알려진 고장 형태, 위험원 및 잠재적 결과)

- 기능적 요구사항 ( Functional requirements)

- 고객 요구사항에 수행될 기능과 관련되어 있는 입력과 출력 및 그들 사이의 처리 과정이나 목표로 하는 제품의 구현을 위해 시스템, 하드웨어, 소프트웨어 등이 가져야 하는 기능적 속성

- 비기능적 요구사항 ( non-Functional requirements)

- 제품의 품질 기준 등을 만족시키기 위해 시스템, 하드웨어, 소프트웨어 등이 가져야하는 성능(응답시간. 처리량 등) 사용의 용이성, 신뢰도, 보안성, 운용상의 제약, 안전성, 유지 보수성 등과 같은 행위적 특성

- Initiation of the safety lifecycle ( 안전 수명 주기의 착수)

1. 신규 개발 아이템의 경우, 위험원 분석 및 리스크 평가가 수행되고 ISO26262의 모든 활동이 적용됨

2. 기존 아이템 혹은 환경의 개선품인 경우, 적용할 수 있는 안전 수명 주기의 subphase와 활동이 Impact analysis and tailored safety lifecycle in the case of modification(개선 변경의 경우, 영향 분석과 조정된 안전 수명 주기)에 따라 결정됨

- Impact Analysis (영향 분석)

- 아이템 혹은 환경에 적용되는 의도된 개선 변경을 식별 및 설명하고 이러한 개선 변겨으이 영향을 평가하기 위해 수행

a) 조작 상황 및 운전 형태

b) 환경과의 인터페이스

c) 자동차, 자동차 구성 및 변형 내에서 위치 및 설치의 특성

d) 온도, 고도, 습도, 진동, 전자파 및 연료 등급과 같은 환경 조건 범위

- 개선 변경의 경우 수행되어야 할 사항

- 기능 안전성에 관한 개선 변경 영향 식별 및 설명

- 갱신이 필요한 관련된 산출물 식별 및 설명

- 안전 활동은 적용할 수 있는 수명 주기 단계에 따라 조정

- 조정은 영향 분석 결과를 기초로 해야함

- 조정의 결과는 안전계획서에 포함되어야함

- 관련된 산출물은 재작업

- Hazard Analysis and risk assessment

- 수행 시기 

- 아이템이 정해지고, 고객으로부터 개발 협약서(DIA)와 계약이 완료된 이후에 신규 혹은 개선품인지 여부를 판별하여 신규개발품에 해당될 경우 개발 아이템을 명확히 정의한 후에 H&R를 실시

- 필요에 따라서 개발 중에 개발 아이템의 설계 변경 사항이 생기거나, 추가 보완 사항이 있을 시 마다 실시

- 상황 분석(Situation analysis)와 위험원 식별(Hazard identification)

- 내부에 안전 메카니즘이 없는 것으로 가정하고 아이템은 위험원 분석과 리스크 평가 중에 평가되어야 함

- 이미 수행된 안전 메카니즘은 위험원 분석과 리스크 평가에서 고려되어서는 안됨

- 올바른 조작 상황과 예측 가능한 올바르지 않는 조작상황 모두 포함

- 위험원은 적절한 기법을 사용하여 시스템적으로 결정되어야 함

- 위험은 자동차 레벨에서 관찰 되어질 수 있는 조건 및 행위의 용어로 정의되어야 함

- 위험스러운 사건은 조작 상황과 위험원의 적절한 조합을 위해 결정되어야 함

- 위험스러운 사건의 결과는 식별되어야 함

- 안전 메커니즘

- 아이템을 안전 상태로 전환되도록 하거나, 안전 상태로 유지하도록 하거나

- 기능 안전성 개념에서 정의된대로 운전자가 고장의 효과를 제어하도록 기대한 것과 같이 운전자에게 경고할 수 있음

- 안전 메커니즘의 범위를 일반적으로 Diagnostic Coverage(DC, 진단 커버리지)라 함

- 기능 안전성 개념 ( Functional Safety Concept)

- 결함 감지 및 고장 완효

- 안전 상태로의 전이

- 직접적으로 안전 목표 훼손을 야기하지 않는 결함과 아이템을 안전 상태로 유지하는 fault tolerance mechanism

- 수용 가능한 시간 간격으로 리스크 노출 시간을 감소하기 위한 결함 감지 및 운전자 경고

- 다른 기능에 의해 동시 다발적으로 발생하는 많은 요청으로부터 가장 적절한 제어를 선택하기 위한 조정 논리

- 기능 안전성 요구사항

- 기능 안전성 요구사항은 적용 가능한 경우 다음을 고려하여 명시해야 함

1) 운전 형태

2) 결함 허용 시간 간격

3) 안전 상태

4) 비상 운전 간격

5) redundancy 기능

- 안전 상태가 허용 가능한 시간 간격 이내에 전이되어 도달할 수 없다면, 비상 운전은 명시되어야 함

- 경고와 성능 저하 개념( warning and degradation concept)은 명시되어야 함