Diagnostic and ECU communication applications
Build focused applications for diagnostic communication, fault memory handling, and live parameter display, designed around a specific set of ECUs and procedures.
Automotive Engineering Tools
Custom software for automotive engineering work
Engineering teams usually have the tools the market sells and a gap where their actual workflow is. Filling that gap does not need a platform — it needs a focused piece of software that understands the vehicle data it handles and does one job properly.
Discuss a Tooling ProjectProblems I can investigate
Find the behavior behind the symptom
- 01
The available tool does not fit how the work is done
A commercial tool covers most of a workflow and blocks the part that matters, or forces an export-and-rework step that costs more than the analysis itself.
- 02
The same manual analysis is repeated constantly
Engineers repeat a sequence of exports, conversions, and checks that is well understood, entirely mechanical, and never quite worth the time to automate until it is.
- 03
A purpose-built CAN viewer is needed
General-purpose bus tools show everything and highlight nothing. A viewer built around the specific messages, signals, and conditions a team cares about is often more useful than a more capable generic one.
- 04
A diagnostic application is needed
A focused tool for ECU communication, DTC handling, diagnostic sessions, or live parameters, shaped around one team's ECUs and procedures rather than a universal tester.
- 05
Data has to move between formats reliably
Conversions between measurement, recording, and tabular formats need to preserve timestamps, signal metadata, and precision, and to fail loudly rather than silently when they cannot.
- 06
Engineering results need a shared view
Results that live in individual scripts and local files are hard to compare or hand over. A dashboard makes the current state visible to the people who need it.
What I can help with
Focused engineering work in Automotive Engineering Tools
CAN tools and traffic viewers
Develop bus tools shaped around the messages and conditions that actually matter to a team, including decoding against database definitions and highlighting the conditions worth seeing.
Measurement viewers and data tools
Build interfaces for inspecting vehicle measurements and recordings where existing viewers cannot handle the file size, the signal set, or the specific comparison being made.
Converters and data pipelines
Implement conversion and processing between engineering data formats with explicit handling of timestamps, metadata, and precision, and clear failure behavior.
Workflow automation
Replace a repeated manual sequence with a scripted workflow that produces the same result every time and can be run by someone who did not write it.
Engineering dashboards and interfaces
Make analysis results visible and comparable across a team, whether as a desktop application or a served interface over an existing data source.
Integration with existing tooling
Connect new software to the tools, APIs, and data already in use, so it extends an established workflow rather than starting a parallel one.
Specific services
Services in Automotive Engineering Tools
Automotive Python Development
Automotive Python development for CAN analysis, data conversion, engineering dashboards, and focused diagnostic applications.
REST API Development
Develop REST APIs for automotive engineering tools with defined endpoints, validated inputs, clear errors, and documented integration contracts.
REST API Integration
REST API integration for automotive engineering tools, connecting telemetry and internal workflows to focused dashboards and dependable automation.
REST API Testing
Test engineering REST APIs for contract compliance, invalid inputs, response data, and state changes with repeatable cases and recorded evidence.
What to send
Start with the evidence you already have
Problem description
The workflow as it runs today, and the specific point where it breaks down.
Requirements
What the tool has to do, and for whom.
Interface specification
The interfaces, protocols, or data structures the tool must work with.
Existing source code
Current scripts or applications to extend, replace, or build on.
API specification
The API of a system the tool needs to integrate with.
DBC
A CAN database, where the tool decodes or generates bus communication.
How the analysis works
From recorded data to engineering findings
- 01
Understand the workflow as it runs today
Establish what engineers actually do, step by step, including the manual workarounds. The gap is usually somewhere other than where the tool request points.
- 02
Define the smallest useful tool
Agree the narrowest scope that removes the real bottleneck, so something usable exists early rather than after a long build.
- 03
Build against real data
Develop against actual recordings, measurements, or ECU behavior rather than idealized inputs, since edge cases in real vehicle data are the norm.
- 04
Put it in front of its users
Get the tool into the hands of the engineers who will use it early enough that their feedback can still change its shape.
- 05
Harden and document
Address the failure cases that matter, make errors legible, and document the tool so it can be run and maintained by people who did not build it.
- 06
Hand over source and knowledge
Deliver the code, its documentation, and the reasoning behind its structure, so the tool remains yours to extend.
What you receive
Deliverables matched to the investigation
Diagnostic application
A focused application for ECU communication, DTC handling, sessions, or live parameters.
CAN analysis tool
A tool for viewing, decoding, or checking bus traffic in your workflow.
Measurement viewer
An interface for inspecting the signals and events that matter in your measurements.
Data converter
A conversion tool between engineering data formats that preserves timestamps and metadata.
Desktop engineering application
A desktop application built around a specific engineering workflow.
Engineering dashboard
A shared view of analysis results and current state across a team.
Python analysis script
A maintainable Python workflow for engineering-data analysis.
Technologies & formats
Automotive data and analysis environments
- Python
Python
A general-purpose language widely used for automotive analysis, tooling, and automation.
- C++
C++
A systems and application language used in embedded, tooling, and platform software.
- Qt
Qt
A cross-platform C++ framework for graphical and embedded applications.
- QML
Qt Modeling Language
Qt declarative language for building animated user interfaces.
- REST API
REST API
An HTTP resource-oriented interface used for software and cloud integration.
- python-can
python-can
A Python library providing a common API for CAN interfaces and messages.
- cantools
cantools
A Python package for parsing CAN databases and encoding or decoding messages.
- SocketCAN
SocketCAN
The Linux kernel networking interface and tools for CAN communication.
- CSV
Comma-Separated Values
A tabular text format often used for exchanging decoded engineering data.
- CANoe
Vector CANoe
A development, simulation, test, and analysis environment for vehicle networks.
- CANalyzer
Vector CANalyzer
A Vector environment for recording and analyzing vehicle-network communication.
- Wireshark
Wireshark
A packet analyzer for capturing, decoding, and inspecting network traffic.
FAQ
Practical questions before an investigation
- How small can a tool project be?
- Small is usually the right size. A script that removes a repeated half-hour of manual work is a legitimate deliverable and often the highest-return one. Larger applications are worth building once the workflow they support is well understood, which a small tool tends to establish.
- Do you build desktop applications or scripts?
- Both, chosen by who uses it and how. A script suits an engineer comfortable at a command line and running the same analysis repeatedly. A desktop application with an interface makes sense when the users are not the author, when interactive inspection is the point, or when the tool must be usable without a Python environment.
- Which languages do you build in?
- Primarily Python, which fits vehicle-data processing and the surrounding ecosystem well, and C++ where performance or an existing codebase requires it. Interfaces are typically built with Qt. The choice follows the constraints of your environment rather than a preference.
- Can you extend software we already have?
- Yes, where the source is available or the tool exposes a usable interface. Extending an established workflow is usually cheaper and better adopted than replacing it. If the existing code cannot practically carry the change, that assessment is given directly rather than discovered halfway through.
- Who owns the resulting code?
- You do. The deliverable is source code with documentation, intended to be maintained by your team. Nothing is built to require ongoing involvement from me in order to keep working.
Discuss the evidence
Discuss an Engineering Tool Project
Describe the workflow that is not working and where engineers lose time today. Existing scripts, an interface specification, or a DBC help scope it.