rnd-ash / openvehiclediag

A rust based cross-platform ECU diagnostics and car hacking application, utilizing the passthru protocol

Ashcon Mohseninia @rnd-ash

Automotive software developer at ECU.de

Creating custom ECU firmware from scratch for open-source MCUs and open source vehicle diagnostic libraries!

Social media

• LinkedIn
• Youtube
• Odysee
• Twitter
• Patreon

Coding languages

• Rust
• C / C++
• Kotlin
• Java

Talks / Presentations

• 18/02/2021 - OSSG - Open source in automotive - OpenVehicleDiag

Major Projects

• OpenVehicleDiag - Initially my thesis project for University. Open source and cross platform car diagnostics and ECU testing platform written in Rust. Supports SocketCAN and SAE J2534 API.
• ECU DIAG - A project based on OpenVehcileDiag to provide a Rust library that can be used for interfacing with VCI hardware for car diagnostics and implements both the KWP, UDS and OBD2 diagnostic protocol servers.
• Ultimate-NAG52 and Ultimate-NAG52-Config-App - A replacement Transmission controller for Mercedes' 5G-Tronic (722.6) gearbox, with full CANBUS support and supporting the CAN systems of all cars with the EGS51, EGS52 or EGS53 OEM TCUs (~1995-2012) Project youtube playlist
• Macchina-J2534 - A SAE J2534 (Passthru) API library for Macchina's M2 and A0 ODB2 adapters (With experimental Linux + OSX support)
• MB-W211-PC - My hobby project - Installing a full PC into the back of my W211, complete with a custom touch panel in the front, and daughter board that houses a custom amplifier and MCU. Works seamlessly with the cars CAN networks. Project youtube playlist

openvehiclediag's Issues

Coding

Is it possible to send data to the ecu?
I‘m talking about coding. I would like to enable/disable features e.g. coming home function for lights.

Missing something stupid? [SUPPORT]

Quite simply, OVD will recognize my Tactrix, will recognize vehicle voltage, and will say "connected" but will not trace any can data.

Tactrix works with other software (vehical), just not with OVD.

This is on Windows 11.

[FEATURE]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Linux "Requirments"

os-release: NAME="Pop!_OS" VERSION="20.10"
I tried compiling and running openvehiclediag before Macchina-J2534. I did not have rust installed, so when started to compile the first error I got was I was missing cargo. I installed cargo using get apt install. I ran into a few other issues, but then moved over to Macchina-J2534. Once there I saw the Requirements recommending installing rustup using the link. This resolved the issue.
May want to add a "Requirements" section to the ReadMe in this repo as well.

Side Note: not knowing much about rust, I watched https://youtu.be/_k-dWdNRVr0?t=318. At that time stamp I saw the compile commands.

[Checklist] Version 1.1

Checklist for Version 1.1

• Add support for BMW's .PRG parsing to JSON (WIP INPA branch)
• Add dynamic window resizing (#21)
• Update ICED GUI, including tooltips for certain functions

MILESTONE - Convert backend to ECU_DIAGNOSTICS crate

This would fix a TON of bugs with UDS functionality, and allow for loads of extra features!

Window size

I am running on an older laptop, resolution 1366x768. openvehiclediag opens larger than my screen. So I have to move the window around to get to all the functions and I cannot get to the bottom of the application.

[QUESTION] Protocol

Hello,

I have a question.

Does the "OpenVehicleDiag" tool support "UDS(Unified Diagnostic Services)" protocol?

Or, are J2534-2 protocol and UDS(Unified Diagnostic Services) the same protocol?

Thank you!

[BUG] Could not found 'read_dtc_info' in 'uds'

While compiling I'm getting following error:

error[E0433]: failed to resolve: could not find read_dtc_info in uds
--> src\commapi\protocols\mod.rs:225:34
|
225 | Self::UDS(s) => uds::read_dtc_info::read_dtc_information(s, dtc)
| ^^^^^^^^^^^^^ could not find read_dtc_info in uds

Since the update after the Youtube Livestream from 08.07.2021, I've pulled both updated files but I'm not able to compile anymore. Unfortunately I couldn't find the solution myself but I'm pretty sure, I'll verry quickly find the problem...

[Feature] Volkswagen TP2.0 transport support

Volkswagen (used to?) use a proprietary CAN transport protocol for diagnostics in the post-k-line cars, but the contents are just standard KWP2000.

Depending on how modular the code is, it may be possible since the core operation is similar to ISO-TP, just with a "connection" to keep alive on top of the KWP diag session. I have a basic implementation in my pyVCDS repository, and am willing to help with testing and implementing when I have free time, although I only have socketCAN adapters.

OVD doesn't with ValueCAN4-2

Hello,

I'm trying to use OVD with ValueCAN4-2.
Interface is correctly recognized with the pick list but when I try to do: Diagn Scanner-->Scan my car-->Start scan,
I get the answer: "could not start scanning: Battery voltage too low/ Could not read battery voltage.

There is no power supply connection on ValueCAN4 DB9 pinout, only CAN1 H/L, CAN2 H/L and 3 GND.

Regards

[BUG] ERROR code 99 (cannot located driver...

Error code 99 (cannot load driver at c:..........

Just compiled a version to run on windows from source code provided.
I am using a scanmatik passthru device.
Device appears in drop down box
When clicking "Launch OVD" i am getting the error that the smj2534.dll cannot be found at the location.
File is correct and present at the location.

Error is not present on the pre-compiled windows EXE and connection works fine.

any pointers??

Unable to build/compile on up to date AttifyOSv4 (Ubuntu 22.04)

Describe the bug
Unable to build/compile on up to date AttifyOSv4 (Ubuntu 22.04)
Possibly user error but it would be helpful to know what version environment is known to work.
Thank you for your attention!

To Reproduce
Steps to reproduce the behavior:

1. curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs/ | sh
2. sudo apt-get install libgtk-3-dev
3. git clone https://github.com/rnd-ash/OpenVehicleDiag.git
4. cd OpenVehicleDiag/app_rust
5. cargo build --release
6. See error:
   Compiling common v0.1.0 (/home/attify/attifyos/git.opt/OpenVehicleDiag/common)
   warning: unused import: collections::VecDeque
   --> /home/attify/attifyos/git.opt/OpenVehicleDiag/common/src/schema/diag/service.rs:1:21
   |
   1 | use std::{cmp::min, collections::VecDeque, convert::TryInto, ...
   | ^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(unused_imports)] on by default

warning: common (lib) generated 1 warning (run cargo fix --lib -p common to apply 1 suggestion)

Expected behavior
Want to test with Tactrix OpenPort 1.3/2.0 & Macchina M2 for Subaru Legacy 2006

Desktop (please complete the following information):

• OS: AttifyOS v4.0 updated/upgraded (Ubuntu 22.04]
• Linux attifyos 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Additional context
Wondered if https://github.com/rnd-ash/Macchina-J2534 must be compiled/installed first but this made no difference.

OS X /usr/share issues

OS X makes use of System Integrity Protection (SIP) to protect the filesystem from malicious things happening on it, so using /usr/share won't be ideal as the user has to disable SIP.

Possible fix for the Macchina driver in comms.rs is

#[cfg(OSX)]
fn get_comm_port() -> Option<String> {
    if let Ok(content) = std::fs::read_to_string(" ~/Library/Macchina/passthru/macchina.json") {
        return match serde_json::from_str::<serde_json::Value>(content.as_str()) {
            Ok(v) => v["COM-PORT"].as_str().map(String::from),
            Err(_) => None
        }
    }
    None
}

Then all we'd need to do is fix the build.sh file to look at what OS is being run and adapt accordingly

CAN message decoding

Is your feature request related to a problem? Please describe.
CAN messages are displayed in RAW format

Describe the solution you'd like
Possibility to show decoded message in human readable format

There is a database of CAN messages for many different cars here:
https://github.com/commaai/opendbc

Installation/use on Linux

Hello,
Sorry for my maybe dumb question, but how to install or use on Linux?
Should I compile/make,...?
I have no skills in Rust
Intended to use with Socketcan

Regards
Nico

Version 1.0 milestone checklist (TODO)

• Automated KWP/UDS Scan for DTC codes
• Grabbing part number over KWP for ECU identification
• Fix broken OBD implementation (Still only over ISO-TP)
• Complete all UDS SID implementations
• Add support for Global diag requests for KWP2000 (Seems to apply to only MB Interior CAN devices)
• Modify JSON format to be more similar to ODX (Categorize functions by "Adjustments", "Actuation", "Functions", and "Reading"
• Add full beta version of SocketCAN

[FEATURE] socket can support

Hi!

Thanks for this project that looks promising.

I know nothing about J2534 but this seems interesting.

I was wondering if the Linux CAN API socket can could be used in order to use any CAN adapter already compatible with Linux?

That would mean to port the J2534 part of the MacchinaM2 firmware into a new driver I think.

Is your feature request related to a problem? Please describe.
Use other CAN adapters, already compatible with Linux.

Describe the solution you'd like
A new OVD driver using Linux socket can.

I might try to dig into it so any pointer is welcomed.

[BUG] CBF parser throwing exceptions on KI171, KI209 and KI230

CBF parser is encountering problems on several cbf files for several ecus
I know there can be multiple versions of one specific cbf file, so I have tried multiple ones, for the same ecu, they all gave similar exceptions, so it should be possible to reproduce these bugs with any of the ecu's cbf files.

KI171

KI209 and KI230

[BUG] Start UDS Diag Session over J1939

I'm not able to start a UDS Diag Session to an ECU over J1939.

I'm trying to connect to a CPC4, Mercedes Off-Highway engine ECU. I tried to parse its CBF with CBF Parser but got an error (would probably be the topic of another bug).

I'm using with your great J2534 Firmware on the Macchina A0, the CAN Analyzer functionality is working perfectly.
However while trying to start a diagnostic session in the manual mode, the frame with ID 0x18DA00F1 is not appearing on the CAN.

Here below is what I get in the log. In the first line I see a baudrate of 500k, where I need 250k. In the CAN Analyzer it is possible to change the baudrate. But in the diagnostic mode?

[DEBUG] - Requesting channel open. ID: 0, Protocol: ISO15765, baud: 500000, flags: 0x0000
[DEBUG] - Write data: COMM_MSG: ID: 17 Type: OpenChannel, Args=[00, 00, 00, 00, 06, 00, 00, 00, 20, A1, 07, 00, 00, 00, 00, 00]
[M2LOG] - Standard CAN detected!
[M2LOG] - Normal ISO-TP Addressing detected!
[DEBUG] - Command took 19213us to execute
[DEBUG] - M2 opened channel!
[DEBUG] - Channel 0 writing IOCTL Param: ISO15765_STMIN. Param value: 20
[DEBUG] - Write data: COMM_MSG: ID: 18 Type: IoctlSet, Args=[00, 1F, 00, 00, 00, 14, 00, 00, 00]
[DEBUG] - Command took 8929us to execute
[DEBUG] - Channel 0 writing IOCTL Param: ISO15765_BS. Param value: 8
[DEBUG] - Write data: COMM_MSG: ID: 19 Type: IoctlSet, Args=[00, 1E, 00, 00, 00, 08, 00, 00, 00]
[DEBUG] - Command took 7899us to execute
[DEBUG] - Filter specified. Type: Mask filter, Data: [0, 0, 255, 255]
[DEBUG] - Filter specified. Type: Pattern filter, Data: [24, 218, 241, 0]
[DEBUG] - Filter specified. Type: Flow control filter, Data: [24, 218, 0, 241]
[DEBUG] - Setting ISO-TP flow control filter (ID: 0) on channel 0. Mask: [00, 00, FF, FF], Pattern: [18, DA, F1, 00], FlowControl: [18, DA, 00, F1]
[DEBUG] - Write data: COMM_MSG: ID: 1A Type: SetChannelFilter, Args=[00, 00, 00, 00, 00, 00, 00, 00, 03, 00, 00, 00, 04, 00, 00, 00, 04, 00, 00, 00, 04, 00, 00, 00, 00, 00, FF, FF, 18, DA, F1, 00, 18, DA, 00, F1]
[DEBUG] - Command took 23438us to execute
[DEBUG] - M2 set filter 0 on channel 0!
[DEBUG] - Channel 0 writing message: Protocol: ISO 15765, RxStatus: 00000000, TxFlags: 00000040, Data: [18, DA, 00, F1, 10, 03]. Response required?: false
[M2LOG] - Send frame -> 18DA00F1 (LEN: 8) [02 10 03 00 00 00 00 00]

[FEATURE] Extract TesterID and EcuID from smr-d

Is your feature request related to a problem? Please describe.
Currently, SMRParser does not extract that much informations. It can extract some metadata and included files but it lacks of some information like Tester ID, ECU ID, st_min, blocksize...

Describe the solution you'd like
I would like to be able to get at least the Tester ID and Ecu ID from the smr-d file.

Thank you,

NPM build fails on OS X

cargo build --release && napi build --release

Updating crates.io index
Updating git repository `https://github.com/napi-rs/napi-rs`

Downloaded num-traits v0.2.14
Downloaded num-bigint v0.2.6
Downloaded autocfg v1.0.1
Downloaded serde_derive v1.0.117
Downloaded num-rational v0.2.4
Downloaded lazy_static v1.4.0
Downloaded libc v0.2.80
Downloaded bitflags v1.2.1
Downloaded serde_json v1.0.59
Downloaded libloading v0.6.5
Downloaded num v0.2.1
Downloaded itoa v0.4.6
Downloaded num-iter v0.1.42
Downloaded unicode-xid v0.2.1
Downloaded num-complex v0.2.4
Downloaded cfg-if v1.0.0
Downloaded num-integer v0.1.44
Downloaded quote v1.0.7
Downloaded ryu v1.0.5
Downloaded syn v1.0.48
Downloaded num-derive v0.3.3
Downloaded proc-macro2 v1.0.24
Downloaded serde v1.0.117
Downloaded 23 crates (1.4 MB) in 1.34s
Compiling autocfg v1.0.1
Compiling proc-macro2 v1.0.24
Compiling unicode-xid v0.2.1
Compiling syn v1.0.48
Compiling serde_derive v1.0.117
Compiling ryu v1.0.5
Compiling serde v1.0.117
Compiling serde_json v1.0.59
Compiling bitflags v1.2.1
Compiling itoa v0.4.6
Compiling cfg-if v1.0.0
Compiling libc v0.2.80
Compiling napi-sys v0.4.7 (https://github.com/napi-rs/napi-rs#68017ce2)
Compiling lazy_static v1.4.0
Compiling num-traits v0.2.14
Compiling num-integer v0.1.44
Compiling num-bigint v0.2.6
Compiling num-rational v0.2.4
Compiling num-iter v0.1.42
Compiling num-complex v0.2.4
Compiling napi-build v0.2.1 (https://github.com/napi-rs/napi-rs#68017ce2)
Compiling libloading v0.6.5
Compiling ovd v0.1.0 (/Users/daniel/Documents/Car Pwnage/OpenVehicleDiag/app)
Compiling quote v1.0.7
Compiling num v0.2.1
Compiling num-derive v0.3.3
Compiling napi-derive v0.5.1 (https://github.com/napi-rs/napi-rs#68017ce2)
Compiling J2534Common v0.1.0 (/Users/daniel/Documents/Car Pwnage/OpenVehicleDiag/MacchinaM2-J2534-Rust/J2534Common)
Compiling napi v0.5.1 (https://github.com/napi-rs/napi-rs#68017ce2)
warning: crate J2534Common should have a snake case name
|
= note: #[warn(non_snake_case)] on by default
= help: convert the identifier to snake case: j2534_common

warning: 1 warning emitted

warning: unused imports: Error, JsFunction, JsString, JsUndefined, Status
--> src/lib.rs:6:33
|
6 | use napi::{CallContext, Result, JsString, Status, Error, JsUnknown, JsFunction, JsUndefined, Module, JsNumber};
| ^^^^^^^^ ^^^^^^ ^^^^^ ^^^^^^^^^^ ^^^^^^^^^^^
|
= note: #[warn(unused_imports)] on by default

warning: unused import: serde_json
--> src/lib.rs:8:5
|
8 | use serde_json;
| ^^^^^^^^^^

warning: unused import: TryInto
--> src/lib.rs:11:20
|
11 | use std::convert::{TryInto, TryFrom};
| ^^^^^^^

warning: unused import: Symbol
--> src/passthru.rs:4:27
|
4 | use libloading::{Library, Symbol};
| ^^^^^^

warning: unused import: J2534Common::PassthruError::ERR_FAILED
--> src/passthru.rs:22:5
|
22 | use J2534Common::PassthruError::ERR_FAILED;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0369]: binary operation == cannot be applied to type J2534Common::FilterType
--> src/passthru.rs:308:24
|
308 | if filter_type == FLOW_CONTROL_FILTER && flow_control == None {
| ----------- ^^ ------------------- J2534Common::FilterType
| |
| J2534Common::FilterType

error[E0369]: binary operation == cannot be applied to type std::option::Option<&J2534Common::PASSTHRU_MSG>
--> src/passthru.rs:308:63
|
308 | if filter_type == FLOW_CONTROL_FILTER && flow_control == None {
| ------------ ^^ ---- std::option::Option<_>
| |
| std::option::Option<&J2534Common::PASSTHRU_MSG>

error[E0308]: mismatched types
--> src/passthru.rs:313:13
|
312 | let p_msg = match pattern {
| ------- this expression has type &J2534Common::PASSTHRU_MSG
313 | None => std::ptr::null() as *const PASSTHRU_MSG,
| ^^^^ expected struct J2534Common::PASSTHRU_MSG, found enum std::option::Option
|
= note: expected struct J2534Common::PASSTHRU_MSG
found enum std::option::Option<_>

error[E0308]: mismatched types
--> src/passthru.rs:314:13
|
312 | let p_msg = match pattern {
| ------- this expression has type &J2534Common::PASSTHRU_MSG
313 | None => std::ptr::null() as *const PASSTHRU_MSG,
314 | Some(m) => m as *const PASSTHRU_MSG
| ^^^^^^^ expected struct J2534Common::PASSTHRU_MSG, found enum std::option::Option
|
= note: expected struct J2534Common::PASSTHRU_MSG
found enum std::option::Option<_>

error[E0308]: mismatched types
--> src/passthru.rs:330:46
|
330 | _ => Err(PassthruError::from_raw(res).unwrap())
| ^^^ expected u32, found i32
|
help: you can convert an i32 to u32 and panic if the converted value wouldn't fit
|
330 | _ => Err(PassthruError::from_raw(res.try_into().unwrap()).unwrap())
| ^^^^^^^^^^^^^^^^^^^^^^^

error[E0615]: attempted to take value of method stop_msg_filter on type &passthru::PassthruDrv
--> src/passthru.rs:336:35
|
336 | let res = unsafe { (&self.stop_msg_filter)(channel_id, filter_id) };
| ^^^^^^^^^^^^^^^ method, not a field
|
help: use parentheses to call the method
|
336 | let res = unsafe { (&self.stop_msg_filter(_, _))(channel_id, filter_id) };
| ^^^^^^

error[E0615]: attempted to take value of method set_programming_voltage on type &passthru::PassthruDrv
--> src/passthru.rs:345:35
|
345 | let res = unsafe { (&self.set_programming_voltage)(dev_id, pin, voltage) };
| ^^^^^^^^^^^^^^^^^^^^^^^ method, not a field
|
help: use parentheses to call the method
|
345 | let res = unsafe { (&self.set_programming_voltage(_, _, _))(dev_id, pin, voltage) };
| ^^^^^^^^^

error: aborting due to 7 previous errors; 5 warnings emitted

Some errors have detailed explanations: E0308, E0369, E0615.
For more information about an error, try rustc --explain E0308.

[BUG] Application does not support DrewTech Mongoose J2534

When I try to select DrewTech Mongoose J2534 adapter I have got error "Error code 8 (Device not connected)".

Here is j2534 log:

++ 0.000s PTOpen(059BBC40, 01357E40)
pName: test
Library Version: MongoosePro GM II J2534 Library v1.2.8.0
E1 Returning 8:ERR_DEVICE_NOT_CONNECTED 'Specified szName 'test' is not valid'

[BUG] Application crashes while Scanning for ISO-TP ECUs (Stage 1/2)

I try to use "Diagnostic Scanner" mode for VW Tiguan MG1 ECU, but application crashes while Scanning for ISO-TP ECUs (Stage 1/2). I used three J2534 devices: CHIPSOFT J2534 Pro, Openport2, SM2. Application crashes at the same location for all specified adapters.
mg1.zip

I attach j2534 log for all of this adapters.

[BUG] GraphicsAdapterNotFound (Windows 7)

If I do start the application only cmd.exe "plop" for less a second and thats all.

[Feature Request] Adaptive Brake Lights

Obligatory I'm not sure this is something you would feature in OVD, since you did say this would stay away from SCN Coding to avoid potential copyright infringements (although I think this request isn't exactly SCN coding).

I also have an '06 w203 and there is a feature that I would love to get on it which is the Adaptive Brake Lights which flash under heavy braking and then turn on the hazards when the vehicle comes to a complete stop which can be turned off by pressing the hazards button or after resuming drive when going over 7mph. This is how it is programmed in the w221 onwards or w211 model year 2007 onwards (code 807).

To know if a vehicle does come with this feature from factory, you run the VIN on a VIN decoder, and there should be an optional with the code K11.

I have looked everywhere and it seems w203's never came with this option, and all I can find are those 3rd party hardware that make the 3rd stop flash everytime one brakes, even if it is just light braking.

Perhaps this is possible to code with Arduino?

I have also searched every menu and submenu in DAS to make sure it wasn't deactivated, and my w203 (code 806) at least, doesn't have the option to activate this anywhere (usually in the rear SAM, according to various forums from other Mercedes models).

Congrats for the amazing project, and keep it coming!

[BUG] App crash on Linux when receiving first CAN msg.

Describe the bug
App crash on Linux with custom j2534, on Windows same driver works fine.

To Reproduce
Steps to reproduce the behavior:

1. Run app -> slelect j2534 mode -> go to CAN Tracker -> Connect
2. See error

Expected behavior
Able to see can message, no crash,

Screenshots

Desktop (please complete the following information):

• OS: Arch Linux

Additional context
j2534 driver src: https://github.com/witoldo7/STM32CAN/tree/h7port/drivers/j2534

Arduino + MCP2515 as J2534-2

I looked around but couldn't find a definitive answer.

Is this setup possible? plausible? Would you recommend it?
Maybe something like Seeed Can-Bus V2 dev board?

[BUG] Can't build because ISO15765_ADDR_TYPE not found

This is my current error message:

error[E0599]: no variant or associated item named `ISO15765_ADDR_TYPE` found for enum `ConnectFlags` in the current scope
   --> src/commapi/passthru_api.rs:139:35
    |
139 |            flags |= ConnectFlags::ISO15765_ADDR_TYPE as u32;
    |                                   ^^^^^^^^^^^^^^^^^^ variant or associated item not found in `ConnectFlags`

If I comment it out I can run OVD.