Skip to main content

What is a "Diagnostic Session"


 

What is a session  ?


Before we move to any service in the UDS we need to know a concept called Session.
  
The literal meaning of session in English is “A period devoted for particular activity’.

It perfectly matches with the meaning of session in diagnostic functionality as well.
Along with this, there are many more aspects which make session very important.

As I mentioned in my blog : https://thevehiclediagnostics.blogspot.com/p/blog-page_8.html

We have multiple use cases of diagnostics and to serve these purposes we exchange multiple diagnostic services.

It is important to consider below factors while performing a Diagnostics Communication:

  • ü Maintain Connection-oriented Communication: Opening and closure of Diagnostic Link for communication. Time out and extension of diagnostic communication.
  • ü Support Session layer requirements of OSI layer.
  • ü Security and authorization of the user – Use of Seed and Key for authenticating user
  • ü Safeguard the easy access ECUs memory, IO or SW, Purpose of Communication – Permission of executing critical services if authorized to do so.
  • ü Function oriented access to Services – Permission to execute grouping of services as per the generalization or specialization purposes.
  • ü Synchronize Diagnostic processes with  ECU’s primary functionalities. e.g when ECU is in Programming Activity it does not set DTCs.


To address all these factors many services work together in UDS. The basic one is Diagnostic Session Control -SID 0x10    

A Session can be defined as a diagnostic connection existing between the sender and receiver for defined time period (until extended) and providing access to defined services of UDS as per the type of session.

          So, to simplify the definition, 
  • Session is time bound connection
  • Session provided access to different services.
  • Session can be changed
  • Session can be extended
  • Session ends if not extended
  • Session can be terminated
  • Session can be of multiple types
Let me clarify more :
  • Session is time bound connection of S3 time 
  • Session provided access to different services - refer ISO 14229-1 Services allowed in each session
  • Session can be initiated and changed with the help of a Diagnostic service $10 - Diagnostic Session Control
  • Session can be extended and terminated by sending or stopping a Diagnostic Service $ 3E   Tester Present
  • Session can be of multiple types :  
                      1. Default Session
                       2. Extended Session
                       3. Programming Session

  On top of this, each OEM provides support of different sessions to serve different functionalities.

 Session does not effect ECUs Primry Funcrtionality :

 So ECUs operating cycle will revolve around above mentioned three sessions. The word “operating cycle” instead of “Diagnostic communication cycle” is used deliberately because ECU can enter these sessions while it performing its basic functions. So ECUs normal functionality shall not be impacted due to session change until; it is forced to change by a diagnostic service itself.e.g Service $ 28 can stop normal application message transmission of ECU and has a huge impact on the ECUs primary function. But reading a DID in any of the session doews not impact ECUs any primary function.

We will see how the "Maintain Connection-oriented Communication " is are handled my Diagnostic Session Control Service in next write - up.


Comments

Post a Comment

Popular posts from this blog

What is a Diagnostic Communication

Diagnostic Communication : Diagnostic Communication is base of Automotive Diagnostics . It is an  exchange of Diagnostic messages between an two entities. Those could be two , ECUs or ECU and  Tester Application.or it could be a group of ECUs and a tester application    The basic components of the diagnostic communication are : A Diagnostic Message :   It could be of these types -  1. A Request 2. A Response  3. A Negative Response Code Diagnostic Address :  1. Functional 2. Physical  Diagnostic Protocol : 1. UDS 2. J1939 3. KWP 2000 etc. Supporting Protocols :  1. CAN 2. Ethernet 3. K-line ,etc What is  Diagnostic Protocols ans supporting Protocols   ?  ECUs and tester communication are connected to each other by physical or wireless media. They exchange messages (requests and responses) over that physical or wireless channel. It is same as we connect to each other over internet or phone...
1 comment
Read more

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 ...
Post a Comment
Read more

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

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.         ...
Post a Comment
Read more