CAN BUS · MATLAB · SIMULINK · DBC · SIL · DIAGNOSTICS

CAN BUS NETWORK SIMULATION

Designing, validating and fault-testing a multi-ECU motorsport CAN network using a DBC-defined Software-in-the-Loop architecture.

EXECUTIVE SUMMARY

From signal definition to a fault-aware vehicle communication network.

This project develops a motorsport CAN communication architecture from first principles. A communication matrix and DBC database define the signals before the network is implemented within MATLAB and Simulink, expanded across four virtual ECUs and subjected to controlled communication and signal faults.

The objective was not simply to demonstrate CAN message transmission, but to investigate the complete engineering chain from physical vehicle signals to raw CAN data, network timing, signal reconstruction and vehicle-level diagnostic behaviour.

ENGINEERING QUESTION

Can a complete multi-rate vehicle CAN network be designed, validated and diagnosed entirely within Software-in-the-Loop?

The investigation considers both normal CAN communication and faulted operation, exploring how engineering signals are encoded, transmitted, reconstructed and monitored for communication or plausibility failures.

01

DEVELOPMENT WORKFLOW

From network definition to diagnostics.

01

CAN Message Design

Define CAN identifiers, signals, scaling, offsets, bit allocation, byte order and message update rates.

02

SIL Validation

Validate DBC-based signal encoding and decoding using MATLAB and Simulink.

03

Network Integration

Combine four virtual ECUs operating at multiple update frequencies into one vehicle architecture.

04

Fault Diagnostics

Inject controlled CAN and signal faults, detect abnormal behaviour and classify diagnostic states.

02

STAGE 1 · CAN MESSAGE DESIGN

Defining the network before building it.

Development began with a communication matrix defining the structure of the vehicle network. Each engineering signal was assigned a CAN identifier, start bit, bit length, data type, scaling factor, offset, physical range and byte order.

These definitions were then transferred into a common DBC database, providing a single definition of the communication architecture for both transmitting and receiving systems.

SIGNAL CONVERSION xphysical = xraw × factor + offset
0x100 ENGINE ECU ENGINE_DATA · 100 Hz
0x200 BRAKE ECU BRAKE_DATA · 100 Hz
0x300 CHASSIS ECU WHEEL_SPEEDS · 200 Hz
0x400 STEERING WHEEL ECU DRIVER_INPUTS · 50 Hz

COMMUNICATION MATRIX

Multi-rate CAN architecture.

ECU MESSAGE CAN ID SIGNALS RATE PERIOD
Engine ECU ENGINE_DATA 0x100 3 100 Hz 10 ms
Brake ECU BRAKE_DATA 0x200 2 100 Hz 10 ms
Chassis ECU WHEEL_SPEEDS 0x300 4 200 Hz 5 ms
Steering Wheel ECU DRIVER_INPUTS 0x400 4 50 Hz 20 ms

MATLAB VALIDATION

Verifying the DBC before network integration.

Before progressing to the Simulink network, the ENGINE_DATA definition was independently validated in MATLAB using known engineering inputs. Physical values were manually converted to their raw CAN representation, assembled into an 8-byte payload and decoded through the DBC.

TEST CASE

Known inputs. Known payload. Verified output.

Three representative engine signals were selected to test scaling, offset handling, byte allocation and DBC decoding before the same database was used within the wider CAN network.

ENGINE SPEED 10,000 rpm
THROTTLE 80 %
COOLANT 95 °C
01 KNOWN INPUT Physical engineering values
→
02 RAW CAN Apply factor + offset
→
03 DBC DECODE Reconstruct physical signals
→
04 PASS / FAIL Compare against known input
ENGINE_DATA · 0x100

Expected 8-byte CAN payload

40 9C C8 87 00 00 00 00
MATLAB CAN_DBC_Validation.m
STAGE 1 
% Define known engineering values
expectedEngineSpeed = 10000;   % rpm
expectedThrottle    = 80;      % %
expectedCoolant     = 95;      % degC

% Convert physical values to raw CAN values
% Raw = (Physical - Offset) / Factor
rawEngine   = expectedEngineSpeed / 0.25;
rawThrottle = expectedThrottle / 0.4;
rawCoolant  = (expectedCoolant - (-40)) / 1;

% Construct expected 8-byte CAN payload
payload = uint8([ ...
    hex2dec('40'), hex2dec('9C'), ...
    hex2dec('C8'), hex2dec('87'), ...
    0, 0, 0, 0]);

msg.Data = payload;

% Decode using DBC signal definitions
decodedEngineSpeed = msg.Signals.EngineSpeed;
decodedThrottle    = msg.Signals.ThrottlePosition;
decodedCoolant     = msg.Signals.CoolantTemperature;

% Automated validation
tolerance = 1e-6;

enginePass = ...
    abs(decodedEngineSpeed - expectedEngineSpeed) < tolerance;

throttlePass = ...
    abs(decodedThrottle - expectedThrottle) < tolerance;

coolantPass = ...
    abs(decodedCoolant - expectedCoolant) < tolerance;

% Overall validation result
if enginePass && throttlePass && coolantPass
    fprintf("OVERALL DBC VALIDATION: PASS\n");
else
    fprintf("OVERALL DBC VALIDATION: FAIL\n");
end
ENGINE_DATA · CAN ID 0x100

03

STAGE 2 · SIMULINK VIRTUAL CAN NETWORK

From engineering signals to CAN messages.

A Software-in-the-Loop model was developed using CAN Pack and CAN Unpack blocks. Known vehicle signals were encoded using the common DBC definition and then reconstructed at the receiving side.

Engine ECU CAN Simulink architecture
Engine ECU SIL architecture used to validate CAN encoding and decoding.
DYNAMIC SIGNAL → ECU SAMPLING → CAN PACK → CAN MESSAGE → CAN UNPACK

SIGNAL TIMING

Signal resolution and update rate are not the same thing.

Dynamic signal testing highlighted two independent sources of discretisation within the communication system.

01

Amplitude Quantisation

Determined by the scaling resolution specified within the DBC definition.

02

Temporal Discretisation

Determined by the update frequency of the transmitting ECU.

ENGINE_DATA UPDATE PERIOD Ts = 1 / 100 = 10 ms
100 Hz CAN signal sampling result
Dynamic input signal compared against the discretised ECU output, demonstrating sample-and-hold behaviour introduced by the defined CAN message update period.

04

STAGE 3 · MULTI-ECU NETWORK

Building the complete vehicle architecture.

The validated Engine ECU methodology was extended to the Brake, Chassis and Steering Wheel ECUs.

Each virtual ECU operates independently at its assigned update frequency while using the same DBC-defined communication architecture.

ENGINE ECU BRAKE ECU CHASSIS ECU STEERING WHEEL ECU
→
4 CAN MESSAGES VEHICLE
DATA LOGGER 13 decoded signals

INTEGRATED ARCHITECTURE

Four ECUs operating simultaneously.

The integrated model allows all four message groups to operate simultaneously while retaining their independent signal behaviour and specified update periods.

Complete multi ECU CAN network in Simulink
Complete multi-ECU Software-in-the-Loop CAN architecture.
4 VIRTUAL ECUs
4 CAN MESSAGES
13 ENGINEERING SIGNALS
3 UPDATE FREQUENCIES

05

STAGE 4 · FAULT INJECTION & DIAGNOSTICS

Moving from communication to fault-aware behaviour.

Once the known-good network had been validated, controlled faults were introduced to investigate how configuration errors, communication loss and implausible signal behaviour affect the receiving system.

01

Incorrect Scaling

Investigated how an incorrect DBC scaling definition can produce an incorrect engineering value while the underlying CAN payload remains valid.

02

Endianness Fault

Demonstrated how incorrect byte-order interpretation can reconstruct valid raw data into unrealistic engineering values.

03

Message Timeout

Deliberately interrupted WHEEL_SPEEDS transmission and detected the communication loss using persistence-based monitoring.

04

Signal Corruption

Injected an implausible wheel-speed value into an otherwise valid CAN message and detected the failure using cross-signal plausibility.

COMMUNICATION DIAGNOSTICS

Detecting loss of the WHEEL_SPEEDS message.

WHEEL_SPEEDS operates at 200 Hz, corresponding to a nominal message period of 5 ms.

MESSAGE PERIOD 5 ms

Transmission was deliberately disabled to reproduce a communication loss. A consecutive missing-message counter monitored the persistence of the failure.

TIMEOUT CRITERION 4 missed messages = 20 ms

Once the persistence criterion was exceeded, the WHEEL_SPEED_CAN_TIMEOUT diagnostic was asserted. Restoring transmission reset the counter and cleared the diagnostic state.

CAN wheel speed message timeout diagnostic
Missing-message counter and resulting CAN timeout diagnostic.

SIGNAL PLAUSIBILITY

Detecting a valid CAN message carrying invalid data.

Communication monitoring alone cannot identify every CAN-related failure. A message may remain structurally valid while containing an incorrect engineering value.

Fault Injection

Between 4 s and 6 s, the front-left wheel speed was deliberately corrupted to 300 km/h while the remaining three wheel-speed channels continued to follow their nominal profiles.

INJECTED VALUE VFL,fault = 300 km/h

Reference Speed

A reference vehicle speed was estimated using the remaining three wheel-speed measurements.

Vref = (VFR + VRL + VRR) / 3

Residual Monitoring

rFL = |VFL − Vref|

The absolute residual was compared against the selected plausibility threshold, allowing the corrupted wheel-speed signal to be identified even though the CAN message continued to transmit correctly.

Front-left wheel-speed corruption
Front-left wheel-speed corruption introduced while the remaining wheel-speed channels retain their nominal profiles.
Wheel-speed plausibility diagnostic
Plausibility diagnostic response following detection of an excessive wheel-speed residual.

DIAGNOSTIC WORKFLOW

From injected fault to diagnostic classification.

FAULT INJECTION CAN TRANSMISSION CAN DECODING SIGNAL MONITORING FAULT DETECTION DIAGNOSTIC CLASSIFICATION

CENTRALISED DIAGNOSTIC MANAGER

One vehicle-level diagnostic output.

The CAN timeout and wheel-speed plausibility diagnostics were consolidated within a central diagnostic manager.

A Boolean FaultActive output identifies whether any monitored condition is present, while a numerical FaultCode distinguishes between the individual and combined fault states.

0 Healthy 1 Plausibility Fault 2 CAN Timeout 3 Combined Fault

INTEGRATED VALIDATION

Distinguishing multiple network fault states.

The final validation combined the communication timeout and signal plausibility diagnostics within a central diagnostic manager. Each condition was assigned a numerical contribution, allowing individual and simultaneous faults to be distinguished using a single FaultCode output.

Diagnostic Classification

The plausibility and timeout diagnostics were combined into a single numerical output, allowing the diagnostic manager to distinguish between healthy operation, individual faults and simultaneous fault conditions.

DIAGNOSTIC LOGIC

FaultCode = PlausibilityFault + 2 × CANTimeout

Final Results

The integrated validation successfully distinguished healthy operation, an isolated plausibility fault, an isolated CAN timeout and a simultaneous combined fault. Each condition produced the expected FaultCode, confirming correct diagnostic classification across all four test states.

Integrated CAN diagnostic manager and FaultCode validation
Integrated diagnostic manager combining wheel-speed plausibility and CAN timeout detection. The resulting FaultCode distinguishes healthy (0), plausibility (1), timeout (2) and combined fault (3) states.
0 HEALTHY

No diagnostic fault active.

1 PLAUSIBILITY

Wheel-speed plausibility fault.

2 CAN TIMEOUT

Wheel-speed CAN communication timeout.

3 COMBINED FAULT

Plausibility and timeout faults active.

MODEL SCOPE

What the SIL model represents.

The project validates logical CAN communication, DBC-defined encoding and decoding, ECU organisation, multi-rate timing and diagnostic behaviour.

The current model does not represent the electrical CAN physical layer, differential CAN High/CAN Low signalling, physical termination, propagation delay, physical bus loading, shared-bus arbitration or hardware transmission and reception.

KEY TAKEAWAYS

From CAN definition to diagnostic classification.

01

Designed a DBC-defined motorsport CAN architecture from a communication matrix.

02

Validated signal packing, decoding, scaling, quantisation and multi-rate ECU timing.

03

Integrated four virtual ECUs and 13 engineering signals into a central Vehicle Data Logger.

04

Implemented controlled fault injection, timeout detection, plausibility monitoring and centralised diagnostic classification.

SOURCE CODE

Explore the implementation.

MATLAB validation scripts, CAN definitions and supporting project files are available within the project repository.

VIEW ON GITHUB ↗