HUBCORE Validation Lab — we welcome equipment, vehicles, technology, pilot sites, sponsors and supporters.
Propose collaboration
Assessment

Control readiness

Green, amber, red — how HUBCORE decides whether a device or site is fit for control.

Short answer

Control readiness is a precondition, not an add-on. Green means documented local control and trustworthy metering; amber means partial or uncovered risk; red means the solution cannot enter the HUBCORE ecosystem until something changes.

Three levels

We assess every device and every site on the same scale so comparison is fair and repeatable.

Control readiness levels
LevelMeaningWhat HUBCORE does
GreenDocumented local control and metering, clear service ownershipFit for integration and piloting
AmberPartial interface, cloud dependency or incomplete documentationUsed in limited scope with risks documented
RedCritical gap in control, metering or accountabilityNot accepted into the ecosystem until changed

Hard blockers

These five situations trigger a red rating automatically, whatever the device's other merits.

Red flag: if a vendor does not document the interface or requires its own cloud for critical control, HUBCORE cannot guarantee the device's behaviour on site.

  • No reliable external measurement or control
  • Closed, undocumented integration with no adapter route
  • Critical operation is vendor-cloud-only, with no local fallback
  • Firmware and service ownership is unclear
  • No safe limits or trustworthy fault data

Before-approval checklist

No device or site enters HUBCORE's approved solutions before this list has been worked through and evidenced.

  • External measurement exists and is readable
  • The control command is documented and tested
  • Local fallback works without the cloud
  • Safe limits are configured and verified
  • Fault data is machine-readable and trustworthy
  • Firmware and service ownership is assigned in writing
Requires verification against manufacturer documentation

How the assessment runs

We assess along the seven dimensions of the HUBCORE fit filter: controllability, measurability, integrability, local operation, security, serviceability and scalability. Each dimension gets evidence — a document, a test or a measurement — and a note where evidence is missing.

  • Every claim is linked to a source or a test
  • Unverified information is visibly marked
  • The rating is revisited when firmware or the interface changes

HUBCORE fit filter

  • Controllability Can the device be safely limited, started and stopped through a documented interface?
  • Measurability Do we get trustworthy measurements (power, energy, phases, state, faults) at sufficient resolution?
  • Integrability Is the interface publicly documented (e.g. Modbus, SunSpec, REST, MQTT, OCPP) and versioned?
  • Local operation Do critical control and safety keep working when the vendor cloud or internet is down?
  • Security Is access authenticated, are rights scoped, is traffic encrypted and firmware updatable?
  • Serviceability Is it clear who owns maintenance, spare parts, firmware and fault resolution?
  • Scalability Can the solution grow (more points, kWh, sites) without redesigning the architecture?

HUBCORE's position

Control readiness is HUBCORE's primary selection criterion. A modest device that can be reliably controlled and measured beats a powerful device that behaves unpredictably.

Not yet verified

  • How to verify cloud dependency without a long field test?
  • What is the minimum telemetry rate that is still trustworthy?