Different Components of Noroam
P2P Server:
A Peer-to-Peer (P2P) application layer that enables the connection and communication between the charging station/session manager (provider) and the mobile application (consumer). Event messages from the Session Manager are sent to the P2P and then forwarded to the connected peers requesting the charging service. The P2P Server also publishes event messages from the consumer peer to the Session Manager (provider peer) for processing.
Redis Server:
This is used for P2P communication with the Session Manager and charge point gateway communication with the Session Manager. Charging sessions data of the charge point gateway are also stored on the Redis Server in a pseudo-decentralized manner for easy access by all services of the SDK.
Session Manager:
Manages charging sessions by receiving commands/events from the P2P Server through the Redis Server and then initiates those commands on the charge point gateway. It is also the communication layer that emits events to the dedicated UI (DUI) and also receives commands/events from the DUI to trigger transactions on the blockchain node. The onboarding of new charging station decentralized identification (DID) documents and the signing and confirmation of multisig transactions are part of what the Session Manager handles. Currently, the SM is limited to only processing a single charging session at a time. The Session Manager can also be referred to as the backend server of the DUI.
Dedicated UI (DUI):
Frontend web app that communicates with the Session Manager using the socket.io library. It displays Session Manager logs and has action buttons for some common tasks. It is designed to be further improved and eventually become the charging station frontend for monitoring sessions and transactions. Future updates will include reporting and analytics interfaces.
Charge Point Gateway (CPG):
This is the communication layer that remotely triggers commands on the charge point. Charge points (CP) are connected to the CPG using the connection endpoint/url. On successful charge point connections, BootNotification data is sent by the charge point, which is received by the CPG for further processing. The CPG is built using the OCPP protocol responsible for the communication between charge point and CPG. The current version of CPG only supports the OCPP 1.6 version; more versions will be implemented in future iterations.
Last updated
