CAN-bus vehicle data in one connected timeline.

CAN bus and OBD-II: what is the difference?

CAN is a communication network used by vehicle electronic control units. Its messages carry bytes; the meaning of those bytes depends on the vehicle and the message definition. A CAN interface gives access to traffic, but interpreting it also requires the right signal information.

OBD-II is a diagnostic system. On vehicles that use CAN for diagnostics, supported diagnostic values may be requested over that network. A diagnostic connector does not mean every internal signal is available, nor that it arrives fast enough for every analysis task.

Which vehicle signals can you integrate?

Engine speed, vehicle speed or selected temperature values are possible examples, where the vehicle and its supported protocol expose them. They are not a guaranteed CU CAN channel list. Driver inputs and other manufacturer-specific data require their own compatibility check.

For each proposed signal, establish its source, units, scaling and update rate. A documented signal map, sometimes supplied as a DBC file, can describe how a raw message becomes a value. Missing or undocumented signals should remain identified as unavailable rather than inferred as measured data.

A practical vehicle-data integration workflow

Start with the decision you want to make: understand an operating condition, review a journey or investigate a change in vehicle response. Then agree which signals are needed and which the vehicle can actually provide.

1. Identify the vehicle model, year, ECU and intended connection.
2. Review the available protocol documentation and signal definitions.
3. Plan the installation and data capture with a qualified technician.
4. Validate units, timestamps and missing data against a known reference.
5. Review the accepted channels alongside position and history in CUPlatform, where supported by the evaluation setup.

Why put vehicle signals and position on one timeline?

An isolated value rarely explains an event. Time and location can help distinguish a recurring operating condition from a one-off change. Comparing sessions also requires consistent channels, units and test conditions.

CU CAN is being developed to bring compatible signals and route context into CUPlatform. The website's animated track views are simulations; they do not demonstrate a validated CU CAN installation or promise a specific sampling rate.

What to send for a compatibility discussion

Tell us the vehicle make, model and year, the ECU if known, the signals you need and the question you want to answer. Include any protocol documentation you are authorised to share and whether the use is on road, on track or on a test bench.

We can then scope an evaluation and identify open engineering questions. Connector, electrical, environmental and vehicle-specific validation remain part of the work; a matching connector alone is not confirmation of compatibility.

Questions before you start

Is CU CAN a universal OBD-II scanner?

No. CU CAN is a vehicle-data integration programme in development. Support must be assessed for the specific vehicle and channels; it is not presented as a universal diagnostic or fault-code tool.

Does CAN-bus integration require a DBC file?

It requires reliable definitions for the signals being decoded. A DBC file is one way to document them; supported diagnostic values can use documented diagnostic definitions instead. A connection alone does not establish what each message means.

Can I use CU CAN Bike for my motorcycle?

CU CAN Bike is the separate motorcycle telemetry prototype. The bike, ECU, required measurements and installation need an evaluation before compatibility or performance can be confirmed.