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

 

 

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

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

이번 포스팅에서는 S로 시작하는 기능안전 용어를 알아 볼게요.

 

 

 

 

 

목차

 

 

---

3.130 Safe Fault (안전한 결함)

안전한 결함은 발생해도 안전 목표(safety goal, 3.139) 위반의 확률을 유의미하게 증가시키지 않는 결함(fault, 3.54)을 의미합니다.

 

Note 1 to entry: ISO 26262-5:2018의 부록 B에 나와 있듯이, 비안전 및 안전 관련 엘리먼트(safety-related element, 3.144) 모두 안전한 결함을 가질 수 있습니다.

Note 2 to entry: 단일점 결함(single-point fault, 3.156), 잔여 결함(residual fault, 3.125), 이중점 결함(dual-point fault, 3.39)은 안전한 결함에 해당하지 않습니다.

Note 3 to entry: 안전(safety, 3.132) 컨셉에서 관련성이 입증되지 않는 한, 2보다 높은 차수의 다중점 결함(multiple-point fault, 3.97)은 안전한 결함으로 간주될 수 있습니다.

안전한 결함(Safe Fault)은 시스템에서 발생하더라도 안전 목표에 큰 영향을 미치지 않는 결함입니다. 즉, 이 결함이 발생해도 시스템의 안전성을 위협할 가능성이 낮습니다.

일반적으로 단일점 결함이나 잔여 결함과 같은 특정 유형의 결함은 안전한 결함으로 간주되지 않으며, 이들은 안전성에 더 큰 영향을 미칠 수 있는 결함입니다. 하지만 2차 이상의 다중점 결함은 특정 조건에서 안전한 결함으로 간주될 수 있습니다. 안전한 결함의 개념은 시스템의 안전 평가와 결함 관리에서 중요한 역할을 합니다.

3.131 Safe State (안전 상태)

안전 상태는 아이템(item, 3.84)이 고장(failure, 3.50)이 발생했을 때, 과도한 수준의 위험(risk, 3.128) 없이 운영되는 운영 모드(operating mode, 3.102)를 의미합니다.

 

Note 1 to entry: 그림 5를 참조하세요.

Figure 5. Safety relevant time intervals

 

Note 2 to entry: 정상적인 운영도 안전할 수 있지만, ISO 26262 표준에서는 고장(failure, 3.50)이 발생한 경우에만 안전 상태가 정의됩니다.

 

예시: 결함 허용이 없는 시스템(system, 3.163)의 경우, 전원 차단 모드.

안전 상태(Safe State)는 시스템에서 고장이 발생했을 때, 그 시스템이 더 이상 위험을 초래하지 않고 안전하게 작동하는 상태를 의미합니다. 이는 시스템이 고장이 발생하더라도 안전하게 종료되거나 위험을 최소화하는 동작을 수행하는 것을 뜻합니다.

예를 들어, 결함 허용이 없는 시스템에서는 전원을 끄는 것이 안전 상태일 수 있습니다. ISO 26262 표준에서는 시스템의 고장 시 안전 상태를 정의하여 안전성을 보장하는 것을 목표로 합니다.

3.132 Safety (안전)

안전은 과도한 위험(unreasonable risk, 3.176)이 없는 상태를 의미합니다.

안전(Safety)은 시스템이 과도한 위험 없이 작동하는 상태를 뜻합니다. 즉, 시스템의 사용이나 작동 중에 사용자나 환경에 큰 위협이 될 수 있는 위험 요소가 존재하지 않는 상태를 말합니다. 이는 시스템 설계 및 운영에서 핵심적인 목표로, ISO 26262 같은 안전 표준에서는 이 안전성을 보장하고 유지하는 방법을 규정하고 있습니다.

3.133 Safety Activity (안전 활동)

안전 활동은 안전(safety, 3.132) 생애 주기(lifecycle, 3.86)의 하나 이상의 단계(phase, 3.110) 또는 하위 단계(sub-phase, 3.161)에서 수행되는 활동을 의미합니다.

안전 활동(Safety Activity)은 시스템의 안전성을 확보하기 위해 안전 생애 주기 동안 특정 단계에서 수행되는 일련의 작업을 말합니다. 이러한 활동은 시스템의 설계, 개발, 운영 및 유지보수 과정에서 안전 목표를 달성하기 위해 필수적으로 수행되며, ISO 26262 표준에 따라 체계적으로 이루어집니다.

3.134 Safety Anomaly (안전 이상)

안전 이상은 기대와 다른 조건으로, 위해(harm, 3.74)를 초래할 수 있는 상태를 의미합니다.

 

Note 1 to entry: 안전 이상은 리뷰(review, 3.127), 테스트(testing, 3.169), 분석, 컴파일, 또는 컴포넌트(component, 3.21)나 관련 문서의 사용 중에 발견될 수 있습니다.

 

예시: 요구사항, 사양, 설계 문서, 사용자 문서, 표준 또는 경험에서의 편차가 될 수 있습니다.

안전 이상(Safety Anomaly)은 시스템이 기대와 다르게 동작하거나, 설계된 조건에서 벗어난 경우로, 이는 위해를 초래할 가능성이 있는 상태를 의미합니다. 안전 이상은 리뷰, 테스트, 분석 등의 다양한 활동 중에 발견될 수 있으며, 이러한 이상이 발견되면 즉각적으로 해결해야 시스템의 안전성을 유지할 수 있습니다.

이상은 요구사항이나 설계 문서와 같은 여러 단계에서 발생할 수 있으며, 이를 발견하는 것은 안전한 시스템 운영에 있어 매우 중요합니다.

3.135 Safety Architecture (안전 아키텍처)

안전 아키텍처는 안전(safety, 3.132) 요구사항을 충족하기 위해 엘리먼트(element, 3.41)와 그들의 상호작용으로 이루어진 집합을 의미합니다.

안전 아키텍처(Safety Architecture)는 시스템이 안전 요구사항을 충족할 수 있도록 설계된 구조를 말하며, 시스템의 요소들이 서로 어떻게 상호작용하는지를 정의합니다. 이 구조는 시스템의 안전성을 보장하기 위해 필수적인 역할을 하며, 각 엘리먼트가 안전 목표를 달성하기 위해 협력해야 합니다.

이를 통해 시스템은 고장이나 위험 상황에서도 안전하게 작동할 수 있도록 설계됩니다. ISO 26262 같은 안전 표준에서는 이러한 아키텍처가 중요한 역할을 하며, 시스템의 안전성 평가에서 핵심적인 부분을 차지합니다.

3.136 Safety Case (안전 케이스)

안전 케이스는 아이템(item, 3.84) 또는 엘리먼트(element, 3.41)에 대해 기능 안전(functional safety, 3.67)이 달성되었음을 증명하는 논거로, 개발 과정에서 수행된 작업 산출물(work product, 3.185)에서 수집된 증거로 입증됩니다.

 

Note 1 to entry: 안전 케이스는 ISO 26262 표준 범위를 넘어서 안전(safety, 3.132) 문제를 포함하도록 확장될 수 있습니다.

안전 케이스(Safety Case)는 시스템이 기능 안전을 달성했음을 입증하는 체계적인 논거로, 이를 뒷받침하는 증거들이 개발 과정에서 생성된 작업 산출물을 기반으로 제시됩니다. 이러한 증거는 시스템이 설계, 개발, 테스트, 검증 등의 단계에서 안전성 요구사항을 충족했음을 보여주는 자료입니다.

안전 케이스는 ISO 26262 표준에서 요구하는 범위를 넘어, 추가적인 안전성 문제를 다룰 수 있도록 확장될 수 있으며, 이를 통해 시스템의 안전성을 더 광범위하게 검토하고 보장할 수 있습니다.

3.137 Safety Culture (안전 문화)

안전 문화는 안전(safety, 3.132)이 다른 경쟁 목표들보다 우선시되는 의사결정 및 행동에서 드러나는 조직의 지속적인 가치, 태도, 동기, 지식을 의미합니다.

 

Note 1 to entry: ISO 26262-2:2018, 부록 B를 참조하세요.

안전 문화(Safety Culture)는 조직이 안전성을 최우선으로 고려하는 가치관과 행동 방식을 의미합니다. 이는 조직의 의사결정이나 행동에서 안전이 항상 최우선으로 고려된다는 것을 나타내며, 이를 통해 안전 목표를 달성할 수 있도록 보장합니다.

안전 문화는 조직의 전반적인 동기와 태도에 깊이 뿌리내려야 하며, 이를 통해 조직은 안전성과 신뢰성을 지속적으로 유지할 수 있습니다. ISO 26262는 이러한 안전 문화를 장려하며, 이를 통해 자동차 안전을 보장하려고 합니다.

3.138 Safety Element Out of Context, SEooC (특정 컨텍스트 외의 안전 엘리먼트)

SEooC는 특정 아이템(item, 3.84)의 맥락에서 개발되지 않은 안전 관련 엘리먼트(safety-related element, 3.144)를 의미합니다.

 

Note 1 to entry: SEooC는 시스템(system, 3.163), 여러 시스템의 조합, 소프트웨어 컴포넌트(software component, 3.157), 소프트웨어 유닛(software unit, 3.159), 하드웨어 컴포넌트(component, 3.21) 또는 하드웨어 부분(hardware part, 3.71)일 수 있습니다.

 

예시: 다양한 OEM 시스템에 통합될 것으로 가정된 일반적인 와이퍼 시스템(system, 3.163).

SEooC는 특정 항목에 대한 명확한 컨텍스트 없이 개발된 안전 관련 요소를 의미합니다. 예를 들어, 특정 차량이나 시스템에 적용되지 않은 상태에서 개발된 와이퍼 시스템과 같은 안전 관련 부품이 다른 시스템에 통합될 수 있습니다.

SEooC는 독립적으로 개발된 후 다양한 차량 제조사(OEM)의 시스템에 통합될 수 있도록 설계된 부품이나 시스템을 가리키며, 이는 다양한 응용 가능성을 고려하여 개발됩니다.

3.139 Safety Goal (안전 목표)

안전 목표는 차량 수준에서 위험원 분석 및 위험 평가(hazard analysis and risk assessment, 3.76)의 결과로 도출된 최상위 수준의 안전(safety, 3.132) 요구사항을 의미합니다.

 

Note 1 to entry: 하나의 안전 목표는 여러 위험원(hazard, 3.75)과 관련될 수 있으며, 여러 안전 목표가 하나의 위험원(hazard, 3.75)과 관련될 수 있습니다.

안전 목표(Safety Goal)는 위험원 분석 및 위험 평가(HARA)의 결과로 도출된 가장 상위 수준의 안전 요구사항입니다. 이는 시스템에서 발생할 수 있는 위험을 식별하고, 이를 방지하기 위해 필요한 안전 조치를 정의하는 데 핵심적인 역할을 합니다.

하나의 안전 목표는 여러 잠재적 위험과 관련될 수 있으며, 반대로 하나의 위험이 여러 안전 목표와 연결될 수도 있습니다. 이를 통해 시스템이 안전하게 운영되도록 보장하며, 특히 자동차 안전성을 확보하는 데 중요한 부분을 차지합니다.

3.140 Safety Manager (안전 관리자)

안전 관리자는 기능 안전(functional safety, 3.67)을 달성하기 위해 필요한 활동을 감독하고 보장하는 책임을 지는 사람 또는 조직을 의미합니다.

 

Note 1 to entry: 아이템(item, 3.84)의 개발 다양한 수준에서, 각 회사는 내부 매트릭스 조직에 따라 업무를 분할하여 한 명 이상의 다른 사람을 임명할 수 있습니다.

안전 관리자(Safety Manager)는 시스템의 기능 안전을 달성하기 위해 필수적인 활동을 관리하고 조정하는 역할을 합니다. 이들은 개발 과정 전반에서 안전 요구사항이 제대로 이행되고 있는지 감독하며, 모든 안전 관련 프로세스가 규정에 맞게 진행되도록 보장합니다.

여러 조직이나 회사가 협력하는 프로젝트에서는 여러 명의 안전 관리자가 각기 다른 책임을 지고 있을 수 있으며, 내부 조직 구조에 따라 업무가 분할될 수 있습니다.

3.141 Safety Measure (안전 조치)

안전 조치는 체계적 결함(systematic failure, 3.164)을 방지하거나 제어하고, 임의 하드웨어 고장(random hardware failure, 3.118)을 감지하거나 제어하며, 그 유해한 영향을 완화하는 활동 또는 기술적 해결책을 의미합니다.

 

Note 1 to entry: 안전 조치에는 안전 메커니즘(safety mechanism, 3.142)이 포함됩니다.

예시: FMEA(고장 모드 및 영향 분석) 또는 글로벌 변수를 사용하지 않는 소프트웨어.

안전 조치(Safety Measure)는 시스템에서 발생할 수 있는 체계적 결함이나 무작위 하드웨어 고장을 방지하고 제어하기 위한 활동 또는 기술적 방법입니다. 이러한 조치는 결함이 발생하더라도 시스템의 안전성을 유지하고, 유해한 영향을 최소화하는 데 도움을 줍니다.

예를 들어, FMEA는 시스템의 잠재적 결함 모드를 분석하고 영향을 평가하는 기법이며, 이를 통해 안전성을 보장할 수 있습니다. 안전 메커니즘도 이러한 안전 조치의 일환으로, 시스템이 고장 시에도 안전하게 작동하도록 합니다.

3.142 Safety Mechanism (안전 메커니즘)

안전 메커니즘은 E/E 기능이나 엘리먼트(element, 3.41) 또는 다른 기술(other technology, 3.105)을 통해 구현된 기술적 해결책으로, 결함(fault, 3.54)을 감지하고 완화하거나 허용하며, 고장(failure, 3.50)을 제어하거나 방지하여 의도된 기능(intended functionality, 3.83)을 유지하거나 안전 상태(safe state, 3.131)를 달성하거나 유지하도록 합니다.

 

Note 1 to entry: 안전 메커니즘은 아이템(item, 3.84) 내에서 결함(fault, 3.54)이 단일점 고장(single-point failure, 3.155)으로 이어지지 않도록 하고, 잠재 결함(latent fault, 3.85)이 발생하지 않도록 방지합니다.

Note 2 to entry: 안전 메커니즘은 다음 중 하나를 수행할 수 있습니다:

a) 아이템(item, 3.84)을 안전 상태(safe state, 3.131)로 전환하거나 유지할 수 있음, 또는

b) 운전자가 고장(failure, 3.50)의 영향을 제어할 것으로 기대되도록 운전자에게 경고할 수 있음, 이는 기능 안전 컨셉(functional safety concept, 3.68)에 정의된 대로입니다.

안전 메커니즘(Safety Mechanism)은 시스템의 결함이나 고장을 감지하고 그로 인해 발생할 수 있는 문제를 완화하거나 허용하는 기술적 장치입니다. 이는 시스템이 의도된 기능을 유지하거나, 필요 시 안전 상태로 전환될 수 있도록 설계됩니다.

E/E 시스템이나 기타 기술을 활용해 구현된 이 메커니즘은 단일점 고장과 같은 치명적인 고장을 방지하고, 잠재적 결함이 문제가 되지 않도록 결함 감지 및 제어 기능을 제공합니다. 또한, 운전자가 직접 제어할 수 있도록 경고를 제공하거나 시스템이 스스로 안전 상태로 전환될 수 있는 기능을 수행합니다.

3.143 Safety Plan (안전 계획)

안전 계획은 프로젝트의 안전 활동(safety activity, 3.133)을 관리하고 실행을 안내하기 위한 계획으로, 날짜, 마일스톤, 과제, 산출물, 책임, 자원 등을 포함합니다.

안전 계획(Safety Plan)은 프로젝트 내에서 안전성을 보장하기 위한 체계적인 관리 계획입니다. 이 계획은 안전 활동이 원활히 진행될 수 있도록 일정, 중요한 마일스톤, 과업, 책임 분배, 필요 자원 등을 명확하게 정의합니다.

프로젝트의 안전성 확보를 위해 책임자와 리소스를 할당하고, 정해진 일정에 따라 안전 활동을 체계적으로 관리하는 중요한 도구로 활용됩니다.

3.144 Safety-Related Element (안전 관련 엘리먼트)

안전 관련 엘리먼트는 안전 목표(safety goal, 3.139)의 위반 또는 달성에 기여할 가능성이 있는 엘리먼트(element, 3.41)를 의미합니다.

 

Note 1 to entry: Fail-safe 엘리먼트(element, 3.41)는 최소 하나의 안전 목표(safety goal, 3.139)에 기여할 수 있다면 안전 관련으로 간주됩니다.

안전 관련 엘리먼트(Safety-Related Element)는 시스템의 안전 목표를 위반하거나 달성하는 데 중요한 역할을 할 수 있는 요소를 의미합니다. 이러한 엘리먼트는 시스템 내에서 안전성을 유지하거나 위협할 수 있는 기능을 담당하며, 특히 페일세이프 엘리먼트처럼 특정 조건에서 안전성을 보장하는 기능을 수행할 수 있습니다.

이러한 요소들을 적절하게 관리하고 평가함으로써, 시스템의 안전 목표를 효율적으로 달성할 수 있도록 해야 합니다.

3.145 Safety-Related Function (안전 관련 기능)

안전 관련 기능은 안전 목표(safety goal, 3.139)의 위반 또는 달성에 기여할 가능성이 있는 기능을 의미합니다.

안전 관련 기능(Safety-Related Function)은 시스템 내에서 안전 목표의 달성 또는 위반에 영향을 줄 수 있는 기능을 말합니다. 이 기능들은 시스템의 안전성을 보장하거나 위협할 수 있는 중요한 역할을 합니다. 따라서 이러한 기능들은 개발 및 운영 중에 특별히 주의하여 관리되어야 하며, 안전 목표를 달성하기 위해 필수적인 역할을 수행합니다.

3.146 Safety-Related Incident (안전 관련 사고)

안전 관련 사고는 안전 관련 고장(failure, 3.50)의 발생을 의미합니다.

안전 관련 사고(Safety-Related Incident)는 시스템에서 안전 관련 고장이 발생한 상황을 말합니다. 이러한 사고는 시스템의 안전성에 영향을 미칠 수 있으며, 안전 목표를 달성하는 데 장애가 될 수 있습니다. 안전 관련 사고는 철저히 분석하고 관리하여 재발 방지와 안전성 확보를 위한 대책이 필요합니다.

3.147 Safety-Related Special Characteristic (안전 관련 특수 특성)

안전 관련 특수 특성은 아이템(item, 3.84)이나 엘리먼트(element, 3.41), 또는 그들의 생산 공정에서, 합리적으로 예측 가능한 편차가 기능 안전(functional safety, 3.67)의 잠재적인 저하에 영향을 미치거나 기여하거나 이를 초래할 수 있는 특성을 의미합니다.

 

Note 1 to entry: IATF 16949에서는 특수 특성이라는 용어를 정의합니다.

Note 2 to entry: 안전 관련 특수 특성은 아이템(item, 3.84) 또는 엘리먼트(element, 3.41)의 개발 단계(phase, 3.110)에서 도출됩니다.

Note 3 to entry: 안전 관련 특수 특성은 안전 메커니즘(safety mechanism, 3.142)과는 다르며 혼동해서는 안 됩니다.

 

예시: 온도 범위, 유효 기간, 조임 토크, 생산 허용 오차, 구성.

안전 관련 특수 특성(Safety-Related Special Characteristic)은 아이템 또는 엘리먼트의 설계 및 생산에서 예상되는 편차가 시스템의 기능 안전에 영향을 미칠 수 있는 중요한 특성을 가리킵니다. 이러한 특성들은 개발 단계에서 도출되며, 안전성을 유지하기 위해 특별한 주의와 관리가 필요합니다.

예를 들어, 온도 범위나 생산 허용 오차와 같은 특성은 안전성을 보장하기 위해 엄격히 관리되어야 하며, 이러한 특성의 편차는 시스템의 안전성을 저하시킬 수 있습니다. 안전 메커니즘과는 별개의 개념으로, 안전 관련 특수 특성은 시스템의 물리적 및 운영적 특성에 중점을 둡니다.

3.148 Safety Validation (안전 검증)

안전 검증은 검토와 테스트를 기반으로, 안전 목표(safety goal, 3.139)가 적절하며 충분한 무결성 수준으로 달성되었음을 보장하는 것을 의미합니다.

 

Note 1 to entry: ISO 26262-4는 안전 검증을 위한 적합한 방법을 제공합니다.

안전 검증(Safety Validation)은 시스템이 설정한 안전 목표를 충분히 달성했는지를 검토하고 테스트를 통해 확인하는 과정입니다. 이를 통해 시스템이 요구되는 안전성과 무결성을 확보했는지 확인할 수 있습니다.

ISO 26262-4에서는 이러한 안전 검증을 수행하기 위한 다양한 방법을 제시하며, 이를 통해 시스템의 안전성을 체계적으로 보장할 수 있습니다.

3.149 Semi-Formal Notation (반형식적 표기법)

반형식적 표기법은 구문(syntax)이 완전히 정의되었으나, 의미(semantics) 정의가 불완전할 수 있는 기술 기법을 의미합니다.

 

예시: SADT(Structured And Design Techniques), UML(Unified Modeling Language).

반형식적 표기법(Semi-Formal Notation)은 시스템 설계나 분석에서 사용되는 기술로, 구문은 명확히 정의되어 있으나 의미가 완전히 정의되지 않은 경우를 말합니다. 이러한 표기법은 시스템을 구조적으로 표현하는 데 유용하지만, 의미 해석이 다소 유연할 수 있어 때로는 추가적인 해석이 필요할 수 있습니다.

예를 들어, UML은 소프트웨어 설계에서 널리 사용되는 반형식적 표기법으로, 다이어그램을 통해 시스템을 시각적으로 표현하지만, 각 다이어그램의 세부 의미는 상황에 따라 달라질 수 있습니다.

3.150 Semi-Formal Verification (반형식적 검증)

반형식적 검증은 반형식적 표기법(semi-formal notation, 3.149)으로 제공된 설명을 기반으로 하는 검증(verification, 3.180)을 의미합니다.

 

예시: 반형식적 모델에서 생성된 테스트 벡터를 사용하여 시스템(3.163)의 동작이 모델과 일치하는지 테스트.

반형식적 검증(Semi-Formal Verification)은 반형식적 표기법을 통해 기술된 시스템의 설계 모델과 실제 시스템 동작이 일치하는지를 검증하는 과정입니다. 이 방식에서는 주로 테스트 벡터와 같은 도구를 사용하여, 모델이 예상하는 대로 시스템이 작동하는지 확인합니다.

예를 들어, UML과 같은 반형식적 모델을 사용하여 시스템의 구조나 동작을 설계한 후, 그 설계가 실제 구현된 시스템과 일치하는지 테스트를 통해 확인하는 절차를 따릅니다.

3.151 Semi-Trailer (세미 트레일러)

세미 트레일러는 트랙터(tractor, 3.170)에 킹핀으로 연결되어 견인되며, 견인 차량에 상당한 수직 하중을 가하는 방식으로 설계된 트레일러(trailer, 3.171)를 의미합니다.

세미 트레일러(Semi-Trailer)는 트랙터에 연결되어 견인되는 트레일러 유형으로, 킹핀이라는 연결 장치를 통해 트랙터와 결합됩니다. 이 방식은 트레일러가 견인 차량에 수직 하중을 가하게 되어, 트랙터가 트레일러의 일부 무게를 지탱하며 안정성을 높이는 역할을 합니다. 대형 화물 운송에서 자주 사용되는 방식입니다.

3.152 Series Production Road Vehicle (양산 차량)

양산 차량은 공공 도로에서 사용될 목적으로 제작된, 프로토타입이 아닌 도로 차량을 의미합니다.

 

Note 1 to entry: 차량 유형 분류는 지역에 따라 다를 수 있습니다.

 

예시 1: 일반 대중에게 판매되는 차량.

예시 2: 공공 도로에서 사용하기 위해 판매되는 차량.

양산 차량(Series Production Road Vehicle)은 프로토타입이 아닌 상업용으로 생산된 차량을 말하며, 이는 공공 도로에서 사용하기 위해 설계되고 제작된 차량입니다. 지역별 규정에 따라 차량의 유형 분류가 다를 수 있지만, 기본적으로 일반 대중이 사용할 목적으로 제작된 차량을 의미합니다.

3.153 Service Note (서비스 노트)

서비스 노트는 아이템(item, 3.84)에 대한 유지보수 절차를 수행할 때 고려해야 할 안전(safety, 3.132) 정보에 대한 문서를 의미합니다.

 

예시: 안전 관련 특수 특성(safety-related special characteristic, 3.147); 요구될 수 있는 안전(safety, 3.132) 작업.

서비스 노트(Service Note)는 차량이나 시스템의 유지보수 과정에서 안전 관련 정보를 제공하는 문서입니다. 안전성을 보장하기 위해 유지보수 작업 중에 특별히 주의해야 할 사항들이 포함되며, 이는 안전 관련 특성이나 작업 중 필요한 안전 절차를 명확히 설명합니다.

3.154 Severity (심각도)

심각도는 잠재적인 위험 사건(hazardous event, 3.77)에서 한 명 또는 그 이상의 개인에게 발생할 수 있는 위해(harm, 3.74)의 정도를 추정한 것입니다.

 

Note 1 to entry: 위험원 분석 및 위험 평가(hazard analysis and risk assessment, 3.76)에서 “S”라는 매개변수는 위해(harm, 3.74)의 잠재적 심각도를 나타냅니다.

심각도(Severity)는 시스템에서 위험 사건이 발생했을 때, 그 사건이 사람에게 미칠 수 있는 위험의 정도를 나타내는 중요한 지표입니다. 이는 위험 분석 및 평가 과정에서 사용되며, 잠재적인 위해가 어느 정도 심각한지를 수치화하거나 추정하여 위험성을 평가하는 데 사용됩니다. “S”라는 매개변수는 이 심각도를 수학적으로 표현하는 값입니다.

3.155 Single-Point Failure (단일점 고장)

단일점 고장은 단일점 결함(single-point fault, 3.156)에서 발생하는 고장(failure, 3.50)을 의미합니다.

단일점 고장(Single-Point Failure)은 시스템 내에서 단일 결함으로 인해 발생하는 고장을 말합니다. 즉, 하나의 결함이 시스템의 안전성에 중대한 영향을 미쳐 고장으로 이어지는 경우를 가리킵니다. 단일점 고장은 안전성을 위협할 수 있는 중요한 요소이므로, 이를 방지하기 위한 설계 및 관리가 매우 중요합니다.

3.156 Single-Point Fault (단일점 결함)

단일점 결함은 엘리먼트(element, 3.41) 내의 하드웨어 결함(fault, 3.54)으로, 이 결함이 안전 목표(safety goal, 3.139)를 직접적으로 위반하며, 해당 엘리먼트(element, 3.41) 내에 어떤 안전 메커니즘(safety mechanism, 3.142)도 적용되지 않은 경우를 의미합니다.

 

Note 1 to entry: 단일점 고장(single-point failure, 3.155)도 참조하십시오.

Note 2 to entry: 예를 들어, 마이크로컨트롤러의 워치독 같은 안전 메커니즘(safety mechanism, 3.142)이 하드웨어 엘리먼트(element, 3.41)에 정의되어 있으면, 해당 하드웨어 엘리먼트의 어떤 결함도 단일점 결함이 아닙니다.

단일점 결함(Single-Point Fault)은 하드웨어 시스템에서 안전 메커니즘이 적용되지 않아, 하나의 결함이 시스템의 안전 목표를 직접적으로 위반하는 경우를 의미합니다. 즉, 결함 하나만으로도 중대한 고장이 발생할 수 있는 상태입니다.

안전 메커니즘이 정의된 경우, 그 엘리먼트는 단일점 결함이 아니게 됩니다. 예를 들어, 마이크로컨트롤러에 워치독과 같은 안전 장치가 있다면, 해당 엘리먼트의 결함은 단일점 결함으로 간주되지 않습니다. 단일점 결함은 중대한 안전 위험을 초래할 수 있기 때문에, 이를 방지하기 위한 적절한 안전 메커니즘을 설계하는 것이 중요합니다.

3.157 Software Component (소프트웨어 컴포넌트)

소프트웨어 컴포넌트는 하나 이상의 소프트웨어 유닛(software unit, 3.159)으로 구성된 소프트웨어 요소를 의미합니다.

소프트웨어 컴포넌트(Software Component)는 소프트웨어 시스템을 구성하는 기본 단위로, 여러 개의 소프트웨어 유닛을 포함할 수 있습니다. 이러한 컴포넌트들은 시스템의 기능적 역할을 담당하며, 다양한 소프트웨어 모듈이 상호작용하여 전체 시스템이 원활히 작동하도록 합니다. 소프트웨어 유닛은 컴포넌트의 더 작은 구성 요소로, 각각 독립적인 기능을 가질 수 있습니다.

3.158 Software Tool (소프트웨어 도구)

소프트웨어 도구는 아이템(item, 3.84) 또는 엘리먼트(element, 3.41)의 개발에 사용되는 컴퓨터 프로그램을 의미합니다.

소프트웨어 도구(Software Tool)는 시스템 개발 과정에서 사용되는 컴퓨터 프로그램으로, 항목이나 엘리먼트를 설계, 분석, 검증 또는 테스트하는 데 활용됩니다. 이러한 도구들은 효율적인 개발을 지원하며, 시스템 품질을 보장하는 데 중요한 역할을 합니다. 예를 들어, 코드 작성을 돕거나 모델링, 시뮬레이션, 디버깅 등을 수행하는 다양한 소프트웨어 도구들이 사용됩니다.

3.159 Software Unit (소프트웨어 유닛)

소프트웨어 유닛은 소프트웨어 아키텍처(architecture, 3.1)의 원자적 수준의 소프트웨어 컴포넌트(software component, 3.157)로, 독립적인 테스트(testing, 3.169)가 가능하도록 설계된 요소를 의미합니다.

소프트웨어 유닛(Software Unit)은 소프트웨어 아키텍처에서 가장 작은 단위의 구성 요소로, 개별적으로 테스트할 수 있는 독립적인 기능을 가집니다. 이는 더 큰 소프트웨어 컴포넌트나 시스템을 구성하는 기본적인 블록이며, 각각의 유닛은 자체적인 기능을 가지고 있어, 단위 테스트를 통해 정확성을 검증할 수 있습니다.

3.160 Statement Coverage (명령문 커버리지)

명령문 커버리지는 소프트웨어 내에서 실행된 명령문의 비율을 의미합니다.

명령문 커버리지(Statement Coverage)는 소프트웨어 테스트 시, 코드의 각 명령문이 실행된 비율을 측정하는 지표입니다. 이는 소프트웨어 테스트의 포괄성을 평가하는 방법으로, 높은 커버리지는 대부분의 코드가 테스트되었음을 의미합니다. 하지만 명령문 커버리지만으로는 모든 경우의 수나 에러 시나리오를 충분히 테스트했다고 보장할 수 없기 때문에, 다른 테스트 기법들과 함께 사용됩니다.

3.161 Sub-Phase (서브 단계)

서브 단계는 안전(safety, 3.132) 생애주기(lifecycle, 3.86)의 단계(phase, 3.110)를 세분화한 것으로, ISO 26262의 조항에 명시된 세부 단계입니다.

 

예시: 위험원 분석 및 위험 평가(hazard analysis and risk assessment, 3.76)는 안전(safety, 3.132) 생애주기(lifecycle, 3.86)의 서브 단계이며, ISO 26262-3:2018의 6조에 명시되어 있습니다.

서브 단계(Sub-Phase)는 안전 생애주기에서 더 큰 단계를 세분화한 단계입니다. ISO 26262 표준에 따라, 각 서브 단계는 특정한 안전 관련 활동을 정의하며, 프로젝트나 시스템 개발 과정에서 구체적인 작업을 수행하는 데 중점을 둡니다. 예를 들어, 위험원 분석 및 위험 평가는 안전성을 보장하기 위한 중요한 서브 단계 중 하나입니다.

3.162 Supply Agreement (공급 계약)

공급 계약은 고객과 공급자 간의 계약으로, 아이템(item, 3.84) 및 엘리먼트(element, 3.41)의 생산과 관련하여 각 당사자가 수행하거나 교환해야 할 활동, 증거 또는 작업 산출물(work product, 3.185)의 책임을 명시한 계약입니다.

 

Note 1 to entry: DIA(3.32)는 개발 단계에 적용되지만, 공급 계약은 생산 단계에 적용됩니다.

공급 계약(Supply Agreement)은 고객과 공급자 사이에서 책임과 역할을 명확히 규정하는 계약입니다. 이 계약은 생산 과정에서 수행해야 할 활동이나 제공해야 할 증거, 작업 산출물에 대한 구체적인 내용을 포함하고 있으며, 양측이 서로 어떤 의무를 가지고 있는지 명확히 정의합니다. DIA가 개발 단계에 초점을 맞춘 반면, 공급 계약은 생산 단계에 초점을 두고 있습니다.

3.163 System (시스템)

시스템은 센서, 컨트롤러, 그리고 액추에이터를 상호 연관시키는 컴포넌트(component, 3.21) 또는 하위 시스템의 집합을 의미합니다.

 

Note 1 to entry: 연관된 센서나 액추에이터는 시스템에 포함될 수도 있고, 시스템 외부에 있을 수도 있습니다.

시스템(System)은 센서, 컨트롤러, 액추에이터와 같은 요소들이 서로 연결되어 기능을 수행하는 구성 요소 또는 하위 시스템의 집합입니다. 센서는 데이터를 수집하고, 컨트롤러는 그 데이터를 처리하며, 액추에이터는 명령을 실행하는 역할을 합니다. 이러한 요소들이 시스템 내부 또는 외부에서 서로 상호작용하며, 통합된 기능을 수행하는 것이 시스템의 핵심입니다.

3.164 Systematic Failure (체계적 고장)

체계적 고장은 특정 원인에 결정론적으로 관련된 고장(failure, 3.50)으로, 이는 설계 변경, 제조 공정, 운영 절차, 문서화, 또는 기타 관련 요인의 변화를 통해서만 제거될 수 있는 고장을 의미합니다.

체계적 고장(Systematic Failure)은 예측 가능하게 발생하는 고장으로, 그 원인은 설계, 제조 공정, 운영 절차, 또는 문서와 같은 구체적인 요인에 있습니다. 이러한 고장은 단순한 수리나 교체로 해결되지 않으며, 근본적인 원인을 제거하기 위해 시스템의 구조적 변경이나 절차 수정이 필요합니다. 체계적 고장을 방지하려면 시스템 설계부터 운영까지 세심한 관리와 개선이 필요합니다.

3.165 Systematic Fault (체계적 결함)

체계적 결함은 그 고장(failure, 3.50)이 결정론적으로 나타나며, 오직 공정 또는 설계 조치를 적용함으로써만 방지될 수 있는 결함(fault, 3.54)을 의미합니다.

체계적 결함(Systematic Fault)은 시스템 내에서 예측 가능하게 발생하는 결함으로, 이는 특정한 설계나 공정 상의 문제로 인해 발생합니다. 이러한 결함은 개별적인 수리나 임시 해결책으로는 방지할 수 없으며, 설계 변경 또는 공정 개선과 같은 근본적인 조치를 통해서만 해결 가능합니다. 체계적 결함은 주로 과정상의 오류나 설계상의 결함에서 기인하기 때문에, 체계적인 관리와 검증 절차가 필수적입니다.