Safety case 추적성 작성 수준

safety case 작성할 때, 고객의 요구사항부터 그것을 기반으로 개발되어진 산출물들의 모든 요구사항들이 빠짐없이 기록되어야 해? 아니면 safety case가 안전 목표를 위배하지 않는 다는 주요 논거를 내세운 것과 관련된 요구사항들만 보여줘도 돼?

 

Safety Case 작성 시에는 모든 요구사항을 빠짐없이 기록할 필요는 없습니다. Safety Case는 시스템이 **안전 목표(Safety Goals)**를 달성하고, 결과적으로 **허용 가능한 리스크(Acceptable Risk)**를 유지하고 있음을 입증하는 **주요 논거(Safety Argument)**에 초점을 맞춰야 합니다.

핵심은 **안전 관련 요구사항(Safety Requirements)**과 그를 충족하는 **증거(Evidence)**를 명확하게 보여주는 것입니다.

---

🚦 Safety Case 작성 시 요구사항 포함 원칙

1. 🎯 범위의 핵심: 안전 관련 요구사항 (Safety-Related Requirements)

Safety Case는 **ISO 26262 Part 2 (General Safety Management)**에 따라 작성됩니다. 여기서 요구하는 핵심은 시스템의 안전성(Safety) 입증입니다. 따라서 다음 요구사항들만 집중적으로 다루어야 합니다.

• Safety Goals (안전 목표): HARA(Hazard Analysis and Risk Assessment)에서 도출된 최상위 안전 목표.
• Functional Safety Requirements (기능 안전 요구사항): Safety Goal을 달성하기 위해 시스템이 수행해야 할 기능적 요구사항 (FSC 기반).
• Technical Safety Requirements (기술 안전 요구사항): 기능 안전 요구사항을 하드웨어 및 소프트웨어 레벨에서 구현하기 위한 구체적인 기술 요구사항 (TSC 기반).
• Hardware Safety Requirements & Software Safety Requirements: 시스템, 하드웨어, 소프트웨어의 안전 설계 및 구현 관련 요구사항.

2. 🧩 Safety Case의 논리적 구성 (Argumentation Structure)

Safety Case는 일반적으로 G-S-N (Goal-Strategy-Evidence/Solution) 구조를 따르며, 논거를 뒷받침하는 요구사항만 포함됩니다.

3. 🚫 일반 요구사항 제외

고객의 요구사항 중 안전과 직접적인 관련이 없는 일반적인 기능 요구사항 (예: 사용자 인터페이스 색상, 특정 통신 프로토콜의 일반 성능, 비안전 관련 진단 기능 등)은 Safety Case의 핵심 논거에서 제외해야 합니다.

• Safety Case가 방대해지고 핵심 주장이 흐려지는 것을 방지해야 합니다.
• 이러한 요구사항은 개발 문서(Requirements Specification)에 기록되지만, Safety Case에서는 **참조(reference)**만 되거나 완전히 생략될 수 있습니다.

---

📋 Confirmation Review 시 체크 포인트

Confirmation Review를 수행하는 담당자로서 Safety Case를 검토할 때, 요구사항 관련하여 다음을 체크해야 합니다.

1. 안전 요구사항의 완결성: 모든 Safety Goal이 완벽하게 Functional $\rightarrow$ Technical $\rightarrow$ SW/HW 요구사항으로 **분해(Decomposition)**되고, Safety Case에 명시되었는가?
2. 안전 요구사항의 추적성: Safety Case가 제시하는 모든 안전 요구사항이 **최종 검증 및 유효성 확인 산출물(V&V Evidence)**과 **명확하게 추적(Trace)**되는가? $Safety\ Goals \leftrightarrow Functional\ Requirements \leftrightarrow Technical\ Requirements \leftrightarrow Tests\ Results$
3. 일관성: Safety Case에서 인용한 안전 요구사항 버전과 실제 개발 문서의 요구사항 버전이 일치하는가?

결론적으로, Safety Case는 시스템이 안전하다는 주장을 입증하기 위한 '법정 변호'와 같습니다. 이 주장을 뒷받침하는 데 필요한 가장 중요하고 핵심적인 안전 관련 요구사항과 그 증거에 집중해야 하며, 모든 일반적인 고객 요구사항을 나열할 필요는 없습니다.

 

일반 요구사항이 아닌 안전 요구사항인 것만 safety case에 기술해야 한다는 것은 알아 근데 그 안전 요구사항 중에서도 다음과 같은 상황에 대해서 물어보는 거야, 예를 들어 safety case가 안전 목표를 위배하지 않는 다는 것을 보여주기 위한 전략으로, sg을 달성하기 위해 FSR을 기준으로 Claim을 작성하고 그 claim에 대한 논거를 작성할 거야. 이런 전략일 때 논거를 주구장창 모든 요구사항을 만족시켰다고 길게 쓸 수 없어서, 기능 안전의 핵심적인 부분을 추려서 작성하게 되자나, 그 때 이렇게 핵심적인 부분의 논거와 직접적으로 관련된 안전 요구사항만 safety case에 추적이 되도록하면 되냐고 물어본 거였어

 

네, 맞습니다. 기능 안전의 핵심적인 부분을 추려서 작성하고, 그 핵심 논거(Claim)와 직접적으로 관련된 안전 요구사항만 Safety Case에 추적이 되도록 하면 충분합니다.

Safety Case는 전략적인 문서이며, 모든 요구사항을 나열하는 문서 저장소가 아닙니다.

---

1. 🛡️ Safety Case의 목적과 범위

Safety Case는 **"시스템이 안전하다"**는 결론을 설득력 있게 입증하는 것이 가장 큰 목적입니다.

핵심 원칙: 최소한의 충분한 증거

Safety Case는 다음의 논리적 연결을 중심으로 구성되어야 합니다 (G-S-N 구조).

1. Goal (안전 목표): 우리의 시스템이 이 목표를 달성했습니다.
2. Claim (주장/논거): 이를 달성하기 위해 우리는 A, B, C와 같은 핵심 안전 전략을 사용했습니다.
3. Evidence (증거): 이 전략(A, B, C)이 성공적으로 구현되었음을 입증하는 **주요 산출물(요구사항, 설계, 테스트)**을 참조합니다.

따라서 Safety Case에 포함되어야 하는 요구사항의 범위는 다음과 같습니다.

• 포함 대상: SG (Safety Goal), FSR (Functional Safety Requirement), 그리고 이 SG/FSR을 달성하는 데 필수적인 핵심 안전 메커니즘과 관련된 TSR/HSR/SSR.
• 제외/참조 대상: 핵심 논거의 직접적인 연결 고리가 아닌, 일반적인 개발 프로세스의 모든 세부 TSR/HSR/SSR. 이들은 별도의 개발 문서(예: 요구사항 명세서)에 기록되고, Safety Case에서는 **"모든 안전 요구사항은 [문서 참조]에 따라 개발되었다"**고 포괄적으로 언급하며 핵심적인 부분만 발췌하여 논거를 만듭니다.

---

2. 🧩 엔지니어링 관점: 핵심 논거의 구체화

실제 엔지니어링 프로젝트에서 수백, 수천 개의 세부 안전 요구사항이 도출됩니다. 이 모든 것을 Safety Case에 담는 것은 비효율적입니다.

① 핵심 Claim 중심의 논거 구성

SG를 위배하지 않는다는 것을 보여주기 위한 Claim은 보통 다음의 핵심 질문에 대한 답으로 구성됩니다.

Safety Case는 위와 같이 핵심 Claim을 구성하고, 이 Claim을 입증하는 데 결정적인 소수의 요구사항과 V&V 증거를 선택적으로 추적하여 보여줍니다.

② "선택적 추적"의 의미

Safety Case에서 "선택적 추적"을 사용할 때 주의할 점은 다음과 같습니다.

• 직접적인 연결 (Direct Link): 핵심 Claim과 관련된 요구사항은 SG $\leftrightarrow$ FSR $\leftrightarrow$ TSR/HSR/SSR의 추적 고리가 Safety Case 내에서 명시적으로 보여져야 합니다.
• 포괄적 참조 (Holistic Reference): 핵심 논거와 무관한 나머지 세부 요구사항들은 "모든 요구사항은 [문서명]에 따라 관리되고 충족됨"이라고 포괄적으로 언급하고 참조 문서를 명시함으로써, 완결성(Completeness)을 확보해야 합니다.

---

3. 🔎 Confirmation Review 시 검토자의 역할

Confirmation Review 담당자로서, 귀하의 역할은 이 논거가 "충분하고, 논리적이며, 객관적 증거로 뒷받침되는지" 확인하는 것입니다.

• Claim의 충분성 확인: Safety Case가 다루지 않은 중요한 위험 요소나 안전 메커니즘이 있는지 확인합니다. 만약 있다면, 이와 관련된 요구사항이 Safety Case의 논거에 빠져 있는 것은 큰 결함입니다.
• 추적의 깊이 확인: 핵심 논거와 관련된 요구사항이 최종적으로 **가장 낮은 레벨의 산출물(코드, 테스트 케이스)**까지 깨짐 없이 (unbroken) 추적되는지 샘플링하여 검증해야 합니다.

즉, 핵심적인 안전 논거에 필요한 안전 요구사항만 집중적으로 기술하고, 나머지는 문서 참조로 대체하여 논거의 설득력을 높이는 것이 Safety Case 작성의 올바른 전략입니다.