How automated 24/7 hardware-in-the-loop rigs help PlugStream build more reliable EV charging features

EV charging features do not live neatly inside one piece of software.

A real charging session passes through the charger, the vehicle, the app, site power conditions, schedules, firmware, cloud services and support tooling. That is why a feature can look simple in the app but still depend on a chain of physical and digital signals behaving in the right order.

At PlugStream, automated hardware-in-the-loop testing helps us test more of that chain before a feature reaches customers.

In plain English, hardware-in-the-loop testing means connecting real or representative charger hardware to a controlled test environment, then running repeatable scenarios against it. The important part is that this is not just a bench rig someone uses occasionally. Our orchestrated HIL setup can run automated scenarios around the clock across multiple rigs in more than one location, exercising charger states, EVSE board behaviour, OCPP handling, access paths, timing windows and handovers that matter in the field.

That is especially important for features such as Charger Readiness and Vehicle Wake Assist, where the customer experience depends on understanding what the charger is waiting for, whether the vehicle is responding and what should happen next.

Why EV charger testing needs a physical layer

Software tests are valuable, but they cannot explain the whole charging journey on their own.

An EV charger is a physical product. It has a connector state, firmware behaviour, power electronics, metering inputs, network conditions and site-specific configuration. It also has to work with vehicles that may have their own charging limits, schedules, sleep behaviour and app settings.

That creates edge cases that are hard to understand if we only look at one layer.

For example:

• a charger can be online but still waiting for a planned schedule
• a charger can be ready while the vehicle is not requesting energy
• a session can pause because load management is protecting the wider site
• a delayed charging window can open after the vehicle has entered a lower-power state
• a support team may need to know whether the problem is charger-side, vehicle-side or site-side

Automated hardware-in-the-loop testing gives us a way to run those scenarios more deliberately, repeatedly and outside normal working hours.

What the PlugStream HIL rigs are designed to do

The HIL rigs give the engineering team controlled environments for exercising charger behaviour without waiting for a rare field condition to appear at exactly the right moment.

The current rig setup runs two EVSE boards with full serial and power on/off control. It also emulates the Control Pilot signal, so the EVSE can be exercised through realistic charger-side state changes rather than only through software messages. That lets the orchestrator move between physical charger-board states, power-cycle paths and firmware-facing behaviours without relying on someone manually standing at the bench.

It also runs four virtual chargepoints for protocol work. Those virtual chargepoints exercise the OCPP integrations across OCPP 1.6, OCPP 2.0.1 and OCPP 2.1, so protocol handling can be tested alongside the physical HIL flows.

The HIL rig gives engineering a controlled place to run physical EVSE-board scenarios and observe the orchestrator status without waiting for a field condition to appear.

The goal is not to replace real-world testing, compliance testing or installer commissioning. It is to make feature development more repeatable.

The automation matters because charging edge cases are often about timing. A scheduled window might open hours after plug-in. A retry path may need to be observed across several state changes. A connectivity condition may appear, clear and then reappear. Running these scenarios manually once is useful. Running them automatically, repeatedly and 24/7 gives us a much stronger signal.

Running multiple rigs in multiple locations also helps us test access from more than one perspective. We can check internal engineering access, external access paths and remote-control behaviour through the routes a charger may actually rely on outside the workshop.

The rigs help us test questions such as:

• Does the charger move through the expected state sequence?
• Does the app receive a useful status at the right point?
• Does a scheduled session stay waiting until the intended window?
• Does a delayed-start scenario behave consistently when the vehicle response changes?
• Does the charger remain reachable through the expected internal and external access paths?
• Does the system produce enough context for support to understand what happened?

This matters because the best customer experience is not just "the charger works". It is also "the system can explain what is happening when charging is waiting, paused or asking for attention".

The orchestrator: making scenarios repeatable around the clock

A test rig is most useful when it can run the same scenario again and again.

That is where the orchestrator comes in.

The orchestrator is the layer that coordinates the automated test flow. It can set up a scenario, trigger the relevant charger-side or app-side behaviour, observe the response and record the result. That makes it easier to compare one firmware build, app change or platform update with another.

Just as importantly, the orchestrator can keep running beyond a single manual test session and across more than one rig. That supports 24/7 test coverage for repeatable scenarios, overnight timing windows, internal and external access checks, and regression paths that would be slow or easy to miss if every run depended on someone standing at the bench.

The orchestrator keeps track of job health, active runs and completed scenarios so engineering can compare behaviour across builds and protocol versions.

For a charging feature, the orchestrator can help answer practical questions:

• Did the charger enter the expected readiness state?
• Did the session wait for the right reason?
• Did a retry or recheck happen where the scenario supports it?
• Did the app-facing status remain clear?
• Did the result match the expected outcome in the matrix?

That repeatability is useful for engineering, but it is also useful for product decisions. When a team can see the same scenario run automatically across a controlled test matrix, it becomes easier to decide whether a feature is ready, needs more handling, or needs clearer customer copy.

The test matrix: turning edge cases into automated named scenarios

A good test matrix turns vague concerns into named cases.

Instead of treating "it did not charge" as one large problem, the matrix separates the conditions that can produce different outcomes.

Virtual chargepoint runs help exercise OCPP protocol handling across 1.6, 2.0.1 and 2.1 without needing a physical charger for every protocol scenario.

Scenario area	What we test	Why it matters
Charger readiness	Ready, waiting, paused, offline and attention states	Customers need clear language before they assume a charger has failed.
Scheduled charging	Delayed starts, saved windows and charger-side waiting states	Overnight and off-peak charging depends on the handover at the planned start time.
Vehicle response	Waiting-for-vehicle behaviour and supported retry paths	The charger cannot control every vehicle state, but it can handle supported handovers more gracefully.
Load management	Power limits, site telemetry and temporary pauses	A pause can be expected behaviour when the site supply needs protecting.
Connectivity	Online, offline and reconnecting charger behaviour	App control and support visibility depend on recent charger communication.
Access paths	Internal access, external access and remote-control routes	A charger may need to behave correctly whether it is reached from inside or outside the workshop.
Firmware and app flows	State changes through charger firmware, cloud services and the app	The customer experience should stay consistent across the full journey.
Support diagnostics	Event context and state history	Support teams need enough information to separate charger, vehicle and site issues.

This is where HIL testing becomes more than a technical exercise. It gives product, engineering and support teams a shared map of the charging journey, then lets that map run continuously as automated scenarios.

How this supports Vehicle Wake Assist

Vehicle Wake Assist is a good example of why this matters.

The feature focuses on a specific delayed-start moment: the customer plugs in earlier, the charger waits for the charging window, and when the window opens the vehicle may not respond as expected.

That is not the same as a simple charger fault. The charger may be ready. The schedule may be correct. The cable may be connected. But the vehicle still has to respond and request energy.

Automated hardware-in-the-loop testing helps us exercise the charger-side handling around that handover. It gives us a more repeatable way to check supported retry and recheck behaviour, including delayed and overnight-style timing paths, while keeping the public promise honest: Vehicle Wake Assist can help reduce missed charging windows where supported, but it cannot override every vehicle sleep state.

How this supports Charger Readiness

Charger Readiness is about explanation.

When a customer opens MyPlugStream, the useful question is often not "is the charger connected?" but "what is the charger ready to do next?"

The answer may be:

• ready for a vehicle
• waiting for a schedule
• waiting for the vehicle
• applying smart charging delay
• paused by site conditions
• offline
• asking for attention

Those states need to be tested as part of a journey, not only as isolated labels. Automated hardware-in-the-loop testing helps confirm that the charger-side behaviour, app-facing message and support context line up, and keeps checking those paths as scenarios are rerun.

What HIL testing does not claim

It is important not to overstate this.

Automated hardware-in-the-loop testing is not a replacement for electrical safety requirements, product compliance work, manufacturing quality checks, installer commissioning or real-world observation. It also does not guarantee that every vehicle, site condition or network condition will behave the same way.

What it does give us is a stronger, more repeatable way to test the behaviours PlugStream can control and observe, with automated runs that can continue through evenings, weekends and overnight charging windows.

That is the right kind of confidence: practical, traceable and grounded in the charging journey customers actually experience.

Why this matters for customers, installers and commercial sites

For drivers, better testing helps reduce confusing "why did it not charge?" moments.

For installers, it supports clearer commissioning and handover conversations, because charger behaviour can be explained in plain language rather than reduced to raw status codes.

For commercial sites and support teams, it helps separate different operational problems: a charger that is offline, a site power condition, a vehicle-response issue, a schedule that has not opened yet, or a supported retry path that needs more time.

That is where PlugStream's wider product story matters. We design and supply the hardware, build the software, connect the product to lifecycle information through PlugStream Passport, surface charging-state context through Charger Readiness, and support commercial continuity through PlugStream Sentinel.

Automated 24/7 hardware-in-the-loop testing fits into that same lifecycle view. It is one more way to keep the charger, software and support journey connected.

What comes next

The more charging moves into scheduled, tariff-aware and managed site contexts, the more important repeatable testing becomes.

The future of EV charging is not just faster power delivery. It is clearer state handling, better customer feedback, supportable hardware and software that can keep improving after installation.

That is what we are building towards: chargers that are not only installed well, but understood, supported and improved throughout their life.

To see the customer-facing features this work supports, read about Charger Readiness, Vehicle Wake Assist and the wider EV charging features guide.