| SWC Type | Description | Example |
|---|---|---|
| Atomic SWC | Leaf component — contains runnables and ports | WheelSpeedCalculator |
| Composition SWC | Container of Atomic SWCs with internal connectors | EngineManagementSystem |
| Sensor/Actuator SWC | Has I/O hardware access ports; interfaces IoHwAb | ThrottlePositionSensor |
| ECU-Abstraction SWC | Abstracts a hardware device | SteeringAngleSensor abstraction |
| Service SWC | Wraps a BSW service; owned by BSW supplier | NvMService, DiagService |
SWC Types
Port Types: R-Port & P-Port
XMLSwcInterface.arxml
<P-PORT-PROTOTYPE>
<SHORT-NAME>SpeedOut</SHORT-NAME>
<PROVIDED-INTERFACE-TREF>/Interfaces/SpeedInterface</PROVIDED-INTERFACE-TREF>
</P-PORT-PROTOTYPE>
<R-PORT-PROTOTYPE>
<SHORT-NAME>SpeedIn</SHORT-NAME>
<REQUIRED-INTERFACE-TREF>/Interfaces/SpeedInterface</REQUIRED-INTERFACE-TREF>
</R-PORT-PROTOTYPE>Interface Variants
| Interface Type | RTE API | Use Case |
|---|---|---|
| SenderReceiver | Rte_Write / Rte_Read | Signals: speed, temperature, flags |
| ClientServer | Rte_Call / Rte_Result | Services: NvM write request, diagnostic callback |
| Mode | Rte_Switch / Rte_Mode | EcuM mode, ComM mode to SWCs |
| Parameter | Rte_Prm_<n>() | Read-only calibration parameters |
| NvData | Rte_Pim_<n>() | Persistent inter-runnable variable via NvM |
Internal Behavior & Runnables
| Trigger Condition | ARXML Event Type | When Runnable Fires |
|---|---|---|
| Cyclic | TimingEvent | Every N ms; period set in OsAlarm |
| Data received | DataReceivedEvent | When new value arrives on an R-Port |
| Mode change | SwcModeSwitchEvent | On transition of a linked Mode interface |
| Init | InitEvent | Once at startup, before cyclic runnables |
CWheelSpeed_Runnable.c
FUNC(void, WheelSpeed_CODE) WheelSpeed_Calculate(void)
{
uint16 rawPulse;
float32 speedKph;
(void)Rte_Read_SpeedIn_PulseCount(&rawPulse);
speedKph = (float32)rawPulse * PULSE_TO_KPH_FACTOR;
(void)Rte_Write_SpeedOut_VehicleSpeed(&speedKph);
}Summary
SWC types define structural roles; port types and interface variants define communication contracts. The RTE enforces these contracts by generating type-safe Rte_Read/Write/Call wrappers — any type mismatch or missing connection causes RTE generation to fail at design time.
🔬 Port Interface Types — When to Use Each
AUTOSAR Classic defines six port interface types, and choosing the wrong one is the most common modelling mistake among engineers new to the standard:
- SenderReceiver (SR): Asynchronous data flow. One SWC writes, one or many SWCs read. The data persists in a buffer — no handshake needed. Best for sensor values, setpoints, status signals.
- ClientServer (CS): Synchronous or asynchronous function call. The client sends a request and optionally waits for a response. Best for service operations: NvM read/write, CRC calculations, calibration parameter access.
- Mode: Mode declarations (ModeDeclarationGroups). Used to communicate the current operating mode (e.g., ECU_RUN, ECU_PREP_SHUTDOWN) from BswM or EcuM to SWCs. The RTE generates ModeNotification runnables that activate on mode switches.
- Parameter: Read-only access to calibration parameters stored in ROM. AUTOSAR's integration point for AUTOSAR-to-ASAM mapping. If your target is a calibration engineer, this is the interface to use.
- NvData: Non-volatile data interface. The SWC declares which data blocks it owns, and the RTE generates typed NvM read/write calls. Direct access to NvM_WriteBlock is an architectural violation.
- Trigger: Edge event notification (Adaptive-style events in Classic). Rarely used in CP — most projects use SR with DataReceivedEvent instead.
🏭 Industry Interface Design Patterns
- Sensor fusion ECU (e.g., ADAS domain controller): Camera, radar, and ultrasonic SWCs each expose SR P-Ports with the same DataElement interface type. The fusion algorithm SWC has three R-Ports — one per sensor. This decouples sensor HW from algorithm SWC with no code change required when swapping sensor hardware.
- Body Control Module: Door lock control uses CS interface. The BMS (Body Management Software) is the server; window, mirror, and light SWCs are clients. Asynchronous fire-and-forget calls avoid blocking the 10 ms OSEK task.
- Calibration SWC: Throttle pedal curve is modelled as a Parameter interface with 16 MAP values. The OEM calibration engineer adjusts these in the A2L file; the SWC reads them at startup via Rte_Prm_ThrottleCurve_Map(). No recompile needed — just re-flash the calibration data section.
⚠️ Common Port & Interface Mistakes
- Wrong interface type for the use case: Using SR where CS is correct (e.g., for NvM writes). SR does not guarantee the receiver has processed the data — you won't know if the write succeeded.
- Multiple data elements on one port: Grouping unrelated signals into a single SR interface couples SWCs unnecessarily. If one signal changes type, the whole interface must be versioned — affecting all connected SWCs.
- Forgetting InitValues on SR ports: Without an InitValue in the ComSpec, Rte_Read returns RTE_E_NEVER_RECEIVED on the first activation until the sender writes once. Safety-critical runnables must handle this startup case.
- Mismatched DataElement units in connected ports: The ARXML schema does not enforce physical units — only types. A sender writing km/h and a receiver expecting m/s will pass type checking but produce wrong calculations silently.
📊 Industry Note
AUTOSAR interface design is a cross-team contract. In a typical OEM project, interface ARXML files are change-controlled separately from implementation code — a change request process exists just for adding a single signal to an SR port. Engineers who understand this avoid costly rework cycles.
🧠 Knowledge Check — Click each question to reveal the answer
❓ A SWC needs to read an odometer value from NvM at startup. Which interface type is correct and why?
✅ NvData interface — it gives the SWC typed access to NvM blocks through the RTE without bypassing the NvM module. Using SR would be incorrect because it implies real-time data flow, not persistent storage. Direct NvM_ReadBlock calls are an architectural violation in AUTOSAR CP.
❓ What is the difference between a P-Port and R-Port in terms of interface direction for SR vs CS?
✅ For SR: the P-Port is the sender (provider), the R-Port is the receiver (requirer). For CS: the P-Port is the server (provides the operation), the R-Port is the client (requires/calls the operation). This is sometimes counterintuitive for CS — the 'server' provides the port, not the caller.
❓ Why should unrelated signals not be grouped into the same SR port interface?
✅ Because the interface becomes a coupling point. Any schema change (type, name, new element) requires re-versioning the entire interface and regenerating ARXML for all connected SWCs. Fine-grained interfaces allow independent evolution of SWCs — a key goal of AUTOSAR's component model.