A Service Oriented Architecture for the Digitalization and Automation of Distribution Grids

Modern distribution grids are complex systems that need advanced management for their secure and reliable operation. The Information and Communication Technology domain today offers unprecedented opportunities for the smart design of tools in support of grid operators. This paper presents a new philosophy for the digitalization and automation of distribution grids, based on a modular architecture of microservices implemented via container technology. This architecture enables a service-oriented deployment of the intelligence needed in the Distribution Management Systems, moving beyond the traditional view of monolithic software installations in the control rooms. The proposed architecture unlocks a broad set of possibilities, including cloud-based implementations, extension of legacy systems and fast integration of machine learning-based analytic tools. Moreover, it potentially opens a completely new market of turnkey services for distribution grid management, thus avoiding large upfront investments for grid operators. This paper presents the main concepts and benefits of the proposed philosophy, together with an example of field implementation based on open source components carried out in the context of the European project SOGNO.


I. INTRODUCTION
Distribution grids are at the center of the ongoing transition in the energy sector [1]. The roadmap towards energy decarbonisation will bring in the next future a further increase of the Distributed Generation (DG) based on renewable sources [2], which is largely connected to the distribution level of the electrical grid. Similarly, the upcoming electrification of the mobility and heating sectors will severely affect the operation of distribution grids, creating more volatile conditions, unknown power profiles and much higher levels of power demand [3], [4]. In this scenario, final customers are called to play an active role by offering their flexibility for ancillary services [5], while new stakeholders (such as energy The associate editor coordinating the review of this manuscript and approving it for publication was Peter Palensky . aggregators, local energy communities, etc.) are already entering the business value chain, thus contributing to further modify the usual patterns of operation of the distribution system [6].
These elements, all together, bring a level of complexity never experienced before in the distribution systems, which goes well beyond the traditional challenges faced for the management of the power network. To address these challenges, Distribution System Operators (DSOs) have to rethink the way they operate and manage their grids. Investments on network reinforcements are not sufficient any longer to deal with the complexity of future distribution systems and the modernization of the distribution grid clearly requires the deployment of advanced Distribution Management Systems (DMS) down to the Low Voltage (LV) level of the network [7]. These needs have been recognized also by policy makers and are considered in current regulatory frameworks. In Europe, for example, the so-called Clean Energy Packet now supports investments in software-based innovation, allowing grid operators to capitalise Operational Expenses (OPEX) and to choose between the deployment of software intelligence and the upgrade of physical assets [8].
DSOs will have to make a significant effort to deploy software solutions to strengthen their automation infrastructure and make their control rooms smarter, upgrading from current relatively simple control routines and dependence on the experience of human operators. Despite the many challenges ahead, the modernization of distribution grids also brings large opportunities. The Information and Communication Technology (ICT) sector has made huge steps forward recently and developed many new technologies. Concepts and platforms for big data management, imported from the Internet of Things (IoT) domain, are more and more often proposed also in the power system sector [9], [10]. Artificial Intelligence (AI) and Machine Learning (ML) are among the biggest technological trends of the last decade and are today commonly considered both for the design of new power system applications and for the provision of additional data analytic tools [11]- [14]. The possibility to adopt cloud computing solutions is also recently gaining momentum, as it may enable a set of technological and business advantages for some utilities [15], [16]. Finally, the upcoming roll-out of the 5G communication infrastructure will soon provide further options for the upgrade of the automation infrastructure, such as low latency communication, high bandwidth, network slicing and edge cloud processing capabilities [17], [18].
In this scenario, this paper presents an innovative philosophy for the deployment of the DMS functionalities needed for future distribution grids. The proposed approach builds upon the use of last generation IoT concepts and the definition of a scalable and modular architecture designed according to the microservices and containerization principles [19]. This architecture breaks the traditional view of the DMS as mainly composed of a large and monolithic system with predefined applications and it allows for fulfilling the functional and non-functional requirements of the DMS. The vision presented in this paper leads to many disruptive changes from both a business and technological perspective. As an example, it enables a multi-vendor provision of the different microservices, thus potentially unlocking new markets of distribution management applications open to multiple stakeholders. Power system, ICT and AI software components can be all easily integrated following the same microservice approach and could be offered as turnkey services, thus avoiding large upfront investments for DSOs. The proposed architecture also facilitates the seamless integration of new services, the flexible sharing of data and exposing interfaces towards other platforms (e.g. flexibility market, smart city platforms, etc.), thus making possible achieving crossdomain interoperability.
The remainder of this paper is structured as follows. Section II reviews related works, with a particular focus on the state of the art of DMS and recent proposals about IoT architectures for smart grids. Section III discusses the functional and non-functional requirements of the DMS taking into account the challenges foreseen in future distribution systems. Section IV presents the proposed architecture and underlines the benefits of the containerized microservices implementation. In Section V, an example of field implementation carried out in the project SOGNO [20] is presented, which proves the feasibility and some of the benefits of the proposed ideas. Section VI presents possible implementation options, discussing related scenarios and the emerging business opportunities. Finally, Section VII provides the conclusions.

II. RELATED WORK A. DMS STATE OF THE ART
The DMS can be defined as an integrated system used by distribution utilities to collect, organise, analyse and visualise the distribution system information, with the scope of operating, controlling and planning the distribution grid in a reliable and efficient way [21]- [23]. An advanced DMS is typically composed of: i) a Supervisory Control and Data Acquisition (SCADA) system for the collection of real-time data and the remote control of devices; ii) a set of software tools for outage management and for the optimal operation and planning of the distribution system; iii) visualization tools as well as training simulators to support grid operators [21]. For its operation, the DMS needs also to be interfaced to several other subsystems, such as the Geographical Information System (GIS), the Customer Information System (CIS), etc. Overall, the DMS is thus a complex software platform that on one hand hosts the intelligence needed for the management of the distribution grid and, on the other hand, collects, processes and handles large amounts of heterogeneous data.
Until now, despite the needs for smart management, most of the DSOs still have DMSs with quite basic functionalities [21], [24]. However, more sophisticated systems and advanced applications are clearly needed in the near future to deal with the increasing complexity of the distribution system [25]. Accordingly, large efforts are currently devoted to develop solutions for the digitalization and automation of distribution grids. In [26], an advanced DMS is proposed, which embeds a dynamic state estimator coordinated with other network optimization functionalities. In [27], a multiagent automation architecture based on the IEC 61850 and IEC 61499 standards is presented. A distributed automation scheme based on IEC 61850 and intelligent substation automation units is instead the focus of [28]. All these proposals offer valid options for the implementation of the automation functionalities and the associated automation architecture, but they do not deal specifically with architectural solutions to facilitate the deployment of the software within the DMS.
Software integration is one of the main challenges behind the implementation of a DMS [22]. This is due to the need of coordinating many different tools, sharing and synchronizing data among multiple applications, as well as interacting with field devices and other subsystems (or platforms), each one potentially adopting its own data models and formats. Today's DMSs are generally monolithic software systems provided by a single vendor and installed in the DSO servers. They are thus closed systems that use proprietary software and data models, with high level of coupling among the different applications. As a result, these systems are generally not simple to maintain, upgrade, extend, they do not scale easily and do not make efficient use of the computational resources. Moreover, they require large upfront investments and dedicated personnel at the DSO to handle not only the operational technology but also the IT system. To alleviate these challenges, in the last decade, innovative solutions coming from the IoT domain have been increasingly proposed.

B. IoT ARCHITECTURES
IoT concepts and technologies are today widely adopted in many industrial sectors. In the last years, different industry IoT architectures, frameworks and platforms have been devised for the development of industrial IoT systems [43]. The Industrial Internet Reference Architecture (IIRA) [44] is a high-level reference architecture for the representation of use cases and the definition of more specific architecture models within each industry sector. It is composed of four layers (business, usage, functional and implementation), which reflect different architectural viewpoints of the industry domain. Arrowhead [45] is an IoT framework, based on a service oriented architecture, aimed at boosting industry automation. It relies on the concept of local clouds to realize systems of systems and it adopts open interfaces and documented design patterns to enable interoperability. FIWARE [46] is an open source IoT platform to develop IoT solutions. It is also based on a service oriented architecture, and it provides a catalogue of so-called enablers that can be plugged, in a modular way, to create customized solutions tailored to different industrial scenarios.
The above initiatives are important references that define unifying concepts, ideas and principles. However, they stay at a high level of abstraction since they aim at covering multiple industry verticals. For this reason, more specific IoT-based architecture models and frameworks are proposed for the power system domain. Each of them may focus on different aspects or architectural viewpoints. Some proposals deal with the virtualization concept, since this is key to allow for data abstraction and interoperability. In [29], cloud-based virtualization is adopted to enable grid monitoring. This solution relies on virtual objects to abstract the physical meters and uses local micro-engines to distribute the intelligence at the edge. The same approach is further elaborated in [30], where the architecture for a more generic implementation of services in the smart grid scenario is presented. The virtualization of intelligence at the edge is also the focus of [31], where a layered architecture is presented to describe the deployment of distributed applications in edge platforms. A layered model is also proposed in [32] for the virtualization in a central cloud. In all these works, the architectural schema mostly focuses on the hardware virtualization aspects. A detailed view of the functional layer of a DMS or Energy Management System (EMS) and of the interactions necessary to deploy and coordinate the power system applications is instead missing. Moreover, the modularity of the software deployment is not explicitly discussed.
Other works emphasize the benefits of cloud computing in terms of elasticity of the resources allocation, availability and reliability. The architectural view in [33] deals with the migration of power system applications to the cloud, highlighting the interconnections between cloud and existing EMS. Such a solution is also validated in the field, thereby confirming the benefits associated to the elastic provisioning of computational resources in the cloud. The authors in [34] describe the framework for implementing an EMS on a virtual private cloud. Such a solution improves reliability and security with respect to a public cloud implementation and it was successfully implemented in a real power system. The proposal in [35] focuses on the DMS. A cloud-based implementation is presented, together with the details about resources utilization and the benefits in terms of resilience, scaling and provisioning. All these proposals offer an architectural view complementary to the one presented in this paper, since they mainly focus on the cloud set-up rather than on the design and functional coordination of the software within the DMS.
Looking at the software deployment, a number of works recently proposed the use of microservice-based architectures in contrast to classical monolithic systems. In [36], a cloudbased platform is used for implementing a grid restoration service. The implementation is based on FIWARE, which builds upon a service oriented architecture [47]. This proposal is however limited to a specific application and does not give an overall view of a DMS or EMS. A modular implementation of power applications via microservices is also recommended in [37]. However, no details are provided here on the coordination of the DMS functional blocks. The work in [38] proposes a microservice-based smart metering infrastructure enabling distribution automation services. This proposal provides the details about the functional interactions between power system and IT components, but possible implementation at the edge and integration of legacy systems are not discussed. In [39], microservices are instead used to deploy some distribution grid applications directly at the edge. Also in this case, no details are provided for the integration of legacy systems and a comprehensive view of the overall DMS implementation is missing. All the above works, moreover, do not indicate the adoption of containerization technologies.
The use of lightweight containers to host the microservices is a key feature of some recent proposals. The authors of [40] and [41] present an EMS based on containerized microservices. Specific solutions are proposed here to dynamically adjust the pod redundancy to build a fault-tolerant system with very high reliability. Both solutions have been also implemented in the field. However, no specific details are provided about the functional layer of the EMS. Moreover, distributed implementation or integration with existing systems are not explicitly discussed. In [42], a container-based architecture for an Advanced Metering Infrastructure (AMI) is presented. This proposal considers most of the key aspects discussed also in this paper, such as software modularity, edge implementation, and integration with legacy system. However, it deals with a smart metering infrastructure, which has different peculiarities with respect to a DMS. This paper presents a microservice-based architecture using container technology for the implementation of a DMS. The proposed architectural view differs from previous proposals because it focuses on a functional viewpoint, namely on the definition and interconnection of the DMS software components. Key aspects related to the DMS implementation are also discussed, such as cloud virtualization, edge deployment, integration of legacy systems, and unlocking of turnkey services from third-party providers. Table 1 provides an overview of the features addressed in this paper in comparison to the other proposals discussed in this section. Overall, this paper brings the following contributions: • it presents a modular architecture based on containerized microservices for the implementation of the software components of a DMS, focusing on the definition of the needed functionalities and their interactions; • it presents an exemplary instantiation of the proposed architecture using open source software components, which has been tested and validated in the field; • it offers a view of different implementation options, like edge deployment or extension of already existing DMSs; • it discusses the business implications potentially arising from the proposed paradigm, underlining the possibility for a multi-vendor provision of DMS modules within an open market of turnkey services.

III. DMS REQUIREMENTS
The changes currently occurring in the distribution system introduce specific requirements, which should be reflected in the architectural design of next generation DMSs. Table 2 provides an overview of DMS requirements derived from the main features foreseeable in future distribution grids. Such requirements and their possible implications for the DMS design are discussed in the following subsections.

A. REAL-TIME COMMUNICATION
A first, obvious requirement for the DMS is the (near) real-time bidirectional data transmission (here and in the VOLUME 10, 2022 following, near real-time indicates the communication or transmission of data with small latencies or delays). This requirement is already present in today's distribution grids, but future scenarios will further emphasize it. In fact, the increasing penetration of renewable sources makes distribution grids more active, but also much more unpredictable, intermittent and dynamic with respect to the past. This calls for the real-time monitoring of the system with fine-grained time resolution as well as for the prompt reaction to possible events, or undesired conditions, via automatic control procedures. In modern IT platforms, this can be achieved with publish/subscribe communication mechanisms, which allow easily forwarding streaming data to multiple applications as well as triggering event-based applications. The publish/subscribe paradigm also facilitates data sharing among applications, removing interdependencies between data producers and consumers. It can provide unified access to both data coming from the field and results produced by applications. This is key to coordinate multiple algorithms and obtain advanced management of complex distribution system scenarios. In addition, the publish/subscribe principle also allows isolating the application development from the process of gathering and storing data, thereby simplifying application development and increasing re-usability of applications [48].

B. INTEROPERABILITY
Another main requirement for the DMS is to guarantee interoperability at different levels. First of all, interoperability is required in terms of connectivity towards heterogeneous devices and equipment in the field. To this purpose, the DMS should support the associated communication protocols of these devices and interpret them towards the applications. It should thus support relevant standards for substation automation and telecontrol (such as IEC 61850 [49] and IEC 60870 [50]), for smart metering (e.g. IEC 62056 [51]), for Phasor Measurement Units (PMU) data transmission (IEEE C37.118.2 [52]), while allowing the flexible integration of additional communication protocols if and when needed.
Interoperability is also required within the DMS itself for application-to-application data exchange. A major interoperability issue is in fact that DMSs usually have their own data models and proprietary protocols, which prevents the interconnection of applications developed by different vendors [23]. This problem can be handled by using transparent and standardized data models, such as the Common Information Model (CIM) [53], and mapping the exchanged data onto such data models. These mappings should be easily configurable to support also changing protocols and applications.
Last but not least, interoperability will be increasingly required also towards other IT infrastructures, such as those associated to energy market, transmission system operators, energy aggregators, smart cities, etc. The operation of the distribution system will be in fact more and more affected by the behaviour of other energy actors as well as interconnected with other systems and networks (e.g. district heating) [54].
The DMS will thus need specific interfaces for sending and retrieving relevant data to/from partner systems. This can be key also for the development of new applications unlocking better system awareness and smarter grid management.

C. SCALABILITY
The acquisition of measurement data with high reporting rates, the connection of end user smart meters and the collection of additional information from external parties clearly emphasize the need to deal with very large amounts of data. The DMS must be able to scale to handle the amount of incoming data as well as the additional information generated by applications. IoT and big data technologies are specifically conceived to deal with the scalability issue and offer a variety of solutions for this [9]. The use of cloud (either public or private) and edge cloud computing could further help to make the DMS quickly scalable [15]. Computing resources might be allocated closer to the edge, e.g. in a substation, or centralized, e.g. in the control room, depending on the requirements of the system operator. Reasons for a deployment at the edge could be, for example, reduced communication latency or the ability to aggregate information before it is sent to the control room. A central private cloud or a public cloud, which might be distributed over several locations, improve flexibility in terms of resource sharing between different applications and redundancy.
Close to the scalability requirement, the DMS must also be easily extensible, namely it should allow new applications and features to be added quickly and without compromising existing applications. Addition of new or patched applications or system upgrades must be feasible in a running DMS without affecting its service availability. This calls for high modularity of the DMS architecture. Such an aspect will be more and more crucial in the future, since the distribution grid scenario will quickly evolve, bringing new challenges and problems that could require a fast deployment of countermeasures.

D. RELIABILITY AND SECURITY
As the DMS functionalities will be essential for operating the distribution grid, reliability is also a main concern. The DMS must be continuously available and operate at expected levels of performance at all times. It should not have single points of failure to ensure resilience and improve reliability. In case of severe issues, it should allow isolating the affected subsystem and maintain functionality of the other services. Using cloud systems and virtualisation approaches could help to achieve these targets by distributing applications, replicating key components to provide redundancy and mirroring data.
While the digitalization process and new IT technologies unlock a wide set of opportunities, they also bring new security threats. Cybersecurity is a major requirement that must be guaranteed for any DMS solution [55]. This firstly requires DMS components and their communications to be secured and to make a continuous effort to apply and maintain best-practice cybersecurity techniques. Specific security policies should be in place to monitor for malicious activity or other violations, to respond to incidents, search for known/unknown threats and consider the security of processes and technologies. Traditionally, DMS/SCADA have used isolated communications networks for security reasons; the use of a private cloud for the DMS applications can fulfil the need to isolate these systems while avoiding the security risks of employing a public-cloud solution. Public clouds typically offer a larger degree of redundancy and distribution but the large number of different types of applications hosted in these environments may also lead to unforeseen interdependencies. For private clouds, redundancy on a local level can be provided in the same way as for on-premise solutions, which are in use today.
Security does not only depend on the architecture but of course it depends on the implementation as well. Open source implementations do not offer ''security through obscurity'' but they have other benefits. Since open source is transparent, it becomes easier to track and analyse dependencies, which improves supply chain security. One concept that supports this activity is the software bill of material (SBOM). Besides sharing resources in terms of personnel and IT is facilitated by open source development. The LFX security portal developed by the Linux Foundation is a good example. The Linux kernel itself shows that open source can support the operation of critical infrastructures since already today control room software is running on Linux based operating systems.

E. COST-EFFECTIVE CUSTOMIZED SOLUTIONS
The distribution sector is very diverse. It varies for size of the operational areas, number of connected customers, network characteristics, etc. This implies that different scenarios will exist. As an example, rural, industrial and urban grids could have very specific problems to be addressed and could leverage upon a quite different set of options for grid management. Some grids could be more affected by problems related to the connection of DG or new types of loads (e.g. electric vehicles and heating), others can experience issues associated to the ageing of the physical infrastructure or to harsh environmental conditions. As a matter of fact, different DSOs will have different challenges and priorities that require solutions tailored to their grid scenario.
In addition to this, DSOs themselves are also very diverse. In the European Union, for example, there are more than 2400 DSOs [56]; some serve a large number of customers and operate the distribution system of an entire country, others serve few customers across the distribution grid of a small municipality. Small and medium utilities are likely to have a limited number of resources, IT personnel and skills [23]. DMS solutions should hence cover also their needs and possibly be cost-effective. Opening and unbundling the market for DMS services to more vendors would be a way to increase competitiveness and lower the prices. Considering alternative business models, such as pay-per-use, could be an additional option to avoid large upfront investments and make the digitalization process more affordable for all DSOs.

IV. DMS MICROSERVICE-BASED ARCHITECTURE A. ARCHITECTURE COMPONENTS
The proposed architecture meets the requirements identified in the previous Section by allowing an easy integration of multiple services needed for the smart management of the distribution grid. This subsection describes the different layers and components of the architecture, while the next subsections discuss more in details the benefits associated to the use of microservice and containerization approaches for the software deployment. Figure 1 shows an overview of the proposed architecture. At the bottom of the architecture, the grid interoperability services ensure the interconnection of the DMS platform with grid devices and components installed in the field. The grid interoperability services are essentially dedicated software adapters, which are designed to provide a twofold functionality. On one side, they are in charge of communicating with the field devices exploiting the communication protocol in use by the device. On the other side, they are the translators responsible for the conversion of the data from their original structure to the data model and format used within the platform (or vice versa, depending on the direction of the communication flow). The communication of the grid interoperability services towards the DMS platform is based on a publish/subscribe pattern. Therefore, these adapters need a publisher interface to forward the data retrieved from the field and a subscriber interface to receive the actuation commands (or other messages) generated by the DMS applications that are to be sent to the field components. Given the heterogeneity of devices and communication protocols, multiple grid interoperability services may be necessary depending on the measurement and automation infrastructure available in the field.
On top of the interoperability layer, the message broker is the key component allowing (near) real-time communication following the publish/subscribe mechanism. It acts as a router that receives the messages sent by the publishers and forwards them to one or more subscribers. The routing of the messages to the subscribers is based on message topics. Data sent by publishers are always labelled with a specific topic and applications can filter the data they receive by selecting the list of topics they subscribe to. The message broker thus mediates the communication between field devices and applications, and among different applications, avoiding any interdependency between data producer and consumer(s) and making sure that each application only receives the data it needs (i.e. those for which it subscribed). In addition, the message broker is also responsible for buffering the communication and managing traffic spikes, and it can provide additional features, such as tracking the correct delivery of messages to the subscribers and providing temporary storage for the data to be delivered. To ensure scalability and improve reliability, a distributed implementation of the message broker is also possible.
In the proposed architecture, data flowing through the message broker are consumed by (near) real-time applications. This category includes all those applications that operate continuously to support the grid management as well as event-based applications that should react immediately when triggered by specific events. State Estimation (SE) and Optimal Power Flow (OPF) are examples of applications working at regular time intervals that need to receive updated data in real-time. The Fault Location Isolation and Service Restoration (FLISR) is instead an example of event-based application. In this case, the application is inactive for most of the time, but it must react promptly if a fault message arrives. The publish/subscribe mechanism significantly facilitates delivering both the input data and the application results in real-time. To this aim, these applications need to be equipped with a publish/subscribe interface for the communication with the message broker.
The application layer of the architecture also includes other applications without stringent real-time requirements. Load Forecasting (LF) and Demand Side Management (DSM) for the day-ahead scheduling of energy resources are examples of these applications. In this case, the applications do not require to receive data in real-time, but rather to get access to sets of historical data from the data management services. To this purpose, a request/response communication mechanism is implemented and REST APIs are provided to query the databases. The architecture does not put any constraint on the database technologies to be used within the data management service. Different solutions can be used to store different types of information, such as static and time series data, and last generation technologies, like graph databases, can be integrated to store metadata with their relationships to enable semantic-based applications. Databases are the main components within the data management module and, similar to the broker, they could be implemented in a distributed way for scalability reasons. Beyond providing storage functionalities, the data management service additionally include tools to manage the access to the databases, to receive data from the message broker, to aggregate/maintain the data and to ensure data persistence.
As discussed in Section III, an important requirement for future DMSs is the possibility to connect to other relevant IT systems (e.g. market platform, weather forecast providers, etc.). Specific connectors are implemented to this purpose. Similar to the grid interoperability adapters, these connectors have the double role to allow the communication with the partner systems from one side, and to carry out the data translation needed to convert the external data into the data model/format used within the platform on the other hand. These connectors are interfaced to the rest of the DMS platform either via the message broker or via the REST API gateway, depending on the type of data exchange or data request and the associated requirements.
At the upper level of the architecture, the visualization layer provides the tools and Graphical User Interfaces (GUI) to present the data to grid operators. This can include geographical representations, time graphs, dashboards with alerts and alarms, etc. The GUIs access the data via the REST API, which gives the possibility to easily customize the visualized data by modifying accordingly the queries. Last but not least, security must be ensured across the entire platform and the communication channels. Different options can be put in place to enable a secure and trusted communication, such as using Transport Layer Security (TLS) and Virtual Private Networks (VPN). Public-key cryptography and further authentication mechanisms can be adopted instead to verify the credentials of entities requiring access to the data.

B. BENEFITS OF MICROSERVICES
In the proposed architecture, one of the main features is the use of microservices for the deployment of the software components and for providing a highly modular and scalable solution. Microservices and containerization are the latest developments in the ICT and IoT domain towards greater modularity. They give the possibility to easily integrate, deploy, upgrade or replace a large number of services in order to flexibly accommodate the DSO needs.
The microservice approach is a popular architectural style in which an overall business or technical goal is achieved via the parallel execution of a set of small and independent processes, each one performing a well-defined task [19]. The microservices can interact with the other services or components deployed in the platform only via their input/output interfaces and using lightweight communication mechanisms. In the proposed architecture, each of the blocks are software components that can be seen as an independent microservice. Some of the main benefits associated to the use of microservices are: • clear definition of the interfaces between different services; • fully independent development of each microservice; • easier understanding and maintenance, since each service performs a clear and small task; • easier computational load balancing, because services can run in different environments and replication numbers; • possibility of polyglot software development.
In addition to this, the use of microservices with clearly defined interfaces removes the need to adopt a vendor lock-in monolithic system and opens to the integration of multivendor solutions, where each service can be purchased from a different vendor according to the trust, quality and set of functionalities offered together with the service. From a technological perspective, this allows overcoming some of the main limitations related to monolithic systems, such as slow upgrade of existing functionalities, difficult integration of new applications and poor optimization of the runtime environment, which are associated to the presence of an underlying large and complex code base. From a business standpoint, this leads to a service-oriented framework that can unlock a new market of IT and power system services where multiple vendors can offer their products, thus increasing competitiveness, cost-efficiency and quality. Last but not least, a DMS design with plug and play microservices offers the opportunity to DSOs to easily customize their system, to test new services, to dynamically upgrade applications or replace obsolete ones, thus enabling them to promptly face new challenges arising in their grid. It should be noted that these benefits can be exploited independently of whether the software is deployed in a public, private or edge cloud environment.
In the following, the terms microservices and services are used as synonyms: the first one is used to put emphasis on the architectural concept, the latter to refer more generally to specific software components.

C. BENEFITS OF CONTAINERIZATION
In recent years, the deployment of microservices is often done in combination with the so-called containers [57]. Containers can be defined as lightweight environments that integrate only the infrastructure and management tools needed to execute the service. They can be stored in a library, launched quickly and shut down easily when no longer needed. Containers enable each microservice to have exclusive access to resources such as processor, memory and libraries, which are essential for the microservice execution. The small size of container images makes it practical to deploy individual services in containers. From a scalability perspective, this is the best solution to design microservice-based systems that can scale quickly owing to a simple and lightweight deployment model.
Among the other benefits, containers also improve the isolation of the environment where the microservice runs, which ensures that microservices running in different containers will not conflict with one another. Therefore, containerization increases security, especially if the operator applies features related to resource and permission limits offered by container orchestration tools.
Containers do not require any specific programming framework or server to run and provide a consistent environment regarding dependencies like programming language runtimes and software libraries, and this allows them to be easily ported to other machines and operating systems. In this way, containers play a key role in facilitating the seamless transfer of microservices from a platform to another, fostering portability and reusability.
Overall, the use of containers for the deployment of microservices leads to the following main benefits: • easy replication and light deployment of applications using container images (similar to the use of virtual machine, but with advantage to be much smaller and to start and stop much faster); • scalable deployment of large number of microservices thanks to the small-size of the containers and of the embedded microservices; • optimization of the hardware usage, with consequent minimization of the hardware requirements needed to run the microservices; • provision of an isolated environment for the execution of the microservice ensuring that different microservices will not conflict one each other; • no requirements for the underlying operating system, which allows wide portability and reusability of the created containers; To safely run containers in a platform, a container orchestrator is needed. The orchestrator introduces a high-level abstraction layer that enables multiple containers to run on VOLUME 10, 2022 host machines and share resources without the risk of conflict. This simplifies the administration of large containerized environments, which is critical to ensure large scalability. The orchestrator also handles load balancing, to ensure that each container gets the necessary resources, and it monitors container health, automatically rolling back changes or shutting down containers that do not respond to pre-defined health checks. It automatically restarts failed containers, reschedules containers when some nodes die and can shift containers seamlessly between servers on premises and in the cloud. Overall, this enables the administration of thousands of containers running simultaneously and unlocks large scalability of the designed eco-system.

V. FIELD IMPLEMENTATION
A practical implementation of the service-oriented DMS presented in this paper has been carried out in the context of the European projects SOGNO [20] and PLATONE [58]. The designed DMS has been deployed and tested within different scenarios in multiple laboratory and field trials across Europe. While the exemplary DMS does not have all the features of a traditional DMS, the sample implementation reported here demonstrates the feasibility of the proposed ideas and allows pointing out possible benefits achievable via the proposed service-oriented architecture. In the following, the set-up adopted for the laboratory and field trial carried out at RWTH Aachen University is presented. Figure 2 shows the platform and software components adopted for this trial referring to the same architectural view presented in Section IV. In the field trial, the DMS platform has been used to enable the real-time monitoring of a portion of the RWTH campus grid. To this purpose, at the grid devices and component level, six in-house built low cost PMUs [59] have been installed to provide measurements with one second reporting rate. The PMUs communicate via LTE and have been customized to send their measurement data in JSON format using the Message Queuing Telemetry Transport (MQTT) protocol [60]. In this way, the PMU data are directly published to an MQTT message broker without the need of any intermediate data translation. The other source of data for the platform is the real-time simulator used for the laboratory trial. Real-time simulations have been used to preliminarily test and validate the developed DMS platform as well as for the validation, through software-in-the-loop simulations, of power system applications that could not be directly tested in the field. This aspect emphasizes one of the benefits of the proposed service-oriented architecture, namely the possibility to connect simulators and to test new applications already at an early stage of the development process, using exactly the same infrastructure and set-up deployed in the field. In the laboratory trial, a dynamic phasor-based real-time simulator, called DPsim [61], has been adopted to run different tests and scenarios. Similar to the PMUs, DPsim has been equipped with an MQTT publisher/subscriber interface for the direct communication with the message broker.
The MQTT protocol mentioned above is used within the platform for the real-time communication via the publish/ subscribe mechanism. This is a lightweight messaging protocol very popular in the IoT domain that is recently capturing attention also in the power system sector [62]. Since in this sample implementation both field devices and simulators directly talk MQTT, the set-up implemented here does not require any interoperability module. Adapters for the IEC 61850 and IEC 60870 protocols (based on the open source libraries available in [63]) have been used in other field trials of the SOGNO project. The real-time data exchange, both between microservices and field devices and among microservices, is coordinated by RabbitMQ [64], which acts as MQTT broker. The payloads in the MQTT messages are in JSON format, with a syntactic and semantic definition that was decided within the SOGNO project. In addition to the real-time data, many applications also require information about the grid topology. Grid data have been modelled following the Common Information Model, as specified in the IEC 61968 standard [53]. The use of standardized data models is a key aspect, since it allows defining standard interfaces that can be re-used in different applications and platforms.
In the application layer, the DMS has been equipped with the following monitoring and control services (developed in-house) for grid automation: • a State Estimation (SE) service for the real-time monitoring of the grid operating conditions, based on the algorithms presented in [65] and [66]; • a Power Control (PC) service for the real-time control of the active and reactive power of distributed generators and energy storage systems to avoid overvoltage conditions, derived from the algorithm presented in [67] • a Power Quality (PQ) service for the computation of some PQ indexes, such as power factor, voltage and current unbalance factor, etc.; All the real-time services have been developed in Python and contain an MQTT publisher/subscriber interface to receive the input data and send the output results. Each service publishes its final results using a dedicated message topic. This allows for coordinating different services to achieve higher level complex functionalities. For example, the PC and PQ services may subscribe to the results of the SE service to use these data as input. In this context, the proper coordination of multiple services is thus subordinated to the clear definition of the input data requirements and the data output of each service. The SE, PC and FLISR service additionally have a purposely developed interface, called CIMpy, for importing the grid information from the CIM files. The LF service, since it does not have real-time requirements and it should access a large set of historical data, directly connects to the database via the REST API gateway. The database used for data persistency is InfluxDB [68], which exploits Telegraf [69] as additional plugin for the real-time data collection. InfluxDB can be easily interconnected to Grafana [70], which is the employed visualization tool. The user can manage the system, and access and visualize relevant data via the REST API Gateway. Figure 3 and Figure 4 show, as an example, some of the Grafana dashboards used for the visualization of the real-time measurements and for the presentation of the state estimation results, respectively.
Each of the grid automation services was designed, developed and operated as a microservice. Each of the microservice applications is installed together with its required software dependencies within a virtual container. This makes sure that the microservices are properly isolated from each other and interact with each other only via the defined interfaces. To this purpose, Docker [71] has been used as container runtime. The virtual containers allow an easy replication of the setup required for the service application, as these containers are instantiated from template files describing the setup, namely Docker images. The orchestration of virtual containers enables to run multiple applications together, each of them in a dedicated container environment. Kubernetes [72] has been used as open-source orchestration solution, which enables to deploy and operate the containers on single as well as multiple host systems.
As it can be observed, apart from the power system applications, which were developed in house, all the rest of the platform builds upon open source software components that are largely used in the IoT domain. The solution is not vendor locked-in and software components can be easily replaced with different ones as far as the input/output interfaces are clearly defined. Moreover, thanks to the development as containerized microservices, some of the presented software components have been reused also in other trials in Ireland and Romania, within different platforms. This proves the portability of the developed components and shows the possibility of fast deployment of the grid intelligence and of new services, with minimal integration efforts (for the deployed power system applications, only few settings in the configuration files had to be changed to adapt to the new grid scenarios). Overall, the experience gained from the field trials confirms that the proposed service-oriented architecture can unlock a low cost (thanks to open source services), fast (only minor modifications to configuration files needed), scalable and extensible deployment of intelligence in the distribution grid. VOLUME 10, 2022

VI. BUSINESS AND IMPLEMENTATION SCENARIOS
The proposed service oriented architecture can lead to many changes not only from a technological point of view but also from a business perspective. Unbundling the DMS in multiple microservices allows in fact many stakeholders to enter the market for the modernization of the distribution system by offering their products or services. Figure 5 shows the main technology providers potentially involved in the process of digitalization and automation of future distribution grids. Similar to the past, sensors and hardware suppliers will of course continue to play a key role, since devices, meters and actuators will be more and more needed in the distribution grid both to obtain system awareness and to implement the desired automation schemes. Telecommunication operators can expand their business, going beyond the simple connectivity of field devices and offering services associated to network slicing, cybersecurity and edge cloud. The main change of paradigm comes however with the DMS implementation. Thanks to the microservice philosophy, in fact, each power system application can be potentially offered by a different provider as a turnkey service. This opens the possibility for multiple vendors to participate into a new market of distribution grid services, which would be more easily accessible also to Small and Medium Enterprises (SMEs) specialized in the development of specific applications. Service providers will have the possibility to compete in this market also by applying new business models, such as pay-per-use, which can be an option to build trust and to attract small and medium size DSOs with limited upfront investment capabilities. In a similar way, different IT providers can offer their solutions for the IT components, such as for data storage, management or visualization. This opens to the implementation of customized IT solutions with modules coming from different specialized vendors.
The high modularity of the proposed architecture also allows providers of new types of services to easily enter this market. This can be interesting above all for highly innovative companies that could offer novel tools not traditionally employed in the power system sector. In today's scenario, this could be the case for companies specialized in the development of big data and machine learning applications. Through the modular design of the DMS architecture, innovative services could be deployed and tested in a sandbox environment in order to prove their business value for DSOs. Despite the modularity of the proposed DMS platform and the reduction of the integration issues via the deployment of microservices within containers, some integration efforts can be still needed, above all in the case of deployment of large infrastructures. In this case, IT engineering companies could play the role of facilitators and support DSOs for the overall deployment of the software or for the integration of new functionalities. Last but not least, cloud providers can provide to DSOs options alternative to on-premise deployment by offering public clouds, private clouds or on demand cloud computing resources in the form of Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS). Cloud services can help reducing business process costs and can be thus an interesting option for many DSOs.
Overall, the scenario here depicted highlights the opportunity to move towards a much more open and heterogeneous market of services for distribution grid management, which would increase competitiveness and quality. This would also allow accommodating more easily, quickly and flexibly the very diverse needs of different DSOs. Developing some components or the entire DMS as open source can unlock even more benefits. Two major system operators describe their experience of working with and as part of the open source community for several years in [73]. They conclude that some software projects would not have been feasible if they had been developed as closed source due to a lack of resources. From a practical perspective, however, it is clear that this transition cannot take place suddenly and that it is rather an incremental process. DSOs have the responsibility of managing a critical infrastructure and they may be conservative and reluctant towards new solutions until they become mature and worthy of trust. From this point of view, different implementation scenarios can be imagined. In the short term, DSOs already equipped with a relatively modern DMS would of course keep relying on it. Microservices can in this case be thought as an extension of the legacy system ( Figure 6). This would still offer the opportunity to DSOs to test innovative applications or auxiliary tools like, for example, recent algorithms based on last generation artificial intelligence. To this purpose, microservices can be installed in open loop so to avoid any possible interference with the already existing DMS.
A full implementation of the architecture according to the scheme presented in Section IV is more difficult in the short term, but still possible in some scenarios. The first one is the case of small/medium size DSOs with strong needs of modernization and smart management of their system. In this case, such DSOs can find in the proposed architecture a costeffective solution, even because they could initially opt for the deployment of a limited number of needed microservices and progress gradually towards the digitalization of their grid. A second scenario is the deployment of intelligence in LV grids. Most of DSOs are in fact blind at LV level, even though this is the portion of the grid more affected by the  issues brought by DG and other distributed energy resources. The proposed architecture can be a very practical solution in this case to quickly integrate monitoring and automation functionalities down to the LV level of the grid.
A progressive shift towards this paradigm goes together with the emergence of a market of DMS services, applications and tools offered by service providers that are mature and trustworthy. In the long term, additional possibilities can be also unlocked by further developments in the ICT sector. As an example, the availability of edge cloud resources can easily enable a distributed implementation of the proposed architecture, as shown in Figure 7. In this scenario, DSOs will have large flexibility in the design of their management schemes through the choice of the applications to be run at local or central level. Such a distributed implementation clearly helps in achieving scalability, in relaxing the communication towards the upper level control center and in decoupling different portions of the distribution system, while still allowing the coordination of services running locally. With reference to this last point, in Figure 7, the communication of local services with the central platform refers to distributed implementation of applications coordinated via a hierarchical scheme, whereas the communication among local services is associated to deployment and coordination of services in a fully decentralized way. As it can be observed, the same conceptual architecture presented in Section IV can be replicated for the deployment of the DMS intelligence both centrally and locally in the edge.

VII. CONCLUSION
This paper presents a service oriented architecture based on last generation IoT technologies to address the requirements of digitalization and smart management of DSOs. The proposed use of microservices, deployed within software containers, allows obtaining a highly modular and scalable framework as well as extensibility of the platform functionalities and upgradeability, portability and reusability of the software components. The microservice philosophy already commonly adopted in the IT sector, once applied to the distribution system scenario, lays the foundation for a completely new way of deploying intelligence in the power domain. In particular, it moves away from traditional implementation of monolithic and vendor lock-in solutions, unlocking new opportunities for a more open, flexible, dynamic and competitive market of turnkey services (both power and IT) for DSOs. While such a change of paradigm may require time to take place, a transition in this direction has the potential to really boost the process of digitalization of distribution grids and to finally conduct them into the smart grid era.