DC Charger Control Card Development
A charger's control card is the part that decides whether the product is yours. Power modules can be sourced and enclosures can be fabricated, but the controller holds the safety logic, the vehicle conversation and the behaviour a customer experiences. RIOD designs control cards, including DC cards, to a client's feature set and protocol targets rather than selling one from a catalogue.
The supervisory control card: what any charger controller has to do as a baseline, what changes in DC, how the design is partitioned so safety functions stay independent of network facing code, and how the work is supported from requirements through to a package another factory can build.
Discuss a control cardFor A manufacturer building or localizing a DC fast charger who needs the control electronics designed rather than bought as a black box.
What the control card is responsible for
In an AC charger the controller is comparatively simple, because the vehicle does the conversion. In DC the charger is the power supply, and the controller is negotiating current and voltage with the vehicle continuously while a large amount of energy moves.
- Vehicle communication over the high level protocol, including the plug and charge path where required
- Control pilot and proximity handling, and the sequencing that has to happen before contactors close
- Setpoint control to the power modules, and the closed loop that keeps delivery inside what the vehicle asked for
- Safety interlocks: insulation monitoring, isolation checks, emergency stop, door and panel interlocks
- Thermal management of modules, cable and connector, including cooled cable where fitted
- Metering, transaction handling and the OCPP conversation with the backend
- Human interface, payment path and whatever the site requires locally
How the work is partitioned
The common mistake is to put everything on one processor because it is cheaper on the bill of materials. It is cheaper right up to the point where a certification body asks how the safety functions are protected from the application code.
Swipe to compare
| Domain | What lives there | Why it is separated |
|---|---|---|
| Safety and control | Interlocks, isolation monitoring, contactor sequencing, current limiting | Constrained, auditable, changes rarely, must be provably independent of the rest |
| Vehicle communication | High level protocol stack, control pilot state machine | Timing sensitive, standards driven, evolves with vehicle behaviour |
| Application and connectivity | OCPP, UI, payments, telemetry, updates | Changes often, network facing, must never be able to affect the safety domain |
The boundary between the third row and the first two is the one that matters. Anything reachable from a network must be unable to influence contactor sequencing or current limits by design, not by convention.
Design decisions that are expensive to reverse
- 1
Power module interface
Which modules, over what interface, and how tightly the control logic assumes their behaviour. Coupling too closely to one vendor makes the product hostage to that vendor's roadmap and pricing.
- 2
Processor headroom
Specified for what the product will do in year five, including protocol versions and security work that does not exist yet. This is where DC controllers most often run out.
- 3
Isolation strategy
Where the barriers sit between high voltage, control and communications. Moving one later is a board respin and a recertification.
- 4
Update path
How each processor is updated in the field, and how a failed update is recovered. A DC charger that needs a laptop and an open panel to update is an unpriced maintenance contract.
- 5
Diagnostic access
What the card records and exposes when something goes wrong. This decides whether a field fault costs a remote session or a site visit.
Designing for local manufacture
A control card designed for a prototype and a control card designed to be built at volume in another country are different boards, and the difference is not cost reduction.
- Component selection weighted toward parts with more than one qualified source in the target market
- Test points and boundary access designed in from the start, so an end-of-line jig can exercise the board rather than infer from the outside
- Programming and provisioning designed as a production step with a defined jig, not as something an engineer does with a cable
- Documentation set that a receiving factory can build from: layout, Gerber, bill of materials with alternates, assembly files and process notes
If localization is the eventual intent, say so at the start. Retrofitting testability and second sourcing into a finished design costs more than designing for it, and it usually arrives as a surprise during the readiness audit.
The default feature set of a charger control card
Before customisation there is a baseline. Almost every charger control card has to do the following, and a specification that omits any of them is usually a specification that has not been finished rather than a product that does not need them.
Swipe to compare
| Function | What it covers |
|---|---|
| Vehicle interface | Control pilot generation and sensing, proximity detection, state machine per IEC 61851, and the high level protocol where ISO 15118 applies |
| Contactor and relay control | Sequencing, welded contact detection, and the interlocks that must be satisfied before anything closes |
| Protection interface | Residual current, overcurrent, over and under voltage, earth continuity, over temperature, and the trip paths that must work independently of application code |
| Current control | Advertising an available current, changing it mid-session, and enforcing site or group limits |
| Metering | Internal energy measurement, and the interface to external meters over Modbus where billing grade measurement is required |
| Connectivity | Ethernet, Wi-Fi, cellular or a combination, with the failover behaviour between them |
| Protocol stack | OCPP 1.6J or 2.0.1, transaction handling, configuration, diagnostics and remote commands |
| Authentication | RFID, app or backend authorisation, plus local whitelist for offline operation |
| Firmware update | Over the air update with verification, rollback and a recovery path for a failed update |
| Security | Secure boot, signed firmware, key storage, and certificate handling where the security profile requires it |
| Human interface | Status indication, display where fitted, and whatever the market expects at the unit |
| Local logging | Events, faults and session records retained locally so a unit can explain itself after the fact |
| Real time clock | Maintained across power loss, because certificate validation and session records both depend on it |
| Diagnostics | Fault codes that distinguish causes, and remote access to logs without a site visit |
In a DC card, three of these change character. Current control becomes closed loop setpoint control against power modules rather than an advertised limit. Protection gains insulation monitoring and isolation testing before contactors close. And the vehicle interface carries a full high level protocol conversation rather than a duty cycle.
How we support the design work
Control cards are designed to a client's requirements rather than sold from a catalogue. The feature set, the protocol targets and the market decide the board, and the engagement can start at any of these points rather than only at the beginning.
- 1
Requirements and architecture
Turning a feature list and a target market into a domain split, a processor selection and an interface plan. This is where OCPP version and ISO 15118 scope get settled, because both drive memory and crypto requirements.
- 2
Schematic and layout
Full electronics design, with isolation strategy and test access designed in rather than added afterwards.
- 3
Firmware
Protocol stack, control logic and the hardware abstraction between them, structured so a later protocol migration does not mean a rewrite.
- 4
Bring-up and validation
First articles exercised against real vehicles and a real backend, not only against a simulator.
- 5
Test systems
End-of-line jigs and programming jigs, so the board can be built and verified at volume rather than checked by an engineer.
- 6
Transfer
Layout, Gerber, bill of materials with alternates, assembly files and production documents, where the intent is to build it elsewhere.
Customisation is scoped against an agreed feature list and charged hourly, because the range between adding an interface and redesigning a domain is wide enough that a fixed price would be wrong in one direction or the other.
What sits with the customer
Type approval of the finished charger is the manufacturer's, not the control card designer's. The card is designed to support it, with the architecture, documentation and evidence a test house will ask for, but the product certification belongs to whoever puts it on the market.
We say this early because it is occasionally assumed to come with the design work, and discovering otherwise at submission is expensive.
Want this applied to your own site?
Discuss a control cardTechnically reviewed by Deepu Joy, Director of Products and Delivery. Last reviewed 2026-09-10.
Frequently asked questions
Do you design control cards to our own requirements?
Yes. Cards are designed to the feature set you need and to your protocol targets, typically OCPP and ISO 15118, rather than sold as a fixed product. The engagement can start at requirements or pick up an existing design.
What does a control card have to do as a baseline?
Vehicle interface, contactor sequencing, protection interface, current control, metering, connectivity, protocol stack, authentication, firmware update, security, human interface, local logging, a maintained clock and diagnostics. The table above sets out what each covers.
Do you design the power stage as well?
The control card is the supervisory and communications side. Power module selection and integration are part of the work; designing the converter topology itself is a different engagement and should be scoped as one.
Can it be built around power modules we have already chosen?
Yes, and that is the common case. The interface to those modules is one of the first design decisions, and we will flag where a chosen module ties the product tightly to one vendor.
Why separate safety onto its own domain?
So that network facing code cannot influence contactor sequencing or current limits by design rather than by convention. It also makes the safety argument to a test house far simpler.
Do you handle certification?
We design to support it and prepare the evidence, and we can work alongside your test house. Type approval of the finished product belongs to whoever places it on the market.
Is this only for DC?
Everything above is written for DC. AC control electronics are a smaller problem with a different shape, and are covered under hardware development.
Building a DC charger and want to own the controller?
Tell us the power modules you are considering, the target market and whether local manufacture is the eventual intent. Those three set most of the design.
Discuss a control card