Know-how · Automation
CAPL and script-driven CAN testing
The standard way to automate a CAN test bench for twenty years, and an honest look at when a general-purpose language is the better tool.
In short
CAPL (Communication Access Programming Language) is an event-driven, C-like scripting language created by Vector for use inside CANoe and CANalyzer. A CAPL program is organised around event handlers — on message, on timer, on key, on start — which fire when a frame arrives, a timer expires or the user acts, making it a natural fit for simulating a missing ECU, generating bus traffic or driving a test sequence in real time on a bench. CAPL runs inside Vector's tools; it is not a general-purpose language and does not run standalone. For work that happens after the bus traffic has been recorded — batch analysis, fleet queries, regression comparison, reporting — a general-purpose language with direct access to the measurement files is usually a better fit, and that is where a Python SDK or REST API approach belongs. The two are complementary rather than competing: real-time bench stimulation and offline analysis are different jobs.
01
How CAPL is structured
A CAPL program is a set of event handlers rather than a top-to-bottom script. `on message` runs when a particular frame arrives, `on timer` when a timer elapses, `on start` once at measurement start. The runtime calls them; you do not call it. For bench work that model is exactly right, because a bus is an event source and a simulated ECU has to answer in real time.
The language is deliberately restricted. It is C-like, with access to the bus, the database signals and the tool's environment, and without the general facilities of a full programming language. That restriction is what keeps it deterministic enough to run in a real-time measurement loop.
- on messageFires when a matching frame arrives on the bus.
- on timerPeriodic or one-shot timed behaviour.
- on key / on start / on stopOperator and measurement lifecycle events.
- Runs inside the toolCAPL is not a standalone language or runtime.
02
What CAPL is good at, and what it is not for
It is good at real-time participation in a bus: restbus simulation where a missing ECU has to be impersonated, fault injection, gateway behaviour, and interactive test sequences on a bench. Anything where something must happen within a frame time, in the loop, is CAPL territory and remains so.
It is a poor fit for work that happens afterwards. Batch-processing a month of recordings, comparing a hundred runs against a reference, querying across a fleet, or producing a report is analysis, not stimulation — and doing it in a language confined to one tool, on one machine, with no package ecosystem, is harder than it needs to be. This is the honest division, not a criticism of the language: it was designed for the first job and does it well.
- Suited to CAPLRestbus simulation, fault injection, real-time sequences, gateway behaviour.
- Suited to a general languageBatch analysis, fleet queries, regression comparison, reporting.
- The deciding questionDoes it have to happen inside the measurement loop?
03
The script-driven alternative for analysis
For the offline half, the useful property is direct programmatic access to the recordings with an ordinary language around it. MDX exposes a local REST API and a Python SDK that mirrors it one to one, so signal queries, batch jobs, event detection and derived channels can be scripted with the rest of the Python ecosystem available — pandas, NumPy, whatever the team already uses.
It also ships an MCP server, which lets an AI assistant run the same analysis through the same tools while the files stay on the engineer's machine. That is a different capability from CAPL rather than a replacement for it: nothing here simulates an ECU on a live bus.
Standards & references
Check the source.
These primary sources define the formats and regulatory context discussed above. They do not certify or endorse VehicleLab products.
Questions
Frequently asked.
What does CAPL stand for?
Communication Access Programming Language. It is an event-driven, C-like scripting language created by Vector for use inside CANoe and CANalyzer.
Can CAPL run outside CANoe or CANalyzer?
No. CAPL executes inside Vector's tool environment and is not a standalone language or runtime.
Is CAPL a general-purpose programming language?
No. It is deliberately restricted to event handlers with access to the bus, database signals and the tool environment, which is what keeps it deterministic enough for a real-time measurement loop.
When should I use Python instead of CAPL?
For work after the recording exists — batch analysis, comparing many runs, fleet queries, reporting — where a general-purpose language and its ecosystem help. CAPL remains the right choice for anything that must happen inside the measurement loop, such as restbus simulation.
Does VehicleLab support CAPL?
No. VehicleLab tools do not execute CAPL. MDX provides a REST API, a Python SDK and an MCP server for scripted analysis of recordings, which covers the offline half of the work rather than real-time bus simulation.
Next step
Open one of your own files with us.
Send a measurement, an A2L or an EHANDBOOK container. We will open it in the instruments on a call, with your engineers in the room.