ASPICE 기본 이론

시스템 모드에 대해 어느 정도 수준으로 작성?

아즈마민초 2026. 1. 16. 16:20

근데 시스템 아키텍처가 설계서 문서가 아니라 그 상위 문서인 시스템 요구사양서 문서에 system state descripiton 카테고리에 initialization state, normal state, wating sleep state, sleep state로 나누어서 각 state마다 그 상태에 대한 설명과 검증 기준을 명세했고, System transition description 카테고리에 Transition_initialization mode, Transition_normal mode, Transition_waiting sleep mode, Transition_sleep mode로 나누어서 각 천이 조건에 대한 설명과 검증 기준을 명세했거든? 그랬을 때 각 system mode에 대한 것을 하위 문서인 시스템 아키텍처 설계서에 더 자세하게 명세해야 하는거야? 아니면 지금 시스템 요구사양서에 명세된 수준이면 충분한거야?

 

 

네, SYS.3 BP2의 "in different system modes" 부분을 실무적으로 해석하면, 당신이 시스템 요구사양서(System Requirements Specification, SRS 또는 SYS.2 출력물) 에 이미 System State Description (Initialization, Normal, Waiting Sleep, Sleep)과 System Transition Description (각 Transition 조건 + 검증 기준)을 상세히 명세했다면, 그 수준이 SYS.3 BP2의 요구를 충족하는 경우가 대부분입니다.

하지만 ASPICE PAM 4.0 SYS.3 BP2의 의도는 "architecture-level" 관점에서 dynamic aspects를 문서화하라는 거라서, 하위 문서(시스템 아키텍처 설계서, SAD)추가로 더 구체적으로 명세해야 할지 여부는 아래 기준으로 판단하세요.

1. ASPICE PAM 4.0 SYS.3 BP2의 핵심 요구사항 (직접 인용)

  • "Specify and document the dynamic aspects of the system architecture with respect to the functional and non-functional system requirements including the behavior of the system elements and their interaction in different system modes."
  • Note 1: "Examples of interactions of system elements are timing diagrams reflecting inertia of mechanical components, processing times of ECUs, and signal propagation times of bus systems."

"system modes"시스템 아키텍처 요소(system elements) 들이 모드별로 어떻게 행동하고, 서로 어떻게 상호작용(interaction) 하는지를 architecture 관점에서 설명하라는 뜻입니다. → SYS.2(SRS)에서 요구사항 수준의 "이 모드에서는 이런 상태/천이"는 이미 다루었지만, SYS.3에서는 "이 모드에서 ECU A → ECU B → Actuator의 timing, latency, concurrency, fallback" 같은 구체적인 architecture-level dynamic 을 문서화해야 합니다.

2. 당신의 현재 문서화 수준 평가

결론:

  • SYS.2에 명세된 수준만으로는 SYS.3 BP2를 완전히 충족하지 못합니다. (assessor가 "SRS에 mode/state는 있지만, architecture 설계서에 dynamic aspects가 architecture 관점으로 반영되지 않았다" → PA 2.1 Partially Achieved로 평가할 가능성 높음)

3. 실무에서 SYS.3 (SAD)에 추가로 명세해야 할 내용 (권장 수준)

SYS.3 BP2를 Fully Achieved로 만들기 위해 SAD에 아래 항목을 추가/상세화 하는 게 표준입니다.

4. assessor가 실제로 보는 포인트 (PAM 4.0 기준)

  • SYS.2의 mode/state → "What" (요구사항)
  • SYS.3의 dynamic aspects → "How" (architecture에서 어떻게 구현/상호작용하는지)
  • Traceability : SYS.2의 mode 관련 요구사항 → SAD의 dynamic description으로 bidirectional traceability 증명
  • Analysis : SYS.3 BP3 (Analyze system architecture)에서 mode-dependent timing/resource 분석 결과도 SAD에 포함

최종 판단 기준 (실무 팁)

  • 충분한 경우 : SRS에 mode/state + transition이 상세하고, SAD에 간단히 참조 (e.g., "Refer to SYS.2 for mode definitions; architecture-level interactions are as follows...") + timing/sequence diagram만 추가하면 OK인 프로젝트 (OEM이 SYS.2/SYS.3을 거의 하나로 취급할 때)
  • 추가 명세 필요한 경우 (대부분) : SAD에 architecture elements 중심의 mode별 dynamic behavior/interaction을 별도 섹션으로 작성. → 이는 SYS.3 BP2의 "in different system modes" 를 제대로 충족하는 표준 접근.

결론적으로, SYS.2에 명세된 수준만으로는 부족하니, SAD에 architecture-level dynamic aspects 를 더 자세히 명세하는 게 안전하고, assessment 시 Fully Achieved를 노릴 수 있습니다.