이 진단 시험 전략이라는 개념은 결함이 잠재되는 가능성이 있을 때 필요한 거지? 그니까 결함이 잠재되었다는 개념은 다중점 고장에서 가능한 일이니까, 다중점 고장이 발생 가능성이 있을 경우 진단 시험 전략이 필요하다는 거가 맞아? 객관적으로 대답해
객관적 답변: "아니요, 그 말은 틀렸습니다. 정반대입니다."
사용자님의 논리 구조를 분석해보겠습니다.
"결함이 잠재된다 → 잠재적 결함은 다중점 고장에서 발생 → 따라서 다중점 고장 가능성 있을 때 진단 시험 전략 필요"
이 논리의 핵심 오류는 원인과 결과를 뒤집은 것입니다.
올바른 논리 구조
실제 ISO 26262의 논리는 다음과 같습니다:
- 모든 시스템에는 단일점 고장(Single-Point Fault)이 발생할 가능성이 있습니다.
- 이 단일점 고장을 방치하면:
- a) 운전 중 바로 위험한 상태로 이어질 수 있습니다. (감지되지 않은 단일점 고장)
- b) 또 다른 고장(두 번째 고장)과 만나서 다중점 고장(Multiple-Point Fault)이 될 수 있습니다.
- 이때, b)의 경우에서 첫 번째 고장이 드러나지 않고 숨어 있는 상태를 '잠재적 고장(Latent Fault)'이라고 합니다.
- 진단 시험 전략의 핵심 목적은:
- a)를 방지하고, (단일점 고장이 바로 위험해지는 것)
- b)로 진행되는 것을 원천 차단하는 것입니다.
- 방법: 첫 번째 고장(단일점 고장)을 빠르고 확실히 찾아내서, 시스템을 안전한 상태로 만들고, 운전자에게 알리는 것입니다. 그러면 두 번째 고장이 와도 이미 시스템은 안전 모드이므로, 다중점 고장이 발생해도 안전합니다.
핵심 개념 재정의
- 다중점 고장의 가능성 ≠ 진단의 필요 조건
- 단일점 고장의 가능성 = 진단의 필요 조건
진단 시험 전략은 "다중점 고장이 생길지도 모르니, 그걸 감시하자"가 아닙니다.
"다중점 고장이 생기지 않도록, 첫 번째 고장이 생기자마자 바로 잡자" 입니다.
비유: 화재 안전 시스템
- 단일점 고장: 전기 콘센트에서 스파크 발생 (첫 번째 위험 요소).
- 다중점 고장: 스파크 + 근처에 휘발유 유출 (두 번째 위험 요소) → 대폭발.
- 잠재적 고장: 휘발유가 조용히 새고 있는 중인데 아무도 모름 (두 번째 위험 요소가 숨어 있음).
- 진단 시험 전략(화재 감지 시스템):
- "스파크(단일점 고장)를 감지하는 연기 감지기" 를 설치하고,
- 정기적으로 감지기 자체가 잘 작동하는지 테스트(자체 시험) 하며,
- 스파크 감지 후 30초 내(FTTI)에 스프링클러를 작동시켜(안전 조치) 화재(다중점 고장)가 나지 않도록 합니다.
이 시스템은 "휘발유가 새는 가능성(다중점 고장 가능성)"을 기다리지 않고, "스파크가 일어날 가능성(단일점 고장 가능성)" 에 대비하여 설치됩니다.
ISO 26262의 요구사항과 일치하는 정답
표준은 ASIL B, C, D 에 대해 단일점 고장 감지(SPF Detection) 를 요구하며, 그 성능을 단일점 고장 메트릭(SPFM) 으로 측정합니다. 다중점 고장은 이미 안전 메커니즘이 실패한 후의 상황을 나타내는 지표(잠재적 고장 메트릭, LFM)로 사용됩니다.
따라서 객관적 결론:
"진단 시험 전략은 다중점 고장 가능성 때문이 아니라, 단일점 고장이 발생할 수 있고, 그것이 (다중점 고장을 포함한) 안전 위반으로 이어질 수 있기 때문에 필요합니다. 다중점 고장 가능성은 진단 전략의 결과(막아야 할 대상)이지, 원인이나 조건이 아닙니다."
-----------------------------------------------------------------------------------------------------------------------------
표준 조항 개요
- 6.4.2.3 진단 시험 전략 (Diagnostic test strategy): 시스템 수준에서 안전 메커니즘의 진단 기능을 어떻게 설계할 것인지에 대한 전략과 원칙을 수립하라는 요구사항입니다.
- 6.4.2.4 자체 시험 (Self-test): 시스템 또는 요소가 스스로 자신의 고장을 검출하기 위해 수행하는 테스트에 대한 요구사항입니다. 진단 시험 전략의 주요 구현 수단 중 하나입니다.
- 6.4.2.5 사전 진단 범위 (Preemptive diagnostic coverage): 안전 관련 요소가 안전 요구사항을 위배하기 전에 고장을 검출할 수 있어야 한다는 요구사항입니다. FTTI 개념과 직접 연결됩니다.
1. 진단 시험 전략 (Diagnostic Test Strategy) - 6.4.2.3
이것은 "계획"입니다.
- 핵심 질문: "시스템에 내장된 안전 메커니즘(진단 기능)이 언제, 어떻게, 얼마나 자주, 무엇을 점검해야 안전을 보장할 수 있을까?"
- 주요 내용: 이 전략은 다음을 정의해야 합니다.
- 테스트 유형: 자체 시험, 비교 시험(Redundancy), 물리적 모니터링 등.
- 테스트 실행 시점:
- 시동 시 검사(Power-On Self-Test, POST): 전원이 켜질 때 한 번 실행.
- 주기적 검사(Periodic Test): 런타임 중 정해진 주기로 반복 실행.
- 요구 시 검사(On-Demand Test): 특정 조건(예: 저속 주행 시)에서 실행.
- 진단 테스트 간격(Diagnostic Test Interval): 주기적 검사의 주기. 이 간격은 고장이 발생했을 때부터 감지되기까지의 최대 시간을 정의하며, 이는 FTTI보다 짧아야 합니다.
- 테스트 응답: 테스트가 실패했을 때 취할 조치(예: 경고, 기능 제한, 대체 값 사용).
사용자님 이해 확인: 만약 "진단 시험 전략을 수립한다"는 것을 "시스템에 어떤 종류의 진단 기능을 도입할지 고르는 것" 정도로 이해하셨다면, 방향은 맞지만 충분하지 않습니다. 그것은 단순한 기법 선택이고, 진짜 전략은 "왜 그 기법을 선택했으며, 그것을 어떤 타이밍으로 운영하여 어떤 안전 목표를 달성할 것인가" 에 대한 체계적인 근거와 계획입니다.
2. 자체 시험 (Self-test) - 6.4.2.4
이것은 전략을 구현하는 "도구" 중 하나입니다.
- 핵심 질문: "이 요소(MCU, 메모리, 로직 회로)가 스스로 정상적으로 작동하는지 어떻게 확인할 것인가?"
- 주요 내용:
- 시동 자체 시험(Initiation self-test): 6.4.2.4.a. 시스템이 안전 관련 기능을 수행하기 전에 실행되는 테스트. (예: MCU가 주요 제어를 시작하기 전에 코어 레지스터, 플래시 메모리 무결성 점검).
- 주기적 자체 시험(Periodic self-test): 6.4.2.4.b. 런타임 중 주기적으로 실행되어, 시동 후에 발생한 고장(예: 단일 비트 오류)을 감지.
- 실행 시간: 자체 시험의 실행 시간은 FTTI에서 고려해야 합니다. 즉, 테스트가 너무 오래 걸려서 고장 감지 후 안전 조치를 취할 시간이 없어서는 안 됩니다.
사용자님 이해 확인: "자체 시험 = POST"로만 이해하셨다면 부족합니다. POST는 시동 자체 시험의 대표적 예시일 뿐이며, 주기적 자체 시험이 훨씬 더 중요하고 복잡합니다. (예: 런타임 중 메모리의 ECC 검사, CPU 코어의 논리 유닛 테스트, ADC 회로의 기준 전압 점검).
3. 사전 진단 범위 (Preemptive Diagnostic Coverage) - 6.4.2.5
이것은 전략과 테스트가 달성해야 하는 "목표"이자 "성능 기준"입니다.
- 핵심 개념: FTTI (Fault Tolerant Time Interval)
- 핵심 요구사항: 고장이 발생한 순간부터, 그 고장이 안전 목표를 위배할 수 있는 위험한 상태(Failure)로 발전하기 전까지의 시간이 있습니다. 이 시간을 FTTI라고 합니다.
- 진단 기능(자체 시험 포함)은 이 FTTI 내에 고장을 반드시 감지하고, 적절한 안전 조치를 완료해야 합니다.
- "사전 진단" 이란 바로 이 FTTI 시간 안에 고장을 찾아내서, 안전 위반을 사전에(preemptively) 막는다는 의미입니다.
사용자님 이해 확인: 이 개념을 "빨리 진단해야 한다"는 정도로 이해하셨다면, FTTI라는 구체적인 시간 제약과 연결지어 생각해야 합니다. 모든 진단 활동은 이 FTTI 타임라인에 맞춰 설계됩니다.
종합 관계도: "전략 → 도구 → 목표"의 흐름
사용자님 이해 평가 및 정리
- 맞는 이해: 두 개념이 시스템 설계 시 고려해야 할 내장형 진단과 관련있으며, 서로 연관되어 있다는认识은 정확합니다.
- 보강이 필요한 이해 (혹시 해당된다면):
- 진단 시험 전략은 단순한 방법론 목록이 아닌, FTTI를 기반으로 한 구체적인 시행 계획서입니다.
- 자체 시험은 POST뿐만 아니라, 런타임 중 지속적으로 수행되는 주기적 테스트가 핵심입니다.
- 이 모든 것의 궁극적인 목표는 6.4.2.5의 "사전 진단 범위" 확보, 즉 FTTI 내에 고장을 감지하여 안전 위반을 예방하는 것입니다.
틀린 점을 고치자면: 만약 두 개념을 동등한 수준의 병렬 활동으로 보셨다면, 그것은 "전략(Strategy)" 과 "기법(Tactic)" 의 관계로 재정립해야 합니다. 진단 시험 전략이 상위 개념이고, 자체 시험은 그 전략을 구현하는 주요 수단 중 하나입니다.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
ISO 26262 Part4에 있는 요구사항을 보여줄테니까, 너가 기능안전에 전반적으로 공부해보고 분석한 결과로 내가 다음에 보여줄 문구에 대해 해석 해줘. 특히, 안전 메커니즘에 대한 진단 테스트 전략이 대체 무슨 뜻인지? 즉 나는 궁금한게 모든 안전 메커니즘을 만들때 그 안전 메커니즘에 대한 진단 메커니즘이 모두 존재해야만 하는 건지 궁금해. 자 그 해당 문구를 보여줄게 "6.4.2.4 This requirement applies to ASILs (A), (B), C, and D. To avoid multiple‑point failures, the diagnostic test strategy shall be specified for each safety mechanism implemented to detect multiple-point faults, considering: a) the reliability requirements of the hardware components with consideration given to their role in the architecture and their contribution to a multiple-point failure; b) the specified quantitative target values for the maximum probability of violation of each safety goal due to random hardware failures (see ISO 26262-5:2018, Clause 9); c) the assigned ASIL derived from the related safety goal, the related functional safety requirement or technical safety requirement at a higher hierarchical level; and d) the multiple-point fault detection time interval. NOTE 1 The diagnostic test strategy can be time driven (e.g. using the diagnostic test time interval) or event driven (e.g. a start-up test). NOTE 2 A second-order multiple-point failure comprises two faults, separated by the multiple-point fault detection time interval. NOTE 3 The use of the following measures depends on the time constraints: — periodic testing of the system or elements during operation; — self-tests of elements during power-up or power-down; and — testing the system or elements during maintenance."
제공된 문구(ISO 26262-4:2018, 6.4.2.4)의 해석
먼저, ISO 26262 표준 전체를 배경으로 설명하겠습니다. ISO 26262는 자동차 전기/전자(E/E) 시스템의 기능 안전(Functional Safety)을 위한 국제 표준으로, 2018년 버전(2nd Edition)이 현재 주로 사용되며, Part 4는 시스템 수준의 제품 개발(Product development at the system level)을 다룹니다. 이 표준은 위험 기반 접근으로, ASIL(Automotive Safety Integrity Level) 등급(QM, A~D)에 따라 안전 요구사항을 정의합니다. 기능 안전의 핵심은 하드웨어/소프트웨어 실패가 안전 목표(Safety Goal)를 위반하지 않도록 하는 것입니다. 실패는 단일 포인트 실패(Single-Point Failure, SPF), 다중 포인트 실패(Multiple-Point Failure, MPF) 등으로 분류되며, MPF는 여러 결함이 누적되어 발생하는 실패를 의미합니다. 안전 메커니즘(Safety Mechanism)은 이러한 실패를 감지, 방지, 또는 완화하는 기술적 솔루션(예: 중복성, 오류 검출 코드, 워치독 타이머 등)입니다.
이제 제공된 문구를 단계적으로 해석하겠습니다. 이 해석은 표준의 맥락(Part 5: 하드웨어 수준 개발, Part 9: ASIL 분해 등)과 연계하여, 기능 안전 전문 지식을 바탕으로 한 분석입니다.
1. 전체 요구사항의 개요
- 적용 범위: ASIL (A), (B), C, D에 적용(ASIL A는 상대적으로 낮지만 여전히 포함, QM은 제외). 이는 안전 요구사항이 있는 시스템에만 해당합니다.
- 목적: MPF를 피하기 위해, MPF를 감지(detect)하도록 구현된 각 안전 메커니즘에 대해 "diagnostic test strategy"를 지정(specify)해야 합니다.
- MPF(Multiple-Point Failures): 여러 결함(예: 두 개 이상의 독립적 결함)이 시간 간격을 두고 발생해 안전 목표를 위반하는 경우. 표준에서 "second-order MPF"는 두 개의 결함으로 구성되며, 첫 번째 결함이 감지되지 않고 잠재(latent) 상태로 남아 두 번째 결함과 결합될 수 있습니다.
- 이를 피하기 위해 안전 메커니즘(예: 오류 검출 메커니즘)이 MPF를 감지하지만, 이 안전 메커니즘 자체가 실패할 수 있으므로(예: latent fault), 이를 진단하는 전략이 필요합니다.
2. "Diagnostic Test Strategy"가 무슨 뜻인지?
- 정의와 의미: Diagnostic test strategy는 안전 메커니즘(특히 MPF를 감지하는 메커니즘)이 제대로 작동하는지 확인하는 테스트 계획/방법론입니다. 이는 "진단(diagnostic)" + "테스트 전략(test strategy)"으로, 안전 메커니즘의 신뢰성을 보장하기 위한 체계적 접근입니다. 단순히 "테스트"가 아니라, 전략(strategy)으로서 시간 간격, 이벤트 트리거, 커버리지 등을 고려한 포괄적 계획을 의미합니다.
- 왜 필요? 안전 메커니즘은 시스템의 실패를 감지하지만, 메커니즘 자체가 고장 나면(예: 센서 오류 검출 회로가 고장), MPF가 undetected 상태로 남아 안전 목표를 위반할 수 있습니다. 따라서 메커니즘의 "건강 상태"를 주기적으로 진단하여 latent faults를 조기에 발견합니다. 이는 "메타 진단"처럼, 안전 메커니즘의 실패를 감지하는 추가 레이어입니다.
- 구체적 내용(문구의 a~d 고려사항):
- a) 하드웨어 컴포넌트의 신뢰성(reliability requirements): 컴포넌트의 역할과 MPF 기여도를 고려. 예: 고장률(FIT, Failure In Time)이 높은 부품은 더 빈번한 진단 필요.
- b) 안전 목표 위반 확률의 정량적 목표(quantitative target values): Part 5 Clause 9에서 정의된 랜덤 하드웨어 실패로 인한 안전 목표 위반 확률(예: ASIL D는 10^-8/h 이하)을 충족하도록. 진단 전략은 이 목표를 달성하기 위한 diagnostic coverage(진단 범위, 예: 99% 이상 faults 감지)를 보장합니다.
- c) 상위 수준의 ASIL: 관련 안전 목표, 기능 안전 요구(FSR), 기술 안전 요구(TSR)에서 유도된 ASIL. 높은 ASIL(예: D)일수록 엄격한 전략(예: 더 짧은 테스트 간격) 필요.
- d) MPF 감지 시간 간격(multiple-point fault detection time interval): 첫 번째 결함 후 두 번째 결함이 발생하기 전에 감지해야 하는 시간. 이는 latent fault의 "existence time"을 제한합니다.
- 노트(Note)의 설명:
- NOTE 1: 시간 기반(time driven, 예: 주기적 테스트 간격) 또는 이벤트 기반(event driven, 예: 시작 시 테스트)일 수 있음. 실시간 시스템에서는 시간 기반이 일반적.
- NOTE 2: Second-order MPF는 두 결함으로, 감지 시간 간격으로 분리됨. 전략은 이 간격 내에 첫 결함을 진단해야 함.
- NOTE 3: 시간 제약에 따라 조치 선택:
- 운영 중 주기적 테스트(periodic testing).
- 전원 온/오프 시 셀프 테스트(self-tests).
- 유지보수 중 테스트. 이는 전략의 유연성을 강조하며, 프로젝트 테일러링(이전 대화에서 언급)으로 최적화할 수 있습니다.
- 예시: 에어백 시스템의 센서 안전 메커니즘(센서 오류 감지)이 MPF를 다룰 경우, 진단 전략은 매 10ms마다 센서 회로를 테스트(parity check 등)하여 latent fault를 발견하도록 지정. 이는 formal verification이나 fault injection 테스트로 검증됩니다.
3. 모든 안전 메커니즘에 진단 메커니즘이 반드시 존재해야 하는가?
- 답변: 아니오, 모든 안전 메커니즘에 반드시 "진단 메커니즘(diagnostic mechanism)"이 별도로 존재해야 하는 것은 아닙니다. 하지만 MPF를 감지하도록 구현된 안전 메커니즘에는 diagnostic test strategy가 필수적으로 지정되어야 합니다.
- 이유와 세부 분석:
- 문구에서 "each safety mechanism implemented to detect multiple-point faults"로 한정됨. 즉, MPF 감지용 안전 메커니즘(예: 중복 센서 비교, ECC 코드)에만 적용. SPF 방지용 메커니즘(예: 단순 중복성)이나 비감지형 메커니즘(예: fail-safe 설계)에는 이 요구사항이 직접 적용되지 않을 수 있습니다.
- 그러나 실제로 많은 안전 메커니즘은 진단 요소를 내장하거나 연계합니다. 예: fault detection 메커니즘은 자체나 다른 메커니즘의 진단을 포함(예: self-test). ISO 26262는 "안전 메커니즘의 안전 메커니즘"처럼 계층적 접근을 권장하지만, 모든 경우에 강제하지 않습니다. 대신, ASIL 수준에 따라 다릅니다 – ASIL D에서는 거의 모든 MPF 관련 메커니즘에 고커버리지 진단이 필요하지만, ASIL A에서는 간소화 가능.
- 예외와 고려: 모든 안전 메커니즘이 진단을 필요로 하지 않는 이유는 효율성 때문. 표준은 불필요한 복잡성을 피하기 위해 테일러링을 허용합니다. 하지만 MPF나 latent faults를 다루는 경우, 진단 없이는 quantitative target(예: failure rate)을 충족할 수 없어 사실상 필수. LinkedIn 분석처럼, 진단은 안전 메커니즘의 효과성을 보장하는 핵심으로, 특히 높은 ASIL에서 MPF mitigation에 필수적입니다.
- 실제 적용: 안전 메커니즘 삽입 시, exploration → insertion → validation → fault injection의 4단계 workflow를 사용하면 진단 전략을 체계적으로 정의. 여기서 formal fault injection으로 diagnostic coverage를 측정합니다.
- 이유와 세부 분석:
4. 결론과 추천
이 문구는 기능 안전에서 MPF의 위험을 강조하며, 안전 메커니즘의 신뢰성을 보장하기 위한 진단 전략을 요구합니다. 이는 "안전의 안전"을 추구하는 ISO 26262의 철학과 맞물립니다. 만약 모든 안전 메커니즘에 진단을 강제하면 과도한 비용이 발생할 수 있으므로, 표준은 MPF 감지용에 초점을 맞춥니다. 프로젝트에서 이를 구현할 때는 안전 분석(FMEA, DFA 등)으로 정당화해야 합니다.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
1. 잠재적 결함(Latent Fault)의 본질
- 정의: "다중점 결함이 있는 랜덤 하드웨어 결함만이 잠재될 가능성을 가진다." (6.4.2.3 비고 1)
- 해석: 단일점 고장은 운전 중 직접적인 영향(위험)을 줄 수 있어 '잠재'되기 어렵습니다. 오직 두 번째 고장과 만나서야 비로소 위협이 되는 첫 번째 고장이, 그 두 번째 고장이 발생하기 전까지 드러나지 않고 숨어 있는 상태를 '잠재적 결함' 이라 합니다.
2. 자체 시험(Self-test)의 역할
- 정의: "...다중점 결함을 검출하기 위해서 컴포넌트의 상태를 검증하는 안전 메커니즘이다." (6.4.2.3 보기)
- 목표: 잠재적 결함이 되기 전의 '첫 번째 고장'을 찾아내는 것입니다.
- 실행 시점: 전원 켬, 전원 끔, 운용 중, 별도의 시험 모드 (다양한 운용 모드).
3. 진단 시험 전략(Diagnostic Test Strategy)의 필요 조건과 목표
- 명시된 목표: "다중점 고장을 피하기 위해" (6.4.2.4 서문)
- 해석: '다중점 고장'이라는 결과를 피하기 위한 전략을 수립하라는 것입니다. 즉, 예방적 전략입니다.
- 입력 조건 (규정 시 고려사항):
- a) 하드웨어 컴포넌트의 역할과 신뢰성: 어떤 부품이 다중점 고장에 얼마나 기여하는지.
- b) 안전 목표 위배 최대 확률(PMHF)의 정량적 목표값: 시스템 전체의 확률적 안전 목표.
- c) 부여된 ASIL: 요구되는 엄격도.
- d) 다중점 결함 검출 시간 간격: 첫 번째 고장을 찾을 수 있는 최대 허용 시간.
개념 간의 종합적 관계: "왜(Why) → 무엇을(What) → 어떻게(How)"
다음 다이어그램은 발췌한 표준의 핵심 개념들이 어떻게 연결되어 작동하는지 보여줍니다:
아키텍처 메트릭 및 PMHF와의 연관성 설명
위 다이어그램의 관계를 자세히 설명하면:
- 출발점: PMHF (Probabilistic Metric for random Hardware Failures)
- Part 5의 9절에서 요구하는 확률적 목표값입니다. "이 시스템이 랜덤 하드웨어 고장으로 인해 안전 목표를 위배할 확률은 10⁻⁸/h 미만이어야 한다" 같은 식입니다.
- 진단 시험 전략 수립 시, 이 목표값(b)을 달성할 수 있도록 설계해야 합니다.
- 진단 시험 전략의 실행 → 아키텍처 메트릭 생성
- 전략에 따라 구현된 자체 시험을 포함한 모든 안전 메커니즘이 얼마나 효과적인지 수치화한 것이 아키텍처 메트릭입니다.
- SPFM (Single-point Fault Metric): 단일점 고장이 안전 목표 위반으로 이어지지 않도록 막은 비율. (진단이 잘 되어 안전 조치가 취해진 경우)
- LFM (Latent-fault Metric): 다중점 고장이 잠재적 결함이 되지 않도록 (즉, 검출되어) 막은 비율.
- 이 메트릭들은 진단 시험 전략의 성능 지표입니다.
- 완결된 논리 고리
- 진단 시험 전략을 수립(a-d 고려) → 자체 시험 등을 구현 → 아키텍처 메트릭(SPFM, LFM) 계산 → 계산된 메트릭과 고장률 데이터로 PMHF 계산 → PMHF 목표값(b) 충족 여부 확인.
- 충족 실패 시, 진단 시험 전략(예: 더 짧은 검출 간격(d), 더 강력한 자체 시험)을 재설계해야 합니다.
6.4.2.5 (안전 메커니즘 개발 ASIL)의 의미
- 이는 "잠재적 결함을 방지하기 위한 안전 메커니즘(예: 자체 시험 기능) 자체도 고장날 수 있으니, 그것을 개발할 때도 일정 수준의 안전성(ASIL)을 보장하라" 는 요구사항입니다.
- 예시: ASIL D 기능을 보호하는 자체 시험 루틴은 최소한 ASIL B로 개발해야 합니다.
- 이유: 안전 메커니즘이 자체적으로 고장나면, 그 메커니즘이 감시하던 주요 기능의 고장을 찾을 수 없게 되어 잠재적 결함 발생 위험이 급증하기 때문입니다.
최종 정리: 사용자님 질문에 대한 명확한 답변
발췌문을 근거로 할 때:
- "다중점 고장 가능성"은 진단 시험 전략의 입력 조건이나 필요 조건이 아니라, 피해야 할 결과(목표)입니다.
- 표준은 "다중점 고장을 피하기 위해" 진단 시험 전략을 수립하라고 말합니다(예방). "다중점 고장 가능성이 있어서" 수립하라고 말하지 않습니다(대응).
- 자체 시험은 이 전략을 구현하여 잠재적 결함(미검출 다중점 결함)의 형성을 방지하는 구체적인 도구입니다.
- 모든 것은 궁극적으로 PMHF라는 확률적 안전 목표를 달성하고, SPFM/LFM이라는 아키텍처 메트릭을 충족시키기 위해 연결됩니다.
따라서, 발췌된 표준 문구는 제가 이전에 설명드린 "진단은 다중점 고장을 예방하기 위해 존재한다" 는 해석을 확고히 지지합니다.
진단 시험 전략을 명세하는 문서와 위치
일반적으로 다음 두 가지 문서 중 하나 또는 모두에 명세합니다.
1. 기술안전개념 문서 (TSC - Technical Safety Concept) - 최선의 선택
- 위치: TSC 내 "안전 메커니즘 및 진단 전략" 또는 "하드웨어-소프트웨어 안전 요구사항 할당" 챕터.
- 이유: TSC는 시스템 수준의 모든 안전 개념을 종합하는 문서입니다. 진단 시험 전략은 안전 메커니즘의 핵심 운영 원칙이므로, 이곳에 명세하는 것이 가장 논리적입니다.
2. 별도의 진단 전략 문서 (Diagnostic Strategy Document) - 복잡한 시스템에 적합
- 위치: TSC에서 참조되는 하위 레벨 전용 문서.
- 이유: 시스템이 매우 복잡하거나(예: 자율주행), 진단 아키텍처가 독립적일 경우 유용합니다.
문서에 "어떻게" 명세해야 하는가? (구체적인 템플릿)
다음은 TSC에 포함될 진단 시험 전략 명세의 표준 형식입니다. 표준(6.4.2.4)이 요구하는 네 가지 고려사항(a, b, c, d)을 모두 반영해야 합니다.
예시: TSC 문서 내 "7.3 진단 시험 전략" 절
7.3 진단 시험 전략 (Diagnostic Test Strategy)
본 아이템의 안전 목표를 달성하고, 다중점 고장 및 잠재적 결함을 방지하기 위해 다음과 같은 진단 시험 전략을 수립한다.
1. 전략 원칙 (General Strategy)
- 진단은 시간 주도형(Time-Driven) 과 사건 주도형(Event-Driven) 을 혼용한다.
- 모든 안전 관련 요소에 대한 진단 테스트 간격은 해당 요소의 FTTI(Fault Tolerant Time Interval) 보다 짧게 설정한다.
- 진단 불능 상태를 방지하기 위해, 진단 기능 자체에 대한 주기적 자체 시험을 구현한다.
2. 진단 대상별 상세 전략 (Detailed Strategy per Diagnostic Target)
3. 전략 수립 근거 (Justification)
- 진단 테스트 간격 도출 근거: 각 간격은 해당 요소의 FTTI 분석 결과와 요소의 고장률(고려사항 a) 데이터를 바탕으로 설정되었으며, 시스템 전체 PMHF 목표값(고려사항 b: 예: 10⁻⁸/h) 을 달성할 수 있음을 시뮬레이션으로 확인함.
- ASIL 준수(고려사항 c): 표에 명시된 ASIL에 따라, 진단 메커니즘의 개발 ASIL은 6.4.2.5조(예: ASIL C 기능의 진단은 ASIL A로 개발)를 준수함.
4. 구현 정보 (Implementation Information)
- 본 전략은 시스템 아키텍처 설계서 [문서번호]에 하드웨어 및 소프트웨어 블록으로 구체화된다.
- 소프트웨어 요구사항 명세서 [문서번호]에는 주기적 작업(Periodic Tasks), 인터럽트 서비스 루틴(ISR), 및 진단 함수의 상세 요구사항으로 전개된다.
- 하드웨어 설계서 [문서번호]에는 전용 모니터링 회로(감시 IC, 비교기)의 설계로 반영된다.
주요 문서와의 추적성 (Traceability)
이 명세는 다른 문서와 다음과 같이 연결되어야 합니다.
- 상위로의 추적 (Upward Traceability):
- TSC의 진단 전략 표에 있는 각 행은 하나 이상의 기술적 안전 요구사항(TSR) 에 연결되어야 합니다.
- 예: "스로틀 센서 비교 시험" 전략 ← TSR-123: 스로틀 센서 불일치 10ms 내 감지
- 하위로의 전개 (Downward Allocation):
- 표의 각 "진단 메커니즘"은 시스템/하드웨어/소프트웨어 요구사항으로 구체화됩니다.
- 예: "CRC 기반 무결성 검사" →
- HW 요구사항: "플래시 메모리 영역에 대한 CRC 계산을 위한 하드웨어 가속기 지원"
- SW 요구사항: "100ms 태스크는 Diag_FlashCRC() 함수를 호출하여 결과 확인"
- 검증으로의 연결 (Link to Verification):
- 전략 표의 "진단 테스트 간격"과 "실행 모드"는 검증 계획서의 테스트 케이스 작성 근거가 됩니다.
- 예: "시험: 5ms 주기의 전원 모니터링 진단 기능 시험. 방법: 5V 레귤레이터 출력을 4V로 강제하고, 5ms 이내에 진단 플래그 설정 여부를 오실로스코프로 관측."
결론: 이렇게 하세요.
- 문서: TSC 문서 내 한 절으로 만드세요. 별도 문서는 관리 부담만 늘립니다.
- 형식: 표(Table) 형식을 사용하세요. 표준이 요구하는 고려사항(a, b, c, d)을 누락 없이 한눈에 담을 수 있습니다.
- 본질: 단순한 목록이 아닌, "FTTI와 PMHF 목표를 달성하기 위한 공학적 근거가 담긴 설계 결정문" 이어야 합니다.
- 생생함: "~해야 한다"는 요구사항 문장과 함께, "~이러한 이유로 이렇게 정했다" 는 근거(Justification)를 반드시 포함하세요.
'기능안전_기본이론' 카테고리의 다른 글
| 소프트웨어 상세 설계서(BSW-Application) (0) | 2025.09.01 |
|---|---|
| fault injection (0) | 2025.09.01 |
| variants존재 판단 여부 (0) | 2025.08.26 |
| 26262 Part4에 의문인 구절 (0) | 2025.08.26 |
| QM VS 안전과 무관한 일반 요구사항 (0) | 2025.08.26 |