ISO 26262: Vocabulary (Part 1), 기능안전 표준 용어 정리 (2018) - D

 

ISO 26262는 자동차 산업에서 널리 사용되는 기능 안전(Functional Safety) 국제 표준입니다. 이 표준은 전기 및 전자 시스템에서 발생할 수 있는 잠재적인 위험을 줄이고, 안전한 시스템 설계를 보장하는 것을 목표로 합니다. ISO 26262는 자동차 시스템 개발 과정에서 안전을 고려하는 일종의 지침서 역할을 하며, 차량의 복잡성이 증가하면서 더욱 중요해지고 있습니다.

이번 포스팅에서는 알파벳 순서에 따라 ISO 26262에서 정의하고 있는 용어를 살펴 보도록 하겠습니다.

---

목차

---

3.27 Dedicated Measure (전용 조치):

안전 목표(3.139) 위반 가능성 평가에서 제기된 고장율(3.53)을 보장하는 조치.

예시: 하드웨어 부품(3.71)의 과설계(예: 전기적 또는 열적 스트레스 등급) 또는 물리적 분리(예: 인쇄 회로 기판에서 접점 간의 간격); 안전 목표(3.139) 위반에 기여하는 고장 모드(3.51)의 발생 위험(3.128)을 줄이기 위한 특수 입고 재료 샘플 테스트; 번인 테스트; 전용 관리 계획.

전용 조치는 안전 목표 위반을 방지하기 위해 고장율을 낮추는 설계적 또는 관리적 조치를 의미합니다. 예를 들어, 하드웨어의 과설계나 특수 테스트 등이 포함됩니다.

 

3.28 Degradation (성능 저하):

아이템(3.84) 또는 엘리먼트(3.41)의 기능, 성능, 또는 두 가지 모두가 감소된 상태 또는 그 상태로의 전이.

성능 저하는 시스템이나 구성 요소의 기능이나 성능이 떨어지는 상태 또는 그 상태로 변화하는 과정을 의미합니다.

 

3.29 Dependent Failures (종속 고장):

통계적으로 독립적이지 않은 고장(3.50)으로, 즉, 고장들의 결합 발생 확률이 각각의 독립적인 고장 발생 확률의 곱과 같지 않은 경우.

참고 1: 종속 고장은 동시에 나타날 수 있으며, 또는 매우 짧은 시간 내에 나타나서 동시에 발생한 것처럼 작용할 수 있습니다.

참고 2: 종속 고장에는 공통 원인 고장(3.18)과 연쇄 고장(3.17)이 포함됩니다.

참고 3: 특정 고장이 연쇄 고장(3.17)인지 공통 원인 고장(3.18)인지는 엘리먼트(3.41)의 계층 구조에 따라 달라질 수 있습니다.

참고 4: 특정 고장이 연쇄 고장(3.17)인지 공통 원인 고장(3.18)인지는 엘리먼트(3.41)의 시간적 행동에 따라 달라질 수 있습니다.

참고 5: 종속 고장에는 고장 확률이 계산되지 않더라도 소프트웨어 고장(3.50)이 포함될 수 있습니다.

종속 고장은 시스템에서 고장들이 서로 독립적으로 발생하지 않고, 서로 영향을 주며 발생하는 고장을 의미합니다. 이러한 고장은 동시에 또는 짧은 시간 안에 발생하며, 공통 원인 고장이나 연쇄 고장을 포함할 수 있습니다.

 

3.30 Dependent Failure Initiator, DFI (종속 고장 유발자):

결합 요인(3.26)을 통해 여러 엘리먼트(3.41)가 고장 나게 하는 단일한 근본 원인.

참고 1: 결합 요인(3.26)은 종속성을 유발할 수 있는 후보로서 종속 고장 분석(DFA) 중에 식별됩니다.

참고 2: 엘리먼트(3.41)의 고장은 동시에 또는 순차적으로 발생할 수 있습니다.

예시 1:

• 결합 요인(3.26): 두 소프트웨어 유닛이 동일한 RAM을 사용함.

• 근본 원인: 하나의 소프트웨어 유닛이 의도치 않게 다른 소프트웨어 유닛이 사용하는 데이터를 손상시킴.

예시 2:

• 결합 요인(3.26): 두 ECU가 차량의 동일한 구획에서 작동함.

• 근본 원인: 해당 구획으로의 의도치 않은 물 유입으로 인해 홍수가 발생하고, 두 ECU가 고장 남.

예시 3:

• 결합 요인(3.26): 두 마이크로컨트롤러가 동일한 3.3V 전원 공급을 사용함.

• 근본 원인: 3.3V에 과전압이 발생하여 두 마이크로컨트롤러가 손상됨.

종속 고장 유발자(DFI)는 결합 요인에 의해 여러 시스템 요소들이 고장 나게 하는 단일한 근본 원인을 의미합니다. 이러한 고장은 동시에 발생할 수도 있고 순차적으로 발생할 수도 있습니다.

 

3.31 Detected Fault (감지된 고장):

안전 메커니즘(3.142)에 의해 정해진 시간 내에 그 존재가 감지된 고장(3.54).

참고 1: 정해진 시간은 고장 감지 시간 간격(3.55) 또는 다중점 고장 감지 시간 간격(3.98)일 수 있습니다.

감지된 고장은 시스템의 안전 메커니즘이 정해진 시간 내에 감지한 고장을 의미합니다. 이 시간은 고장 감지 간격이나 다중 고장 감지 간격일 수 있습니다.

 

3.32 Development Interface Agreement, DIA (개발 인터페이스 협약서):

고객과 공급자 간의 협약서로, 아이템(3.84) 또는 엘리먼트(3.41) 개발과 관련하여 각 당사자가 수행할 활동, 검토할 증거, 또는 교환할 작업 산출물(3.185)에 대한 책임이 명시된 문서.

참고 1: DIA는 개발 단계에 적용되며, 공급 계약서(Supply Agreement, 3.162)는 생산 단계에 적용됩니다.

개발 인터페이스 협약서(DIA)는 고객과 공급자가 개발 과정에서 각각의 책임과 교환할 작업 산출물을 명확히 규정한 공식 문서입니다.

 

3.33 Diagnostic Coverage, DC (진단 커버리지):

하드웨어 엘리먼트(3.41)의 고장율(3.53) 또는 하드웨어 엘리먼트(3.41)의 고장 모드(3.51)의 고장율 중, 구현된 안전 메커니즘(3.142)에 의해 감지되거나 제어되는 비율.

참고 1: 진단 커버리지는 하드웨어 엘리먼트(3.41)에서 발생할 수 있는 잔여 고장(3.125) 또는 잠재적 다중점 고장(3.97)과 관련하여 평가될 수 있습니다.

참고 2: 아키텍처(3.1)의 다양한 수준에서 구현된 안전 메커니즘(3.142)을 고려할 수 있습니다.

참고 3: 특별히 명시되지 않는 한, 안전 관련 하드웨어 엘리먼트(3.41)의 안전 고장(3.130) 비율은 안전 메커니즘(3.142)의 진단 커버리지를 결정할 때 고려되지 않습니다.

진단 커버리지는 하드웨어의 고장이나 고장 모드 중에서 안전 메커니즘이 얼마나 많은 고장을 감지하거나 제어할 수 있는지를 비율로 나타낸 것입니다. 안전성을 보장하기 위해 중요한 요소입니다.

 

3.34 Diagnostic Points (진단 포인트):

엘리먼트(3.41)의 출력 신호로, 고장(3.54)의 감지 또는 수정이 관찰되는 지점.

참고 1: 진단 포인트는 “경고(alarms)”, “오류 플래그(error flags)” 또는 “수정 플래그(correction flags)“라고도 불립니다.

예시: 피드백 정보.

진단 포인트는 시스템에서 고장 감지나 수정이 이루어지는 특정 출력 신호 지점을 의미하며, 종종 경고나 오류 플래그로 나타납니다.

 

3.35 Diagnostic Test Time Interval (진단 테스트 시간 간격):

안전 메커니즘(3.142)에 의해 온라인 진단 테스트가 실행되는 사이의 시간, 온라인 진단 테스트 실행 기간을 포함함.

참고 1: 그림 5를 참조하세요.

진단 테스트 시간 간격은 온라인 진단 테스트가 반복 실행되는 사이의 시간을 의미하며, 테스트가 실행되는 시간을 포함합니다.

 

3.36 Distributed Development (분산 개발):

아이템(3.84) 또는 엘리먼트(3.41)의 개발 책임이 고객과 공급자 사이에서 나누어져 전체 아이템 또는 엘리먼트를 개발하는 방식.

참고 1: 고객과 공급자는 협력 당사자의 역할을 나타냅니다.

분산 개발은 고객과 공급자가 각각의 역할을 나누어 시스템이나 구성 요소를 공동으로 개발하는 방식을 의미합니다.

 

3.37 Diversity (다양성):

동일한 요구 사항을 충족시키는 서로 다른 해결책으로, 독립성(3.78)을 달성하는 것을 목표로 함.

참고 1: 다양성은 독립성(3.78)을 보장하지 않지만, 특정 유형의 공통 원인 고장(3.18)을 처리할 수 있습니다.

참고 2: 다양성은 기술적 해결책(예: 다양한 하드웨어 컴포넌트(3.21), 다양한 소프트웨어 컴포넌트(3.21)) 또는 기술적 수단(예: 다양한 컴파일러)을 적용하는 것을 의미할 수 있습니다.

참고 3: 다양성은 중복성(3.122)을 실현하는 한 가지 방법입니다.

예시: 다양한 프로그래밍 방법; 다양한 하드웨어.

다양성(Diversity)은 동일한 요구 사항을 충족하기 위해 서로 다른 접근 방식을 사용하는 것으로, 시스템의 독립성을 높이고, 특정 고장 위험을 줄이는 방법 중 하나입니다.

 

3.38 Dual-Point Failure (이중점 고장):

두 개의 독립적인 하드웨어 고장(3.54)이 결합되어 안전 목표(3.139) 위반을 직접적으로 초래하는 고장(3.50).

참고 1: 이중점 고장은 다중점 고장(3.96)의 2차 순서에 해당합니다.

참고 2: ISO 26262 표준에서 다루는 이중점 고장에는, 하나의 고장이 안전 관련 엘리먼트(3.144)에 영향을 미치고, 다른 고장이 안전 상태(3.131)를 달성하거나 유지하기 위한 안전 메커니즘(3.142)에 영향을 미치는 경우가 포함됩니다.

이중점 고장(Dual-Point Failure)은 두 개의 독립적인 하드웨어 고장이 결합되어 시스템의 안전 목표를 위반하게 되는 고장으로, ISO 26262에서 중요한 다중 고장 중 하나입니다.

 

3.39 Dual-Point Fault (이중점 결함):

다른 독립적인 결함(3.54)과 결합하여 이중점 고장(3.38)을 초래하는 개별 결함(3.54).

참고 1: 이중점 결함은 이중점 고장(3.38)이 식별된 후에만 인식될 수 있으며, 예를 들어 고장 수 분석에서 확인될 수 있습니다.

참고 2: 다중점 결함(3.97)도 참조하세요.

이중점 결함(Dual-Point Fault)은 다른 독립적인 결함과 함께 발생하여 시스템의 이중점 고장을 일으키는 개별 결함을 의미합니다.