Updating charger firmware from the CSMS is mostly a bookkeeping problem. The CSMS sends one request, then follows a series of status messages from the station until the update succeeds or fails. Real hardware makes the failure paths hard to reach, since you would need a download that breaks on purpose. A simulated station walks through the same status sequences and lets you pick how they end.
What the station sends on OCPP 1.6
When your CSMS sends UpdateFirmware, GetDiagnostics or GetLog, the station answers first and then reports progress in separate notifications. These are the sequences:
| Request | Outcome | Notifications, in order |
|---|---|---|
| UpdateFirmware | Installed (default) | Downloading, Downloaded, Installing, Installed |
| UpdateFirmware | DownloadFailed | Downloading, DownloadFailed, Idle |
| UpdateFirmware | InstallationFailed | Downloading, Downloaded, Installing, InstallationFailed, Idle |
| GetDiagnostics | Uploaded (default) | Uploading, Uploaded |
| GetDiagnostics | UploadFailed | Uploading, UploadFailed, Idle |
| GetLog | Uploaded (default) | Uploading, Uploaded |
| GetLog | UploadFailure | Uploading, UploadFailure, Idle |
Note the difference in spelling: the OCPP 1.6 diagnostics status is UploadFailed, while the log status from the security whitepaper is UploadFailure. A CSMS that maps both to one internal value needs to handle each string.
The signed variants work the same way. A SignedUpdateFirmware request runs the firmware sequence and reports it with SignedFirmwareStatusNotification, carrying the request id from your request.
Choosing the outcome
The outcome and the pace are set with six configuration keys. They are specific to SimItNow and are not part of OCPP. Set them from your CSMS with ChangeConfiguration before you send the request, and the station answers Accepted:
- FirmwareSimulatedOutcome is
Installed,DownloadFailedorInstallationFailed. - DiagnosticsSimulatedOutcome is
UploadedorUploadFailed. - LogSimulatedOutcome is
UploadedorUploadFailure. - FirmwareSimulatedDelaySeconds, DiagnosticsSimulatedDelaySeconds and LogSimulatedDelaySeconds are the number of seconds the station waits between notifications. They default to 0, so the whole sequence arrives at once.
Set a key back to its default value when you want the success path again. OCPP 2.0.1 and 2.1 have no ChangeConfiguration to set these keys with, so those stations always run the sequences to success. Use a 1.6 station for the failure paths.
What to check in your CSMS
- A delay of 10 or 20 seconds between notifications shows how your CSMS behaves while a download is in progress. Does its timeout fire too early, and does a status page show Downloading and not just the end result?
- Each failure path should leave the update marked failed, with the station ready for another attempt. Idle follows a failure, and it is not a failure by itself.
- A second UpdateFirmware sent while the first is still running cancels the first and starts the sequence again. The CSMS should not report two updates at once.
- Retry logic after DownloadFailed: does the CSMS retry, how often, and does it stop eventually?
Two things the simulator does not do. It does not fetch the file at the location in your request, so that URL does not have to exist, and testing your own file hosting is a separate job. It also does not reboot or change its firmware version after Installed: the next BootNotification reports the same version as before. A CSMS that marks the update done only when the version changes will wait forever, which is worth knowing about your own code.
Pairing it with a security event
A real charger reports a successful update with a SecurityEventNotification of type FirmwareUpdated. SimItNow does not send it on its own, but you can trigger it once the Installed notification has arrived, as described in testing OCPP security profiles. That tests the second half of the flow, where the CSMS has to connect a security event to the update that caused it.
OCPP 2.0.1 and 2.1
The same requests work on 2.0.1 and 2.1 stations. UpdateFirmware answers Accepted, or AcceptedCanceled when it cancels a running update, and the station sends FirmwareStatusNotification with the request id. A request that carries a signature adds a SignatureVerified status after Downloaded. GetLog answers Accepted with a file name and sends LogStatusNotification, ending in Uploaded. For failure paths on those versions, run the 1.6 station.
Create a free account and run a failed update against your CSMS.