EV Charger Technology Transfer

The transfer boundary

Every transfer agreement separates four things. Confusing them is the most common cause of dispute later.

1. 1

   Background IP

   What RIOD owned before the programme started. Platform architecture, existing firmware modules, accumulated design methods. Usually licensed, rarely assigned.

2. 2

   Project IP

   What is created specifically for your programme. Ownership is negotiable and should be settled before work starts, not at handover.

3. 3

   Manufacturing know-how

   How the product is actually built, tested and kept in tolerance. This carries the most commercial value and the least documentation in most transfers.

4. 4

   Licensed rights

   What you may do with the above: manufacture, modify, sublicense, sell, and in which territories.

A transfer that names only the deliverables and skips this section is not finished.

Production files

Production files are the subset a factory actually consumes: BOM and approved vendor list, manufacturing outputs, drawings, work instructions, process flow, tooling specifications and test specifications, released according to the agreement.

The distinction matters because design files and production files serve different readers. An operator does not need the schematic. A production engineer does. Sending everything to everyone is how uncontrolled copies end up on a shop floor.

Firmware handover options

Firmware is where transfer scope varies most, and where expectations most often diverge. Four models, in increasing depth:

1. 1

   Binary only

   You receive signed release images and the programming method. You cannot modify. Lowest risk to both parties, and adequate for most L1 to L3 programmes.

2. 2

   Production build package

   You receive what is needed to program, configure and verify units in production, including calibration and test hooks, without source access.

3. 3

   Controlled source or module access

   Defined modules are shared under licence, typically excluding security sensitive components. Suitable when your team needs to extend behaviour rather than maintain the whole stack.

4. 4

   Full source licence

   Complete access under agreed terms. This requires you to own firmware competence, including secure update handling and the consequences of a bad release reaching the field.

Source access is a commercial decision with an engineering obligation attached. Teams that request full source and lack a firmware function usually end up worse off than with a production build package.

Test system handover

Without transferred test capability, nothing else in the transfer is verifiable. This covers the programming fixture, end-of-line test system, calibration method and interval, test software, pass and fail limits, golden units, and record retention.

Test limits deserve specific attention. Limits that are too tight produce false failures and pressure to override them. Limits that are too loose let marginal units into the field. The limits handed over are the ones the product was characterised against, and changing them is a change control event.

Knowledge transfer

Training is delivered by role, because an operator and a firmware engineer need different things.

• Operators: assembly sequence, handling, ESD discipline, common defects, when to stop and escalate.
• Production engineers: line setup, station configuration, yield analysis, fixture maintenance.
• Quality: inspection method, acceptance criteria, defect classification, audit records.
• Firmware and service: programming, configuration, diagnostics, field failure triage.
• Management: change control obligations, certification consequences, escalation routes.

Competence is recorded, not assumed. A training matrix showing who has been trained on what, and when, is part of the handover.

Acceptance gates

A transfer is accepted in stages, not signed off in one meeting.

1. 1

   Documentation review

   Your team reads the pack and raises gaps before anything is built.

2. 2

   Sample or pilot build

   A small batch built by your people, with ours present.

3. 3

   Line qualification

   The line, fixtures and test stations demonstrate repeatability.

4. 4

   First article inspection

   Formal verification against drawing and specification.

5. 5

   SOP release

   Start of production is authorised against defined criteria.

6. 6

   Stabilization period

   Typically 500 to 1000 production hours, during which yield, defects and field returns are monitored jointly before responsibility fully transfers.

Stabilization is where problems that depend on volume, operator rotation and supplier lot variation become visible. Some are detectable earlier through rate trials and audit sampling, but stabilization is the cheapest place to find them, because responsibility has not yet fully moved.

Post-transfer governance

After start of production the relationship continues through engineering change orders and notices, field root cause analysis, security and firmware updates, component obsolescence management, and certification delta review whenever a change touches a scheme relevant part.

Someone must own each of these. If the agreement does not say who, the answer in practice is no one.

What is actually handed over

In practice a transfer package covers the following, released according to the agreement:

• Firmware source code, or signed binaries, depending on the model agreed
• Electronics layout and Gerber files
• Bill of materials with the approved vendor list
• Mechanical files and assembly files
• Production documents, work instructions and process flow
• Test plans, test jig designs and acceptance limits
• Product manuals and the supporting knowledge base

Both firmware models are available: signed binary only, or full source. Which applies is a commercial decision made at the start rather than discovered at handover.