Do we always get response for UDS request?

When we send a UDS request from a client to server, we do not get the response always. The response can be either positive or negative.

Let us consider a simple single frame unsegmented request on CAN protocol.

• In unsegmented request first byte will be always Data length in the request, followed by Service ID which is the second byte, then followed byte will be sub-function or service request related parameter bases on service ID.

• If we set the MSB bit of the third byte to "1" which means "Suppress response", then we do not get the positive response for the request.

• If we set the MSB bit of the third byte to "0", then the client is allowed to send response depending on response type.

• If the response is positive, then the client will send the response to the server.

• If the response is negative, then the client will send the response to the server only if it is a physical request. For functional requests client may send the negative responses to the server or may not.

The client may send response to the server before changing its state or after changing its state.
For example If we request programming request to client then client will change its state from Normal mode to Programming session mode. When it enters to Programming session, it sends response.
The response data contains timing parameters of the session. Server applications usually do not know about Programming session timing parameters which lies in Boot software. So it is the responsibility of boot software to send the response for programming request to the client.

Difference between constant pointer and pointer to constant

Constant pointer:

Declaration:
int *const ptr = &m;
Note: Apply the keyword from right to left.
Explanation: "ptr" is a constant pointer because keyword "const" will have higher precedence then "*" symbol.
Significance: The value of address can not be changed.
Example: ptr = &n; is not allowed because the memory location which "ptr" is pointing to, can not be changed.
Value or Data at address location can be changed.
Example: *ptr = 20.
Data at "*ptr"  has been modified to 20.

Pointer to constant.

Declaration:
int const *ptr = &m;
Note: Apply the keyword from right to left.
Explanation: "ptr" is a pointer which is pointing to constant integer data.
Significance: The value or data where pointer is pointing to, can not be changed.
Example:
*ptr = 20; is not allowed but "ptr = &n" is valid.

Interview Questions on Controller Area Network

1) What is CAN(Controller Area Network)?

Ans: Controller Area Network(CAN) is a serial communication protocol originally developed by Robert Bosch for exchanging informations between Electronic Control Units(ECU) connected in a vehicle together.


2)Why CAN is having terminating resistance of 120ohms at each end?

Ans: Controller Area Network(CAN) uses 120 ohms of resistances at each end to match the network impedance. When network resistance matches with the terminating resistance then there will not be any reflections in the network according to Maximum Power Transfer Theorem. Whatever the voltage level sends by CAN node will be completely delivered to the terminating load(Resistance).

Let us take the case of CAN does not have 120 ohms terminating resistance. If a CAN node wants to send consecutive bit sequence of 101. For 1(Recessive)bit, CAN transceiver maintains 2.5V across each CAN High and CAN Low. For 0(Dominant)bit, CAN transceiver maintains 3.5V on CAN High and 1.5V on CAN Low. If there is reflection because of improper terminating resistance then they there will be reflection on network line.

In case of dominant bit(0), the CAN transceiver feedback line will read intermediate voltage rather than 3.5V on CAN High and 1.5V on CAN Low. This leads to CAN bit error because, CAN transceiver expects same voltage on feedback line as maintained by the CAN transceiver for sending out a bit.

3)Why Controller Area Network is an asynchronous communication protocol?

Ans: Controller Area Network(CAN) does not use of external clock signal for data transmission. Synchronization between transmitter and receiver is being done by falling edge of CAN line .i.e from recessive bit(1) to dominant bit(0).

4) Explain Controller Area Network(CAN) standard frame bit fields?

The meaning of the bit fields are:

• SOF(Start of Frame):–The single dominant start of frame (SOF) bit marks the start of a message, and is used for synchronization between transmitter node and receiver node. SOF will be always from Recessive bit to Dominant bit which makes the falling edge.Whenever CAN node sees falling edge then controller adjusts its clock for incoming signal.

• Identifier-The Standard CAN 11-bit identifier establishes the priority of the message. The lower the binary value, the higher its priority. These 11 bit identifier is used for arbitration.

• RTR–The single remote transmission request (RTR) bit is dominant (0) for data frames and recessive (1) for remote request frames.

• IDE–A dominant single identifier extension (IDE) bit means that a standard CAN identifier with no extension is being transmitted. This bit is used to maintain backward compatibility between extended CAN and Standard CAN frame.

• r0–Reserved bit(Reserved for future expansion).

• DLC–The 4-bit data length code (DLC) contains the number of bytes of data being transmitted.

• Data–Up to 64 bits of application data may be transmitted.

• CRC–The 16-bit (15 bits plus delimiter) cyclic redundancy check (CRC) contains the checksum (number of bits transmitted) of the preceding application data for error detection.

• ACK–Every node receiving an accurate message overwrites this recessive bit in the original message with a dominate bit, indicating an error-free message. When a receiving node detect an error then leaves this bit recessive, it discards the message and the sending node repeats the message after rearbitration. In this way, each node acknowledges (ACK) the integrity of its data. ACK is 2 bits, one is the acknowledgment bit and the second is a delimiter.

• EOF–This end-of-frame (EOF), 7-bit field marks the end of a CAN frame (message) and disables bit-stuffing, indicating a stuffing error when dominant. When 5 bits of the same logic level occur in succession during normal operation, a bit of the opposite logic level is stuffed into the data.

• IFS–This 7-bit interframe space (IFS) contains the time required by the controller to move a correctly received frame to its proper position in a message buffer area.



5)If there is only one node on the bus and it is transmitting messages on the bus continuously, what will happen? will node go into the bus-off state or what happens?

Ans: Since there is only one CAN node on the bus, and it transmits messages on the bus continuously, since there is no other node for receiving the CAN messages in the above case,always there is an Acknowledgement error and the node will continue to retransmit the frame until it receives an acknowledgement. Obviously there is no receiver on the bus, no acknowledgement,Error Frames are transmitted on the Bus and finally the CAN transmitter node goes into Bus-off State ans stops transmitting messages until next reset.



6)If there are only two nodes on the bus, and both are transmitting same identifier(exactly the same identifier),who will win the arbitration or what happens?

Ans: If two nodes try to transmit a message with same identifier then both nodes access the network because there will not be any conflicts between two nodes. Both nodes think that it is transmitting message. If the data filed in any of the nodes differ then there will be bit error set by a node,  which tries to send recessive bit, Once it detects an error frame then it stops transmitting message on the network. Node will again try to re transmit the message once the network is idle.



7)Is CAN full duplex?

Ans: CAN is not full duplex. It is a half duplex communication system because it either transmits or receives a message. It can not do both transmission and reception at a time. Like full duplex RS232 communication system CAN does not have dedicated transmission and reception line. Same line(s) is(are) being used for both transmission and reception based on physical layer.

8) What is the use of Interframe space in CAN?
Ans: IFS– 7-bit interframe space (IFS) contains the time required by the controller to move a correctly received frame to its proper position in a message buffer area.

9) What will happen if an ECU configured for 500Kbps and ECU configured fir 1Mbps, are connected to the same CAN bus and starts communication?
Ans: Communication will stop. Node will go to bus off state. Which node will first enter into bus off state depends on which controller tries to transmit more number of messages. When there are different baud rates, there will not be synchronization between nodes, both nodes will not understand each other. Node will acknowledge each other for the messages sent. Which keeps incrementing Error counter. Eventually will reach busoff  state and Stops communication. 

Diagnostic Fault Code or Diagnostic Trouble Code

As the complexity and feature in a car or truck increases, it is very difficult for someone especially mechanic or service person to identify the problem. It can be mechanical problems, electrical problems and software problems etc.

To tackle this problem people have come with a nice mechanism to identify the problem that could have occurred in a truck or a car.

Each electrical component will be associated with a unique code and that will be called as either diagnostic trouble code or diagnostic fault code. Along with the diagnostic code, there will a failure type information which informs about type of the failure.

For example consider brake light and there will be a diagnostic trouble code associated with brake light. For brake light not to work, there could be many problems like, it might have happened because of open circuit, short circuit to ground or short circuit to battery or any other electrical problems. To indicate all these problem there is a failure type along with diagnostic trouble code. All the failure type detection mechanism will be implemented in software on an ECU.

If any of a diagnostic trouble code is active then this will displayed on Instrument cluster of the car and driver has to take the vehicle to service station. If service person sees the active diagnostic trouble code then he will immediately come to know about fault component and fault type. So it is very easy for him to fix the problem with a minimal time. Once he fixes the problem, he will check the diagnostic trouble code again. If it is still active even after repair then he would not have done it properly.If the diagnostic trouble code is not active then he has done it properly. So it is like two way one for the owner that service person has done it properly and other way for service person, it is very easy to diagnose the problem and fix it.

V-Cycle Development Process in Automotive System

The automotive industry is a wide range of companies and organizations involved in the design, development, manufacture, marketing, and selling of motor vehicles. It is one of the world's most important economic sectors by revenue. The automotive industry does not include industries dedicated to the maintenance of auto-mobiles following delivery to the end-user, such as auto-mobile repair shops and motor fuel filling stations.




In the Automotive industry, many companies follow different development process to improve quality, reduce cost of its product, provide best features like comfort, safety, less fuel consumption, power etc.

One of the best process that many companies have been following till now is V-cycle methodology of development process.

In an Automotive industry everything starts from customer and ends at customer because they are the one going to buy their product. So before developing a new model or product, an automotive industry analyse the market needs and ask for the customer expectations. Based on the customer expectations, industry try to develop a product with its technical competency. It also considers legal regulations into account while developing new product. and finally there should be something new in the product otherwise why will people buy a product which is is already exist in the market.

So, based on all these information and inputs, experts from the industry derive the technical requirements to achieve customer needs, meet legal regulations and add something best into new product.

The requirement derived from the experts or experienced people will have high level features and high level requirements and it does not cover too many technical details.It is complete end to end functionalities of a vehicle. For example customer needs comfort. To have very good comfort in a vehicle, company can introduce leaf suspension or electronically controlled suspension etc.. So Experts will decide which type of suspension to be used in the future vehicle to give off best comfort to the driver and also thinks about cost involved that.

There are advanced safety features like Adaptive Cruise Control, Line Keeping Support, Blind Spot Detection System etc. To realize these features, a vehicle will be having so many on board control unit(ECU) communicating with each other to exchange the  information within them. These high level requirements do not say about number of ECUs involved, module dependency etc.   

The next phase will be the development of decided feature. If the high level requirement just says ECS(Electronically controlled Suspension) to a developer, definitely developer will go mad because without any technical details developer can not implement anything. So vehicle level requirement author will try to capture all technical requirements which are necessarily required for a developer for development. 

The vehicle level requirements will have the complete end to end vehicle(Technical) requirements but, a developer can not develop everything at once. So the developer will capture ECU level requirements from end to end functional requirements . 

For Example consider a requirement of  "If driver presses accelerator pedal then engine speed shall increase". For this complete requirement there would be more than 2 ECUs involved. One ECU might read the accelerator pedal sensor signal and convert it into equivalent percentage level and transmit to other ECU to convert corresponding engine speed. So developer will develop a function to read accelerator pedal signal in one ECU and other developer will develop a function to receive the percentage accelerator value and convert this to engine speed in one more ECU. This phase is called ECU level development.

A developer will derive the ECU level detailed technical requirements from End to End vehicle level requirements(Cross functionality requirements). ECU level requirement will be have complete details about requirements, dependency with other ECUs, CAN or J1939 messages etc.

The next phase of the development cycle will be preparing software design documents from ECU level requirements. Software Design Document will have information about software architecture, modularity, Number of global variables, extern  variables used, number of functions in a module, periodicity of the module(Function)  and algorithm or flow chat design of complete software.

Software implementation will start from Software Design Document. Software implementation can follow MatLab modelling or Hand code.
Hand code can use programming languages like C or C++. It can be assembly language to some extent.

Once the software is ready then developer will perform unit testing. The objective of unit testing is to find out the bugs or issues in each module of software. It can also extends to check for redundancy in a module.
Unit testing is performed by simulating all possible values for parameters of module including boundary values.
Unit testing will also help in determining the code coverage. It can be Manual or Automated testing.

Advantages of Unit testing:

1. Issues are found at early stage. Since unit testing are carried out by developers where they test their individual code before the integration. Hence the issues can be found very early and can be resolved then and there without impacting the other piece of codes.

2. Unit testing helps in maintaining and changing the code. This is possible by making the codes less interdependent so that unit testing can be executed. Hence chances of impact of changes to any other code gets reduced.

3. Since the bugs are found early in unit testing hence it also helps in reducing the cost of bug fixes. Just imagine the cost of bug found during the later stages of development like during system testing or during acceptance testing.

4. Unit testing helps in simplifying the debugging process. If suppose a test fails then only latest changes made in code needs to be debugged.

If there are any issues in Unit testing then developer will work on it and make necessary changes on it to make it work or behave as per the requirements.

The input for unit test will be Software Design Document. The plan for unit test will come in parallel with software development. All test cases in Unit test will independent of software development methodology. 

The next step in development cycle will be Integration. In integration develops integrates all modules and will have the final executable which will be flashed on Electronic Control Unit(ECU). Once integration is done then developer performs integration testing. The objective of integration testing will be finding out issues at functional level. It also enables in finding out issues of module dependencies, data integrity, data flow and timing.
If there are any issues found in Integration testing the developer will work on those issues and make necessary changes  to make it work as per requirements.
The input for Integration test also will be Software Design Document. The plan for integration test will come in parallel with software development. All test cases in Integration test will independent of software development process and methodology.

Once the complete software is ready then developer performs Smoke test on level to check all functionality and deliver it for Component Verification.

Component Verification will be performed by verifiers and will be extensive test carried on the delivered software.
In component verification, verifiers will verify ECU level functionalities by simulating signal from other ECUs.
Component verification will also includes validation of non functional and diagnostics requirements of an ECU.
Component verification can be manual or Automation.
Input for Component verification will be ECU level requirement document. The plan for component verification will come in parallel with preparation of software of design document. All test cases in component verification will independent of software methodology and Process.
If there any issues found in component verification then verifier will report to developer then developer will analyse the issue and will make necessary changes to make it work as per requirements and re deliver the software.

The next phase of  development process will be Integration Testing. In integration testing, system verifiers will integrate all ECUs which are part of vehicle. The objective of integration testing is to validate the end to end vehicle level functionalities and finding issues related to communication between two ECUs, timing issues, Data integrity and Data flow between two or more ECUs.
System integration verification will also include validation of non functional and diagnostic requirements of vehicle.
System level testing can be manual or Automation.
Input for system integration testing will be cross functional requirement documents. Then plan for system integration verification will come in parallel with preparation of ECU level requirements.
If there are any issues found in System integration testing then verifier will report to developer. Developer will analyse the issues and will make necessary changes to make it work as per requirements and re deliver the software.

The next phase of vehicle development will be vehicle level verification. In vehicle level verification , verifier will integrate all ECUs in vehicle and validate the end to end functionalities. The objective of vehicle level verification is to validate the end to end vehicle level functionalities on vehicle, system behaviour on real time environment and finding issues if there are any.
Input for vehicle level verification will be High level functional requirement documents. The plan for vehicle level verification will come in parallel with preparation of cross functional requirements.
If there are any issues found in System integration testing then verifier will report to developer. Developer will analyse the issues and will make necessary changes to make it work as per requirements and re deliver the software.

If everything is fine the vehicle will go for certification. In certification a government official will check for legal requirement ans will assure certificate of clearance.