Charging Module vs. Complete Charger: How to Define Responsibility Boundaries in EV Charger Design

“Charger” can describe a power-conversion module, module pack or PMU, integrated device, or controller/backend. The buyer’s decision is which object is being purchased and who owns the interfaces, evidence and acceptance work. For an EV Charger project evaluating modular EV charging solutions, use one primary artifact: a Layer Responsibility RACI.

Name the four layers once

A single module is primarily a power-conversion object. A module pack or PMU is a separate component set whose BOM, allocation and interfaces must be defined. An integrated charger is a named configuration that may add enclosure, connector, HMI and communications. A controller, CSMS or backend manages software and network scope. These layers can form one system without becoming one evidence object.

OCPP belongs to the communication implementation and its tested object; it is not a property to assign to every power module. Likewise, a module record does not automatically include payment, HMI, connector, site work or complete-charger certification.

Use the Layer Responsibility RACI

“Owner” means the party responsible for defining and proving the item in the project. It does not automatically mean that a supplier must provide it.

For every row, add the object, responsible party, interface owner, acceptance owner, scope and change trigger. The scope should name the model or configuration, software or firmware version, connector or profile, target region where relevant and the evidence document. The acceptance owner is the person who decides whether the result closes the requirement; it is not necessarily the party that supplied the data.

Use concrete wording. “Supplier provides the named module data and deviation response; integrator verifies the module-to-controller interface; project owner accepts the system test” is reviewable. “Supplier provides charger certification” is not reviewable until the object, variant, holder, market and validity are named. Keep an open dependency visible rather than filling it from a family statement.

Apply the RACI at design freeze

Before release, require four checks. First, rewrite every ambiguous “charger” requirement as module, PMU/module pack, integrated charger, CSMS/backend or project system. Second, assign power, control, communication, connector and service interfaces. Third, record model, version, region, certificate holder or test scope where applicable. Fourth, write the acceptance test, logs, deviation process and retest trigger for each layer.

The RACI becomes contractual only when the statement of work, supply boundary and project responsibilities align. Until then, mark it as a proposed responsibility map and keep unowned interfaces open.

If an interface has no owner, the architecture is not ready. If component evidence is complete but system pairing or acceptance is open, record the route as conditional rather than treating the module as the finished charger. If a cabinet, allocation, firmware or protocol profile changes, use the RACI trigger to reopen only the affected rows.

The test rows should follow the same layer split. A module test can close the named power-conversion conditions. An integrated-charger test can close the selected enclosure, connector, control and safety configuration. A controller or backend test can close the communication implementation and project workflow. A vehicle-side or site test may still require its own owner and witness. Keeping these results adjacent but separate is what makes the RACI useful during design freeze.

Keep architecture evidence separate from commercial scope

UUinside material can show ACU, PMU, DCU, DSU, CMS and optional POS as architecture components and can help a team draw the layer map. It does not by itself decide who owns a connector, HMI, payment function, backend, commissioning activity or complete-charger certification in a particular contract. Those rows require the ICD, acceptance plan and agreed project boundary.

UUGreenPower product materials likewise require the buyer to preserve the named layer and page. A module entry can support model-level evidence; an integrated-device entry can support only its named configuration. Neither should be converted into a turnkey, service or backend promise.

When the buyer receives a broad solution description, ask for the ICD, configuration baseline, acceptance plan and statement of work that connect the diagram to the purchased object. If those documents are not available, the architecture map remains a planning aid and the commercial boundary stays open. This protects procurement from treating one labelled block as a complete deliverable.

Before you freeze the architecture

Ask: Which layer is being bought? Who owns every interface? Which tests prove the component and which prove the complete charger? Which responsibilities are documented and which need commercial confirmation? A charging module vs complete charger review is successful when those answers are visible in one RACI, so a modular EV charging solutions discussion can proceed without asking a module supplier to prove a system function it never owned.