Sample Protocol Test Report
This page shows the kind of report structure technical buyers usually want before they trust a testing platform: clear scope, findings, and protocol-level evidence.
This is a representative report layout, not a customer export. Its role is to show what buyers can inspect: run scope, concrete findings, and message-level evidence that helps engineering teams decide whether the product fits their workflow.
Protocols covered
OCPP 1.6, OCPP 2.0.1, OCPI 2.2.1
Virtual profiles
ABB, EVBox, Wallbox, Alfen-style mixed fleet
Checks shown
Connectivity, transactions, smart charging, roaming, CDR integrity
Purpose
Release confidence before production rollout or partner onboarding
What buyers usually look for in a report
Run summary
A compact overview of protocol version, charger profile mix, scenario coverage, and the release or onboarding goal behind the run.
Assertions and findings
A buyer can inspect which flows passed, which ones failed, and whether the platform captures the practical debugging context needed by engineers.
Protocol trace evidence
Message-level visibility matters because many EV charging issues only become obvious when you inspect actual OCPP or OCPI traffic in sequence.
Sample findings
The goal is not perfect green checks everywhere. The goal is a report that makes pass, review, and next-step decisions easy to understand before production release or partner go-live.
| Area | Status | What the team sees |
|---|---|---|
| OCPP 1.6 transaction flow | Pass | BootNotification, Authorize, StartTransaction, MeterValues, and StopTransaction completed within expected timing windows. |
| OCPP 2.0.1 smart charging | Review | Charging profile accepted, but one EVSE returned a delayed acknowledgement during a reconnect sequence. |
| OCPI 2.2.1 CDR export | Pass | Session closure and tariff calculation fields matched the expected reference payload for the sample roaming run. |
| Hub-oriented onboarding path | Review | Credentials exchange succeeded, but partner metadata handling needs a follow-up before certification rehearsal. |
Sample protocol trace
Buyers who already know OCPP or OCPI usually want to verify that they can see raw traffic, not just a high-level dashboard.
> connect ws://csms.example.test/ocpp/charger-204
< [2,"boot-001","BootNotification",{"chargePointVendor":"ABB","chargePointModel":"Terra AC"}]
> [3,"boot-001",{"status":"Accepted","interval":300,"currentTime":"2026-04-01T08:00:00Z"}]
< [2,"tx-014","TransactionEvent",{"eventType":"Started","triggerReason":"Authorized","seqNo":0}]
> [3,"tx-014",{}]
< [2,"mv-044","MeterValues",{"evseId":1,"meterValue":[{"sampledValue":[{"measurand":"Energy.Active.Import.Register","value":"12.4"}]}]}]
> [3,"mv-044",{}]See product views
Inspect the logs, workflows, and coverage screens behind this sample report.
Review deployment and security
Check how cloud, on-premises, and procurement conversations are framed before buying.
Ask for a tailored walkthrough
Use your own protocol version, charger mix, or roaming workflow as the starting point.