1. What is AUTOSAR and why is it needed?

AUTOSAR (AUTomo ve Open System ARchitecture) is a worldwide development partnership that

standardizes the so ware architecture for automo ve ECUs.
It is needed to:

 Enable scalability and flexibility across car lines.

 Improve so ware reuse and exchange across OEMs and suppliers.

 Reduce development me and cost by standardizing interfaces and layers.

 Support integra on of advanced features (ADAS, connec vity) with safety and security.

2. What are the differences between Classic Pla orm and Adap ve Pla orm?

Feature Classic Pla orm Adap ve Pla orm

Microcontroller-based (hard real- High-performance ECUs (mul -core,

Target ECUs
me) POSIX)

Applica on type Sta c, real- me applica ons Dynamic, service-oriented applica ons

Communica on COM stack (e.g., CAN, LIN, FlexRay) Service-based (SOME/IP over Ethernet)

Update Dynamic deployment and updates at

Sta c configura on
mechanism run me

Use cases Body, powertrain, diagnos cs Infotainment, ADAS, autonomous driving

OS AUTOSAR OS (OSEK-based) POSIX-based (e.g., Linux, QNX)

3. Explain the AUTOSAR layered architecture.

The AUTOSAR Classic Pla orm has a three-layer architecture:

 Applica on Layer: Contains applica on-level func onality in the form of So ware
Components (SWCs).

 RTE (Run me Environment): Mediates communica on between SWCs and the BSW,
implemen ng the Virtual Func onal Bus (VFB).

 Basic So ware (BSW): Provides core services, communica on stacks, ECU abstrac on, and
microcontroller abstrac on.

BSW is further divided into:

 Service Layer (e.g., NVRAM Manager, Diagnos c Services)

 ECU Abstrac on Layer (e.g., I/O, ADC)

 Microcontroller Abstrac on Layer (MCAL)

  Complex Drivers (op onal, for non-standard HW)

4. What are So ware Components (SWC) and how are they connected?

SWCs are reusable units of applica on func onality with well-defined interfaces. They are:

 Hardware-independent

 Described using XML-based ARXML files

 Interconnected via ports using sender-receiver or client-server communica on pa erns.

Connec ons:

 Within ECU: Routed by RTE

 Across ECUs: Translated to bus signals via COM stack

5. What is the RTE and what is its role?

RTE (Run me Environment) is an abstrac on layer that:

 Connects SWCs to each other and to BSW modules.

 Realizes the Virtual Func onal Bus (VFB) at run me.

 Ensures SWCs remain hardware-independent by handling all communica on.

It is generated per ECU based on system configura on.

6. Describe the VFB (Virtual Func onal Bus) concept.

VFB is a conceptual communica on bus in AUTOSAR:

 Represents a virtual connec on between SWCs, regardless of their actual ECU loca on.

 Ensures applica on development can proceed without knowledge of deployment.

 The RTE and COM stack implement the VFB func onality at run me.

7. What is the role of BSW (Basic So ware)?

BSW provides all the low-level so ware services required by SWCs:

 Hardware abstrac on (e.g., ADC, PWM, CAN drivers)

 Communica on services (e.g., PDU Router, CAN TP)

 System services (e.g., Diagnos cs, OS, NVRAM Manager)

 Ensures pla orm-independence and reuse across hardware pla orms.

1. What is the role of the DCM module?

The Diagnos c Communica on Manager (DCM) manages the diagnos c communica on as per UDS
(ISO 14229) and OBD standards.
Its main responsibili es include:

 Handling UDS and OBD requests from diagnos c testers.

 Parsing diagnos c messages (e.g., ReadDataByIden fier, DTC requests).

 Dispatching requests to appropriate applica on or BSW modules (e.g., DEM, SWC).

 Managing diagnos c sessions and security access.

 Coordina ng ming and response formats.

2. How does DCM handle different UDS services?

DCM supports UDS services via a service table and dispatching logic:

 Each UDS service (e.g., 0x22, 0x2E, 0x19) has a handler func on.

 Services are mapped via configura on (e.g., in ARXML or Vector's DaVinci Configurator).

 DCM parses the SID, checks session/security validity, and routes it to:

o Applica on callouts (e.g., SWC or BSW func ons)

o Internal handlers (for built-in services like 0x10, 0x11)

 For services like 0x19 (DTC), DCM interacts with DEM.

3. How does DEM store and manage DTCs?

Diagnos c Event Manager (DEM) manages Diagnos c Trouble Codes (DTCs) and their associated
events.

Key features:

 Events are mapped to DTCs in configura on.

 Stores DTCs in event memory (e.g., primary, secondary).

 Supports status bits (e.g., testFailed, confirmedDTC) via event status.

 Offers APIs to:

o Report event status (Dem_ReportErrorStatus)

o Read DTCs (Dem_GetStatusOfDTC, etc.)

o Clear DTCs
4. Explain the life cycle of a DTC in DEM.

1. Event detected: Applica on calls Dem_ReportErrorStatus(EventId, Status).

2. Debouncing (op onal): Event passes debounce algorithm.

3. DTC gets stored in event memory with appropriate status bits.

4. DTC confirmed: If confirmed criteria are met (e.g., mul ple failed cycles).

5. DTC aging: If event remains passed for N cycles, aging starts.

6. DTC cleared: Via UDS service 0x14 or programma cally.

5. What is event debouncing in DEM?

Event debouncing prevents false posi ves due to signal noise or transient errors.

Key points:

 A debounce algorithm (e.g., counter-based, me-based) filters raw event states.

 Only a er debounce confirms “Failed” or “Passed”, DEM processes it.

 Configurable per event in tools like DaVinci Configurator.

6. How do you configure a UDS service in Vector tools?

Using Vector DaVinci Configurator/Developer:

1. Import or define diagnos c SWS/ARXML.

2. Under the DCM module, define:

o Service Table: Add UDS SID (e.g., 0x22).

o DID: For services like 0x22/0x2E, configure Data Iden fiers.

o Session/Security: Configure availability.

3. For applica on-routed data, define callouts or RTE ports.

4. Generate code and implement callbacks (e.g., Dcm_<Service>_<DID>_ReadData).

7. What is the difference between OBD and UDS diagnos cs?

Feature UDS (ISO 14229) OBD (ISO 15031/15765)

Purpose OEM-level diagnos cs Emission-related mandatory diagnos cs

Services e.g., 0x22, 0x2E, 0x19 e.g., 0x01, 0x03, 0x04

Tester tool OEM/internal testers Standard scan tools (e.g., for inspec on)
Feature UDS (ISO 14229) OBD (ISO 15031/15765)

Data format Configurable, flexible Standardized PIDs and DTCs

Access level O en secured or session-limited Always accessible in default session

8. How is DID data fetched and updated?

DIDs (Data Iden fiers) are handled in UDS services like:

 0x22 (ReadDataByIden fier)

 0x2E (WriteDataByIden fier)

DCM uses callbacks:

 Read DID: Dcm_<DID>_ReadData (applica on or BSW)

 Write DID: Dcm_<DID>_WriteData

The data can be:

 Fetched from applica on variables (via RTE)

 Retrieved from NVRAM or sensors

 Updated in RAM, NVRAM, or SWC memory depending on config

9. What is the role of DET?

DET (Development Error Tracer):

 Part of AUTOSAR BSW for error repor ng during development.

 Logs internal so ware errors (e.g., NULL pointer, invalid state).

 Provides Det_ReportError API used by BSW modules.

 Only ac ve in development builds; disabled in produc on.

It helps in:

 Debugging configura on or integra on issues.

 Verifying compliance with module API usage.

1. How does AUTOSAR COM module handle signal packing and unpacking?

The COM module handles signal-to-I-PDU and I-PDU-to-signal conversion:

 Packing (Tx):

o Applica on signals are collected.

o COM packs signals into an I-PDU buffer according to the configured bit posi on,
length, and byte order.

o Packed I-PDU is passed to PDU Router → CAN Interface → CAN Driver.

 Unpacking (Rx):

o A received I-PDU is unpacked by COM.

o Signals are extracted from their defined posi ons.

o Updated signal values are passed to the applica on via RTE or no fica on callbacks.

Packing/unpacking uses signal group configura on, endianness, bit offset, and scaling rules as
defined in ARXML.

2. What is the role of the PDU Router (PduR)?

PduR is a rou ng module that:

 Routes I-PDUs between upper layers (COM, DCM, etc.) and lower layers (CAN Interface, LIN
Interface, etc.).

 Is completely protocol-independent.

 Does not modify the PDU content.

 Ensures mul plexing/demul plexing of data sources to appropriate communica on

channels.

Example flows:

 COM → PduR → CANIF (Tx)

 CANIF → PduR → COM (Rx)

 DCM → PduR → CANIF (for diagnos cs)

3. How do you configure I-PDUs and signals in Vector DaVinci?

In Vector DaVinci Configurator:

1. Import System Descrip on ARXML from communica on tools like CANdela Studio.

2. Navigate to COM module configura on:

o Define signals, signal groups, I-PDUs.

 o Map signals to I-PDUs.

o Set a ributes: update bit, transfer property, signal length, meout, etc.

3. In PduR:

o Route I-PDUs to/from COM, DCM, or other modules.

4. In CAN Interface and CAN Driver:

o Assign PDU handles to CAN IDs and hardware objects.

Then, generate code and implement callbacks if required.

4. What is the interac on between CAN Interface and CAN Driver?

 CAN Interface (CANIF):

o Hardware-independent abstrac on layer.

o Manages CAN controller and transceiver states.

o Converts I-PDU to/from CAN frames.

o Manages dynamic IDs and mode control.

 CAN Driver (CanDrv):

o Low-level interface to the microcontroller's CAN hardware.

o Sends and receives CAN frames using hardware buffers (HOHs).

o Reports Tx/Rx status to CANIF via ISR or polling.

Flow Example (Tx):

COM → PduR → CANIF → CAN Driver → CAN Bus

5. What is dynamic vs sta c I-PDU?

Feature Sta c I-PDU Dynamic I-PDU

CAN ID Fixed, configured at design me CAN ID can be changed at run me

Use case Normal periodic signals Diagnos cs, mul plexed data

Config in Vector CANIF → Sta cTxPdu CANIF → DynamicTxPdu

Example RPM or temperature Diagnos c responses, tool requests

Dynamic I-PDU requires a CAN ID handle to be updated via API (CanIf_ChangeTxPduId() or

PduR_CanIfTriggerTransmit()).

6. What are trigger-transmit and signal meout mechanisms?

Trigger Transmit:

 Used for on-demand transmission.

 Lower layer (e.g., CANIF) asks upper layer (e.g., COM, DCM) to fill the data during
transmission.

 Common in diagnos cs or event-driven messages.

 Func on: PduR_<UpperModule>_TriggerTransmit() or Dcm_TriggerTransmit().

Signal Timeout:

 Ensures signal freshness.

 If a received signal is not updated within a configured me:

o COM sets it to a default value.

o May no fy applica on via meout callback.

 Timeout is configured per Rx signal using parameters like ComTimeout.

1. What is the role of the NvM module?

NvM (Non-vola le Memory Manager) handles:

 Reading/wri ng structured data to/from non-vola le memory (EEPROM, Flash).

 Providing a high-level API to applica ons and other BSW modules (e.g., DEM, DCM).

 Ensuring data integrity, consistency, and reliability across resets and power cycles.

 Managing block-based storage, job priori za on, redundancy, and error handling.

NvM sits on top of Fee/Ea and communicates through MemIf.

2. How does NvM ensure data consistency?

NvM uses mul ple mechanisms to ensure data consistency and reliability:

 Redundant blocks: Writes two copies alternately to allow recovery if power fails mid-write.

 CRC checks: Validates data correctness on read using configured CRC.

 Write verifica on: Ensures data was correctly wri en via checksum comparison.

 Write-once blocks: Used for calibra on or factory data to prevent accidental overwrites.

 NV-RAM Block Status: Tracks validity using NvM_RequestResult.

These are configured per NvM block.

3. What are NvM blocks and how are they configured?

NvM operates on data in units called blocks:

 A block is a logical representa on of a structured data unit (e.g., calibra on data, counters).

 Each block has:

o Block ID (unique)

o Length

o Data pointer

o Management type (standard, redundant, immediate)

o Associated storage type (Fee or Ea)

Configura on in Vector DaVinci:

 Under the NvM module, define NvM Blocks.

 Link to RAM Data pointers.

 Enable/disable CRC, sta c IDs, write protec on, ROM defaults.

 Map each block to an underlying device driver (Ea or Fee).

4. Describe the difference between Fee and Ea.

Feature Fee (Flash EEPROM Emula on) Ea (EEPROM Abstrac on)

Use case For internal Flash (no EEPROM) For dedicated external EEPROM

Device type Emulates EEPROM over internal Flash Talks to real EEPROM over I2C/SPI

Storage method Virtual sector-based, Flash wear-leveling Block-oriented EEPROM access

Used with Flash-based microcontrollers EEPROM modules on board

NvM selects either Fee or Ea as the underlying memory driver based on block mapping.

5. How does MemIf help abstract hardware access?

MemIf (Memory Abstrac on Interface) is a middleware interface that:

 Sits between NvM and Fee/Ea.

 Provides uniform APIs for memory opera ons (Read, Write, Erase, Compare).

 Abstracts which physical memory is used—NvM doesn’t need to know if it’s Flash or
EEPROM.

 Also handles job results and status management.

This allows replacing or upda ng memory drivers without affec ng higher-level modules.

6. What is the CRC mechanism in NvM?

NvM uses CRC (Cyclic Redundancy Check) to ensure data integrity:

 At write me:

o NvM computes CRC over the data + op onal admin fields.

o CRC is stored along with the block.

 At read me:

o CRC is recalculated and compared.

o If mismatch occurs, NvM flags the block as invalid, and ROM default (if configured)
may be used.

NvM supports:

 CRC16, CRC32 (configurable per block)

 Can be turned on/off per block

 Relies on Crc module from AUTOSAR BSW

1. What are the different task types in AUTOSAR OS?

AUTOSAR OS defines several task types, categorized mainly by scheduling behavior and ac va on
method:

Task Type Descrip on

- Ac vated only by the OS

Basic Task - Runs to comple on (non-preemp ble)
- May not block or wait

- Can wait for events using WaitEvent()

Extended Task - Supports preemp on
- Typically used in complex apps
Task Type Descrip on

- High-priority task for quick reac ons

Foreground Task
- O en triggered by interrupts

- Low-priority infinite loop

Background Task
- Used for idle- me work

- Used for one- me ini aliza on

Init Task
- Runs at startup

Runnable En ty - Not an OS task, but part of AUTOSAR SWC execu on via RTE

2. How does the OS handle events and alarms?

Events (for Extended Tasks only):

 Events are like flags or signals.

 One task can WaitEvent(EventMask) and suspend.

 Another task or ISR can SetEvent(taskID, EventMask) to wake it.

 GetEvent and ClearEvent APIs allow checking/clearing event states.

Alarms (used with counters):

 Timers that trigger ac ons (at specific or recurring mes).

 Ac ons include:

o Ac va ng a task

o Se ng an event

o Calling a callback func on

 Configured using OS counters and alarms (either so ware or hardware-based).

3. What are resources and how are they used to avoid race condi ons?

Resources in AUTOSAR OS help ensure exclusive access to shared data or hardware.

 Used to protect cri cal sec ons.

 Based on priority ceiling protocol:

o When a task locks a resource, its priority is raised to the resource’s ceiling.

o Prevents priority inversion (low-priority task blocking high-priority task).

APIs:

 GetResource(ResourceID)
  ReleaseResource(ResourceID)

Configura on involves:

 Declaring resources in OS configura on.

 Assigning resources to tasks needing them.

4. Explain the concept of trusted and non-trusted applica ons.

AUTOSAR supports mul -core, mul -app systems with varying trust levels:

Aspect Trusted Applica on Non-Trusted Applica on

Restricted to its own par on

Memory access Full access (or with fewer restric ons)
memory

API permissions Can call any OS services Limited to a subset of safe OS services

Failure Failure can impact system-wide

Isolated to prevent cascading failures
containment behavior

Use case Safety-cri cal logic Supplier or third-party code

MCAL, OS core, and cri cal BSW are usually in trusted applica ons.

5. What is ming protec on and how is it implemented?

Timing protec on ensures that tasks, ISRs, and apps do not:

 Overrun their allocated execu on me

 Violate ming constraints, e.g., inter-arrival me or locking dura on

Key Types:

 Execu on Time Monitoring: Limits how long a task/ISR can run.

 Inter-arrival Time: Prevents tasks from being ac vated too frequently.

 Resource Lock Time: Limits me spent holding a resource.

Implementa on:

 The OS uses ming budgets (configured per task/ISR).

 Hardware mers or counters are used to track actual me.

 Viola ons trigger:

o Protec on hooks

o Error handling mechanisms (e.g., OS shutdown, task termina on)

Configured in the OS (e.g., Vector's OSEK Builder or AUTOSAR OS XML) using:

  Execu onBudget, InterArrivalTime, LockBudget

1. Describe the role of DaVinci Configurator vs DaVinci Developer.

Feature DaVinci Developer DaVinci Configurator Pro

Design AUTOSAR So ware Components

Purpose Configure Basic So ware (BSW) and RTE
(SWCs)

Used by Applica on developers System integrators, BSW engineers

Func onal design: ports, runnables,

Focus Mapping, configura on, genera on
interfaces

- Configure BSW modules (e.g., COM,

- Define SWCs, ports, interfaces
Key ac ons DCM)
- Map runnables
- Map signals, PDU rou ng

ARXML Processes ARXML + config to generate

Produces component descrip ons
genera on BSW code

RTE genera on No (only design) Yes

Summary:

 DaVinci Developer → SWC-level modeling

 DaVinci Configurator → Integra on + full system genera on

2. How do you handle E2E protec on in Vector tools?

E2E protec on (End-to-End protec on) ensures data integrity in safety-cri cal systems.

Configura on in Vector tools:

1. In DaVinci Configurator:

o Under COM module, enable E2E Profile (e.g., Profile 1, 2).

o Configure for relevant signals or signal groups.

o Define:

 Data ID

 Check algorithm (CRC)

 Alive counters / CRC genera on / recovery methods

 2. Code genera on:

o Vector tools generate COM wrapper func ons.

o Applica on must call E2E profile APIs before/a er signal access.

Run me behavior:

 Sender: Computes CRC, adds alive counter.

 Receiver: Checks CRC, verifies counter, detects stale/invalid data.

Used with ASIL-rated systems, especially in safety communica on (e.g., brake commands).

3. What is the role of ARXML files in AUTOSAR?

ARXML (AUTOSAR XML) files are central to the AUTOSAR toolchain and interoperability.

They define:

 So ware Component Descrip ons (ports, interfaces, runnables)

 System Descrip ons (ECU topology, mappings)

 BSW configura ons (COM, DCM, NvM, etc.)

 Communica on and Diagnos cs (PDU, signals, DIDs)

They are generated and exchanged between:

 OEM ↔ Tier-1

 DaVinci Developer ↔ Configurator

 System engineers ↔ So ware developers

ARXML is the standardized format that allows automa on, valida on, and integra on of so ware
across tools.

4. How does the configura on workflow proceed from SWC design to code genera on?

Here's the typical AUTOSAR workflow using Vector tools:

1. SWC Design (in DaVinci Developer):

o Define SWCs, ports, interfaces, runnables.

o Export component descrip on ARXML.

2. System Integra on (OEM or integrator provides):

o System ARXML: ECU topology, signal mappings, DIDs, CAN network config, etc.

3. BSW Configura on (in DaVinci Configurator Pro):

o Import component + system ARXML.

 o Configure:

 RTE genera on (connect SWC ports)

 COM, DCM, NvM, DEM, CANIF, etc.

 PDU rou ng and signal mapping

o Generate code for:

 BSW modules

 RTE

 Integra on stubs

4. Integra on and Build:

o Merge generated code with applica on code.

o Build in IDE (e.g., IAR, EB tresos, or custom toolchain).