Questions and answers

What version of the standard has been used?

The code was originally written based on ISO-14229:2006. Some addition from the 2013 and 2020 version has been added, but not exhaustively.

How reliable is this code?

To the best of my knowledge, quite good. This project comes with a fair amount of unit tests, many based on examples proposed in the UDS standard document. Every service encoding/decoding is unit-tested.

The project is fully type-hinted and passes static type check using the mypy module

Only a few common services have been tested on a real ECU by the author, but many users are using the library successfully, including some major OEM.

Why is there unimplemented services?

One of these reasons:

The actual synchronous client doesn’t support it.

The ratio of “service usage in the industry” over “the amount of work necessary to implement it” is too poor.

The service has been added in the 2020 version and I haven’t taken the time to implement it.

As for the client capabilities, I am aware that the single-request/single-response mechanism of the actual client is limiting. I believe it is enough to handle the majority of today’s use-cases. I may work in a future version for a more sophisticated client that will have message queues for each service with callback and everything, therefore allowing asynchronous services such as ResponseOnEvent or ReadDataByPeriodicIdentifier

I have a CAN transceiver, how do I use this project now?

This project is not all you need; you need to create a path for the data to reach your CAN box.

Under Linux, if your CAN box is supported by SocketCAN, you should have a new network interface after plugging in the device. Compile and install this module, then find out what CAN IDs are used for diagnostics and use the SocketConnection or IsoTPSocketConnection

If you do not want to rely on SocketCAN, you can use PythonIsoTpConnection. This connection will make usage of Python’s can-isotp module which can be coupled with python-can to access the CAN layer. The main advantage of doing this is that python-can supports many can interface, both under Windows and Linux. Unfortunately, the transport layer (IsoTp) implementation needs to be in the user space, which usually fails to meet the protocol timing requirements. Most of time, this is not an issue.

If you can’t use any of the above solution, you will need to write your own Connection class that handles everything from the transport protocol (IsoTP) to the hardware which means interacting with the drivers. See Defining a new Connection

What is the DTC mirror memory?

A mirror memory is an optional feature that a UDS server can offer. It’s a snapshot of a specific memory section that is frozen in time. Interacting with this mirror memory avoids race conditions such as a DTC status changing while reading its value.

The client may ask the server to copy the mirror memory or erase it by calling a routine or writing a data identifier. The implementation is ECU manufacturer specific.

What makes a DTC permanent?

Some diagnostic trouble codes are severe and can only be removed by the manufacturer. A permanent DTC is stored in a non-volatile memory and cannot be cleared with a common test tool or by removing power on the ECU.

How can I contribute?

Create a Github issue, fork the project, propose a pull request and I will review it; that’s the best way.

My IsoTPSocketConnection raises an error after updating udsoncan

With a breaking change of the isotp v2 socket module, it was necessary to change the signature of the IsoTPSocketConnection. The change has been carried in v1.21.2. It is not possible to pass rxid and txid parameter. A full isotp.Address must be provided.

# Before 1.21
IsoTPSocketConnection('vcan0', rxid=123, txid=456)

# After 1.21
IsoTPSocketConnection('vcan0', isotp.Address(isotp.AddressingMode.Normal_11bits, rxid=123, txid=456))