# Diag in Rust

this is library, that is supposed to convey asynchronous communication via CAN bus.

Note that some of the libraries are unoptimized and could resolve into downloading up to a multible gigabites of data.

## Structure of project:

Basic CLI app for sending and receiving UDS messages in diag-cli folder.

UDS library with examples in uds-rs.

The basic usage of the uds-rs app in the diag app in src folder.

Odx-parser folder houses odx-parser, as well as GetDatabase derive macro

For more in-depth documentation refer to the readmes in the folders and documentation.

## Setup

Here are some useful information about how to operate with can as well as some observations about VW and ISO standards

Virtual CAN:

    sudo modprobe can
    sudo ip link add dev vcan0 type vcan
    sudo ip link set up vcan0

message to the CAN can be sent using can-utils 

    cansend vcan0  123#DEADBEEF

message to the isotp-can can be sent using

    isotpsend -s 0x123 -d 0x321 vcan0

message from isotp-can can be received using

    isotprecv -s 0x234 -d 0x322 vcan0 -l

Message is passed via stdin. Hex values separated by spaces, ended by EOF (ctrl+D)
    
When communication with BOSH parking ECU the CAN needs to be set up with command:

    sudo ip l set dev can0 up type can bitrate 500000

ECU listens for request on CanID 0x774 and sends responds to CanID 0x704.

Here are few examples, how to communicate with ECU using isotpsend and isotprecv

    isotpsend -s 0x70A -d 0x774 can0

Possible message: 22 25 2D 55 55 55 55

    isotprecv -s 0x70A -d 0x774 can0 -l
    
Possible response: 62 25 2D 9C (response is padded with 0xAA bytes)

The request in send needs to be padded with 0x55 bytes, otherwise the ECU will not respond.

Useful request messages for working with Bosh parking sensor:

To get long response (multiple CAN frames) use following: 0x22, 0xf1, 0x8a (padded it looks like this: 0x22, 0xf1, 0x8a, 0x55, 0x55, 0x55, 0x55)

Error response [7f, 22, 78] (correctly received, busy, ask later, but later same response). Request: 0x22, 0xf1, 0x8c,


## Notes

When writing documentation for an API is cumbersome, it means that the API is poorly written.

# Observed differences between ISO UDS and VW80124 standard:

## TLDR 

| Service                     | What Changes                                                                 | Difference VW/ISO                   | VW80124:2010-06 reference | ISO 14229-1:2013(E) reference | 
|-----------------------------|------------------------------------------------------------------------------|-------------------------------------|---------------------------|-------------------------------|
| 0x19 - Read DTC information | DTCMaskRecord parameter                                                      | size 1byte/3byte                    | page 67, \[VW80124-3114\] | page 190, Table 257           | 
| 0x19 - Read DTC information | Highest bit of DTCInformationType parameter                                  | in VW bit7 suppresses pos. response | page 67, \[VW80124-3114\] | page 190, Table 257           |
| 0x19 - Read DTC information | DTCExtendedDataRecordNumber parameter                                        | size 3byte/1byte                    | page 67, \[VW80124-3114\] | page 191, Table 259           | 
| 0x11 - ECU reset            | Highest bit of ResetType parameter                                           | in VW bit7 suppresses pos. response | page 27, \[VW80124-960\]  | page 43, Table 33             |
| 0x19 - Read DTC information | VW does not provide response structure for 0x1 ReportNumberOfDTCByStatusMask | in VW not specified/present in ISO  | page 67, \[VW80124-3165\] | page 200, Table 271           |

## READ_DTC_INFORMATION

Iso allowes 27 subfunctions. VW only 5 - 0x1, 0x2, 0x4, 0x6 0xE. (0x4 is only allowed during developement in debug session 0x4f)

However even these subfunctions are not 1:1 compatible.  
**DTCMaskRecord** has length of 3 bytes in ISO and only 1 byte in VW  
**DTCExtendedDataRecordNumber** has length of 1 byte in ISO and 3 bytes in VW
