ASPICE - SYS.3 시스템 아키텍처 설계 정리

1. Introduction

ADAS/자율주행 시스템을 개발하는 엔지니어라면 Automotive SPICE (ASPICE)라는 용어를 들어보셨을 것입니다. ASPICE는 자동차 산업에서 소프트웨어와 시스템 개발 프로세스의 품질을 높이기 위한 표준 모델입니다. 오늘은 ASPICE 4.0 버전에서의 SYS.3 시스템 아키텍처 설계 (Process ID: SYS.3) 프로세스에 대해 정리하겠습니다. 특히 카메라, 레이더, 브레이크로 구성된 AEB (Automatic Emergency Braking, 자동 긴급 제동) 시스템 예제를 통해, 요구사항으로부터 시스템 아키텍처를 어떻게 도출하고 구조화하며 산출물을 남기는지 살펴보도록 하겠습니다.

2. SYS.3 프로세스 개요: 목적과 Outcome

SYS.3 시스템 아키텍처 설계 프로세스의 목적(Purpose)은 한 문장으로 정리됩니다. “시스템 요구사항에 부합하는 분석된 시스템 아키텍처를 정립하는 것”이죠. 즉, 시스템의 기능/비기능 요구사항을 충족할 수 있는 시스템 구조를 만드는 것이 이 프로세스의 목표입니다.

ASPICE 4.0 기준으로 정의된 프로세스 결과 (Outcomes)는 총 4가지입니다:

• Outcome 1: 시스템 요소들의 구성, 인터페이스, 관계 및 상호작용이 정의된 시스템 아키텍처가 수립된다. (요구사항을 만족하는 전체 시스템 구조를 설계)
• Outcome 2: 시스템 아키텍처를 미리 정한 평가 기준에 따라 분석하고, 특히 하드웨어 요소에 대한 Special Characteristic(특수 특성)을 식별한다. (아키텍처가 충분히 타당한지 검토하고 안전/품질 등에 중요한 특성을 찾아냄)
• Outcome 3: 시스템 아키텍처와 시스템 요구사항 사이에 일관성 있는 양방향 추적성이 확보된다. (요구사항과 설계 간에 빠짐없이 연결되고 모순이 없음을 보장)
• Outcome 4: 합의된 시스템 아키텍처 및 특수 특성이 모든 관련자에게 전달된다. (완성된 아키텍처를 이해관계자들이 공유하여 알게 됨)

요약하면, SYS.3 프로세스를 수행하면 시스템 요구사항을 만족하는 완성된 시스템 설계도가 나오고, 그 설계도가 타당한지 분석/검증되며, 요구사항과의 추적성도 확보되고, 최종적으로 관계자들에게 커뮤니케이션까지 이루어지는 것입니다.

3. SYS.3의 Base Practice와 산출물 (Output Work Product)

이러한 Outcomes를 달성하기 위해 ASPICE에서는 SYS.3 프로세스에 대한 Base Practice(기본 수행 활동)들을 정의하고 있습니다. ASPICE 4.0에서 SYS.3에는 다음 5개의 베이스 프랙티스가 있습니다:

• SYS.3.BP1: 시스템 아키텍처의 정적 측면 명세 – 시스템의 정적 구조를 설계하고 문서화합니다. 시스템을 구성하는 요소들과 외부 인터페이스를 정의하고, 각 요소 간 관계를 명확히 기술합니다. 여기에는 기능/비기능 요구사항을 토대로 어떤 하위 시스템이나 구성요소들이 필요한지를 정하는 작업이 포함됩니다.
  
  
• SYS.3.BP2: 시스템 아키텍처의 동적 측면 명세 – 시스템 요소들의 동적인 동작과 상호작용을 정의합니다. 예를 들어 시스템이 가지고 있는 다양한 동작 모드(예: 기동, 정상 작동, 종료, 진단 모드 등)에서 각 구성요소들이 어떻게 행동하고 상호 작용하는지 시나리오를 작성합니다. ※ 참고: BP1이 정적 “구조도”를 그리는 것이라면, BP2는 시퀀스 다이어그램, 상태 전이도, 타이밍 다이어그램 등으로 동작 흐름을 설계하는 단계라고 볼 수 있습니다.
  
  
• SYS.3.BP3: 시스템 아키텍처 분석 – 설계된 아키텍처를 기술적 측면에서 분석 및 평가합니다. 제품 라이프사이클 전반에 걸친 고려사항(예: 생산 가능성, 유지보수, 재사용 가능성 등)과 프로젝트 견적에 유용한 설계 정보들을 검토합니다. 이 과정에서 하드웨어 요소와 관련된 특수 특성(Special Characteristics)도 도출하게 됩니다. 또한 아키텍처 대안을 비교하고 설계 선택의 근거(rationale)를 기록하는 것도 이 활동의 핵심입니다.
  
  예: ASPICE 4.0에서는 아키텍처 분석 방법의 예로 프로토타입, 시뮬레이션, FMEA 등을 명시하여 권장하고 있습니다. 실제로 “이 설계가 최적인가?”를 따지는 데 FMEA(고장 모드 영향 분석) 같은 기법을 활용하면 시스템 아키텍처의 위험 요소를 찾고 특수 특성을 식별하는 데 도움이 됩니다.
  
  
• SYS.3.BP4: 일관성 확보 및 양방향 추적성 설정 – 시스템 아키텍처의 요소와 시스템 요구사항이 서로 하나씩 빠짐없이 대응되도록 추적성을 구축합니다. 요구사항 대비 설계 요소의 매핑(mapping)을 만들고, 변경 요청이 발생했을 때 영향도를 쉽게 분석할 수 있도록 합니다. 또한 요구사항과 설계 간 모순이나 불일치가 없는지 검토하여 일관성(consistency)을 확인합니다. (참고: ASPICE 가이드에서는 추적성 연결만 만들어 놓는다고 일관성이 자동으로 확보되는 것은 아니며, 내용적 일치를 함께 검증해야 한다고 강조합니다.)
  
  
• SYS.3.BP5: 합의된 시스템 아키텍처 전달 – 최종 확정된 시스템 아키텍처와 식별된 특수 특성을 관련자 모두에게 전달합니다. 시스템 엔지니어링 팀뿐 아니라 소프트웨어, 하드웨어, 테스트 등 모든 이해관계자가 새로운 아키텍처를 공유받아 알아야 하기 때문에, 필요한 커뮤니케이션 활동(회의, 설명회, 문서 배포 등)을 수행합니다.

위 Base Practice들을 수행하는 과정에서 생성되는 대표적인 산출물(Output Information Item)들도 정의되어 있습니다. ASPICE 4.0에서 SYS.3와 관련된 주요 산출물은 다음과 같습니다:

• System Architecture – 시스템 아키텍처 산출물 (주로 문서 또는 모델 형태)
• Consistency Evidence – 일관성 및 추적성에 대한 증적 자료
• Communication Evidence – 아키텍처를 커뮤니케이션한 증적 자료
• Analysis Results – 아키텍처 분석 결과 자료
• Special Characteristics – 식별된 특수 특성에 대한 정보

이들 각각은 아래에서 자세히 설명하겠지만, 쉽게 말해 “시스템 설계도”와 이를 뒷받침하는 부수적인 기록들이라고 생각하면 됩니다. SYS.3 프로세스를 거치면 이러한 산출물이 남게 되며, 이것들이 모여 시스템 아키텍처 설계 패키지를 이룹니다.

프로세스 수행 지표 (PPI)와 SYS.3

ASPICE 4.0에서는 프로세스 수행 지표(PPI: Process Performance Indicators)라는 개념을 도입하여, 각 프로세스가 제대로 수행되었는지를 판단하고 측정합니다. 간단히 말하면 “해당 프로세스를 수행한 증거”라고 할 수 있는데, 구체적으로는 Base Practice와 산출물(Output Information Item) 두 가지가 이에 해당합니다.

• Base Practices: 앞서 열거한 SYS.3의 BP1~BP5가 바로 프로세스 수행의 활동 지표입니다. 각 Base Practice가 실제로 수행되었는지를 보면 프로세스의 구현 여부를 알 수 있습니다. 예를 들어 BP1과 BP2가 수행되었다면 정적/동적 아키텍처 설계 활동이 이뤄진 것이고, BP4가 수행되었다면 추적성 구축이 되었다는 뜻입니다.
  
  
• Output Information Items: 프로세스를 수행하면 결과물로 남는 산출물입니다. SYS.3의 경우 시스템 아키텍처 문서, 일관성 증적, 의사소통 기록, 분석 결과, 특수 특성 목록 등이 산출물 지표에 해당합니다. 이 항목들이 실제로 산출되고 적절히 관리되고 있다면 SYS.3 프로세스가 성과를 내고 있다는 증거가 됩니다.

PPI는 주로 프로세스 평가(Assessment) 시에 활용됩니다. 예를 들어 어떤 회사의 시스템 아키텍처 설계 프로세스를 평가할 때, 위에 언급한 5가지 Base Practice들이 빠짐없이 실행되고 있는지, 그리고 산출물들이 제대로 생성되어 품질 기준을 만족하는지 (Annex B의 특성 기준 참고) 등을 확인하게 됩니다. ASPICE 4.0에서는 “프로세스 결과”으로 평가가 이뤄지므로, SYS.3의 목적을 달성했다는 것을 보여주는 Outcome (성과)와 PPI 증적이 중요합니다.

요약하자면, SYS.3 프로세스의 PPIs = { BP1, BP2, BP3, BP4, BP5 } + { 시스템 아키텍처, 일관성 증적, 커뮤니케이션 증적, 분석 결과, 특수 특성 }입니다. 엔지니어 입장에서는 “이 다섯 가지 활동을 모두 수행해서 이 다섯 가지 결과물을 잘 남기면 된다”라고 기억해두면 되겠습니다.

4. SYS.3 산출물 정보 항목과 그 특성 (Annex B 참조)

이제 SYS.3 프로세스에서 나오는 핵심 산출물(Output Information Item) 각각이 어떤 모습이어야 하는지 조금 더 자세히 알아보겠습니다. ASPICE 4.0 PAM의 Annex B에서는 각 산출물 유형이 갖춰야 할 특성(Characteristics)을 가이드하고 있습니다. 이를 참고하여, SYS.3 산출물들의 기대되는 내용과 특징을 하나씩 설명해보겠습니다.

• 시스템 아키텍처 (System Architecture): SYS.3의 가장 중요한 산출물입니다. 말 그대로 시스템의 구조와 설계를 담은 결과물이죠. 일반적으로 “시스템 아키텍처 명세서” 혹은 “시스템 설계 문서” 등의 형태로 작성됩니다. 이 산출물에는 다음과 같은 내용이 포함되어야 합니다:
  • 시스템 요소 정의: 시스템을 구성하는 서브시스템, ECU, 센서, 액추에이터 등의 요소들을 모두 식별하고 기술합니다. 각 요소의 역할과 책임도 설명되어야 합니다.
  • 아키텍처 선정 근거: 왜 그런 구조로 설계를 했는지 설계 판단의 근거(rationale)를 명시합니다. (예: 기존 컴포넌트 재사용 여부, 제품 라인 전략, 기술 제약 고려 등)
  • 요구사항 할당: 어떤 요구사항이 어떤 요소에 할당되었는지 보여줍니다. 이를 통해 각 요소가 구현해야 할 기능/특성이 추적 가능하도록 합니다.
  • 구성 요소별 동작: 각 시스템 요소의 개별 동작 방식과 상호 작용을 설명합니다. (예: “센서 A가 신호를 보내면 제어기 B가 이를 받아 C를 구동한다” 등)
  • 인터페이스 정의: 요소들 간의 인터페이스를 상세히 정의합니다. 여기에는 전기적 인터페이스, 통신 버스(proto: CAN, LIN 등), 기계적 연결(커넥터, 볼트), 소프트웨어-하드웨어 인터페이스(HSI) 등 시스템 구성요소 사이의 모든 연결 특성이 포함됩니다. 예를 들어 “센서와 ECU 간에는 CAN 버스로 연결되며 메시지 프로토콜은 ~이다” 또는 “ECU와 액추에이터는 전압 신호로 연동된다” 등의 내용을 명시합니다.
  • 시스템 모드 및 상태: 시스템의 상태(state)와 운영 모드(operation modes)에 따른 시스템 요소들의 동작도 기술됩니다. (예: 기동, 대기, 긴급동작, Limp-home 모드 등 각 상황에서 어떤 요소가 켜지거나 꺼지고, 어떤 상호작용이 있는지)
  • 재사용/플랫폼 요소 식별: 만약 재사용되는 구성요소나 플랫폼이 있다면 이를 식별합니다. (예: “기존 제품에서 검증된 센서 모듈을 재사용” 등)
  • 시스템 파라미터: 시스템의 튜닝 파라미터나 설정값이 있다면 기본 설정과 적용 범위를 기록합니다. (예: 임계값, 보정값 등)
  Note: 시스템 아키텍처 산출물은 흔히 다이어그램과 표로 구성됩니다. 상위 수준의 블록 다이어그램으로 전체 구조를 보여주고, 각 블록(요소)에 대해 상세 설명을 붙이는 식이죠. 또한 인터페이스는 별도 문서(예: “인터페이스 명세서”)로 상세 정의되기도 하지만, ASPICE 4.0에서는 이를 모두 System Architecture 산출물의 일부로 간주합니다. 중요한 것은 정적 구조 + 동적 동작 + 인터페이스 + 근거/비고가 모두 포함되어 일관성 있게 연결되는 것입니다. 추가로, 이러한 시스템 아키텍처 설계시, INCOSE 의 Systems_Engineering_Body_of_Knowledge_(SEBoK) 을 참고하시면 많은 도움이 될 것입니다. (아래 링크의 내용 참고)

 

SEBoK

 

• 일관성 증적 (Consistency Evidence): 이것은 시스템 요구사항과 시스템 아키텍처 설계 간에 일관성과 추적성이 확보되었음을 보여주는 증거 자료입니다. 형태는 정해져 있지 않지만 보통 추적 매트릭스나 검토 보고서 등의 조합으로 구성됩니다. 이 산출물의 주요 특성은 다음과 같습니다:
  • 양방향 추적성 입증: 요구사항부터 설계 요소까지, 그리고 그 반대로 모든 관련 아티팩트가 연계되어 있음을 보여주는 자료입니다. 예를 들어 요구사항 관리 도구에서 요구사항 ↔ 아키텍처 요소 간 링크를 걸어두거나, 표형태로 일일이 매핑을 정리하는 방식을 들 수 있습니다. 핵심은 모든 요구사항이 어떤 설계 요소로 구현되는지 누락 없이 표시되고, 반대로 모든 설계 요소가 어떤 요구에 의해 정당화되는지를 확인할 수 있어야 한다는 점입니다.
    
    
  • 내용적 일치 증거: 추적 링크를 거는 것만으로는 충분치 않고, 실제 내용이 모순 없이 일치함을 보여주는 증거가 필요합니다. 이를 위해 동료 검토(Peer Review)나 워킹 세션을 통해 “요구사항 해석과 설계 구현이 잘 맞아떨어지는지” 확인한 기록을 남길 수 있습니다. 예를 들어 “SYS-REQ-10번 요구를 설계 요소 X와 Y로 분할했는데, 이 분할이 타당한지 리뷰함 – OK” 같은 리뷰 코멘트가 그 증거가 될 수 있습니다. 변경 이력이나 변경 코멘트(Change comment)를 남겨서 요구-설계 간 내용 변경이 추적되도록 하는 것도 방법입니다.
    
    
  • 완전성 확인: 모든 요구사항이 설계에서 다루어졌는지, 그리고 요구사항에 없는 설계 요소가 새로 추가되었다면 (파생 요구사항이라면) 적절히 요구사항 문서에 피드백되었는지 등의 완전성 검증 결과도 여기에 포함될 수 있습니다. 종합하면, 일관성 증적은 “요구사항과 설계가 이음새 없이 들어맞는다”는 것을 증명하는 자료입니다. 흔히 요구사항-설계 추적성 매트릭스, 검토 체크리스트, 리뷰 미팅 기록 등이 이에 해당합니다.
    
    
• 커뮤니케이션 증적 (Communication Evidence): 설계된 시스템 아키텍처를 모든 이해관계자들에게 전달 및 공유한 활동의 흔적입니다. 쉽게 말해 “우리가 설계를 다 했어요”라는 사실을 알리고 공유한 증거입니다. ASPICE 가이드는 이메일, 보고, 회의록 등 다양한 커뮤니케이션 형태를 모두 인정하고 있습니다. 예를 들어 다음과 같은 것들이 커뮤니케이션 증적이 될 수 있습니다:
  • 아키텍처 설계 검토 회의를 열고 회의록을 남긴 것 (참석자, 일시, 주요 결정 사항 포함).
  • 관련 부서에 설계 공지 이메일을 보내고 보낸 메일함에 그 기록이 남아 있는 것.
  • 프레젠테이션 자료를 만들어 설명하고, 그 자료를 배포한 것.
  • 사내 위키/블로그에 새 아키텍처에 대한 게시글을 올려 구성원들이 볼 수 있게 한 것.
  • 이밖에 대면/화상으로 브리핑을 한 경우 녹화본이나 참석자 확인 메모 등도 해당됩니다.
  중요한 점은, 누가 언제 무엇을 공유받았는지를 확인할 수 있어야 한다는 것입니다. 커뮤니케이션 증적을 통해 아키텍처 변경 사실을 모든 관련 팀에 확실히 알렸다는 것을 보여줄 수 있어야 합니다.
  
  
• 분석 결과 (Analysis Results): 아키텍처 분석 및 대안 평가를 수행한 결과를 담은 산출물입니다. 일반적으로 아키텍처 평가 보고서, 의사결정 기록, FMEA 결과표 등의 형태로 존재할 수 있습니다. 이 산출물의 특징은 다음과 같습니다:
  • 분석 대상의 식별: 무엇을 분석했는지 그 대상을 명확히 합니다. (예: “카메라 단일센서 대 레이더 단일센서 대 복합센서” 세 가지 대안을 분석)
  • 분석 기준과 방법: 어떤 기준(criteria)으로 평가했는지를 기록합니다. (예: 비용, 중량, 검출 성능, 안전성 등의 평가 척도와 우선순위, 또는 FMEA의 SEV/DET 점수 등)
  • 분석 결과 결정 사항: 분석을 통해 내린 결정 또는 선택된 대안이 무엇인지, 그리고 그 근거(rationale)를 명시합니다. 왜 그 선택을 했는지 논리와 데이터를 들어 설명해야 합니다. 또한 그 과정에서 전제 assumption로 둔 사항이나 남은 위험 요소도 함께 기록합니다. (예: 특정 센서를 선택하면서 “야간 성능은 향후 시험을 통해 보완 필요” 같은 리스크 언급)
  • 품질 속성 검토: 설계 품질 측면에서 올바름(correctness), 이해용이성(understandability), 검증가능성(verifiability), 실현가능성(feasibility), 타당성(validity) 등의 항목에 대해 분석에 포함되었는지도 확인합니다. 예를 들어 “설계 A는 성능은 좋지만 비용이 너무 높아 현실성이 부족” 등의 평가를 기술하는 것이지요.
  분석 결과 산출물은 의사결정의 투명성을 높이고 향후 문제 발생 시 근거 자료로 활용됩니다. 또한 특수 특성의 식별 과정(예: FMEA를 통해 Severity 높은 항목 도출)도 이 산출물에 담길 수 있습니다.
  
  
• 특수 특성 (Special Characteristics): 특수 특성이란 제품의 안전, 법규 준수, 성능 등에 큰 영향을 미치는 중요 특성을 말합니다. 자동차 품질 표준 IATF 16949나 VDA 지침에서 정의하는 바에 따르면, 설계 또는 제조 공정상의 이러한 특성들은 별도로 관리되어야 합니다. SYS.3 프로세스에서는 시스템 아키텍처 단계에서 이러한 특성을 식별하고 목록화하는 것이 산출물로 남습니다. 특수 특성 산출물의 특징은 다음과 같습니다:
  • 관련 표준에 따른 정의: IATF 16949:2016 등에 따르면 특수 특성은 제품 특성 또는 프로세스 파라미터 중에서 안전이나 법규 준수, 기능, 성능, 제조 후 공정에 영향을 줄 수 있는 것들을 말합니다. 쉽게 말해 이 특성이 목표치를 벗어나면 심각한 문제가 되는 항목들이죠 (예: 브레이크 제동력, 에어백 전개 속도, ECU 열발산 등).
    
    
  • 명확한 식별과 표시: 이러한 특성은 설계 산출물에서 별도로 식별되어야 합니다. 실제 자동차 회사들은 도면이나 명세서에 특수 특성 항목에 별도의 기호나 표식을 붙여 관리합니다. SYS.3 산출물에서도 “어떤 요소의 어떤 속성이 특수 특성이다”라는 식으로 표 또는 목록을 만듭니다.
    
    
  • 검증 가능성: 특수 특성은 반드시 측정 가능하거나 테스트 가능한 형태로 정의되어야 합니다. 그래야만 이후 검증 단계를 통해 이 특성이 확보되었는지를 확인할 수 있기 때문입니다. (예: “최대 제동력 0.8g 이상”은 측정 가능하므로 특수 특성으로 좋지만, “충분히 강하게 제동”은 애매해서 안 됩니다)
    
    
  • 식별 방법: 특수 특성은 주로 FMEA와 같은 분석 기법을 통해 식별됩니다. SYS.3.BP3 분석 단계에서 엔지니어들이 FMEA를 수행하며 Severity나 높은 요인을 찾아내면, 그것이 특수 특성으로 지정되는 식입니다. ASPICE 가이드에서도 특수 특성 식별에 FMEA가 유용한 방법이라고 언급하고 있습니다.
  특수 특성 산출물은 품질/안전 팀과 공유되어 이후 개발 프로세스(예: 설계 상세화, 제조 공정 개발 등)에서 특별 관리 대상으로 이어집니다. 예를 들어 “레이더 센서의 장착 각도 오차”가 특수 특성으로 지정되었다면, 나중에 생산 시에 그 각도를 엄격히 관리하고 검사하도록 프로세스를 구성하게 되는 식입니다.

이상이 SYS.3 프로세스의 주요 산출물과 각각의 기대 특성들입니다. 이해를 돕기 위해 다음 섹션에서는 AEB 시스템 예시를 통해 이러한 산출물이 어떻게 만들어지고 활용되는지 한 번 따라가 보겠습니다.

5. 예시: AEB 시스템의 요구사항부터 아키텍처 설계까지

이제 전방 카메라와 레이더 센서, 브레이크 액추에이터로 구성된 자동 긴급 제동(AEB) 시스템 사례를 들어, SYS.3 프로세스가 어떻게 현실에 적용되는지 살펴보겠습니다. 일반적으로 AEB 시스템은 인지(센싱) - 판단(ECU 제어) - 실행(브레이크 동작)의 3계층 구조로 나눌 수 있습니다. 우리 예시에서는 전방 카메라와 레이더 센서가 인지 계층, AEB ECU가 판단 계층 (판단 계층의 AEB S/W 의 경우 레이더 또는 전방 카메라 센서 ECU 에 포함될 수도 있고, 별도 DCU 에 포함될 수 있습니다. 여기서는 별도의 AEB ECU 로 설정하겠습니다), 브레이크 모듈이 실행 계층 역할을 수행한다고 가정하겠습니다.

시나리오 배경:
차량 전방에 장애물이 나타나 급정거가 필요한 상황에서, 운전자가 브레이크를 밟지 않으면 차량이 자동으로 감지하고 브레이크를 제어하여 충돌을 피하거나 피해를 줄여야 한다 – 이러한 AEB 기능을 개발한다고 가정합니다.

 

이제 SYS.3의 흐름에 맞춰, 시스템 요구사항으로부터 아키텍처를 도출하고 문서화하는 일련의 단계를 순서대로 따라가 보겠습니다:

1. 시스템 요구사항 분석 및 정리: 우선 AEB 기능에 대한 시스템 요구사항(SYS.2 산출)을 입력으로 받아야 합니다. 예를 들어, AEB 관련 요구사항에는 다음과 같은 것들이 있을 겁니다:
   • “차량 전방 100m 내 장애물을 감지할 것” (감지 성능 요구)
   • “충돌 예상 시 운전자 경고 후 X초 이내에 자동 제동을 개시할 것” (기능 동작 요구)
   • “AEB 시스템은 오탐지로 인한 불필요한 제동을 최소화할 것” (성능/품질 요구)
   • “시스템 고장 시 운전자에게 경고등을 표시할 것” (고장 대응 요구)
     
     이처럼 다양한 요구사항을 토대로, 다음 단계에서 어떤 구성요소와 구조가 필요한지 생각하게 됩니다.
2. 시스템 아키텍처 구조 설계 (정적 측면, BP1): 요구사항을 만족하기 위한 시스템 요소들을 식별하고 전체 구조를 설계합니다. AEB 예시의 경우 다음과 같은 구성으로 아키텍처를 잡을 수 있습니다:
   • 전방 카메라 센서 – 보행자/차량을 시각적으로 인식 (장점: 물체 유형 식별 가능).
   • 전방 레이더 센서 – 동적 물체 인지 및 물체까지의 거리와 속도를 측정 (장점: 악천후에도 거리 감지 정확).
   • AEB ECU – AEB 제어 논리를 실행하는 전자 제어 장치(프로세서). 카메라/레이더 데이터를 받아 위험을 판단하고 브레이크 제어 명령을 출력.
   • 브레이크 액추에이터 모듈 – ECU 명령에 따라 브레이크 유압을 제어하거나 모터를 작동시켜 실제 차량 감속을 수행 (예: 전동 브레이크 부스터나 ABS 모듈 활용).
   • HMI 경고 등 – 운전자 경고를 위한 계기판 경고등, 알람음 등.
   이 시스템을 하나의 블록 다이어그램으로 그려보면, 센서들 → ECU → 브레이크의 흐름으로 연결됩니다. 예를 들어, 카메라와 레이더 센서는 각자 ECU에 데이터를 송신하고, ECU는 Brake 모듈에 제동 명령 출력을 하는 구조입니다. 센서 퓨전 로직을 ECU가 담당하여 두 센서 정보를 종합 판단하도록 설계할 수 있습니다 (카메라와 레이더를 함께 사용함으로써 각각의 단점을 보완하고 신뢰도를 높입니다).
   
   각 요소에는 고유의 ID와 기능 정의를 부여합니다. 예컨대 “CAM1: 전방 카메라 – 객체 인식 (차량/보행자 분류)”, “RAD1: 전방 레이더 – 거리/상대속도 측정”, “ECU_AEB: 제동 제어 ECU – 충돌위험 판단 및 제동 제어”, “BRK1: 브레이크 모듈 – 제동력 구현” 등으로 정의합니다. 이렇게 하면 요구사항 할당과 추적에 유용합니다.
   (실제 제품은 이렇게 간단하지 않습니다. 카메라의 경우도 인식, 거리 측정, 속도 측정, Quality 측정, Class 판단 등 다양합니다.)
   
   
3. 동적 동작 및 상호작용 설계 (동적 측면, BP2): 이번에는 시간 흐름에 따른 동작 시퀀스와 시스템의 모드별 행동을 설계합니다. AEB 시스템의 대표적인 시나리오로 “전방 충돌 위험 발생부터 자동 제동 수행까지”를 생각해볼 수 있습니다. 이를 시퀀스 다이어그램 형태로 그려보면:
   • 정상 주행 모드: 카메라와 레이더가 지속적으로 전방을 모니터링하고, ECU는 평소에는 대기 상태로 센서 데이터를 주시만 합니다.
   • 경고 단계: ECU가 어느 임계치 이상으로 충돌 가능성이 높다고 판단하면, 우선 HMI 경고등/알람을 활성화하여 운전자에게 경고합니다.
   • 자동 제동 단계: 운전자가 일정 시간 내 수동 대응하지 않으면, ECU는 브레이크 모듈에 즉시 제동 명령을 보냅니다. 브레이크 모듈은 차량 감속을 시작합니다.
   • 종료 조건: 위험이 해소되거나 차량이 정지하면, ECU는 제동 명령을 해제하고 AEB 개입을 종료합니다. 이후 시스템은 초기 상태로 돌아갑니다.
   이러한 상호 작용 과정을 그림과 함께 설명하고, 각 단계에서 시스템 요소들 간 신호 교환(예: 레이더 → ECU: “거리=50m”, ECU → 브레이크: “제동압력=최대”)을 명시합니다. 또한 시스템 모드로 대기, 경고, 제동, 오작동/고장 등의 상태를 정의하고 전이 조건을 정리합니다. 예를 들어 “고장 모드에서는 AEB ECU가 동작을 중단하고 고장신호만 보낸다 (Limp-home 스타일)” 등의 규칙을 기술합니다.
   
   
4. 시스템 아키텍처 분석 및 특성 평가 (BP3): 앞서 설계한 구조와 동작이 요구사항을 만족하면서 현실성 있는지 다양한 각도에서 분석합니다. 주요 분석 활동은 다음과 같습니다:
   • 대안 비교 검토: 혹시 다른 센서 구성이나 제어 전략이 있는지 검토합니다. 예를 들어 “레이더만 사용하는 A안, 카메라만 사용하는 B안, 둘 다 사용하는 C안”을 놓고 장단점과 요구사항 충족도를 평가해볼 수 있습니다. C안(카메라+레이더 조합)이 감지 신뢰도를 높일 수 있지만 비용과 복잡도가 증가할 것입니다. 이러한 trade-off를 표로 정리하고, 고객 요구(예: 유럽 NCAP 안전규격 충족) 등을 고려하여 최종 선택을 정당화합니다. 여기서는 “센서 2개 조합이 비용은 높지만 안전 목표 달성을 위해 필요하므로 채택”과 같은 의사결정 근거를 명확히 기록합니다.
     
     
   • 성능 및 자원 분석: 설계가 시간적/공간적 성능 요구를 만족할지 따져봅니다. ECU의 처리 성능으로 두 센서 데이터를 실시간 처리 가능할지, 제동 개시까지의 지연 시간이 요구 (X초 이내)에 부합할지 계산합니다. 만약 현재 ECU 사양으로 부족하다면 더 강력한 프로세서 필요성이 도출될 수 있죠. 메모리, 통신 대역폭 등 자원 측면도 검토합니다.
     
     
   • 신뢰성/고장 분석: FMEA 기법으로 각 구성요소의 고장 모드가 시스템에 미치는 영향을 분석합니다. 예를 들어 “레이더 고장 시 카메라만으로도 최소 제동을 할 수 있는가?”, “ECU 전원 상실 시 실패 안전 동작은 무엇인가?” 등을 평가합니다. 이 과정에서 안전상 중요한 특성(예: 제동 시스템의 단일고장허용) 등이 특수 특성으로 식별될 수 있습니다. 도출된 위험에 대해서는 요구사항을 보완하거나(예: “ECU 고장 시 경고등 켜기” 요구 추가) 설계 대책을 고려합니다.
     
     
   • 제품 수명주기 고려: 생산, 정비, 폐기 단계까지 염두에 두고 문제가 될 부분이 없는지 점검합니다. 예를 들어 “레이더 센서의 캘리브레이션은 공장 생산 시 어떻게 할 것인가?”, “카메라 장착부 정렬은 서비스 시에도 유지될 수 있는가?” 등을 생각해보는 것이죠. 이런 부분에서 특수 관리가 필요한 항목이 있으면 특수 특성으로 기록합니다.
   이러한 분석 활동의 결과는 앞서 언급한 Analysis Results 산출물로 정리됩니다. 예컨대 “최종 아키텍처로 C안을 선택 – 이유: 신뢰도 향상. 가정: 레이더 부품 단가는 XX$ 이하로 유지. 위험: 레이더와 카메라 간 sensor fusion 알고리즘 복잡도 증가로 개발 리스크 존재”와 같은 내용이 그 보고서에 담길 것입니다. 또한 FMEA를 통해 “브레이크 액추에이터 응답 시간”이 매우 중요한 특성임을 알게 되었다면, 이를 Special Characteristic 목록에 추가합니다 (예: “특수 특성 #1: 최대 제동 응답 지연 = 0.2초 이하”).
   
   
5. 추적성 확보와 일관성 확인 (BP4): 시스템 요구사항 문서 대비 우리가 설계한 아키텍처를 한 줄 한 줄 매핑해봅니다. AEB 예를 들어 보죠:
   • 요구사항 “100m 내 장애물 감지” → 카메라 + 레이더 구성으로 충족 (두 센서의 감지거리 스펙이 100m 이상임을 설계에 반영).
   • 요구사항 “X초 내 자동제동” → ECU 소프트웨어 알고리즘 + 브레이크 모듈 응답으로 충족 (ECU 처리시간 + 브레이크 시스템 응답이 X초 이내라는 설계를 명시).
   • 요구사항 “오탐 최소화” → 카메라+레이더 센서 융합 알고리즘으로 오탐율 감소 (설계 결정으로 반영).
   • 요구사항 “고장 시 경고등” → ECU 고장진단 기능 + HMI 경고등으로 구현 (아키텍처에 해당 기능 포함).
   이처럼 모든 요구사항이 대응되는 설계 요소/메커니즘을 찾았는지 확인합니다. 누락된 요구사항이 발견되면 설계에 추가하거나, 필요시 요구사항을 수정해야 합니다. 반대로 설계 상에서 새로 식별된 요구가 있다면 (예: “듀얼 센서 간 동기화 필요” 같은 세부 요구) 이를 요구사항 문서에 피드백하여 추가/수정하게 됩니다. 이런 과정을 거쳐 요구 ↔ 설계 추적 매트릭스를 작성하면 Consistency Evidence 산출물의 핵심이 완성됩니다.
   
   Note : 추적성 매트릭스는 관리 도구를 활용하면 편리합니다. DOORS, Polarion, Codebeamer 등의 요구관리 툴과 Enterprise Architect 와 같은 모델링 툴을 연계하면 요구와 설계 간 링크를 자동으로 검사할 수 있습니다. ASPICE에서는 링크가 있는지만 보는 게 아니라 내용이 일치하는지도 봐야 하므로, 사람의 리뷰가 여전히 필요합니다. 그래도 링크 덕분에 변경 영향 분석이나 누락 확인이 훨씬 수월해지므로, 가능한 자동화된 추적성을 구축하는 것이 좋습니다.
   
   
6. 그리고 해당 매트릭스나 링크를 가지고 검토 회의를 진행합니다. 시스템 요구 담당자와 아키텍트들이 모여 “매핑이 타당한지, 혹시 모순은 없는지” 함께 확인하죠. 예를 들어 “카메라로 보행자 인식한다고 했는데 요구사항에는 보행자 검출 명시가 없네? 추가하자.” 또는 “센서 융합으로 오탐 줄인다고 했는데, 혹시 한쪽 센서가 틀린 정보 주면 어떻게 되지?” 등의 토론을 거칩니다. 이 과정에서 발견된 불일치는 수정하고, 모든 사람이 동의하면 “요구사항과 아키텍처 일관성 OK”로 마무리합니다. 이때 회의록이나 리뷰 결과를 일관성 증적으로 저장해 둡니다.
   
   
7. 산출물 문서화 및 공유 (BP5): 이제 확정된 시스템 아키텍처와 관련 산출물들을 정리하여 공식 문서화합니다. 시스템 아키텍처 명세서에는 최종 구조도와 인터페이스 정의, 동작 시나리오 등이 모두 반영되도록 업데이트합니다. 분석 결과 보고서와 특수 특성 목록도 첨부하거나 관련 저장소에 함께 보관합니다. 모든 산출물에는 버전을 부여하고 형상관리 저장소에 등록하여 형상 통제를 합니다.
   • 부서 간 설계 리뷰 미팅 개최: 각 팀 리드들을 모아 아키텍처 설명 프레젠테이션을 진행하고 질의응답을 받습니다. 이때 나온 의견으로 경미한 수정사항이 생길 수도 있고, 모두 동의하면 승인을 받습니다.
     
     
   • 설계 패키지 배포: 이메일로 아키텍처 문서와 첨부자료를 전체 팀에 배포하고 확인을 요청합니다. 혹은 사내 협업툴(예: Confluence, SharePoint 등)에 문서를 올리고 공지하는 방법도 좋습니다.
     
     
   • 추후 변경 관리 안내: 아키텍처가 이후 바뀔 경우의 Change Control 프로세스를 공지합니다. 예컨대 “이후 변경 시에는 시스템 아키텍처 문서 vX.y에 변경 기록을 남길 것” 등 절차를 알립니다.
   이러한 활동을 통해 모든 관련자가 새로운 시스템 아키텍처를 인지하게 됩니다. 만약 이해관계자 중 누군가 정보를 받지 못하면 개발 진행에 차질이 생길 수 있으므로, 꼼꼼히 커뮤니케이션 증적을 남겨두는 것이 중요합니다 (예: 메일 수신 확인, 회의 참석자 리스트 등).
   
   
8. 그런 다음, 이러한 최종 산출물을 관련 부서에 전파합니다. AEB 시스템의 경우 차량 제어 소프트웨어팀, 하드웨어 회로팀, 검증 테스트팀 등 여러 팀이 이 아키텍처 정보를 필요로 합니다. 다음과 같은 커뮤니케이션 활동을 수행할 수 있습니다:

이상으로 AEB 시스템 예시를 따라 SYS.3 프로세스를 한 바퀴 돌아보았습니다. 처음에는 다소 복잡해 보이지만, 요약하면 “요구사항을 받아 -> 시스템 구조를 만들고 -> 잘 됐는지 분석한 후 -> 요구대비 매칭 확인하고 -> 결과물을 모두 문서화해서 공유한다”는 일련의 흐름입니다. 이 과정에서 도출된 산출물들은 차후 시스템 통합 단계나 소프트웨어/하드웨어 요구사항 단계의 입력으로 쓰이게 되어, 개발의 일관성을 유지시켜 줍니다.

---

마지막으로, 실제 현업에서 ASPICE의 요구사항을 모두 완벽히 따르는 것은 어려울 수 있습니다. 하지만 SYS.3 프로세스가 강조하는 핵심 – “체계적인 설계와 근거, 그리고 추적 가능성” – 만은 꼭 기억하시기 바랍니다. 예제를 통해 보았듯이, 요구사항을 구조로 풀어내고, 그 결과를 분석/검증하며, 이를 투명하게 기록하고 소통하는 일련의 작업은 안전하고 신뢰성 있는 ADAS/자율주행 시스템 개발에 필수적인 요소입니다.

 

ASPICE 4.0의 SYS.3를 준수하려는 노력은 곧 제품의 품질 향상으로 이어질 것입니다. 초기엔 문서작업이 늘어나 부담스러울 수 있지만, 잘 정리된 시스템 아키텍처와 추적성은 개발 후반의 시행착오를 줄이고, 협업을 원활하게 만들어줍니다. 엔지니어로서 이러한 시스템적인 사고 방식을 익혀두면 큰 자산이 될 것입니다.