Inter-Core Communication (IOC) - AUTOSAR Expert

IOC Role & RTE Integration

IOC (Inter-OS-Application Communicator) is the AUTOSAR OS-defined mechanism for exchanging data between RTE ports whose sender runnable and receiver runnable are mapped to different OsCores. The RTE generator replaces normal Rte_IWrite/Rte_IRead buffer access with generated Ioc_Send() / Ioc_Receive() wrappers when it detects a cross-core port connection.

IOC Data Path

  Core 0 — Task_SafetyCtrl_10ms             Core 1 — Task_ComStack_1ms
  ┌──────────────────────────────┐          ┌──────────────────────────────┐
  │ SpeedSafetySWC               │          │ CanRxSWC                     │
  │ Rte_IRead_SpeedIn_Value()    │          │ Rte_IWrite_SpeedOut_Value()  │
  └───────────┬──────────────────┘          └──────────────┬───────────────┘
              │ generated: Ioc_Receive(IOC_CH_SPEED, &val) │ generated: Ioc_Send(IOC_CH_SPEED, val)
              │                                            │
              └──────────────── IOC Channel ───────────────┘
                     OsSpinlock-protected shared memory ring buffer
                     (located in shared RAM: .ioc_data section)

💡 Transparent to SWC

SWC code remains unchanged — the same Rte_IWrite and Rte_IRead calls are used regardless of whether the connected port is on the same core or a different core. The RTE generator determines IOC vs. local buffer based on OsTaskCoreRef assignments in the ARXML. This means moving a SWC between cores requires only an ARXML config change and RTE regeneration, not any SWC code changes.

IOC Modes: Queue vs Last-Is-Best

Mode	OsIocQueueLength	Overrun Behaviour	Use Case
N:1 Queue (FIFO)	> 1 (e.g., 4)	Oldest entry dropped; Ioc_Send returns IOC_E_LIMIT	Bursty sensor data where all samples matter (e.g., CAN Rx burst)
1:1 Last-Is-Best	1 (or OsIocQueueLength absent)	New value overwrites existing; never blocks	Cyclic status signals where only latest value is relevant (speed, RPM)

CIOC_Overrun_Handling.c

/* Sender side: check for queue full condition */
Std_ReturnType ret = Ioc_Send_SpeedChannel(&speedValue);
if (ret == IOC_E_LIMIT) {
    /* Queue full — oldest entry dropped by OS, new value enqueued */
    /* Log via DEM if overrun rate is safety-relevant */
    overrunCount++;
    if (overrunCount > IOC_MAX_OVERRUN_THRESHOLD) {
        Dem_ReportErrorStatus(DEM_EVENT_IOC_OVERRUN, DEM_EVENT_STATUS_FAILED);
    }
}

/* Receiver side: drain queue each cycle */
Std_ReturnType ret;
SpeedType val;
do {
    ret = Ioc_Receive_SpeedChannel(&val);
    if (ret == IOC_E_OK) { ProcessSpeed(val); }
} while (ret == IOC_E_OK); /* read until empty */

OsIocCommunication Configuration

XMLOs_IOC_Config.arxml


  IOC_SpeedChannel
  
  
    
      /Os/Apps/OsApp_QM_Core1
    
  
  
  
    
      /Os/Apps/OsApp_Safety_Core0
    
  
  
  4
  
  
    
      /DataTypes/uint16

IOC Internals: Spinlock-Protected Ring Buffer

The AUTOSAR OS implementation of IOC uses an internal OsSpinlock to protect the shared memory ring buffer during Ioc_Send() and Ioc_Receive(). Application code never calls GetSpinlock() directly — this is entirely encapsulated in the OS IOC implementation.

IOC Property	Detail
Shared memory location	`.ioc_data` linker section in shared SRAM accessible by all cores
Spinlock acquisition	Internal to OS — Ioc_Send acquires spinlock, writes to ring buffer, releases spinlock atomically
Worst-case latency	Spinlock hold time ≈ ring buffer write time (~20–50 ns at 400 MHz); no busy-wait loop in application code
Data consistency	Complete: IOC transfers entire data element atomically — no partial read of multi-byte values
Zero-copy	Not supported by AUTOSAR OS IOC — data is always copied into the ring buffer

⚠️ IOC vs Spinlock vs Shared Memory

Prefer IOC over direct spinlock-protected shared memory for inter-core data exchange wherever possible: IOC is AUTOSAR-standardised (portable across OS suppliers), its spinlock usage is bounded and analysable by the OS vendor, and it integrates cleanly with the RTE. Raw spinlock-protected shared memory should only be used for BSW-internal data not passing through the RTE (e.g., a shared NvM write-request flag accessed by BSW modules on both cores).

Summary

IOC is the correct and only AUTOSAR-standardised mechanism for transferring RTE port data across OsCore boundaries. Queue mode vs. last-is-best selection depends on whether all samples or only the latest value is relevant. The OsIocQueueLength, sender/receiver OsApplication references, and data type must all be consistent with the RTE port mapping — a mismatch causes silent data loss with no compile-time error.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.