Учебники / 0841558_16EA1_federico_milano_power_system_modelling_and_scripting

Fig. 21.2 Proposed data exchange structure

“The IEC standard 61970-301 [138] is a semantic model that describes the components of a power system at an electrical level and the relationships between each component. The IEC 61968-11 [137] extends this model to cover the other aspects of power system software data exchange such as asset tracking, work scheduling and customer billing. These two standards, 61970301 and 61968-11 are collectively known as the Common Information Model (CIM) for power systems and currently have two primary uses: to facilitate the exchange of power system network data between companies; and to allow the exchange of data between applications within a company.”

In its purpose, CIM is designed to cover all aspects of power systems and uses RDF for organizing data. There are several ways to implement a CIM data file. A common structure consists in dividing the power system elements into two sections, namely topological data and physical resources. The topological data organizes the system into islands and each island into topological nodes that contain terminals. The attributes of each topological object define its connectivity to other terminals. Resources can be further subdivided into two groups, operational resources and equipments. Operational resources are containers such as control areas, bays, substations, voltage levels, etc, while equipments are the physical devices, such as loads, that belong to some container. Terminals provide the links between topological data and physical resources, as illustrated in Figure 21.3. Topological nodes and equipments belong to containers. Then, equipments can be connected to a node through one or more terminals.

The CIM scheme is su ciently general to be able to describe any aspect of power systems. And actually this is the goal of the task forces that are defining the IEC standards that describes the CIM format. Furthermore, being based

are commercial interests behind the definition of CIM. However, a monopolistic proprietary approach is certainly to be avoided if a format claims to be an international standard.

5.CIM has been designed to cover all aspects of power systems. In the idea of its creators, CIM can be actually able to describe any aspect of reality. Due to the G¨odel’s theorem, if a system is complete is inconsistent, and if it is consistent is incomplete. If the goal of CIM is to be complete, then CIM is inexorably destined to be inconsistent.

6.The name itself, i.e., common information model, indicates the inadequacy of CIM for describing data for power system analysis. CIM is designed to be a mere “information” data base. However, as discussed in the following section, a data format cannot be independent from the mathematical models used for describing power system devices.

21.4Consistent Data Schemes

Any data format is implicitly based on a certain set of mathematical models of power system devices. Part III has discussed a variety of devices, but the list is well far to be complete and more devices will be invented in the future. Furthermore, each device has a variety of possible models, depending on the detail level and on the analysis that has to be solved. According to this premise, the definition of a complete data format is simply impossible. But, fortunately, it is not desirable. Rather than aiming to classify any power system device in a closed structure, a consistent data format should simply provide a structure (or a scheme) able to describe as many devices as possible. In other words, it is not relevant how many devices a data format includes, but how versatile and well-designed is the scheme on which the format is built. In this regard, the approach of CIM is correct, since it provides a general scheme for describing power systems.3

A scheme is an abstract object and should not be based on a specific language. A common issue of most data formats is to confuse syntax rules with the data scheme. Mark-up languages avoid this confusion and should be preferred. However, the scheme should not depend on a specific mark-up language.

Based on the features described in Section 21.1, other desired properties are the possibility of spreading data in multiple files, data prototyping and data manipulating commands. Least but not last, a scheme should be as readable as possible so that it is not necessary to use dedicated software to write a simple data file for didactic use. This feature is irrelevant for industrial applications because nobody actually writes by hand a data file composed of thousands of buses. However, designing a data format only thinking in

3The success of the XML language is also due to the fact that XML provides the means for designing as complex as desired schemes.

industrial applications (e.g., CIM) and neglecting didactic issues implies a training cost when it comes to employ just-graduated engineers.

Nevertheless, it would be very useful if a data format for power system analysis aligns with the concepts that are included in the CIM for power system data (i.e., standards IEC 61970, 61968, 61850, 60870-6 (TASE.2), ISO9506 (MMS), etc.) In fact, it is not desirable to have corporate systems, SCADA, and substation protection and control working on a common information model, and the analysis software moving to a completely di erent direction.

Finally, according to the discussion given in Subsection 22.2.4 of Chapter 22, it is desirable that a data format integrates device parameters and geographical information so that one does not have to maintain two separate databases that almost never agree.

Example 21.1 Data Format Example

This example provides a simple yet versatile data format.

The proposed scheme is as follows. A network is composed of a set of devices. A device can be topological (e.g., buses and areas) or physical (e.g., generators and loads). Each device is defined by a list of parameters. The device identification code (called idx in the following example) allows connecting devices together. For example, to indicate that a load is connected to a certain bus, it su ces to assign the bus identification code to the load parameter bus.

As discussed above, the syntax is not really important, especially if using mark-up languages. However, to maintain as readable as possible the file, the following rules are used:

1.The name of the device starts in the first column.

2.Device data can span multiple lines.

3.Lines following the first one must be indented.

4.Data follows in Property Name = Value pairs, separated by commas.

5.Data in form of strings must be delimited by "".

6.Data in form of arrays must be delimited by brackets [].

7.Each element of the array must be separated by semicolons.

8.Float data support simple operations (sum, multiplication, etc.).

9.Comments starts with a # in the first column

For example this is how the IEEE 14-bus system looks like in this format:

Bus, Vn = 69.0, idx = 1, name = "Bus 1"

Bus, Vn = 69.0, idx = 2, name = "Bus 2"

Bus, Vn = 69.0, idx = 3, name = "Bus 3"

Bus, Vn = 69.0, idx = 4, name = "Bus 4"

Bus, Vn = 69.0, idx = 5, name = "Bus 5"

Bus, Vn = 13.8, idx = 6, name = "Bus 6"

Bus, Vn = 13.8, idx = 7, name = "Bus 7"

Bus, Vn = 18.0, idx = 8, name = "Bus 8"

Bus, Vn = 13.8, idx = 9, name = "Bus 9"

Bus, Vn = 13.8, idx = 10, name = "Bus 10"

Bus, Vn = 13.8, idx = 11, name = "Bus 11"

Bus, Vn = 13.8, idx = 12, name = "Bus 12"

Bus, Vn = 13.8, idx = 13, name = "Bus 13"

Bus, Vn = 13.8, idx = 14, name = "Bus 14"

Area, idx = 1, name = "14-Bus"

Shunt, Vn = 13.8, b = 0.19, bus = 9, idx = "Shunt 1", name = "Shunt Bus 9"

SW, Vn = 69.0, bus = 1, busr = 1, idx = 1, name = "SW Bus 1", pg = 2.324, pmax = 999.9, pmin = -999.9, qmax = 9.9,

qmin = -9.9, v0 = 1.06

Script 21.1 Data Parser

The following Python code implements a parser for the data format described in the previous section. A parser consists in a procedure that reads a file and extracts data and/or information based on a given syntax. Regular expressions (imported through the standard library re) allows e ciently parsing the data.4 Finally, the command INCLUDE is supported through a recursive call to the function read.

import re import system

def alter(data):

device = data[0] action = data[1]

if data[2] == ’*’: data[2] = ’.*’ regex = re.compile(data[2])

prop = data[3]

value = float(data[4])

4Regular expressions are a fascinating world apart in computer programming. The regular expression parser is an extremely powerful tool for manipulating text and data and is provided as a standard library by most programming languages, including Perl, Python and Java. The interested reader can find a complete description of regular expressions in [102].

else:

print ’ALTER action <%s> is not defined’ % action

def read(fid, header = True):

# useful regular expressions and constants

line += ’ ’ + newline

data = sep.split(line) device = data.pop(0) device = device.strip()

if device == ’ALTER’: alter(data) continue

if device == ’INCLUDE’:

print ’Parsing include file <%s>.’ % data[0] newfid = open(data[0], ’rt’)

read(newfid, header = False) # recursive call newfid.close()

print ’Parsing of include file <%s> completed.’ % data[0] continue

kwargs =

for item in data:

pair = equal.split(item) key = pair[0].strip()