Automotive Diagnostics

  There are multiple users those need to use UDS protocol for various purposes like Garage person for fault detection, ECU manufacture for Testing activities and development purpose. Also  OEM needs  access to ECU memory for flashing purposes.   UDS services can be categorized in different groups like few services will just read some Data from memory,a few will write or update the data to memory, some will erase/update ECU sw itself , some will control Inputs outs of ECU directly.  So there are chances that any improper usage of UDS service may result in safety issues , security breaches or damage to ECU resources. Hence, it doesn't make sense to give access to all services to everyone. To achieve this UDS has designed some mechanisms like Sessions, Security Authentication, Preconditions. I hope you are aware about what a Diagnostic Session is. Please visit :  https://thevehiclediagnostics.blogspot.com/2020/01/what-is-diagnostic-session.html   if you ...

A diagnostic session enables a specific set of diagnostic services and/or functionalities in the server(s). Along with this, we need to focus on the services which are synchronized tightly with the session. Any change in the session is directly interlinked with the functionality of diagnostic services.  As these services are linked to ECU processes (like message transmission, DTC setting and fail safe actions, Security Access) along with session change, these processes need to be aligned. Session change does not have an impact on non-volatile memory.  Lets dive in-depth : Below are the services which are impacted majorly due to session changes in server.  Communication Control - 0x28 Control DTC Setting - 0x85 Response on Event - 0x86 Security Access - 0x27 Let us take an example of Communication Control service (0x28). Communication Control (0x28) service is used for enabling and disabling the normal communication and network management messages of an ECU. It is one...

 Let us see how the function of Security Access is served by Diagnostic Session.   Security is an important aspect of an UDS implementation. It is required to avoid unauthorized access to ECU. As one can control ECU functionality through usage of UDS services, it becomes vital to secure ECU from unintended or vulnerable access.  Hence UDS has provisioned a special service called Security Access SID 0x27 to authorize a user.It works on the principle of Seed and key mechanism. You can get lot many websites explaining how security service works. The intention of this write up is to know how session is important for the implementation of security of an ECU. As mentioned in the blog (https://thevehiclediagnostics.blogspot.com/2020/01/what-is-diagnostic-session.html )  a diagnostic session of an ECU is a timed window. Session management helps in following manner for security 1 . Limit a secured access for timed window i.e session. 2 . End se...

We have seen a concept of P2 Timer and P2 * Timer in the blog – https://thevehiclediagnostics.blogspot.com/2020/01/diagnostic-session-function-1-maintain.html So it is time to know how Service $ 10 – Diagnostic Session Control is having on a function related to these timers. Session Layer requirement Overview of P2 Timer :   P2 timer and P2 * timer are mentioned as a performance parameters    Standard values for these parameters are defined in ISO 14229 Part -2   But an ECU may change these timings in non-default sessions and Client needs to adapt them dynamically (some conditions are applicable). Explanation : Though there is defined value of P2 timer, this timing can be still improved. As these are marked as performance requirement, if the ECU can give better performance, then these timings can be reduced. ECU can change these values in non-default session as per the performance.         ...

Support Session layer requirements of OSI layer requirement   specifies the timings related requirements for Client and Server. There are timers called P2 and P2 * for both (client and server) to be followed. Let us see what is P2 timer? A communication is a series of requests and responses. Request is sent by Client and response is sent by Server. So when a client sends a request it needs to wait for a response from server Have we ever thought how much time it shall wait till the response come. What it if waited but never received a response ? These are a few example of scenarios where communication does not go as expected. But definitely these things are taken care while designing the protocol and we need to know how.       So the question is Why server needs to wait and for how much time it needs to wait ? Is there any limit for that ? Yes there is a limit and client will wait as per the defined limit. But this does not answer the question co...

Maintain Connection-Oriented Communication Whenever ECU is awake and ready to process any message on CAN , it can also process a diagnostic message.  So we do not need any special connection establishment for starting the Diagnostic Communication. But we need to maintain a Diagnostic  Communication Link between client and server when we need it for longer time till our purpose is not served.  Going ahead , we will see what does it mean.  There are two use cases of Session Management : Diagnostic Connection: When Client is connected to server, the server has to notify the client that it is connected to the server and diagnostic communication is not yet finished. The need of this feature is in the power management of the Server ECU . Server ECU will be in  wake up state during the diagnostic communication and shall not go to sleep while communication is going on. Also it shall not remain in wake up  state unnecessarily if no more diagnos...