Fundamental changes in the current energy grids, towards the so called smart grids, initiated a range of projects involving extensive deployment of metering and control devices into the grid infrastructure. Since in many countries, the choice of supportive information and communication technologies (ICT) for the grid devices still remains an open question, benchmarking tools aimed at predicting their behavior in the deployed solution play an essential role in the decision-making process. This paper presents a Prolog-based simulation environment, named Grid Mind, primarily intended for the very purpose. The tool was successfully used to generate simulation scenarios in several smart-grid related projects and became a self-standing simulation tool for the evaluation of information and communication technologies used to deliver lowvoltage metering and monitoring data. The tool is continuously evolving, aimed to become an integral part of the future energy grid design in the Czech Republic and beyond.
JAN ROSECKY1;2, FILIP PROCHAZKA2 and BARBORA BUHNOVA1
With the growing emphasis on energy security policies, the electricity distribution
grids are currently facing a profound transformation challenge. The new approach,
referred to as the smart grid, implies intelligent distribution throughout the grid,
aiming at automated problem detection and handling as well as power balancing in
order to minimize distribution-related losses and fully use the potential of
unregulated renewable power sources
Having up-to-date, accurate and complete data is crucial for achieving the
aforementioned goals, hence serious attention must be paid to measuring and detecting
mechanisms as well as distribution of relevant data to other grid agents. The latter
implies the need for a solid communication and information-technology
infrastructure developed along with the energy infrastructure. Its requirements, side-by-side
with the economical and legal constraints, form an investment dilemma of vital
importance for the future development of the energy grids (
Apart from the pilot projects, simulation has been playing a major role in the
design of smart-grid solutions. A number of smart grid simulation tools and
environments has been introduced (Mets et a
In this paper, we introduce a SWI Prolog-based smart-grid simulation tool,
named Grid Mind, used as a rule-based simulation scenario generator in
The paper is structured as follows: An overview of related work, mainly focusing on other smart-grid simulation tools and environments, is presented in Section 2. Section 3 introduces the overall architecture of the domain-independent core of the tool and its main components. A brief presentation of the modeling approach used in a real industrial project is provided in Section 4. Finally, Section 5 sums up the lessons learned, reflecting on the major issues and drawbacks, most of which are being solved in the on-going work, also mentioned in the section.
Recently, an extensive review on existing smart grid modeling and simu
As for the former, various agent-based energy and communication infrastructure
co-simulation tools have been introduced to analyze the influence of different types
of control strategies, e.g. dynamic pricing or centralized control algorithms, on the
grid cell sustainability. Mosaik (
The wide-area monitoring, protection and control simulators test the influence
of real-time sensor data availability on the overall grid stability guaranteed by the
supervisory control and data acquisition (SCADA) systems. EPOCHS
Our work touches both the measuring-data harvesting (e.g. for demand-response strategies) and grid monitoring and control, complementing the state of the art with a more in-depth analysis of the dynamics of metering-data delivery delay and incompleteness, caused by simultaneous data transfers and communication channel overloading, as well as the influence on the data volume and transaction load on the metering data management system.
Grid Mind
The overall architecture of the domain-independent environment core (of Grid Mind v2), presented in this section, is depicted in Figure 1. Element storage and transformation tools form the structural core of the environment, described in Subsections 3.1 and 3.2 – a knowledge base to build the models in. The Modeler parses the model language into a canonical representation using a definite clause grammar (DCG). The three solver components, handling the model dynamics, are presented in Section 3.3. Finally, Self Monitor provides a simple logging interface, and Model Browser is responsible for json export to the GMIG visualization framework using the HTTP JSON library.
Model elements and relations between them form a (hyper)graph, stored in the Storage component, extended and modified during the simulation using a set of functions provided by the Transformer component. The elements and relations are represented as Prolog terms and predicates, respectively, stored in a Prolog database. An element in Grid Mind v2 notion is a compound term of arity 3, where the first argument is the name of the element, the second argument is a list of its abstractions and the third argument is so-called element construction, a list of roles the element plays in domain relationships. An exemplary element is in Figure 2. The relations used for orientation in the spectrum of elements, whose semantics is described further in this section, are: (i) abstraction, (ii) role, (iii) context member, and (iv) causality.
Elements represent concepts on various levels of abstraction and detail. Thus, in
order to enable the construction of more general models or meta levels, elements
are not classified into classes, instead, they are placed into an abstraction hierarchy,
inspired by the notion of concept lattices
In the second generation of the tool, the notion of attributes referred to roles. The third generation extends it to all relations (with the exception of abstraction).
The environment is responsible for attribute inheritance, fostering the code reusability: When an element attribute is searched, than if not found at the queried element, it is sough on the higher levels of the abstraction hierarchy.
An example of an abstraction hierarchy chain is: power_grid_element secondary_substation node_substation substation_1234
According to the hierarchy and the definition of node_substation in Figure 2, substation_1234 will also power 30 consumption points without having to state it explicitly.
Domain relations, be it between elements or an element and a general term, are modeled using so-called roles. “To play a role for” is a ternary relation, used to model domain relations, with the following semantics: Definition 2. Value V plays role R for element E iff E has a property named R with value V .
In Grid Mind v3, a role is also considered to be an element. That allows the definition of role ontology as well as structuring the roles into contexts, facilitating the queries (e.g. get all the location characteristics of a given element) by bringing additional mechanisms of role polymorphism. Definition of node_substation in Figure 2 assigns value 30 to node_substation role how_many_consumption_points
If V is also an element, an inverse role can be defined: Definition 3. IR is an inverse role to R iff for every pair of elements E 1, E 2: E 1 plays role R for element E 2 iff E 2 plays role IR for element E 1.
The support of the use of the inverse roles in queries is now being implemented in the third generation of the tool.
Contexts form logical clusters of elements, often serving as sub-models of particular problems. E.g.
Definition 4. Element E is a member of context C iff it fits the context definition, i.e. is a logical part of the context.
In the third generation of the tool, the relation will become ternary, taking into account the role a particular element plays in a given context.
The simulation nature of the environment implies the need to record the causalities between events. As further mentioned, event reactions cause additional events in the future, making the causal relationship ternary: Definition 5. Action A is a causality between events E 1 and E 2 iff A caused E 2 in reaction to E 1.
A series of predicates used to store, update and query the aforementioned
relations, as well as the transitive and reflexive closure of the binary ones, forms the
conceptual core of the simulation environment. Blurring the barrier between types
and instances naturally supports the construction of domain-specific modeling tools
without getting lost in "meta-muddle", as described in
Potential relation dependencies and stochastic relations motivated the need to work
with implicitly constructed relations, with actors derived as a result of an
operation. Procedural knowledge-base attachments called lambda-elements or lambdas
are used for this very purpose. The name has been chosen to emphasize the
conceptual connection to transparent intentional logic – TIL (
Definition 6. Lambda element is a compound term of arity 4: lambda_elem( Id, Variables, Guards, Predicates ), evaluable for given Variables iff Guards hold, and true for given Variables iff evaluable and Predicates hold.
The dynamics of the environment is handled by a set of so-called solvers—engines used to generate elements or generally modify the element graph using model lambda elements. Lambdas are often parts of rules passed to the solvers.
Depending on the nature of relations that an element participates in, it can be classified either as an extension or an intension. The TIL-inspired classification indicates to which extent the element is modeled explicitly or, complementarily, the amount of lambda elements used in the element construction. An (ultimate) extension is an element whose relations contain no lambda. The more the element relations are constructed using lambdas, the more intensionally-modeled the element is.
Intensions form a natural way of defining patterns for generating, especially when particular role values for a given set of elements are picked randomly or depend on one another. The generating process is realized by so-called extension making—constructing explicit form of element by finding values of its intensionallyconstructed relations, evaluating their lambda elements. When evaluated lambdas contain non-deterministic predicates, multiple extensions with all admissible relation combinations can be generated.
Pseudo-code in Algorithm 1 in Appendix A represents a naive extension making process used in Grid Mind v2, where an evaluable lambda is sought within all element’s unevaluated lambdas. When the lambda is evaluated, the process repeats, since the evaluation may have influenced evaluability of other lambdas by instantiating a free variable shared by the lambdas. The cycle loops until a fixed point is reached, meaning no further lambdas can be evaluated. Grid Mind v3 will implement more sophisticated extension-making strategy, based on variable dependency graph. In that case, when seeking an evaluable lambda, only so far untested lambdas or those, whose guards variables may have been instantiated by one of the evaluated lambdas, are to be tested on evaluability.
Also referred-to as Production Rule Solver, the Context Generator represents an approach to element or general term generation, mainly used for the data exports. Initial rules, containing lambdas returning initial collection content, form the bootstrap of the resulting collection. Iterative rules contain lambdas determining the set of records to be added to the resulting collection based on its current content. The solver iteratively processes the collection until a fixed point is reached, meaning no further new records are added. The pseudo code of the process is presented in Algorithm 2 in Appendix A. The solver proves particularly useful for obtaining constrained breath-first search results initiating from a given set of elements, e.g. for finding transitive consequences of a given event.
Finally, the Consequence Generator handles the actual simulation process. Simulation timeline is a queue of events to be processed, sorted by their timestamps. Intensionally-defined registered actions (subscriptions) may react to the events, producing a set of output events to be put back into the timeline. After adding the set of initial events (e.g. “start a measuring process”) to the timeline, the Consequence Generator can be executed to run a simulation, ending either when the queue is empty, or with an explicit termination (while handling an event). Causalities are recorded and stored during the simulation. Algorithm 3 in Appendix A represents the pseudo-code of the simulation run process.
Our approach to simulation analysis builds upon the TIL notion of possible worlds
(
This implies that apart from the simulation itself, the responsibilities of the environment also include the execution of individual simulation runs, orchestrating the entire analytical process. In its full extent, the environment and related visualization framework should be able to provide extensive assessment of a given set of possible technical solutions under different conditions. Practical reasons why so far this has not been made possible are discussed in Section 5.
This section presents the crucial models and preview of result visualization from a recent simulation project, assessing the communication technologies for transfer of low-voltage metering and monitoring data in a prepared pilot project of a Czech energy distribution company. Since the planed deployment of the monitoring devices within the project scope only covered tens of secondary substations in different locations, the simulation was used to assess the influence of sharing a communication medium, particularly a base transceiver station (BTS), by multiple substations in a fully-deployed setting, meaning every secondary substation equipped with a monitoring device. Assuming the independence of an individual cluster of substations around a BTS, the problem was reduced to simulating the behavior of 8 clusters, each containing approximately 10 substations obtaining smart meter data from individual consumption points. The simulated scenarios covered one week of life with various cellular network communication technologies implemented, under changing conditions including dynamic external load in the used communication network infrastructure or dropouts of individual communication devices at end-point meters. The dynamics of the following characteristics was observed: (i) data delivery latency; (ii) reliability (percentage of successfully transferred data) of measurement data reading, signaling and command transmitting; (iii) communication network data load; (iv) end-system data and transaction load.
The communication infrastructure was modeled as a graph of network devices connected via communication lines. A channel connecting two devices refers to a graph path (lines and devices) between them. The model of a network line has been abstracted to the following characteristics with values added based on pilot project observations:
Throughput, meaning the amount of data transmitted through a line or device at a time unit. Channel throughput is equal to the minimum throughput of a channel component.
Latency, constant delay added to the throughput-caused delay for every data transfer. Channel latency is equal to the sum of the component latencies. Reliability, i.e. the probability of losing or damaging a transferred message.
Reliability of a channel is equal to the product of its component reliabilities.
Expected delivery time of a data batch of size S , transferred through a channel with latency Lch , comprising component C with throughput Tc, external load Exc and amount of concurrent transfers Ac, was computed as:
S = min Tc Exc + Lch
c2ch Ac
When starting a new transfer or finishing an old one, the volume of transferred
data and new delivery-time estimates were computed for every transfer sharing
a channel component with the affected transfer. Transported data batches
corresponded to those of IEC 60870-5-104 protocol
The used network communication models are a subject to further discussion and verification, planned to be conducted in cooperation with other Czech universities in the upcoming months. Our experience suggests that a similar abstraction can be applied to the communication models without a significant loss of precision of the behavior characteristics of the overall simulation setting. Interface to an existing network simulator would inevitably cause a drop of performance, closing the door to an efficient state-space analysis of a particular technical solution.
The conducted project have shown that the introduced environment can be successfully employed for realistic simulations demanded by industry. The SWI Prolog database used as a knowledge base core is able to handle hundreds of thousands of element records, each having from tens to thousands of connections. When loaded, the overall general smart grid model comprised over 1,000 elements. Over 6,000 elements were stored in the knowledge base when the project models have been extensionized. Apart from other elements, simulation runs ended up generating 150,000 up to 400,000 events during 5 to 20 minute run times, depending on the complexity of the simulated scenario.
Figure 3 represents an exemplary simulation output. The setting simulated daily data reading procedures via the public GPRS infrastructure. The upper timeserie presents normalized portions of hourly simulated dropouts of communication devices at end-point meters and external network load, potentially caused by extensive data transfers in the area when using a public telecommunication operator’s network. The lower timeserie represents the resulting hourly line load caused by (compressed) metering data transfers. As can be seen, lowering the capacity of the communication media raises the overall volume of transferred data, due to repetitive transfers. On the other hand, dropouts of individual communication devices at end-point meters prevent them from communicating at all, shifting the load to the following days.
The crucial contribution of the project covered not only the results of the conducted analysis but also the structured representation of the modeled problem, revealing the potential of the used knowledge base architecture. Both helped establishing a solid ground for the planned deployment of the metering and monitoring devices onto the secondary substations in the Czech Republic.
The second generation of the tool proved its usefulness in a number of projects, which at the same time helped us to identify the areas of possible future development. This chapter sums up the lessons learned from the usage of Grid Mind v2.
Due to complex model structure, dependencies and a set of specific predicates designed to use the environment, there is room for improvement from the usability perspective. In particular, the tool usability could be improved by encapsulating the model – extensionize – simulate – evaluate approach (see Section 4) entirely into the notion of the models. In order to do that, models should state their dependencies explicitly in a model header, to be processed by the model reader component.
Stochastic nature of the models requires multiple simulation runs to be executed in order to get statistically-relevant results. Extensive simulation analysis in a single-threaded Grid Mind v2 could be sped-up by the parallelization of individual simulation runs. When implemented, not only will Grid Mind be able to determine the probability characteristics of a particular solution, also extensive state-space analysis, determining the system behavior under various conditions, could be conducted on a computation grid in a matter of minutes.
The uprising interest of the Czech energy distribution companies, outlining
several upcoming projects, has recently initiated the development of the third
generation of the tool. The aforementioned points triggered a range of design changes,
improving the tool performance and usability. The design of the conceptual core is
still a subject to further research. Particularly a comparison with existing
Prologbased approaches like
The paper introduces the Grid Mind modeling and simulation environment, currently used for the analysis of smart grid information and communication technologies. The environment core is domain independent, believed to be usable for any simulation-analytical task. Domain models are structurally represented in a knowledge base, forming a graph of elements and relationships between them. Various abstraction levels, connected by the abstraction-specialization relations, represent a way of creating reusable model patterns, adjustable for specific purposes. Trinity of solvers handle the model dynamics, including the simulation engine and the generator of model elements. The models cover individual technical processes and routines, including reading and error-handling strategies.
The environment has been successfully used in several real industrial projects. The presented case study has validated its usefulness and revealed its capabilities, as well as its limitations. The architecture of the knowledge storage combined with the power of the three solvers has shown its potential, not only for the simulation analysis itself but also for forming a structured knowledge base of the local power grids and their future-development scenarios. The uprising smart-grid simulation projects demand in the Czech Republic illustrates how the fruitful cooperation between academia and industry can effectively solve complex problems in real world.
procedure solve_prod_rules(+Init_rules, +Iter_rules, -Result_set) Result _set .add (solve(Init _records)) Changed true while Changed do
Changed false for all Record in Result _set do for all Rule in Iter _rules do
New _records Rule.apply_on(Record ) Set _just _changed Result _set .add (New _records)
Changed Changed _ Set _just _changed end for end for end while end procedure
procedure run_conseq_generator(+Tmln_in, +Subscrs, -Tmln_out) Terminate false Tmln Tmln_in while (Tmln 6= []) ^ :Terminate do
Event _in Tmln.pop() for all Subscr 2 Subscrs do if Subscr .reacts_on(Event _in) then
Terminate Terminate _ Subscr .execute(Event _in; Events_out ) Tmln.put _sorted (Events_out ) for all Event _out 2 Events_out do
record _causality(Event _in; Subscr ; Event _out ) end for end if end for end while
Tmln_out Tmln end procedure