Towards model-driven CIM-based data exchange for DSOs

To support migration of DSOs towards domain-wide standards, we propose a middleware platform for DSOs based on the Common Information Model, which is supported by a model-based approach. Initially, we conducted a domain analysis with two German DSOs, where information and requirements about the DSO domain was collected, analyzed and structured. Based on the information captured, a domain model was derived, which generalizes domain knowledge of the DSO domain. Furthermore, we then identified relevant use-cases for our middleware platform.

Using the domain model, we then derive parts of the implementation of the middleware platform within a model-driven engineering approach. The approach is intended to support efficient adaptation of parts of our platform to different distribution system operator system landscapes by utilizing the shared structure of data models and systems of DSOs and by employing model-to-model transformations.

Then, we present a modular software architecture that provides an efficient method to access interfaces of DSO data systems by utilizing lean micro-services and established web protocols. Here, based on a system landscape employed by a given DSO, we describe how single systems can be integrated into the middleware platform. The approach offers modularity with respect to offering step-by-step integration of different DSO systems, while not impeding ongoing business-relevant and day-to-day operations. Our concept aims at mapping non-CIM data to the standardized CIM data model for integrated systems. We identified the latter to represent a major keystone ability for a comprehensive DSO data exchange platform.

To apply our approach, we are implementing a vertical prototype for a single use-case scenario, which is limited in its functional scope. Functionally, the prototype demonstrates platform functionality for obtaining data necessary for network calculation, based on a data set representative of a medium-sized DSO’s grid planning department. In addition to functional requirements, additional functionalities such as a user interface and security requirements are addressed and evaluated within the prototype. For this, we followed a two-stage development methodology: Firstly, we integrated and tested the single features in our academic research environment. Then, secondly, we conducted a field test with a German DSO. The field test is performed by installing DSO data sources and systems on virtual machines equipped with real-world and representative DSO data. Note that direct integration into a DSO production environment would exceed available resources for implementation.

This section elaborates on a domain analysis for the distribution system operator domain. Here, to understand the domain and requirements of DSOs, a domain analysis was conducted with two German DSOs. Here, domain knowledge was captured in an interview process spanning multiple topic areas with different DSO departments intended to support capturing DSO requirements. For the interview process, we focused on internal DSO departments concerned with planning and operative asset management, system operation and network control, strategic asset management and regulation management, metering point operations, network documentation, accounting and purchasing as well as IT infrastructure management. For these topic areas, the domain analysis then specifically focused on eliciting requirements for DSOs with respect to challenges arising in the context of establishing smart energy systems. Based on the information elicited, we established a metamodel for capturing domain knowledge. The metamodel is visualized in Fig. 1.

Note that, based on the established metamodel, we then derive a general domain model for the domain of distribution system operators, which we described in detail in previous work (Ascher and Bytschkow 2018). Here, a domain model represents a model about the relevant parts of an application domain (Broy 2013). In this context, our domain model describes common domain elements about the distribution system operator domain, which are shared between different DSOs (e.g. common domain entities such as SCADA or GIS systems), but depending on the DSO, may occur in different representations such as SCADA systems from specific vendors or specific configurations. The goal of a domain model is to capture information about the problem domain itself, rather than the solution domain. In fact, requirements elicitation and design for a given solution can then be performed based on the domain model (See “Model-based adapters” and “Middleware platform” sections).

This section describes model-based generation of specific parts of the implementation of our overall platform. More specifically, we describe code generation of so-called adapters by automatically deriving implementation code from an implementation model as well as the domain model.

Our approach for domain modeling defines an instrument to describe the problem domain of distribution system operators, which allows describing entities and relations of a specific problem domain. For this, we employ Multi-Level-Modeling (Atkinson and Kühne 2003), which allows us to model an arbitrary number of modeling levels, where each level describes a concretization of its parent level. More specifically, our approach defines different hierarchical modeling levels M(·) for representation of domain knowledge. Here, the metamodel level (M3) defines generic domain model entities and the relations between them (See “Domain analysis” section). Then, as an instance of the metamodel, the domain model (M2) describes more specific domain entities, which occur in DSOs, such as SCADA or GIS systems of a specific vendor or data models employed by a specific metering application. Finally, as instances of the domain model, instance models (M1) describe concrete instantiations of the domain model for specific DSOs such as a specific SCADA system of a given vendor configured for a single DSO.

Based on the information encoded within the domain model (M2) and instance model (M1) levels, we are able to perform data transformations from data encoded within one system to another data model. More specifically, Model-to-Model (M2M) transformations are defined to convert one data model to another, where the transformation of a source data model to a target data model utilizes a set of functional transformation rules. Thus, the transformation rules define the conversion from individual data entities in the source model to data entities in the target model. Note that transformation rules are defined on the domain model (M2) level and are therefore independent of the specific instance data of a particular DSO. Then, based on the defined transformation rules, a transformation of specific instance data such as a specific network topology in an application-specific data model to another can be performed. In our approach, we employ M2M transformations to convert non-CIM data, which for example occurs in proprietary, application-specific data models to standardized CIM data, based on the CIM data model, and vice versa.

Conceptually, to then integrate these M2M transformation with a given system or application, we employ adapters, which are part of our platform. The core idea of adapters is to enable software systems to remain independent, where each system integrated within our platform is wrapped with its own specialized adapters. More specifically, adapters represent components of the proposed platform, which read the data input of an application, deserialize this input, map it into to a given, known source data model (i.e. the data model of a given system or application), perform a M2M transformation to a target data model, and then write the resulting output data after serializing it. Note that, in order to read data inputs from an application, we assume that the application produces this data in response to a specific query and that this data is made available to the adapter, for example as a local file. In fact, here services produce the query to a given application and execute the workflow of an adapter. An extensive description of services is provided in “Middleware platform” section. The workflow of an adapter is visualized in the right part of Fig. 2.

Technically, to implement an adapter within a given scenario (e.g. a sequence of activities with a given system), we define a generic implementation model. Here, as required conceptually, the implementation model of an adapter encodes the information necessary to read an input, perform a transformation, and write a specific output. Based on the system an adapter is implemented for, input and output data models are referenced using the information encoded within the domain model, i.e. the proprietary data model for the given system as well as the standardized CIM data model, the transformation should be performed to or from. The implementation model of an adapter is visualized in the left part of Fig. 2.

Based on this information, implementation code is then derived from the implementation model using code generation. To then tailor the implemented adapter to a specific DSO system configuration, we supplement the information encoded in the implementation code with information from the specific instance model (of the domain model) for the given DSO. Therefore, using the information encoded in the instance model, we adapt adapters dynamically to the specific system configuration of a DSO. Note that the approach is intended to support easy platform adaptation for heterogeneous DSOs by utilizing commonalities in data models and systems.

The technical part of our platform was aligned along the requirements and use-cases, which were identified during the domain analysis of the participating DSOs (see “Domain analysis” section). Over 100 use-cases were determined and described during this analysis, for the reason to mark the communication patterns behind it. We consider patterns as a sequence of events such as versioning and merge, market processes such as offer/bid/dealclose and underlying distribution of data streams.

Afterwards, an architectural style viable for the requirements of DSOs were chosen, based on correlation between communication patterns and corresponding communication methods (see Fig. 3). As it fully covers the communication patterns identified, the Representational State Transfer (REST) architectural style (Medvidovic and Taylor 2010) was selected. REST denotes a architectural style for distributed systems in general and web services in particular, and defines a stateless client-server protocol. In addition, is scalable with respect to queue-based methods, is suitable for integrating current safety requirements and technology as well as enables efficient system integration, control and maintainability. Furthermore, REST offers lightweight applicability and flexibility in industrial IT environments. By utilizing established and open technologies within our approach, system operators can choose to combine open-source and closed-sourced systems or components, which enables synergies between them. By means of integrating independent applications into the platform, a wide variety of different functionality can be accommodated. This includes the connection of simulation tools to grid calculation applications, the utilization and condition monitoring of the distribution grid, the prediction of energy consumption and weather, and addition of new energy systems as well as changing load profiles (Alberts et al. 2014).

As shown in Fig. 4, the primary software systems remain independent, and are each wrapped with their own specialized adapters. Adapters then allow data exchange within our platform. The bottom line shows a selection of further configurations when connecting new systems. Depending on the components involved, a wide variety of integration variants can be implemented.

Single use-cases are then realized using services. Two types of services are employed: use-case services and application services. Use-case services are responsible for the coordination of the interaction of individual components within the respective use-case, perform the control flow of involved data and provide a corresponding user interface. Instead, application services encapsulate either an existing specialized technical application or provide subject-specific functionality. Using this, application services only have to implemented once and can be reused by services of different use-cases. As shown in Fig. 5, each service is consisted of a server-module and a core-module. Core-modules include specialized control logic for accessing data or processing subject-specific data. Note that implementation code for integrating subject-specific applications and code for core-modules doesn’t comprise a REST interface. Implementation is performed in the given target language such as Python or Java. In addition, the complete control flow of the realized use-case is implemented in core-modules. Then, finally, adapters for the conversion from and to the CIM are integrated within core-modules.

The server-module contains the main-loop and converts REST to procedure calls. For parallel calls, the server provides separate threads as process environments. Likewise, an exception forwarding mechanism is realized, where exceptions are translated by the server-module into a REST string and back into an exception by the calling proxy. Communication with other services is performed via the proxy-module, which converts service-internal function calls to REST for each service.

As part of the project, one scenario was selected from 100 different use cases identified as part of the performed domain analysis and was implemented within a case study. For this, the scenario "data acquisition for network calculation" was selected, which represents a vertical prototype covering all relevant features of the proposed platform. In Fig. 6, the scenario is visualized conceptually.

In terms of data, the scenario covers a wide range of links between data sources of different IT systems that are relevant to network calculations for DSOs. In terms of source systems, data from a GIS system, a metering system and an asset management system is utilized. In this concrete scenario, the target system represents an application for network calculation. Additionally, a subject-specific service was employed between the data sources and target system. This service enriches the network data provided by the GIS system with asset and metering data in order to generate a low-voltage grid model that is consistent from medium voltage to every single low-voltage house connection. The goal of the prototype was to cover a scenario highly relevant for and benefiting to a participating DSO, while enabling application of the approach in a real-world setting.

The Common Information Model (CIM) has been recognized as a key element to connect different DSO systems and applications using a standardized data model and enable interoperability for smart grid applications (Hargreaves et al. 2014; Ascher and Bytschkow 2018). In that, a substantial challenge consists in bridging the gap between application-specific data models and the application-independent CIM data model in order to make data accessible for applications requiring multiple data sources such as power system simulations. As a result, several approaches have focused on this challenge in the past.

The CIM2Matpower (CIM2Matpower) package supports transformation of a CIMv14 ENTSO-E profile transmission system network model to a Matpower case structure (Zimmerman et al. 2011). However, currently, the tool is only intended to support transmission system operator data structures. Armendiariz et al. (2015) introduce a method to convert proprietary application data models to the MATLAB Matpower data model (Zimmerman et al. 2011) by utilizing the CIM. The developed tool is intended to support the conversion from utility data such as network topologies and equipment data into MATLAB Matpower to support simulation studies evaluating different technical options for future DSO operations. Gomez et al. (2017) propose an model-driven engineering approach which applies model-to-model transformations between CIM and the Modelica system modeling language (Mattsson et al. 1998). Here, the approach focuses on using M2M transformations to derive Modelica models for dynamic power system simulations only. In contrast, the scope of our approach aims to provide a holistic platform employing adapters between heterogeneous DSO applications and the CIM. Finally, Bredillet et al. (Bredillet et al. 2010) propose a smart grid service-oriented architecture, utilizing model-driven development and incorporating standards such as the Common Information Model (CIM) and the IEC 61850 standard. Goering et al. (2016) propose multi-layer service-oriented architecture utilizing the CIM. Finally, Haq et al. (2011) leverage the CIM to integrate systems from different application vendors within an Service Oriented Architecture.