AUTOSAR Classic Interview Questions

Application Layer (SWC), RTE, BSW (Services Layer, ECU Abstraction Layer, MCAL), and the Microcontroller. The Application Layer contains Software Components that implement vehicle functions. The RTE serves as middleware between SWCs and BSW. The BSW is split into Services (OS, COM, NvM, DCM), ECU Abstraction, and MCAL which directly interfaces with hardware.

Sender-Receiver (S/R) is data-centric asynchronous communication where a sender provides data and receivers consume it - typical for signal exchange like sensor values. Client-Server (C/S) is function-call-based communication where a client invokes a server operation and optionally waits for a response - used for services like diagnostic requests or NvM read/write operations.

The Runtime Environment (RTE) provides the communication infrastructure between Software Components and between SWCs and BSW modules. It abstracts the underlying communication mechanism (inter-ECU via COM or intra-ECU via direct function call), making SWCs independent of the ECU topology. The RTE is auto-generated from the system configuration and handles data consistency, blocking/non-blocking semantics, and mode management notifications.

Application SWC (implements application logic), Sensor/Actuator SWC (interfaces with hardware via ECU Abstraction), Service SWC (provides BSW services to application layer), ECU Abstraction SWC (wraps ECU-specific I/O), Complex Device Driver SWC (bypasses AUTOSAR layering for special hardware), Composition SWC (groups multiple SWCs), and Parameter SWC (provides calibration data).

A Runnable Entity is the smallest executable code unit within an SWC - essentially a C function. It can be triggered by: TimingEvent (periodic execution), DataReceivedEvent (when new data arrives on an S/R port), OperationInvokedEvent (when a C/S operation is called), ModeSwitchEvent (on mode transition), InitEvent (at ECU startup), or DataSendCompletedEvent. Runnables are mapped to OS Tasks during configuration.

NvM (NVRAM Manager) is the top-level module providing block-based non-volatile storage with redundancy and CRC protection. Below NvM, the MemIf layer routes requests to either Fee (Flash EEPROM Emulation) for internal flash or Ea (EEPROM Abstraction) for external EEPROM. Fee sits on top of Fls (Flash driver), Ea sits on top of Eep (EEPROM driver). NvM supports Native, Redundant, and Dataset block types.

Implicit communication means the RTE copies data at runnable boundaries - the runnable always works with a consistent snapshot, and data is written back after completion. Explicit communication means the runnable explicitly calls Rte_Read/Rte_Write APIs at specific points in its code. Implicit is safer (guaranteed consistency) but uses more RAM for shadow copies. Explicit gives more control over timing.

COM module manages the packing of application signals into I-PDUs (Protocol Data Units) for transmission and unpacking received I-PDUs into individual signals. It handles byte ordering (big-endian/little-endian), signal groups (for consistent multi-signal updates), update bits, transfer property (triggered/pending), deadline monitoring, and signal gateway routing between different buses.

The PDU Router (PduR) is the central routing component that forwards I-PDUs between different BSW modules: COM ↔ transport protocols (CanTp, FrTp), DCM ↔ transport protocols, and between different bus interfaces for gateway ECUs. It supports 1:1, 1:N (fan-out), and N:1 routing, with configurable buffer management. PduR decouples upper layers from lower communication layers.

AUTOSAR OS (based on OSEK) supports Basic Tasks (run-to-completion, no waiting) and Extended Tasks (can use WaitEvent to block). Scheduling can be Full Preemptive (any higher-priority task can preempt), Non-Preemptive (task runs until it terminates or explicitly yields), or Mixed. Tasks have static priorities, and scheduling follows fixed-priority preemptive scheduling. The OS also provides Alarms for periodic activation and Schedule Tables for synchronized task activation.

Port Interfaces define the type of data or operations exchanged through ports. Types include: Sender-Receiver Interface (defines data elements for signal exchange), Client-Server Interface (defines operations with parameters), Mode-Switch Interface (defines mode groups), Trigger Interface (defines trigger events), Parameter Interface (provides calibration constants), and NV Data Interface (for non-volatile data access through NvM service ports).

Inter-ECU communication flows through the COM stack: SWC → RTE → COM (signal packing) → PduR (routing) → Transport Protocol (CanTp for segmented messages) → Interface module (CanIf) → Driver (Can) → Physical bus. On the receiving ECU, the reverse path unpacks the data. The RTE abstracts this so SWCs don't know if communication is intra-ECU or inter-ECU.

BswM is the central mode management module that controls ECU states and coordinates BSW module behavior. It evaluates mode requests from SWCs and BSW modules through configurable rules (logical expressions) and executes action lists (e.g., enable/disable COM groups, switch communication modes, trigger NvM writes). BswM is crucial for managing startup/shutdown sequences, communication control, and partial networking.

EcuM manages the ECU lifecycle: STARTUP (hardware init → BSW init → SchM start), RUN (normal operation - stays here while RUN requests exist), POST_RUN (allows final NvM writes before shutdown), SHUTDOWN (deinitialize BSW → hardware → off), SLEEP (low-power mode with wakeup sources), and OFF. EcuM Flex allows more flexible state machine customization compared to the fixed EcuM states.

EcuM Fixed provides a predefined state machine (STARTUP→RUN→SHUTDOWN/SLEEP) with fixed behavior. EcuM Flex provides only basic startup/shutdown sequencing and delegates the main state management to BswM, giving much more flexibility to configure complex mode management scenarios like partial networking, multi-core coordination, and custom sleep modes. EcuM Flex is the preferred approach in modern AUTOSAR.

DCM (Diagnostic Communication Manager) handles UDS diagnostic requests: it manages diagnostic sessions (Default, Extended, Programming), security access levels, and routes service requests to appropriate handlers. DEM (Diagnostic Event Manager) manages DTCs - storing fault status, aging, priority, and freeze frames. DCM reads DTC information from DEM. Both modules interface with NvM for persistent storage.

SchM integrates BSW modules with the AUTOSAR OS by providing the scheduling context for BSW main functions. Each BSW module has MainFunction_xxx() calls that need periodic execution - SchM maps these to OS tasks/alarms. SchM also provides exclusive areas (critical sections) for BSW data protection. It's the glue between the OS and BSW module periodic processing.

The SWCD is an ARXML file that formally describes an SWC's interface and behavior: its ports (Provide/Require), port interfaces, internal behavior (runnables, events triggering them), inter-runnable variables, exclusive areas, per-instance memory, calibration parameters, and data type mappings. The SWCD enables tool-based integration without access to source code - the contract between SWC developer and integrator.

ARXML (AUTOSAR XML) is the standardized XML-based exchange format for all AUTOSAR configuration data. It describes system topology, SWC descriptions, ECU configurations, BSW parameters, data types, and communication matrices. ARXML enables tool interoperability - different vendors' tools can exchange configurations. It follows the AUTOSAR meta-model schema and is the single source of truth for code generation.

CanIf provides a standardized interface between upper layers (PduR, CanSM, CanTp) and the CAN Driver. It handles: PDU-to-HW-object mapping, transmit buffering, receive indication routing, CAN controller mode management (STARTED/STOPPED/SLEEP), transceiver control, DLC checking, and multiple CAN controller management. CanIf decouples the upper communication stack from hardware specifics.

Basic CAN uses software filtering - a hardware mailbox receives multiple CAN IDs and the driver filters them in software. Full CAN uses hardware filtering - each message ID has a dedicated hardware mailbox with exact-match acceptance filtering. Full CAN is faster (no software overhead) but limited by hardware mailbox count. Most projects use a mix: Full CAN for critical messages, Basic CAN for the rest.

CAN FD support extends through the entire COM stack: Can Driver supports CAN FD frames (up to 64 bytes, higher bitrate in data phase), CanIf handles the FD flag and DLC mapping (discrete values: 12/16/20/24/32/48/64 bytes), PduR routes larger PDUs, and COM packs signals into larger I-PDUs. The configuration adds CAN FD controller settings (data-phase baudrate, transceiver delay compensation). Existing CanTp segmentation still works for messages exceeding 64 bytes.

CanSM manages the state of CAN networks and controllers. It handles: network mode requests from ComM (FULL_COM, SILENT_COM, NO_COM), controller mode transitions (START/STOP/SLEEP), bus-off recovery (with configurable recovery strategies - immediate restart or delayed), and transceiver mode control. CanSM ensures coordinated mode transitions across all CAN controllers on a network.

ComM manages communication channel modes based on user requests. Users (SWCs, DCM) request FULL_COM or NO_COM. ComM aggregates requests - if any user needs FULL_COM, the channel stays active. It coordinates with CanSM/LinSM/FrSM for network mode changes, NmIf for network management, and BswM for mode notifications. ComM also handles communication inhibition and partial networking (PNC - Partial Network Cluster).

PNC allows selective wake-up of ECUs based on which vehicle function is needed, reducing power consumption. Each ECU is assigned to Partial Network Clusters. When a PNC-relevant NM message is received, only ECUs belonging to that PNC wake up. This is implemented through ComM PNC configuration, NM message user data carrying PNC bit vectors, and CanTrcv selective wakeup capability (CAN FD transceivers with partial networking support).

AUTOSAR NM keeps bus communication alive by circulating NM messages among participating ECUs. When an ECU needs communication, it sends NM messages; when all ECUs release, NM messages stop and the bus enters Bus Sleep. Key states: Bus-Sleep → Network (Repeat Message → Normal Operation → Ready Sleep) → Bus-Sleep. NM coordinates synchronized shutdown through NM-timeout monitoring and supports passive mode for listen-only ECUs.

AUTOSAR NM is decentralized - each node independently manages its NM state based on received NM messages and timeouts. OSEK NM (Direct NM) uses a token-ring approach where a logical ring passes through all nodes. AUTOSAR NM is simpler, more robust (no ring management), and better suited for modern vehicles with many ECUs. OSEK NM is legacy and rarely used in new projects.

AUTOSAR supports multi-core through: OS partitions mapped to specific cores, inter-core RTE communication (with spinlock/data consistency), IOC (Inter-OS-Application Communication) for cross-core BSW communication, core-local SchM instances, and synchronized startup/shutdown via EcuM and master/satellite core concepts. The configuration tool assigns SWCs and BSW modules to cores, and the RTE generator handles cross-core communication automatically.

Exclusive Areas protect shared data from concurrent access. Types include: interrupt-disabling (fastest, shortest duration - disables all/category-2 interrupts), OS Resources (priority ceiling protocol for task-level protection), and Spinlocks (for multi-core protection). SWCs declare exclusive areas in their SWCD, and the RTE generates the appropriate protection mechanism. BSW modules use SchM exclusive areas with similar semantics.

DEM manages diagnostic events (DTCs): it receives event reports from SWCs/BSW (Dem_SetEventStatus), applies debouncing (counter-based or time-based), manages the UDS DTC status byte (testFailed, confirmedDTC, etc.), stores freeze frames/extended data records, handles DTC aging (automatic clearing after N passing cycles), DTC priority and displacement, and persists data via NvM. DEM supports event combination and dependent DTCs.

DTC debouncing prevents transient faults from being reported as confirmed failures. AUTOSAR supports: Counter-based debouncing (increment on FAILED, decrement on PASSED, report when threshold reached - most common), Time-based debouncing (fault must persist for a configured time), and Monitor-internal debouncing (the SWC handles debouncing logic internally). Counter-based is used in 90% of projects.

DCM manages sessions (DefaultSession, ProgrammingSession, ExtendedDiagnosticSession, custom OEM sessions) with configurable service availability per session. Security access uses seed-key authentication - DCM generates a random seed, tester calculates key using OEM algorithm, DCM verifies. Multiple security levels can exist (e.g., Level 1 for basic access, Level 2 for programming). Session/security timeouts auto-revert to default session.

Alarms trigger actions (activate task, set event, call callback) when an OS counter reaches a configured value - used for periodic task activation. Schedule Tables provide time-synchronized activation of multiple tasks/events at specific offsets within a repeating period - essential for synchronized communication (e.g., FlexRay). Schedule Tables can synchronize to external time sources. Alarms are simpler; Schedule Tables provide deterministic multi-task coordination.

AUTOSAR uses #include MemMap.h with open/close macros (e.g., #define COM_START_SEC_VAR_INIT_8BIT) to control linker section placement of variables, code, and constants. This enables: placing safety-critical code in protected memory regions, calibration data in specific flash sectors, frequently accessed variables in fast RAM, and configuration data in designated NV memory areas. Each BSW module has its own MemMap.h file.

Compiler Abstraction macros (Compiler.h, Compiler_Cfg.h) provide portable keywords across different compilers: FUNC() for function declarations, VAR() for variables, CONST() for constants, P2VAR/P2CONST for pointers, and FUNC_P2CONST for function pointers. Memory class qualifiers (__near, __far, __huge) are also abstracted. This allows the same source code to compile on different microcontroller/compiler combinations.

MIL (Model-in-the-Loop): Test Simulink models before code generation. SIL (Software-in-the-Loop): Test generated C code on PC with virtual ECU (VEOS, SILVER). PIL (Processor-in-the-Loop): Test compiled code on target hardware with debugger. HIL (Hardware-in-the-Loop): Test real ECU on HIL bench (dSPACE SCALEXIO, ETAS LABCAR) with simulated sensors/actuators. Each level adds more realism and catches different defect types.

EB tresos (Elektrobit) is an AUTOSAR BSW configuration tool - an alternative to Vector DaVinci. It provides: BSW module configuration with GUI editors, parameter validation, code generation for BSW and RTE, ARXML import/export, multi-variant configuration management, and a plugin architecture. tresos Studio is the IDE, and tresos AutoCore provides the BSW module implementations (similar to Vector's MICROSAR stack).

Both configure AUTOSAR BSW and generate code. DaVinci Developer handles SWC/system design, DaVinci Configurator handles BSW configuration - they're separate tools. EB tresos Studio combines both in one IDE. DaVinci is tightly integrated with MICROSAR BSW stack; tresos with AutoCore BSW. Key difference: DaVinci's validation is generally stronger, but tresos has better plugin extensibility. OEM preference often determines the choice.

AUTOSAR defines standard service port interfaces allowing SWCs to access BSW services through the RTE. Examples: NvMService for reading/writing NvM blocks, DiagnosticMonitor for reporting DEM events, DiagnosticInfo for reading DTC information, EcuM_ShutdownTarget for requesting ECU shutdown. These are typed port interfaces defined in the standard - SWCs use them instead of directly calling BSW APIs.

The Ethernet COM stack adds: TcpIp (TCP/IP stack with DHCP, ARP, ICMP), SoAd (Socket Adaptor - maps PDUs to TCP/UDP sockets), DoIP (Diagnostics over IP for UDS-over-Ethernet), SD (Service Discovery for SOME/IP), SOME/IP transformer for service-oriented communication, and EthIf/EthDrv for Ethernet hardware. This enables diagnostic communication via DoIP and service-oriented architecture via SOME/IP.

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the standard middleware for Ethernet-based service communication. It supports: Method calls (request/response), Events (publish/subscribe with SD), Field getters/setters/notifiers, and serialization of complex data types. In AUTOSAR Classic, SOME/IP is integrated through the transformer framework and SD module. SWCs use standard S/R or C/S ports while transformers handle SOME/IP serialization.

AUTOSAR supports functional safety through: Memory partitioning (OS Applications with protection via MPU), timing protection (execution budget monitoring, inter-arrival time protection), E2E protection library (CRC, sequence counter, alive counter for signal integrity), BSW modules certified to ASIL D (e.g., RTA-OS, MICROSAR Safe), safe communication (COM-based E2E wrapper), and WdgM (Watchdog Manager) for program flow monitoring.

WdgM monitors program flow to detect software execution failures. It defines Supervised Entities (SE) with Checkpoints that must be reached within configured timeframes. Monitoring types: Alive Supervision (periodic checkpoint reached within tolerance), Deadline Supervision (time between two checkpoints within range), and Logical Supervision (checkpoints reached in correct sequence). WdgM triggers the internal/external watchdog on failure.

E2E protection detects communication faults (corruption, repetition, loss, delay) on safety-relevant signals. The sender adds a CRC and sequence counter to the signal group; the receiver verifies them. AUTOSAR defines profiles (Profile 1, 2, 4, 5, etc.) with different CRC polynomials and counter sizes. The E2E library integrates as a transformer or via COM-based E2E wrapper. Required for ASIL-rated inter-ECU signals.

AUTOSAR transitioned from version numbering (4.0, 4.2, 4.4) to release naming (R19-11, R20-11, R22-11). Key additions in recent releases: Adaptive Platform interfaces for Classic-Adaptive interaction, enhanced Ethernet support (TSN, SOME/IP-TP), security modules (SecOC, Crypto Stack, IdsM), vehicle diagnostics over Ethernet improvements, and multi-core extensions. The metamodel remains backward compatible.

SecOC adds authentication to PDUs to prevent message spoofing. The sender generates a MAC (Message Authentication Code) using a shared key and appends a truncated authenticator + freshness value to the PDU. The receiver verifies the MAC before passing the PDU to upper layers. SecOC integrates between PduR and the interface modules. Freshness management (counter or timestamp-based) prevents replay attacks. Keys are managed by the Crypto Stack (Csm/CryIf/Crypto).

Csm (Crypto Service Manager) provides the API for cryptographic operations (encrypt, decrypt, MAC, hash, signature, random). CryIf (Crypto Interface) routes requests to appropriate Crypto Driver instances. Crypto Drivers implement the actual algorithms - either in software or via HSM (Hardware Security Module). The stack supports: AES, RSA, ECC, SHA, CMAC, and secure key management. Essential for SecOC, secure boot, and certificate handling.

AUTOSAR defines three configuration stages: Pre-Compile (compile-time constants - #defines), Link-Time (const variables - resolved at linking), and Post-Build (loadable/selectable configuration - different parameter sets in flash). Post-Build Loadable allows updating configuration without recompiling code. Post-Build Selectable chooses between pre-built variants at runtime. Most BSW parameters support all three variants for maximum flexibility.

Service Interfaces are used in Adaptive AUTOSAR for service-oriented communication (ara::com). In Classic AUTOSAR, the concept is approximated through Standardized Interfaces (e.g., NvM service ports). The key difference: SWC ports in Classic are statically configured at compile time, while service interfaces in Adaptive are dynamically discovered at runtime via Service Discovery. Classic uses RTE-generated direct calls; Adaptive uses middleware proxy/skeleton pattern.

Calibration parameters are defined in SWCs as ParameterAccess points or through Parameter SWCs. They are mapped to specific memory sections (calibration flash area) via MemMap. In the running ECU, calibration tools (INCA, CANape) access parameters via XCP protocol using A2L files that describe parameter addresses and types. AUTOSAR supports reference calibration (single page) and working page switching for online calibration.

XCP (Universal Measurement and Calibration Protocol) enables external tools to read/write ECU internal variables for measurement and calibration. AUTOSAR includes an XCP module in the BSW that provides XCP-on-CAN, XCP-on-Ethernet, and XCP-on-FlexRay transport. XCP supports DAQ (data acquisition - cyclic measurement), STIM (stimulation - writing values), and memory page switching. The A2L file maps variable names to addresses.

The LIN stack includes: LinDrv (LIN hardware driver), LinIf (LIN Interface - manages schedule table execution, master/slave switching, sleep/wakeup), LinSM (LIN State Manager - coordinates with ComM), LinTp (LIN Transport Protocol - for diagnostic communication over LIN), and the LIN Transceiver driver. For LIN master nodes, LinIf executes configurable schedule tables that define the communication sequence. Slave response is handled by the slave ECU's LinDrv.

FlexRay stack: FrDrv (FlexRay driver - controls the CC), FrIf (FlexRay Interface - manages communication cycle, slot assignments, job list execution), FrSM (FlexRay State Manager - startup synchronization, wakeup), FrTp (FlexRay Transport Protocol - segmented message transfer), and FrTrcvDrv (transceiver driver). FlexRay provides deterministic time-triggered communication with dual-channel redundancy, making it suitable for chassis and safety-critical applications.

Flashing involves: Bootloader (separate from application - manages flash programming), DCM in Programming Session (accepts UDS services 0x34 RequestDownload, 0x36 TransferData, 0x37 RequestTransferExit), Fls driver for flash erase/write operations, and CRC verification. The tester requests session change to Programming, performs security access, downloads new software, verifies CRC, and resets ECU. The bootloader validates the application before jumping to it.

Primary bootloader (PBL) resides in protected flash - it's never updated and provides basic communication (CAN driver, UDS minimal) and the ability to flash the secondary bootloader. Secondary bootloader (SBL) provides full flash capability with optimized drivers, supports all communication protocols, and handles the actual application software flashing. This two-stage approach ensures the ECU is always recoverable even if the SBL is corrupted.

OS Applications group OS objects (Tasks, ISRs, Alarms, Schedule Tables, Counters) into trust domains. Trusted Applications have full hardware access; Non-Trusted Applications run with MPU restrictions. Applications can communicate via IOC (Inter-OS-Application Communication). This enables: memory protection between SWCs of different ASIL levels, isolation of third-party software, and multi-core partitioning. Cross-application access requires explicit permission configuration.

CDDs bypass the standard AUTOSAR layering to access hardware directly when the standard BSW modules don't support the specific hardware or when timing requirements are too strict. CDDs have direct access to MCAL or even hardware registers, but they lose portability. Common use cases: custom sensor interfaces, specialized actuator control, high-speed communication protocols not covered by AUTOSAR, and legacy driver integration.

A gateway ECU routes messages between different buses (e.g., CAN-to-CAN, CAN-to-Ethernet). In AUTOSAR, PduR handles PDU-level routing between interface modules. For signal-based gateway, COM extracts signals from source I-PDUs and packs them into destination I-PDUs with optional transformation. For PDU-based gateway, PduR forwards complete PDUs between buses. Gateway tables in PduR define the routing paths and can include buffering.

AUTOSAR includes J1939 modules for commercial vehicle communication: J1939Tp (Transport Protocol - BAM and CMDT transfer), J1939Nm (Network Management - address claiming), J1939Rm (Request Manager - handles PGN requests), and J1939Dcm (Diagnostic Communication - DM1/DM2/DM5 messages). These modules integrate with the standard COM stack and allow mixed J1939/UDS diagnostic implementations common in truck ECUs.

AUTOSAR Transformers convert data between internal SWC representation and on-wire format. Types include: SOME/IP Transformer (serialization for Ethernet), COM-Based Transformer (for COM signal transformation), E2E Transformer (adds safety protection), and Safety Transformer. Transformers are configured in the transformer chain - multiple transformers can be applied sequentially to a signal (e.g., E2E + SOME/IP). They're invoked by the RTE during communication.

Classic: static configuration, bare-metal/RTOS (OSEK), C language, fixed-priority scheduling, compile-time binding - designed for hard real-time control ECUs. Adaptive: dynamic configuration, POSIX OS (Linux/QNX), C++14/17, service-oriented (ara::com with SOME/IP), runtime service discovery - designed for high-performance computing ECUs (ADAS, infotainment). Many modern vehicles use both, with Classic for domain controllers and Adaptive for central computers.

Variant coding allows configuring ECU behavior without reflashing through Post-Build parameters. In AUTOSAR: define variant coding parameters in DCM (writable DIDs), store values in NvM blocks, reference these values in application SWCs for behavior selection. BswM rules can also depend on variant coding values. Alternatively, Post-Build Selectable configuration allows choosing between pre-built parameter sets at production or in the field.

System Architect: defines ECU topology, SWC composition, network design (PREEvision). SWC Developer: implements application SWCs following the contract (SWCD). BSW Integrator: configures BSW modules (DaVinci/tresos), generates RTE, resolves integration issues. Calibration Engineer: tunes parameters using INCA/CANape. Test Engineer: validates on HIL/SIL. Tool Chain Manager: maintains build system and tooling. Safety Manager: ensures ISO 26262 compliance across all roles.

AUTOSAR StbM (Synchronized Time-Base Manager) provides global time synchronization across ECUs. It supports: CAN-based time sync (using dedicated time sync messages following AUTOSAR Time Sync over CAN protocol), Ethernet-based sync (gPTP/IEEE 802.1AS), and FlexRay global time. StbM provides APIs for reading synchronized time and supports multiple time domains for different synchronization sources.

Det is a development-time error reporting module. BSW modules call Det_ReportError() when they detect configuration errors, invalid API parameters, or unexpected internal states. Det can be configured to: log errors, halt execution (for debugging), or call user-defined callback functions. Det is typically disabled in production builds for performance. It's the primary tool for catching integration errors during development.

AUTOSAR OS classifies interrupts as Category 1 (not managed by OS - fastest, can't use OS services) or Category 2 (managed by OS - can activate tasks, set events, but have overhead). ISR priority is configured independently of task priority. The OS provides ISR nesting support. In AUTOSAR, most hardware interrupts (CAN receive, timer) are Cat-2 ISRs that signal BSW processing. MCAL drivers contain the actual ISR implementations.

IoHwAb provides a standardized interface for sensor/actuator access, abstracting the physical hardware. SWCs access I/O through ECU Abstraction port interfaces, which IoHwAb implements by calling MCAL drivers (ADC, DIO, PWM, ICU, etc.). This separation means SWCs don't depend on specific hardware - the same SWC can run on different ECUs by reconfiguring IoHwAb. IoHwAb also handles signal conditioning, scaling, and filtering.

Software Clusters (introduced in AUTOSAR 4.4+) group related SWCs and BSW modules into independently updatable units. Each cluster has its own configuration and can be flashed separately. This enables: independent development and release cycles for different vehicle functions, OTA partial updates, and supplier delivery as self-contained clusters. The cluster manifest defines dependencies, interfaces, and versioning.

MICROSAR is Vector's implementation of the AUTOSAR BSW modules. It includes: MICROSAR OS (AUTOSAR OS implementation), MICROSAR COM (COM, PduR, CanIf, CanTp, etc.), MICROSAR DIAG (DCM, DEM), MICROSAR MEM (NvM, Fee, Fls), MICROSAR SYS (EcuM, BswM, SchM, WdgM), MICROSAR ETH (TcpIp, SoAd, DoIP), and MICROSAR SAFE (E2E, safe modules). It's the most widely used commercial AUTOSAR stack globally.

1) Define system description in ARXML (ECUs, networks, signals). 2) Design SWCs with ports and runnables (DaVinci Developer or SystemDesk). 3) Create system composition mapping SWCs to ECUs. 4) Configure BSW modules (DaVinci Configurator or tresos): OS tasks/alarms, COM signals/I-PDUs, DCM services, NvM blocks, etc. 5) Generate RTE and BSW code. 6) Implement SWC runnables in C. 7) Compile, link, flash. 8) Test on HIL.

The AUTOSAR methodology defines the workflow: System Design (VFB view - SWCs, compositions, data types) → ECU Extract (extract one ECU's configuration from system) → BSW Configuration (configure all BSW modules for the ECU) → RTE Generation (generate RTE from SWC/system description) → Build (compile all code) → Integration Testing. Each step produces ARXML artifacts consumed by the next step. Tools automate the transitions.

BSW modules report errors through: Det (development errors - wrong parameters, invalid state), Dem (production errors - hardware failures, communication errors reported as DTCs), and return values (Std_ReturnType: E_OK/E_NOT_OK). Development errors are caught during integration and typically disabled in production. Production errors are visible to the diagnostic tester. Each module has a defined error classification in its SWS specification.

Dem_SetEventStatus(EventId, EventStatus) is called by monitor functions to report diagnostic events. EventStatus can be DEM_EVENT_STATUS_PASSED (test passed), DEM_EVENT_STATUS_FAILED (fault detected), DEM_EVENT_STATUS_PREPASSED/PREFAILED (for debouncing). Typically called cyclically by a diagnostic monitor runnable. DEM applies debouncing and updates the UDS DTC status byte. The EventId maps to a specific DTC number in the configuration.

AUTOSAR supports OTA through: Software Clusters (independently updatable units), UCM (Update and Configuration Management - in Adaptive Platform) or similar Classic mechanisms, secure communication (TLS/SecOC), bootloader with A/B partition support, signature verification (Crypto Stack), and delta update capability. The Classic Platform typically receives updates via DoIP from a master ECU running Adaptive Platform that handles the OTA backend communication.

FiM controls the enabling/inhibiting of software functions based on DEM event status. When a fault is reported (DTC becomes active), FiM can disable dependent functions via permission queries. SWCs call FiM_GetFunctionPermission() to check if they should execute. This prevents cascading failures - for example, if a sensor DTC is active, the control algorithm depending on that sensor is inhibited. FiM configuration defines event-to-function inhibition relationships.

Mode Management controls ECU behavior across operating states. Key actors: EcuM manages startup/shutdown states, BswM evaluates mode rules and executes actions, ComM controls communication modes, application-level mode SWCs define function-specific modes. The flow: SWC requests mode change → BswM evaluates rules (conditions from multiple sources) → BswM executes action list (switch COM groups, control NM, notify SWCs). This enables coordinated behavior changes across the entire ECU.

Key challenges: data consistency (shared variables accessed from multiple cores need spinlock protection), core synchronization at startup (master/satellite boot sequencing), cross-core communication overhead (IOC calls are slower than local calls), BSW module partitioning (some modules can't be split across cores), debugging complexity (reproducing race conditions), and timing analysis (WCET affected by spinlock contention and cross-core interrupt latency).

WdgDrv is the low-level driver for the internal/external watchdog timer - it sets trigger conditions and timeout values. WdgIf (Watchdog Interface) provides an abstraction layer routing WdgM commands to the correct WdgDrv instance. WdgM (Watchdog Manager) is the high-level module performing supervision logic. The flow: WdgM evaluates supervision results → determines the watchdog mode (ALIVE/EXPIRED) → calls WdgIf to trigger/stop the watchdog → WdgIf calls WdgDrv.

I-PDU multiplexing allows a single CAN message ID to carry different signal layouts depending on a multiplexer signal value. The multiplexer signal (selector) determines which dynamic signals are present in the current frame. COM module handles the multiplexing logic - it knows which signal layout corresponds to each selector value. This is common in vehicle diagnostics and body controller messages where many signals share limited CAN IDs.

COM module handles byte ordering during signal packing/unpacking. Each signal in the DBC/ARXML configuration specifies its byte order. Most automotive protocols use Motorola (big-endian) byte order, while microcontrollers are typically little-endian. COM converts between these representations transparently. The signal's bit position and byte order determine the packing algorithm. Incorrect byte order configuration is a common integration bug.

ComXf is the AUTOSAR Communication Transformer that handles data serialization for COM-based communication. For simple signals, COM handles packing directly. For complex data types exchanged over Ethernet (SOME/IP), the SOME/IP transformer serializes/deserializes structured data. ComXf also supports custom transformers for OEM-specific protocols. The transformer chain in the RTE ensures correct data representation across different communication channels.

PPort (Provide Port): SWC provides data/service to others. RPort (Require Port): SWC requires data/service from others. PRPort (Provide-Require Port): SWC both provides and requires data on the same port - used for bidirectional communication or services where the SWC acts as both client and server. Ports are typed by Port Interfaces. The connector in the composition links PPort to RPort, and the RTE generates the communication code.

Per-Instance Memory (PIM) provides SWC-specific writable memory managed by the RTE - each SWC instance gets its own copy. AUTOSAR also defines: Calibration Parameters (read-only from SWC perspective, writable via calibration tools), Inter-Runnable Variables (shared between runnables within the same SWC), and Shared Calibration Parameters (accessible by multiple SWCs). PIM is used for runtime state that needs to persist within a power cycle.

Common issues and debugging approaches: 1) COM signal not updating - check PduR routing, CanIf Rx indication, COM signal configuration. 2) DTC not setting - verify DEM event mapping, debouncing thresholds, enable conditions. 3) NvM block not persisting - check NvM block configuration, Fee/Fls job processing, shutdown sequence. 4) Task timing violation - use GLIWA T1 for runtime analysis. 5) RTE errors - check SWCD consistency and connector mapping. Det errors are the first place to look.

SD enables dynamic discovery of SOME/IP services on Ethernet networks. Service providers advertise their available services (OfferService), and consumers subscribe to services (FindService/Subscribe). SD uses UDP multicast for discovery messages. In AUTOSAR Classic, SD integrates with BswM for mode management - when a service becomes available, BswM can trigger dependent actions. SD supports multiple instances and event groups.

DoIP enables UDS diagnostic communication over Ethernet (ISO 13400). The DoIP module handles: TCP connection management for diagnostic sessions, vehicle identification (DoIP entity announcement), routing activation (logical address management), and diagnostic message encapsulation. DoIP supports both unicast (point-to-point) and broadcast communication. It's essential for modern vehicles where the diagnostic interface uses Ethernet instead of CAN.

TIMEX defines timing constraints in ARXML format: end-to-end latency requirements (sensor-to-actuator timing chains), periodic execution constraints (runnable period and jitter tolerances), synchronization constraints (events that must occur within a time window), and age constraints (maximum data age). Timing tools (Timing Architects TA, INCHRON) import TIMEX requirements, simulate the system, and verify compliance. TIMEX is crucial for ISO 26262 timing verification.

All ECUs on the bus participate in NM message exchange. When an ECU no longer needs communication, it stops sending NM messages. As long as any ECU sends NM, all others stay awake (hearing NM resets their timeout). When the last ECU stops, all nodes time out simultaneously (NM Timeout) and enter Ready Sleep state. After a coordinated wait (Wait Bus Sleep timer), all ECUs enter Bus Sleep together. This prevents partial sleep scenarios.

IdsM collects and manages security events from across the ECU - unauthorized diagnostic access attempts, SecOC authentication failures, unexpected message patterns, and firewall violations. It aggregates events, applies filtering/throttling, and can report to a central security monitoring unit via DEM or custom reporting. IdsM is part of the AUTOSAR cybersecurity extension, supporting ISO 21434 compliance.

AUTOSAR OS provides: Memory Protection (MPU-based - prevents tasks from accessing unauthorized memory regions), Timing Protection (monitors execution time budgets, inter-arrival times, and resource lock times - kills tasks exceeding limits), Service Protection (restricts OS API usage based on trust level). Non-Trusted OS Applications get all three; Trusted Applications can opt out. Protection errors trigger the ProtectionHook for error handling.

ECU Extract is the subset of the system description relevant to one specific ECU. It's created from the System Description (which describes all ECUs, networks, and SWCs) by extracting: SWCs mapped to this ECU, their port connections, the communication matrix (only messages this ECU sends/receives), the network topology this ECU participates in, and calibration parameters. Tools like PREEvision or SystemDesk create the system view; DaVinci creates the ECU extract.

DEM stores DTC data in NvM blocks: primary memory (for emission-related DTCs), user-defined memories, and permanent memory. Each DTC entry contains: UDS status byte, occurrence counter, aging counter, freeze frame data (snapshot of signals at failure time), extended data records (additional diagnostic information), and timestamps. DEM supports DTC displacement - when memory is full, lower-priority DTCs are displaced by higher-priority ones.

The Supervision Graph defines the expected program flow as a directed graph of Checkpoints within Supervised Entities. Logical Supervision verifies that checkpoints are reached in the correct sequence (valid transitions). The graph can be linear (A→B→C) or branching (A→B or A→C, both valid). Invalid transitions indicate control flow corruption - a safety-critical failure. Combined with alive and deadline supervision, it provides comprehensive runtime monitoring.

Application Data Types (ADT) describe data from the application perspective - physical units, ranges, semantics (e.g., VehicleSpeed in km/h, range 0-300). Implementation Data Types (IDT) describe the actual C representation (e.g., uint16). The CompuMethod provides the mapping (scale + offset). This separation allows changing the implementation (e.g., uint8 → uint16) without modifying the SWC interface. RTE generates the conversion code.

MCAL (Microcontroller Abstraction Layer) modules directly access hardware: Gpt (General Purpose Timer), Adc (Analog-to-Digital Converter), Pwm (Pulse Width Modulation), Dio (Digital Input/Output), Icu (Input Capture Unit), Spi (SPI communication), Port (Pin configuration and mode), Mcu (MCU clock, reset, power management), Wdg (Watchdog), Fls (Flash), Fee (Flash EEPROM Emulation), Can/Lin/Fr/Eth drivers. MCAL is microcontroller-specific.