---
title: "Vendor tools and interchange"
---

# Vendor tools and interchange

Which vendor project files the module edits and how, which files it writes for which vendor tool and how far each was checked, how vendor projects and wording carry over, and how the module fits the customer's environment.

## Editing the vendor's project files

| Vendor file | Edited here | How the write is made |
|---|---|---|
| DBC (CANdb++) | Everything CANdb++'s object dialogs edit, in the CAN Database view or as text | Minimal text edits in CANdb++'s formatting, placed where CANdb++ puts them; opening and saving without a change gives the same bytes on all 220 vendor and community files tested |
| ARXML (ECUC values) | In the BSW Configuration editor or as text | Minimal edits placed where the AUTOSAR schema orders them |
| ARXML (software components, Adaptive manifests) | In their tree and form editors or as text | Minimal edits placed where the AUTOSAR schema orders them |
| ARXML (communication) | As text, with checks and navigation | Text editor; the CAN Database view shows it read only |
| LDF, A2L | As text, with checks and navigation; the A2L's addresses and types also from the build | Text editor; the A2L update edits only the numbers and types concerned |
| CANoe `venvironment.yaml`, `.vtestunit.yaml`, `.vtesttree.yaml`, `.vsysvar`, CAPL | As text, with Problems and, for CAPL, navigation and completion | Text editor |
| DCM data sets | As text, with problems at their line; written from an ECU, image or merge | Text editor and the data set commands |
| DaVinci projects (`.dpa`, `.dvjson`) | Read, not edited | Changed only by DaVinci's own `dvcfg-b` when you run an update |
| CANdelaStudio CDD, ODX, PDX | Read, not edited | |

**State:** DBC writing modelled: every edit reads back as the change in cantools and canmatrix, and statements are formatted as in files CANdb++ saved. No DBC edited here has been opened in CANdb++.

## Files written for vendor tools

| The module writes | Meant for | Checked so far |
|---|---|---|
| DBC edited in the CAN Database view, new from templates, converted from ARXML | CANdb++, CANoe, CANalyzer, CANape | Read back by the module, cantools and canmatrix |
| Communication matrix workbook and CSV | Excel, review tools | Read by cantools, canmatrix and LibreOffice Calc |
| ASC recordings and exports | CANalyzer, CANoe, CANape | Read back by python-can and the module |
| BLF and MF4 bus logging, through python-can and asammdf | CANalyzer, CANoe, CANape, INCA | Read back by python-can and the module |
| PEAK TRC 1.0 to 2.1 | PCAN-View, PCAN-Explorer, PEAK-Converter | Laid out per PEAK's TRC document; read back by python-can in 1.0, 1.1, 1.3, 2.0 and 2.1 |
| MF4 measurements and sweeps | CANape, INCA | Read by asammdf and mdflib |
| DCM 2.x and CDF 2.0 data sets | INCA, CANape | Read by dcmReader and autors; CDF valid against ASAM's DTD |
| Calibrated images (Intel HEX, S-records, binary) | vFlash, CANape, INCA, the OEM's flash tool | Read by GNU objcopy |
| Generated C code | The ECU's compiler | Compiled with gcc and clang |
| CANoe4SW test units, test trees and CAPL from test designs and variant runs | CANoe4SW Server Edition | Valid against Vector's published JSON schemas; read by the module's CANoe readers |

**None of these has been opened by the vendor tool it is meant for.** Each stays "not yet run against" its tool until a lab or customer run. The module's own formats (`.flashjob.json`, `.eol.json`, `.diagtests.json`, `.testdesign.json`, `.panel.json`, `.lintrace`, `.vscode/automotive-ecus.json`, `.vscode/automotive-protection.json`, `.vscode/automotive-trace-links.json`) are documented and have JSON schemas where they are JSON.

## Bringing a vendor project over

- **CANoe4SW Server Edition environments** are read as the project: databases, nodes, test units and system variables (see [CANoe projects and CAPL](https://neuralinverse.com/docs/modules/automotive/canoe/)).
- **DaVinci Configurator projects** are listed with their ECUC files and inputs (see [BSW configuration](https://neuralinverse.com/docs/modules/automotive/bsw-configuration/)).
- **ODX, PDX and CDD descriptions** are used as they are delivered.
- **A workspace of data only**, as a logger, test drive or HIL bench leaves it (captures and traces with no database or project), starts the environment, so the trace editors open them at once.

## Wording and keys

The module uses the vendors' words where it can: the CAN Bus panel's Trace, Graphics, Data, State Tracker and Statistics views are named as CANoe's windows are; the Diagnostics panel has Fault Memory and a Diagnostic Console; the CANoe Project view, CANoe Test Units and Build CANoe Environment use Vector's terms. Interactive Transmit is CANoe's Interactive Generator under another name. The module binds two keys: Ctrl+Alt+J (**Connect CAN Channel**) and Ctrl+Alt+H (**Start Rest-Bus Simulation**). The panel views can be arranged by hand.

## Change management

The module's files are text or XML and are kept in whatever version control the team uses, through the Editor's Source Control view. **Compare CAN Database with HEAD** gives a semantic diff of a DBC against its last commit.

## In the customer's environment

| Requirement | As built | Not verified |
|---|---|---|
| Windows | Vendor library discovery from install folders, the install locations Windows records, the system folder and PATH; the Windows receive-event wait; the registry for the D-PDU API; helper processes for x64 and x86 | Not run on Windows, except the helper processes under Wine |
| No Python | Vector, PEAK and Kvaser interfaces, slcan, the virtual bus, LIN, UDS, DoIP, XCP, MDF measurements and every reader except BLF and MF4 bus logging | BLF and MF4 bus logging and the other python-can interfaces need your Python with python-can (and asammdf) |
| Offline | Nothing is downloaded at run time | Not checked on an offline install |
| No administrator rights | The module writes only to the workspace on request, the recording folder and the build folder | Not checked on a managed machine |
| Policy | Library, interpreter and tool paths are machine-scoped settings | No administrator policy documented |
| Packaged build | The packaging builds the helper processes per platform | No packaged, code-signed product built |