# Architecture ## Entities The domain model underneath show the entities a their relationships to each other. The abstracted world view of the system so to speak. Everything is and *Identity* which can be associated with multiple *CoinAddress*es. A *CoinAddress* represents the address or identifier on a blockchain and follows the derivation path of a master key. As an *Identity* can bis associated with multiple *CoinAddresses,* those identities can operate on multiple blockchains at the same time. All sub-classes of an *Identity* can operator on blockchains as well. An *Identity* can either be a *Device* or a *User. Devices* are associated with *Measurements* that are created in the system based on the measurements of a physical device. *Devices* can further be specialised as *EnergyConsumptionUnits* and *EnergySources.* *EnergyConsumptionUnits* represent everything that consumes energy and they are always associated with one *Member.* *EnergySources* on the other hand are devices that produce energy and are associated with one or multiple *Shares*. Where *Members* can own multiple *Shares* of an *EnergySource.* *Members* are specific form of a *User.* Operators are not considered in the domain model as their purpose is only to operate on the entities described above. ![](https://2774879019-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F37URXugGKPWDi5ErP0ov%2Fuploads%2FC84eHuc8gKVY10SKo8Wz%2FMyPower%20-%20Class%20Diagram.svg?alt=media\&token=7ee6ed7c-2ca0-4995-800d-71e22797346a) ## Components They system considers various environments with their components: ![](https://2774879019-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F37URXugGKPWDi5ErP0ov%2Fuploads%2FDqUEsa6PnHjhtlVDKwgt%2FMyPower%20-%20Component%20Diagram.svg?alt=media\&token=375a41a3-5baa-4cac-ba51-a7fb0953ac51) ### Device Environment Those components are installed at the physical device that should be considered in the system. This can either be an energy source like a solar panel, as well as a consumption unit like the flat of a member. In order to receive measurements of a device a *Meter* needs to be present. A *Trusted Gateway* is attached to the *Meter* and queries in a predefined time interval its measurements. To be able to proof the integrity of the measurement at any time, the *Trusted Gateway* creates a digital signature based on the measurements. Those information will be encrypted and sent via Lora to a *Lora Gateway* from which it will be forwarded to the LoraWan Provider. #### Meter Wir unterstützen alle gängigen Smart Meter, welche derzeit von den Wiener Netzen zur Anwendung kommen. Um die Daten von den Smart Metern abzugreifen, wird die **D0 Kundenschnittstelle** genutzt. Unterstütze Smart Meter: * Landis\&Gyr E450 * Iskra AM550E/AM550T * [Janitza UMG 604 Pro](https://www.janitza.de/umg-604-pro.html) #### Trusted Gateway At the core of the Trusted Gateway is the [Secure Element](https://www.riddleandcode.com/introduction-to-secure-elements) which enables the secure storage of the digital identity (private key). The Secure Element is embedded into a Trusted Gateway device along with a secure software stack that is integrated to create and verify the integrity and unique identity of the physical objects. The Trusted Gateway version used in this release uses [LoRa](https://en.wikipedia.org/wiki/LoRa) to transmit data from the physical object to the backend of the system. The Trusted Gateway can be connected to metering devices via following protocols: * IR (D0), * Modbus TCP, * Modbus RTU and * M-Bus. Tested on Iskra, Landis+Gyr and Janitza devices.
To transmit metering data from the infrared customer interface of a smart meter like it is used by the Wiener Netze, we connect an IR sensor to the smart meter and via USB to the Trusted Gateway. The other protocols are used similarly with respective USB dongles. The current data flow of the metering data using the Trusted Gateway is: 1. The Trusted Gateway queries in regular time intervals (currently 15 minutes) the *absolute energy* together with a timestamp from the smart meter, 2. A hash of the payload from the meter is created 3. The hash is signed with the private key stored in the Secure Element 4. The payload together with the previous created signature is sent via LoRaWan to nearby *Lora Gateway* 5. The Lora Gateway forwards the LoRa message via TCP/IP to a LoRa Wan Provider. We are currently using [TheThingsNetwork](https://www.thethingsnetwork.org/). (The Trusted Gateway was registered to the LoRaWan provider beforehand!) 6. The backend service connects to the LoRaWan provider via a publish-subscriber pattern so that any message sent by the Trusted Gateway will be forwarded to the backend. 7. The backend verifies the integrity of the data by using the public key of the Trusted Gateway by creating a hash of the payload and comparing it to the digital signature created by the device. 8. If the data is valid, the application either only stores the measurement in its database (Consumption), or mints KWH tokens on Polygon and distributes it to the shareholder of the energy source (Production). The components of the Trusted Gateway Lora, can be found ![](https://2774879019-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F37URXugGKPWDi5ErP0ov%2Fuploads%2FrfJyeuJZLGS1l7HvPVS5%2F1ed809af-53f2-4c00-86d9-b117fc55c81a.png?alt=media\&token=91222f04-6b29-4504-99c2-41f9dd0b3db4) ![](https://2774879019-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F37URXugGKPWDi5ErP0ov%2Fuploads%2FA0Bw9SZlQ5AQFVmhdzrE%2F72cd6ada-9b73-4aae-9f52-11fa09d0bffa.png?alt=media\&token=089b90ab-62cf-45ed-a2a8-f7c16b8232e1) ### LoraWan Provider This is the environment of an external service provider. The service it is hosting is called *TheThingsNetwork* which is a messaging broker for Lora devices. **The Things Network** ### Riddle & Code This components are deployed within three datacenter located in Austria. The business logic is implemented in the *MyPower-Backend* that subscribed to *TheThingsNetwork* and awaits measurements from devices. Based on the information stored in the *SQL Database* those measurements can be decrypted and associated with devices added to the system. For the production of energy sources it creates blockchain transactions by using the *Signature Broker* and *Signers.* Instead of receiving measurements from TheThingsNetwork, the system can use a *Device Broker* where information from devices can be sent to. It uses an MQTT protocol and a publish subscriber pattern between the devices and the *MyPower Backend.* The *MyPower Frontend* provides the users a graphical interface to interact with the system. It is served via *NginX* that is used as a web server as well as a proxy to for requests to the *MyPower Backend.* The authentication to the system is handled by the *Identity and Access* management component. It is a KeyCloak instance and uses the industrial standard for authentication OAuth2. The system works without this component and the purpose of it is to link the cryptographic identities of the *MyPower Backend* with the information from the users like, name and email. This component can either be deployed on customer side or can be offered by Riddle\&Code as a service. **MyPower Backend** Github: An description of the API can be found under following URL `1/riddleandcode/energy-community/api/v1/redoc` **MyPower Frontend** Github: **Signer** **Signature & Device Broker**