autosar dem interview questions

Interviewing for a job in the Autosar domain can be a challenging and daunting task. There is a lot of competition, and the interview questions can be hard to prepare for. Luckily, this blog post is here to help. It will provide a list of common Autosar Dem interview questions and tips on how to answer them effectively. Autosar Dem is the acronym for Automotive Open System Architecture, a software platform for developing electronic control units in cars. It is a complex, technical system and applicants must have a good working knowledge of it to be successful in their interviews. This blog post will provide an overview of the Autosar Dem platform and offer insight into what to expect during an interview. It will also provide useful tips on answering Autosar Dem interview questions so you can ace your interview and land the job.

• Question 1. What Is Autosar? Answer : …
• Question 2. What Is Swc? …
• Question 3. What Is Can And Its Uses? …
• Question 4. What Are The Can Frame Works? …
• Question 5. Why Can Is Having 120 Ohms At Each End? …
• Question 6. Why Can Is Message Oriented Protocol? …
• Question 7. Can Logic What It Follows? …
• Question 8. What Is Can Arbitration?

Interview Questions on AUTOSAR

Interviews for Top Jobs at Valeo

AUTOSAR Developer Interview

AUTOSAR DEM Module : Diagnostic Event Manager (DEM) is part of service layer of AUTOSAR architecture. DEM module is responsible for

SWCs communicate with DEM module through RTE, using Client Server port or Sender receiver port. SWC communicates to report status of event to DEM and DEM reads data from SWCs to collect snapshot data. DCM module communicates with DEM and vice versa using AUTOSAR interface to read Diagnostic information (i.e. Service No. 19 Read DTC status or Read Snapshot data). DEM communicates with NVM using AUTOSAR interface. DEM uses NVM to read and write diagnostic information into memory. Other BSW modules communicates to DEM module to report BSW event status whether event is passed or failed.

Automotive electronic control units (ECUs) are created and established using the AUTOSAR ECU software architecture. Its objectives include adaptability to various vehicle and platform variations, software portability, consideration of availability and safety standards, cooperation between different partners, sustainable resource use, and maintainability throughout the entire product lifecycle. To encourage standardization in the software development process for automotive electronic control units (ECUs), the AUTOSAR Architecture was introduced.

ComStack stands for Communication Stack. The Communication Stack, or ComStack, in the AUTOSAR layered architecture facilitates vehicle network communication. In other words, ComStack can be described as a software stack that offers communication services to application Layer/application Software and basic software modules. A component of the BSW (Basic Software) is the AUTOSAR Communication Stack.

In order to handle more complicated electrical and electronic systems in a vehicle, such as simple integration, switching the functions within a complex engine control (ECU) network, and managing the lifecycle of the entire product, AUTOSAR is used. Additionally, it is used for microcontrollers that are intended for applications, primarily in the automotive sector, that use CAN, Flex Ray, Ethernet, etc. It is designed to use the least amount of memory possible when used in microcontroller-based applications because microcontrollers have limited memory.

In addition to blocks and constructs for Basic Software services, such as NVRAM Manager and Diagnostics Event Manager, AUTOSAR Blockset offers an AUTOSAR editor, dictionary, and blocks for creating Classic Platform and for simulating the BSW services along with your application software model. The AUTOSAR editor aids in defining the interfaces, data types, and properties of AUTOSAR software components and mapping them to already-existing Simulink models. Scaling your atomic software components to composition software components and to ECUs is possible.

Diagnostic modules brief description:

The DCM module controls the diagnostic states, particularly diagnostic sessions and security states, and ensures the flow of diagnostic data. The DCM module also determines whether the requested diagnostic service is supported and whether it can be carried out during the current session in light of the diagnostic states. The DCM module provides the OSI-Layers 5 to 7.

The DCM module offers a broad range of ISO14229-1 [15] services at OSI-level 7. Additionally, the OBD services $01 – $0A are supported by the DCM module’s mechanisms. All light duty OBD regulations (including California OBDII, EOBD, Japan OBD, and all others) can be met by AUTOSAR OBD functionality with the help of these services.

The following specifications’ network-independent sections are handled by the DCM module at OSI-level 5:

The DCM module is network-independent. The DCM module does not handle any network-specific functionality (the specifics of networks like CAN, LIN, FLEXRAY, or MOST). The PDU Router (PDUR) module gives the DCM module a network-independent interface.

A diagnostic message is delivered by the PDUR module to the DCM module. The DCM module processes and checks internally the diagnostic message. The DCM will communicate with other BSW modules or SW-Components (through the RTE) to obtain requested data or carry out requested commands as part of processing the requested diagnostic service. This processing is very service-specific. Usually, the DCM will compile the information gathered and send a message back via the PDUR module.

DCM module as consisting of the following sub modules:

Processing and storing diagnostic events (errors) and related data are the responsibilities of the service component Diagnostic Event Manager (Dem). Further, the Dem provides fault information to the DCM (e. g. read all stored DTCs from the event memory). The Dem provides interfaces to other BSW modules and the application layer.

Both the Software Components (SW-Cs) and Basic Software (BSW) modules use the Diagnostic Event Manager (Dem) to manage and store the events discovered by diagnostic monitors. The interface makes the saved event data accessible to other BSW modules or SW-Cs.

When developing and running software components and other basic software modules, the default error tracer offers functionality to support error detection and tracing. The Default Error Tracer receives and assesses error messages from these components and modules for this purpose.

A Basic Software Module of the Diagnostic Services is the Diagnostic Log and Trace (DLT). It provides a generic Logging and Tracing functionality.

One of the Basic Software Modules of the Diagnostic Services is the Function Inhibition Manager (FIM). The FiM stands for the assessment and assignment of events to the necessary software component actions (e.g. g. inhibition of specific “Monitors”).

When the event status changes, the Dem updates the Function Inhibition Manager (FiM) so that function entities can be stopped or released in accordance with assigned dependencies.

FAQ

What is DEM in AUTOSAR?

The Diagnostics Event Manager (DEM) is in charge of processing and storing diagnostic errors (events) and all related data. In addition, DEM gives the Diagnostic Communication Manager (DCM) the diagnostic trouble codes (DTC) as needed.

What is DTC in AUTOSAR?

A DTC is a distinct number that identifies at least one diagnostic event. The DEM can distinguish between OBD-relevant DTCs and other (e. g. UDS or J1939) DTCs. DTCs can also be organized by groups. AUTOSAR defines two provided groups: emission-related DTCs and all DTCs.

Which module gets notified on change in the status of an event in DEM module?

A Basic Software Module of the Diagnostic Services is the Diagnostic Event Manager (Dem). Relevant errors are reported either from Application Layer (resp. SW-C) or Basic Software Modules (BSWM). Using the Dem_ReportErrorStatus API, BSWs report the event’s updated status.

Which software used for AUTOSAR?

The industry standard for embedded real-time ECUs built on OSEK is the AUTOSAR classic platform. Its main deliverable is specifications. The architecture separates the application, runtime environment (RTE), and basic software (BSW) layers of software that operate on a microcontroller.