irriis integrated risk reduction of information …integrated project irriis integrated risk...

Integrated Project

IRRIIS

Integrated Risk Reduction of Information-based

Infrastructure Systems

Deliverable D 1.3.2

“List of available and suitable simulation components”

Version V 1.0

Due date of deliverable: 31/7/2006

Actual submission date: 18/9/2006

Organisation name of lead contractor for this deliverable:

Ecole Nationale Supérieure des Télécommunications

(ENST)

Dissemination Level

PU Public

Start date of project: 01 February 2006 Duration: 3 years

Table of Contents

2

Authors Sandrine Duflos (ENST)

Gwendal Le Grand (ENST)

Alpha Amadou Diallo (ENST)

Claude Chaudet (ENST)

Artur Hecker (ENST)

Claudio Balducelli (ENEA)

Felix Flentge (Fraunhofer IAIS)

Christine Schwaegerl (Siemens)

Olaf Seifert (Siemens)

Work package WP 1.3 : “Requirements for a synthetic simulation environment

SYNTEX”

Task Task 1.3.2: “Selection of available and suitable simulation components”

Quality Manager Bernard Burtschy (ENST)

Approval Date 07/08/2006

Remarks none

Internal Review Dirk Stolk (TNO)


Remarks

Internal Review Eric Luiijf (TNO)/ SP1 leader


Remarks

Table of Contents

3

Table of Contents

TABLE OF CONTENTS..............................................................................................................3

FIGURES .......................................................................................................................................8

TABLES .......................................................................................................................................10

ABBREVIATIONS .....................................................................................................................11

1. INTRODUCTION...............................................................................................................14

2. METHODOLOGICAL APPROACH...............................................................................15

3. SIMULATIONS TOOLS PRINCIPLES ..........................................................................16

4. SYNTEX OVERVIEW.......................................................................................................17

4.1 SYNTEX design .............................................................................................................................. 17 4.1.1 Synthetic infrastructure simulator.............................................................................................. 17

4.1.1.1 SYNTEX as an integrated simulator .............................................................................................. 18 4.1.1.2 SYNTEX as an overlay for scenario information exchange........................................................... 20

4.1.2 The market platform to share stakeholder data.......................................................................... 21 4.1.3 The global picture ...................................................................................................................... 23

4.2 Scenarios within SYNTEX ............................................................................................................. 24 4.2.1 Scenario generation ................................................................................................................... 24

4.2.1.1 Generality about attack and fault scenarios in SYNTEX ............................................................... 24 4.2.1.2 Attack and fault trees...................................................................................................................... 25 4.2.1.3 Textual representation of a Tree..................................................................................................... 27 4.2.1.4 Generic Fault Tree example ........................................................................................................... 27 4.2.1.5 Generic Attack Tree example ......................................................................................................... 29 4.2.1.6 Combination of attack and fault scenarios...................................................................................... 30 4.2.1.7 Need of a tool for scenario tree editing and execution ................................................................... 32

4.2.2 Scenario description .................................................................................................................. 33

5. REQUIREMENTS FOR SIMULATION WITHIN SYNTEX .......................................36

5.1 Global CI simulation requirements............................................................................................... 36 5.1.1 Modelling requirements............................................................................................................. 36 5.1.2 Simulation requirements............................................................................................................ 38

5.2 SYNTEX requirements................................................................................................................... 39 5.2.1 Requirements relative to SYNTEX as an integrated simulator ................................................. 39 5.2.2 Requirements relative to SYNTEX as an overlay for scenario information exchange ............. 40

5.3 Requirements derived from Deliverable D.1.3.1 .......................................................................... 40

5.4 Conclusion ....................................................................................................................................... 41

Table of Contents

4

6. AVAILABLE TOOLS TO SIMULATE (INTERCONNECTED) CIS OF A SINGLE SECTOR ......................................................................................................................................43

6.1 Introduction..................................................................................................................................... 43

6.2 Telecommunications networks simulation tools........................................................................... 43 6.2.1 Introduction ............................................................................................................................... 43 6.2.2 OPNET and the OPNET Modeler ............................................................................................. 43

6.2.2.1 Description ..................................................................................................................................... 43 6.2.2.2 Suitability for modelling................................................................................................................. 44 6.2.2.3 Suitability for simulation................................................................................................................ 49 6.2.2.4 Conclusion...................................................................................................................................... 52

6.2.3 The NS-2 simulator and the VINT project ................................................................................ 53 6.2.3.1 Description ..................................................................................................................................... 53 6.2.3.2 Suitability for modelling................................................................................................................. 54 6.2.3.3 Suitability for simulation................................................................................................................ 56 6.2.3.4 Conclusion...................................................................................................................................... 59

6.2.4 The QualNet Network Simulator............................................................................................... 60 6.2.4.1 Description ..................................................................................................................................... 60 6.2.4.2 Suitability for modelling................................................................................................................. 61 6.2.4.3 Suitability for simulation................................................................................................................ 62 6.2.4.4 Conclusion...................................................................................................................................... 66

6.2.5 The OMNeT++ simulator .......................................................................................................... 67 6.2.5.1 Description ..................................................................................................................................... 67 6.2.5.2 Suitability for modelling................................................................................................................. 68 6.2.5.3 Suitability for simulation................................................................................................................ 69 6.2.5.4 Conclusion...................................................................................................................................... 73

6.2.6 The J-Sim simulator................................................................................................................... 75 6.2.6.1 Description ..................................................................................................................................... 75 6.2.6.2 Suitability for modelling................................................................................................................. 75 6.2.6.3 Suitability for simulation................................................................................................................ 76 6.2.6.4 Conclusion...................................................................................................................................... 77

6.2.7 The SSF framework................................................................................................................... 78 6.2.7.1 Description ..................................................................................................................................... 78 6.2.7.2 Suitability for modelling................................................................................................................. 79 6.2.7.3 Suitability for simulation................................................................................................................ 79 6.2.7.4 Conclusion...................................................................................................................................... 80

6.2.8 The Dynamic Network Emulation Backplane Project............................................................... 81 6.2.8.1 Description ..................................................................................................................................... 81 6.2.8.2 Suitability for modelling................................................................................................................. 82 6.2.8.3 Suitability for simulation................................................................................................................ 83 6.2.8.4 Conclusion...................................................................................................................................... 83

6.2.9 Summary.................................................................................................................................... 83

6.3 Electrical networks-specific simulation tools................................................................................ 85 6.3.1 Introduction ............................................................................................................................... 85 6.3.2 The Siemens Power System Simulation Software..................................................................... 85 6.3.3 PSSTMNetomac .......................................................................................................................... 86

6.3.3.1 Description ..................................................................................................................................... 86 6.3.3.2 Suitability for modelling................................................................................................................. 89 6.3.3.3 Suitability for simulation................................................................................................................ 92 6.3.3.4 Conclusion...................................................................................................................................... 97

6.3.4 PSSTMSINCAL .......................................................................................................................... 98 6.3.4.1 Description ..................................................................................................................................... 98 6.3.4.2 Suitability for modelling............................................................................................................... 100 6.3.4.3 Suitability for simulation.............................................................................................................. 100 6.3.4.4 Conclusion.................................................................................................................................... 104

6.3.5 The PowerWorld simulator...................................................................................................... 106 6.3.5.1 Description ................................................................................................................................... 106 6.3.5.2 Suitability for modelling............................................................................................................... 106

Table of Contents

5

6.3.5.3 Suitability for simulation.............................................................................................................. 107 6.3.5.4 Conclusion.................................................................................................................................... 108

6.3.6 The PSCAD/EMTDC Simulator ............................................................................................. 109 6.3.6.1 Description ................................................................................................................................... 109 6.3.6.2 Suitability for modelling............................................................................................................... 110 6.3.6.3 Suitability for simulation.............................................................................................................. 111 6.3.6.4 Conclusion.................................................................................................................................... 114

6.3.7 The SEPIA simulator............................................................................................................... 115 6.3.7.1 Description ................................................................................................................................... 115 6.3.7.2 Suitability for modelling............................................................................................................... 115 6.3.7.3 Suitability for simulation.............................................................................................................. 116 6.3.7.4 Conclusion.................................................................................................................................... 118

6.3.8 Summary.................................................................................................................................. 119

6.4 Conclusion ..................................................................................................................................... 121

7. AVAILABLE TOOLS TO SIMULATE (INTERCONNECTED) CIS OF DIFFERENT SECTORS ..........................................................................................................122

7.1 Introduction................................................................................................................................... 122

7.2 Tools based on Agent-based Modelling....................................................................................... 122 7.2.1 Introduction ............................................................................................................................. 122 7.2.2 The North Carolina University simulation tool ....................................................................... 123

7.2.2.1 Description ................................................................................................................................... 123 7.2.2.2 Suitability for modelling............................................................................................................... 124 7.2.2.3 Suitability for simulation.............................................................................................................. 125 7.2.2.4 Conclusion.................................................................................................................................... 126

7.2.3 The Electric Power and Communication syncHronizing Simulator (EPOCHS)..................... 127 7.2.3.1 Description ................................................................................................................................... 127 7.2.3.2 Suitability for modelling............................................................................................................... 128 7.2.3.3 Suitability for simulation.............................................................................................................. 128 7.2.3.4 Conclusion.................................................................................................................................... 129

7.2.4 The Critical Infrastructure Simulation by Interdependent Agents (CISIA)............................. 130 7.2.4.1 Description ................................................................................................................................... 130 7.2.4.2 Suitability for modelling............................................................................................................... 131 7.2.4.3 Suitability for simulation.............................................................................................................. 133 7.2.4.4 Conclusion.................................................................................................................................... 133

7.2.5 Conclusion ............................................................................................................................... 135

7.3 Tools based on mathematical models .......................................................................................... 136 7.3.1 Introduction ............................................................................................................................. 136 7.3.2 The ENEA Mathematical model ............................................................................................. 136


7.3.3 The mathematical model of the Dresden Technological University, the Zilina University and the Collegium Budapest ....................................................................................................................... 138


7.3.4 Formal verification .................................................................................................................. 140 7.3.4.1 Description ................................................................................................................................... 140 7.3.4.2 Suitability for modelling............................................................................................................... 141 7.3.4.3 Suitability for simulation.............................................................................................................. 141 7.3.4.4 Conclusion.................................................................................................................................... 142

7.3.5 Summary.................................................................................................................................. 142

Table of Contents

6

7.4 Conclusion ..................................................................................................................................... 142

8. SUMMARY OF PROS AND CONS FEATURES OF SIMULATION COMPONENTS TO INTEGRATE WITHIN THE SYNTEX...........................................................................144

9. CONCLUSION..................................................................................................................155

10. GLOSSARY...................................................................................................................158

11. REFERENCES..............................................................................................................163

11.1 General references ........................................................................................................................ 163

11.2 Scenario generation references .................................................................................................... 164

11.3 Telecommunication network simulator references.................................................................... 164 11.3.1 OPNET references ................................................................................................................... 164 11.3.2 NS-2 references ....................................................................................................................... 164 11.3.3 QualNet/GloMoSim references ............................................................................................... 165 11.3.4 OMNeT++ references.............................................................................................................. 165 11.3.5 J-Sim references ...................................................................................................................... 166 11.3.6 SSF references ......................................................................................................................... 166 11.3.7 Dynamic Network Emulation Backplane project References ................................................. 166

11.4 Electrical network simulator references ..................................................................................... 167 11.4.1 NETOMACS references.......................................................................................................... 167 11.4.2 SINCAL references ................................................................................................................. 167 11.4.3 PowerWorld references ........................................................................................................... 167 11.4.4 PSCAD references ................................................................................................................... 167 11.4.5 SEPIA references..................................................................................................................... 167

11.5 ABM references............................................................................................................................. 167 11.5.1 General ABM references ......................................................................................................... 168 11.5.2 The North Carolina University ABM simulation tool ............................................................. 168 11.5.3 EPOCHS references ................................................................................................................ 169 11.5.4 CISIA references ..................................................................................................................... 169

11.6 Mathematical models references ................................................................................................. 169

12. APPENDIXES ...............................................................................................................170

12.1 Appendix 1 - Example of NS script ............................................................................................. 170

12.2 Appendix 2 - Explanation of calculation methods for electric power systems ........................ 172 12.2.1 Load flow calculation .............................................................................................................. 172 12.2.2 Unbalanced load flow calculations .......................................................................................... 172 12.2.3 Optimised load flow ................................................................................................................ 172 12.2.4 Short circuit calculation........................................................................................................... 172 12.2.5 Optimum sectionalising points ................................................................................................ 173 12.2.6 Rating of low voltage networks............................................................................................... 173 12.2.7 Multiple/general faults............................................................................................................. 173 12.2.8 Stability (RMS)........................................................................................................................ 174 12.2.9 Electromagnetic transients (EMT)........................................................................................... 174 12.2.10 Eigenvalue/modal analysis ...................................................................................................... 174

Table of Contents

7

12.2.11 Harmonics................................................................................................................................ 174 12.2.12 Ripple control .......................................................................................................................... 175 12.2.13 Reactive power optimisation ................................................................................................... 175 12.2.14 Line constants .......................................................................................................................... 175 12.2.15 Protection simulation modules ................................................................................................ 175 12.2.16 Motor start ............................................................................................................................... 177 12.2.17 Load profile ............................................................................................................................. 177 12.2.18 Load development ................................................................................................................... 177 12.2.19 Contingency analysis ............................................................................................................... 178 12.2.20 Reliability ................................................................................................................................ 178 12.2.21 Cost calculation ....................................................................................................................... 179

12.3 Appendix 3 - Further PSS family ................................................................................................ 180 12.3.1 PSS™E (PSS/E) ...................................................................................................................... 180

12.3.1.1 General description....................................................................................................................... 180 12.3.1.2 Integrated, easy-to- use features ................................................................................................... 180 12.3.1.3 Python scripting............................................................................................................................ 181 12.3.1.4 User-Written Models .................................................................................................................... 181 12.3.1.5 MATLAB-Simulink ® PSS/E Interface....................................................................................... 181 12.3.1.6 Optimal Power Flow (OPF).......................................................................................................... 181 12.3.1.7 PSS™E Balanced or Unbalanced Fault Analysis......................................................................... 182 12.3.1.8 PSS™E Dynamic Simulation....................................................................................................... 182 12.3.1.9 PSS™E Extended Term Dynamic Simulation ............................................................................. 183

12.3.2 PSS™MUST - On-line tap and phase-shifting transformer models........................................ 183 12.3.3 PSS™TPLAN.......................................................................................................................... 183 12.3.4 PSS™Engines.......................................................................................................................... 184 12.3.5 PSS™ADEPT.......................................................................................................................... 184 12.3.6 PSS™ODMS ........................................................................................................................... 184 12.3.7 MOD™.................................................................................................................................... 184 12.3.8 PSS™LMP .............................................................................................................................. 185

12.4 Appendix 4 - EPOCHS Experiments .......................................................................................... 186 12.4.1 Backup Protection Case........................................................................................................... 186 12.4.2 SPS Case Overview ................................................................................................................. 187 12.4.3 An Algorithm to Estimate a System's Disturbance Size.......................................................... 188 12.4.4 The System Studied and Agent-Based SPS Scheme ............................................................... 188

12.4.4.1 The System Studied...................................................................................................................... 188 12.4.4.2 Description of the SPS Architecture............................................................................................. 189

12.4.5 Simulation Results ................................................................................................................... 189

Figures

8

Figures

Figure 1: SYNTEX as an integrated simulator .............................................................................18 Figure 2: SYNTEX as an overlay for scenario information exchange .........................................18 Figure 3: Examples of canonical architectures .............................................................................19 Figure 4: Common virtual market.................................................................................................21 Figure 5: Evolution of trust over time – trust is lost faster than it is gained .................................23 Figure 6: Evolution and convergence of trust in time...................................................................23 Figure 7: Scenario generation and description..............................................................................24 Figure 8: Example of scenario behaviour .....................................................................................25 Figure 9: Structure of an attack tree example ...............................................................................26 Figure 10: Structure of a fault tree example..................................................................................26 Figure 11: Example of generic fault tree for telecom and electrical CIs ......................................28 Figure 12: Two possible fault scenarios generated by the fault tree.............................................29 Figure 13: Example of generic attack tree for telecom and electrical power CIs .........................30 Figure 14: Three possible fault scenarios generated by the attack tree.........................................30 Figure 15: Combination of attack and fault scenarios...................................................................31 Figure 16: Supporting functions for the experimenters ................................................................32 Figure 17: A LAMPS fragment using the four basic concepts. ....................................................34 Figure 18: The behaviour of a generator corresponding to a request to change its capacity ........34 Figure 19: The OPNET Project Editor interface and example......................................................45 Figure 20: The OPNET PDF editor interface................................................................................46 Figure 21: OPNET Node Editor interface.....................................................................................47 Figure 22: OPNET Process Editor interface .................................................................................48 Figure 23: The different OPNET model levels [OPNet]...............................................................49 Figure 24: The OPNET Probe Editor interface.............................................................................50 Figure 25: The OPNET Simulation Tool interface .......................................................................50 Figure 26: Example of results analysis with the OPNET Analysis Tool ......................................51 Figure 27: Simplified user’s view of NS-2 [NStut] ......................................................................54 Figure 28: Simulated network and traffic with NS-2....................................................................55 Figure 29: The NAM user interface ..............................................................................................57 Figure 30: Example of simulation visualisation with NAM .........................................................57 Figure 31: Generic NS script structure..........................................................................................58 Figure 32: The NAM editor interface ...........................................................................................58 Figure 33: The QualNet workplace interface................................................................................61 Figure 34: Example of topology description with the QualNet scenario designer .......................63 Figure 35: Example of dynamic graphs generated by the QualNet Animator ..............................64 Figure 36: Example of use of the QualNet Analyser ....................................................................65 Figure 37: Example of use of the QualNet Packet Tracer.............................................................65 Figure 38: The OMNeT++ GNED editor interface.......................................................................69 Figure 39: Example of simulation execution with OMNeT++ Tkenv..........................................71 Figure 40: Output vector files visualisation with OMNeT++ Plove.............................................72 Figure 41: Examples of output scalar file visualisation in OMNeT++.........................................73 Figure 42: Components and composite components in J-Sim ......................................................75 Figure 43: J-Sim Graphical editor interface..................................................................................76 Figure 44: DNEB Backplane system Architecture .......................................................................82 Figure 45: Overview of main PSS software topics. ......................................................................86 Figure 46: Frequency domains for NETOMAC simulation..........................................................87 Figure 47: NETOMAC program configurations...........................................................................88

Figures

9

Figure 48: Demonstration of NETOMAC simulation models ......................................................89 Figure 49: Possibilities offered by NETOMAC for simulating electrical systems.......................93 Figure 50: NETOMAC Eigenvalue calculation ............................................................................95 Figure 51: Graphical evaluation of load centres. ........................................................................103 Figure 52: Graphical representation of network with graphical evaluation................................104 Figure 53: Example of PowerWorld Simulation.........................................................................107 Figure 54: The PSCAD/EMTDC Component Editor .................................................................111 Figure 55: The PSCAD/EMTDC GUI ........................................................................................112 Figure 56: The Phasor Meter tool ...............................................................................................113 Figure 57: The transmission line constants viewer .....................................................................113 Figure 58: Example of scenario design with the scenario editor ................................................117 Figure 59: Examples of Load (on left) and Generator Company (on right) properties ..............117 Figure 60: Example of simulation result display (competition between two generator company agents). ........................................................................................................................................118 Figure 61: The Agent-based simulation environment architecture.............................................124 Figure 62: Example of dependency simulation...........................................................................125 Figure 63: EPOCHS general architecture ...................................................................................128 Figure 64: CISIA agent internal model. ......................................................................................132 Figure 65: CISIA agent input and output interfaces ...................................................................132 Figure 66: Fault propagation in CISIA .......................................................................................133 Figure 67: Graphical visualisation of infrastructures..................................................................180 Figure 68: Fig. 5. A 400 kV power system with an agent-based backup protection system. .....187 Figure 69: (a) A primary relay misoperates at time 0.2 by setting a trip signal. (b) A traditional backup protection system would allow the breaker to trip, cutting power across the line. (c) The agent-based protection system communicates with its neighbours and determines that the trip signal should be blocked. (d) The agent-based system blocks the false trip signal. ...................187 Figure 70: Rotor angles with transient instability induced by a disturbance ..............................190 Figure 71: (a) The system remains stable after generation rejection. (b) The system undergoes an unacceptable frequency decrease. ...............................................................................................191 Figure 72: Remote load shedding maintains the frequency above a preset level .......................192 Figure 73: Comparison of the SPS operation with different levels of loss rate ..........................193

Tables

10

Tables

Table 1: Example of the textual representation of an attack tree ..................................................27 Table 2: OPNET modelling suitability..........................................................................................52 Table 3: OPNET simulation suitability.........................................................................................53 Table 4: NS-2 modelling suitability ..............................................................................................59 Table 5: NS-2 simulation suitability .............................................................................................60 Table 6: QualNet modelling suitability.........................................................................................66 Table 7: QualNet simulation suitability ........................................................................................67 Table 8: OMNeT modelling suitability.........................................................................................74 Table 9: OMNeT simulation suitability ........................................................................................74 Table 10: J-Sim modelling suitability ...........................................................................................77 Table 11: J-Sim simulation suitability ..........................................................................................78 Table 12: SSF modelling suitability..............................................................................................80 Table 13: SSF simulation suitability .............................................................................................81 Table 14: Comparison of the telecom tools modelling suitability ................................................84 Table 15: Comparison of the telecom tools simulation suitability................................................85 Table 16: NETOMAC modelling suitability.................................................................................98 Table 17: NETOMAC simulation suitability ................................................................................98 Table 18: SINCAL modelling suitability ....................................................................................105 Table 19: SINCAL simulation suitability ...................................................................................105 Table 20: PowerWorld modelling suitability ..............................................................................108 Table 21: PowerWorld simulation suitability .............................................................................109 Table 22: PSCAD/EMTDC modelling suitability ......................................................................114 Table 23: PSCAD/EMTDC simulation suitability......................................................................114 Table 24: SEPIA modelling suitability .......................................................................................119 Table 25: SEPIA simulation suitability.......................................................................................119 Table 26: Comparison of the electric tools modelling suitability ...............................................120 Table 27: Comparison of the electric tools simulation suitability ..............................................121 Table 28: North Carolina University ABM tool modelling suitability .......................................126 Table 29: North Carolina University ABM tool simulation suitability ......................................127 Table 30: EPOCHS modelling suitability ...................................................................................130 Table 31: EPOCHS simulation suitability ..................................................................................130 Table 32: CISIA modelling suitability ........................................................................................134 Table 33: CISIA simulation suitability .......................................................................................135 Table 34: Modelling suitability of the ENEA model ..................................................................137 Table 35: Simulation suitability of the ENEA model .................................................................138 Table 36: Modelling suitability of the mathematical model .......................................................140 Table 37: Simulation suitability of the mathematical model ......................................................140 Table 38: Pros and conf of suitable simulation components.......................................................144 Table 39: Simulation tools possible integration..........................................................................154

Abbreviations

11

Abbreviations

ABM Agent-Based Modelling AC Alternating Current ACA Autonomous Component Architecture ACM Association for Computer Machinery ANSI American National Standard Institute API Application Programming Interface ASCII American Standard Code for Information Interchange ASP Application Service Provider ATC Available Transfer Capability ATM Asynchronous Transfer Mode CAD Computer Assisted Design CBQ Class-Based Queuing BOSL Block-Oriented Simulation Language BPF Berkley Packet Filter CAS Complex Adaptive Systems CBR Constant Bit Rate CI Critical Infrastructure CIM Common Information Model CISIA Critical Infrastructure Simulation by Interdependent Agents COM Component Object Model CPU Central Processing Unit CSMF Conceptual Schema Modelling Facility DaSSF Dartmouth Scalable Simulation Framework DC Direct Current DHS Department of Homeland Security DML Domain Modelling Language DMS Distribution Management System EDC Electronic Dispersion Compensation EMT ElectroMagnetic transients EMTDC ElectroMagnetic Transients including DC EPOCHS Electric Power and Communication syncHronizing Simulator EPRI Electric Power Research Institute FACTS Flexible AC Transmission Systems FCITC First Contingency Incremental Transfer Capability FFT Fast Fourier Transformation FTP File Transfer Protocol GIS Geographic Information System GloMoSim Global Mobile Simulation GTO Gate Turn-Off GUI Graphical User Interface HC Hierarchical Component HLA High Level Architecture HTML HyperText Markup Language HVDC High-Voltage DC Hz Hertz IEC International Electrotechnical Commission IEEE Institute for Electrical and Electronic Engineer

Abbreviations

12

IGBT Insulated Gate Bipolar Transistor IP Internet Protocol IRRIIS Integrated Risk Reduction for Information-based Infrastructure Systems IT Information Technology JADE Java Agent DEvelopment framework J-Sim Java Simulator LAMPS Language for Agent-based Simulation of Processes and Scenarios LAN Local Area Network LCCI Large Complex Critical Infrastructure MAC Medium Access Control MANET Mobile Ad-hoc NETwork MFC Microsoft Foundation Class MPLS Multi-Protocol Label Switching MW MegaWattNAM Network Animator NED NEtwork Description NETOMAC Network Torsion Machine Control NS Network Simulator ODBC Open DataBase Connectivity OLE Object Linking and Embedding OMT Object Model Template OO Object Oriented OPF Optimal Power Flow OPNET OPen NETwork OS Operating System O-TCL Object-oriented Tool Command Language PARSEC PARallel Simulation Environment for Complex Systems PDF Probability Density Function PDNS Parallel and Distributed NS PGP Pretty Good Privacy PSCAD Power System Computer Aid Design PSLF Positive Sequence Load Flow software PSS Power System Simulation PTDF Power Transfer Distribution Factor QoS Quality of Service RED Random Early Detection REPAST REcursive Porous Agent Simulation Toolkit RFID Radio Frequency Identification RTI Real Time Infrastructure RUV RUntime Virtual SCADA Supervisory Control and Data Acquisition SEPIA Simulator for Electric Industry Agents SINCAL Siemens Network Calculation SQL Structured Query Language SSF Scalable Simulation Framework SSR Sub-Synchronous Resonance STATCOM STATic reactive COMpensation SVC Static Var Compensator SYNTEX Synthetic Simulation Environment TCL Tool Command Language TCP Transmission Control Protocol TE Top Event

Abbreviations

13

TIF Telephone Interference Factor TISN Trusted Information Sharing Network THD Total Harmonic Distorsion THFF Telephone Harmonic Form Factor TTC Total Transfer Capability UDP User Datagram Protocol UFLS UnderFrequency Load Shedding VBR Variable Bit Rate VDE Verband Der Elektrotechnik, elektronik und informationstechnik (Association for Electrical, Electronic and Information Technologies) VINT Virtual-Inter-Network Test bed WYSIWYG What You See Is What You Get XML Extensible Markup Language

Introduction

14

1. Introduction

The well being of our societies in terms of economy, politics, environment, and population safety depends on critical infrastructures. These infrastructures (e.g. energy supply, telecommunications, water supply, transportation, etc.) are highly interconnected and interdependent. In other words, if disruptions occur in one infrastructure, they can cause disruptions in the others and vice-versa. Examples of such events include blackouts observed in North America and Italy in 2003. These blackouts were spectacular because the failure happened in the electricity supply infrastructure, i.e. at the centre of all other infrastructures. In addition, the large and complex critical infrastructures (LCCIs) are more and more interdependent. For instance, telecommunication infrastructures are increasingly critical for other infrastructures because they are used for monitoring and supervision.

To avoid the repetition of past events, electrical blackouts or telecom outages, a good understanding of the LCCIs’ behaviour is essential to prevent possible cascading effects. Therefore, a correct modelling of LCCIs, of their vulnerabilities and their dependencies, together with a correct simulation of their behaviour, disruption, and resulting (cascading) effects are essential.

The purpose of this document is to identify, to list and to compare tools and components suitable for simulation of critical infrastructures. Those must be suitable to model and simulate electricity supply and telecommunication critical infrastructures (CIs), their (inter)dependencies and behaviour (normal CIs behaviour as well as behaviour in case of failure by identifying the cascading effects). Suitable tools will then be associated and integrated within SYNTEX.

Subsequent sections of this document are organised in the following way: first, we present the approach we follows to compile this document. Then, Section 0 details the principle of simulation tools. Section 4 presents an overview of SYNTEX to understand this synthetic simulation environment and to identify the simulation features that are important when designing SYNTEX. These requirements are depicted in Section 5. Section 6 details the features of the simulation tools that are suitable to simulate (interconnected) CIs of a single sector (either telecommunications or electric power). Section 7 then concentrates on simulation tools suitable to simulate (interconnected) CIs of different sectors. Section 8 resumes the applicability of each simulation component to the proposed SYNTEX designs and pros and cons of each studied simulator. Finally, Section 9 concludes the document with a summary of the different studied simulator features suitable for their use within SYNTEX.

Methodological approach

15

2. Methodological approach

To compile the list of available and suitable simulation components, several points were essential.

First, to identify simulators suitable for integration within the SYNTEX, it was essential to determine what the SYNTEX is and therefore what the features a simulator must have to be suitable. This problem was subject of discussions at the beginning of this work. A first proposition of our view of the SYNTEX was presented during the Rome meeting (6-7 April 2006).

At the same time, we started our identification of possible simulation tools. We first joined our knowledge on modelling and simulation subjects and identified a set of possible telecommunications simulators. We completed this list with searches on the Internet and on research organisation libraries like IEEE and ACM. We also discussed with telecom and electric supply stakeholders to determine the simulators they use. In the telecom sector, it turns out that the identified simulators were included in the ones we listed.

The IRRIIS consortium identified the two main possible views of the SYNTEX presented in this document, and a set of requirements to determine the suitability of each simulation tool.

We also propose a non-exhaustive list of simulation tools. A large number of simulators exists and was studied without being presented in the document due to their lack of suitability or of documentation. Therefore we propose a list of tools that are suitable for the possible SYNTEX views we identified, and tools that includes interesting features to integrate within the SYNTEX or to use as reflexion basis.

Simulations tools principles

16

3. Simulations tools principles

A simulator is a tool that tries to mimic the behaviour of a system. Two types of simulators are distinguished: continuous time based simulators and discrete event based simulators. Most of the available simulation tools are discrete event simulators.

In continuous simulation, the system behaviour is represented by differential equations and the simulation consists in solving the equation.

In discrete event simulation, the system behaviour is described as a series of events that must be processed at a discrete point of the simulated time and that take a certain amount of real time. Events are managed by an event scheduler enabling usually offline simulations. Nevertheless, some simulators integrate real-time event schedulers permitting online simulations. Online simulation requires taking into account inputs from the real network or from an application and the output of data that will be re-injected in the real network or sent to the application.

Discrete event simulation tools are generally organised in the same manner. They are composed of modelling libraries and of a simulation engine. The modelling libraries represent the available models to describe the system to simulate (e.g. to represent network elements, links, protocols or applications). The simulation engine executes the simulation scenario (topology and system organisation), and the scenario behaviour (description of what happens, where and when). A simulator generally takes the scenario and the scenario behaviour as input and generates output traces containing the simulation results.

Depending on simulators, the description of scenario and scenario behaviour can be done manually by writing a script or a simulation code file, or in a simplified way through a graphical user interface (GUI). A GUI may also be used for simulation execution or for simulation result display and analysis. Some other simulators also propose a direct generation of scenario.

The simulation time depends on the number of events to process and the complexity of calculation required per event. So, the larger and the more complex a system is, the longer the simulation duration will be. To solve this problem, simulation tools propose various solutions like for example a hierarchical organisation of the model (an entity can represent a sub-model) to withstand space explosion, or parallel and distributed simulation (distribution of the simulation on several processors or workstations) to reduce the simulation duration.

Since the goal of this document is to list and examine suitable simulation tools and components to integrate into SYNTEX, in the following section we will describe what SYNTEX actually is or may be. We will denote by Model the description of a given topology, i.e. the nodes and links involved. Modelling will denote the action of representing a real topology in a given formalism. A scenario is a set of events happening on a model, for instance malfunctioning of one node at a certain date. Finally, Simulation is the computation of the results of a given scenario on a model. Simulation is performed by a tool called a Simulator.

SYNTEX overview

17

4. SYNTEX overview

SYNTEX is defined as a synthetic environment for CI simulation that may simulate one or more critical infrastructure(s) and their dependencies. SYNTEX could therefore be designed in various ways, which are presented in the following subsection. In the second subsection, we describe how to generate and characterise various scenarios to represent the behaviour of several types of CIs.

4.1 SYNTEX design

Such a simulator can be used at least in two different ways:

• to plan infrastructure resources prior to deployment (although there is already plethora of internal infrastructure simulators);

• to assess and quantify the impact of failures and instabilities attached to the dependencies on external infrastructures and to determine appropriate reconfiguration scenarios and give recommendations on the most appropriate reactions, if coupled properly to a monitoring tool.

According to the different functionalities of the SYNTEX, different actors may use SYNTEX. These actors are described in Chapters 2 and 4.2 of deliverable D1.3.1 “Catalogue of requirements for SYNTEX” [D.1.3.1].

We first present the different views of SYNTEX design and then how information between stakeholders may be exchanged.

4.1.1 Synthetic infrastructure simulator

Two main possible ways were identified to design SYNTEX. The first one consists of integrating SYNTEX within CIs and simulating all CIs and their dependencies (as dependency flows). It is represented on Figure 1. In this case, two paths are possible: the full design of a new integrated simulator or the improvement of an existing and generic simulator. In the second way, each CI has its own simulator and SYNTEX is designed as an overlay to exchange scenario information among the CI simulators. This scenario is represented in Figure 2. Both alternatives are detailed in the following subsections.

SYNTEX overview

SYNTEX

stakeholder stakeholder stakeholder stakeholder

…

dependency flowcanonical architectures

Figure 1: SYNTEX as an integrated simulator

SYNTEX

…

stakeholder Simulator resultssimulator input (scenario)

Specific Simulator APINS API OPNET API

input

18

…

CI simulator CI simulator CI simulator CI simulator

Scenario translation module Simulation results getting module

the best way for a safe exchange of

information ?

SINCAL API

Figure 2: SYNTEX as an overlay for scenario information exchange

4.1.1.1 SYNTEX as an integrated simulator

In this first vision, SYNTEX is a global simulator that is integrated to every CI. In other words, SYNTEX has a unique interface, running in each CI. All these instances are able to communicate together and exchange information on the CI they belong to. No obvious link exists with already used simulators. Conversion scripts or dialog modules can however be imagined to avoid re-description of every CI topology.

This approach requires a high level representation of flows and system nodes, regardless of the infrastructure they belong to. Whatever hierarchical level is examined within a critical infrastructure, it is possible to represent it as a composition of several sets of canonical architectures with intrinsic properties [LeG04].

Therefore, infrastructures can be decomposed in interconnected canonical architectures, and it is possible to develop specific, standard and abstract security measures for each canonical architecture, depending on parameters such as the context of the fault and the nature of the flow.

SYNTEX overview

Figure 3 represents a non-exhaustive set of simple graphs representing canonical architectures. In this figure, nodes represent either physical or management entities or a compound of these entities; links represent flows and services provided to or by a node. Dependency flows can be represented by the same means.

Figure 3: Examples of canonical architectures

This approach has two main characteristics: first, canonical architectures are flow-oriented (links in the figure can refer either to intra or inter-dependency flows); second, canonical architectures are generic (entities of a canonical architecture at a certain level can be a compound of canonical architectures at a lower level; this implies a hierarchical modelling with a relevant granularity). Therefore, it is possible to model a critical infrastructure (or even dependent infrastructures) as interconnected canonical architectures on which a set of scenarios may be applied to modify the morphology of the system in order to improve infrastructure resilience.

Therefore, in this approach, SYNTEX is a set of interconnected canonical architecture simulators distributed between each involved CI, as depicted on Figure 1. It is able to simulate each CI and the dependencies are simulated as flows between the CIs (red links on Figure 1).

This integrated simulator may be implemented either as a new simulator or using and improving an existing one. In this second case, some features are required for a suitable simulator:

• It must be generic enough to model the canonical architectures and their flows (traffic flows as well as dependency flows)

• It must permit hierarchical modelling to compose the network topology according to the already modelled canonical architectures

• It must support to be distributed between the different CIs to convey the dependency information to the other CIs.

The synthetic simulator can assist in demonstrating possible risks if external infrastructure data is not available: it should quantify the degree of certainty of the evolution of the system based on the external knowledge available, and assess the necessity to get specific external data from other infrastructures.

Theoretically, it is possible to represent the global interconnected infrastructure comprising several private infrastructures managed by distinct authorities, but this would imply that:

19

SYNTEX overview

20

• It is possible to describe all the dependency and interdependency flows between infrastructures.

• The simulator owner has a global knowledge on all the morphologies of all the simulated infrastructures.

Although this would be an ideal situation, it does not seem likely in a liberal economy where infrastructure owners are simultaneously partners and competitors. In fact, dependency analysis faces two paradoxes:

1. On the one hand internal data are confidential and their divulgation represents a risk to the infrastructure owner, and on the other hand, an infrastructure depends on other infrastructures and it is necessary to collect dependency information to improve the infrastructure’s resilience.

2. To obtain the maximum possible optimisation, a global view is necessary. However, to establish the global simulation, profound knowledge of the targeted infrastructures is required. It is unclear who could have this knowledge and how to master the potential complexity of such an all-in-one simulation. In respect to these pragmatic considerations, it seems that a local simulator used by the stakeholder is appropriate. However, the question arises how to obtain a global optimum with only local analysis.

In order to achieve this goal, a possible solution consists in designing a non-intrusive and profit-driven common virtual market. This virtual market may be used for critical information offer and demand management to feed the synthetic simulator with appropriate dependency flows. This issue is addressed in section 4.1.2.

4.1.1.2 SYNTEX as an overlay for scenario information exchange

The second way to view SYNTEX is as an overlay enabling the exchange of information during scenario execution (Figure 2).

In this view each stakeholder has its own simulator that simulates uniquely the stakeholder’s CI. Each simulator input is a scenario issued from SYNTEX. The output is the result of the scenario simulation. In this case, SYNTEX formats the scenario to the specific simulator language of each CI, for example using a common Application Programming Interface (API). It then receives the results of simulations and reintroduces these results through new scenarios.

As for the previous SYNTEX design, the problem of dependency information disclosure remains. Two solutions may be envisaged:

• The CI simulator reveals only selected results. This solution is restrictive. The stakeholders will certainly minimize the amount and the quality of information to reveal because they do not know who will access this information.

• The use of a market platform for information exchange as exposed in Section 4.1.2.

In this SYNTEX design, stakeholders have their own simulators, which must have specific features to allow interactions with SYNTEX. These simulators must be able to consider external information (scenario from SYNTEX) as an input. Moreover, the models used by the simulators must be extensible to add properties and/or attributes or to create new models to take into account information and features describing the dependencies with the other CIs (e.g. the electrical autonomy of a telecom device to take into account power failures). Finally, the

SYNTEX overview

simulator must generate traces that represent (selected) dependency information, which can be interpreted by SYNTEX to design new scenarios.

4.1.2 The market platform to share stakeholder data

Many ways to exchange information between stakeholders may be imagined. Foreign governmental prerogatives, such as the DHS (Department of Homeland Security) of USA [DHS] or the TISN (Trusted Information Sharing Network) platform in Australia [TISN], aim to enable CI owners to cooperate. However, the TISN platform is not a success. The DHS works a little, but this relative success is due to its state governing.

We describe here a market-like solution that seems to be a flexible and efficient solution to deal with the problem of critical data exchange between stakeholders. Stakeholders may use the virtual market to offer and demand dependency information. This market is described on Figure 4.

Virtual Market

Simulator

Regulator

Figure 4: Common virtual market

The market does not contain the data but rather data descriptions so that an infrastructure owner who needs external dependency information may browse available offers and obtain pricing information for example.

We propose that the market would be regulated by a trusted third party organisation. This organisation could be for instance an organism appointed by a State or a group of States (e.g., the European Union) or a private company. In any case, it will only provide a common offer browsing and placement playground and manage the initial user contact establishing (similar to the eBay model). This organisation would provide a minimal level of trust in the market itself as well as – in case of appointment – a legal framework for data sharing.

This mechanism assumes that the infrastructure management is able to quantify the risk using adapted risk assessment tools [LeG06a].

The sustainability of the market can then be guaranteed both through demand and offer:

• General motivation: being in the market is a means to increase one’s profit.

21

SYNTEX overview

22

• Demand motivation: an operator will increase its profits by mastering his risk. He will be ready to pay for data if the sum of his purchases does not exceed a function of the cost of a service failure representing his financial risk.

• Offer motivation: an operator may increase his profit by offering data on the virtual market. The price of the data must be greater that the financial risk associated to the revelation of this data.

This virtual market model has significant advantages since it is a well-known abstraction that is already used in several domains and for which several optimisations are available. It should go through a bootstrapping phase (during which initial credits could be given to participants to boost market exchanges) and a transient phase before converging to fix and fair prices for the data. Moreover, the virtual market is a solution to the availability problem of confidentiality of internal data while still protecting the provider’s interests, since the offering stakeholder can decide to sell or not sell the data according to buyer’s identity and legal or commercial considerations.

Moreover, in case only a limited number of stakeholders would co-operate and the majority refuses to reveal information, the virtual market may be a good solution to prompt new stakeholders to participate. The virtual market does not handle data but data description. Cooperative stakeholders may access data only if they divulgate their own data. Non cooperative stakeholders may access data descriptions but have no access to data. If only few stakeholders participate in the market, offers and demands may be unbalanced. However, by viewing the description of data that may be useful for simulations, non-cooperative stakeholders may be prompted to share their own data. This feature is not possible in cooperative platforms for information sharing. In this case, cooperative stakeholders divulgate information to all stakeholders and (as in the market) do not necessarily obtain useful data. On the other hand, non cooperative stakeholders exploit the obtained data without divulgating their own data. This does not prompt non cooperative stakeholders to become cooperative and this does not prompt cooperative ones to continue.

However, the major drawback of this proposal so far is that the purchaser should fully trust the external data bought within the market.

The introduction of dynamic trust models in resilient infrastructure models is motivated by the necessity to assess the trust associated to data generated by other infrastructures, especially if this data is used to modify local configurations. Moreover, it is likely that such models will also be required for other applications since in the near future infrastructures will comprise more and more communicating and mobile objects (e.g. RFID) that will require dynamic and autonomous trust management to guarantee secure self-organisation, secure routing, to complement authentication etc.

In [LeG06b], a dynamic trust management model that integrates all the components of trust is proposed. The use of this framework in the virtual market context will assist the purchasing infrastructure operator in assessing the relevance of the purchased data.

Figure 5 shows an example of how trust may evolve in time, depending on the events perceived in the environment, reputation, etc. We note that the trust and distrust granularity must be very fine and that trust depends on a context. Moreover, it is much easier to lose trust than to gain it. Using the proposed algorithms, Figure 6 shows how distrust evolves and converges in time.

SYNTEX overview

Trust

Time

Trustmax

Figure 5: Evolution of trust over time – trust is lost faster than it is gained

Figure 6: Evolution and convergence of trust in time

4.1.3 The global picture

Therefore, the final framework is obtained as follows:

• each operator runs his own simulator. This simulator might be: an integrated tool (new or improved) for the own infrastructure and dependency assessment (integrated view); or a generic dependency analyser interfaced with a present local and specific simulator (overlay view);

• with the help of this simulator the domain administrator identifies which dependency flow data is required and should be obtained;

• the availability and prices for this information is checked in the virtual market;

• the administrator decides to buy or not to buy this information based on several metrics (price, trust, etc.);

• if the information is bought, its relevance and accuracy is assessed based on trust models (which are also updated with this experience); in parallel, the market may collect data concerning the satisfaction of users to improve trust information, in the way of Pretty Good Privacy (PGP) or the concept of Web of Trust;

23

SYNTEX overview

• the synthetic simulator (integrated simulator or local and specific one) is run with various scenarios; the output represents the resilience of the system in this scenario and various reconfiguration options;

• according to the targeted reliability of the own services, the local administrator may propose additional actions (increase redundancy, local reconfigurations, provide policies and plans for actions to be taken in the problem cases) to mitigate the impact of the dependency.

The simulations of CIs and dependencies are based on scenarios, which are generated beforehand. The next section describes the process of generation and description of scenarios that will be simulated within SYNTEX.

4.2 Scenarios within SYNTEX

Figure 7 details the steps preceding the simulation of scenario within SYNTEX.

SYNTEX

Scenario generator

Scenario descriptor

input

Figure 7: Scenario generation and description

A scenario can be generated from an input (e.g. a fault tree). This aspect is depicted in the first subsection. However, this scenario cannot be understood directly by a simulator. In a following step, the description of the scenario is necessary. The second subsection proposes the use of an agent-based language (LAMPS) to describe it in a generic way. This aspect is of particular interest in the context of heterogeneous CI simulators.

4.2.1 Scenario generation

4.2.1.1 Generality about attack and fault scenarios in SYNTEX

The synthetic simulation environment (SYNTEX) is a platform where different types of software components can be used “on demand” to produce data/parameters or to simulate behaviours for different CIs.

Building a “scenario” in SYNTEX means defining an initial state and a sequence of events (that constitute a “behaviour”) in which every event may be triggered on a time basis, following some rules, asynchronously by an external program or by a SYNTEX component. An event can also activate another SYNTEX component.

24

SYNTEX overview

Figure 8: Example of scenario behaviour

In the behaviour example depicted in Figure 8, event 1 triggers an activation event. After a time t1, event 2 is activated and component 1 starts. Then, the third event is initiated at the request of component 1 causing component 2 to be started. Event 4 only starts after component 1 finishes its work and then event 5 waits until a time t2 has elapsed before starting components 3. When component 3 finishes it work, event 6 generates again the initial activation event, so the system has a periodical behaviour. The event activation order has to be maintained but the time intervals between the previous and the following events may change depending on the external activations times.

In SYNTEX, components execute specific (or elementary) functions. The language used to produce behaviours is similar to a workflow in which general functions are composed by a set of more specific functions to be executed in a certain sequence and/or periodically.

A specific behaviour could also activate other behaviours. SYNTEX contains a basic set of behaviours (in a workflow library) that implement the most typical behaviours for the CIs simulated in SYNTEX.

Basic behaviours are normally associated to a single infrastructure and to a certain sets of initial conditions. Conversely, it is not generally well understood what might happen when different behaviours, belonging to different CIs, are linked together. This is one of the challenges for experimentation in SYNTEX.

In SYNTEX, “attacks” or “faults” will be realised as the behaviour corresponding to certain attack or fault scenarios. A standard methodology is proposed in SYNTEX to acquire the knowledge about fault or attack scenarios and a mechanism able to produce all the possible variations of a certain type of scenario. Fault trees and attack trees seem a useful tool to model fault and attack scenarios and are therefore described in the following section.

4.2.1.2 Attack and fault trees

An example of attack tree is depicted on Figure 9. Let us examine the structure of this attack trees. The root of the tree (G) represents a goal that, if reached, could significantly harm the infrastructure’s mission. The terminal leaves (AX) of the tree represent the actions that must be executed to obtain higher levels goals. The intermediate steps (SX) are decision points where the attacker may consider different alternatives.

25

Every decision node could be decomposed inside lower level nodes using <AND>, <XOR> and <OR> decomposition types. In Figure 9, there are two <AND> types of nodes and one <XOR>

SYNTEX overview

type of nodes. It is interesting to observe that an attack tree “generates” attack patterns that constitute attack scenarios. The tree, represented on Figure 9, has only one <XOR> node and consequently generates the two following attack patterns:

G

S1 A2 S2

A3 A4 A5 A6

Attack patterns: P1: <A3, A2, A5, A6>

P2: <A4, A2, A5, A6>

Figure 9: Structure of an attack tree example

Looking at a fault tree, like the one represented on Figure 10, we see that a top event (TE) is caused by failures of components C1, C2, C3, the failure of C1 is caused by a failure of subcomponents C11 or in C12, the failure of C2 is an intrinsic failure and the failure of C3 is determined by failures of both C31 and C32.

Fault trees represent fault sequences of components in which each component (CX) is logically decomposed into sub-components (CXX). In a Fault Tree, leaves represent failures of sub-components (fault causes), and the logical nodes are the faults (consequences) of the components.

TE

C1 C2 C3

C11 C12 C31 C32

Fault patterns:

<C11, C1, C2, C31, C32, C3>

<C12, C1, C2, C31, C32, C3>

Figure 10: Structure of a fault tree example

26

SYNTEX overview

4.2.1.3 Textual representation of a Tree

An attack tree or a fault tree may be also represented in a textual form as shown in Table 1.

Goal GA Precondition Pstart AND S1 XOR A3 (%60) A4 (%40) A2(%100) S2 AND A5 (%40) A6 (%80) Post-condition: Presult The attack tree generates the following intrusion scenarios: <A3, A2, A5, A6> with 19,2% of Presult certainty <A4, A2, A5, A6> with 12,8% of Presult certainty

Table 1: Example of the textual representation of an attack tree

Some general precondition may be determined to reach the goal, and some post-condition may be generated as a result after the goal is reached.

Another interesting element that may be included is a certainty level associated to the terminal leaves of the tree. For an attack tree, this certainty level may represent the “difficulty level” that is expected for executing an action. For a fault tree it may be the probability of the component failure under the defined preconditions. These numerical values should in general be defined by the domain experts or by vulnerability or risk analysis.

4.2.1.4 Generic Fault Tree example

Figure 11 represents an example fault tree for a telecom and an electrical CI. The top event is a “loss of a critical service” impacting both infrastructures (communication and electric power supply). This event may be, for example, produced by failures subsequent to a natural disaster like an earthquake.

The availability level of the studied service can decrease more or less in different part of a territory due to the loss of more specific (local) services (serv. 1, 2 etc.). Services belonging to the telecom CI are represented in black and services from electrical CI in blue. The availability of the specific services depends on the availability of components and sub-components.

27

It is interesting to see that in this tree the links may represent both “fault links” (1) and “dependency” links (2). Fault links represent failures that can propagate from different components within a single infrastructure while dependency links represent failures that can propagate from the first to the second infrastructure, when the loss of a service furnished by the

SYNTEX overview

first infrastructure is critical for the proper operation of a component belonging to the second infrastructure.

“Probability levels” may be associated to the failures of the sub-components, as shown in the figure. The probability of each component failure can be determined e.g. by risk analysis. If we imagine that component failures are due to an earthquake, we have to evaluate the probability of failure of each component under such conditions.

Figure 11: Example of generic fault tree for telecom and electrical CIs

Figure 12 depicts two possible scenarios that can be generated from the previous tree. Both are related to the sequence of events producing a failure in telecom service n. 1. The first one, caused by an internal failure, contains only fault links. The second, caused by failures in the electrical equipments, also contains an interdependency link represented as a dashed line.

28

SYNTEX overview

Figure 12: Two possible fault scenarios generated by the fault tree

4.2.1.5 Generic Attack Tree example

Figure 13 represents a generic example of an attack tree applied to the same telecom and electrical CIs. Dependency links are not shown here because they are generated only by fault propagation. However, a “parallel” attack strategy aiming at several infrastructures can be shown. A malicious attacker can decide to attack different infrastructures simultaneously. This may be a quite common case when physical attacks happen against a portion of a territory on which several devices/resources belonging to different LCCIs reside. In case of cyber-attacks, worms and viruses can infiltrate simultaneously different cyber-networks. Attacks coming from terrorist organisations may be “coordinated”, including simultaneous cyber and physical attacks.

While, in the fault tree, a single scenario corresponds to a single path from the root node to a leaf node, in an attack tree a single attack scenario corresponds to a combination of attack actions. In the scenarios generated by a fault tree, there is a precise cause to consequence relationship between the various events. Faults also have a temporal order from the bottom to the top of the tree.

In the scenarios generated from an attack tree, the relationship between action events and the order of the actions is not so obvious and is difficult to determine examining only the tree. It is however possible to establish that the actions have a default temporal order from the left part to the right part of the tree; this default order must be modifiable in the produced scenarios after they have been generated with the default order.

29

SYNTEX overview

Figure 13: Example of generic attack tree for telecom and electrical power CIs

Figure 14 represents three of all possible scenarios generated from the attack tree of Figure 13. These scenarios correspond to coordinated attacks against both infrastructures. In this figure, time ordered as well as time unordered links are represented. In case of coordinated attacks against more infrastructures, it is useful to be able to change the time order and to modify the different time values (t1, …, t4)

Figure 14: Three possible fault scenarios generated by the attack tree

4.2.1.6 Combination of attack and fault scenarios

In the real world, the threats to CIs may be caused by nature, faults, attacks, human errors, or by a combination of all these factors. Failures of critical services occur when the infrastructure is vulnerable to such a threat. Failures are usually generated by faults, but a service could be compromised by an attack that generating a fault that, consequently, leads to a service loss. The same fault may be also generated by a human error that may have, as a consequence, an identical

30

SYNTEX overview

service failure. It therefore seems useful to be able to combine the results of attack and fault trees, for instance resulting in a combined attack and fault scenario. Figure 15 depicts an example of such a combination of attack scenario with a fault scenario.

There are many different ways to combine attack and fault trees. Within the physical layer, a specific action might produce a fault inside a critical component. Within the cyber layer, worms or virus proliferations may reduce the level of availability of services in several network components. Sometimes, malicious actions generated inside the cyber layer may have dangerous effect on the physical layer, and the failure severity and rate may increase due to additional human errors.

Figure 15: Combination of attack and fault scenarios

Let us examine the scenario depicted on Figure 15. If the third attack scenario from Figure 14 defines the following actions, able to produce faults on telecommunication and electrical CIs:

- Action 11 -> may produce an internal failure inside Component 11 (in the telecom CI)

- Action 211 -> may produce a failure inside Component 21 (in the electrical CI)

Analysing the generated scenario depicted on Figure 15, we can see that the attacker, with a coordinated attack against both infrastructures has two different chances to provoke a failure of service 1 in the telecom CI. If we associate certainty levels to actions and component failures, the previous model could also help to better understand the possibility for an attacker to reach its goal with single and with coordinated attacks.

Attack scenarios may also target different layer. For example, an attack may be a cyber attack or a mixed type of attack (attack on the cyber-layer of telecom CI and on the physical layer of the electrical CI).

It is also important to introduce timing information between attack execution and subsequent faults triggering. A fault effect, and consequently the activation of the corresponding fault scenario, may be delayed after the attack due to some intra-dependency relations.

31

SYNTEX overview

4.2.1.7 Need of a tool for scenario tree editing and execution

In SYNTEX, the user needs to test the infrastructures vulnerabilities and the adopted mitigation solutions under many types of contingencies generated by attacks, fault scenarios and their possible combinations. The experiments must be executed, the results logged and archived and, more important, the experimenter must be able to repeat the experiment under the same conditions (using the same attack/fault scenarios).

As the effects of an attack may depend not only on the attack/fault behaviour but also on other CIs’ behaviours, the duration of a single experiment may not be well known in advance. To make repeatable and demonstrable experiments, it seems necessary to have a tool that supports:

- design of attack/fault scenarios; - construction of libraries of these scenarios; - monitoring and logging of the execution of scenarios in SYNTEX; - archiving of the obtained results.

Figure 16 illustrates this process.

Figure 16: Supporting functions for the experimenters

Some tools are already available for attack and fault tree design and analysis, for example Isograph [IsoG]. However, these tools are generally dedicated to an offline evaluation of the consequences of attacks and faults without any real simulation of the analysed environment. Our objective is to produce attack/fault scenarios (selected according to their severity) that will be executed in a simulation environment, leading to real experiments scenarios design that may be used to demonstrate the effectiveness of proposed solutions. Experiments must thus be documented and repeatable.

32

SYNTEX overview

33

The attack tool required for the experimentation activities in IRRIIS may provide some functions that are different from the tools generally available on the market. The objective here is not to make a deep risk analysis of all the components of a single infrastructure, but to focus mainly on the interdependencies aspects, generating scenarios that contain the interdependency links. The generated scenarios must be editable, especially for the introduction of temporal aspects, and integrated into SYNTEX environment. The generated scenarios must be combined or linked so that many combinations can be produced from a limited set of available scenarios.

4.2.2 Scenario description

LAMPS (Language for Agent-based Simulation of Processes and Scenarios) is a language for description and modelling processes and scenarios that is currently under development at the Fraunhofer Institute for Autonomous Intelligent Systems. It is used in several projects dealing with agents and processes in some sense, for instance, the agent-based simulation of military scenarios. The common core of all these projects is a radical agent-based approach: everything is modelled as an autonomous agent that responds and reacts to messages. Agents have attributes, describing their current state and certain behaviours describing which actions to take under which conditions. The behaviours can be either implemented by the developer (system-specified behaviour) in programming language or designed by the user (user-specified behaviour) using LAMPS.

LAMPS has graphical and textual representations. The graphical representation is based on Petri networks. In other words, LAMPS uses the following four basic concepts:

• Places hold states, i.e. some arbitrarily structured piece of data. The contents of a place are called tokens. Places can contain several tokens of different or identical types.

• Actions describe the effects behaviours that agents may apply to themselves or to other agents (using messages).

• Relations denote the links between places, actions, and agents. Relations correspond to the edges in the Petri net model.

• Agents in LAMPS correspond to the conditions (guards) of Petri nets. An agent in LAMPS observes the set of places that have relations to its actions. Based on these places the agent decides which actions are executed and which parameters should be used.

Figure 17 represents a simple example illustrating the four basic concepts. So far, LAMPS turned out to be very flexible and to be applicable to a broad range of different problems. For instance, LAMPS can be easily used to describe scenarios. In the radical agent-based approach a scenario is just another agent and its behaviour describes the events that happen within the scenario.

A very important feature of LAMPS is the ability to specify behaviours in a hierarchical way: actions can be other behaviours also defined in LAMPS. This allows the user to split complex behaviours in sub-behaviours and to work at various abstraction levels. Tools assisting the user in the specification of behaviours with LAMPS are currently under development at Fraunhofer AIS.

SYNTEX overview

Figure 17: A LAMPS fragment using the four basic concepts.

Let us take a deeper look at the example represented in Figure 17. The agent Inf A monitors the place Enemy spotted. When the place contains a token, the agent executes the action Combat that sends a token into the place Resistance broken.

The graphical representation of LAMPS has been used in a wide variety of application domains, ranging from technical processes in telecommunications to management processes in large companies. One major advantage of the graphical representation is its understandability that facilitates communication with domain experts. In IRRIIS, LAMPS could be used to describe the behaviour of physical network components, the behaviour of components in the cyber layer and the behaviour of humans in the management layer (as long as it can be formalized). Figure 18 gives an example of the treatment of a request to change its current capacity by a power generator.

requestedcapacity wait ready set

attributecapacity change

process error

self

self self

Recalculate power flows

power flow sim

Figure 18: The behaviour of a generator corresponding to a request to change its capacity

Let us examine this behaviour in details:

1) A token with the requested capacity is placed in the place Requested capacity. 2) The agent inspects the token, and either triggers the action Wait (it takes some time to

change the capacity of a generator) or the action Process error (e.g. if the requested capacity is higher than the generator maximum capacity).

3) If a capacity change is possible, a new token is placed in the place Ready. 4) Whenever a new token appears in the Ready place, the agent sets its capacity to the

requested capacity using the Set attribute action. 5) Set attribute places a new token in the place Capacity change.

34

SYNTEX overview

35

6) The Power flow sim agent watches the place Capacity change. Whenever a new token appears in this place, it recalculates the power flows of the whole network and sends messages to all involved agents to set their loads correspondingly.

Due to its generality, LAMPS can be used to describe behaviour on all different levels of a critical infrastructure, from the physical layer up to the management layer, of a critical infrastructure. Furthermore, it can be used to describe the behaviour of external factors, for instance electricity consumers, and to describe the occurrence of certain events along with conditions triggering this event. Therefore, LAMPS could be integrated into SYNTEX as a general way to describe behaviours and scenarios. As LAMPS is developed by Fraunhofer IAIS, source code and knowledge is available to the project, which may ease integration of LAMPS into SYNTEX.

Requirements for simulation within SYNTEX

36

5. Requirements for simulation within SYNTEX

The objective of SYNTEX is to allow modelling and simulation of telecommunication and electric power CIs as well as their dependencies to identify and to contain possible cascading effects in case of failure in a CI. (The simulation tools principles are already explained in Section 3)

This section proposes a list of requirements to identify suitable simulation tools. It is split in four parts. The first one details global CI simulation requirements. The second one presents the requirements issued from SYNTEX design. The third part depicts requirements derived from deliverable D.1.3.1 (“Catalogue of requirements for SYNTEX”). Finally, the last part provides a summary of the requirements listed in the section.

5.1 Global CI simulation requirements

The global CI simulation requirements designate the necessary conditions to select simulation tools and components. They are listed in the IRRIIS project description of work [DoW05] and are divided in two parts: modelling requirements and simulation requirements.

5.1.1 Modelling requirements

Generally, simulators already propose models that are available to describe scenarios. These models have different features that must be taken into account for the simulator selection. Tools have to be selected considering their modelling power and their ability to represent complex problems. The following features highlighted in the IRRIIS description of work, must be considered:

• Implemented modelling formalisms.

The two main modelling formalisms are determinism and stochastics. In short, a model is deterministic when the same results are obtained, regardless of how many times the model is re-calculated. An example of deterministic model is the calculation of the return on a 5-year investment with an annual interest rate of 7%, compounded monthly [MoC]. A deterministic model may be turned into a stochastic model by introducing random variables. These variables bring uncertainty in the model and provoke variations in the simulation results. These random variables are important in CI simulation to model for instance, the variation of flow amount or intensity that may be observed in communication as well as in electricity networks.

• Ability to represent continuous as well as discrete variables.

A random variable reflects an uncertainty in the sequence of events. It is often represented by a probability density function describing a probability distribution function (e.g., Poisson distribution) [DV1, DV2]. The random variables used to obtain a stochastic model may be of two types: discrete or continuous. A discrete variable is a variable that can only take a countable number of values. A continuous random variable is a random variable in which the data can take


an infinite number of values. For any continuous random variable x with probability density

function f(x) describing a continuous distribution, we have [DV1, DC1]. ∫+∞

∞−

= 1)( dxxf

These variables may be used to describe the traffic behaviour during the simulation either at discrete points of the simulated time (discrete variables) or in a continuous manner (continuous variables).

In case of SYNTEX as an overlay, SYNTEX will deal with electrical and telecom simulators.

Telecom simulators are discrete event simulators whereas electric power simulators generally provide continuous time simulation by solving differential equations in a time-stepped manner. SYNTEX shall be able to synchronise the simulators and translate output data of a first simulator into input data of a second one.

In discrete event simulation, the simulation is organised as a set of events occurring at a certain simulated time. Each event begins when the previous finishes. Real time and simulated time are decorrelated. The time step is not regular, it depends on the event. The time order is in seconds (including tenth and hundredth of seconds).

• Integration with other tools easiness.

This feature should be evaluated to assess the potential use of the simulator with other tools that may for example define models or scenarios to be used by the simulator. This also indicates the ability of the simulator to be integrated within SYNTEX and to interact with other tools.

• Composition of sub-models in a hierarchical fashion to withstand space explosion.

Characteristics of CIs are their large scale and their complexity. Scale and complexity are then increased when several CIs must be simulated. Hierarchical models allow simplification of the simulation scenario topology since an entity of the model can represent a sub-model. The visualisation of the model is easier. Moreover, simulators proposing this modelling feature may simulate only the higher-level model. The sub-models are simulated only if they are explicitly checked. This allows a reduction of the simulation time but may distort the simulation results. Indeed, it is essential to be able to simulate large-scale networks without decreasing the model complexity in order to maintain a realistic simulation which is essential for our purpose.

• Hosting heterogeneous modelling formalisms.

This feature offers more possibilities to the user in the definition of new models and can increase the ability of the simulator to import and use external models.

If SYNTEX allows the interactions of various and heterogeneous tools, the use of external models, which are validated and accepted, is essential to simulate a realistic behaviour of CI. Disturbances may then be added (e.g.: through fault scenarios), and compared with the normal case and/or real failure cases.

• The host operating system.

37

It may be a deciding point for the choice of the simulator. For example, a simulator only available to UNIX-like systems cannot be selected if Windows Operating System (OS) runs on the hosting machine.


38

• Ability to be distributed on a platform (network).

This feature allows the distribution of the simulation load of the described scenario over a set of machines. This may allow a reduction of the execution time in certain cases.

5.1.2 Simulation requirements

Each simulation tool, including the simulation engine, is unique. They have characteristics representing their simulation capabilities. Several important features are listed hereafter:

• Ability to simulate electric power and telecommunication networks.

This feature is essential in the case where SYNTEX uses a single tool to simulate electrical as well as telecommunication networks. However, SYNTEX may also be seen as an interface between existing and specific CI simulators as described in Section 4.1.1.2.

• Ability to generate disturbances/corruptions inside the simulated networks.

To study the simulation behaviour, the dependencies between CIs and the possible cascading effects, it is essential to be able to generate disturbances and corruptions in the simulated networks. These disturbances/corruptions may be represented, for instance, as an entity/node failure or as a link failure.

• Their ability to perform state estimations of the network.

This feature is essential to determine how and/or for how long the network may or may not support the possible disturbances and failures as well as how the reconfiguration scenario or recovery actions (the reaction to the disturbances) may limit the problem.

• Available network visualisation tools and network database systems.

To describe the scenario or to visualise and to analyse the simulation results, graphical tools and GUI make often work easier due to the visualisation capability. It is essential to be able to use the simulator rapidly and to have explicit result representation (e.g., by plot generation).

• Hardware/ software components of the Supervisory Control and Data Acquisition (SCADA) systems that may be configured as small testing environment in the laboratory.

This feature is specific to the simulation specific CIs that use SCADA systems, e.g. electric power (generation, transmission, and distribution), natural gas (processing, transport), and drinking water. Due to its wide use in this field, the simulation tool must be able to consider inputs from the SCADA systems. More generally, it must be able to receive information from a real network.


39

• Ability to create archives containing logs of the networks status and the operative actions.

This aspect is important to keep trace of the simulations (scenario and countermeasures) to know how to react if the same scenario really occurs.

In addition to the previous topics, two others features have to be considered:

• The simulation engine performance.

SYNTEX will simulate large scale and complex infrastructures. These two characteristics increase the simulation time. Therefore, a high-performance simulation engine is essential to obtain an acceptable simulation time.

• License type.

The type and the price of the license can be a point that needs to be taken into account in the selection of an existing simulator.

5.2 SYNTEX requirements

SYNTEX requirements are issued from the designs of SYNTEX described in Section 4.1.1. These requirements are detailed in the following sub-sections according to the two architectural designs proposed above. The global characteristics listed in Section 5.1 must be considered along with these requirements.

5.2.1 Requirements relative to SYNTEX as an integrated simulator

In this view of SYNTEX, the simulator models CIs in a generic way by the use of canonical architectures. The following requirements appear:

• The simulator must support hierarchical modelling.

A CI may be represented as an aggregate of canonical architectures organised in a hierarchical way, i.e. a CI can be represented by a canonical architecture, each node of this architecture may be a “black box” containing another canonical architecture. Therefore, the simulator has to support hierarchical modelling to compose the network topology accordingly.

• The simulator must support generic models.

The simulator must model all CIs in a similar way, including theirs specific components, their specific flows and also the possible dependency flows occurring between simulated CIs.

• The simulator must support distributed execution among the different CIs.

Simulation will take place at the different CI locations. So the simulator must be able to convey the local simulation results (selected dependency information) to others CIs for dependency simulation.


40

5.2.2 Requirements relative to SYNTEX as an overlay for scenario information exchange

In this SYNTEX design, stakeholders have their own simulators and SYNTEX acts as an overlay that provides interface between the different heterogeneous local simulators. In this case, the simulators do not need to be generic or to have the ability to simulate several types of CI. However, each simulator must provide an interface to SYNTEX. Therefore some features, along with the global characteristics listed in Section 5.1, are essential:

• The simulator must allow the extension of its predefined models.

The predefined models of the simulator must be extensible to allow addition of new properties and/or attributes. Alternatively, it should be possible to create new models. This allows taking into account information and features relative to the dependencies with the others CIs (e.g. the electricity autonomy of a telecom device when suffering a power failure).

• The simulator must be able to consider external information as an input.

Since the simulator is interfaced with SYNTEX, it must be able to treat scenarios already described by SYNTEX and to simulate them.

• The simulator must be able to generate trace files of its simulation results.

The simulator must be able to return selected results to SYNTEX. Then SYNTEX may use the simulator to create new scenarios for the others CI simulators.

5.3 Requirements derived from Deliverable D.1.3.1

The deliverable D1.3.1 “Catalogue of requirements for SYNTEX” provides the list of requirements for SYNTEX definition [D1.3.1]. This document also determines the requirements in terms of modelling and simulation. The following requirements are identified in D1.3.1:

• The simulation model needs to be stochastic.

SYNTEX shall simulate electrical physical behaviour, and the power intensity may vary during energy supply. These variations have to be simulated. The telecommunications physical behaviour also varies according to the type and the amount of traffic. Stochastic models allow modelling of these variations through the use of probabilities.

• Models need to be extensible or modifiable. New models may be created.

The current simulators do not necessarily provide predefined models including desired characteristics. So it is essential to be able to modify/extend existing models or to create new ones, to obtain models which answer our requirements. Moreover, models include topology information (network components and links) and traffic representation.

• The simulator may be able to interact with the real network/system.

The simulator may need to take into account real data (e.g., if SCADA components are not simulated but interact with the simulator by sending the acquired data). In this case, the simulator has to interact with the real network/system to get the data.


41

• The simulator must be able to design and manage scenarios

Simulators generally offer the possibility to design new scenarios. Depending on the view of SYNTEX, this aspect is not essential since scenarios may be generated before SYNTEX implication or available in a library. However, it is an advantage to offer the possibility to archive existing scenarios, to re-use and/or modify pre-defined or stored ones.

• The simulator must include GUI and analysis tools.

As it is highlighted in Section 5.1.2, a GUI makes the scenario and/or model creation and modification easier. GUI is also a means to visualise values and trends of the network parameters, the topology of the networks, the properties of the network components, and to monitor the simulation run. These aspects are important for network state estimation to analyse the different network properties (e.g. topology or dependencies), to identify possible problems, and find solutions.

• The simulator must have fast simulation capabilities.

In case of a major failure, the simulator should simulate the network state behaviour faster than real time in order to identify cascading effects and to test countermeasures that can be applied on the real infrastructure, therefore allowing fast reaction to the problem. This feature is also useful to enable SYNTEX integration within a live network.

• The simulator may exchange information with other simulators.

Since SYNTEX simulation shall be distributed between the different CIs, two solutions are possible to simulate dependencies and cascading effects:

1. SYNTEX is composed of homogeneous simulators and must therefore support distributed simulation.

2. SYNTEX is composed of heterogeneous simulators. It should thus either be High Level Architecture (HLA) compliant or use another similar common vehicle to exchange information.

5.4 Conclusion

This section summarises the features and requirements described in Section 5. This list will be used to evaluate the different simulation tools presented in the document.

Summary of the modelling aspects:

• Implemented modelling formalisms, especially stochastic modelling. • Continuous as well as discrete variables representation. • Integration with other tools easiness. • Hierarchical modelling support. • Ability to deal with heterogeneous modelling formalisms. • Required operating systems. • Ability to be distributed over a network. • Generic models support (SYNTEX as an integrated simulator). • Possibility of extension/modification of existing and predefined models. • Possibility of creation of new models.


42

Summary of the simulation aspects:

• Simulation of electricity and telecommunication infrastructures. • Simulation/consideration of SCADA system components • Generation of disturbances/corruptions inside the simulated networks. • Available analysis tools for state estimations of the network, results analysis, etc. • Available network visualisation tools and network database systems. • Possibility to design scenarios. • Possibility to archive scenarios and modify existing ones. • Available GUI for scenario creation/management, model creation/modification. • Ability to create archives containing logs of the networks status and the operative actions. • Consideration of external information as input. • Creation of trace files of the simulation results. • Interaction with the real network/system. • Ability to exchange information with other simulators (distributed simulation, HLA,

etc.). • Performance of the simulation engine (fast simulation capabilities). • Type of license.

The two following sections compare the various simulations tools studied (for a single sector as well as for multiple sector simulation of CIs), according to the requirements listed previously.

Available tools to simulate (interconnected) CIs of a single sector

43

6. Available tools to simulate (interconnected) CIs of a single sector

6.1 Introduction

Nowadays, various tools are available to make simulations in different activity sectors. In the telecommunication and electricity sectors, commercial as well as public domain simulators are available to industrials and academics.

In Sections 6.2 and 6.3 , we compare, sector by sector, a list of selected public and private domain simulation tools. We distinguish the well-known simulators (that are already used by stakeholders) and other available simulators (interesting for specific capabilities that can be useful to the IRRIIS project).

Section 6.2 compares network simulators such as OPNET, NS-2, QualNet and OMNeT++ [OPNet, NS-2, QualNet, OMNet] that are already known and used by the telecommunication stakeholders, and simulators such as J-Sim, SSF and Backplane [J-Sim, SSF, DNEB] that are more recent simulators issued from research projects. Section,6.3 compares electricity simulation tools used by stakeholders such as Siemens the PPS family (e.g., NETOMAC and SINCAL), PowerWorld and PSCAD [NETO, SINCAL, PW, PSCAD], and research simulation tools such as SEPIA [SEPIA].

6.2 Telecommunications networks simulation tools

6.2.1 Introduction

Four simulators are well known to the stakeholders: OPNET, especially the OPNET Modeler is the most widely used; NS-2, which remains the most used by academics, is a de facto standard in network simulation; QualNet and OMNeT++ are on their way up for industrials as well as for academics.

In addition to the stakeholders well-known simulators, we chose to present three other simulators: J-Sim, SSF and Backplane, which have interesting features we aim to highlight.

6.2.2 OPNET and the OPNET Modeler

6.2.2.1 Description

OPNET (OPen NETwork) [OPNet], or more precisely the OPNET Modeler [OPNetMod], is a commercial discrete-event simulator initially developed by the Massachusetts Institute of Technology (MIT) in 1987. It provides a global environment to model, simulate and evaluate performances of all kinds of wired and wireless communication networks and distributed systems. It is available on Windows 2000, XP, Linux and Solaris platforms.

The OPNET environment includes graphical tools for scenarios and models conception, scenarios simulation, data collection and data analysis.


44

To run an OPNET simulation, the enumerated steps must be followed:

1. The creation of simulation scenario (called the network model) using models from the standard library to describe topology and traffic.

2. The choice of the collected statistics from each network object or from the network as a whole for future analysis of simulation results.

3. The execution of the simulation.

4. The visualisation and analysis of simulation results.

A simulation within OPNET is represented by a project including a set of scenarios. This project is created through the project editor also known as the OPNET central interface. All the available functionalities may be accessed from this editor. It provides an access to other editors that propose functions including node and process model creation, building packet formats, and creating filters and parameters.

OPNET provides many additional functions including a High-Level Architecture (HLA) module, which allows communication between various simulators.

6.2.2.2 Suitability for modelling

OPNET allows hierarchical modelling by defining a network as a collection of sub-models representing sub-networks or nodes. Modelling is done within the modelling environment, which consists of three domains [Kou04, OPNetMod]:

• The network domain.

It defines the communication network topology to simulate. A network topology is created with the project editor GUI. Such a topology includes the network nodes, their interconnections and their features. Figure 19 presents the project editor interface.

The topology used by the simulator can either be created manually with the provided palette, imported, or using predefined topologies (bus, star, fully-meshed, etc.). Nodes and links can be characterised by configurable models that specify their functions and that can be accessed by a simple click.


The definition and configuration of each node parameters is done within the Parameter Editor. These parameters are, for example, the packet format (definable with the Packet Format Editor), defining the internal structure of a packet as a set of fields, or the probability density functions (PDF) (definable by the PDF Editor, cf. Figure 20). These PDF are used to model the network traffic using probabilistic characterization. Different distributions are available with this functionality such as Uniform, Exponential, Erlang, Gamma Hyper-Exponential or Geometric distributions. This PDF functionality provides OPNET the ability to implement stochastic models. Moreover, PDF handle discrete as well as continuous variables.

Figure 19: The OPNET Project Editor interface and example

45


Figure 20: The OPNET PDF editor interface

The Link Model Editor is used to model the link objects between the nodes. Any link has different attribute interfaces and representation. Furthermore, comments and keywords can be specified for easy recognition.

The Path Editor is used to create new path objects, defining routes that traffic take. Any protocol model that uses logical connections or virtual circuits (MPLS, ATM, Frame Relay, etc.) can define and use these paths to route traffic.

One of the assets of the OPNET network domain is the opportunity to create models by a duplication of already defined ones containing groups of nodes and links. This feature simplifies a complex model into a set of models simpler to manage (modularity).

OPNET network domain also offers the possibility to configure all applications available on a node, the Quality of Service (QoS) parameters of each application, and to define, for a node, a user profile consisting on the use of several applications.

• The node domain.

The node domain instantiates the nodes defined in the network domain, i.e. elements connected to the network that can send and receive data, by the way of the Node Editor. A node can either be created by the user or provided by the library. A node refers to different types of devices. Predefined equipment such as servers, routers, switches, workstations, are also provided.

46

In the node domain, a node is composed of a variable set of transmission modules (transmitters) and reception modules (receivers) that ensure its connection to the communication links. A module represents an application, a protocol layer or a physical resource. The modules interact with packet streams for the exchange of formatted messages (packets) between modules. They also make use of logical associations that define a correspondence between two modules (e.g.:


transmitter and receiver) to consider them as a pair when a node is connected to the network domain. Finally, statistic wires allow to send simple digital signal and control information from a module to another (they are used when a module needs to monitor performance or the state of another module).

Figure 21 shows an example of the node editor.

• The process domain

The process domain describes every module (processors or queues) that is programmable by the user. They execute processes or tasks.

This domain is designed with the Process Editor (depicted on Figure 22), which allows process modelling with finite state automata (state/transition). Each state contains the C/C++ code of the tasks to execute at the entry and exit of the state. The transition specifies the necessary conditions to go from a state to another.

Finally, Figure 23 summarises the model levels.

Figure 21: OPNET Node Editor interface

47


Figure 22: OPNET Process Editor interface

48


Figure 23: The different OPNET model levels [OPNet]

6.2.2.3 Suitability for simulation

An OPNET simulation project consists in the following tasks: network model creation, choice of the network parameters to monitor (collected statistics), simulation execution, results visualisation and analysis.

The network model has already been presented in the previous section. Editors are in charge of the achievement of the other tasks. Moreover, OPNET may import data from text files, XML, and other popular tools (Cisco, HP, CA, NetScout, BMC, Concord (CA), Sniffer, Infovista, MRTG, cflowd, tcp-dump, and so on). This facilitates its integration with other tools.

The Probe Editor selects the statistics to be collected. This editor is used to place probes at various points of interest in the network model. These probes can be used to monitor any value computed during simulation. The Probe Editor is called by the Project Editor. It is used to set additional characteristics of each probe. Several types of statistics can be collected using different probes, including global (network) statistics, node statistics, attribute statistics and several types of animation statistics. The Probe Editor interface is represented on Figure 24.

49


Figure 24: The OPNET Probe Editor interface

The Simulation Tool (represented on Figure 25) is used by the user to define a sequence of simulations. The user may specify the input and output options, as well as the different runtime options such as parallel simulation. The simulation is then run from the Project Editor.

Figure 25: The OPNET Simulation Tool interface

The visualisation and analysis of results is achieved with the Analysis Tool and the Filter Editor.

50


The Analysis Tool (cf. Figure 26) displays the results of a simulation or series of simulations as graphs. Although simulation results can be viewed in the Project Editor, the Analysis Tool has several useful additional features. For example, it is possible to create scalar graphs and parametric studies, define template to filter statistical data, and create analysis configurations that can be saved and viewed later.

Figure 26: Example of results analysis with the OPNET Analysis Tool

The Filter Editor is used to define filters to mathematically process, reduce, or combine the statistical data. OPNET has a number of available data filters and allows the creation of additional ones. New filter models are built by combining existing models with each other.

The animation of the scenario behaviour may be visualised during or after the simulation running. The collected statistics can also be graphically monitored during the simulation execution. These results can be exported to spreadsheets or XML.

Thus, OPNET provides a full GUI, which contains various accessible buttons and menus. Many functions may be activated with the buttons such as the failure and the recovery of links and nodes.

OPNET offers also the possibility to organise and compare several network scenarios in the same project. Their simulation results can be compared for example in the same graphs.

OPNET proposes also a debugging tool, called the Simulation Log, that checks warnings and errors.

The simulator supports distributed simulation through the HLA module [OPNetHLA]. It supports building and running a federation of many simulators that model some aspect of a composite system. The HLA Module allows OPNET simulations to model some portion or the whole communications aspects of the HLA federation models. The HLA interface provides the 51


various simulators (federates) the required mechanisms to share a common object representation (for persistent elements), to exchange messages (interactions), and to maintain appropriate time synchronization. OPNET also supports parallelised simulation and System-in-the-loop simulation (connection to live hardware/software) with a real-time discrete event simulator.

Finally, OPNET has a scalable and efficient simulation engine to run simulations faster than real time. For example it may simulate on standard workstations thousands of wireless nodes in a complex environment with dynamic application and routing behaviour faster than real time [OPNet].

6.2.2.4 Conclusion

OPNET offers many advantages that can be exploited to adapt it to the IRRIIS context. For instance, OPNET modelling modularity is an asset to model critical infrastructures. It offers the possibility to define and add new models specific to the infrastructure to simulate. New parameters can also be specified to model actions that might occur within the infrastructure (management, processing, etc.). Infrastructures can be distinguished by the process models (i.e.: the codes or programs that characterise the state of the modules associated to a node or a link).

However, this tool is quite complex, especially if specific component have to be developed.

Table 2 and Table 3 summarise the suitability of OPNET for modelling and simulation.

Table 2: OPNET modelling suitability

Enabling stochastic modelling

Continuous as well as discrete variable representation

Easiness of integration with other tools

Hierarchical modelling support

Possibility of hosting heterogeneous modelling formalisms deteministic and stochastic

Hosting operating systems Windows 2000/XP, Linux, Sun Solaris

Ability to be distributed on a platform network

Generic models support (SYNTEX as an integrated simulator) not specified

Possibility to extend/modify existing and predefined models

Possibility to create new models not specified

Modelling suitability

52


Table 3: OPNET simulation suitability

Simulation of electricity and telecommunication networks Telecom

Simulation of SCADA system componentsGeneration of disturbances/corruptions inside the simulatednetworksAvailable analysis tools for state estimations of the network, resultsanalysis, etc. Network visualization tools and network data base systems

Possibility to design, archive and modify scenarios

GUI for scenario creation/management

GUI for model creation/managementAbility to create archives containing logs of the networks status andthe operative actionsConsideration of external information as input

Create of trace files of the simulation results

Interactions with the real network/system

Ability to exchange information with other simulators

Fast simulation capabilities

Type of Licence commercial

Simulation suitability

6.2.3 The NS-2 simulator and the VINT project

6.2.3.1 Description

NS-2 [NS-2] is the second version of NS (Network Simulator). It is a public domain event-driven network simulator developed at UC Berkeley. It is available on UNIX, Free BSD and Windows OS platforms.

NS-2 is currently a part of the VINT (Virtual Inter-Network Test bed) project [VINT]. This project develops simulation tools (including result display, analysis) and converters that convert network topologies issued from generators to the NS format. These topology generators are the Inet topology generator, the GT-ITM topology generator, the tiers topology generator, and the BRITE topology generator [NStopo].

NS-2 is designed to simulate small-scale networks. It can simulate of a variety of IP networks and applications (TCP and UDP implementation, traffic source behaviour such as FTP, Telnet, Web, CBR and VBR, router queue management mechanism such as Drop Tail, RED and CBQ, routing algorithms such as Dijkstra, and so on). NS also implements multicasting and some MAC layer protocols for LAN simulations.

53


NS-2 is based on three languages:

• Tcl, which is used to write simulation scripts (topology, link types and traffic types).

• OTcl, to define other simulation parameters (initialization of the event-scheduler, putting in place the topology and indicating to traffic sources when the traffic starts and stops).

• C++, to implement the schedulers and network components.

The Tcl part of NS allows easy integration in an application. In this case, the application can use the Tcl standard functions or add new commands to the Tcl interpreter.

Since the different network components are written in C++, the modification of an existing component may consist in adding new attributes and methods to an object class for instance. However, adding new components such as a new protocol is a complex task that requires good knowledge of the simulator. It is not sufficient to create new C++ classes since they must be linked to the OTcl ones. C++ header files must be modified and NS must be recompiled, in order to use the new components in the simulator. The interaction between the OTcl (Object oriented Tcl defined by the Massachusetts Institute of Technology) interpreter and the C++ libraries is shown on Figure 27. This separation is made to reduce packet and event processing time. Therefore, to setup and run a simulation, a user should write an OTcl script defining the simulation scenario (network topology, used protocols, events on traffic behaviour, link or node failure, route changes and the collected statistics). The network topology is defined by the network objects and the plumbing functions in the library. The user indicates in the event scheduler when traffic sources should start or stop transmitting packets. The OTcl script is then analysed by the interpreter and the C++ libraries are used to implement the data. The network component objects describe the network topology and the plumbing modules implement the traffic. So OTcl is used to implement high level control operations and C++ to describe the pre-defined models (components, protocols, etc.) [Bre00].

Figure 27: Simplified user’s view of NS-2 [NStut]

Eventually, NS-2 produces simulation results stored in classical trace files or in NAM trace files displayed for example with the network animator (NAM) tool.


NS-2 simulates IP-based networks, including terrestrial, wireless and satellite networks, by defining the network topology (network nodes and how they are linked), the agent representing transport connection associated to each node (e.g., TCP/UDP) and the traffic that can be

54


generated by/through the agent (e.g., FTP/CBR). Figure 28 shows an example of simulation with NS.

Figure 28: Simulated network and traffic with NS-2

Since NS-2 is a discrete event simulator, it handles discrete variables that represent the different events of the simulation scenario. Furthermore, NS-2 gives a mathematical support that can be used to model traffic distribution or packet loss (deterministic or probabilistic packet loss in queues attached to network nodes). The traffic distribution can be modelled in a deterministic or in a stochastic way in non-connected mode (for UDP protocols). For example, deterministic traffic generation may be handled by the CBR distribution: traffic is generated according to a deterministic rate with fixed size packets. Optionally, the interval between inter-packet departures can be randomized. Stochastic traffic generation can use either Exponential distribution or Pareto distribution. Packets are sent at a fixed rate during on periods and no packets are sent during off periods. The periods lengths and intervals are calculated by exponential or Pareto distributions.

The traffic can also be generated by a trace file in binary format. This trace file shall contain the time and the length of the packet to generate. Since NS-2 is very popular, various tools have been interfaced with it, either directly or through converters. For example, NS may use various inputs from topology generators such as Inet or GT-ITM to obtain trace files representing the traffic and topology files.

The outputs produced by NS-2 can be:

• General format trace files that can be interpreted parsed and processed to be used by plotting software like GNUplot or Xgraph, or they can be directly read with UNIX commands.

• NAM format trace files, NAM being the animation tool available to visualise the network simulation.

55


56

• Personalized trace files, if the user decides to trace only a limited number of parameters. For example, it is possible to log the times when specific packets were received by a node, the bandwidth of a flow, etc.

Finally, the current implementation of NS does not allow the simulation of large-scale networks due to excessive memory and CPU time requirements. An extension for parallel and distributed simulation (called Parallel and Distributed NS (PDNS) [PDNS]) has been proposed by the PADS research group of Georgia Tech Lab [PADS]. Extensions and enhancements have been developed to allow a network simulation to be run in a parallel and distributed fashion, on a network of workstations.


NS-2 is a discrete event-based simulator. The event scheduler is either a non real-time scheduler (list, heap or calendar) or a real-time scheduler. The default scheduler is Calendar-based. The real-time scheduler is mainly used for real-time synchronization of an emulated network.

Various disturbances and corruptions can be generated inside the simulated network. Errors can be inserted inside the traffic by creating an error model, which define packet loss profile to be applied. Links can be cut and nodes stopped at a precise time and restored afterwards. It is also possible to introduce any noise model on any link. All these disruptions must be defined in the OTcl script describing the scenario.

NS proposes different ways to estimate the network state by tracing packets and by monitoring queues and flows. Tracing can be done on all links or on specified links. The trace records each individual packet as it arrives, departs, or is dropped at a link or queue. The monitors record counts of various quantities such as packet and byte arrivals, departures, etc. the queue monitoring permits to get statistics for a queue. The flow monitoring permits to implement per-flow statistics gathering.

The resulting traces (from tracing and monitoring) can be analysed and visualised with graphical tools. The NAM (Network Animator) is proposed by the VINT project to display the simulation scenario. Its user interface, shown on Figure 29, is similar to that of a CD player (play, fast forward, rewind, pause and so on), and also has a display speed controller. Furthermore, it can present graphically simple information such as the throughput and number of packet dropped at each link, although the graphical information cannot be used for accurate simulation analysis. Figure 30 gives an example of simulation display and result visualisation.


Figure 29: The NAM user interface

Figure 30: Example of simulation visualisation with NAM

57


Other tools such as X-graph or GNUplot propose also a graphical interface that allows analysis of NS simulation results such as queue monitoring with X-graph.

In NS-2, scenarios are described with OTcl scripts. These scripts are generally written manually and follow the organisation depicted on Figure 31 (a complete example is described in the appendixes (Appendix 1).

set ns [new Simulator]

# [Turn on tracing]

# Create topology

# Setup packet loss, link dynamics, trace and monitoring

# Create routing agents

# Create:

# - multicast groups

# - protocol agents

# - application and/or setup traffic sources

# Post-processing procs

# Start simulation

Figure 31: Generic NS script structure

Moreover, simple scenarios can be created in the graphical NAM editor (Figure 32). The Tcl scripts are then directly generated.

Figure 32: The NAM editor interface

58


To facilitate the description of the scenario, NS-2 optionally includes a scenario generator [Sce_gen]. It is composed of three generators: the topology generator, the agent generator and the routing generator.

NS also includes an emulation facility [Net_em, Fal99] to plug the simulator inside a real network as a common node. NS captures live packets according to a filter and then generates and injects packets in the live network when the simulator exits.

Two emulation modes are available:

• The opaque mode in which network packets are not analysed and simply pass through the simulator.

• The protocol mode in which network packet fields are generated by the simulator. Data are interpreted from the real network to the simulator and generated to return to the real network. This mode allows data exchange with a live application.

Unfortunately, this facility is still under development (free BSD 2.2.5) and only two types of network objects are available: IP and Pcap/BPF.

6.2.3.4 Conclusion

The NS-2 simulator is dedicated to IP networks. It is simple and easy to use even if the scenarios must be written in OTcl. Network emulation and parallel simulation are possible. The major drawbacks of NS-2 are its scalability to a great number of nodes and the complexity of extensions development. Table 4 and Table 5 summarise the features of NS-2.

Table 4: NS-2 modelling suitability






Hosting operating systems Windows, Unix, Free BSD


Generic models support (SYNTEX as an integrated simulator)


Possibility to create new models


59


Table 5: NS-2 simulation suitability

Simulation of electricity and telecommunication networks Telecom



GUI for scenario creation/management limited






Type of Licence free of charge


6.2.4 The QualNet Network Simulator

6.2.4.1 Description

QualNet is a commercial discrete event-based simulator developed for an efficient simulation of large and heterogeneous networks [QualNet]. It supports a wide range of networks (MANET, QoS, wired networks, cellular, satellite). It runs on several platforms (Linux, Solaris, Mac and Windows XP OS), as it is developed in Java.

Two simulators are available: the QualNet Developer and the QualNet Parallel Developer. Each one is composed of a set of tools for custom network modelling and simulation projects. These tools are put together under the QualNet Simulation Engine and the QualNet Graphical User Interface.

The QualNet Simulation engine is extremely scalable [Speed, Cla03]; up to tens of thousands nodes can be simulated. It makes possible the simulation of large-scale network with a lot of traffic and mobility in a reasonable time. It pretends to be the most efficient simulator in terms of simulation time and scalability. These results are obtained by an improvement of the simulation engine with, for example, a better management of memory. The simulation speed and the scalability are improved with the QualNet Parallel Developer. Moreover, the simulation engine allows real-time simulation.

60


The QualNet User Interface, called the workplace (Figure 33), is composed of five modules:

• The Scenario designer, to create and set up models and scenarios.

• The Animator, to graphically visualise the simulation.

• The Protocol designer, to model new protocols with a graphical finite state machine tool.

• The Analyser, to analyse the simulation results with statistical graphs.

• The Packet tracer, to analyse the simulation results with a packet level visualisation tool.

Figure 33: The QualNet workplace interface

QualNet is a commercial derivative of GloMoSim (Global Mobile Simulation), which also permits the simulation of large-scale wireless networks and focuses on MANET [Xia98].

QualNet and GloMoSim are both based on the PARSEC discrete event simulation language [Bag98]. GloMoSim uses the parallel simulation ability of PARSEC and QualNet improves it.


QualNet includes two specific tools to model large scale networks in a deterministic way as well as in a stochastic way (with log normal, Rayleign, rician, uniform, exponential and deterministic distribution) for traffic modelling: the scenario designer and the protocol designer.

The scenario designer allows defining the geographical distribution of network nodes, their physical connections and the functional parameters associated to the nodes, with a graphical user interface using intuitive click and drag tools. It also allows the definition of network layer protocols and traffic characteristics for each node. 61


62

QualNet proposes a list of predefined components such as standard nodes, switches, access points, hubs and so on. Other components are also available such as the hierarchical components (HCs) to provide a hierarchical design of the network. These HCs can be considered as autonomous systems and connected with each other. QualNet offers also the possibility to duplicate an entire HC or to create nested HCs.

The protocol designer is a finite state machine tool useful to model custom protocols. It allows the definition of the protocol states, transitions, variables, events, statistics variables, etc. using the GUI. However, the process of each state needs to be coded in C/C++. It is also possible to modify provided protocol models. New models can also be developed directly in C/C++ and added without the GUI.

In addition, the GUI allows the user to develop custom C code for new models by enhancing the simulator with additional functionalities that represent the network behaviour for scenario. This permits the user to indicate to the simulator how, in certain cases, events are processed. It is also possible to extend the API to accommodate it to new developed models. This makes QualNet efficient and extensible.


QualNet simulation engine provides a fast process of the events. This is an essential asset to simulate large-scale networks, with real-time constraints.

This fast process is achieved by a smart memory management (economical use and efficient manipulation of memory), by avoiding unnecessary calculation and by a better organisation of the simulator kernel [Speed].

In this simulator, scenarios are managed by the scenario designer evoked above. It allows the creation of new scenarios that are stored in scenario files (.snc). The saved scenario will contain configuration text files, statistics results and trace results. A defined scenario may be saved either as a common scenario or as a scenario template (used to create new ones). Existing scenarios may be edited for modification or for re-execution. Figure 34 shows an example of topology description.


Figure 34: Example of topology description with the QualNet scenario designer

QualNet allows the generation of node and interface faults in either a deterministic or a stochastic (uniform or exponential) way, by defining the faults in a command line text file. The faults may be static from one time to another, or dynamic, repetition of the faults a certain number of times or continuously during the time the node or the interface is down.

QualNet includes a graphical tool, (the Animator) to visualise the simulation running. The animator allows:

• The selection of the statistics to collect for specified components of the network.

• The possible animation of queues associated to nodes.

• The view of the simulation execution.

• The generation of dynamic graphs from the collected statistics. Examples of graphs are shown on Figure 35.

63


Figure 35: Example of dynamic graphs generated by the QualNet Animator

To increase the simulation speed, QualNet also allows the execution of the simulation from the command line and in batch mode. The simulation results (generated trace files) are then available to be analysed with the appropriate tools.

QualNet provides two ways to analyse the simulation results: the Analyser and the Packet Tracer. These tools require the simulation ends.

The Analyser is a statistical graphing tool. It permits either to choose from all available metrics generated from the scenario simulation in pre-designed reports, or to use the scenario designer to customize own reports.

Statistics can be viewed while they are being generated (i.e., issued from a single scenario simulation), and results can be compared from different experiments. Figure 36 gives an example of the Analyser abilities. All generated graphs are exportable to spreadsheets.

64


Figure 36: Example of use of the QualNet Analyser

The Packet Tracer uses the trace files, allowing the user to follow the packet life cycle. It allows visualisation of the contents of packets as they go up and down in the protocol stack. Figure 37 depicts the Packet Tracer interface.

Figure 37: Example of use of the QualNet Packet Tracer

65


The QualNet simulator provides two other interesting functionalities:

• The ability to make parallel simulations that distribute the simulation on different hosts in order to reduce the simulation time.

• An HLA module that allows QualNet to communicate with another simulator and exchange information in the format of the Federation Object Model. QualNet and its HLA module are already used by war simulation games (real-time networked video game) for a continual feedback loop with the war server [NCW].

QualNet also supports some form of network emulation [Mon03].

6.2.4.4 Conclusion

The QualNet advantages are the complete GUI provided, which is, in our opinion, simpler to use than the OPNET one. It shows a very good scalability, simulation time being reasonable, even on a laptop or desktop computer (tens of thousands of nodes including mobility and high traffic can be simulated in relatively short simulation times). It also provides an efficient HLA module and a detailed documentation.

However, some features are not clearly detailed. For example, QualNet allows the modelling of new protocols with the GUI as well as by directly coding the protocol. Nevertheless, it makes not clear that new components can be created. (This kind of information should be available in the programmer guide that is for programmers who want to develop their own simulation purposes, but this guide is not available in the evaluation version of QualNet).

Table 6 and Table 7 summarise the QualNet features.

Table 6: QualNet modelling suitability



Easiness of integration with other tools through input and output files



Hosting operating systems Windows, Linux, Solaris, Mac


Generic models support (SYNTEX as an integrated simulator) not specified


Possibility to create new models(protocol models)


66


Table 7: QualNet simulation suitability

Simulation of electricity and telecommunication networks telecom







Ability to exchange information with other simulators HLA communication library




6.2.5 The OMNeT++ simulator

6.2.5.1 Description

OMNeT++ is an open source, component-based, modular and open architecture environment for discrete event simulation [OMNeT]. It is free of charge for academic and non-profit use. Its primary application area is the simulation of communication networks, but its generic and flexible architecture makes it possible to use it in other areas like the simulation of complex IT systems, queuing networks or hardware architectures.

OMNeT++ is not a network simulator; however, it is currently gaining popularity as a network simulation platform in the scientific community as well as in industrial ones, and building up a large user community.

OMNeT++ simulation environment is composed of:

• A graphical network editor (GNED) to allow graphical topology build, creating files in the Network Description (NED) language.

• A simulation kernel library containing definitions of objects used for the topology creation and scenario description.

• A compiler for the NED topology description language, to use the topology file for the simulation.

67


68

• Graphical and command-line interfaces (Tkenv graphical user interface and Cmdenv interface) for simulation execution.

• Graphical tools for results analysis: Plove, a graphical plotting tool and Scalars, a graphical output scalars visualisation tool.

• A model documentation tool to create dynamically documentation on the created object-oriented model.

• Utilities (random number seed generation tool, Makefile creation tool, etc.).

• Documentation, sample simulations, etc.

OMNeT++ runs on Linux, other Unix-like systems and on Windows (XP, Win2K) OS platforms.


Models, in OMNeT++, are described through a component-based architecture, where components (modules) are C++ implementations of the different elements of the modelled network.

Two kinds of modules exist: simple modules and compound modules. Compound modules are a set of simple modules. These modules are assembled into larger components and models using a high-level Network Description (NED) language, allowing a hierarchical organisation of the network. These compound modules allow simulation of large-scale networks.

Modules communicate by message exchanges. These messages may represent, for instance, packets in communication networks or jobs in queuing networks. They are sent from a simple module to another simple module, either directly to their destination or along a predefined path. Messages are exchanged through gates (input and output interfaces of the modules) and connections (links between modules). Connections may take place within a single hierarchy level, either between two sub-modules or between a sub-module and a compound module.

OMNeT++ offers the possibility either to modify existing models, or to create new object classes that may be derived from basic object classes (module, gate, connection, etc.). Modules types can be stored in separate files. This allows the user to group existing module types and to compose component libraries.

OMNeT++ implements a deterministic modelling formalism. But it also handles continuous and discrete stochastic variables that give randomness to the model. For continuous random variables, the following distributions are available: Uniform, Exponential, Normal, Normal truncated, Gamma, Beta, Erlang, Chi-square, Student-t, Cauchy, Triangular, Lognormal, Weibull and Generalized Pareto. The discrete random variables are generated in concordance to the following distributions: Uniform integer, Bernoulli, Binomial, Geometric and Poisson. In addition, OMNeT permits to define new distributions (in C/C++).

Another interesting asset of OMNeT is its ability to be integrated with other tools. The whole environment can be customized while the simulation runs, which makes it possible to embed an OMNeT++ simulation into a larger application.


Finally, several open source simulation models are available, in the field of Internet simulations (IP, IPv6, MPLS, etc), mobility and ad-hoc simulations and other areas.


The programmable component-based aspect of OMNeT++ allows the user to describe the network topology without being limited to telecommunication network elements, attributes and functionalities. So electricity supply and telecommunication networks as well as other type of infrastructure can be described with OMNeT++.

The GNED editor, evoked above, allows an easy definition of scenarios. It allows a graphical as well as a script-based description of the topology with the use of modules, gates and connections. Figure 38 shows the GNED interface.

Figure 38: The OMNeT++ GNED editor interface

This editor is able to export the generated NED files into XML format and to import XML files respecting the NED document type definition to create topologies. Since XML is a common way to exchange structured information between applications, this provides a standard mean to interface OMNeT++ with other systems. For example, network topologies stored in an SQL (Structured Query Language) database by a network management application can be imported into OMNeT++ [Var01].

This editor also allows the creation of topology templates to make reusability of models easier. This feature may be useful, in case SYNTEX is an integrated simulator, to model the canonical architectures.

69


70

To simulate large-scale networks, it is also possible to:

• Generate NED files from textual data files with a text-processing program written in awk or perl (perl can interact with SQL database where various topology files can be stored).

• Building the network topology from C++ code. The C++ program reads the textual data file or the database where the topologies are stored.

All the simulation objects are described by C++ classes of the simulation kernel library. Therefore, the simple modules used in the topology, which are the active components of the simulation, are characterised by a C++ code describing the module behaviour. Each module is able to generate, read and react to events (the messages). This behaviour is described either with discrete events or as a finite state machine.

The OMNeT++ simulator includes a set of user interfaces and tools that may be used to perform state estimations of the networks and also to visualise the simulation results. They allow the user to start and stop simulation execution, and eventually to change variables/objects inside the model while the simulation runs.

Since the simulation scenario is described in C++, this code must be compiled and an executable file is generated. Moreover, the OMNeT++ user interfaces are separate libraries that connect to the simulation kernel and to the models via an interface. This means that the simulation executable is a standalone program that can be run on other machines without OMNeT, its simulation interfaces or model files.

OMNeT++ user interfaces used for simulation execution are:

• Tkenv: Tk-based graphical, windowing user interface

• Cmdenv: command-line user interface for batch execution

Tkenv supports interactive execution of the simulation, tracing and debugging. It is recommended in the development stage of a simulation or for presentations, since it provides a detailed picture of the simulation state, at any point of the execution. Its most important features are:

• Separate window for each module's text output.

• Scheduled messages can be watched in a window as simulation progresses.

• Event-by-event execution.

• Execution animation.

• Labelled breakpoints.

• Inspector windows to examine and alter objects and variables in the model

• Graphical display of simulation results during execution. Results can be displayed as histograms or time-series diagrams.

• Simulation can be restarted.


• Snapshots (detailed report about the entire model or specific objects of the model).

The Tkenv interface is presented on Figure 39 with a simulation example.

Figure 39: Example of simulation execution with OMNeT++ Tkenv

The command line user interface (Cmdenv) is a small, portable and fast user interface that compiles and runs on all platforms whether it is UNIX or Windows console. Cmdenv is designed primarily for batch execution.

The simulation outputs are written into three kinds of data files:

• The output vector files, visualised with the Plove tool. They can also be read with other tools like Matlab, Octave, or exported into spreadsheets.

• The output scalar files, visualised with the Scalars tool.

• User own files.

The Plove tool is a tool for plotting and analysing OMNeT++ output vector files. Plove can plot one or more output vectors in a graph. The graphs may be saved to files in various formats (EPS, GIF, etc) or (on Windows) copy them to the clipboard. The Plove tool allows results filtering before plotting (averaging, truncation, smoothing, histogram etc). Some filters are built in and may be modified; new ones can also be created. Figure 40 shows an example of vector files visualisation.

71


Figure 40: Output vector files visualisation with OMNeT++ Plove

The Scalars tool creates bar charts, x-y plots or from OMNeT++ output scalar files. The graphs may be saved to files in various formats (EPS, GIF, etc) or exported via the clipboard, into spreadsheets, etc. Figure 41 shows an example of Scalars use.

72


Figure 41: Examples of output scalar file visualisation in OMNeT++

OMNeT++ includes also parallel simulation functionality. Some research work, on the management of remote simulation on a set of workstations, has been realised in the Remote OMNeT++ project [Erd01, Len97, Len98, Wag01].

6.2.5.4 Conclusion

The OMNeT++ simulation tool allows the modelling and simulation of networks in a generic way. Models already exist for telecommunications but this simulator can be easily used and extended (since it is open source) to simulate other kinds of infrastructures. This is an important feature in case of designing SYNTEX as an integrated simulator.

73


Its modularity and portability make it an interesting candidate for its integration within SYNTEX. The modelling and simulation features of OMNeT are summarised in Table 8 and Table 9.

Table 8: OMNeT modelling suitability

Modeling suitability

Enabling stochastic modeling Continuous as well as discrete variable representation Easiness of integration with other tools Hierarchical modeling support Possibility of hosting heterogeneous modeling formalisms deteministic and stochastic

Hosting operating systems Windows, Unix/Linux

Ability to be distributed on a platform network possible parallel simulation

Generic models support (SYNTEX as an integrated simulator) Possibility to extend/modify existing and predefined models Possibility to create new models

Table 9: OMNeT simulation suitability

Simulation of electricity and telecommunication networks generic modelling

Simulation of SCADA system componentsGeneration of disturbances/corruptions inside the simulatednetworks defined in C++ code

Available analysis tools for state estimations of the network, resultsanalysis, etc. Network visualization tools and network data base systems


GUI for scenario creation/management GNED for topology

GUI for model creation/management use of a C++ editor for component behaviour

Ability to create archives containing logs of the networks status andthe operative actions (with snapshots)Consideration of external information as input




Fast simulation capabilities not specified

Type of Licence commercial, free for academic and non-profit use


74


6.2.6 The J-Sim simulator

6.2.6.1 Description

J-Sim (Java Simulator) is a free of charge implementation for simulation of a component-based architecture, the Autonomous Component Architecture (ACA). The ACA mimics the integrated circuit design and manufacturing model in terms of how components are specified, designed and assembled [J-Sim]. J-Sim includes a specific platform, dedicated to network simulation, the Internetworking Simulation Platform called INET, but is not limited to this field. Its organisation is similar to the one of OMNeT++.

J-Sim is a real-time process-driven simulator, in other words, a simulation runs in the same manner as a real system does, in the sense that event executions are carried out in real time as opposed to at fixed time points in discrete event simulation.

As in NS-2, two languages are used in J-Sim: Java to describe and implement models and a script language to construct, configure and/or control the simulation at run-time. J-Sim has been designed to support Tcl, Perl or Python script languages, however, the available implementation is based on Tcl. J-Sim provides specific Tcl commands, the Runtime Virtual (RUV) commands, to simplify the manipulation and the configuration of the network components during simulation runtime.


In this architecture each network entity (node, link, network interface card, protocol instance or even a whole network) is a component. Each component connects each other through ports, by which data flows are exchanged. A component, particularly a node or a network, can be composite, that is to say composed of several inner components, (nodes, links or other networks for a network component; network interfaces, protocols or applications for a node component). Figure 42 summarises the component and composite component notions

Figure 42: Components and composite components in J-Sim

The behaviour of a component is described with a contract. Two types of contracts are available: the port contract and the component contract. The port contract is specific to a port of the component. It describes the communication pattern of the component with the other components that are connected to this port. The component contract represents the input/output relation of a component. Therefore, these contracts describe when and where data arrives at each of its ports, how data are processed and if the component generates output and at which port.

The models described and used in J-Sim are deterministic. However, they allow the use of stochastic variables linked to the traffic model. As in NS, exponential and Pareto traffic models are included.

75



J-Sim includes the INET platform that is dedicated to network simulation. However, its component-based architecture allows the modelling of all kinds of infrastructures. Since a component is a “box” that receives input flows and send output flows through ports. A component and its ports can be used to represent telecommunication networks as well as electricity networks. Moreover, this simulator is open source; therefore, it can be extended to support power supply modelling.

J-Sim offers the possibility to disable components. Disturbances can be generated, for instance by disabling a link or a node, creating failures inside the simulated network.

A GUI, the G-editor (Figure 43), allows the graphical creation and edition of a simulation model. Each simulation model is saved as an XML file. It also allows to run simulations based on the model and to act on the simulation while it is running. For example, it is possible to access the properties of each network component.

The simulation results can be collected of three ways:

• Directly saved in a trace file (.trace) to be analysed later.

• Displayed online on a XY graph using the plotter component or saved in a .plot file to be displayed later.

• Saved in a trace file at the NAM format (file .nam) to be displayed with the network animation tool of NS-2.

Figure 43: J-Sim Graphical editor interface

76


J-Sim also accepts trace files, representing the incoming traffic, as input. Moreover enhancements have been done to plug real Java applications generating traffic to the simulator.

6.2.6.4 Conclusion

J-Sim is similar to OMNeT++ on several points; For example, it has a component-based architecture enabling generic modelling and it can store models in XML files. Its advantage, compared with OMNeT++, is that it is free of charge.

Unfortunately, it does not integrate as many features as OMNeT++. Common features are less efficient. The OMNeT++ GUI integrates more tools and functionalities than J-Sim. In addition, the J-Sim simulation performance is not documented. The modelling and simulation features of J-Sim are summarised in Table 10 and Table 11.

Table 10: J-Sim modelling suitability






Hosting operating systems all support






77


Table 11: J-Sim simulation suitability

Simulation of electricity and telecommunication networks generic modelling

Simulation of SCADA system componentsGeneration of disturbances/corruptions inside the simulatednetworksAvailable analysis tools for state estimations of the network, resultsanalysis, etc. a plotter only

Network visualization tools and network data base systems a plotter only


GUI for scenario creation/management (Tcl writting even so necessary)

GUI for model creation/management component behaviour coded in JavaAbility to create archives containing logs of the networks status andthe operative actions in output files

Consideration of external information as input





Type of Licence free of charge


6.2.7 The SSF framework

6.2.7.1 Description

SSF (Scalable Simulation Framework) is a public domain standard developed by the S3 (Scalable Self-Organising Simulations) consortium [S3, SSF]. It allows discrete-event simulation of large and complex systems. Two major implementations are available: Raceway in Java and DaSSF (Dartmouth SSF) in C++ [Race, DaSSF]. Raceway runs on every platform due to its Java kernel. DaSSF is only available to UNIX-like platforms.

To build a simulation in SSF, the following steps are required:

• Define the model.

• Define the scenario. Since SSF is process oriented, all events of the simulation are described as messages sent and received between the network entities.

• Define the topology of the simulation network.

• Define the simulation environment, in other words, the hardware platform (number of machines, number of processors on each machine) supporting the simulation running.

• Define the simulation runtime information, for instance the beginning and termination times, the topology and the simulation environment used.

78


79

• Create a makefile including all the files required for the simulation (i.e. the files defined previously)

Models and scenarios may be defined either in Java or in C++, depending on the chosen implementation (Raceway or DaSSF).

The topology, simulation environment and simulation runtime are described with a specific language called DML (Domain Modelling Language) [DML]. The topology is stored in a model.dml file, the simulation environment in a machine.dml file and the simulation runtime information in a runtime.dml file. This last file refers to the two others for topology and simulation environment used.

This feature eases the reusability of scenarios (topology, simulation environment, behaviour) in different conditions. For instance, a same scenario may be simulated on different topologies and distributed on various simulation environments.


Models defined in SSF are described through five object classes: entity, process, inChannel, outChannel and event. An entity is a container for simulation state variables. It relates to a logical process in the simulation. For example, hosts or routers are entities. A process describes the state evolution of an entity depending on its interactions with other entities. The channels allow interactions between entities. inChannels and outChannels are respectively the end and starting points of any communication link. An inChannel is an incoming channel of an entity. It allows the reception of events. A process can wait on one or several inChannels for messages to arrive. When a message is received, the message can be mapped on one or more outChannel that represent the outgoing channels of an entity. An outChannel can be mapped on one or more inChannels. An entity object may own one or more process, inChannel and outChannel. Finally, Events are the messages sent between the entities.

This simulator proposes a wide range of functions to generate continuous as well as discrete random variables for traffic distribution. DaSSF offers uniform, exponential, Erlang, Pareto, normal, lognormal, Chisquare, Student continuous distribution, and Bernoulli, equilikely, bionominal, geometric, Pascal and Poisson random variables distributions.

SSF is process-oriented but extended functionalities allow the use of discrete event scheduling by the definition of a new class, the DirectInChannel in DaSSF, on which common routines (not processes) are attached.

Finally, only the Raceway implementation seems to support hierarchical modelling of networks. This aspect is not approached in the DaSSF documents [DaSSFUM].


The five classes (entity, process, inChannel, outChannel and event) described previously are generic classes, not linked to a specific infrastructure. Therefore all types of infrastructures can be modelled and simulated within SSF.

As for OMNeT++, disturbances and failures must be described in the code (C++ or Java depending on the implementation used). SSF proposes process functions that allow to put any entity in a waiting state.


No GUI is available with DaSSF, neither to model the system nor to visualise the simulation results. This does not facilitate the creation of models and scenarios, the generation of disturbances and the visualisation and analysis of simulation results. However, data can be collected and then returned to the user after simulation in output files.

Unlike DaSSF, the Raceway implementation proposes a software tool, Raceway Views, enabling the graphical visualisation and edition of large network configuration, including navigation in large hierarchical networks. It also displays network simulation (view of measurement data streams and of time series plotting). Few documents are available on this subject.

Finally, SSF allows parallel and distributed simulation by maintaining multiple event queues, and executing them on multiple processors with proper synchronization. It pretends to propose fast simulation capabilities.

6.2.7.4 Conclusion

SSF is a component-based simulation tool. It allows generic modelling and simulation of an infrastructure. It is telecommunications-oriented but can be extended to support other infrastructures. In addition to its generic modelling, the separate storage of topology, simulation environment and of simulation runtime information is an advantage as it increases the reusability for the creation of new scenarios. Finally, SSF is gaining popularity, for instance simulation results using SSF have been presented during the IEEE SIGCOM conference in December 2005.

Unfortunately, it integrates less features than other tools like OPNet, QualNet and OMNeT++. Moreover, the use of the DML Language requires some expertise and does not simplify the integration of SSF with other simulation tools, due to this specific input format.

Finally, DaSSF is well documented but it does not integrate a GUI and Raceway proposes a GUI but little documentation is available.

Table 12 and Table 13 summarise the modelling and simulation features of SSF.

Table 12: SSF modelling suitability




Hierarchical modelling support(Raceway implementation)


Hosting operating systems Raceway: multi platformDaSSF: Unix OS






80


Table 13: SSF simulation suitability

Simulation of electricity and telecommunication networks generic with focus on telecom

Simulation of SCADA system componentsGeneration of disturbances/corruptions inside the simulatednetworksAvailable analysis tools for state estimations of the network, resultsanalysis, etc. Network visualization tools and network data base systems Raceway


GUI for scenario creation/management Raceway

GUI for model creation/management RacewayAbility to create archives containing logs of the networks status andthe operative actionsConsideration of external information as input not specified


Interactions with the real network/system not specified

Ability to exchange information with other simulators not specified


Type of Licence GNU Public licence


6.2.8 The Dynamic Network Emulation Backplane Project

6.2.8.1 Description

The Dynamic Network Emulation Backplane is a project directed by the Georgia Tech Lab [DNEB]. It proposes a parallel and distributed real-time simulation platform that allows the use of various heterogeneous simulation tools simultaneously [Ril01].

Figure 44 depicts the backplane architecture. It shows that the Backplane supports insertion of multiple network simulators, which together emulate an intermediate virtual network. Each simulator exchanges event messages with the backplane in its native format. The backplane converts the messages in a common and dynamic format, and forwards them to the other simulator(s).

In addition, live applications (e.g. Netscape) can be integrated into the simulation execution via the Veil library. This library is designed to transparently capture and re-route network data from the live applications via the virtual network using the backplane.

81


Figure 44: DNEB Backplane system Architecture

The network simulators are supposed to run faster or, at least no slower than real-time, when executed on a cluster of one or more workstations. The applications themselves run in real-time, with either human or embedded system in the loop. The backplane is implemented using a high-performance runtime infrastructure package (the Federated Simulations Development Kit – FDK) also developed by the Georgia Tech Lab.

This project is not restricted to a cooperation of simulators located on different hosts. It allows partitioning of the protocol layers (split protocol stack method) among the cooperating simulators, according to their ability to model these protocols [Xu01]. For example, for a simultaneous use of NS-2 and GloMoSim, NS can be used for TCP simulation (due to its rich set of TCP models) and GloMoSim can be used for the IP and MAC layers simulation (due to its wide range of wireless IP/MAC models).


Due to simulator cooperation and the split protocol stack method, the backplane can get the best models of each simulation tools and therefore obtain a complete and suitable model library. It makes the backplane flexible.

The split protocol stack method is achieved with an insertion of the backplane between the protocol layers that are modelled and simulated by different simulation tools. Therefore, the Backplane is used as an exchange medium between the layered simulators as it is done for simulators located on different workstations. Moreover, to avoid a parallel event processing of the simulators, they introduce the concept of master/slave between the simulators (the lower layer simulator being the master and the higher level the slave). Shared variables are used to synchronize different simulators [Xu01].

However, this split of protocols layer between different simulators generates certainly difficulties to model the network. This problem is not mentioned in the available documents.

82


83


As for modelling, the simulation suitability mainly depends on the simulation suitability of the used simulators.

To optimise the execution speed of simulators, the members of this project propose a method to parallelise network simulators [Wu01]. This method decomposes the system to model it into subsystems, each instantiating a different simulator. Each simulator is then extended to allow data exchange and synchronization with other simulators. A parallelisation of OPNET is also described.

In addition, they propose a parallelised and distributed version of NS [PDNS] that has been evoked in Section 6.2.3.2. To improve the parallelisation of NS, they introduce the notion of Nix Vectors that are dynamically created vectors that replace routing information. The routing tables are suppressed. The routes are computed on-demand and are stored directly in the simulated packets [Ril00]. This method reduces the use of memory and allows larger-scale network simulations.

Nevertheless, despite the provided optimisations, the use of several simulators in a same protocol stack slows down the simulation speed due to the intermediary exchanges between the simulators and the backplane [Xu01].

In addition, no explanation is available on the scenario description when using the split protocol stack method. Do the simulators exchange information by input/output trace files? This is not mentioned in the available documents.

6.2.8.4 Conclusion

The interesting feature of this tool is its ability to emulate large-scale networks and to distribute the simulation among heterogeneous simulators. It may be interesting to consider this work in case SYNTEX is designed as an overlay for dependency information exchanges.

Since the modelling and simulation power of the Backplane depends on the simulators used, it is not useful to summarise its features with the comparison tables.

6.2.9 Summary

This section focused on the telecommunication simulators with interesting features and functionalities that may be integrated within SYNTEX. Two types of simulators are highlighted: telecom-dedicated simulators (OPNet, NS-2 and QualNet) and generic simulators focusing on telecom networks (OMNeT, J-Sim and SSF).

Except for NS-2, the telecom-dedicated simulators include a wide variety of features as well as a GUI for model and scenario definition and for simulation display and results analysis. QualNet seems to be easier to manipulate than OPNet but OPNet is a more complete simulation toolbox. Finally OPNet and QualNet both include an HLA module to allow communication between running simulations.

The most complete generic simulation tool is OMNeT. This tool includes a lot of functionalities and an efficient GUI that can be compared to QualNet and OPNet ones. The two generic simulators have interesting aspects (XML format storage for J-Sim, reusability of parts of


scenario for SSF), however, they do not compete with OMNeT in terms of functionalities or GUI.

Finally, the Backplane project allows the simulation of large-scale networks, using existing simulators and by the exchange of data between the communicating simulators. It offers an alternative to HLA that is complex and difficult to implement.

The following tables (Table 14 and Table 15) compare the features of the main simulation tools for modelling and for simulation.

Table 14: Comparison of the telecom tools modelling suitability

Modelling suitability OPNET NS QualNet OMNeT

Enabling stochastic modellingContinuous as well as discrete variable representationEasiness of integration with other tools

through input and output files


Possibility of hosting heterogeneous modelling formalisms

deteministic and stochastic




Hosting operating systems Windows 2000/XP, Linux, Sun Solaris

Windows, Unix, Free BSD

Windows, Linux, Solaris, Mac Windows, Unix/Linux


possible parallel simulation

Generic models support (SYNTEX as an integrated simulator) not specified not specified

Possibility to extend/modify existing and predefined modelsPossibility to create new models not specified

(protocol models)

84


Table 15: Comparison of the telecom tools simulation suitability

Simulation suitability OPNET NS QualNet OMNeTSimulation of electricity and telecommunication networks Telecom Telecom Telecom Generic modelling

Simulation of SCADA system componentsGeneration of disturbances/corruptions inside the simulated networks

defined in C++ code

Available analysis tools for state estimations of the network, results analysis, etc. Network visualization tools and network data base systemsPossibility to design, archive and modify scenariosGUI for scenario creation/management limited GNED for topology

GUI for model creation/management use of a C++ editor for component behaviour

Ability to create archives containing logs of the networks status and the operative actions (with snapshots)Consideration of external information as inputCreate of trace files of the simulation resultsInteractions with the real network/systemAbility to exchange information with other simulators

HLA communication library


Type of Licence commercial free of charge commercialcommercial, free for

academic and non-profit use

6.3 Electrical networks-specific simulation tools

6.3.1 Introduction

The following sections detail the features of several commercial simulators: the Siemens PSS family (NETOMAC and SINCAL), the PowerWorld simulator and the PSCAD simulation tool. Other tools are presented in Appendix 3.

In addition to the previous electrical networks simulators, we present SEPIA, whose particularity is to consider that the electricity market aspects impact the electricity supply behaviour.

All these simulators are described in the following subsections.

6.3.2 The Siemens Power System Simulation Software

Siemens proposes the Power System Simulation (PSS) family software for network calculation, analysis, coordination of time-over current protection, current transformer dimensioning and protective settings check (Figure 45). This suite is a family of tools for all engineering tasks associated with networks and installations. The family is also suitable for Pipe

85


Network (Gas, Water, District Heat) Simulation, which is not considered in this document. The two main simulation tools are detailed in the two next sections.

Figure 45: Overview of main PSS software topics.

TM6.3.3 PSS Netomac

6.3.3.1 Description

NETOMAC (Network Torsion Machine Control) simulates dynamics and transients behaviours within a milliseconds time frame. It offers a wide range of methods for analysis and synthesis of electric power systems. In order to design individual elements of transmission systems or to perform transient and dynamic calculations on large systems, it is possible to simulate electrical networks in the time domain. Likewise, it is possible to study the frequency domain with the aid of eigenvalue calculations. These methods find general application in the design of control systems and in analysing the behaviour of large networks.

The tool provides a GUI to specify electrical systems and control structures. A database is used for all calculations, regardless of the domain (time or frequency) investigated. With the aid of filters, it is possible to transfer data from other simulation programs to the NETOMAC database.

Apart from simulation in the time domain and the latest methods for computing in the frequency domain, the system can also deal very effectively with the optimisation of electrical systems and the identification of component parameters. A number of examples are given to demonstrate the versatility of the program system. They show the considerable flexibility and adaptability that NETOMAC can offer its users.

In addition to a variety of existing elements and models, it is a simple matter in all the program modes to define any user-related models, which allow optimum matching to the particular problem under examination.

86


All computing options are based on a uniform database, which allows various problems to be analysed without the need for any additional conversion of data, such as ascertaining system stability in the time domain with subsequent modal analysis in the frequency domain.

Figure 46 shows the frequency domains that NETOMAC currently supports. They range from extremely fast-travelling wave phenomena on overhead power lines to the control phenomena of power stations including their steam systems. A real-time simulation of electromechanical transients is also possible.

Figure 46: Frequency domains for NETOMAC simulation

A variety of program configurations is available – from “Light” to “Professional”, as shown on Figure 47.

87


Figure 47: NETOMAC program configurations

Netomac light

Studies of dynamic phenomena in electrical power supply systems are becoming a more and more important part of the daily work of electrical engineers. The NETOMAC Light interactive system has been developed to make the task of getting into dynamic simulation much simpler. It offers:

• Ease of use when performing dynamic studies, thanks to the intuitive user interface

• Automatic and interactive creation of NETOMAC input files and standard COMTRADE result files

• Library of predefined model networks so that the dynamic performance of networks can be handled quickly

• Libraries of standard network elements, e.g. machines, transformers, cables, overhead lines, machine and network controllers

• Testing of protection equipment and control devices under real conditions with different network configurations on real-time

• Help in the form of expert knowledge in the design of networks

Netomac professional

NETOMAC professional offers a great variety of possibilities:

• Simulation of electromagnetic and electromechanical transient phenomena in time domain

• Steady-state load-flow and short-circuit current calculations

• Frequency range analysis

• Eigenvalue analysis 88


• Simulation of torsional vibration systems

• Parameter identification

• Reduction of passive and active networks

• Optimisation

• Interactive network training simulator

• Real-time simulation

• Extended user interface for the graphical input of network and controllers structures and documentation of results

• Data import from other planning packages, e.g. SINCAL, PSS/E, etc.

• Additional formats for data export


NETOMAC is intended for power system analyses.

It permits the modelling of program elements, network elements, machines and load flows.

• Program elements.

The most various system elements are available for the wide frequency spectrum in which the program system can be applied. Figure 48 shows a number of these simulation models schematically.

Figure 48: Demonstration of NETOMAC simulation models

89


90

• Network elements.

Apart from linear, non-coupled or coupled R, L and C elements, which can also be multi-phased, linear elements are also present. These include, for example, inductances, thyristors, diodes, GTOs or surge arresters and spark gaps. Other non-linear elements can be entered by the user related to the application by graphical input means with the aid of a block-oriented simulation language (BOSL) integrated in the program. Examples are variable admittances (Var-Y), variable active/reactive elements (Var P/Q) or variable voltage and current sources. A wide spectrum is thus available, for example for the modelling of passive and active network elements of the FACTS family (Flexible AC Transmission Systems), such as static compensators or series compensation with thyristor or GTO techniques. The latest elements of this family, such as the unified power flow controller, are also available.

Single and multi-phase overhead power lines and cables can be input as homogeneous lines or via PI elements with frequency-dependent parameters. The constants and parameters of overhead power lines can be determined via a special program section from the geometry of the configurations (e.g. Marti model for cables). Transformers are implemented as 2- and 3-winding transformer models and as 3-phase autotransformers with any vector group. Single-phase transformer models are also available. Other models can be implemented by the combination of ideal isolated transformers with optional linear and nonlinear elements. The transformation ratio can be controlled as defined by the user (Var-Tap element). The specified open or closed-loop control is graphics-aided and defined by the user.

NETOMAC also possesses voltage and current sources, both sinusoidal and controlled according to structures defined by the user. Complex network models, such as HVDC (High-Voltage DC Transmission) and FACTS can be established as base frequency models for investigations in the stability domain or as commutating models for detailed investigations in the instantaneous value mode. The open and closed-loop control structures can be defined by the user.

• Machines.

Apart from the great number of network elements, various machine models are also available. Synchronous and asynchronous machines are modelled as standard equivalent circuits (Park model). A universal (user defined) equivalent circuit of the rotor of machines (so-called free rotor circuit) for 3 and single-phase machines (e.g. traction generators) is available. Main and leakage flux of machines can be plotted taking saturation into account.

Machines can be coupled mechanically via the shaft (e.g. 50 Hz/60 Hz frequency converter). The machine models can also be supplemented by a torsion spring mass model of the shaft as torsional oscillation system.

These multi-mass oscillation systems permit the investigation of mechanical resonances due to disturbances in electrical networks both in the time and frequency domains.

The control devices of the machines are entered aided by user-defined graphics. Besides optional voltage and turbine controller structures, protective functions of machines, such as underfrequency, undervoltage, overcurrent time or underexcitation protection, are pre-programmed and can be parameterized as required. The user’s own protection structures can be implemented easily via the graphic input. A special stability model is available for long-term simulation.


91

• Load flows.

For any simulation of electrical networks it is necessary to determine the load flow conditions and the initial conditions of the simulation elements as a precondition for the subsequent computation by integration of the system differential equations. NETOMAC uses a current iteration process with constant node admittance matrix for determining the system working point. Compared to methods with a quadratic convergence, such as the Newton method, this method is more robust and flexible in critical load flows, which offers the advantage of solving the most varied load flow situations. In NETOMAC, the load flow is not restricted to three-phase or symmetrical systems. Single-phase load flows and multi-phase, also unsymmetrical load flows can be calculated with inductive and capacitive couplings.

With the aid of supplementary program parts, the coupling matrices can be determined directly from the conductor geometry. Hence, interference problems, such as with traction power supply or between overhead transmission lines and telecommunication systems, can be calculated. Calculations with the simulation of homogeneous lines are also possible, for example to determine the voltage profile along the line.

Due to the many user-definable loads and network elements, it is necessary to consider the voltage dependence of loads or the automatic setting of transformer tap changers already in connection with the load flow. The action of protective devices (e.g. undervoltage protection or overcurrent protection) or controlled reactive power compensation (such as static compensator or controlled series compensation) is considered in the load flow. In the same way, the steady-state behaviour of HVDC systems is integrated in the load flow.

With asynchronous motors, the slip and thus the reactive power required is matched automatically depending on the load. This provides many possibilities of also using the load flow calculating part of NETOMAC separately from other simulating possibilities.

The output of load flow results can be matched to the particular requirements so that every user can produce his/her own problem-related output tables.

There are two ways with NETOMAC to model the system and its components:

• Using models.

During the long period of application, a large number of models have been established for NETOMAC. Some of the most important ones are listed below. They are available as macros or can be called down from a library:

- Voltage controller according to IEEE (or user defined) - Turbines and turbine controllers according to IEEE (or user defined) - HVDC system models for instantaneous value mode and stability mode including

automatic control - Multi-terminal HVDC systems including automatic control - Models for FACTS element (for instantaneous value mode and stability mode)

o Static compensator (thyristor and GTO technology) o Controlled series compensation (thyristor and GTO technology) o Universal load flow controller(thyristor and GTO technology)

- Models for superconducting storage units (for instantaneous value mode and stability mode)

- Models for circuit-breakers taking arcing into account - Models for asynchronous machines


92

- Models for arresters

• Using the block oriented simulation language (in case of optional complex functions).

More than 100 different function blocks are available in a library which can be combined to any open or closed-loop control structures or evaluation devices by means of the graphic interface. Besides very simple blocks, such as PID elements, there are also complex “blocks”, such as FFT (Fast Fourier transformation).

The controllers can be stored as macros in a library so as to link them quickly to a system. Parameterising can be input individually and changed, or the preset (default) values can be used.

Specific blocks, such as load step change relays for turbines, are available, as are blocks for power electronics functions, such as firing pulse blocks. This permits digital sampling controllers to be established, for example.

Optionally complex open and closed loop control and protective functions can be implemented with the block-oriented simulation language on machines and in the network.

Besides the open and closed-loop control structure, signal processing structures can also be defined by the user (evaluation devices). External, user-defined subroutines can also be coupled (open-loop) and there is an interface to real-time applications (closed-loop).

The block-oriented structures can be combined with FORTRAN-like terms, such as mathematical functions, logical terms or instructions, e.g. IF/THEN/ ELSE and GOTO/CONTINUE. Input variables are available to the controllers in all sizes from the networks and machines. In addition, the variables from other closed and open-loop controllers or the evaluation structures can be used as input variables. All inputs and outputs of blocks can be output.

In conclusion, NETOMAC offers a wide variety of available models and further can be created, but only relevant for network operation. Currently, it is not foreseen to model interdependencies, especially with telecommunication industry.


NETOMAC provides the most important methods for the analysis of dynamics of electrical networks in the time and frequency domains.

Figure 49 shows the possibilities offered by NETOMAC for simulating electrical systems. Two ways are feasible in the time domain, whereby the instantaneous value mode permits the representation of electrical systems phase by phase. Symmetrical systems are supplemented to form three-phase systems by inputting a phase. Unsymmetrical systems can be taken into account by elements in the individual phases. That is also possible for any DC systems.

The instantaneous value mode thus permits the complete solving of any electromagnetic and electromechanical problems. The so-called stability mode is available concurrently with the instantaneous value mode. Where the admittances are represented by differential equations in the instantaneous value mode, the stability mode permits the network to be described single-pole by complex admittances. This produces a pure fundamental-wave model of the network which permits the simulation of electromechanical transients.


Generators and other machines are represented in the stability mode by differential equations of a reduced order. Moreover, calculation is also possible by means of symmetrical components (0-1-2 system) so that even unsymmetrical faults can be calculated in the stability mode.

In NETOMAC, analyses in the frequency domain are integrated in addition to calculations in the time domain. For this purpose, the whole system is linearised automatically, including the network, machines, control loops, machine shafts, etc., about the working point of the system, starting from the load flow situation. Thus, the small signal behaviour of the whole system is available. The network, machine or control loop can be represented by a transfer function (Bode diagram, Nyquist diagram). Thus, automatic control devices, for example, can be designed by conventional methods. Moreover, the calculation of eigenvalues is available in NETOMAC. This permits the oscillation behaviour of systems to be determined and information to be given on the stability, controllability, observability, damping and oscillation of the state variables of the system. Based on this, automatic control devices, such as power system stabilizer, can be configured, or dynamic, reduced models designed in which only the dominant state variables are considered.

Figure 49: Possibilities offered by NETOMAC for simulating electrical systems.

In the instantaneous value mode, NETOMAC solves differential equations by the differential conductance method. The integration is made according to the trapezoid rule which assures global, numerical stability. The system matrices are sparse, which is taken into account with regard to storage and solution methods, for example for matrix inversion or multiplication (triangular factorization, forwards-backwards substitution …).

Discontinuities are interpolated with half time steps by means of implicit Euler methods. In the case of system changes, interpolation to the past takes place for exact determination of zero crossings. The firing pulses are considered especially for converter valves, separated according to firing time and pulse.

The instantaneous value mode permits modelling of the network, machines and controllers. It offers a complete solution for all electromechanical and electromagnetic phenomena, including unsymmetrical and non-linear processes.

93


94

The main field of application is the design of power system equipment, taking transient phenomena into account. An example is the determining of valve loading of a static compensator during and after short-circuits in the network.

The stability mode of NETOMAC differs from the instantaneous value mode by the simulation of the network in the form of complex impedances instead of differential equations. Controllers and machines are modelled as differential equations. Machines are used as differential equations of a reduced order (neglecting flux changes in the d and q axes).

In the stability mode, the system is considered single-pole. Typically, the stability of multi-machine systems is considered here. In order to be able to consider unsymmetrical faults in addition to symmetrical faults, such as three-pole short-circuits, a universal disturbance scenario is possible with the aid of symmetrical components (0-1-2 system).

The calculation in the stability mode can also be supplemented by parallel calculations in the instantaneous value mode. This permits the consideration of complex transients in connection with the stability of large systems. An example of this is the commutation in HVDC systems which can influence the overall system stability in the event of fault conditions. This permits the accuracy of the calculations in the instantaneous value mode for individual parts of the system to be combined with the extensive system in the stability mode.

Besides the interlinked calculation in the instantaneous value and stability modes, a sequential changeover between the two calculation types is possible to permit exact assessment of transients during the consideration of stability. In the stability mode, HVDC systems and FACTS are interfaced by variable admittances or variable sources (current, voltage, power), whereby the individual control loops are simulated in detail.

Various possibilities of fault simulation are implemented in NETOMAC. Very many faults are initiated by the change of impedances, which takes place according to various criteria:

• Voltage scanning • Current scanning • Three-phase switching at current zero of one or more branches • Switching taking arcing voltages into account

Other fault conditions can be the result of changes in the initial angle after load flow or of a change in system frequency. Via the elements of variable admittance or variable active/reactive power, complex faults can be defined by the user whom switches off machines, open lines, decouple or initiate load shedding scenarios.

Optional fault conditions can be obtained via the symmetrical components. Other disturbance scenarios are possible by switching over between the instantaneous value mode and the stability mode.

Besides the possible simulations in the time domain, the program system also permits the consideration of networks, machines, shafts and open and closed-loop controllers in the frequency domain. Hence, the analysis of closed-loop control elements is just as possible as the examination of networks, protective devices or machines at various frequencies.

In large electrical systems, the relationships between generators, network and closed-loop control devices are becoming ever more complex. FACTS elements are being used for fast, active closed-loop control of transmission systems and for filtering in distribution systems.


Figure 50: NETOMAC Eigenvalue calculation 95


96

Modern processes describing the behaviour of the system in a simple and clear manner are required for analysing the interaction of these complex operating media. For this purpose, the system eigenvalues are analysed in NETOMAC. Compared with the traditional simulation approach, this methodology provides more information on the system behaviour with respect to damping, frequency behaviour, observability, controllability and mutual influencing of system conditions. Special fields of application of eigenvalue analysis are intersystem oscillations, voltage stability, modelling of dynamic equivalents, controller design, sub-synchronous resonances or harmonics effects (Figure 50).

The possibility of optimising can be applied to any NETOMAC system. All modelling possibilities described are permissible so that linear and nonlinear problems can be solved. The user defines the target function with the aid of the graphics interface as evaluation function with any input variables from the network or the control loop. Secondary conditions can be considered as defined by the user.

The parameters to be varied are selected by highlighting and providing with a starting value and possible upper or lower variation limit. Optimising is possible in the frequency domain, with load flow and for general mathematical functions that are defined as block optimised structures.

The input for the NETOMAC program system is implemented graphically with the aid of the NETCAD program system. NETCAD is a drawing tool that is simple and quick to operate for implementing, editing and documenting of electrical systems and control structures.

Besides familiar CAD functions, such as copying, shifting, rotating, zooming, etc., the system has a large symbol library which contains all elements of the NETOMAC program in the form of symbols. The user establishes system diagrams and the block diagram by graphical connection of library symbols (generator, transformer, lines, controller blocks, etc.). The data is input via masks that are object-related and have abbreviated aid texts in addition to detailed aid texts.

It is also possible to combine groups of linked symbols to form independent new symbols as macro models and to add these to the symbol library or to the user’s own library. For example, complex control structures or partial networks consisting of a large number of equipment can be combined to form new symbols. On the basis of this hierarchical structuring capability, the system makes it possible to decide, according to requirements and for the same database, in how complex or simplified a way a system can be illustrated.

Individual components can be activated and deactivated and connected to any desired part of the system. It is thus possible to show and simulate in a simple and clear manner, the behaviour of various FACTS elements at various points in the network.

NETOMAC offers a wide variety of possibilities for preparing the proper network calculations by way of special pre-processing modules. The most important of these are:

• Reducing order of passive networks by parameter identification • Reducing order of active networks by eigenvalue analysis • Reducing order of dynamic load models • Parameter identification of asynchronous motors, taking saturation into account • Determining overhead transmission line and cable data from the geometry (frequency-

dependent parameters or coupling matrices)

The result outputs in the NETOMAC system are many and various and extend from a simple representation of simulation variables versus time right up to complex evaluations,


97

such as a Fourier analysis and stresses in machine shafts. The graphics output is either on a monitor screen, on printers or plotters, or in metafiles for further processing in text-editing systems or graphic programs. It is also possible to prepare result lists that can be processed further with other program systems. This kind of further processing takes place for example when the computer simulation is interfaced with an analogue real-time simulator.

Another possibility of interfacing the computer simulation with real-time applications in closed-loop operation is implemented via the block-oriented simulation language and via external devices (converters, amplifiers).

As individual outputs are available Machine variables, Network and load variables and Controller variables.

At the moment, it is not foreseen to model interdependencies, especially with telecommunication industry.

6.3.3.4 Conclusion

The NETOMAC program system presents a multitude of possibilities for simulating all electromagnetic and electromechanical phenomena in electrical systems. The analysis in the frequency domain usefully supplements the processing possibilities. The eigenvalue analysis opens up numerous methods leading further, such as the establishing of dynamic, reduced network models by reducing the order.

Many kinds of pre-processing are available, such as parameterising of power lines or motors and identifying of model parameters. The possibilities of system analysis are supplemented by user-defined optimising processes. With all this, NETOMAC offers numerous possibilities like no other comparable simulation system.

PSSTMNETOMAC links up the most important methods for the analysis of dynamics of electrical networks in the time and frequency domain. It is a program for all tasks associated with the dynamic phenomena of electrical networks. It presents real-time capability for protection testing and network security calculations thus providing fast response when network problems occur.

The modelling and simulation features of NETOMAC are summarised in Table 16 and

Table 17.


Table 16: NETOMAC modelling suitability

Erreur ! Des objets ne peuvent pas être créés à partir des codes de champs de mise en forme.

Table 17: NETOMAC simulation suitability

Simulation of electricity and telecommunication networks Dynamics and transients behaviours of electric power systems


Possibility to design, archive and modify scenarios not specified



Creation of trace files of the simulation results






TM6.3.4 PSS SINCAL

6.3.4.1 Description

TMThe PSS SINCAL (Siemens Network Calculation) program for system analysis and planning has been created to simulate, display and evaluate power transmission and distribution systems.

SINCAL is a static simulation program, but the main NETOMAC features are integrated as a module in SINCAL.

This tool is well suited for the needs of both industry and utility companies. Typical user groups include municipal power companies, regional and national utilities, industrial plants, power stations and engineering consulting firms. It provides high-performance tools for planning and design of supply networks for a variety of different fields – for gas, just as much as for district heating, electrical power and water.

SINCAL provides the system planner with powerful tools necessary for examining any network states and determining the most suitable network structure. The impact of switching operations can be analysed and networks can be optimised with regard to losses and utilization.

98


99

SINCAL is based on well-known Windows environment for simple handling. It provides object-orientated modelling of all equipment.

All data are managed in a commercial database such as ACCESS or ORACLE. Input data of the networks to be calculated, equipment data and graphics data for true-location or schematic network representation, as well as results of the various calculation methods - i.e. all data necessary for system planning - are stored in this one. This means: data access is possible by standard methods, even when SINCAL is not being used.

All data for network calculation and planning are stored within one data base with standard QSL access. It is not necessary to handle different input files, SINCAL works directly with this database. It does not make temporary exports/imports as many other programs. This is essentially important for the work with the system free of redundancies. When working with PSS/SINCAL all changes are automatically and immediately saved in the data base.

SINCAL can work with more than one data base simultaneously.

SINCAL has a client-server architecture and Internet ability. In addition, the system has to be customized according to demands by modules. Interfaces to GIS (Geo Information System) and SCADA systems are available/customisable as additional components. This could be standard ASCII-file definitions or direct OLE or ODBC links, SQL procedures etc.

Most GIS systems are customized to customer requirements - that is why interfaces have to be adapted to the special data base design of the system. With SINCAL, this is very simply done because the results of all calculations are available in the data base too.

Imports of data are possible too. The data can be exchanged simply, using the most widely varied standardised data formats, such as SQD, PSS/Engine HUB-File, SQL Import, ODBC, PSS/E (RAW), OLE, DVG Exchange format, XML, UCTE, EXCEL, NETOMAC or plotting formats, such as WMF, EMF DWG, BMP, PSP, GIF, PLT, JPG, PRN, PNG, PRT, TIF, SID Import, DXF, SHP Import, EPS, PIC Import, PCL, HPGL - Hardcopy functions, SVG.

SINCAL includes a graphical user interface being the environment in which:

• networks are drawn and defined, • networks are updated with direct access to the values (input, graphic, results) of the data

base in user-friendly masks, • planning scenarios are defined, • calculations are started, • results are displayed. The analysis of the network will be done by filtering or coloured

display, • more than one network can be calculated simultaneously, • reports are generated, • network schematics are plotted and diagrams are printed, • data import or export are done.

SINCAL is well documented. Free definable reports with all means of Crystal Reports are provided. The online help is working with latest HTML based helping functions. Even manuals can be generated out of this information. Many standard reports for each calculation method are available. Further, with SINCAL training of employees in own network is possible which allows to prepare for critical situation.


100


SINCAL is well suited to model all aspects concerning electrical network configuration and operation. The family is also suitable for Pipe Network (Gas, Water, District Heat) modelling and simulation.

Libraries Data bases with various types of equipment (e.g. cables, overhead lines, transformers, protection devices, etc.) are provided and can be augmented by the user. There is a library for built-in models and models for whole parts of the network. Macros can also be complete databases. SINCAL can work with more than one data base simultaneously. Full and flexible data management including tree-list and browser functionality is available for input data results and variants.

The system provides mixed Graphical Representation. For network planning the representation of the network depends on the tasks you have to do. If you want to set protection devices or have a look on the structure of the network, schematic sight is the best. In medium and low voltage networks however a semi scale drawing allows the engineer to take into consideration local specialties and topographical demands. SINCAL can mix semi-scale structures with schematic structures even within one network diagram. User defined units are also available. SINCAL works in a world co-ordinate system. Therefore no maps can be too large sized. Maps of different scale can be integrated into the same map. Only the paper size of the plotter sets limits.

Also every element has to build in the network only one time, the mathematical model of the element differs according to the task of the calculation method. For instance, lines can have PI-equation or wave-equation, loads/asynchronous motors can change their behaviour during calculation. For Harmonics the dependency of the impedance has to be taken into consideration. Not all parts of a network must have graphical description. SINCAL can calculate with the network if the topology is available. This shows each element is an object with different attributes. SINCAL is working with name plate values. Most of the input data are entered in their physical quantities so that you can easily use the known data of equipment and save a lot of calculation or transformation time just before the calculation. The specification of lines differ for low voltage and medium voltage systems (e.g. cable types with technical data that are available in the data base: NKBA..) or high voltage system (where electrical values are normally measured). According to that more input options for cable and over head lines are available.

The number of nodes/substations is unrestricted (e.g. 25.000 nodes networks have been calculated in connection to GIS systems.) because the program automatically allocates the required memory.

Currently, it is not foreseen to model interdependencies, especially with telecommunication industry.


SINCAL integrates a powerful GUI, whose selected features are the following:

• Typical full graphical windows application with browser, menu bars, tool-bars, pop-up windows, etc.

• Intuitive handling • Multi-layer and multi-window concept


101

• User defined design of tab-bars • Separate windows for network diagram, data base editing, messages, diagrams, … • Variety of grid, zoom, sketching and editing functions • One data object for all means: selection of equipments in drop-down menus without

redundancies in graphic and data base. Each object is used for all calculation methods and variants. Different data of the same element can be displayed in accordance to the selected view and calculation method.

• Easy changes of single elements and groups (varying, shifting, deleting, copying) • Digitising facilities for low and medium voltage networks for more planning quality • Scanning and hybrid graphics or files from other systems as background material • Automatic or user defined drawing of single line diagrams • Automatic back documentation of alphanumerical networks or imported networks from

other systems. Single line diagram can be easily generated by placing the nodes • Networks in true location form • Networks using world coordinated and are not limited to paper sizes. • Direct data base access • Linkage between tabular data, dialog entry, diagrams and graphical network

representation: Selected elements in the tabular view will be marked and zoomed in the graphical representation. Even program messages (e.g. warning messages that input data is outside the typical range) are linked to elements.

• Text filters for input and result data allow user-defined display of data in the network diagram.

• Traffic light colours or range shading • The content of all (graphical) reports, drawings, tabular is completely user defined. • Easy documentation with additional input of lines, circles, rectangles, polygons, texts,

etc. • Free positioning of every element and description text • Plots in scale mode or WYSIWYG mode • Diagrams: multiple curves per chart, multiple axis, user defined units • Curve tracking and reading of exact values and coordinates (e.g. location in km) • Parameter files store user defined settings. • Header and legend templates can be linked to any project. • Labelling of plant and equipment can be defined in terms of: scope, units, formats,

positions, numbers.

This graphical user interface makes it possible to enter and display networks in true-location or schematic form. The network and additional graphic information can be drawn and organised in different graphical layers. Different variants can be conveniently handled by variant management tool.

The variant management tool organises variants in a tree-structure. Changes in one variant will automatically update all dependent sub-variants. Each variant can be loaded, displayed and evaluated independently. Network development is easy to handle. Analysis across variants is a very mighty tool which is available by standard data base actions.

The analyses methods SINCAL uses are the following:

• Load Flow (Current Iteration and Newton-Raphson) • Short Circuit (1-, 2- and 3-phase), according to IEC/VDE, with pre-load • Dimensioning of Low-Voltage Networks


102

• Optimal Branching • Optimal Load Flow • Multiple Fault • Stability • Harmonics • Ripple Control • Distance Protection • Overcurrent-Time Protection • Protection Simulation • Motor Start-up • Load Profile Calculation • reliability calculation

These modules allow a wide range of network-related tasks to be performed, such as analysis of critical situations:

• Weak-point determination in the network, fault analysis • Simulation of equipment outage • Minimization of losses • Harmonic response • Optimisation of breaking points • Planning of network expansion • Design of equipment according to standards • Training of employees in own network • Reliability studies • Stability simulations • Protection simulation and coordination (a prerequisite for a stable network operation)

The functions are explained in detail in Appendix 2.

Various steady-state and dynamic calculation methods are available. It is also possible to simulate the effect of time series (e.g. load curves) or time events (e.g. open circuit) on the network. Calculation results can be depicted in different ways (e.g. tables, screen forms, diagrams and reports) and evaluated in the network diagram by means of colouring in accordance with predefined criteria. For instance, “traffic-light colours” can indicate the state of system elements.

The macro function of SINCAL allows the connection and synchronized calculation of separate networks. Furthermore, it enables the use of separately defined type databases in different network areas.

Every input data is carefully checked at once. That could be the topology (e.g. the node name must be unique) or the specific value of the equipment (e.g. the range of input data for Xd” of generator or the vector groups of transformers). Standard values are available too.

With the Batch mode functionality the user can define several tasks, which have to be done often (multiple runs) or for overnight procedures in variant calculations. For batch mode, users need not know a specific command structure, but only record the steps the program should do later on. SINCAL provides an Interactive Mode. It can be used in background calculation for other programs e.g. GIS-Systems, which generate a network, start a calculation and wait for the


results to import them again in the external system. The open data base can be used as the interchanging platform for data. No other interface has to be developed.

SINCAL can work in single user or multi user mode with Oracle data base.

SINCAL can also work as an ASP (Application Service Provider) System. With this option, the user can work with SINCAL via internet and SINCAL is managed on a PC hosted within SIEMENS with high security fire walls. At any time, the user has access to the newest version of SINCAL, needs not provide PC capacity for SINCAL (only a display station) and just pays for the time he works with SINCAL.

The program system possesses computer network capability, i.e. IT resources such as printers and plotters, data security systems, etc. can be utilised. If required, data and results can be made accessible to other users.

Figure 51 and Figure 52 show examples for the visualisation of simulation results.

Figure 51: Graphical evaluation of load centres.

103


Figure 52: Graphical representation of network with graphical evaluation.

6.3.4.4 Conclusion

SINCAL is a mighty network simulation program - as described in Section 6.3.4 - which allows to analyse almost all aspects relevant for network operation. By using the PSSTMSINCAL program, engineers can simulate future scenarios and thus avoid potential mistakes in costly investment project. Several of the modules, especially those connected with protection systems, are also ideal for training purposes. Critical situation can be analysed in detail and in advance.

The PSSTMSINCAL (Power System Simulator/Siemens Network Calculation) program for system analysis and planning has been created to simulate, display and evaluate power transmission systems. SINCAL is well suited for the needs of both the power industry and utility companies. Typical user groups include municipal power companies, regional and national utilities, industrial plants, power stations and engineering consulting firms. It is a high-performance tool for planning and design of supply networks for a variety of different fields - for gas, district heating, electrical power and water.

TMPSS SINCAL provides the system planner with the equipment necessary for examining any network states and determining the most suitable network structure. And in addition he/she will be able to rely on the certainty of his/her switching operations and have the facility for reducing losses, as well as making the optimum use of network elements.

The modelling and simulation features of SINCAL are summarised in Table 18 and in Table 19.

104


Table 18: SINCAL modelling suitability





Possibility of hosting heterogeneous modelling formalisms Use of mathematical models for load modelling

Hosting operating systems Windows

Ability to be distributed on a platform network not specified





Table 19: SINCAL simulation suitability

Simulation of electricity and telecommunication networks Electric and pipe networks

Simulation of SCADA system components OptionallyGeneration of disturbances/corruptions inside the simulatednetworksAvailable analysis tools for state estimations of the network, resultsanalysis, etc. Network visualization tools and network data base systems










105


106

6.3.5 The PowerWorld simulator

6.3.5.1 Description

The PowerWorld simulator allows the simulation of high voltage power system operation on a time frame ranging from several minutes to several days.

This simulator is composed of a base package able to provide a highly effective power flow analysis for an efficient solving of systems of up to 100 000 buses (in PowerWorld, the major part of electric network, such as generators and transformers are associated to buses). This base package also contains all the tools necessary to perform integrated economic dispatch, area transaction economic analysis, power transfer distribution factor (PTDF) computation, short circuit analysis, and contingency analysis.

All these features and tools are accessible through a visual interface.

PowerWorld offers five optional add-ons:

• An Available Transfer Capability calculation, to determine the maximum MW transfer possible between two parts of the power system without violating any limits.

• A Linear Programming OPF, to determine how to mitigate constraints in the most economical fashion, and to report the cost of enforcing line constraints.

• PVQV (Power/Voltage and Var/Voltage) Curve tool, to help fill the industry’s need for a user friendly planning-mode tool for analysing voltage stability and security that is flexible, highly graphical en easy to use.

• Security constrained OPF (SCOPF), to achieve an economical operation of the system while considering not only normal operating limits, but also violations that would occur during contingencies. The SCOPF changes the system pre-contingency operating point so that the total operating cost is minimized, and no security limit is violated if contingencies occur. It extends the Simulator OPF.

• Simulator Automation Server (SimAuto), to launch and control PowerWorld Simulator from within another application, thus enabling you to access the data of a Simulator case, to perform defined Simulator functions and other data manipulations, and then to send results back to your original application, to a Simulator auxiliary file, or to a Microsoft® Excel spreadsheet. The Simulator Automation Server acts as a COM Object, which can be accessed from various Windows-based programming languages that support COM compatibility (e.g., Borland® Delphi, Microsoft® Visual C++, and Microsoft® Visual Basic).

This tool is only available on Windows OS platforms.


The PowerWorld tool integrates existing models. It supports detailed modelling of load tap-changing and phase-shifting transformers, switching shunts, generators cost curves, load schedules, transaction schedules dc lines, multi-section lines and remote bus voltage control.

It also integrates economic data to assess the economic importance of the modelled system in addition to the technical aspects.


The models support mathematical model to represent the load. It handles continuous and discrete variables to regulate the terminal voltage of switched shunts.

This simulator offers users the possibility to use existing and predefined models, to extend them or to create new ones.


PowerWorld offers a powerful GUI that centralizes all simulator functionalities. This GUI allows the definition of new scenarios (called cases) or the creation of scenarios from existing ones. All the components used to model the electric network may be added and customized from this graphical interface.

The GUI also permits the visualisation of the simulation running (Figure 53) through the use of coloured and animated online diagrams with the possibility to zoom and pan on the simulated system. These online diagrams animate the flow power in the system; the magnitude of the flow is represented by the size of this last one. The flow animations are completely customizable.

Figure 53: Example of PowerWorld Simulation

The GUI allows the user to act on the simulation during its execution by for example open or close circuit breakers on objects like branches, loads and generators. In this case, the simulation engine detects the change and recalculates the simulation with the new data.

In addition, the GUI allows the automated creation of diagrams through, dedicated tools, including GIS tool, the automatically insertion of displayed objects and the ability to simultaneously format group of objects.

The simulator allows the generation and the analysis of four types of faults: single lines-to-ground faults, line to line faults, 3 phase balanced faults and double line-to-ground faults. All the faults are specified within a fault data tab by its type and its location. The faults and the resulting data can be saved in or loaded from an external file. Each fault can be displayed (as a scenario) to analyse its results.

PowerWorld provides tools to calculate sensitivities. For example, it can compute and display PTDFs. It can also calculate line flows and interfaces sensitivities, or loss sensitivities

107


To analyse the simulation results various tools are available such as the contingency analysis tool. This one implements a full AC power flow for each contingency for increasing accuracy. This type of analysis is essential for flagging voltage/var problems that would otherwise go undetected using DC load flow techniques. This tools permits the management, creation, analysis and reporting lists of contingencies and associated violations

PowerWorld provides line flows and interface pie charts to indicate flow as a percentage of the line or interface ratings.

The PowerWorld simulation tool also supports GIS.

6.3.5.4 Conclusion

The PowerWorld simulator is a performing tool focusing on power flow modelling and simulation. It offers the possibility to use existing models. It integrates a powerful GUI that centralizes all the simulator functionalities, that is, model and scenario creation, simulation running, simulation results analysis. Its interesting features are that it considers the economic impact on the electrical model.

PowerWorld also offers the possibility to export data for their analysis by other tools.

Table 20 and Table 21 summarise the modelling and simulation features of PowerWorld.

Table 20: PowerWorld modelling suitability





Possibility of hosting heterogeneous modelling formalisms Use of mathematical models for load modelling







108


Table 21: PowerWorld simulation suitability

Simulation of electricity and telecommunication networks power flow











6.3.6 The PSCAD/EMTDC Simulator

6.3.6.1 Description

PSCAD (Power System Computer Aid Design) is powerful GUI for the EMTDC (Electromagnetic Transients including DC) simulation engine, an electromagnetic transient simulator. PSCAD is developed by the Manitoba HVDC Research Centre [PSCAD, PS_UM, EM_UM]. EMTDC is a well-known electric power simulator. One of its main strengths is its ability to accurately simulate power system electromagnetic transients. That is, EMTDC models short-duration time-domain electric power responses. PSCAD is a graphical interface that is used to simplify the development of EMTDC scenarios.

Examples of studies possible with the PSCAD/EMTDC simulator are the following:

• Find over-voltages in a power system due to a fault or breaker operation. Transformer saturations are a critical factor and are represented.

• Find over-voltages in a power system due to a lightning strike. This simulation would be performed with a very small time step (nano-seconds).

• Find the harmonics generated by a SVC, HVDC link, STATCOM, machine drive (virtually any power electronic device) using accurate models of thyristors, GTOs, IGBTs, diodes, etc. along with the detailed control systems, analog or digital.

• Find the maximum energy in a surge arrester for a given disturbance. • Tune and design control systems for maximum performance. Multiple run facilities are

often used here as well to automatically adjust gains and time constants.

109


110

• Investigate the Sub-Synchronous Resonance effect when a machine and a multi-mass turbine system interact with series compensated lines or power electronic equipment. Control systems can also be modified to investigate possible SSR mitigation methods.

• Modelling of STATCOMs or Voltage Source Converters with their detailed control models.

• Study interactions between SVCs, HVDC and other non-linear devices. • Investigate instabilities due to harmonic resonance or control interactions. • Investigate the pulsing effects of diesel engines and wind turbines on the electric

network. • Perform Insulation coordination studies. • Variable speed drives of various types including cycloconverters and transportation and

ship drives. • Industrial systems including compensation controllers, drives, electric furnaces, filters,

etc. • Feeds to isolated loads. • Study the transient effects of distributed generation such as wind and micro-turbines on

the grid. • Capacitor switching transients. • Effect of transmission line imbalances on the system performance during contingencies.


The PSCAD/EMTDC simulator allows the modelling of power systems. It has very detailed electrical models making it well suited to electromagnetic transient investigations. The following are some common models found in systems studied using PSCAD:

• Resistors, inductors, capacitors • Mutually coupled windings, such as transformers • Frequency dependent transmission lines and cables (including the most accurate time

domain line model in the world) • Current and voltage sources • Switches and breakers • Protection and relaying • Diodes, thyristors and GTOs • Analog and digital control functions • AC and DC machines, exciters, governors, stabilisers and inertial models • Meters and measuring functions • Generic DC and AC controls • HVDC, SVC, and other FACTS controllers • Wind source, turbines and governors

If a particular model does not exist, PSCAD/EMTDC offers the possibility to create a new custom model through the Component Editor (Figure 54).


Figure 54: The PSCAD/EMTDC Component Editor

PSCAD/EMTDC simulates power system scenarios in continuous time by solving a series of differential equations in a time-stepped manner.


PSCAD is a powerful GUI for the EMTDC simulator presented on Figure 55.

111


Figure 55: The PSCAD/EMTDC GUI

This graphical interface includes a lot of notable features such as:

• Unit Conversion System • Phasor Meter Devices (Figure 56) • Navigation History Bar • Global Substitutions and Extended Substitution Syntax • Automatic Computations • Component Property Viewer • Enhanced Message Balloons • Better Sequence Component Ordering • Implicit Bus Linking • Common Program Associations • Matrix Memory Optimisation • New Wires and Tri-Segment Transmission Lines • GUI Drag and Drop Extensions, and Tline Navigator • Transmission Line Constants Viewer (Figure 57) • Improvements in the Transmission Line Constant Program • Core Support for the New Intel V9 F90 Fortran Compiler • Sentinel Drivers Updated • Improved License Manager Support for Hibernation and Suspend Modes • License Manager Now Tracks User Usage for Local Administrative Use. • Many models in the master library.

112


• A multimeter • Permanent Magnet machine • Array input and interpolation support in common CSMF components • Terminal initialization for machines and sources • A Potenitla Transformer model • Breaker and Fault models now have current chopping • FFT and THD handle up to 255 harmonics • and so on.

Figure 56: The Phasor Meter tool

Figure 57: The transmission line constants viewer

The GUI also allows the creation, modification and saving of scenarios (cases) in specific files.

PSCAD/EMTDC allows the generation of failures and disruptions by the way of faults and breakers. However no more information is available on how faults can take place within the simulation.

PSCAD/EMTDC proposes three types of output files. The constant file contains all information necessary for the simulator to represent the transmission system in the time domain. The log file can be exported to Excel format. And the classical output file enables the display of important transmission system data. The simulator permits also the importation/exportation of definition files.

Finally, instead of using the graphical interface, users may also write scenarios in Fortran, C and Matlab.

113


6.3.6.4 Conclusion

The PSCAD/EMTDC simulator is a powerful accepted tool for the simulation of electromagnetic transients. This tool includes an efficient GUI to use and create new models, to describe simulation scenarios, to run the simulation and to analyse the results.

Table 22 and Table 23 summarise the modelling and simulation suitability of PSCAD/EMTDC.

Table 22: PSCAD/EMTDC modelling suitability


Continuous as well as discrete variable representation continuous



Possibility of hosting heterogeneous modelling formalisms Use,of mathematical models for load modelling







Table 23: PSCAD/EMTDC simulation suitability

Simulation of electricity and telecommunication networks electromagnetic transient











114


115

6.3.7 The SEPIA simulator

6.3.7.1 Description

SEPIA (Simulator for Electric Industry Agents) is a Windows-based software tool for discrete event simulation for electric power industries [SEPIA, Har00]. It has been designed and developed by the Honeywell Technology Centre and the University of Minnesota in the context of the Complex Adaptive Strategies research of EPRI (Electric Power Research Institute) [EPRI].

It allows exploring the behaviour of complex adaptive systems using an agent based simulation and optimisation approach that is inspired by game theory, machine learning and biological evolution [Har00].

SEPIA is split into three main components:

• A graphical user interface, for simulation scenario creation, running and monitoring. • A generic simulation engine, to control the simulation and enable agent

communications. • Domain specific agents, to represent the system components that are able to

communicate. They are interfaced through an agent bus (included in the simulation engine).

The particularity of this tool is its ability to simulate electrical power infrastructure and the associated markets. It allows conducting simulations regarding the behaviour of power system under a variety of physical and market conditions.


With SEPIA, a power system is modelled as a set of zones, composed of generators and loads, interconnected by tie lines (high voltage interconnections carrying transactions between generators and loads of a single or of different zones). SEPIA allows also to model the generator operating companies and the consumer operating companies. All these components are implemented by agents. Agents can be coded with different high-level language such as C/C++, Basic, Lisp and Java, since the SEPIA interface definitions are respected.

SEPIA has several gaps to model the physical layer:

• It does not manage transmission loading within a zone.

• It is only possible to model generator companies having generators in a single zone (idem for consumer companies and loads).

• It models the transmission system as a linear or dc power flow model. A simplified ac power flow model is also available.

• Generators are modelled as always being on. SEPIA does not allow making failure on generators (on/off status).

SEPIA uses stochastic modelling for:


116

• Power production, which depends on the load and on the fuel consummation of generators (also depending on the load).

• Load, which depends on the purchase of energy by a consumer company from a generator company and therefore on the market. The load variation is modelled according to a continuous random variable respecting a uniform distribution.

The agents used in SEPIA are able to learn and adapt during the simulation running, thanks to learning algorithms (possibility to have several algorithms per agent). These learning algorithms are integrated in each agent. [Har00] gives an example of learning process with a variation of the Q-learning algorithm, which allows a stochastic selection of actions to do according to a set of estimations of action success depending on an input state. The estimations are modified by the agent depending on the real action success.


SEPIA is a discrete event-based simulator. In its simulation engine, the events are represented by message exchanges. The simulation time is incremented by the arrival of a new message.

SEPIA provides a graphical user interface that allows the user to manage the simulation through:

• A scenario editor to define or modify a scenario by specifying appropriate agents and their interactions (Figure 58).

• A simulation control to start, stop, pause and single step the simulation run.

• A property editor to specify and monitor agent and simulation parameters (Figure 59). SEPIA allows the modification of properties before, during or after the simulation run. Specific custom dialog boxes may be available for each agent for its configuration.

• A reporting facility to report periodic status of each agent (Figure 60). These reports can be displayed in live graphs and/or logged in files to be analysed offline. All messages exchanged between the agents can also be monitored, for example for simulation debugging.


Figure 58: Example of scenario design with the scenario editor

Figure 59: Examples of Load (on left) and Generator Company (on right) properties

117


Figure 60: Example of simulation result display (competition between two generator company agents).

6.3.7.4 Conclusion

SEPIA is a tool to simulate electric power infrastructures in a simplified manner and mainly the electricity market with the negotiation of prices between the different generator and consumer companies and how this market influences the load variation. This is the main feature of this simulator and it could be interesting in the IRRIIS project if this aspect is considered.

Table 24 and Table 25 summarise the modelling and simulation suitability of SEPIA

118


Table 24: SEPIA modelling suitability

Enabling stochastic modelling (at a low level)

Continuous as well as discrete variable representation (at a low level)








Possibility to create new models(based on existing agents)


Table 25: SEPIA simulation suitability

Simulation of electricity and telecommunication networks electricity market

Simulation of SCADA system componentsGeneration of disturbances/corruptions inside the simulatednetworksAvailable analysis tools for state estimations of the network, resultsanalysis, etc.

(e.g., for price negociation)

Network visualization tools and network data base systems

Possibility to design, archive and modify scenarios design







Type of Licence research project


6.3.8 Summary

In this section we present different simulation tools dedicated to electrical infrastructures.

119


This section focused on the electrical sector simulators with interesting features and functionalities that may be integrated within SYNTEX.

The studied simulators a wide variety of features and performing GUI for model and scenario definition as well as for simulation display and results analysis. However, they focus on different parts of the electric sector. PowerWorld simulates power flows and considers economic aspects. PSCAD focuses on the simulation of electromagnetic transient. NETOMAC simulates electromagnetic and electromechanical phenomena in electrical systems. SINCAL is a static simulation program for power transmission and distribution systems simulation. Moreover, it optionally integrates the NETOMAC functionalities, increasing its capabilities. Finally, SEPIA proposes a high level simulation of energy supply including market dynamics.

The most complete simulation tools are the PSS family tools: NETOMAC and SINCAL. It provides a mighty tool to model nearly every aspect of electric power supply.

Table 26 and Table 27 compare the features of the main simulation tools for modelling and for simulation.

Table 26: Comparison of the electric tools modelling suitability

Modelling suitability NETOMAC SINCAL PowerWorld PSCAD / EMTDC

Enabling stochastic modellingContinuous as well as discrete variable representation continuous

Easiness of integration with other toolsHierarchical modelling support


Use of mathematical models for load

modelling


modelling


modelling


modellingHosting operating systems Windows Windows Windows WindowsAbility to be distributed on a platform network not specified not specified not specified not specified

Generic models support (SYNTEX as an integrated simulator)Possibility to extend/modify existing and predefined modelsPossibility to create new models

120


Table 27: Comparison of the electric tools simulation suitability

Simulation suitability NETOMAC SINCAL PowerWorld PSCAD / EMTDCSimulation of electricity and telecommunication networks

Dynamics and transients behaviours

Electric and pipe networks power flow electromagnetic

transient Simulation of SCADA system components Optionally

Generation of disturbances/corruptions inside the simulated networksAvailable analysis tools for state estimations of the network, results analysis, etc. Network visualization tools and network data base systemsPossibility to design, archive and modify scenarios not specified not specified


GUI for model creation/management

Ability to create archives containing logs of the networks status and the operative actionsConsideration of external information as inputCreation of trace files of the simulation resultsInteractions with the real network/systemAbility to exchange information with other simulatorsFast simulation capabilities

Type of Licence commercial commercial commercial commercial

6.4 Conclusion

This section presented suitable simulation tools that are oriented either to telecommunication infrastructures or to electricity infrastructures.

The telecommunication simulators are either dedicated simulators, specific to telecommunication sector (e.g., OPNet, NS, QualNet) or generic simulators (e.g., OMNeT, J-Sim, SSF), potentially modelling of all types of infrastructures since elements are boxes receiving inputs and generating outputs.

The electric simulators do not propose generic modelling. They are dedicated to electric sector but some, PowerWorld and SEPIA, consider that economical aspects can influence of the system behaviour.

Despite SINCAL that optionally proposes the simulation of SCADA equipments, none of the studied simulation tools focus on the simulation of different sectors infrastructures and of their (inter)dependencies. This aspect is studied in the following section.

121

Available tools to simulate (interconnected) CIs of different sectors

122

7. Available tools to simulate (interconnected) CIs of different sectors

7.1 Introduction

In the previous section (Section 6), we show it is possible to simulate different sectors CIs with generic simulators since they describe CIs with ‘black boxes’ representing the CI components, and input/output flows, representing the flows exchanged by components (CI specific flow or dependency flow). To model a specific CI, the generic model must be extended to represent the desired infrastructure.

In this section, we focus on tools able to simulate (without model extensions) heterogeneous CIs and their (inter)dependencies. But only few tools are identified. Theses tools are based either on the concept of Agent-Based Modelling (ABM), or on mathematical models. These tools are respectively detailed in Section 7.2 and in Section 7.3

7.2 Tools based on Agent-based Modelling

7.2.1 Introduction

Critical infrastructures are often compared to Complex Adaptive Systems (CAS) [Rin01, Tol04, Dun06, CAS], that is, “they are all complex collections of interacting components in which change often occurs as a result of learning processes” [Rin01]. M. Dunn and V. Mauer define CAS as “real-world systems that are characterised by apparently complex behaviour, which emerges as a result of often nonlinear spatial-temporal interactions among a large number of component systems at different levels of organisation” [Dun06].

CAS are generally implemented with agents, an agent being an entity that can be defined by its location, its capabilities, and its memory. This makes the implementation of systems organised as collections of agents interacting with each other possible. In addition, they have the capability to evolve over time and to take past experiences into account.

Many agent-based modelling (ABM) environments, such as Cougaar, SWARM, REpast, JADE, are available [Cougaar, Swarm, REpast, Nor06, JADE, ABM_L]. They are generally dedicated to the modelling and simulation of large-scale systems composed of thousands to millions agents. They provide graphical support to design the model, display the simulation run and analyse the results. They also propose specific features such as time scheduler to provide discrete event simulation (agent behaviour is usually driven by the goals it has to achieve), communication mechanisms, agent state storing and displaying facilities and the ability to distribute simulation over several workstations.

Two modelling approaches may be associated to ABM: ontologies and rules.

The concept of ontology may also be considered to model critical infrastructures. It is a concept issued from philosophy. It provides an explicit description of a domain. The domain is described in terms of concepts, properties and attributes (of the concept), constraints on properties and attributes, and possibly individuals.


123

An ontology defines a common vocabulary and a shared understanding of the domain. It represents knowledge on the domain. It permits to declare structures of knowledge databases and provides a domain description through sets of classes that can be used by ABM tools; for the development of domain-independent applications, or even for the development of problem solving applications (explicit and structured representation of problem-solving knowledge with inputs and outputs domain independent ontologies).

Rule-based approaches may also be considered to model CI. This approach is already used in the artificial intelligence domain, more precisely for expert system knowledge representation.

This approach enables the separate description of a domain and of the behaviour of the domain. This facilitates behaviour changes. The domain behaviour is described through rules that are centralised in a knowledge database. These rules respect a declarative programming and express "What to do" not "How to do it" in the form “WHEN…THEN…”. They use the objects composing the domain model. This makes the rules reading and understanding easier for a domain expert. A rule engine is able to solve the rules rapidly and in a scalable manner.

These tools are interesting for the purpose of IRRIIS since they allow modelling a domain (a critical infrastructure or a set of dependent CIs). Ontologies and rule based approaches may also be coupled for modelling the system and its behaviour.

Various tools are available for ontology and rule descriptions. However, we will not describe them in detail because they are out of the scope of this deliverable which is focused on simulation tools for telecom and electric power CIs. However, more detail on ontology editors (Protégé, Ontolingua and Chimaera, OntoEdit and OilEd) is in [Protégé, OntoL, Chimaera, OntoE, OilEd], and on rule-based approaches (Drools rule editor and engine and JBoss rules) in [Drools, JBoss].

In this section we present three research works dealing with the concept of agents to model and simulate different sectors CIs and their dependencies.

7.2.2 The North Carolina University simulation tool

7.2.2.1 Description

The simulation tool developed at the North Carolina University aims to model and to simulate infrastructures and cross-infrastructures [Tol04, Tol04b]. It is based on the Cougaar agent architecture that allows the construction of large-scale agent-based applications, and of a Geographic Information Systems (GIS) to analyse and visualise the simulation [Cougaar]. This architecture is depicted on Figure 61.

Each infrastructure involved in the simulation is modelled by a behavioural model. Several behavioural models can be plugged together in the simulation architecture. Cross-infrastructure simulation is possible through the use of intelligent agents. Intelligent agents are software agents that are able to react to changes in their environment, to take actions to act on their environment and to interact with other agents, in order to achieve their objective. These agents may change state according to two factors:

• In function of a meta-knowledge database including dependencies data. Actions taken by the agents can provoke changes of state within and across infrastructures.


• In function of GIS supported network analysis. Actions taken by the agents can provoke changes of state within an infrastructure.

Figure 61: The Agent-based simulation environment architecture

This architecture is composed of four main components:

• The behavioural models that are specific to each modelled CI and represent its behaviour.

• The agent architecture that allows the simulation of dependencies between the different infrastructures.

• The GIS application that represents the models in a geographical way. It also includes analysis methods used by agents to infer their reaction to a state change in an infrastructure.

• The End-User simulation environment that allows the user to visualise the simulation behaviour through the GIS application. It also provides a way to act on the simulation by enabling or disabling CI features and then viewing the impact of the actions.


Little information is available on the modelling suitability of the proposed agent based architecture.

124

To model the critical infrastructures, behavioural models are used. They may be plugged in and out as needed. A model represents the behaviour of a CI and different models may be used for a same infrastructure. In addition several models of a same infrastructure type may be plugged together (e.g., for adjacent telecom stakeholder models). New models may also be added to the simulation environment. However, these assertions cannot be verified since no more information is available and no reference on these models is provided.


The agents aim to simulate the dependencies between the infrastructures. To do this, they base their reactions on meta-knowledge. This meta-knowledge represents the dependencies as a set of rules to respect.


The simulation is launched by the user through the user interface that utilizes the GIS for the visualisation. To initiate the simulation, the user may select and disable certain CI features and then view the action results.

The simulation is executed by different agents. When detecting a change in a simulated CI state, these agents use meta-knowledge and GIS analysis methods and communicate with each other to determine the appropriate actions to do on the different infrastructures, modelling the cascading effects within the CI or between the linked CIs.

Figure 62: Example of dependency simulation

Figure 62 shows an example of simulation depicting the impact of a power failure in the electrical CI and on a gas distribution CI. The user begins by selecting and disabling a small segment of an electrical infrastructure (in red on Figure 62 (a)). As soon as it is detected by the agents, the impact of this failure is computed. As a result, it has an influence on the downstream

125


part of the electrical infrastructure and also on the gas distribution one due to the closeness of an electric powered gas pump. From the GIS network analysis support, they deduce and render the downstream impacts of this failure on the electrical CI (in red on Figure 62 (b)). From the meta-knowledge, agents deduce that, without power, the gas pump is out of order. Then it uses the GIS network analysis support to deduce and render the downstream impacts of this gas pump failure (in red on Figure 62 (c)). Agents infer then that the power downstream disruptions impact the gas distribution even more due to cascading effects, and so disable the related part of the gas distribution CI (in red on Figure 62 (d)).

7.2.2.4 Conclusion

This work aims to help to identify the CIs’ behaviour and also their vulnerabilities. Figure 62 shows how a failure in the electrical CI causes some disruptions in the CI and also disruptions in a larger part of the gas distribution CI.

Agents are used here to identify which changes must be done in the different CI as a result of a failure in one of these. They base their reasoning on meta-knowledge to deduce that a failure can affect other parts of the system (in the CI or in other CIs). They use the GIS network analysis support to identify the impact in the CI, and specific meta-knowledge (representing the dependencies between CIs), to identify the cross-infrastructures’ disruptions.

Table 28 and Table 29 summarise the modelling and simulation suitability of this simulation tool according to the available information.

Table 28: North Carolina University ABM tool modelling suitability

Enabling stochastic modelling not specified

Continuous as well as discrete variable representation not specified

Easiness of integration with other tools not specified

Hierarchical modelling support not specified

Possibility of hosting heterogeneous modelling formalisms not specified

Hosting operating systems Windows, Unix



Possibility to extend/modify existing and predefined models not specified

Possibility to create new models possible incorporation of new infrastructure models


126


Table 29: North Carolina University ABM tool simulation suitability

Simulation of electricity and telecommunication networks

Simulation of SCADA system components depends on the model usedGeneration of disturbances/corruptions inside the simulatednetworks disabling parts of Cis

Available analysis tools for state estimations of the network, resultsanalysis, etc. not specified

Network visualization tools and network data base systems


GUI for scenario creation/management not specified

GUI for model creation/management not specifiedAbility to create archives containing logs of the networks status andthe operative actions not specified

Consideration of external information as input not specified

Create of trace files of the simulation results not specified

Interactions with the real network/system not specified

Ability to exchange information with other simulators simulation of cascading effects intra and inter Cis

Fast simulation capabilities not specifiedType of Licence Research Project


7.2.3 The Electric Power and Communication syncHronizing Simulator (EPOCHS)

7.2.3.1 Description

EPOCHS (Electric Power and Communication syncHronizing Simulator) is a distributed simulation environment for electric power infrastructures and its communication elements [Hop 03]. In other words it simulates electric power and telecommunication infrastructures as well as the dependencies of the power network on telecommunications.

It assumes that existing power simulators do not support the communication capabilities present in the real power systems. To solve this problem, EPOCHS proposes to allow communications between existing simulators of electricity and telecommunication sectors, by federating them similarly as HLA. The difference with HLA lies in the fact that EPOCHS does not necessarily modify the simulator code to interface with it.

To do this, it uses the concept of agent to create an architecture that allows the communication between two simulators, an electricity power simulator (either PSCAD/EMTDC or PSLF) and a telecommunication simulator (NS2). The general architecture of EPOCHS is described by Figure 63.

127


NS-2 PSLF

Custom module

PSCAD

RTI

AgentHQAgentAgentAgent

AgentHQAgentAgentAgent

Custom moduleCustom module

Figure 63: EPOCHS general architecture

EPOCHS is composed of:

• The AgentHQ, a discrete event system allowing agents to exchange information with each other and to get and send values from and to the simulators.

• The simulators, either NS-2 and PSLF or NS-2 and PSCAD/EMTDC, which have been extended with a ‘custom module’ to be able to interact with the other EPOCHS’ components.

• The RTI (Real Time Infrastructure). It allows the synchronization of the simulation (the simulators can interact at specific synchronization times whose interval is fixed by the user) and the routing of communication between the EPOCHS’ components.


EPOCHS interfaces existing simulators and uses the specific modelling ability of each one to create scenarios. NS-2 has been chosen for its suitability to model TCP network used with SCADA systems, PSLF for its ability to model electromechanical transient simulation and PSCAD/EMTDC for its ability to model electromagnetic transient simulation.

EPOCHS agents are used to model and test agents those would be loaded in IEDs (Intelligent Electronic Devices), hardware environment with computational, communication and I/O capabilities.

Therefore, EPOCHS agents have an API making them able to interact with the simulated power system in order to ask for its power system state and to receive the associated values or to send and receive communication messages.


Since EPOCHS interfaces existing simulators, its simulation suitability is linked to the simulators ones.

128

However, EPOCHS offers the ability to create communications between simulators of different sectors, by the way of an agent-based architecture. To make this communication


129

possible, different means are used according to the simulator specificities, and if its source code is available or not:

• NS-2 simulator is extended with an intermediate code. A new transport protocol has been design to serve as link with EPOCHS.

• For PSCAD/EMTDC, an external programming interface is used. A new library is created to define a new custom component interacting with PSCAD/EMTDC, with the simulated components as well as with EPOCHS.

• PSLF. A gateway program is used. Using the PSLF own language, a stub has been created to interact with EPOCHS through the use of files.

As we seen in Section 7.2.3.1, the simulators can communicate at specific synchronization points fixed by the RTI. At each synchronization points, the AgentHQ is triggered and acts as a proxy between the simulators (electric power and telecommunication) and the agents. It gives the agents the opportunity to calculate their set of operations for the next period. Therefore, the agents have the possibility to ask the power system its state and to receive the corresponding information. The agents can then react, depending on the current system state, by sending messages or by asking complementary or updated information. The messages are exchanged using the NS-2 network simulator. Moreover, agents can receive messages at any time and react to these by doing additional actions.

In the experiments presented in [Hop], disruptions are made on electrical infrastructures to prove the usefulness of agent-based systems in different cases. These experiments are presented in Appendixes (Appendix 4).

7.2.3.4 Conclusion

The interest of this simulation tool is that it allows the simulation of electrical infrastructures including their communication system. It does not allow the simulation of an entire telecom infrastructure, but it provides a solution to allow communications between heterogeneous simulators whose source code is not necessarily available. It will be interesting to consider this feature for SYNTEX design, especially if the second view of SYNTEX is chosen. The modelling and simulation features of EPOCHS are summarised in Table 30 and Table 31.


Table 30: EPOCHS modelling suitability

Enabling stochastic modelling depends on the simulators

Continuous as well as discrete variable representation depends on the simulators

Easiness of integration with other tools depends on the simulators

Hierarchical modelling support depends on the simulators

Possibility of hosting heterogeneous modelling formalisms depends on the simulators

Hosting operating systems depends on the simulators


Generic models support (SYNTEX as an integrated simulator) depends on the simulators

Possibility to extend/modify existing and predefined models depends on the simulators

Possibility to create new models depends on the simulators


Table 31: EPOCHS simulation suitability

Simulation of electricity and telecommunication networks electricity including telecommunication features

Simulation of SCADA system componentsGeneration of disturbances/corruptions inside the simulatednetworks possible through the used simulators

Available analysis tools for state estimations of the network, resultsanalysis, etc. depends on the simulators

Network visualization tools and network data base systems depends on the simulators

Possibility to design, archive and modify scenarios depends on the simulators

GUI for scenario creation/management depends on the simulators

GUI for model creation/management depends on the simulatorsAbility to create archives containing logs of the networks status andthe operative actions depends on the simulators

Consideration of external information as input depends on the simulators

Create of trace files of the simulation results depends on the simulators






7.2.4 The Critical Infrastructure Simulation by Interdependent Agents (CISIA)

7.2.4.1 Description

130

CISIA is a simulation tool defined by the Roma Tre University [Pan05, Pan04]. It is currently still under development. It has been designed for analysing the short time effects of a failure in terms of fault propagation and in terms of performance degradation [Pan04].


131

This simulator uses REpast (REcursive Porous Agent Simulation Toolkit) [REpast, Nor06], a java-based ABM tool. CISIA extends these java classes to define the components of the simulated infrastructures and create the CI models. CISIA uses also the simulation run, display and collecting data capabilities of REpast.


Each component of the infrastructure is abstractly modelled by the way of three quantities that represent its state:

• The Operating Level (OL), represents, in percentage, the ability of the system to perform its required job.

• The Requirements (R), represents the system requirements to reach an OL of 100 %.

• The Fault (F), represents a fault occurring within an agent (true/false state), and the type of this fault. A fault implies an OL of 0 %.

In addition, neighbour agents that are connected exchange inputs and outputs together.

The inputs are:

• The induced faults (IN.F), the faults propagated from agent to agent.

• The input requirements (IN.R), the amount of resources required by the neighbour agents.

• The input operative level (IN.OL), the operative level of the neighbour agents from which resources are received.

The outputs are the counterparts of the inputs:

• The propagated faults (OUT.F), the fault propagated to the neighbour agents.

• The output requirements (OUT.R), the amount of resources required from neighbour agents.

• The output operative level (OUT.OL), the operative level of the agent itself.

The internal model of an agent is depicted on Figure 64. It describes the behaviour of the agent by the way of two interconnected dynamics. The Element dynamics describes the service the agent provides. This service is represented by the output operative level and the output requirement, which are calculated from the input requirements, the input operative level and the current operative level of the agent. The operating level of the agent depends on its failure level, that is to say the failure dynamics. The failure dynamics is a mix of the input fault, of the output fault and of the agent state.


Element dynamic

Failure dynamicIN.F

IN.OL OUT.OL

OUT.F

IN.R

OUT.R

Element dynamic

Failure dynamicIN.F

IN.OL OUT.OL

OUT.F

IN.R

OUT.R

Failure dynamics

Element dynamicsElement dynamic

Failure dynamicIN.F

IN.OL OUT.OL

OUT.F

IN.R

OUT.R

Element dynamic

Failure dynamicIN.F

IN.OL OUT.OL

OUT.F

IN.R

OUT.R

Failure dynamics

Element dynamics

Figure 64: CISIA agent internal model.

An agent’s connections are modelled through dependencies. These dependencies can be relative to the operating level, the requirements or the faults and are represented through binary incidence matrix. The faults can be of three types: physical (via physic linkages), geographical (in close spatial proximity) and/or cyber (cyber connected). The faults that can be received from other agents are specified in the input interface of the agent. The faults that can be transmitted to other agents are listed in its output interface (Figure 65). Another interface defines the internal parameters of the agent.

Input InterfaceInput Interface

10[A]IN.R

‘short circuit’‘fire’‘mechanical break’‘flooding’‘virus’

BooleanIN.F

10[A]IN.OL

Nominal Value / TypeUnit

10[A]IN.R

‘short circuit’‘fire’‘mechanical break’‘flooding’‘virus’

BooleanIN.F

10[A]IN.OL


Output InterfaceOutput Interface

‘virus’booleanOUT.FC

‘fire’‘mechanical break’

booleanOUT.FG

‘short circuit’‘fire’

booleanOUT.FP

10[A]OUT.OL


‘virus’booleanOUT.FC

‘fire’‘mechanical break’

booleanOUT.FG

‘short circuit’‘fire’

booleanOUT.FP

10[A]OUT.OL


Figure 65: CISIA agent input and output interfaces

In addition, the faults are propagated only to the concerned agents as described by Figure 66. For instance, a physical fault is only propagated to the physical neighbourhood (specified in the physical fault incidence matrix).

Finally, the operating level and the requirement values are modelled by fuzzy numbers, in other words imprecise numbers that vary between a minimum and a maximum computed by a given function. It allows calculation of the "degrees of truth" of a system.

132


‘mechanical break’‘fire’

‘short circuit’‘virus’

‘fire’‘short circuit’


‘virus’

to Physical neighborhood

to Geographical neighborhood

to Cyber neighborhood

Agent’s faultF.Type

Agent’s output interface

OUT.FP

OUT.FG

OUT.FC

FPm

FGm

FCm


‘short circuit’‘virus’

‘fire’‘short circuit’


‘virus’

to Physical neighborhood

to Geographical neighborhood

to Cyber neighborhood

Agent’s faultF.Type

Agent’s output interface

OUT.FP

OUT.FG

OUT.FC

FPm

FGm

FCm

Figure 66: Fault propagation in CISIA


CISIA allows the simulation of all kind of infrastructure but only at a coarse level. CISIA uses the REpast ABM tool to model the infrastructures that will be simulated. It extends the java classes representing the agents to model the infrastructure components and their dependencies.

This tool provides a user interface to model the system, display and analyse results [REpast, Nor06]. It provides a range of two-dimensional agent environments and visualisations. It offers built-in simulation results logging and graphing tools.

It also allows a runtime access and modification of agent properties, agent behavioural equations, and model properties.

REpast includes a fully concurrent discrete event scheduler. This scheduler supports both sequential and parallel discrete event operations. REpast includes also libraries for random number generation, specialised mathematics, etc. It integrates geographical information systems (GIS) support.

REpast is fully implemented in a variety of languages including Java and C# and the models used can be developed in various languages (e.g., Java, C#, Managed C++, Visual Basic.Net, Managed Lisp, Managed Prolog, Python scripting). It is available on Windows, Mac OS, and Linux. In addition, it supports simulation over large-scale computing clusters. It also includes additional features, as depicted in [Nor06] and [REpast]. 7.2.4.4 Conclusion

CISIA is a tool enabling the simulation of heterogeneous critical infrastructures at a coarse level. It is used to analyse fault propagation across these CIs.

The main particularity of CISIA is that it models the three types of faults met in CIs: physical (via physic linkages), geographical (in close spatial proximity) and/or cyber (cyber connected) faults.

The modelling and simulation features of CISIA are summarised in Table 32 and Table 33.

133


Table 32: CISIA modelling suitability





Possibility of hosting heterogeneous modelling formalisms fuzzy logic only

Hosting operating systems not specified

Ability to be distributed on a platform networkthanks to REpast





134


Table 33: CISIA simulation suitability

Simulation of electricity and telecommunication networks

Simulation of SCADA system componentsGeneration of disturbances/corruptions inside the simulatednetworksAvailable analysis tools for state estimations of the network, resultsanalysis, etc. thanks to REpast

Network visualization tools and network data base systemsthanks to REpast



GUI for model creation/managementthanks to REpast

Ability to create archives containing logs of the networks status andthe operative actions thanks to REpastConsideration of external information as input

Create of trace files of the simulation resultsthanks to REpast



Fast simulation capabilities depends on REpast



7.2.5 Conclusion

In this section, we present how ABM tools are used to model and simulate heterogeneous critical infrastructures, their behaviour and mainly their dependencies.

The simulation tool proposed by the North Carolina University uses agent to simulate the dependencies between infrastructures. EPOCHS allows also the simulation of dependencies but it realises an interface between existing simulators. Finally CISIA focuses on the fault propagation and allows the modelling of physical, geographical and cyber faults.

These tools are recent research work, often in progress and only little information is available through the published documents. However, they highlight the ability to model heterogeneous CIs and their dependencies by the way of agents and agent-based modelling tools. These tools provide generally a simulation environment including interfaces for modelling, simulation running, and visual interface for simulation execution and for simulation results analysis, like traditional simulation tools. More information about these ABM tools is available in [Nor06, Swarm]

135


7.3 Tools based on mathematical models

7.3.1 Introduction

Modelling and simulation of critical infrastructures is also possible using mathematical models. Mathematical models are already used to model single infrastructures and some recent works, presented in this section focus on the modelling of the interdependencies between different sectors’ CIs.

7.3.2 The ENEA Mathematical model

7.3.2.1 Description

The objective of this work, developed by ENEA, is the modelling of interdependencies by the way of phenomenological behavioural equations in order to predict the dynamics of these dependencies [Iss06].

The described model is based on the Leontief input-output model of the economy for equilibrium in markets [Leo86].


A CI topology is represented as an adjacency matrix in which each entry represents the existence of a link between the two nodes (line and column). This representation does not allow the specification of different infrastructure components with specific behaviours.

CIs are also described in terms of inoperability, that is, with a variable (xi) taking values between 0 and 1 (0 signifying the ith CI is perfectly operable; 1 signifying the ith CI is completely inoperable). This inoperability variable (xi) depends on the inoperability variable of others CIs (x

136

j), and of a perturbation term (u ) that can affect the ithi infrastructure. The impact of the

inoperability variables of the other CIs is deduced from the dependencies existing between the CIs. The dependencies between two CIs are modelled through an interdependency matrix. Each non-zero entry represents the propagated effect of inoperability. The respected (simplified) formula is the following:

, BukRxkx +=+ )()1(

where k is the time, R, the interdependence matrix and B, the incidence matrix, i.e. the possible perturbations within the infrastructure.

This formula represents a static modelling of the system. To introduce dynamics in the interdependent CIs, a buffer is added before (upstream buffer) or after (down stream buffer) each CI. This allows decoupling of the behaviour of two dependent infrastructures. Buffers can absorb the received perturbation or pass part or all the perturbation to the (next, in case of downstream buffer) CI.

Finally, this model allows discrete event simulation. In this case, the equation modelling the system is recalculated at each discrete time k.



This work focuses on the modelling of complex infrastructures so it does not provide GUI, neither for model creation, simulation running nor for results analysis. However, simulation results (equation results at each discrete time) can be stored in a log file that can then be viewed on a chart. The trace file contains the state of the system at each simulation time.

In this model, disturbances and corruptions are modelled by the incidence matrix and by the perturbation variable. This allows to impact (at time k) the inoperability variable representing the CI state and also the inoperability variables (at time k+1) of the dependent CI thanks to the interdependency matrix.

Finally, the simulation is performed from an initial state that defines initial value for each variable and each matrix. Therefore, external information (inputs) can serve as inputs to the formula.

7.3.2.4 Conclusion

The model presented here is a work in progress that aims the study of CI interdependences. It is based on the Leontief input-output economical model dedicated to the market dynamics representation. Each CI is represented in a simple way with an adjacency matrix to indicate the presence of a link between two nodes. Equations, based on the Leontief model, are proposed to first model statically the dependencies between CIs, the possible faults within a CI and the propagation of the faults; then to provide a dynamic model by the introduction of buffers before or after each CI to eventually absorb the disturbances to reduce the fault propagation.

Table 34 and Table 35 summarise the modelling and simulation features of the ENEA proposed model.

Table 34: Modelling suitability of the ENEA model


Continuous as well as discrete variable representation continuous (but differiential equations recalculated each discrete time)




Hosting operating systems depends on the development environment


Generic models support (SYNTEX as an integrated simulator) since modelling with adjacency matrixes




137


Table 35: Simulation suitability of the ENEA model

Simulation of electricity and telecommunication networks since modelling with adjacency matrixes




GUI for model creation/managementAbility to create archives containing logs of the networks status andthe operative actionsConsideration of external information as input possible




Fast simulation capabilities not indicated

Type of Licence research work in progess


7.3.3 The mathematical model of the Dresden Technological University, the Zilina University and the Collegium Budapest

7.3.3.1 Description

The model proposed by the Dresden Technological University, the Zilina University and the Collegium Budapest aims to model the cascading failures and disaster spreading in complex systems on a general level.


In this work, the general model targets a network of systems components. The network is modelled by a directed connected graph with nodes (system components) and directed links (dependencies).

A node state is represented by a variable, which is equal to 0 for a normal operation of the component. The level of perturbation, acting on the state of a node, is calculated using all external and internal disturbances, whose sum exceeds a certain threshold. The obtained formula closely resembles a sigmoid function.

Moreover, spontaneous failures are considered in this model. They are modelled as a noise, which is a random input of the node.

138


139

The model allows the simulation of failure propagation from a node to the linked ones according to a weight and a delay associated to each link.

This model also includes a recovery process, the ability of a node to recover from failures, after a constant time. The recovery state depends on the node state and the time.


This model allows the simulation of different kinds of infrastructures because components of the system are modelled by generic nodes and connected by directed weighted links. However, it does not model the type of information exchanged. The links represent only the dependencies between components and how failures are propagated.

Corruptions and disturbances can be simulated. If the variable representing the node state is different from 0, a disruption is modelled and then propagated along time. Random failures can also be modelled using the noise variable.

As for the previous work no annex tool is available to simplify the topology creation. However, the TouchGraph tool may be used [TG] to provide a snapshot of a disaster spreading simulation [Kar06]. This tool is dedicated to the visualisation of research results on the web. The simulation results may also be stored in an output file to be then interpreted by any graph visualisation tool.

Finally the simulation speed capabilities are not mentioned in the documents.

7.3.3.4 Conclusion

This model allows the simulation of the spreading of breakdowns and failures caused by outside extreme events. Simulations based on various network topologies were done using this model and seems to provide interesting results for the study and the prediction of cascading effects (only at physical layer however).

However, this work is in progress and needs to be compared with real world scenarios. Moreover, it must be improved in terms of possible failure propagation (not be limited to physical propagation) as well as in terms of model precision.

Table 36 and Table 37 summarise the modelling and simulation features of the proposed model.


Table 36: Modelling suitability of the mathematical model


Continuous as well as discrete variable representation continuous

Easiness of integration with other tools network visualization with TouchGraph



Hosting operating systems depends on the development environment


Generic models support (SYNTEX as an integrated simulator) since modelling with directed graphs




Table 37: Simulation suitability of the mathematical model

Simulation of electricity and telecommunication networks since modelling with directed graphs




GUI for model creation/managementAbility to create archives containing logs of the networks status andthe operative actionsConsideration of external information as input possible




Fast simulation capabilities not indicated

Type of Licence research work in progress


7.3.4 Formal verification

7.3.4.1 Description

Formal verification is a generic term that regroups two methods to validate systems using mathematical techniques: model checking and theorem proving. The purpose of both techniques

140


141

is usually to ensure that a system complies to some properties (no deadlock, no livelock, no starvation for instance), whatever the state it can be in. These approaches are very attractive as they are able to prove that a system, provided that it complies with the specification that was analysed, will comply with some properties, whatever the state it enters, even after a failure. If the system does not comply with these properties, the software is usually able to identify and describe the failure scenario.

Model checking approaches require the user to describe a system or a protocol in a dedicated language, to specify some properties that the system is supposed to verify in the same or in another language. The verification engine then generates every possible state that the system may experience and verifies the properties on each of these states. Research in this area has been very active to provide the user a descriptive and easy language to describe systems. For instance, languages based on process algebras are usually considered to have a good description power but are often uneasy to manipulate. Another very active research topic concerns the representation of data. In other words, how to be able to generate the whole states space of a system in an efficient way, without requiring too much memory? Typical examples of model checkers are Lotos, Lotos NT, Promela, Esterel, PEPA and, to some extent, Petri networks.

Theorem proving relies on inference engines that, from a formal specification, are able to derive some properties on the system. Usually, theorem-proving software are able to decompose such a property in sub-properties and then use simpler rules to reach the expected result. These tools are usually very powerful but require good description ability from the users. A drawback of these methods appears when the software is unable to verify a property on a system. It usually is not able to distinguish between an unprovable property and a failure due to a lack of precision in the system description. However, one great advantage of these tools is that they do not suffer from the system states explosion problem appearing with model checkers. A typical example of theorem proving software is Coq.


There are various model checking description languages. Most are based on or derived from process algebras (Lotos, PEPA for instance). It is indeed a formalism used to model concurrent systems. Some other formalisms, like Petri nets, present some slight differences (synchronization done by channels or by tokens for instance). However, the main tasks of system modelling is usually rather similar from a language to another.

A system is usually decomposed in small entities. Each small sub-system’s behaviour is then usually modelled using a more-or-less easy-to-manipulate language. The formalism then provides ways to put small systems together by the means of synchronization operations.

For instance, it would be possible to describe the behaviour of a telecommunication router, as a state machine, the behaviour of an electric generator as another state machine, and to plug them together via some synchronization operation.

The languages used have great description power but are generally not very easy to manipulate. They are indeed quite far from the usual imperative languages that people are familiar with (C, java, …) and therefore require a learning step.


The difficult part in formal verification usually resides in the system description part. The specification should be precise enough to precisely reflect the system behaviour and coarse enough to decrease verification complexity.


142

Verification software is usually high-quality software, able to deal with rather complex systems. Many techniques are used to ease the verification process (bisimulation in the case of process algebras for instance). However, CIs are very large systems, involving a lot of equipments and parameters and even the best software may not yet be able to fully check such infrastructures.

7.3.4.4 Conclusion

These tools are very attractive regarding the objective of SYNTEX, as they explore the whole system’s states space. In an ideal scenario, all faults could be identified, classified and solutions could be derived. However, these approaches usually suffer either from the complexity of modelling (the user should be experiences to find the right level of granularity required) or from the system states explosion.

Moreover, it seems rather difficult to have a converter able to take the models from a given simulator and to translate them into a formal description of CIs components. This means that designing a system that allows end users to keep their simulation tools while using a formal verification-based core system is probably impossible. Moreover, the complexity of the CIs systems is also, today, still a limitation, at least for the model checking-based approaches. Therefore, if a deep study of this field could be interesting to evaluate its suitability to CIs interdependencies modelling, it may be out of the scope of the IRRIIS project.

The large set of tools available does not allow representing this formalism capabilities in terms of an array as in previous sections.

7.3.5 Summary

The simulation tools studied in this section proposed different way to model and simulate the network. The first one is based on the Leontief input output model, the second on a sigmoid function and the third on formal methods. They all provide interesting results but are not compared with real world ones. The studied works, being sill in progress, do not consider complex network topologies.

Moreover, most of them do neither integrate GUI nor annex tools for simulation display, results analysis. However, existing tools can be used in this way, as described in [Cha04].

Finally, these mathematical models remain complex to understand to handle as well for the manipulation and the attribution of values to the different variables, for the scenario definition as for the CI topology and dependencies’ creation.

7.4 Conclusion

In this section, we presented works dedicated to the modelling and the simulation of different sectors CIs and of their dependencies. The studied tools are based either on agent-based modelling or on mathematical models.

The agent-based modelling tools propose different ways to model and simulate heterogeneous CIs. The first one focuses on (inter)dependencies simulations, the second one defines specific interfaces for existing simulators, and the third one focuses on the modelling of different levels of faults (physic, geographic and cyber) and on their propagation. The proposed solutions are specific solutions (e.g., EPOCHS proposes interfaces for NS-2, PSCAD/EMTDC and PSLF simulators, but allows the use of only two simulators simultaneously) or high-level solutions.


143

However, they may be used as study basis to design SYNTEX. Finally, it should be noted that ABM integrates an interesting feature, its learning ability that can be useful to model human behaviour and decision.

The mathematical models allow the simulation of (inter)dependencies and cascading failures. The first one is based on the Leontief model and the second one exhibits a sigmoid-like behaviour. The proposed solutions are too recent. They do not proposed sufficiently advanced solutions. Moreover, drawbacks of mathematical models are their complexity and their lack of tools (e.g., graphical tools) to help the simulation scenario design.

Summary of pros and cons features of simulation components to integrate within the SYNTEX

8. Summary of pros and cons features of simulation components to integrate within the SYNTEX

In this section we summarise the features of studied simulation component adapted to each SYNTEX design. The first table (Table 38) gives the pros and cons of each simulator. The second table (Table 39) points to which SYNTEX the simulation tool may be integrated.

Table 38: Pros and conf of suitable simulation components

possible tools simulation object granularity

level target audience

Public domain Hierarchical modelling impossibleAvailable on the main OS platforms

Stochastic modelling Predifined models availableCreation/modification of models and components

Discrete event simulatorA GUI is available for:

simple scenario creation Small scale network simulationInputs: - possibility to import topologies from various topology generators - traffic inputs through binary trace files

Outputs, exportation of simulation results in : - classical trace files - NAM trace files - personalized trace files (for limited parameter number)

Other features: - real time simulation capability - network emulation facility - proposition of a parallel and distributed NS (PDNS)

NS-2 Telecom infrastructures fine

General

Scenario description in OTcl (no GUI available)

Modelling

Adding new components is complex. It requires a good knowledge of the simulatorModellingFew random variables distributions are available for stochastic modelling

SimulationSimulation

pros cons

Designer: ability to create new models and compnts

Experimenter & MIT Tester: new model creation, simulation execution, statistics collection and analysis

External Simulator: data importation

External Analysis: statistics collection, outputs and logs generation

Operator: control of online simulation

MIT System: realistic simulation results, statistics collection, outputs generation

144




Available on various OS platforms Propritetary and expensive toolThe most complete tool for telecom network simulation

Complex tool. Require trainingStochastic modelling with various distributions for random variablesHierarchical modellingPredifined topologies/models/equipments availableCreation/modification of models and equipements

Discrete event simulatorPerforming GUI for (all information accessible through GUI): - scenario and model conception - data/statistics collection - simulation running - simulation results visualization and analysisCollection of statistics on global network, nodes, attibutes…

Results analysis possibilities: - filtering of simulation results to process/reduce/combine statistics - creation/saving of analysis configuration - association/comparison of several scenarios

Inputs: possibility to import data from text files, XML and various popular toolsOutputs:exportation of simulation statistics to spreadsheets or XMLOther features: - large scale network simulation - parallel and system in the loop simulations - faster than real time simulations - communications with other simulators (HLA module)

Operator: - control of online simulation

pros cons

OPNET Telecom infrastructures fine

General General

Modelling/SimulationModelling

Simulation

Designer: ability to create new models and components

Experimenter & MIT Tester: - new model creation - simulation execution - statistics collection - simulation results analysis and comparison

MIT System: - realistic simulation results - statistics collection - outputs generation

External Simulator: - data importation - HLA module

External Analysis: - statistics collection - outputs and logs generation

145




Available on various OS platforms Propritetary tool

Stochastic modellingHierarchical modellingPredifined models and equipments availablePossibility to create/modify models

Discrete event simulatorPerforming GUI for (all information accessible through GUI): - scenario and model conception - data/statistics collection - simulation running - simulation results visualization and analysis


Collection of statistics on global network, node, protocol…

Results analysis possibilities: - filtering of simulation results to process/reduce/combine statistics - customization of analyse reports - association/comparison of several results

Inputs: possibility to import configuration files, external files via HLA, etc.

Outputs:exportation of simulation statistics to trace files, of logsOther features: - large scale network simulation - parallel simulation - real time simulation - communications with other simulators (HLA library) - possibility to create scenario templates - form of network emulation


Simulation

pros cons

General

Modelling

Not clear that new component may be created

Few random variables distributions are available for stochastic modelling

Designer: ability to create new models

QualNet Telecom infrastructures fine

General

Modelling

External Simulator: - data importation - HLA module



146




Available on the main OS platforms Commercial toolOpen sourceFlexible and modular Specific language for topology definition

Stochastic modelling with some distributions for random variables, possibility to define new distributionsHierarchical modelling

Predifined (generic and network infrastructures) model and components

Creation/modification of models and components through the OMNeT API

Discrete event simulatorPerforming GUI: - topology description - simulation running - simulation results visualization and analysisCollection of statistics on global network, nodes, links…Filtering of simulation results before analysing the trace filesInputs: - importation/exportation of topologies from/to data and XML files - interaction with databasesOutputs: various simulation statistics output files, log filesOther features: - large scale network simulation - parallel distributed simulation - system in the loop simulation - OMNET tool not required to run simulation (execution file creation)



External Simulator: - data importation



General Designer: ability to create new models and components

OMNET++All infrastructures

with a generic modelling

Depends on the defined

model granularity

General

Modelling

Simulation

Modelling/Simulation

No GUI for: - model/equipment creation and modification

(done in C++) - scenario definition (done in a confiuration file)

pros cons

147




Free of chargesOpen sourceMulti platform support

Stochastic modelling Hierarchical modelling

Predifined (generic and network infrastructures) model and componentsSimulation performances not documented

Creation/modification of models and components

Real-time simulatorPerforming GUI for: - simulation model (topology and part of scenario) description (generate associated TCL code) - simulation running - simulation results visualization and analysisCollection of statistics on global network, nodes, links…Inputs: - files for incoming traffic - imporation of XML scenario model filesOutputs: various simulation statistics output files, log filesOther features: - plug in of java real-time applications - possibility to act on simulation while it is running

GNU public licence No GUI for C++ implementationC++ and Java implementationsGaining popularity

Stochastic modelling with continuous and discrete random variables (wide range of distributions for C++ implementation)Hierarchical modelling in Java implementation

Storage of information on topology, simulation environment and simulation runtine in 3 distinct filesLarge scale simulationParallel and distributed simulation

Designer: ability to create new models and componentsExperimenter & MIT Tester: - new model creation - simulation execution - statistics collection and analysisMIT System & External Analysis: statistics collection, outputs and logs generation

SSFAll infrastructures



model granularity

General

Modelling

Simulation

Script language to construct/configure/control the simulation

Few random variables distributions are available for stochastic modellingNo GUI for model/equipment creation and modification (done in Java)


J-SimAll infrastructures



model granularity

General

Modelling

Simulation

pros cons

Simulation

Few documented GUI for Java implementation

Use of a specific language to describe topology, simulation environment and simulation run-timeNo information on inputs, real network interactions, information exchange with other simulators, fast simulation capabilities


MIT S tExperimenter & MIT Tester: - new model creation - simulation execution - statistics collection - simulation results analysis

MIT System: - statistics collection - outputs generation




148




Alternative to HLA Few documentedPatitioning of protocol layers among the cooperative heterogeneous simulators

Use of the best models of each simulator

Large scale network simulationParallel and distributed real time simulation (involves improvement of simulators running speeds)Network emulationSystem or human in the loop simulation (not documented)Other simulation features depend on the used simulators

Available on Windows OS platforms Propritetary toolFlexible and adaptable Only available on Windows OS

Use of differential equations to model admittancies, controllers and machine behaviorsPredifined models and elements availableCreation/modification of models

Time and frequency domain simulationAll NETOMAC information stored in a databasePerforming GUI for: - system modelling (with NETCAD) - simulation results visualization and analysisStatistics on machines, networks, loads and controllersVarious and performing analysis of system states and statisticsInputs: - from NETCAD (system mdel) - from other simulators through the databaseOutputs:exportation of simulation statistics on various formatsOther features: - real-time simulation of electromechanical transients - interface with real time applications - interface with analogue real-time simulators

BackPlanecommunications between telecom

simulators

fine (depends on

the used simulation

tools)

General General Experimenter / External Analysis: - collection and analysis of dependency statistics

Modelling/Simulation Split of protocol layers cernerly generate difficulties for model conceptionModelling

Use of several simulators in the same protocol stack slows down the simulation speed.

Simulation

No information on parallel or distributed simulation

Simulation

NETOMAC

Dynamics and transients

behaviors of electric power

systems

fine

General

pros cons


Experimenter & MIT Tester: - new model creation - simulation execution - statistics collection - simulation results analysis



External Analysis: - statistics collection - outputs generation

General

Modelling No consideration of communication capabilitiesSimulation

149




Available on Windows OS platforms Propritetary toolWell documented Only available on Windows OS

Predifined models and elements availableUse of different mathematical models for elementsCreation/modification of models

Includes the main features of NETOMAC as a moduleVarious and performing analysis and calculation are availableAll SINCAL information stored in a databasePerforming GUI for: - system modelling - planning scenario definition - simulations running - simulation results visualization and analysis


Inputs : - through the database (no need to handle different input files) - possible importation of data in various standard data formats or plotting formatOutputs: - generation of reports - exportation of dataOther features: - no restriction on the number of nodes/substations - more than one network can be calculated simultaneously - possible interfacing to GIS and SCADA systems - possible work with SINCAL via the Internet


No information on parallel or distributed simulationSimulation

SINCALPower

transmission and distribution

fine

General General

Modelling SimulationStatic simulation program but possible to include NETOMAC as a module





pros cons

150




Available on Windows OS platforms Propritetary toolDedicated to high voltage power systems

Mathematical model for load modellingUse of discrete and continuous variables

Only available on Windows OSFew available information

Predifined models and components availableConsideration economic data influence on the modelCreation/modification of models

No information on possible inputsPerforming GUI centralizing all functionalities: - model and scenario definition - simulation running visualization - simulation results visualization and analysis

No information on parallel or distributed simulation

Possiility to act on simulation during its executionOutputs: possible exportation of simulation statistics for analysis by other tools

Other features: - simulation of systems of up to 100 000 buses - GIS tool - tools to calculate sensitivities - adds on to launch and control PowerWorld from another application



Simulation of dependencies between an electrical CIs and its telecom CI Considers only two simulators at the same time

Agent-based modelling of dependencies Fast simulation capabilities not specifiedInterfacing simulators according to their specificities, even if source code is not availableCI modelling depends on the used simulators

Exchange of information between simulators through agents, at specific synchronization pointsCI simulation depends on the used simulators

Simulation


Experimenter & MIT Tester:



Power World

high voltage power systems fine

General General

Modelling

No consideration of communication capabilities

Simulation

Simulation

pros cons

General Experimenter / External Analysis: - collection and analysis of dependency statistics

EPOCHSElectrical CIs with

communication capabilities

fine

General

modelling

Simulation

151




Available on Windows OS platforms Propritetary toolLast version only available on Windows OS

Use of differential equations to model behaviorsPredifined models and components availableCreation/modification of models and components

Limited to time domain simulationsContinuous time simulationPerforming GUI for: - model and component definition - scenario definition - simulation running - simulation results visualization and analysisPossibility to import dataOutputs: - contant files - log files (possible exportation to MS Excel) - output filesOther features: - scenarios can be written in Fortran C and MathLab - fast simulation capabiility (short duration responses)


Simulation of electicity markets Only available on Windows OS

Agent-based modellingDifferent possible languages to code agentsStochastic modelling of power production and load

Discrete event simulatorUse of agent learning capabilities to adapt behavior during simulation running A GUI for: - system and scenario modelling - simulation running - simulation results visualization and analysis

Simulator does not get inputs (no information on this part)

Outputs:generation of trace files

Experimenter & MIT Tester: - new model creation - simulation running - statistics collection, analysis

PSCAD / EMTDC

electromagnetic transients fine

General

ModellingNo consideration of communication capabilities

SimulationSimulation

SimulationSEPIA

Electrical power infrastructures and associated market

Coarse

General

Modelling No consideration of communication capabilities

Modelling

Coarse level modelling of electrical networks

cons

General

Only uniform distribution for random variablesSimulation

General

Few information is available on fault generationNo information on parallel or distributed simulationNo information on type of data that can be imported

Designer: ability to create new models & components

MIT System: realistic simulation results, statistics collection outputs generation

External Simulator: data importation External Analysis: statistics collection, outputs generation

Experimenter & MIT Tester: - new scenario model creation - simulation execution - statistics collection - simulation results analysis

MIT System & External Analysis: statistics collection, outputs generation


pros

152




Simulation of dependencies between different sectors' CIs with agents No information on behavioral models used for CIs modelling

Agent-based modelling of dependenciesCI modeled with behavioral models

Plug-in and out of models as neededGIS support for error propagation visualization

Consideration of CI inoperability (depending on possible perturbation of the CI and on other CI inoperability)

Modelling of CIs (topology, disturbances and dependencies) with matrixes

Based on the Leontief model for perturbation propagation modelling No GUIIntroduction of dynamics in the system with bufferring of perturbation propagation

Discrete event simulation (equation recalculated each discrete time)Simulation results stored in a trace fileResults can be viewed on a chart

Interesting for study and presiction of cascading effects Work in progress

Network modelling with directed graphsModelling of node state with a normal operation variableModelling of perturbation level of components No tool for topology creation/generation

Modelling of spontaneous failures

Simulation of failure propogation according to link featuresModelling/simulation of recovery process

cons

ENEA math. model

Interdependencies Fine for CI in/operability

North Carolina

University Simulation

tool

Infrastructures and cross-

infrastructures


model granularity

Experimenter / External Analysis: - analysis of fault propagation and CI components perturbation level

General


General

Modelling

Simulation

General Work in progressModelling/Simulation

No distinction between architecture componentsNo tool for topology creation/generation

Experimenter / External Analysis: - analysis of dependency statistics

Experimenter / External Analysis: - analysis of fault propagation and CI components inoperability

pros

Dresden Univ., Zilina Univ.,

Collegium Budapest

math. model

cascading failures and disasters General

General

Modelling

Simulation

Modelling

Simulation

No distinction between architecture components


No information on (fast) simulation capabilities

General

153




Consideration of physical, geographical and cyber faults Work in progressGeneral level

Agent-based modellingInfrastructure components modeled by its operating level (calculated with fuzzy numbers), its requirements and the fautlsDependencies between components represented through incidence matrix

Uses the REpast ABM tool features

CISIAfault propagation and performance

degradationGeneral

General

Modelling

Simulation

General Experimenter / External Analysis: - analysis of fault propagation

pros cons

Table 39: Simulation tools possible integration

SYNTEX Integrated view

SYNTEX Overlay view Possible interfacing for the SYNTEX overlay view

OPNET Use of HLA, use of inputs/outputs, development of a specific interfaceNS Use of inputs/outputs, development of a specific interfaceQUALNET Use of HLA, use of inputs/outputs, development of a specific interfaceOMNeT++ Use of inputs/outputs, development of a specific interfaceJ-Sim Use of inputs/outputs, development of a specific interfaceSSF Use of inputs/outputs, development of a specific interfaceBackPlane Similar principle than HLANETOMAC Use of inputs/outputs, development of a specific interfaceSINCAL Use of inputs/outputs, development of a specific interfacePower World Use of inputs/outputs, development of a specific interfacePSCAD/EMTDC Use of inputs/outputs, development of a specific interfaceSEPIA Use of inputs/outputs, development of a specific interfaceNorth Carolina University Simulation toolEPOCHS Use of specific interfacesCISIAENEA math. modelDresden Univ., Zilina Univ., Collegium Budapest math. model

154

Conclusion

155

9. Conclusion

This document presented a list of simulation tools suitable for modelling and simulation of critical infrastructures. The objective was to identify the tools and components that could be considered and integrated within SYNTEX according to the selected design. We proposed two possible SYNTEX designs in Section 3. The first one consists in integrating SYNTEX within critical infrastructures and simulating CIs as a whole including their dependencies (represented as dependency flows). The second possible design considers that each CI has its own simulator and SYNTEX is used as an overlay that interfaces the different CI simulators to exchange scenario information among them.

We differentiated two types of simulators: dedicated simulators and generic simulators. Most of the simulators of the literature are dedicated simulators. They are sector-specific (either for telecommunications or for electrical infrastructures) and do not allow the simulation of other types of infrastructures. However, new models and components can be defined to design and simulate new protocols. Moreover, they include precise models and provide efficient simulations. These simulators generally include specific tools:

• To assist in the design of simulation scenarios. • To animate/display the simulation. • To help to collect simulation statistics. • To help to understand and analyse simulation results by the way, for example, of charts.

The most complete simulators are OPNET and QualNet for telecommunications and SINCAL for electricity. Moreover, SINCAL optionally simulates SCADA devices but is not able to model a full telecom network yet.

These simulators can be used in the second possible design of SYNTEX, because they allow precise simulation of the infrastructures and are already used by stakeholders. But data exchange between them is difficult since they are often proprietary products and do not necessarily use compatible data formats for simulation inputs and outputs. Hopefully, several solutions were identified to assist information exchange:

• The use of the HLA standard. Unlike SINCAL, OPNET and QualNet include an HLA module. This means it would be required to extend the SINCAL source code to make it HLA aware, but this solution may have a high cost due to the constraints of the HLA standard.

• Developing different interfaces for each simulator as it is described for the EPOCHS solution (Section 6.2.3). However, the complexity of this solution increases with the number of different simulators used.

• Developing a specific communication channel as described in the backplane project (Section 5.3.4). The advantage of this solution is that it proposes a similar (but less restricting) solution than HLA.

Generic simulators are normally used for the simulation of telecommunication networks and include specific models for sector-specific simulation. The main advantage of this approach is that the generic description of model elements offers the possibility to model infrastructures of any type (in the case of IRRIIS, telecommunication as well as electrical networks). The system is

Conclusion

156

modelled by black boxes that are described by their behaviour and their input/output interfaces. Various types of components (specific to each infrastructure) may be modelled with these generic boxes. Boxes are connected by the way of generic links. These links may model telecommunication flows, electric power flows or dependency flows. Therefore, different models can be defined from the generic elements (boxes and links). A simulator like OMNeT++ integrates a GUI and tools to graphically define models and scenario, to specify the statistics to be collected, to display the simulation, and to analyse simulation results.

These simulators can be used to implement the first design of SYNTEX (with a global view). Since the same simulator is used in all infrastructures, heterogeneity (of simulators) is no longer an issue. However, it is essential that the simulator supports distributed simulation and that it is available on various operating systems (to be used in all CIs). OMNeT++, for instance, complies to this constraint.

Agent-Based Modelling and simulation environments, like REpast, also allow generic modelling and integrate GUIs, display and analysis tools for the simulation. The major difference between classical simulators and ABM environments is that the use of agents offers learning capabilities. The behaviour of an agent can vary according to its experience. This feature can be used to simulate human behaviour and actions within CIs. However, the execution agent systems (communications, learning, etc.) require a lot of resources that can impact the simulation speed (this aspect is usually not evoked in the studied works). This may become a drawback for simulation within SYNTEX.

ABM can be used to simulate the dependencies according to meta-knowledge, to interface existing simulators by allowing the dependency data exchange and the synchronization of the simulators or to implement completely a generic simulator and the dependencies with offered/consumed resources and fault propagation.

Apart from the few generic simulators presented in Section 6, the tools we identified do not allow simulation of multiple and heterogeneous critical infrastructures together with their (inter)dependencies.

The mathematical models described for the simulation of (inter)dependencies are presented in recent publications (2006). The disadvantages of these models lie in their complexity and their lack of graphical tools to create models, to display the simulation, and to analyse simulation results.

The SEPIA simulator has interesting considerations of the market influence on the electrical infrastructure.

Most of the studied tools are available:

• Tools such as OPNET, QualNet, OMNeT++, PSCAD/EMTD, PowerWorld, etc. are subject to a commercial licence.

• Tools like SINCAL and NETOMAC are available within the IRRIIS consortium since these tools are project partners property.

• Tools like NS-2 are available and free of charges.

The problem is posed for academic research project and industrial research work and projects because they may not be achieved or they may be confidential. In this case, they may be used as reflexion basis.

Conclusion

157

To conclude, the choice of the simulators or components to be integrated within SYNTEX depends on the selected design (what is the scope of SYNTEX: does it simulate several infrastructures or not?).

For the integrated view of the SYNTEX, the OMNeT++ simulation tool seems to be the most adapted simulator to represent the canonical architectures used in this view for the modelling of critical infrastructures. It includes efficient GUI and supports distributed simulation. Finally, it may be extended to be turned to specific SYNTEX requirements.

For the overlay view of the SYNTEX, the OPNET (for telecom) and SINCAL (for electric power supply) are the most suitable simulation tools in each specific sector. However, these simulators are not able to communicate directly. They must be interfaced. Several solutions are possible. The first one is to exploit the HLA capability of OPNET. In this case, it is essential to extend SINCAL in order to make it HLA compliant. The second possibility is the definition of an overlay, a similar but less restrictive solution than HLA, imposes a common format for the exchange of dependency information. The last possibility is the development of a specific interface using specific objects like agents in charge of the exchange of data. In all cases, synchronisation of simulators is essential.

As we seen, whatever design is selected, suitable tools exist and can be used but extensions and developments are always required to allow the simulation of heterogeneous CIs and of the (inter)dependencies.

Glossary

158

10. Glossary

Attack tool Tool to design attack trees that can be used to generate fault behaviours. The attack tool allows the editing of attack trees, generates all possible fault behaviours and allows the user to modify the results.

Attack tree “Attack trees provide a formal, methodical way of describing the security of systems, based on varying attacks. Basically, you represent attacks against a system in a tree structure, with the goal as the root node and different ways of achieving that goal as leaf nodes.” (Schneier, 1999)

Attribute Each component can have at least one attribute. Attributes have a name, a data type and a certain value. One can distinguish between basic attributes (e.g. the capacity of a generator or the amount of electric power consumed by a consumer) and derived attributes (e.g. the load in a distribution line) which are calculated using the basic attributes.

Attribute value plot

Attribute value plots are used in online mode and analysis to show the evolution of attribute values over time or to show the relation between different attribute. During analysis the attribute may be from the same or from different simulation runs.

Behaviour See user-specified behaviour, system-specified behaviour

Batch mode The batch mode of the simulator is used to run many simulations automatically without having to interact with the simulation environment. The scenarios to run and possible fault behaviours are specified in a beforehand.

Cascading effect See cascading failure

Cascading failure

“A cascading failure occurs when a disruption in one infrastructure causes the failure of a component in a second infrastructure, which subsequently causes a disruption in the second infrastructure.” (Rinaldi, 2001)

Glossary

159

CI model A CI model consists of components and connections between them.

Component A (network) component is an object in a CI Model e.g. a generator, a transmission line, a substation. Components have attributes and user-specified behaviour.

Connection Connections describe links between different components in a CI model. E.g. a generator can be linked to a transmission line. Connections may be realised as attributes but should be handled differently in the

GUI due to their importance for network modelling.

Continuous simulation

In continuous simulation, the system behaviour is represented by differential equations and the simulation consists in solving the equation.

Cyber interdependency

“An infrastructure has a cyber interdependency if its state depends on information transmitted through the information infrastructure.” (Rinaldi, 2001)

Discrete event simulation

In discrete event simulation, the system-specified behaviour is described as a series of events that must be processed at a discrete point of the simulated time and that take a certain amount of real time. Events are managed by an event scheduler enabling usually offline simulations. Nevertheless, some simulators integrate real-time event schedulers permitting online simulations. Online simulation requires taking into account inputs from the real network or from an application and the output of data that will be re-injected in the real network or sent to the application.

Event An event describes what happens to a component in the CI model if a condition is fulfilled, e.g. the tripping of a transmission line at a certain time.

Event log The event log contains all events which occurred during a simulation run and are considered “important”, e.g. the trip of a line. System-specified behaviour or user-specified behaviour may write to the event log.

Glossary

160

Fault behaviour The fault behaviour describes negative effects to an infrastructure, like attacks or faults. For the simulation, fault behaviour can be loaded in addition to the “normal” scenario behaviour. Fault behaviour may be created “by hand” as other behaviours or with the support of the attack tool using attack trees.

Fault tree Fault trees represent fault sequences of components in which each component is logically decomposed into sub-components (CXX). In a Fault

Tree, leaves represent failures of sub-components (fault causes), and the logical nodes are the faults (consequences) of the components

Geographical interdependency

“Infrastructures are geographically interdependent if a local environmental event can create state changes in all of them.” (Rinaldi, 2001) E.g. if telecommunication and electrical distribution lines use the same bridge, the destruction of the bridge (local environmental event) has effects on the state of both infrastructures.

GUI A GUI is a graphical user interface which allows the user to interact with the simulation in an intuitive way.

HLA HLA (High Level Architecture) is an IEEE standard developed by the United States department of defence HLA00a, HLA00b, HLA00c, HLA03, Kuh99]. It allows the exchange of information among several and heterogeneous simulators during simulation running. Communications are possible thanks to the RTI (Run Time Interface), which provides a set of services useful for simulations to coordinate their actions and the information exchange. To communicate through the RTI, each simulator must be RTI compliant:

• By implementing/using a RTI compliant API. • By respecting the OMT (Object Model Template) for information

(objects, events, etc.) exchange and for specific simulator modelling. • By respecting a number of rules concerning communications

between simulations and concerning each simulation. The HLA ability can be useful to exchange information between electricity and telecom simulators.

Glossary

161

LAMPS LAMPS (Language for Agent-based Modelling of Processes and Scenarios) is a general language to describe processes and scenarios. It has some similarities to Petri Nets as it also has places, tokens and transitions (called actions in LAMPS). Places can contain tokens which represent some data. There are rules associated with each action which invoke the actions under certain conditions. These actions get tokens as input data and may create one or several tokens as output. LAMPS can be used to describe all kinds of

user-specified behaviour ( component behaviour, scenario behaviour and fault behaviour).

Log See Event log and simulation log.

Logical interdependency

“Two infrastructures are logically interdependent if the state of each depends on the state of the other via a mechanism that is not a physical, cyber, or geographic connection.” (Rinaldi, 2001)

Model A model is the description a given topology, i.e. the nodes and links involved. See CI Model

Modelling Modelling denotes the action of representing a real topology in a given formalism.

Online mode If a simulation is running in online mode, the user can monitor and influence the running simulation, e.g. by changing the values of

attributes.

Physical interdependency

“Two infrastructures are physically interdependent if the state of each is dependent on the material output(s) of the other.” (Rinaldi, 2001)

Scenario A scenario consists of a CI model, the initial states of all components and the scenario behaviour which describes the events which happen within the scenario.

Scenario behaviour

The scenario behaviour describes the “normal” events which happen within a scenario (e.g. a consumer changes the amount of electric power that is consumed). The events may be triggered by time or by other conditions defined in the scenario behaviour.

Glossary

162

Simulation log The simulation log contains the evolution of the values of all attributes over time. It builds the basis for the analysis of simulation runs.

Simulation run A simulation run is a single execution of a scenario and optional fault behaviour.

System-specified behaviour

System-specified behaviour is behaviour of components or scenarios which is either to basic or to complicated to be described as user-specified behaviour and therefore has to be implemented in a programming language by a developer.

Topology A topology is given by connections between components of a CI model.

User-specified behaviour

User-specified behaviour is behaviour which can be designed and modified by the user using a special language for behaviour definition ( LAMPS). User-specified behaviour can invoke other user-specified behaviour or

system-specified behaviour.

References

163

11. References

11.1 General references

[D.1.3.1] IST IRRIIS project, Catalogue of Requirements for the SYNTEX, August 2006.

[DC1] http://www.mathsrevision.net/alevel/pages.php?page=52 (last access on 10/09/06)

[DHS] Department of Homeland Security Home Page, http://www.dhs.gov/dhspublic/ (last access on 10/09/06)

[DoW05] IST IRRIIS project, Annex 1 - description of work, December 2005.

[DV1] http://www.stats.gla.ac.uk/steps/glossary/probability_distributions.html#discvar (last access on 10/09/06)

[DV2] http://www.mathsrevision.net/alevel/statistics/discrete_random_variables.php (last access on 10/09/06)

[HLA00a] 1516:2000 IEEE Standard for Modelling and Simulation (M&S),High Level Architecture (HLA) - Framework and Rules, 2000.

[HLA00b] 1516.1:2000 Errata 2003 IEEE Standard for Modelling and Simulation (M&S) High Level Architecture (HLA) - Federate Interface Specification, 2000.

[HLA00c] 1516.2:2000 IEEE Standard for Modelling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT) Specification, 2000.

[HLA03] 1516.3:2003 IEEE Recommended Practice for High Level Architecture (HLA) Federation Development and Execution Process (FEDEP), 2003.

[Kuh99] Kuhl F., R. Weatherly, J. Dahmann, Creating Computer Simulation Systems: An Introduction to the High Level Architecture. Upper Saddle River, NJ: Prentice Hall., 1999 (ISBN: 0-13-022511-8; Published: Oct 8, 1999; Copyright 2000).

[LeG04] Le Grand, Riguidel, A global framework to enhance critical infrastructure protection, in the proceedings of the International Conference on Critical Infrastructures CRIS'2004, 25-27 October 2004 Grenoble, France

[LeG06a] Gwendal Le Grand, Eyal Adar, White Cyber Night -- a risk assessment tool for network resilience evaluation,in the proceedings of the International Workshop on Complex Network and Infrastructure Protection (CNIP'06), Rome, March 28-29 2006

[LeG06b]Le Grand, G., Riguidel, M., Urien, P., Serhrouchni, A., Tchepnda, C., Naqvi, S., Tastet, F., Lopez, G., Johnson, J., Arujo, J., Gessler, G., and Feroul, M.. D1.4: Final Trust, Security and Policy Framework. SEINIT Project, Sixth Framework Programme, Security Expert Initiative, December 2005

[MoC] Monte Carlo simulation http://www.vertex42.com/ExcelArticles/mc/MonteCarloSimulation.html (last access on 10/09/06)

[TISN] Trusted Information Sharing Network for Critical Infrastructure Protection Home Page http://www.cript.gov.au/agd/www/TISNhome.nsf (last access on 10/09/06)

http://www.mathsrevision.net/alevel/pages.php?page=52

http://www.dhs.gov/dhspublic/

http://www.stats.gla.ac.uk/steps/glossary/probability_distributions.html#discvar

http://www.mathsrevision.net/alevel/statistics/discrete_random_variables.php

http://perso.enst.fr/%7Elegrand/Publis/CRIS2004.pdf

http://www.leg.ensieg.inpg.fr/cris2004/

http://perso.enst.fr/%7Elegrand/Publis/WCK.pdf

http://perso.enst.fr/%7Elegrand/Publis/WCK.pdf

http://www.vertex42.com/ExcelArticles/mc/MonteCarloSimulation.html

http://www.cript.gov.au/agd/www/TISNhome.nsf

References

164

11.2 Scenario generation references

[And01] Andrew P. Moore, Robert J. Ellison, Richard C. Linger, Attack Modelling for Information Security and Survivability, Mar 2001, www.cert.org/archive/pdf/01tn001.pdf (last access on 10/09/06)

[Bal06] Balducelli C., Vicoli G., “A Tool to formalise and test attack scenarios of software intensive critical infrastructures”, 13th TIEMS (The International Emergency Management Society) Annual Conference, May, 23-26, 2006, Seul, Korea.

[IsoG] Isograph Web site: http://www.isograph-software.com/index.htm (last access on 10/09/06)

[McQ06] McQueen M., Boyer W, Flynn M., Alessi S., “Quantitative Risk Reduction Estimation Tool for Control Systems: Suggested Approach and Research Needs”, in proceedings of The International Workshop of “Complex Systems & Infrastructure Protection”, march 28-29, 2006, Rome, Italy.

[Rob81] Roberts, N. H., V. W. Vesely, D. F. Haasl, and F. F. Goldberg. Fault Tree Handbook, Systems and Reliability Research, Office of Nuclear Regulatory Research. U.S. Nuclear Regulatory Commission. Washington, D.C. 20555, (1981).

[Sch99] Schneier, B., Attack Trees: Modelling Security Threats, Dr. Dobb’s Journal, December 1999, ISSN 1044-789X.

11.3 Telecommunication network simulator references

11.3.1 OPNET references

[Kou04] Anis Koubaa, Gestion de la Qualité de Service temporelle selon la contrainte (m,k)-firm dans les réseaux à commutation de paquets, Thèse INPL, October 2004. (www.loria.fr/~akoubaa/PhD, last access on 10/09/06)

[OPNet] The OPNET simulator Home Page http://www.opnet.com (last access on 10/09/06)

[OPNetHLA] the OPNET HLA module: http://www.opnet.com/products/modules/hla.html (last access on 10/09/06)

[OPNetMod] The OPNET Modeler Home Page www.opnet.com/products/modeler/home.html (last access on 10/09/06)

[OPNetTut] OPNET tutorial: www.loria.fr/~akoubaa/OPNET/main.htm (last access on 10/09/06)

[Kim03] Andrew Kim, OPNET tutorial, 2003 (www.loria.fr/~akoubaa/OPNET/Files/Andrew Kim Opnet Tutorial.pdf, last access on 10/09/06)

11.3.2 NS-2 references

[Bre00] Breslau, L.; Estrin, D.; Fall, K.; Floyd, S.; Heidemann, J.; Helmy, A.; Huang, P.; McCanne, S.; Varadhan, K.; Ya Xu; Haobo Yu, Advances in network simulation, IEEE Computer Volume 33, Issue 5, May 2000 Page(s):59 - 67

[Fal99] Kevin Fall, Network Emulation in the Vint/NS Simulator, ISCC July 1999

http://www.cert.org/archive/pdf/01tn001.pdf

http://www.isograph-software.com/index.htm

http://www.loria.fr/%7Eakoubaa/PhD

http://www.opnet.com/

http://www.opnet.com/products/modules/hla.html

http://www.opnet.com/products/modeler/home.html

http://www.loria.fr/%7Eakoubaa/OPNET/main.htm

http://www.loria.fr/%7Eakoubaa/OPNET/Files/Andrew%20Kim%20Opnet%20Tutorial.pdf

http://www.loria.fr/%7Eakoubaa/OPNET/Files/Andrew%20Kim%20Opnet%20Tutorial.pdf

References

165

[Net_em] NS network Emulation: http://www.isi.edu/nsnam/ns/ns-emulation.html (last access on 10/09/06)

[NS-2] NS-2 simulator Home Page: http://www.isi.edu/nsnam/ns/ (last access on 10/09/06)

[NStut] NS tutorial: http://nile.wpi.edu/NS/ (last access on 10/09/06)

[NStopo] NS topology generation: http://www.isi.edu/nsnam/ns/ns-topogen.html (last access on 10/09/06)

[PADS] The PADS research group Home Page: http://www.cc.gatech.edu/computing/pads (last access 10/09/06)

[PDNS] the PDNS (Parallel and Distributed NS) Home Page: http://www-static.cc.gatech.edu/computing/compass/pdns/ (last access on 10/09/06)

[Sce_gen] NS scenario generation: http://www-mash.CS.Berkeley.EDU/ns/ns-scengeneration.html (last access on 10/09/06)

[VINT] VINT project Home Page: http://www.isi.edu/nsnam/vint/ (last access on 10/09/06)

11.3.3 QualNet/GloMoSim references

[Cla03] Clare, L.P.; Jennings, E.H.; Ciao, J.L.; Performance evaluation modelling of networked sensors; Aerospace Conference, 2003. Proceedings. 2003 IEEE Volume 3, March 8-15, 2003 Page(s):3_1313 - 3_1322.

[Xia98] Xiang Zeng, Rajive Bagrodia, Mario Gerla, GloMoSim: a Library for Parallel Simulation of Large-scale Wireless Networks, PADS '98, May 26-29, 1998 in Banff, Alberta, Canada.

[NCW] QualNet, Network Centric Warefare, QualNet white paper, 2006. http://www.scalable-networks.com/products/developer/special_documents.php (last access on 10/09/06)

[Bag98] R. Bagrodia, R. Meyer, M. Takai, Y. Chen, X. Zeng, J. Martin, B. Park, H. Song, PARSEC: A Parallel Simulation Environment for Complex Systems, Computer, Vol. 31(10), October 1998, pp. 77-85.

[Mon03] Alberto Montresor, Gianni Di Caro, Poul E. Heegaard, Architecture of the Simulation Environment, BISON IST-2001-38923 deliverable. Biology-Inspired techniques for Self Organization in dynamic Networks, June 2003.

[QualNet] the QualNet Simulator Home Page: http://www.scalable-networks.com/ (last access on 10/09/06)

[Speed] QualNet, Speed and Scalability: Requirements for Industrial Strength Network Simulator, QualNet white paper, 2002. http://www.scalable-networks.com/products/developer/special_documents.php (last access on 10/09/06)

11.3.4 OMNeT++ references

[Erd01] Erdei, M., A. Wagner, K. Sója, M. Székely, “A Networked Remote Simulation Architecture and its Remote OMNeT++ Implementation”. In Proceedings of the European Simulation Multiconference (ESM 2001), Prague, Czech Republic, June 2001.

[Len97] Lencse, G., “Efficient Simulation of Large Systems – Transient Behaviour and Accuracy”. In Proc. of the 9th European Simulation Symposium (ESS’97). October 1997, Passau, Germany.

http://www.isi.edu/nsnam/ns/ns-emulation.html

http://www.isi.edu/nsnam/ns/

http://nile.wpi.edu/NS/

http://www.isi.edu/nsnam/ns/ns-topogen.html

http://www.cc.gatech.edu/computing/pads

http://www-static.cc.gatech.edu/computing/compass/pdns/

http://www-static.cc.gatech.edu/computing/compass/pdns/

http://www-mash.cs.berkeley.edu/ns/ns-scengeneration.html



http://www.isi.edu/nsnam/vint/

http://www.scalable-networks.com/products/developer/special_documents.php


http://www.scalable-networks.com/



References

166

[Len98] Lencse, G., “Efficient Parallel Simulation with the Statistical Synchronization Method”. In Proceedings of the Western Multiconference on Simulation (WMC’98), Communication Networks and Distributed Systems (CNDS’98). January 1998, San Diego, CA.

[OMNeT] The OMNeT simulator Home Page: http://www.omnetpp.org/ (last access on 10/09/06)

[OmnetManual] The OMNeT User Manual: http://www.omnetpp.org/doc/manual/usman.html (last access on 10/09/06)

[Var01] Varga Andras, Using the OMNeT++ Discrete Event Simulation System, In Proceedings of the European Simulation MultiConference (ESM’01), Prague, Czech Republic, June 2001.

[Wag01] Wagner, A., M. Erdei. 2001. “Agent-Based Resource Management for Remote Simulation Systems and an Implementation for Remote OMNeT++”. In Proceedings of the European Simulation Multiconference (ESM 2001), Prague, Czech Republic, June 2001.

11.3.5 J-Sim references

[J-Sim] J-Sim Simulator Home Page http://www.j-sim.org/ (last access on 10/09/06)

11.3.6 SSF references

[DaSSF] The DaSSF project home page: http://www.crhc.uiuc.edu/~jasonliu/projects/ssf/ (last access on 10/09/06)

[S3] The DARPA ITO Project S3 (Scalable Self-Organizing Simulations) home page: http://dimacs.rutgers.edu/Projects/Simulations/darpa/ (last access on 10/09/06)

[SSF] The SSF project home page: http://www.ssfnet.org/ (last access on 10/09/06)

11.3.7 Dynamic Network Emulation Backplane project References

[DNEB] The Dynamic Network Emulation Backplane project home page: http://www-static.cc.gatech.edu/computing/pads/netemulation/ (last access on 10/09/06)

[Per01] Kalyan Perumalla, Richard Fujimoto, Virtual Time Synchronization over Unreliable Network Transport, Proceedings of the ACM/IEEE Workshop on Parallel and Distributed Simulation, May 2001

[Ril01] George Riley, Mostafa Ammar, Richard Fujimoto, Kalyan Perumalla, Donghua Xu, Distributed Network Simulations using the Dynamic Simulation Backplane, Proceedings of the International Conference on Distributed Computing Systems, April 2001.

[Ril00] G. F. Riley, M. H. Ammar, and R. M. Fujimoto. Stateless routing in network simulations. In Proceedings of the Eighth International Symposium on Modelling, Analysis and Simulation of of Computer and Telecommunication Systems, August 2000.

[Wu01] Hao Wu, Richard Fujimoto, George Riley, Experiences Parallelizing a Commercial Network Simulator, Proceedings of the Winter Simulation Conference, December 2001.

[Xu01] Donghua Xu, George Riley, Mostafa Ammar, Richard Fujimoto, Split Protocol Stack Network Simulations Using the Dynamic Simulation Backplane, Proceedings of the ninth International Symposium on Modelling, Analysis and Simulation of Computer and Telecommunication Systems, August 2001.

http://www.omnetpp.org/

http://www.omnetpp.org/doc/manual/usman.html

http://www.j-sim.org/

http://www.crhc.uiuc.edu/%7Ejasonliu/projects/ssf/

http://dimacs.rutgers.edu/Projects/Simulations/darpa/

http://www.ssfnet.org/

http://www-static.cc.gatech.edu/computing/pads/netemulation/

http://www-static.cc.gatech.edu/computing/pads/netemulation/

References

167

11.4 Electrical network simulator references

11.4.1 NETOMACS references

[NETO] The NETOMAC Home Page: www.netomac.de (last access on 10/09/06)

11.4.2 SINCAL references

[SINCAL] The SINCAL Home Page www.sincal.de (last access on 10/09/06)

11.4.3 PowerWorld references

[PW] The PowerWorld Home Page: http://www.powerworld.com (last access on 10/09/06)

[PWUG] The PowerWorld User Guide: http://www.powerworld.com/Document%20Library/pw110UserGuide.pdf (last access on 10/09/06)

11.4.4 PSCAD references

[EM_UG] The EMTDC User Guide: http://pscad.com/PDF/EMTDC%20Users%20Guide%20V4.2.pdf (last access on 10/09/06)

[PSCAD] The PSCAD Home Page: http://pscad.com/ (last access on 10/09/06)

[PS_UG] The PSCAD User Guide: http://pscad.com/PDF/PSCAD%20Users%20Guide%20V4.2.pdf (last access on 10/09/06)

11.4.5 SEPIA references

[EPRI] The EPRI Home Page: www.epri.com (last access on 19/07/06)

[Har00] Harp, S.A.; Brignone, S.; Wollenberg, B.F.; Samad, T.; SEPIA. A simulator for electric power industry agents, Control Systems Magazine, IEEE, Volume 20, Issue 4, Aug. 2000 Page(s):53 – 69.

[SEPIA] The SEPIA project Home Page: http://www.htc.honeywell.com/projects/sepia/ (last access on 10/09/06)

11.5 ABM references

http://www.powerworld.com/

http://www.powerworld.com/Document%20Library/pw110UserGuide.pdf

http://pscad.com/PDF/EMTDC%20Users%20Guide%20V4.2.pdf

http://pscad.com/

http://pscad.com/PDF/PSCAD%20Users%20Guide%20V4.2.pdf

http://www.epri.com/

http://www.htc.honeywell.com/projects/sepia/

References

168

11.5.1 General ABM references

[ABM_L] List of available ABM tools: http://www.swarm.org/wiki/Tools_for_Agent-Based_Modelling (last access on 10/09/06)

[CAS] Complex Adaptive Systems: http://www.eas.asu.edu/~kdooley/casopdef.html (last access on 10/09/06)

[Drolls] Drools Tools documentation Home Page: http://labs.jboss.com/file-access/default/members/jboosrules/freezone/docs/3.0.2/html.index.html (last access on 10/09/06)

[Dun06] M. Dunn and V. Mauer, International CIIP Handbook 2006 Vol II: Analyzing issues, challenges and prospects, Series Editors, Andreas Wenger and Victor Mauer, Centre for Security Study, ETH Zurich, 2006 (ISBN: 3-905696-08-8).

[Chimaera] Chimaera Home Page, http://www.ksl.stanford.edu/software/chimaera/ (last access on 10/09/06)

[Cougaar] The Cougaar ABM environment Home Page: www.cougaar.org (last access on 10/09/06)

[JADE] The JADE ABM environment Home Page: http://jade.tilab.com/ (last access on 10/09/06)

[JBoss] JBoss rules Home Pages: http://www.jboss.com/products/rules (last access on 10/09/06)

[Mac05] Charles L. Macal, Michel J. North, Tutorial on agent-based modelling and simulation, Proceedings of the 2005 Winter Simulation Conference, Orlando, December 4th - 7th, 2005.

[Nor06] North, M.J., N.T. Collier, and J.R. Vos, "Experiences Creating Three Implementations of the Repast Agent Modelling Toolkit," ACM Transactions on Modelling and Computer Simulation, Vol. 16, Issue 1, pp. 1-25, ACM, New York, New York, USA (January 2006).

[OilEd] OilEd Home Page: http://www.ontoknowledge.org/oil/ (last access on 10/09/06)

[OntoL] OntoLingua Home Page http://www.ksl.stanford.edu/software/ontolingua/ (last access on 10/09/06)

[OntoE] OntoEdit Home Page, http://www.ontoknowledge.org/tools/ontoedit.shtml (last access on 10/09/06)

[Protégé] Protégé Hoem Page, http://protege.stanford.edu/ (last access on 10/09/06)

[REpast] The REpast ABM environment Home Page: http://repast.sourceforge.net/ (last access on 10/09/06)

[Rin01] Rinaldi, S.M.; Peerenboom, J.P.; Kelly, T.K.;Identifying, understanding, and analyzing critical infrastructure interdependencies, Control Systems Magazine, IEEE Volume 21, Issue 6, Dec. 2001 Page(s):11 – 25.

[Swarm] The SWARM ABM environment Home Page: www.swarm.org (last access on 10/09/06)

11.5.2 The North Carolina University ABM simulation tool

[Tol04] William J. Tolone, David Wilson, Anita Raja, Wei-ning Xiang, Huili Hao, Stuart Phelps, E. Wray Johnson. Critical Infrastructure Integration Modelling and Simulation" Proceedings

http://www.swarm.org/wiki/Tools_for_Agent-Based_Modelling

http://www.swarm.org/wiki/Tools_for_Agent-Based_Modelling

http://www.eas.asu.edu/%7Ekdooley/casopdef.html

http://labs.jboss.com/file-access/default/members/jboosrules/freezone/docs/3.0.2/html.index.html

http://labs.jboss.com/file-access/default/members/jboosrules/freezone/docs/3.0.2/html.index.html

http://www.ksl.stanford.edu/software/chimaera/

http://www.cougaar.org/

http://jade.tilab.com/

http://www.jboss.com/products/rules

http://www.ontoknowledge.org/oil/

http://www.ksl.stanford.edu/software/ontolingua/

http://www.ontoknowledge.org/tools/ontoedit.shtml

http://protege.stanford.edu/

http://repast.sourceforge.net/

http://www.swarm.org/

References

169

of 2nd Symposium in Intelligence and Security Informatics Tucson, Arizona, June 2004. http://www.sis.uncc.edu/%7Eanraja/PAPERS/ISI04.pdf (last access on 10/09/06)

[Tol04b] William J. Tolone, David Wilson, Anita Raja, Wei-ning Xiang, E. Wray Johnson. Applying Cougaar to Integrated Critical Infrastructure Modelling and Simulation. Proceedings of First Open Cougaar Conference New York City, July 2004. http://www.sis.uncc.edu/%7Eanraja/PAPERS/OCC04.pdf (last access on 10/09/06)

11.5.3 EPOCHS references

[Hop 03] Hopkinson, K.M.; Giovanini, R.; Wang, X.; Birman, K.P.; Coury, D.V.;Thorp, J.S., EPOCHS: Integrated Cots Software For Agent-Based Electric Power And Communication Simulation , Winter Simulation Conference. December 2003, New Orleans, USA. http://www.cs.cornell.edu/projects/quicksilver/public_pdfs/epochs.pdf (last access 10/09/06)

[Hop] Hopkinson, K.M.; Giovanini, R.; Wang, X.; Birman, K.P.; Coury, D.V.;Thorp, J.S., EPOCHS: A Platform for Agent-Based Electric Power and Communication Simulation Built for Commercial OFF-The-Shelf Components, submitted to IEEE Transactions on Power Systems. http://www.cs.cornell.edu/projects/quicksilver/public_pdfs/ieee_template_09_30_05a.pdf (last access on 10/09/06)

11.5.4 CISIA references

[Pan05] S. Panzieri, R. Setola, G. Ulivi: “An approach to model complex interdependent infrastructures,” 16th IFAC World Congress, Praha, Czech Republic, 2005.

[Pan04] S. Panzieri, R. Setola, G. Ulivi: “An agent based simulator for critical interdependent infrastructures,” 2nd Int. Conf. on Critical Infrastructures, October 25-27, Grenoble, France, 2004.

11.6 Mathematical models references

[Cha04] M. Chakrabarty, D. Mendonça, Intregrating Visual and Mathematical Models for the Management of Interdependent Critical Infrastructures, IEEE International Conference on Systems, Man and Cybernetics, 2004.

[Iss06] L. Issacharoff, S. Bologna, V. Rosato, G. Dipoppa, R. Setola, E. Tronci, A Dynamical Model for the Study of Complex Systems’s Interdependance, CNIP’06 (Complex Network & Infrastrucuture Protection, Rome, Italy, March 2006.

[Leo86] Leontief, Wassily W., Input-Output Economics. 2nd ed., New York: Oxford University Press, 1986.

[Pet06] K. Peters, L. Buzna, D. Helbing, Mathematical Modelling of Cascading Failures and Disaster Spreading in Complex Networks, CNIP’06 (Complex Network & Infrastructure Protection, Rome, Italy, March 2006.

[TG] the TouchGraph tool Home Page: www.touchgraph.com (last access on 10/09/06).

http://www.sis.uncc.edu/%7Eanraja/PAPERS/ISI04.pdf

http://www.sis.uncc.edu/%7Eanraja/PAPERS/OCC04.pdf

http://www.cs.cornell.edu/projects/quicksilver/public_pdfs/epochs.pdf

http://www.cs.cornell.edu/projects/quicksilver/public_pdfs/ieee_template_09_30_05a.pdf

http://www.touchgraph.com/

Appendixes

12. Appendixes

12.1 Appendix 1 - Example of NS script

set ns [new Simulator]

$ns color 1 Blue

$ns color 2 Red

set nf [open out.nam w]

$ns namtrace-all $nf

proc finish {}{

global ns nf

$ns flush-trace

close $nf

exec nam out.nam &

exit 0

}

set n0 [$ns node]

set n1 [$ns node]

set n2 [$ns node]

set n3 [$ns node]

$ns duplex-link $n0 $n2 2Mb 10ms DropTail

$ns duplex-link $n1 $n2 2Mb 10ms DropTail

$ns duplex-link $n2 $n3 1.7Mb 20ms DropTail

170

Appendixes

171

$ns queue-limit $n2 $n3 10

set tcp [new Agent/TCP]

$tcp set class_ 2

$ns attach-agent $n0 $tcp

set sink [new Agent/TCPSink]

$ns attach-agent $n3 $sink

$ns connect $tcp $sink

$tcp set fid_ 1

set ftp [new Application/FTP]

$ftp attach-agent $tcp

$ftp set type_ FTP

set udp [new Agent/UDP]

$ns attach-agent $n1 $udp

set null [new Agent/Null]

$ns attach-agent $n3 $null

$ns connect $udp $null

$udp set fid_ 2

set cbr [new Application/Traffic/CBR]

$cbr attach-agent $udp

$cbr set type_ CBR

$cbr set packet_size_ 1000

$cbr set rate_ 1mb

$cbr set random_ false

$ns at 0.1 "$cbr start"

$ns at 1.0 "$ftp start"

$ns at 4.0 "$ftp stop"

$ns at 4.5 "$cbr stop"

$ns at 5.0 "finish"

puts "CBR packet size = [$cbr set packet_size_ ]"

$ns run

Appendixes

172

12.2 Appendix 2 - Explanation of calculation methods for electric power systems

12.2.1 Load flow calculation

Load flow calculation is the program module for analysing and restructuring existing network. Weak point determination is one of the important tasks within network planning. Different algorithms – i.e. Newton-Raphson, current iteration and others - are available for calculating the distribution of currents, voltages and loads in your network, even under difficult circumstances, such as when several infeeds, transformer taps and poor supply voltages are involved

12.2.2 Unbalanced load flow calculations

Unbalanced load flow calculations are enhanced symmetrical load flow calculations. SINCAL‘s Unbalanced Load Flow calculation module calculates the power flow from the generators over lines and transformers to the consumers (loads) in each phase.

12.2.3 Optimised load flow

Optimised load flow minimizes the transmission losses in a given network (target function). The system variables in this case are generator voltages, generator reactive powers and the transformation ratios of the transformers. Limitations are the loading of plant and equipment, the voltage range and the P/Q diagram allowed for the generators. The program employs the Newton-Raphson method of calculating load flow. The results are presented in the same way as ordinary load flow.

12.2.4 Short circuit calculation

Short circuit calculation is the method employed for ascertaining the correct ratings for the network (i.e. the maximum fault currents) and also the correct protection settings (i.e. the minimum fault currents). Single-phase, two-phase and three-phase faults can be calculated for individual nodes or whole sub-networks, i.e. it is possible to ascertain the current distribution in the network in each fault condition. The calculation can be performed either in accordance with the latest issue of the relevant ANSI C37, IEC 61363-1, VDE 0102/IEC 909 standard or while taking a certain load flow into account. Any possible changes to the standard are incorporated directly and smoothly into the calculation process since our experts are participating in standards committee meetings. Different transformer vector groups are also taken into account in the case of asymmetrical faults, as are the various methods of neutral earthing employed. The current-carrying capacity of busbars and cables (1-second current) can be checked, too. Although, in the ascertaining of the correct ratings for networks, the method of calculation based on relevant standards is the most popular, the load flow superposition method is actually better for determining minimum fault currents. This is especially the case when the fault current is of the same order of magnitude as the load current. The key values in the standard for assessing the fault characteristics (such as Ik“, ip, Ia, Sk“, Uo, Z0/Z1, etc. as well as cumulative values) are – like all result data – stored in the database where they are available for further calculations. The

Appendixes

173

calculation reports include fault location-based tables with all contributions and branches viewed together with summaries of results.

12.2.5 Optimum sectionalising points

In meshed networks, this method can be used for calculating the positions of the optimum sectionalising points and for transferring them to the network configuration at the press of a button. It allows the network to be broken down into a simple radial network with minimum transmission losses. With the help of load flow calculation, the point of minimum voltage is determined in a program loop and the feeder of minimum current isolated at that point. This is continued until the whole network is unmeshed. Naturally, any topological changes are taken into account at each new calculation of load flow. This method is also especially good for pinpointing the correct sectionalising points between the different transformer ranges.

• Determination of the radial network structure with lowest losses • Working across network levels • Defining network groups, which should open, and which should not. • Automatically transfer and application of open points/switches • Marking of all open points in the network diagram

12.2.6 Rating of low voltage networks

Rating of low voltage networks i.e. checking the tripping conditions, is a combination of load flow calculation and short- circuit calculation. In accordance with the VDE 0102 standard, the program utilizes the minimum single-phase fault currents to determine the maximum permitted rated current of the appropriate fuse. For this purpose the protected zone under investigation is examined with help of a traveling fault to find the point where the minimum fault currents flow through the adjoining fuses. A protected zone can be limited by up to three protection devices. SINCAL identifies the existing fuses whose rated current exceeds the maximum permitted value. A situation where the load current exceeds the maximum permitted current of the fuse is also flagged out.

12.2.7 Multiple/general faults

When faults and interruptions occur in several places simultaneously, e.g. in the not-so-rare case of a double earth fault, the multiple fault calculation determines the steady-state distribution of current and voltage in the network. The actual switching configuration is taken into account as well as the load flow. Potential bus bar faults are: Single-phase fault, Two-phase fault with/without earth, Three-phase fault with/without earth The following interruptions and faults are possible on conductors: Single-phase, two-phase and three- phase interruption; Single-phase interruption and single-phase earth fault; Two-phase interruption and two-phase earth fault; Three-phase interruption and single-phase or three-phase earth fault; Two-phase interruption and two-phase fault; Three-phase interruption and two-phase or three-phase fault. The general fault analysis is based on a complete 3-phase system representation (symmetrical components). All specified faults can be combined to different “calculation cases” which can be calculated simultaneously. Results can be shown case by case in the network diagram, reports or data base masks.

Appendixes

174

12.2.8 Stability (RMS)

The Stability method is available for providing the answer to the question of whether or not the generators can continue in stable operation in the network in the case of faults or interruptions.

12.2.9 Electromagnetic transients (EMT)

SINCAL Stability is used for investigations in which the envelope curves of the characteristic values are sufficient as results. If the 3-phase reel waveform is needed then PSS/SINCAL’s Electromagnetic Transients module is needed. PSS/SINCAL’s Electromagnetic Transients module allows networks, machines (park 7th order) and controllers to be modelled by means of differential equations. Symmetrical systems are entered single-phasely and completed to three-phase systems internally. Asymmetrical systems can be accommodated by means of elements in the individual phases. This is also possible for any kind of DC system. Special equipment (e.g. load model, FACTS elements, controls, etc.) can be defined by the user by means BOSL (Block Orientated Simulation Language). Therefore, the EMT module can provide a complete solution of all electromechanical (RMS) and electromagnetic (EMT) phenomena, including asymmetrical and non-linear events. The main field of use is in the design of equipment and apparatus while taking transient phenomena into account. For instance, typical applications are wind park integration studies, investigations of dynamics of industrial networks and studies of HCDC and FACTS plants. The results are depicted in diagrams and can be analysed with the evaluation tool SIGRA or comtrade viewers.

12.2.10 Eigenvalue/modal analysis

In addition to the facility for simulation in the time domain, SINCAL also permits the study of networks, machines, shafts and control systems in the frequency domain, as well as allowing the elements of control systems to be analysed and the system behaviour to be optimised. In large-scale electrical systems the relationships between generators, networks and control systems are becoming ever more complex. FACTS elements are used for the fast active control of transmission systems and for filtering purposes in distribution systems. The analysis of such complex interaction between systems and equipment needs modern methods that are able to describe the behaviour of the whole system both simply and clearly. SINCAL uses the analysis of system eigenvalues for this purpose. Compared with traditional methods of simulation, this method provides more information about the behaviour of the system regarding damping, frequency response, observability, controllability and the effects of system state. Specific areas of application for eigenvalue analysis are inter-system oscillation, voltage stability, modelling of dynamic equivalents, controller design, subsynchronous resonance and harmonics effects.

12.2.11 Harmonics

The harmonics module is used for calculating the distribution of harmonics in electrical networks as well as for calculating frequency response. The calculated harmonic currents and voltages in the network can be evaluated by several different methods such as, for example TIF, THFF or EDC. In addition to the graphical output of frequency responses for the required nodes, the network impedances are also shown in the complex plane and the harmonics level for all nodes and network levels with the appropriate limit values. The input data must be supplemented with the frequency relationship of the network elements, for the purpose of which there are three

Appendixes

175

different methods available. The transmission lines are simulated with wave equations. Simulation of a resonance network is possible with very convenient inputs. Current and voltage infeeds are also allowed for odd-number harmonics anywhere in the network. A variety of different filters are offered.

12.2.12 Ripple control

The ripple control module calculates the ripple control level and the distribution of the ripple-control currents in the electrical network for serial and parallel signal inputs. The frequency relationship of the elements can be entered for this method, too.

12.2.13 Reactive power optimisation

The optimised utilization of reactive power has a positive effect on network operation. Typical advantages are:

• Reduction in transported apparent power • Reduction in loading level of network components • Reduction in transportation losses • Improved voltage profile • Voltage limit violation can be avoided • Upgrade of transformer stations can be delayed or avoided • Cost of reactive power consumption can be reduced

A series of load flow calculations for the entire network determines the required reactive power. In each individual load flow calculation, a fraction of the reactive power requirement at the transformers is compensated. The reactive power requirement can be inductive or capacitive. The calculation of the reactive power requirement is carried out for selected network levels. In the graphical network diagram, a compensator symbol (i.e. reactor or capacitor symbol) is depicted at the terminal of the lower voltage side of the transformer where reactive power is required. All relevant results such as the required reactive power, reduction in losses, etc. can be displayed.

12.2.14 Line constants

The line constants calculation module is capable of determining characteristic parameters of overhead lines and underground cables. The line parameters required for network analysis - i.e. load flow, short-circuits, interferences and other studies - can be calculated based on geometrical configuration (i.e. tower or trench structure), overhead line or cable type. Following systems can be calculated: One-phase systems with ground return conductor, two-phase systems (AC systems, e.g. railway systems), and three-phase systems. The enhanced line parameter calculation module is capable of calculating cable interference.

12.2.15 Protection simulation modules

If a misuse has occurred and needs to be understood (“post mortem analysis”) or if you want to evaluate – hypothetical - fault conditions then a stepped event analysis is the best solution.

Appendixes

176

SINCAL’s interactive protection simulation is one of the most powerful tools in the industry for evaluating protection system response from the time a fault occurs until it is cleared – time step by time step. Every time a relay is tripping the system stops and the engineer can analyse the conditions of all relays in masks, diagrams and reports and adapt the relay settings according to the demands. At any time the user can continue the simulation until the fault is cleared and a total fault clearance time is calculated. Protection devices are:

• Overcurrent time protection such as Fuses, Bimetallic relays, Contactors, Miniature circuit breaker, Low voltage circuit breaker, Definite time relays, British Standard behaviour, all types of circuit-breaker with instrument-transformer and free user defined relays with predefined block structures

• Distance protection such as many predefined relays from different manufacturers are available which model the behaviour of the selected distance relay. Different starting characteristics can be modelled. MHO and polygonal characteristics can be entered. The user can define starting and tripping characteristics (composed of lines and circles)

• Differential relays for reliability studies.

In general, differential protection is used as main protection with fast operating times. Other protection devices provide backup. The determination of the settings of backup protection devices is the main objective of the protection coordination.

The distance protection method calculates the impedance settings for the three zones and the overreach zones (autoreclosure and signal comparison) of distance protection relays in any type of meshed network. When grading impedances are being calculated, the setting given priority is the one that causes the protection to respond selectively regardless of how the network is connected. Initially, all values are calculated for the first zones and this is followed by all second zones and then all third zones. The second and third zone of the relays can be altered during or after calculation of the settings while working interactively from the screen, so it is a simple matter to accommodate the protection engineer’s ideas. There are various ways of taking into account the time grading of the third zone. The results of the program are provided in time grading diagrams drawn to scale and a table of settings for each protection device.

Overcurrent time protection simulates the time sequence of the fault clearance in radial and meshed networks. This unique feature is called stepped event analysis. For this purpose, there is a database of protection devices storing approximately 1000 circuit breakers with instrument-transformers, low-voltage circuit breakers, fuses, bimetallic relays, contactors and miniature circuit breakers together with all possible settings. The combination with distance protection relays is no problem. The locations of faults to be examined can be defined at nodes or anywhere on any power lines or cables. Either single-phase, two-phase or three-phase faults can be simulated, arc impedances included. Starting and triggering of protection devices are simulated in as many time steps as necessary. The operating state of the protection devices can be visualised in the network diagram by color-code. Any violations of the grading times are also indicated, as is multiple tripping of protection devices. Directional elements can be freely defined. Damage curves for cables and transformer loadings are also displayed in graphical form. The system generates grading diagrams for IP2Pt, RX, and Zt-functionality. The fields of application are the checking of thermal loads and incorrect tripping in normal operation, the determining of disconnection times, the co-ordination of protection and the checking of grading times

The enhanced protection simulation considers overcurrent and distance protection devices.

Appendixes

177

12.2.16 Motor start

The Motor Start module is an effective tool for the calculation of the operational behaviour of the electrical network. It provides answers to questions such as: Will the motor start successfully considering the given load torque; How large is the voltage dip during the motor start; What are the operation point of the motors; How long is the start up time: What is the network loading during the motor start.

With this method, the demand of power during the motor start with inclusion of the voltage at the motor terminal can be calculated. This is a dynamic process, which will be solved by the method of homogenous time steps. For this, a calculation loop over a period of time is defined; and load flow and motor power are determined. Non-linear saturation and star-delta-switching is available. Any number of motors can be started at different times. Within SINCAL the user can define the functions motor torque, load torque and current as a function of speed in diagrams with quick response to the input data.

12.2.17 Load profile

The load profile calculation is a special form of load flow calculation – in steps of a quarter of an hour for a full day – with loads varying with time. For this task, besides the normal nominal power, loads have assigned information on the specific type of consumer with a daily load profile (absolute values or percentage). Optionally, the user can define customer data like annual consumption, subscription rights or maximum power. The power of each load can be calculated based on the given parameters and functions together with load profile (type or absolute value) and customer data. If you want to calculate with the actual power - taking into consideration the simultaneity factor – this is easily done, too. The simultaneity factor can be a function of number of consumers at a node/branch. For this dependency, the user can also define several types. When working with this kind of consumer behaviour, the calculation no longer can calculate with static impedances for the network in dependency of the location of the consumers. As results all load flow calculations are available including the analysis of maximum or minimum values (e.g. for voltages and loading etc.). Diagrams with daily profiles for nodes and branches exist. Limit violations during the whole day are also prepared in diagrams. The total lost energy in kWh per day of the feeding transformer is presented in a diagram

12.2.18 Load development

The load development module provides information on how to develop electric networks taking into account future load growth and migration scenarios. Load forecast has to provide the input data. SINCAL Load Development calculations are enhanced load flow calculations with load and generation levels that vary over time. These calculations are done annually for a specific period of time. In addition to nominal values, SINCAL assigns load increases/decreases to nodes and considers commissioning and decommissioning dates for network components. Load changes can be assigned according to graphic functions or network element groups, or they can be assigned to specific consumers. The entire load flow calculation results with evaluation of minimum and maximum values (e.g. voltages or loading levels) and diagrams with information on power requirements and overloaded lines are provided. Additional information is provided if limits have been exceeded during the calculation period. The Load Development tool can provide valuable information for the future development of networks.

Appendixes

178

12.2.19 Contingency analysis

The purpose of the Contingency Analysis is to assess the load flow in networks during outages of network components and generators. It provides information on security of supply and weak points in the network. The network operator obtains important information on following issues:

• n - 1 criteria compliance • risk of supply interruptions • overload conditions due to network component outages • unfeasible network conditions as a result of network component outages • priorities of network development measures • form of contractual agreements with consumers

Contingency Analysis comprises a series of load flow calculations. One or more elements are considered on outage in each individual load flow calculation. SINCAL can simulate the outage of a single network component, a group of components (that have to be operative as a group) and overloaded components. Conditional and unconditional outages as well as base and resulting outages can be modelled. All relevant results (minimum and maximum values, unsupplied consumers, overloads, etc.) are recorded. The results can be summarised in a clearly arranged tree structure. For large networks, the evaluation can be limited to the main characteristics in order to be able to deal with large amounts of data and to achieve short calculation times. All typical load flow results can be provided if more detailed results are required for the analysis of critical cases.

12.2.20 Reliability

A number of different criteria are used in the network planning process to assess the reliability of power supplies. There is a differentiation, for example, between failure and customer-orientated planning criteria and between deterministic and probabilistic criteria. A failure-orientated reliability criterion - such as the (n-1) criterion, for example - filters out those failures whose effects are unacceptable. Only one fault is assessed each time. Customer-orientated planning criteria summate all fault-related interruptions in the power supply to the customer. Probabilistic reliability calculations are employed for determining the values for individual customers. These characteristic values can then be compared against limit values for specific customers. For a long time deterministic reliability criteria were used exclusively for assessing adequate reliability of a power supply at the planning stage of a network. The task of the planner was to select a limited number of system states and fault scenarios and then to examine them for adherence to the requirements specified by the criterion. The probabilistic reliability calculation makes special demands on the database. In addition to the electrical and topographical data for load flow and short circuit calculations, additional information is needed for setting the boundaries of the network to be examined, and its component parts, for network protection and for simulating the conduct of the fault. When analysing reliability it is usually necessary to subdivide large energy distribution networks into smaller sub-systems. The bounding of the system arises from the task to be examined. Within the system being examined there are further boundaries. All individual items of equipment whose malfunctioning has the same effects on the energy supply network are combined to form component units. This subdivision is especially important with regard to the degree of detail and the cost of computing. The bounding of components, from which the inception of a fault and the intervention of the system protection can be simulated, is obtained by grouping together items of equipment that are all tripped by the primary protection when a fault occurs. Overhead power lines, cables, transformers and busbars usually comprise this tripping

Appendixes

179

range-orientated component bounding; the outgoing-feeder and busbar-side parts of the switching panels are assigned to the corresponding component parts. Failure models have been developed from analyses of the operation of real networks and from fault statistics that allow the course of events of faults to be classified. The most important models are:

Independent single failure: failure of one single component

• Common-mode failure: simultaneous failure of several components due to a common cause

• Multiple earth fault with multiple tripping: interdependent failure of two components in networks with resonant earthing or with an isolated neutral on the basis of an existing earth fault

• Failure during maintenance of the backup component: interdependent failure during maintenance of the backup component

• Over-functioning of protection device: stochastic secondary failure due to non-selective tripping of the protection system

• Malfunction of protection device: stochastic secondary failure due to failure of the primary protection device and tripping of the backup protection device

The analytic method combinatorially generates all failure combinations. Only those combinations having a probability above a given threshold value are further regarded in the calculation. Another possibility to limit the number of the combinations to be regarded in the calculation is the limitation of the order, i. e. the number of simultaneously failed elements, of the combinations. Probabilistic reliability calculation allows quantitative description of supply reliability through appropriate characteristic indices. In the field of reliability calculation there exists internationally a multitude of different indices being more or less meaningful and widespread. However, certain basic indices have proved to be valuable, and from those basic indices further sizes can be calculated on demand.

12.2.21 Cost calculation

Cost calculation assesses the cost of network planning measures by means of the present value method that is commonly used in the electricity industry. The cost of alternative projects can be easily compared using the present value method and PSS/SINCAL’s variant management tool. The result of the cost evaluation is important for determining the priority of network expansion projects.

Appendixes

12.3 Appendix 3 - Further PSS family

Siemens network simulation software PSS is especially for transmission networks in a worldwide market.

12.3.1 PSS™E (PSS/E)

12.3.1.1 General description

Since its introduction in 1976, the Power System Simulator for Engineering (PSS/E) tool has become the most comprehensive, technically advanced, and widely used commercial program of its type. It is widely recognized as the most fully featured, time-tested and best performing commercial transmission planning program available, providing users with power flow, short circuit, dynamic simulation (including long term), and optimal power flow. This is the de facto standard power system analysis tool used in over 105 countries and by 10,000+ users in more than 700 different organisations worldwide. Thus, PSS/E has been used to study a variety of networks. Its algorithms are well tested, flexible, and robust.

It provides full graphical visualisation of infrastructures (Figure 67).

or

Figure 67: Graphical visualisation of infrastructures

PSS™E provides users with power flow, short circuit, dynamic simulation (including long term), optimal power flow, linear network, and small signal analysis. The program employs the latest computer technology and numerical algorithms to efficiently solve networks large and small. PSS/E includes modelling for advanced technologies, such as the application of FACTS devices and Voltage Source Converter HVDC Light systems. The program allows for a variety of analyses. When many cases must be analysed quickly, DC load flow capability is provided. Dynamic modelling for PSS/E includes highly detailed governor models, allowing most standard boiler control strategies and very detailed HVDC models, which apply to specific installations.

12.3.1.2 Integrated, easy-to- use features

The PSS/E program package has a modern, easy-to-use, Microsoft® Foundation Class (MFC), graphical user interface (GUI). The GUI contains command recording capability to aid the user in building macros, which can be used to automate repetitive calculations. PSS/E has been used in production mode on the largest network size models being simulated. Common reports in

180

Appendixes

181

pleasant, readable formats are standard. Most data can be entered and modified via the one-line diagram.

12.3.1.3 Python scripting

PSS/E Version 30 introduced the Python scripting language for program automation processing. Python is an interpreted, interactive, object-oriented programming language. It is widely used and is often compared to Tcl, Perl, Scheme or Java. Python combines remarkable power with very clear syntax. It has modules, classes, exceptions, very high-level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems (X1, Motif, Tk, Mac, MFC). New built-in modules are easily written in C or C++.

Python is also usable as an extension language for applications that need a programmable interface. The Python implementation is portable. It runs on many brands of UNIX, Windows, OS/2, Mac, Amiga, and many other platforms. The Python implementation is copyrighted but freely usable and distributable, even for commercial use.

12.3.1.4 User-Written Models

PSS/E was the first commercially available program to accommodate user-written dynamic models. This capability is constantly being improved to accommodate the wide variety of equipment that Siemens PTI engineers encounter in their worldwide consulting and the rapid technology changes that users are experiencing.

The Siemens PTI approach offers the following features:

• No restriction on modelling complexity • Highly efficient resultant model for use in production environment

12.3.1.5 MATLAB-Simulink ® PSS/E Interface

A new MATLAB Simulink PSS/E Interface is a standard feature of PSS/E Version 30 for those users licensed for Dynamics. This interface provides a mechanism for PSS/E and the MATLAB Simulink model to communicate and exchange data. At PSS/E-30 users will be able to create MATLAB models of AVR and Governors and interface it directly with PSS/E. In effect, instead of having to write code (in FLECS or Fortran as is traditionally done in PSS/E) for user models of AVR and Governor one would be able to wire-up the model in MATLAB Simulink.

12.3.1.6 Optimal Power Flow (OPF)

In this era of competition, this efficient tool is a necessity to minimize costs of operating the system. The OPF provided with PSS/E solves the full power flow equation coupling problem to handle active and reactive power flows. It has been designed to assist users in quickly defining and solving the most complex power system optimisation problems. Besides having an easy-to-use GUI and being well integrated into PSS/E, it can be used in the following applications:

• Voltage limited transfer analysis, Voltage collapse analysis • Reactive power margins and scheduling • Transfer capability investigation • Location-based marginal cost assessment • Ancillary service opportunity cost assessment • Impact assessment base case development

Appendixes

182

PSS/E OPF improves the efficiency and throughput of power system performance studies by adding intelligence to the load flow solution process. Whereas the conventional load flow relies on an engineer to systematically investigate a variety of solutions before arriving at a satisfactorily "good" solution, PSS/E OPF directly changes controls to quickly determine the best solution. From virtually any reasonable starting point, you are assured that a unique and globally optimal solution will be attained; one which simultaneously satisfies system limits and minimizes costs or maximizes performance.

PSS/E OPF provides all of the most commonly desired objective functions, including: • Minimize fuel costs • Minimize active power slack generation • Minimize reactive power slack generation • Minimize active power loss • Minimize reactive power loss • Minimize adjustable branch reactance • Minimize adjustable bus shunts • Minimize adjustable bus loads • Minimize interface flows • Maximize interface active power transfer

12.3.1.7 PSS™E Balanced or Unbalanced Fault Analysis

The PSS™E Fault Analysis (short circuit) program is fully integrated with the power flow program. The system model includes exact treatment of transformer phase shift, and the actual voltage profile from the solved power flow case.

Operation Modes:• Three-phase and phase-to-ground faults are shown on power flow single line diagrams

• Simultaneous complex events at multiple buses or transmission points

• Automatic sequencing of three-phase and phase-to-ground solutions including line-out and line-end faults throughout a specified subsystem for each fault

12.3.1.8 PSS™E Dynamic Simulation

PSS™E offers users uncompromising dynamic simulation capabilities.

Operation Principles: • Interrupt and restart the simulation at any time • Interactive or "batch" mode available through simple English language commands • Any disturbance allowed, such as faults, generator tripping, motor starting, loss of field

Simulation Setup: • Computation of response ratio and open circuit transient response of excitation systems.

(This and similar tests on turbine governors are used to check or estimate data.) • Synchronous and induction machine parameter estimation

Models:

Appendixes

183

• Extensive library of generator, exciter, governor, and stabilizer models • Detailed load, static var, and multi-terminal HVDC models • Underfrequency, distance, overcurrent, and other relay models • Frequency dependence effects on models and network parameters • User-defined models of any control process without penalty in program execution time

Output: • Any system quantities may be monitored, plotted, or compared • Plotting software includes arithmetic or advanced analysis of simulation results

12.3.1.9 PSS™E Extended Term Dynamic Simulation

PSS™E extended term simulation allows users to study longer term effects, such as frequency deviations as affected by prime mover response and voltage changes caused by protective equipment, and yet minimize computer time by providing a variable time-step integration technique.

12.3.2 PSS™MUST - On-line tap and phase-shifting transformer models

The capability to move power from one part of the transmission grid to another is a key commercial and technical concern in the restructured electric utility environment. Engineers determine transmission transfer capability by simulating network conditions with equipment outages during changing network conditions. Simulation tools calculate the first contingency incremental transfer capability (FCITC). FCITC is adjusted for uncertainties and posted as the ATC and TTC. The purpose of the PSS™MUST (Power System Simulator for Managing and Utilizing System Transmission) software is to efficiently calculate:

• Transaction impacts on transmission areas, interfaces, monitored elements or flowgates. • Generation redispatch factors for relieving overloads. • Incremental transmission capability (FCITC). FCITC variations with respect to network

changes, transactions, and generation dispatch.

PSS™MUST complements PSS™E data handling and analysis functions with the most advanced linear power flow and user interface available. PSS™MUST speed, ease-of-use, and versatile EXCEL interface simplifies and reduces data setup time, and improves results display and understanding.

12.3.3 PSS™TPLAN

PSS™TPLAN is an integrated, stand-alone computer software package for transmission reliability assessment. It is comprised of a variety of state-of-the-art analytical formulations – mathematically optimised solutions and simulations of system response – presented in an intuitive interface. The interface lets you build up your analysis – from a basic focus on deterministic reliability, onto probabilistic risk assessment and further on to cost-effectiveness.

Appendixes

184

12.3.4 PSS™Engines

PSS/Engines (Embeddable Distribution Network Analysis for DMS and GIS Systems) is a unique suite of network simulation libraries, which helps users meet the fast-paced, wide-ranging challenges posed by today’s electric power industry.

Applications typically include embedding by GIS vendors such as Intergraph and GE Network Solutions as well as Distribution Management Systems from suppliers like LogicaCMG & Soluziona.

12.3.5 PSS™ADEPT

PSS™ADEPT (Power System Simulation for Advanced Distribution Engineering Productivity Tool) is an integrated interactive program for simulating, analysing and optimising performance of balanced and unbalanced distribution systems. PSS™ADEPT makes available a comprehensive analysis tool that includes the following analysis capabilities:

• Modern Graphic User Interface • Comprehensive electrical modelling • Unbalanced loop and radial network modelling with no limits • Load flow, Short Circuit and Motor Starting • Load Scaling • Protection and Coordination • Harmonic Distortion Analysis • System Reliability • Capacitor Placement Optimisation • Tie Open Point Optimisation

12.3.6 PSS™ODMS

The Power System Simulator for Operations and (CIM) Database Maintenance System (PSS™ODMS) provides an easy-to-use interface that allows system modellers to exchange bus-breaker models quickly and easily between diverse EMS systems. PSS™ODMS converts operations information into the EPRI Common Information Model (CIM) in an open ODBC environment. The optional Viewer/ Editor provides graphical editing of the CIM compliant database. The Viewer/Editor has the capability to dynamically generate fully interactive substation-level and “World View” one-line diagrams from the network topology data alone, providing an instantaneous graphical view of any part of the network. It is also available via EMS suppliers who have OEM agreements with Siemens PTI, such as Advanced Control Systems (ACS) of Atlanta.

12.3.7 MOD™

MOD (Model On Demand) extends the capabilities of the System Simulator for Operations and (CIM) Database Maintenance System (PSS™ODMS) product line. The user can manage a great number of change cases for PSS™E. MOD assembles sets of model changes into “queues”. Queues can then be managed and organised in various fashions depending on the needs of the PSS™E user. Queues are coupled with MOD seasonal and annual profiles to provide the

Appendixes

185

PSS™E user with a procedure for organising and re-organising system investigations. All this without the need for generating a great number of PSS™E base cases, or repeatedly rerunning PSS™E cases when planning sequences change. MOD eliminates the traditional time-consuming generation interconnection study process where one case depends on solving one or more prior case(s) in sequence. Previous sequential dependency, where the planner is required to rerun a number of cases to establish a new case sequence, is a thing of the past. With MOD, the planner is freed to study the ever-changing world!

12.3.8 PSS™LMP

PSS/LMP (Power System Simulator for Location Marginal Pricing) is a tool to help you understand electricity markets and predict their behaviour. PSS/LMP performs a chronological simulation of power markets based on locational marginal pricing (LMP). Given economic and network information, it simulates the operation of a market while respecting critical security constraints, thanks to the power of the built-in security constrained unit commitment (SCUC). Power prices (LMPs) and unit commitment and dispatch levels are among the many outputs. PSS/LMP can be used for strategic planning, price forecasting, asset valuation (physical and financial), and market validation. The graphical user interface (GUI) allows the user to edit data and view results. Model changing is easy because the economic data is kept in a common database format while network data is in the industry-standard PSS/E format. To ease the pain of model development, customizable prebuilt models are available for select regions.

For convenience and flexibility, results are stored to a database as well. When technical accuracy and ease of use are important, PSS™LMP is the market simulator to choose.

Appendixes

186

12.4 Appendix 4 - EPOCHS Experiments

This section describes a case in detail where EPOCHS has been used to demonstrate the benefits and drawbacks in using communication in an agent-based special protection system. A brief overview of a backup protection system, using PSCAD/EMTDC and NS2, is also provided. An additional test case for EPOCHS, using PSLF, and NS2, monitors power systems to prevent blackouts caused by voltage collapse. These experiments point towards a future where tests can be performed to find problems before systems are deployed.

It must be emphasized that EPOCHS allows user to test either electric power protection and control schemes using the PSCAD/EMTDC electromagnetic simulator in conjunction with the NS2 network simulator or in electromechanical simulations using PSLF in conjunction with NS2. EPOCHS has never been used with PSLF, PSCAD/EMTDC, and NS2 simultaneously. The vastly different timescales involved in electromagnetic and electromechanical simulations make their combination difficult if not impossible to model properly.

12.4.1 Backup Protection Case

Relay misoperations, such as incorrectly tripping a healthy line or the failure to isolate a faulted line, are involved in major disturbances in the power system. Zone 3 backup relays are required to clear a fault when the primary relay fails. Backup protection systems have many challenges to overcome. First, the region they isolate is often larger than it need be. Second, they traditionally act without the use of explicit communication. The need for small isolated regions imposes long lag times for zone 3 relays, which are one of the major causes of power system instability. This section outlines a backup protection system that improves on traditional systems using explicit network-based communication.

A new agent-based design for zone 3 backup protection relays has been created to improve on traditional relays. The agent-based relays are able to use communication to send their relay status information, breaker trip signal events, and local measurements when a primary protection event occurs.

The agent-based protection system has many benefits over traditional systems. Zone 3 relays can be monitored to allow corrections to prevent false breaker trips. These corrections have the potential to greatly reduce the number of incorrect trips in cases where there is a heavy load. In addition, in the case of both primary and local backup relay failure, the agent can locate the faulted line using notification messages and can send a trip signal to potentially only clear the faulted line. Traditional backup systems clear such faults using remote backup relays with a bigger isolated region and with a greater delay time. If an incorrect primary relay trip is found by the agent then a block signal can be sent to stop an unwarranted breaker trip. Breaker failure protection trips all breakers connected in the same bus in most bus arrangements and induces a big disturbance leading to poor overall reliability. The reliability gains can be significant in those cases. As an example, Figure 68 shows a 400 kV power system. Figure 69 shows the result of a primary relay misoperation. Traditional relays do not explicitly communicate and Figure 69 (a) and (b) show that the primary relay misoperation occurs when they are used. Agents are able to coordinate their actions to detect and stop an incorrect breaker signal, as shown on Figure 69 (c) and (d).

The backup protection example demonstrates EPOCHS’ utility in simulating electromagnetic cases that depend on communication using PSCAD/EMTDC with NS2. Figure 69 illustrates the

Appendixes

potential benefit of coordinating backup protection through communication. The SPS example in the next section is an electromechanical case using PSLF with NS2.

Figure 68: Fig. 5. A 400 kV power system with an agent-based backup protection system.

Figure 69: (a) A primary relay misoperates at time 0.2 by setting a trip signal. (b) A traditional backup protection system would allow the breaker to trip, cutting power across the line. (c) The agent-based protection system communicates with its neighbours and determines that the trip signal should be blocked. (d) The agent-based system blocks the false trip signal.

12.4.2 SPS Case Overview

Power system instability usually involves large areas and results in dire consequences. Loss of generator synchronism for a single or group of generators with respect to another group of generators is a transient instability, which can result in costly power blackouts. Stability problems typically involve disturbances such as the loss of generation, loads, or tie lines. These disturbances stimulate power system electromechanical dynamics. The system response typically includes deviations in frequencies, voltages, and generator phase angles. Special Protection Schemes (SPS) are mechanisms generally designed to counteract power system instability. The most common SPS schemes employ generation rejection and load shedding, according to a report on SPSs throughout the world.

The SPS in this section is designed to react to a severe fault in a major EHV transmission line in the case where another outage has already taken place in the same corridor. The goal is to prevent instability and preserve the system's integrity within a safe operating frequency range. The SPS system employs an algorithm to determine the proper amount of load to shed in order to hold the system's frequency above a preset level based on wide area measurements. This SPS is designed for wide-area protection and acts in a system-oriented manner.

187

Appendixes

188

The SPS requires synchronized information periodically sampled across the system and is heavily dependent on an underlying communication infrastructure. The wide-area protection system’s reliance on communication requires a simulation system that incorporates detailed models of both network communication and electric power systems. EPOCHS is the only platform that provides these combined capabilities. The proposed SPS system has been tested with a modified version of the IEEE 50 generator test case. The results show promise for the use of SPS schemes like the one described here in the future. The SPS experiments also demonstrate the utility of EPOCHS in evaluating electromechanical systems that make use of network communication.

12.4.3 An Algorithm to Estimate a System's Disturbance Size

This section describes an algorithm, which estimates a disturbance's size when confronted with electromechanical dynamics during an emergency. The method allows one to compute the steady state frequency after a disturbance and the amount of load shedding required to maintain a preset frequency level taking the effect of generator governors into account. Experiments described in section 12.4.3 and results presented in section 12.4.4 demonstrate the viability of this technique in a realistic test environment within EPOCHS.

The goal of the proposed SPS is to shed enough load to keep the system’s frequency above a preset level following a generation loss. The key to doing so is to determine the precise generation shortfall when a disturbance occurs. The system shortfall can be calculated with the following formula.

Pd = Pa + ΔPe (ω0+ - ω0-, u0+ - u0-) (1)

Formula 1 shows that the size of the disturbance, Pd , is equal to the system accelerating power, Pa , which is proportionate to the change in the system's frequency, plus the change in electrical power demand Pe due to the variation in frequency and voltage. Pd is the key to determining the amount of generation that has been lost. It is important to note that - O and + O respectively denote the time immediately before and after the disturbance. Pa and Pe can both be obtained based on wide area measurements using the generators' operating status and samples of the system's frequency before and after the disturbance, but measurements must be simultaneously taken at points throughout the region. Data points must be sent to the SPS from the region's generators and key loads, and action must be taken, within a half second to be effective. The expense and requirements involved in deploying the SPS scheme make it critical that the system is thoroughly tested so that its operations are fully understood before deployment. These factors make the SPS system an excellent candidate for evaluation in EPOCHS.

12.4.4 The System Studied and Agent-Based SPS Scheme

12.4.4.1 The System Studied

Experimental simulations make use of IEEE's 145-bus 50-generator system. The 50-generator test case has a large share of the generation concentrated in the northeast and high load in the southwest of the system.

The IEEE 145-bus 50-generator test case has been modified so that it is more representative of power systems that require SPS protection. The six machines located at buses 93, 104, 105, 106, 110, and 111 are represented with two-axis machine models equipped with IEEE type AC4

Appendixes

189

exciters. The other generators are represented by classical machine models. All generators are equipped with basic steam turbines and employ governors with a 5% droop setting. System analysis has been performed after the governors have responded, but before new load reference set points are established by the AGC subsystem. The system has been modified by adding a 500 kVline from bus 1 to bus 25. The added line increased the number of system branches from 453 to 454. The intent is to create a case that requires the use of a SPS in order maintain system stability. Power systems can generally sustain the loss of a single tie line, but require action with the loss of a second if the line is not cleared quickly enough. Next, the total system capacity has been reduced to 30,050.00 MW. This lower system capacity makes the 4,277 MW power flow along the main 500 kV transmission corridor much more important than it is in the original system. The changes mentioned above caused the admittance load to be abnormally high. The 145-bus IEEE system has been rebalanced to correct the problem by setting the percentage of admittance load to 5.02%. The remaining 94.98% of the system's load has been set as constant active and reactive power.

12.4.4.2 Description of the SPS Architecture

The proposed SPS is required to act rapidly and reliably to electromechanical instability. The communication requirements are different from that of traditional SCADA systems due to the need for fast information updates and rapid response to commands dictating generation rejection and load shedding. The agents are separated into three types: the main SPS agent, generator agents, and load agents. In the IEEE 50-generator example, the main SPS agent is located at bus 1, a 500 kV substation. The main agent identifies extreme contingencies such as the loss of two lines and performs both generation rejection with preset units and load shedding based on real-time measurements.

The generators that can be rejected are selected based on simulation studies. The main SPS agent communicates with generation and load agents to gather data values including generators' connection status, active power outputs, angular frequencies and frequency derivatives. It also communicates with agents located at major system or load buses to collect voltage and frequency measurements as well as the load available for shedding.

Generator agents are located at power plants where they send their measurements to the main SPS agent upon request. Generator agents also reject generation when ordered to do so by the main SPS agent. Load agents are mainly located at distribution substations. These agents shed load when ordered to do so by the main SPS agent. They also locally perform underfrequency load shedding (UFLS). UFLS might occur if the frequency reached a threshold value of 57~58.5Hz after a remote load shedding scheme with a preset frequency of 58.8 Hz failed to hold the frequency above 58.5 Hz.

12.4.5 Simulation Results

Initially in the electrical portion of the EPOCHS-based simulation, the 500 kV transmission lines from buses 1 to 6, 1 to 25, and the two lines from 1 to 2 carry respectively 722.2 MW, 1,106.5 MW, and 2x361.1 MW. A trip on the 1-6 line causes the system to operate under stressed conditions. The power in lines 1-25 and 1-2 respectively increase to 1,384MW and 2×515.7 MW. If a three phase fault occurs near bus 1 when line 1-6 has already tripped then the critical fault clearing time to open line 1-25 is around 0.065 seconds.

A communication network was created with a node at each bus and an edge between nodes wherever one or more transmission lines existed. The link delays were set to 0.5 seconds. Each

Appendixes

link's bandwidth was set to 150 Megabits per second so that no packets would be lost due to network congestion. Per-link loss rates were first set to 0% and then the experiment was rerun with a loss rate of 5%. The simulation with 5% link loss rates was performed to get a basic idea of how the SPS system would react to lossy communication. All messages were sent using UDP.

The assumptions made in the communication network configuration helped to validate that the SPS system was operating properly and that the results obtained from EPOCHS were correct. Actual network traffic is delayed due to propagation delays, router queuing delays, and buffering inside the sending and receiving machines. Queuing delays have an inherent dependency on the network congestion levels created by competing traffic, which tends to vary over time. EPOCHS has the ability to model these complexities, but early experiments have modelled traffic simply in order to aid in the validation of EPOCHS and the SPS system studied.

In the SPS experiments, a fault occurs on the 1-25 line at time 0. The fault is cleared at 0.07 seconds, and a trip command is sent to generator 93 at 0.10 seconds. Because the fault is cleared after the critical fault clearing time, the system becomes transiently unstable and one group of 17 generators loses synchronism with another group of 33 generators. Figure 70 shows the rotor angle of a representative sample of generators with respect to the generator at slack bus 145.

The main SPS agent at bus 1 recognizes the situation and begins to communicate with other system agents to gather data values including generators' connection status, active power outputs, and angular. The main agent also issues a generation rejection order to the agent at bus 93. Bus 93 is chosen based on an off-line simulation study. Generation rejection keeps the system stable, as shown on Figure 71 (a), but the frequency drops near 57.5 Hz, as shown on Figure 71 (b).

Figure 70: Rotor angles with transient instability induced by a disturbance

190

Appendixes

a)

b)

Figure 71: (a) The system remains stable after generation rejection. (b) The system undergoes an unacceptable frequency decrease.

The main agent detects the "disturbance" created by generation rejection at bus 93. It begins to estimate the disturbance size and finds it to be -1,862 MW. The main agent calculates that there is 2,090 MW generation remaining and predicts that the steady state system frequency after this disturbance is 57.45 Hz. The predicted frequency value, as shown as on Figure 71 (b), is very close to the simulation results.

Because the preset frequency is 58.8 Hz in the test system, remote load shedding is required. The load shedding amount required to maintain the system frequency above that preset level is estimated to be 886 MW. This total load is shed at buses 14, 25, 27, 63, and 69 with the same percentage allocated to each load. The shed loads are, respectively, 85.97 MW, 293.29 MW, 182.25 MW, 157.16 MW and 167.92 MW.

191

Appendixes

The system's frequency response, as shown on Figure 72, demonstrates the merit of the proposed SPS system.

The SPS experiments also validated the accuracy of EPOCHS. Logs of agent's network communication, electric power requests, and communication sent between EPOCHS' components show that EPOCHS was operating correctly.

Experiments operated as predicted, which also validated the EPOCHS simulation environment. EPOCHS was also helpful to the system developers in illustrating potential problems that had not been anticipated in the SPS system. Fig. 10 shows that the SPS operation with a 5% loss rate per link is different from the one without communication losses. The algorithm used by the SPS agent to determine the amount of load to shed depends on measurements that are simultaneously taken at each of the load and generation agents in the region. Measurements must be taken close to the point of the disturbance to be valid. The likely reason for the differences between the 0% loss rate and 5% loss rate cases is that the information used to calculate the disturbance size and load shedding amount are different for the two cases. If too many communication packets are lost then there can be a large time lag between the beginning of the disturbance and the point where that disturbance was computed. The system frequency will continue to decline after the disturbance has occurred. The SPS algorithm implicitly depends on receiving measurements close to the time of the fault, but no mechanism has been explicitly created to ensure this in the experiments described. The results shown on Figure 72 serve as an illustration of the utility of a simulation platform like EPOCHS, and also demonstrate the negative consequences that hidden flaws can have if realistic simulation facilities are not available.

The experimental results demonstrate the utility of the proposed SPS system. More generally, the experiments validate the EPOCHS platform and illustrate its ability to effectively simulate scenarios involving power protection and control systems based on network communication.

Figure 72: Remote load shedding maintains the frequency above a preset level

192

Appendixes

Figure 73: Comparison of the SPS operation with different levels of loss rate

193

irriis integrated risk reduction of information …integrated project irriis integrated risk...

Documents