Safety case 양식 내 traceability 작성법

afety case안에서 safety requirement와 traceability를 보여주려면 어떻게 보여주는게 좋을까?

 

 

 

 

ISO 26262 Safety Case에서 Safety Requirement와 Traceability를 효과적으로 보여주는 것은 시스템의 안전성을 입증하는 데 매우 중요합니다. '주장(Claim)', '논거(Argument)', '증거(Evidence)'의 구조 안에서 이러한 정보들을 어떻게 구성하면 좋을지 구체적인 방법을 제시해 드릴게요.

1. Safety Requirements (안전 요구사항) 제시 방법

Safety Case는 기능 안전 개념(Functional Safety Concept, FSC) 및 기술 안전 개념(Technical Safety Concept, TSC)에서 파생된 안전 요구사항(Safety Requirements, SRs)이 궁극적으로 어떻게 달성되었는지를 보여줘야 합니다.

Safety Case 문서 내에서:

• 주장(Claim) 레벨:
  • 가장 높은 레벨의 주장 중 하나는 "모든 기능 안전 요구사항이 시스템에 의해 완전히 구현되고 검증되었다" 또는 "모든 할당된 ASIL 등급의 안전 요구사항이 ISO 26262에 따라 충족되었다"와 같은 내용이 될 수 있습니다.
• 논거(Argument) 레벨:
  • 이 주장을 뒷받침하기 위해, 안전 요구사항의 식별, 분해, 할당, 구현, 검증 프로세스에 대한 논거를 제시합니다.
  • 예시 논거: "시스템/하드웨어/소프트웨어 안전 요구사항은 기능 안전 요구사항으로부터 체계적으로 파생되었고, 각 요구사항은 그에 해당하는 ASIL 등급에 따라 적절한 개발 및 검증 활동을 거쳤다."
  • 예시 논거: "모든 안전 요구사항은 시스템의 최종 상태에서 의도된 안전 기능을 수행함을 보장하기 위해 철저히 검증되었다."
• 증거(Evidence) 레벨:
  • 여기서 실제 안전 요구사항 목록을 직접 나열하기보다는, 안전 요구사항 문서 자체를 참조합니다.
  • 참조 예시:
    • "기능 안전 요구사항은 [문서명: 기능 안전 요구사항 명세서, 문서 ID: FSR-DOC-XYZ, 버전: 1.0]에 명시되어 있다."
    • "하드웨어 안전 요구사항은 [문서명: 하드웨어 안전 요구사항 명세서, 문서 ID: HSR-DOC-ABC, 버전: 1.1]에 정의되어 있다."
    • "소프트웨어 안전 요구사항은 [문서명: 소프트웨어 안전 요구사항 명세서, 문서 ID: SSR-DOC-DEF, 버전: 1.2]에 정의되어 있다."
  • 필요하다면, Safety Case에서 특히 강조하거나 설명이 필요한 핵심 안전 요구사항 몇 가지를 요약하여 제시할 수 있습니다. 하지만 모든 SR을 나열하는 것은 비효율적입니다.

2. Traceability (추적성) 보여주는 방법

ISO 26262에서 추적성은 개발 생명주기 전반에 걸쳐 요구사항, 설계, 구현, 검증 활동 간의 연결 고리를 보여주는 핵심적인 요소입니다. Safety Case는 이러한 추적성이 효과적으로 관리되고 있음을 입증해야 합니다.

Safety Case 문서 내에서:

• 주장(Claim) 레벨:
  • "모든 안전 요구사항은 개발 생명주기 전반에 걸쳐 양방향으로 추적 가능하며, 이는 ISO 26262의 요구사항 추적성 원칙을 준수한다."
• 논거(Argument) 레벨:
  • 추적성이 어떻게 보장되는지에 대한 논리적인 설명을 제시합니다.
  • 예시 논거: "요구사항 관리 도구(예: DOORS, Polarion, Jira 등)를 사용하여 안전 목표(SG)부터 기능 안전 요구사항(FSR), 기술 안전 요구사항(TSR), 하드웨어/소프트웨어 안전 요구사항(HSR/SSR)까지의 종방향 추적성이 확립되었다."
  • 예시 논거: "각 안전 요구사항은 해당 설계 요소, 구현 코드 및 검증 테스트 케이스와 양방향으로 연결되어 있어 완전한 커버리지를 보장한다."
  • 예시 논거: "변경 관리 프로세스에 따라 요구사항 변경 시 추적성 링크에 대한 영향 분석이 수행된다."
• 증거(Evidence) 레벨:
  • 이 부분이 가장 중요합니다. 추적성의 '근거'는 주로 추적성 매트릭스(Traceability Matrix) 또는 요구사항 관리 도구의 보고서입니다. Safety Case 문서에 이 모든 내용을 직접 넣기보다는 참조하는 것이 일반적입니다.
  • 참조 예시:
    • "기능 안전 요구사항과 기술 안전 요구사항 간의 추적성은 [문서명: 기능 안전 요구사항-기술 안전 요구사항 추적성 매트릭스, 문서 ID: FSR-TSR-TM-001, 버전: 1.0]에 명시되어 있다."
    • "하드웨어 안전 요구사항과 하드웨어 설계/테스트 케이스 간의 추적성은 [문서명: H/W 추적성 보고서, 문서 ID: HW-TR-REP-001, 버전: 1.1] 또는 [요구사항 관리 시스템 (예: DOORS) 내의 추적성 뷰/레포트]를 통해 확인할 수 있다."
    • "모든 소프트웨어 안전 요구사항은 해당 소프트웨어 아키텍처 요소, 소프트웨어 컴포넌트, 소스 코드 및 단위/통합/검증 테스트 케이스와 [문서명: S/W 추적성 매트릭스, 문서 ID: SW-TR-MAT-001, 버전: 1.2] 또는 [요구사항 관리 도구의 자동 생성 보고서]에 따라 연결되어 있다."
  • 시각화: Safety Case 문서 내에서 전체적인 추적성 개념을 설명할 때, V-모델 다이어그램에 추적성 화살표를 추가하거나, 간략화된 추적성 흐름도를 그려서 이해를 돕는 것도 좋은 방법입니다. (예: SG ↔ FSR ↔ TSR ↔ HSR/SSR ↔ H/W Design ↔ S/W Design ↔ Code ↔ Test)

요약 및 실무 팁:

• Safety Case는 '참조 문서'의 집합체가 아닙니다. 핵심은 '주장', '논거', '증거'의 논리적인 흐름을 명확하게 제시하는 것입니다.
• 간결성: Safety Case는 너무 방대하지 않게 작성되어야 합니다. 상세 내용은 외부 참조 문서에 맡기고, Safety Case는 핵심적인 주장과 논거, 그리고 그를 뒷받침하는 문서들에 대한 명확한 참조를 제공해야 합니다.
• 명확한 식별자: 모든 참조 문서에는 고유한 문서 ID, 버전 번호, 그리고 가능하다면 특정 섹션/페이지 번호까지 명확하게 기재하여 검토자가 쉽게 찾아볼 수 있도록 합니다.
• 도구 활용: 요구사항 관리 도구(RM Tools)는 추적성 관리에 필수적입니다. 이러한 도구에서 생성된 추적성 매트릭스나 보고서를 Safety Case의 증거로 직접 참조하거나, 필요에 따라 핵심 부분을 스크린샷 등으로 첨부하여 설명할 수 있습니다.