EVSE Design and Development Services

What development covers

• Requirements definition, including the market and certification targets that constrain everything else
• System architecture: controller topology, protection strategy, metering approach, thermal design
• Electronics design through to a manufacturable board
• Firmware, including the charging state machine and the protocol client
• Protocol and backend integration, tested against the platform you will actually use
• Validation: electrical, thermal, EMC pre-compliance, environmental and interoperability
• Production readiness: test coverage, documentation and pilot support

Where programmes lose time

Three places, consistently. Requirements that name a power level and a protocol but not the market, the supply configuration or the certification target. Architecture decisions deferred until the schematic, when they have already been made implicitly. And EMC discovered at the accredited laboratory rather than at pre-compliance, which converts a design iteration into a schedule slip.

How deep the engagement goes

Development is scoped at the depth the commercial objective needs, from configuring an existing platform through to a product designed from requirements. Choosing a deeper level than necessary is the most common way development budgets overrun.

Design for what happens after launch

A charger is supported for years by people who did not design it, in places nobody visits. Diagnosability, field-updatable firmware with a safe rollback path, and a test architecture that survives transfer to another factory are design inputs rather than later additions.

If local manufacturing is a possibility, say so during architecture. Designing for a future transfer costs little at that point and is expensive to retrofit.

Why one team across the stack changes the timeline

Most charger programmes are assembled from suppliers who each own one layer, and every requirement that crosses a layer becomes a negotiation. Most interesting requirements cross several.

• The hardware vendor, who can change the enclosure and the electronics
• The firmware house, who can change the behaviour but not the hardware it runs on
• The platform provider, who can change what the fleet does but not what the charger is capable of

A customer we built a full programme for told us the thing that surprised them was the speed. The explanation is structural rather than complimentary: because the hardware, the firmware and the platform sit with one team here, a requirement raised does not have to be routed through three organisations who each own part of the answer and none of the responsibility. It gets answered, or it gets refused, quickly.

That is also why we can tell a customer early when something is a bad idea. A supplier who owns one layer can only tell you it is possible in their layer.

Why a custom product is worth building

The argument against custom development is cost and time. The argument for it is that everything else on the market is the same product.

• Your charger looks like yours, not like the same enclosure every other brand is reselling
• Features your market actually asks for, rather than the intersection of what a catalogue product offers everyone
• A specification you control, so a customer requirement does not have to wait for a supplier's roadmap
• Differentiation that persists, because a competitor cannot buy the same thing

In a market where most brands are reselling variations of the same imported design, being visibly and functionally different is worth more than the development costs.

Speed is the thing customers mention

The concern with custom development is always the timeline, and it is the thing we are told surprised people most.

We are not designing a charger from first principles each time. Eight to ten years of charger engineering means the hardware platform, the firmware architecture, the protocol stack and the production approach already exist and are proven in the field. Custom development is applied to that rather than started from nothing.

The practical result is that a customer's own charging product typically arrives in three months, extending to twelve depending on the type and number of products, and without the two years of field problems a first design discovers.