EV Charger Local Manufacturing Partner

What local manufacturing actually means

The term covers four different things, and conflating them is why localization budgets go wrong.

1. 1

   Assembly localization

   Parts arrive, your line puts them together and tests them. Value add is labour and logistics. Capability required is modest.

2. 2

   Electronics localization

   Boards are built locally from an approved manufacturing pack. Process control starts to matter here, because a charger board carries metering accuracy and protection functions that do not announce themselves when they degrade.

3. 3

   Supplier localization

   Parts are sourced domestically under change control. This is the stage that delivers real landed cost improvement, and the stage where uncontrolled substitution does the most damage.

4. 4

   Technology transfer

   Design and manufacturing assets, know-how and lifecycle responsibility move to you under a defined agreement.

Most programmes need the first two or three. Very few need all four.

The ladder, and who does what

Each step up adds local value and adds responsibility. There is no stage at which the product becomes simpler. The right stage is the lowest one that satisfies your tariff position, local content target, service model and strategic control goals.

Localization scope matrix

Not every part localizes at the same difficulty. Planning by part rather than by stage produces a more honest schedule.

Production enablement pack

Localization content that stops at a BOM is not a transfer. The enablement pack covers process flow, work instructions and standard operating procedures, tooling, programming method, end-of-line test with defined limits, golden samples, traceability structure and operator training.

Golden samples matter more than teams expect. Without a reference unit that is known good, a drifting test station and a genuinely failing product look identical.

Supplier localization process

Substituting a part is a qualification sequence, not an approval email.

1. 1

   CTQ definition

   Establish what is critical to quality for that part: electrical, thermal, mechanical, EMC, safety and firmware behaviour.

2. 2

   RFQ

   Issue to candidate suppliers against the CTQ set, not against the old part number alone.

3. 3

   Sample

   Receive and inspect against specification.

4. 4

   First article inspection

   Verify the sample against drawing and requirement, documented.

5. 5

   Validation

   Test in the product, under the conditions that matter, including thermal and EMC where the part sits in those paths.

6. 6

   Approval

   Add to the approved vendor list with defined conditions.

7. 7

   ECN control

   Any later change to that part re-enters the process. This is the step most programmes skip, and the one that causes field failures eighteen months later.

Certification impact

Localization changes can require assessment or retesting depending on the target scheme and which parts changed. A packaging change is unlikely to matter. A protection device, metering element, enclosure material or communications module change may. The review happens at the start of each stage so the certification cost sits in the plan rather than being discovered after the pilot build.

RIOD supports certification work and takes products through accredited laboratories. Treat any specific scheme requirement as confirmed by the laboratory and the certification body, not by a supplier claim.

After transfer

Localization does not end at start of production. Components go obsolete. Firmware changes. Units fail in the field in ways laboratories do not reproduce.

• Engineering change control for design and process changes
• Firmware release management and validation
• Certification delta review whenever a change touches a scheme relevant part
• Component obsolescence planning and alternate qualification
• Field root cause analysis across hardware, firmware, protocol and backend

Sustaining this requires the original design team to remain available and accountable after handover, which is a commercial commitment rather than a technical one. It is worth asking any transfer partner how that is staffed, and for how long.

How a programme runs in practice

Programmes do not start with a factory. They start with a small number of units, so both sides learn what the product actually is before anyone commits capital.

1. 1

   Samples

   An initial batch, typically around twenty units, so you can test the platform in your own conditions and with your own customers before committing.

2. 2

   Customisation

   Enclosure and mechanical changes, 3D modelling and moulding, feature and interface changes, and whatever else the product needs to be yours rather than ours. Charged hourly against an agreed scope.

3. 3

   Technology transfer

   The design and production package moves to you: source code, layout, Gerber files, bill of materials, mechanical and assembly files, production documents, manuals and the supporting knowledge base.

4. 4

   Manufacturing localization

   We help you build it at your own site: test jigs, test plans, process optimisation, vendor management, PLM integration and stock management, with our engineers travelling to execute alongside your team.

Most programmes run this sequence in order. Some stop after customisation, which is a legitimate outcome rather than a failed transfer.

What continues afterwards

Localization does not end at start of production, so the relationship usually continues on a monthly support model covering engineering change, firmware releases, field root cause analysis and the questions a new production team has in its first year.

Where the programme also needs software, the same team builds the charging management platform, the operations suite and the charger registry behind it. That is the end-to-end position: hardware, firmware, production capability and the platform, from one engineering organisation.

How this went for one customer

A renewables company in Europe came to us wanting to enter EV charging. They had no chargers in the field yet, which meant they could not answer the first question any manufacturer asks, which is how many units they wanted. Starting from there is the normal case rather than the awkward one, and the sequence below is how it was handled.

1. 1

   Agreement, then samples

   Rather than quote against a volume neither side could forecast, we agreed a programme and shipped product samples so they had something real to put in front of their own market.

2. 2

   Their platform, built alongside

   We developed their charging management system to their own requirements at the same time, so the samples arrived with software that was theirs rather than a login on another company's platform.

3. 3

   Volume, once the samples had proved the case

   Only after the samples had done their work did volume follow. That order matters: it is the difference between buying stock and validating a business.

4. 4

   Mechanical and feature customisation

   The product was reshaped to their form factor and their brand, and the feature set adjusted to what their market actually asked for.

5. 5

   Technology transfer

   Two AC platforms transferred, starting at 3.3 kW: source, layout, Gerber files, bill of materials, mechanical and assembly files, production documents and test plans.

6. 6

   Localization

   We set up the manufacturing arrangements in their market so the product could be built locally rather than shipped from India.

The hardest part was not the engineering. It was vendor management. Building locally means sourcing locally, and qualifying suppliers in a market where we had no existing relationships took longer than the technology transfer itself. Anyone planning a localization programme should budget for that specifically, because it is the part that is invisible until it is on the critical path.

They are in production now and run their own operational system. What they told us surprised them was the speed: they reached their market without the delay a new entrant normally absorbs. The reason is not flattering to the industry. Because we own the stack from the hardware upward, a requirement they raised could be answered the same week rather than routed through three suppliers who each own one layer of it.

What they had tried first

They did not arrive with a blank sheet. They arrived having already made the three mistakes that a new entrant almost always makes, and it is worth naming them because they are cheap to avoid and expensive to unwind.

• They had sampled one or two units. A sample batch that small tells you whether a charger switches on. It does not tell you anything about variation, about field behaviour, or about what your own customers will do with it.
• They had taken white-label software with nothing behind it. It carried their name and none of their data, which meant it looked like a platform and functioned like a demo.
• They had a charger sold to them as OCPP. Its OCPP support was not actually interoperable with what they needed to connect it to. A version number on a datasheet is a claim about a protocol, not a guarantee about your backend.

Those three together are why they moved to a custom product under their own identity. Not because custom is better in the abstract, but because the shortcuts had each failed in a way that cost more to repair than to have done properly.

What most people get wrong about this

The market describes localization as extremely complex. In our experience it is not, and the reason people think otherwise is that they are solving the wrong problem.

OCPP support inside the charger is a small part of the work. It gets most of the attention because it is the part with a version number attached, so it is the part that is easy to specify and easy to argue about. The real problem is operational interoperability: whether the unit does the right thing with the site, the supply, the vehicle and the platform, repeatedly, over years. That is not a messaging question and no protocol version answers it.

Programmes that treat localization as a communications exercise get a charger that talks correctly and behaves badly. Programmes that treat it as an operational exercise find the actual work is ordinary: qualifying suppliers, building test systems, controlling revisions, and training people. Difficult to do carelessly, not difficult to understand.