ASPICE 4.0 SWE.2: 소프트웨어 아키텍처 설계 (AEB 예제)

1. Introduction

오늘은 ASPICE 4.0의 SWE.2 소프트웨어 아키텍처 설계 프로세스에 대해 알아보겠습니다. ASPICE(Automotive SPICE)는 자동차 소프트웨어 개발 프로세스를 평가하고 향상하기 위한 품질 모델입니다. SWE.2는 그 중 소프트웨어 아키텍처 설계 단계로, 요구사항을 만족하는 소프트웨어 구조를 체계적으로 수립하는 것이 목적입니다.

 

이 글에서는 자동 긴급 제동 시스템(AEB, Automatic Emergency Braking)을 예제로 삼아 AUTOSAR 기반 소프트웨어 아키텍처 설계를 살펴보겠습니다. AEB는 전방의 차량이나 보행자를 센서로 감지하여 충돌 위험이 높을 때 자동으로 브레이크를 거는 첨단 운전자 지원 시스템입니다. ADAS 소프트웨어 개발자가 애플리케이션 소프트웨어와 베이직 소프트웨어(BSW)를 모두 다루는 것으로 가정하여, AUTOSAR 관점에서 정적 설계와 동적 설계를 구분하여 설명하겠습니다. 또한 ASPICE 4.0의 베이스 프랙티스(Base Practices, BP)별로 실제 활동 사례를 들어보고, 각 산출물이 어떤 형식으로 만들어지며 ASPICE Annex B에 정의된 정보 특성(일관성, 추적성, 검증가능성 등)을 어떻게 충족해야 하는지도 함께 다뤄보겠습니다.

 

2. SWE.2 소프트웨어 아키텍처 설계란? (Purpose & Outcomes)

SWE.2 프로세스의 목적은 소프트웨어 요구사항을 만족하는 아키텍처 설계를 수립하고, 각 요구사항을 어떤 소프트웨어 요소가 담당할지 할당하며, 설계된 아키텍처를 다양한 기준으로 평가하는 것입니다. 궁극적으로 좋은 소프트웨어 아키텍처를 만들어 팀원들과 합의하는 것이 목표입니다.

 

SWE.2의 성과(Outcomes)를 요약하면 다음과 같습니다:

1. 소프트웨어 아키텍처 정의 – 소프트웨어를 구성하는 요소들(컴포넌트 등)이 정의되고 구조가 수립됩니다. (어떤 기능이 어떤 모듈/SW 컴포넌트로 구성되는지)
2. 요구사항 할당 – 소프트웨어 요구사항들이 개별 소프트웨어 요소에 할당됩니다. 각 요구를 구현할 책임이 어느 부분에 있는지 맵핑됩니다.
3. 인터페이스 정의 – 각 소프트웨어 요소의 인터페이스(입출력 및 상호작용 방식)가 명확히 정의됩니다. (컴포넌트 간 데이터 교환, 호출관계 등)
4. 동적 동작과 자원 사용량 정의 – 소프트웨어 요소들의 동적인 동작(런타임 상호작용, 시퀀스, 스레드 등)과 목표 자원 사용량(메모리, CPU 등 성능 목표)이 정해집니다.
5. 추적성 및 일관성 확보 – 소프트웨어 요구사항과 아키텍처 요소 간에 양방향 추적성(traceability)이 수립되고, 요구사항과 설계 간 일관성이 보장됩니다.
6. 아키텍처 합의 및 공유 – 완성된 소프트웨어 아키텍처 설계가 이해관계자들에게 검토/승인되고, 관련 모든 팀원에게 효과적으로 공유(커뮤니케이션)됩니다.

위의 결과들을 통해, 우리는 요구사항에서 출발하여 일관되고 검증가능한 소프트웨어 구조를 얻을 수 있습니다. 다음 섹션부터 이러한 결과를 달성하기 위한 구체적인 활동(BP들)을 AEB 예제를 통해 살펴보겠습니다.

 

3. 정적 소프트웨어 아키텍처 설계 (Static Design)

정적 설계란 소프트웨어의 정적 구조를 설계하는 것입니다. 즉, 소프트웨어를 어떤 컴포넌트들로 구성하고, 이들이 어떻게 관계를 맺는지 결정하는 단계입니다. 정적 뷰(static view)에서는 S/W의 객체, 컴포넌트, 속성, 관계 등의 구조에 초점을 둡니다. 이는 흔히 클래스 다이어그램, 컴포넌트 다이어그램 등으로 표현되며, 동적 뷰(dynamic view)와 대비됩니다 (동적 뷰는 런타임 시 객체들의 상호작용과 상태변화를 다룹니다).

 

SWE.2의 BP1: 소프트웨어 아키텍처의 정적 측면을 명세 활동에 해당하며, AUTOSAR를 활용한 AEB 예제로 구체적인 정적 설계 활동을 알아보겠습니다.

3.1 소프트웨어 컴포넌트 분할 (SW-C Partitioning)

첫 번째로 할 일은 AEB 기능을 달성하기 위해 필요한 소프트웨어 컴포넌트들을 정의하고 분할하는 것입니다. AUTOSAR 기준으로 애플리케이션 레이어에 들어가는 SW-C (Software Component)들을 식별합니다. 일반적으로 AEB 시스템의 기능을 생각하면 세 가지 계층으로 볼 수 있습니다: 인지(Perception), 판단(Decision), 실행(Execution)

• 인지 컴포넌트들 (Perception): 전방 상황을 인지하는 역할의 SW-C입니다. 예를 들어 레이더 센서 컴포넌트와 카메라 센서 컴포넌트를 둘 수 있습니다. 이들은 각각 레이더와 카메라로부터 장애물 정보를 수집합니다. AEB 시스템에서는 두 센서 정보를 퓨전(fusion)하여 더 정확한 객체 인식을 하는데, 이를 처리하는 센서 융합 컴포넌트도 정의합니다. (카메라로 대상 유형과 위치 파악, 레이더로 거리와 속도 파악 후 융합 등)
• 판단 컴포넌트 (Decision): AEB의 두뇌에 해당하는 부분입니다. 센서들로부터 융합된 환경 정보를 받아들여 충돌 위험을 판단하고 제동 여부를 결정합니다. AUTOSAR SW-C로 AEB 판단 로직 컴포넌트를 만들 수 있습니다. 이 컴포넌트는 내부 알고리즘으로 물체와의 TTC(Time to Collision)를 계산하거나, 위험 수준을 판단하여 긴급제동을 트리거할지 결정합니다. 예컨대 “충돌까지 남은 시간이 X초 이하이고 운전자가 회피하지 않는 경우 제동 명령” 같은 룰을 구현합니다. 또한 Forward Collision Warning(FCW) 단계와 실제 Automatic Braking(AB) 단계를 구분하여 경고만 할지 브레이크까지 할지 판단할 수도 있습니다.
  
  
• 실행 컴포넌트들 (Execution): 결정된 제동 명령을 실제 차량 제어로 연결하는 SW-C입니다. 일반적으로 브레이크 제어는 ESC(Electronic Stability Control)와 같은 제어기가 담당하므로, AEB ECU에서 ESC로 제동 요청을 보내야 합니다. 이를 위한 브레이크 인터페이스 컴포넌트를 정의합니다. 이 컴포넌트는 ESC 제어기와 통신하여 제동압을 지시하거나, 브레이크등을 켜는 등의 출력을 담당합니다. 만약 AEB 기능이 ESC ECU 내에 구현된다면, 해당 ECU 소프트웨어 안에 AEB 로직이 들어가고 직접 액추에이터 제어까지 할 수도 있지만, 여기서는 이해를 돕기 위해 AEB 제어 ECU와 ESC ECU가 CAN 통신하는 구조를 가정하겠습니다.

위처럼 기능별로 SW-C를 모듈화(modularity)하면 각 컴포넌트는 명확한 책임을 가지므로 응집도는 높이고 결합도는 낮출 수 있습니다. 또한 이렇게 분할된 SW-C들은 AUTOSAR RTE(Runtime Environment)를 통해 통신하므로, 서로 독립적으로 개발되고 Basic Software 서비스나 OS 자원을 공유합니다. 아키텍처 설계 산출물로는 이러한 SW-C들의 구조적 다이어그램(예: 컴포넌트 다이어그램)이 작성됩니다. 이 다이어그램이나 문서에는 SW-C 계층 구조, 각 컴포넌트의 기능 설명, 그리고 하위에 정의될 소프트웨어 유닛(구현 단위)들에 대한 개요까지 포함될 수 있습니다.

 

정보 특성 충족: SW-C 분할을 할 때 산출물(예: 소프트웨어 아키텍처 명세서)에는 완전성이 필요합니다. 즉, 정의된 모든 컴포넌트 를 합치면 요구된 기능을 빠짐없이 커버해야 합니다. 또한 컴포넌트 정의 간 일관성이 있어야 하고 (예: 동일한 용어와 원칙으로 설계), 각 컴포넌트가 추후 상세 설계와 구현 가능한 수준으로 명확하게 기술되어야 합니다.

 

3.2 인터페이스 설계 (Interface Design)

컴포넌트를 정의했으면, 이제 컴포넌트 사이의 인터페이스를 상세히 설계해야 합니다. 이는 SWE.2의 BP3 “소프트웨어 요소의 인터페이스 정의”에 해당하는 부분입니다. 인터페이스란 컴포넌트들이 데이터를 주고받는 창구로, AUTOSAR에서는 포트(Port)와 인터페이스(Interface)로 모델링됩니다.

 

예를 들어 AEB 센서 융합 컴포넌트는 레이더 컴포넌트와 카메라 컴포넌트로부터 입력을 받아야 합니다. 이를 위해 레이더/카메라 컴포넌트에는 탐지한 객체 정보를 내보내는 Sender(센더) 포트가, 센서 융합 컴포넌트에는 이를 받는 Receiver(리시버) 포트가 정의됩니다. 전송 데이터는 예컨대 객체_목록 또는 거리/속도 데이터 등의 신호로 정의하며, 신호의 데이터 타입, 단위 등이 명시되어야 합니다. AUTOSAR 송수신 인터페이스(S-R Interface)를 사용해 이러한 주고받는 데이터 요소들을 정의하게 됩니다.

 

또한 AEB 판단 로직 컴포넌트는 융합된 센서 정보를 받아야 하므로, 센서 융합 컴포넌트와의 인터페이스를 정의합니다. 그리고 판단 결과(“즉시 제동” 여부 등)를 브레이크 인터페이스 컴포넌트에 전달해야 하므로 그 사이에도 인터페이스가 필요합니다. 이를 위해 판단 컴포넌트가 브레이크 요청 신호를 출력하는 Sender 포트, 브레이크 컴포넌트가 받는 Receiver 포트를 가집니다. 이 신호는 예컨대 제동_요청_레벨 (0=no brake, 1=partial, 2=full brake 같은)으로 정의할 수 있습니다.

 

Basic Software와의 인터페이스도 고려해야 합니다. 센서 데이터는 실제로는 CAN 혹은 Ethernet 통신으로 다른 ECU에서 들어올 수 있습니다. 이 경우 AUTOSAR COM Stack과 RTE 설정을 통해 해당 신호가 센서 컴포넌트로 매핑되도록 해야 합니다. 예를 들어 레이더 ECU에서 주기적으로 송출하는 CAN 메시지 Radar_Object를 AEB ECU의 레이더 컴포넌트 입력으로 연결합니다. 마찬가지로 AEB ECU가 ESC ECU로 보내는 제동명령은 CAN 메시지 AEB_BrakeCmd로 정의되어 나가야 하며, 브레이크 인터페이스 컴포넌트의 출력과 연결됩니다. 이러한 ECU 간 신호 흐름 설계도 SW 아키텍처의 일부입니다 (시스템 아키텍처와 연계됨).

 

AUTOSAR 컴포넌트 간 인터페이스는 크게 Sender-Receiver(데이터 흐름)와 Client-Server(서비스 호출) 형태가 있습니다. AEB 예제에서는 주로 주기적인 센서 데이터와 이벤트성 브레이크 명령 등이므로 Sender-Receiver로 모델링했습니다. 반면 진단 서비스 요청 같은 건 Client-Server로 할 수도 있습니다. 인터페이스 설계 산출물로는 각 포트별 제공/요구되는 신호 목록, 데이터 사전, ID 등이 문서화되거나 ARXML로 산출됩니다.

 

ASPICE 정보 특성 측면에서 인터페이스 명세서는 명확성과 호환성이 중요합니다. 명확성은 데이터의 단위, 범위, 해석이 모호하지 않게 정의되는 것이고, 호환성은 송신측과 수신측 정의가 일치해야 한다는 것입니다 (예: 데이터 타입 일치, 스케일링 일치 등). 또한 모든 컴포넌트 인터페이스 합이 시스템 레벨에서 일관성있게 맞아야 합니다. ASPICE Annex B의 정보 항목 정의에 따르면 소프트웨어 아키텍처에는 각 소프트웨어 컴포넌트의 개별적인 기능/비기능 동작, 관계 간 인터페이스의 기술적 특성 등이 담겨야 합니다. 예를 들어 인터페이스의 기술적 특성에는 프로세스 사이의 동기화 방법, API, 호출 메커니즘, 라이브러리 의존성 등이 포함됩니다. 이러한 요소들을 꼼꼼히 문서화하면, 이후 구현단계에서 오해 없이 개발할 수 있고 검증 단계에서도 추적 가능합니다.

 

3.3 Runnable 및 태스크 매핑 (Runnable Mapping to Tasks)

정적 설계의 마지막 활동으로, 소프트웨어 컴포넌트의 내부 런너블(runnable)과 OS 태스크(task) 매핑에 대해 언급하겠습니다. (이는 동적 동작과도 관련되지만, 설정 자체는 아키텍처의 정적 일부분이므로 여기서 다루도록 하겠습니다.)

 

런너블은 컴포넌트 내부의 실행 단위 함수 블록입니다. AUTOSAR에서 각 SW-C는 하나 이상의 Runnable을 갖고, 각 Runnable은 이벤트에 의해 스케줄됩니다 (예: 주기 타이머, 데이터 수신, 모드 전이 등). 아키텍처 설계 단계에서 우리는 컴포넌트별 주요 Runnable을 정의하고, 이것들이 어떤 주기로 동작해야 하는지 결정합니다. 그리고 이러한 Runnable들을 어떤 태스크 컨텍스트에서 실행할지 할당(mapping)합니다.

 

예를 들어 센서 융합 컴포넌트의 FusionProcess라는 런너블은 50ms 주기로 실행되어 최신 레이더/카메라 데이터를 융합한다고 가정합시다. AEB 판단 컴포넌트의 BrakeDecision 런너블은 10ms 주기로 실행되어 항상 위험을 체크하고 즉각 반응하도록 설계할 수 있습니다 (더 자주 실행하여 빠른 반응). 브레이크 인터페이스 컴포넌트의 SendBrakeCmd 런너블은 BrakeDecision이 낸 신호를 감지할 때마다 (DataReceivedEvent) 실행되어 ESC로 CAN 메시지를 보낼 것입니다.

 

이러한 Runnable들을 OS Task에 배치하는 것은 중요합니다. AUTOSAR OS에서 태스크는 우선순위와 주기를 가지므로, 예를 들어 10ms 주기의 우선순위가 높은 태스크에 BrakeDecision을 넣고, 50ms 주기의 중간 우선순위의 태스크에 FusionProcess를 넣는 식입니다. 이렇게 하면 브레이크 결정이 항상 센서융합보다 빠르게 주기적으로 실행되어도, 실제 데이터는 이전 주기의 융합 결과를 사용하게 될 수 있겠죠. (필요하면 FusionProcess도 10ms로 맞출 수도 있습니다.) 또한 센서 수신 처리나 CAN 송신도 각각 태스크 문맥에서 이루어집니다.

 

아키텍처 설계 산출물로 태스크/런너블 맵핑표가 작성됩니다. 여기에는 어떤 컴포넌트의 어떤 Runnable이 어떤 Task에 속하고, 주기/트리거, 우선순위, 예상 실행시간(WCET) 등이 명시됩니다. 이는 곧 시스템 성능 요구를 만족하기 위한 설계인데, ASPICE에서는 이를 동적 행위와 자원 소비 목표 정의의 일부로 간주합니다. 이러한 매핑은 훗날 시간 분석이나 스케줄링 검증의 근거가 되므로, 정확하고 추적 가능하게 관리되어야 합니다. (예: 요구사항에 “0.1초 이내 브레이크”가 있다면, 10ms 태스크 주기로 설계한 근거로 해당 요구를 만족한다고 추적)

 

정보 특성 충족: 태스크/런너블 설계에서는 일관성과 효율성이 중요합니다. 일관성은 컴포넌트의 중요도와 태스크 우선순위 등이 부조화 없게 하는 것이고, 효율성은 자원 활용 목표 내에서 설계하는 것입니다. 예를 들어 CPU 부하 분산이나 메모리 여유를 고려해야 합니다. ASPICE Annex B는 아키텍처 정보에 소프트웨어 요소들의 개별적인 기능/비기능 동작뿐 아니라 자원 소비(Resource consumption) 목표도 포함하도록 권장합니다. 여기에는 각 요소별 예상 메모리 사용량(ROM, RAM), CPU부하 등이 있습니다. 이러한 정보를 아키텍처 문서에 명시하면 설계의 검증가능성이 높아집니다. (예: 실제 측정과 비교 검증이 가능하므로)

 

4. 동적 아키텍처 설계 (Dynamic Design)

동적 설계는 소프트웨어의 런타임 동작을 설계하는 단계입니다. 정적 설계가 ‘어떤 부품들로 소프트웨어를 구성하는가’였다면, 동적 설계는 ‘그 부품들이 시간에 따라 어떻게 상호작용하는가’를 다룹니다. SWE.2의 BP2: 소프트웨어 아키텍처의 동적 측면을 명세하는 활동에 해당합니다

 

동적 동작을 설계할 때는 시스템의 모드/상태, 컴포넌트 간 메시지 흐름의 시퀀스, 병행 동작과 타이밍 등을 고려해야 합니다. AUTOSAR 시스템에서는 모드 관리, 이벤트 및 인터럽트, 그리고 여러 ECU 사이의 통신이 모두 동적 행위의 일부입니다.

AEB 사례로 동적 설계 내용을 구체화해 보겠습니다.

4.1 소프트웨어 모드 전이 (Modes & States)

AEB 기능은 주행 중 상태 변화에 따라 다르게 동작해야 할 수도 있습니다. 예를 들어 차량에 드라이브 모드, 충돌 경고 단계(FCW), 자동 제동 단계(AB) 등의 논리가 있습니다. 이러한 동적 상태(mode)를 모델링하면 시스템 동작을 더 명확히 표현할 수 있습니다.

 

AUTOSAR에는 모드 관리(Mode Management) 기능이 있어 ECU나 SW-C별 모드를 정의하고 전환할 수 있습니다. AEB의 간단한 예로 AEB_On/Off 모드를 생각해봅시다. AEB Switch (운전자가 AEB 기능을 켜고 끌 수 있다고 가정) 상태나 차량 속도에 따라 AEB 동작이 활성/비활성 모드로 전환될 수 있습니다. 예를 들어 차량 속도가 15km/h 미만이면 AEB를 끔 (매우 저속에서는 작동 안 하도록) 등의 모드 조건을 둘 수 있습니다.

 

모드 전이 다이어그램을 그려서, Normal 상태 -> AEB_Active 상태로 들어가는 조건, 다시 비활성화되는 조건 등을 나타냅니다. 이러한 모드 전이는 ModeSwitchEvent 등을 통해 런너블 실행에도 영향을 줍니다 (활성 모드일 때만 AEB 판단 runnable이 돌도록). AEB 시스템 자체의 모드 외에도, 차량 전체 모드 (예: Ignition On/Off, 에코/스포츠 모드 등)가 AEB 기능에 영향을 줄 수 있음을 고려해야 합니다.

 

예를 들어 AUTOSAR BswM(Basic Software Mode Manager)을 통해 차량 시동 꺼짐 상태에서 AEB 관련 통신을 정지시킨다든지, ESC 시스템의 상태(예: 현재 제동 중인지 등)를 모니터하여 AEB 결정에 사용한다든지 하는 시나리오가 있습니다. AEB 판단 컴포넌트는 ESC로부터 차량 안정화 제어중 같은 플래그를 받아와서 이미 ESC가 개입한 상황이면 추가 제동을 스킵할 수도 있습니다. 이처럼 여러 컴포넌트/ECU 간의 상태 동기화가 필요하면 모드 관리를 활용하는 것이 좋습니다.

 

동적 설계 산출물로 이러한 상태/모드 다이어그램 또는 상태표가 작성됩니다. 이는 요구사항 (예: “AEB 기능은 시속 10km 이하에서는 비활성화 되어야 한다”)을 구현하기 위해 상태 논리가 잘 반영되었는지 검증하는 데 쓰입니다. 정보 특성 측면에서는 상태 정의의 일관성 (모든 가능한 상태를 정의하고 모호성 없게 전이 조건 명확히)과 추적성 (각 상태나 전이 규칙이 어떤 요구사항에서 왔는지 링크)이 중요합니다.

 

4.2 런너블 시퀀스 및 통신 시퀀스 (Runnable Sequence & Interactions)

정적 설계에서 정의한 컴포넌트와 인터페이스를 토대로, 실제 런타임 시퀀스를 그려보는 것이 동적 설계입니다. 이는 시퀀스 다이어그램이나 활동 다이어그램 (Activity Diagram) 형태로 표현될 수 있습니다. 특히 다중 ECU 상황에서는 시퀀스 다이어그램이 효과적입니다. 이제 AEB 시나리오에서 긴급제동 발생 시퀀스를 간략히 생각해보죠.

1. 레이더/카메라 센서 ECU들은 주기적으로 전방 객체 정보를 CAN 메시지로 방송합니다. (예: Object_List 메시지, 50ms 마다)
2. AEB 제어 ECU의 레이더 SW-C와 카메라 SW-C는 RTE/COM을 통해 그 데이터를 받아 옵니다 (데이터 수신 이벤트 발생).
3. 해당 이벤트에 반응하여 센서 융합 컴포넌트의 런너블 FusionProcess가 즉시 실행됩니다 (혹은 주기적으로 동작하며 내부적으로 최신 데이터를 가져올 수도 있음). 이 runnable은 레이더+카메라 정보를 취합해 객체_위협리스트를 산출합니다.
4. 그 결과는 RTE 버퍼를 통해 AEB 판단 로직 컴포넌트에 제공됩니다. AEB 판단 runnable BrakeDecision은 주기적으로 실행되며, 매 사이클마다 최신 위협리스트를 읽어옵니다. 여기서 가장 가까운 객체와의 TTC를 계산하고, 위험도가 임계치를 넘으면 “긴급제동 필요” 플래그를 True로 설정합니다.
5. BrakeDecision 런너블은 True로 바뀐 플래그를 RTE를 통해 브레이크 인터페이스 컴포넌트로 전달합니다. 이때 인터럽트 혹은 이벤트가 발생했다고 가정할 수 있습니다. (AUTOSAR에서는 DataReceivedEvent 또는 모드전이 이벤트 등으로 구현 가능)
6. 브레이크 컴포넌트의 SendBrakeCmd 런너블이 즉각 실행되며, ESC로 CAN 통신을 통해 제동 명령 메시지 AEB_BrakeCmd를 보냅니다. 이 메시지에는 필요한 제동 강도나 속도가 포함되어 있습니다. 동시에 브레이크등 ON 신호도 차량 네트워크에 전송될 수 있습니다.
7. ESC ECU는 해당 메시지를 수신하면, ESC 소프트웨어가 차량의 브레이크 유압을 제어하여 실제 제동을 수행합니다.

위 과정을 시간 순서대로 그린 시퀀스 다이어그램은 개발팀과 테스트팀이 시스템 동작을 이해하는 데 큰 도움을 줍니다. 각 선은 ECU와 컴포넌트를 나타내고, 화살표는 메시지나 호출, 활성화 이벤트를 표시합니다. 이러한 동적 상호작용 설계는 Outcome 4에서 언급한 “소프트웨어 요소들의 타이밍과 동적 상호작용이 요구되는 동적 행위를 충족하는지 평가”하는 근거가 됩니다. ASPICE 가이드에서는 동적 행위로 운영 모드(e.g. start-up, shutdown, normal, 진단 등), 프로세스/태스크 간 상호통신, 주기/사이클, 인터럽트 우선순위, 동시 실행 간 상호작용 등을 예시로 들고 있습니다.

 

AEB의 경우 시동 -> 정상주행 -> 긴급제동 -> 복귀 같은 시나리오를 시퀀스로 표현해볼 수 있습니다. 예를 들어 긴급제동 중에는 일부 다른 기능(ACC 등)을 일시 중지하는 식의 시퀀스도 있을 수 있습니다. 이러한 시퀀스 설계는 시스템의 대응 시간 요구 (예: 응답시간 100ms 이내) 등을 만족하도록 튜닝되어야 합니다. 만약 시퀀스 상으로 병목이나 지연이 발생하면, 정적 구조로 돌아가 조정을 해야 합니다. (예: 컴포넌트 분리를 재고하거나 태스크 우선순위 조정 등)

 

정보 특성 충족: 시퀀스 설계 산출물은 일반적으로 검증 가능성(Verifiability)을 높입니다. 시퀀스 다이어그램 자체가 요구사항 시나리오(예: “앞차 급정거 시 AEB 동작 순서”)를 충족하는지 시뮬레이션하거나 리뷰할 수 있기 때문입니다. 동적 설계 문서에는 시간 제약, 신호 흐름 등이 정확히 기술되어야 하며, 이는 곧 일관성(정적 설계와 모순 없어야 함) 및 완전성(모든 주요 시나리오를 다루었는지)과 연결됩니다. 예를 들어 “센서 신호 손실 시 타임아웃 처리” 같은 예외 시나리오도 동적 설계에 포함되면 견고성(robustness) 측면까지 만족하게 됩니다.

 

마지막으로, 다중 ECU 간 통신 부하나 버스 지연도 동적 행위의 일부입니다. AEB의 CAN 메시지들이 버스 용량을 넘지 않도록 주기나 데이터 크기를 설계했는지, 혹은 Ethernet이라면 대역폭은 충분한지 등을 검토해야 합니다. 이러한 자원 소비 목표도 동적 설계에서 다루며, 필요시 시뮬레이션/분석을 통해 설계를 뒷받침해야 합니다.

 

5. 아키텍처 대안 평가 및 개선 (Architecture Analysis & Evaluation)

좋은 설계를 위해서는 한번에 딱 최적 해법을 내놓기 어렵습니다. SWE.2 BP3: 소프트웨어 아키텍처 분석 활동에서는, 여러 설계 대안을 평가(Evaluate)하고 최종 아키텍처를 선택하는 작업이 포함됩니다. 즉, 아키텍처 설계 단계에서 다양한 접근을 비교 분석하고, 선택된 구조에 대한 정당한 근거(rationale)를 기록해야 합니다.

 

예를 들어 AEB 시스템을 설계하면서 다음과 같은 대안을 고려해볼 수 있습니다:

• 대안 1: AEB 판단 로직을 별도 ADAS ECU에서 수행하고 ESC와 통신 (우리가 위에서 설계한 방식).
• 대안 2: 아예 ESC ECU 내부에 AEB 알고리즘을 포함시켜, 센서 데이터를 ESC ECU가 직접 수신하여 판단까지 수행. 이 경우 통신 지연이 감소하고 구현이 단순해질 수 있으나, ESC ECU의 부하가 증가합니다.
• 대안 3: 이중화된 아키텍처 – 센서 2개를 독립 채널로 처리하여 하나는 경고 위주, 다른 하나는 제동 결정 (Doer-Checker 패턴)으로 만들어 안전성을 높이는 방법. 예를 들어 레이더 기반과 카메라 기반 충돌 판단을 두 채널에서 하고 상호 검증해 오탐을 줄이는 구조.

각 대안별로 장단점 평가 기준을 세울 수 있습니다. ASPICE에서는 품질 속성 예시로 모듈성, 유지보수성, 확장성, 안전성, 보안성 등을 언급합니다. 우리 사례에선:

• 대안1은 ECU 분리로 기존 ESC 시스템에 영향 적고 확장성 높으나, 통신 지연과 ECU 비용이 증가.
• 대안2는 실시간성 우수하고 비용 절감되나, ESC 소프트웨어 복잡도가 증가하고 벤더 종속적일 수 있음.
• 대안3는 신뢰성 향상(한 채널 오류 시 다른 채널로 커버 가능)하지만 개발비용 크고 시스템 복잡도가 큽니다.

이러한 분석을 통해 프로젝트 요구 (예: 비용 vs 성능 vs 안전) 에 최적인 아키텍처를 선정합니다. 선정 후에는 왜 이 아키텍처를 택했는지 근거를 기록해야 합니다. 예컨대 “통신 지연 50ms 이내 요구를 만족하고 기존 ESC SW 변경 최소화를 위해 대안1 선택”과 같이 명시합니다. 이 기록은 나중에 변경관리나 리뷰 시 유용한 이력 근거(evidence)가 됩니다.

 

또한 아키텍처 분석 단계에서는 자원 소비 목표도 구체화합니다. 즉, 메모리는 몇 KB 사용, CPU 부하는 몇 % 이내, CAN 버스 부하는 몇 % 등 목표치를 정하고 현재 설계가 이를 만족할지 평가합니다. 만약 예상치가 목표를 넘는다면, 다시 구조를 조정하거나 요구사항과 협의해야 합니다. 예를 들어 AEB 기능 추가로 ECU CPU 부하가 80%->95% 된다면, 더 성능 좋은 MCU를 쓴다든지, 알고리즘을 최적화한다든지의 액션이 필요할 것입니다.

산출물: 아키텍처 대안 평가 결과는 보통 아키텍처 평가 보고서나 의사결정 기록 형태로 남습니다. 여기에는 고려한 대안들, 평가 기준, 점수 혹은 장단점 비교표, 최종 결정 및 근거가 포함됩니다. ASPICE 4.0에서는 이런 것을 Analysis Results(분석 결과) 정보 항목으로 취급합니다. 실제로 SWE.2 프로세스의 Output으로 Analysis Results가 언급되어 있습니다.

 

정보 특성 충족: 이 산출물은 추적성있게 관련 요구사항(특히 비기능 요구)과 연결되어야 합니다. 또한 평가 기준과 선택 근거가 명확하고 일관되게 작성되어, 나중에 다른 사람이 봐도 이해할 수 있어야 합니다 (예: 유지보수팀이 왜 이런 구조인지 이해). 검증가능성은 여기서 선택 근거가 요구사항을 실제로 만족하는지 증명하는 것으로 나타납니다. 만약 “50ms 이내”가 근거라면, 시뮬레이션이나 계산으로 그 수치가 나왔음을 증거로 남기는 것이 좋습니다.

 

아키텍처 분석에는 Make or Buy 결정(외부 솔루션 사용 여부)이나 재사용 컴포넌트 평가도 포함될 수 있습니다. 우리 예제에서는 예를 들어 “센서 융합 알고리즘을 오픈소스로 가져올지” 같은 고민이 있을 수 있는데, 이런 의사결정도 근거를 남겨야 합니다.

 

마지막으로 리스크 분석도 병행됩니다. 특정 아키텍처 선택으로 인한 위험(예: 대안2 선택 시 ESC ECU 메모리 부족 위험)을 식별하고 대응해야 합니다. 이런 내용은 Risk Management 프로세스와 연결되지만, 아키텍처 단계에서 인지하고 있으면 추후 문제를 예방할 수 있습니다.

 

6. 요구사항 추적 및 일관성 확인 (Traceability & Consistency – BP4)

SWE.2의 Outcome 중 하나는 요구사항과 아키텍처 간의 일관성과 양방향 추적성 확보였습니다. 이를 달성하기 위한 활동이 BP4: 일관성 확보 및 추적성 수립입니다.

 

추적성(Traceability)이란 각 소프트웨어 요구사항이 어디에서 구현되고 있는지, 그리고 각 아키텍처 요소가 어떤 요구사항에서 유래했는지를 서로 연결짓는 것입니다. 예를 들어 AEB 시스템의 요구사항 중 “시스템은 충돌 예상 시 0.5초 이내에 브레이크를 자동 제동해야 한다”는 항목이 있다고 합시다. 이 요구는 아키텍처의 AEB 판단 컴포넌트와 브레이크 인터페이스 컴포넌트에 걸쳐서 실현됩니다. 우리는 요구사항 관리 도구(DOORS 등의 툴)나 매트릭스를 통해 해당 요구 ID를 이 두 컴포넌트에 링크합니다. 반대로 컴포넌트 쪽에서도 이들이 커버하는 요구사항 ID를 기록해둡니다. 이렇게 하면 요구사항 대비 설계 커버리지(coverage)를 쉽게 볼 수 있고, 나중에 요구 변경 시 영향 분석도 용이합니다. ASPICE 지침도 “양방향 추적성은 커버리지 분석과 변경영향 분석을 지원한다”라고 명시하고 있습니다.

 

일관성(Consistency)은 요구사항 내용과 설계 내용이 서로 모순 없이 일치한다는 뜻입니다. 단순히 링크만 걸어놨다고 자동으로 일관성이 보장되는 것은 아닙니다. 그래서 내용상의 검토(review)가 필요합니다. 예컨대 요구사항에 “이중 센서 사용으로 신뢰도를 높일 것”이라고 쓰여 있는데 아키텍처 설계에서 센서가 하나만 있다면 불일치입니다. 또는 요구사항에 특정 법규 기준 (ISO 뭐 준수) 등이 명시됐는데 설계상 그에 필요한 기능(예: 이벤트 데이터 기록 기능 등)이 누락되었다면 일관성 문제가 됩니다.

 

이를 위해 아키텍처 설계 완료 후 공식 산출물 검토(review)를 수행합니다. SW 아키텍처 문서와 요구사항 사양서를 대조하며, 모든 요구를 아키텍처가 만족하는지 체크리스트를 점검합니다. 발견된 불일치나 누락 사항은 수정 조치를 하고, 문제없을 때까지 반복합니다. 이 리뷰 기록 자체가 ASPICE에서 말하는 일관성 증빙(Consistency evidence)에 해당합니다. 예를 들어 아키텍처/요구사항 상관검토 회의록이나 검토 체크리스트 결과가 그 증거가 될 수 있습니다. (ASPICE 4.0에서는 Output으로 Consistency Evidence라는 항목이 존재합니다.)

 

또 한 가지 일관성은 시스템 아키텍처와의 정합성입니다. AEB 같은 기능은 시스템 레벨에서 하드웨어 할당, 센서/액추에이터 구성 등이 이미 정의되어 있을 것입니다. SW 아키텍처는 시스템 아키텍처(SYS.3 프로세스 산출물)와 모순이 없어야 합니다. 예를 들어 시스템 아키텍처에서 “레이더 센서는 별도 ECU”로 되어 있는데 소프트웨어 아키텍처 설계자가 레이더 처리를 우리 ECU 내 SW-C로 넣어버리면 안 됩니다. 이러한 부분도 검토를 통해 확인해야 합니다.

 

산출물: 추적성은 흔히 요구사항 관리표 또는 추적 매트릭스로 관리됩니다. 간단히는 엑셀 매트릭스로 요구 ID vs 컴포넌트 매핑을 작성할 수도 있고, DOORS 같은 툴에서 링크를 맺고 리포트로 뽑기도 합니다. ASPICE에서는 굳이 산출물 이름을 지정하진 않지만, Traceability가 확보되었다는 증거를 보여줘야 합니다. 일관성의 증거로는 검토 보고서, 시뮬레이션/프로토타입 결과 등이 활용될 수 있습니다.

 

정보 특성 충족: 추적성 및 일관성 활동 자체가 정보 특성을 충족시키기 위한 것이므로, 여기서는 완전성, 일치성, 검증가능성을 모두 다루게 됩니다. 완전성은 모든 요구사항이 빠짐없이 대응되는지 (Trace coverage 100%), 일치성은 요구-설계 간 모순 없음을 (검토 OK), 검증가능성은 이렇게 매핑이 되어야만 이후 테스트 케이스를 효과적으로 도출할 수 있음을 의미합니다. (예: 요구사항 기반 테스트에서, 요구 <-> 컴포넌트 <-> 유닛 단위까지 쭉 추적이 되어야 테스트 결과로 요구 충족 입증 가능). Annex B에서도 “추적성은 커버리지 입증과 변경 영향분석, 검증 커버리지 증명에 활용된다”라고 강조합니다.

 

요약하면, “요구사항 -> 아키텍처 -> 상세설계/코드”로 연결짓는 작업이며, 이는 ASPICE의 핵심 품질 요구 중 하나입니다. ADAS 개발처럼 복잡한 프로젝트일수록 이런 추적성 관리가 중요한데, 끝나고 나면 개발자는 본인 설계가 왜 필요한지, 요구를 어떻게 만족하는지 명확히 설명할 수 있게 됩니다.

 

7. 아키텍처 공유 및 합의 (Communication & Agreement – BP5)

소프트웨어 아키텍처 설계가 완성되면 그것으로 끝이 아닙니다. 해당 아키텍처가 제대로 이해되고, 관련된 모든 사람의 동의(Agreement)를 얻어야 비로소 다음 단계로 진행할 수 있습니다. SWE.2의 마지막 활동인 BP5: 아키텍처 합의된 내용 전달은 이를 다루며, Outcome 6 “아키텍처 설계가 모든 영향받는 당사자들에게 합의되어 전달된다”를 만족시키는 것입니다.

 

아키텍처 합의는 일반적으로 아키텍처 리뷰 회의를 통해 이뤄집니다. 소프트웨어 팀뿐만 아니라 시스템 엔지니어, 하드웨어 팀, 테스트 팀, 품질 담당자 등 관련자 전원이 설계 내용을 검토하고 피드백을 줍니다. ADAS의 경우 안전 관련 이슈가 있을 수 있으므로 기능 안전(FuSa) 팀도 참여하여 아키텍처가 ISO 26262 원칙에 부합하는지 확인할 수 있습니다. (예: ASIL 요구에 따라 독립 채널 필요 등의 의견) 이렇게 각 분야 전문가들의 의견을 반영해 수정이 필요한 부분은 수정하고, 모두가 “이 정도면 되겠다” 합의하면 공식 승인으로 넘어갑니다.

 

합의가 되었다면, 이제 개발팀 전체와 정보를 공유해야 합니다. 아키텍처 산출물을 형상관리 레포지토리에 저장하고 버전 태깅하여 베이스라인(Baselining)합니다. 그리고 개발자들에게 공지하거나, 위키/포털에 게시하여 언제든 열람할 수 있게 합니다. 필요하다면 주요 내용 (컴포넌트 분할, 인터페이스, 시간 설계 등)을 교육하거나 프레젠테이션으로 공유하기도 합니다. 특히 개발자 중에는 어플리케이션 SW 개발자, BSW 구성 담당자, 테스트 작성자 등이 모두 있기 때문에, 각자의 관점에서 필요한 정보를 전달해야 합니다. 예컨대:

• Application 개발자에게는 “컴포넌트 간 인터페이스와 책임 분담”을 명확히 하고,
• BSW 담당자에게는 “필요한 서비스 (통신, 메모리, OS 설정 등)와 자원 요구”를 전달하며,
• 테스트 엔지니어에겐 “어떤 시나리오에 어떤 반응이 설계되었는지” 알려주어 테스트 케이스 설계에 활용하게 합니다.

이렇게 해야 모두가 같은 그림을 보고 개발을 진행하여 통합 시 문제가 줄어듭니다. 만약 커뮤니케이션 없이 각자 생각대로 개발하면 나중에 호환이 안 되어 재작업이 생길 수 있습니다.

 

산출물: 커뮤니케이션의 증거로 남는 것은 보통 회의록, 배포 이메일, 서명된 승인 기록 등이 있습니다. ASPICE 4.0에서는 이를 Communication Evidence라는 정보 항목으로 부릅니다. 예를 들어 아키텍처 설명 회의 실시 및 참석자 명단, 리뷰 승인 서명 로그, 프로젝트 포털 게시물 등을 증빙으로 제시할 수 있습니다. 중요한 건 합의되었다는 상태입니다. 어떤 조직은 Software Architecture Document에 서명란을 넣어 책임자들이 사인하도록 하기도 합니다. 또는 JIRA 같은 툴에서 아키텍처 이슈를 만들고 “승인” 상태로 둬도 됩니다.

 

정보 특성 충족: 이 부분은 주로 이해가능성(understandability)과 적시성(timeliness)에 관한 것입니다. 아키텍처 정보가 전달되어야 할 사람들에게 적시에 전달되고 이해되었는가가 중요하죠. 문서 자체도 가독성 좋게 구조화되어 있어야 하고 (예: 복잡한 다이어그램에 설명이 없이 방치되지 않도록), 변경 발생 시 업데이트가 잘 전파되어야 일관성이 유지됩니다. Annex B에서는 커뮤니케이션을 강조하며, 이해관계자가 모두 참여했음을 명시적으로 추적하라고 합니다 (예: 서명된 합의서: 해당 아키텍처에 관련된 모든 당사자가 참여/동의했음을 보여줌).

 

또한, 형상관리를 통해 올바른 버전의 산출물이 공유되는지도 품질 특성입니다. 만약 개발 도중 아키텍처가 변경되면 (변경도 BP5 활동으로 간주합니다 – 업데이트된 설계를 다시 전파), 이전 버전 문서를 참고해 개발하는 실수를 막아야겠죠. 이를 위해 “최신 버전 식별, 변경 내역 히스토리 관리” 등이 필요합니다.

 

정리하면, 사람과 정보의 연결이 이 단계의 핵심입니다. 아무리 훌륭한 아키텍처도 관련 개발자들이 모르고 있으면 그림의 떡이니까요. ADAS처럼 여러 영역이 융합된 개발에서는 개발 파트 간 의사소통이 특히 중요하므로, 아키텍처 공유 단계에서 충분한 시간과 노력을 들이는 것이 투자 대비 큰 효과를 발휘합니다.

 

8. 주요 산출물 및 정보 항목 특성 (Outputs & Information Item Characteristics)

SWE.2 프로세스에서 나오는 주요 산출물(Output Information Items)과 각각이 가져야 할 정보 특성을 마지막으로 정리해보겠습니다. ASPICE 4.0 기준으로 SWE.2의 출력은 다음과 같이 분류할 수 있습니다:

• 소프트웨어 아키텍처 설명서 (Software Architecture) – 소프트웨어의 정적/동적 설계를 종합적으로 담은 산출물입니다. 보통 문서 또는 모델(AUTOSAR ARXML 등) 형태로 존재하며, 컴포넌트 구조, 인터페이스 정의, 다이어그램, 설계 결정 근거 등을 포함합니다. 이 정보 항목은 일관성, 완전성, 추적성, 명확성 등의 특성을 충족해야 합니다. Annex B에 따르면 소프트웨어 아키텍처 항목에는 선정된 아키텍처에 대한 정당한 근거, 각 소프트웨어 컴포넌트의 개별적인 기능/비기능 동작, 컴포넌트 간 인터페이스의 기술적 특성 (동기화, 호출 방법 등), 소프트웨어 컴포넌트들의 동적 거동 (모드, 스레드, 우선순위, 상호작용 등), 전체적인 주석이나 설명 등이 포함되어야 합니다. 이러한 내용이 충실히 담겨 있으면 검증가능성과 이해가능성이 높아집니다. 예를 들어, AEB 아키텍처 문서에 “야간 보행자 검출 기능은 카메라 센서 SW-C와 AEB 판단 SW-C의 협조로 구현됨” 등이 기술되고 해당 요구사항 ID가 표기돼 있다면, 나중에 그 부분을 집중 테스트하거나 리뷰하기가 쉽습니다.
  
  
• 아키텍처 추적 매트릭스/리포트 (Traceability Matrix) – 요구사항 대비 SW 아키텍처 요소의 추적표입니다. 꼭 별도 문서일 필요는 없지만, DOORS 보고서 등으로 추출해 관리할 수 있습니다. 이 산출물은 완전성(모든 요구사항이 매핑되었는가)과 일관성(잘못된 링크 없는가)이 핵심 특성입니다. 보통은 요구사항 ID -> 아키텍처 컴포넌트 이름의 1:N 관계를 보여주며, 필요한 경우 컴포넌트 -> 요구사항 역방향도 포함합니다. 이 자료는 아키텍처 검증, 테스트 커버리지 분석 때 반드시 필요하므로 최신 상태로 유지되어야 합니다.
  
  
• 아키텍처 평가/분석 결과 (Analysis Results) – 앞서 설명한 아키텍처 대안 평가, 자원 분석 등의 결과를 문서화한 것입니다. 이는 의사결정 로그, SW 아키텍처 평가 보고서 등의 형태로 남습니다. 추적성 측면에서 이 산출물은 특정 품질 요구(성능, 안전 등)와 연관된 결정을 담고 있으므로 해당 요구사항과 연결되고, 또한 선택된 아키텍처에 그 근거를 연결해야 합니다. 일관성 특성은 평가 기준이 일관되고 합리적으로 적용되었는가로 나타납니다. 예를 들어 한 아키텍처를 점수 5점 만점에 4점 줬다면 다른 것도 동일한 기준으로 점수화되어야 공정하겠죠. 검증가능성은 선택 근거가 이후 단계(예: 시험에서 실제로 0.5초 내 제동이 되는지 확인)로 검증될 수 있다는 의미입니다.
  
  
• 소프트웨어 아키텍처 모델 파일들 – AUTOSAR 적용 시 ARXML 등 모델 파일도 산출물입니다. 이는 문서보다는 도구용 산출물이지만, 형상관리되고 팀에 공유되어야 한다는 점에서 중요합니다. 이러한 파일들은 정확성(정의한 내용이 실제 설계와 일치), 일관성(모델 내 참조 무결성), 완전성(필요 요소 다 포함) 등이 필요합니다. 예를 들어 포트 하나를 모델에 정의 안 해놓으면 빌드시 문제되겠죠. ASPICE는 모델도 산출물로 인정하며, 정보 특성은 동일하게 적용됩니다.
  
  
• 검토 기록 및 합의 증빙 (Consistency/Communication Evidence) – 아키텍처 리뷰의 결과, 합의의 증빙 등을 포함합니다. 예컨대 리뷰 체크리스트 표에 “모든 항목 OK” 사인이 있다면 일관성 증빙으로 볼 수 있습니다. 그리고 회의록에 참석자 전원이 승인했다는 내용이 있다면 커뮤니케이션 증빙입니다. 이러한 정보 항목들은 추적성 측면에서는 누가 언제 뭘 확인했는지 추적 가능해야 하고, 무결성 측면에서는 검토한 범위가 전체 아키텍처를 다 커버해야 합니다 (예: 인터페이스만 리뷰하고 동적 동작은 안했다면 불완전). 검증가능성은 실제로 이 검토를 통해 아키텍처가 요구사항에 부합함을 증명했다고 볼 수 있습니다.
  
  
• 형상/버전 정보 – 산출물 자체는 아니지만, 모든 아키텍처 산출물에는 버전과 형상관리 ID가 붙습니다. 이것도 넓게 보면 정보 항목 특성(신뢰성)의 일부입니다. 최신 버전으로 공유되고 과거 변경 내역이 추적 가능한지, 변경시 승인이 이루어지는지 등이 프로세스 품질에 포함됩니다.

마지막으로 Annex B의 정보 항목 특성 관점에서 자주 언급되는 것들을 한 번 더 정리하면: 일관성(consistency), 완전성(completeness), 추적성(traceability), 정확성(corrrectness), 명확성(unambiguity), 검증가능성(verifiability/testability), 변경 용이성(modifiability) 등이 있습니다. 우리가 특히 강조한 일관성/추적성/검증가능성 외에도, 문서가 애매모호하지 않고, 실수나 오류가 없도록 정확해야 하며, 미래에 수정이 필요할 때 구조적으로 수정이 용이한지도 중요한 품질입니다. 예를 들어 아키텍처가 너무 복잡하게 얽혀있으면 요구 변경 시 수정이 어려워지므로, Loose coupling and Hiugh cohesion 원칙(응집도/결합도 등)으로 잘 설계하면 변경 용이성 특성도 향상됩니다.

 

9. 결론

이상, ASPICE SWE.2의 모든 활동과 산출물을 AEB 사례를 통해 살펴보았습니다. 정적 설계부터 동적 설계, 대안 평가, 추적성과 합의까지 전체 그림을 이해하셨길 바랍니다. 이제 실제 ADAS 소프트웨어를 개발할 때, 여기 소개된 ASPICE 내용들을 적용해보시게 되면, 처음에는 다소 절차가 복잡해 보일 수 있지만, “설계를 제대로 해놓으면 구현과 테스트가 수월해진다”는 것을 곧 체감하게 되실 것입니다.