Skip to main content

Diagnostic Session : Function 2 - Part 1- Support Session layer requirements of OSI layer

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 completely.

We need to go deeper to know the what are these limits. The limits are labelled as "P2 time" and set to a values considering the Transmission delay and Processing time.

Transmission delay is caused due to many factors like gateway, arbitration process, etc

Processing time is the time taken by ECU to make the response contents ready for sending. Processing time depends upon the service which is under process and availability of ECU resources to accomplish the process.

Let us see P2 time and timer in detail -

The time limit is refereed as P2 time and the timer maintained for this purpose is called P2 timer. It exists for Server and named as P2 server. It exists for client and named as P2 Client. 


So do watch below video to explore what is P2 server and P2 client Time and timer :





We will explore the answer to this question in next blog. 


Before answering to the question let us see why this situation will come when ECU will not reply in that time.  Diagnostic services are of different types. When a service is being processed by server as requested by Client it needs to perform various actions. For some of the actions it may take more time. e.g for Erasing a memory or writing a memory or disabling an output or computing a value. 
So ECU can start processing a request and that process is not likely to be completed in P2 Server time then ECU needs to inform that to the client. This is done with the usage of NRC 0x78. 
   
Please refer below video how it works. 
      

Comments

Popular posts from this blog

What is UDS on CAN or Diagnostic on CAN ?

OSI Model and Diagnostics : OSI model has 7 layers and each layer has defined functionality. To understand this you can refer this excellent IEEE  publication. It explains OSI Model for CAN , Ethernet, flexray and MOST.  External reference : http://www.ieee802.org/1/files/public/docs2013/new-tsn-diarra-osi-layers-in-automotive-networks-0313-v01.pdf   So let us understand,  what is this UDS on CAN  ? When a Diagnostic Message formatted  as per ISO 14229 -1 i.e UDS Standard is sent over Controller Network we say Diagnostics Communication is happening as per UDS on CAN. So as per this : Below layers participate in Diagnostic Communication Over CAN :  1. Application Layer :  ISO 14229-1:2013 ROAD VEHICLES — UNIFIED DIAGNOSTIC SERVICES (UDS) — PART 1: SPECIFICATION AND REQUIREMENTS  ISO 14229-3:2012 ROAD VEHICLES — UNIFIED DIAGNOSTIC SERVICES (UDS) — PART 3: UNIFIED DIAGNOSTIC SERVICES ON CAN IMPLEMENTATION (UDSON...

Diagnostic Session : Function 5 - Session Oriented Access to Services

  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 ...

Diagnostic Session : Function 4 - Synchronize different Diagnostic Processes.

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...