이전 주제와 다른 질문인데, 기능안전 관련해서 TSR 문서 있자나, TSR이 어떻게 보면 ASPICE프로세스 관점에서 볼 때, 시스템 요구사양서 문서에 해당되는 거 같은데, (물론 다른 점도 많지만), 아무튼 ASPICE에서 시스템 요구사양서 문서에는 각 요구사항에 대한 verification criteria를 명시해야 되는 거로 알고 있거든? 마찬가지로 TSR 문서도 각 요구사항에 대한 verification criteria가 있어야 할까? 주관적인 판단으로 먼저 답하기 전에 실제 모범 자료들을 먼저 분석하고 너의 생각을 말해줘
네, 맞습니다. TSR(Technical Safety Requirements) 문서도 각 요구사항에 대한 **검증 기준(Verification Criteria)**을 명시해야 합니다. 이는 ASPICE와 ISO 26262 모두에서 요구하는 필수적인 활동입니다.
ASPICE와 ISO 26262 관점에서의 검증 기준
ASPICE와 ISO 26262는 모두 V-모델을 기반으로 개발 프로세스를 정의하며, 각 단계의 산출물은 다음 단계의 입력이 되고, V-모델의 오른쪽 단계(통합, 검증, 유효성 확인)에서 이전 단계의 요구사항이 충족되었는지 확인하는 것을 강조합니다.
- ASPICE: ASPICE의 SYS.2(System Requirements Analysis) 프로세스는 "시스템 요구사항이 정확성 및 **검증 가능성(verifiability)**에 대해 분석되고 분류된다"고 명시합니다. 이는 모든 시스템 요구사항이 테스트 가능해야 함을 의미하며, 이를 위해 요구사항에 대한 구체적인 검증 기준을 정의하는 것이 가장 좋은 방법입니다.
- ISO 26262: ISO 26262 파트 8(지원 프로세스)의 9.5절은 검증 활동에 대해 정의하고 있습니다. 이 절에 따르면, 검증 계획에는 "검증 대상인 작업 산출물의 목적과 내용," "사용되는 방법," "합격 및 불합격 기준(Pass and Fail Criteria)," "사용되는 환경 및 도구"가 포함되어야 합니다. TSR은 ISO 26262의 핵심 작업 산출물 중 하나이므로, TSR의 각 요구사항에 대한 검증 기준은 필수적입니다.
TSR 문서에 검증 기준을 명시하는 이유
TSR은 HARA(Hazard Analysis and Risk Assessment)에서 도출된 기능 안전 요구사항(FSR)을 구체적인 기술적 요구사항으로 변환하는 문서입니다. 따라서 TSR의 요구사항은 시스템의 안전을 직접적으로 보장하는 역할을 하므로, 해당 요구사항이 실제로 구현되었는지 객관적으로 확인하는 것이 매우 중요합니다.
TSR에 검증 기준을 명시하는 것은 다음과 같은 이점을 제공합니다.
- 객관성 확보: "응답 시간이 빠를 것"과 같은 주관적인 요구사항 대신, "응답 시간은 100ms 이내일 것"과 같이 측정 가능한 기준을 제시하여 검증의 객관성을 확보합니다.
- 개발 효율성: 개발자는 검증 기준을 통해 요구사항의 정확한 목표를 파악할 수 있으며, 테스트 엔지니어는 해당 기준에 맞춰 테스트 케이스를 명확하게 설계할 수 있습니다.
- 추적성(Traceability): TSR 요구사항이 테스트 케이스 및 검증 결과와 연결되어 있음을 입증하여 V-모델의 오른쪽 단계와 왼쪽 단계 간의 추적성을 보장합니다.
모범 자료를 통해 본 TSR 검증 기준
실제 모범적인 TSR 문서들은 각 TSR 항목 옆에 구체적인 검증 방법을 명시합니다. 예를 들어, TSR의 한 요구사항이 "안전 관련 RAM은 이중화되어야 한다"라면, 이에 대한 검증 기준은 "메모리 영역을 이중화하여 읽고 쓰는지를 확인하는 테스트 케이스를 통과해야 함"과 같이 구체적으로 명시됩니다.
다른 예시로는 TSR이 "고장 시 안전 상태로 100ms 이내에 진입해야 한다"고 명시할 경우, 검증 기준은 "고장을 주입하여 100ms 이내에 안전 상태로 전환되는지 확인하는 Fault Injection Test를 통과해야 함"과 같이 작성될 수 있습니다.
결론적으로, TSR은 시스템의 기능 안전을 보장하는 핵심 문서이므로, 각 요구사항에 대한 검증 기준은 모든 안전 표준에서 필수적으로 요구되는 요소이며, 이는 주관적인 판단이 아닌 명확한 모범 사례이자 표준 요구사항입니다.
'기능안전_기본이론' 카테고리의 다른 글
| HARA개념과 SG, QM의 엘리먼트에 할당 과정 (0) | 2025.09.09 |
|---|---|
| BSW와 MCU관계 (0) | 2025.09.08 |
| 소프트웨어 상세 설계서(BSW-Application) (0) | 2025.09.01 |
| fault injection (0) | 2025.09.01 |
| 진단 테스트 전략, 자체 시험 (0) | 2025.08.26 |