EV Charging Engineering and Technology Consulting

What we consult on

The range is deliberately wide, because the questions that stall a charging business rarely sit inside one discipline. Current work includes consulting for utility companies and electrical panel manufacturers on EV charging station development.

1. 1

   Hardware and firmware

   Charger architecture, control card design, protection, metering, thermal behaviour, and the firmware that runs it. Whether a product is right for the market you are selling into, and what it would take to make it right.

2. 2

   The power side

   Supply, load, protection coordination, current control and what a site can actually carry. Frequently the layer where a problem blamed on the charger turns out to live.

3. 3

   Protocol

   OCPP across versions, interoperability with a specific platform rather than compliance in the abstract, security profiles, and the integration work between a charger and a backend.

4. 4

   CMS and cloud

   Platform architecture, multi-tenancy, data model, APIs, and whether what you have will carry the network you intend to build on it.

5. 5

   Operations

   How the network is run: monitoring, ticketing, automated triage, voice and messaging support, field dispatch, and where the operating cost actually concentrates.

What we can test rather than opine on

A consulting opinion is worth something. A test result is worth more, and a large part of this engagement is running the test rather than offering the view.

• OCPP testing against the platform and release you will actually run, with the message set your operation depends on
• Interoperability between specific hardware and a specific backend, which is a different question from whether either is compliant
• Readiness: whether a product, a factory or a platform is ready for the stage you are planning, which is frequently the finding the programme does not want
• Hardware evaluation against your requirements, including hardware you have already bought
• Site and load assessment, where the question is what a connection can carry rather than what a charger is rated at
• Failure analysis across a fleet, where the pattern rather than the individual fault is the answer

Finding where the problem actually is

This is the single most common reason companies come to us, and it is worth describing plainly because it is not a service most people know they can buy.

A charging business has a symptom: sessions failing, a site underperforming, a platform that cannot do something, units coming back from the field. It has a hardware supplier, a software supplier and an installer, and each of them has looked at their own layer and found nothing wrong. Nobody is lying. The problem is in the seam between two layers, and no supplier owns a seam.

• Is it the hardware, the firmware, or the way the firmware handles what the hardware is telling it?
• Is it the charger, or the supply the charger is correctly refusing to draw from?
• Is it the protocol implementation, or the platform's use of it?
• Is it the platform, or the operational process wrapped around the platform?
• Is it any of those, or is it the vehicle?

We can answer those because we have built in all of them. That is the only real qualification for this work, and it is worth asking any consultant to demonstrate it rather than claim it.

How the engagement works

Hourly, against an agreed scope.

1. 1

   A question

   Sometimes it is a single decision that has stalled: a written answer, and you carry on. We would rather do this than convert it into a project.

2. 2

   An assessment

   A defined piece of work with a deliverable: a test result, an evaluation, a readiness finding. Scoped in advance, and the scope is what we hold to.

3. 3

   Ongoing advisory

   Access to the team for the duration of a programme, where the questions keep arriving and each one is too small to contract for separately.

Hourly rather than fixed price because the distance between a question and a programme is wide, and a fixed price for either would be wrong in one direction. It also means we have no incentive to make a small engagement into a large one, which matters more than it sounds in consulting.

The conflict, stated plainly

We manufacture chargers and we build a platform. That is a conflict of interest on any advice about buying either, and you should weigh what we say accordingly.

The way we handle it is to show the working rather than only the conclusion, so you can check the reasoning instead of trusting the source. Where a competitor's product fits your requirement better, that is what the assessment says. And if you would rather have this done by somebody with no product in the market, that is a reasonable position and we will say so rather than argue you out of it.

The assumptions we test first

Most charging projects arrive with three assumptions already made, and all three are worth testing before anything is designed around them.

1. 1

   That the load is simultaneous

   It usually is not. Apartments show the highest utilisation of any AC site we operate and it concentrates overnight, but it is also almost entirely schedulable, because no resident is leaving before morning. Sizing against scheduled load rather than simultaneous load can remove a supply upgrade from the project.

2. 2

   That the protocol version is the integration

   A customer bought a charger sold as OCPP that was not interoperable with the platform they had committed to. Version numbers describe a protocol. Integrations are specific to a platform and a release.

3. 3

   That the platform decision is reversible

   It frequently is not. We resold a shared platform where a change one customer needed could not be made without affecting the rest, and deploying it in the end meant visiting every charger physically.

What consulting does not mean here

• Not a slide deck. The deliverable is a finding, a test result or a decision, and it is written so your own engineers can disagree with the method rather than only the answer
• Not a route into a procurement conversation. An engagement that concludes you should not buy anything is a successful engagement
• Not a substitute for your team. We work alongside your engineers, who know things about your operation that no visitor discovers in three days
• Not open ended. Hourly against an agreed scope, and we tell you when the useful part is finished