This paper presents a solution to the Smart Grid case at the Transformation Tool Contest (TTC) 2017 using the .NET Modeling Framework (NMF). The goal of this case was to create incremental views of multiple models relevant in the area of smart grids. Our solution uses the incremental model transformation language NMF Synchronizations and the underlying incrementalization system NMF Expressions.
A (well-behaved) in-model lens l : A ,! B between types A and B consists of a side-effect free Get morphism l %2 M or(A; B) (that does not change the global state) and a morphism l &2 M or(A B; A) called the Put function that satisfy the following conditions for all a 2 A; b 2 B and ! 2 :
l & (a; l % (a)) = (a; !) l % (l & (a; b; !)) = (b; !~) for some !~ 2 :
The first condition is a direct translation of the original PutGet law. Meanwhile, the second line is a bit weaker than the original GetPut because the global state may have changed. In particular, we allow the Put function to change the global state.
An unidirectional (single-valued) synchronization block S is an octuple (A; B; C; D; A C ; B D; f; g) that declares a synchronization action given a pair (a; c) 2 A C : A = C of corresponding elements in a base isomorphism A C . For each such tuple in states (!L; !R), the synchronization block specifies that the elements (f (a; !L); g % (b; !R)) 2 B D gained by the function f and the lens g are in the dependent isomorphism B D.
f
A B
A C B D
C
g
D
A schematic overview of a synchronization block is depicted in Figure 1. The usage of lenses allows these declarations to be enforced automatically2. The engine simply computes the value that the right selector should have and enforces it using the Put operation.
A multi-valued synchronization block is a synchronization block where the lenses f and g are typed with collections of B and D, for example f : A ,! B and g : C ,! D where stars denote Kleene closures.
Synchronization Blocks have been implemented in NMF Synchronizations, an internal language integrated into C# [HB17]. 3
3.1
We discuss the solutions to the outage detection and the outage prevention tasks separately in Sections 3.1 and 3.2.
In NMF Synchronizations, the support for multiple input pattern elements is rather limited. As a reason, we experienced with NTL [Hin13] that multiple input elements is a rare case, but required a tremendous amount of code to support it. At the same time, the advantages of a true support for multiple input elements over transformation of tuples is limited.
Therefore, the easiest way to support multiple input pattern elements in NMF Synchronizations is to simply use tuples as inputs. Then, the model matching has to be adapted to match tuples instead of elements. Therefore, the main rule synchronizes a tuple of the CIM model and the COSEM model with the resulting view model.
MainRule
(M eterAsset P hysicalDevice)
AssetT oConsumer (join)
:RootElements:Of T ype < EnergyConsumer >
2If f was also a lens, then the synchronization block can be enforced in both directions.
Listing 1: The implementation of the main rule for outage the outage detection task
In particular, the definition of the synchronization block in Listing 1 is implemented in a call to the SynchronizeManyLeftToRightOnly. The types and the base isomorphism MainRule used in the synchronization block can be inferred from the context and the explicitly specified dependent synchronization rule AssetToConsumer.
Because .NET has a hard implementation of generics3, a type filter can be easily specified by passing generic type arguments. NMF also contains an overload of the OfType type filter that accepts two type arguments and keeps the collection interface.
In particular, the incrementalization system NMF Expressions that is used in NMF Synchronizations does support joins available through the query syntax of C#. A second synchronization rule then implements the kept attributes for every such a tuple, as depicted in Listing 2. 1 public class AssetToConsumer : SynchronizationRule < Tuple < IMeterAsset , IPhysicalDevice >, IEnergyConsumer > { 2 public override void DeclareSynchronization () { 3 SynchronizeLeftToRightOnly ( 4 asset => Convert . ToInt32 ( asset . Item2 . AutoConnect . Connection ) , e => e. Reachability ); 5 SynchronizeLeftToRightOnly ( asset => asset . Item2 . ElectricityValues . ApparentPowermL1 , e => e. PowerA ); 6 SynchronizeLeftToRightOnly ( asset => asset . Item1 . ServiceDeliveryPoint . EnergyConsumer . MRID , e => e. ID ); 7 SynchronizeLeftToRightOnly ( 8 asset => asset . Item1 . ServiceDeliveryPoint . EnergyConsumer is ConformLoad ? 9 (( ConformLoad ) asset . Item1 . ServiceDeliveryPoint . EnergyConsumer ) 10 . LoadGroup . SubLoadArea . LoadArea . ControlArea . MRID : 11 (( NonConformLoad ) asset . Item1 . ServiceDeliveryPoint . EnergyConsumer ) 12 . LoadGroup . SubLoadArea . LoadArea . ControlArea . MRID , 13 e => e. ControlAreaID ); 14 SynchronizeLeftToRightOnly ( SyncRule < LocationToLocation >() , 15 asset => asset . Item1 . Location , e => e. Location ); 16 } 17 }
Listing 2: Implementation of kept attributes and references in the outage detection task
Listing 2 essentially consists of five synchronization block where each synchronization block is responsible for the synchronization of an attribute or reference of the target model. In case no synchronization rule is provided (like for the first four synchronization blocks), implicitly the identity of the inferred type is used. Two further synchronization rules synchronize location and position point. 3.2
In the implementation of the outage prevention task, the principle approach to use tuples to synchronize multiple inputs is the very same approach as in the outage detection task. 1 public class MainRule : 2 SynchronizationRule < Tuple < CIMRoot , COSEMRoot , Substandard >, Model > { 3 public override void DeclareSynchronization () { 4 SynchronizeManyLeftToRightOnly ( SyncRule < MMXUAssetToVoltageMeter >() , 5 dr => dr . Item1 . IDobject . OfType < IMeterAsset >() 6 . Join ( dr . Item3 . LN . OfType < IMMXU >() , 7 asset => asset . MRID , 8 mmxu => mmxu . NamePlt . IdNs , 9 ( asset , mmxu ) => new Tuple < IMeterAsset , IMMXU >( asset , mmxu )) , 10 model => model . RootElements . OfType < IModelElement , IPMUVoltageMeter >() ); 11 12 SynchronizeManyLeftToRightOnly ( SyncRule < DeviceAssetToPrivateMeterVoltage >() , 13 dr => dr . Item1 . IDobject . OfType < IEndDeviceAsset >() 14 . Join ( dr . Item2 . PhysicalDevice , 15 asset => asset . MRID , 16 pd => pd .ID ,
3This means that the generic type arguments are still available at runtime. Our solution is quite concise as it only consists of 58 lines of code for the outage detection scenario and 195 lines of code for the outage prevention scenario. Both numbers include empty lines as well as lines that only contain braces. Another 140 lines of code actually run the benchmark.
The performance results recorded on an Intel i7-4710MQ clocked at 2.50Ghz in a system with 16GB RAM are depicted in Figure 3 that list the time to update the view model after every iteration, each applying 10 changes. The results are available for the NMF solution both in incremental and in batch mode, the reference solution in ModelJoin and the solution by Peldszus et al. using eMoflon.
OutageDetection, ChangeSet: changeSequence1, Function: Update
OutagePrevention, ChangeSet: changeSequence1, Function: Update 100 ● ● )s 10 m ( e m iT 1 0.1 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
Iteration Tool ● ModelJoin NMF NMF (batch) RGSEeMoflonTGG (a) Outage Detection Task 100 ) (sm10 e m i T 1 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
Iteration
Tool ● NMF NMF (batch) RGSEeMoflonTGG (b) Outage Prevention Task
For the Outage Prevention task, unfortunately the reference solution in ModelJoin ran out of memory and hence, it is not shown on the plot in Figure 3b.
The results indicate that the NMF solution in batch mode is the fastest among the batch implementations. Furthermore, if one switches the execution mode to incremental, then this yields another speedup of roughly more than a magnitude.
The performance curve for the incremental change propagation is more rough than the performance for the batch execution. This is because propagating the change depends much more on the actual changes than rerunning the view computation on the entire (changed) model. However, interestingly, we see some spikes in the otherwise smooth curve for the batch execution. We think that this is due to garbage collection.
OutageDetection, working set
OutagePrevention, working set ● ● ●
● changeSequence1 [Mit]
Tool ● ModelJoin NMF NMF (batch) RGSEeMoflonTGG
Tool ● ModelJoin NMF NMF (batch) RGSEeMoflonTGG
Interestingly, we noted that the incremental execution mode of NMF has the least memory consumption compared to the other solutions. Incremental tools usually have a memory overhead but the advantage of the incremental execution here is that only the changes of the models have to be loaded and not all of the entire models in each iteration. 5
In this paper, we presented the NMF solution to the Smart Grid case at the TTC 2017. The solution shows how synchronization blocks, in particular their implementation in NMF Synchronizations can be used to perform incremental view computations. The resulting solution is faster than the reference implementation by multiple orders of magnitude. In particular, the ability of NMF to run the solution incrementally yields a very good performance. Erik Burger, Victoria Mittelbach, and Anne Koziolek. Model-driven consistency preservation in cyber-physical systems. In Proceedings of the 11th Workshop on Models@run.time. CEUR Workshop Proceedings, October 2016. Georg Hinkel and Erik Burger. Change Propagation and Bidirectionality in Internal Transformation DSLs. Software & Systems Modeling, 2017.
Georg Hinkel. An approach to maintainable model transformations using an internal DSL. Master’s thesis, Karlsruhe Institute of Technology, October 2013.
Georg Hinkel. NMF: A Modeling Framework for the .NET Platform. Technical report, Karlsruhe Institute of Technology, Karlsruhe, 2016.
Georg Hinkel. The TTC 2017 Outage System Case for Incremental Model Views. In Antonio GarciaDominguez, Georg Hinkel, and Filip Krikava, editors, Proceedings of the 10th Transformation Tool Contest, a part of the Software Technologies: Applications and Foundations (STAF 2017) federation of conferences, CEUR Workshop Proceedings. CEUR-WS.org, July 2017.