Multi-Vendor Power and Control Integration

Most of the systems I work on are assembled from products that were never designed together. Battery management comes from one manufacturer, charging and power conversion from another, and DC distribution, monitoring, supervisory control, and the human-machine interface from others still. They are expected to behave as one system, usually over a shared CAN bus and a protocol like RV-C that each of them implements with its own reading of the optional parts. I integrate those products into one system, and then I investigate the failures that only show up once they are operating as one.

A protocol specification settles less than people expect. It says what a message means, but it leaves open how soon a device answers, how often it repeats its status, what it does with a command for a mode it doesn’t support, and who is in charge when two controllers both think they are. Two devices can each pass their manufacturer’s compliance tests and still disagree about all of that. Sometimes they can’t even share a wire. Victron’s own CAN products and an RV-C network run at the same bit rate on the same kind of cable, but they use different identifier spaces, so a GX device keeps them on separate, isolated CAN ports and bridges between them in software rather than letting them collide.

That work spans system architecture, device configuration, and CAN/RV-C analysis. The analysis part means putting a logger on the bus in listen-only mode, so it cannot acknowledge a frame and change the thing it is watching, and recording every frame with a timestamp. Intermittent faults have to be reproduced before they can be understood, and the goal of a capture is to turn a fault that happened once in a customer’s vehicle into a sequence of frames that provokes it on a bench. Firmware or configuration changes then have to be validated against that same sequence before anyone relies on them. A good deal of the job is coordination. Manufacturers, installers, customers, and our own engineering team each see a different part of the same failure, and comparing those observations is often how the picture comes together.

The difficult problems are often not contained within any one device. They live between devices, where two products make different assumptions about command timing, reported state, control authority, initialization, or recovery. Command timing: one device sends a command once and expects it to stick, while another expects the command repeated every second and treats silence as a request to stop. Reported state: one device reports the mode it was asked for and another reports the mode it has actually reached, and the difference only matters during the half second when they disagree. Control authority: a display and a supervisory controller both believe they own an inverter’s mode, and each one politely restores the setting the other just changed, which is what the figure is doing, and will keep doing until one of them stops believing it. Initialization: a device that boots a second before the bus it depends on is up may claim an address, miss a status broadcast, or settle into a default no one chose. Recovery: after a fault, one product returns to its last state and another returns to off, and both call that safe. Each device can be behaving exactly as designed while the system, taken together, produces the wrong result.