임베디드 소프트웨어 구조_어떤 개념인가

1. 시스템 요구사항 → 시스템 아키텍처 (하드웨어+소프트웨어+기계 등 전체 구조)
2. 시스템 아키텍처 중 소프트웨어에 할당된 요구사항을 추려 소프트웨어 요구사양서 작성
3. 소프트웨어 요구사양을 만족시키기 위해 소프트웨어 아키텍처 설계
   • 이 단계에서 컴포넌트(모듈)를 정의하고, 컴포넌트 간 인터페이스를 설계함 (이때 각 컴포넌트 내부는 블랙박스)
4. 이후 각 컴포넌트 내부를 화이트박스로 보고 소프트웨어 상세설계 수행 (데이터 구조, 알고리즘, 함수 흐름 등)
5. 상세설계를 바탕으로 코드 구현

이 흐름은 자동차 분야에서 ISO 26262 기능안전 표준이나 ASPICE 프로세스에서도 유사하게 정의하고 있습니다.

1. 코드는 어떤 하드웨어에 작성되는가?

말씀하신 대로, 코드는 결국 특한 하드웨어(마이크로컨트롤러, MCU)에 저장되고 실행됩니다.
자동차 부품(ECU) 내부에는 보통 플래시 메모리(비휘발성) 에 코드가 저장되고, 부팅 시 RAM으로 로드되어 CPU가 이를 읽어 연산합니다.

• ECU(Electronic Control Unit) : 엔진, 브레이크, ADAS 등 각 부품을 제어하는 임베디드 시스템
• MCU(Microcontroller Unit) : ECU 안에 있는 핵심 반도체, CPU + 메모리 + 주변 인터페이스(CAN, LIN, ADC 등)를 하나로 통합
• SoC(System on Chip) : 최신 차량에서는 인포테인먼트나 ADAS처럼 고성능이 필요한 경우 SoC를 사용하기도 함

따라서 소프트웨어 설계 팀은 어떤 MCU/SoC를 사용할지 하드웨어 팀과 협의하고, 해당 하드웨어의 메모리 맵, 레지스터, 주변 장치 드라이버 등을 고려하여 소프트웨어 구조를 설계합니다.

---

2. 소프트웨어 아키텍처 수준에서 "컴포넌트 간 인터페이스" 예시

인터페이스는 크게 하드웨어와 가까운 수준(드라이버 계층) 과 애플리케이션 수준(함수 호출, 이벤트) 으로 나뉩니다.

(1) 하드웨어 추상화 계층에서의 인터페이스

예를 들어 CAN 통신을 받는 경우, 소프트웨어 아키텍처에서는 보통 MCAL(Microcontroller Abstraction Layer) 또는 통신 스택이라는 컴포넌트를 두고, 그 위의 상위 컴포넌트는 다음과 같은 인터페이스로 CAN 데이터를 받습니다.

• Can_Read(CAN_CHANNEL, &message)
• Can_Write(CAN_CHANNEL, message)

여기서 message는 이미 CAN ID, 데이터 길이, 데이터 바이트 등이 구조체로 추상화된 상태입니다.
즉, 소프트웨어가 직접 물리적인 전압 차이(CAN_H/CAN_L)를 읽는 것이 아니라, CAN 컨트롤러 하드웨어가 전압을 디지털 프레임으로 변환해주고, 드라이버가 이를 소프트웨어가 이해할 수 있는 형태(구조체)로 제공합니다.

마찬가지로 전압값도 ADC(Analog-to-Digital Converter) 하드웨어가 전압을 디지털 값(예: 0~4095)으로 변환하면, 드라이버가 Adc_Read(channel) 같은 인터페이스로 제공합니다.

(2) 애플리케이션 계층에서의 인터페이스

더 상위의 소프트웨어 컴포넌트(예: 브레이크 제어 컴포넌트, 차속 추정 컴포넌트) 간에는 보통 함수 호출 수준의 인터페이스를 설계합니다.

• Brake_Apply( pressure_target )
• VehicleSpeed_Get( ) → speed_kmh

이런 함수들은 내부 변수나 다른 컴포넌트의 출력을 입력으로 받으며, CAN 메시지나 전압값이 직접 들어오는 것이 아니라 이미 가공된 의미 있는 정보(차속, 압력 목표치 등) 가 전달됩니다.

---

3. "소프트웨어가 직접 인풋으로 받는 수준" 정리

따라서 소프트웨어 아키텍처 설계 시에는 “어떤 컴포넌트가 어떤 하드웨어 리소스(CAN, ADC, GPIO 등)를 통해 어떤 정보를 어떤 형태로 받을지”를 명확히 정의하고, 그 정보를 가공하여 상위 컴포넌트에 전달할 때는 하드웨어 의존성을 제거한 추상화된 인터페이스로 설계합니다.

---

4. 추가로 보완할 점

• 말씀하신 “컴포넌트 안은 블랙박스로 보고 인터페이스 설계 → 이후 화이트박스로 상세설계”는 계층적 분할 방식에서 정확합니다. 다만 실제 업계에서는 아키텍처 단계에서도 중요한 내부 알고리즘이나 안전 관련 메커니즘은 화이트박스 수준까지 일부 미리 정의하기도 합니다.
• 자동차 소프트웨어는 최근 AUTOSAR 표준을 많이 따르는데, 여기서는 위에서 말한 MCAL, 통신 스택, RTE(런타임 환경), SWC(소프트웨어 컴포넌트) 등이 명확히 구분되어 인터페이스가 표준화되어 있습니다.
• “코드 구현까지가 소프트웨어 설계의 마무리”라고 하셨는데, 업계에서는 보통 상세설계까지가 설계 단계로 보고, 코딩은 구현 단계로 구분합니다. 다만 실무에서는 설계자와 구현자가 같은 경우 경계가 모호해지기도 합니다.

정리하자면, 소프트웨어 설계 팀은 요구사항 → 아키텍처 → 상세설계 → 구현까지 책임지며, 특히 아키텍처 단계에서 하드웨어 추상화를 통해 소프트웨어가 다루는 인터페이스의 범위(드라이버 수준 ~ 애플리케이션 함수 수준)를 정의합니다. 코드는 특정 MCU/SoC의 플래시 메모리에 저장되어 실행되며, 소프트웨어는 하드웨어가 1차적으로 변환해준 디지털 정보(CAN 프레임, ADC 값 등)를 입력으로 받게 됩니다.

 

네, 말씀하신 대로 자동차 업계(특히 AUTOSAR 기반)에서는 소프트웨어를 크게 ASW(Application Software) 와 BSW(Basic Software) 로 나눕니다.
BSW 안에는 MCAL, 통신 스택, RTE 등이 포함되며, 이들 각각은 명확한 역할을 가지고 있습니다.

아래에 BSW의 전체적인 구조와 함께 각 구성 요소의 역할을 자세히 설명하겠습니다.

 

1. AUTOSAR 기반 소프트웨어 계층 구조

 

BSW는 위와 같이 계층화되어 있으며, MCAL, 통신 스택(Communication Stack), RTE는 각기 다른 계층에 위치합니다.

---

2. MCAL (Microcontroller Abstraction Layer)

• 위치: BSW의 최하위, 하드웨어 바로 위
• 역할: MCU 내부의 주변 장치(CAN 컨트롤러, ADC, GPIO, SPI, 타이머 등)에 대한 드라이버를 제공합니다.
• 기능:
  • 하드웨어 레지스터를 직접 읽고 쓰며, 상위 계층(ECU 추상화 계층)에 하드웨어 독립적인 API를 제공합니다.
  • 예: Can_Write()는 CAN 컨트롤러의 레지스터에 프레임을 씀, Adc_Read()는 ADC 결과 레지스터 값을 반환.
• 의의: MCU가 바뀌면 MCAL만 교체하면 상위 소프트웨어는 재사용 가능.

---

3. 통신 스택 (Communication Stack)

통신 스택은 BSW 내 여러 계층에 걸쳐 분산되어 있으며, 대표적으로 CAN, LIN, FlexRay, Ethernet 등 각 통신 프로토콜별로 스택이 존재합니다.
여기서는 CAN 통신 스택을 예로 들어 설명합니다.

• Com 모듈: 최종적으로 애플리케이션이 사용하는 신호(Signal) 단위로 데이터를 제공.
  예: Com_ReceiveSignal(vehicleSpeed) → 물리값(km/h)으로 변환된 결과 전달.
• 통신 스택 전체 역할:
  • CAN 프레임 수신 → ID 필터링 → 신호 추출 → 상위 애플리케이션에 전달
  • 애플리케이션에서 보낸 신호 → 프레임 조립 → 전송

---

4. RTE (Runtime Environment)

• 위치: BSW의 최상위, ASW와 BSW 사이
• 역할: ASW 내 소프트웨어 컴포넌트(SWC) 간 및 SWC와 BSW 간 통신을 중개하는 미들웨어입니다.
• 구체적 기능:
  • 통신 추상화: SWC가 서로를 직접 호출하지 않고, RTE가 제공하는 포트를 통해 데이터를 주고받습니다.
  • 스케줄링: SWC의 실행 주기(Runnable)를 관리하고, OS 타이머와 연동하여 주기적으로 호출합니다.
  • 하드웨어 독립성: SWC는 RTE 아래에 CAN, LIN 등이 무엇이 있는지 알 필요 없이, RTE가 제공하는 인터페이스로만 통신합니다.
• 예시:
  SWC에서 Rte_Read_BrakePressure(&pressure)를 호출하면, RTE가 실제로는 Com_ReceiveSignal()이나 Adc_Read() 등을 통해 데이터를 가져와서 전달합니다.

---

5. 정리: BSW에 포함되는 요소들

BSW는 단순히 MCAL + 통신 스택 + RTE만 있는 것이 아니라, 아래와 같은 다양한 모듈들로 구성됩니다.

 

RTE는 엄밀히 말하면 BSW의 상위에 있으면서 ASW와 BSW를 연결하는 별도 계층이지만, 실무에서는 “BSW에 포함된다”고 넓게 말하기도 합니다.
통신 스택은 BSW의 여러 계층(MCAL, ECU Abstraction, Services)에 걸쳐 구현됩니다.
MCAL은 BSW의 최하위 계층입니다.

---

6. 결론

• ASW는 차량의 제어 로직(브레이크, 엔진, ADAS 등)을 구현하는 애플리케이션 계층입니다.
• BSW는 ASW가 하드웨어에 독립적으로 동작하도록 하는 기반 소프트웨어이며, 그 안에 MCAL, 통신 스택, RTE, OS, 진단, 메모리 관리 등이 포함됩니다.
• MCAL은 하드웨어를 직접 제어하는 최하위 드라이버,
  통신 스택은 CAN/LIN/Ethernet 등 통신을 계층별로 처리,
  RTE는 ASW와 BSW를 연결해주는 미들웨어입니다.

이 구조 덕분에 애플리케이션 개발자는 하드웨어 변경에 영향받지 않고 로직에 집중할 수 있으며, 자동차 업계에서는 ISO 26262 기능안전 요구사항을 만족하면서 소프트웨어의 재사용성과 이식성을 높일 수 있습니다.