CANoe Tool Questions:

01. What is difference the between IG and G block in CANalyzer/CANoe tool?

Answer: There are two limitations to the Generator block that limit its effectiveness in complex tasks. The block is misleading for some people because it requires multiple windows for setting up the transmit message list. The second problem is the block settings have to be set before the CANalyzer measurement starts. No changes can be made if the measurement is running.

Fortunately, CANalyzer has another transmission block that eliminates both practical limitations: the Interactive Generator block (IG). The IG block combines the configuration windows of the Generator block into one window; therefore, everything can be setup in one spot. In addition, changes can be made with the IG.

Without CAPL,can we simulate the other ECU’s CAN Messages except Test ECU in the CAN Simulation Network in CANoe tool without using IG or G blocks.

02. How to change the baud rate in CANoe without changing the code?

The bit rate may be changed by either changing the oscillator frequency, which is usually

restricted by the processor requirements, or by specifying the length of the bit segments in “time quantum” and the prescaler value.

In Canoe tool, we can change the bus timing register 0 & 1 values for correcting the baud rate.

In Autosar, we can use post build configuration for CAN baudrate values.

03. What is environment variable?

Environment variables are data objects global to the CANoe environment and are used to link the functions of a CANoe panel to CAPL programs.

04. What is HIL and SIL testing?

Answer: Hardware-in-the-loop (HIL) simulation is a technique that is used in the development and test of complex real-time embedded systems. HIL simulation provides an effective platform by adding the complexity of the plant under control to the test platform. The complexity of the plant under control is included in test and development by adding a mathematical representation of all related dynamic systems. These mathematical representations are referred to as the “plant simulation”. The embedded system to be tested interacts with this plant simulation.

Hardware-In-the-Loop System is an effective platform for developing and testing complex real-time embedded systems. HIL system provides the complexity of the plant under control using mathematical representation, called “plant simulation”, of all related dynamic systems. It also includes electrical emulation of sensors and actuators which act as the interface between the plant simulation and the embedded system under test.

Advantages of HIL System

Provides Cost Savings by Shortened Development time
Complete, consistent test coverage.
Supports automated testing
Enables testing the hardware without building a “plant prototype”
Simulator performs test outside the normal range of operation
Supports reproducible test runs that can assist in uncovering and tracking down hard to find problems.
Enables testing with less risk of destroying the system

SIL: SIL refers to the kind of testing done to validate the behavior of the C-code used in the controller. That code can be auto-generated from the model used in algorithm development. Emmeskay has a deep understanding of SIL testing and auto-code generation from the many SIL projects we have performed for our customers.

Testing and Validation

Plant model developed in vehicle simulation environment is imported to Simulink as a library.
Controller is tested in loop with the plant for different routes and speed profiles.
Controller is tested for different fault modes of the system using GUI VisualConnex

RTOS Question:

What is RTOS?

Real-Time Operating System is a multitasking operating system intended for real-time applications. It is used on every device/system needing real time operations that means operations based not only on correctness but also upon the time (clock cycles) in which they are performed.

In general, an operating system (OS) is responsible for managing the hardware resources of a computer and hosting applications that run on the computer. An RTOS performs these tasks, but is also specially designed to run applications with very precise timing and a high degree of reliability. This can be especially important in measurement and automation systems where downtime is costly or a program delay could cause a safety hazard. To be considered “real-time”, an operating system must have a known maximum time for each of the critical operations that it performs (or at least be able to guarantee that maximum most of the time). Some of these operations include OS calls and interrupt handling. Operating systems that can absolutely guarantee a maximum time for these operations are commonly referred to as “hard real-time”, while operating systems that can only guarantee a maximum most of the time are referred to as “soft real-time”.

Example: Imagine that you are designing an airbag system for a new model of car. In this case, a small error in timing (causing the airbag to deploy too early or too late) could be catastrophic and cause injury. Therefore, a hard real-time system is needed; you need assurance as the system designer that no single operation will exceed certain timing constraints. On the other hand, if you were to design a mobile phone that received streaming video, it may be ok to lose a small amount of data occasionally even though on average it is important to keep up with the video stream. For this application, a soft real-time operating system may suffice. An RTOS can guarantee that a program will run with very consistent timing. Real-time operating systems do this by providing programmers with a high degree of control over how tasks are prioritized, and typically also allow checking to make sure that important deadlines are met.

How Real-Time OSs Differ from General-Purpose OSs?

Operating systems such as Microsoft Windows and Mac OS can provide an excellent platform for developing and running your non-critical measurement and control applications. However, these operating systems are designed for different use cases than real-time operating systems, and are not the ideal platform for running applications that require precise timing or extended up-time. This section will identify some of the major under-the-hood differences between both types of operating systems, and explain what you can expect when programming a real-time application.

Interrupt Latency

Interrupt latency is measured as the amount of time between when a device generates an interrupt and when that device is serviced. While general-purpose operating systems may take a variable amount of time to respond to a given interrupt, real-time operating systems must guarantee that all interrupts will be serviced within a certain maximum amount of time. In other words, the interrupt latency of real-time operating systems must be bounded

Unanswered Interview Questions If you know comment as reply)

What is the use of Passive error node?

Error Passive receivers can no longer interrupt the data transfer as a recessive Error Flag does not influence the bus levels. An Error Passive transmitter can still interrupt its own message by sending a passive Error Flag. Attention, if one Receiver is in error passive mode no data consistency is guaranteed any more.

How to find the bug in code using debugger if pointer is pointing to a illegal value?

If two CAN messages with same ID sending at a same time, different data which can node will gain arbitration? How to test it?

Is it possible to declare struct and union one inside other? Explain with example