OBC and DC/DC Converter Software Requirements for Vehicle Integration

OBC and DC/DC converter software must be specified as part of the vehicle E/E architecture, not treated as a supplier-only function. The integration baseline should define CAN signals and UDS diagnostics, bootloader behavior, calibration ownership, cybersecurity interfaces, update recovery, and formal change control before validation begins.

What software information must the OEM define first?

The OEM should provide a software interface control document covering network topology, CAN or Ethernet transport, message ownership, signal scaling, timing, startup sequencing, diagnostic addressing, and permitted operating states. The OBC and DC/DC converter cannot be integrated reliably from a signal list alone: enable conditions, wake-up behavior, shutdown delays, isolation states, contactor dependencies, and fallback actions also need definition.

For CAN-based diagnostics, the project should identify the applicable UDS profile, transport-layer assumptions, diagnostic session behavior, security-access method, data identifiers, routine controls, and negative-response handling. ISO 14229-1 defines the general UDS application layer, while ISO 14229-3 specifies the UDS-on-CAN profile and its CAN-specific restrictions.[2][4]

The interface should distinguish commands from status reporting. For example, a charge-enable request, voltage or current limit, operating mode, and wake request should each have defined validity rules. The converter should report measured values, derating state, active limits, diagnostic state, and shutdown reason without forcing the vehicle controller to infer them from missing messages.

How should CAN diagnostics be structured?

Diagnostics should cover both electrical faults and software state. Typical categories include input undervoltage or overvoltage, output overvoltage, overtemperature, overcurrent, isolation concerns, communication timeout, invalid command, internal watchdog reset, nonvolatile-memory error, and incompatible software or calibration data. Each event needs a status model, debouncing rule, healing condition, snapshot requirement, and reaction level.

The DTC strategy should state whether a fault is warning-only, power-limiting, latched until a service routine, or immediately shutdown-critical. Freeze-frame content may include converter state, commanded and measured values, temperatures, bus voltage, reset cause, and software identifiers. The exact data set depends on the vehicle diagnostic concept and should be agreed before testing rather than copied from a generic converter template.

Diagnostic timing is equally important. The OEM and supplier should agree on response time, P2 and P2* behavior, session timeouts, bus-load assumptions, and whether diagnostic communication is available during charging, sleep transition, and service mode. A converter that enters a protective state must still communicate enough information for the vehicle to distinguish a hardware fault from a network or sequencing problem.

Which bootloader strategy supports vehicle production and service?

A production bootloader should support controlled entry, software identification, compatibility checks, programming, verification, and recovery after interruption. The memory layout should reserve clearly defined areas for bootloader, application, calibration, diagnostic data, and recovery metadata. The supplier should provide the memory map and programming dependencies under configuration control; exact addresses should not be assumed across hardware variants.

Programming authorization should use the vehicle cybersecurity architecture rather than an open engineering access path. The bootloader should verify image integrity and authenticity, reject incompatible hardware or dependency combinations, and record programming results. A failed update must leave the converter in a recoverable state, such as a validated previous application or an approved recovery image.

The release package should identify the application version, bootloader compatibility, calibration compatibility, hardware revision, checksum or cryptographic verification data, and required diagnostic sequence. Factory programming, end-of-line replacement, dealer service, and over-the-air or workshop updates may use different workflows, but they should use a common versioning logic and produce traceable records.

How should calibration access and parameter ownership be controlled?

Calibration must be separated from unrestricted software development access. Define which parameters are tunable, which are production-fixed, which are safety-related, and which require a controlled service routine. Limits for voltage, current, thermal protection, ramp rates, sleep timing, and fault thresholds should have an owner, engineering rationale, allowed range, and validation evidence.

During development, measurement and calibration tools may use an agreed interface such as XCP where appropriate. AUTOSAR documentation describes XCP functions including synchronous measurement, stimulation, online memory calibration, calibration-page switching, and development flash programming.[10] That capability should be disabled, restricted, or cryptographically controlled in production according to the OEM security concept.

Calibration files should carry a part or platform identifier, hardware compatibility, software compatibility, parameter-set revision, checksum or signature, and approval status. The vehicle controller should not silently accept an incompatible parameter set. If the converter supports multiple calibration pages, the active-page transition must be deterministic and recoverable after reset or power loss.

What cybersecurity interfaces belong in the converter requirement?

The converter requirement should identify trust boundaries and external interfaces: CAN or Ethernet diagnostics, bootloader access, calibration tools, gateway routing, manufacturing stations, service tools, and any backend update path. For each interface, specify authentication, authorization, message protection where required, key provisioning, access logging, lockout behavior, and the response to failed authorization.

Security must also cover normal control messages. Plausibility checks, freshness or timeout monitoring, range checks, and state-dependent command acceptance reduce the risk that a malformed or replayed command produces unsafe power behavior. A converter should reject commands that are numerically valid but operationally impossible, such as an enable request during an invalid high-voltage state.

The software package should support vulnerability handling throughout the vehicle programme. Define who receives vulnerability reports, how affected versions are identified, how a mitigation is tested, and how service or fleet campaigns are authorized. Cybersecurity controls must not prevent a safe recovery path when a vehicle has an interrupted update or a converter fault.

How should software changes be managed across variants?

Every software release should be tied to a defined hardware revision, vehicle programme, communication database, calibration set, bootloader version, and diagnostic specification. The change record should state the reason, affected functions, safety and cybersecurity impact, test evidence, backward-compatibility result, and production disposition.

Configuration management should cover source code, generated communication files, diagnostic databases, calibration data, bootloader packages, test scripts, and release notes. A change to a CAN scaling factor or diagnostic identifier can be as significant as an algorithm change because it may affect the vehicle controller, gateway, service tool, and end-of-line test system.

Variant handling should avoid uncontrolled forks. Use a common software baseline with explicitly managed feature flags or configuration variants where practical. Before approving a change, run interface regression tests, power-state tests, fault-injection tests, update tests, thermal and electrical protection tests, and vehicle-level compatibility checks. The acceptance matrix should show which tests apply to each hardware and vehicle variant.

Which integration option fits the programme lifecycle?

The right software arrangement depends on the OEM’s ownership model, diagnostic infrastructure, update strategy, and service responsibilities. The options below describe engineering trade-offs rather than product rankings.

The choice should be frozen before design verification. Changing from direct CAN diagnostics to gateway-routed UDS late in the programme can affect addressing, timing, security access, test equipment, manufacturing stations, and service documentation. Likewise, moving calibration ownership from the supplier to the OEM requires tool, data, approval, and field-support changes.

What should the software handover package contain?

The handover should include the software interface specification, CAN database, diagnostic specification, DTC list, UDS service matrix, bootloader protocol, memory map, release binaries, calibration files, compatibility rules, cybersecurity assumptions, and known limitations. It should also include reset-cause definitions, state-machine descriptions, fault-reaction tables, and the test evidence supporting each safety-relevant behavior.

For production readiness, provide end-of-line programming and test instructions, service-tool requirements, update recovery instructions, version-reading procedures, and a method for identifying the installed hardware, application, bootloader, and calibration versions. The OEM should be able to determine whether a field issue comes from hardware, software, calibration, communication, installation, or vehicle sequencing without returning immediately to the supplier.

Before programme sign-off, conduct a joint review using real vehicle power transitions and network conditions. Verify cold start, wake-up, charging enable, charging interruption, sleep entry, low-voltage recovery, high-voltage shutdown, diagnostic sessions, interrupted programming, invalid commands, and fault recovery. Final numerical limits, identifiers, timings, and compatibility rules must come from the approved project datasheet and interface baseline.