AUTOSAR SW-Component (SW-C) — AUTOSAR Classic Platform의 Application Layer 구성 단위. 소프트웨어 설계·패키징·배포의 기본 단위로, 외부와의 접점인 Port와 내부 실행 단위인 Runnable을 갖는다. SW-C 간 통신은 RTE가 중개하므로, 같은 ECU인지 다른 ECU인지에 무관하게 동일한 인터페이스로 연결된다. Component-Based Architecture의 대표 구현. 형식적인 설계 산출물은 Software Component Description에 담긴다.
Component-type vs Component-prototype
SW-C는 타입-인스턴스 분리 모델을 따른다.
- Component-type — 속성 정의 (Port 구성, 내부 Runnable 선언)
- Component-prototype — Component-type의 인스턴스 (메모리 할당 단위)
예: SeatHeatingControl (type, 8 Port 선언) → SHCFrontLeft / SHCFrontRight (두 prototype). 둘은 동일 속성이되 메모리상 독립. 하나의 type에서 여러 prototype을 만드는 것을 Multiple Instantiation이라 부른다.
Component-type 9종
기능·역할에 따라 다음 9종으로 분류된다.
| Component-type | 설명 |
|---|---|
| Application SW-C | 애플리케이션 로직. AUTOSAR 모든 통신 방법·서비스 사용 가능, ECU HW 독립 |
| Composition SW-C | 다른 SW-C들을 캡슐화하여 상위 수준 단위로 제공 (아래 섹션 참조) |
| Service SW-C | 표준화된 서비스를 표준 인터페이스로 제공, BSW 모듈과 통신 |
| Sensor-Actuator SW-C | 센서·액츄에이터 제어. Application SW-C와 IO Hardware Abstraction 사이 중개. ECU HW 의존으로 자유 재배치 어려움 |
| Parameter SW-C | 파라미터 값(고정 데이터·상수·변수·캘리브레이션) 접근 제공 |
| Service Proxy SW-C | 모드를 시스템 전체에 분배. 모든 ECU가 이 SW-C의 복사본 인스턴스를 소유 |
| ECU-Abstraction SW-C | ECU 특정 I/O 기능 접근. Client-Server P-Port 제공, Sensor-Actuator SW-C와 통신 |
| Complex Device Driver SW-C | AUTOSAR 표준이 지원하지 않는 HW 드라이버 구현 |
| NV Block SW-C | 비휘발성 데이터·데이터 블록 접근. NvM 모듈(BSW)과 통신 |
Composition
다른 Component를 포함하는 Component. Composition 자체도 Component-type이므로 더 큰 Composition 안에 prototype으로 다시 포함될 수 있다. 최종 계층은 Root Composition → Root Composition Prototype으로 실체화.
구성 요소:
- 내부 Component-prototype들
- 내부 prototype 간 연결용 Port·Connector
- 외부 경계에 노출되는 자체 Port
Assembly Connector vs Delegation Connector
| Connector | 연결 대상 | 방향 제약 |
|---|---|---|
| Assembly Connector | 같은 Composition 내 두 Prototype의 P-Port ↔ R-Port | 항상 P ↔ R |
| Delegation Connector | Composition 외부 Port ↔ 내부 Prototype의 동형 Port | P ↔ P, R ↔ R 만 가능 |
Assembly는 내부 통신선, Delegation은 외부 노출을 의미. Delegation이 P↔P·R↔R 규칙을 가지는 이유는 외부에서 본 방향성을 보존하기 위함.
구성 — Port와 Interface
SW-C는 외부와 Port를 통해 통신한다. Port는 두 방향으로 나뉜다.
- R-Port (Require Port) — 다른 SW-C로부터 필요한 데이터·서비스
- P-Port (Provide Port) — 다른 SW-C에 제공하는 데이터·서비스
두 SW-C 간 연결은 한쪽의 P-Port ↔ 다른 쪽의 R-Port로 성립한다. Port에 부착된 Interface가 전달 데이터 형식과 연산 시그니처를 정의한다.
┌─────────────┐ ┌─────────────┐
│ SW-C A │ │ SW-C B │
│ P-Port ───────── R-Port │
│ │ │ │
│ R-Port ───────── P-Port │
└─────────────┘ └─────────────┘Communication Models
SW-C 간 통신은 Port의 Interface 종류에 따라 두 모델로 나뉜다. 실행·통신 아키텍처 패턴의 일반론이 AUTOSAR 관점으로 구체화된 형태.
Client-Server Communication
- Client가 통신을 시작. 서비스 수행 요청을 파라미터와 함께 전달
- Server는 요청을 대기하다가 서비스 수행 후 응답을 반환
- 동기적이며 원격 함수 호출(RPC) 성격
- RTE API:
Rte_Call_<port>_<operation>
Sender-Receiver Communication
- 비동기 데이터 분배 모델
- Sender는 수신자의 응답을 기대하지 않음
- 정보 분배는 통신 인프라(RTE/BSW)의 책임
- 단일 송신 → 다중 수신(broadcast·multicast) 자연스러움
- RTE API:
Rte_Send_<port>_<data>/Rte_Receive_<port>_<data>
선택 기준: 결과가 필요한 요청은 Client-Server, 주기적 측정값·이벤트 전파는 Sender-Receiver.
Runnable
SW-C 내부의 실행 가능한 코드 단위. AUTOSAR는 SW-C = Set of Runnables로 정의한다.
주기 Runnable (Periodic)
각 Runnable은 Period를 선언해 주기적으로 실행된다.
- Period 예: 5 ms, 10 ms, 100 ms
- 같은 SW-C 내 Runnable이라도 서로 다른 주기를 가질 수 있음
- 이벤트 기반 Runnable (Data Receive, Operation Invoke 등)도 존재
Task로의 매핑
SW-C는 OS Task를 직접 모른다. Runnable들은 통합 단계에서 도구가 동일 Period끼리 묶어 Task에 매핑한다. 상세는 Runnable-to-Task Mapping.
Runnable Sequencing
한 Task 내 여러 Runnable의 호출 순서는 Runnable 간 데이터 의존성에 따라 결정된다. A의 출력이 B의 입력이면 A → B 순서. 이 의존성은 설계 도구가 ARXML로부터 분석한다.
설계 관점
- 재사용 단위 — 차량 프로젝트 간 SW-C 단위 재사용이 목표
- Deployment 단위 — VFB 매핑에서 “어느 ECU에 배치할지”의 granularity
- ECU-agnostic — Port를 통해서만 외부와 소통하므로 배치가 바뀌어도 내부 코드는 불변
- 예외: Sensor-Actuator SW-C — ECU HW 의존 (센서·액츄에이터는 특정 ECU의 전기 인터페이스에 연결됨). 성능·효율상 자유 재배치 불가. HW 변화는 IO Hardware Abstraction이 흡수