We present a solution to the Outage System Case of the Transformation Tool Contest 2017, based on the bidirectional model transformation language eMo on. The case comprises two tasks, in which the goal is to produce custom model views on a set of input models from a smartgrid system, eventually allowing power outages to be detected and prevented. To facilitate understandability, our solution uses eMo on's declarative transformation rules. Moreover, to address performance, we use a general-purpose-language preprocessing step contributing to the identi cation of elements participating in the considered views.
to historical ones. Technically, each of the views required for these tasks can be expressed as a model, based on a view-speci c meta-model (see Fig. 1a and Fig. 3 in [Hin17]).
In this paper, we present a solution to the Outage System Case based on eMo on [ALPS11], a bidirectional model transformation language and tool based on the paradigm of triple graph grammars (TGGs, [Sch95]). The main use-case of TGGs is the synchronization of two models, called left-hand side and right-hand side model (LHS, RHS). The user speci es a set of rules, which map LHS meta-model classes to RHS meta-model classes by using a dedicated correspondence model. From these correspondence rules, one can automatically generate transformation code for realizing model synchronization in two directions: the forward direction for propagating changes of the LHS to the RHS model, and the backward direction for propagating changes of the RHS to the LHS model.
In our application of eMo on to the Outage System Case, we interpret the set of input models as the LHS, and the output view as the RHS. Since the views in our scenario are not required to be editable, we only need the forward direction in order to produce and update the required views. We provide the code for our solution at https://github.com/SvenPeldszus/rgse.ttc17.emoflon.tgg.
The rest of this paper is structured as follows: In Sec. 2, we provide an overview of our solution. In Sec. 3, we show details, including example rules. We evaluate our solution in Sec. 4, and give a conclusion in Sec. 5.
In this section, we present the details of our solution. For each task, we rst explain the preprocessing step, followed by an explanation of the transformation. 3.1
Preprocessing. The preprocessing step has two goals: First, it uni es the input models into the glue model used as input for the transformation. Second, it enriches this model with auxiliary references and model elements to support a more compact speci cation and a more e cient matching.
To unify the input models, we introduce a dedicated container element called Root. A Root holds a CIM model, a SCL/LN model and a COSEM model. In addition, it has some references to enable a more convenient retrieval of involved elements: in particular, all MeterAssets of the CIM model are stored in a reference called assets. Finally, it holds a set of MeterAssetsAndPhysicalDevicesPairs to identify pairs of PhysicalDevices and MeterAssets with the same ID.
In a purely declarative speci cation, nding these pairs can be highly ine cient, since the underlying implementation may consider all pairs of PhysicalDevices and MeterAssets, ltering them to keep only those with matching IDs. To overcome this, we compute these pairs upfront using a Java method of 15 lines of code, where we consider each PhysicalDevice and MeterAsset element only once, while maintaining a a hash map. This enables us to identify the required element pairs in linear time.
Transformation. The view produced to solve Task 1 includes three distinct classes: EnergyConsumer, Location, and PositionPoint. Our transformation includes a TGG rule for producing each of them, amounting to three basis TGG rules in total. These basis rules are further extended by rule re nements [ASLS14] for dealing with special cases, such as the if-then-else in the ModelJoin speci cation.
To understand eMo on rules, it is important to consider that they declaratively specify how the considered models should be related in the end. They do not specify the process of how these relationships are established| instead, this process is realized in the generated forward and backward transformation code.
In Fig. 2 we present an example of a TGG rule and a related re nement. The upper half of Fig. 2 illustrates the EnergyConsumer rule. The base rule represents lines 2 to 4 of the ModelJoin source of Task 1. The rule includes green nodes and edges for specifying newly created elements, and black nodes and edges for specifying existing ones. LHS model elements are shown with a yellow background, and RHS elements are shown with a red background. Elements of the correspondence model are indicated as diamonds. Beneath the graph, the rule includes two attribute conditions, specifying equality between pairs of values. Lax equality (laxEq) is used to compare a boolean to an integer, based on an underlying Java implementation. Note that the shown graphical representation of rules is a read-only representation generated by eMo on; the actual rule creation and development was performed using eMo on's textual syntax.
In a nutshell, this rule speci es the correspondence between a MeterAsset{PhysicalDevice pair and an EnergyConsumer. The forward transformation generated from the rule establishes that for each such pair in the input model, a corresponding EnergyConsumer will be generated in the output model. The attribute conditions ensure that the attributes of the newly created EnergyConsumer obtain the values according to the speci cation. Note that MeterAssetPhysicalDevicePair was not contained in the original model; as argued above, we added this during the preprocessing to enable a more compact speci cation and improved performance during matching.
The re nement EnergyConsumerWithID shown in the lower half of Fig. 2 deals with the following fact: For the ServiceDeliveryPoint of the considered MeterAsset, an existing EnergyConsumer may or may not exist. If it exists, it needs to be treated according to the view speci cation. We implement this distinction using rule re nement. The underlying semantics is to glue together the re nement with all of its super-rules, based on name equalities of the included elements. In the example, this allows us to apply the additional attribute condition to the target model, enabling us to propagate the LHS EnergyConsumer's mRID to the RHS EnergyConsumer's ID eld, in case the former exists. 3.2
Preprocessing. The preprocessing for task 2 follows the same basic ideas as for Task 1. We unify the input models, populate certain convenience references and add auxiliary model elements to facilitate a compact speci cation and optimized matching. The custom parts of interest in the glue meta-model is a reference mmxus ++ pair : MeterAssetPhysicalDevicePair
EnergyConsumer ++ a
++ b Transformation. Similar to Task 1, we organize the overall TGG rule speci cation into rules for speci c classes from the view meta-model and rule re nements for dealing with special cases thereof. This time, more di erent elements types are involved and there are fewer special cases per element type: We distinguish 19 rules in total, only three of them needing re nements.
Fig. 3 illustrates two of these rules. The Location rule speci es the correspondence of Location elements in the LHS and RHS models, which are related to an existing MeterAsset and PMUVoltageMeter, respectively. To comprehend why we need to specify the related MeterAssetMMXUPair as well, we rst give some details on how the matching process works.
In essence, the LHS is matched as a rst step and after that, the RHS is matched. In TGGs, it is assumed that for each LHS match, we can identify a corresponding RHS match. However, in our particular scenario, the issue is that we do not transform all of the MeterAssets, but only some of them, strictly speaking those with a corresponding MMXU. Therefore, specifying the MeterAssetMMXUPair (which, again, is produced during preprocessing) saves us from matching MeterAssets with no RHS counterpart, which would lead to an error.
Based on the correspondence manifested in the Location rule, the Position rule speci es the correspondence of PositionPoint classes in the LHS and RHS. Again, we use attribute conditions to specify the equality of involved attributes, which will be used during the forward transformation to propagate the values from the LHS element to the RHS counterpart. In the overall forward transformation process, all Locations will be transformed rst, which enables all PositionPoints to be transformed subsequently. 4
In this section, we evaluate two aspects of our solution: conciseness and performance.
According to the speci cation, conciseness is to be evaluated in terms of the number of Lines of Code (LoC). The measurement shall include \the model views and glue code to actually run the benchmark", while the code for converting the change sequences can be ignored. We present the results in Table 1a. Since our solution comprises declarative rule speci cation as well as some imperative orchestration code, we list both separately, amounting to 1312 LoC for rules and 364 for code. The glue code for running the benchmark comprises 119 LoC.
For the performance evaluation, we show the execution times for both tasks when applied to the input change sequences. All experiments have been performed on an Ubuntu 16.04 LTS PC with an Intel i5-6200U and 8 GB of RAM of which our implementation was allowed to allocate up to 6 GB for the experiments.
Location pair : MeterAssetMMXUPair
a
Location meter : MeterAsset location : Location
Mode batch batch batch batch batch batch
Time[ms] det/prev
Mode batch batch batch batch batch batch 825.9/975.0 350.2/504.9 483.3/477.1 281.4/312.2 256.7/329.1 217.1/235.5 (b) Performance (task 1) (c) Performance (task 2)
We presented a solution to the TTC 2017 Outage System Case based on eMo on. Following a simple preprocessing step in Java, we facilitated a compact declarative speci cation as well as an e cient execution of our solution. We believe that the overall solution combines the best of both worlds by providing a mostly declarative speci cation, while using imperative code for performance-critical parts of the rule application process.