The CAN Protocol

Origins & Why It Still Wins a protocol designed for cars, not computers

Before CAN, an automobile was wired point-to-point: every switch, sensor and lamp had its own dedicated copper. By the early 1980s the harness in a fully optioned Mercedes had ballooned past two kilometres of wire weighing more than 50 kg. Bosch engineer Uwe Kiencke and his team set out to design a serial bus that was cheap, robust, prioritised and multi-master — a network where any node could speak when the bus was idle, and where the most urgent message would always go through first.

The 1986 SAE paper announcing CAN listed four design choices that, in retrospect, explain its longevity:

For an electric vehicle, these properties matter more, not less, than they did for an internal-combustion car. A traction inverter must decide within a millisecond whether to honour a torque request; a battery management system must veto closing the main contactors if even one of 100+ cell modules reports a fault. CAN's deterministic priority resolution and its tolerance of single-wire failures (an open or short on either bus line still permits degraded operation per ISO 11898-2) make it a natural fit for safety-critical traffic that must arrive.

The Physical Layer two wires, one differential voltage, two states

A high-speed CAN bus consists of exactly two wires — CAN_H and CAN_L — twisted together, terminated at each end of the trunk with a 120 Ω resistor matching the cable's characteristic impedance. Information is encoded not in the absolute voltage of either wire, but in the differential voltage between them, which radically improves immunity to the electromagnetic chaos of an EV powertrain.

The bus has two states, deliberately named to avoid the usual high/low ambiguity:

• Recessive (logical 1) — both wires float to about 2.5 V via bias networks; the differential V_diff ≈ 0 V.
• Dominant (logical 0) — the transmitter drives CAN_H up to about 3.5 V and CAN_L down to about 1.5 V; V_diff ≈ 2 V.

The asymmetry is intentional. When one node transmits a dominant bit and another transmits a recessive bit simultaneously, the dominant bit overwrites the recessive — this is the AND-of-the-bus property on which all arbitration depends.

Anatomy of a Frame SOF · arbitration · control · data · CRC · ACK · EOF

A classical CAN data frame is a packet of between 47 and 135 bits — short, by any modern standard. Every byte exists for a reason: arbitration, addressing, length signalling, payload, integrity, acknowledgement, end-marker. Understanding the layout makes oscilloscope decoding intuitive and explains, for instance, why an 11-bit ID message of zero data length still requires 47 bit-times to transmit.

Standard frame (CAN 2.0A, 11-bit identifier)

One subtle but essential mechanism is bit stuffing. After any run of five identical bits in the field from SOF through CRC, the transmitter inserts an opposite-polarity stuff bit, which the receiver removes. This guarantees enough edges for receivers' bit-timing units to stay synchronised — and explains the upper bound of 135 bits per frame.

Arbitration CSMA/CR — collisions made polite

What happens when two ECUs decide to transmit at the same instant? On Ethernet, both detect the collision, back off, and retry with a randomised delay — wasting time and giving no guarantee of priority. CAN solves the same problem more elegantly. Because dominant bits overwrite recessive bits on the wire, each transmitter compares the bit it intended to send against the bit it actually sees. The moment a node sees a dominant bit when it transmitted a recessive bit, it knows another node has a higher-priority (lower-numbered) ID, and it instantly stops transmitting and switches to receive mode. The winner's frame continues uninterrupted.

This is called Carrier Sense Multiple Access with Collision Resolution (CSMA/CR), and it has a beautiful consequence: the highest-priority message in the system suffers, in the worst case, only one bit-time of latency for any given lower-priority frame already in transit — a deterministic bound that lets engineers prove real-time schedulability.

Bit Timing & Synchronisation where embedded firmware meets the wire

Every node on a CAN bus must agree, to within fractions of a bit-time, on where the middle of each bit is. There is no separate clock line: receivers extract timing from recessive-to-dominant edges in the data stream itself. To make this possible, the nominal bit time is divided into four segments:

The Synchronisation Segment (always 1 Time Quantum, TQ) is where edges are expected. The Propagation Segment compensates for signal-propagation delay along the cable plus transceiver group delay — round-trip. The two Phase Segments bracket the sample point, the instant at which the receiver actually latches the bit's logic level. Industry convention places the sample point at 75–87.5% of the bit time; CANopen recommends 87.5%, AUTOSAR drivers default similarly.

Resynchronisation occurs when an unexpected edge falls inside PhaseSeg₁ or PhaseSeg₂: the controller shortens or lengthens these segments by up to the Synchronisation Jump Width (SJW) to slide the sample point back over the new edge.

Error Handling & Bus States five mechanisms, two counters, three states

CAN's fault-confinement model is one of its most studied features. Every node maintains two counters — the Transmit Error Counter (TEC) and the Receive Error Counter (REC) — that move in response to detected errors and successful transmissions. The node's behaviour transitions through three states based on the counter values:

• Error Active (TEC & REC < 128): the node participates fully and signals errors with an active error flag of six dominant bits, destroying the offending frame and forcing retransmission.
• Error Passive (TEC or REC ≥ 128): the node still transmits and receives, but its error flag becomes passive (six recessive bits) so it cannot disturb other nodes' traffic. A typical sign of marginal hardware.
• Bus Off (TEC ≥ 256): the node disconnects itself from the bus. Recovery requires either application-level intervention or 128 occurrences of 11 consecutive recessive bits.

Five complementary error-detection mechanisms operate in parallel: bit monitoring (compare transmitted bit with bus value), bit stuffing (more than five identical consecutive bits), frame check (fixed-form fields must match), CRC (15-bit polynomial over the frame), and ACK check (at least one receiver must drive the ACK slot dominant). Together they reduce the residual undetected-error probability below 10⁻¹³ — about one undetected error per million years of continuous traffic at 500 kbit/s.

CAN-FD and the Path to CAN-XL faster data, longer frames, same arbitration

Classical CAN tops out at 1 Mbit/s and 8 bytes of payload — comfortably enough for periodic torque and temperature signals, but painfully slow for the multi-kilobyte secure flash blocks now demanded by over-the-air updates and for the parameter dumps of modern motor-control software. CAN-FD (Flexible Data-rate), introduced by Bosch in 2012 and standardised as ISO 11898-1:2015, addresses both shortcomings while preserving the priceless property of bitwise arbitration.

The trick is to use two bit rates per frame, separated by the BRS (Bit Rate Switch) bit:

1. The arbitration phase (SOF through BRS) runs at the classical nominal rate — typically 500 kbit/s — because arbitration requires every transmitter to see every other's dominant bit before the sample point.
2. Once arbitration is won and BRS is set recessive, the bus switches to the data phase rate — commonly 2 Mbit/s or 5 Mbit/s in vehicles, up to 8 Mbit/s on benches — for the DLC, data and CRC fields.
3. After the CRC, the bus reverts to nominal rate for ACK and EOF.

The payload limit jumps from 8 to 64 bytes, the CRC widens to 17 or 21 bits with a different polynomial (chosen to maintain Hamming distance even under bit-stuffing irregularities), and a stuff-bit count field guards against a class of subtle errors that plagued early FD implementations.

Higher-Layer Protocols UDS, ISO-TP, J1939, OBD-II, CANopen

Raw CAN gives you frames, IDs and bytes. To actually exchange diagnostic requests, segmented file transfers, or standardised emissions data, the industry layers higher protocols on top:

ISO 15765-2 — Transport Protocol (ISO-TP)

CAN's 8-byte (or 64-byte) payload is too small for many diagnostic operations. ISO-TP fragments a logical message of up to 4 GB into a sequence of single, first, consecutive and flow-control frames, with a tiny header in the first byte indicating the frame type and sequence number. Every UDS exchange you observe on a vehicle bus is in fact an ISO-TP conversation.

ISO 14229 — Unified Diagnostic Services (UDS)

UDS defines the request/response protocol used by every modern OEM scan tool: read DTCs (0x19), read data by identifier (0x22), security access (0x27), routine control (0x31), request download (0x34) for ECU flashing, and many more. Each request carries a service identifier (SID); a positive response echoes the SID + 0x40, a negative response is 0x7F <SID> <NRC>.

SAE J1939

Dominant in commercial vehicles and heavy machinery, J1939 uses 29-bit identifiers to encode source address, destination address and a Parameter Group Number (PGN). It defines a fixed catalogue of Suspect Parameter Numbers (SPNs) — engine RPM, coolant temperature, etc. — so any J1939-compliant ECU is plug-and-play. Several electric-truck programmes adopt J1939 conventions even when the powertrain is fully electric.

ISO 15031 / SAE J1979 — OBD-II

The legally mandated subset of diagnostics, accessed via the trapezoidal connector under the dash. PIDs (Parameter IDs) under service 0x01 expose a defined list of signals: vehicle speed, battery state of charge for EVs (PID 0x5B), HV battery pack temperature (0x5C), etc. Useful for compliance and for third-party telematics dongles.

CANopen, CANaerospace, DeviceNet

Outside the automobile, CANopen (CiA 301) is the dominant higher-layer protocol — used in industrial robotics, medical devices, and increasingly in charging infrastructure on the back end of CCS DC fast chargers. It defines an object dictionary, PDOs (Process Data Objects), and SDOs (Service Data Objects).

CAN in the EV Architecture domain controllers, gateways, zonal trends

A contemporary battery-electric vehicle does not have a CAN bus — it has several, partitioned by function and safety integrity. The diagram below shows a typical (and deliberately simplified) topology with the principal domains and the kind of traffic each carries.

Why segment the buses?

Three reasons dominate:

• Bandwidth. A single bus at 500 kbit/s saturates around 60% utilisation for jitter-tolerant safety traffic. Segmenting keeps the powertrain bus uncluttered by infotainment chatter.
• Failure isolation. A shorted CAN_H on the chassis bus must not silence the battery contactor command.
• Cybersecurity. The OBD port and the telematics modem live on the chassis or comfort bus; the gateway implements a firewall that forwards only whitelisted IDs into the powertrain.

Charging interfaces

The DC fast-charging story is split between standards:

• CCS / Combo uses HomePlug Green PHY power-line communication (PLC) over the Control Pilot wire, layered with ISO 15118 — not CAN. The OBC, however, communicates with the BMS over an internal CAN bus throughout the session.
• CHAdeMO uses CAN at 500 kbit/s directly on dedicated charger-to-vehicle pins to carry charge-control messages (charger capabilities, vehicle state, current request).
• NACS / Tesla currently uses PLC for DC fast charging; AC remains a simple Control Pilot PWM with no high-level protocol.

The zonal trend

Newer architectures — Mercedes-Benz MMA, VW SSP, GM Ultifi, Stellantis STLA Brain — are moving toward zonal rather than functional partitioning, with a high-bandwidth backbone (Automotive Ethernet 100/1000BASE-T1, TSN) connecting four to six zonal controllers, each of which fans out to local sensors and actuators via short CAN-FD or LIN segments. The number of long CAN runs shrinks; the number of short CAN segments multiplies. The protocol survives, but its role inverts — from vehicle backbone to local actuator bus.

Practical Notes diagnostics, bus loading, calibration pitfalls

Bus loading — rules of thumb

Calculate worst-case bus load as Σ (frame_length_bits / period_ms) / bitrate. Targets in production EV programmes:

DBC files

The de-facto exchange format for CAN message catalogues is the Vector DBC file: a plain-text description of every message ID, signal start-bit, length, byte order (Intel/Motorola), scale, offset, units and value tables. Most tooling — Vector CANalyzer, CANoe, PEAK PCAN-View, Wireshark with the CAN plugin, Python's cantools library — consumes DBC directly. Treat the DBC as part of the source code: version-control it, code-review it, generate the embedded encoder/decoder from it.

Partial Networking & wake-up

An EV at rest in a parking garage cannot afford to keep every ECU powered. CAN Partial Networking (ISO 11898-6) allows selected ECUs to be put into sleep while a transceiver with selective wake-up filters specific IDs and powers the microcontroller only when a relevant frame arrives. This is essential for keeping 12 V battery drain below the typical 50 mA target during the long-key-off phase.

Common pitfalls — a partial list

• Missing or extra termination. The bus needs exactly two 120 Ω terminators, at the geometric ends of the trunk. A third terminator (often a forgotten development tool) drops the differential amplitude below the receiver's threshold; a missing one causes reflections and stuff errors. Measure the bus resistance with the network unpowered: it should read 60 Ω.
• Ground offset between ECUs. A 1 V common-mode offset is normal in an EV; 5 V is asking for trouble. ISO 11898-2 specifies a common-mode range of −2 V to +7 V; exceed that and the transceiver corrupts bits silently.
• Cycle-time jitter. A 10 ms message that occasionally takes 14 ms because of higher-priority traffic is normal; one that takes 40 ms suggests a bus-load problem or a misconfigured COM stack.
• Endianness confusion. Most automotive DBCs use Motorola (big-endian) byte order, but many test tools default to Intel (little-endian). A torque scaling of 0.0625 Nm/bit suddenly reading 16 384 Nm is almost always a byte-order flip.
• Silent ECU after flashing. If a freshly flashed ECU appears dead, check it is not stuck in Bus-Off because of a single early TX error against a misconfigured bitrate. The bit-timing register is one of the most miscalibrated registers in automotive embedded.

CAN Interface Hardware what sits between your laptop and the bus

So far, the protocol. Now the metal. Every measurement, every flash, every dyno trace begins with a small black box that bridges three worlds: a host computer speaking USB or PCIe; a protocol stack speaking CAN frames with microsecond timestamps; and a transceiver speaking dominant and recessive bits onto a pair of copper wires. This object is the CAN interface, and choosing the right one is more consequential than its modest price suggests.

The vendor landscape

The professional automotive market is dominated by a small number of suppliers, each with a slightly different philosophy:

The software stack

An interface is only as useful as the layers above it. From the bottom up:

• Driver / API. Vector XL-Driver Library, PCAN-Basic, Kvaser CANlib, ICS API, IXXAT VCI, or on Linux the kernel's SocketCAN framework which exposes CAN as a network interface.
• Bindings. Most professional engineering work happens through Python (python-can, cantools), MATLAB (Vehicle Network Toolbox), or C# / .NET wrappers above the vendor API.
• Applications. Vector's CANoe and CANalyzer for monitoring and simulation; CANape and ETAS INCA for measurement and calibration; PEAK PCAN-View for quick diagnostics; Wireshark with the CAN plugin for ad-hoc bus capture.

Bench setup pitfalls

• Termination is on you. Most interfaces do not internally terminate the bus — they are designed to tap an already-terminated network. On the bench, add a 120 Ω resistor at each end of your stub, or use a breakout box that includes switchable termination. Forgetting this is the most common cause of "the bus worked yesterday" syndrome.
• Driver/firmware pinning. Vector's XL-Driver Library bumps interface firmware on connect. Pin the host driver version in your test environment; a Friday-afternoon Windows Update has stopped more dyno sessions than any controller bug.
• USB power budget. A four-channel device drawing > 400 mA over USB 2.0 may glitch when an unpowered hub gets congested. Use a powered hub or, better, the interface's own external power input if it has one.
• Bus power. The interface does not wake the bus from a sleeping ECU. Power must come from the vehicle or a bench supply on KL30/KL15.

XCP — Measurement & Calibration over CAN how engineers actually look inside a running ECU

UDS, covered in §VIII, is the diagnostic protocol; it answers "what is wrong?" and "what is your software version?" But the daily work of a controls engineer is different: you need to see a state variable evolve in real time while the inverter is spinning the dyno, and you need to tweak a calibration constant — a torque-table cell, a regulator gain, a current-limit threshold — without rebuilding and reflashing the ECU. That is the job of XCP, the Universal Measurement and Calibration Protocol, standardised by ASAM.

XCP descends from CCP (CAN Calibration Protocol, 1996), which was tied to CAN. XCP generalised the abstraction: the application layer is identical regardless of whether the underlying transport is CAN, CAN-FD, Ethernet (UDP or TCP), USB, FlexRay or a custom serial link. In an EV powertrain context you will encounter all four of the first transports, often in the same project: XCP on CAN on the production inverter, XCP on Ethernet for high-bandwidth rapid prototyping with dSPACE or ETAS hardware, and XCP on USB for bench-side data logging from a debug interface.

Architecture in one sentence

A master (CANape, INCA, MATLAB Vehicle Network Toolbox, a custom Python script using pyxcp) issues commands to a slave (the XCP driver embedded in the ECU firmware), which responds with answers and asynchronously streams measurement data back at configured event triggers.

Two packet types, three core services

XCP defines exactly two packet families:

• CTO — Command Transfer Object. Synchronous request/response: CONNECT, GET_STATUS, SHORT_UPLOAD, SET_CAL_PAGE, DOWNLOAD, BUILD_CHECKSUM, etc.
• DTO — Data Transfer Object. Asynchronous bulk data, carrying either DAQ (slave → master, measurement) or STIM (master → slave, stimulation) payloads.

On top of these, three services do almost all the work:

1. Measurement (DAQ). The master configures one or more DAQ lists: each list is a set of memory addresses (ECU variables) tied to an event channel — typically a periodic task in the ECU scheduler (1 ms, 10 ms, 100 ms) or an event raised by a specific function (e.g. each PWM cycle). When the event fires, the XCP slave packs the current values of those variables into a DTO and transmits. No polling.
2. Calibration. The master may DOWNLOAD new values to any writable memory address, with optional resource-access protection. Cleared with SET_CAL_PAGE, the change takes effect on the next time the application code reads the parameter.
3. Page switching. Many ECUs implement two memory pages — a reference page (the flashed baseline, read-only) and a working page (RAM, writable). A SET_CAL_PAGE command swaps which one the application sees. This gives an engineer the ability to roll back a calibration change instantly, and to compare new-vs-old behaviour by toggling pages mid-test.

The A2L file — the missing piece

The XCP protocol does not know names. It moves bytes between memory addresses, full stop. The bridge between "address 0x80001234, four bytes, little-endian" and "motor mechanical speed in revolutions per minute" lives in the A2L file (ASAM MCD-2 MC), a plain-text description that every measurement / calibration tool ingests. A minimal entry looks like:

/* MEASUREMENT block — one per observable variable */
/begin MEASUREMENT motor_speed_rpm "Motor mechanical speed"
   FLOAT32_IEEE NoCompuMethod 0 0 -10000 10000
   ECU_ADDRESS 0x80001234
   DISPLAY_IDENTIFIER nSpeed
   FORMAT "%.1f"
   PHYS_UNIT "rpm"
/end MEASUREMENT

/* CHARACTERISTIC block — one per calibration parameter */
/begin CHARACTERISTIC Iq_Limit_A "q-axis current limit"
   VALUE 0x80008000 Linear_q15 500.0 -500.0 500.0
   PHYS_UNIT "A"
/end CHARACTERISTIC

For a model-based development flow — Simulink Embedded Coder, TargetLink, or ETAS ASCET — the A2L file is generated automatically from the model: every Simulink signal marked for measurement and every workspace tunable parameter appears in the A2L with the correct address (resolved post-link by parsing the linker map) and the correct conversion rule (inferred from the data-type and scale/offset attributes on the signal).

Calibration page switching, in practice

When commissioning a new motor map on the dyno, you load the existing flash calibration onto the reference page, copy it to the working page, then make incremental changes to the working page — torque table cells, MTPA breakpoints, field-weakening transition speeds — while the dyno is running. At any moment you can SET_CAL_PAGE → reference to A/B-compare the original and the new calibration on the same operating point. When you're happy, the working page becomes the new flash content and is written back to the ECU's non-volatile memory via the standard UDS flash sequence. The protocol is unchanged; the workflow is what makes XCP indispensable.

The Tooling Ecosystem CANoe, CANape, INCA, HIL, restbus, file formats

The protocols described in this monograph are not, on their own, productive. Around them an entire ecosystem of measurement, simulation, calibration, logging and testing tools has grown up — much of it from the same companies that supply the interface hardware. A working engineer needs to know which tool to reach for, and which file format to feed it.

Measurement & Calibration

Bus Simulation & Test

HIL & Rapid Prototyping

Hardware-in-the-loop (HIL) systems close the loop between a real ECU and a real-time simulated plant. They consume your CAN signals as inputs to a vehicle dynamics or e-machine model and inject the model's responses back on the bus — a dyno-in-a-box. The four big platforms in the EV space:

• dSPACE SCALEXIO / MicroAutoBox III — the de-facto standard at most German OEMs. Model deployment from Simulink Real-Time Interface. MicroAutoBox is the in-vehicle, ruggedised variant for rapid prototyping (bypassing).
• ETAS LABCAR — close integration with INCA and ASCET; popular at Bosch supplier sites.
• NI VeriStand / PXI — the LabVIEW-based platform; flexible, large I/O, strong on multi-channel current and high-voltage applications.
• Speedgoat — Simulink Real-Time native; lighter weight than the others; popular in university labs and small teams.

Bypassing deserves a special note in an EV context. The technique replaces a piece of running ECU code — say, the q-axis current controller — with a function executing on external rapid-prototyping hardware, communicating via XCP-on-Ethernet at sub-millisecond cycle times. You iterate on the model in Simulink, hit "build and deploy", and the new controller is live on the dyno seconds later, with the rest of the production ECU code untouched. The technique is invaluable for tuning regulator gains, evaluating new MTPA strategies, or testing harmonic-current injection schemes before they are mature enough to embed in the production binary.

Restbus simulation

An ECU on the bench, unplugged from the rest of the vehicle, is hostile territory: every periodic message it expects from a neighbour is missing, every timeout fires, and the application either refuses to start or enters a limp-home mode. The cure is restbus simulation — typically authored in CANoe, where you load the vehicle DBC, mark which nodes are real and which are simulated, and the tool generates the expected periodic traffic for all simulated nodes. The device-under-test sees a believable network and behaves as it would in the vehicle.

The file-format menagerie

Where to start, if you are starting today

For a controls engineer arriving on a new EV programme, the minimum-viable toolkit is: a four-channel CAN-FD interface (Vector VN1630A or PEAK PCAN-USB FD), Vector CANoe or PEAK PCAN-View for live bus monitoring, the project's DBC and A2L files under version control, Python with python-can and cantools for scripted measurement and replay, MATLAB / Simulink with Vehicle Network Toolbox if your team is model-based, and CANape or INCA the moment XCP-based calibration becomes part of the daily work. Add a HIL system when your control loops are mature enough that you can no longer tolerate dyno turnaround times.

CANape & CANoe the two programs you live in

Of the dozen vendor tools listed in the previous section, two account for the overwhelming majority of an EV-controls engineer's wall-clock time. CANape is where you measure and calibrate a real ECU; CANoe is where you simulate the rest of the vehicle so that ECU has someone to talk to. They share a vendor (Vector Informatik), an ancestor in CANalyzer, and a common visual idiom, but the workflows are genuinely different. This section walks through both with enough detail to recognise — and reproduce — what an experienced user is doing on the screen across the desk from you.

XIV.A — CANape, the engineer's measurement bench

CANape is, at heart, an XCP master with very polished display, recording, and calibration windows on top. Open a project and you will find four artefacts that define what it can do:

• Device. A description of one ECU on the bus — its XCP slave configuration, the channel and bit-rate to reach it, and the A2L file that names every memory location.
• Bus database. The DBC (or ARXML) for any CAN traffic you want to observe in parallel with XCP measurements.
• Measurement Configuration. The set of signals to be recorded, grouped by event channel (1 ms / 10 ms / 100 ms / on-change), with target sample rates that CANape negotiates with the slave's DAQ lists.
• Display Configuration. The arrangement of windows — Graphic (oscilloscope-style traces), Numeric (live values), Oscilloscope (high-rate burst capture), Bus Statistics, Map / Curve editors for 2-D and 3-D calibration tables.

The day-to-day rhythm is straightforward. You connect the interface, CANape sends the XCP CONNECT command, queries the slave's resources, and downloads the configured DAQ lists to the ECU. You hit the red Measurement button and signals begin streaming from the ECU to your display in real time. You drag a calibration parameter from the parameter tree onto a slider widget, change it on the fly, and watch the response in the same window. When you have something worth keeping, the Recorder writes the lot to an MDF4 file with full timing metadata, ready for offline analysis in MATLAB, Python, or Vector's own vSignalyzer.

Drag the Torque demand slider while measurement is running — the working page applies your calibrated K_p immediately and the actual-torque trace responds with the corresponding rise time. Flip the Page selector to Reference to see how the same demand would have been tracked with the flashed-baseline K_p. This is the workflow that distinguishes a calibration tool from a passive logger: the act of measurement and the act of tuning are unified in the same window.

Calibration objects beyond simple parameters

CANape's parameter tree is hierarchical and typed. A scalar like Iq_Limit_A opens as a numeric editor; a 1-D table like MTPA_Iq_vs_Tdemand[] opens as a curve editor with draggable breakpoints; a 2-D map like Efficiency_eta(speed, torque) opens as a surface editor with both contour and 3-D views, and the cursor on the surface follows the ECU's live operating point if the corresponding signals are being measured. For an MTPA-curve recalibration session, you can have the map editor on one screen, a 4-channel scope of (T_demand, T_actual, I_q, I_d) on another, and reshape the map by dragging individual cells while watching the response in real time — a workflow that would have been unthinkable in the days when a calibration change meant a flash cycle and a power-down.

XIV.B — CANoe, the virtual vehicle network

If CANape's centre of gravity is the device, CANoe's is the network. The premise is simple: most testing of an embedded ECU has to happen long before the rest of the vehicle exists, or in scenarios that would be expensive or dangerous to provoke on a real car. CANoe lets you build a virtual replica of the vehicle network — every bus, every node, every signal, every periodic message and every event-driven response — and run it in real time alongside the one or two real ECUs you actually have on the bench.

The configuration is organised around four main windows:

CAPL — the language that makes CANoe powerful

The single feature most responsible for CANoe's dominance is CAPL — the Communication Access Programming Language, a C-flavoured event-driven scripting language with direct access to bus messages, signals, system variables, and Vector's environment functions. Every simulated node and every test case is a CAPL program. A minimal CAPL file that simulates a torque-request transmitter and reacts to a status response looks like this:

/* TorqueRequester.can — a simulated VCU node */

variables {
   message 0x100 TorqueReq;                // frame definition
   msTimer SendCycle;                       // 10 ms periodic timer
   float   currentDemand_Nm = 0.0;
}

on start {
   write("VCU node up at t = %f s", timeNow());
   setTimer(SendCycle, 10);             // fire every 10 ms
}

on timer SendCycle {
   // Encode physical Nm to raw (scale 0.0625 Nm/bit, signed 16-bit)
   TorqueReq.word(0) = (int)(currentDemand_Nm / 0.0625);
   TorqueReq.byte(2) = sysGetVariableInt(VCU::DriveMode);
   output(TorqueReq);
   setTimer(SendCycle, 10);
}

/* Event-driven: react to a received MotorStatus message */
on message MotorStatus {
   if (this.byte(0) & 0x01) {
      write("⚠  Motor fault flag at %.3f s", timeNow());
      currentDemand_Nm = 0.0;                  // safe-state
   }
}

/* Panel-driven: react to operator changing a system variable */
on sysvar VCU::TorqueDemand {
   currentDemand_Nm = @VCU::TorqueDemand;
}

Note three patterns: the on timer handler implements periodic transmission; the on message handler is the event-driven reception path; the on sysvar handler links a system variable to a user-interface widget on a CANoe panel. CAPL is fast enough to keep up with the bus in real time (microsecond-scale handler execution) and capable enough to express complex test logic, gateway behaviour, residual-bus simulation, and even bit-level fault injection.

Test automation — vTESTstudio

For repeatable regression testing, hand-written CAPL gives way to vTESTstudio, Vector's test-authoring environment. Tests are authored declaratively as a sequence of stimulus and check statements; vTESTstudio compiles them into CAPL that runs on the same CANoe runtime. The output is a structured HTML report listing passed and failed cases — exactly the artefact you need for ASIL evidence under ISO 26262.

The three workflows you will use most

1. Restbus simulation. Load the project DBC, mark the device-under-test as Real and every other node as Simulated, and CANoe will auto-generate (or you'll fill in) the CAPL stubs that produce the expected periodic traffic. The DUT sees a network that looks complete.
2. Trace replay. Drop a logged .blf or .asc file into a Replay block in the Measurement Setup. The bus replays the captured traffic exactly as it occurred, with original timing — invaluable for reproducing a field-failure scenario on the bench.
3. Gateway emulation. Two CAN channels, one CAPL program forwarding selected IDs from channel 1 to channel 2 with optional ID remapping, signal scaling, or rate gating. Useful when standing in for a not-yet-available production gateway, or when testing how a new ECU behaves behind a real one.

How they fit together

On a typical day at the inverter bench you may well have both tools running at once: CANoe on one monitor simulating the VCU, BMS, and OBD-tester so the inverter under test sees a complete vehicle, and CANape on another monitor connected to the same bus, measuring inverter-internal signals via XCP and tuning the q-axis current PI gains live. The two programs share the bus through the same CAN interface — typically a Vector VN1610 or VN1630A — and Vector's drivers arbitrate access cleanly. Combined, they cover virtually the entire span of bench-side work between "a fresh binary just compiled" and "a calibrated, regression-tested release candidate."

References & Further Reading

1. Robert Bosch GmbH. CAN Specification 2.0, Parts A and B. Stuttgart, 1991. The foundational document; still freely available from Bosch.
2. ISO 11898-1:2015. Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling. The current international standard, including CAN-FD.
3. ISO 11898-2:2016. Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit. Defines the physical layer, transceiver behaviour, and common-mode voltage range.
4. ISO 11898-6:2013. Road vehicles — CAN — Part 6: High-speed medium access unit with selective wake-up functionality. The CAN Partial Networking standard.
5. ISO 15765-2:2024. Road vehicles — Diagnostic communication over CAN (DoCAN) — Part 2: Transport protocol and network layer services. ISO-TP, the basis for UDS over CAN.
6. ISO 14229-1:2020. Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer. The vocabulary of every modern scan tool.
7. SAE J1939 family of standards. Recommended Practice for Serial Control and Communications Heavy Duty Vehicle Network. The 29-bit-ID protocol used in trucks and increasingly in electric commercial vehicles.
8. ISO 15118-1/-2/-20. Road vehicles — Vehicle to grid communication interface. Plug-and-Charge, used over PLC for CCS DC fast charging.
9. CHAdeMO Association. CHAdeMO Protocol Specification. CAN-based DC fast-charging protocol.
10. K. Etschberger. Controller Area Network: Basics, Protocols, Chips and Applications. IXXAT Press, 2001. Still one of the clearest tutorial books.
11. M. Di Natale, H. Zeng, P. Giusto, A. Ghosal. Understanding and Using the Controller Area Network Communication Protocol: Theory and Practice. Springer, 2012. Excellent on schedulability analysis and timing.
12. Vector Informatik GmbH. CANoe / CANalyzer Users' Manual. Reference for DBC files, real-time bus simulation, and CAPL scripting.
13. AUTOSAR Classic Platform. Specification of CAN Driver, CAN Interface, CAN State Manager, PduR, Com (current revision). Defines the layered automotive software stack on top of CAN.
14. F. Hartwich. CAN with Flexible Data-Rate. Bosch white paper, 2012. The introductory paper for CAN-FD.
15. CiA 601-3. CAN XL specifications. The forthcoming successor to CAN-FD, with up to 2048-byte payloads.
16. ASAM e.V. ASAM MCD-1 XCP — Universal Measurement and Calibration Protocol, Part 1 (Overview), Part 2 (Protocol Layer), Part 3 (Transport Layers — XCP on CAN, FlexRay, Ethernet, USB, SxI). The defining XCP standard.
17. ASAM e.V. ASAM MCD-2 MC (ASAP2 / A2L). The ECU description file format consumed by every measurement and calibration tool.
18. ASAM e.V. ASAM MDF 4.x. The standardised measurement data format used by CANape, INCA, and most automotive loggers.
19. A. Patzer, R. Zaiser. XCP — The Standard Protocol for ECU Development. Vector Informatik whitepaper, freely available. The clearest introductory text on XCP.
20. Vector Informatik. VN1630A Product Information & XL-Driver Library Manual. Hardware reference for the four-channel CAN-FD / LIN interface and the host driver API.
21. PEAK-System Technik. PCAN-Basic API Documentation. Reference for the cross-platform driver used with PEAK hardware.
22. R. Hartkopp et al. SocketCAN — Controller Area Network Protocols on Linux. Linux kernel documentation; the basis for python-can and most open-source automotive tooling on Linux.
23. K. Lennartsson. CAN, CAN-FD and CAN-XL in Automotive. Kvaser AB technical article. Useful comparison of the three protocol variants in production use.