EcuBus-Pro: an open source ECU diagnostic and test tool with TypeScript scripting

What EcuBus-Pro replaces, and for whom

The README describes EcuBus-Pro as an open-source alternative to commercial automotive diagnostic tools such as CAN-OE. That framing sets the audience: engineers doing ECU development and testing who would otherwise license a closed desktop tool for bus diagnostics, UDS request handling, DoIP sessions and LIN work. The project is written in C++ with an Electron and TypeScript front end, and it is licensed under Apache-2.0.

The scope is broader than a single protocol. The README lists CAN and CAN-FD, DoIP, LIN, SOME/IP, a TypeScript automation layer, a HIL test framework, LIN LDF editing and export, CAN DBC viewing, real-time signal graphing, a command line interface, and a drag-and-drop panel builder. Someone who needs one of those features gets the rest of the stack as well, which is either convenient or unnecessary depending on the team.

The people who benefit most are those who already own a supported interface. EcuBus-Pro does not ship hardware. It talks to PEAK, KVASER, ZLG, Toomotss, VECTOR, SLCAN and GS_USB (CANDLE) dongles, plus the project's own EcuBus-LinCable for LIN and PWM. If you have none of these, the software is not usable on a real bus.

How the scripting and HIL layers fit together

The architecture visible in the repository is an Electron application with a separate CLI entry point. The build scripts show two Vite configurations, electron.vite.config.ts for the desktop app and cli.vite.ts for the command line, with cli:build producing the packaged CLI and platform-specific targets such as cli:build:win and cli:build:linux. A TypeScript SDK is built separately through vite.sdk.config.ts and the build:sdk script, with tsconfig.sdk.json governing it.

That split matters for how you work. The desktop application is the interactive surface: bus traffic, diagnostic requests, graphs, panels. The SDK and CLI are the automation surface, which is what you would wire into a build server or a bench script. The scripting layer is TypeScript, and the README compares its intent to CAPL, the scripting language used in Vector tooling. The HIL test framework sits on top of the same scripting runtime, so a test is a script that drives the bus and asserts on responses.

Hardware access is abstracted behind vendor modules. The package.json ecubusPro.vendor map is the clearest statement of that design: on win32 the list is simulate, kvaser, peak, zlg, toomoss, vector, slcan, ecubus and candle; on linux and darwin it is only simulate and slcan. The simulate entry means the application can run without a physical bus, which is how you would evaluate the scripting layer before buying hardware.

Installing EcuBus-Pro and running a first script

The README points to the install documentation under docs/about/install.md and to the release page for downloads. The repository is an Electron project, so a source build goes through npm. The package.json defines the standard entry points: dev for the development build and build for a type-checked production build.

npm install
npm run dev

The dev script runs electron-vite dev, which starts the desktop application with hot reload. The build script runs typecheck first, covering both the Node and web TypeScript configurations, then electron-vite build. If you only want the SDK rather than the full application, the build:sdk script runs vite build with vite.sdk.config.ts.

The CLI has its own scripts. cli:build builds the CLI bundle, and cli:build:win or cli:build:linux additionally run the platform packaging step inside the cli directory.

npm run cli:build

For a first real use, the simulate vendor is the least demanding path. It is listed for all three platforms, so you can open a bus channel without a dongle, attach the script runtime, and confirm that a diagnostic request and its response flow through the UI before introducing real hardware. The README does not document a rollback procedure for a failed install, so treat the release downloads and the source build as the two supported routes and keep the version you were running until the new one is verified on your bench.

Where EcuBus-Pro will not work for you

The vendor matrix is the sharpest limitation. On Windows the application supports simulate, kvaser, peak, zlg, toomoss, vector, slcan and candle. On Linux and macOS the same field lists only simulate and slcan. A team standardised on Vector or PEAK hardware and working on Linux cannot use those interfaces with EcuBus-Pro as packaged, even though the same dongles work on Windows. SLCAN and the simulate channel are the portable options.

Hardware support is also not the same as protocol support. The README lists CAN and CAN-FD for ZLG, while LIN appears against EcuBus-LinCable, PEAK, KVASER, Toomotss and VECTOR. If your bench is LIN-based and your adapter is a ZLG unit, the README does not claim LIN for it.

Database handling is asymmetric in a way worth noting. The README says LIN LDF files can be edited and exported, while CAN DBC files are view only. Teams that expect to author DBC files inside the tool will need another editor. That is a design boundary, not a bug, but it shapes which part of the workflow EcuBus-Pro can own.

Finally, the release cadence is versioned but not frequent: v0.8.64, v0.8.65 and v0.8.66 landed between April and July 2026, with the last push on 2026-07-21. That is a maintained project, but the version number still sits below 1.0, which is worth weighing against the stability expectations of a production validation bench.

EcuBus-Pro compared with CANoe and other commercial stacks

The README names CAN-OE, almost certainly a rendering of CANoe, as the commercial category EcuBus-Pro positions against. The difference is not only price. Commercial stacks such as CANoe pair the desktop tool with a validated, vendor-supported hardware line and a long history of conformance documentation. EcuBus-Pro pairs an open Apache-2.0 codebase with third-party dongles from several vendors, and the quality of that path depends on the vendor module you select.

The scripting comparison is the same shape. CAPL is a proprietary language tied to Vector's environment. EcuBus-Pro uses TypeScript, which means the SDK can be built and consumed like any other TypeScript package, and the same language covers the HIL test framework. For a team already writing TypeScript tooling, that removes a language to learn. For a team with a decade of CAPL test assets, it means a port.

There is also a difference in what you can inspect. With an Apache-2.0 project you can read the vendor abstraction, the CLI entry point and the SDK source in the repository. With a commercial tool you get a support contract instead. Neither is strictly better; they fail in different ways when something goes wrong at 2 a.m. on a bench.

Licence and the cost of staying current

EcuBus-Pro is licensed under Apache-2.0, with the licence text in license.txt. That permits commercial use and modification, and it includes a patent grant. It does not, however, grant rights to the third-party vendor SDKs that the hardware modules likely depend on. If you build from source, the terms attached to a vendor's driver or SDK are separate from the project licence. That is a question for your legal team, not something the repository answers.

Upgrade cost is tied to the versioned releases. The project ships discrete versions rather than a rolling channel, so upgrading means moving from one tagged release to the next and re-verifying your scripts against it. The typecheck step in the build script is a signal that TypeScript surface changes are taken seriously, but it does not tell you whether a script that ran on v0.8.64 behaves identically on v0.8.66. The README does not document a compatibility policy between releases, so pinning a version for a validation bench and testing the next release on a separate machine is the conservative approach.

Sponsorship is present in the README as a funding route, with tiered logo placement. That is a funding model, not a licence change, and it does not alter the Apache-2.0 terms.

Editorial conclusion

EcuBus-Pro fits engineers who already own a supported CAN or LIN interface and want a free, scriptable diagnostic and HIL test environment on Windows, Linux or macOS. It is the wrong choice if your hardware vendor is not in the list for your platform, or if you need validated conformance evidence that a commercial tool vendor supplies. Before committing, check the vendor list for your operating system in package.json, confirm your dongle appears in the hardware documentation, and decide whether the versioned release cadence matches your project schedule.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes