Architectural map
This section contains an overview of the final version of the system as it has been designed for implementation, giving an holistic view of the developed components and their relationships with each other.
Components of the system can be categorized in:
- Microservices: standalone services that encapsulate their state and provide a well defined set of functionalities accessible through their public interface. Microservices can communicate with each other through events or asynchronous commands.
- Azure services: instances of services offered by the Microsoft Azure cloud infrastructure, providing a wide range of features that need to be integrated with other services.
- Functions: stateless instances that are typically used to translate and facilitate communication among other components of the system. They fit particularly well in the serverless computation model, and are therefore chosen to be implemented through Azure Functions. An important thing to note is that in Azure, the minimal unit of deployment is a Function App, which can host multiple functions with different tasks that scale together. The following sections use the term "function" to indicate an Azure Function App, that can therefore contain multiple instances of serverless functions.
- Devices: computational resources belonging to the physical world. They are embedded IoT devices onto the electric scooters managed by the system.
The diagrams in the sections below show the communication between each pair of components, classifying it in:
- Synchronous updates (Updates arrow): commands sent over synchronous media, like HTTP or RPC.
- Asynchronous commands (Sends commands arrow): commands sent in an asynchronous way, typically using message queues.
- Publish subscribe (Exposes topic & Observes arrows): events are published on topics and observed by subscribers of that topic, using asynchronous messaging.
E-Scooter subdomain
This subdomain contains all the services and functions that deal with the scooter lifecycle and with the exchange of information between the physical devices and the system.
Since the scooter data context has the authority over the identity of the scooters and, thus, over their existence in the system, we planned to build it as a microservice. However, for this prototypal implementation, due to the limited time, it was mocked via a GUI that mimics its behavior exposing the scooter lifecycle interface (i.e. notifying the creation/deletion of scooters).
On the other hand, the Scooter Monitor & Control context deals with the communication with the physical world. Its access point to the real world has been chosen to be realized via the Azure IoT Hub, a service specifically designed to be the pivot point between the cloud and IoT devices.
The IoT Hub can keep track of a large set of entities (denoted as Devices), each with its own identity. Each device has two sets of properties to hold state: (i) Desired properties, used by the cloud infrastructure to communicate the desired state for the device; (ii) Reported properties, used by the device to communicate its actual state (which can be different from the desired one). Furthermore, each device can emit a series of frequent events (almost a continuous stream) denoted as Telemetry. These are meant for continuously changing properties (like position, speed or battery level, in the e-scooter domain).
New scooters that are registered to the system are recorded as devices inside the IoT Hub thanks to the Manage Devices function, relying on the scooter lifecycle topic. After registration, the scooter can start to be monitored and/or controlled by the system.
The physical actuation of control policies is demanded to the Scooter Control function, which receives asynchronous commands from other components in order for them to be propagated to the physical devices via the IoT Hub. This commands, among others, include the operations to lock/unlock scooters, for example when a customer rents one.
The IoT Hub can also be configured to emit events whenever a telemetry is sent or whenever a reported property changes. This feature has been exploited to integrate it with the rest of the ecosystem. In particular, the cloud service emits events when properties like locked or standby change. In order to have a simpler interface for reported properties updates, the Scooter Monitor function has been put in between the Hub and the rest of the system, to translate them into events tailored for the e-scooter domain.
User subdomain
Being a generic subdomain, the team decided to have the User subdomain be implemented using an off-the-shelf package. Therefore, the team opted to mock the interfaces of this subdomain that were needed by other components in other subdomains, namely the Customer lifecycle topic. This is the topic exposed by the designed Customer Microservice to let others know about customers signing up to the system or customers unregistering from it. Like the scooter data microservice, this was implemented via a GUI emitting the events for other services to observe.
Rent subdomain
The rent subdomain deals with the functionalities that allow customers to rent scooters, along with side features reserved to assistants and admins of the service. The core of this subdomain is the Rent Microservice, which provides clients with an interface to start and stop rents as a customer, or to enable or disable scooters as an assistant or as an admin. To work properly, it needs to know about the existing customers and scooters, which is done by subscribing to the Scooter Lifecycle, Scooter Status and Customer Lifecycle topics. This service is also responsible for the locking and unlocking of scooters according to the lifecycle of the related rents. Since these operations are offered by the Scooter Control function, the rent service only needs to send asynchronous commands to it when necessary.
The Rent Microservice does not directly deal with the payment of the rides, but delegates this responsibility to another microservice from a different bounded context, the Rent Payment Service. Since payments are assumed to use virtual currency managed by the system, this service needs to ensure that: (i) a renting customer has enough credit to start a rent, that is authorizing or rejecting the rent; (ii) a rent is stopped when a customer's credit runs out. This collaboration between the two services is carried out via an exchange of events using the Rent Lifecycle and Rent Payment Events topics. Due to the limited time though, the Rent Payment service was mocked with a function that always authorizes rents when they are requested.
Azure Digital Twins
Since this project is about the exploration of the digital twins paradigm, the team decided to adopt a standard and production-ready solution to keep track of the real-time state of the system. This gives clients the possibility to query it in arbitrary ways. The solution of choice was Azure Digital Twins, which has all the required features.
Azure Digital Twins allows developers to define a set of DTDL models to define real-world assets as twins along with their properties and the relationships they can have with other digital twins. Once the models are uploaded to the Azure Digital Twins instance, external agents can use its API and/or SDK to run CRUD operations on both digital twins and relationships, in order to control the digital twin graph.
EScooter DTDL Models
DTDL models of EScooter digital twins can be found in the twins-models repository.
Azure Digital Twins can be easily integrated with other cloud services (including the IoT Hub) using Azure Functions. In particular, the team planned to develop a group of functions to create digital twins for the scooters and the customers managed by the rest of the system and also to keep them up to date with the real-time state.
Created: June 29, 2021 15:36:54