How to Specify OBC and DC/DC Converter CAN Integration

Specify the CAN interface as a vehicle-system requirement before selecting an OBC or DC/DC converter. The interface must define signals, timing, diagnostics, wake-up and fault reactions, while assigning software ownership for the supplier, vehicle ECU and diagnostic tool.

What should the CAN interface specification contain?

Start with a signal matrix rather than a general statement such as “CAN communication required.” For every transmitted and received signal, define the message identifier, sender, receiver, cycle time, startup behavior, byte position, length, byte order, physical unit, offset, scaling, valid range, default value and failure value. Include alive counters, rolling counters and checksum requirements where the vehicle network requires them.

For an OBC, typical application signals include charging enable, requested AC input current, charging voltage or power limits, operating mode, connector or pilot status, isolation status and charging completion. For a DC/DC converter, the matrix may include enable, requested output voltage, current limit, power limit, measured voltage, measured current and thermal status. The exact list depends on the vehicle architecture and must be agreed from the system requirements, not copied from another programme.

Define whether a signal is a command, a measured value, a limit, a status indication or a diagnostic result. This distinction matters when values conflict. For example, the vehicle controller may request a current limit while the converter independently applies a thermal limit. The interface should state which value has priority and how the effective limit is reported.

Who owns the converter state machine?

Ownership must be explicit. A vehicle control unit may own the complete charging sequence and command the power converter through states such as initialization, standby, precharge, active conversion, controlled stop and fault. Alternatively, the OBC or DC/DC converter may own internal transitions and expose only enable, disable and status signals. Both approaches can work, but an undefined split creates competing timers, unsafe restarts and difficult fault analysis.

Document every state transition and its prerequisites. These may include valid CAN communication, low-voltage supply within range, high-voltage interlock continuity, contactor feedback, insulation status, connector status and absence of latched faults. Specify whether the converter accepts a command immediately after power-up or waits for a valid periodic message. Also define the behavior when a command disappears halfway through a controlled shutdown.

Software ownership should cover the CAN driver, transport protocol, signal packing, network management, application state machine, diagnostic services, bootloader and calibration data. The supplier should identify which functions are delivered as production software, which are configurable, and which must be implemented by the vehicle programme. Agree the interface versioning process before integration testing begins.

How should timing and communication supervision be defined?

Each critical command needs a communication supervision rule. Specify the expected message period, permitted jitter, timeout threshold, startup grace period and reaction after timeout. A missing enable command may require a controlled power reduction, while a missing safety-related limit may require immediate inhibit. Do not use one generic CAN timeout for every signal.

Define the behavior of counters and checksums separately from timeout supervision. A message can arrive on schedule but still contain a repeated, corrupted or out-of-sequence payload. The receiving software should state whether it rejects only the affected signal, invalidates the complete message or enters a fault state. It should also report the communication fault through status signals and diagnostic memory.

Test timing under realistic bus load, including diagnostic traffic, gateway delays, ignition transitions and temporary bus-off recovery. Confirm that the converter does not restart power transfer merely because communication resumes. A restart should require the agreed enable sequence and all electrical safety conditions.

What diagnostics should the OBC or DC/DC converter support?

Define diagnostic access independently from normal control messages. UDS is commonly used to control diagnostic functions in an ECU, including reading fault information and supporting software download; UDS on CAN has a dedicated application profile under ISO 14229-3.[3][8] The programme should specify the diagnostic addressing scheme, sessions, security access, tester-present behavior, negative responses, data identifiers, routines and reset rules.

Agree the diagnostic trouble code catalogue before software release. Each code should identify the monitored condition, debounce method, confirmation criteria, aging or clearing rule, freeze-frame content, warning strategy and recovery behavior. Useful categories include CAN communication loss, invalid command, supply undervoltage, overtemperature, overvoltage, overcurrent, insulation-related input, interlock interruption and internal self-test failure.

Distinguish a present fault from a stored event. A transient overtemperature may cause derating and recover automatically, while a detected internal power-stage fault may require a latched shutdown and service action. State whether clearing a diagnostic code clears the operational inhibit. In many architectures, code deletion alone must not re-enable high-voltage conversion.

How should wake-up and sleep behavior be specified?

Define all wake-up sources: ignition or key state, vehicle network activity, charging connection, scheduled charging request, low-voltage supply change, diagnostic request and external enable input. For each source, state whether it wakes only the CAN transceiver, the control processor or the complete power stage. A wake-up event should not automatically authorize energy transfer.

CAN network management can coordinate transitions between bus-sleep and network operation, and AUTOSAR CAN Network Management defines wake-up behavior through network-management communication.[1][2] Even when the vehicle does not use AUTOSAR, the programme should document equivalent rules: who requests the network to remain awake, which node initiates wake-up, what the first valid application message is and how long the converter remains awake after shutdown.

Specify the sleep-entry sequence. A robust sequence normally stops power conversion, opens or releases the relevant control path according to the vehicle design, stores required diagnostic information, acknowledges shutdown and then disables unnecessary circuitry. Include minimum hold-up time, low-voltage current targets, wake-up latency and behavior during repeated wake-sleep cycling. Check the datasheet for actual quiescent-current and timing limits.

What happens when a CAN command or electrical condition is invalid?

Build a fault-reaction table linking each fault to detection, reaction, reporting and recovery. A communication timeout may trigger controlled ramp-down; an invalid current request may be rejected while the last safe limit remains active; an interlock opening may require immediate inhibit; and a converter internal protection event may latch until a defined reset condition. The vehicle controller and converter must not independently issue contradictory recovery commands.

Define derating separately from shutdown. Derating can preserve operation within thermal, voltage or current limits, but the converter must report the active derating reason and effective output limit. If the vehicle controller continues requesting an unavailable value, the interface should provide a clear status rather than silently clipping the command.

Specify reset behavior for brownout, watchdog reset, CAN controller bus-off, firmware reset and loss of the low-voltage supply. After any reset, define the initial output state, message validity, diagnostic indication and conditions for re-enabling conversion. Validate that contactor sequencing and discharge requirements remain safe even if CAN communication stops at the worst point in the sequence.

What should be frozen before supplier nomination?

Release a controlled interface package containing the CAN database, signal matrix, state diagram, diagnostic specification, network-management rules, fault-reaction table, bootloader requirements, cybersecurity assumptions and test cases. Include example traces for startup, normal operation, controlled stop, timeout, wake-up, bus-off recovery and diagnostic sessions. This package gives suppliers a common basis for quotation and avoids comparing products against different interpretations of “CAN compatible.”

Ask each supplier to mark the interface as native, configurable, requiring custom software or requiring an external gateway. Request a deviation list rather than a general compatibility statement. The response should identify unsupported signals, timing constraints, diagnostic limitations, bootloader dependencies, calibration ownership and any requirement for a separate CAN channel.

Complete bench, hardware-in-the-loop and vehicle testing against the same versioned requirements. Test the nominal path and abnormal paths, including corrupted counters, invalid scaling, delayed commands, lost wake-up frames, diagnostic interruption and simultaneous thermal and communication faults. Product-specific electrical, EMC, environmental and performance values must be taken from the current datasheet and programme validation plan.