Smart-grid-framework-co-simulation-using-HLA-architecture_2016_Electric-Power-Systems-Research

Electric Power Systems Research 130(2016)22–33Contents lists available at ScienceDirectElectric Power SystemsResearchj o u r n a l h o m e p a g e :w w w.e l s e v i e r.c o m /l o c a t e /e p srSmart grid framework co-simulation using HLA architectureAndréN.Albagli ∗,1,Djalma M.Falcão 1,JoséF.de Rezende 2COPPE/UFRJ –Programa de Engenharia Elétrica,Caixa Postal 68504,CEP 21941-972Rio de Janeiro,RJ,Brazila r t i c l ei n f oArticle history:Received 16April 2015Received in revised form 20August 2015Accepted 21August 2015Available online 15September 2015Keywords:Smart grid HLACo-simulationa b s t r a c tHLA is an architecture that was developed in 90s for military co-simulation.From year 2000it became a standard and much attention has been given to it because of its ability to integrate different applications,providing synchronization among them.Smart grid is one of the applications that may take advantages of this approach because it connects different information and communication technology (ICT)archi-tectures and power systems.The goal of this paper is to describe several aspects of co-simulation,that are required to develop a framework,and discuss the simulation architecture design.We propose an integration of simulators Simulink,Omnet++and JADE,a multiagent framework,to develop smart grid applications.In addition,we illustrate this integration using one case study of a 33modified radial-distribution network when power failure happens.We demonstrate the ICT and electric models and simulation results.©2015Elsevier B.V.All rights reserved.1.IntroductionModeling and simulation is an area of great importance that can help to troubleshoot problems related to performance and improve user experience.Nevertheless,the development of a sim-ulator that approaches all aspects of an environment is time consuming,expensive and requires a large amount of experience in different subjects.One way to avoid these problems is to divide-and-conquer,i.e.,to use different simulators integrated in such a way that they behave as one.One of the recent application areas of modeling &simulation is smart grid.Smart grid is a concept that applies ICT technology and infrastructure to the electric network environment.Smart grid deals with different applications like Demand Response (DR),Tran-sient Analysis (TA)or network power failure,which requires an intelligent system to control the network behavior.The biggest challenge in modeling and simulating smart grids is the creation of a scalable architecture that could easily describe the interac-tions among different simulators and provide a global view of the communication infrastructure,energy network and software appli-cation layer.Each simulator has its own development language,interfaces and mathematical methods to describe environment behavior which turns integration more complicated.Depending on∗Corresponding author.Tel.:+5521985779990.E-mail addresses:andre.nudel@ufrj.br (A.N.Albagli),falcao@nacad.ufrj.br (D.M.Falcão),rezende@land.ufrj.br (J.F.de Rezende).1Electric Engineering Program.http://www.pee.ufrj.br .2System Engineering and Computer Science Program.http://www.cos.ufrj.br .the size of the network that is being studied and the details to be observed,it may require different large scale machines [1].There are two approaches to develop co-simulations:first,design an “engine”which deals with data transfer between sim-ulators and synchronization [2–4];second,use a framework as a “glue”that can control the flow of information among them.In this way,HLA framework architecture becomes a good approach because of loose coupling among simulators.The first integration step is the design of a meta-model that describes all objects that exchange data types among simulators in a high-level view.Modeling and simulation using HLA architecture require some steps.The IEEE standard 1516.3describes the best practices and procedures to create distributed simulation and execution (DSEEP)[5].It identifies seven important high-level steps from the defini-tion of the goals to the simulation execution and data analysis.This article will provide the most of these seven steps to develop an inte-gration famework for three different softwares:Matlab/Simulink,Omnet++and Java Agent Develop Environment (JADE)[6],includ-ing ontology definitions and meta-model for data exchange among simulators.The remainder of the paper is organized as follows.In Sec-tion 2,the reasons for studying co-simulations are presented.In Section 3,a literature review is introduced.In Section 4,some concepts review about model development,multiagent systems,high-level architecture (HLA),ontologies and meta-models are pro-vided.Section 5describes the proposed simulation architecture.In Section 6,proposed ontology models are developed as the basis for a meta-model creation.In Section 7,a complete meta-model for object model template is presented.In Section 8,it is presented/10.1016/j.epsr.2015.08.0190378-7796/©2015Elsevier B.V.All rights reserved.A.N.Albagli et al./Electric Power Systems Research130(2016)22–3323a case study of radial-distribution network reconfiguration using co-simulation.Finally,in Section9,this paper is concluded and propositions for future works are presented.2.MotivationSmart grid has been considered the next frontier of automation because new communication and information systems technolo-gies can improve reliability and availability of an energy network. This brings higher customer satisfaction and better economical results.Moreover,it can provide a higher network control and mon-itor levels and improve performance analysis of power systems. Questions like“Do wireless mesh network fulfill the requirements to be used in substation protection system?”,or“what are the risks imposed in distributed control system in case of a cyber-attack?”, or even ask“what happens if a utility uses a third party carrier to connect thousands of devices and a network congestion happens?”may be answered by a well-designed integrated environment.As co-simulation approaches different scenarios,it is very important that a solution be evaluated in detail before its deploy-ment.It has strong potential to help electric network behavior analysis with different environments and architectures and to select the right infrastructure for application under study.3.Related workIntegration of different environments imposes a strong chal-lenge as it requires different skills in computing,communication, math science,control theory and engineering in order to build and design highly complex systems.Moreover,different applications may require strong synchronization and modeling interaction.Because of these aspects there are two implementation approaches:first,develop specific integration code,which increases the abstraction level of some relevant network aspects like the suppression of communication layer protocols or not use the application domain specific language.Increasing abstraction level may lead to wrong results like not considering different types of traffic,queues or modeling a new protocol.Synchronization among these environment shall be supplied as well.Second,use a framework which acts as a communication bus which provides all methods to synchronize and exchange data.The design part refers to develop a code that calls these implemented methods and let the bus do all the job.But even this approach shows that it requires a strong understanding on how the data is exchanged and code development is time consuming.The biggest advantage is the exist-ence of a looser coupling environment among simulators,i.e,no core engine modifications are required.In[7],authors study the impact of telecommunication network failures over a power grid, using co-simulation of a network discrete event simulator(NS-2) and power distribution simulator(OpenDSS),which designs the power architecture and control scheme via scripting.Both were integrated sending control messages to NS-2without middleware or synchronization.In[8],authors create an architecture using HLA in order to inte-grate commercial off-the-shelf systems(COTS)applied to power electric control.In the paper,three different simulators are used: NS-2,PSCAD and a discrete-event system which acts much like to multiagent systems.Some scenarios were demonstrated to show the capability of transient analysis considering the effects of delay and packet loss.Although showing interesting results it does not provide details neither about integration level nor about modeling.In[9],a framework called Mosaik based on the approach of simulation environment divided into four layers:control,scenario, semantic and syntactic.In each layer,the high-level abstraction is used to represent entities and attributes.However,thepaperFig.1.Node model architecture.describes some drawbacks such as the lack of model details and the impracticability of using hierarchically structured scenarios.In[10],an architecture is proposed based on JADE framework (multiagent environment)and network simulator OPNET Mod-eler.Both were integrated using HLA framework.Although the interface between simulators and run-time infrastructure(RTI)are described,there is no detail on data exchange structure.Results are demonstrated on how background traffic affects agent response time.Moreover,the power network integration is not detailed in this work so that an end-to-end analysis is still missing.4.ConceptsNodes are considered as being constituted of three layers and are an abstract representation of an Intelligent Electronic Device(IED), illustrated in Fig.1.Thefirst layer is the electric layer,which is represented by a model developed in Simulink.All the information from electric attributes like power,voltages,currents,frequency and status are collected by the cognitive layer.This layer uses multiagents framework in order to simulate dis-tributed intelligence along the network.The intelligent or cognitive layer is implemented by multiagents using JADE middleware.This layer monitor the electric attributes by interacting with Simulink and makes decisions based on what it perceives.Its decision is represented by a command request to the actuator like“open the breaker”or“shutdown a system”.Agents are composed of different group behaviors that makes them a reasonable approach to apply in complex systems where,depending on physical aspects modeled, may have different actions.The third layer represents the communication level in which JADE messages are encapsulated and transported via communi-cation network.It interacts with other nodes via communication simulator as if it were a part of large distributed environment. The communication network will be able to simulate all physical aspects like signal propagation delay,power noise level,interfer-ence and pass the message to upper communication protocol levels.4.1.MultiagentMultiagent system(MAS)has been classified in many different ways.Some authors describe MAS as an intelligent system or hav-ing a certain level of intelligence.In a general way,the concept converges to a common definition that MAS is an entity,hardware or software,that executes tasks autonomously or in an indepen-dently way.In order to do this,the system must interact with the environment and execute tasks to achieve a specific goal.In[11],a wider concept of intelligent agent is described.24 A.N.Albagli et al./Electric Power Systems Research130(2016)22–33Agents are designed to solve a problem and are based on behav-iors implemented in each one.As they work together,they need to exchange information in order to reach a solution.Moreover,using this ability,it is possible to create an autonomous system that has properties such as resilience,fault tolerance and robustness.The ability to recover when its elements fail,or even in situations when a network reconfiguration is required,is a very important char-acteristic that can be used in power systems.This kind of robust system,which is able to adapt,treat errors and takes decisions based on incomplete information,makes its application to power systems automation very attractive.Based on these skills,an agent must know how to cooperate and communicate.Global behavior with these skills will reach,at least,a local optimal solution.The most important part in an agent is its communication.In order to keep interoperability among different agents,a standard was created.This communication model was developed by the Foundation for Intelligent Physical Agents(FIPA)and is being widely adopted in industry and academy.FIPA is an IEEE standard and specifies a set of messages exchange between agents.This interaction uses an agent communication language(ACL)which is composed of severalfields and one of them is named performa-tive.Thisfield defines the type of communicative act or speech act [12]which states that messages represent action or communicative acts.In a real distributed environment,agents send messages using HTTP or HTTPS protocols.As HTTP uses transport control proto-col(TCP),it assures packet delivery by congestion avoidance.HTTP messages do not need to be fully transmitted via RTI.Each node synthesizes it and the payload length is calculated.This value is used to compose another simple message,in XML format,that is transmitted through RTI.4.2.OntologyIn order to provide a consistent data exchange and the right level of interoperability between simulators,it is necessary to use the same semantics among them byfirst creating an ontology.For-mally,ontology represents the knowledge of a specific domain which captures high-level concepts that are used to create mod-els based on a common vocabulary.Besides representing a list of objects,it defines properties and relationships between objects according to a specific domain of knowledge.It is demonstrated that developing an ontology for modeling&simulation[13]can bring the following benefits:1.It is demonstrated that building an ontology is important for cre-ating a robust intelligent system and modeling and simulation applications.2.Ontology became standard and can be reusable.No need to“rein-vent the wheel”.3.Ontology helps to share a common knowledge among applica-tions.Although it is not a requirement when using HLA,it helps to build semantic interoperability among the simulators byfirst cre-ating a common sense of elements to be used.4.2.1.Standard IEC61970/61968The International Electrotechnical Commission(IEC)are stan-dards61970[14]and61968[15]applied to electric network and distribution network respectively and are widely accepted by util-ities and industry.This suite defines a CIM(Common Information Model)that is an extensible model that will serve as a guideline for future smart grids interoperability[16].CIM can be viewed as an ontology as it defines the classes,properties and relationships among electric elements.As it is an information model,it is language agnostic and can be implemented in a structure that can be derived in different ways like a database schema,C++or Java code.Both standards define an ontology of electric models which will be used as a base model in this paper and expanded to support new object classes for smart grid environment.4.2.2.Tools for ontology developmentThere are several tools for ontology development like Ontolin-gua[17],WebOnto[18],OntoEdit[19]and Protégé[20].Protégéis the selected tool to design our common ontology.It is an open source software developed in Java language by Stanford University to model ontologies and knowledge acquisition.It is a veryflexible software,widespread adopted,and has a GUI to edit ontology.It creates classes and an hierarchical relationship among them and their attributes known as slots).Slots are represented by a name and a value and can be of types like string,integer,float or Boolean. In order to illustrate this concept let’s suppose a subclass Breaker. Breaker has a relation of type“is-part-of”to one level above,Pro-tectedSwitch and so on until the top hierarchic level.This subclass has an attribute named AmpRating with an integer value.This struc-tured class and attributes will subside the creation of a meta-model to be used in HLA framework.This tool can also generate Java code including for JADE using a plug-in called beangenerator[21].4.3.High-level architectureHigh-Level Architecture is a framework designed by US Depart-ment of Defense and Simulation Office in order to guarantee the interoperability of warfare tools simulation.It became the IEEE-1516standard in year2000and is composed of a suite[22–24]of documents that describe the interface specification and simulation. The whole structure is known as federation and each simulator is a federate.Each federate is connected to a bus known as Run-Time Infrastructure(RTI),as illustrated in Fig.2,which in turn provides several services so that it is able to connect each simulator and control the dataflow between them.This is not only the capability of the bus but also synchronization points that assures the correct time advance.Simulink federate is in charge of simulating the electric models and send the electric attributes to the RTI bus while Omnet federate is in charge of receiving messages sent from the agents(JADE feder-ate)and route them to other agents.Finally,the Manager federate is in charge of keeping everything synchronized and start/stopping simulation as well.Each simulator exchange messages via RTI bus. However,some application program interfaces(API)development are required to interface with RTI.4.3.1.Object model templateIn order to exchange information among simulators,HLA pro-vides a data structure.This structure is part of HLA specification and is known as Object Model Template(OMT).Thisfile iscomposedFig.2.Framework architecture.A.N.Albagli et al./Electric Power Systems Research130(2016)22–3325of tables which contains object classes,attributes with their inter-nal types,interaction classes,parameters and some other valuable data.It is used to describe a single simulation object model(SOM) or a whole federation object model(FOM).The goal of these tem-plates is to provide a common information model shared across simulators.Object classes and attributes can be inherited by other classes in such a way that it makes their use very similar to oriented object approach.4.4.Models&metamodelsThere are few concepts about model definition.A model of a system is defined as a“description of an abstraction of a reality according to a certain conceptualization”[25].The Object Manage-ment Group(OMG)Model Driven Architecture(MDA)defines“a model of a system is a description or specification of that system and its environment for some certain purpose”[26].Moreover,mod-els can describe structures,behaviors and interrelations between models.Depending on the details that are required to be repre-sented,some may be suppressed if they do not add any additional significance to model behavior.The FOMfile describes the infor-mation that is exchanged in run-time among federates.A typical file contains data types,object classes,interaction classes and class attributes.In order to build the object model template,an ontology model is used as the basis for implementing it.4.4.1.Relation between ontology and HLA modelsThe process of creating a federation is not an simple task.As ontology definition was thefirst step,now it is necessary to trans-form ontology models into HLA object models.In[27],the author develops a study about ontologies,models and metamodels and their different interpretations from other authors and relationships. It is stated that there are two different types of ontologies used in software engineering:(a)Domain ontologies,which are used to create a specific domainof knowledge,like power resources model and communication model;(b)Meta-ontologies or foundational ontologies,which are equiv-alent in nature to a metamodel of a modeling language and describe the concepts of domain-specific ontologies.Both can be modeled by a language like Unified Modeling Lan-guage(UML)but it does not provide all the resources to support a complete language description.Several authors[28,29]have been using the OMG approach to develop the link between ontologies and metamodels.In order to transform ontologies into models to be used by HLA,it is necessary to understand what IEEE1516Object Model Template (OMT)Standard recommends.OMT is applied either both SOM and FOMfiles.OMT consists of several components(15)described as tables.Not all of them are required but at least the following ones are necessary:object classes,attribute,interaction and parame-ter.Attributes represent the qualities or characteristics of an object class and parameters represent the variables that are used to trans-port interaction.The most adopted approach to develop this transformation is model driven engineering(MDE)which is briefly described here. MDE was developed tofill a gap of software development complex-ities and architecture design and it is an approach that combines models,transformation rules and modeling languages in order to raise the level of abstraction of a physical system[30].It has two focuses:develop a domain-specific modeling language and an automated transformation of models into code generated.Domain specific modeling language(DSML)is used for particular domain knowledge and uses graphical models to describe a software system.Code generation translates these models into source code of specific domain and in the case of integrated simulations,input files for simulators like FOM and SOMfiles.Model driven architecture(MDA)is another strategy adopted for model driven development(MDD)in software engineering.It was proposed by OMG in2003[31]in order to improve software development.Its approach focuses on a high-level modeling sys-tem creation for a specific architecture.This high-level model uses boxes and texts to describe or specify the system which,in our case, can be represented by a federation or a group of software.MDA divides the development in three tier called views:thefirst,known as Computational Independent Model(CIM),represents a domain-model of the system without details.The second,known as Platform Independent Model(PIM),which still describes the system in a high-level model developed in general purpose language like UML. The third,known as Platform Specific Model(PSM),uses the infor-mation modeled in PIM and translates to a specific platform which, in the case of simulation,is represented by RTI,a framework of services.Another approach was developed by Vanderbilt University[32] called Model Integrated Computing(MIC)which is a technology to specify modeling languages based on its tool Generic Model Envi-ronment(GME).It is a software which uses graphical interface to create models and metamodels using the concept of paradigm(a language that describes the model).The paradigm is a concept that creates other models using an UML class diagram notation and Object Constrained Language(OCL).Moreover,its architecture can be extended to create model translators into source code in several languages like Java,C#or any other language.5.Proposed architectureFig.3shows the proposed integrated architecture of simula-tors cited before.RTI middleware is implemented by an opensource software called Portico[33].Portico is adherent to the standard IEEE 1516-2010.It is supported in Java and C++and has several methods that allow data exchange and synchronization between federates. Objects used by the three federates are described in FOMfile.Each electric node model like buses,loads,switches,has an agent representing the application layer or cognitive layer.Each node assembles an HTTP message reproducing the exact commu-nication message exchanged among agents.Omnet++deals with messages in two ways:either sending the complete payload or sim-ply sending a packet with a specific length.The second option was chosen to simplify implementation.Instead of sending HTTP mes-sages to RTI,a simple XML message is created.This type of message contains essential information to Omnet++simulator,like source and destination nodes and payload length which is based on the HTTP message.Omnet++integration is designed by three classes.First,Omnet++ gateway is a C++module which is in charge of loading RTI in mem-ory,receiving messages(interactions),queuing and sending them to another class module called Txcc.The Txcc is a C++class that simulates HTTP1.1protocol.The C++Srv class is another module that is in charge of receiving sockets and sending HTTP messages back to gateway.Every time a message arrives at the gateway,in XML format,it decodes it and send to the source node in order to reproduce the network packet.As soon as the source node sends the message,routing protocol takes care of forwarding it until its destination.When packet arrives,the node sends back to gateway the same message originally sent.In this way,it is possible to sim-ulate the network characteristics like latency,packet loss,jitter.In summary,the federate agent publishes the XML message and fed-erate Omnet++subscribe it.Theflow of information is illustrated in Fig.426A.N.Albagli et al./Electric Power Systems Research 130(2016)22–33Fig.3.Integrated architecture.The module cRTIScheduler is a C++subclass that extends cSched-uler class that implements Omnet++scheduler events.A code is designed to override the default method that gets the next event schedule.It compares the Omnet++simulation time and RTI advance step time and decides to get the next event in the queue.Finally,Simulink has three modules,developed in Java,which enables integration.The module RTI starts up the RTI framework.The modules SendAttributesToRTI and ReceiveInteraction are devel-oped as matlab S-function and call Java code to interface with RTI.The first module sends model attributes such as voltage,current,reactive power to RTI while the second one receives interactions from RTI such as open/close switches.6.Proposed ontology modelsOntology development has a strong importance for modeling and simulation because it is a path to build a structured knowledge base necessary to provide a standard way to access environmentalvariables.Ontologies can build relationships among objects such that it is possible to retrieve some information in an easy way and mostly they can be reused and expanded.Moreover,ontologies have a strong importance in software development,metamodel creation and in distributed intelligence [34,35].The ontologies are separated in three layers:electric model,node model and applica-tion model.6.1.Electric model ontologyIn electric model,the standard IEC 61970and 61968are used as a starting point to develop the ontology adapted to the Simulink/Matlab environment.The core model is defined in IEC 61970-301and 61968-11.As the goal of the model is to provide a broad range of elements that can be used in a smart grid,the ontology model was extended in some specific parts as show in Fig.5.Some parts of IEC are still under development like distributedgeneration.Fig.4.Message flow between Omnet++and JADE.A.N.Albagli et al./Electric Power Systems Research130(2016)22–3327Fig.5.Electric model ontology.Just to clarify the subsequent models,the World Wide Web Con-sortium(W3C)established that in Ontology Web Language(OWL) specification,the class Thing has predefined semantics and repre-sents a set of individual or classes.It is known as the top concept of all classes.Note that some new classes were included:•SmartAppliance–Contains several intelligent appliances(air con-ditioner,washing machines,refrigerator);•PoleMountedCapacitorSystem–Represents a controlled capacitor bank to be used in a distribution network;•FACTS and PMU used in transmission system;•DistributedGeneration–Represents the models of new sources of alternative energy and Storage,which represents different sources of energy storage like fuelCells;•Battery–Divided into two new categories:CarBattery and Indus-trialBattery.•EnergyConsumer–The same class from IEC61970contains four subclasses,three of which already exist in Simulink.There is no single solution thatfits all environments.A model creation is a continuous process of evolution,validation and verifi-cation.Determining how accurate a model is and classes designed will depend on how much detail is desired and what goals were necessary to reach.Because of this,it is not possible to cover all scenarios applied to a smart grid but the intention is to provide a starting point from where the models can beexpanded.Fig.6.Node model ontology.6.2.Node model ontologyNode model represents an element from a communication net-work model that could be mapped onto agent model.We propose an hierarchy that a node is composed by two attributes:Application and NodeIdentification in the network.The Application can be divided into three subclasses:Mes-sageType,which is represented by FIPA message,the Protocol type, which is one of the transport protocol provided by JADE framework, and Name,which represents the several smart grid applications like advanced meter reading(AMR)or demand response(DR).The class NodeIdentification defines the node required to identify it in the communication network.This class has two other sub-classes:NodeID,which is an integerfield and NodeName,which is a string that represents the object name.In case of smart grids,this pair can identify the element in a network like ThreePhaseDynami-cLoad001(Fig.6).6.3.Application model ontologyIn order for JADE to correctly interpret messages sent by agents, it created a classification of all possible elements of a domain dis-course and it is known as content reference model(CRM).This classification is based on ACL which requires that the message con-tent shall have the proper semantic according to the performative parameter message.The CRM describes three types of elements:•Predicates–expressions that can be evaluated true or false.For example:(CircuitBreaker0001(IsON))•Action–represents an action that an agent can per-form.For example:(PowerSystemResource.Equipment.Distributed Generation.SolarCell(ReadAtrributes(Voltage)))•Concept–expressions that represent which elements indicate a domain of discourse.For example:(Failure(Short-Circuit))Using semantic language can improve logic complexity and make system behavior more intelligent.Now a whole logical sen-tence can be constructed like the ones shown in Fig.7.Fig.8illustrates a sample of an ontology structure that uses CRM approach and some aspects that may be used to control smart grid environment.As ontologies describe the concept of a domain of knowledge and there is no standard for this subject until now,it can be expanded to increase the number of options of actions,concepts and predicates.In order to illustrate content message exchange,two short examples of message content are illustrated Fig.9.It is possible to see the performative or speech act command‘QUERY-IF’and ‘INFORM’,the source and destination nodes and the command sent. Thefirst agent Bus0checks if the breaker ThreePhaseBreaker001has a status ON.The second one Load0informs to bus Bus0that its load。