Skip to content

Session

An openOBD session is started on a Connection. A connection generally exists in a ticket unless specified otherwise. In a session the desired diagnostic procedure can be carried out using the available services.

Note

For development purposes it is possible to start a session on a connection without creating a ticket. In this situation the session is started using startSessionOnConnector(ConnectorId).

Session

For the purposes of this chapter, an openOBD session will be referred to as "session" unless mentioned otherwise.

Claiming a session

Once a session is created using the SessionController, it is required to be "claimed" by the client. This is done using the authenticate() service. When starting a new session using the SessionController, the SessionInfo is retrieved. The authentication_token found in SessionInfo is required to be added to the header of the gRPC calls as the bearer token to successfully "claim" the created session.
Once the session is "claimed", the session state changes from available to active. This indicates the client is currently using the session to carry out their desired diagnostic service.

Maintaining a session

Before performing services on an active session, it required to ensure that the session remains authenticated with the client implementation. The service openSessionTokenStream() allows for this. This service returns a SessionToken which is required to be updated in the header as the bearer token of the gRPC calls being made during the session. It proves the client is authenticated to the session and can carry out the services required to perform the desired diagnostic service.

Closing a session

When the desired service is carried out, finish(ServiceResult) is used to indicate the end of the session. The session state is then set to finished. ServiceResult is used to indicate the status of the performed diagnostic service during the session. Below is a detailed description of how the ServiceResult is used and why it is implemented.

Service result

During a session, if there is at least one service carried out the final result or state can be indicated using ServiceResult. This helps to indicate if the carried out service during the session was successful or not. During failures, the reason for failure can be specified allowing for a better understanding of why the service failed.

Result

The Result gives a detailed description of the service result. This shows why a service fails or is successfully thus, helping and enabling the operator to take the required action if necessary. If the result is RESULT_SUCCESS no further action is required since the service has been successfully carried out. When RESULT_FAILURE_COMMUNICATION_FAILURE is shown there some common faults that result in this situation. Some of them are listed below:

  • When there is a fault connection between the VCI and OBD socket of the vehicle.
  • When there is no communication between the communicated vehicle ECU and the session (e.g. the ECU is in hibernation mode).
  • When there are problems in the internet connection leading to high latency. This can be further investigated via connectionMonitor.

User feedback

This is useful when using UserInterface services. This allows the user to give feedback via the UI. The available options can be seen in UserFeedback. An example situation, when a service has been successfully carried out but sometimes there still some warning lights being displayed on the dashboard on the vehicle. Using the UI, USER_FEEDBACK_ASSISTANCE_REQUESTED can be used to indicate that an operator's assistance is required.