ISO 26262: 기능안전, ASIL Decomposition (ASIL 분해), 방법론, 절차, 관련 기술 그리고 주의 사항

 

ASIL Decomposition (ASIL 분해)은 참 어려운 작업인 거 같아요.

이번 포스팅에서는 ISO26262 표준에 따른 "ASIL 분해"를 어떻게 하는지 알아볼게요.

ASIL 분해 중, 주의사항도 함께 알아볼 테니, 아래 내용을 잘 따라가 볼까요? 

 

 

 

ASIL Decomposition (ASIL 분해)의 목적과 의미

ASIL 분해(ASIL decomposition)는 복잡한 시스템의 안전 요구 사항을 여러 하위 요구 사항으로 나누어 독립적인 시스템 요소에 할당함으로써 기능안전을 보장하는 방법입니다. 주요 목적은 다음과 같습니다:

• 안전 목표 달성: 시스템 고장 시에도 안전한 상태를 유지하도록 보장.
• 설계 복잡성 감소: 초기 안전 요구 사항을 분해하여 관리하기 쉬운 하위 요구 사항으로 단순화.
• 독립성 확보: 요소 간 고장 전파를 방지하여 시스템 안전성 강화.
• 비용 최적화: 불필요한 고비용을 줄이고, 각 요소에 적합한 ASIL 등급을 적용.

Reference in ISO 26262

5.4.1: ASIL 분해가 적용될 때, 해당 절의 모든 요구 사항을 준수하여 시스템의 안전 목표를 유지하고, 각 요구 사항이 시스템 전체의 안전성에 기여하도록 해야 합니다.

5.4.3: 초기 안전 요구 사항을 분해하여 독립적인 요소로 나누고, 이를 통해 고장이 발생하더라도 시스템의 안전 목표를 위반하지 않도록 보장해야 합니다. 이러한 독립성은 종속적 고장 분석을 통해 입증되어야 하며, 안전 메커니즘이 충분히 효과적으로 작동해야 합니다.

 

ASIL Decomposition (ASIL 분해) 절차

ASIL 분해는 ISO 26262 표준에 따라 매우 체계적인 절차를 따릅니다. 이 과정에서 기능안전을 유지하기 위해 각 단계는 신중하게 실행되어야 합니다.

 

1. 초기 안전 요구 사항 평가

우선 기능안전과 관련된 초기 안전 요구 사항을 평가해야 합니다. 이 단계에서는 시스템의 안전 목표와 각 요구 사항이 시스템의 기능안전 목표를 어떻게 충족하는지 평가합니다. 그런 다음 각 요구 사항에 적절한 ASIL 등급을 결정합니다.

일반적으로 초기 안전 요구사항 도출은 다음과 같은 방법을 사용할 수 있습니다.

• HARA (Hazard Analysis and Risk Assessment): 시스템에 내재된 잠재적 위험을 분석하고, 이러한 위험이 발생할 가능성과 그로 인한 결과를 평가합니다. 이를 바탕으로 각 위험 요소를 줄이기 위한 구체적인 안전 요구 사항을 도출합니다.
• FMEA(Failure Mode and Effects Analysis): 각 기능 또는 구성 요소의 고장 모드를 분석하고, 이러한 고장이 시스템 안전성에 미치는 영향을 평가합니다. 이를 통해 각 구성 요소가 안전 목표에 어떻게 기여해야 하는지를 결정할 수 있습니다.
• FTA(Fault Tree Analysis): 시스템의 특정 위험이 발생할 수 있는 경로를 분석하는 방법입니다. 이를 통해 시스템이 고장 시에 어떤 경로를 통해 위험 상황이 발생할 수 있는지를 이해하고, 필요한 안전 요구 사항을 정의할 수 있습니다.

초기 안전 요구사항 도출 이후, 기능안전 목표를 어떻게 충족할 수 있는지를 평가하게 됩니다. 이는 시스템이 주어진 안전 목표를 달성할 수 있도록 각 요구 사항이 적절히 설계되었는지 확인하는 과정입니다.

• 고장 시나리오 분석: 초기 안전 요구 사항이 안전 목표를 충족하는지 평가하기 위해, 시스템 고장 시나리오를 분석합니다. 예를 들어, 시스템이 특정한 기능에서 고장을 일으켰을 때, 시스템이 어떻게 반응해야 하는지를 시뮬레이션하거나 모델링합니다. 이때 안전 요구 사항이 적절히 정의되었는지, 각 요구 사항이 고장 발생 시 시스템을 안전한 상태로 전환할 수 있는지를 확인합니다.
• 독립성 평가: ASIL 분해에서 각 요구 사항이 서로 독립적인 요소에 할당되어 있는지 평가합니다. 이는 시스템의 한 요소가 고장 나더라도 다른 요소가 정상적으로 작동할 수 있는지를 확인하는 중요한 과정입니다. 종속 고장 분석(Dependent Failure Analysis)을 통해 시스템의 고장 전파 가능성을 확인하고, 필요한 경우 추가적인 안전 메커니즘을 도입하여 고장 전파를 방지합니다.
• 안전 메커니즘 적용 여부 평가: 각 요구 사항이 안전 메커니즘에 의해 보호되고 있는지도 평가해야 합니다. 예를 들어, 고장 감지 시스템이나 백업 시스템 등이 적절히 작동하는지 확인하고, 이들이 기능안전 목표를 달성하는 데 필요한 수준으로 설계되어 있는지를 평가합니다.

Reference in ISO 26262

5.4.3: 초기 안전 요구 사항은 독립적 요소들에 의해 구현될 수 있는 중복된 요구 사항으로 분해되어야 하며, 종속적 고장 분석을 통해 독립성을 검증해야 한다.

2. 안전 요구 사항 분해

분해된 각 요구 사항을 독립적인 시스템 요소에 할당하는 과정은 설계 및 분석 단계에서 이루어집니다. 이를 위해 시스템의 아키텍처를 신중하게 설계하고, 독립성을 보장하는 다양한 방법을 사용합니다.

 

2.1 기능 기반 할당

분해된 요구 사항은 시스템의 기능별로 독립적으로 할당되어야 합니다. 즉, 각 요구 사항을 구현하는 기능적 요소들이 고유한 책임을 지고, 서로 간섭하지 않도록 설계합니다. 예를 들어, 차량의 제동 시스템에서는 다음과 같이 할당할 수 있습니다:

• 제어 기능: 제동력을 조절하는 제어 유닛은 ASIL D 수준의 높은 안전성을 필요로 합니다.
• 모니터링 기능: 제동 상태를 감지하고 이상 여부를 판단하는 모니터링 유닛은 ASIL A 또는 B 수준의 요구 사항을 만족할 수 있습니다.

이때, 제어 유닛과 모니터링 유닛은 서로 독립적으로 작동해야 하며, 한쪽의 고장이 다른 쪽에 영향을 미치지 않아야 합니다.

 

2.2 물리적 분리

물리적 분리는 하드웨어 구성 요소 간의 독립성을 보장하기 위한 기본적인 방법입니다. 이 방식은 시스템의 각 기능을 독립된 하드웨어 장치에 할당하여 고장이 다른 장치에 전파되지 않도록 합니다.

• 예시 1: 독립된 제어 모듈
  안전에 중요한 두 개의 ECU를 물리적으로 분리된 회로에서 운영하여, 한 ECU에 문제가 발생하더라도 다른 ECU가 기능을 계속 수행하도록 설계할 수 있습니다.
• 예시 2: 전원 공급의 독립성
  두 요소가 동일한 전원 공급에 의존하지 않도록, 각 요소에 별도의 전원 공급 장치를 할당함으로써 고장에 대한 독립성을 강화할 수 있습니다.

 

2.3 소프트웨어 분리

하드웨어뿐만 아니라 소프트웨어에서도 논리적인 분리가 필요합니다. 동일한 하드웨어 플랫폼에서 여러 소프트웨어 기능을 실행하는 경우, 소프트웨어 간의 상호 의존성을 최소화하여 각 기능이 독립적으로 동작할 수 있도록 설계해야 합니다.

• 예시: 소프트웨어 파티셔닝
  동일한 하드웨어에서 여러 안전 기능을 실행하는 경우, 각 기능을 별도의 소프트웨어 파티션으로 구분하여 할당할 수 있습니다. 이때 파티션 간에 메모리 보호와 스케줄링을 적용하여 고장이 한 소프트웨어 파티션에 영향을 미치지 않도록 합니다.

 

2.4 종속적 고장 분석(Dependent Failure Analysis, DFA)

분해된 요구 사항을 독립적인 시스템 요소에 할당할 때 중요한 과정 중 하나는 종속적 고장 분석(DFA)입니다. DFA는 시스템 요소들이 서로 독립적으로 작동하는지 검증하는 방법으로, 한 요소의 고장이 다른 요소에 전파될 가능성을 분석합니다.

DFA를 통해 다음을 검토합니다:

• 하드웨어 및 소프트웨어 간의 종속성: 동일한 물리적 리소스(예: 전원, 통신 채널)를 사용하는 요소 간의 고장 전파 가능성을 확인합니다.
• 공통 원인 고장: 두 요소가 동일한 원인(예: 과열, 전자기 간섭)에 의해 동시에 고장 날 수 있는지 확인합니다. 공통 원인이 있을 경우, 이를 완화하기 위한 안전 메커니즘을 설계합니다.
• 고장 영향 평가: 고장이 발생했을 때 시스템 전체에 미치는 영향을 평가하고, 각 요소가 독립적으로 안전 목표를 달성할 수 있는지 확인합니다.

 

2.5 안전 메커니즘과 의도된 기능 분리

ASIL 분해에서는 안전 메커니즘과 의도된 기능을 별도로 독립적인 시스템 요소에 할당하는 것이 중요합니다. 의도된 기능이 고장 났을 때, 안전 메커니즘이 이를 감지하고 시스템을 안전하게 유지할 수 있어야 합니다.

• 예시: 차량의 제동 시스템에서 브레이크 제어 기능은 고장 시 안전 메커니즘(예: 브레이크 상태 모니터링 시스템)이 즉시 개입하여 시스템을 안전한 상태로 전환해야 합니다. 제어 기능과 안전 메커니즘은 물리적, 논리적으로 분리되어 있어야 하며, 고장에 의한 상호 간섭이 없어야 합니다.

 

2.6 다양한 ASIL 등급 요소 간 할당

ASIL 분해의 목적 중 하나는 시스템을 효율적으로 설계하기 위해 다양한 ASIL 등급을 요소별로 할당하는 것입니다. 고도의 안전성을 요구하는 요소(예: ASIL D)는 고비용의 높은 안전성을 요구하지만, 덜 중요한 요소(예: ASIL A 또는 QM)에는 보다 낮은 수준의 안전성을 적용할 수 있습니다.

• 예시: 차량 스티어링 시스템에서 ASIL D 요구 사항은 주요 제어 기능에 할당되고, 모니터링 시스템에는 ASIL B 또는 ASIL A 요구 사항을 적용할 수 있습니다.

Reference in ISO 26262
5.4.4: 각 분해된 안전 요구 사항은 독립적으로 초기 안전 요구 사항을 충족해야 한다.
5.4.5: 하드웨어 아키텍처 메트릭의 평가와 무작위 하드웨어 고장으로 인한 안전 목표 위반의 평가는 ASIL 분해로 변경되지 않는다.

 

3. ASIL 할당

분해된 각 요구 사항에 적합한 ASIL 등급을 할당합니다. 예를 들어, ASIL D 요구 사항을 ASIL C와 ASIL A로 분해하고, 각각 독립적인 요소에 할당할 수 있습니다.

Reference in ISO 26262
5.4.8: ASIL 분해 시, 각 분해된 ASIL은 안전 목표의 ASIL을 괄호 안에 표시해야 한다.
5.4.9: 분해된 요구 사항은 각 수준의 ASIL 요구 사항에 맞추어 할당되어야 한다.

 

4. 독립성 검증

분해된 요소들이 충분히 독립적으로 작동하는지 검증하는 단계입니다. 

• DFA를 통한 독립성 검증: DFA의 주요 단계는 (1) 고장모드 식별, 예를 들어 전원 고장, 통신 오류, 하드웨어 고장 등을 식별합니다. (2) 고장 전파 경로 분석, 예를 들어 하나의 요소가 고장 나면 동일한 전원 공급을 사용하는 다른 요소가 함께 고장 날 가능성을 분석합니다. 마지막으로 (3) 고장 경감 대책 수립, 예를 들어 전력 공급을 분리하거나, 서로 다른 통신 경로를 사용하는 등의 조치를 취할 수 있습니다. 이런 과정을 통해 분해된 요소들이 충분히 독립적으로 작동하는지에 대한 증거를 제공할 수 있습니다.
• 물리적/논리적 분리: 물리적 분리는 하드웨어 구성 요소 간 상호 의존성을 제거하여 독립성을 보장하는 방법으로 예를 들면, 차량 내 두 개의 ECU를 서로 다른 회로에서 운영하여 하나의 ECU에 문제가 발생하더라도 다른 ECU가 영향을 받지 않도록 설계하는 것을 말합니다. 또한 논리적 분리는 동일한 하드웨어에서 실행되는 여러 소프트웨어 모듈을 격리하여 상호 영향성을 받지 않도록 하는 방법으로 예를 들면, 동일한 ECU에서 여러 개의 독립적인 소프트웨어 모듈이 동작하는 경우, 소프트웨어 간의 메모리 영역을 물리적으로 분리하여 한 모듈의 오류가 다른 모듈로 영향을 미치지 않도록 하는 방법입니다. 이를 통해 분해된 요소들이 물리적/논리적으로 독립적으로 작동하는지에 대한 증거를 제공할 수 있습니다.
• 다중 채널 설계 및 중복성: 다중 채널 설계는 독립성 검증을 위한 또 다른 중요한 기법입니다. 이 기법은 동일한 기능을 두 개 이상의 독립적인 채널에 배치하여, 한 채널이 고장 날 경우 다른 채널이 기능을 유지할 수 있도록 합니다. 이를 통해 시스템의 독립성을 강화할 수 있습니다.
• 진단 및 모니터링 시스템: 진단(Diagnosis) 및 모니터링(Monitoring) 시스템을 도입하여 독립성을 검증하고 유지하는 방법도 중요합니다. 각 독립적인 시스템 요소가 정상적으로 동작하고 있는지, 고장이 발생했을 때 빠르게 감지하고 대응할 수 있는지 확인해야 합니다.
• 고장 모드 및 영향 분석(FMEA, Failure Mode and Effects Analysis): 고장 모드 및 영향 분석(FMEA)을 통해 시스템 요소가 독립적으로 고장을 처리할 수 있는지, 고장이 다른 요소로 전파되지 않는지 확인할 수 있습니다.
• 공통 원인 고장 (CCF, Common Cause Failure) 방지: 공통 원인 고장(Common Cause Failure, CCF)은 한 가지 원인으로 인해 여러 독립적인 시스템 요소가 동시에 고장 나는 상황을 의미합니다. CCF를 방지하는 것은 독립성 검증에서 매우 중요합니다.

Reference in ISO 26262

5.4.10: 분해 후 요소들 간의 독립성을 확인하기 위한 증거를 제공해야 한다.

5.4.3: 종속적 고장 분석을 통해 독립성이 입증되어야 한다.

 

5. 안전 메커니즘 적용

분해된 요구 사항 중 일부는 안전 메커니즘에 할당될 수 있습니다. 이때, 안전 메커니즘이 기능안전을 보장할 만큼 충분히 효과적인지 확인하는 것이 중요합니다.

Reference in ISO 26262

5.4.7: 의도된 기능성과 관련된 안전 메커니즘이 더 높은 ASIL로 할당되어야 한다.

 

6. 시스템 통합 및 검증

마지막으로, 분해된 요구 사항들이 시스템에 통합된 후, 전체 시스템이 기능안전을 유지하는지 검증합니다. 이 과정에서는 각 요소의 독립성을 확인하고, 통합된 시스템이 초기 안전 요구 사항을 충족하는지 평가합니다.

Reference in ISO 26262

5.4.12: ASIL 분해가 적용된 각 수준에서, 통합과 검증 활동은 초기 ASIL 요구 사항에 따라 수행되어야 한다.

 

ASIL Decomposition (ASIL 분해) 시 고려사항 및 주의사항

ASIL 분해는 기능안전을 유지하면서도 복잡한 시스템을 안전하게 설계하기 위한 핵심적인 방법이지만, 몇 가지 중요한 고려 사항이 있습니다.

1. 요소 간 독립성 확보
   ASIL 분해에서 각 분해된 요구 사항을 구현하는 요소들이 충분히 독립적이어야 합니다. 요소 간 독립성이 부족하면, 고장이 전파되어 전체 기능안전을 해칠 수 있습니다. 따라서 종속적 고장 분석을 통해 독립성을 철저히 검증해야 합니다.
2. 동종 중복성의 한계
   동일한 하드웨어나 소프트웨어를 중복 사용하는 방식(예: 동일한 프로세서를 이중으로 사용하는 것)은 기능안전을 보장하는 데 한계가 있습니다. ASIL 분해를 통해 안전성을 확보하려면 고장의 원인과 종속성을 철저히 분석해야 하며, 단순한 중복만으로는 충분한 기능안전을 보장할 수 없습니다.
3. 안전 메커니즘의 역할
   ASIL 분해에서는 안전 메커니즘의 역할이 매우 중요합니다. 안전 메커니즘은 시스템 고장이 발생하더라도 시스템의 기능안전을 유지하기 위한 마지막 방어선으로 작동합니다. 따라서, 안전 메커니즘은 충분히 효과적으로 설계되고, 각 요소 간 독립성을 보장할 수 있어야 합니다.
4. ISO 26262 표준 준수
   ASIL 분해 과정에서 ISO 26262 표준을 철저히 준수해야 합니다. 각 단계에서 기능안전을 보장할 수 있는 적절한 조치들이 취해졌는지 확인하고, 하드웨어, 소프트웨어, 시스템의 모든 요소가 안전하게 설계되었는지 검증해야 합니다.