Vehicle diagnostics
Communication interface firmware
Every vehicle speaks a slightly different language. Alongside standards like OBD or J1939, many manufacturers have dialects of their own — and a diagnostic tool has to understand them all. For a Czech manufacturer of automotive diagnostic equipment, we develop the firmware for a communication interface that translates between the vehicle and the diagnostic software. One device, many protocols — from buses three decades old to diagnostics over Ethernet.
The device connects to a vehicle and exposes its control units to diagnostic software on a computer — over USB, wirelessly via Bluetooth, or across the network. Its firmware handles the standard diagnostic protocols (OBD, KWP2000 and ISO 9141 over K-line, J1850 in both VPW and PWM variants, CAN with ISO-TP and J1939) as well as manufacturers' own proprietary protocols, where a single brand routinely means several different transport variants. The device can also record measured data continuously to its own memory — so it doubles as a black box for later analysis. Alongside the firmware itself we deliver the host-side tools that build, provision, update and test the device.
Technology
The firmware is written in C for an ARM Cortex-M7 (STM32H7) on top of the FreeRTOS kernel, with a shared library for dispatch, cryptography, communication and auditing. Communication is handled by three CAN transceivers, K-line and J1850 drivers, serial channels, USB, Ethernet with a network stack for DoIP, and a Bluetooth Low Energy module. Data is recorded to external NOR flash, which also replaces the EEPROM for configuration. Security rests on an AES-GCM encrypted session, HMAC verification and signed firmware packages with anti-rollback protection. The companion host tools are written in Python and drive the build through CMake and Ninja, flashing through OpenOCD and updates over USB; tests run in four layers — unit tests on the target hardware, integration tests driven from the host, tests against a simulated vehicle, and system tests on real hardware — automatically in CI.
The brief
This was a replacement for the firmware of a device already in the field, not a greenfield build. The new platform had to stay compatible at the data level with the customer's existing diagnostic software, which meant taking the original behaviour apart protocol by protocol and rebuilding it on a maintainable foundation. On top of that, embedded plays by different rules than the web: every megahertz and kilobyte counts, bus timing is non-negotiable, and a bug can't be fixed with a page refresh. The firmware must serve several CAN channels, serial lines, USB, the network and wireless communication at once — in real time and reliably, because a vehicle's diagnosis depends on the output. And because the device sells as product lines with different feature sets, protecting the know-how was part of the job: encrypted firmware, secure key injection into the board, and licences tied to an individual unit.
The solution
The firmware is built as a layered architecture in C on top of the FreeRTOS real-time kernel. At the bottom sit the bus drivers — three CAN channels, K-line, J1850, serial lines, USB, Ethernet and Bluetooth. Above them stand the protocol state machines of the individual diagnostic standards and brand-specific protocols. At the top sit the manager for communication with the computer and a datalogger that manages the external flash memory on its own. Security rests on the bootloader as the device's single trust anchor: a three-stage boot chain where each stage validates the next, dual-bank flash with rollback to the previous version, a signed and encrypted update package delivered over USB, and an encrypted session between host and device. Keys are injected into the board through a controlled provisioning step, and the licence is evaluated at runtime against the device serial number, unlocking the subset of protocols the customer has paid for. The whole chain — build, flash, package, update, provisioning and tests — is driven by a single command-line tool for Windows, macOS and Linux.
Key features
- the standard OBD, KWP2000, ISO 9141, J1939, J1850 (VPW and PWM) and CAN protocols
- diagnostics over Ethernet per ISO 13400-2, including vehicle discovery and session control
- brand-specific protocols where one brand can mean four different transport variants
- uploading and downloading calibration maps for tuning control units
- three concurrent CAN channels, USB, Ethernet and Bluetooth as a full replacement for the cable
- recording of up to 25 defined values into 128 MB of memory — black-box mode with no computer attached
- encrypted session, signed firmware, rollback to the previous version and an audit log
- a licence bound to the device serial number unlocks the protocols that were paid for
- vehicle simulation inside the device — tests run without a physical control unit
- host-side tools to build, update, provision and verify a board
Results & benefits
- a complete firmware replacement for a shipping device, delivered in four releases over five months
- one device covers both standard and brand-specific protocols, from K-line to diagnostics across a network
- wireless connectivity and a third CAN channel took the device beyond what the original version could do
- device-level licensing made it possible to sell several product lines from a single firmware
- automated tests verify the device with no vehicle attached, including an eight-hour endurance run
- proof that Oidis reaches beyond the web: embedded development, hardware, security and automotive
