Problem
The charging-platform operator approached Offline Protocol with a problem at the boundary between its cloud platform and the charging site: essential session and operational workflows depended on a connection that was not always available. A charger could continue operating while the central platform lost a timely account of its state, authorization context, meter readings, and eventual session outcome. Operations then had to recover the transaction history and establish whether requests, including flexibility-service events, had actually been acted on.
Solution
The deployment adds the Offline Protocol Mesh SDK1 alongside the existing OCPP architecture and charging management platform. OfflineID2 authenticates chargers and site controllers, while Data Edge Sync3 shares local session views backed by retained authorization, metering, and charger-state records. Reliable delivery adds acknowledgments, retries, and deduplication to approved operational requests, preserving both acceptance and station-confirmed execution evidence. Retained application records reconcile upstream after connectivity returns; the existing OCPP client keeps its protocol responsibilities.
Outcome
Approved charging workflows continue through cloud outages, and operations recovers the session history and command evidence needed to resolve each interruption. A restored connection now brings back what the station did, including whether a flexibility event was accepted, rejected, or executed. The operator can account for charging activity with less manual reconstruction, while existing authorization and electrical-safety policies continue to govern the station.
Continuity alongside the existing charging platform
The Offline Protocol Mesh SDK1 runs on compatible charger, gateway, or site-controller profiles at the integration boundary. OfflineID2 gives enrolled devices their own authenticated identity. Messaging Layer Security (MLS)4 protects coordination between authorized participants.
The local record includes charger state, session identifiers, authorization decisions and their validity, metering observations, and command outcomes. Retaining an authorization decision does not extend its expiry or grant a new permission. The station's protection, load limits, contactor control, and approved offline-authorization policy remain authoritative.
The existing OCPP owner keeps its native connection, protocol queue, and recovery responsibilities. Offline Protocol adds a durable application outbox and local coordination path around supported integration points. Hosted Relay forwards retained application records to the authenticated platform adapter; that adapter confirms business-level ingestion. There is no competing OCPP client for the same station.
Session identity survives the outage
The adapter keys the retained history by station, EVSE or connector, and transaction. Each observation also carries a source sequence and capture timestamp. The projected session view references that history and records the last station-confirmed state. Its freshness advances on a new station observation, not on an upload, so a recovered cloud connection cannot make stale charger state appear current.
Data Edge Sync3, Offline Protocol's replicated-data layer, distributes compact session views and service records. Meter observations remain an attributed event log. They are not shared fields that another client can overwrite.
The integration preserves the deployed OCPP version's lifecycle. OCPP 1.6 uses StartTransaction, MeterValues, and StopTransaction; OCPP 2.0.1 uses sequenced TransactionEvent reporting.5 Reconciliation fills the original transaction history. Replaying an end record does not issue a new physical command.
Flexibility events retain delivery and execution evidence
Approved local commands and flexibility-service events carry a stable identifier, validity window, and policy context. The site retains receipt, acceptance or rejection, and the station-confirmed outcome under that identifier. Transport acknowledgment establishes delivery; it does not establish that a charger executed the requested action.
Retries reuse the identifier and recorded outcome. An expired event is rejected instead of being executed late after reconnection. The recovery path returns the retained acknowledgment and execution evidence to the charging platform. This gives operations a traceable answer to three separate questions: did the event arrive, was it permitted, and what did the station actually do?
The deployed integration boundary
The gateway composition uses offline-protocol, offline-protocol-core, offline-protocol-services, offline-protocol-reliability, and offline-protocol-mls. Acknowledgments, retries, deduplication, and bounded recovery come from the delivery lifecycle.6 offline-protocol-transport and offline-protocol-router support the Dynamic Offline Relay Switch (DORS), the automatic transport selection solution, over paths qualified for each hardware profile.
The adapter commits an exported event with its application outbox entry. A durable projection queue updates offline-protocol-data separately because the station database and SDK store are separate transactions. Deduplication covers the supported replay horizon, and controlled backlog draining preserves capacity for current station traffic.
The deployment path began with one real charging workflow, joint engineering success criteria, and simulated and real connection-loss conditions. Qualification is specific to station firmware, OCPP version, and authorization policy. A denied session remains denied when its policy requires online approval. Payment processing, tariff calculation, electrical safety, and the existing charging system of record retain their owners.
What operations can now account for
The site retains session evidence through cloud outages and resolves approved local work without waiting for an upstream round trip. Recovery brings back the record of what happened, including event acknowledgments and station outcomes. Operations no longer has to infer execution from the return of connectivity alone.
Runtime Telemetry7 exposes local delivery, backhaul availability, queue age, recovery duration, and synchronization outcomes. The validation record connects those signals to source events:
| Operational measure | Validation evidence |
|---|---|
| Session retention | Source-key coverage, start/end completeness, and meter totals across isolation and recovery. |
| Charger-state continuity | Station-event-to-local-view latency and stale-state detection when the station link also fails. |
| Approved local execution | Request ID, policy decision, station-confirmed outcome, and persisted acknowledgment. |
| Flexibility-event evidence | Receipt, expiry handling, execution outcome, and upstream acceptance for each event ID. |
| Duplicate-free ingestion | One accepted record per source key under repeated replay and lost acknowledgments. |
| Recovery time | Backhaul restoration to final recipient commit, recorded with backlog size and bandwidth. |
Managed services and expansion
The retained session and command record gives the charging operator a foundation for services beyond outage recovery. Expansion follows the people who need that evidence: the support desk resolving a station incident, the installer commissioning equipment, and the driver checking a session.
Network operations and flexibility evidence. Hosted Relay carries retained application records to the platform adapter. Managed Telemetry adds a fleet-wide operating view by collecting selected local delivery, queue-age, and recovery signals alongside application ingestion results. That lets support distinguish a backhaul interruption from a station-interface or recipient failure. Flexibility-service reporting can reuse the event's receipt, policy decision, expiry, and confirmed outcome for an evidence service across participating sites.
Installer services. Capability Exchange exposes scoped diagnostics and commissioning checks through the same authenticated service model.8 An installer application can collect the station profile, run permitted checks, and retain a commissioning report for upstream review. Proof of Location9 can add visit-presence evidence where the site has suitable witnesses; the test results still establish whether commissioning succeeded.
Driver visibility. A companion application can show the session state and freshness supplied by an authorized site interface, then receive reconciled history after recovery. Native bindings and handset transports are qualified separately. This opens additional driver-support and installer-service offerings around the deployed chargers, gateways, and site controllers, while charging permission, tariffs, payment, and electrical protection retain their existing owners.
References
- 01Offline Protocol Mesh SDK
- 02OfflineID and device identity
- 03Data Edge Sync: replicated documents and persistence
- 04Messaging Layer Security: RFC 9420
- 05OCPP 2.0.1 transaction handling and protocol changes
- 06Delivery lifecycle and reliability
- 07Runtime telemetry
- 08Service discovery and authenticated invocation
- 09Proof of Location
