개요
자동차 소프트웨어 개발은 요구 분석, 아키텍처 설계, 상세 구현, 단위 검증, 통합 검증에 이르기까지 일정한 흐름과 절차를 갖춘 고도화된 엔지니어링 활동입니다. 이러한 활동을 체계적으로 운영하도록 규정하는 표준이 Automotive SPICE®로 수렴하며, AUTOSAR 기반 ECU 소프트웨어 개발에서는 SWE.1부터 SWE.6까지의 프로세스가 기술 활동과 가장 직접적으로 연결됩니다. AUTOSAR가 소프트웨어 구조화, 재사용성, 표준화된 통신/진단 프레임워크를 제공한다면, SWE 프로세스는 이러한 기술적 활동을 어떤 절차, 산출물, 추적성 체계로 관리해야 하는지를 정의합니다. 따라서 두 체계를 자연스럽게 통합해 운영하는 것은 고품질 ECU 소프트웨어 개발의 본질적 전략이라 할 수 있습니다.
SWE.1 - 소프트웨어 요구사항 분석
AUTOSAR 요구로의 구조화와 요구 특성 기반 정의
SWE.1에서는 시스템 요구를 소프트웨어 요구로 정제하고, 이후 AUTOSAR 설계 요소와 연계 가능하도록 구조화하는 과정을 수행합니다. Classic AUTOSAR 개발에서는 SWC 단위로 요구를 구조화하며, Port 및 인터페이스 요구, Runnable 실행 조건과 주기, Timing 제약, Safety와 Security 등 요구사항의 주요 특성을 명확하게 정의해야 합니다. Automotive SPICE® 4.0에서는 기능/비기능 요구의 구분을 하기보다 모든 요구사항이 갖추어야 할 특성(명확성, 검증 가능성 등)을 충족하는지가 핵심 평가 요소입니다. 검증 기준 역시 요구의 고유 특성으로 통합되어 별도 활동으로 분리되지 않습니다.
SWE.1에서 정의된 요구사항은 arxml 요소(SWC, Port, Interface, Runnable 등)와의 연계성이 확보되어야 하며, RTE 생성 결과와의 추적성을 확보하는 것은 단순 표준 준수를 넘은 실용적인 실무 적용 용례입니다. 요구 분석이 제대로 이루어지지 않으면 이후 설계와 검증 단계에서 재작업이 반복되므로, SWE.1의 완성도는 전체 AUTOSAR 개발 품질을 좌우하는 가장 중요한 기반입니다.
SWE.2 - 소프트웨어 아키텍처 설계
AUTOSAR 요소(arxml) 기반 구조 정립과 설계 정당성 확보
SWE.2에서는 소프트웨어 구조를 정의하고 구성요소 간 관계를 AUTOSAR 모델을 중심으로 정교하게 설계합니다. SWC 구조, Runnable 분할 전략, 인터페이스 설계, 서비스 호출 관계, BSW 의존성, OS 스케줄링과 Task 매핑 등이 ECU Extract 기반의 시스템 구성을 바탕으로 정제됩니다.
Automotive SPICE® 심사에서는 설계 문서와 arxml 모델 간 불일치가 가장 자주 지적되며, 모델 기반 개발 방식과 일관된 변경관리 체계로 개선 가능합니다. Automotive SPICE® 4.0에서는 ‘대안 아키텍처 평가’가 단순화되어, 선택된 아키텍처가 요구와 제약 조건에 비추어 적절히 정당화되었는지를 설명하는 것이 핵심입니다.
SWE.3 - 소프트웨어 상세 설계 및 유닛 구현
구현과 직접 연결되는 정밀 설계와 설계–모델–코드 정합성 확보
SWE.3는 소프트웨어 구성요소의 내부 동작을 상세하게 정의하는 단계입니다. Runnable 단위의 처리 로직, 데이터 타입과 구조, 오류 처리 방식 등 구현과 직결되는 사항을 명확히 설계해야 합니다. AUTOSAR 개발에서는 상세설계가 구현 코드 및 arxml 모델과 자연스럽게 연계되어야 하며, Config Tool에서 생성되는 설정값이 수작업 코드와 모순되지 않도록 정합성을 유지하는 것이 중요합니다. 상세설계가 미비하면 SWE.4의 단위 검증 품질이 저하된다는 점을 염두에 두셔야 합니다.
SWE.1/SWE.2/SWE.3 흐름 간단 예
BMS 셀 전압 모니터링하는 요건을 가지고 SWE.1~3의 흐름에 대한 예를 살펴보겠습니다. 시스템에서 소프트웨어로 할당한 요구사항은 다음과 같습니다.
“BMS는 96개 셀의 전압을 100 ms 주기로 측정하고, 셀 전압이 4.25 V를 초과하면 과전압 경고를, 2.50 V 미만이면 저전압 경고를 발생시켜야 합니다. 측정 정확도는 ±5 mV 이내, 응답 지연은 15 ms 이하이며, ASIL B를 만족해야 합니다.”
SWE.1 소프트웨어 요구사항 분석 단계에서는 특정 AUTOSAR 아키텍처 요소를 직접 언급하지 않고, 이후 SWC, Runnable, Timing 제약 등 arxml 요소로 추적 가능하도록 순수 요구사항만 정의합니다. 즉, 100 ms 주기 셀 전압 측정, 상한 4250 mV 및 하한 2500 mV 기준 경고 발생, 정확도 ±5 mV, 응답 지연 15 ms 이하, ASIL B 준수 등의 내용만 명확하게 기술하고 각각 추적성 ID를 부여합니다.
SWE.2 소프트웨어 아키텍처 설계 단계에 들어서야 비로소 위 요구사항을 만족시키는 구조를 설계합니다. 요구사항을 만족시키기 위해 CellVoltageMonitoring_SWC라는 AUTOSAR SWC를 정의하고, 96개 셀 전압을 수신하는 Receiver Port 하나와 과전압/저전압 경고를 각각 제공하는 Provider Port 두 개를 정의합니다. 내부에는 CellVoltageMonitor_Runnable 하나만 두고 100 ms 주기 이벤트로 실행되도록 설계하며, 이 Runnable을 Bms_100ms_Task에 매핑합니다. 동시에 ExclusiveArea 보호와 End-to-End 타이밍 제약 15 ms 이내를 RTE 계약으로 명시하고, 단일 Runnable 구조를 선택한 이유(구성 간결, 메모리 사용 최소화, 재사용성 향상 등)를 간단히 정당성으로 기술합니다.
SWE.3 소프트웨어 상세 설계 단계에서는 Runnable 내부 로직만 집중적으로 다룹니다. 96개 셀 전압 배열을 순회하면서 상·하한값과 비교하고, 기준을 벗어나면 해당 경고 플래그를 TRUE로 설정하는 흐름을 의사코드 수준으로 작성합니다. ADC 읽기 실패 시 이전 값을 유지하고 Fault Counter를 증가시키는 예외 처리도 포함합니다. 모든 내용은 arxml의 Runnable 및 InternalBehavior 요소와 정확히 일치하도록 정합성을 확보합니다.
SWE.4 - 소프트웨어 유닛 검증
구현된 유닛이 요구/설계와 일치함을 입증하는 단계
SWE.4의 목적은 구현된 소프트웨어 유닛이 요구사항 및 설계 의도에 따라 올바르게 동작함을 입증하는 것입니다. AUTOSAR 기반 개발에서는 자동 생성 코드와 수작업 코드가 공존하므로, 각 코드 유형에 대한 검증 수준을 조직 차원에서 명확히 정의해야 합니다. 자동 생성 코드에 대해서도 요구 및 설계와의 정합성 검증은 반드시 수행해야 합니다.
SWE.5 - 소프트웨어 컴포넌트 검증 및 통합 검증
유닛 → 컴포넌트 → ECU 전체로 이어지는 단계적 검증 체계
SWE.5는 소프트웨어 요소들이 통합된 환경에서 의도된 대로 상호작용하는지 확인하는 단계입니다. AUTOSAR 기반 프로젝트에서는 인터페이스 불일치, RTE 계약 위반, Task 스케줄링 문제, Timing chain 위반, 통신 스택 설정 오류 등이 자주 발생하므로 SWE.5의 중요성이 매우 큽니다.
Automotive SPICE® 4.0에서는 SWE.5가 이전 버전 대비 크게 강화되었습니다. 컴포넌트 수준 검증 활동이 명확히 포함되어, 유닛 검증(SWE.4) 후 바로 ECU 전체 통합 검증으로 넘어가는 기존 관행을 개선했습니다. 이제는
- 유닛을 SWC(컴포넌트) 단위로 통합하여 기능적 동작 검증 → Software Component Verification
- 컴포넌트를 ECU 전체로 통합하여 검증 → Integration Verification의 2단계 검증 체계를 명확히 수립/운영해야 합니다. 이는 AUTOSAR SWC 구조와 완벽히 부합하는 변화입니다.
SWE.6 - 소프트웨어 검증
ECU 소프트웨어가 요구를 충족하는지 최종적으로 평가하는 단계
Automotive SPICE® 4.0에서 SWE.6 명칭이 Software Qualification Test → Software Verification으로 변경되었습니다. 목적은 동일하며, ECU 소프트웨어가 OEM 요구, 안전 요구, 성능 요구 등을 충족하는지를 최종적으로 검증합니다.
Classic AUTOSAR에서는 E2E 보호, Diagnostic 서비스, 통신 프로토콜 구현 등이 주요 검증 대상이며, SWE.6는 통합 소프트웨어(Integrated SW) 레벨에 집중합니다. 차량 레벨 검증은 SYS.5 / VAL 프로세스에서 수행하므로 범위 혼동을 방지해야 합니다.
AUTOSAR–SWE 통합 프로세스에서 발생하기 쉬운 문제와 개선 방향
- arxml 모델 ↔ 설계 문서 불일치
- 요구–설계–테스트 간 추적성 부족
- 자동 생성 코드 검증 누락
- BSW 설정 변경의 버전 관리 미흡
→ 모델 기반 개발(MBD)을 중심에 두고, 문서/코드/테스트를 동일한 변경관리 체계에서 운영하면 근본 해결 가능합니다.
결론: AUTOSAR와 Automotive SPICE® 4.0 결합은 품질과 경쟁력을 동시에 확보하는 핵심 전략
AUTOSAR는 구조적 기반을, SWE 프로세스는 품질 확보 절차를, Automotive SPICE®는 평가 기준을 제공합니다. Automotive SPICE® 4.0에 맞춰 세 체계를 유기적으로 통합하는 것이 SDV 시대에 기술 품질, 개발 효율, 심사 대응력을 모두 확보하는 가장 현실적이고 강력한 전략입니다.