Application of multi-agent techniques to the optimal...

_

Application of multi-agent techniques to the optimal configuration of electric

distribution systems including dispersed generation

MASTER’S THESIS

to obtain the degree

“Ingénieur EPFL en systèmes de communications”

Sébastien Rumley

under the supervision of

Prof. H. Rudnick Prof. A. Germond

Santiago de Chile, PUC Lausanne, EPFL

2005

EIDGENÖSSISCHE TECHNISCHE HOCHSCHULE LAUSANNE POLITECNICO FEDERALE DI LOSANNA SWISS FEDERAL INSTITUTE OF TECHNOLOGY LAUSANNE

LABORATOIRE DE RESEAUX ELECTRIQUES ELECTRIC POWER SYSTEMS LABORATORY

Diploma Project Candidate : Sébastien Rumley Section of Communication systems Application of multi-agent techniques to the optimal configuration of electric

distribution systems including dispersed generation

Introduction : Electrical distribution networks are operated according to a radial configuration. However their basic structure generally comprises loops. Therefore they can be configurated according to several possible operating schemes in order to supply the loads required by the consumers. Heuristic methods were developed successfully for solving this combinatory optimisation problem, (Merlin and Back, 1975, Liu 88, Aoki et al. 88, Cherkaoui 93, Rudnick 97). Presently, new methods are available, and the optimal configuration problem needs to be extended, including the integration of distributed generation sources in the distribution systems, and in the context of liberalised markets.

Objective : The objective of the diploma project is to investigate the application of multi-agent techniques to the optimal configuration and reconfiguration of electric distribution systems, including dispersed generation. The evaluation of the method will include a comparison between the results obtained with multi-agent and known heuristic methods.

Working plan : 1- Study and understand the problem of distribution system configuration and reconfiguration, and the application of heuristic methods to this problem. 2- Propose a method based on the application of multi-agent systems to solve the distribution system optimal reconfiguration problem. Evaluate the possibility of defining as objective function the minimal number of reswitching, in addition to the usual loss or line overload minimization. In this first part of the project, the distributed generation will not be considered.

3- Generate synthetic distribution networks for testing the algorithms. Evaluate the performances and convergence properties. 4- Compare the performances of the multi-agent methods with those of heuristic methods in the case of practical examples analysed in the PhD thesis of Rachid Cherkaoui, who will provide the numerical data. 5- Propose an approach for including the distributed generation in the model. 6- Conclude and prepare a final report in English, following the attached instructions. Supervision : The project will be performed at the Power Systems Laboratory of Pontificia Universidad Católica de Chile, and supervised by Prof. Hugh Rudnick. The student will inform regularly Prof. Germond of the progress of the work. Deadline : The project will begin on November 15. The student will hand over two copies of the final report to Professor Rudnick on May 14 and a copy by e-mail in pdf format to Prof. Germond.

Lausanne, October 14, 2004

Prof. Alain Germond Contacts at EPFL : Elvira Kaegi-Kolisnychenko ([email protected]) Rachid Cherkaoui ([email protected]) References : C. C. Liu et al. “An expert system operational aid for restoration and loss reduction of distribution systems”, IEEE Transactions on Power systems, Vol. 3, No2, May 1988, pp 619-626 R. Cherkaoui, "Méthodes heuristiques pour la recherche de configurations optimales d'un réseau électrique de distribution", thèse EPFL 1058, Lausanne, 1992. R. Cherkaoui, A. Bart, A. Germond, "Optimal Configuration of Electrical Distribution Networks Using Heuristics Methods", 11 th Power Systems Computation Conference (PSCC), Avignon (France), Aug 30-Sep 3, 1993. H. Rudnick, I. Harnisch, R. Sanhueza, “Reconfiguration of Electric Distribution Systems”, Revista Faculdad de Ingeniera, U.T.A. (Chile), Vol 4, 1997 T.Nagata, H.Sasaki “A Multi-agent Approach to Power System Restoration”, IEEE Transactions on Power Systems, Vol. 17, NO 2, May 2002

"La lutte elle-même vers les sommets suffit à remplir un cœur d’homme. Il faut imaginer Sisyphe heureux."

Albert Camus, Le Mythe de Sisyphe

3

0. Summary

• 1. Introduction and motivation o 1.1 Authors foreword

§ 1.1.1 Article in Science et Vie § 1.1.2 Family and education background § 1.1.3 From the computing and communication world to power systems

o 1.2 Present problems in the field of energy § 1.2.1 Energy as a response to many questions § 1.2.2 Global warming and the Kyoto Protocol § 1.2.3 Consequences for the electrical sector § 1.2.4 Distributed generation § 1.2.5 Market liberalisation

o 1.3 Focus on the distribution networks § 1.3.1 How the previous cited problem affects the distributions networks § 1.3.2 Abstract description of the problem

o 1.4 The agents and the last optimisation techniques § 1.4.1 Classical optimisation methods § 1.4.2 Biological inspiration § 1.4.3 The distributed fashion

o 1.5 Synthesis

• 2. Description of the problem and of the work environment o 2.1 Thesis specifications

§ 2.1.1 Main idea § 2.1.2 Official information and given specifications

o 2.2 Classical description of the configuration/reconfiguration problem § 2.2.1 Combinatorial optimisation problem § 2.2.2 Physical constraints § 2.2.3 Optimisation criteria § 2.2.4 NP-hardness property § 2.2.5 Load-flow computation § 2.2.6 Actual methods and literature survey

o 2.3 The distributed paradigm § 2.3.1 Divide ut imperes § 2.3.2 Internet and the distributed revolution § 2.3.3 Spanning-tree organisation in Ethernet devices § 2.3.4 Distributed algorithms and multi-agent system presentation § 2.3.5 Literature survey about agents and distributed algorithms

o 2.4 Traditionnal software used in this case § 2.4.1 Matlab, usual engineering application § 2.4.2 Other traditional languages used for simulations

o 2.5 Java as universal language § 2.5.1 Quick description of Java § 2.5.2 Main advantages of Java § 2.5.3 Java performance § 2.5.4 JCreator and JDB § 2.5.5 Javadoc

4

• 3. Realisation o 3.1 Planning - History o 3.2 Package organisation and functions isolation o 3.3 Network model’s subproject

§ 3.3.1 Object Oriented § 3.3.2 The thesis.network.properties package and the Element class § 3.3.3 Serialisation § 3.3.4 GUI interaction § 3.3.5 Agents interaction

o 3.4 Graphic User Interface’s package § 3.4.1 A single sketch is worth a thousand words § 3.4.2 Classical file functions § 3.4.3 Properties editing § 3.4.4 Logging frame

o 3.5 Multi-agent framework § 3.5.1 Communication stack § 3.5.2 Used messages, protocol § 3.5.3 Thread manager § 3.5.4 The logger

o 3.6 First design method § 3.6.1 Leader election and clustering § 3.6.2 Ant inspired “travelling salesman problem” algorithm § 3.6.3 Implementation

o 3.7 Second design option § 3.7.1 Learning from mistakes in first design § 3.7.2 Feeders as masters § 3.7.3 Main concept: charge transfer § 3.7.4 The procedures § 3.7.5 Problems with asynchronous messaging § 3.7.6 Implementation

o 3.8 Others § 3.8.1 Testing project and statistics watcher § 3.8.2 “The simplest load flow calculator” § 3.8.3 Development environment

• 4. Results o 4.1 Network model and the associated interfaces o 4.2 First method

§ 4.2.1 Three parts of the algorithm § 4.2.2 Time measurements and performance § 4.2.3 Optimisation results

o 4.3 Javadoc documentation o 4.4 Second method

§ 4.4.1 Full framework and algorithm separation § 4.4.2 Results through examples § 4.4.3 Comments

o 4.5 Limitations, known bugs or failures § 4.5.1 In the GUI or in the network model § 4.5.2 In the agent framework § 4.5.3 In the algorithms themselves § 4.5.4 In the tools

o 4.6 Little problems, big time...

5

• 5. Conclusion o 5.1 General comments on the development of the project

§ 5.1.1 The good choice of Java § 5.1.2 To reflect on the first method § 5.1.3 Horizons opened by the ‘transfer-method’ § 5.1.4 The assumptions list...

o 5.2 Not yet evoked themes § 5.2.1 Distributed generation § 5.2.2 Financial aspect

o 5.3 Future improvements § 5.3.1 GUI related § 5.3.2 Framework related § 5.3.3 Algorithms related

o 5.4 Author's comment § 5.4.1 The Pandora’s Box... § 5.4.2 What I learned § 5.4.3 Acknowledgements

o 5.5 Final conclusion

• 6. Annexes o 6.1 References o 6.2 More information

1. Introduction and motivation

1.1 Authors foreword

1.1.1 Article in Science et Vie

In 2002, I came across a special edition of the popular magazine Science et Vie (Energy 2001, published in 2001). I read it from the cover to cover. All the current problems facing the energy industry in the twenty first century were dissected: nuclear power, electricity networks and grids, hydro-electricity. At the time, I was in my third year of communication systems studies, my head full of TCP algorithms, Fourrier transforms and sampling theorems. Reading the article, I came to realise these problems were real, not anchored in theory. Power is the core of our society. No power means no computers, and no TCP. While I maintained great interest and passion in my studies, my surroundings constantly reminded that computer science and communication subjects were difficult to explain to other people, in particular to people that did not have a technical background. In comparison, energy and electrical problems are pretty obvious to most people, and it gave me more satisfaction explaining to people that I research energy problems than explaining the latest progress in multicast IP networks. However, energy problems were not really my domain.

1.1.2 Family and education background

‘Common’ engineering not belonging to my domain, is not completely true. First of all, with a civil engineer for a father, specialising in dam construction, electrical generation problems were not completely unknown to me. Furthermore, it is difficult in Switzerland to know nothing about hydraulic energy. Hence, when I was nine years old I had to present a chosen subject, and I chose Energy. It was not easy to do a complete summary of such a topic, but with the help of my father I managed to make a good introduction to this fascinating subject. From that moment on, energy problems have always interested me.

1.1.3 From the computing and communication world to power systems

Although I had, after reading the aforementioned magazine, a renewed interest to do something in relation with energy problems, I spent a few more years studying classical communication systems, with the intention of becoming a computer science engineer. When looking at the list of lectures offered in electrical engineering, one description caught my eye at once: the course was called Electric Energy Systems, and was an overview of several classical problems related to energy transportation networks, and seemed to be understandable to me.

Chapter 1 – Introduction and motivation 8

I took this lecture. It was a bit beyond me at the beginning since my knowledge about, for example, direct, inverse or homopolar voltages was limited. The lecture, however, diverted relatively quickly from electromagnetic problems to present subjects more related to optimisation: production planning, network management, etc. I found I was more interested in those subjects and I felt a sensation of dejà vu. The optimisation techniques that were presented here had many things in common with the ones I had seen in my computer networks lectures. The electrical networks seemed suddenly very similar to communication networks, and I saw here the first connection between my world and the world of power. I then remembered my former aspirations to doing something in my life and career that will help people to have access to energy, and decided to go and talk to the lecturer, the Professor Germond. We had a very interesting talk, at the end of which I decided to write my master thesis about electrical networks.

Now, a year later, I am writing the final report for that same master’s thesis. I learned that the two worlds are not so far apart, and that if at the beginning the reaction of some friends was “What are you doing? Why are you changing the direction of your studies?”, now I can say that both domains have many things in common, and furthermore, that engineers or researchers from the two sides should continuously keep abreast of each other’s work. I hope that the reader will arrive at the same conclusion, and agree that computer systems, electrical and mathematical engineers are not so different: we are all engineers, and similar problems are awaiting us all.

1.2 Present problems in the field of energy

1.2.1 Energy as a response to many questions

In August 2003, the city of New York and a big part of the east cost of the USA suffered a black-out that lasted several days and affected 50 million people [1.1]. This black-out meant no telephone connection, no subway, no light, no elevators, but also no water, because the water feeding network was operated with pumps. No electricity meant a city on pause.

In September 2000, to protest against the high price of fuel, French and English truckers and fishers launched an operation to coerce their governments into making concessions. The idea was simple: to block the access of fuel tanks and refineries with trucks. Quickly many fuel stations were empty, many people were unable to fill their tank and consequently part of the economy was frozen, leading to important money losses, and an economy under pressure [1.2].

These two examples show how contemporary western societies are addicted to energy. A city of more than one million inhabitants cannot survive more than two weeks without electrical supply, and whole economies can be frozen by something as trivial as fuel shortages.

So, why did the United States decide to enter into conflict in Afghanistan and in Iraq? Though the debate over the rights and wrongs of these wars is inappropriate here, it is probably sufficient (and not too controversial) to state: for the energy. Why did M. Vladimir Putin take control of the Russian Petroleum company Yukos? Once again, energy, or rather the control of it, appears to have been the determining factor. Control of energy has one of the biggest influences on decision-making at the international level. And the price of oils barrel (which currently exceeds the fifty US dollar mark for the first time of history) is among the main economical indicators. Energy is at the root of many geopolitical debates and problems. Modern society is built on the assumption that energy is always available, right here, right now. It is hard to imagine a world where hitting a switch does not flood a room with light, where fuel stations are empty, where radiators are cold.

Chapter 1 – Introduction and motivation

9

Nevertheless, energy production and supply is not as obvious as many people think, and it is much more complex than electric plugs, or gas stations. The process of energy distribution is a complicated system, subject to international and economic influences, and unstable. At the present time energy is, more or less, universally available because the organisations that control its distribution have more of an interest in making it available than in making it a scarce commodity. These organisations are, however, part of a sensitive system without an overseeing control, and small dysfunctions have the potential to turn into big problems with global repercussions.

Beside classic domestic political issues like health, education or police activity, energy supply is among the more important preoccupations of modern countries. Every government knows very well the importance of energy in modern society, and virtually all are preparing their strategies for the coming years. After a dream of one hundred and fifty years made of intense energy consumption, at the beginning of the third millennium the world has woken up with a hangover. The alarm has been sounded by many scientific or economist: global warming, which has been proved to be caused by carbonic gas emissions; falling levels of fossil occidental energy reserves, not as inexhaustible as thought; growth of energy consumption by developing superpowers such as China and India. Currently, the price of oil is climbing steadily, and the worlds daily oil production capacity is slowly being overtaken by daily consumption.

Issues related to energy distribution are more the topic now than ever, and the world is looking for solutions for the growing pressure on power supplies. This subject is a multi-faceted one, and any proposals must take into account all areas: production or recycling of energy, transportation of energy, and the consumption of energy.

1.2.2 Global warming and the Kyoto Protocol

In December 1997, 180 countries signed a declaration to fight global warming. 38 countries promised to reduce their carbonic gas emissions by at least 5% compared to the levels of 1990. After many diplomatic moves, assessments, changes of opinion, and discussion, this common declaration, the Kyoto Protocol, came into effect and many occidental countries now have to reduce their carbonic gas production as a result of the initiatives and benchmarks contained in this accord.

Carbonic gas emissions are natural, not just a result of human activity. Each member of the animal kingdom transforms nutrients (basically glucose) and oxygen to carbon dioxide and water and vital energy. On the other side, organic organisms (plants), with the help of the sun through photosynthesis, capture some of the carbon dioxide present in the atmosphere and turn it into oxygen and nutrients (glucose) once again. This well known biological process is named the carbonic cycle. However, animal (and principally human) activity is actually producing much more carbon dioxide than the worlds organic organisms can process.

500 millions years ago, great geological disruptions caused a large amount of carbon, under the form of dead vegetal and animal organisms, to be buried. From this era until now, a long transformation process turned this carbon into what is called fossil energy: natural gas, oil, and coal. This forgotten underground treasure was suddenly discovered by Man two centuries ago at the beginning of the so-called industrial revolution, and has been actively used and burned since then.

This large amount of forgotten carbon tried to reintegrate the active carbonic cycle, however due to the own inertia of this cycle, this reintegration is a long process. Human, with little consideration for its value and the time that had been taken to create it, failed also to take into consideration the length of this reintegration process. From this evidence results that a part of carbonic gas which resulted of the combustion of this fossil energy went into the atmosphere, and provoked a greenhouse effect, leading to a period of global warming. It is widely accepted that the global warming problems are principally due to the use of fossil energy, and the Kyoto protocol’s aim is to control the future the production of carbonic gas, which implies control of the combustion of fossil energy.


Fossil energy, in many countries, is principally used in transportation and heating. In transportation, the carbonic gas reduction effort concerns the efficiency of the engines of cars, buses and trucks, the use of smaller engines or vehicles or even more, the reduction of the travelled distances. In heating, most of the time, isolation is the best way to reduce energy consumption. In these countries, the reduction of fossil energy consumption will be possible without recourse to the electricity industry, except in two situations:

• Electrical energy is more present in railways and general public transport than in private transportation. Therefore, by creating initiatives for people to use public transport more often, the share of electrical energy in the total energy usage of the country will increase.

• Some fuel or gas based central heating systems may be replaced by electrical heating systems.

Hydro/Wind-electric 2.9%

Nuclear power 32.9%

Coal 23.7%

Lignite 28.1%

Other burning materials 1.7%

Fuel oil 1.3%

Gas 9.3%

Total combustible 64.2%

Figure 1.1: Repartition by type of the production of electricity in Germany, 2003 [1.3]

However, in many countries the production of electrical energy is mainly based on fossil energy. In Germany for example, in 2003, about 65% of the electricity was made by burning fossil combustibles (fig. 1.1). In the United States, the rate reached 70% [1.4] (fig 1.2). The part of carbonic gas emissions due to electricity production is directly related to these rates. It is important to note also that in the occidental and industrialised countries, electric energy represents between 10 and 20% of the total energy consumption. Consequently, a country anxious to reduce its carbonic gas emissions, in most cases, should also target the electricity generation sector. Moreover, it should be relatively easy for a country to have a direct effect on this sector, since it is often state regulated, or in certain cases still a state-owned sector.

Figure 1.2: Production and use of electricity in the United States (illustration coming from [1.4]), in 2003


11

1.2.3 Consequences for the electrical sector

The question then becomes how to reduce the carbonic gas emissions created during electricity generation processes, or how to supply the increasing electrical power demand without emitting more carbonic gas. The problem may be taken from three different angles which correspond to the three elements of the electrical market: production, transport, consumption.

Consume cleverly, rationalise

By reducing the total electrical consumption (or at least the electrical consumption per capita), carbonic gas emissions will obviously also be reduced. One can refer to the various publications and consciousness raising campaigns to discover different ways to reduce consumption at home (about 25% of total electricity consumption). Industry (50% of total electricity consumption), by rethinking some industrial processes, could also reduce electricity consumption. Finally the service sector (about 15% of total electricity consumption), by introducing power saving plans, could also contribute to the global objective of saving electricity.

Optimise transportation

Investments in electric transport and distribution networks may be made in order to optimize the transportation of electrical energy. Electrical losses due to transportation and distribution, say the difference between the upstream injected power and the energy consumed and billed is estimated, in the case of the U.S.A, to 9% [1.4].

A big part of this loss is unavoidable: there is no way to ideally transport the electrical power from the dam to the consumer. However in several cases, it would be valuable to change old fashioned transmission lines or transformation systems to technologically better ones. Furthermore, by trying to produce the electricity locally to where the demand is, and by efficiently organising the networks, many losses could be avoided. Of course these have a cost, in terms of money and investments. It is unfortunately still in many cases financially more profitable to loose several kilowatts along the way than rebuilding a whole transmission line. Organising a network carries a cost (engineers that develop a method, technicians that apply the changes to the network, etc). Moreover, since the electric market may be partially or completely open, some economic criterions will encourage decisions that go against the goal of loss reduction. However, a state, with punctual intervention, could speed up the investment or limit the energy waste.

Produce differently, use new ideas

If we assume a fixed level of consumption, we must acknowledge that reducing the level of one means of production means increasing the share of the others. Let us split the electricity production in four different domains: fossil, nuclear, hydroelectric, and the others. Assuming fossil energy is the means of production to be reduced, another mean among the others must be increased.

Increasing the share of nuclear production is a difficult political and financial problem. It is political because after the events of Chernobyl nuclear power assaults the collective conscience. Many people do not want to live near a nuclear plant, a nuclear waste processing centre, or storage place, although they admit that nuclear power may be the lesser evil. It is financial because a nuclear plant is costly, extremely costly, and is a very long term investment. A government or state body, are almost the only actors which could bring financial benefits from a nuclear power plant. In the time of electric market liberalisation, this does not sound as appealing.

Hydro electrical production is often presented as the best and cleanest way to produce electricity. It is true only if one forgets the ecological and environmental impact that the creation of a lake (in the case of a mountain dam) or the splitting of a river in two parts (in the case of a river dam) will have. Here


again, public opinion plays a strong role. In Switzerland for example, people are content or even proud of the dams constructed 50 or more years ago, but nobody wants a new one. All the more so since nice mountain locales or even villages would be submerged. One must also point to the polemic of the three gorges dam in China.

All that remain are the other forms of electricity production. This ‘other’ concepts group a wide spectrum of methods: wind turbines, solar panels, rubbish processing plants, geothermic processing plants, and cogeneration. Some of these technologies are still at the prototype level, whereas others can only be used very marginally. Solar panels are very expensive and difficult to finance (without a state grant, as the reader shall see). Cogeneration seems to be a promising solution but is still fairly new. Finally, wind turbines, if placed intelligently may produce affordable electric energy, but generally the state or government have to artificially promote this production. Furthermore, wind turbines do not fit very well in the landscape and are susceptible to local opposition much like hydroelectric dams.

1.2.4 Distributed generation

As described in the previous section, alternative and renewable energy sources may be the only one possible choice and solution for some countries, especially in Europe until now. But also as we already saw, these sources are expensive and difficult to implement, at least on a large scale. They need a new way of thinking. This way is now getting built:

France has promulgated a law in 2000, which redefined the role of the electric public service: “guarantees the electric supplies over all the territory, in respect of the general interest. According to the energy policy, contributes to the independence and security of the supplies, to the air quality and to the fight against greenhouse effect, (...) and to the rational use of electricity”. Towards the terms used in the introduction, this law introduced a small revolution: force all electric power distributors to buy at any time any electric energy produced by the way of renewable energies, at a fixed price, as long as the production capacity stays below a certain limit [1.5].

Following to this law, an order in council defines the rates (in Euro cents) at which the power distributors must buy the power (per kilowatt-hour):

• For wind energy, 8.38 cents the five first years (of exploitation), then between 3.05 and 8.38 cents

• For hydro electrical energy, between 5.49 and 6.01 cents • For solar energy, 15.25 cents, and even 30.5 cents in Corsican and overseas departments.

Assuming that cost of production of the nuclear kilowatt-hour, usually known as the cheapest one, is evaluated to 2.7 cents, the previous cited rates are very generous. The French state also grants subsidies when buying the equipment, and procures fiscal advantages to people that install such power generators.

This costly policy (one billion euros yearly, previsions for 2010) is however producing results: it is now profitable for a particular in France to equip his house with solar panels or a wind turbine [1.3]. In 2002, home-installed photovoltaic power (connected to the network) totalled 528 kilowatts. In 2003, this number almost tripled to reach 1483 kilowatts. This should also bring the prices of the photovoltaic panels down because of the increase in production, induce some fresh and innovative ideas (fig. 1.3), and could launch a new trend. France predicts for 2010 7 gigawatts of new installed power by this way. In comparison, France has 116 gigawatts of installed power, for an average consumption of 48 gigawatts. Consequently to this program, renewable energy power will no longer be considered as marginal, and construction of traditional power plants should be avoided.


13

Figure 1.3: Architectural integration of a wind-mill

This new way of electric generation however induces new problems related to electric power production and distribution. First of all, wind or solar power highly depends on the climatic conditions (moreover, solar panels are of course ineffective during the night). When a significant part of the installed power is wind or solar dependent, traditional load planning and dispatching methods will not work anymore. The behaviour of a hydraulic, gas or steam turbine is completely determined by the controller, and can be planned in advance. On the other hand, wind turbines and solar panels turbines are stochastic, which introduces a statistical part into the planning and dispatching algorithms. Reaction times (of the algorithm but also of the commitment system) should be heavily reduced, since a wind turbine offers no prevention before slowing down: when it happens, a battery should work in the interim, until another generation unit can be committed. The smaller the time until the commitment of the substitution unit, the smaller the requirement on the battery.

Secondly, this leads to a drastic change in scale. In the past model, generation and transportation networks consisted of relatively few power plants, producing higher order power quantities (~gigawatt). Those high order generations only permitted to adapt the quantity of power to the demand at one point, the other generations being fixed on the other points. In presence of an electric system having implemented wind or solar energy, the number of generators explodes, and the operating margin for regulating the power becomes very narrow. The generation is not centralised to a few points anymore, but spread in many different places. That is the origin of the term Distributed Generation. Integration of distributed generation into current transport and distribution networks is really a technical challenge, and this represents an entire domain of research.

1.2.5 Market liberalisation

Additional to the geographical decentralisation presented previously, another parallel decentralisation is running alongside, on the financial and property plan this time.

Electric market liberalisation is a sensitive subject, precisely because electricity supply assumes a great importance on the political scene, among others. It could be considered as a mix between two ideas. The first one, very ideological, that almost everything should be liberalised, is expressed by means of supply and demand. According to these mechanisms, the market laws (concurrence among others) will automatically control the domain and stabilise at a near optimal state. The corollary to this theory is that every centrally organised system is subject to inefficiency, since central mean no concurrence and no way to compare itself to the others.


The second idea, more pragmatic and applied to our electrical case, means that if the historically simplest (and even to only possible) way to design, build and operate an electrical supply system in a zone (in general a country, sometimes a region) was to do it completely centrally, this no longer makes sense. This may be particularly true in Europe. Even if electricity is more than ever a strategic resource, European countries put now enough faith in their neighbours to share the electric resources, in order to reduce the costs. International commerce increases each day and much more goods or services are crossing the borders now than ever in the past. There is no more reason for a land to stay electrically disconnected from its neighbours, which implies power and money exchange, and consequently the presence of a market, which can be more or less internationally regulated.

If until now the question of market liberalisation took place more at the generation and transportation level, allowing only electrical operators to deal among them, the arrival of the distributed generation changed the balance. Indeed, consumers are becoming producers, interested in selling their power at a certain price. Independently, the increasing ecological conscience brings people to have a desire for possibility of generating power. In Switzerland for example, it is already possible to buy with a guarantee electrical power which has been generated with renewable energies, albeit at a slightly more expensive price.

Finally, an electrical provider is at present supposed to be constantly able to provide a given current intensity to a customer, except in cases of heavy failure. This could be brought to be changed in the future, with people being ready to support some more frequent power cuts in exchange of discounted prices. If those discounts are important enough, it will eventually be profitable for customers to buy a cogeneration or diesel generator, to ward of those cuts. Even profitable if at another time a customer may inject some of his own power into the network, at a good price (like peek hours).

According to stock exchanges, raw material or property market mechanisms are already pretty difficult to analyse, electrical power markets have furthermore to deal with hard real-time constraint (I need this power at this price and now), and security constraints (if I buy this power, is it possible to transfer it to me without overcharging the lines ?). An ideal and elegant solution about how to liberalise completely the electrical market has not been found yet. Remains also a challenge for the economists, power systems engineers, and mathematicians.

1.3 Focus on the distribution networks

Typical representations of the electrical supply networks consist of three layers, which also correspond to three different tension levels. On the top lays the transport layer. The transport layer is basically made of high-voltage transmission lines and buses (high-voltage stations). The voltage level (going from 65 kilovolt to 380 kV, or even more) permits a reduction of the losses for long distance transport.

On the lower part lays the low-voltage distribution network. These networks are pretty simple, and basically just connect a private consumer to an electric transformer (the last mile of the network). The voltage does not exceed 250 volts for security reasons.

Between both layers, there is an intermediate one: the medium-voltage distribution network. The voltage levels are variable, generally contained between 5 and 50 kilovolts. The voltage corresponds to an economic optimum, since that higher voltage levels reduce ohmic losses, but need more expensive transmission cables, to perform the isolation.


15

1.3.1 How the previous cited problem affects the distributions networks

The medium-voltage distribution networks (also just called distribution voltage, since the low-voltage does not really form a network) are actually faced to four main problems.

• Distribution networks are constantly evoluting, following the development of cities and rural areas. They are sometimes difficult to extend as quickly as the cities or as the electric consumption increases, especially when the cables are subterraneous. More than transport networks, they have to deal with the geographical distribution: there is not one load at one point but many different loads at different points. For this reason, they are more complex and dense than their transport equivalents.

• Minimising the losses into a distribution network has always been an important research domain for electrical engineers. In the future, economic and political motivation should be focused on the energy rationalisation principle. Furthermore, even though in the past and still today the commands of the distribution networks are manual, automatically and remotely controlled commands are more and more common, which allows to react rapidly to the state of the network and permits frequent loss-reduction changes.

• With the appearance of the distributed generation paradigm, the distribution networks are no longer distribution networks, but repartition networks. In the distribution networks, the direction of the current is always the same (from the feeder to the consumer); with distributed generation, the direction of the current may change from one case to another. This implies big changes in the manner of operating the network, and in the security devices of the network. Furthermore, a wind turbine connected to the network has no energy production guarantee, and here again, the network must be able to react quickly.

• Distribution networks will soon have to deal with market liberalisation (corollary of the distributed generation). How to permit the existence of an energy market while keeping the network correctly organised, guaranteeing power feeding, and according to the security policies?

The two first cited problems are not new, and active research has been conduced for many years in this area. They are classical power system problems and can be considered well-known, even if the perfect solution has not been found yet. On the other hand, the two last problems present a new challenge, all the more so since they will have to cohabit with the two first ones.

1.3.2 Abstract description of the problem

Assuming that low-voltage distribution networks consist uniquely of point-to-point connections, and that transport networks are on the opposite grid- or mesh based, a distribution network presents a hybrid structure. It is operated within a radial or tree structure, with always one unique path (made of active links) between a node and another one. However, physically, it presents a high-density mesh structure, especially in urban examples. This implies the presence of additional inactive links. These links are present for two main reasons:

• A radial graph offers one and only one path from one node to another. Consequently, a failure in the graph means the automatic isolation of at least one node, which should be avoided. Assuming that 100% failure resilient electrical links do not exist, the solution is to give some redundancy to the network, adding from several to many lateral links.

• The loads to serve at one point are subject to variation (day/night, winter/summer, special circumstances). The ratios between yearly average and peak consumption are important. The network must be dimensioned according to the peaks, resulting in a weak average use of the links. When a link comes close to its maximum value, the operator should plan an increase of the link capacity, which is a costly operation, in terms of time and money. Or, he should only look if the load present on this link, by switching on some several lateral links, can be reduced.


Now, the interesting question is: which branches or links should be used and which ones should be disabled? After a failure, some particular changes in the topology have to be done quickly, in order to feed all consumers. This part of the problem is called reconfiguration since it re-configures an existing state of the network. After an extension, or during regular analysis, a new operational structure can be decided, according to load statistics from the last month. In this case the problem is known under configuration problem.

Remains to justify the necessity of operating a distribution network within a radial structure. A mesh operated electrical network requires the presence of control devices, and according to the size of the treated networks, equipping one entirely with such devices implies big investments. The advantages that would procure a mesh-operated distribution network (in term of losses, failure-resistance) are not comparable to the investment size. However, the arrival of the distributed generation and market liberalisation problems will eventually oblige the owners of the links to invest into more sophisticated control devices. In this horizon, one may think that a meshed distribution network is the solution of the future. It is too early for any predictions, and for the moment, one will assume that distribution networks have to be radial.

1.4 The agents and the last optimisation techniques

1.4.1 Classical optimisation methods

The previous question, which links should be used and which ones should not, may appear easy to answer on first look. Apparently, there is no need to solve big equation systems, no integrals, no derivatives. One needs only to elaborate a list of links to activate, or to disable.

The reality is unfortunately not as simple. First of all, the number of possible versions of the list is very big, since it corresponds, as in a lottery, to a combination of a certain number of elements. Such mathematical problems are for this reason called combinatorial problems. Secondly, the problem depends on the state of each link which is either active or inactive, and cannot be a ‘partially’ active. Such problems are called discrete, and need a particular methodology.

Since many things in the world can be formulated as a discrete combinatorial problem, many methods to optimise them have been imagined, developed and improved during the years, forming now a separate topic in the mathematics: the discrete optimisation. Note that one speaks of optimizing and not of solving. It is indeed very rare that the optimal value can be found by solving something.

As one will see in the second section, there exist several discrete combinatorial optimisation methods. Although they may differ greatly between each other, all classical optimisation methods are however based on three principles: space representation, exploration and fitting:

• Space representation proposes to consider each possible combination as a point and to build a map with all the points.

• Exploration means travelling in the solution set, using the previously drawn map to locate oneself.

• Fitting will evaluate the quality of a combination, according to optimisations criteria. • Using these three functions, an algorithm will select a certain number of combinations,

analyse them, and return the best one.


17

1.4.2 Biological inspiration

Even though the first developed methods were very systematic and mathematical-oriented, researchers remarked that the most rigid method was not the one with the best results. New methods appeared with the introduction of controlled randomness, using random numbers to plan their exploration, using more or less randomness as a source of creativity.

One day the researchers realised that something was experimenting, exploring and optimising since million of years: life. They realised that life was an expert in the use of randomness. Genetic mutations are completely unpredictable and may affect any gene. There is a big part of chance that a precise individual and another mate and breed. On the other hand, almost everything in biology makes sense. It makes sense that humans are between 1.5 meter and 2 meter high. That coconut floats and reaches other shores by this way, that bats rely on a internal sonar.

Those researchers began to take inspiration looking at the biological world. And they began to elaborate new methods based on biological principles: genetic algorithms for example, propose a representation of the combinations like individuals, to randomly introduce small mutations into them, to interbreed them, and select only the best ones. But other methods took inspiration from the movement of the bird in a swarm, or the methodology of exploration of the ants.

However, these methods are always based on the three previously cited points: space representation, exploration and selection. All these methods, classical ones as biologically inspired ones are normally conducted centrally, by one central computing unit.

1.4.3 The distributed fashion

After many years of improvement, the methods described before are however reaching their limits. New ideas have to be introduced. Among them, the concept of distribution. Again, as in real life, it often makes sense to split the problem in several sub-problems and delegate a person or a group of persons for each of them. It can be seen as the base of any collective society, under two paradigms:

• Task sharing - where a big task, that would be too much work for one unique individual, is done by many, making its realisation possible.

• Specialisation - where a task, which would be too difficult technically for one unique individual, is solved by many, where each of them will use their individual skills.

Because its benefits are obvious, the distribution idea is progressing quickly, reaching into all research and optimisation domains. New problems will however appear. Again, as in the life, the splitting and the allocation of the tasks implies the presence of an organisation organism. Historically, in the human history, the social organisation has always been hierarchical, leading to the presence of chiefs, superiors, subordinates etc. Recently however, the hierarchical organisation is contested and chiefs are replaced by committees, boards, assemblies, etc. One thing is however always true: working elements must be somewhere controlled.

Organising a group of individuals, in a firm, in a country, in the world, is not a recent question. Sociologists, anthropologists or even economists have been studying for many years, and even before, the question of how to organise a state. This has always been a critical question (a philosophical one, see Plato or Seneca writings). They have however to deal with the human condition and its flaws (corruption, abuse of power, etc). In the optimisation or even scientific domain in general, workers are assumed to be well disciplined and without ambition. Three main points remain however to be solved:

• Some problems are difficult to split in equal subparts. Furthermore, all problems include a part that is it not possible to split. That implies that some working elements will stay sometimes idle, since they wait for another element to finish.


• Sub-problems are rarely completely independent between themselves. This implies the necessity for the working element to communicate regularly the last results or information, either to the chief, or directly to the other sibling elements.

• Working elements have to be, in one manner or another, organised. Whatever the retained solution (strong and rigid hierarchical structure to complete collaboration and hierarchy avoidance), there is always a kind of work and time overhead, due to the necessity to control all the workers.

New methods have of course to take in account those problems. But, in all cases, in some very complex situations (like in the internet, as one will see in section 2), there is no other alternative but to split problems and for that reason distributed algorithm and science is becoming a very active area of research.

1.5 Synthesis

Points 1.2.4 and 1.2.5 asked the following question: How to deal with different actors (on the economical layer and/or on the electrical layer) in a distribution networks? Point 1.4.3 introduces another: How to apply a distributed optimisation method to the distributions networks? This thesis proposes to find a common way to solve these two questions.

The answer should be common, because on one side, the presence of many actors induces the necessity of a distributed organisation and command system, which will be inspired by the existing distributed systems in the world and in the scientific world. On the other side, in order to apply the latest optimisation ideas to the configuration/reconfiguration problem, one must be split somewhere. Why not split among the actors?

2. Description of the problem and of the work environment

2.1 Thesis specifications

2.1.1 Main idea

According to what has been said in the previous sections, the purpose of this work is to explore the new possibilities offered by the latest distributed (also called multi-agent) optimisation methods, and to see how they could be applied to classical or newer problems related to distribution networks. The purpose of this work is not to perform a revolution in the distribution networks operation, but must be taken and read like an introductive study, demonstrating the advantages as well as the drawbacks of decentralisation, tracing the guidelines for future works, and exposing the next reader to the problems confronted.

2.1.2 Official information and given specifications

This work was conducted over the course of six months, from November the 15th, 2004 to May 14th, 2005, at the ‘Power systems laboratory of Pontifical Catholic University of Chile’, in Santiago, Chile. It has been supervised locally by Professor Hugh Rudnick. At the same time, it has been remotely supervised by Elvira Keagi and Professors Alain Germond and Sidi Rachid Cherkaoui, from the ‘Electric Power Systems Laboratory of Swiss Federal Institute of Technology’, in Lausanne, Switerland.

20 Chapter 2 - Description of the problem

On November the 15th of 2004, the problem and task at hand was defined as follows to the author:

Introduction :

Electrical distribution networks are operated according to a radial configuration. However their basic structure generally comprises loops. Therefore they can be configured according to several possible operating schemes in order to supply the loads required by the consumers. Heuristic methods were developed successfully for solving this combinatory optimisation problem, (Merlin and Back, 1975, Liu 88, Aoki et al. 88, Cherkaoui 93, Rudnick 97). Presently, new methods are available, and the optimal configuration problem needs to be extended, including the integration of distributed generation sources in the distribution systems, and in the context of liberalised markets.

Objective:

The objective of the diploma project is to investigate the application of multi-agent techniques to the optimal configuration and reconfiguration of electric distribution systems, including dispersed generation. The evaluation of the method will include a comparison between the results obtained with multi-agent and known heuristic methods.

Working plan:

1) Study and understand the problem of distribution system configuration and reconfiguration, and the application of heuristic methods to this problem.

2) Propose a method based on the application of multi-agent systems to solve the distribution system optimal reconfiguration problem. Evaluate the possibility of defining as objective function the minimal number of reswitching, in addition to the usual loss or line overload minimisation.

In this first part of the project, the distributed generation will not be considered.

3) Generate synthetic distribution networks for testing the algorithms. Evaluate the performances and convergence properties.

4) Compare the performances of the multi-agent methods with those of heuristic methods in the case of practical examples analysed in the PhD thesis of Rachid Cherkaoui, who will provide the numerical data.

5) Propose an approach for including the distributed generation in the model.

6) Conclude and prepare a final report in English, following the attached instructions.

Chapter 2 - Description of the problem 21

2.2 Classical description of the configuration/reconfiguration problem

2.2.1 Combinatorial optimisation problem

In the point (1.3.2), the problem of the configuration/reconfiguration has already been defined. Formally, given a graph G(X,B) where X is the set of the nodes of G and B the set of the links in the network, the problem consists in finding a subset of links L, L ⊂ B. An element present in B is defined as able to transfer a certain flow between its two extremities. The presence of a link l in B means that the corresponding electrical liaison is active.

The set L ⊂ B is said connected, when for every two nodes of X, there exists a path in L. Moreover, the number of elements of L is equal to the number of elements presents in X minus one, or expressed formally,

Those two properties are due first to the necessity of feeding all consumers, and secondly to the radial physical constraint (see point 2.2.2).

To further define the problem, two sets U and Y must be attached to B, U being the set of all binary variables defining the state of each link (active or disabled) and Y the set of the variables representing the electric currents in the branches. Another set Z must be attached to the node set of X, formed by the variable representing the voltage levels at the nodes.

Given this notation, the classical formulation of the problem is

Optimize f(U, Y, Z) under constraints :

• Arborescence of the graph • Branches and cables capacity • Feeder capacity • Voltage levels and Kirchhoff’s equations

The function f(U, Y, Z) is arbitrary chosen but should take in account several criteria:

• Losses minimisation • Load balancing • Voltage drop-down • Switching operation

It must map the advantages or drawbacks of a possible combination, and if possible be growing, i.e. for any combination u1 and u2, equal except for one criterion where u2 is better than u1:

The present optimisation problem is multi-dimensional, and the global quality of the solution depends on the quality of various criteria. Depending on the case, one may either project all those dimensions over one ‘quality’ axis by the mean of weights, or let the algorithm free to find the Pareto-front of the

|L| = |X| - 1 (2.1)

f(u2, y2, z2) ≥ f(u1, y1, z1)


function. Note, however, that optimising only one criterion at the same time is generally impossible, due to the correlation between the criteria and the non-linearity of the problem. Hence, criteria are non-independent cannot be decorrelated.

2.2.2 Physical constraints

Any set L of links (lets say candidate) must before being evaluated and classified as a possible solution, fulfill several criteria in relation to the physical properties of the network:

Radial property - arborescence

Since the distribution networks must be radial (graph theory says ‘arborescent’), any candidate combination must respect this property. It is possible to express formally and mathematically this constraint. In reality, this property can be very easily verified using an algorithm that would, stating on one node, visit recursively all the node’s children. If a node is visited twice, the loop exists. If a node is never visited, the graph is not complete (isolated parts).

Before using such an algorithm, it would, however, make sense to use the property (2.1) and check if the number of links selected equals the number of nodes minus one. In the negative case, candidate is to be discarded immediately and some computing time will be saved. The proof of property (2.1) is recursive, and can be found in any basic graph theory handbook.

Branches and cable capacity

The links of the graph represent electric cables, which have, as with any electric device, security specifications. Each cable has for the least a maximum voltage, and a maximum power value. While maximum voltage is set by the isolation properties of the cable, excessive transported power may induce a high resistance heating effect and damage the cable.

Each element x of X will define an Ix max value, and for any branch k of the graph, the security constraint must be respected, i.e.:

where:

Ik max maximal authorised current in branch k Ik actual current in branch k uk state of branch k (active or disabled)

Notice that current or voltage limits are often set according to physical properties of the cables, but not always. Other considerations (electromagnetic noise, shortcut risk, load balancing) should bring the operators to fix limits below the physical ones.

Feeder capacity

Each feeder (normally HV/MV transformation station) defines also a maximal load property, defined by the transformer’s specifications. Exploiting a feeder outside its nominal capacity may cause a voltage drop on the network, or even seriously damage the feeder equipment.

A solution candidate shall always exploit the feeders below their capacity.

Ik max ⋅ uk ≥ Ik


Voltage levels and Kirchhoff’s equations

A candidate must of course satisfy the constraint announced by a derivation of Kirchhoff’s currents lemma, which states that on any node of the network, the sum of the incident currents of the node (negative or positive currents, depending on the branch orientation) must be equal to the current consumed locally by the node.

Furthermore, according to the functioning modes and policies of the transformers, a certain voltage level must be guaranteed on the entire network. Since long cables may induce significant voltage drops, a candidate must fit within this constraint and feed the consumers without using paths that are too long. This constraint is related to the ohmic losses optimisation’s criterion, since a long path induces them as well. Note also that voltage drops may be declared as unacceptable only when exceeding a certain value, but shall moreover always be minimised, as one will read in the next subsection.

2.2.3 Optimisation criteria

Once a candidate has been identified as a valid solution, its quality will have to be evaluated, using the previously announced optimisation function f. Here again, several criteria shall be taken in account:

Losses minimisation

Electric ohmic losses are unavoidable, and induce several technical and economical problems. If on one hand any thermal dissipation is wasted, it will not produce any profit. On the other hand the resistance and the capacity of electric cables are inversely proportional to their temperatures. According the Ohm’s rule, they are defined by the following equation:

where:

The sum is over any branch k of the network

• Rk the resistance of branch k • Ik the current present in the branch k

The minimisation of the losses at the same time, results in the maximisation of the exploitation margin. They are also related to drops in voltage.

Load balancing

In order to avoid feeder surcharges and hence power cuts at the consumer level, it is desirable that any feeder disposes of a certain current or power margin. The whole consumption over the network should then be spread as uniformly as possible among the different feeders. This criteria can be expressed in many ways, for example by minimising the difference between the reserves of effective power (expressed in watts) among the feeders, or on the contrary, between the relative reserves (expressed in percentages). The minimisation is usually done according to a least mean squares method.

Voltage drop-down

As said in the previous sub-section, voltage drop-down shall always be minimised, since a voltage-balanced network will offer a better resistance to failures or load modifications. Like for the load balancing, a least square method is usually used to express the global voltage differences.

Sum (Rk ⋅ Ik2)


Switching operation

Since many distribution networks are still manually operated, restrictions on minimising the number of switching operations assume particular importance. The minimisation can be simply done on the number itself. However, depending on the structure of the network (geographical, economical), certain switching operations may be privileged to other ones. The reader will refer to [2.1] for more details on this topic.

2.2.4 NP-hardness property

At this point, it is important to explain why finding the best solution or even a ‘not too bad’ solution is not obvious. The first step in this direction is to express the number of possible candidates for a given situation. As said before, the number of selected links |L| must be equal to the number of nodes |X| minus 1.

Upper bound

This can be use to extract an upper bound for the number of candidates: count all the possible ways to select |L| elements among |X| elements, which is

Lets evaluate this value for some examples :

15 nodes, 20 branches: possibilities < C (15, 20) = 15'504 25 nodes, 30 branches: possibilities < C (25, 30) = 142'506 100 nodes, 120 branches: possibilities < C (100, 120) ≈ 2.433 ⋅ 1018

As we can see, the presence of a factorial operator makes the numbers increase very quickly, and although the third example is only 4 times bigger than the second, the numer of possibilities far overshadows that of the second.

The numbers cited before are, however, only upper bounds. Selecting |X| - 1 branches does not guarantee at all the completeness of the network (completeness means every node has a path to any other). The real number will be in reality much smaller, but it depends directly on the topology.

Lower bound

A lower bound may also be found. Given a graph with n nodes and m > n - 1 links and assuming there is always at most one link between two nodes: to reach an arborescent topology, m - n + 1 links will have to be removed, and the links to be removed must be part of a loop. Each time that one link is removed, there is always at least one loop and the loop has always at least three links. From that results at least three choices to remove a link, and that this choice is independent of the previously removed links. Therefore, there are at least 3m - n + 1 possibilities to reach an arborescent topology. Using the previous examples:

15 nodes, 20 branches: possibilities > 320 - 15 + 1 = 729 25 nodes, 30 branches: possibilities > 320 - 15 + 1 = 729 100 nodes, 120 branches: possibilities > 3120 - 100 + 1 ≈ 1010

C(|L|, |X|) = (|X|)! / [(|L|)! ⋅ (|X| - |L|)!]


Although the resulting numbers are, at least for the two first examples, very low, the non-polynomial property of the solution space has been demonstrated.

There exists, however, an analytical method to compute exactly the number of arborescent topologies of a graph. It is based on a matrix representation of networks and the computation of its determinant. Reader will refer to [2.1] for more details.

Remember that it still has not been proven in this report that a polynomial method to solve this problem and to find the best solution actually exists. In other terms, that there exists a method other than enumerating all or a big part of the solution to find the best one. To evade this difficult question, without entering into the deep subject of algorithmic complexity, one will say that:

• Even if the problem of finding a minimum spanning tree (finding a set of links that connects all the nodes in between while minimizing the total sum of the weights of the links) has been identified as a member of the NP-simple set, so that there exists an algorithm that can find the best solution in a polynomial time, in the current case, the number and the diversity of the constraints and optimisation criteria render impossible the creation of a simple weight for each link. Our problem will then be considered, as it is the case in the literature, as a NP-hard problem [2.1, 2.2]

• The existence or the absence of any method permitting the resolution of NP-hard problems in polynomial time has still not be proven, and is one of the greatest interrogations of mathematicians to date[2.3].

There are then really no ways to follow other than the heuristic way, as described in pragraph (1.4.1). As one will see in the literature survey (2.2.6), save two or three exceptions, the heuristic way is privileged. It is globally assumed that problem is hard to solve, and exhaustive search methods must mostly be banned, due to the size of the solution space.

2.2.5 Load-flow computation

In order to know all the characteristics of a candidate, and to estimate its validity and quality, a load-flow computation algorithm must also be used. Due to their arborescent property, load-flow computing is much easier to compute on distribution networks than on transport networks. Furthermore, in many fictive cases or even in some real cases, simplifications can be done.

The standard representation and model of a transmission line is represented in figure 2.1. This representation already implies a simplification, since the transversal susceptance is split in two equal parts and placed on both sides of the line, even though a perfect model would realise the integration of the linear susceptance over the length of the line.

Figure 2.1: Model of a branch

Ii Ri jXix x

jBi2

jBi2

V V


In the case of distribution networks, according to the relative short size of the links, always regarding fig. 2.1, the phase gap between the voltages present at the two ends of a line shall also considered negligible (αij ≈ 0).

Finally, as was the case in this work, the last possible simplification is to liken current and power in the networks to pure direct current and define the phase gap between voltage and current as also negligible (ϕij ≈ 0).

Furthermore, one may suppose the presence of a device that would raise the voltage to its nominal value ‘for free’ in any node of the network. This last simplification is however extreme and will not be possible in a real case. This does not, however, deter from its application it in order to simplify the development of new methods and algorithms.

2.2.6 Actual methods and literature survey

The number of publications treating of distribution networks optimisation shows directly the research activity on that branch and the importance of the topic. Almost all optimisation techniques have been applied by somebody to the problem.

Save A. B. Morton and I. M. Y. Mareels, who presented a brute force exhaustive method [2.4], the heuristic way has been, like explained previously, primordially used. Three categories of classical heuristics may be identified: constructive or greedy (starting with all branches off and enabling one of them after one, until having a connex graph) [2.1], destructive (starting with all branches on and disabling progressively, until having a non-cyclic graph) [2.1, 2.5, 2.6], and ‘branch exchange’ or ‘switch exchange’ (starting with a given case, try to find two branches - one active, the other deactivated - so that activating one and deactivating the other will globally improve the quality of the case) [2.1, 2.7 and 2.8].

All these methods generally make use of the Dynamic Programming paradigm, namely that to pass from one state of the algorithm to the next one, the decision corresponding to the best ‘immediate profit’ will always be taken. Dynamic Programming has been proved very effective for problems satisfying the Bellman optimality principle (a small positive change is always a step to the best solution). For some problems however, dynamic programming gets quickly stuck in a local optimum, and must be framed with other techniques (backtracking, random generation) [2.1].

Figure 2.2: Bellman optimality principle

2

8

6

5 4

6

2

8

5 4

6

Satisfies Bellman’s optimality principle (the way to the global optimum is only made of ways to the best possible next state)

Does not satisfy

X Possible state of the algorithm, associated solution’s score X

Possible next state

Best possible next state

Part of way to the best state

10


Other heuristic techniques are: Branch and Bound (identify each time a criteria that allows to discard the greatest number of solutions) [2.1], Expert Systems (ES) approach (identify the problem using several if/else clauses resulting to stored ‘rules’, and respectively to the case, choose several actions) [2.9, 2.10], Neural-Network (NN) methods [2.11, 2.12], Genetic Algorithms (GA - build a population of feasible solutions, then select some of the best ones, mix them, and include the new solutions into the population, and start again) [2.13, 2.14, 2.15], or Simulated Annealing (SA - apply random changes to succeeding solution, lowering continuously the randomness - the variance) [2.1, 2.7, 2.16]. Remark that many of those techniques use also a mechanism of ‘branch exchange’. The way to find two exchangeable branches differs however in each method [2.1, 2.7, 2.9, 2.13, 2.14, 2.15, 2.16].

Some of the cited publications discuss the used load-flow methods [2.1, 2.5, 2.6], others simply do not mention it. There exists in the literature a large choice of load-flow resolution methods (Gauss-Siedel, Netwon Raphson, fast-decoupled) [2.10], with different levels of precision, computing time, and depend on the simplifications used to model the network. One will refer to [2.17] to have a good idea of this subject.

2.3 The distributed paradigm

2.3.1 Divide ut imperes

Divide ut imperes, divide and conquer in English, a historically famous quote. It has been attributed to many historical politicians, generals or kings (Philip of Macedonia, Roman senate, Louis XI of France, Catherine of Medici, Machiavelli, Napoleon) and that is not an hazard since it represents exactly the way to follow in front of big tasks, works or responsibilities.

This idea is, however, not new in the field of algorithms or even mathematics: any recursive reasoning shall be considered as a manner to divide a problem. A good definition can be found in [2.18], where solving a problem comes down to:

• DIVIDE - split the problem in sub problems • CONQUER - solve recursively the sub problems until the size of them allows a direct

resolution • COMBINE - reorganise the solutions of all the sub problems into a complete solution of the

initial problem

P. Dumas [2.19] gives many examples of mathematical subjects where similar division is used.

But, if the division paradigm may be applied to tasks/problems, it can as well be applied to the resources that solve a problem or a task. In the real world, it consists in hiring more workers, buy more machines and organising the whole work among them. In the computer world, and since computers are used to solve them, in optimisation or scientific problems, it consists in using more CPUs. The first computer systems using multiple CPUs had them ‘inside the box’, i.e. generally soldered on the same motherboard or on different ‘sisterboards’ located in one case. Actually, multiprocessor computing is evolving into two directions:

• Integration on the same chip of multiple processing units (Intel’s Pentium 840) • Build big computing meshes using simple personal computers.


The second point is actually possible thanks to the huge developments made in computer networking. But the greatest innovations in the field of work and task distribution are due to the internet.

2.3.2 Internet and the distributed revolution

Historically, the Internet (in the fact is direct ancestor, Arpanet) has been thought from the first day as a decentralised and distributed network. The motivation was strategic and military: to provide a highly redundant network to command the launch of nuclear missiles. Indeed, at the time, while the nuclear missile bases were ultra protected and secured, the Achilles’ heel of the system were the transmission cables. Arpanet was then built under the assumption that if already several cities or command centres had been eliminated, it would always be possible to launch a reply. Hence, Arpanet came to light in 1968.

Arpanet slowly migrated from a national defence network to an educational network. Since Arpanet was only the backbone on the communication system, and since many other smaller and local communication networks (campus networks) had connected to it, its name progressively changed to Internet. In 1990, the original Arpanet links had been disabled, replaced by wider band and faster connections. In the same year, the World Wide Web is conceived at the CERN is Geneva.

The Internet quickly appeared like a fantastic knowledge exchange mechanism, allowing researchers of the entire world to share information and use other researcher’s know-how. With the introduction of the html, and the democratisation of the WWW, it was however only a small part of what the Internet would provide in the future.

At the present day, researchers, artists or businessmen still encounter difficulties imagining all the possibilities of the Internet. As a communication network, the Internet already changed many things in the postal world, reducing almost all the mail transfer to only official documents and physical goods. The Internet has also helped make a dent in state censorship and information processing. It is about to destroy the classical phone networks [2.20], and to revolutionise the idea of personal and intellectual property, with the apparition of file sharing applications. But the Internet also presents some bad sides: each year at least one paedophile network is discovered. Anybody may publish anything on the web. Furthermore, just at the moment when some internet related laws are edited and applied, new cryptographic transfer methods are applied, making the tracking of any misuse or illegal use of internet quasi impossible. That illustrates the abilities of a distributed network: unpredictable, ultra resistant, innovative...

Internet provides a quasi total abstraction between the physical and transport layer, and the application. Internet networks devices (routers, DNS servers) have as objective to allow any computer to communicate with any other computer, whatever the type of communication. Internet applications will assume that any connected computer is reachable and able to communicate, whatever the type of link. The distributed paradigm lies however across the two worlds. The ‘physical’ network is built of more or less random connections, similarly to a road network (at the difference that it is actually impossible to map the whole internet) and use a distributed system to route the packet at the good destination, allowing constant changes in the topology, and providing failure resistance. Similarly, the more recent distributed application also define logical links and maps between the peers, and even provides a routing functionality in certain case. One can say that Internet is actually built of a double distributed system.


Figure 2.3: The double distribution of internet

It is however very important to notice that Internet is absolutely not optimal, and even far from of any kind of optimality. On the ‘physical’ layer, links have been added progressively, trying each time to resolve a part of the traffic jam problems, exactly like roads and street in the road network. Besides, many links are not in service, due, e.g., to commercial preoccupations. From a peer-to-peer point of view, the route (defined by routing rules) is also never optimal, and a transmission between Sweden and Chile will may be once be routed through California, though the existence of a direct Europe-South America link. The optimality is also not reached at the ‘logical’ level, according that much data will be transferred many times in opposite directions. That is particularly true with the file exchange platform like KaZaa or eDonkey. A file will probably be transferred from a user A to a user B, and then from the user B to a user C, though user C is very close to A. This might also be the case according to internet radios. A whole sound stream will be transferred from radio server to each end listener, even if many listeners are close together. Multi-cast networks research is trying to slowly avoid this bandwidth waste, but the road is long and, once again, optimality should be considered in this case as an impossible dream.

Nevertheless, those drawbacks do not prevent that Internet is a genial thing. Assuming the relative chaos of the Iinternet structure, the result works ‘fairly well’. Even more, it is almost sure that internet is working due to its chaotic organisation, and that any organised counterpart will maybe work worse, or even will not work at all. Out of this example, one shall keep in mind that optimality, and certain cases, is not the main keyword. And that the best solution may sometimes appear in cases where strict optimality principles have precisely been dismissed. In relation with the biological example cited in the introduction, many things in the biology are not optimal. All the same life continues its millenary evolution and who can say where it will stop?

2.3.3 Spanning-tree organisation in Ethernet devices

The Internet is of course very large and complex, and it would not make any sense to compare it with the electric distribution networks. A more appropriate distributed example in the computer communication world, is the spanning tree protocol in IEEE 802.1 compliant networks (the classical Ethernet network).

As with electric distribution networks, Ethernet networks have a radial topology. This is done in order to simplify the routing process and avoid a packet to cycle indefinitely. In order to recuperate from cable failures or maintenance errors, lateral cables are allowed, but some of them will be disabled. This operation is completely transparent to the user. Ethernet devices implementing the second layer of the OSI model (data-link layer) and lower, such as bridges (also called switches), implement this

Physical network, zones, cables, switches

Internet abstraction, IP, routers, DNS servers

Logical network, TCP/UDP connections


function by default. This protocol/algorithm, assuming any bridge is uniquely identifiable (the MAC address), or a unique priority level, and given a cost for each possible link, will select one bridge as the root, and define the tree of all shortest paths towards the root. It proposes to find a minimal spanning tree in the network, by the mean of the distributed Bellman-Ford algorithm [2.21].

One can note by this example that a distributed system does not always imply the presence of a full processing unit (like a personal computer) at any point of the network. Bridges are devices available now for less than 20 €, effectively implementing a real distributed algorithm.

2.3.4 Distributed algorithms and multi-agent system presentation

In the optimisation and artificial intelligence domains, a distributed system is generally called multi-agent, and inversely multi-agent systems (MAS) can globally be defined as distributed artificial intelligence methods or distributed research algorithms. Similar to real scenarios where a task has to be split into several smaller blocks, each agent in a MAS running independently of the others, receives a specified task and has to solve it on its owns. However, it may communicate with other agents when a part of the information is missing, or if the task depends of the results of another agent. Multi-agent or distributed algorithms presented particular properties:

Organisation

We encounter here again the problem of the ‘social organisation’ of the agents: should one define a well defined hierarchical system, with one or more agents assuming chief functions and assigning the work to subordinates and coordinating the exchanges of information? Or on the contrary, assume a totally egalitarian system, where each agent is identical to any other and will communicate with its peers, also eventually adopting a temporary leader election mechanism. The different processes running on a computer might be considered as agents in a multi-agent system. They are constantly exchanging information amongst themselves and alternately using the CPU(s), but are orchestrated by the operating system which has a central leader and organisational role. On the other hand, the distributed system presented at the previous point (Ethernet) might be considered as ‘purely’ distributed, since any device will use and apply the same algorithm, and are, for this function at least, equals.

Depending on the case, a more or less centralised organisation is desired or to be avoided. The centralised systems are generally easier to develop and to simulate; they avoid many problems inherent to the distribution (consensus, variable sharing, time synchronisation). However, due to the existence of a leader in the system, they present a weak failure resistance, since the elimination of the leader leads to an interruption of the whole service. The full-distribution property of the Ethernet devices, for example, is basically due to the following assumption: the topology is unpredictable and always subject to changes (user connecting or disconnecting cables, cable break). Even if a root is elected in the spanning tree, the disconnection of this root will produce a network reorganisation and should not be a problem for anyone. Other distributed systems follow the earthworm principle, namely that a division will produce two independent systems.

Synchronous vs. Assynchronous

The other great distinction among distributed algorithms is their time-management. While synchronous distributed algorithms operate using well defined time steps (common for all agents, which means the most of the time the presence of a synchronising element), asynchronous ones will work uninterrupted until the end of the work is reached, or until an agent has to wait for an information coming from neighbours. To continue with the analogy of human workers, synchronous means meetings with the chief or colleagues each morning, asynchronous means meetings when necessary.


Figure 2.4: In a synchronous system, messages are sent at the end and next state begins after all receptions

Synchronicity means inefficiency. Since the duration of the time steps are generally fixed (fixed according to the maximum time that an agent can need to complete one step), much computing time will be spent waiting for the next time step. Synchronous algorithm are however easier to develop and to analyse, since many things can be assumed. Asynchronous algorithms must deal with particular problems, like messages ordering (a message A sent before another message B may reach the destination later, which leads to a problem when the sender assumes that the receiver processes the message B after A has been processed).

Figure 2.5: Typical distributed system properties

Message passing vs. Shared Memory

Remains to define how one agent will communicate and interact with one another. Once again, there exist two diametrically opposed concepts. While the shared memory (also called blackboard) concept proposes to reserve a ‘public expression place’, where everyone can read or write, the message passing paradigm assumes that any information exchange is made within a closed message, even encrypted.

The blackboard solution may appear as the simplest one. It presents, however and as always, special requirements. The backboard must be accessed within a certain rule set, to avoid the presence of multiple writers at the same time. If it is the case, the writings of an agent A might be directly overwritten by the writings of B. Furthermore, the writings of anybody are accessible to all, which may be undesirable or forbidden. That is the reason why blackboard systems usually need a central controller that will limit the access of the shared zone in order to guarantee the consistence of the contained data. The necessity of this central controller makes the blackboard paradigm unusable in completely distributed systems.

t0 t1 t2 t3

processing phase message exchange phase

First-in First out order respected

First-in First out order NOT respected

First-in First out order respected but causal order NOT respected


2.3.5 Literature survey about agents and distributed algorithms

As main reference over this subject, one shall refer to a full handbook. [2.22], [2.23] or [2.24] are commonly recommended for that purpose by lecturers. Afterwards, specific application of distributed systems, under the form of multi-agents methods, to scientific optimisation problems can be read in [2.25], [2.26] and [2.27]. One will cite in particular the definitions given for a multi-agent system: “An agent is characterised by the following abilities: autonomy, social ability, reactivity, pro-activeness”[2.25] or, an agent “is a software system that is situated in an environment and that operates in a continuous Perceive-Reason-Act cycle”[2.26].

Various publications present the utilisation of MAS in various research fields: Theoretical optimisation of a function [2.28], usage of artificial ants to assign frequency in cellular radio networks [2.29], dynamic multi-vehicle pickup and delivery problems [2.30], machine utilisation planning [2.31]. And more especially in the electrical area, the multi-agent techniques are applied, among other things: to the power restoration problem [2.32, 2.33], to outage work scheduling [2.34], to unit commitment problems [2.35] and to operate and control a distribution system with dispersed power sources [2.36].

More exotic multi-agent systems can be discovered in [2.37] (use of artificial ants in order to treat the Travelling Salesman Problem) or [2.38] and [2.39] (Particle Swarm optimisation). At last, specific problems inherent to MAS are described more in depth in many articles, refer to [2.40], [2.41] or [2.42] and the experienced reader might take a look into [2.43] to discover particular distributed problems in the case of Peer-to-Peer architectures.

2.4 Traditional software used in this case

2.4.1 Matlab, usual engineering application

At the beginning of a practical work of the size of this thesis, is it worthy to invest some reflection time into choosing an appropriate development framework. In order to implement some research ideas, run simulations and analyse their results, in the field of electricity as in many others, Matlab is commonly used since it provides a relatively simple programming language, many embedded functionalities widespread in scientific studies (Matrix inversion, Fourier transform, or even load-flow computation). Furthermore, it offers integrated graph painting possibilities, allowing the representation of the results.

Matlab was, however, not been retained in this project for two main reasons: first of all, an efficient use of Matlab requires a certain amount of knowledge. The Matlab programming language is relatively simple since it does not need a compiler, but on the other hand, an error is difficult to locate, at least at the beginning. Secondly, Matlab may be a very good environment to simulate and compute many things, but can be very restrictive, in particular when a given functionality does not exists (e.g. when various processes have to be used).


2.4.2 Other traditional languages used for simulations

FORTRAN

The FORTRAN is a sacred monster of the engineering world in general. It has been widely used during many years to simulate or solve many computational problems. It is, however, getting a bit old (more than 50 years) and if Matlab has been discarded for lacking low level functions as thread management, FORTRAN must be discarded for the same reason

Pascal - Delphi - Ada - Smalltalk

There exists an almost infinite list of programming languages. These languages have been used more or less widely in scientific engineering, like Pascal, which was at one moment a reference language [2.1]. All these languages may present advantages but are generally not widely used, and even not widely known.

C++

C++ is the most widespread programming language. It is used to develop commercial computer software, games, compression algorithms, etc. One can also encounter it in the development of many engineering works and studies, and even in agent-based developments [2.44]. C++ is however a very complex programming language. It is possible, through the object oriented mechanism, and using templates, to do just about everything with C++, also a reason why it may be so complex. And since C++ interacts directly with the OS, the public APIs are sometime difficult to find and may require quite a bit of time to understand. All those programming languages have been excluded in favour of Java, described in the next section.

2.5 Java as universal language

2.5.1 Quick description of Java

In comparison of the previously cited programming languages, Java is relatively young since it has been developed in the early nineties. Java is in fact built of two more or less distinct parts:

• the java programming language itself, originally thought and developed as a C++ alternative • the java platform, based on the Java Virtual Machine and the java API

Java is a modern object-oriented programming language. Inspired by the C++ or Objective C, but avoids many C++ drawbacks, although their respective syntaxes may look similar. Implementing the last concepts of the software engineering field, it pushes very far some typical concepts, like strong typing, encapsulation, variable visibility and exception handling.

Java as a platform proposes to compile the Java code into ‘intermediate code’ rather than ‘machine code’. This intermediate code, or pseudo code, will be executed on a Virtual Machine, which works as an interface between the Java abstraction and the computer hardware or operating system. Under this assumption, a Java program will be executable on any Java Virtual Machine, whatever the type of the computer or its operating system. Besides, the JVM maps the basic input/output functions, which allows the program to interact with the user through devices like keyboards, computer mouses or the


screens, but also with other computers through a network stack or with other devices like a printer. Finally, the JVM implements an integrated garbage-collection mechanism, which frees the programmer of many memory and pointer worries.

2.5.2 Main advantages of Java

If some time is needed to assimilate Java’s object-oriented concepts (and by extension to measure the wealth of the language), the ‘pure’ structure of Java normally obligates the developer to write well-structured code. Furthermore, using cleverly selected identifiers or method (function) names, a function of a piece of code may be relatively quickly identified, for example:

int totalAnnualCostOfTheFleet = 0; for (int i = 0 ; i < car_array.length ; i++) { totalAnnualCostOfTheFleet += car_array[i].returnAnnualCost(); }

Without any Java knowledge but with some programming experience, it shouldn’t prove too difficult to notice that the previous code snippet will sum the annual cost of a fleet of cars. Still related to syntax, many constructs must be explicitly expressed in Java, while in C++ or in other languages they are implicit. It results that a Java programmer does not has much liberty. On the counterpart, the compiler will be able to detect many mistakes and errors due to lack of attention, speeding up the debugging process.

Outside the intrinsic language property, programming in Java provides several big advantages:

Multi-platform

As said before, thanks to the hardware and operating system abstraction, a java program shall be ‘written once, and run everywhere’. Since system diversity is always present (the old Macintosh/PC compatible debate, the Linux/Windows new one), the assurance that code will always be usable cancels many organisational preoccupations or even problems, especially in the educational sector, where the diversity is most present. Remark that Java will not work on a machine lacking the Java Environment. It can, however, be downloaded and installed for free, in its basic version.

Java’s embedded functionalities

As said before, the standard version of Java provides a large quantity of classes, permitting the easy implementation of many useful computer concepts, such as a graphical user interface (windows, menus, buttons, etc), user interface devices (mouse, keyboard), but also more core computing utilities like hash values or hash tables, linked lists, mathematical functions like sine, cosine, exponential. Input/output functions are also present, in order to write data to a file on the local file system, or to transfer data remotely.

Network communications in Java

There exists hence of course an interface permitting the use of IP connections. The management of the IP connections, through the socket mechanism, is very simple and intuitive in Java. A simple client/server application is very easy to realise. Furthermore, Java implements a default serialising/deserialising mechanism (marshalling), which simplifies greatly the transfer of structured information.


Multi-threading in Java

Finally, Java provides very intuitive thread management methods. Threads can be assimilated to independent code readers and executers. The presence of various threads induce for the application the possibility to do several things simultaneously (or virtually at the same time, since only one thread can be executed at once on one CPU, and machines defining a CPU for each thread do not yet exist). Displaying information on the screen while listening for remote communications, for example or, in the case presented in this work, simulating many agents using one unique computer. Multi-threading is an advanced topic, and thread creation is often a very difficult operation using direct calls to operating system. Java hides many of those problems, even if the programmer liberty is slightly constrained in the end. One will however observe later in this report that thread handling requires special knowledge, but in all cases less using Java.

2.5.3 Java performance

Before accepting Java as the perfect solution, it would make sense to point out the drawbacks. The most commonly cited one is performance. Indeed, since Java is an interpreted language, the performance should be much weaker. Surprisingly, Java performance is getting better and better and is now very close to C++. Indeed, if Java on one hand, has to translate the pseudo code into machine code, C++ programs have also to spend much time on operating system calls, especially on recent operating systems (Win32, UNIX). The performance of Java depends of course on several assumptions, which cannot be considered as a drawback anymore [2.45].

2.5.4 JCreator and JDB

Once the programming language elected, it was remaining to decide for an integrated development environment (IDE) or a combination of several developer’s tools. The retained software editing software, called JCreator, is provided by Xinox Software, and exists under two versions.

• JCreator Lite provides a simple text editor with basic syntax highlighting and embedded compilation and execution commands. In occupies a small disk space and is free to download and to use. It loads quickly and permits to pass rapidly from a source file to another. Finally it offers common project management functionalities.

• JCreator Pro implements the same basic functions than the Lite versions, but also provides some code completion mechanisms, and an integration of the Java Debugger. It is offered for 69 US dollars.

Even if, according to the cited Java advantages (exceptions, transparent memory use), most of the bugs and problems can be identified using a text logging mechanism, the use of the debugger will make sense in many cases. Furthermore, in several cases, especially in multi-threading applications, the debugger is the only way to identify problems, and solve them. Java offers a basic debugger allowing breakpoints, variable or threads stack consultation and step by step execution, among others. It can be used independently and command line controlled. One will nevertheless prefer to use it inside Jcreator Pro or using a free GUI.


Figure 2.6: JCreator workspace

2.5.5 Javadoc

One of the benefits of Java remains the format of its API’s (application programming interface) documentation. The properties of an object and its description are easy to consult, as are its members (fields, methods). As this documentation is available under the form of collection of html pages, hypertext links permit to navigate rapidly among the object descriptions.

In return for some time spent documenting code, a similar collection of html pages can be generated using the Javadoc program. Providing a full Javadoc documentation with a project allows future users to have a good overview of the project, and to consult the characteristics of an object without opening the source file.

3. Realisation

3.1 Planning - History

This work has been carried out over the course of 26 weeks. The time has been divided as follows:

• Weeks 1 to 4: Installation of the work environment, collection of interesting papers and publications about covered subjects, writing of a preliminary literature review. Java was chosen as the programming language for the project.

• Weeks 5 to 8: Writing of the basic Java objects for network representation, GUI, etc. The framework to support the agents (TCP/IP stack, messages, and synchronization) is also realised. First stones of the first organisation method are placed.

• Weeks 9 to 12: Working on the first method. Several tools have to be added (the Logger, the StatisticWatcher) and some big changes are made in the communication stack. First method returns successfully a valid list of links rapidly and with little memory space occupation.

• Weeks 13 to 15: Summer break • Weeks 16 to 17: Last workings on the first method, which is abandoned since it gives any

convergence property and valid results. • Weeks 18 to 21: The second method is thought and designed. Development goes pretty quick

since almost all objects already exist. • Weeks 22 to 23: The entire java code is consolidated, cleaned and commented. The Javadoc

documentation is generated. • Weeks 24 to 26: Redaction of the current report, organisation of the results. Some bugs are

identified and corrected, final changes in the package structure.

3.2 Package organisation and functions isolation

The project revolves around 4 subprojects: the network modelling, the graphical interface, the multi-agent algorithm and some secondary tools. Each subproject is sub-organised in different packages, as shown on the following figure:

38 Chapter 3 - Realisation

Figure 3.1: Package organisation (packages with * are empty and just regroup sub-packages)

These 4 parts have been written according to the isolation paradigm. Internal functions of the objects are, if possible, declared private to limit the access from external objects. Furthermore, many interfaces have been written to strengthen this isolation, and thereby avoid many bugs.

For example, the class thesis.network.elements.Node contains many accessible methods. Some of them are directly related to the graph topology ( addLink() , removeAllLinks()) even tough others more related to the graphical interface (paint(), inMyZone()). However, when considering a node as a place where an agent can run, the topology of the graph is supposed to be fixed and some specific methods (e.g. removeLink()) shall be inaccessible. For that reason the class Node implements the thesis.network.elements.interfaces.ElectricalNode interface. This interface defines five methods that permit only an access to the local topology present around the node.

The import statements present at the beginning of the classes only import:

• Basic java classes (especially the classes of the java.util package) • Classes of the thesis.tools package • Classes of the same subproject (thesis.gui, thesis.network, thesis.agents) • Interfaces of other subprojects

Exceptions however exist, for example the classes of the graphical interface need a full access to the element that they display. Import statement with asterisk (import java.util.*; imports all classes of the java.util package) were strictly avoided in the project, since their utilisation may conduce to importing undesired classes, and produce conflicts.

thesis.tools

thesis.agents thesis.agents.communications thesis.agents.interfaces

thesis.agents_new* thesis.agents_new.framework thesis.agents_new.algorithm

thesis.gui

thesis.network* thesis.network.properties

thesis.network.elements.interfaces thesis.network.elements

thesis Entry points of the program

Agents related packages

Graphical Interface

Network modelisation

Tools

Chapter 3 - Realisation 39

3.3 Network model’s subproject

Packages concerned: thesis.network.elements thesis.network.elements.interfaces thesis.network.properties

3.3.1 Object Oriented

The purpose of this sub-project is to represent the structure of a distribution network. Aside the representation of the Network itself in the Network class, this package naturally also contains a link representation and a node representation.

Figure 3.2: Organisation of classes used to model the networks

The inheritance function has been applied as often as possible. A consumer node is naturally an extension of a node. In order to allow future extensions, the classes AbstractPhysicalLink and AbstractPhysicalLinkRepresentative have been defined as a common reference to deal with links.

The classes BasicElectricalLink and BasicElectricalLinkRepresentative are presented as default implementations but other special classes can be added, in order to represent a link type more precisely (homopolar direct and inverse properties, installation cost, installation year or owner, etc).

In accordance with the isolation principle presented previously and speed up the algorithm, the ‘representative’ classes have been added alongside the link objects. To guarantee that agents will possess only knowledge about the local topology (the state of the current node and of the incident links), an additional layer had to be introduced over the link objects. In the fact, an AbstractPhysicalLink object keeps the reference of the Node objects present at the extremity, and a Node object keeps also the references of all the adjacent link objects. Thereby using only the AbstractPhysicalLink.getOtherNode() and Node.getLinks()methods, one might recursively reach any node or link of the network, and get the information over them, even without a

Network

Node

Element

AbstractPhysicalLink

ConsumerNode FeederNode BasicElectricalLink

AbstractPhysicalLinkRepresentative

BasicElectricalLinkRepresentative

contains 0:n

represents 1:1

ElementPropertySet

ElementProperty

owns 1:1

owns 0:n

AbstractClass Class inherit defines and make us of 0:n between 0 and n instances 1:1 exactly one


call to the Network object. Since the representative objects contain only the indexes of their extremities and not the whole references, the former locality property is guaranteed. Furthermore, the representative objects keep a reference to their associated link internally, but as transient fields, which means that those fields are neither serialised nor transmitted. Since an AbstractPhysicalLink, as said before, recursively owns the references to all the objects of the graph, the serialisation of such an object induces the serialisation of the whole network information. The use of the representative version with transient fields, will therefore drastically reduce the quantity of exchanged data.

Figure 3.3: Access to the describing objects means access to the whole graph

Figure 3.3b: The discribed interfaces limit that access

The interface LinkRepresentative provides a common reference for all representative objects. Note that not all of the methods defined in LinkRepresentative are implemented by default by AbstractPhysicalLinkRepresentative. If a later class extends this class, it must implement the missing methods (they are however implemented into the BasicElectricalLinkRepresentative class).

One will refer to the Javadoc documentation to learn more about the presented classes.

3.3.2 The thesis.network.properties package and the Element class

To provide a unified mechanism to attribute values or properties to objects, and to modify them easily (also see point 3.4.3), the superclass Element and the classes ElementProperty and ElementPropertySet have been written. The main idea is to place in each element a small database to store its parameters. The database is an ElementPropertySet, and each property is, obviously, an ElementProperty. The database supports three different types: integer, double and string. When adding a property to an element, the type must be set. Properties may also be mandatory or not (a mandatory property cannot be deleted), editable or not.

2

getConnectedLink(3)

3

getLinksNumber() getPosition()

getOtherNode(2)

getEndNode() getStartNode()

getLinksNumber() getPosition()

getConnectedLink(5)

5

getEndNode() getStartNode()

getOtherNode(3)

Node



Node

2

getConnectedLinkRepresentative(3)

getIndex()

getOtherNodeIndex(2)

getEndNodeIndex() getStartNodeIndex()

ElectricalNode


3

Chapter 3 - Realisation 41 For this reason, all inheriting classes from Element must define a getDescription() method. When a new instance is created, a mandatory and un-editable property containing the returned value of getDescription() is created and added to the database. This solution of storing parameters is combinable with the get-set paradigm. For example, the class ConsumerNode defines two methods to access transparently the database about the consumption value:

public int getConsumption() { return getProperty(CONSUMPTIONPROPERTY). getInt(); } public void setConsumption(double i) { set(CONSUMPTIONPROPERTY,i); }

The constant CONSUMPTIONPROPERTY is the key of the consumption value of a consumer in the database. The method getProperty(java.lang.String key) and set(String key, int i) is defined in Element.

3.3.3 Serialisation

A modelled network must be able to be saved on disk and reloaded later, in order to reuse it or compare it to others. The class Network defines the loadNetwork(java.io.File f) and saveNetwork(java.io.File f) methods that provide an embedded writing/reading process. Since java’s default serialisation mechanism is used, all classes of objects being susceptible to appear in a network (more or less all classes of the thesis.network.elements package) must implement the java.io.Serializable interface.

All the classes of the thesis.network.elements package also define a serialVersionUID field:

private static final long serialVersionUID = 0x0000000000000001;

This number defines the version of the file. If an object is written using a class that defines a number A, and then the object is read using the same class but with a different number than A, the reading mechanism will be interrupted and an exception will be thrown. This number is always defined. If it is not explicitly done, the java compiler defines one by hashing the class signature (number of methods, name of the methods, arguments, fields, etc). To avoid compatibility problems, it is preferable to define this number and change it manually when important changes have been made to the class.

3.3.4 GUI interaction

Three interfaces model three properties related to the GUI. A Paintable object may be graphically represented and must provide a paint() method, a Clickable object is subject to receive clicks and must then provide an inMyZone() method, and finally nodes are Movable and may change of position.

3.3.5 Agents interaction

The Agentable (valid for nodes to which an agent will be created), Activable (a link that can be switched on or off), LinkRepresentative, ElectricalNode, Consumer and Injector represent the interface with the agent world.


Figure 3.4: Active and LinkRepresentative interfaces are implemented by link-type classes, as


Figure 3.5: Agentable, ElectricalNode, Consumer and Injector interfaces are implemented by node-type classes

3.4 Graphic User Interface’s package

Packages concerned: thesis.gui

3.4.1 A single sketch is worth a thousand words

The implicit graphical nature of a network stays into the mathematical term to define it: a graph. Though networks may be represented by matrices or other methods, the graphical representation

Activable

isActive()

setActive(boolean b) switchIt()


LinkRepresentative

getCapacity()

getCurrentPower() getEndNodeIndex()

getLength()

getRate() getScore()

getStartNodeIndex()

getOtherNodeIndex()

isElectrified()

setElectrified() setCurrentPower()

Agentable

getIndex()

getLinksRepresentatives() getScore()

setScore(double d)

ElectricalNode

getActiveLinksRepresentatives()

getConnectedLinksRepresentatives() getElectrifiedLinksRepresentatives()

getIndex(double d)

getLinksRepresentatives()

Consumer

Injector

getInjection()

getMaxInjection() getRate()

isSurcharged()

setInjection(int i)

ConsumerNode

FeederNode

Node

getConsumption()

Chapter 3 - Realisation 43 remains the most intuitive for the human eye. According to that observation, it has been decided to include a graphical interface in this project.

First part of the GUI: the network editor, which allows the creation of a simple representation of a network in a few clicks.

Figure 3.6: Snapshot of the network editor panel

Using colour, it is further possible to easily illustrate the state of a network, for example representing the overcharged nodes in red (fig. 3.6).

Next to the zone where the networks are represented, the main window provides a menu bar and two toolbars. While the upper toolbar contains action launching buttons, the second includes tools that must be first activated (only one at the same time) and then that will interacts with the design zone at the position of the cursor.

3.4.2 Classical file functions

Graphical interface is also used to simplify the load/save process. The class thesis.gui.NetworkFileChooser allows selection of a saving location or identification of a file to load by means of graphical directory representations and mouse clicks.

Figure 3.7: The NetworkFileChooser's dialog box

3.4.3 Properties editing

In relation to point 3.3.2, the GUI provides a tool called ‘Set information’ in the second toolbar. When this tool is called, a new window appears by clicking on an object present in the design zone, displaying the list of the properties of the object (using the informations() method of the Clickable interface). This provides a unique way to consult or change the parameters of any object.


The classes NetworkInformationInputDialog and NewInformationDialog, which are responsible for the display and management of the properties, display the missing properties in red, prevent the deletion of mandatory ones, and allow the creation of new properties. Editable properties can be changed by clicking on the field, as long as the new value is compatible to the property type.

Figure 3.8: The properties editor. An invalid value has been entered, notified by a dialog box.

3.4.4 Logging frame

To simplify the debugging process or the understanding of the program, the logging frame can be displayed or hidden. See point 3.5.4 for more details.

3.5 Multi-agent framework

Packages concerned: thesis.agents thesis.agents_new.framework thesis.tools

3.5.1 Communication stack

Agents have to be able to share or exchange information amongst themselves, which the communication stack is responsible for. Note first of all that the retained paradigm to exchange information, in this project, is ‘message passing’. Two objects implement the communication: the CommunicationAgent/CommunicationStub and the Neighbour/Neighbour_NewVersion objects (two implementations exist, since two different methods were developed. Refer to subsections 3.6 and 3.7).

First, the CommunicationAgent object is responsible for the server part of the communication, in the sense that it will launch a small program (a thread) that will listen for incoming connections (from clients). When this small program detects that somebody tries to connect, it ‘picks up’, establishes the connection, reads the message and ‘hangs up’ (run() method in CommuncationAgent, runAcceptingConnectionProcedure() method in CommunicationStub). Depending on the case, it either stores the message in a list and waits for the main agent to reclaim the ‘mail’, or directly contacts the main agent and tells him that a new message has arrived. Secondly, the CommunicationAgent manages a list of Neighbour objects.

A Neighbour object represents a neighbouring agent to whom the current agent will eventually speak. It contains the information about contacting the represented remote agent, and will carry on the connection procedure: compose the number (address), wait until the other party picks up, establish the

Chapter 3 - Realisation 45 connection etc (methods commitMessages() in Neighbour, sendMessage() in Neighbour_NewVersion). A Neighbour object may also, in certain cases, be used as a container for information: indeed, if it represents a remote agent, it may also contain some data that the main agent knows about him.

Figure 3.9: Agents send messages through a CommunicationStub

Neighbour objects are created using the information contained in the link (a LogicalLink or a LinkRepresentative implementation) that exist between the running agent and the represented remote one. In the simplest case, when all agents are running on the same machine, the address of the remote agent is simply defined using indexes. An agent using the index m will listen on the port (Constants.CLIENT_START_PORT_NUMBER + m) (see the Constants class). The index of the distant agent is extracted from the link.

All communications are made using TCP/IP. It is always assumed that all the agents are running on the same machine (IP = “localhost”). The communication stack is, however, implemented capable of using different addresses.

3.5.2 Used messages, protocol

The transmission protocol has been simplified to the maximum. After the connection has been established, the sender writes one byte over the channel: its index. Then the two sides setup an object stream over the channel. Finally, the sender writes one and only one object over the stream. Object streams are one of the very useful Java functionalities. Just as for the saving/loading process, it allows to directly send a whole object, without having to describe how the object should be written.

To simplify the reception process, it will be assumed that only objects of classes dedicated to communication are sent. The classes Message and AbstractMessage exist for that purpose. A message object contains the index of the sender, the index or the receiver, a type variable, and a data field. Since the data field can contain any serializable object, messages may contain just about anything and should never be a restriction. Messages are considered at this point as blocks, whatever they may contain.

3.5.3 Thread manager

The NetworkOrganisor and NetworkOrganisor_NewVersion are responsible of the organisation of all the threads. Even if the agents are completely or quasi-completely independent, one has to, at the very least in the beginning, take the graph, instantiate an agent for each node, and start it. The organiser deals with this task and also with the necessity to know when the algorithm is terminated, in order to display the results, for example.

Agent A

Agent B

Neighbour Neighbour

Agent X

Agent E

Agent E

Agent A

CommunicationStub CommunicationStub


While the NetworkOrganisor, written for the first version of the algorithm, proposes a synchronous organisation, the NetworkOrganisor_NewVersion works asynchronously. In the first version, a unique thread will ‘visit’ each agent separately. The received mail of each visited agent is read, some actions are done according to it and finally some new messages are created and temporarily stored. As soon as all agents have been visited, all stored messaged are sent. Agents are not really running simultaneously, however, as said before, unless using a separate machine for each agent, various agents can not ‘physically’ run simultaneously, since a single CPU cannot execute more than one thread concurrently, and thereby this methodology does not change many things.

Figure 3.10: The main thread visits each agent

The end of the algorithm is easy to detect in the synchronous case: if the visiting thread does not send any message for two consecutive cycles, the ‘energy’ of the system is null and no other message will ever been sent (since messages are sent in reaction to other ones). In the asynchronous case, the end of the algorithm is more difficult to detect. The idea is to look at a thread’s activity. If all threads are idle for a certain amount of time, the process is declared terminated. As one will see in the results section, only and incomplete solution to this problem has been found.

At the end of the process, the caller (e.g. the GUI) can collect the results of the process by accessing the NetworkOrganisor and NetworkOrganisor_NewVersion objects.

3.5.4 The logger

Generally, logging (displaying or inscription of some information related to the execution of a program) consists in placing display commands in the code (in java, System.out.println("text to log"), in C++ printf("text to log")), execute the program, and analyse its behaviour by reading on the console or in a dedicated text-file, the displayed information. In the present case, the simultaneous presence of several threads complicates greatly the consultation of the logs, since information related to each agent must be extracted separately to be correctly understood. This is the mission of the logger mechanism present into the object thesis.tools.Logger.

Organiser agent 0 agent 1 agent n

1 cycle

Chapter 3 - Realisation 47 This final (non-instanciable) object provides several static methods, grouped in two categories:

• The logging methods themselves, similar to System.out.println("text to log")), for example:

printmedium( java.lang.String string, java.lang.Object o1, java.lang.Object o2)

• Some extra control methods

The first method, other than the character string containing the text to display, receives two further parameters. Those parameters will be used to build a key, and this key be used to store the text in a set, with all other logging information having the same key. The first object can be for example the class of the caller and the second object its index. In the first method, the first object is used to represent the layer and the second the index. Assuming that two agents never share the same index and layer, each agent will have its own logging category.

Besides the two extra parameters, the method’s name is printmedium(). A look in the documentation will show the existence of two printlow() and printhigh() methods, which allow logging levels. Depending on some settings (defined in a property file), only logs defined with high level (logs placed in the code using the printhigh() method), or only those with medium and high levels, should be displayed. Thereby, when running a small test on a small network, all levels should be activated. On the contrary, when running a simulation on a big network, only the medium or high levels should be used, to prevent the creation of too large an output file.

Other methods of the class permit the retrieving of the logging information, erasing, or redefinition of the file’s name where data should be written. Furthermore, the method registerLoggingPanel() will associate the Logger to a special frame. When the flushLog() method is afterwards called, all the logging information will be displayed in the registered frame.

Figure 3.11: The logger window

Property file

The before using the Logger, an initialisation method has to be called: loadProperties(File f). This refers to a property file typically containing this information:

loggingLow true - if low level should be processed or not loggingMedium true - if medium level should be processed or not loggingHigh true - if high level should be processed or not


useTime false - if time information must be displayed on each line toStdOutput true - if text should also be displayed on the command line threadName false - if the thread’s name must figure on the line outputFile logging.out - filename of the output file

Logging text will be displayed on the console and written in the output file according to those preferences.

3.6 First design method

3.6.1 Leader election and clustering

Using the ‘base’ classes described in the previous points, it was possible to design and develop the algorithm itself. As the project was long, some preliminary decisions were taken arbitrarily at the beginning, for example the synchronicity. The questions “where an agent should be placed?” or “what should be represented by an agent?” were important but were missing clear answers. As a first attempt, it was decided to try to split the problem in smaller sub-problems.

Organisation of a network into smaller sub elements is not a new topic. It appears for example in some peer-to-peer networks. The deal consists in building a hierarchic organisation over a set of all equal elements. This uses the concepts of leader election (choose one or more nodes which will assume leader functions, and attribute one unique leader to each node in the graph) and of clustering (more or less apply the leader election paradigm recursively). The first objective has been therefore the implementation of a recursive leader election mechanism, which will return, for a given graph, a hierarchic organisation made of masters and subordinates, at different levels.

3.6.2 Ant inspired “travelling salesman problem” algorithm

Given a pure hierarchic structure, where except for one element (the root - the big chief), each element has a leader, a graphical representation of such a structure forms a complete and acyclic graph, exactly like a configuration of a distribution network. According to this similarity, why not try to find a hierarchic organisation formed and based on electrical criteria? Imagine a system in which each node in the network, equipped with an agent, would communicate with its neighbours, choose one of them as master according to a ‘quality’ factor, or propose itself as master for some of its neighbours (the quality factor will first be defined as a ‘representation of the benefits to have a given node in a master position’). A system where, at the end, a whole hierarchic organisation takes place, with the node defining the best quality factor at the top. The presented method proposes to realise such a system.

The main question is, however, “how to estimate this quality factor?” For example by constituting and evaluating many organisations. If one possible solution gives a good result, nodes defined as masters in the solution will see their quality estimator (or score) being up-reviewed. This concept of reintroducing some results as a part of the problem, called reinforcement, is not new in the simulation field and is used for traffic simulations. The ants inspired algorithms applied to the ‘travelling salesman problem’ also makes extensive use of it. Let us see how to do it.

Chapter 3 - Realisation 49 3.6.3 Implementation

Packages concerned: thesis.agents

General description

At the beginning of an iteration, an agent is started on each node of the network. Each of those agents first sends a welcome message to all its neighbours. It then exchanges its score with them and elects its master according to the different received scores: the neighbour with the greater score (and with the smaller index in case of equality) or itself, if it has the best score. It will finally communicate the result of its choice to all neighbours.

Figure 3.12: Each agent elects a leader

This first stage provides a beginning of organisation, but generally it will not be sufficient, since more than one single node may have decided to choose itself as master. In order to connect the ‘islands’ amongst themselves, a second stage of the algorithm will be started. The ‘self-master’ nodes will ask the agent’s organiser to instantiate and start a new agent on the same node, but defined on a higher layer. This layer will thereby be constituted of several nodes that run the same algorithm again to connect to each another. Furthermore, it contains only nodes and no links.

Figure 3.13: ‘self-master’ agents create new agents on the upper layer and find routes to others.

The upper layer agents will consequently ask to the agents present of the same node but on the lower layer, to find routes that interconnect the zones. When a route is identified, the lower agent passes it to the upper agent, and from that point on, a new link exists in the upper layer.

6

8

10

7

4

3

5

9

0

2

1 11

Layer 0

6

8

10

7

4

3

5

9

0

2

1 11

8

4

3 0

Layer 0

Layer 1


Figure 3.14: Node 3 is alone on the layer 2

Using this method recursively, there will come a moment where there is one and only node on the nth layer (fig 3.14), on whom all other nodes of the lower layers will depend. A list of links can be established, and the iteration is done (fig. 3.15).

Figure 3.15: Using the hierarchical organisation, a list of links is set up on the original layer

Using the provided list of links, a configuration will be set up and presented to a load-flow algorithm. With the results of the load-flow, the scores of the graph’s elements will be revised. This constitutes the end of a full cycle and the system is ready to iterate once again until it ends in an acceptable solution.

8

4

3 0

Layer 1

3

Layer 2

11

6

8

10

7

4

3

5

9

0

2

1 11

8

4

3 0

Layer 0

Layer 1

3

Layer 2

Chapter 3 - Realisation 51

Figure 3.16: The three stages of a full cycle

States

The implementation of the algorithm is written into the LocalNodeAgent class. An instance of that class must be created for each agent, independently of the layer. At each step (remember that the algorithm is synchronous), depending on the current state of the machine, several actions are executed and the next state is defined. States 0 and 1 are related to the initialisation, 2 and 3 to the normal operation process, 4 and 5 to the finalisation process.

The LogicalLink interface

Even if a level of abstraction is already defined by the representative class, the presence in the algorithm of some virtual links (links that connect an upper agent and its lower counterpart, for example) needed another kind of abstraction. The LogicalLink interface (and its multiple implementations) presents a global abstraction and defines for each link the signature (the mark) of the destination, the manner to reach it (typically useful with composed links) and other functionalities. It permits the easy creation of a Neighbour object.

The Configuration class

Agents, when announcing the identity of their master, also broadcast information about the part of the graph they dominate. The Configuration class provides several methods in order to represent this dominated part with a simple character string.

The reader will report to the Javadoc documentation for more details. Results and comments about this method are presented in section 4.

3.7 Second design option

3.7.1 Learning from mistakes in first design

Without presenting too early the conclusion about the first method, two months before the deadline of the project, the first method presented in section 3.6 was not yielding the expected results. Even if all possibilities of the method had not been exhaustively explored, it was assumed, possibly wrongly (see conclusion), that it would make more sense to try another concept. Above all, it was probably the last possible moment to branch off.

Links set

constitution Loadflow

computation Score award


The first stones of the second method were laid by learning from the first one. First of all, it has been seen that even if a distribution network shares some common properties with a mathematical graph, it can not be assimilated to it, due to the diversity of its elements (consumers, feeders, links, etc). This diversity should be taken in account even in the first stages of a method’s development. Secondly, even if the concept of splitting both the optimisation problem and the work to solve it should remain a key, a partitioning into too fine pieces will induce other problems: a characteristic of one element at one side of the network may be responsible for a problem located on the other side.

3.7.2 Feeders as masters

The new method is based on one simple observation: a distribution network in exploitation is already split in zones, where each zone is attached to a feeder and independent of the others. Why, in this case, not model the division of the problem on this evidence and consider feeders as masters of the zone they supply? And let them take the whole initiative in order to improve the structure of the network?

3.7.3 Main concept: charge transfer

Assuming no response to the previous two questions, a ‘charge transfer’ concept has been devised: after a first stage destined to map the connected zone, a feeder will eventually notice that the present configuration brings him to an overloaded state, or that the present configuration accepts him at capacity. In those cases, it will initiate a dialog with the neighbouring zones (and thus feeders) in order to exchange some consumers or some consumer groups. As it is assumed that communications take place only between two connected nodes, feeders cannot contact directly other ones. Communications must then be relayed by intermediate nodes.

A transfer of a charge in the network is always made as described on figure 3.17. Since each non-feeder node has one and only one active connected link in direction of is feeder (name it the uplink), by switching off this link and activating another one (if such exists), the feeding of the node (and eventually its subpart) is changed. Depending on the situation, the recently activated link might lead to the creation of another zone. In this case an exchange between two zones has been realised. Otherwise, the charge stays in the same zone, but the internal organisation of the zone changed.

Figure 3.17: Changes consist in switching the uplink

3.7.4 The procedures

Contrary to the first presented method, the new one relies on an asynchronous paradigm. The algorithm is build of procedures, which consist of:

• Transmitting to all children the order to start the same procedure • Eventually sending, via inactive links, a ‘question’ • Waiting until responses for all sent messages arrive • Transmitting a response to father

F

F

C

Chapter 3 - Realisation 53 When a feeder initiates a procedure, it will provoke a sort of chain reaction, where successively each ‘generation’ will be awoken and equally enter into the procedure. This forms the ‘forward’ part. At the end of the propagation mechanism, many nodes of the zone will stay in idle mode, waiting for responses (from children or other zones neighbours). The responses will progressively reach nodes waiting for them, and each generation will successively be able to respond to its father, until the final response is transmitted to the feeder (‘backtracking’ part). According to the content of this response, the feeder might decide for a change, and inform personally the node concerned by the change. Figure 3.18 tries to summarise and illustrate the principle.

Figure 3.18: Overview of the principle

When a feeder gets the final response, it contains a list of possible changes given the present topology (the list can be empty). Each change is basically identified by the index of the transferred node, the index of the providing one and of the receiving one, plus a flag indicating if the other concerned feeder agrees with it. The initiator will have to select one change among the set of agreed changes (if any), and according to the dynamic programming principle, select the most profitable one. Only changes that globally increase the quality of the network are committed, in order to avoid infinitive cycling (given two configuration A and B, B being globally more profitable than A, the algorithm will probably pass from A to B but never return to A from B: no cycle).

Note that contrary to the first one, this method uses an asynchronous algorithm. Agents are generally in a sleep mode and awoken by an event, in our case the reception of a message, or, for the feeders, an external event. When an agent is awakening, it will achieve ‘as quick as possible’ the work related to the reception of the message and go back to its sleeping mode again.

3.7.5 Problems with asynchronous messaging

This asynchronous property, which can appear logic and easier to apply than the synchronous one (no need of external ‘organiser’ to orchestrate and synchronise the agents), poses several problems. The simplest one is a great classic in distributed systems: deadlocks. It can be illustrated in a very simple example. Given three agents (or more generally processes) A, B and C, lets assume that A is contacting B to send him a message. B is however busy: it has just received a message from C and is reading it. B, alerted by some news received in the message, decides to contact A to also inform him.

B tries to contact A, which is busy trying to contact B. A waits for B and B waits for A. Both are trapped in two different places: they will never meet. The system is considered as blocked (deadlocked) since only an external event may interrupt the waiting time of the two nodes. This problem is pretty easy to solve, by defining for each agent a ‘postman’, who will take care of the

1

1

1 1 2

2

2 3

3

3

4

4

4

Zone borders

Procedure border

Feeders

Intermediate nodes or comsumers


communications and ‘take the message’. See the point 3.7.6 for more details. It induces, however, more difficulties.

Another problem encountered, also a great classic but this time related to databases, can be explained with the following example: an airline company is selling tickets over the internet. For a given flight, the plane is full except one single seat. Two customers, A and B, are interested in buying a ticket for the corresponding flight. A arrives first, chooses the seat, and begins to fill the forms. B arrives and tries to select the same flight. The system tells B that the flight is full. In the meantime, A has reached the final step of the reservation, where the price is displayed and where the confirmation button should be pressed. Disgusted by an excessive price, customer A changes his mind and renounces the ticket. But nothing informs B that a seat is actually available again. Because selling too many tickets may have bad consequences, it is preferable to sell zero.

A similar problem appears in the present case. In order to respect the dynamic programming principle (and avoid a cycle behaviour), only profitable changes must be committed. In several cases, however, the combination of two independent profitable changes may bring the network to a worse state. Fig 3.19 illustrates a possible case. Feeder 1 is overloaded while feeder 2 has free capacity, and their two zones are somewhere sharing a common border. Some consumers of zone 1 should be transferred to zone 2. Border nodes A and B might be transferred, but the transfer of both of them will bring feeder 2 in an overloaded state. Furthermore, if feeder 2 is globally less powerful than feeder 1, the overload of feeder 2, according to the transfer of both A and B, will be more important that of feeder 1. In consequence, even if the two changes are independently accepted by feeder 2, feeder 1 should commit only one of them. For this reason, a procedure will always lead to at the most one change.

Figure 3.19: Two changes may bring the network to a worse state

Moreover, one can imagine the following situation: on one hand feeder 1 will contact feeder 2 in order to give it a consumer; on the other hand, feeder 2 will contact feeder 1, telling him that it has capacity and that a consumer may be transferred. There are in this situation two separate procedures, and each of them can lead to a single change in the configuration. If, for a given reason, they independently choose to transfer both nodes A and B, the same problem appears again.

This forces the definition of priorities among the procedures. Or, as it has been done in the implementation, to isolate the procedures by defining a time for ‘request’ exchanges (an overloaded feeder asks the neighbouring feeder to take a part of its zone), and for ‘offer’ exchanges (a feeder with capacity offers its neighbouring feeders to transfer some consumers).

A final problem must be presented: as said before, when running a procedure, nodes will stay some time in a ‘wait stage’, waiting for some responses. What should do a node when, in a procedure, it

Maximal injection: 15 Current injection: 10

Maximal injection: 20 Current injection: 25 Overload: 5 – 25%

Maximal injection: 15 Current injection: 20 Overload: 5 – 33%


Chapter 3 - Realisation 55 receives a zone change message? Is the proposed change compatible with a possible change that would follow the current executed procedure? An idea would be to wait until the end of the current procedure before processing the external messages. This solution is however to be avoided, since it may also lead to a deadlock situation: both sides of a network wait infinitely for responses that are precisely blocked on both sides, because both sides are waiting for the end of the procedure to terminate.

To avoid this problem, one may define an ‘ask later again’ mechanism. When a zone is in a procedure, it will systematically respond that it is busy and cannot respond for the moment. When a node, in a procedure, receives an ‘ask later’ message, it aborts its own procedure and tells its father that procedure must be aborted due to the busy state of the other node. By doing that, it will be free again to respond to messages of the other zone. This solution works but is inelegant. When a feeder node receives a message telling him that current procedure has been aborted, it just starts a new one again. Depending on the distance between the feeder and the ‘border’, the time between the successive tasks may be very short or very long. On the other side, the time needed by the procedure to finish also depends on the size of the problem. Fig 3.20 shows an example where this situation may induce a feeder to continuously annoy the other zone, preventing it to terminate efficiently its procedure, and consuming many CPU time doing that. See chapter 4 and 5 for proposed solutions to this problem.

Figure 3.20: Feeder 2 annoys continuously feeder 1, which has to wait the end of its long procedure

3.7.6 Implementation

Packages concerned: thesis.agents_new.algorithm

Starting of agent, end of algorithm detection

Before analysing the implementation of the algorithm itself, it would make sense to review again the NetworkOrganiser_NewVersion class. Like the NetworkOrganiser, the method organiseNetworkInternal(Network net) is responsible for the creation of the agents and their respective starts. The difference appears at the end of algorithm detection. Indeed, instead of analysing the number of sent messages, it has been preferred to use a mechanism of signals and of monitors, which come integrated with Java.

The implemented protocol inherits from AgentStub (see next section) a static method called getMonitor(), which just returns am empty object, used as a baton. Without entering in the specific subject of real-time programming in Java, one will just say that using the synchronized keyword, it is possible to guarantee that a portion of code or one of many portions of code is always executed by almost one thread (mutual exclusion). Using this principle, let us define a sign in/sign off mechanism: when a thread becomes active (not waiting for a message anymore), it calls the method signIn()(that increments the AgentStub.activeThreads variable). Before returning to the wait state, it calls the method signOff() (decrementation). Because the

Feeders

Intermediate nodes or comsumers

Existing procedure

New procedure

Zone 1

Zone 2


AgentStub.activeThreads variable is protected by an exclusion mechanism (only one thread at the same time can hold the token), it always contains the right value of the presently active thread. Since some other functionalities are also available aside from the mutual exclusion, this mechanism is called a monitor.

When a thread signs off (calling signOff()) it also checks if it is the last one active. If this is the case, and if no messages are being sent, nothing else should happen and the algorithm is finished. The calling thread can be woken up.

Changes to communication stack - the AgentStub and CommunicationStub classes

To solve the deadlock problem enounced previously, the CommunicationStub (equivalent to CommunicationAgent in the first method) has been modified. There are now two running threads per node, one dedicated to the reception of the messages, and one for their processing. The two threads communicate using a monitor-controlled buffer, implemented with a LinkedList and used in a First-in First-out queue.

With the implementation of all the algorithm’s functions, the class LocalNodeAgent_NewVersion had become huge and difficult to debug. Consequently, it has been decided to regroup all the basic functions into a super class, called AgentStub. It contains the mechanism related to the sign-in/sign-off, plus some extra ‘send’ method that permits to send a message only to the active adjacent links.

Main algorithm class - The LocalNodeAgent_NewVersion class

This big class is the core of the presented solution. It is basically built of 6 subparts:

• The constructors, the start(), connect(), launch_algorithm() methods that are used when a new instance is created

• The start[...]Procedure() methods that initiate the different procedures and create the respective objects.

• The receiveMessage(Message_NewVersion m) method • Some dedicated methods for precise actions. For example, the

respondToZoneChangeOffer() method is responsible of agreeing or disagreeing a change proposition coming from another feeder (“I propose you to transfer to me node 5” or “I propose to transfer you node 4”).

• Some tools methods

When the start method is called, the agent first sets up the communication stack, calling the connect() method. When it is done, the non-feeder nodes will stay in waiting state, the feeder node will initiate an explore procedure, in order to know the state of their zones (one will read later exactly how the procedure works). Depending on the result of the exploration, and of the mode, feeders may initiate another procedure.

Modes

To deal with the presented problem of two simultaneous changes due to two different procedures, a mode of functioning can be used when instantiating the LocalNodeAgent_NewVersion objects. This must be provided as parameter to the constructor and may take one of the following values:

LocalNodeAgent_NewVersion.REQUEST - limit to request procedures, only overloaded feeders ask others to transfer charges

Chapter 3 - Realisation 57 LocalNodeAgent_NewVersion.OFFER - limit to offer procedures, only non-

overloaded feeders ask others if they want to give charges

LocalNodeAgent_NewVersion.REORG - limit to reorganisation procedures, feeders only examine the internal configuration in order to optimise it

LocalNodeAgent_NewVersion.ALL - permit all the procedures at the same time

Procedure objects

The procedure objects are the central concept of the code organisation of this package. As said before, agents ‘enter’ in a procedure, and for this reason procedures can be considered as states. The class LocalNodeAgent_NewVersion defines a field currentProcedure initialised to null.

Procedure currentProcedure = null;

When an agent enters into a procedure, it has to instantiate it and to assign it to its currentProcedure field. The class Procedure is only a common definition and cannot be instantiated (abstract class). Refer to Javadoc documentation for which methods Procedure objects must implement [3.1].

Two of these methods are initProcedure() and receiveMessage(). The messages to the neighbours (except the father) are sent in the first one. The number of sent message is notated conscientiously since it correspond to the number of responses that must been received before responding to the father. This method may conduce directly to the (local) end of the procedure, when no messages are sent and no responses are awaited. The receiveMessage() method processes the receive message in function of the present procedure. One might be surprised to discover another receiveMessage() method, since the LocalNodeAgent_NewVersion class already defines a similar one. However, messages must sometimes be processed differently, depending on the state of the agent: outside any procedure, or in one.

Dispatching of the messages

Let us have a look again over the receiveMessage() method defined in the LocalNodeAgent_NewVersion class. The first part defines a little synchronisation mechanism. The second part processes certain types of messages that are always processed the same way, whether the agent is in a procedure or not. After those two parts, the following statement appears:

if (currentProcedure != null) { ProcedureResult response = currentProcedure.receiveMessage(m); }

This means that if a procedure (represented by the currentProcedure variable) exists, the message is processed by a procedure object.

Depending on its current state and on the type of message, a message should at the end be processed outside of the procedure, like a normal message. In another case, the reception of the message can provoke the termination of the procedure: if it was the last awaited response for example. A ProcedureResult object, which is returned by the methods receiveMessage() and initProcedure(), deals with the different enumerated situations. By calling method toTerminate() of this object, the agent knows if the procedure that returned this object shall be


terminated. By calling toContinue() method, the agent knows if the message must continue to be analysed or must be discarded. By calling the invokeTasks(), a certain number of tasks relative to procedure termination are executed. One will then see the following pattern into the LocalNodeAgent_NewVersion class (method receiveMessage()):

if (currentProcedure != null) { ProcedureResult response = currentProcedure.receiveMessage(m); if (response.toTerminate()) { currentProcedure = null; response.invokeTasks(); } if (!(response.toContinue())) {

return; } }

Figure 3.21: Processing of one received message, among the different classes

In reaction to the terminated state of the procedure, the ‘slot’ is freed (which causes the procedure to be recycled), then the tasks of the response are executed. In reaction of the continue state, the method will return directly (without continuing to process the message) or continue normally (fig. 3.21).

Planned tasks

When calling the invokeTasks() method, tasks previously planned in the methods receiveMessage() and initProcedure() are run. Why not execute these tasks directly in those methods? Sometimes, the termination of an exploration procedure at the level of a feeder may launch a new procedure (request of offer). However, since an agent can be in one procedure at most in the same time, the agent must first get out of the existing procedure before starting a new one.

Process

message in the current

class

Terminate current

procedure Invoke tasks

Process message in procedure

class

terminate flag

continue flag

Message physically End of reception

false

false

false

false

true

true

true

true

CommunicationStub

LocalNodeAgent_NewVersion

Procedure

If priority

type

If a procedure

exists

Chapter 3 - Realisation 59 To assign a new task to a response, this following pattern is used:

PlannedTask[] task = new PlannedTask[1]; task[0] = new PlannedTask( "startTransferOfferProcedure", lna, new Object[]{});

Generally tasks are defined in an array, which is then first initialised. The constructor of the PlannedTask object takes three parameters: the name of the method to call, the object on which the following method has to be called, and the arguments that must be addressed to the called method. In the present case, the startTransferOfferProcedure() method will be called on the lna object (= LocalNodeAgent_NewVersion) with zero arguments. This typical example illustrates what has been said before: to start a new procedure (an offer one in this case) the last one must be terminated. Remark moreover that all the start[..]Procedure methods are declared twice in LocalNodeAgent_NewVersion, once with an argument, once without. The declarations without arguments are present to simplify the construction of task running those methods.

A global view of the procedures

Until this point the procedures have been described according a ‘local’ point of view. Let us change focus to global working, by analysing the organisation of the messages. The class thesis.agents_new.algorithm.Message, an extension of the abstract AbstractMessage class, defines several message types. Types are used to identify messages and to differentiate them.

When a feeder decides to initiate a procedure, it creates a Communication object. In this object, several values will be defined, depending on the procedure (each procedure defines a separate implementation of the Communication abstract class). Then this Communication object, included as the data field of the Message class, is sent to its children, which make a copy of it and send it down again to the next descendant, etc (fig. 3.22). Each procedure defines also a message type for those first communications (table 3.1)

table 3.1 ExploreProcedure NETWORK_EXPLORE TransferRequestProcedure TRANSFER_REQUEST TransferOfferProcedure TRANSFER_OFFER InternalReorganisationProcedure REORGANISATION_REQUEST


Figure 3.22: First phase of the ‘forward’ part

When the border of the zone is reached, the explore procedure simply recursively retrieves the topological information. The offer, request and reorganisation procedures will on the contrary send other messages across the border of the zone. To do so, another object is used: the ChangeProposition object (another type of message is also used, see table 3.2). This ChangeProposition contains many fields that are progressively filled during the journey of the message. The first part of this journey consists to get back up to the feeder concerned by the exchange. Once the border is crossed, the message is ‘escorted’ (forwarded) to the root of the other zone, and the indices of the visited nodes are saved (fig. 3.23).

table 3.2 TransferRequestProcedure ASK_FOR_ZONE_CHANGE_REQUEST TransferOfferProcedure ASK_FOR_ZONE_CHANGE_OFFER InternalReorganisationProcedure ASK_FOR_REORGANISATION

Figure 3.23: Second phase of the ‘forward’ part

When ChangeProposition reaches the other feeder concerned by the exchange, this other feeder will set the agree flag, fill the last data fields and return it to its initiator (inside a third type of message, see table 3.3). To get back in its original zone, the indices of the nodes previously visited are

2 3

6 5 9

8

Zone 1

Zone 0

Zone 2

0

1

Type: TRANFER_REQUEST Data: TransferRequestCommunication

complete = false proposals = null givingFeederIndex = 0 ...


4

6 10 9

11

Type: ASK_FOR_ZONE_CHANGE_REQUEST Data: ChangeProposition

powerQuantityTransfered = 5 transferedNodeIndex = 6 receivingNodeIndex = 9 givingNodeIndex = 3 path = [6] …

Type: ASK_FOR_ZONE_CHANGE_REQUEST Data: ChangeProposition

powerQuantityTransfered = 5 path = [6 9 10] …

Maximal injection: 15 Current injection: 10 Zone 1

Zone 2

Chapter 3 - Realisation 61 used (fig. 3.24). As the message reaches its original ‘zone’ again, its contained ChangeProposition object is included in Communication object as a ‘proposal’.

table 3.3 ZONE_CHANGE_REASK_LATER ZONE_CHANGE_ACCEPTED All procedures except ExploreProcedure ZONE_CHANGE_REFUSED

Figure 3.24: First phase of the ‘backward’ part

During the last step of the operation, when a border node has received all the awaited responses, the Communication object containing the various propositions is passed to the father (using messages of table 3.4). At each level, proposals are aggregated and finally one unique Communication object reaches the initiating feeder (fig. 3.25), which will analyse them, select the best one, and eventually commit it.

table 3.4 ExploreProcedure NETWORK_EXPLORE_RESPONSE TransferRequestProcedure TRANSFER_REQUEST_RESPONSE TransferOfferProcedure TRANSFER_OFFER_RESPONSE InternalReorganisationProcedure REORGANISATION_REQUEST_RESPONSE

6 10 9

11

Type: ZONE_CHANGE_ACCEPTED Data: ChangeProposition

path = [] …

Type: ZONE_CHANGE_ACCEPTED Data: ChangeProposition

path = [6 9 10] offeredPower = 5 agreed = true toForward = true …

pendingPowerRequestSum = 5 Zone 1

Zone 2


Figure 3.25: Second phase of the ‘backward’ part

Those four stages of the procedure are followed by the commitment of a change. This is however realised outside of any procedure. When a proposition induces a change to be committed, a COMMIT_ZONE_CHANGE message is sent to this node. When a proposition is not acceptable, a DO_NOT_COMMIT_ZONE_CHANGE is sent. As the node receives the commit information, in the positive case it will process to the link change and broadcast a COMMIT_DONE message. In the negative case, the DO_NOT_COMMIT_ZONE_CHANGE should just be forwarded to the second feeder, informing it that the planned proposition will never be made.

Figure 3.26: Change become effective

A random code for communications - The RandomCodeBearer class

Since all communications are travelling independently on the network, a mechanism able to identify quickly a certain message as an expected one was needed. Types of messages can be used for that purpose but are not sufficient. The two exchanged objects, Communication and ChangeProposition, extend for this reason the RandomCodeBearer class. This class just defines a field that contains a randomly generated number. Each time that a new Communication or ChangeProposition object is created, a random number is attributed to it. This random number is defined as an integer, and may take any number from 0 to (2^31)-1. Even if it is possible that

2 3

6 5 4 9

8

Other zone change response, from previous phase

Zone 1

Zone 0

Zone 2

0

Type: TRANSFER_REQUEST_RESPONSE Data: TransfertRequestCommunication

complete = true proposals: change 6 from 3 to 9 accepted change 4 from 2 to 8 refused

Type: TRANFER_REQUEST_RESPONSE Data: TransferRequestCommunication

complete = true proposals: change 4 from 2 to 8 refused

1

Type: TRANFER_REQUEST_RESPONSE Data: TransferRequestCommunication

complete = true proposals: change 6 from 3 to 9 accepted

1

2 3

6 5 4 9

Zone 1

Zone 2

0

Type: COMMIT_ZONE_CHANGE Data: ChangeProposition

…

1

2 3

6 5 4 9

Zone 1

0

Type: COMMIT_DONE Data: ChangeProposition

…

To feeder 11

Chapter 3 - Realisation 63 two distinct communications carry the same number at the same time, the probability of such an event (a collision) is assumed insignificant.

There’s a last point to clarify: if, on one hand, it is always the same ChangeProposition object that is travelling from one node to another, new Communication objects are created at each sub-node, with each time a different code. When a son receives a Communication object from its father, it has to note its code. Later, before sending another Communication object containing the response and the proposals, the code for this another Communication object must be replaced by the noted one.

3.8 Others

3.8.1 Testing project and statistics watcher

Testing the first method

Beside the main Jcreator project called thesis, another small project has been created, the testing project. The idea of this project was to test the functionalities of the main one. This project contains two classes: the RandomNetworkGenerator and MassiveTester classes.

The method generateConnectedNetwork(int nodes, int links) of class RandomNetworkGenerator, generates randomly a graph containing nodes and links. There are two restrictions on the parameters: first, the network must be complete, so links > (nodes - 1). Secondly, network can contain at the most (nodes(nodes - 1))/2 links. Given the two constants MIN_GRAPH_COMPLETENESS and MAX_GRAPH_COMPLETENESS, these restrictions are reinforced, and:

• links < (nodes-1)*MIN_GRAPH_COMPLETENESS • links > ((nodes)*(nodes-1) * 0.5)*MAX_GRAPH_COMLPETENESS

Graphs are generated with two possibilities: the first one proposes to select each time two nodes randomly, and to define a link between both, if such a link does not already exist. Before it is returned, the completeness of the graph is checked. The second method first constructs a tree in the graph and then adds the rest of the links similarly to the first method.

The MassiveTester class has been used to check the validity of the first algorithm. It asks the RandomNetworkGenerator to create several networks, and calls the NetworkOrganisor on them. For each generated network, a line of statistics was written in an output file, by means of the StatisticsWatcher class. This last class, included into the thesis.tools package, should be used through five well distinct methods (see Javadoc documentation for usage). It produces data in a text file that can later be used in some spreadsheet software, in order to analyse or represent graphically the data.


Benchmarking the second one

To generate the data included in the result part of this work (about the second method), the thesis.Tester class has been added. It is directly at the root of the project since it can be used as an entry point: the following line entered in the command line

java thesis.Tester 2-2.net 1 request

launches one time (the 1) a request phase on the network saved in the file 2-2.net and this one

java thesis.Tester circle.net 10 offer offer reorg

launches 10 times successively two offer phases and then one reorg phase on the network of file circle.net.

The results of the execution are: a stats_[filename_given_as_parameter].txt file containing some information separated by tabs, and some

[filename_given_as_parameter]__[X].net

containing the resulting network.

3.8.2 “The simplest load flow calculator”

To perform the evaluation stage in the first method, an implementation of a load-flow computation algorithm had to be made. The proposed implementation, available in class SimplestLoadFlowCalculator is, has its name indicates, the simplest way to do it.

The method computeFowardConsomation(int busConsumption, BasicElectricalLinkRepresentative elecLink) consists in the main computation step. Given a global power consumption on one node (including consumption of sub nodes), and a certain link, this method computes the power that an upper node must inject into the link in order to receive locally the desired power. As assumed previously, the current is assumed to be continuous. Furthermore, one assumes the presence of a device that raises (for free) the voltage level at the end of each link to its nominal value at any node (in order to compensate for the voltage drops). Let’s also define the following values:

P total power injected at the beginning of the link [Watt]

P’ total power that reaches the end of the link [Watt]

U nominal voltage level of the network [Volt]

U’ effective voltage level at the end of the link (before raising) [Volt]

R electrical resistance of the link [Ohm]

I current circulating in the link [Ampere]

Given those assumptions and definitions, according to the Ohm’s rule, the following statements can be extracted:

P = I ⋅ U (1)

P’ = I ⋅ U’ (2)

(U - U’) = I ⋅ R (3)

Chapter 3 - Realisation 65 The goal is to know the amount of power that must be injected at the beginning of the link to feed the node’s consumption, in our case, P. Using (1), (2) and (3), the following expression can be extracted:

P = ( )R

RPUUU2

'42 −− (4)

This value P is the one returned by the computeFowardConsomation() method.

Given this method, the whole state of the network can be computed, starting at the leaves and going progressively up: when the consumptions for all the children of a node have been computed, the consumption for the node itself can be computed. Figure 3.27 shows a possible order for computing the loads. This vertical progression is realised by the method doIt() and a node is processed by method processNode(). The SimplestLoadFlowCalculator also carries out the score computations.

Figure 3.27: Processing order of each link in a load-flow computation

3.8.3 Development environment

As said in the introduction, JCreator provides several integrated tools that can be called directly from the editor. For some special functions, however, one will need to call external tools and functions. For that purpose, several windows shell script functions have been created:

Atomical operations

• clean.bat: remove all generated and temporary files and directories • compile.bat: recompile all files • debug.bat: start the debugger on the project • generatedoc.bat: generate the Javadoc documentation • run.bat: start the execution of the program

Composed operations

• build.bat: cleans and regenerate everything (including documentation) • generatejar.bat: recompile everything and recompose the .jar file

Executable .jar file

.jar files are on one side only compressed archives containing what a Java application needs to run. They are on this point very similar to ZIP or RAR archives (and even more, the compression

g

d e

c b a

F

1 3

2 5

4

6


mechanism is identical to the ZIP one). However, they may include a special file, called Manifest, which contains extended properties. A Manifest file may contain many type of information like version, manufacturer, a cryptographic signature that authenticate the containing of the archive, etc.

In the present case, Manifest file will be interesting especially for one new functionality (since Java version 1.5.0): the executable comportment of .jar files. By defining, in the Manifest, a name of the entry point class of the project, a double click on the file directly starts the application. That avoids the need of the console, and, in some cases, the need of defining special environment variable in the system configuration.

The project is then packed in one unique file called thesis.jar, which contains the following Manifest:

Manifest-Version: 1.0 Main-Class: thesis.Thesis

Directory structure

In might make sense to have a look at the project’s file and directory organisation. In the project main directory, one will find, beside the already cited batch files, the Jcreator project file, a file called src_thesis.txt and a list of directories.

The file src_thesis.txt should normally be generated by JCreator and contain the list of all source files composing the project (absolute address of the file). The directories list contains:

• Two ‘permanent’ folders: o src - the source files (according package organisation) o div - the other files of the project (the Manifest file, the logging properties)

• Four ‘generated’ folders: o bin - contains the executable of the project o classes - the compiled java classes o doc - the Javadoc documentation o lib - a library version of the project

4. Results

4.1 Network model and the associated interfaces

One of the objectives of this work was, on one side, to provide a set of classes permitting the modelling of distribution networks according to the oriented object paradigm and, on the other side, a Java based graphical application to design, edit and observe network models.

As described in the points 3.3 and 3.4, a complete network model and an operational graphical user interface have been developed. Even if the proposed model stays very simple and limited, everything has been done in order to permit its extension without having to change too many things in the core classes. Other classes extending the Element, the Node or the AbstractPhysicalLink classes can be added, they may use the already implemented methods of they their super-classes (paint(), myZoneIs(), and will in any case profit from all the advantages offered by the existing graphical interface (button, mouse interaction, etc.) and by the embedded properties handling function. Furthermore, if they implements the right interfaces and respected the isolation principle enounced earlier, they should be directly compatible with the existing other subprojects or packages.

To justify those assumptions, one can cite an example: the class thesis.gui.NetworkEditorPanel owns the TOGGLE_BUTTON_ACTIONS table that defines the properties of each toggle button of the NetworkEditorPanel. One line of this table defines the toggle button associated to the creation of a feeder node:

{ "feeder node", - internal name

"New feeder node", - text of the button

"Place a new feeder node", - tool tip text

null - method to call when mouse is pressed

null - method to call when mouse is moved

"addNode", - method to call when mouse is released

thesis.network.elements.FeederNode.class - parameter to give to the method

}

68 Chapter 4 - Results

Assuming that a model for a ‘transformer node’ must be introduced to model a special network, an associated toggle button shall then also be added. By adding the following line into the tab

{ "transformer node", - internal name

"New transformer node", - text of the button

"Place a new transformer node", - tool tip text

null - method to call when mouse is pressed

null - method to call when mouse is moved

"addNode", - method to call when mouse is released

[class of the transformer node] - parameter to give to the method

}

a new toggle button will appear in the toolbar. Furthermore, because the NetworkEditorPanel uses the reflection, the existing addNode() method can be used to create the transformer at the mouse position when a click is made and when this button is toggled. No new method is necessary (as long the creation of the new element does not require special parameters).

The corresponding packages may therefore be useful in future projects and help the people working on them spare some development time. According to its extension possibilities, it would be usable in most cases.

4.2 First method

4.2.1 Three parts of the algorithm

As mentioned before, the first method is based on three separate steps: construction of a solution, fitting and scoring.

The mechanism developed to construct the solution (via electing leaders etc) almost always returns a valid set of branches (radial but complete). It has been tested, using the testing project, with many different random graphs, of different sizes. The first developments of this part took a lot of time, since they were made in parallel to the development of other functions. The first method was ‘the first to suffer’ since most of the code organisation problems, IP stack problems or serialization problems were encountered during its development.

The second part, the fitting, corresponds to the development of the load-flow algorithm. The proposed solution is, as the name of the class indicates, very simple, it is however operational and should present good time characteristics since each node is ‘visited’ only once. It also provides a method

Chapter 4 - Results 69

allowing the computation of one link independently of the whole algorithm. It should of course be extended or replaced in another context, but it can be considered as a result.

In order to remain true to the distributed algorithm paradigm,(already shaken by some assumptions), it has been decided that the scores will always be computed locally. Links scores are only defined for several criteria: previous score, activity in the previous solution, charge or occupation in the previous solution. Node scores are then computed using only the scores of the links incident to the node.

4.2.2 Time measurements and performance

Using the MassiveTester, the performance of the first phase for one iteration (assembly of links to reach a complete tree) has been measured and represented here. Time measurements are presented first of all:

Average time duration (in second) of one iteration (over 10 samples) table 1 50 nodes 75 nodes 100 nodes 125 nodes 150 nodes 75 links 4.9 100 links 7.6 9.6 125 links 9.4 11.1 13.6 150 links 10.0 13.4 16.2 16.2 175 links 16.1 17.1 19.2 19.9 200 links 19.3 20.6 22.5

Average time (in milliseconds) per node | per link (over 10 samples)

table 2 50 nodes 75 nodes 100 nodes 125 nodes 150 nodes 75 links 98 65 100 links 152 76 128 96 125 links 188 75 148 89 136 109 150 links 200 67 179 89 162 108 130 108 175 links 215 92 171 98 154 110 133 114 200 links 193 97 165 103 150 113

These benchmarks were made on a 1066 MHz Pentium III. Notice the good performance of the large size network (150 nodes, 200 links). To run the tests optimally, the load-flow computation has been deactivated, as has the score calculation. The logging was restricted to the high level group. One may note the following things:

About the time per node (left sub-column):

• It increases with the number of links, which is fairly normal: increasing the number of links without increasing the number of nodes means more links adjacent to each node and therefore more work.

• With a fixed number of links, it decreases with the number of nodes: this is due to the same reason as above, since increasing the number of nodes without changing the number of links means reducing the number of neighbours of each node thus reducing the amount of work.

About the time per link (right sub-column);

• It is more stable than the time per node: links are not "thinking" objects • It stays quasi constant (assuming a certain variance) with respect to the number of links and

increases slightly with respect to the number of nodes. This can be explained by the work distribution, more nodes meaning more agents.


The number of messages sent has also been analysed:

Average sent messages in one iteration (over 10 samples) 50 nodes 75 nodes 100 nodes 125 nodes 150 nodes 75 links 1606.1 100 links 2059.5 2303.5 125 links 2423.4 2823.9 3211.4 150 links 2657.8 3530.9 3952.9 3928.3 175 links 4024.6 4290.1 4802.8 4650.5 200 links 4947.4 5276.9 5564.6

Average number of messages sent per node | per link (over 10 samples) 50 nodes 75 nodes 100 nodes 125 nodes 150 nodes 75 links 32.1 21.4 100 links 41.2 20.6 30.1 23.0 125 links 48.5 19.4 37.7 22.6 32.1 25.7 150 links 53.2 17.8 47.1 23.6 39.6 26.4 31.4 26.2 175 links 53.7 23.0 42.9 24.5 38.4 27.4 31.0 26.6 200 links 49.5 24.7 42.2 26.4 37.1 27.8

Messages results are similar to the time ones, and it would make sense to build another table, indicating the time per message:

Time (in milliseconds) per message (over 10 samples) 50 nodes 75 nodes 100 nodes 125 nodes 150 nodes 75 links 3.0 100 links 3.7 4.2 125 links 3.9 3.9 4.2 150 links 3.8 3.8 4.1 4.1 175 links 4.0 4.0 4.0 4.3 200 links 3.9 3.9 4.1

The time per message can be considered constant, at around 4 milliseconds. This shows empirically that the time complexity of the algorithm is equivalent to the message complexity, since sending a message always takes about the same time.

The algorithm execution time can therefore be supposed polynomial both in respect to the message and time complexities. Do not forget furthermore that it is distributed and hence usable on many machines. Assuming that each node is running its agents and that communications times between distant machines are null, one may suppose that the running times on each machine will be similar to the ones found in table 2 (running time/node numbers). Let us build a last table, dividing the value of table 2 (left column) by the average number of links on each node:


Time per node divided by neighbourhood factor 50 nodes 75 nodes 100 nodes 125 nodes 150 nodes 75 links 32.6 100 links 38 48 125 links 37.5 44.4 54.4 150 links 33.3 44.4 54 54 175 links 46 58.8 55.8 56.7 200 links 48.2 51.5 56.2

These times represent the average time spent by each node with any of its neighbours. The values are slowly increasing but this can be attributed to the fact that in the simulation, all threads must share one CPU, which induces a waste of time. Under this and the previous assumption, one may suppose that the complexity of the presented algorithm is proportional to the number of nodes and their average number of neighbours. In other terms, with n nodes and l links, O(n2/l).

4.2.3 Optimisation results

After many tries, score function changes, iterations, the method has been declared invalid and irrelevant, since no convergence property has been found. Moreover, the algorithm just jumps from one solution to another one, without making much sense. Finally, the algorithm gets relatively quickly stuck in one solution, or in a group of three of four solutions, among which it cycles. In a few cases and examples, a valid solution or even the best solution has been reached by the algorithm. It is, however, possible that those cases are due more due to a random positive iteration of the algorithm, rather than a clever algorithm.

The above sentence overstates the problem quite a bit and too quickly. In the present form, the algorithm has a few chances to converge, according to the following example: given a network with two feeders, assume that the algorithm found an intermediate solution S. In this solution, consumer A, B and C are cared by feeder F1, and consumer D and E by F2. F1 is surcharged, F2 has big capacity.

Figure 4.1: C is not aware of the problems it causes

A solution to the problem would be to activate the link (A-n3) and disable the (n1-A). But, in the solution S, the cause of the problem (A), just sees the two links A-n1 and A-n3. None of them are in surcharge. For the point of view of A, everything is doing very well in the network and there is no need to change. Since the scores are computed locally, if a node do not detect problem in the neighbourhood, its score will always be up revised, and therefore algorithm is stuck in a bad solution. In this case, in makes particularly sense to discard the presented algorithm.

a e

F

b c d

F

c does not see any problem in its direct neighbourhood

n1 a e

F

b c d

F

the only solution of the problem is however in this

neighbourhood

n1


However, all this lies on the locality principle. Assume now that scores are attributed in function of the global quality of the solution. Of course, this quality must be evaluated, defining penalties for overcharged nodes, links, bonuses for well balanced solutions, and building such a quality function is not straightforward. But afterwards, by revising the scores of the element proportionally to this quality value (or proportionally to the relation between the present quality factor and the best one), and in respect of what happened in the organisation construction, it is absolutely not sure anymore that the proposed method will provide any good results at all. Is it possible to compute a global quality factor in a distributed system? As one will see in the next section, the load-flow computation presented in this network can easily be distributed among the nodes, each one computing its own domain. In consequence, it should not be too difficult to think a similar mechanism that would grade a solution.

Those observations about global rating arrived unfortunately a bit loo late, and it had already been decided to develop the concept presented on the next section. No valuable results will then be presented in relation to this method.

4.3 Javadoc documentation

As said previously, a Javadoc documentation as been extracted from all classes of this project. It is available in the electronic version of this report. Refer to chapter 6 for more details

Figure 4.2: Snapshot of the javadoc (actually on class ConsumerNode)

4.4 Second method

4.4.1 Full framework and algorithm separation

Before presenting the results in term of successful configurations, the package and the class structure, as the code organisation can already be held as a result. Contrary to the organisation of the other


method’s classes, which did not define a clear separation between the algorithm itself and the framework, the second method is implemented in two well distinct packages:

thesis.agents_new.framework; thesis.agents_new.algorithm;

The four classes of the framework package are completely independent of the algorithm package, since none of them import objects from it. A special AbstractMessage class has been introduced. AbstractMessage defines the basic definitions or properties of the exchanged message (like the presence of the index of the receiver, the one of the sender) but does not fix any implementation concerning the type of message. AgentStub, at the beginning just introduced to split the functions of LocalNodeAgent_NewVersion, is now a well defined abstract class providing low level functions and release the sub classes of many responsibilities. The CommunicationStub is roughly integrated to AgentStub. It cannot be directly instanced and is available through the getCommunicationStub() method of AgentStub. The set of its public methods has been severely restricted. Finally, as the CommunicationStub is integrated in the AgentStub, the neighbour objects are integrated into the CommunicationStub. The Neighbour_NewVersion class also define neither public constructors nor public methods. The class is let public since it might be extended by another class (that will, for example, define other fields to store neighbour related information).

Figure 4.3: The agent itself, then AgentStub, providing access to the physical base and to the communication

stack.

The presented algorithm uses these four classes as any other could, and this package, beside the other general ones, is susceptible to be reused in another project.

4.4.2 Results through examples

To prove the validity of the algorithm, the most direct way is probably to present examples. For each example, some numerical results are indicated. They where generated using the StatisticsWatcher, on a Pentium III 1066 MHz. The average time indicated corresponds to an average of ten samples, discarding the biggest and the smallest ones.

getPhysicalBase() getCommunicationStub()

ElectricalNode

getActiveLinksRepresentatives()

getConnectedLinksRepresentatives( getElectrifiedLinksRepresentatives(

getIndex(double getLinksRepresentatives(

CommunicationStub

getNeighbour(int index)

getNeighbourIterator( sendToAll(...

sendToAllButOne(...sendToOne(

access to the topological and electrical information

access to the communication facilities

Agent class (LocalNodeAgent_NewVersion)

AgentStub abstract class


Basic examples

Two examples were used during the whole development in order to verify the pertinence of the changes. The first one is the ‘2 producers 2 consumers’ illustrated here (file 2-2.net):

Figure 4.4: Network '2-2.net' before changes

The only possible solution is to transfer node 1 to feeder 3. Using either one request phase or one offer phase, the algorithm returned this possible solution:

Figure 4.5: Network '2-2.net' after changes

1 offer phase applied to '2-2.net' Nodes number Links number Average time[ms] Average messages Echanged bytes 4 3 173.4 18 20'520

1 request phase applied to '2-2.net'

Nodes number Links number Average time[ms] Average messages Echanged bytes 4 3 162.8 19 21'418

The second is the ‘loop’ example (loop.net):

Figure 4.6: Network 'loop.net' before changes

Here again only one solution is valid: instead of feeding directly node 2 (what causes the link 0-2 being overloaded), it must be feed passing thru 1. One internal reorganisation phase found the problem and gives the correct solution:


Figure 4.7: Network 'loop.net' after changes

1 reorganisation phase applied to 'loop.net' Nodes number Links number Average time[ms] Average messages Echanged bytes 3 3 203.7 27 20'330

More complex examples

The 2-2 and the loop are good but too simple examples. A unique change is to do and furthermore this change is the only possible one. The next examples propose some more complex graphs with more links and more possibilities (before and after):

• ‘3 producers 3 consumers 4 intermediates’ (file 3-3+4.net) • ‘4 producers 5 consumers 4 intermediates’ (file 4-5+4.net) • ‘3 zones’ (file 3-zones.net)

The ‘3 producers 3 consumers 4 intermediates’ is solved by both offer and request phases. However, two offer phases must be run to get the final solution.

2 offer phases applied to '3-3+4.net' Nodes number Links number Average time[ms] Average messages Echanged bytes 10 12 1142.8 182.1 222'296

1 request phase applied to '3-3+4.net'

Nodes number Links number Average time[ms] Average messages Echanged bytes 10 12 1185.5 220 243'032

The ‘4 producers 5 consumers 4 intermediates’ can be only solved completely running twice an offer phase, and then a reorganisation one, since the request concept gets block in the following situation (fig 4.8):

Figure 4.8: Network '4-5+4.net' ; request phase cannot go further


From the original state, only consumer 11 has been transferred to feeder 2. After that, feeder 0 will be the unique one to stay overloaded. Unfortunately, its neighbouring feeders 0 and 3 cannot help him: 3 is already at the limit and 1 has only 10 of capacity, while the only transferable node 9 needs 20.

2 offer phases and one reorganisation applied to '4-5+4.net' Nodes number Links number Average time[ms] Average messages Echanged bytes 13 16 1598.2 244.9 242'644

The ‘3 zones’ illustrates the same case: feeder 0 is overloaded but its unique neighbouring feeder 1 is already working almost at its limit. A request procedure will not thereby bring any improvement here. Using an offer phase, the feeder 2, much more below its limit than 1, will receive 6. 1 is discharged and might receive 7 from 0: a valid situation has been found.

1 offer phase applied to '3-zones.net' Nodes number Links number Average time[ms] Average messages Echanged bytes 10 9 797.4 143.4 158'746

Bigger examples

Some bigger examples have been designed, as the ‘circle’ (circle.net): Six 80 kilowatts injectors are placed in on a circle formed by links of 100 kilowatts of capacity. 15 consumers (consuming between 15 and 35 kilowatts) are placed in the circle, connected by 25 and 50 kilowatts links.

Figure 4.9: Network 'circle.net' before changes

Figure 4.10: Network 'circle.net' after changes

A request phase solves the injector overload by switching three links. After these three operations, the system is in a normal state again excepting one overloaded link (the offer and request phases does not


try yet to solve the links overload). An offer phase finds the same situation (with on overloaded link) by switching nine links.

1 request phase applied to 'circle.net' Nodes number Links number Average time[ms] Average messages Echanged bytes 36 57 5999.4 351.4 431'301

1 offer phase applied to 'circle.net'

Nodes number Links number Average time[ms] Average messages Echanged bytes 36 57 25254.3 1959.6 1'604'394

Special cases

Three examples illustrate several lacks of the algorithm. In the file ‘special.net’ both feeders0 and 1 supply a very distant consumer. The nominal value of the consumer’s consumption is inferior to the capacities of the feeders, but due to the long distance separating the producer and the consumer, important losses appear, overloading both feeders and links. The solution consists for both of them to exchange the consumer with the other, since there exists two disabled short links permitting such a change. Regrettably, none of the procedure are able to realize a such exchange.

Figure 4.11: Network 'special.net' in wrong and correct states

In the file ‘special_deadlock.net’, feeder 2 is overloaded and feeder 0 has no consumers. Between them feeder 1 is working at the maximum of its capacity. No request procedure will of course affect the present situation, since the only direct neighbour feeder of 2 is 1 and is saturated. No offer procedure will solve this problem neither, according the following scenario:

Figure 4.12: Network 'special_deadlock.net' in the original state

Feeder 0, who has some capacity, makes a proposal to feeder 1. Feeder 1 will agree the proposal for nodes 3 and 4, and feeder 0 will choose one. After the commitment, the present state is reached:


Figure 4.13: Network 'special_deadlock.net' in the deadlocked state

Feeder 0 supplies either node 3 or 4, feeder the node not supplied among 3 and 4, and feeder 2 always 5 and 6. The situation is blocked: to discharge feeder 2, feeder 1 would have to supplies either 5 or 6. To do so, feeder 1 must be free, which implies feeder 0 supplying 3 and 4. And this is not possible: no procedure will ever go from situation of figure 4.12 to the one of figure 4.13, since 4.13 is worst than 4.12.

Figure 4.14 Algorithm should accept this situation to reach to best one (fig. 14). It can not since it is worst than

situation of figure 4.13

Figure 4.15: Network 'special_deadlock.net's possible solution

Literature examples

T. Nagata et alt. presents in [2.32] a simple network composed of 8 substations (2 feeders and 6 consumers), plus 6 intermediate stations. A fault is simulated in this network, and method presented in the same publication proposed a list of operations to apply to the network in order to retrieve a normal situation.


Figure 4.16: On the left, the original network, on the right, feeder 1 has been deleted to simulate the failure of the link 0-3

The simulated fault is the disconnection of link connecting node 1 and 3 and the whole part of the graph situated below 3 is cut. According that 3, as first reaction, activates the link between itself and 2 to remedy at the loss of the arborescence, this link becomes overloaded. A single phase of the reorganisation procedure remedy to this overloaded. Furthermore, it gives the same list of operations than the method presented in [2.32] (except that [2.32] defines two end switches for each link, while the work defines only a unique state).

Figure 4.17: Network as been reconfigured successfully

R.S Cherkaoui presents in [2.1] an example of distribution network (inspired from real world) containing 230 nodes and 306 branches. At the hour of the redaction of this report, the application of this network to the presented algorithm has been made yet. Hopefully results will be presented during the oral exam, or added later to this document.

4.4.3 Comments

The small examples illustrate the concepts of the method, and prove that it is basically working. Medium examples continue in this direction, but already present the weakness of the request procedure. Special cases show what must be added as functionalities in the algorithm. The circle example proposes to show the performance in front of a network that could eventually already be a real one. And the literature example compares the proposed algorithm to an existing one. On this subject, one may say that the method of [2.32] uses also a multi-agent system but with a central coordinator, which is not the case here.

Sometimes the indicated average number of message is not an integer, which means that the number of sent message was not fixed. Even if the procedures are totally deterministic, those differences are due to the scheduling of the different java threads. In average, java shares the CPU time equally


among threads of same priority, but only in average. The first feeder to commit a change will then not always be the same one, what has an influence over the total number of messages.

The average execution times indications are present to give a size order. It is however difficult to extract a time principle out of that results. The number of message and the times needed depend greatly of the network case. One may however remark the good performance of the request procedure in the circle example, overall compared to the offer procedure. Remark that the request procedure is more limited (since it blocks in the 3-zone, for example) but on the other hand more efficient. Request procedure proceeds in smaller steps and allows more changes, which is not always a good solution. The size indicated for each example is also purely indicative. Observe however those messages are in average 1 kilobyte big. This is not much but could be drastically reduced using a dedicated serialization mechanism. In general, many things could be optimized in the project, to reduce the execution time or the amount of transferred data.

Just to prove the assessment that transient fields are not transmitted, in the example of the ‘4-5+4.net’ file, the communication size is of 242 kilobytes. Without the use of transient modificators, this communication size jumps to... 1.31 megabyte. Those modificators are thereby well used.

Finally, when executing method over big examples (the circle in particular), many error messages will probably be displayed on the command line. They are principally IllegalStateException thrown when an unexpected message is received: for example, it is abnormal for a node to receive an EXPLORE_RESPONSE message outside an exploration procedure. Explain the presence of those wrong messages is difficult. Such problems happen especially in big networks and after a certain time of execution. To understand why did such a message have been received outside of the procedure, the history (using the logs) of the concerned threads must be analysed. But sometimes this information contained into the logs is not sufficient since it does not represent the exact situation.

4.5 Limitations, known bugs or failures

The following lacks have been identified among the different parts of the project. Some of them are just esthetical when others may induce a bad comportment. The first objective of a project continuing this one would be to correct the presented points.

4.5.1 In the GUI or in the network model

The NetworkEditorPanel uses, to represent graphically a network, a java.awt.Canvas. Canvas objects seem to not fit very well with the javax.swing members (used for the menu, the buttons, etc). The size of a thesis frame has been intentionally blocked for that reasons. It is big enough to represent small examples of 10 or 20 nodes, but for more complicated representation, that could be a limitation. It has been tried to place the Canvas object into a JScrolPane object, be without success. Other options must be envisaged.

The implementation of the inMyZone() method in the AbstractPhysicalLink class is a bit hazardous. It proposes to compute two angles and to check if those angles are inferior to 25 degrees. It generally works for long enough links but not for short ones. Furthermore, when many links are located in the same zone, a click on one of them returns sometimes the properties of another one.


Icons of the toolbars buttons are missing. For this reason the following lines are displayed on the console when a new frame appears:

Resource not found: toolbarButtonGraphics/navigation/save.gif Resource not found: toolbarButtonGraphics/navigation/load.gif ...

Once again, the model deals only with direct current. The powers are always represented as integers and the voltage level is supposed to be uniform, what is rarely the case. The nodes, links and associated class should thereby be changed in order to support alternative currents, distinct voltage levels, non-integer power consumptions, etc.

4.5.2 In the agent framework

The algorithm makes extensive use of TCP connections, since each time that a message must be sent, a new connection is setup. In the circle example previously cited, the offer procedure sends about 80 messages per second, and in total, almost 2000 messages are sent. The TCP stack is called 2000 times. The internal implementation of the TCP algorithm appears to be struggling with that many connections. Exceptions (java.io.BindException, java.io.ConnectException) are thrown from the native part of the TCP implementation and generally do not give much more information than ‘connection refused’. Consequently, the choice of TCP/IP connections as inter process communication channel should be reviewed. Remember, however, that TCP has also been elected in order to stay compatible with an eventual version of the framework that would support a multi-machine environment. By supposing a unique machine for each node in the circle example, the number of messages per node is about 54, which remains within the capabilities of Java’s TCP stack.

The second main problem of the multi-agents framework is related to the detection of the algorithm’s termination (in the asynchronous case). As seen, this is due to the monitors principle: an object used as a baton is passed from a thread to another when those threads have to read or modify special variables. These two special variables (the number of active threads, the number of unprocessed messages) and the monitor object itself are implemented using static variables, which means variables associated to classes and not to objects. Those static variables are common to all objects, and in one sense, the full distributed property of the method disappears since a central organism (in occurrence Java) exists. One may however say that this mechanism is only present to detect the end of the algorithm and does not affect the algorithm itself. Once the algorithm has started, it runs and finishes automatically. The detection of the end of a distributed algorithm is a very complex problem, to which a perfect solution probably exists. One will refer to the literature to find and apply it.

4.5.3 In the algorithms themselves

As already said, both of the presented algorithms are first of all not optimal from the point of view of message size, identification of the receiver, etc. Both of them may be greatly speeded up in defining a number variable for each message’s type instead of the current string. The concept presented in the first method of using recursively new agents on the same node, is probably fairly inefficient, and should be replaced by another, proven optimal.

In the ‘transfer-oriented’ algorithm, an implementation of a strict structure was attempted in order to avoid ‘mislaid’ messages, with the help of the procedures and of the random codes. However, as said at the point 4.4.3, some messages are mislaid, why exactly remains un cleared. Generally, during the first 4 or 5 seconds of the execution, no error messages are displayed. The further the program advances, the more errors appear. Are all these errors related to the loss of a unique message, after a stack failure? Or is there in the algorithm a special situation where a special kind of message in not correctly treated, inducing afterwards the strange behaviour observed?


The ‘risk problem’ is related to this subject. What is the good solution? In which case the procedure collision must be avoided? Is there really a risk that a part of the network remains isolated after two consecutive changes? The developed algorithm does not include a proof of validity and could need to be rethought from a to z, in order to implement the presented functions correctly.

4.5.4 In the tools

The load-flow computation tool and algorithm gives a very approximate value, due to all simplifications and assumptions made. Furthermore, when used globally (for example called by the GUI, the load-flow algorithm works only for radial networks but furthermore, it returns exotic computation when used with non-radial networks, without detecting the non-radial state of the presented network.

As for the logger, it keeps all logging results internally in lists, for ever. It does not induce many problems when used with small examples, that could however be a larger flaw when used with big network instances. The logger may indeed contain at the end enough information to overrun the java memory available. A solution would be, when reaching a certain quantity of logging lines, to write some of them in a text file. This renders possible reading those text files again and reloading the result of each logging category into the LoggingFrame.

4.6 Little problems, big time...

On the other side, a list of the most warped problems solved can be established (as a hall of fame).

In the first version of the communication stack, the memory occupation was increasing very quickly and was reaching the limit of the Java Virtual Machine’s stack even with small networks. Memory problems are uncommon in Java, since most of time the integrated garbage collector recycles transparently the memory occupied by objects no longer used. Why in the current case, was this mechanism not working? Probably because somewhere in the program, a reference of to an object was kept even though unused. Much time has then been spent in analysing the garbage collection mechanism, the finalisation of the objects. Objects creations have been counted. But the memory occupation was still huge. Finally, the reason has been found: when an object is written over an ObjectOutputStream, this stream keeps its reference in order to do not have to write it again on the stream. Each ObjectOutputStream associated to each connection between an agent and another was keeping the whole conversation in memory. The solution was then simple: delete every ObjectOutputStream after use and reinstantiate a new one.

When the java.io.BindException and java.io.ConnectException cited before are thrown for the first time, they are held due to a faulty use of the communication stack. Much time has been spent to avoid them, until coming to the conclusion that such exceptions were normal. They simply needed to be caught, and the connection setup again.

During the development of the second method, it was thought that the program was getting blocked for one unique reason: something was not correct in the termination detection mechanism. This was checked repeatedly until finally, with the help of the debugger, the internal and instantaneous state of the program was used, to discover that at the end of execution, the program was blocked due to a deadlock (described in point 3.7.5)


To close this result chapter, the stupidest bug distinction must be awared: The Configuration class proposes to store a representation of a tree in a string. To decompose the representation, the string must be analysed and recursively parsed. The class uses for that purpose some classes of a specific package of Java: the regular expressions package. To extract, with the help of those classes, the part “1-12” contained into “1-12[1-4[0-4[].0-3[]]]”, the following regular expression has first been used:

"([0-9]+-[0-9]+).*\\]"

In the world of regular expressions, [0-9]+ means any number of at least one digit, .* means a sequence of any character (of any length), \\[ means the character ‘[’ and the (...) means capture this part. The whole expression means: “capture two numbers of at least one digit each separated by a hyphen, followed by some sequence of character terminated by a bracket”. Let us see what it captures:

1-5[] gives 1-5 12-3[0-0[]] gives 12-3 1-1[0-2[0-3[],[0-4]]] gives 1-1 2-12[] gives 2-1 !!??

Why do the expression capture ‘2-1’ in ‘2-12[]’? The first reaction is to think that there is a bug. But no, it is totally logic: the two numbers separated by a hyphen are 2 and 1, and the following sequence of character terminated by a bracket is ‘2[]’. To extract ‘2-12’ from ‘2-12[]’, the following expression must be used:

"([0-9]+-[0-9]+)\\[.*\\]"

which means “capture two numbers of at least one digit each separated by a hyphen, followed by a character sequence in bracket.

This small difference of two back slashes was difficult to locate and identify. For three days, the blame was put on the algorithm itself. Finally, after a lot of tests, it was obvious that the fault was in the Configuration class, but two more days were necessary to identify and correct it.

5. Conclusion

5.1 General comments on the development of the project

After six month of work, let us stand back and see what emerges of this work. Aside from a graphical interface that displays and permits the edition of basic distribution networks representations, the problem of the configuration of distribution networks has been approached in two different ways, applying distributed paradigms and methods.

5.1.1 The good choice of Java

First of all, the choice of Java as the main development language and environment was probably a good one. Except for some details inherent to each development environment (related in point 4.5 and 4.6), the use of Java has never been regretted: the language itself has never been an obstacle and moreover, some particular functionalities of Java, like the reflection, allowed me to solve elegantly many problems.

One just expects that this assessment will be true also outside of the borders of this project, and that people without that much knowledge of Java will nevertheless have access to the essence of this work. Eventually, this project will also introduce a bit more Java in the electrical engineering field, inciting people to discover its fantastic capacities.

5.1.2 To reflect on the first method

No convergence, no results, no use, the judgement was rapid and sharp. Did the ‘cluster-method’ really bring nothing?

Practically, apart from a better understanding of many problems, which is part of a scientific study, it does not appear under the form presented here as an applicable method providing concrete results. At best it will contribute to the development of future applications, which will take inspiration of out this work or use the developed application logic. However, as it has already has been said, it may be conducive to the development of a new class of reinforcement based learning algorithms, applied to the reconfiguration problem. Using global and more meticulous scoring functions, eventually combined with some changes inside of the score based master election mechanism, the method is no longer useless, and in this case the presented clustering algorithm may regain some credibility.

We have nevertheless to undertake a deeper analysis of what can be distributed and what cannot. A non-distributed version of the clustering algorithm should also be studied, and the role and the localisation of the agent may be redefined.

86 Chapter 5 - Conclusion

5.1.3 Horizons opened by the ‘transfer-method’

The second studied method, on the contrary, presents practical examples. Relaxing many criterions such as execution time, safety and accuracy, it could hold as applicable, useful and relevant. The examples illustrated in the previous chapter justify partly this assessment.

As the ‘cluster-method’ does not give results but may finally lead to an effective and powerful method, the ‘transfer-method’ provides concrete results which prove its capacity in front of small examples, but presents new problems and lacks something with bigger ones, and may eventually be, in the end, completely useless.

One can however have faith in its possibilities and future. Further developments, formal analysis and higher order tests of course have to liberate the method from the restrictions of those various uncertain points presented at point 4.4.3 and 4.5.3. and much more work will be necessary to deal with the assumptions that have been implicitly made throughout the work.

5.1.4 The assumptions list...

There is a considerable number of assumptions that have been made. First of all, since the simulations have always been run on one unique machine, one can reasonnably assume that no messages are lost. In a real case however, some packets are lost and programs using TCP/IP should deal with undelivered messages.

The network is supposed to be fixed and not subject to any topology change during the execution of the algorithm. Taking again the Ethernet example, devices do not indicate periods during which the topology of the network can be changed (by plugging or unplugging cable), and periods during the network should not be changed, using as an excuse that the distributed algorithm shall not be interrupted. The comportment of both presented algorithms were absolutely unpredicted (and will remain unpredictable?) in front of such situations.

If the disconnection of a cable can be seen as a risk related to the links, the nodes in the real world are generally also supposed to fail. In the present case, nodes are getting in trouble only when, for example, a certain message type is received while the node (its agent) is in a procedure’s state where such messages do not arrive. Even if the exact reason for this problem has not been identified yet, this can be only due to a software error, and among all probabilities, to an error in the algorithm itself. Now, imagining each agent running on a separate computer, each of those agents is of course subject to the same software flaws, but also to all the defaults of the computer’s operating system which may cause it to crash, electricity feeding may stop, user may shut down the computer, etc. Even if the algorithm itself is 100% failure-proof, computers running it are rarely that secure, and scenarios where nodes fail must be envisaged in a distributed system.

Finally, if one day the present algorithm is integrated to ‘distribution switches’ similar to Ethernet switches, a decision will have to be taken if changes decided by the algorithm should be directly applied to the network (and by who). It is assumed here: when a node receives a COMMIT_ZONE message, it switches (automatically) the changes directly on the graph. This could, however, induce security problems: the algorithm must be absolutely proved as secure, so that it will never commit changes that may be conducive to the creation of a loop in the system. Another possible case would be the following: network is in a state A which is defined as overloaded but can support the overload for a while. The algorithm commits a branch and the network falls into state B, globally less overloaded but unsupportable. If such instantaneous changes are not allowed, that means more or less that a version of the algorithm must first run in a simulator. The simulator produces a list of changes, which is to be verified and committed.

Chapter 5 - Conclusion 87

In a model where changes are instantaneously committed, each physical node is equipped with a computing device that communicates with other nodes. The presence of a whole distributed system makes much sense. If a simulator is used, it does not make sense anymore to allocate one computer for each node. The simulator will be run on one big machine, or eventually a group of machines, which makes the problem different and calls into question many choices made for the algorithm. Furthermore, once the list of changes is set by the simulator, who will plan and commit the changes? A central entity, as a human person, or another distributed algorithm?

5.2 Not yet evoked themes

5.2.1 Distributed generation

The application of the presented method regarding distributed generation, discussed in the introduction, has not yet been treated. Let us see how it would be possible to integrate this principle into the related work:

As the first step, one may declare that this principle is implicitly included in the presented method: in a certain manner ‘distributed generators’ can be held as normal ones, but with a smaller capacity. The second method, in particular, sees no difference between high and small capacity feeders. Furthermore, the more different feeders exist in the network, the better the algorithm should work, since more zones will exist, thereby making the paths shorter between producers and consumers. A consumer with generation capacity can be represented using one consumer node, and one feeder, linked with null length and infinite capacity (fig. 5.1). If the generated power exceeds the local consumption, the algorithm should at least associate both nodes in the same zone, and eventually extend the zone to some other consumers, if capacity permits.

Figure 5.1: A link of null length and infinite capacity between a feeder and a consumer models the distributed

generation

Another way to include distributed generations into the algorithm would be to define a ‘generation property’ inside each consumer, and use it when an exploration procedure is launched. One saw in chapter 3 that on each node, a ‘forward power’ value was defined, according to the following expressions:

busConsumption = forwardConsumption of suns + localConsumption forwardConsumption = busConsumption + losses(busConsumption, uplink)

Given a positive ‘local generation’ value on each consumer (or even on each node), the following expressions:

internalBusConsumption = forwardConsumption of suns + localConsumption busConsumption = |internalBusConsumption - localGeneration| forwardConsumption = busConsumption + losses(busConsumption, uplink)


present a manner of integrating the distributed generation in the network. The absolute value means that forwarding power values are always positive, and therefore that the orientation of the network does not change (currents always go from the root of the zone down to the tree).

Both ways have advantages and drawbacks. By defining distributed sources as independent feeders, those feeders will actively take part in the discussion and repartition process and will exchange nodes with the other feeders. Unfortunately, if powers offered by distributed sources are weak, they can rarely be sufficient to feed more than the local consumption and some neighbours. For example, a node consumes 5 and generates 14 kilowatts. 9 kilowatts are therefore available. The consumers in the direct neighbourhood regrettably all have a consumption of 5 kilowatts or more. Since a consumer cannot be fed by more than one injector simultaneously, the first 5 supplementary kilowatts will be attached to one neighbour, but the 4 remaining others must be wasted.

Using the other way, the same node will probably be included in a tree and have one of its neighbours defined as a sun. The 9 kilowatts will then be injected in its direction and 9 kilowatts less will be ordered to the upper node. But it may also happen that the given node lies at the bottom of the tree, since the local generation property does not influence the reconstruction of a configuration. In this case, all of the 9 kilowatts must be wasted.

5.2.2 Financial aspects

The omission of any money consideration in the project could have been put in the assumption list. It is, however, more than an assumption: taking financial parameters (like sale or purchase price, return of investment, etc) would have made the project development even harder and may have made the behaviour of the algorithm even less coherent.

Electrical distribution networks are considered as operated according a priorities list: the first objective is to feed everybody without creating any surcharge in the networks. The second priority, depending on the cases, can be financial or ‘ecological’ or a mix of them: save money, limit energy waste, saving money while limiting energy waste. The current project concentrates only on the first priority and therefore money consideration can be brushed away.

5.3 Future improvements

Apart from the correction of the ‘bugs’ described at point 4.6, new work directions exist for this project, under many different aspects.

5.3.1 GUI related

The graphical user interface and the network model can be extended. The purpose of the GUI goes outside of this project, and its classes can eventually be used to model other types of networks: domestic or transport ones. The ‘write-once run everywhere’ concept may also be continued, in order to add even more flexibility to the framework.

It has been seen at point 4.1 that extending the GUI to support new network objects was greatly simplified using the reflection mechanisms, and that it was not necessary to write any new method. The class NetworkEditorPanel has however to be changed, since the array defining the buttons is included in it. Why not push even further the concept and define the button into the concerned


class? But do the definitions of a button really have their place in a class in charge of representing an electric object? Or shall one put them in an external file?

This tickles the definition of beans. Beans extend the definition of classes by defining next to the class file a ‘descriptor’. This descriptor permits the modification of the comportment of the class without touching the class itself. Here this idea would make sense, since the descriptor would only contain the information contained into the tab of class NetworkEditorPanel.

Finally, the serialisation mechanism implement yet produce that kind of file:

¬í sr thesis.network.elements.Network 1 [1]

I linksNumberI nodesNumberL linkListt Ljava/util/List;L nodeListq ~ xp

sr java.util.VectorÙ—}[€;¯

I �capacityIncrementI (…) ...

It could be useful to add another serialisation mechanism understandable by human persons, for example, using XML files. A possible solution:

<network nodes=2 links=1> <node links=1 index=0> <link index=0 start=0 end=1> </node> <node links=1 index=1> <link index=0 start=0 end=1> </node> </network>

5.3.2 Framework related

There are two distributed algorithms, a whole network modelling package, where everything has been done to allow the agents to work independently. But at the end, all agents are running on the same machine, and the few good qualities of the distributed algorithm, the ability to be split, are not used.

However, thanks to the abstraction made between the algorithm, the model and the framework, it should be possible to support multi-machine execution only by modifying this last one. Indeed, the graph model contains just information about the topology and some properties on each element but no kind of ‘node address’, or similar things. On the other side, in the ‘transfer-method’, the algorithm itself (LocalNodeAgent_NewVersion) works only using the neighbour abstraction and does not use directly the addresses to communicate with its neighbours.


Only the framework should be modified in that sense. First of all, an ‘algorithm daemon’ must be written and run on each machine. A ‘work distributor’ should:

• contain a list of the daemons started (at least a list of addresses) • attribute to each machine several node of the network to process • transmit to each machine the local information of the node (for example, passing it a whole

constructed CommunicationStub with all its neighbours already configured) • let the machines process start

The solution seems easy and simple, however, two details have to be forgotten:

First, remember that the representative versions of the links contain a reference to the original link, but declared ‘transient’. Representative objects, when the reference exists, permit to set values of the original link. When the reference is not there anymore, because the object has been sent, trying to modify values will systematically produce an Exception. The agents just consult the value of the links of their neighbours. However, they modify some values of their own link (the forwarding power, the activity), and they need for that reason the real version of it.

This explication permits to illustrate one more time why local information must be conscientiously shared and protected. The following figures present it graphically.

Figure 5.2: Having a central definition of the network may induce problems when distributing the work among

various Virtual Machines, especially if agents access the definitions directly

Figure 5.3: With a framework responsible to definitions splitting and no other possible access to them,

distribution is achievable

Virtual Machine Network definition

framework Agent Agent

Agent Agent

framework framework

Network definition

?

?

VM VM

Virtual Machine Network definition

framework

Agent Agent Agent

VM

Node definition

Node definition

Node definition

Agent

VM

Node definition

Network definition


The second point is the termination of the algorithm. The shared variables and monitors cannot be used anymore, and other principles must be applied. Methods exist to determinate if a message-passing oriented distributed algorithm as been terminated. One of them have to be elected and applied.

5.3.3 Algorithms related

On the field of the algorithms, many things can be done: implement one more other serialisation mechanism, which will only serialise the strict minimum and even use data compression. Analyse the working of the algorithm and select for each case the right implementation of the Collection interface (each of them have different processing time for the basic operations: adding an element, removing one, search one, iterate over them). Check the validity of the proposed procedure handling method, the utility of reask messages, imagine another scoring functions for the ‘cluster-method’.

The ‘transfer-method’ may also be upgraded in direction of the distributed generation. According to both solutions enounced at the point 5.2.1, a hybrid one may exist, where intermediate nodes also take initiative to optimize their production.

Other ideas: the reorganisation procedure is always launched by the root feeder. It would be possible to allow other nodes do it also, in order to discharge the feeder of all responsibilities. In big network, where one feeder has 10 or more adjacent links, an idea would be to create 10 independent ‘virtual feeders’, which at the beginning own the tenth of the available power, but which may later discuss between them to share better the total feeder energy. This would split the work charge on each feeder and speed up the whole process.

At last, the presented work is open to many new ideas: formal ones or foolish others. One strongly hopes that those new ideas will be thought, created and implemented!

5.4 Author's comment

5.4.1 The Pandora’s Box...

Pandora, the first woman on earth according to Greek mythology, sent to Earth by the gods in response to the theft of fire by Prometheus, had with her a box, present of Zeus, with a sign not to open it. She did, and all the flaws, misfortunes and pain flowed out of the box and arrived on earth.

This thesis was like opening Pandora’s Box. I do not want to say that my entire work was only pain and misfortune, however many unexpected problems jumped fairly quickly out of the box and changed the planned development of the thesis.

At the beginning of this work, I was awaiting problems related to the electrical world: resistances, losses, dealing with frequencies, etc. The reality has been quite distinct: almost all the problems ecountered have been more or less related to the distributed computing world. Look for example at the ‘transfer method’: in a certain manner, it is just a small algorithm that exchanges two or three branches in a graph, but this small algorithm provoked a wide variety of interesting problems.

Let us now imagine a much more complex algorithm, inspired by the present one. Overloaded feeders also send ‘help signals’, but those signals may be relayed by other zones (multi-hopping communications). The ‘3-zones’ example in this case could be also solved by a request procedure. However, the procedure induces in this case more than one change, which means that changes must be


synchronised, and be compatible. With combined changes, how does one avoid a cycling state of the algorithm? And if a request may go through one zone, why not through two, three, four zones? Where should we place the limit? Remember also that procedure awaits responses. If responses are expected to come from the whole network, the algorithm will probably spend much time in a waiting state.

So, let us suppress the strict condition that all responses must be present before taking a decision, and declare that responses have 5 seconds to come back, and after this delay, changes are taken according to the actual information. But what happens if just after the commitment, a message arrives saying “No, don’t do this change, it will provoked a collapse!”?

Somewhere, I opened the Pandora box of the distributed systems, but just a little bit. It was enough to unleash several problems, some of them are solved, some of them not. A larger collection of even wilder ones are always stuck in the box, and ready to invade this subject, as soon as the box is opened again.

5.4.2 What I learned

Problems are nevertheless the Sisyphus’s rock of engineers. And according to Albert Camus “The struggle itself to the summit is enough to fill a man’s heart. Sysiphus must be imagined happy”. Boxes like Pandora's are, in the end, excellent presents for engineers.

Because interesting it certainly was! Many problems encountered had been presented during one lecture or another that I have taken during the course of my studies. They seemed, presented on the paper, very rare problem, very theoretic and may only be present in the ‘warped spirit’ of the researchers. I now have proof that those problems are real ones, appearing much earlier than thought. I had the opportunity to develop my own solution to solve them.

I do not say that my solutions are perfect, certainly they are not. But some of them seem to work, and furthermore I acquired a broad understanding of the problems constructing this solution.

More specifically, I did in this six months many things that I had never done before: to build a documentation collection, to read many papers to gain knowledge about one subject, to write a literature survey. To think in terms of packages, of isolation, of interfaces, to organise objects coherently in super or sub classes. After all of this, I haven't started hearing voices and there is still only one consciousness in my head. I acquired a good experience of reading logs generated by various threads and reorganising them. I also learned to use the java debugger, which was completely new for me.

Finally, and I shall say it only once in this report, I learned how to speak Spanish whilst writing this in Chile. It doesn't have much to do with agents and algorithms, but it may be the greatest satisfaction associated with this work.

5.4.3 Acknowledgements

Thanks first of all to Prof. Alain Germond who motivated me to cross the ocean and come to Chile to do this work and thanks to Prof. Hugh Rudnick, for his wise advice, his assistance and his initiatives to help me understand Chile a bit better (Chile from the electrical point of view, but not only...)

Thanks to Elvira Kaegi, who took the time to speak with me in spite of the distance, and who gave me some more motivation at certain critical moments.


Thanks to Rodrigo Moreno, who, among others, invited me from the firsts days to join him and his colleges for the lunch, realising thereby a part of my integration into the university and the Chilean culture.

Thanks to Louisa, Maive and Adam and in particular to Sam, who helped me a little bit (note of Sam: “are you joking? We helped a lot!”) to edit the English of this text. Thanks to all people who supported me during six month and suffered my bad mood when this project was not working particularly well.

And finally, special thanks to Luc-André Burdet, who worked as final reader and corrector, even though he was finishing his own thesis at the time.

5.5 Final conclusion

The above material does not constitute a major improvement in the field of reconfiguration. No magic solution has been found and distribution networks may stay fairly quiet for the next little while. However, each month new publications announce the application of multi-agent and distributed methods to electrical networks in general [5.1, 5.2], and this revolution of distribution will not spare the electrical networks. The present work proposes to do a small part of the groundwork towards this achievement. Problems have been highlighted, possible solutions realised, ideas proposed. Results have been presented, under assumptions.

This project, through its current report, its documentation or its source code, proposes two methods that may have some benefits. Moreover, it serves as an introductive text to the world of distribution, for electricians or others.

Achevé le lundi 9 mai 2005, Santiago du Chili

Chapter 6 - Annexes 95

6. Annexes

6.1 References

[1.1] NORTH AMERICAN ELECTRIC RELIABILITY COUNCIL, “Technical Analysis of the August 14, 2003, Blackout: What Happened, Why, and What Did We Learn?“. Report to the NERC Board of Trustees by the NERC Steering Group, July 2004.

[1.2] Public Safety and Emergency Preparedness Canada, report of January 25th 2005 over incident IA05-001

[1.3] Bundesministerium für Wirtschaft und Arbeit, Referat IX A 2, "Zahlen und Fakten - Energiedaten", 2004.

[1.4] US Energy Information Administration, "Annual energy review 2003", http://www.eia.doe.gov/aer, 2004.

[1.5] LOI no 2000-108 du 10 février 2000 relative à la modernisation et au développement du service public de l'électricité, France.

[2.1] S. R. Cherkaoui, “Méthodes heuristiques pour la recherche de configurations optimales d’un réseau

électrique de distribution”, Thèse No 1058, EPFL, Lausanne, 1992. [2.2] Luenberger, D.G., “Introduction to linear and non-linear programming”, Addison-Wesley, 1973. [2.3] Clay Mathematics Institute Millennium’s problems. http://www.claymath.org/millennium/ [2.4] A. B. Morton, I. M. Y. Mareels, “An efficient brute-force solution to the network reconfiguration

problem”, IEEE Transactions On Power Delivery, Vol. 15, No. 3 2000. [2.5] A. Merlin, H. Back, “Search for a Minimal-Loss Operating Spanning Tree Configuration in an Urban

Power Distribution System”, Proc. of the 5th Power Systems Computation Conference, Cambrigde, 1975.

[2.6] D. Shirmohammadi, H. W. Hong, “Reconfiguration of electric distribution networks for resistive line losses reduction”, IEEE Transaction on Power Delivery, Vol. 4, No. 2, 1989.

[2.7] K. Nara, M. Kitagawa, “Distribution systems loss minimum reconfiguration by simulated annealing method”, IEE International Conference on Advances in Power System Control, Operation and Management, 1991.

[2.8] E. Miguez, J. Cidrás, E.D. Dorado, J.-L. Garcia-Dornelas, “An improved branchexchange algorithm for large-scale”, IEEE Transactions on Power Delivery, Vol. 17, No. 4, 2002.

[2.9] K.-H. Jung, H. Kim, Y. Ko, “Network reconfiguration algorithm for automated distribution systems based on artificial intelligence approach”, IEEE Transactions on Power Delivery, Vol. 8, No. 4, 1993.

[2.10] M. Eremia, J. Trecat, A. Germond, “Réseaux électriques – Aspects actuels”, Editura Tehnica Bucuresti, 2000.

[2.11] H. Kim, Y. Ko, K-H. Jung, “Artificial Neural-Network based feeder reconfiguration for loss

Chapter 6 - Annexes

96

reduction in distribution systems”, IEEE Transactions on Power Delivery, Vol. 8, No. 3, 1993. [2.12] D. Bouchard, A. Chikhani, V. L. John, M. M. A. Salama, “Applications of Hopfield Neural Networks

to Distribution Feeder Reconfiguration”, 1993. [2.13] Y. Fukuyama, H.-D. Chiang, “A Parallel Genetic Algorithm for service restoration in Electric Power

Distributions Systems”, 1995. [2.14] A. Moussa, M. El-Gammal, E. N. Abadía, A. I. Attia, “A Genetic Based Algorithm For Loss

Reduction in Distribution Systems”, ICCTA, 2004. [2.15] E.D. Dorado, J. Cidrás, E. Miguez, “Application of evolutionary algorithms for the planning", IEEE

Transactions on Power Delivery, Vol. 17, No. 3, 2002. [2.16] Y.-J. Jeon, J.-C. Kim, J.-O. Kim, J.-R. Shin, K. Y. Lee, “An efficient simulated annealing algorithm

for network reconfiguration”, IEEE Transactions on Power Delivery, Vol. 17, No. 4, 2002. [2.17] R. Ranjan, B. Venkatesh, D. Das, “Load Flow Algorithm of Radial Distribution Networks

Incorporating Composite Load Model”, International Journal of Power and Energy Systems, Vol. 23, No. 1, 2003.

[2.18] Conceptions d’algorithmes et applications, cours 1, Olivier Bodini [2.19] Philippe Dumas, INRIA, France, http://algo.inria.fr/dumas/DC/index_am.html [2.20] “Impact of Skype on Telecom Service Providers”, Evalueserve Report, January 2005. [2.21] J.-Y. Le Boudec, “Interconnection Layer 2: LAN and bridges”, lecture notes of “Computer

Networks”, EPFL, June 2003. [2.22] G. Tel. “Introduction to Distributed Algorithms”. CambridgeUniversity Press, 1994. [2.23] N. Lynch. “Distributed Algorithms”. Morgan Kaufmann Publishers, Inc., 1995. [2.24] V.C. Barbosa. “An Introduction to Distributed Algorithms”. MIT Press, Cambridge, MA, 1996. [2.25] M. J. Wooldrige, N. R. Jennings, “Intelligent agents: Theory and Practice”, Knowledge Engineering

Review, 10(2), 1995. [2.26] J. Lind, “Iterative Software Engineering for Multiagent Systems : The MASSIVE method”, Springer

Verlag, Berlin, 2001. [2.27] M. J. Wooldrige, N. R. Jennings, “Agent Theories, Architectures, and Languages: A Survey”. In M.

J. Wooldrige, N. R. Jennings, editors, Intelligent Agents. Springer- Verlag, Berlin, 1995. [2.28] K. C. Tsui, J. Liu, “Multiagent Diffusion and Distributed Optimization”, AAMAS’03, 2003. [2.29] J. Abril, F. Comellas, A. Cortés, J. Ozón, M. Vaquer, “A Multi-agent System for Frequency

Assignment in Cellular Radio Networks”, IEEE Transactions on Vehicular Technology, vol. 49, No. 5, 2000.

[2.30] K. Dorer, M. Calisti, “Agent-based Dynamic Transport Optimization”, Whitestein Technologies Technical Report, 2004.

[2.31] S. Kornienko, O. Kornienko, J. Priese, “Application of multi-agent planning to the assignment problem”, Computers in Industry, Vol. 54, Issue 3, 2004.

[2.32] T. Nagata, H. Watanabe, M. Ohno, H. Sasaki, “A Multi-Agent Approach to Power System Restoration”, IEEE Transactions on Power Systems, Vol. 17, No. 2, 2002.

[2.33] T. Nagata, Y. Tao, Y. Tahara, T. Aoyama, H. Fujita, M.Koaizawa, “Development of bulk power system restoration simulator by means of multi-agent approach”, Circuits and Systems, 2004. MWSCAS '04.

[2.34] M. Utatani, T. Nagata, H. Nakayama, Y. Nakamura, “A Multi-Agent Approach to Outage Work Scheduling for Electric Power System”, Transmission and Distribution Conference and Exhibition 2002: Asia Pacific. IEEE/PES.

[2.35] T. Nagata, M. Ohono, J. Kubokawa, H. Sasaki, H. Fujita, “A Multi-Agent Approach to Unit Commitment Problems”, Electrical Engineering in Japan Volume 141, Issue 2, 2002.

[2.36] T. Hiyama, D. Zuo, T. Funabashi, “Multi-Agent Based Control and Operation of Distribution System with Dispersed Power Sources”, Transmission and Distribution Conference and Exhibition 2002: Asia Pacific. IEEE/PES.

[2.37] M. Dorigo, L. M. Gambardella, “Ant Cologny System: A Cooperative Learning Approach to the Traveling Salesman Problem “,IEEE Transactions on Evolutionary Computation, Vol.1, No.1, 1997.

[2.38] C. A. Coello Coello, M. S. Lechuga, “MOSPO: A Proposal for Multiple Objective Particle Swarm Optimization”, IEEE, 2002.

Chapter 6 - Annexes 97

[2.39] J. E. Fieldsend, “Multi-objective particle swarm optimisation methods”, 2004. [2.40] Eric W. Weisstein. "Vertex Cover." From MathWorld--A Wolfram Web Resource.

http://mathworld.wolfram.com/VertexCover.html [2.41] F. Grandoni, J. Könemann, A. Panconesi, “Distributed Weighted Vertex Cover via

Maximal Matchings”, 2004. [2.42] D.S. Hirschberg, and J.B. Sinclair. “Decentralized extrema-finding in circular configurations of

processors”. In Communications of the ACM 23(11), pages 627-628, November 1980. [2.43] G. Pandurangan, P. Raghavan, E. Upfal, "Building Low-Diameter P2P Networks",

Proceedings of the IEEE Symposium on Foundations of Computer Science, 2001. [2.44] B. Raney, K. Nagel, “An Agent-Based Simulation Model of Swiss Travel: First Results”, STRC 03

Conference paper, March 2003. [2.45] C. Mangione, “Performance tests show Java as fast as C++”, javaworld.com, February 1998. [3.1] Java Object Serialization Specification version 1.5.0,http://java.sun.com, 2004. [5.1] B. Zhao, C. X. Guo, and Y. J. Cao, "A Multiagent-Based Particle Swarm Optimization Approach for

Optimal Reactive Power Dispatch", IEEE Transactions on Power Systems, Vol. 20, No. 2, 2005. [5.2] M. M. Nordman and M. Lehtonen, "Distributed Agent-Based State Estimation for Electrical

Distribution Networks", IEEE Transactions on Power Systems, Vol. 20, No. 2, 2005.

6.2 More information The electronic version of this thesis provides references on source and project files, Javadoc documentation, and network examples. It may be found at the following address: http://wamli.olympe.ch/rapports/index.html

Application of multi-agent techniques to the optimal...

Documents

Transcript of Application of multi-agent techniques to the optimal...