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.