List of available and suitable simulation components

Transcription

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
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)
Approval Date
14/09/2006
Remarks
Internal Review
Eric Luiijf (TNO)/ SP1 leader
Approval Date
18/09/2006
Remarks
2
Table of Contents
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
4.1.1.2
4.1.2
4.1.3
SYNTEX as an integrated simulator .............................................................................................. 18
SYNTEX as an overlay for scenario information exchange........................................................... 20
The market platform to share stakeholder data.......................................................................... 21
The global picture ...................................................................................................................... 23
4.2 Scenarios within SYNTEX ............................................................................................................. 24
4.2.1 Scenario generation ................................................................................................................... 24
4.2.1.1
4.2.1.2
4.2.1.3
4.2.1.4
4.2.1.5
4.2.1.6
4.2.1.7
4.2.2
5.
Generality about attack and fault scenarios in SYNTEX ............................................................... 24
Attack and fault trees...................................................................................................................... 25
Textual representation of a Tree..................................................................................................... 27
Generic Fault Tree example ........................................................................................................... 27
Generic Attack Tree example ......................................................................................................... 29
Combination of attack and fault scenarios...................................................................................... 30
Need of a tool for scenario tree editing and execution ................................................................... 32
Scenario description .................................................................................................................. 33
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
3
Table of Contents
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
6.2.2.2
6.2.2.3
6.2.2.4
6.2.3
The NS-2 simulator and the VINT project ................................................................................ 53
6.2.3.1
6.2.3.2
6.2.3.3
6.2.3.4
6.2.4
Description ..................................................................................................................................... 78
Suitability for modelling................................................................................................................. 79
Suitability for simulation................................................................................................................ 79
Conclusion...................................................................................................................................... 80
The Dynamic Network Emulation Backplane Project............................................................... 81
6.2.8.1
6.2.8.2
6.2.8.3
6.2.8.4
6.2.9
Description ..................................................................................................................................... 75
Conclusion...................................................................................................................................... 77
The SSF framework................................................................................................................... 78
6.2.7.1
6.2.7.2
6.2.7.3
6.2.7.4
6.2.8
Description ..................................................................................................................................... 67
Conclusion...................................................................................................................................... 73
The J-Sim simulator................................................................................................................... 75
6.2.6.1
6.2.6.2
6.2.6.3
6.2.6.4
6.2.7
Description ..................................................................................................................................... 60
Conclusion...................................................................................................................................... 66
The OMNeT++ simulator .......................................................................................................... 67
6.2.5.1
6.2.5.2
6.2.5.3
6.2.5.4
6.2.6
Description ..................................................................................................................................... 53
Conclusion...................................................................................................................................... 59
The QualNet Network Simulator............................................................................................... 60
6.2.4.1
6.2.4.2
6.2.4.3
6.2.4.4
6.2.5
Description ..................................................................................................................................... 43
Conclusion...................................................................................................................................... 52
Description ..................................................................................................................................... 81
Conclusion...................................................................................................................................... 83
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
6.3.3.2
6.3.3.3
6.3.3.4
6.3.4
PSSTMSINCAL .......................................................................................................................... 98
6.3.4.1
6.3.4.2
6.3.4.3
6.3.4.4
6.3.5
Description ..................................................................................................................................... 86
Conclusion...................................................................................................................................... 97
Description ..................................................................................................................................... 98
Suitability for modelling............................................................................................................... 100
Suitability for simulation.............................................................................................................. 100
Conclusion.................................................................................................................................... 104
The PowerWorld simulator...................................................................................................... 106
6.3.5.1
6.3.5.2
Description ................................................................................................................................... 106
4
Table of Contents
6.3.5.3
6.3.5.4
6.3.6
The PSCAD/EMTDC Simulator ............................................................................................. 109
6.3.6.1
6.3.6.2
6.3.6.3
6.3.6.4
6.3.7
6.4
Description ................................................................................................................................... 109
Conclusion.................................................................................................................................... 114
The SEPIA simulator............................................................................................................... 115
6.3.7.1
6.3.7.2
6.3.7.3
6.3.7.4
6.3.8
Conclusion.................................................................................................................................... 108
Description ................................................................................................................................... 115
Conclusion.................................................................................................................................... 118
Summary.................................................................................................................................. 119
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
7.2.2.2
7.2.2.3
7.2.2.4
7.2.3
The Electric Power and Communication syncHronizing Simulator (EPOCHS)..................... 127
7.2.3.1
7.2.3.2
7.2.3.3
7.2.3.4
7.2.4
Description ................................................................................................................................... 127
Conclusion.................................................................................................................................... 129
The Critical Infrastructure Simulation by Interdependent Agents (CISIA)............................. 130
7.2.4.1
7.2.4.2
7.2.4.3
7.2.4.4
7.2.5
Description ................................................................................................................................... 123
Conclusion.................................................................................................................................... 126
Description ................................................................................................................................... 130
Conclusion.................................................................................................................................... 133
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.2.1
7.3.2.2
7.3.2.3
7.3.2.4
Description ................................................................................................................................... 136
Conclusion.................................................................................................................................... 137
7.3.3 The mathematical model of the Dresden Technological University, the Zilina University and
the Collegium Budapest ....................................................................................................................... 138
7.3.3.1
7.3.3.2
7.3.3.3
7.3.3.4
7.3.4
Formal verification .................................................................................................................. 140
7.3.4.1
7.3.4.2
7.3.4.3
7.3.4.4
7.3.5
Description ................................................................................................................................... 138
Conclusion.................................................................................................................................... 139
Description ................................................................................................................................... 140
Conclusion.................................................................................................................................... 142
Summary.................................................................................................................................. 142
5
Table of Contents
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
6
Table of Contents
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
12.3.1.2
12.3.1.3
12.3.1.4
12.3.1.5
12.3.1.6
12.3.1.7
12.3.1.8
12.3.1.9
12.3.2
12.3.3
12.3.4
12.3.5
12.3.6
12.3.7
12.3.8
General description....................................................................................................................... 180
Integrated, easy-touse features ................................................................................................... 180
Python scripting............................................................................................................................ 181
User-Written Models .................................................................................................................... 181
MATLAB-Simulink ® PSS/E Interface ....................................................................................... 181
Optimal Power Flow (OPF).......................................................................................................... 181
PSS™E Balanced or Unbalanced Fault Analysis......................................................................... 182
PSS™E Dynamic Simulation ....................................................................................................... 182
PSS™E Extended Term Dynamic Simulation ............................................................................. 183
PSS™MUST - On-line tap and phase-shifting transformer models........................................ 183
PSS™TPLAN.......................................................................................................................... 183
PSS™Engines.......................................................................................................................... 184
PSS™ADEPT.......................................................................................................................... 184
PSS™ODMS ........................................................................................................................... 184
MOD™ .................................................................................................................................... 184
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
12.4.4.2
The System Studied...................................................................................................................... 188
Description of the SPS Architecture............................................................................................. 189
12.4.5 Simulation Results ................................................................................................................... 189
7
Figures
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
8
Figures
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
9
Tables
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
10
Abbreviations
Abbreviations
ABM
AC
ACA
ACM
ANSI
API
ASCII
ASP
ATC
ATM
CAD
CBQ
BOSL
BPF
CAS
CBR
CI
CIM
CISIA
COM
CPU
CSMF
DaSSF
DC
DHS
DML
DMS
EDC
EMT
EMTDC
EPOCHS
EPRI
FACTS
FCITC
FFT
FTP
GIS
GloMoSim
GTO
GUI
HC
HLA
HTML
HVDC
Hz
IEC
IEEE
Agent-Based Modelling
Alternating Current
Autonomous Component Architecture
Association for Computer Machinery
American National Standard Institute
Application Programming Interface
American Standard Code for Information Interchange
Application Service Provider
Available Transfer Capability
Asynchronous Transfer Mode
Computer Assisted Design
Class-Based Queuing
Block-Oriented Simulation Language
Berkley Packet Filter
Complex Adaptive Systems
Constant Bit Rate
Critical Infrastructure
Common Information Model
Critical Infrastructure Simulation by Interdependent Agents
Component Object Model
Central Processing Unit
Conceptual Schema Modelling Facility
Dartmouth Scalable Simulation Framework
Direct Current
Department of Homeland Security
Domain Modelling Language
Distribution Management System
Electronic Dispersion Compensation
ElectroMagnetic transients
ElectroMagnetic Transients including DC
Electric Power and Communication syncHronizing Simulator
Electric Power Research Institute
Flexible AC Transmission Systems
First Contingency Incremental Transfer Capability
Fast Fourier Transformation
File Transfer Protocol
Geographic Information System
Global Mobile Simulation
Gate Turn-Off
Graphical User Interface
Hierarchical Component
High Level Architecture
HyperText Markup Language
High-Voltage DC
Hertz
International Electrotechnical Commission
Institute for Electrical and Electronic Engineer
11
Abbreviations
IGBT
IP
IRRIIS
IT
JADE
J-Sim
LAMPS
LAN
LCCI
MAC
MANET
MFC
MPLS
MW
NAM
NED
NETOMAC
NS
ODBC
OLE
OMT
OO
OPF
OPNET
OS
O-TCL
PARSEC
PDF
PDNS
PGP
PSCAD
PSLF
PSS
PTDF
QoS
RED
REPAST
RFID
RTI
RUV
SCADA
SEPIA
SINCAL
SQL
SSF
SSR
STATCOM
SVC
SYNTEX
TCL
TCP
TE
Insulated Gate Bipolar Transistor
Internet Protocol
Integrated Risk Reduction for Information-based Infrastructure Systems
Information Technology
Java Agent DEvelopment framework
Java Simulator
Language for Agent-based Simulation of Processes and Scenarios
Local Area Network
Large Complex Critical Infrastructure
Medium Access Control
Mobile Ad-hoc NETwork
Microsoft Foundation Class
Multi-Protocol Label Switching
MegaWatt
Network Animator
NEtwork Description
Network Torsion Machine Control
Network Simulator
Open DataBase Connectivity
Object Linking and Embedding
Object Model Template
Object Oriented
Optimal Power Flow
OPen NETwork
Operating System
Object-oriented Tool Command Language
PARallel Simulation Environment for Complex Systems
Probability Density Function
Parallel and Distributed NS
Pretty Good Privacy
Power System Computer Aid Design
Positive Sequence Load Flow software
Power System Simulation
Power Transfer Distribution Factor
Quality of Service
Random Early Detection
REcursive Porous Agent Simulation Toolkit
Radio Frequency Identification
Real Time Infrastructure
RUntime Virtual
Supervisory Control and Data Acquisition
Simulator for Electric Industry Agents
Siemens Network Calculation
Structured Query Language
Scalable Simulation Framework
Sub-Synchronous Resonance
STATic reactive COMpensation
Static Var Compensator
Synthetic Simulation Environment
Tool Command Language
Transmission Control Protocol
Top Event
12
Abbreviations
TIF
TISN
THD
THFF
TTC
UDP
UFLS
VBR
VDE
VINT
WYSIWYG
XML
Telephone Interference Factor
Trusted Information Sharing Network
Total Harmonic Distorsion
Telephone Harmonic Form Factor
Total Transfer Capability
User Datagram Protocol
UnderFrequency Load Shedding
Variable Bit Rate
Verband Der Elektrotechnik, elektronik und informationstechnik
(Association for Electrical, Electronic and Information Technologies)
Virtual-Inter-Network Test bed
What You See Is What You Get
Extensible Markup Language
13
Introduction
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.
14
Methodological approach
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.
15
Simulations tools principles
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.
16
SYNTEX overview
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.
17
SYNTEX overview
…
stakeholder
stakeholder
stakeholder
stakeholder
SYNTEX
canonical architectures
dependency flow
Figure 1: SYNTEX as an integrated simulator
input
SYNTEX
the best way for a
safe exchange of
information ?
Scenario translation module
NS API
OPNET API
CI simulator
CI simulator
Simulation results getting module
…
Specific Simulator API
CI simulator
SINCAL API
CI simulator
…
stakeholder
simulator input (scenario)
Simulator results
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 redescription 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.
18
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
•
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 profitdriven 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
20
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.
Regulator
Virtual Market
Simulator
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
•
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.
22
SYNTEX overview
Trust
Trustmax
Time
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.
input
Scenario generator
Scenario descriptor
SYNTEX
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.
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>
25
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
Attack patterns:
S1
A3
A2
A4
P1: <A3, A2, A5, A6>
P2: <A4, A2, A5, A6>
S2
A6
A5
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 subcomponents (fault causes), and the logical nodes are the faults (consequences) of the
components.
TE
Fault patterns:
<C11, C1, C2, C31, C32, C3>
C1
C2
C3
<C12, C1, C2, C31, C32, C3>
C11
C12
C31
C32
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
Precondition
GA
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.
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
27
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
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.
33
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.
requested
capacity
wait
power
flow sim
self
self
set
attribute
ready
capacity
change
Recalculate
power flows
process
error
self
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
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.
35
Requirements for simulation within SYNTEX
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 recalculated. 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
36
an infinite number of values. For any continuous random variable x with probability density
+∞
function f(x) describing a continuous distribution, we have
∫ f ( x)dx = 1 [DV1, DC1].
−∞
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.
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.
37
•
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.
38
•
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.
39
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.
40
•
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.
41
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.
42
Available tools to simulate (interconnected) CIs of a single sector
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.
43
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.
44
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.
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.:
46
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
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
Hosting operating systems
deteministic and stochastic
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
not specified
Possibility to create new models
52
Table 3: OPNET simulation suitability
Simulation suitability
Simulation of electricity and telecommunication networks
Telecom
Simulation of SCADA system components
Generation of disturbances/corruptions inside the simulated
networks
Available analysis tools for state estimations of the network, results
analysis, 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/management
Ability to create archives containing logs of the networks status and
the operative actions
Consideration 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
6.2.3
commercial
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 eventdriven 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 predefined 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
•
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 Calendarbased. 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.
56
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
Windows, Unix, Free BSD
59
Table 5: NS-2 simulation suitability
Telecom
networks
analysis, etc.
limited
Type of Licence
6.2.4
free of charge
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
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.
62
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
through input and output files
Windows, Linux, Solaris, Mac
not specified
(protocol models)
66
Table 7: QualNet simulation suitability
telecom
networks
analysis, etc.
HLA communication library
Type of Licence
6.2.5
commercial
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
•
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.
68
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
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.
70
•
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
Hierarchical modeling support
Possibility of hosting heterogeneous modeling formalisms
Windows, Unix/Linux
possible parallel simulation
Table 9: OMNeT simulation suitability
generic modelling
networks
analysis, etc.
defined in C++ code
GNED for topology
use of a C++ editor for component
behaviour
(with snapshots)
not specified
commercial, free for academic and nonprofit use
Type of Licence
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
all support
77
Table 11: J-Sim simulation suitability
generic modelling
networks
analysis, etc.
a plotter only
a plotter only
(Tcl writting even so necessary)
component behaviour coded in Java
in output files
Type of Licence
6.2.7
free of charge
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
•
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.
79
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
80
(Raceway implementation)
Raceway: multi platform
DaSSF: Unix OS
Table 13: SSF simulation suitability
generic with focus on telecom
networks
analysis, etc.
Raceway
Raceway
Raceway
not specified
not specified
not specified
not specified
Type of Licence
6.2.8
GNU Public licence
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 realtime, 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
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
83
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
OPNET
NS
QualNet
OMNeT
Continuous as well as discrete
variable representation
Easiness of integration with other
tools
through input and
output files
Possibility of hosting heterogeneous
modelling formalisms
deteministic and
stochastic
Windows 2000/XP,
Linux, Sun Solaris
deteministic and
stochastic
Windows, Unix, Free
BSD
deteministic and
stochastic
Windows, Linux,
Solaris, Mac
deteministic and
stochastic
Windows, Unix/Linux
possible parallel
simulation
Ability to be distributed on a platform
network
Generic models support (SYNTEX as
an integrated simulator)
Possibility to extend/modify existing
and predefined models
not specified
not specified
not specified
(protocol models)
84
Table 15: Comparison of the telecom tools simulation suitability
Simulation of electricity and
telecommunication networks
Simulation of SCADA system
components
Generation of
disturbances/corruptions inside the
simulated networks
Available analysis tools for state
estimations of the network, results
analysis, etc.
Network visualization tools and
network data base systems
Possibility to design, archive and
modify scenarios
GUI for scenario
creation/management
OPNET
NS
QualNet
OMNeT
Telecom
Telecom
Telecom
Generic modelling
defined in C++ code
limited
GNED for topology
use of a C++ editor for
component behaviour
Ability to create archives containing
logs of the networks status and the
operative actions
Consideration 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
(with snapshots)
HLA communication
library
not specified
Type of Licence
commercial
free of charge
6.3
Electrical networks-specific simulation tools
6.3.1
Introduction
commercial
commercial, free for
academic and non-profit
use
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.
6.3.3
PSSTMNetomac
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
•
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 preprogrammed 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.
90
•
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
91
•
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.
92
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 (01-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
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 multimachine 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.
94
Figure 50: NETOMAC Eigenvalue calculation
95
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 (frequencydependent 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,
96
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 closedloop 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 userdefined 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.
97
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
Dynamics and transients behaviours of
electric power systems
networks
analysis, etc.
not specified
Creation of trace files of the simulation results
Type of Licence
6.3.4
commercial
PSSTMSINCAL
6.3.4.1 Description
The PSSTMSINCAL (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
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.
99
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
100
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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 truelocation 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
101
•
•
•
•
•
•
•
•
•
•
•
•
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
102
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 highperformance tool for planning and design of supply networks for a variety of different fields - for
gas, district heating, electrical power and water.
PSSTMSINCAL 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
Use of mathematical models for load
modelling
Windows
not specified
Table 19: SINCAL simulation suitability
Electric and pipe networks
Optionally
networks
analysis, etc.
not specified
Type of Licence
commercial
105
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 tapchanging 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.
106
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-toground 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
Use of mathematical models for load
modelling
Windows
not specified
108
Table 21: PowerWorld simulation suitability
power flow
networks
analysis, etc.
Type of Licence
6.3.6
commercial
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
•
•
•
•
•
•
•
•
•
•
•
•
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).
110
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
Use,of mathematical models for load
modelling
Windows
not specified
Table 23: PSCAD/EMTDC simulation suitability
electromagnetic transient
networks
analysis, etc.
Type of Licence
commercial
114
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:
115
•
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.
116
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
(at a low level)
(at a low level)
Windows
(based on existing agents)
Table 25: SEPIA simulation suitability
electricity market
networks
analysis, etc.
(e.g., for price negociation)
design
Type of Licence
6.3.8
research project
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
NETOMAC
SINCAL
PowerWorld
PSCAD / EMTDC
Continuous as well as discrete
variable representation
Easiness of integration with other
tools
continuous
Possibility of hosting heterogeneous
modelling formalisms
Ability to be distributed on a platform
network
Generic models support (SYNTEX as
an integrated simulator)
Possibility to extend/modify existing
and predefined models
Use of mathematical
models for load
modelling
Use of mathematical
models for load
modelling
Use of mathematical
models for load
modelling
Use of mathematical
models for load
modelling
Windows
Windows
Windows
Windows
not specified
not specified
not specified
not specified
120
Table 27: Comparison of the electric tools simulation suitability
Simulation of electricity and
telecommunication networks
Simulation of SCADA system
components
Generation of
disturbances/corruptions inside the
simulated networks
Available analysis tools for state
estimations of the network, results
analysis, etc.
Network visualization tools and
network data base systems
Possibility to design, archive and
modify scenarios
GUI for scenario
creation/management
NETOMAC
SINCAL
PowerWorld
PSCAD / EMTDC
Dynamics and
transients behaviours
Electric and pipe
networks
power flow
electromagnetic
transient
commercial
commercial
Optionally
not specified
not specified
commercial
commercial
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
Interactions with the real
network/system
Ability to exchange information with
other simulators
Type of Licence
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
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.
122
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.
123
•
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.
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.
124
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 metaknowledge, 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
not specified
not specified
not specified
not specified
not specified
Windows, Unix
not specified
not specified
possible incorporation of new
infrastructure models
126
Table 29: North Carolina University ABM tool simulation suitability
depends on the model used
networks
analysis, etc.
disabling parts of Cis
not specified
not specified
not specified
not specified
not specified
not specified
not specified
not specified
not specified
Type of Licence
7.2.3
simulation of cascading effects intra and
inter Cis
Research Project
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
Agent
AgentHQ
Agent
Agent
RTI
Custom module
NS-2
Custom module
PSLF
Custom module
PSCAD
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.
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
128
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.
129
Table 30: EPOCHS modelling suitability
depends on the simulators
Table 31: EPOCHS simulation suitability
electricity including telecommunication
features
networks
analysis, etc.
possible through the used simulators
Type of Licence
7.2.4
not specified
research project
The Critical Infrastructure Simulation by Interdependent Agents (CISIA)
7.2.4.1 Description
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].
130
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.
131
OUT.R
IN.OL
OUT.OL
Element
Element dynamics
dynamic
Failure
Failuredynamics
dynamic
OUT.F
IN.F
IN.R
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 Interface
Unit
Output Interface
Nominal Value / Type
Unit
Nominal Value / Type
IN.OL
[A]
10
OUT.OL
[A]
10
IN.F
Boolean
‘short circuit’
‘fire’
‘mechanical break’
‘flooding’
‘virus’
OUT.FP
boolean
‘short circuit’
‘fire’
OUT.FG
boolean
‘fire’
10
OUT.FC
boolean
‘virus’
IN.R
[A]
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
Agent’s output interface
Agent’s fault
F.Type
‘fire’
‘short circuit’
‘virus’
‘fire’
‘short circuit’
OUT.FP
‘fire’
OUT.FG
to Physical
neighborhood
mFP
to Geographical
neighborhood
mFG
to Cyber
neighborhood
‘virus’
OUT.FC
mFC
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
fuzzy logic only
not specified
thanks to REpast
134
Table 33: CISIA simulation suitability
networks
analysis, etc.
thanks to REpast
thanks to REpast
thanks to REpast
thanks to REpast
thanks to REpast
depends on REpast
Type of Licence
7.2.5
research project
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
(xj), and of a perturbation term (ui) that can affect the ith 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:
x( k + 1) = Rx (k ) + Bu ,
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.
136
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 (but differiential equations
recalculated each discrete time)
depends on the development environment
137
since modelling with adjacency matrixes
Table 35: Simulation suitability of the ENEA model
since modelling with adjacency matrixes
networks
analysis, etc.
possible
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
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.
139
Table 36: Modelling suitability of the mathematical model
continuous
network visualization with TouchGraph
depends on the development environment
since modelling with directed graphs
Table 37: Simulation suitability of the mathematical model
since modelling with directed graphs
networks
analysis, etc.
possible
not indicated
Type of Licence
7.3.4
research work in progress
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
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.
141
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.
142
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.
143
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
pros
cons
General
Public domain
Modelling
Hierarchical modelling impossible
Available on the main OS platforms
Modelling
Adding new components is complex. It
requires a good knowledge of the simulator
Stochastic modelling
Few random variables distributions are
available for stochastic modelling
Predifined models available
NS-2
Telecom
infrastructures
fine
Creation/modification of models and components
Simulation
Discrete event simulator
A GUI is available for:
simple scenario creation
Inputs:
- 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)
144
Simulation
Scenario description in OTcl (no GUI
available)
Small scale network simulation
target audience
Designer: ability to create new
models and compnts
Experimenter & MIT Tester:
new model creation, simulation
execution, statistics collection
and analysis
MIT System: realistic
simulation results, statistics
collection, outputs generation
External Simulator: data
importation
External Analysis: statistics
collection, outputs and logs
generation
Operator: control of online
simulation
possible
tools
simulation object
granularity
level
pros
cons
General
Available on various OS platforms
The most complete tool for telecom network simulation
Modelling
Stochastic modelling with various distributions for random variables
Hierarchical modelling
Predifined topologies/models/equipments available
Creation/modification of models and equipements
Simulation
General
Propritetary and expensive tool
Modelling/Simulation
Complex tool. Require training
target audience
models and components
- new model creation
- simulation execution
- statistics collection
- simulation results analysis
and comparison
OPNET
Telecom
infrastructures
fine
Performing GUI for (all information accessible through GUI):
- scenario and model conception
- data/statistics collection
- simulation running
- simulation results visualization and analysis
MIT System:
- realistic simulation results
- outputs generation
Collection 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
tools
Outputs:exportation of simulation statistics to spreadsheets or XML
Other features:
- large scale network simulation
- parallel and system in the loop simulations
- faster than real time simulations
- communications with other simulators (HLA module)
145
External Simulator:
- data importation
- HLA module
External Analysis:
- outputs and logs generation
Operator:
- control of online simulation
possible
tools
simulation object
granularity
level
pros
cons
General
Available on various OS platforms
Modelling
General
Propritetary tool
Modelling
Not clear that new component may be created
Predifined models and equipments available
Possibility to create/modify models
Simulation
target audience
models
and comparison
QualNet
Telecom
infrastructures
fine
Performing GUI for (all information accessible through GUI):
- scenario and model conception
- data/statistics collection
MIT System:
Collection of statistics on global network, node, protocol…
External Simulator:
- data importation
- HLA module
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.
External Analysis:
Outputs:exportation of simulation statistics to trace files, of logs
Other features:
- parallel simulation
- real time simulation
- communications with other simulators (HLA library)
- possibility to create scenario templates
- form of network emulation
146
Operator:
possible
tools
simulation object
granularity
level
pros
cons
General
Available on the main OS platforms
Open source
Flexible and modular
Modelling
Stochastic modelling with some distributions for random variables,
possibility to define new distributions
Predifined (generic and network infrastructures) model and components
Creation/modification of models and components through the OMNeT API
OMNET++
All infrastructures
with a generic
modelling
Depends on
the defined
model
granularity
Simulation
Performing GUI:
- topology description
target audience
General
Commercial tool
Specific language for topology definition
No GUI for:
- model/equipment creation and modification - new model creation
(done in C++)
- scenario definition (done in a confiuration
file)
and comparison
MIT System:
External Simulator:
- data importation
Collection of statistics on global network, nodes, links…
Filtering of simulation results before analysing the trace files
Inputs:
- importation/exportation of topologies from/to data and XML files
- interaction with databases
Outputs: various simulation statistics output files, log files
Other features:
- parallel distributed simulation
- system in the loop simulation
- OMNET tool not required to run simulation (execution file creation)
147
External Analysis:
Operator:
possible
tools
simulation object
granularity
level
pros
cons
General
Free of charges
Open source
Multi platform support
Modelling
No GUI for model/equipment creation and
modification (done in Java)
Script language to construct/configure/control
the simulation
Predifined (generic and network infrastructures) model and components
J-Sim
All infrastructures
with a generic
modelling
Depends on
the defined
model
granularity
Simulation performances not documented
target audience
MIT S t
Experimenter
& MIT Tester:
MIT System:
Simulation
Real-time simulator
External Simulator:
- data importation
Performing GUI for:
- simulation model (topology and part of scenario) description (generate
associated TCL code)
External Analysis:
Collection of statistics on global network, nodes, links…
Operator:
Inputs:
- files for incoming traffic
- imporation of XML scenario model files
Outputs: various simulation statistics output files, log files
Other features:
- plug in of java real-time applications
- possibility to act on simulation while it is running
General
GNU public licence
C++ and Java implementations
SSF
All infrastructures
with a generic
modelling
Depends on
the defined
model
granularity
Gaining popularity
Modelling
Stochastic modelling with continuous and discrete random variables (wide
range of distributions for C++ implementation)
Hierarchical modelling in Java implementation
Simulation
Storage of information on topology, simulation environment and simulation
runtine in 3 distinct files
Large scale simulation
Parallel and distributed simulation
148
Few documented GUI for Java implementation - new model creation
Use of a specific language to describe
- statistics collection and
topology, simulation environment and
analysis
simulation run-time
MIT System & External
Analysis: statistics collection,
No information on inputs, real network
interactions, information exchange with other outputs and logs generation
simulators, fast simulation capabilities
Simulation
No GUI for C++ implementation
possible
tools
simulation object
granularity
level
pros
cons
General
Alternative to HLA
Patitioning of protocol layers among the cooperative heterogeneous
simulators
Modelling
BackPlane
communications
between telecom
simulators
fine
Use of the best models of each simulator
(depends on
Simulation
the used
simulation
Large scale network simulation
tools)
Parallel and distributed real time simulation (involves improvement of
simulators running speeds)
Network emulation
General
Few documented
Split of protocol layers cernerly generate
difficulties for model conception
target audience
Experimenter / External
Analysis:
- collection and analysis of
dependency statistics
Use of several simulators in the same
protocol stack slows down the simulation
speed.
System or human in the loop simulation (not documented)
Other simulation features depend on the used simulators
General
Available on Windows OS platforms
Flexible and adaptable
Modelling
Creation/modification of models
Simulation
NETOMAC
Only available on Windows OS
Use of differential equations to model admittancies, controllers and
machine behaviors
Predifined models and elements available
Dynamics and
transients
behaviors of
electric power
systems
General
Propritetary tool
No consideration of communication
capabilities
Simulation
No information on parallel or distributed
simulation
Time and frequency domain simulation
All NETOMAC information stored in a database
fine
Performing GUI for:
- system modelling (with NETCAD)
Statistics on machines, networks, loads and controllers
MIT System:
Various and performing analysis of system states and statistics
Inputs:
- from NETCAD (system mdel)
- from other simulators through the database
External Simulator:
- data importation
Outputs:exportation of simulation statistics on various formats
External Analysis:
Other features:
- real-time simulation of electromechanical transients
- interface with real time applications
- interface with analogue real-time simulators
149
possible
tools
simulation object
granularity
level
pros
cons
General
General
Propritetary tool
Well documented
Modelling
Simulation
Predifined models and elements available
Static simulation program but possible to
include NETOMAC as a module
Use of different mathematical models for elements
Simulation
simulation
target audience
Includes the main features of NETOMAC as a module
Various and performing analysis and calculation are available
All SINCAL information stored in a database
SINCAL
Power
transmission and
distribution
fine
Performing GUI for:
- system modelling
- planning scenario definition
- simulations running
MIT System:
Inputs :
- through the database (no need to handle different input files)
- possible importation of data in various standard data formats or
plotting format
External Simulator:
- data importation
Outputs:
- generation of reports
- exportation of data
Other 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
150
External Analysis:
Operator:
possible
tools
simulation object
granularity
level
pros
cons
General
Modelling
General
Propritetary tool
Dedicated to high voltage power systems
Few available information
Mathematical model for load modelling
Use of discrete and continuous variables
Predifined models and components available
Consideration economic data influence on the model
Simulation
Simulation
Power
World
high voltage power
systems
fine
capabilities
No information on possible inputs
simulation
Performing GUI centralizing all functionalities:
- model and scenario definition
- simulation running visualization
target audience
MIT System:
Possiility to act on simulation during its execution
Outputs: possible exportation of simulation statistics for analysis by other
tools
External Analysis:
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
General
Simulation of dependencies between an electrical CIs and its telecom CI
modelling
EPOCHS
Electrical CIs with
communication
capabilities
fine
Agent-based modelling of dependencies
Interfacing simulators according to their specificities, even if source code
is not available
CI modelling depends on the used simulators
Simulation
Exchange of information between simulators through agents, at specific
synchronization points
CI simulation depends on the used simulators
151
simulation
General
Considers only two simulators at the same
time
Simulation
Fast simulation capabilities not specified
Analysis:
- collection and analysis of
dependency statistics
possible
tools
simulation object
granularity
level
cons
pros
General
Propritetary tool
Last version only available on Windows OS
capabilities
General
Modelling
Use of differential equations to model behaviors
Predifined models and components available
Simulation
Continuous time simulation
PSCAD /
EMTDC
electromagnetic
transients
fine
Simulation
Limited to time domain simulations
Few information is available on fault
generation
simulation
No information on type of data that can be
imported
Performing GUI for:
- model and component definition
- scenario definition
Outputs:
- contant files
- log files (possible exportation to MS Excel)
- output files
Agent-based modelling
Different possible languages to code agents
Stochastic modelling of power production and load
Simulation
Coarse
- statistics collection,
analysis
MIT System: realistic
simulation results, statistics
collection outputs generation
External Analysis: statistics
collection, outputs generation
Other features:
- scenarios can be written in Fortran C and MathLab
- fast simulation capabiility (short duration responses)
General
Simulation of electicity markets
Modelling
SEPIA
models & components
External Simulator: data
importation
Possibility to import data
Electrical power
infrastructures and
associated market
target audience
simulation
General
capabilities
Modelling
- new scenario model
creation
Coarse level modelling of electrical networks
Use of agent learning capabilities to adapt behavior during simulation
running
A GUI for:
- system and scenario modelling
Only uniform distribution for random
variables
Simulation
Simulator does not get inputs (no information
on this part)
MIT System & External
Analysis: statistics collection,
outputs generation
simulation
Outputs:generation of trace files
152
possible
tools
simulation object
granularity
level
cons
pros
target audience
No information on behavioral models used for Analysis:
- analysis of dependency
CIs modelling
statistics
No information on (fast) simulation capabilities
General
Simulation of dependencies between different sectors' CIs with agents
North
Depends on Modelling
Carolina Infrastructures and
the defined
Agent-based modelling of dependencies
University
crossmodel
Simulation
infrastructures
CI modeled with behavioral models
granularity
tool
Simulation
Plug-in and out of models as needed
GIS support for error propagation visualization
General
Consideration of CI inoperability (depending on possible perturbation of
the CI and on other CI inoperability)
Modelling
ENEA
math.
model
General
Work in progress
No distinction between architecture
components
Modelling of CIs (topology, disturbances and dependencies) with matrixes
No tool for topology creation/generation
Interdependencies
Fine for CI
in/operability
Based on the Leontief model for perturbation propagation modelling
Introduction of dynamics in the system with bufferring of perturbation
propagation
Simulation
Analysis:
- analysis of fault propagation
and CI components
inoperability
No GUI
Discrete event simulation (equation recalculated each discrete time)
Simulation results stored in a trace file
Results can be viewed on a chart
Dresden
Univ.,
Zilina
Univ.,
Collegium
Budapest
math.
model
cascading failures
and disasters
General
General
General
Interesting for study and presiction of cascading effects
Modelling
Work in progress
No distinction between architecture
components
Network modelling with directed graphs
Modelling of node state with a normal operation variable
Modelling of perturbation level of components
No tool for topology creation/generation
Modelling of spontaneous failures
Simulation
Simulation of failure propogation according to link features
Modelling/simulation of recovery process
153
Analysis:
and CI components
perturbation level
possible
tools
simulation object
granularity
level
pros
cons
General
Consideration of physical, geographical and cyber faults
General
Work in progress
General level
Modelling
CISIA
fault propagation
and performance
degradation
General
target audience
Analysis:
Agent-based modelling
Infrastructure components modeled by its operating level (calculated with
fuzzy numbers), its requirements and the fautls
Dependencies between components represented through incidence matrix
Simulation
Uses the REpast ABM tool features
Table 39: Simulation tools possible integration
SYNTEX
SYNTEX Overlay
Integrated view
view
OPNET
NS
QUALNET
OMNeT++
J-Sim
SSF
BackPlane
NETOMAC
SINCAL
Power World
PSCAD/EMTDC
SEPIA
North Carolina University Simulation tool
EPOCHS
CISIA
ENEA math. model
Dresden Univ., Zilina Univ., Collegium
Budapest math. model
Possible interfacing for the SYNTEX overlay view
Use of HLA, use of inputs/outputs, development of a specific interface
Use of inputs/outputs, development of a specific interface
Use of HLA, use of inputs/outputs, development of a specific interface
Similar principle than HLA
Use of specific interfaces
154
Conclusion
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
155
Conclusion
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.
156
Conclusion
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.
157
Glossary
10. Glossary
Attack tool
Tool to design attack trees that can be used to generate pfault behaviours.
The attack tool allows the editing of pattack 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 ponline mode and analysis to show the
evolution of pattribute values over time or to show the relation between
different pattribute. During analysis the pattribute may be from the same
or from different psimulation runs.
Behaviour
See puser-specified behaviour, psystem-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 pscenarios to run and possible pfault behaviours are specified in a
beforehand.
Cascading effect See pcascading 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)
158
Glossary
CI model
A CI model consists of pcomponents and pconnections between them.
Component
A (network) component is an object in a pCI Model e.g. a generator, a
transmission line, a substation. Components have pattributes and puserspecified behaviour.
Connection
Connections describe links between different pcomponents in a pCI
model. E.g. a generator can be linked to a transmission line. Connections
may be realised as pattributes but should be handled differently in the
pGUI 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.
“An infrastructure has a cyber interdependency if its state depends on
Cyber
interdependency information transmitted through the information infrastructure.” (Rinaldi,
2001)
Discrete event
simulation
In discrete event simulation, the psystem-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 pcomponent in the pCI 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 pevents which occurred during a psimulation
run and are considered “important”, e.g. the trip of a line. pSystemspecified behaviour or puser-specified behaviour may write to the event
log.
159
Glossary
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” pscenario behaviour. Fault behaviour may be
created “by hand” as other behaviours or with the support of the pattack
tool using pattack trees.
Fault tree
Fault trees represent fault sequences of pcomponents in which each
pcomponent 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 pcomponents
“Infrastructures are geographically interdependent if a local
Geographical
interdependency 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.
160
Glossary
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
puser-specified behaviour (pcomponent behaviour, pscenario behaviour
and pfault behaviour).
Log
See pEvent log and psimulation log.
“Two infrastructures are logically interdependent if the state of each
Logical
interdependency 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 pCI 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
pattributes.
“Two infrastructures are physically interdependent if the state of each is
Physical
interdependency dependent on the material output(s) of the other.” (Rinaldi, 2001)
Scenario
A scenario consists of a pCI model, the initial states of all pcomponents
and the pscenario behaviour which describes the pevents which happen
within the scenario.
Scenario
behaviour
The scenario behaviour describes the “normal” pevents which happen
within a pscenario (e.g. a consumer changes the amount of electric power
that is consumed). The pevents may be triggered by time or by other
conditions defined in the scenario behaviour.
161
Glossary
Simulation log
The simulation log contains the evolution of the values of all pattributes
over time. It builds the basis for the analysis of psimulation runs.
Simulation run
A simulation run is a single execution of a pscenario and optional pfault
behaviour.
Systemspecified
behaviour
System-specified behaviour is behaviour of pcomponents or pscenarios
which is either to basic or to complicated to be described as puser-specified
behaviour and therefore has to be implemented in a programming language
by a developer.
Topology
A topology is given by pconnections between pcomponents of a pCI
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 (pLAMPS).
User-specified behaviour can invoke other user-specified behaviour or
psystem-specified behaviour.
162
References
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
access on 10/09/06)
(last
[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)
163
References
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
[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
164
References
[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:
static.cc.gatech.edu/computing/compass/pdns/ (last access on 10/09/06)
[Sce_gen]
NS
scenario
generation:
scengeneration.html (last access on 10/09/06)
http://www-
http://www-mash.CS.Berkeley.EDU/ns/ns-
[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.scalablenetworks.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.scalablenetworks.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.
165
References
[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
[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://wwwstatic.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.
166
References
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
167
References
11.5.1 General ABM references
[ABM_L] List of available ABM tools: http://www.swarm.org/wiki/Tools_for_AgentBased_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/fileaccess/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
168
References
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
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).
169
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
$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
171
Appendixes
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 currentcarrying 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
172
Appendixes
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.
173
Appendixes
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 threephase 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 largescale 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
174
Appendixes
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 ripplecontrol 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.
175
Appendixes
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 instrumenttransformers, 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.
176
Appendixes
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.
177
Appendixes
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
178
Appendixes
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.
179
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-touse 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
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-touse 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
181
Appendixes
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:
182
Appendixes
•
•
•
•
•
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.
183
Appendixes
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 busbreaker 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
184
Appendixes
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.
185
Appendixes
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
186
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
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
188
Appendixes
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 realtime 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
189
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

List of available and suitable simulation components

Transcription

Similar documents