When a valid sensor reading is wrong

A charger receives a temperature reading of 25 °C. The value is present. It is formatted correctly. It sits comfortably inside a plausible range.

So is the sensor healthy?

Not necessarily.

If the reading remains at 25 °C while operating conditions change, the number itself may never look alarming. Its behaviour is the concern. A range check can confirm that the value is possible. It cannot, on its own, confirm that the value still describes reality.

This distinction matters anywhere a system relies on measurements to understand its own state. A sensor can fail loudly with a missing or impossible value. It can also fail quietly by continuing to report something believable.

That is the problem Sensor Confidence addresses.

Traditional plausibility checks remain useful. A missing signal, an impossible voltage, or a value outside its expected range deserves attention. These checks catch faults that announce themselves clearly.

The harder cases stay inside the lines.

A current measurement can remain at zero. An output-live indication can remain active. Protection feedback can remain unchanged. A temperature can settle on a value that would look entirely ordinary in a static table.

Each reading may be valid in isolation. The system around it may tell a different story.

Credibility therefore depends on more than the number. It depends on questions such as:

This is not a reason to discard range checks. It is a reason to treat them as the beginning of an evidence chain.

Consider the 25 °C example again.

The useful question is not simply whether 25 °C is plausible. It is whether the reported temperature behaves credibly during the period being observed. That assessment may consider operating state, elapsed time, current flow, other thermal evidence, and the sensor’s own history—where those inputs are available and implemented.

The same reasoning applies to current. A zero reading can be correct while no vehicle is drawing power. The same zero can become questionable when independent evidence suggests an active charging session and sustained output.

Context changes the meaning of a value.

This is why Sensor Confidence is designed around relationships rather than a collection of isolated thresholds. It asks whether the available evidence supports the reading, challenges it, or leaves the answer unknown.

Sensor Confidence applies this evidence model across five relationships within the charger.

Two copies of the same source do not necessarily provide two independent reasons to believe it.

Useful corroboration comes from signals that observe the system in different ways. A command and a separate electrical response can test intent against outcome. A thermal reading and changing operating conditions can test whether the sensor responds. A CP state and measured current can test whether a session behaves coherently without assuming that the vehicle must draw the full offered current.

Independent evidence does not guarantee certainty. Sensors can share failure modes, evidence can arrive late, and a system may not expose every signal. The point is to preserve those limitations and make the reasoning explainable.

An evidence trail should be able to say:

That is a more useful engineering record than an unexplained green or red indicator.

Sensor Confidence evaluates credibility and records why the available evidence supports, challenges, or cannot resolve a reading.

Established thermal, RCD, contactor, PEN, current-limit, charging, and related protection functions remain authoritative. Sensor Confidence adds diagnostic context without replacing the charger’s protection architecture.

Keeping those responsibilities distinct makes the evidence easier to understand and act on.

The charger is where signals, state, and existing protection logic meet. Sensor Confidence evaluates defined relationships locally and deterministically.

PlugStream Cloud provides a different kind of value. Through PlugStream Sentinel, it can help operators review available evidence across supported assets, identify trends, compare genuinely comparable cohorts, and prioritise investigation.

The two layers should not be confused.

Cloud monitoring does not become local electrical protection because it receives more data. A fleet health view cannot replace the protection systems designed to act at the charger. The strongest architecture gives each layer a clear responsibility and keeps those boundaries visible.

The firmware programme keeps these relationships testable and traceable. Supporting evidence can include:

Versioned evidence preserves enough provenance to show what was tested, what the system observed, and what the result does—and does not—prove.

“Is this value valid?” remains worth asking.

Sensor Confidence adds another:

“What evidence makes this reading credible?”

That question turns a number into an explainable system view and gives technicians and operators more useful evidence when behaviour no longer makes sense.