기능안전에서 안전, 비안전 요구사항 모두 기술?

ISO 26262-4:2018 Clause 6.4.1.3 해석

"기술 안전 요구사항이 규정된 기능에 추가적으로, 다른 기능 또는 요구사항이 시스템 또는 엘리먼트에 의해 구현된다면, 이러한 기능 또는 요구사항은 규정되어야 하거나 그들의 명세가 참조되어야 한다."

1. 핵심 의미: "안전과 비안전 요구사항의 총체적 관리"

• 이 조항은 개발자가 안전 요구사항만 쏙 빼내서 따로 개발하지 말라는 경고입니다.
• 실제 시스템(예: 브레이크 제어 ECU)은 안전 기능(TSR) 뿐만 아니라, 수많은 비안전 기능(Non-Safety Functions, 기타 요구사항) 을 동시에 수행합니다.
• 예시: 동일한 ECU가 안전 기능: "자동 긴급제동(AEB)"을 수행하면서도, 비안전 기능: "크루즈 컨트롤", "연비 표시", "진단 통신" 등을 함께 수행할 수 있습니다.

2. 실무적 요구사항: "완전한 명세서를 만들어라"

• 시스템 또는 요소의 요구사항 명세서는 단편적이어서는 안 됩니다. 해당 요소가 수행하는 모든 기능(안전 + 비안전)의 전체 목록을 포함하거나, 그 명세가 있는 다른 문서를 정확히 참조(Reference)해야 합니다.
• 왜 이렇게 해야 하나?
  1. 상호작용 분석: 비안전 기능이 안전 기능에 나쁜 영향을 미칠 수 있습니다. (예: 크루즈 컨트롤 소프트웨어의 버그로 인해 AEB 메모리 영역을 침범할 수 있음). 모든 기능을 한눈에 보아야 이런 부정적 상호작용(Negative Interaction) 을 분석할 수 있습니다.
  2. 자원 분배: CPU 시간, 메모리, 통신 대역폭 등 제한된 자원을 모든 기능이 공유합니다. 안전 기능이 필요한 자원과 타이밍을 보장받으려면, 다른 기능들이 얼마나 자원을 쓰는지 알야아 합니다.
  3. 안전 사례의 완결성: "이 요소는 안전하다"는 주장을 하려면, 그 요소의 모든 행위를 고려했음을 증명해야 합니다. 숨겨진 비안전 기능은 안전 사례의 빈틈이 됩니다.

3. 비고(※)의 의미: "기타 요구사항의 출처"

• 비안전 요구사항의 출처는 다양함을 인정하고 있습니다.
  • 법규 (ECE, FMVSS): 필수 준수 사항입니다.
  • 플랫폼 전략: 차종을 초월해 공통으로 적용되는 설계 원칙입니다.
  • 기능적 개념: 제품 기획 단계의 사용자 편의 기능들입니다.
  • 사이버보안 개념: 최근 매우 중요해진 영역으로, 안전성과 직접적으로 충돌할 수 있는 요소입니다(예: 보안 진입 절차가 긴급 제동을 지연시킬 수 있음).

---

ISO 26262-4:2018 Clause 6.4.1.4 해석

"기술 안전과 비안전 요구사항은 모순되어서는 안 된다."

1. 핵심 의미: "요구사항 간의 충돌을 해결하라"

• 이 조항은 6.4.1.3의 자연스러운 확장입니다. 모든 요구사항을 다 모았다면, 그들 사이에 충돌(Conflict)이나 모순(Inconsistency) 이 없는지 확인하고 해결하라는 것입니다.
• "모순" 이란 공학적, 물리적으로 동시에 만족될 수 없는 상태를 말합니다.

2. 실무적 예시와 해결 방안:

3. 실무 프로세스: "요구사항 조정 회의"

• 이 조항은 단순한 권고가 아닌 필수 활동을 의미합니다. 시스템 아키텍트는 안전 엔지니어, 기능 개발자, 사이버보안 전문가, 품질 담당자가 함께 참여하는 회의를 통해 모든 요구사항을 병렬로 검토하고 충돌을 사전에 발견해야 합니다.
• 발견된 충돌은 "안전이 최우선" 원칙 하에 해결되며, 그 결정 과정과 타당성은 안전 사례(Safety Case) 에 기록되어야 합니다.

종합 결론

6.4.1.3과 6.4.1.4는 함께 "시스템 설계의 현실 감각"을 요구합니다.

• 6.4.1.3: "세상에 안전 기능만 있는 게 아니야. 다른 수많은 기능들과 함께 돌아가는 현실을 인정하고, 그 모든 것을 문서화해라."
• 6.4.1.4: "그러고 보니 그 기능들끼리 싸울 수도 있겠네? 그 충돌을 미리 찾아서 안전을 우선시하며 해결해라."

이 두 조항을 소홀히 하면, 아무리 훌륭한 안전 설계도 실제 차량에 통합될 때 주변 기능과의 충돌로 인해 실패하거나, 예상치 못한 위험을 초래할 수 있습니다. 따라서 이는 시스템 수준 요구사항 분석의 완결성(Completeness)과 일관성(Consistency) 을 보장하는 핵심 조항입니다.

 

근데 궁금한 점은 TSC문서에 비안전 관련 요구사항을 쓸 일을 없을테고 여기서 말하는 것은 시스템 아키텍처 설계서 문서에 안전 비안전 요구사항 모두를 표현하라는 거야? 그리고 너가 설명한 "1.상호작용 분석:~~~" 이 부분은 기능안전 개발 프로세스에서 DFA 활동으로 해결이 될거 같기도 한데 맞아?

 

완벽한 지적입니다. 사용자님의 두 가지 질문 모두 기능안전 실무의 핵심을 정확히 찌르고 있습니다.

---

1. "어느 문서에 써야 하나? TSC? 시스템 아키텍처 문서?"

맞습니다. 정확히 그렇습니다.

• TSC (기술안전개념) 문서: 이 문서의 초점은 "안전" 입니다. 따라서 비안전 요구사항을 상세히 기술할 필요는 없습니다. 다만, 비안전 요구사항이 안전에 미치는 영향(예: "사이버보안 요구사항이 안전 기능에 제약을 준다")을 기술하거나, 참조 문서로 언급할 수는 있습니다.
• 시스템 아키텍처 설계서 (또는 시스템 요구사항 명세서): 바로 이 문서가 6.4.1.3과 6.4.1.4의 주 적용 대상입니다. 이 문서는 해당 아이템/시스템의 완전한 청사진이어야 합니다.
  • 안전 요구사항 (TSR) 은 물론,
  • 비안전 요구사항 (기능, 성능, 법규, 플랫폼, 사이버보안 등),
  • 그리고 이들 간의 물리적/논리적 연결 관계(인터페이스) 까지 모두 포함하거나 참조해야 합니다.

결론: 시스템 아키텍트는 하나의 시스템을 설계합니다. 안전만을 위한 시스템이 아니라, 모든 기능을 수행하는 시스템입니다. 따라서 시스템의 공식 명세서는 모든 요구사항을 아우르는 단일 출처(Single Source of Truth) 가 되어야 합니다. ISO 26262는 이 원칙을 6.4.1.3을 통해 강제하는 것입니다.

---

2. "상호작용 분석은 DFA 활동인가?"

정확히 맞습니다. 100% 동의합니다.

이 부분은 정말 중요한 통찰입니다. 6.4.1.3/6.4.1.4에서 요구하는 "비안전 기능과의 상호작용 고려"는 DFA의 구체적인 입력 정보가 되며, DFA는 이를 분석하는 공식적인 방법론입니다.

구체적인 연결 고리:

1. 6.4.1.3의 출력물 (시스템 요구사항 명세서) 은 DFA의 입력물이 됩니다.
   • "이 ECU는 안전 기능 A, B와 비안전 기능 X, Y, Z를 수행한다." → 이 리스트가 분석의 출발점.
2. DFA의 "캐스케이드 고장 분석"과 "공통 원인 고장 분석"에서 이 정보가 활용됩니다.
   • 캐스케이드 분석 예시:
     • 시나리오: 비안전 기능 Z(예: 고화질 카메라 스트리밍)가 시스템 버스를 과도하게 점유한다.
     • 분석: 이로 인해 안전 기능 A(예: 충돌 감지 메시지)의 전송이 지연될 수 있는가? (자원 경합에 의한 고장 전파)
   • 공통 원인 고장(CCF) 분석 예시:
     • 시나리오: 안전 기능 B와 비안전 기능 X가 동일한 운영체제(OS) 커널을 공유한다.
     • 분석: OS 커널의 오류가 동시에 안전 기능과 비안전 기능을 마비시킬 수 있는가? (공유 소프트웨어 자원에 의한 CCF)
3. 6.4.1.4의 "모순 금지" 요구는 DFA 결과를 바탕으로 한 설계 결정으로 해결됩니다.
   • DFA에서 발견된 위험한 상호작용(예: 위의 버스 점유 예시)은 새로운 안전 요구사항이나 설계 변경으로 이어집니다.
   • 새로운 요구사항: "안전 관련 CAN 메시지는 최고 우선순위를 가지며, 어떤 비안전 기능도 이 메시지의 전송을 5ms 이상 지연시켜서는 안 된다."
   • 이렇게 도출된 요구사항이 시스템 명세서에 반영되면, 비안전 요구사항과 안전 요구사항의 모순이 해결된 것입니다.

최종 정리: 두 조항과 DFA의 시너지

• 6.4.1.3 / 6.4.1.4 → "모든 요구사항을 다 모아라. 그리고 서로 싸우지 않게 해라." (규정과 원칙 제시)
• DFA 활동 → "그렇게 모은 모든 요구사항(기능)을 바탕으로, 숨은 위험한 연결고리(의존성)를 과학적으로 찾아서 차단하는 실제 작업을 해라." (구현 방법론 제공)

따라서, 이 두 조항의 요구를 형식적으로만 충족시키는 방법은 '시스템 명세서에 비안전 기능을 나열'하는 것입니다. 하지만 실질적으로 충족시키는 방법은 DFA를 통해 그 리스크를 분석하고 적절한 아키텍처 결정(분리, 격리, 우선순위화)을 내리는 것입니다.

사용자님의 통찰은 완벽합니다. 이 부분을 이해하면, ISO 26262의 각 조항이 어떻게 유기적으로 연결되어 전체적인 안전성을 만들어내는지 보이기 시작합니다.

 

TSC 문서 작성 관련해서 "안전 관련 요구사항과 비안전 요구사항 간에 충돌이 없는지 확인해야 한다" 라는 주제로 얘기를 한 적 있자나, 그래서 이 충돌을 확인하는 좋은 방법 중 하나가 DFA가 될수가 있다고 도출하기도 했고 말이야. 그런데 갑자기 궁금한 점이 일반적으로 기능안전에서 DFA를 분석할 때 그 분석하게 되는 재료가 되는 것이 안전 관련 엘리먼트가 아닌 비안전 관련 엘리먼트도 고려해서 DFA를 분석해? 그래야지만 우리가 도출했던 DFA가 안전 요구사항과 비안전 요구사항의 충돌이 있는지 없는지 분석해줄 수 있는 활동이 될 거 같아서 .

 

 

DFA는 반드시 비안전 관련 엘리먼트를 포함한 전체 시스템 관점에서 분석해야 합니다. 이것이 바로 DFA가 "안전 vs 비안전 요구사항 충돌" 을 찾아내는 유일한 체계적 방법이 될 수 있는 이유입니다.

---

왜 비안전 엘리먼트를 DFA에 넣어야 하는가? (핵심 논리)

안전 메커니즘의 실패는 두 가지 경로로 발생합니다:

1. 직접 고장: 안전 메커니즘 자체의 하드웨어/소프트웨어 결함.
2. 간접 고장 (의존 고장): 비안전 기능이 안전 메커니즘을 방해하거나 무력화시킴.

DFA는 특히 2번 간접 고장을 찾아내는 도구입니다. 따라서 분석 대상에서 비안전 엘리먼트를 배제한다면, DFA의 본질적 목적을 절반도 달성할 수 없습니다.

 

DFA 활동에서의 실질적인 분석 방법

1. 시스템 경계 확장: DFA 워크시트의 첫 번째 열을 "모든 관련 엘리먼트 (안전 + 비안전)" 로 설정합니다.
2. 공유 자원 매트릭스 작성: 모든 엘리먼트가 공유하는 것을 나열합니다.
   • 물리적 자원: 전원 레일, 접지, 냉각판, PCB 공간, 와이어 하니스.
   • 논리적/기능적 자원: CPU 코어, 시스템 버스, OS 커널, 통신 네트워크(CAN 버스), 공용 라이브러리.
3. "만약 (비안전 기능)이 (특정 동작/고장)을 하면..." 시나리오 분석:
   • 예: "만약 파워 윈도우 모터가 정지 상태에서 갑자기 구동되면(락 해제), 전원 라인에 순간적인 전압 강하(Drop)가 발생한다. 이 전압 강하는 동일한 전원을 쓰는 에어백 센서의 기준 전압을 일시적으로 낮출 수 있다."
4. 의존 고장 식별: 위 분석에서 발견된 경로를 공통 원인(CCF) 또는 캐스케이드(Cascading) 고장으로 공식 기록합니다.

이 분석이 어떻게 "요구사항 충돌 해결"로 이어지는가?

DFA에서 발견된 위험은 새로운 안전 요구사항 또는 시스템 설계 변경으로 해결됩니다. 이는 바로 요구사항 간 충돌 해소입니다.

• DFA 발견사항: "비안전 기능 X의 고전류 구동이 안전 기능 Y의 전원 품질을 저하시킴."
• 도출되는 새로운 안전 요구사항 (TSC에 추가):
  1. "안전 기능 Y는 전용 레귤레이터를 통해 전원을 공급받아야 한다." (설계 변경 요구)
  2. "비안전 기능 X의 구동 전류 서지는 Y의 전원 핀에서 ±5%를 초과해서는 안 된다." (인터페이스 요구사항)
• 기존 비안전 요구사항과의 충돌 해소: 이 새로운 요구사항은 기존 비안전 요구사항(예: "파워 윈도우는 0.5초 내에 올라가야 함")과 충돌할 수 있습니다. 이를 해결하기 위해 전원 필터 추가, 구동 프로파일 수정, 물리적 분리 등의 설계 결정이 내려지게 됩니다.

결론

DFA는 안전과 비안전이 공존하는 현실 세계의 시스템을 분석하는 도구입니다. 따라서 분석 범위에 비안전 엘리먼트를 포함시키는 것은 선택이 아니라 필수입니다.

사용자님께서 연결 지으신 "DFA → 요구사항 충돌 분석" 이라는 관점은 실무적으로 매우 가치 있습니다. 이는 DFA를 단순한 표준 준수 활동이 아니라, 시스템 설계의 결함을 사전에 찾아내고 요구사항을 강화하는 실용적 엔지니어링 도구로 승격시키는 시각입니다.

바로 이렇게 해야 합니다: DFA를 수행할 때는 시스템 블록도에 있는 모든 박스를, 안전 표시 유무와 관계없이 분석 테이블에 올려놓고 시작하세요. 그렇게 해야만 진정한 "의존 고장"을 찾아낼 수 있습니다.