Scenarios
To get an impression how modules/add-ons work together a few flows have been visualized.
- Unconfigured charging station boots
- Configure charging station
- Accepting/registering a charging station
- Start transaction
- Remote stop transaction
- Authorizing identification
When a charging station (re)boots it sends out a "BootNotification". Charging stations have to be accepted and configured before they are fully operational. Until that, any boot notification request from the Charging Station will be rejected.
In the flow below, the charging station sends a "BootNotification" to Motown. The OCPP module checks if it knows the charging station, here it does and it sends out a "BootChargingStationCommand". The core receives that command via the command bus (not visualized). The core checks if the charging station has been configured before. In this sample it has not, so it sends out a "UnconfiguredChargingStationBootedEvent". The next flow describes an add-on that handles that event and configures the charging station.
The charging station configuration add-on listens for "UnconfiguredChargingStationBootedEvent". The add-on checks its local database to see if the vendor and model mentioned in the event are known. Here the combination is known and the add-on creates a "ConfigureChargingStationCommand" with the configuration and sends it. The Motown core receives that command, updates its information about that charging station and sends out an event to indicate the charging station has been configured.
Other add-ons will listen for that event and update their own representation of that charging station.
When a new (unknown) charging station sends a boot notification to Motown the boot notification response will by default be "rejected". The charging station is not allowed to initiate any communication with Motown besides boot notifications until it is accepted and configured. The configuration process is described above.
Accepting a charging station is done via the operator API. Here a user is logged in to a GUI (that uses the operator API) and wants to accept a charging station in Motown. The GUI uses the operator API to send out a AcceptChargingStationCommand which is picked up by the Motown core and an event is sent out.
Notice that the operator API waits to mark the charging station as accepted until the ChargingStationAcceptedEvent is received.
When starting a transaction the charging station can request Motown to authorize the identification (eg. RFID token) used to start the transaction. This is done by sending an Authorize request. Authorizing an identification is done by the Identification Authorization add-on. That add-on uses one or more configured authorization services. In this sample CIR has been configured.
First step in the start transaction is authorizing the identification that starts the transaction. For brevity the authorize flow is omitted here. The OCPP add-on generates a transaction identifier and sends out a command to the Motown core to indicate a transaction has been started.
Normally a transaction is stopped on initiative of the charging station. But it's also possible to request a stop transaction from Motown. To do this a user initiates a RequestStopTransactionCommand via the operator API.
After receiving the "Remote Stop Transaction" the charging station should stop the transaction and notify Motown about the stopped transaction in a separate message not displayed in this flow.
