기능안전의 통합 테스트 관련 특이성

그런데 내가 알기로는 통합 테스트는 아키텍처 설계서를 기반으로 하는 거로 알고 있는데, 왜 너가 만들어준 체크리스트를 보면 TSR, SSR 같은 요구사항과의 추적성을 묻는거야?

 

좋은 질문입니다! 통합 테스트 전략이 아키텍처 설계서를 기반으로 한다는 점은 맞습니다. 하지만 ISO 26262와 같은 기능 안전 표준에서는 통합 테스트가 단순히 아키텍처 설계의 인터페이스와 상호작용을 검증하는 것뿐만 아니라, 안전 요구사항(Technical Safety Requirements, TSR 및 Software Safety Requirements, SSR)과의 추적성도 보장해야 합니다. 이에 대해 자세히 설명드리겠습니다.

 

1. 왜 TSR/SSR과의 추적성이 중요한가?

ISO 26262의 요구사항: ISO 26262에서는 시스템 및 소프트웨어 통합 테스트가 안전 요구사항(예: TSR, SSR)을 충족하는지 확인해야 한다고 명시합니다(ISO 26262-4 SYS.4, ISO 26262-6 SWE.4). 이는 통합 테스트가 단순히 구성 요소 간의 인터페이스 동작을 확인하는 데 그치지 않고, 시스템이 안전 목표(Safety Goals)와 관련된 요구사항을 만족하는지 검증해야 함을 의미합니다.

따라서 테스트 케이스는 아키텍처 설계뿐만 아니라 TSR/SSR과도 명확히 연결(추적)되어야 하며, 이를 통해 모든 안전 관련 요구사항이 테스트로 커버되었음을 입증해야 합니다.

2. 안전 요구사항과 아키텍처의 관계: 아키텍처 설계는 TSR/SSR을 구현하는 방법(예: 시스템/소프트웨어 구성 요소, 인터페이스, 안전 메커니즘)을 정의합니다. 통합 테스트는 이 아키텍처가 설계대로 동작하는지 확인하면서 동시에 TSR/SSR에서 요구한 안전 기능(예: 오류 탐지, 타이밍 제약, 장애 내성 등)이 제대로 구현되었는지를 검증합니다.

예를 들어, SSR에서 "10ms 이내에 응답해야 한다"는 요구사항이 있다면, 통합 테스트는 아키텍처의 인터페이스가 이 요구사항을 충족하는지 확인하는 테스트 케이스를 포함해야 합니다. 이를 위해 추적성 매트릭스가 필요합니다.

3. 추적성의 역할: 추적성(Traceability)은 테스트 케이스가 모든 관련 TSR/SSR을 커버하는지 확인하는 데 사용됩니다. 이는 특히 ASIL C/D와 같은 높은 안전 무결성 수준에서 중요하며, 모든 안전 요구사항이 검증되었음을 입증하는 데 필수적입니다(ISO 26262-8 Clause 6).

또한, 추적성은 양방향(Forward: 요구사항 → 테스트 케이스, Backward: 테스트 케이스 → 요구사항)으로 유지되어야 하며, 이는 안전 케이스(Safety Case)를 구성할 때 확인 검토(Confirmation Review)에서 중요한 증거로 사용됩니다.

4. 체크리스트에 추적성이 포함된 이유:

제공된 체크리스트는 ISO 26262의 요구사항을 기반으로 작성되었으며, 이는 통합 테스트 전략이 단순히 아키텍처 설계의 구현을 검증하는 데 그치지 않고, 안전 요구사항(TSR/SSR)과 안전 목표(HARA에서 정의된 Safety Goals)에 대한 검증을 보장해야 함을 강조합니다.

체크리스트의 "Traceability" 섹션(예: "Traceability to Requirements", "Traceability to Safety Mechanisms")은 테스트 전략이 아키텍처뿐만 아니라 안전 요구사항과의 연계를 명확히 문서화하도록 요구합니다. 이는 ISO 26262-4(시스템 통합) 및 ISO 26262-6(소프트웨어 통합)의 필수 작업 산출물(Work Product) 요구사항을 충족하기 위함입니다.

요약

통합 테스트는 아키텍처 설계서를 기반으로 하되, ISO 26262에서는 이 테스트가 안전 요구사항(TSR/SSR)을 검증하는 데 초점을 맞춰야 한다고 요구합니다. 따라서 테스트 전략은 아키텍처의 인터페이스와 상호작용을 확인하는 동시에, 모든 안전 요구사항이 테스트 케이스로 커버되었음을 입증하기 위해 추적성을 유지해야 합니다. 체크리스트에 TSR/SSR 추적성이 포함된 것은 이러한 ISO 26262의 요구사항을 충족하기 위한 것입니다.

 

근데 이미 아키텍처 설계서의 요구사항은 그 상위 문서인 요구사양서의 요구사항과 양방향 추적성이 연결되어 있기 때문에, 테스트 전략에서 추적성을 확인하는게 아키텍처 설계서의 요구사항만 보는게 아니라 그 상위문서인 요구사양서의 요구사항까지 보는 거면 중복되는 활동 아니야? 그리고 설령 요구사양서의 요구사항과 추적성을 연결한다고 해도 그건 테스트 결과에서 보이면 되지, 굳이 테스트 전략에서부터 보여야 해?

 

매우 좋은 지적입니다! 질문에서 제기된 중복성과 테스트 전략에서 요구사항 추적성을 확인하는 필요성에 대해 ISO 26262의 맥락에서 명확히 설명드리겠습니다.

 

1. 중복 활동 여부: 아키텍처 설계서와 요구사양서의 추적성

질문에서 언급하신 대로, 아키텍처 설계서(예: System/Software Architecture Specification)의 요구사항은 상위 문서인 요구사양서(예: Technical Safety Requirements, TSR 또는 Software Safety Requirements, SSR)와 이미 양방향 추적성으로 연결되어 있습니다. 따라서 테스트 전략에서 TSR/SSR과의 추적성을 다시 확인하는 것이 중복된 활동처럼 보일 수 있습니다. 하지만 이는 ISO 26262의 요구사항과 기능 안전 프로세스의 철학을 고려할 때 중복이 아니라 필수적인 단계로 간주됩니다. 그 이유는 다음과 같습니다:

 

ISO 26262의 계층적 검증 구조

ISO 26262는 시스템 및 소프트웨어 개발 프로세스를 계층적으로 관리하며, 각 단계(요구사항 정의 → 아키텍처 설계 → 구현 → 테스트)에서 요구사항의 충족 여부를 독립적으로 검증하도록 요구합니다. 통합 테스트 단계(SYS.4, SWE.4)에서는 아키텍처 설계뿐만 아니라 상위 요구사항(TSR/SSR)이 실제 구현에서 올바르게 반영되었는지 확인해야 합니다.

 

아키텍처 설계서가 TSR/SSR과 추적성을 갖고 있다고 하더라도, 통합 테스트는 구현된 시스템/소프트웨어가 이 요구사항을 실제로 만족하는지를 검증하는 단계입니다. 따라서 테스트 전략에서 TSR/SSR과의 추적성을 명시적으로 확인하는 것은, 아키텍처 설계 단계에서의 추적성과는 별개로, 테스트가 모든 안전 요구사항을 커버했음을 보장하기 위한 추가적인 안전 장치입니다

 

중복이 아닌 상호보완

아키텍처 설계서와 TSR/SSR 간의 추적성은 설계 단계에서 요구사항이 올바르게 반영되었는지를 확인하는 데 초점이 맞춰져 있습니다. 반면, 통합 테스트 전략에서의 추적성은 테스트 케이스가 이러한 요구사항을 검증하는 데 충분한지 확인하는 데 목적이 있습니다.

 

예를 들어, TSR에서 "시스템은 10ms 이내에 응답해야 한다"고 명시되어 있고, 아키텍처 설계서에서 이를 구현하기 위한 인터페이스와 모듈이 정의되었다면, 통합 테스트 전략은 이 요구사항이 테스트 케이스로 검증되는지(예: 타이밍 테스트 포함 여부)를 확인해야 합니다. 이는 설계 단계의 추적성과는 별개의 활동으로, 구현의 정확성을 검증하는 데 필요합니다.

 

독립적 검증의 중요성

ISO 26262는 특히 ASIL C/D와 같은 높은 안전 무결성 수준에서 독립적 검증과 확인 검토(Confirmation Review)를 강조합니다. 테스트 전략에서 TSR/SSR과의 추적성을 명시적으로 확인함으로써, 테스트가 안전 요구사항을 빠뜨리지 않았음을 독립적으로 입증할 수 있습니다. 이는 중복이 아니라 안전성을 보장하기 위한 상호보완적 활동입니다.

 

2. 테스트 전략에서 추적성을 보여야 하는 이유

질문에서 언급하신 것처럼, 테스트 결과에서 추적성을 확인하면 충분하지 않느냐는 점은 타당한 의문입니다. 하지만 ISO 26262에서는 테스트 전략 단계에서부터 추적성을 명시적으로 정의하고 문서화해야 하는 이유가 있습니다:

 

사전 계획의 중요성

테스트 전략은 테스트 실행 전에 작성되며, 테스트가 어떤 요구사항을 검증할 것인지 미리 계획하는 단계입니다. ISO 26262-8(Clause 6)에서는 작업 산출물(Work Product)이 완전성과 추적성을 갖춰야 한다고 요구합니다. 따라서 테스트 전략 문서에서 TSR/SSR과의 추적성을 명시함으로써, 테스트 계획이 모든 안전 요구사항을 커버하도록 사전에 보장할 수 있습니다.

 

테스트 결과에서만 추적성을 확인한다면, 테스트 계획이 불완전하거나 일부 요구사항이 누락되었을 경우 이를 사후에 발견하게 되어 재작업 비용이 증가할 수 있습니다. 테스트 전략에서 추적성을 정의하면 이러한 리스크를 줄일 수 있습니다.

 

확인 검토(Confirmation Review)

ISO 26262-8(Table 1)에 따르면, 테스트 전략 문서는 독립적인 확인 검토 대상입니다. 이 과정에서 검토자는 테스트 전략이 모든 안전 요구사항(TSR/SSR)을 커버하는지, 그리고 이를 검증하기 위한 테스트 케이스가 적절히 정의되었는지를 확인합니다. 이를 위해 테스트 전략 문서에 추적성 매트릭스(예: 테스트 케이스와 TSR/SSR 간 매핑)가 포함되어야 하며, 이는 테스트 결과 문서가 아니라 테스트 전략 단계에서 준비되어야 합니다.

 

안전 케이스(Safety Case) 구성:

안전 케이스는 시스템이 안전 요구사항을 충족했음을 입증하는 종합적인 문서입니다. 테스트 전략에서 TSR/SSR과의 추적성을 명시적으로 문서화함으로써, 안전 케이스에 필요한 증거를 체계적으로 제공할 수 있습니다. 이는 테스트 결과뿐만 아니라 테스트 계획 단계부터 체계적으로 관리되어야 합니다.

 

효율성과 명확성

테스트 전략에서 추적성을 정의하면 테스트 팀이 어떤 요구사항을 검증해야 하는지 명확히 이해할 수 있습니다. 이는 특히 복잡한 시스템에서 테스트 범위를 명확히 하고, 테스트 케이스가 요구사항을 빠뜨리지 않도록 보장합니다. 테스트 결과에서만 추적성을 확인하려면, 테스트 실행 후 누락된 요구사항을 발견했을 때 이미 자원이 소모된 상태일 수 있습니다

 

3. 체크리스트와의 연관성

제공된 Integration_Test_Strategy_Checklist.md 파일의 "Traceability" 섹션(예: "Traceability to Requirements", "Bi-Directional Traceability")은 이러한 ISO 26262의 요구사항을 반영한 것입니다. 특히 다음 항목들은 테스트 전략에서 TSR/SSR 추적성을 확인하는 이유를 명확히 보여줍니다

 

Traceability to Requirements: 테스트 케이스가 TSR/SSR과 명확히 매핑되어 있는지 확인하여 모든 안전 요구사항이 테스트로 커버되었음을 보장

 

Bi-Directional Traceability: 요구사항에서 테스트 케이스로, 그리고 테스트 케이스에서 요구사항으로의 추적성을 통해 누락이나 불일치를 방지.

 

Traceability to Safety Mechanisms: 안전 메커니즘(예: 오류 탐지, 장애 내성)이 테스트로 검증되는지 확인하여 안전 요구사항의 구현을 보장.

 

4. 결론

중복 여부: 테스트 전략에서 TSR/SSR과의 추적성을 확인하는 것은 아키텍처 설계 단계에서의 추적성과는 별개의 활동으로, 구현된 시스템/소프트웨어가 안전 요구사항을 충족하는지 검증하는 데 필요합니다. 이는 중복이 아니라 ISO 26262의 계층적 검증 프로세스의 일부입니다.

 

테스트 전략에서의 추적성 필요성: 테스트 전략에서 추적성을 명시적으로 정의하는 것은 테스트 계획의 완전성을 보장하고, 확인 검토 및 안전 케이스 구성을 지원하며, 테스트 실행 전 누락을 방지하기 위한 필수 단계입니다. 테스트 결과에서만 추적성을 확인하는 것은 사후 대응에 가까우며, 사전 계획의 철저함을 대체할 수 없습니다.

 

추가 제안

만약 질문하신 맥락에서 추적성 관리의 중복성을 줄이고 싶다면, 다음과 같은 방법을 고려할 수 있습니다:

 

 

• 통합 추적성 매트릭스: 프로젝트 전체에서 단일 추적성 매트릭스를 유지하여 요구사항(TSR/SSR), 아키텍처 설계, 테스트 케이스 간의 관계를 한 곳에서 관리. 이 경우 테스트 전략은 이 매트릭스를 참조하되, 테스트 케이스와 요구사항 간의 매핑만 별도로 강조.
• 도구 활용: 요구사항 관리 도구(예: DOORS, Polarion)를 사용하여 추적성을 자동화하면, 테스트 전략 문서에서 추적성 확인 작업의 부담을 줄일 수 있습니다

그러면 통합 테스트 단계에서 요구사양서의 요구사항까지 보게 된다면 예를 들어, ISO 26262 개발 단계 중 소프트웨어 통합과 검증 이후 단계인 소프트웨어 임베디드에 대한 검증은 무엇을 검증하는거야? 내가 알기로는 SSR(소프트웨어 요구사양서)기반을 검증하는 거로 알고 있는데, 그러면 해당 검증 단계의 이전 단계인 소프트웨어 통합과 검증 단계와 중복되는 활동이 되지 않아?

 

매우 좋은 질문입니다! 질문에서 제기된 소프트웨어 통합 및 검증 단계(SWE.4)와 소프트웨어 임베디드 검증 단계(ISO 26262-6의 시스템 수준 검증, SYS.4 또는 SWE.5와 관련) 간의 중복성 우려에 대해 명확히 설명드리겠습니다. ISO 26262의 맥락에서 각 단계의 목적과 검증 대상, 그리고 왜 중복이 아닌지를 Integration_Test_Strategy_Checklist.md 파일을 참조하며 설명하겠습니다.

 

1. 소프트웨어 통합 및 검증(SWE.4) 단계의 목적

소프트웨어 통합 및 검증 단계(SWE.4)는 소프트웨어 구성 요소(예: 소프트웨어 유닛 또는 모듈)를 통합하여 소프트웨어 아키텍처 설계(Software Architecture Specification, ISO 26262-6 Clause 7)에 따라 올바르게 동작하는지 확인하는 단계입니다. 이 단계에서는 다음과 같은 요소를 검증합니다:

• 검증 대상:
  • 소프트웨어 구성 요소 간의 인터페이스와 상호작용(예: 데이터 흐름, 함수 호출).
  • Software Safety Requirements (SSR)과 소프트웨어 아키텍처 설계에 정의된 기능적 및 비기능적 요구사항(예: 타이밍, 오류 처리).
  • 안전 메커니즘(예: 오류 탐지, 워치독 타이머)의 초기 구현.
• 체크리스트와의 연관성:
  • Integration_Test_Strategy_Checklist.md의 Traceability to Architecture (섹션 3): "Does the test strategy verify the interfaces and interactions defined in the System/Software Architecture Specification (ISO 26262-6 Clause 7)?"
  • Traceability to Requirements (섹션 3): 테스트 케이스가 SSR과 매핑되어 있는지 확인.
  • Verification of Safety Mechanisms (섹션 5): 소프트웨어 수준의 안전 메커니즘(예: 오류 처리, 진단 커버리지)을 검증.

이 단계는 소프트웨어 단위 테스트(SWE.3)에서 개별적으로 검증된 유닛을 통합하여 소프트웨어 전체가 SSR과 아키텍처 설계에 따라 동작하는지 확인하는 데 초점이 맞춰져 있습니다. 예를 들어, 소프트웨어 모듈 간의 통신 프로토콜이나 타이밍 제약이 올바르게 구현되었는지 테스트합니다.

 

2. 소프트웨어 임베디드 검증(SYS.4 또는 SWE.5와 관련) 단계의 목적

소프트웨어 임베디드 검증은 소프트웨어가 실제 하드웨어(예: ECU)에 통합된 상태에서 시스템 수준에서 동작하는지 확인하는 단계입니다. ISO 26262-6에서는 SWE.5(소프트웨어 검증)로 명시되기도 하며, 시스템 수준 검증(SYS.4)과 연계될 수 있습니다. 이 단계에서는 다음과 같은 요소를 검증합니다:

• 검증 대상:
  • 소프트웨어가 하드웨어 환경(예: 실제 ECU, 센서, 액추에이터)에서 SSR을 충족하는지.
  • 시스템 수준의 Technical Safety Requirements (TSR) 및 Safety Goals(HARA에서 정의)와의 일치성.
  • 하드웨어-소프트웨어 상호작용(예: 하드웨어 인터럽트 처리, 메모리 액세스).
  • 실제 환경에서의 비기능적 요구사항(예: 실시간 성능, 전력 소비).
  • 시스템 수준의 안전 메커니즘(예: 하드웨어-소프트웨어 통합된 오류 탐지, PMHF 목표).
• 체크리스트와의 연관성:
  • Safety Requirements Coverage (섹션 2): "Does the test strategy cover all relevant Technical Safety Requirements (TSR) or Software Safety Requirements (SSR)?"
  • PMHF Compliance (섹션 7): 하드웨어-소프트웨어 통합 상태에서 Probabilistic Metric for Random Hardware Failures (PMHF) 목표 충족 여부.
  • Test Environment (섹션 4): 실제 하드웨어(HIL 또는 실 하드웨어)를 포함한 테스트 환경에서의 검증

이 단계는 소프트웨어가 독립적으로 동작하는 것이 아니라 하드웨어와 통합된 상태에서 전체 시스템의 안전성과 요구사항 충족 여부를 확인하는 데 초점이 있습니다. 예를 들어, 소프트웨어가 ECU에서 실행될 때 특정 센서 입력에 대해 10ms 이내에 응답하는지, 하드웨어 오류에 대해 안전 메커니즘이 적절히 작동하는지를 테스트합니다.

 

3. 중복성에 대한 우려와 차이점

질문에서 제기된 "소프트웨어 통합 및 검증(SWE.4)과 소프트웨어 임베디드 검증 단계가 SSR을 기반으로 하므로 중복되는 활동 아니냐"는 우려에 대해, 두 단계는 겉보기에 SSR을 검증하는 것처럼 보일 수 있지만, 검증의 맥락과 범위가 다릅니다. 이를 구체적으로 비교해 설명드리겠습니다:

• 검증 범위의 차이:
  • SWE.4 (소프트웨어 통합 및 검증): 소프트웨어 단독 환경(예: SIL, Software-in-the-Loop 또는 시뮬레이션 환경)에서 소프트웨어 구성 요소 간의 통합성과 SSR 충족 여부를 검증. 하드웨어는 고려하지 않거나 최소화된 추상화된 환경에서 테스트.
  • 임베디드 검증(SYS.4/SWE.5): 소프트웨어가 실제 하드웨어에 탑재된 상태에서 시스템 전체(하드웨어+소프트웨어)의 동작을 검증. 이는 하드웨어-소프트웨어 상호작용, 실제 환경에서의 타이밍, 하드웨어 오류 대응 등을 포함.
• 검증 환경의 차이:
  • SWE.4에서는 주로 소프트웨어 중심의 테스트 환경(예: 시뮬레이터, 소프트웨어 테스트 벤치)을 사용하며, 하드웨어의 영향을 최소화합니다.
  • 임베디드 검증에서는 실제 하드웨어(예: HIL, Hardware-in-the-Loop 또는 실 차량 환경)를 사용하며, 하드웨어의 제약(예: 메모리 지연, 인터럽트 처리)과 상호작용을 고려합니다. 체크리스트의 Test Environment (섹션 4) 항목은 이를 반영합니다.
• 검증 대상의 차이:
  • SWE.4는 소프트웨어 아키텍처와 SSR에 초점을 맞추며, 소프트웨어 내부의 인터페이스와 안전 메커니즘을 검증.
  • 임베디드 검증은 시스템 수준의 TSR과 SSR을 모두 고려하며, 하드웨어와 소프트웨어의 통합 동작, 시스템 수준의 안전 목표(HARA) 충족 여부를 검증. 체크리스트의 Safety Goal Traceability (섹션 2)와 PMHF Compliance (섹션 7)는 이를 강조.
• 중복이 아닌 상호보완:
  • SWE.4에서 SSR을 검증하더라도, 이는 소프트웨어 단독 환경에서의 동작을 확인하는 것입니다. 하지만 실제 하드웨어 환경에서는 예상치 못한 변수(예: 하드웨어 지연, 전력 문제, 인터럽트 충돌)가 발생할 수 있으므로, 임베디드 검증에서 다시 SSR을 검증하는 것은 필수적입니다.
  • 예를 들어, SSR에서 "10ms 이내 응답"을 요구한다고 가정할 때, SWE.4에서는 시뮬레이션 환경에서 이를 검증하지만, 임베디드 검증에서는 실제 ECU에서 하드웨어 타이머와 인터럽트가 이를 충족하는지 확인합니다. 이는 중복이 아니라 더 실제적인 환경에서의 추가 검증입니다.
• ISO 26262의 계층적 검증 철학:
  • ISO 26262는 개발 단계를 계층적으로 나누어 각 단계에서 독립적으로 검증하도록 요구합니다. 이는 안전 무결성을 보장하기 위해 각 레벨(유닛 → 통합 → 시스템)에서 요구사항의 충족 여부를 재확인하는 것을 의미합니다. 체크리스트의 ISO 26262 Compliance (섹션 9)는 이러한 계층적 검증의 필요성을 반영합니다.

4. 테스트 전략에서 SSR 추적성의 역할

질문에서 언급하신 "테스트 결과에서 SSR 추적성을 확인하면 되지 않느냐"는 점에 대해, 이전 답변에서 설명했듯이 테스트 전략 단계에서 SSR 추적성을 명시하는 것은 사전 계획의 완전성을 보장하기 위함입니다. 소프트웨어 통합 및 검증(SWE.4)과 임베디드 검증 단계 모두에서 테스트 전략은 SSR과의 추적성을 포함해야 하며, 이는 다음과 같은 이유로 필요합니다:

• SWE.4에서의 추적성: 소프트웨어 통합 테스트가 SSR을 모두 커버하도록 계획. 체크리스트의 Traceability to Requirements (섹션 3)와 Coverage Criteria (섹션 5)는 이를 보장.
• 임베디드 검증에서의 추적성: 시스템 수준에서 SSR뿐만 아니라 TSR과 안전 목표까지 검증하도록 계획. 체크리스트의 Safety Goal Traceability (섹션 2)와 ASIL-Specific Requirements (섹션 7)는 이를 강조.

두 단계 모두 SSR을 참조하지만, SWE.4는 소프트웨어 내부 동작에 초점을 맞추고, 임베디드 검증은 하드웨어와의 통합 및 시스템 수준 동작에 초점을 맞춥니다. 따라서 테스트 전략에서 SSR 추적성을 포함하는 것은 중복이 아니라 각 단계의 고유한 검증 목표를 지원하는 필수 활동입니다.

 

5. 결론

• 소프트웨어 통합 및 검증(SWE.4): 소프트웨어 단독 환경에서 소프트웨어 구성 요소 간의 통합성과 SSR 충족 여부를 검증. 초점은 소프트웨어 아키텍처와 인터페이스.
• 소프트웨어 임베디드 검증(SYS.4/SWE.5): 하드웨어에 탑재된 소프트웨어가 시스템 수준에서 SSR, TSR, 안전 목표를 충족하는지 검증. 초점은 하드웨어-소프트웨어 상호작용과 실제 환경에서의 동작.
• 중복 여부: 두 단계는 SSR을 참조하지만, 검증 환경과 대상이 달라 중복이 아니라 상호보완적입니다. SWE.4는 소프트웨어 내부 동작을, 임베디드 검증은 시스템 수준 동작을 검증하며, 이는 ISO 26262의 계층적 검증 프로세스를 따릅니다.
• 테스트 전략에서의 추적성: 테스트 전략에서 SSR 추적성을 명시하는 것은 테스트 계획의 완전성을 보장하고, 확인 검토 및 안전 케이스 구성을 지원하기 위해 필요합니다. 이는 SWE.4와 임베디드 검증 단계 모두에서 적용되며, 각 단계의 고유한 검증 목표를 반영합니다.

6. 추가 제안

중복성에 대한 우려를 줄이기 위해 다음과 같은 접근을 고려할 수 있습니다:

• 통합 추적성 관리: 단일 추적성 매트릭스를 사용하여 SSR, 아키텍처, 테스트 케이스 간의 관계를 통합 관리. SWE.4와 임베디드 검증 단계에서 이 매트릭스를 참조하되, 각 단계의 테스트 케이스는 고유한 환경과 목표를 반영.
• 테스트 재사용: SWE.4에서 검증된 테스트 케이스를 임베디드 검증에서 재사용 가능하도록 설계하여 중복 테스트를 최소화. 단, 하드웨어 환경에 맞게 테스트를 조정.
• 도구 활용: 요구사항 관리 도구(예: DOORS, Polarion)를 사용해 추적성을 자동화하고, 각 단계에서 필요한 추적성 정보만 필터링하여 문서화.

ISO 26262의 개발을 준수하려면 소프트웨어 통합 및 검증 전략을 짤 때, 소프트웨어 아키텍처 기반의 소프트웨어 모듈간의 인터페이스, 상호작용에 대한 검증을 위한 테스트 케이스 개발 뿐만 아니라, SSR의 요구사양도 검증할 수 있는 테스트 케이스도 개발해야 해?

 

네, 정확하게 짚으셨습니다.
ISO 26262를 준수하여 소프트웨어 통합 및 검증 전략을 수립할 때, 아래 두 가지 모두에 대한 테스트 케이스를 반드시 개발해야 합니다:

---

✅ 1. 소프트웨어 아키텍처 기반의 모듈 간 인터페이스/상호작용 검증

• 소프트웨어 통합 검증(Software Integration Testing)은
  SW 컴포넌트들 간의 상호작용, 인터페이스, 통신 흐름, 데이터 교환이
  SW 아키텍처 설계대로 잘 구현되었는지를 검증합니다.
• ISO 26262-6 (Part 6, Table 10 – "Software integration and verification")에서도 명시합니다.

✅ 2. SSR(Software Safety Requirements) 충족 여부 검증

• SW 통합/검증 단계에서는 단순히 구조적 적합성 뿐만 아니라,
  안전 기능이 SW 레벨에서 실제로 동작하는지, 즉 SSR을 만족하는지도 반드시 검증해야 합니다.
• ISO 26262-6 (Clause 9.4.3)에서는 다음을 명확히 요구합니다:

"The verification of the software safety requirements shall demonstrate that they are implemented correctly in the integrated software."

🔧 전략 예시

통합 테스트 전략을 세울 때 이렇게 구분할 수 있습니다:

 

[통합 검증 전략 문서 구성 예시]

1. 검증 목적
2. 검증 대상 소프트웨어 모듈/인터페이스
3. 테스트 유형 분류:
   3.1. 구조적 검증 (Module A ↔ Module B 연결)
   3.2. SSR 기반 요구사항 검증
4. 테스트 케이스 목록
   - TC-001: A → B 데이터 흐름 검증
   - TC-007: SSR-03 Fault 시 Mechanism 반응 확인
5. Fault injection 계획 (필요 시)
6. Pass/Fail 기준 정의