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

 

기능안전 표준인 ISO 26262에서 사용되는 용어가 참 많아요.

그래도 정확한 내용을 알아야 잘 활용할 수 있겠죠?

이번에는 F로 시작하는 기능안전 용어를 알아 볼게요.

 

 

 

 

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

 

목차

---

3.50 Failure (고장)

엘리먼트(3.41) 또는 아이템(3.84)의 의도된 동작이 결함(3.54)으로 인해 종료되는 것

참고 1: 종료는 영구적일 수도 있고 일시적일 수도 있습니다.

엘리먼트나 아이템이 결함 때문에 제대로 작동하지 않아서 멈추는 걸 고장이라고 해요. 이 고장은 영구적일 수도 있고, 잠깐일 수도 있어요.

3.51 Failure Mode (고장 모드)

엘리먼트(3.41) 또는 아이템(3.84)이 의도된 동작을 제공하지 못하는 방식

엘리먼트나 아이템이 고장 나서 제대로 작동하지 못하는 방식을 고장 모드라고 해요.

3.52 Failure Mode Coverage (FMC, 고장 모드 커버리지)

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

하드웨어 엘리먼트의 고장 모드 중에서, 안전 메커니즘이 감지하거나 제어할 수 있는 고장의 비율을 고장 모드 커버리지라고 해요.

3.53 Failure Rate (고장률)

하드웨어 엘리먼트(3.41)의 생존 확률로 고장(3.50)의 확률 밀도를 나눈 값

참고 1: 고장률은 일정하다고 가정되며 일반적으로 “λ”로 표시됩니다.

고장률은 하드웨어 엘리먼트가 고장 날 확률을 고장 나지 않을 확률로 나눈 값이에요. 보통 이 값은 일정하다고 보고, “λ”로 나타내요.

3.54 Fault (결함)

엘리먼트(3.41) 또는 아이템(3.84)이 고장 나게 할 수 있는 비정상적인 상태

참고 1: 영구적, 간헐적, 일시적인 결함(3.173) (특히 소프트 에러)이 고려됩니다.

참고 2: 서브시스템이 오류(3.46) 상태에 있을 때, 시스템(3.163)에 결함을 일으킬 수 있습니다.

참고 3: 간헐적인 결함은 가끔 발생했다가 사라지는 경우입니다. 이 유형의 결함은 컴포넌트(3.21)이 고장 직전이거나, 예를 들어 스위치 내부의 오작동 때문에 발생할 수 있습니다. 일부 시스템 결함(3.165) (예: 타이밍 불규칙성)이 간헐적인 결함으로 이어질 수 있습니다.

결함은 엘리먼트나 아이템이 고장 날 수 있게 만드는 비정상적인 상태예요. 결함은 영구적일 수도, 간헐적으로 나타났다 사라질 수도 있고, 일시적일 수도 있어요.

3.55 Fault Detection Time Interval (FDTI, 결함 감지 시간 간격)

결함(3.54)이 발생한 시점부터 그것이 감지될 때까지의 시간

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

Figure 5. Safety relevant time intervals

참고 2: 결함 감지 시간 간격은 진단 테스트 시간 간격(3.35)과는 독립적으로 결정됩니다.
예시: 진단 테스트의 결함 감지 시간 간격은 구현된 오류(3.46) 카운터로 인해 진단 테스트 시간 간격(3.35)보다 더 길어질 수 있습니다. 즉, 결함(3.54)은 오류(3.46) 반응을 일으키기 전에 진단 테스트에 의해 여러 번 감지되어야 합니다.

참고 3: 결함 감지 시간 간격, 진단 테스트 시간 간격(3.35), 그리고 결함 반응 시간 간격(3.59)은 결함(3.54) 감지에 기반한 안전 메커니즘(3.142)의 중요한 특성입니다.

참고 4: 결함 감지 시간 간격과 결함 반응 시간 간격(3.59)의 합이 해당 결함 허용 시간 간격(3.61)보다 짧으면, 해당 결함(3.54)은 안전 메커니즘(3.142)에 의해 적시에 처리됩니다.

결함 감지 시간 간격은 결함이 생긴 순간부터 그것이 감지될 때까지 걸리는 시간을 말해요. 진단 테스트와는 별개로 결정되고, 오류 반응을 일으키기 전에는 여러 번 감지되어야 할 수도 있어요. 이 시간 간격과 결함 반응 시간 간격을 더한 값이 허용된 시간보다 짧아야 안전하게 처리된다고 볼 수 있어요.

3.56 Fault Handling Time Interval (FHTI, 결함 처리 시간 간격)

결함 감지 시간 간격(3.55)과 결함 반응 시간 간격(3.59)의 합

참고 1: FHTI는 안전 메커니즘(3.142)의 특성입니다.

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

Figure 5. Safety relevant time intervals

결함 처리 시간 간격(FHTI)는 결함 감지 시간(FDTI)과 결함 반응 시간을 합친 것으로, 시스템이 결함을 얼마나 빠르게 감지하고 대응하는지를 나타냅니다. 감지 시간은 결함 발생부터 이를 탐지하기까지 걸리는 시간이고, 반응 시간은 감지 후 시스템이 결함에 대처하는 데 걸리는 시간입니다. FHTI는 시스템의 안전성과 신뢰성을 평가하는 중요한 요소로, 결함을 신속히 처리할 수 있는지 여부를 판단하는 기준이 됩니다.

3.57 Fault Injection (결함 주입)

엘리먼트(3.41) 내에서 결함(3.54)의 영향을 평가하기 위해 결함(3.54), 오류(3.46) 또는 고장(3.50)을 삽입하여 관찰 지점(3.101)을 통해 반응을 관찰하는 방법

참고 1: 결함 주입은 아이템(3.84) 또는 엘리먼트(3.41) 수준에서, 범위, 실행 가능성, 관찰 가능성, 요구되는 세부 수준에 따라 다양한 추상화 수준에서 수행될 수 있습니다. 목적에 따라 안전 수명 주기의 다른 단계에서, 그리고 다양한 결함 모델(3.58)을 고려하여 수행될 수 있습니다.

예시 1: 잠재 결함(3.85)을 감지하기 위한 전략의 일환으로, 안전 메커니즘(3.142)이 제대로 작동하는지 확인하기 위해 운영 중에 결함(3.54)을 주입하는 경우.

예시 2: 통합 테스트 중에 하드웨어 디버그 포트 또는 전용 소프트웨어 명령을 통해 결함(3.54)을 주입하여 하드웨어-소프트웨어 인터페이스(HSI)를 테스트하는 경우.

예시 3: 하드웨어 컴포넌트 수준에서 고착 결함(stuck-at fault) 또는 일시적 결함(3.54)을 시뮬레이션하여 안전 메커니즘(3.142)의 진단 범위(3.33)를 검증하거나 오류(3.46) 또는 고장(3.50)을 일으킬 수 있는 결함(3.54)을 식별하는 경우.

결함 주입은 시스템이나 엘리먼트 내에 결함, 오류, 또는 고장을 인위적으로 삽입하여 그 시스템이 어떻게 반응하는지 관찰하는 방법입니다. 결함 주입은 다양한 수준에서 수행될 수 있으며, 주로 안전 메커니즘이 제대로 작동하는지 확인하거나 하드웨어와 소프트웨어 간의 인터페이스를 테스트하는 데 사용됩니다.

3.58 Fault Model (결함 모델)

결함(3.54)으로 인해 발생하는 고장 모드(3.51)를 나타낸 것

참고 1: 결함 모델은 특정 결함(3.54)의 결과를 평가하는 데 사용됩니다.

결함 모델은 결함으로 인해 발생할 수 있는 고장 모드를 나타낸 것입니다. 주로 결함이 발생했을 때 그로 인한 결과를 평가하기 위해 사용됩니다.

3.59 Fault Reaction Time Interval (FRTI, 결함 반응 시간 간격)

결함(3.54)이 감지된 시점부터 안전 상태(3.131) 또는 비상 작동 상태(3.43)에 도달할 때까지의 시간

 

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

Figure 4. Emergency operation tolerance time interval

Figure 5. Safety relevant time intervals

결함 반응 시간 간격은 결함이 감지된 후, 시스템이 안전 상태나 비상 작동 상태로 전환될 때까지 걸리는 시간을 말합니다. 이 시간은 시스템의 안전성과 신뢰성에 중요한 역할을 합니다.

3.60 Fault Tolerance (결함 허용)

하나 이상의 특정 결함(3.54)이 발생한 상황에서도 지정된 기능을 제공할 수 있는 능력

참고 1: 지정된 기능은 의도된 기능(3.83)일 수 있습니다.

결함 허용은 시스템이 하나 이상의 결함이 발생해도 여전히 정상적인 기능을 수행할 수 있는 능력을 의미합니다. 즉, 결함이 있어도 시스템이 계속해서 의도된 기능을 제공할 수 있는지를 나타냅니다.

3.61 Fault Tolerant Time Interval (FTTI, 결함 허용 시간 간격)

아이템(3.84)에서 결함(3.54)이 발생한 시점부터 안전 메커니즘(3.142)이 활성화되지 않은 경우 위험한 사건(3.77)이 발생할 수 있는 최소 시간 간격

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

Figure 5. Safety relevant time intervals

참고 2: 이 최소 시간 간격은 모든 위험한 사건(3.77)에 대해 평가되어야 합니다. 이는 위험(3.75)의 특성화에 따라 달라질 수 있습니다.

참고 3: FTTI는 아이템(3.84)의 오작동 행동(3.88)으로 인한 위험(3.75)과 관련이 있습니다. FTTI는 이 위험(3.75)에서 도출된 안전 목표(3.139)의 중요한 속성입니다.

참고 4: 결함(3.54)은 아이템(3.84)이 안전 상태(3.131)로 유지되거나, 안전 상태(3.131)로 전환되거나, 비상 운전(3.43)으로 전환되는 경우, 해당 결함 허용 시간 간격 내에서 안전 메커니즘(3.142)에 의해 적시에 처리됩니다.

참고 5: 위험한 사건(3.77)이 발생하는 것은 결함(3.54)이 존재하고 차량이 해당 결함(3.54)이 차량 동작에 영향을 줄 수 있는 시나리오에 있을 때 의존합니다.

예시: 브레이크 시스템(3.163)에서의 고장(3.50)은 브레이크가 작동될 때까지 위험한 사건(3.77)으로 이어지지 않을 수 있습니다.

참고 6: FTTI는 아이템(3.84) 수준에서만 정의되지만, 엘리먼트(3.41) 수준에서는 최대 결함 처리 시간 간격(3.56)과 결함 처리 후 기능적 안전 개념(3.68)을 지원하기 위해 달성해야 하는 상태를 명시할 수 있습니다.

참고 7: 결함 감지 시간 간격(3.55)은 오류(3.46)의 디바운싱을 허용하기 위해 진단 테스트 시간 간격(3.35)이 결함 감지 시간 간격(3.55)보다 충분히 짧은 경우 여러 진단 테스트 시간 간격(3.35)을 포함할 수 있습니다.

결함 허용 시간 간격(FTTI)는 아이템에서 결함이 발생한 순간부터 위험한 사건이 발생하기까지의 최소 시간으로, 안전 메커니즘이 활성화되지 않았을 때를 기준으로 합니다. 이 시간 내에 시스템이 안전 상태나 비상 운전 상태로 전환되면 결함이 안전하게 처리된 것으로 봅니다. 위험한 사건이 발생하는지 여부는 결함이 존재하고 차량이 그 결함으로 인해 영향을 받을 수 있는 상황에 있는지에 따라 달라집니다.

3.62 Field Data (필드 데이터)

아이템(3.84) 또는 엘리먼트(3.41)의 사용 중에 얻어진 데이터로, 누적 운전 시간, 모든 고장(3.50), 그리고 서비스 중 발생한 안전 이상(3.134)을 포함합니다.

참고 1: 필드 데이터는 일반적으로 고객 사용으로부터 수집됩니다.

필드 데이터는 아이템이나 엘리먼트를 실제로 사용하면서 수집된 데이터로, 누적된 작동 시간, 발생한 모든 고장, 그리고 서비스 중에 나타난 안전 문제들을 포함합니다. 보통 이 데이터는 고객이 제품을 사용하면서 수집됩니다.

3.63 Formal Notation (형식 표기법)

구문과 의미가 모두 완전히 정의된 기술 서술 방법

예시: Z 표기법(Zed), NuSMV(상징적 모델 검사기), 프로토타입 검증 시스템(PVS), 비엔나 개발 방법(VDM), 수학적 공식.

형식 표기법은 구문과 의미가 명확하게 정의된 서술 방법으로, 주로 시스템을 설명하거나 검증할 때 사용됩니다. 대표적인 예로 Z 표기법, NuSMV, PVS, VDM, 그리고 수학적 공식들이 있습니다.

3.64 Formal Verification (정형 검증)

아이템의 정확성을 증명하기 위해 사용되는 방법

정형 검증은 아이템이 올바르게 작동하는지를 증명하기 위해 수학적 또는 논리적 방법을 사용하는 절차입니다.

3.65 Freedom from Interference (간섭 자유도)

두 개 이상의 엘리먼트(3.41) 간의 연속적인 고장(3.17)이 없어서 안전 요구사항(3.132)을 위반하지 않는 상태

예시 1: 엘리먼트 1이 엘리먼트 2로부터 간섭이 없는 상태라면, 엘리먼트 2의 고장(3.50)이 엘리먼트 1의 고장을 유발할 수 없습니다.

예시 2: 엘리먼트 3이 엘리먼트 4에 간섭이 있는 상태라면, 엘리먼트 3의 고장(3.50)이 엘리먼트 4의 고장을 유발할 수 있습니다.

간섭 자유도는 두 개 이상의 엘리먼트가 서로 영향을 주지 않아, 한 엘리먼트의 고장이 다른 엘리먼트의 고장을 유발하지 않는 상태를 말합니다. 안전 요구사항을 준수하기 위해 이러한 간섭이 없어야 합니다.

3.66 Functinal Concept (기능 컨셉)

의도된 기능과 원하는 동작을 달성하기 위해 필요한 상호작용을 명시한 사양

참고 1: 기능 컨셉은 컨셉 단계(3.110)에서 개발됩니다.

기능 컨셉은 시스템이 원하는 동작을 하기 위해 어떤 기능이 필요하고, 그 기능들이 어떻게 상호작용해야 하는지에 대한 구체적인 설명입니다. 이 개념은 시스템 개발의 초기 단계인 개념 단계에서 만들어집니다.

3.67 Functional Safety (기능 안전)

E/E 시스템(3.40)의 오작동(3.88)으로 인한 위험(3.75) 때문에 발생하는 불합리한 위험(3.176)이 없는 상태

기능 안전은 E/E 시스템(전기/전자 시스템)의 오작동으로 인해 발생할 수 있는 불합리한 위험을 방지하는 상태를 의미합니다. 시스템이 안전하게 작동하여 위험을 최소화하는 것을 목표로 합니다.

3.68 Functional Safety Concept (기능 안전 컨셉)

기능 안전 요구사항(3.69)의 명세와 관련 정보, 이를 아키텍처(3.1) 내 엘리먼트(3.41)에 할당하고, 안전 목표(3.139)를 달성하기 위해 필요한 상호작용을 정의한 것

기능 안전 컨셉은 시스템이 안전 목표를 달성하기 위해 필요한 기능 안전 요구사항을 명시하고, 이를 시스템의 각 엘리먼트에 어떻게 할당할지, 그리고 이 엘리먼트들이 어떻게 상호작용해야 하는지를 설명한 것입니다.

3.69 Functional Safety Requirement (기능 안전 요구사항)

구현에 독립적인 안전 행동(3.132) 또는 구현에 독립적인 안전 조치(3.141)를 명시하며, 그와 관련된 안전 속성을 포함하는 것

참고 1: 기능 안전 요구사항은 특정한 위험한 사건(3.77)을 고려하여 아이템(3.84)을 안전 상태(3.131)로 유지하거나 달성하기 위해, 안전 관련 E/E 시스템(3.40) 또는 다른 기술(3.105)의 안전 관련 시스템(3.163)에 의해 구현되는 안전 요구사항일 수 있습니다.
참고 2: 기능 안전 요구사항은 제품 개발의 개념 단계(3.110)에서 사용되는 기술과 무관하게 지정될 수 있습니다.
참고 3: 안전 관련 속성에는 ASIL(3.6)에 대한 정보가 포함됩니다.

기능 안전 요구사항은 안전한 동작을 보장하기 위해 구현 방식과 상관없이 적용되는 안전 행동이나 조치를 정의한 것입니다. 이 요구사항은 위험한 상황에 대비해 시스템이 안전 상태를 유지하도록 하고, 개발 초기에 사용 기술과 독립적으로 설정될 수 있습니다. 또한 ASIL과 같은 안전 등급과 관련된 정보를 포함합니다.