proactive architecture and application for the management of electrical networks e. zimeo department...

ProActive Architecture and Application for the Management of Electrical Networks

E. ZimeoDepartment of Engineering - RCOSTUniversity of Sannio, Benevento, Italy

[email protected]

ProActive User Group and ContextSophia Antipolis, Nizza, France

18 October 2004

Introduction 1/4

• On-line power systems security analysis (OPSSA) is one of the most relevant assessments made to assure the optimal control and management of electrical networks

• There are many phenomena (contingencies) that can compromise power systems operation– an unexpected variation in the power system structure – a sudden change of the operational conditions

• OPSSA deals with the assessment of the security and reliability levels of the system under any possible contingency

Introduction 2/4

Three main steps:

1. Screening of the most “credible” contingences

2. Predicting their impact on the entire system operation • the contingencies analysis is performed according to the (n-1)

criterion• for each credible contingency, the simulation of the system

behaviour and the verification of operational limits violations• the system behavior is verified finding the solution of the

system state equations (power flow or load flow equations)

3. Preventive and corrective controlling • identification of proper control actions able to reduce the risk

of system malfunctioning

Introduction 3/4

• Focus: on-line prediction (step 2)– computation times should be less than few minutes for

information to be useful

• Unfortunately OPSSA is computing and data intensive– structure of modern power systems– computational complexity of algorithms– number of contingencies to analyze

• New methodologies to reduce computational times– parallel processing on supercomputers and then on cluster

and network of workstations (to reduce costs) has been employed (i.e. PVM)

Introduction 4/4

• Our proposal:– A java-based distributed architecture instead of PVM

• Advantages:– Programming is easier– Portability is assured on each architecture implementing a JVM – Better integration with Web technologies– Object-Oriented programming allows for adopting architectural

and design patterns

• Disadvantages:– Efficiency is reduced due to Java communication overheads– Execution time is higher due to interpretation

The overall distributed architecture

Inte

rnet

- H

TT

P in

tera

ctio

ns Internet - T CP and HT T P interactions

ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS

Com putationalEngine

Presentation tier Middle tier Storage tier

. . .. . .

W eb Server Application Se rv e r

Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........

scalability accessibility manageability

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........

A network of field power meters (FEMs)

- distributed in the most critical sections of the electrical grid

- to provide input field data for power flow equations, such as active, reactive and apparent energy

- based on ION 7330-7600TM units

- equipped with an on-board web server for their full remote control

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........

A network of distributed Intelligent Electronic Devices (IEDs)

- distributed in the most critical sections of the electrical grid

- to monitor continuously the thermal state of critical sections of the electrical grid

- to analyse system behavior

- to verify limits violations (such as load capability)

- remote controlled by the TCP/IP protocol

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........

Clients

- used by the power systems operators

- to access OPSSA information for system monitoring and management

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........

Web components

- handle the presentation at the server-side

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........

Business Logic Components

- access data stored in a DBMS

- continuously monitor the power system, coordinating the execution of security analysis

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........

A DataBase Management System (DBMS)

- used to permanently store output data

- remote accessed

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........

Computational Engine

- a parallel and distributed processing system

- to execute power flow equations in a short time

Computational engine: algorithm

• Sequential algorithm • Concurrent algorithm

i < = N e

N O

YES

Any c ons train tvio lated ?

Contingenc ylis t em pty ?

YES

N O

N O

YES

Ac quire f ielddata

Com pute thes tate es tim ation

S elec t ac ontingenc y

Com pute thepow er f low

s olution

Chec k the voltage andpow er c ons train ts

Chec k theequipm entc ons train ts

i = i + 1

G enerate analarm

Any c ons train tv io lated ?

YES

N O

Any c ons train tv io lated ?

YES

N O

. . . .

. . . . . .

.

.

.

Ac quire f ielddata

S ubdivide theJ ob

S elec t thec ontingenc y 1


s olu tion

Chec k thec ons train ts

S elec t thec ontingenc y N


s olu tion

Chec k thec ons train ts

Chec k thec ons train ts of the

equipm ent 1 inc ontingenc y 1

Chec k thec ons train ts of theequipm ent N e in

c ontingenc y 1

Chec k thec ons train ts of the

equipm ent 1 inc ontingenc y N

Chec k thec ons train ts of theequipm ent N e inc ontingenc y N

G enerate analarm

G enerate analarm

Com pute s tatees tim ation

Adopting a concurrent algorithm based on the domain decomposition

Computational Engine: design goals

• The computational engine is designed as a framework, whose main goals are:1. high performance

– The framework is to be able to compute the analysis of each contingency in parallel with the others

2. flexibility and scalability– The framework is to be able to exploit all the available

resources to minimize the computation time

3. hierarchy– The framework is to be able to exploit clusters of

workstations or networks of workstations handled by front-ends

• Architectural design solution: hierarchical master/slave model

The hierachical m/s model 1/3

master

sub-master slave slavesub-master

slave

slave

slave slave

slave

slave

input data s tructure

– hierarchical master/slave model

• object-level parallelism

• master and slaves are transparently

created

The hierachical m/s model 2/3

• Three implementation problems:– Task allocation in order to minimize the execution

time• Time minimization algorithm

– Object-oriented design to support a transparent hierarchical master/slave model

• Hierarchical master/slave pattern

– Object-oriented implementation to support a distributed and parallel implementation of the hierarchical master/slave pattern

• RMI based implementation• ProActive based implementation

Task allocation: time minimization

• This phase is important and complex due to the heterogeneity of hardware architectures– to minimize load imbalance, the workload should be distributed

dynamically and adaptively to the changing conditions of resources.

• We consider only static information– Defined N as the number of independent sub-tasks in which the

overall task is divided;

– n as the number of available resources at a certain level;

– and ti as the elapsed time that the resource i needs to complete a

single sub-task;

– ni the number of sub-tasks assigned to the resource i

– the problem to minimize the execution time using assigned resources can be formulated as follows:

Nn

tntntnn

ii

nn

1

2211 ...

The hierachical m/s pattern• M/S pattern:

– splitWork() is used to create slave objects, to allocate them onto the available resources, and to partition a task into sub-tasks.

– callSlaves() is used to call the method service() on all the slave objects, which perform the same computation with different inputs.

– combineResults() is used to combine the partial results in order to produce the final result.

• Hierarchical M/S pattern:– An additional class (Server) is

introduced– service()is used to hide the

difference between master and slave objects

M as te r

+ s ervic e(O bjec t) :O bjec t+ s plitW ork()+ c allS laves ()+ c om bineRes ults ()

S erve r

+serv ice(Object):Object

Slave

+ s ervic e(O bjec t) :O bjec t

C lie nt

+ us e_s erv ic e_AP I()

HM/S pattern implementation

• To support distributed and parallel implementation of HM/S pattern– service() has to be asynchronously invoked– Each service() method has to be executed by a different

computational resources

• Solutions: an object-oriented middleware based on remote method invocations– RMI – the well known middleware provided by SUN– ProActive - Java library for seamless sequential, concurrent

and distributed programming

RMI implementation of HM/S pattern

• Each Server – is defined as a remote object – is allocated onto a different computational resource– its method service() has to be asynchronously and remotely

invoked by the client– the asynchronous invocation is implemented by invoking service() within a dedicated thread of control

:M as ter

:T h re a d :M as terRM I

RM I

RM I

:Applic ationc om ponent

C o m pu ta t io n a l En g in e

s e rv ic e ()

s e rv ic e ()

s e rv ic e ()

s e rv ic e () :T h re a d

:T h re a d

< < c re a t e > >

< < c re a t e > >

< < c re a t e > >

. . . . .

H os t H os t

H os t

:S laveRM I

RM I

RM I

H os t

H os t

H os t

:J M atLink

:S lave :JM a th Lin k


:S laveRM I

RM I

H os t

H os t

:JM a th Lin k


s e rv ic e ()

:T h r e a d

:T h r e a d

:M as ter

:T h r e a d

:T h r e a d

H os t

:M as ter :T h r e a d

S e rve rs

R D B M S

D e vic e sfor m onitor inga n e le c tr ic a lgr id

ProActive implementation of HM/S p.

• Each Server– is defined as an active object (that can be dynamically created)– is allocated on a different computational resource (dynamically)– its method service() has to be asynchronously and remotely

invoked by the client. – the asynchronous invocation is directly supported by ProActive

:M as ter

:M a s t e r



s e rv ic e ()

. . . . .

H os t

H os t

H os t

:S lave

H os t

H os t

:S lave

:M a s t e r

H os t

ì:M a s t e r

:S lave

H os t

H os t

:S lave

:S lave

H os t

H os t

:S lave

s e rv ic e ()

S e rv e rs

R D B M S

D e vic e form onitor inga n e le c tr ic a lgr id

:J M athLink

:J M athLink

:J M athLink

:J M athLink

:J M athLink

:J M athLink

Software platform evaluation on a testbed 1/2

• RMI - ProActive• Tomcat 4.1• Java SDK 1.4.1• MATLAB 6.5

• Standard IEEE 118-nodes test network

• electrical network description is local to each computational resource

• The experiments refer to 186 contingencies

• A COW with P1 proc.• P1 = Pentium II 350 MHz

• A NOW with P2 proc.• P2 = Pentium IV 2 GHz

In ternet

Clien t

S erv let Container

P 1

P 1

P 1

P 1

P 1

P 1

P 1

P 1

P 2

P 2

P 2

P 2

M as ter1 M as ter2

M as ter

l evel 0

l evel 1

l evel 2

P 1 P 2

2421

1821

35...

6...

Pnnn

Pnnn

Software platform evaluation on a testbed 2/2

• The framework shows good results• RMI vs ProActive:

– Exibhit almost the same results (ProActive is based on RMI)– ProActive simplifies parallel and distributed programming– ProActive enables group communication (not used in this work)

Execution times Speed up

Open problems

• Problem 1: – The method splitWorks has to know dynamically the number of

computers to use, the computational power of each computer

• Solution 1: – A broker based architecture

• Problem 2: – Too much code for invoking the same method on each slave

• Solution 2: – Adopting groups to simplify the code in the master/slave model

• Problem 3: – Too much data communication

• Solution 3: – Implementation of group communication on multicast protocols

Broker based architecture: a step further toward flexibility and efficiency

A Grid-based Computational Engine

• At the University of Sannio we have developed a broker-based middleware – HiMM (Hierarchical Metacomputer Middleware)

• a middleware that provides an object-based programming model

HiMM collective layer

:BusinessCom ponent

:Inform ationSystem

HiM

:Broker

- Code- Input- Application description- QoS requirem ents

Resource selectionT ask m apping

Com putational Engine

results

Resourcediscovery

User

Com putationalresources

• Economy-driven resource broker

- ease application submission

- simplifying the application

deployment

- functionalities of resource

management

• Application description–JDF – Job Description Format

– Application QoS requirements–URDF – User Requirements Description Format–the deadline and the budget–time optimisation algorithm or cost optimisation algorithm

OPSSA deployment and evaluation 1/3

• The work load is distributed among the available resources according to their performance and price

20

40

60

80

R0 R1 R0 R1 R0 R1 R0 R1 R0 R1 R0 R1

N. o

f co

ntin

ge

nci

es

Resources

N. of Contingencies assigned to each Resource (Deadline = 900 sec)

80 (B=800$)

92 (B=1000$) 98 (B=1200$) 105 (B=140$) 112 (B=1600$) 118 (B=1800$)


• The resources were temporarily dedicated to OPSSA computations• The budget is limited

100

200

300

400

500

600

700

800

900

30 40 50 60 70 80 90 100 110 120

Exe

cutio

n tim

e (s

ec)

Total n. of sub-tasks

Execution Time (Deadline=900 sec. Budget=1800$)

Estimated TimeMeasured Time


100

200

300

400

500

600

700

800

900

40 60 80 100 120 140 160 186

Exe

cutio

n tim

e (s

ec)

Total n. of sub-tasks

Execution Time (Deadline=900 sec. Budget=(illimited)1000000$)

Estimated TimeMeasured Time

• The resources were temporarily dedicated to OPSSA computations• The budget is unlimited

Which programming paradigm for OPSSA on HiMM ?

OPSSA on HiMM uses a specific implementation of ProActive

Integration HiMM / ProActive 1/2

• The implementation of P/H has been made easy thanks to the particular organization of both software systems– ProActive is heavily based on the Adapter Pattern

– HiMM is implemented following the Component Framework approach.

N E on node x

P ro A ct iv eM es s ag e

C o n s u m erL e v e l Se n d e r

E P s

O b je c t A

B P r o x y

N E on node y

P ro A ct iv eM es s ag e

C o n s u m erL e v e l Se n d e r

E P s

O b je c t B

A B o d y

L N

R e s u lt

Exec ution Environm ent

L N

N M

a c c e s s to G r id f e a tu r e s

H iM M T r a n s p o r t l a y e r( T C P , R U D P , F M )

H B A

H B A idH B A id

F u tu r e P o o l

H B AH B o d y

G lo b al U ID fo r H iM M G lo b al O b ject s

P ro A ct iv e co m p o n en t o f an act iv e o b ject

H iM M A d ap ters

H B A = H B o d y A d ap terH B A id = H B o d y A d ap ter s tu b co n tain s o n ly th e G U ID o f th e rem o te ad ap ter

H B o d y = H al fB o d y

A B o d y = A ct iv eB o d yS tu b g en erated b y B cel

R eferen ceIn v o cat io n o r d ata t ran s fer

H N A

H N A = H N o d eA d ap ter

Integration HiMM / ProActive 2/2

public class MatrixMultiply extends ProActiveExecutionEnvironment { private NodeMgr nodeMgr; private volatile boolean stop = false; public void init (NodeMgr nm) { super.init(nm); nodeMgr = nm; NodeFactory.setFactory(“himm”, new HNodeFactory()); } public void start() { stop = false; if(nodeMgr.isRoot()) { HMatrix[] mDxActiveGroup=null; int dim=0; System.out.println("Insert matrix size:"); <read dim>; Matrix mDx = new Matrix(dim); LevelMgr lm = nodeMgr.downLevelMgr(); int size = lm.size()-1; Object[] po = new Object[]{mDx.getTab()}; mDxActiveGroup = new Matrix[size]; for(int i =0; i<size; i++)

mDxActiveGroup[i] = (HMatrix) ProActive.newActive(HMatrix.class.getName(), po, NodeFactory.getNode(“himm://”+(i+1)), null, HMetaObjectFactory.newInstance()); Matrix mSx = new Matrix(dim); while (!stop) { Matrix[] results = multiply(mSx, mDxActiveGroup); Matrix result = Matrix.rebuild(results, dim); ... } } }…}

public class HMatrix extends Matrix implements InitActive, RunActive, EndActive {

private HMatrix[] subMats; public void initActivity(Body body){ HBodyAdapter hba =(HBodyAdapter) body.getRemoteAdapter(); NodeMgr nodeMgr = hba.getNodeMgr(); if(nodeMgr.isCoordinator()) { LevelMgr lm = nodeMgr.downLevelMgr(); int size = lm.size()-1; subMats = new Matrix[size]; Object[] po = {tab}; for(int i =0; i<size; i++) { subMats[i] = (HMatrix)ProActive.newActive(HMatrix.class.getName(),

po, NodeFactory.getNode(“himm://”+(i+1)),null, HMetaObjectFactory.newInstance()); } } } public void runActivity(Body body) { Service service = new Service(body); while (body.isActive()) { Request r = service.blockingRemoveOldest(); HBodyAdapter hba =(HBodyAdapter) body.getRemoteAdapter(); NodeMgr nodeMgr = hba.getNodeMgr(); if(r.getMethodName().equals("multiply")&& nodeMgr.isCoordinator()){ HiMMRequest rr = (HiMMRequest)r; float[][]mSxtab =(float[][])rr.methodCall.getParameter(0); Matrix mSx = new Matrix(mSxtab); Matrix[] results = new Matrix[subMats.length]; Object[] subSxMats = mSx.createSubMatrixes(subMats.length); for(int i=0; i< subMats.length; i++) results[i] = subMats[i].multiply((float[][])subSxMats[i]); Matrix result = Matrix.rebuild(results, mSxtab.length); Object[] params = new Object[]{result}; Class[] classes = new Class[]{Matrix.class}; try { Method m = HMatrix.class.getMethod("getResult", classes); rr.methodCall = MethodCall.getMethodCall(m, params); } catch (NoSuchMethodException e){ … } service.serve(rr); } else service.serve(r); } }

Performance analisys 1/2

• We have conducted an analysis to compare RMI with HiMM and P/R with P/H • The benchmark is the invocation of a remote method (with one parameter and an empty

body) and the return of an integer value, for a varying size of the parameter• The figure shows that for a small size (1 byte) of the parameter, RMI RTT (0.9 ms) is

smaller than HiMM RTT (1.3 ms), but P/H RTT (7.8 ms) is smaller than P/R RTT (9.2 ms) – Even if the HiMM transport layer is not optimized, P/H behaves better than P/R due to the use of

asynchronous messaging that allows low-level ProActive operations to be overlapped with communication

1

10

100

1000

1 10 100 1000 10000 100000

Th

rou

ghp

ut (

me

tho

d in

voca

tion

s / s

)

Parameter Size

RMI(S-R)/H

P/HP/R

1

10

100

1 10 100 1000 10000 100000

RT

T (

ms)

Parameter Size

RMIS-R/H

P/HP/R

Performance analisys 2/2

• A further analysis has aimed to measure the speedup factor by running a simple application benchmark

• The benchmark is the product of two square matrixes with different sizes of the matrixes.

• The performance obtained with P/H is slightly better than the one obtained with P/R, especially when the size of the matrixes is small

– This is mainly due to the improvement of remote method invocation implemented by HiMM– When the size of the matrixes is large, the execution time is dominated by the time of the matrix

serialization, which is the same in P/H and P/R

0

1

2

3

4

5

100 200 300 400 500 600 700 800 9001000 1200

Spe

edup

Fac

tor

Matrix Size

P/H 2 nodesP/R 2 nodesP/H 4 nodesP/R 4 nodesP/H 6 nodesP/R 6 nodes

0

500

1000

1500

2000

2500

100 200 300 400

Exe

cutio

n ti

me

(m

s)

Matrix Size

S-R/HP/HP/R

On going work

ProActive Groups over Reliable Multicast

• We intend to implement the OPSSA by using ProActive Hierarchical Groups

• Group at different hierarchical levels will be mapped on HiMM macro-nodes

• HiMM will provide reliable multicast to ProActive groups for communication among members

:M as ter

:M a s t e r



s e rv ic e ()

. . . . .

H os t

H os t

H os t

:S lave

H os t

H os t

:S lave

:M a s t e r

H os t

ì:M a s t e r

:S lave

H os t

H os t

:S lave

:S lave

H os t

H os t

:S lave

s e rv ic e ()

S e rv e rs

R D B M S

D e vic e form onitor inga n e le c tr ic a lgr id

:J M athLink

:J M athLink

:J M athLink

:J M athLink

:J M athLink

:J M athLink

Group

Group

Group

Group

Web services for process coordination in OPSSA

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........


WSRF + BPEL Engine

Generic Middleware for Sensor Networks

Inte

rnet

- H

TT

P in

tera

ctio


ElectricalGrid

FEM

FEM

FEM

FEM

IEDIED

IED

IED

IED

IED

DBMS



. . .. . .


Serv let

JSP

BusinessLogic

BusinessLogic

Web Browser

Applet

HT M L client

Web Browser

Applet

HT M L client

..........


WSRF + BPEL Engine

Sensor Networks MW

HiMM connectivity layer

• HiMM manages resources according to a hierarchical topology (Hierarchical Metacomputers) in order to– meet the constraints of the Internet

organization

– exploit the heterogeneity of networks

– improve scalability • Clusters of computers hidden from the

Internet or intra-connected by fast networks are seen as macro-nodes– A macro-node is a high-level concept that

allows clusters to be transparently used as a single powerful machine

– A macro-node can in turn contain other macro-nodes

• A metacomputer can be organized according to a recursive tree topology

• The Coordinator interfaces the macro-node with the metacomputer network

N et-IPN et-IP

Root

W SW S

M ac ro-nodeM ac ro-node

M ac ro-node

C C

C

N et-IP

N et-F P

C lus te r

D o m a inX M L c f g f i l e

C o nso le

C

D o m a inX M L c f g f i l e

C lu s t e rX M L c f g f i l e

U s e rX M L c f g f i l e

N ode

H M H M

C re a t e a n o d e

N o d e c re a t io nc o m m a n d

HiMM resource layer

• A macro-node is characterized by two main components:– The Host Manager (HM)– The Resource Manager (RM)

• The HM runs on each node wanting to donate CPU cycles

• The RM is use to publish the available computing power at each level

• A macro-node manages another important component: – the Distributed Class Storage

System (DCSS)– This component allows a HiM to

run applications even if application code is not present on nodes

N et-IPN et- IP

Root

W SW S

M ac ro-node M ac ro-node

M ac ro-node

C C

C

N et-IP

N et-F P

R M

R M R M

R M

C lus te r

C o nso le

s ubs c r ibe

publis h

p 1.3 .2 .1 p 1.3 .2 .3

p 1.3 .2 .2

p 1.3 .2 = p 1.3 .2 .1+ p 1.3 .2 .2+ p 1.3 .2 .3p1.3 .1

p 1.3= p 2.1+ p 2.2p 1.1p 1.2

p 1.4

p 1.1 = p 1.1 .1+ p 1.1 .2+ p 1.1 .3p 1.2p 1.3 = p 1.3 .1+ (p 1.3 .2 .1+ p 1.3 .2 .2+ p 1.3 .2 .3 )p 1.4

H M H MH MH M

H M H M H M

p : c o m p u t in g p o w e r o f a h o s to r a m a c ro -n o d e

H M H M

C

p 1.1 .1 p 1.1 .2 p 1.1 .3

HiMM node architecture

• HiMM implements its services in several software components whose interfaces are designed according to a Component Framework approach

• Both nodes and coordinators are processes in which a set of software components are loaded either at start-up or at run-time

• The main components are: – the Node Manager (NM)

• guarantees macro-node consistency• provides users with services for

writing distributed applications• takes charge of some system tasks,

such as the creation of new nodes at run-time

– the Node Engine (NE)• The Message Consumer (MC)• The Execution Environment (EE)• The Level Sender (LS)

N ode E ngine N ode M a na ge r(Le v e l M a n a g e r)

E x e c u t io nE n v i r o n m e n t

M e s s a g eC o n s u m e rL e v e l Se n d e r

E P s

L o a da c o m p o n e n t

I n s t a l la c o m p o n e n t

a C o m p o n e n t

N o d e M a n a g er (N M ) : m an ag es a n o d e in o rd er to g u aran tee th e H iM co n s i s ten cyN o d e E n g i n e (N E ) : d efin es th e b eh av io r o f a n o d eL ev el S en d er (L S ) : s en d s a m es s ag e (an o b ject ) to a n o d e o r a g ro u p o f n o d esM es s a g e C o n s u m er (M C ) : receiv es m es s ag es fro m th e n etw o rkE x ecu ti o n E n v i ro n m en t (E E ) : s to res a co m p o n en t o f a d i s t rib u ted ap p l icat io n

HiMM communication API

• HiMM allows nodes to communicate using the component LevelSender

• A LevelSender can be customized even if a default one is always available – This component provides users with simple communication

mechanisms based on the asynchronous sending of objects

class DefaultLevelSender impements LevelSender {

public void send(Object m, int node) { … }

public void broadcast(Object m) { … }

public void deepBroadcast (Object m) { … }

}

HiMM: interaction among components

HO S T

HO S THM

HiM N ode

Configurator

N o d e M g r

G UI

EE

LS M C

S end a command

C o n s o le

N o d e En g in e

class Application implements ExecutionEnvironment { void init(NodeMgr nm) throws … { nodeMgr = nm; } void start() { … nodeMgr.downLevelSender().send(msg, node); nodeMgr.downLevelMgr().addNode(…); Object o = nodeMgr.downLevelMsgConsumer().receive(); … }}

proactive architecture and application for the management of electrical networks e. zimeo department...

Documents

system behaviour

power flow equations

power systems operators

entire system operation

opssa information

electrical gridto

usefulunfortunately

contingencies analysis