1
What is the MCAL and what is its role in the AUTOSAR architecture?
Answer
The Microcontroller Abstraction Layer (MCAL) is the lowest BSW layer that directly accesses microcontroller hardware. It provides standardized APIs to upper layers, abstracting hardware differences. MCAL modules include: Dio, Port, Adc, Pwm, Icu, Gpt, Spi, Can, Lin, Eth, Fls, Eep, Wdg, and Mcu. The MCAL makes upper BSW layers hardware-independent - the same COM stack works whether the CAN controller is from Infineon, Renesas, or NXP.
2
What is the Mcu module responsible for?
Answer
The Mcu (Microcontroller Unit) module handles: clock tree initialization (PLL configuration, clock dividers), MCU mode management (Run, Sleep, Standby), RAM initialization, reset reason detection, and peripheral clock enable/disable. Mcu_Init() is typically the first MCAL call during startup. It provides Mcu_SetMode() for power management and Mcu_GetResetReason() for startup diagnostics. Configuration defines clock frequencies for all peripherals.
3
Explain the Port and Dio modules.
Answer
Port module configures GPIO pin properties at initialization: direction (input/output), initial level, pull-up/pull-down, slew rate, and alternate function (SPI, CAN, PWM). Port_Init() sets all pins per configuration. Dio module provides runtime read/write access: Dio_ReadChannel(), Dio_WriteChannel(), Dio_ReadChannelGroup(), Dio_FlipChannel(). Port handles configuration; Dio handles runtime I/O. They are separate per AUTOSAR to allow independent configuration.
4
How does the Adc module work in AUTOSAR?
Answer
The Adc module manages analog-to-digital conversion. Key concepts: Adc Groups - sets of channels converted together; Conversion modes - One-shot or Continuous; Trigger sources - Software or Hardware (timer, external). API: Adc_SetupResultBuffer() allocates result storage, Adc_StartGroupConversion() initiates, Adc_ReadGroup() retrieves results. Notifications (callbacks) signal conversion complete. Configuration defines: resolution, reference voltage, sampling time per channel.
5
What is the Spi module and how is it structured?
Answer
The Spi Handler/Driver manages SPI communication with external devices (sensors, EEPROMs, gate drivers). Key abstractions: Channel - data buffer for one transfer; Job - a sequence of channels with the same CS pin; Sequence - a chain of jobs executed in order. API: Spi_SetupEB()/Spi_WriteIB() for data, Spi_AsyncTransmit() for non-blocking transfer, Spi_SyncTransmit() for blocking. Supports queued transmission and priority-based job scheduling.
6
Explain the Can driver module architecture.
Answer
The Can module directly controls the CAN hardware controller. It provides: Can_Write() to transmit frames, Can_MainFunction_Read/Write/BusOff/Mode() for polling, and callbacks to CanIf for received messages (CanIf_RxIndication) and transmit confirmation (CanIf_TxConfirmation). Configuration defines: baud rate (bit timing segments), hardware filters, mailbox assignment, and controller modes. The Can module is the bottom of the communication stack: Can → CanIf → PduR → COM.
7
What is the Gpt module?
Answer
The Gpt (General Purpose Timer) module provides timer services for the BSW. It manages hardware timers with: Gpt_StartTimer() / Gpt_StopTimer(), configurable one-shot or continuous modes, and expiry notifications (callbacks). Used for: OS tick generation, timeout monitoring, measurement intervals, and event timing. Configuration specifies: timer channels, prescaler, target time, and notification functions. Important for BswM timing and diagnostic timeout monitoring.
8
How does the Pwm module work?
Answer
The Pwm module generates Pulse Width Modulation signals using hardware timers. API: Pwm_SetDutyCycle() sets the duty cycle (0-0x8000 = 0-100%), Pwm_SetPeriodAndDuty() changes both. Supports idle states and configurable polarity. Used for: motor control (H-bridge drivers), LED dimming, valve control, and fan speed. Configuration defines: channel-to-timer mapping, default period, idle state, and polarity.
9
What is the Icu module?
Answer
The Icu (Input Capture Unit) module measures external signal properties using hardware timers. Capabilities: signal measurement mode (period, duty cycle, high/low time), timestamp mode (capture event times), edge counting mode, and edge detection for wakeup. Used for: crankshaft/camshaft signal measurement, wheel speed sensing, and frequency input. API: Icu_StartSignalMeasurement(), Icu_GetDutyCycleValues(), Icu_GetTimestampIndex().
10
Explain the Wdg and WdgIf modules.
Answer
Wdg (Watchdog Driver) directly controls the hardware watchdog timer. WdgIf (Watchdog Interface) provides an abstraction layer allowing upper layers (WdgM) to access multiple watchdog instances uniformly. Wdg_SetTriggerCondition() configures the timeout, Wdg_SetMode() switches between Off, Slow, and Fast modes. WdgM (Watchdog Manager) implements alive, deadline, and logical supervision using WdgIf to trigger the hardware watchdog.
11
What is the Fls module and how does it relate to Fee?
Answer
Fls (Flash Driver) provides low-level flash memory access: Fls_Read(), Fls_Write(), Fls_Erase(), Fls_Compare(). Operations are asynchronous with Fls_MainFunction() processing. Fee (Flash EEPROM Emulation) sits above Fls, implementing a virtual EEPROM using flash pages: Fee_Read(), Fee_Write(), Fee_EraseImmediateBlock(). Fee handles wear leveling, page swapping, and garbage collection. The stack: NvM → MemIf → Fee → Fls.
12
How is the Eth (Ethernet) driver structured in AUTOSAR?
Answer
The Ethernet stack has multiple layers: Eth (controller driver) manages the MAC hardware, handles frame TX/RX, and manages buffers. EthIf (interface) abstracts multiple controllers. EthTrcv (transceiver) manages the PHY. EthSwt manages Ethernet switches. Above these: TcpIp stack (socket abstraction), SoAd (Socket Adaptor maps PDUs to sockets), and DoIP for diagnostics. Configuration includes: MAC address, VLAN settings, buffer pools, and PHY configuration.
13
What is the NvM module and what does it do?
Answer
NvM (NVRAM Manager) provides persistent storage services for BSW and application modules. It manages read/write requests to non-volatile memory with: queuing, prioritization, error recovery, and data integrity (CRC). NvM abstracts the underlying memory technology - whether flash (via Fee/Fls) or EEPROM (via Ea/Eep). All BSW modules (DEM, DCM, BswM) and application SWCs use NvM for persistent data.
14
What are the different NvM block types?
Answer
NvM Native Block - standard read/write block, single copy. NvM Redundant Block - two copies stored; NvM automatically uses the valid copy and recovers from single-copy corruption. NvM Dataset Block - array of data sets (up to 255), selectable by index; used for variant data or DTC snapshots. Each block has: block ID, length, RAM buffer address, ROM default data, CRC type, and write protection settings.
15
Explain NvM read and write operations.
Answer
Read: NvM_ReadBlock(blockId, destPtr) queues an async read. NvM_MainFunction() processes the queue, calling MemIf_Read() → Fee_Read() → Fls_Read(). On completion, NvM calls the configured notification callback. Write: NvM_WriteBlock(blockId, srcPtr) queues an async write. NvM calculates CRC, then calls MemIf_Write(). NvM_WriteAll() writes all modified blocks during shutdown - critical for data preservation.
16
What is NvM_ReadAll and NvM_WriteAll?
Answer
NvM_ReadAll() is called during startup (by EcuM) - it reads ALL configured permanent blocks from NvM into their RAM mirrors. It restores the system state from the last shutdown. NvM_WriteAll() is called during shutdown (by EcuM/BswM) - it writes ALL modified permanent blocks back to NvM. Both are asynchronous multi-block operations processed by NvM_MainFunction(). They ensure data consistency across power cycles.
17
What is Explicit vs Implicit Synchronization in NvM?
Answer
Explicit Synchronization: NvM manages the RAM block buffer directly. The application provides a pointer, and NvM reads/writes data at that address. The application must not modify data during NvM operations. Implicit Synchronization: NvM uses a mirror buffer internally and calls application callbacks (NvM_ReadRamBlockFromNvM, NvM_WriteRamBlockToNvM) to copy data. This prevents data corruption from concurrent access and is safer for multi-core systems.
18
How does NvM handle CRC and data integrity?
Answer
NvM supports CRC-8, CRC-16, or CRC-32 per block, configured statically. On write: NvM calculates CRC over the data and stores it alongside. On read: NvM recalculates CRC and compares - mismatch triggers CRC error, and NvM attempts recovery (redundant block or ROM defaults). For redundant blocks, NvM checks both copies and uses the valid one. CRC type selection balances detection capability vs computation time.
19
What happens when NvM detects a corrupted block?
Answer
Recovery sequence: 1) For redundant blocks: read the second copy; if valid, use it and repair the first copy. 2) If both copies are corrupt or block is native: load ROM default data (if configured). 3) If no defaults: report error status NVM_REQ_INTEGRITY_FAILED. 4) NvM calls the error notification callback. DEM can log a DTC. The application can check NvM_GetErrorStatus() to know if data is valid or default.
20
What is the MemIf module?
Answer
MemIf (Memory Abstraction Interface) provides a uniform API to NvM regardless of underlying memory technology. It routes NvM requests to either Fee (for flash-based emulated EEPROM) or Ea (for external EEPROM). API: MemIf_Read(), MemIf_Write(), MemIf_EraseImmediateBlock(), MemIf_GetStatus(), MemIf_GetJobResult(). The routing is based on the device index assigned to each NvM block.
21
How does Fee handle wear leveling?
Answer
Fee (Flash EEPROM Emulation) uses a log-structured approach: new data is written sequentially to flash pages rather than overwriting. When a page fills up, valid data is copied to a new page and the old page is erased (garbage collection). This distributes erase cycles evenly across flash sectors, extending flash lifetime. Fee tracks block locations in a page header. Write amplification is the trade-off: one logical write may require copying multiple blocks.
22
What is NvM_InvalidateNvBlock and when is it used?
Answer
NvM_InvalidateNvBlock() marks a block as invalid in NvM without erasing the physical data. Subsequent reads will fail (returning NVM_REQ_NV_INVALIDATED), forcing use of ROM defaults. Use cases: factory reset of learned values, clearing calibration data during reprogramming, invalidating blocks after ECU variant change. The block can be revalidated by writing new data with NvM_WriteBlock().
23
How does NvM handle write protection?
Answer
Write protection prevents modification of critical NvM blocks. Two types: static write protection (configured at build time, cannot be changed at runtime) and dynamic write protection (can be set/cleared via NvM_SetBlockProtection()). Write-protected blocks reject NvM_WriteBlock() with NVM_REQ_BLOCK_SKIPPED. Used for: bootloader configuration, security keys, and factory calibration data that must not be overwritten accidentally.
24
What is the NvM job queue and how does prioritization work?
Answer
NvM maintains a job queue for asynchronous read/write requests. Jobs are processed by NvM_MainFunction() (called cyclically, typically every 5-10ms). Prioritization: immediate priority jobs (NvM_WriteBlock with immediate flag) jump the queue for safety-critical data. Standard jobs are FIFO. Multi-block operations (ReadAll/WriteAll) have lowest priority and are interruptible by single-block requests.
25
What is the AUTOSAR COM module?
Answer
The COM module implements signal-based communication at the application level. It packs application signals into I-PDUs (Protocol Data Units) for transmission and unpacks received I-PDUs into signals. Key features: signal packing/unpacking with byte order and bit position, transmission modes (periodic, event, mixed), signal groups, notification callbacks, deadline monitoring, and signal invalidation.
26
Explain the COM transmission modes.
Answer
Direct: I-PDU sent immediately when a signal is updated via Com_SendSignal(). Periodic: I-PDU sent at a fixed interval (e.g., every 10ms) regardless of signal updates. Mixed: combines periodic with minimum-delay transmission on signal update. None: I-PDU is only sent when explicitly requested. Periodic with repetition: on signal change, send N rapid repetitions then resume periodic. Configuration specifies mode per I-PDU.
27
What is the PduR (PDU Router)?
Answer
PduR routes I-PDUs between source and destination modules. It is the central routing hub of the communication stack. Routes: COM → PduR → CanIf (TX), CanIf → PduR → COM (RX). PduR also handles: gateway routing (CAN→CAN, CAN→Ethernet), multicast (one source to multiple destinations), transport protocol routing (to CanTp for multi-frame), and multiplexed PDU routing. Configuration defines all routing paths.
28
What is the CanIf module?
Answer
CanIf (CAN Interface) abstracts the CAN driver for upper layers. It provides: CanIf_Transmit() to send L-PDUs, receive indication callbacks to PduR, controller mode management (Started/Stopped/Sleep), transceiver mode control, and PDU-to-hardware-object mapping. CanIf decouples upper layers from hardware specifics - one CanIf API works across all CAN controllers and transceivers.
29
How does the communication stack handle multi-frame messages (CanTp)?
Answer
CanTp (CAN Transport Protocol, ISO 15765-2) segments large messages into multiple CAN frames. Flow: sender transmits First Frame (FF) with total length, receiver responds with Flow Control (FC) specifying block size and timing. Sender transmits Consecutive Frames (CF). CanTp reassembles at receiver. Used for: UDS diagnostics (messages > 8 bytes), XCP measurement data, and large calibration uploads. CanTp sits between PduR and CanIf.
30
What is signal byte order in COM and why does it matter?
Answer
COM signals can be big-endian (Motorola) or little-endian (Intel) byte order, configured per signal. This determines how multi-byte signals are packed into the I-PDU payload. Big-endian: MSByte at lowest byte index. Little-endian: LSByte at lowest byte index. Getting byte order wrong causes signal value corruption - a very common integration bug. The byte order must match the communication database (DBC/ARXML).
31
What is COM signal notification?
Answer
COM can notify upper layers when signals change or are received: Notification callback - function called when an I-PDU is received. Signal invalidation - signals marked invalid after timeout or explicit invalidation. Signal filtering - configured filters (ALWAYS, MASKED_NEW_DIFFERS_MASKED_OLD, etc.) control when notifications trigger. Update bits - optional flag in I-PDU indicating which signals were updated. Applications register via COM configuration.
32
What is the IpduM (I-PDU Multiplexer)?
Answer
IpduM multiplexes multiple dynamic parts into a single I-PDU based on a selector field. Example: a CAN frame with byte 0 as selector, where selector=1 sends dataset A in bytes 1-7 and selector=2 sends dataset B. This saves bus bandwidth by sharing one PDU ID for multiple data sets. IpduM sits between COM and PduR, handling the mux/demux logic transparently.
33
What is SecOC and how does it protect communication?
Answer
SecOC (Secure Onboard Communication) authenticates I-PDUs to prevent spoofing and replay attacks. It adds a MAC (Message Authentication Code) and freshness value (counter/timestamp) to each protected PDU. On reception, SecOC verifies the MAC and freshness. Failed verification rejects the PDU. SecOC sits between PduR and the interface layers. Key management and freshness synchronization are critical configuration aspects.
34
What is E2E protection in AUTOSAR?
Answer
E2E (End-to-End) Protection Library adds safety-relevant data integrity checks over communication: CRC (protects against bit errors), Counter (detects message loss/repetition), DataID (prevents message mismatch), and Timeout (detects communication loss). E2E profiles (P01, P02, P04, P05, P07) define different protection schemes. E2E Transformer or E2E State Machine wraps/unwraps protection data transparently. Required for ASIL-rated communication.
35
How does AUTOSAR handle Ethernet communication (SoAd, TcpIp)?
Answer
SoAd (Socket Adaptor) maps I-PDUs to TCP/UDP sockets, bridging the PDU-based upper layers with socket-based TCP/IP. TcpIp module provides the BSD socket abstraction over Ethernet. Stack: COM/DCM → PduR → SoAd → TcpIp → EthIf → Eth. SoAd manages: socket connections, routing groups, and PDU-to-socket mapping. Configuration defines: IP addresses, port numbers, protocol (TCP/UDP), and routing tables.
36
What is the ComM (Communication Manager)?
Answer
ComM manages communication channel states (No Communication, Silent Communication, Full Communication) based on user requests and bus activity. It coordinates: COM (enable/disable TX/RX groups), NM (request/release network), CanSM/EthSM (bus state machines), and DCM (diagnostic communication needs). ComM ensures orderly startup/shutdown of communication and prevents bus access in wrong states.
37
What is the AUTOSAR OS and what are its key features?
Answer
AUTOSAR OS is based on OSEK/VDX with extensions for safety and multi-core. Key features: static configuration (all tasks/resources defined at compile time), priority-based preemptive scheduling, conformance classes (BCC1/BCC2/ECC1/ECC2), scalability classes (SC1-SC4), memory protection via MPU, timing protection, inter-OS-Application communication, and multi-core support. It has minimal footprint (few KB ROM/RAM) suitable for resource-constrained ECUs.
38
What are the AUTOSAR OS conformance classes?
Answer
BCC1: basic tasks only (no waiting), one activation per task, limited resources. BCC2: basic tasks with multiple activations per task, full resource support. ECC1: extended tasks (can enter waiting state via WaitEvent), one activation. ECC2: extended tasks with multiple activations. Basic tasks run to completion; extended tasks can block on events. Most automotive applications use ECC2 for maximum flexibility.
39
What is the difference between a Basic Task and an Extended Task?
Answer
Basic Tasks have three states: Suspended, Ready, Running. They run to completion once activated - cannot wait or block. Extended Tasks add a Waiting state - they can call WaitEvent() to block until an event is set. Extended Tasks enable event-driven patterns but consume more stack (stack must be preserved while waiting). Basic Tasks can share stack space. Most ISR-like periodic functions use Basic Tasks; event-driven communication handlers use Extended Tasks.
40
How does the AUTOSAR OS scheduler work?
Answer
AUTOSAR OS uses fixed-priority preemptive scheduling. Each task has a static priority (higher number = higher priority). The highest-priority ready task always runs. When a higher-priority task becomes ready (via activation or event), it immediately preempts the current task. Non-preemptive tasks run to completion once started. Scheduling points: task activation, event set, resource release, and explicit Schedule() call.
41
What are OS Alarms and how are they used?
Answer
Alarms are timer-based mechanisms that trigger actions at specified counter values. An Alarm is linked to a Counter (driven by a hardware timer or software). Actions on expiry: ActivateTask, SetEvent, IncrementCounter, or call an AlarmCallback. Alarms can be one-shot or cyclic. Use: periodic task activation (e.g., 10ms task), timeout monitoring, and scheduled events. Configuration: Counter → Alarm → Task mapping.
42
What is an OS-Application in AUTOSAR?
Answer
An OS-Application groups OS objects (tasks, ISRs, alarms, counters, resources) into a protection domain. Each OS-Application can have its own trust level: Trusted (full access) or Non-Trusted (restricted by MPU). OS-Applications provide memory isolation between different ASIL levels and QM components. Cross-application access is controlled by explicit permissions. Essential for Freedom from Interference (FFI) in safety systems.
43
How does memory protection work in AUTOSAR OS?
Answer
AUTOSAR OS SC3/SC4 uses the MPU to enforce memory boundaries per OS-Application. Each task/ISR has configured read/write access to specific memory regions. Violations trigger a ProtectionHook. Protection types: stack protection (detect overflow), data protection (prevent cross-application writes), and code protection (prevent execution of data). Configuration defines: memory regions, access rights, and trusted functions for cross-boundary calls.
44
What is timing protection in AUTOSAR OS?
Answer
Timing protection (SC2/SC4) monitors: execution budget (max CPU time per task activation), time frame (minimum arrival time between activations), lock budget (max time holding a resource or disabling interrupts). Violations trigger ProtectionHook with OS error codes. This prevents: runaway tasks consuming all CPU, interrupt storms, and priority inversion from excessive resource locking. Critical for ASIL timing requirements.
45
What is a Schedule Table in AUTOSAR OS?
Answer
A Schedule Table defines a sequence of expiry points at fixed offsets within a repeating period. At each expiry point, actions execute (ActivateTask, SetEvent). Unlike individual alarms, Schedule Tables synchronize multiple actions with precise relative timing. They can be synchronized to a global time source. Use: coordinating cyclic task activations with guaranteed timing relationships (e.g., sensor read → compute → actuator write).
46
How does AUTOSAR OS handle multi-core?
Answer
AUTOSAR OS supports multi-core with: one OS instance per core, shared spinlocks for cross-core synchronization, IOC (Inter-OS-Application Communication) for data exchange, cross-core task activation via ActivateTask() on remote core, and synchronized startup. Each core has independent scheduling. Spinlocks replace resources for cross-core mutual exclusion. ShutdownAllCores() coordinates system shutdown.
47
What is the EcuM (ECU State Manager)?
Answer
EcuM manages the overall ECU lifecycle: startup sequence (init BSW modules in correct order), run management (track RUN requests from SWCs), sleep management (coordinate shutdown, configure wakeup sources), and shutdown/reset. EcuM defines ECU states: STARTUP, RUN, POST_RUN, SLEEP, OFF. It orchestrates the transition between power states and triggers NvM_WriteAll before shutdown.
48
Describe the AUTOSAR startup sequence managed by EcuM.
Answer
1) EcuM_Init(): Initialize OS, initialize SchM. 2) StartPreOS: init deterministic modules (Mcu, Port, Dio). 3) Start OS. 4) EcuM_StartupTwo (in OS task): init remaining BSW (Can, COM, NvM), call NvM_ReadAll. 5) Wait for NvM_ReadAll completion. 6) Init RTE. 7) Start application SWCs. 8) Signal BswM for mode switches. The exact init order is configurable but dependency-constrained.
49
What is the difference between EcuM Fixed and EcuM Flex?
Answer
EcuM Fixed: the original implementation with predefined state machine and fixed behavior. It directly manages RUN/POST_RUN/SLEEP transitions. EcuM Flex (introduced later): provides basic sleep/wakeup/shutdown but delegates mode management to BswM. EcuM Flex is simpler and more flexible - BswM rules control the actual mode behavior. Most modern AUTOSAR projects use EcuM Flex + BswM combination.
50
What are EcuM wakeup sources?
Answer
Wakeup sources are hardware events that bring the ECU from SLEEP to RUN: CAN wakeup (network activity), wakeup line (external pin), internal timer (scheduled wakeup), or diagnostic request (DoIP activation). Each source has a configured validation timeout. On wakeup: EcuM detects the source, validates it (debounce), and initiates the startup sequence. ComM uses wakeup source information to decide which channels to activate.
51
What is the BswM (BSW Mode Manager)?
Answer
BswM is the central decision engine for mode management in AUTOSAR. It evaluates rules based on mode conditions (inputs) and executes action lists (outputs). Inputs: ComM channel mode, NvM status, EcuM state, diagnostic session, application mode requests. Actions: enable/disable COM groups, switch PduR routing, control NM, trigger DEM operations. BswM replaces hardcoded mode logic with configurable rules.
52
How do BswM rules work?
Answer
A BswM rule consists of: Mode Request Ports (inputs - mode values from other modules), a Logical Expression (boolean combination of mode conditions), and an Action List (sequence of actions to execute when the expression is true). Rules are evaluated either: immediately when a mode changes (immediate), or during BswM_MainFunction() (deferred). Examples: IF ComM==FULL_COM AND NvM==ReadAll_OK THEN enable_COM_TX_group.
53
Give an example of BswM controlling communication startup.
Answer
Scenario: Enable CAN TX only after NvM is ready and COM is initialized. Rule: ModeCondition1: EcuM_State == RUN, ModeCondition2: NvM_ReadAll == OK, ModeCondition3: ComM_Channel1 == FULL_COMMUNICATION. LogicalExpression: Condition1 AND Condition2 AND Condition3. ActionList: Com_IpduGroupStart(TxGroup), Com_IpduGroupStart(RxGroup). This ensures no garbage data is transmitted before NvM restores calibration values.
54
What is the role of BswM in diagnostics?
Answer
BswM manages diagnostic mode transitions: when DCM enters Extended Session, BswM can: enable additional diagnostic services, switch COM to diagnostic mode, disable application functions that interfere with testing, and unlock calibration parameters. When DCM returns to Default Session, BswM reverses these actions. This centralized control prevents scattered conditional logic throughout the BSW.
55
How does EcuM handle shutdown?
Answer
Shutdown sequence: 1) EcuM receives shutdown request (EcuM_SelectShutdownTarget). 2) BswM prepares: disable COM, stop application SWCs. 3) EcuM calls NvM_WriteAll() to persist all data. 4) Wait for NvM_WriteAll completion (with timeout). 5) Deinit BSW modules in reverse order. 6) EcuM_Shutdown() or EcuM_GoSleep() - either power off or enter sleep mode with configured wakeup sources.
56
What is the SchM (Schedule Manager)?
Answer
SchM provides the BSW MainFunction scheduling mechanism and critical section protection. It triggers cyclic MainFunctions of BSW modules (NvM_MainFunction, Com_MainFunction, etc.) from OS tasks. SchM also provides exclusive area APIs: SchM_Enter_<module>() and SchM_Exit_<module>() for protecting shared data within BSW. Exclusive areas map to interrupt disable, spinlocks, or OS resources depending on protection needs.
57
How do EcuM and BswM work together?
Answer
EcuM handles the hardware-level lifecycle (startup/sleep/wakeup) while BswM handles the logical mode management. Flow: EcuM detects wakeup source → reports to BswM → BswM evaluates rules and enables appropriate communication channels via ComM → ComM requests NM → NM brings up the network → BswM enables COM groups. On shutdown: BswM disables COM → ComM releases NM → EcuM triggers NvM_WriteAll → EcuM enters sleep.
58
What are BswM action lists?
Answer
Action lists are ordered sequences of actions executed when a BswM rule evaluates to true. Available actions include: ComM_AllowCom, Com_IpduGroupSwitch, PduR_EnableRouting, NM_NetworkRequest, Dcm_RequestCommunicationMode, RteSwitch (trigger mode switch port), EcuM_SelectShutdownTarget, and user-defined callouts. Actions execute sequentially and can be conditional (AbortOnFail). Lists are configured statically in the BSW configuration.
59
What is the DCM (Diagnostic Communication Manager)?
Answer
DCM handles UDS diagnostic services per ISO 14229. It manages: diagnostic session control (Default, Extended, Programming), service dispatching (routes requests to handlers), security access (seed & key validation), response handling (positive, negative, pending), and protocol timing (P2, P2*). DCM sits above PduR and interacts with DEM (for DTCs), DID data providers, and routine implementations.
60
How does DCM handle service processing?
Answer
Request flow: 1) PduR delivers diagnostic request PDU to DCM. 2) DCM validates: session, security level, message length. 3) DCM identifies the service (SID) and sub-function. 4) DCM calls the configured service handler: internal (DID read/write) or external (callout to SWC). 5) Handler processes and returns data. 6) DCM assembles and sends the response PDU. 7) On error: DCM sends NRC (Negative Response Code). All timing is managed by DCM.
61
What is the DEM (Diagnostic Event Manager)?
Answer
DEM manages Diagnostic Trouble Codes (DTCs) and their lifecycle. It handles: event reporting (Dem_SetEventStatus), DTC status byte management (testFailed, confirmedDTC, etc.), aging and displacement, snapshot and extended data recording, enable conditions, and storage in NvM. DEM is the central DTC database - DCM reads DTC info from DEM via Dem_GetDTCByOccurrenceTime, Dem_GetStatusOfDTC, etc.
62
Explain the DTC status byte bits.
Answer
The UDS status byte (8 bits): Bit 0 - testFailed: current test result is failed. Bit 1 - testFailedThisOperationCycle: failed at least once this cycle. Bit 2 - pendingDTC: failed in current or previous cycle. Bit 3 - confirmedDTC: DTC is confirmed (after trip counter threshold). Bit 4 - testNotCompletedSinceLastClear: test hasn't completed since DTC clear. Bit 5 - testFailedSinceLastClear. Bit 6 - testNotCompletedThisOperationCycle. Bit 7 - warningIndicatorRequested.
63
How does DEM handle DTC aging?
Answer
Aging removes confirmed DTCs that have not recurred for a configured number of operation cycles. When a confirmed DTC passes all tests for N consecutive cycles (aging counter threshold), DEM clears the confirmedDTC bit and optionally deletes the DTC entry. Typical threshold: 40-200 cycles. Aging ensures old, resolved faults don't permanently clutter the DTC memory. Each DTC can have an individual aging threshold.
64
What is DTC displacement in DEM?
Answer
When DTC memory is full and a new DTC needs storage, displacement logic decides which existing DTC to evict. Priority-based: lower-priority DTCs are displaced first. DEM can be configured with displacement strategies: by DTC priority, by occurrence order, or no displacement (reject new DTCs). Displaced DTCs lose their snapshot and extended data. Critical DTCs should have high priority to prevent displacement.
65
What are DEM enable conditions?
Answer
Enable conditions gate when DEM processes event status reports. If the enable condition for a DTC is not fulfilled, Dem_SetEventStatus() is ignored. Use cases: don't process DTCs during first 5 seconds after startup (voltage stabilization), disable temperature DTCs when engine is cold, or suppress communication DTCs during bus-off recovery. Conditions are set/cleared via Dem_SetEnableCondition().
66
How does DCM handle session management?
Answer
DCM supports diagnostic sessions: Default Session (limited services), Programming Session (for flashing), Extended Diagnostic Session (all services). Sessions control: which services are available, which DIDs are readable/writable, and security requirements. Session transitions via DiagnosticSessionControl (0x10). DCM manages S3 server timer - if no request is received within S3 timeout (typically 5s), DCM returns to Default Session.
67
What is the DCM security access mechanism?
Answer
Security Access (UDS 0x27) uses a seed-key challenge-response: 1) Tester requests seed (odd sub-function). 2) DCM generates a random seed and sends it. 3) Tester computes key using a secret algorithm. 4) Tester sends key (even sub-function). 5) DCM verifies the key. Multiple security levels can be configured, each protecting different service access. Failed attempts trigger a delay timer to prevent brute-force attacks.
68
What are DIDs and how does DCM read/write them?
Answer
DIDs (Data Identifiers) are 16-bit identifiers for ECU data items. ReadDataByIdentifier (0x22) reads DIDs, WriteDataByIdentifier (0x2E) writes them. DCM configuration maps each DID to: a data source (direct memory, callback to SWC, or RTE port), access conditions (session, security), and data length. Common DIDs: 0xF190 (VIN), 0xF187 (spare part number), 0xF191 (hardware version). Applications implement DID callbacks.
69
What is Routine Control in DCM?
Answer
RoutineControl (0x31) executes ECU routines: Start (0x01), Stop (0x02), RequestResults (0x03). Each routine is identified by a 16-bit Routine Identifier. Examples: 0xFF00 (erase flash memory), 0xFF01 (check programming dependencies), 0x0203 (actuator test). DCM dispatches to configured routine handlers. Routines can be: synchronous (result returned immediately) or asynchronous (start returns pending, results queried later).
70
How does DCM handle response pending (NRC 0x78)?
Answer
When a service takes longer than the P2 server timer (typically 50ms), DCM sends a Negative Response with NRC 0x78 (requestCorrectlyReceivedResponsePending). This tells the tester to wait with extended timeout P2* (typically 5000ms). DCM can send multiple NRC 0x78 responses. This is common for: NvM read/write operations, flash erase, and complex routine controls. The maximum number of pending responses is configurable.
71
What is the FIM (Function Inhibition Manager)?
Answer
FIM controls the enable/disable state of software functions based on DTC status. When certain DTCs are active, FIM can inhibit related functions to prevent cascading failures. Configuration: Function ID → DTC list → inhibition condition (testFailed, confirmed, etc.). API: FiM_GetFunctionPermission() returns whether a function is permitted. Example: if wheel speed sensor DTC is active, FIM inhibits ABS function.
72
How does DEM store snapshot data?
Answer
When a DTC transitions to a specific state (e.g., testFailed), DEM captures a snapshot (freeze frame) containing: DIDs specified in the DTC's snapshot record configuration (e.g., vehicle speed, engine RPM, battery voltage, odometer). Snapshots preserve the vehicle conditions at fault occurrence. Multiple snapshots can be stored per DTC (configurable). DCM reads snapshots via ReadDTCInformation (0x19, sub-function 0x04).
73
What is the WdgM (Watchdog Manager)?
Answer
WdgM provides software supervision using three mechanisms: Alive Supervision - verifies periodic functions execute at the correct rate. Deadline Supervision - verifies execution time between checkpoints is within bounds. Logical Supervision - verifies the correct execution sequence through checkpoints. If supervision fails, WdgM transitions from ALIVE to EXPIRED to STOPPED, triggering safety reactions. WdgM feeds the hardware watchdog via WdgIf.
74
How does WdgM alive supervision work?
Answer
Alive supervision monitors periodic tasks: the supervised function calls WdgM_CheckpointReached() each cycle. WdgM counts these calls within a reference cycle (e.g., 100ms supervision period). If the count is outside the configured min/max range, supervision fails. This detects: task not running (count too low), task running too fast (count too high), or task stuck in a loop. Each supervised entity has independent alive monitoring.
75
What is the Det (Default Error Tracer)?
Answer
Det is a development-time error reporting module. BSW modules call Det_ReportError(ModuleId, InstanceId, ApiId, ErrorId) when they detect API misuse: null pointer, invalid parameter, wrong state. Det is typically active during development and can be disabled in production to save resources. Custom Det handlers can: log errors, trigger breakpoints, or assert. Det errors indicate integration or configuration bugs.
76
What is the difference between Det and DEM error reporting?
Answer
Det reports development/integration errors - programming mistakes like null pointers, invalid IDs, or calling APIs in wrong sequence. These should never occur in production. DEM reports runtime diagnostic events - hardware failures, communication timeouts, and sensor malfunctions that can occur in the field. Det is for developers during integration; DEM is for workshops and customers during vehicle lifetime.
77
How does WdgM deadline supervision work?
Answer
Deadline supervision measures execution time between two checkpoints: WdgM_CheckpointReached(start_cp) marks the beginning, WdgM_CheckpointReached(end_cp) marks the end. The elapsed time between them must be within configured min/max deadline bounds. This detects: functions taking too long (performance issue), functions completing too fast (possible skipped processing), and timing violations in safety-critical paths.
78
What happens when WdgM supervision fails?
Answer
Failure sequence: Local status transitions from ALIVE → EXPIRED. If multiple supervised entities fail, or after a configured failed tolerance count, the global status transitions: ALIVE → EXPIRED → STOPPED. In EXPIRED: WdgM stops triggering the hardware watchdog, which will reset the ECU after the watchdog timeout. In STOPPED: immediate safe state. BswM can be notified to trigger graceful degradation before reset.
79
What is the NM (Network Management) module?
Answer
NM coordinates sleep/wake behavior across all ECUs on a network. AUTOSAR NM uses a token-passing-like ring message scheme: each ECU periodically sends NM PDUs while communication is needed. When all ECUs release the network, NM transitions to Bus Sleep. States: Bus Sleep → Network Mode (Repeat Message → Normal Operation → Ready Sleep) → Prepare Bus Sleep → Bus Sleep. CanNm, UdpNm, and LinNm implement protocol-specific behavior.
80
What is the CRC library in AUTOSAR?
Answer
The CRC library provides standardized CRC calculation functions: Crc_CalculateCRC8() (SAE J1850), Crc_CalculateCRC8H2F() (0x2F polynomial), Crc_CalculateCRC16() (CCITT), Crc_CalculateCRC32() (IEEE 802.3), Crc_CalculateCRC32P4() (0x1EDC6F41), and Crc_CalculateCRC64(). Used by: NvM (block integrity), E2E (data protection), SecOC (MAC calculation), and COM (signal protection). Table-based or runtime calculation is configurable.
81
What is the ComXf (Communication Transformer)?
Answer
ComXf serializes and deserializes complex data types for communication. SOME/IP Transformer handles SOME/IP serialization. E2E Transformer adds/verifies E2E protection. Safety Transformer applies safety-related data transformations. Transformers chain together: SWC data → SOME/IP serialization → E2E protection → COM → PduR. They decouple data representation from transport, enabling the same SWC to communicate over CAN or Ethernet.
82
How does the Dcm handle ResponseOnEvent (0x86)?
Answer
ResponseOnEvent (ROE) allows a tester to subscribe to automatic ECU notifications. The ECU stores the event condition (e.g., DTC status change, DID value change) and monitored service. When the condition is met, DCM automatically sends the response without a new request. Sub-functions: start/stop/clear ROE. Use case: tester subscribes to DTC changes during a test drive, receiving real-time fault notifications.
83
What is the BswM's role during ECU reprogramming?
Answer
During reprogramming: 1) DCM receives programming session request → BswM is notified. 2) BswM rule evaluates → executes action list: disable application SWCs, disable COM TX, stop NM, prepare memory. 3) BswM triggers EcuM to enter programming state. 4) After reprogramming: EcuM resets ECU. 5) On restart: BswM detects reprogram-complete flag, runs validation routines before enabling normal operation.
84
What is the AUTOSAR BSW module initialization order?
Answer
Typical order (EcuM managed): Phase 1 (pre-OS): Mcu_Init → Port_Init → Dio_Init. Phase 2 (post-OS): Det_Init → SchM_Init → Gpt_Init → Wdg_Init → WdgM_Init → Can_Init → CanIf_Init → CanTp_Init → PduR_Init → Com_Init → Dcm_Init → Dem_Init → NvM_Init → Fee_Init → Fls_Init → BswM_Init → EcuM_StartupTwo. Dependencies drive order: Can before CanIf, NvM before DEM (DEM reads DTCs from NvM).
85
How does the AUTOSAR BSW handle error reporting hierarchy?
Answer
Three levels: 1) Det (development errors) - catches API misuse during integration, typically disabled in production. 2) DEM (production errors) - logs runtime faults as DTCs with snapshots for workshop diagnosis. 3) Application error handling - SWC-level error detection and reaction via FIM and safety monitors. Additionally, WdgM provides supervision-based error detection. BswM coordinates system-level error reactions across all reporting mechanisms.