3.3 CityMoS Power
3.3.2 Data Format
The default input and output data format for CityMoS Power is XML. This format applies to both the input data required when instantiating the main class MainPlanning as well as to the serialized and deserialized PNMs and power flow values. A definition of XML and XSD, a schema system for validating XML documents, is given in Section 3.2.1. In Section 3.3.2.1, an XSD file providing a formal specification of the XML documents’ syntax is described. An example of an XML input file complying with the XSD and illustrating the implementation of its main concepts is shown and discussed in Section 3.3.2.2. Because of its broad spread and
in some cases clear advantages over XML, theComma Separated Value (CSV) file format is additionally supported. Its usage is described in Section 3.3.2.3.
3.3.2.1 XSD
Input and output data for CityMoS Power is stated using XML. The XML documents’ syntax is formally specified by an XSD file. Listing 3.1 provides an overview of such an XSD used for defining both input and output data required and generated by CityMoS Power. In the following, the main concepts of elements, attributes, restrictions, and constraints are introduced necessary to understand the XML file described in Section 3.3.2.2.
Listing 3.1 Overview of CityMoS Power’s XSD.
1 <xs : schema
8 <xs : element name=" PowerSystem ">
9 <xs : complexType>
10 <xs : sequence>
11 <xs : element name=" Node " t y p e=" s p : NodeType " minOccurs=" 2 " maxOccurs="
unbounded " />
12 <xs : element name=" Edge " t y p e=" s p : EdgeType " minOccurs=" 0 " maxOccurs="
unbounded " />
13 <xs : element name=" Area " t y p e=" s p : AreaType " minOccurs=" 0 " maxOccurs="
unbounded " />
20 <!−− KEY, KEYREF, & UNIQUE CONSTRAINTS FOR NODE−−>
21 <!−− . . . −−>
22 <!−− KEY, KEYREF, & UNIQUE CONSTRAINTS FOR EDGE−−>
23 <!−− . . . −−>
24 <!−− KEY, KEYREF, & UNIQUE CONSTRAINTS FOR AREA−−>
25 <!−− . . . −−>
26
27 </xs : element>
28
29 <!−− DEFINITION OF THE COMPLEX TYPE NODETYPE−−>
30 <!−− . . . −−>
31 <!−− DEFINITION OF THE COMPLEX TYPE EDGETYPE−−>
32 <!−− . . . −−>
33 <!−− DEFINITION OF THE COMPLEX TYPE AREATYPE−−>
34 <!−− . . . −−>
35
36 </xs : schema>
The document starts with the definition of the namespacessp (line 4) andxs(line 5) which include all elements, attributes, and datatypes defined by the given XML schema and in the language definition itself. It is further stated that elements used and declared in this XSD must
be namespace qualified (line 6) meaning their namespace must always be specified along with their name. The body of the file contains the definition of the main elementPowerSystem(line 8).
This element specifies possible subelements Node(line 11), Edge(line 12), and Area (line 13) as well as the additional attributesAuthor(line 15),Version(line 16), andDate(line 17). Primary key, key reference, as well as uniqueness constraints for all three subelements are also defined. To provide an easy overview some definitions are intentionally left out, indicated by<!−−...−−>. They are defined or discussed onward in the course of this section.
The data type of elements and attributes may be either simple, e.g., int, decimal, string, etc., or complex, e.g., PowerSystem,Node,Edge, orArea. Listing 3.2 shows the definition of a complex type on the example of NodeType, the data type for the subelement Node. The definition is logically split into four parts indicating time-dependent subelements (line 3) as well as static mandatory (line 9), optional (line 12), and additional attributes (line 15). An attribute is hereby defined by its name, its simple datatype, a required or optional flag, and in the optional case an additional default value. TheanyAttributedefinition (line 16) allows the XML document to be extended by additional attributes not explicitly specified in the XSD. The definition of
EdgeType, the data type for the subelementEdge, is done accordingly.
Listing 3.2 Definition of the complex type NodeType.
1 <xs : complexType name=" NodeType ">
2
3 <!−− TIME−DEPENDENT SUBELEMENTS−−>
4 <xs : sequence>
5 <xs : element name=" I n p u t " t y p e=" s p : NodeInputType " minOccurs=" 0 " maxOccurs="
unbounded " />
6 <xs : element name=" Output " t y p e=" s p : NodeOutputType " minOccurs=" 0 " maxOccurs="
unbounded " />
7 </xs : sequence>
8
9 <!−− REQUIRED ATTRIBUTES−−>
10 <xs : a t t r i b u t e name=" IdNode " t y p e=" x s : i n t " u s e=" r e q u i r e d " />
11
12 <!−− OPTIONAL ATTRIBUTES−−>
13 <!−− . . . −−>
14
15 <!−− ADDITIONAL ATTRIBUTES−−>
16 <xs : anyAttribute p r o c e s s C o n t e n t s=" l a x " />
17
18 </xs : complexType>
Time-dependent complex types such as NodeInputType which is provided by Listing 3.3 or
NodeOutputTypeare characterized by the mandatory attributesTimePeriod(line 4),PowerDemandActive
(line 5), and PowerDemandReactive (line 6). Those attributes specify the active and reactive power demand of a Nodeat each unique time period. Depending on the specific complex type, additional required and optional attributes are also defined.
Simple data types as defined by the xsnamespace may also be subtyped and amended by additional restrictions. Those restrictions are called facets. Listing 3.4 shows the definition of a facet on the example of theVoltageLevelType defined for the optional VoltageLevelattribute of
NodeType. The voltage level is hereby restricted to the specifically mentioned values between
0.4 and 400 (line 3).
Listing 3.3 Definition of the complex type NodeInputType.
1 <xs : complexType name=" NodeInputType ">
2
3 <!−− REQUIRED ATTRIBUTES−−>
4 <xs : a t t r i b u t e name=" TimePeriod " t y p e=" x s : i n t " u s e=" r e q u i r e d " />
5 <xs : a t t r i b u t e name=" PowerDemandActive " t y p e=" x s : d e c i m a l " u s e=" r e q u i r e d " />
6 <xs : a t t r i b u t e name=" PowerDemandReactive " t y p e=" x s : d e c i m a l " u s e=" r e q u i r e d " />
7
8 <!−− OPTIONAL ATTRIBUTES−−>
9 <!−− . . . −−>
10
11 <!−− ADDITIONAL ATTRIBUTES−−>
12 <xs : anyAttribute p r o c e s s C o n t e n t s=" l a x " />
13
14 </xs : complexType>
Listing 3.4 Definition of a facet on the example of the simple type VoltageLevelType.
1 <xs : simpleType name=" V o l t a g e L e v e l T y p e ">
2 <xs : r e s t r i c t i o n b a s e=" x s : d e c i m a l ">
3 <xs : pattern v a l u e=" 0 . 4 | 6 . 6 | 2 2 | 6 6 | 2 3 0 | 4 0 0 " />
4 </xs : r e s t r i c t i o n>
5 </xs : simpleType>
An XML schema cannot only include facets but also key, key reference, and uniqueness constraints indicated by the elementskey, keyref, and unique. In Listing 3.5, a key constraint is defined for the attributeIdNodeof the element Node.
Listing 3.5 Definition of a key constraint on the example of the element Node.
1 <xs : key name=" Node_IdNode_Key ">
2 <xs : s e l e c t o r xpath=" s p : Node " />
3 <xs : f i e l d xpath=" @IdNode " />
4 </xs : key>
The given key can be referenced by other attributes. Those referring attributes can then only take values of that key attribute. Listing 3.6 provides an exemplified definition of a key reference constraint in which the attributes IdNode1 and IdNode2 of the element Edge are referencing the previously defined key Node_IdNode_Key. This allows the element Edge to be valid only when referencing two existing Nodeelements.
Listing 3.6 Definition of a key reference constraint on the example of the element Edge.
1 <xs : keyref name=" Edge_IdNode1_Ref " r e f e r=" sp : Node_IdNode_Key ">
2 <xs : s e l e c t o r xpath=" s p : Edge " />
3 <xs : f i e l d xpath=" @IdNode1 " />
4 </xs : keyref>
5 <xs : keyref name=" Edge_IdNode2_Ref " r e f e r=" sp : Node_IdNode_Key ">
6 <xs : s e l e c t o r xpath=" s p : Edge " />
7 <xs : f i e l d xpath=" @IdNode2 " />
8 </xs : keyref>
In the context of CityMoS Power it is a necessary requirement that the location of each
Nodeis unique for the entire planning process. In Listing 3.7 such a uniqueness definition is provided for the element Nodebased on the combination of its attributesLatitude and Longitude. Listing 3.7 Definition of a uniqueness constraint on the example of the element Node.
1 <xs : unique name=" Node_Location_Uni ">
2 <xs : s e l e c t o r xpath=" s p : Node " />
3 <xs : f i e l d xpath=" @ L a t i t u d e " />
4 <xs : f i e l d xpath=" @Longitude " />
5 </xs : unique>
3.3.2.2 XML
Data for CityMoS Power is specified in XML files complying with the XSD described in the previous Section 3.3.2.1. Those files have to be valid and thus well-formed. Although there is only one XSD all XML files have to comply with, different XML files varying in structure and content are used to cover the various use cases of CityMoS Power. Investigated use cases are described in Chapter 4. In the following, a minimal implementation of the XML schema’s elements for input data is exemplarily illustrated.
Each XML file consists of one PowerSystemelement which is defined by a reference to the applied XML schema (line 3), a set of namespaces (lines 4 and 5), and the stipulated attributes
Author, Date, and Version (line 6) as illustrated in Listing 3.8. The body of the file contains definitions for the elements Node(line 9) and Edge (line 10). Area elements do not appear in the input data but are only part of the output of the PSP process. Definitions indicated by
<!−−...−−>are deliberately left out to improve readability and will be discussed onwards in the course of this section.
Listing 3.8 Simplified example of an input file for CityMoS Power.
1 <PowerSystem 2
3 x s i:s c h e m a L o c a t i o n=" h t t p : / / r p 5 . i n f o CityMoS_Power . xsd "
4 xmlns=" h t t p : / / r p 5 . i n f o "
5 xmlns:x s i=" h t t p : / /www. w3 . o r g / 2 0 0 1 /XMLSchema−i n s t a n c e "
6 Author=" David_Ciechanowicz " Date=" 2016−01−01 " V e r s i o n=" 3 . 3 ">
7
8 <!−− NODE ELEMENTS−−>
9 <!−− . . . −−>
10 <!−− EDGE ELEMENTS−−>
11 <!−− . . . −−>
12
13 </PowerSystem>
Node elements may be differentiated into PQ and PV nodes, the latter distinguishing substations and power plants. An example of a minimal PQ node is illustrated in Listing 3.9.
It is defined by its required attribute IdNode as well as the optional attributes Latitude and
Longitude(line 1). With the key and uniqueness constraints defined in the XSD, this allows to uniquely identify and locate the PQ node. Default values apply to all other non-mentioned
optional attributes as defined in the XSD. Depending on the use case, these optional or other attributes may additionally be specified here.
To plan a power system or conduct power flow studies, the active and reactive power demand of all PQ nodes for any but the same period of time must be provided. The subelementInput
therefore includes the attributesTimePeriod, PowerDemandActive, andPowerDemandReactive (lines 2 to 4). In case the reactive power demand is not specified, CityMoS Power will calculate this value from the given active power demand and a power factor. If not changed in the settings, a default value for the power factor is taken.
Listing 3.9 Exemplified definition for the input of a PQ node.
1 <Node IdNode=" 2 0 0 0 0 1 " L a t i t u d e=" 1 . 2 9 9 8 9 1 4 " L o n g i t u d e=" 1 0 3 . 6 2 5 4 5 6 2 ">
2 <Input TimePeriod=" 1 " PowerDemandActive=" 6 6 . 1 4 " PowerDemandReactive=" 3 2 . 0 3 " />
3 <Input TimePeriod=" 2 " PowerDemandActive=" 6 6 . 0 7 " PowerDemandReactive=" 3 2 . 0 0 " />
4 <Input TimePeriod=" 3 " PowerDemandActive=" 6 6 . 0 1 " PowerDemandReactive=" 3 1 . 9 7 " />
5 </Node>
The regular PSP process may optionally be adjusted by additionally defining existing elements with specific properties. An example for a substation is shown in Listing 3.10. In addition to the attributesNameand Description, a substation is distinct from a PQ node by the attributeIdNodeTypeas well as its voltage level, specified by both the lower and upper winding attributeVoltageLevelandVoltageLevelUpper, respectively. No Inputsubelement should be provided as substations do not have a distinct time-dependent power demand.
Listing 3.10 Exemplified definition for the minimal input of a substation.
1 <Node IdNode=" 3 4 7 7 3 7 6 " D e s c r i p t i o n=" L a b r a d o r s u b s t a t i o n " IdNodeType=" 2 " L a t i t u d e="
1 . 2 7 0 5 3 8 9 " L o n g i t u d e=" 1 0 3 . 7 9 8 4 9 6 4 " Name=" L a b r a d o r " V o l t a g e L e v e l=" 230 "
V o l t a g e L e v e l U p p e r=" 400 " />
In the PSP process, power plants are specified as input as illustrated in Listing 3.11.
They can be distinguished from substations by a different value for the attributeIdNodeType. Additionally, attributes indicating its minimum and maximum active and reactive power supply must be specified.
Listing 3.11 Exemplified definition for the input of a power plant.
1 <Node IdNode=" 3 4 7 7 3 8 5 " D e s c r i p t i o n=" Tuas power p l a n t " IdNodeType=" 3 " L a t i t u d e="
1 . 2 8 7 1 9 9 7 " L o n g i t u d e=" 1 0 3 . 6 4 0 5 8 7 3 " Name=" Tuas P o w e r G e n e r a t i o n "
PowerSupplyActiveMax=" 2 6 0 9 0 0 0 " PowerSupplyActiveMin=" 0 " PowerSupplyReactiveMax
=" 1 3 7 4 0 0 0 " P o w e rS u p p l y Re a c t i v e Mi n="−815000 " V o l t a g e L e v e l=" 400 "
V o l t a g e L e v e l U p p e r=" 400 " />
In case specific power lines for already definedNodeelements are known in advance of the PSP process, they can be specified as shown in Listing 3.12. Besides the mandatory attributes
IdEdge,IdNode1, and IdNode2, aName as well as Reactanceand Resistancevalues may optionally be provided.
Listing 3.12 Exemplified definition for the input of a power line.
1 <Edge IdEdge=" 2 6 7 1 1 5 1 " IdNode1=" 3 4 7 7 3 8 5 " IdNode2=" 3 4 7 7 3 7 6 " Name=" Tuas − L a b r a d o r "
R e a c t a n c e=" 0 . 0 0 0 1 0 9 3 " R e s i s t a n c e=" 0 . 0 0 0 0 0 9 " />
3.3.2.3 CSV
XML files allow for an easy formal specification of their syntax with the help of XSD files. The structure of the data as well as restrictions and key, key reference, and uniqueness constraints can be specified. This advantage comes at the cost of a higher complexity when specifying data in this format. For simple tabular data or large data sets without the requirement for a formal syntax specification the CSV file format is favorable. CSV files have less overhead compared to their payload. Hence, they require less storage and can be processed much faster. When specifying hierarchical data, additional effort, however, has to be taken to avoid excessive redundancies in the data.
Alternatively to XML, CityMoS Power therefore supports input and output data in the CSV file format. Since this format does not allow representing multiple data sets with different attributes in one file, separate files for each of the XML schema’s element and subelement types need to be created. Besides a header naming all the attributes required for its use case, a CSV file also contains a body with values in a comma separated format. Although the XSD file cannot be used to formally validate a CSV file’s syntax, it is still informally used to describe allowed attributes. In Listing 3.13 and 3.14, an example for the input of a PQ node in the CSV file format matching the one for the XML format shown in Listing 3.9 is given. Since the input data is hierarchical, two separate CSV files have to be created to reduce redundancies in the output. The distributed data is linked by the node’s unique attributeIdNode.
Listing 3.13 Exemplified definition for the static part of the input of a PQ node in the CSV file format.
1 IdNode,L a t i t u d e,L o n g i t u d e 2 2 0 0 0 0 1 , 1 . 2 9 9 8 9 1 4 , 1 0 3 . 6 2 5 4 5 6 2
Listing 3.14 Exemplified definition for the dynamic time-dependent part of the input of a PQ node in the CSV file format.
1 IdNode,TimePeriod,PowerDemandActive,PowerDemandRective 2 2 0 0 0 0 1 , 1 , 6 6 . 1 4 , 3 2 . 0 3
3 2 0 0 0 0 1 , 2 , 6 6 . 0 7 , 3 2 . 0 0 4 2 0 0 0 0 1 , 3 , 6 6 . 0 1 , 3 1 . 9 7
Defining the time-dependent power demand per sector instead of per PQ node is only supported in the CSV file format. This option allows CityMoS Power to automatically assign a power demand value to each single PQ node in case it is only available on a by-sector basis.
Hereby, given power demand values for a sector are by default equally distributed to all nodes associated with this sector by their IdSectorattribute. A more fine-grained distribution can be achieved by additionally specifying theIdBuildingType which further distinguishes a sector.