当前位置:首页 >> 电力/水利 >>

pscad X4 Simulation Data Model (SIM)


Portable Information Model
Edited by Craig Muller
This document outlines the design and implementation of an Xml based model definition for Electro Magnetic Transients (EMT) Simulators and the elements to manage them from within the application. (Original document started by Craig Muller, November 21, 2005. Last edited on Monday, April 25, 2011)

Background
In the real world, computer systems and databases often contain data in incompatible formats. One of the most time-consuming challenges for developers has been to exchange data between such systems. This effort involves the development, testing and maintenance of custom file readers and writers for each of the target formats desired. When operating with a time domain software simulation. The core information about existing branch network UDC models and their design is held by a User Defined Component (UDC Each UDC definition is stored in a text UDC). based project file along with the corresponding instance data in circuit schematics. Since the instance information of one definition is stored in the definition of other models, a relationship is formed between the definitions. The format of the file is custom designed to suit the application and is not intended to be shared with other applications. Since it is not intended for other software tools to read, it is considered an unpublished storage format.

Situation
Historically, different vendors of software simulation tools would develop their own custom approach to storing network and modeling information. This information would be stored in file formats defined by the vendor with the sole intention of operating with only those vendors’ tools. This is problematic for the end user since it is often that users may be operating in more than as single vendor product due to specific capabilities that are found with one tool and no with another. If network or modeling information is common between the studies on the different tools, the task of sharing this information is difficult if not impossible. In addition, this makes it very difficult for external suppliers to read and generate these files automatically. In recent years, a drive towards enterprise solutions has lead to a push towards centralized data storage. In this strategy, the use of custom file formats becomes less attractive since there is no effective way to share the information with other tools. Further to this, the merging of information is difficult since there is no standard on how to handle this. This clearly generates a need for an accepted standard for file storage that is both well published and highly extensible. There are few possible answers to handling this need. One is to further refine the existing file format to make it more flexible. This would require the creation of detailed documentation to describe not only the basic format element, but would require the deployment and maintenance of published code to process it. In addition, there is no assurance of the internal storage of the data once it has been read in from the source file. Since the representation could differ between every external software vendor, there is little consistency in the available search and verification of the data between vendors. This generates a need to separate the core storage, retrieval, imaging and search activities from that of the target application. This way the target application needs to consider only how the data will be used and not the mechanisms to access it.

1

Target
A complete storage and retrieval mechanism that is both effective and flexible to manage diverse sets of data containment, management, tracking and searching. This storage mechanism must have a well documented and well supported design in the industry. The mechanism must have a storage strategy defining a meaningful and extensible paradigm for application in the domain of power systems simulation.

Proposal
Breaking away from the old model of custom files and custom structures takes a first step. Since the design of the structures has many dimensions and needs, it would prudent to start with a good base. A solid wall comes from high quality mortar. In the context of data storage and sharing, this mortar comes in the form of a baseline strategy for general data representation. Files store bytes of data and that are stored as representations of characters (ASCII) or memory images (BINARY). The latter is effective when large volumes of similar data patterns are used, such as data streams, but not well accepted for flexible data environments where human readable forms are preferred. This situation is not uncommon in industry and a fully mature representation is readily available using eXtensible Xml Markup Language (Xml If ASCII files were the mortar of the predecessors, Xml can be thought of as a better Xml). mortar. Layering a simple but effective language construct to text files and then providing memory structures to represent it along rich set of manipulation tools creates a very flexible and powerful foundation material. This approach slowly appeared throughout the software industry and is now more prevalent in the software for power systems.

But could it be that are we all boiling frogs?

It would seem unlikely that the presence of Xml as the de-facto standard is a bad thing. Evidence shows that it may not always be easy to share information between different systems, but that the common practices encourage cooperation. All that is required for cooperation then is a high level viewpoint of the data structures. Standardizing all system state files to the Xml format, including the UDC information contained in the project files. Xml has the key capabilities of standards, documentation, portability and a rich feature set of implementations available. These features provide the baseline mechanism for smart storage and retrieval. The addition of an Xml layer to the problem space does not in itself create a solution. What it does do is extend very basic storage and retrieval methods for text files with a structured text model that has a corresponding structured model in memory. The addition of structure to storage gives new abilities to the basic libraries to include a rich set of extended behavior for validation, searching, appending, removing and modifying of text elements from the document. Ordinarily, all these functions and storage structures would be created by the application operating on the data. Rather, this provides a common baseline for all these activities. Xml also has its detractors. Given this baseline structure, it does not provide organization. Organization of the Xml elements and fields is a critical part of the design process, impacting ease of access and manipulation to the document. The same factors that govern the organization of the application software can also be applied to the organization of the data. If the storage strategy is not well thought out, working with the information can be arduous, leading to a lot of work to access a small amount of information. In addition, a poor storage strategy can lead to difficulty when attempting to extend the structure, or to add elements dynamically. For these reasons, certain basic guidelines were utilized in the design process:

2

1. Similar activities in the software should be identified for common design patterns. These common patterns should have a corresponding structure in Xml that can be reused at any level in the document. Reusable implementations of these patterns should be provided in a shared library of tools. 2. Generic field storage must be designed such that elements can be created and added dynamically. This means the fields are not known in advance to the creation of the document. As such the fields must be definable at runtime but still satisfy the conditions of the schema document. 3. The strategy must support the addition of meta-data (data about the data) to the document. In this context meta-data is new information that is created by the application by analysis of the existing data. As such it is not added by the user, but inferred by the relationships existing in the structure. 4. The strategy must support the process of data mining to create new Xml for use in compiling and reporting. This includes searching the document using XPath and producing effective output listings. 5. The strategy must support the addition of raw data blocks for use by the target application. There are often situations where data is too specific to the target application that it has no need to be fully qualified or shared with other tools. This can be used to store custom data for interpretation only by the target.

3

1. Network Representation
When working on Electromagnetic Transient Analysis (EMT) using a Power Systems CAD (PSCAD) software tool, a high degree of detail is required. This detail is a critical input to the software, enabling it to perform metaprogramming to produce a simulation of the system. Unfortunately, the breadth of programmatic solutions to the problem by vendors and research groups is very large. In addition, some software solutions are intended to function along with hardware solutions, influencing the approach. The generated code can vary in language (FORTRAN, C, C# and Java), producing different programming models which must also be addressed. Given wide variety of solutions already out there and the need to create a single network representation, the best way to attack this problem is to start from the basic and work top-down from the high-level viewpoint and work into the details. The network diagram is the key to building a structured system. It is the network that provides the relational information between the models in the system and thus defines the entire behavior of the model containing it. Power systems software usually uses simplified notation such as a one-line diagram and point/path relationships to model behavior. The schematic diagram takes the form of a flow network or flow circuit and is drawn using two basic wire elements, nodes and branches When this concept is applied to a power system environment, branches. the nodal points are called buses, since it is typical for a bus bar to contain a coordinated set of node elements corresponding to the number of phases in the system. This allows the representation to work with a simplified one-line representation, while internally retaining the individual elements for the nodal network. The flow network is a very simple set of buses and relational elements that provide energy transport between live buses or energy conversion between any given live bus and the ground bus. The relational elements are the branches. Each branch element connects to one, two or three buses using interface points called ports This is ports. the very high level view of the network that does not consider a lot of the network detail.

Flow Network The flow network is flat, and represents the highest level representation of the network. At this level, the network can be viewed as an aggregation and does not require complex data structures to store and represent the objects in the network. Objects in an aggregation, do not have ownership responsibility, and can be created and destroyed in isolation from one another. The objects are related to one another through links that specify how one object may interact or influence the other. Since the representation is simplified, it provided basis for sharing between multiple solver engines using table based storage. Table formatting is very typical for frequency domain software tools. The top-level representation is the only part of the network that is stored in the common tables. In any system representation, the ground bus is not a visual element; rather it is an implicit bus that always exists providing a reference voltage of zero and is represented by a node zero. Node zero is reserved for this purpose in the data representation. The Common Information Model (CIM) is a standard adopted for transmission and distribution as IEC 61970-501. CIM uses standard relational model and the Resource Description Framework (RDF) to describe a network of wires and the common vocabulary to define a power systems network. It has become more prevalent in the simulation area since it provides an effective network model using XML and standard methods for information interchange. The model provides tables of entities that represent both real entities in the network as well as attribute based entities. Entities exist that represent the nodes and ports in the network and utilize the

4

relationships provided to tie together the electrical entities. RDF ‘triples’ (subject, predicate, object) provide an effective way to build up nodal network of both real and abstract objects.

Relational Graph The simple network graph is supported by the subject as the starting point, the predicate is the line relation and the object is the target point. Since the approach is very general, the relations can represent both the real network terminations (such as a transformer terminal associated to a busbar), or abstract (such as a base voltage associated to a collection of equipment).

Network Connectivity modeled in CIM-RDF (From IEC 61970-301) The graph is a super-set of the flow network since it contains many more objects that represent abstract entities, above and beyond the actual electrical nodes in the network. Real network connections are shown where terminals (black dots) touch connectivity nodes (circles). Real objects are shown as solid-border boxes, whereas abstract objects are shown by dotted-border boxes. Measurements are shown as callout boxes. Storage of the data elements in Xml uses a simple flat list of object entities. Each entity has a unique rdf:ID attribute along with a set of sub-elements that describe properties of that entity as either literals (body text) or object relations. Each relation is described using a predicate tag and an rdf:resource attribute that identifies the ID of the target object. A sample of a bus bar section object is shown below.
<cim:BusbarSection rdf:ID="_56B490DCE34B0D1FE04014AC92606106"> <cim:IdentifiedObject.name>160</cim:IdentifiedObject.name> <cim:Equipment.MemberOf_EquipmentContainer rdf:resource="#_56B490DCDDEA0D1FE04014AC92606106" /> </cim:BusbarSection>

5

The bus bar is a real object in the system and thus has a real representation within a schematic diagram. Other objects provide abstractions to support connections, but do not map well to schematic diagrams for simulation tools. This is the case for a connectivity node.
<cim:ConnectivityNode rdf:ID="_56B490DCDCD60D1FE04014AC92606106"> <cim:IdentifiedObject.name>179</cim:IdentifiedObject.name> <cim:IdentifiedObject.pathName>ECAR ECAR MARTDALE 345 179</cim:IdentifiedObject.pathName> <cim:ConnectivityNode.MemberOf_EquipmentContainer rdf:resource="#_56B490DCDDE80D1FE04014AC92606106" /> </cim:ConnectivityNode>

The Connectivity Node provides an object that real equipment can connect to and thus describe the network topology. Simulation environments tend to use wire objects for this purpose instead. As a result, the schematic tools include a physical grid to provide shared coordinates. The sharing of coordinates acts to provide the connectivity. The CIM standard provides a number of class packages to define entities for the application of an energy management system. These packages contain many more entities and attributes that exceed the needs of a PSCAD as it stands today. The goal here is to identify the packages and entities that are relevant for the software tool in describing the flow network as an aggregate. Currently, simulation tools analyze the existing schematic diagram to generate a network listing dynamically. This network list has many commonalities to the schema described by CIM and thus creates a compelling argument to develop a strategy that is compatible with the IEC standard. The two basic wire classes defined in the flow network are described by the Topology and Wires packages. This can be directly related to the schematic structure in the simulation software and the nodal network formed when the schematic diagram is compiled. The incorporation of compatible representations in the network listing enables the software to exchange data with existing CIM resources while retaining functional compatibility with existing simulation projects. While the CIM model provides relational information about the network configuration, it does not provide any mechanism to store simulation specific information about the simulation models or the schematic diagram required to support the visualization of the network in a software tool. For example, a transformer in the network is described in terms of basic information about parameters and terminal points, but not information is available to simulate time domain behavior. Depending on the software tool, this information can be quite extensive and include information that is only specific to the software internals. This requirement is exceedingly complex for the UML semantics described by the standard. In order to capture the information needed by the software tool, custom storage strategies are required for internal data that are unique and generally not shared with other tools. Since they are not shared, they do not need to conform to a standard model framework and can opt for methods and techniques that best suit the software tool for efficiency and flexibility. An example of a partial flow network, containing BusBars, Generation, Loads and Lines visualized in a power system simulation is shown below:

6

Flow Network View The flow network acts as a root level representation of the system. To simulate the system in the time domain, not enough information is provided in the flow network alone, and it must be extended to provide the detailed modeling information in each branch entity. Extending the existing information is problematic, since these extensions create a new set of data that is not consistent with common storage. Rather than extending existing table based data storage, it is possible to provide a second tier of data storage, designed to support the software detailed needs for simulation, that has a distinct interface point with the table based network representation. This can be achieved by overlapping the simulation detail at a top-level branch and representing each by a composite network model.

Flow and Composite Network Relations

The level of detail required is dependent on the type of simulation engine that must operate on it and the type of network being represented. This was a critical design strategy of the data representation because it was necessary to provide modeling capabilities that were as simple or as complex a necessary. This meant that the branch model could represent something as simple as three phase load, or something as complex as an HVDC link or a distribution system. The branch detail is represented by as much or as little detail required while adhering to a well defined interface methodology. Decoupling the top-level network from the detailed information provides a mechanism to add and remove information dynamically without affecting the base network representation. In composite network schematics, the representation includes a number of new elements that support the representation of model controls and data visualization. The use of wires as connective devices establishes input and output ports for control models that are separated by the physical layout. This is a familiar representation in electronics design. The hybrid data representation utilized both an aggregate storage strategy for top-level flow networks and a composite storage strategy for detailed modeling at each wire model. 1. Flow Network Rooted at the top-level of the network representation, it is governed by a homogenous Network: aggregate of wire models, each having between one and three ports. The network connectivity is fully described by linking each port to a corresponding busbar.

7

2. Composite Network Rooted from inside a top-level branch model, it is governed by a heterogeneous Network: collection of both primitive and composite components. Unlike the flow network, connectivity is not described by linking. Rather ideal wires provide object connection mapping between the component ports. Both natural networks and sequential processing for control systems. Control ports are defined by a source/sink relationship forming sequential processing statements in Backus-Naur Form. With this design, one can then navigate into any branch model and view the network details inside. Since a branch mode contains a detailed network, that network can, in turn, contain more detailed network models. The end result is the system forms a hierarchy, rooted at the top by a flow network. Unlike the top-level network, the detail described in the modeling below requires significant data structures to maintain them. The information is broken down into different functional sets that are built up from smaller primitive types into a composite. In turn, more complex composites can be built other composites. The end result is a model structure with sufficient detail to support time domain simulation, yet layered to include state based solvers. Storing this information is not well suited for an aggregate relational system, since there are implied relations in the composition of the objects that are not easily represented. Members of a composition have owners that are responsible for their life cycle. Composites can be manipulated to change ownership of members if required. These owners are not explicitly stated, but rather are implied by the organization of that data. Relationships like this cannot be effectively stored using a table based approach, but are better suited as a data hierarchy. Composite structures can be effectively represented using a hierarchy since the organization provides all the implied relations needed to support the detail. Each hierarchy is represented in Xml using the Document Object Model (DOM). Unlike table based storage methods, the hierarchy of the document model provides support for classification of information into taxonomic scheme. This is very effective for organizing complex information into logical groupings for processing and handling with a PSCAD software tool. Thus the detailed information about one component model can be completely exclusive from the information about another component model. Manipulating a single element in the DOM automatically encapsulates all of the information contained within the descendants of the element, thus treating the collection as a single object. This is a very important behavior of visual interfaces in software tools that must present a composite pattern of objects such that it appears as only a single object. It is natural for humans to think in terms of a ‘car’ as a single object rather than all the individual objects a car is assembled from. Humans do not need to know all the details of how a car works to drive it, only the information about how to interface with it. From a software design standpoint, it is less complex to treat composite components and primitives in a homogenous fashion, since the code is virtually identical and requires least knowledge of the descendent elements. Depending on the type of simulation, in PSCAD, it is possible for extended electric networks to be formed inside the hierarchy. These extended networks are provided to support a higher level of detail often needed for time domain EMT simulation. Since the electrical network is not a natural hierarchy, additional electric network elements represented in a document must be processed to establish network meta-data that tie all the network nodes into a matrix. This matrix forms the simultaneous solution for the simulation. This combination of a high level network aggregate representation using tables and a detailed model representation using a composite pattern is utilized to create a complete hybrid model of the power system for use in simulation software tools. Combining the two strategies together at well defined points in the visualization, allows the software to represent that system once, but allows many different types of solution engines to use it. The critical decision in organizing the information is to determine the nexus point between the high-level flat representation and the detailed hierarchical representation. If we consider a distribution network, the application of the data is similar but not the same as a transmission network.

8

Distribution System Modeled in PSCAD When viewed from a high-level, the network appears simple to represent, but as you drill down into the detail the presence of unbalanced items in the network creates phasing complexities. By design, the assignment of phases is assumed to be in order of A, B and C corresponding to the first, second and third element in the storage array. On occasion, an exception must be made when the normal rules are not followed. Alternate phasing could be expressed using a simple integer offset where the sign indicates the direction and the value indicates the offset from the base. In addition, the modeling requirements need further detail to represent it for time domain simulation. Below is the portion of the detailed view of the same network.

9

Detailed Load Models

Composite Network View in PSCAD Since there are two storage strategies working together on a single representation, a certain amount of overlap is used to provide the same information for both the aggregate and the composite representations. This overlap can be maintained using an automatic synchronization between known fields, thus state base solution tools are not required to access and manipulate information stored in the composite model and reducing software complexity. When using steady state solvers the results are pushed back to the flow network representation, thus closing the loop and turning the solver itself into a relational engine. Since the flow network is stored using tables, addition fields to support output state information are provided. The solver performs numerical analysis on the existing state to calculate new table entries that can be used as input to queries using tuple relational calculus. The result of the queries forms the basis for an output report or other activities. XPath can be used to form these queries programmatically and used as starting values for input to a timedomain simulation. The time domain solver is thus able to start its initial state closer to the desired point saving a significant amount of computation cycles. This is an important design challenge since the algorithms used to solve power systems in the time-domain is fraught with computational complexity that requires intelligent application of information and approximation to reduce the amount of resources required to solve a problem as the problem space grows in scale. The application of network equivalence techniques applies to both the aggregate network and the composite modeling to provide approximations that reduces the problem space such that a solution can be determined in a reasonable time frame. In this context, a reasonable time frame refers to exponential time where the cost of resources does not exceed an economic benefit. Equivalent network effectively reduces the size of the exponential function for any given system. This discussion has outlined the representation of a flow network and visualizing that network using an already existing standard. There is sufficient functionality in CIM to define flow networks as a relational network database. Parts that do not existing can forma an extension to be used as necessary. The next step in the process is to define the modeling strategy for a single branch in the network. The strategy here is the same one that will be used for all user-defined branch models, so it is important to be feature rich and adaptable to changing circumstances in the target software.

10

2. Composite Model Definition
With the basic design for a composite model in place, what is left to describe is how that model is stored and represented in memory. The composite network is a complete model definition for a single branch model in the flow network and or any composite component residing with the schematic diagram. Since one composite model can consist of instances of another, complex structures and networks can be formed from relatively simple implementations. In addition, models can be create in multiple instances allowing the designer to reuse patterns already established without duplication them. It is the role of the network processing engine in the software to develop networks dynamically. This is an important distinction from the aggregate model used in CIM, where the entire network is already determined in the RDF triples. Whereas the flow network is fully described in advance, the composite networks are generated dynamically. From a design standpoint, this has a key advantage in providing an environment where complex structures can be created and modified using modular approach. At the top-level the network is viewed as a flat design, where all the relationships are explicitly defined and the amount of system information is well defined. Once you traverse into a branch, the network is managed as a hierarchy. It is natural for the user to work in different levels of detail depending on the situation. With a hierarchy, the system can be created in greater detail as one navigates deeper. The level of detail is under the control of the designer. This level of detail cannot be effectively described by the flow network.

Sample Composite Network with Mixed Detail To create the composite network, a definition of a signal composite component is all that is required. Since each can contain instances of another component, complex network can be created from a single design. In the example given above, a top level branch is expanded into detailed tower sections with transmission lines between the segments. Each tower is the then broken into further detail to perform precise measurement functions. To create a composite component, 4 key functions must be provided: Configuration, Visualization, Network and Scripting.

2.1 Configuration
The configuration information is included as parameters to the component that are available to every instance of a composite component. Since they are attached to the instance of the object it provides means to use the same model in multiple instances and configure that model accordingly. These parameters are created in a

11

default state when the component is first created and then can be modified from there. The definition of the form provides a structure for manipulating, interpreting and validating the contents of the parameter value.

Dialog Fragment for Transformer Configuration

2.2 Visualization
Visualization control defines the interface in terms of graphical display and termination ports. With a visual interface the instance can be manipulated on a schematic diagram of the user interface. In Xml a standard for vector graphics exists called Scalable Vector Graphics (SVG). SVG is a W3C standard for vector based graphical drawing. It is well documented and has a very rich feature set. In the application here, only a sub-set of the specification is implemented as it relates to the component display. One attractive feature of the specification is it allows for the definition of custom child elements that are not part of the specification. Component ports (terminals) are a critical requirement, yet are unique to this implementation of the visual interface.

SVG Transformer Showing Terminals Ports

2.3 Network
Network control defines behavior of the composite component in the simulation using a schematic network topology of other component instances. Since the network can include instances of other components, complex structures can be created using a collection of simpler primitives. The inclusion of other component instances that also have schematic diagrams creates a hierarchical network that forms the basis for detailed simulation. The network components include classes of components designed to represents real elements and other classes that are designed purely to support the user interface and convey information back to the user when simulations are performed. The user interface collection can be placed on the schematic but do not have ports or any rotation capabilities. They are linked to other components to play a support role by providing a defined recording point in the simulation that is stored as waveforms.

Recording Device Composite Network Fragment with Recording Components

2.4 Scripting

12

In components that do not have a schematic diagram, called primitives, scripting is provided to define the core behavior of the component. Scripting is essentially a series of raw text sections that are used to store custom implementations. Since the software has a long history of defining component behavior through scripting it is critical that this capability be retained moving forward. Since no scripted component can contain any other component, all components are considered leaf nodes in the simulation tree. The scripting interface is essentially a raw interface that allows the software to design its own mechanisms for the component. These are typically software interface points for custom code and software libraries used to support the simulation. The details of that mechanism are not described in the Xml schema. Models are able to provide information to the application for simulation by either providing a scripted network topology with source code to define the function calls and program code or by defining a schematic diagram.

Script Fragment Defining Winding Branches in a Transformer

13

3. Composite Network Schema
Advanced software tools to perform design and simulation utilize Model-View-Controller (MVC) architecture. The model represents the domain specific data, the view presents results to the user, and the controller collects user input. This is an effective way to build a practical and extensible user interface tool around the model data. To visualize the network, the software tool creates component objects on a canvas and locates them at given coordinates to form a schematic diagram. Each component provides view and control that is intimately linked the data behind it so that actions performed generates a response that changes the data behind it. The data behind, in turn, reflects those changes back to the schematic diagram so that the user can see what is happening. This creates a closed loop user interface. A simple schematic view of a composite network with two ports is shown below:

Composite Schematic View with Both Natural and Control Ports

In the schematic diagram show here, natural ports are tied together with wires to form a simple network, which are externalized using special components marked as ‘in’ and ‘out’. Three transformers are wired into the network which is scalar on the inside and 3 phases on the side of the input/output ports. The phases are mapped using a special breakout component located on either side of the network. A single control port exists on each transformer. The control port acts as a sink to the source port coming from an array tap which, in turn, is a sink to an external import component. The control signal is an array of 3 values where each value is tapped off the array accordingly to each transformer. To reduce complexity of the data representation, bus bar phasing at the flow level is fixed to a dimension of three. Similarly, all the ports for any given branch are all dimension three. Parts of the system that are studied using n-phase representation are modeled in the branch detail.

14

Model structures are defined as a hierarchy of sub-structures qualified by keywords and content. This is a DOM document model that matches the Xml Document Object Model. "The W3C Document Object Model (DOM is a DOM) platform and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of a document." The DOM provides a standard set of objects for HTML and Xml documents, and a standard interface for accessing and manipulating them. The Document Object Model method involves parsing Xml documents into a target neutral format in the local memory storage. This storage forms a tree structure of homogeneous element objects, attributes and character data that can be randomly queried at any time after the parsing is complete. This is the most flexible way to manage Xml information, but also a slower and more resource intensive method. Since it is in memory it is also volatile. An Xml file is the persistent or non-volatile image of that storage device represented by ASCII characters. When working with legacy data files, the import and export functions must be custom designed by each application, converting custom storage architectures to an Xml equivalent representation in memory. In most applications, custom structures are created for the purposes of manipulation and processing of data. These can be visual elements on the display screen in the form of navigation trees, schematic components or tables and lists. Retrieval of the complete software state is now defined as a two step process. The first step is to import or read the data file into an Xml Document in memory. The second step is to parse the Xml Document and synchronize the internal state of all the peer objects with that of the document. Listeners to the document trigger the synchronization whenever the document changes state. Storage of the software is state similar, using a format action to push the data from the peer back to the Xml Document. Format actions occur when the user interacts with the objects in the user interface. Formatting is executed on a continuous basis using object response methods. This keeps the document and peers in sync at all times. Export to a legacy file format is not required, but can be provided for backward compatibility.

psc

import
DOC

parse

Peer Data Structures

pscx

read
Import/Read to the Document

psc

export
DOC

format

Peer Data Structures

pscx

write
Export/Write from Document

To support the Model-view-controller design strategy, a mechanism called reflection is responsible for invoking a factory method to construct peer objects on the view. The data is therefore driving the behavior of the software and thus the instruction about how to maintain the view are governed by the programming rules associated to the data elements in the Xml document. Since the application may depend on temporary objects to interact with the Xml, these structures must be constructed and kept in synchronization at all times. These temporary objects are called peers and serve a purpose to represent the data in the document using a number of different peers, interfaces. These interfaces provide the only means of interaction between the user and the document. Peers must be defined such that they can support the incorporation of derivations. This means a base element is created, but by declaring a derivation class, the object can take on changeable behavior at runtime. 15

The response of the peer back to the document is up to the application. The strategy of when to push information back to the document depends on the type of object and the state of the program. Certainly all peer information must be pushed back before the document is stored to an Xml file. Defining a network model requires the organization and storage of information that describes both the visual interface and behavior of the component. This information is required so that the software can generate a user interface element as an interaction point. In the design of a hierarchical system, the behavior of any network model can have as a sub-set, the behavior of any other network model (save itself). This allows the user to define complex systems from the building blocks of simpler systems. It is a classical object oriented design approach that is both effective and maps well to code generation in software. Since the software is an object oriented design tool, every component requires two sets of information. One is the parameter information that is attached to every unique instance of the object. The other is behavior information that describes how the component will behave given the definition. Any model is defined once but can be used many times. The parameter information for each instance of a model can be different, thus allowing each network instance to behave in a unique fashion based on the definition.

Named Value Parameter Lists
Throughout the Xml document, elements may have a one or more child <paramlist>. The purpose of this element is to provide a general purpose named value parameter storage mechanism that can be dynamically extended at runtime and still pass Xml validation. Xml validation is based on schema documents that define in advance all the possible elements and attributes and how they may be organized within an Xml document. In the case of user defined models, it is not known what the attribute will be used in the model until it is created and thus no pre-defined schema can be created to support validation. To support runtime creation of new parameters an organized list is utilized as children to elements in the structure. These lists follow a standardized design pattern that can be reused anywhere with the software to add parameter information. They provide general purpose storage of object variables. In code, utility routines are created for general manipulation and validation of the lists. An example of one is shown below:
<paramlist name="set1"> <param name="Tmva" value="0.5 [MVA]" /> <param name="f" value="$(FREQ)" /> <param name="Xl" value="0.000001 [pu]" /> <param name="NLL" value="0.0 [pu]" /> <param name="IL1" value="" /> <param name="IL2" value="" /> <param name="IMAG" value="" /> <param name="FLUX" value="" /> </paramlist>

The lists contain homogeneous sets of <param> each containing a ‘name’ and ‘value’ attribute. When the document is validated, the list is validated to ensure it is well formed, but the attribute data is not. This allows new fields to be added at any time and still pass the schema validation. Validation of the data is the exclusive responsibility of the object that they are associated with. The object may choose different approaches if the data is considered critical or only optional. An object in the document may contain multiple instances of <paramlist>. This is often utilized when multiple contexts are possible for a single object and it is important to select the correct data for the given context. A name attribute may exist in this case. This allows the object processing the data to select the correct set of parameters based on a given value for the name.

16

For clarity, the <paramlist> are often not included in the Xml listings here so that the more critical points can be highlighted. This prevents the text from being overloaded with parameter information that is not relevant to the discussion point.

3.1 Schematic
When representing this schematic diagram in Xml, elements are created that store the instance data for each component on the schematic. Each instance is represented by one of several possible child elements to <schematic>. In this diagram most elements are either <User>, representing instances of user defined components or <Wire> representing the wires connecting them together. A finite set of element tags are defined for the schematic diagram and they are listed here. A sample snippet of Xml body is shown below:
<schematic classid="UserCanvas" ...> <Wire classid="WireOrthogonal" ...> ... </Wire> <User classid="UserCmp" ...> ... </User> </schematic>

What is important to note in the segment of Xml data is the addition of a classid attribute to each of the elements found as direct children. The purpose of this attribute is to provide a mechanism to support an abstract factory pattern allowing the element to specify what type of concrete component to construct at runtime. This provides a means to create derivations of a base element without breaking the schema validation of the document. This is a key addition to the schematic allowing the future inclusion of derivations without changing the base tag. This is very important since it allows for extension of the Xml representation to occur through data rather than hard coding in the schema. The down side to this is it does require the software to perform addition runtime validation. This is not difficult since the factory method is capable of doing this action and reporting in situations of failure. In this design a taxonomic containment hierarchy is formed and the Xml element is referred to as a phylum tag. These tags are base tags to support the creation of a rich set of ‘class’ peer elements in the user interface.

3.1.1 Wire
A <Wire> is base to all wire component types and is the most fundamental type of object in the schematic representation. It can be formed into two basic sub-types that are used for representation of the entities in the flow diagram as well as within the composite network as well. A peer component is created in the schematic diagram using a factory method identified by the classid attribute. It is the concrete class of object that defines both the sub-type and the final behavior of the object.
1. 2. 3. 4. 5. WireOrthogonal BusBar WireBranch Cable TLine

The two basic subtypes for wires are ideal and non-ideal. If the sub-type is ideal, then by definition the wire is considered zero-impedance along its length and all ports connected to that wire are connected to the same node in the network (if the ports are natural) or connected to the same signal in the controls (if the ports are transfer). An example of an ideal-wire model in Xml is shown below.
<Wire classid="WireOrthogonal" name="" id="0" x="216" y="324" w="152" h="98" orient="0"> <vertex x="0" y="0" /> <vertex x="0" y="-90" />

17

<vertex x="144" y="-90" /> </Wire>

Ideal Wire, showing vertex points

Wire Relationship in the User Interface Since the wire is schematically represented by a variable number of vertex points, <vertex> children exist in a variable length list to define the wire path. Each vertex represents a coordinate point on the diagram. When a component port aligns with the same coordinate point of the wire they are considered connected. In addition, for ideal wires, the body of the wire is also a valid connecting point. In the example given, there are two components with ports connected to the ends of the wire, and one component whose port is connected to the body of the wire. All ports will be connected to the same node in the network. If a wire has more than two vertexes, then it is multi-segmented. Ideal wires always have both the body and the ends of the wire connected together. This enabled them to be used to tie together parts of the schematic diagram to form a network. When operating in the flow schematic, the concrete class is extended to create a BusBar. A BusBar is an ideal-wire model designed to represent a BusBar section within the high level network.

Bus Bar Component Since the schematic diagram must provide mechanisms for users to wire together components, most ideal wires found in the composite network are not declared or anonymous. Anonymous wires will form nodes in the network that are automatically assigned by the compile process. This assignment is temporary designed to support the mapping of information used by the time-domain solution. A Bus Bar is a specific derivation of wire class that provides a declared node in the network. A declared node is one that is given a specific ID value for reference by solvers operating in the flow network. Every Bus Bar has a unique ID and optionally a non-unique name. In the example given the non-unique name is “BUS1”. Non-ideal wires comprise the remaining concrete classes in the set. All non-ideal wires must be declared and linked to a resource that defines the behavior of wire. The base for the non-ideal types is the WireBranch and this extends into travelling wave models in the form of a Transmission Line or Cable. Each of the non-ideal types requires a supplementary model that defines its behavior in detail. When the modeling is performed by a travelling wave solver, the name field provides identification of the corresponding line definition. Since the processes for modeling a wire by this method is well defined, all that is required is the corresponding reference. This model can be a detailed composite model or one of the travelling wave models. This is attached by placing an element as child to the wire.
<Wire classid="TLine" name="SendFeed" id="315322553" x="360" y="234" w="194" h="46" I="0" J="0" K="0" orient="0"> <User classid="UserCmp" name="SendFeed" x="0" y="0" z="-1" orient="0" id="315322553" link="315322553"> <paramlist link="-1" name=""> <param name="Name" value="SendFeed" /> .

18

. . <param name="CoupleName" value="ROW11" /> <param name="CoupleOffset" value="0.0 [m]" /> <param name="CoupleRef" value="0" /> </paramlist> </User> <vertex x="0" y="0" /> <vertex x="18" y="0" /> <vertex x="54" y="54" /> <vertex x="72" y="54" /> </Wire>

Transmission Line Component In this example the transmission line is linked to a model named SendFeed that defines the behaviour of the line when it is solved in the time-domain. Since the modeling for time-domain must consider the effects of coupling between lines within the same Right-Of-Way (ROW) the component provides an additional tag that informs the solver of the lines sharing the same physical space. The solver will considers the proximity effects of all lines have the same coupling tag. In the example given the tag is ROW11. If the wire is modeled by a composite instead of a line model, then the network must be described. Only branches in the flow network can be modeled as top-level references to a component in the composite network. In the composite network, all non-ideal wires use the line model. The top-level reference is achieved by adding the instance of the composite network component as an element under the wire.
<Wire classid="WireBranch" name="Main" id="228310162" x="180" y="180" w="80" h="62" orient="0" I="0" J="0" K="0"> <paramlist> <param name="Name" value="" /> <param name="Date" value="-1" /> </paramlist> <User classid="UserCmp" name="Main" id="228310162" x="0" y="0" w="0" h="0" z="-1" orient="0" link="228310162"> <paramlist link="-1" name="" /> </User> <vertex x="0" y="0" /> <vertex x="18" y="0" /> <vertex x="54" y="54" /> <vertex x="72" y="54" /> Wire linked to a </Wire>

composite network model

Wire Modeled Using a Composite Network 19

External Ports

Actual Implementation If the user drills down from the flow network to the composite network it exposes the actual modeling used to define the branch. For this to work the composite network must have exactly the same number and type of ports used by the branch in the flow network. In this example the modeling is a simple two winding transformer, but the amount of detail that can be included at this point is unlimited as long as it matches up to the ports defined at the top. With the exception of the exported nodes any other nodes created internally are not declared at the flow level. By design the internal nodes will not create additional phantom buses at the flow level and not come in conflict the bus listing designated for the common tables. Ideal wires that are used to define the control signals for sequential processing are not involved at all at the flow level. The control networks are purely defined for use with time-domain simulation and are not seen by steady state solvers. Recording Device

Fragment of a Control System Using Ideal Wires for Sequential Processing It should be noted at this point that the precise handling of controls systems within a time-domain simulator varies, and it is generally up to the target software to decide how the control networks are formed. This distinction is provided for the purposes of separating the two functional parts of the system if required. The data representation is same in all cases, just the type changes between the wires, thus retaining portability.

3.1.2 User
A <User> is base to all user defined component types. It is called this since it is designed to be highly adaptable to user level requirements. It is a critical type and binds together the relationships in hierarchy of the composite network. A peer component is created in the schematic diagram using a factory method identified by the classid attribute. Unlike other components in the schematic diagram, this object is instantiated from an existing definition object. It is the definition object that is responsible for modeling the behavior of the component in conjunction with the instance properties associated with the component. Since the definition is dynamically controlled at a user level, the instance must link itself to this resource using a unique name attribute. To completely define the user level object both a factory class and a runtime definition model must be provided. A sample component instance is shown below:

20

<User classid="UserCmp" name="master:xfmr-2w" id="1118812865" x="396" y="360" w="74" h="78" z="50" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Tmva" value="0.5 [MVA]" /> <param name="f" value="$(FREQ)" /> <param name="Xl" value="0.000001 [pu]" /> . . . <param name="FLUX" value="" /> </paramlist> </User>

The definition of the model is designed to support multiple states. When an instance is created, by initial state of all fields is filled with default data. This default data is required to ensure that the model is in a valid state for simulation. If no instance data is provides, then the model would appear in an undefined condition as shown below:
TapI Tap

%Tmva %Tmva %V1 / %V2 TapI #1 #2 B #1 #1G1 #2 B1 N1(3) G2
A1

A

A
A2

#2 N2(3)

B
B2

C
C1

%V1
G1 G2%V2

C
C2

G1

G2

Raw Model without Instance Data Once instance data is provide, the component can process the data to determine a valid state and present that to the user as something more familiar. The same transformer model with instance data applied appears as below:

Peer Component in the User Interface To coordinate the sharing of multiple projects within the simulator environment, it is important to distinguish the network models from each other when they share the same name but are located in different projects. This distinction is provided using an instance namespace that is prefixed to the model name. It is important not to confuse the instance namespace with that of the Xml namespace that this document is a part. The instance namespace is provided a dynamic user level control over the linking of instance data with desired modeling information. Each model definition is provided a unique name with the context of a project so that it may be identified. To further provide support for the inclusion of information from a project used as a library, each project must be afforded its own name identifier. This prevents situations where the name could be ambiguous if it is found in multiple libraries. To provide a proper namespace, the Xml document for each <Project> has been given a 21

‘name’ attribute. This name attribute is not connected with the file name and thus can be used effectively to provide a consistent namespace to component instances without being affected by file name changes in the file system. In addition, since the document may come from a system that is serving up the document, file names could not even be used in these situations. When model instances are added to a schematic diagram, the information that connects the instance of the component to the definition is bound by the name attribute of the element <User>. When new component instances are stored in the schematic diagram, each instance is now fully qualified by a context namespace and a definition model name. This ensures on reload that each component can find precisely the definition required to complete the resolution, regardless of the order in which the project documents are loaded into the workspace. This will allow more than one user definition to have the same name but in different project scopes like master:multimeter, mycase:multimeter, or mylib:multimeter. The value of the ‘name’ attribute for user instance will adopt the new format. The scoped name format is name = namespace:name.

3.1.3 Instrument
An <Instrument> is base to instrumentation components. Instrumentation components are part of the user interface support collection designed to link to other components tied into the simulation. Their existence has no impact on the simulation, only to convey information visually back to the user. These components are not containers, but rather standalone display devices, driven by the update system as a simulation is executing. The ‘classid’ can have a value of one of the following classes:
1. 2. 3. Oscilloscope PhasorMeter PolyMeter

<Instrument classid="Oscilloscope" name="" x="198" y="270" w="126" h="162" title="untitled" id="18093058" link="25175160"> . . . </Instrument>

An oscilloscope is design to present a standing wave representation of a periodic signal. Internally it has the ability to trigger and display a portion of the waveform for one or more cycles.

Instrument Component in the User Interface
<Instrument classid="PhasorMeter" name="" x="342" y="162" w="162" h="198" id="28619802" link="25248992" title="Generator Angle"> . . .

22

</Instrument>

A Phasor Meter is an instrument design to display complex phasors on a dial display. It has the ability to accept multiple arrays so that multiple phasors can be displayed on the same instrument for comparison purposes.

Instrument Component in the User Interface
<Instrument classid="PolyMeter" name="" x="1134" y="432" w="648" h="144" title="PWM Output Spectrum" state="1" hash="48638545" link="24169608"> . . . </Instrument>

A Poly Meter is a gauge design to display an array of values as a series of vertical bars. This instrument is typically used to display spectrum graphs where each value in the array is frequency harmonic, but is capable of displaying any set of real numbers within a given range.

Bar Gauge Device

Instrument Component in the User Interface

3.1.4 Frame
A <Frame> is base to all frame type displays used for plotting. A frame component is a composite class of object that is capable of user-level containment other specific composite component types. Frame elements will contain sub-elements. Since the child elements are not top-level, they are handled entirely by the frame object. Using the classid, the factory method can create a concrete component one of the following types:
1. 2. GraphFrame ControlFrame

23

If the concrete class is a GraphFrame, <Graph> children define the presence of graph objects in the frame. Every the graph object can be constructed from a known set of possible concrete classes defined by the classid attribute. Like the frame object, a graph is also a user-level container that can accept other know composite types. Inside the <Graph> are <Curve> children defining the presence of curve interfaces in the graph. The ‘link’ attribute tells the application what ‘id’ to look for when searching for the corresponding input/output device. A sample of Xml code showing a frame container which graph containers and curves is shown below:
<Frame classid="GraphFrame" name="frame" x="594" y="828" w="468" h="450" id="867728800"> <Graph classid="OverlayGraph" id="300405243"> <Curve classid="Curve" name="AC Voltage" link="23352056" color="8388608"/> <Curve classid="Curve" name="AC Volts (RMS)" link="23358376" color="16777471"/> </Graph> <Graph classid="OverlayGraph" id="716091687"> <Curve classid="Curve" name="DC Volts" link="23243792" color="8388608/> <Curve classid="Curve" name="DC Current" link="23329944" color="32768/> </Graph> </Frame>

Curves are placed inside the Graph Graphs are placed inside the Frame

Frame Component in the User Interface If the concrete class is a ControlFrame, <Control> children define the presence of control panel objects in the frame. Control panel object can be created using different concrete classes defined by the classid. Controls are composite types but they are not user-level containers.
<Frame classid="ControlFrame" name="" x="846" y="684" w="216" h="126" id="24898126"> <Control classid="Slider" name="" link="23082280" /> <Control classid="Meter" name="" link="23358376" /> <Control classid="Meter" name="" link="23243792" /> </Frame>

24

Input Slider

Peer Component in the User Interface Every Frame element will contain sub-elements. Since the child elements are not top-level, they are handled entirely by the frame object. In the case of a ControlFrame, <Control> child elements define the presence of control interfaces in the frame. The ‘link’ attribute tells the application what ‘id’ to look for when searching for the corresponding input/output device.

25

The <schematic> contains all of the component types that can be added to a schematic diagram. In an effort to keep the schema portable and simple, the Wire and Frame nodes were made generic so that they can be used to represent other components.

<schematic classid="UserCanvas" size="A/A4" orientation="Landscape" margins="false" grid="false" virtuals="false" signals="false" sequence="false" autoseq="true" monitor="false" zoomlevel="6" scrollx="0" scrolly="0"> <paramlist> <param name="show_grid" value="0" /> <param name="show_signal" value="0" /> <param name="show_virtual" value="0" /> <param name="show_sequence" value="0" /> <param name="auto_sequence" value="1" /> <param name="size" value="0" /> <param name="orient" value="0" /> <param name="show_border" value="0" /> </paramlist> <User classid="UserCmp" name="master:xnode" id="646147213" x="72" y="360" w="16" h="30" z="-1" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="in" /> </paramlist> </User> <User classid="UserCmp" name="master:xfmr-2w" id="981685497" x="396" y="234" w="74" h="78" z="30" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Tmva" value="0.5 [MVA]" /> <param name="f" value="$(FREQ)" /> <param name="Xl" value="0.000001 [pu]" /> <param name="NLL" value="0.0 [pu]" /> <param name="CuL" value="0.0 [pu]" /> <param name="Ideal" value="1" /> <param name="Tap" value="2" /> <param name="View" value="2" /> <param name="V1" value="14.376 [kV]" /> <param name="V2" value="14.376 [kV]" /> <param name="Enab" value="0" /> <param name="Sat" value="1" /> <param name="Xair" value="0.2 [pu]" /> <param name="Tdc" value="1.0 [s]" /> <param name="Xknee" value="1.25 [pu]" /> <param name="Txk" value="0.1 [s]" /> <param name="Im1" value="1 [%]" /> <param name="IL1" value="" /> <param name="IL2" value="" /> <param name="IMAG" value="" /> <param name="FLUX" value="" /> </paramlist> </User> <User classid="UserCmp" name="master:breakout" id="1675292287" x="180" y="360" w="38" h="75" z="-1" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Dis" value="0" /> <param name="Com" value="0" /> </paramlist> </User> <Wire classid="WireOrthogonal" name="" id="0" x="216" y="360" w="152" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="144" y="0" /> </Wire>

26

<Wire classid="WireOrthogonal" name="" id="0" x="216" y="324" w="152" h="98" orient="0"> <vertex x="0" y="0" /> <vertex x="0" y="-90" /> <vertex x="144" y="-90" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="360" y="270" w="44" h="296" orient="0"> <vertex x="0" y="0" /> <vertex x="-36" y="0" /> <vertex x="-36" y="288" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="360" y="396" w="44" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="-36" y="0" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="360" y="522" w="44" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="-36" y="0" /> </Wire> <User classid="UserCmp" name="master:ground" id="609479090" x="324" y="558" w="20" h="26" z="-1" orient="1" link="-1"> <paramlist link="-1" name="" /> </User> <User classid="UserCmp" name="master:xnode" id="233385407" x="792" y="360" w="18" h="30" z="-1" orient="4" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="out" /> </paramlist> </User> <User classid="UserCmp" name="master:breakout" id="1573930840" x="612" y="360" w="38" h="75" z="-1" orient="4" link="-1"> <paramlist link="-1" name=""> <param name="Dis" value="0" /> <param name="Com" value="0" /> </paramlist> </User> <Wire classid="WireOrthogonal" name="" id="0" x="576" y="360" w="152" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="-144" y="0" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="576" y="324" w="152" h="98" orient="0"> <vertex x="0" y="0" /> <vertex x="0" y="-90" /> <vertex x="-144" y="-90" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="432" y="270" w="44" h="296" orient="0"> <vertex x="0" y="0" /> <vertex x="36" y="0" /> <vertex x="36" y="288" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="432" y="396" w="44" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="36" y="0" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="432" y="522" w="44" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="36" y="0" /> </Wire> <User classid="UserCmp" name="master:ground" id="990632881" x="468" y="558" w="20" h="26" z="-1" orient="7" link="-1"> <paramlist link="-1" name="" /> </User>

27

<User classid="UserCmp" name="master:xfmr-2w" id="1118812865" x="396" y="360" w="74" h="78" z="50" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Tmva" value="0.5 [MVA]" /> <param name="f" value="$(FREQ)" /> <param name="Xl" value="0.000001 [pu]" /> <param name="NLL" value="0.0 [pu]" /> <param name="CuL" value="0.0 [pu]" /> <param name="Ideal" value="1" /> <param name="Tap" value="2" /> <param name="View" value="2" /> <param name="V1" value="14.376 [kV]" /> <param name="V2" value="14.376 [kV]" /> <param name="Enab" value="0" /> <param name="Sat" value="1" /> <param name="Xair" value="0.2 [pu]" /> <param name="Tdc" value="1.0 [s]" /> <param name="Xknee" value="1.25 [pu]" /> <param name="Txk" value="0.1 [s]" /> <param name="Im1" value="1 [%]" /> <param name="IL1" value="" /> <param name="IL2" value="" /> <param name="IMAG" value="" /> <param name="FLUX" value="" /> </paramlist> </User> <User classid="UserCmp" name="master:xfmr-2w" id="1496069239" x="396" y="486" w="74" h="78" z="90" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Tmva" value="0.5 [MVA]" /> <param name="f" value="$(FREQ)" /> <param name="Xl" value="0.000001 [pu]" /> <param name="NLL" value="0.0 [pu]" /> <param name="CuL" value="0.0 [pu]" /> <param name="Ideal" value="1" /> <param name="Tap" value="2" /> <param name="View" value="2" /> <param name="V1" value="14.376 [kV]" /> <param name="V2" value="14.376 [kV]" /> <param name="Enab" value="0" /> <param name="Sat" value="1" /> <param name="Xair" value="0.2 [pu]" /> <param name="Tdc" value="1.0 [s]" /> <param name="Xknee" value="1.25 [pu]" /> <param name="Txk" value="0.1 [s]" /> <param name="Im1" value="1 [%]" /> <param name="IL1" value="" /> <param name="IL2" value="" /> <param name="IMAG" value="" /> <param name="FLUX" value="" /> </paramlist> </User> <Wire classid="WireOrthogonal" name="" id="0" x="216" y="396" w="8" h="98" orient="0"> <vertex x="0" y="0" /> <vertex x="0" y="90" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="216" y="486" w="152" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="144" y="0" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="576" y="396" w="8" h="98" orient="0"> <vertex x="0" y="0" />

28

<vertex x="0" y="90" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="576" y="486" w="152" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="-144" y="0" /> </Wire> <User classid="UserCmp" name="master:voltmetergnd" id="1789396988" x="702" y="360" w="16" h="29" z="70" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="E1" /> </paramlist> </User> <User classid="UserCmp" name="master:ammeter" id="1303903104" x="612" y="360" w="38" h="24" z="60" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="Ir" /> </paramlist> </User> <Wire classid="WireOrthogonal" name="" id="0" x="72" y="360" w="116" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="108" y="0" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="648" y="360" w="152" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="144" y="0" /> </Wire> <User classid="UserCmp" name="master:import" id="1585432944" x="306" y="108" w="71" h="18" z="10" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="TAP3" /> </paramlist> </User> <User classid="UserCmp" name="master:datatap" id="1371946569" x="360" y="198" w="23" h="20" z="20" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Index" value="1" /> <param name="Dim" value="1" /> <param name="Type" value="2" /> <param name="Style" value="1" /> <param name="Disp" value="1" /> </paramlist> </User> <Wire classid="WireOrthogonal" name="" id="0" x="342" y="108" w="8" h="350" orient="0"> <vertex x="0" y="0" /> <vertex x="0" y="342" /> </Wire> <User classid="UserCmp" name="master:datatap" id="170652895" x="360" y="324" w="23" h="20" z="40" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Index" value="2" /> <param name="Dim" value="1" /> <param name="Type" value="2" /> <param name="Style" value="1" /> <param name="Disp" value="1" /> </paramlist> </User> <User classid="UserCmp" name="master:datatap" id="227209142" x="360" y="450" w="23" h="20" z="80" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Index" value="3" /> <param name="Dim" value="1" /> <param name="Type" value="2" />

29

<param name="Style" value="1" /> <param name="Disp" value="1" /> </paramlist> </User> <User classid="UserCmp" name="master:export" id="1148517423" x="756" y="108" w="73" h="18" z="100" orient="2" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="Irs3" /> </paramlist> </User> <User classid="UserCmp" name="master:datalabel" id="2023756150" x="666" y="108" w="8" h="20" z="-1" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="Ir" /> </paramlist> </User> <User classid="UserCmp" name="master:datalabel" id="1399714253" x="666" y="90" w="16" h="20" z="-1" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="E1" /> </paramlist> </User> <User classid="UserCmp" name="master:export" id="985986561" x="756" y="90" w="73" h="18" z="110" orient="2" link="-1"> <paramlist link="-1" name=""> <param name="Name" value="Ers3" /> </paramlist> </User> <Wire classid="WireOrthogonal" name="" id="0" x="666" y="90" w="62" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="54" y="0" /> </Wire> <Wire classid="WireOrthogonal" name="" id="0" x="666" y="108" w="62" h="8" orient="0"> <vertex x="0" y="0" /> <vertex x="54" y="0" /> </Wire> </schematic>

Schematic Model Representation in Xml

30

4. Configuration
When a model instance is created, it is the parameters of the model that provide the primary configuration control. Since the design of the model and its core function are contained in the definition, this behavior is consistently the same for all instances of the model. The use of instance parameters allows user to change specific behavioral elements through data.

Dialog Fragment for Transformer Configuration

Parameters are organized into named groups called a <category>. Each category contains a flat list of <parameter> elements defined through its attributes and its default content is contained within a single element value The parameters can be classified as either numeric or text value. text.

4.1 Structure
The schema diagram shown below (in Figure 5) gives a better description of the elements that are recognized within a <form> element. The attributes shown in Table 1 below represent the remaining elements of the form.
<form> <category name="Configuration"> <parameter type="Real" name="Tmva" desc="Transformer MVA" content_type="Constant" min="1e-006" max="" unit="MVA"> <value><![CDATA[100.0]]></value> </parameter> <parameter type="Real" name="f" desc="Base operation frequency" content_type="Constant" min="0.0001" max="" unit="Hz"> <value><![CDATA[60.0]]></value> </parameter> <parameter type="Real" name="Xl" desc="Leakage reactance" content_type="Constant" min="0" max="1" unit="pu"> <value><![CDATA[0.10]]></value> </parameter> <parameter type="Real" name="NLL" desc="No load losses" content_type="Constant" min="0" max="1" unit="pu"> <value><![CDATA[0.0]]></value> </parameter> <parameter type="Real" name="CuL" desc="Copper losses" content_type="Constant" min="0" max="1" unit="pu"> <value><![CDATA[0.0]]></value> </parameter> <parameter type="Choice" name="Ideal" desc="Ideal transformer model"> <value><![CDATA[0]]></value> <choice><![CDATA[0 = No]]></choice> <choice><![CDATA[1 = Yes]]></choice> </parameter> <parameter type="Choice" name="Tap" desc="Tap changer on winding"> <value><![CDATA[0]]></value> <choice><![CDATA[0 = None]]></choice> <choice><![CDATA[1 = #1]]></choice> <choice><![CDATA[2 = #2]]></choice> <cond><![CDATA[(true)]]></cond>

31

</parameter> <parameter type="Choice" name="View" desc="Graphics Display"> <value><![CDATA[2]]></value> <choice><![CDATA[1 = Circles]]></choice> <choice><![CDATA[2 = Windings]]></choice> <cond><![CDATA[(true)]]></cond> </parameter> </category> <category name="Winding Voltage Ratings"> <parameter type="Real" name="V1" desc="Winding #1 voltage (RMS)" content_type="Constant" min="0.0001" max="" unit="kV"> <value><![CDATA[230.0]]></value> </parameter> <parameter type="Real" name="V2" desc="Winding #2 voltage (RMS)" content_type="Constant" min="0.0001" max="" unit="kV"> <value><![CDATA[230.0]]></value> </parameter> </category> <category name="Saturation"> <parameter type="Choice" name="Enab" desc="Saturation enabled "> <value><![CDATA[0]]></value> <choice><![CDATA[0 = No]]></choice> <choice><![CDATA[1 = Yes]]></choice> </parameter> <parameter type="Choice" name="Sat" desc="Place saturation on winding"> <value><![CDATA[1]]></value> <choice><![CDATA[1 = #1]]></choice> <choice><![CDATA[2 = #2]]></choice> </parameter> <parameter type="Real" name="Xair" desc="Air core reactance" content_type="Constant" min="0.001" max="10" unit="pu"> <value><![CDATA[0.2]]></value> </parameter> <parameter type="Real" name="Tdc" desc="Inrush decay time constant" content_type="Constant" min="0.001" max="" unit="s"> <value><![CDATA[1.0]]></value> </parameter> <parameter type="Real" name="Xknee" desc="Knee voltage" content_type="Constant" min="" max="" unit="pu"> <value><![CDATA[1.25]]></value> </parameter> <parameter type="Real" name="Txk" desc="Time to release flux clipping" content_type="Constant" min="0" max="1e+006" unit="s"> <value><![CDATA[0.1]]></value> </parameter> <parameter type="Real" name="Im1" desc="Magnetizing current" content_type="Constant" min="0.0001" max="50" unit="%"> <value><![CDATA[0.4]]></value> </parameter> </category> <category name="Monitoring of Currents and Flux"> <parameter type="Text" name="IL1" desc="Name for winding #1 current"> <value><![CDATA[]]></value> </parameter> <parameter type="Text" name="IL2" desc="Name for winding #2 current"> <value><![CDATA[]]></value> </parameter> <parameter type="Text" name="IMAG" desc="Name for magnetizing current (kA)"> <value><![CDATA[]]></value> </parameter> <parameter type="Text" name="FLUX" desc="Name for flux linkage (kWb-N)"> <value><![CDATA[]]></value> </parameter>

32

</category> </form> <parameter> elements may be created as nested children of <category> elements where each <parameter> has a

‘type’ attribute (as shown in Table 1). This attribute also enables the dialog to perform data validation. The “Table” type is under development and will support homogenous tables of either Real or Integer numbers.
Parameter attributes content_type min max unit
l l l l l l l l

type Text Integer Real Choice Table

name
l l l l l

desc
l l l l l

group
l l l l l

precision

table_type

l

l

Table 1: Required Attributes (by parameter “type”)
Attribute type name desc content_type min, max unit group precision table_type Description
Must be one of the following types { Text, Integer, Real, Choice, Table } Symbolic name & must be compatible with standard Fortran naming conventions Describes the input field and is also the name presented to the user in the dialog Enumerated data type for integer & real numbers { Literal, Constant, Variable } Enter a value limit for these fields (must be +-1e+38) Add a unit (if any) to represent the Target Unit related to this field. Use these to categorize your properties (when viewed in the Property Editor)

Number of decimal places to display in table cells Must be one of {Real, Integer}

Table 2: Attribute Description

4.1.1 Category
It is not uncommon for a single object to possess a large number of properties. In these situations, it is often preferable to present the properties in defined categories. In MFC, the categories are defined as individual pages in a property sheet. In the functionality provided here, the categories provide individual sheets that are selected by a major drop list at the top of the dialog. When selected, the user can scroll the pages by scrolling the wheel on the mouse, or use page down and page up to control movement, or finally select the category from the list itself. Each category contains a list of <parameter> elements that define individual control fields in the dialog. Every element under the category will be a member of the same sheet. In addition, a <cond> element is used to define an optional [CDATA] expression which is used to control the enable/disable state of the drop-list. The expression can contain other property names. This expression is pumped into a user expression evaluator generating an output state of true/false to enable the control. If this element is excluded then the state is always enabled. An example of a <category> element is shown below:
<category name="Paper Settings"> <cond><![CDATA[(LL>=1)]]></cond> <parameter.. /> <parameter.. /> </category>

Based on the <cond>, this <category> will be enabled when the <param> whose ‘name’ has a value of “LL” also has a numeric ‘value’ >= 1. The evaluation is performed at the developer level by providing and evaluation code for the given expression. If not included, it is always enabled.

33

Every <parameter> can contain a prompt text. The prompt is displayed at the bottom panel of the dialog and is primarily used to give the user a bit more information about the parameter while not cluttering the dialog with lengthy caption strings. A sample of a <help> prompt is shown below:
<help><![CDATA[Selects paper size from a standard set]]></help>

A CDATA[] section is used to allow for raw character text.

4.1.2 Text Box
The text box implements a string field. The ‘type’ attribute must have the value “Text”.
<parameter type="Text" name="creator" desc="Creator" group="Simulation"> <value><![CDATA[]]></value> </parameter>

The corresponding <param> data element would look like:
<param name='creator' value='Craig Muller'/>

Text boxes are the simplest types since they have no content validation at all. All the validation is expected to be performed by the software that operates on the string data. The dialog will assume that any content is valid.

4.1.3 Numeric Box
The integer or real box implements a numeric field. The ‘type’ attribute must have the value “Integer” or “Real”.
<parameter type="Integer" name="runs" desc="#Runs" group="Simulation" content_type="Literal" min="1" max="10" unit=""> <value><![CDATA[0]]></value> </parameter>

The corresponding <param> data element would look like:
<param name='nruns' value='1'/>

In addition to the existing attributes, attributes for ‘content_type’, ‘min’, ‘max’, and ‘unit’ are included. These attributes are used for validation purposes of the numeric data provided in the field. “Literal’ content is validated against syntax and the values of ‘min’ and ‘max’. Since values used in objects may be provided from another external parameter, the content can be set to “Constant” or “Variable”. This allows users to input variable names rather than literal numbers. The validation of the contents is done my checking the result against variable symbol syntax. For example: “A1” is valid whereas “1A” is not valid. When using numeric values in simulations, they can be broken into two types, literals (terminal) and variables (non-terminal). The use of variable parameters is not easily validated and allows values to cascade from one module to another. This behavior is the identical to that of a transfer port. (See the section on interface ports for more detail) If this variable is transported to the circuit schematic, then this is analogous to an import action. When used for configuration purposes, each instance value must be transported by proxy using a symbolic constant (since they are initialized once and never changed). A constant is terminal (once initialized from the expression it represents), and can never appear on the left hand side of a Backus-Naur Form (BNF) expression. This means that a constant can never be assigned from a non-terminal in the schematic. Such an assignment would then break the terminal nature of the constant and lead to unpredictable behavior.

34

4.1.3 Choice Box
If the parameter type is ‘Choice’ then it is an enumeration. Enumerated parameters have a specific number of defined items Selection of the parameter value must be one of the defined items each of which is defined by items. an item element. The choice box implements a mutually exclusive finite list of known numeric states. The user is allowed to select one of the states from an automatically generated list of items in a drop-list box. Each item defines a text string that specified the symbolic representation of the item and its corresponding numerical value used in the simulation. To create the <form> needed to generate the choice box requires knowledge of a few basic fields. If the attribute ‘type’ is set to the value “Choice”, then the implementation expects specific sub-elements. The form must contain a single <value> element comprising of a [CDATA] containing the integer number of the default selected state. This is used whenever a new instance of a <paramlist> data is created. Following that element is at least 1 and up to n <choice> elements. These elements define in [CDATA] the numeric value and the text to be displayed in the drop list that defines then numeric value. The format is a simple “number = text” association. The last child element is a <cond> which defines in [CDATA] an expression used to control the enable/disable state of the drop-list. The expression can contain other property names. This expression is pumped into a user expression evaluator generating an output state of true/false to enable the control. In most cases, the list always enabled and thus the value is always “true”. An example of schematic paper settings is shown below:
<parameter type="Choice" name="size" desc="Paper Size" group="Shape"> <value><![CDATA[0]]></value> <choice><![CDATA[0 = A/A4 (8.5x11)]]></choice> <choice><![CDATA[1 = B/A3 (11x17) ]]></choice> <choice><![CDATA[2 = C/A2 (17x22) ]]></choice> <choice><![CDATA[3 = A/A1 (22x34) ]]></choice> <choice><![CDATA[3 = Oversize (34x44)]]></choice> <cond><![CDATA[true]]></cond> </parameter>

The corresponding <param> data element would look like:
<param name='size' value='1'/>

When a <param> data element is provided, the default value is replaced by the value contained in the element. Since indexes are *not* used for tracking, due to limitations as a result of parameter changes between versions, the elements are matched by value in the <form>. If a match fails then the default value is selected.

4.1.4 Boolean Toggle
The Boolean parameter type implements a simple 2-state property that always returns ‘true’ or ‘false’ value. In addition, the state names displayed in the drop list are customizable. This type of control is essentially a simplified subset of the choice list having exactly two choices.
<parameter type="Boolean" name="header_visible" desc="Show Header?" group=""> <value><![CDATA[true]]></value> <cond /> <help /> <choice><![CDATA[true = Show]]></choice> <choice><![CDATA[false = Hide]]></choice> <cond><![CDATA[true]]></cond> </parameter>

4.1.5 Numeric Table
35

The numeric table implements a homogeneous set of integer or real numbers within a popup table form. Users can define the number of decimal places they wish displayed in the table (0 to 6) or they set it undefined (-1), in which case real numbers are displayed with all of the decimal places that were originally entered. Columns can be added, removed or renamed using the Edit Columns property. Column names and data rows are stored in the parameter element. Row elements are also added to new component instances using the parameter rows as default values. The corresponding <param> data element might look like the following:
<parameter type="Table" name="xytable" desc="XY Table" group="test" table_type="Real" precision="2" > <value><![CDATA[0]]></value> <column label="X" width="50" /> <column label="Y" width="50" /> <help><![CDATA[Test table]]></help> <row>0,2.0</row> <row>1,5.0</row> <row>2,7.0</row> <row>3,3.0</row> <row>4,1.0</row> <cond /> </parameter>

The corresponding <param> would look like:
<param name="xytable" value="Table(2,5)"> <row>0,1.0</row> <row>5,5.0</row> <row>2,7.75</row> <row>344446,3.2333</row> <row>1,1.101</row> </param>

An example of the dialog produced is shown below:

36

Popup Table

For each instance of a component that uses a definition, there is a corresponding set of parameter values. This is stored in a generic <paramlist> element. Each list contains a homogeneous list of <param> elements that provide the value of a given named parameter for that instance. A sample instance element is given below:
<User classid="UserCmp" name="master:xfmr-2w" id="1118812865" x="396" y="360" w="74" h="78" z="50" orient="0" link="-1"> <paramlist link="-1" name=""> <param name="Tmva" value="0.5 [MVA]" /> <param name="f" value="$(FREQ)" /> <param name="Xl" value="0.000001 [pu]" /> <param name="NLL" value="0.0 [pu]" /> <param name="CuL" value="0.0 [pu]" /> <param name="Ideal" value="1" /> <param name="Tap" value="2" /> <param name="View" value="2" /> <param name="V1" value="14.376 [kV]" /> <param name="V2" value="14.376 [kV]" /> <param name="Enab" value="0" /> <param name="Sat" value="1" /> <param name="Xair" value="0.2 [pu]" /> <param name="Tdc" value="1.0 [s]" /> <param name="Xknee" value="1.25 [pu]" /> <param name="Txk" value="0.1 [s]" /> <param name="Im1" value="1 [%]" /> <param name="IL1" value="" />

37

<param name="IL2" value="" /> <param name="IMAG" value="" /> <param name="FLUX" value="" /> </paramlist> </User>

The use of parameter lists in instances of component is found in the schematic diagram data. This is described in greater detail later on. The corresponding configuration dialog for the component is shown below:

Creating the Xml Data
When working with the actual instance data, the format is somewhat simpler. Data is formed into lists of property values called <paramlist>. Each <paramlist> contains a ‘name’ attribute, used for identification and organizational purposes. If only a single list is exists, then the ‘name’ field can be left empty. Each <param> stores the attributes ‘name’ and ‘value’. All other information is provided for by the definition. And example <paramlist> is given below:
<paramlist name = 'Test Object'> <param name='description' value='A sample test dialog'/> <param name='creator' value='joe the coder' enabled='false'/> <param name='runs' value='1'/> <param name='time_step' value='0.000005'/> <param name='snap_name' value='test_snap.snp'/> <param name='view' value='1'/> <param name="xytable" value="Table(2,5)"> <row>0,1.0</row> <row>5,5.0</row>

38

<row>2,7.75</row> <row>344446,3.2333</row> <row>1,1.101</row> </param> <param name="xyztable" value="Table(3,10)" enabled='false'> <row>0,1.0,4</row> <row>5,5.0,4</row> <row>2,7.75,4</row> <row>344446,3.2333,4</row> </param> <param name='size' value='1'/> <param name='orient' value='1'/> <param name='border' value='1'/> </paramlist>

For example: The data for the field named ‘creator’ is given the content of ‘Joe the coder’. This is the content that will appear in the dialog.

39

5. Visualization
In order to use a component in a schematic diagram, it must have a visual interface that acts as iconic representation of component and provides physical terminations for wires. The visual interface provides to the user a familiar basis for manipulation and control over the model represented by the system. The representation is used in schematic diagram to provide the relational information between the models. Relations are defined through the terminals of the graphic called ‘ports’. When one port is connected to another port it established an input/output or natural relation between the models. For organizational purposes, simple ideal wire models allow the user to separate the models with some physical space. Since the wires are ideal, they have no effect on the simulation except to establish the relations between ports.

2 Winding Transformer For the purposes of a graphical representation using Xml, as well established standard already exists with a rich set of representations that meet and exceed the needs of a power system schematic. For this reason all model SVG graphics are defined by the World Wide Web Consortium W3C standard for Scalable Vector Graphics (SVG SVG) and complies with these standards for that sub-set implementation. If there is a non-compliance situation, this is indicated in the specification. SVG is an Xml markup language for describing two-dimensional vector graphics, both static and animated, and either declarative or scripted. SVG has provision to allow for custom extension of the elements, which is important to the schematic diagram when defining the ports to the model. The specific sub-set of drawing commands that are implemented by the model and its corresponding graphics engine are listed here. There are several types of graphic objects available to help design a visually appealing component. All the graphical elements of the model are described by a series of meta-drawing commands or ‘shape. These commands describe the sequence in which primitive objects are drawn relative to a single origin point. Colours and styles are changes between the strokes affect all stroke that follow the resource change. Each action is defining a single set of coordinates or a state change by changing pens and brushes. The graphics information does not apply to any of the ports used by the model. Ports are defined through an extension element that provides location and type information. Ports are graphically invisible except when displayed within an editing environment.
<svg viewBox="-200 -200 200 200"> <cond><![CDATA[(Tap!=0)&&(View==1)]]></cond> <line x1="7" y1="4" x2="9" y2="-6" stroke="Black" stroke-dasharray="none" stroke-width="0.6" /> <line x1="4" y1="3" x2="9" y2="-6" stroke="Black" stroke-dasharray="none" stroke-width="0.6" /> <line x1="-4" y1="36" x2="9" y2="-6" stroke="Black" stroke-dasharray="none" stroke-width="0.6" /> <cond><![CDATA[(View==1)]]></cond> <line x1="-30" y1="36" x2="-30" y2="0" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="-34" y1="36" x2="-30" y2="36" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="-34" y1="0" x2="-30" y2="0" stroke="Black" stroke-dasharray="none" stroke-width="0.2" />

40

<line x1="33" y1="36" x2="33" y2="0" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="33" y1="36" x2="37" y2="36" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="33" y1="0" x2="37" y2="0" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <cond><![CDATA[(View==2)]]></cond> <line x1="-6" y1="36" x2="-36" y2="36" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="-6" y1="31" x2="-6" y2="36" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <path d="M-6.000 22.000 A4 4 0 1 1 -6.000 30.000" arc="-11,22,-2,31,90,-180" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <path d="M-6.000 13.000 A4 4 0 1 1 -6.000 21.000" arc="-11,13,-2,22,90,-180" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <path d="M-6.000 4.000 A4 4 0 1 1 -6.000 12.000" arc="-11,4,-2,13,90,-180" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="-6" y1="0" x2="-6" y2="4" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="-36" y1="0" x2="-6" y2="0" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="6" y1="36" x2="36" y2="36" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="6" y1="31" x2="6" y2="36" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <path d="M6.000 22.000 A4 4 0 1 0 6.000 30.000" arc="2,22,11,31,90,180" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <path d="M6.000 13.000 A4 4 0 1 0 6.000 21.000" arc="2,13,11,22,90,180" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <path d="M6.000 4.000 A4 4 0 1 0 6.000 12.000" arc="2,4,11,13,90,180" stroke="Black" stroke-dasharray="none" strokewidth="0.2" /> <line x1="6" y1="0" x2="6" y2="4" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <line x1="36" y1="0" x2="6" y2="0" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <cond><![CDATA[(Tap!=0)&&(View==2)]]></cond> <line x1="-36" y1="-36" x2="0" y2="0" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <cond><![CDATA[(View==1)]]></cond> <line x1="-30" y1="18" x2="-27" y2="18" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <ellipse cx="-9" cy="18" rx="18" ry="18" stroke="Black" stroke-dasharray="none" stroke-width="0.2" fill-style="Hollow" fill-fg="Black" fill-bg="" /> <line x1="30" y1="18" x2="33" y2="18" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <ellipse cx="12" cy="18" rx="18" ry="18" stroke="Black" stroke-dasharray="none" stroke-width="0.2" fill-style="Hollow" fill-fg="Black" fill-bg="" /> <cond><![CDATA[(Tap!=0)&&(View==1)]]></cond> <line x1="0" y1="18" x2="-36" y2="-36" stroke="Black" stroke-dasharray="none" stroke-width="0.2" /> <cond><![CDATA[(Tap!=0)]]></cond> <text x="-22" y="-28" stroke="Black" fill="Black" font-size="Small" text-anchor="Middle"><![CDATA[Tap]]></text> <cond><![CDATA[true]]></cond> <text x="-13" y="22" stroke="Black" fill="Black" font-size="Small" text-anchor="Middle"><![CDATA[#1]]></text> <text x="19" y="22" stroke="Black" fill="Black" font-size="Small" text-anchor="Middle"><![CDATA[#2]]></text> </svg>

Model Xml

Text parsing is performed on the body of the child element to form peer structures for drawing the component.

5.1 Stroke Elements
Most of the graphic for a model is created using stroke elements. These elements are basic 4 point definitions for drawing. The <line>, <rect>, and <ellipse> are formatted using the top left and bottom right corners of their bounding boxes shown below:
x1,y1 x1,y1 x1,y1

x2,y2

x2,y2 x2,y2

Rectangle, Line, Ellipse 41

<line x1="-36" y1="0" x2="-6" y2="0" stroke="Black" stroke-dasharray="none" stroke-width="0.2" />

x1 y1 x2 y2

= = = =

The The The The

x-axis y-axis x-axis y-axis

coordinate coordinate coordinate coordinate

of of of of

the the the the

start of the line. start of the line. end of the line. end of the line.

If the attribute is not specified, the effect is as if a value of "0" were specified. x = The x-axis coordinate of the side of the rectangle which has the smaller x-axis coordinate value in the current user coordinate system. y = The y-axis coordinate of the side of the rectangle which has the smaller y-axis coordinate value in the current user coordinate system. If the attribute is not specified, the effect is as if a value of "0" were specified. width = The width of the rectangle. height = The height of the rectangle. A negative value is an error. A value of zero disables rendering of the element.
<ellipse cx="12" cy="18" rx="18" ry="18" stroke="Black" stroke-dasharray="none" strokewidth="0.2" fill-style="Hollow" fill-fg="Black" fill-bg="" />

5.2 Path Element
The <path> is a simple extension of the above and includes the starting angle and the sweep length in degrees as shown in Figure 2 below. Note that the visible arc extents will not necessarily match the arc’s top left and bottom right bounds:
<path d="M-6.000 22.000 A4 4 0 1 1 -6.000 30.000" arc="-11,22,-2,31,90,-180"

x1 = top left x coordinate y1 = top left y coordinate x2 = bottom right x coordinate y2 = bottom right y coordinate Start = Integer value specifying start angle (deg) CC from 3 O’clock Sweep = Integer value specifying sweep length
x1,y1

Figure 2. Arc
x2,y2

Figure 2. Arc

5.3 Text Element

42

<text> consists of an insertion point and a text string as shown in Figure 3:
<text x="-22" y="-28" stroke="Black" fill="Black" font-size="Small" text-anchor="Middle"><![CDATA[Tap]]></text>

x y CDATA

= top left x coordinate = top left y coordinate = text string

Text

‘stroke’ changes the state of the current pen. The Color, Width and Style attributes are optional and can be changed individually or left blank signifying that the attribute is to remain unchanged. The optional Node attribute is used with the ByNode value to inform PSCAD to interpret that attribute’s value by the type of node specified. Alternatively, the attribute can be forced to a default by using one of the extended values shown in the 4tyh column below.

Color Black Maroon Green Olive Navy Purple Teal Gray Silver Red Lime Yellow Blue Fushia Aqua White

Width 0.2 0.4 0.6 0.8 1.0 1.2 1.4

Style Solid Dashed Dotted DotDashed

Extended Logical Integer Real Complex ByNode

‘fill’ changes the state of the current brush. The brushes may be applied to Ellipses and Rectangles. Style and fill’ Color attributes are optional and can be changed individually or left blank signifying that the attribute is to remain unchanged.

43

Color Black Maroon Green Olive Navy Purple Teal Gray Silver Red Lime Yellow Blue Fushia Aqua White

Style Hollow Solid BkDiag FwDiag Cross DgCross Horiz Vert

‘font-size’ changes the state of the current font. The fonts are applied to Text objects. Style and Color font-size’ attributes are optional and can be changed individually or left blank signifying that the attribute is to remain unchanged. The first optional parameter, [Blue], is not user accessible and is set internally by PSCAD. It is either Blue or intentionally left blank to force the font color Black. The following two optional parameters specify size and alignment and are limited to the three choices as well as being left blank. Color Blue Size Small Medium Large Align Left Center Right

5.4 Conditionals
<cond> is used to change the visibility of a graphics object. The action requires an inner data section since the COND may use characters which otherwise would corrupt the document.
<cond><![CDATA[(View==1)]]></cond>

In this case, the condition evaluates to true if the parameter ‘View’ has a value equivalent to ‘1’.

5.5 Ports
The <port> element defines how an instance of the model connects to other instances within a schematic diagram. Every model defines the relationship between the ports, and this is the essence of the modeling process. To use this model in a simulation, the schematic diagram provides a visual way for the user to establish the relations between the models in the system. It is the role of the ports to provide these points of interaction. When the user attached two models together through the use of wires, the relationship between the models is established. When the schematic is compiled, meta-data is generated that tracks the relationships so that simulation code can be generated. This is an explicit relation. The model can define both natural ports in the network solution (used for through (current) and across (voltage) variables) and transfer ports (used to define ports where signal variables are transferred into the 44

model). Natural ports are conservative, meaning they conserve the fundamental laws of physics. The physical laws governing are provided by the nodal network modeling engine that is targeted. Transfer ports are not conservative, and operate on a purely numerical action of input and output values. In terms of simulation code, they act as input and output parameters that change dynamically during the simulation. This is a one-to-many system where a single port defines an output while many ports connected to it are acting as sinks. This is analogous to communications ports on any device that is used to transfer information from one object to another. Graphically they are typically depicted by different colours on the graphic diagram. Although they appear in the graphic editor, they do not have any visible appearance on the schematic diagram. The relationship between the across variables and the through variables is not defined by the port, but rather a branch definition. This is described in the scripted sections below.

Interface Graphic

<svg viewBox="-200 -200 200 200"> <port model="Transfer" name="TapI" x="-36" y="-36" dim="1" mode="Input" type="Real"><![CDATA[Tap!=0]]></port> <port model="Natural" name="A1" x="-36" y="0" dim="1" mode="" type="NonRemovable"><![CDATA[true]]></port> <port model="Natural" name="A2" x="36" y="0" dim="1" mode="" type="NonRemovable"><![CDATA[true]]></port> <port model="Natural" name="B1" x="-36" y="36" dim="1" mode="" type="NonRemovable"><![CDATA[true]]></port> <port model="Natural" name="B2" x="36" y="36" dim="1" mode="" type="NonRemovable"><![CDATA[true]]></port> </svg>

? ? ?

x: The x coordinate of the origin of the port. y: The y coordinate of the origin of the port. name Enter a name for the Connection. Note that this name must be compatible with standard name: FORTRAN naming conventions (i.e. it must begin with a non-numeric character, do not include spaces, etc.). dim If this port is to carry a signal that is defined as a standard FORTRAN array, then this is the dim: dimension of the array signal. For example, if port 'TAP3' is to be defined as REAL TAP3(3), then this field should be specified as 3.

?

5.5.1 Transfer Types
1. Integer This input defines the type of data signal that will be passing through this connection and is Integer. based on the standard Fortran INTEGER declarations. 2. Integer This input defines the type of data signal that will be passing through this connection and is Integer. based on the standard Fortran REAL declarations.

45

5.5.2 Natural Types
When the port is selected as natural, there are 4 electrical types that affect how nodes are created in the network topology. 1. Fixed A fixed node is the most common type of electrical node and should be the default. Fixed: 2. Removable A removable node is that which may be 'removed' if it is to be part of a collapsible branch. Removable: 3. Switched: If your node is to be part of a frequently switching branch, that is a branch whose equivalent conductance is changing many times during a simulation (thyristor, GTO, etc.), then this option should be chosen. 4. Ground node is to be a ground node. Ground:

46

6. Script
Script is used to define component behavior when no schematic diagram is provided. In the diagram of the circuit with the transformers in it, internal network elements and simulation code are not described by the diagram and thus must be provide by some other means. Each piece of critical information is thus provided by a raw text segment in the scripts section.

6.1 Branch
To illustrate, a user creates a single-phase electrical circuit, which includes a classical transformer component.

There are 6 electrical nodes in this system, and therefore the system matrix will have dimension 6 x 6.

For each component primitive a schematic diagram is not provided and the network topology is defined by a segment call ‘Branch’ in the scripts. The relationship between through (branch) variables and across (bus) variables is defined by a generalized expression interface. If we use the example of a simple resistive component type as shown below:

Branch design is accomplished by specifying the type and size of passive elements (i.e. lumped R, L and/or C), and to which natural ports they fall between. The Branch Segment is provided for the input of electric branch information (if it exists), for insertion into the Electrical Network Conductance Matrix It is essentially an Matrix: input portal for control of the Equivalent Conductance (GEQ) Interface. A single branch statement represents a single RLC electrical branch, to which is associated an impedance Z = R + jX where Z is derived jX, from a combination of series-connected, lumped R, L and/or C values.

47

The branch is always defined in terms of this impedance and, as such, the remaining part of the expression is not scripted and is intrinsically part of the branch calculation when the solver executes. This results in a simplified RLC branch definition as follows. The $<symbol> is a parameter. Syntax:

Name TO FROM R L C [<Name =] $<TO $<FROM [<Keyword Name> TO> FROM> Keyword Keyword>] [$]<R> [$][<L>] [$][<C>]

Where, ? Name (optional) Used to give the branch a through variable name, which can be used to refer to the branch (instead of its nodes) in other sections. Note that many subroutines require the name as an argument <TO> and <FROM> are the names of the natural ports. <R> is the resistance value of the branch [W] <L> is the inductance of the branch (optional) [H] <C> is the capacitance of the branch (optional) [mF] Keyword can be either 'SOURCE' or 'BREAKER' and is explained in the following sections $ is the Substitution Prefix Operator ($)

? ? ? ? ? ?

NOTE If a branch does not contain all three types of elements, 0.0 replaces the value of the element that is NOTE: not present. The Branch Segment may also be used to define switching branches and those that contain an ideal voltage source (i.e. infinite bus). The Branch Segment could then contain the following two statements:

$N1 $N2 $R 0.0 $C $N1 $N2 0.0 0.001 0.0

These statements are equivalent to the following schematic:

Branch statements do not describe any internal node elements in the system matrix, only relationship between existing nodes. To provide addition matrix information not visible on a schematic, the matrix-fill segment is provided to include the omitted branch information for any internal component nodes. The general format for a Matrix-Fill Segment statement would appear as follows: <port_1> <port_2> <port_3> <port_4>...

48

Where <port_#> is the name of the natural port involved with Matrix-Fill. All Connections in a single statement are assumed as connected to each other.

6.2 Computations
The computations segment is provided for the pre-processing of parameter data in order to construct a new derived constant that can be used by the simulation. Although component parameter input may be in the most convenient form for the user, it may not be so convenient for the component code itself. For example, the component routine may require the system frequency in radians per second, but the input data field may ask the user for the same quantity in Hertz. Both mathematical and logical expressions are allowed. All expressions processed are done so before any code is constructed, and only considered once. Therefore, quantities defined here are derived constants for the remainder of the simulation. Computations can be performed on input parameters, input signals, or on results of other computations Computed constants are constructed in a cascade manner. This means the sequence in which they are declared is important and a constant cannot be used in an expression before it has be define by a previous expression. Syntax: <DataType> <Name> = <Expression> ? ? ? DataType may be either a REAL or INTEGER type value. If omitted, it is assumed to be REAL Name is the name of the constant Expression is a mathematical or logical expression containing only constant parameters

Ternary Operator The ternary operator is a short form method for representing an IF-ELSE-ENDIF type expression. A derived constant can be defined according to certain conditions, in a single line. <Expression> ? <True_Expression> : < False_Expression >

Expression is a logical expression using logical operators. True_Expression and False_Expression are evaluated depending on the first outcome. Example: Define a REAL derived constant 'Torq'. The value of 'Torq' is defined by an expression, where one element of this expression varies according to a condition. This can be accomplished by using the ternary operator as follows: REAL Torq = (X > 1 ? 0.0 : Tm) + Te*100 Where: 'X', 'Tm' and 'Te' are pre-defined constants.

49

6.2.1 Operators
Operators ++-*/ % ** \ > >= < <= == != ! && || ~ & ~& | ~| ^ ^~ ~^ << >> ?: {} {{}} Unary plus, minus Arithmetic Remainder Exponentiation Parallel (xy) / (x +y) Relational Logical equality Logical negation Logical and Logical or Bit-wise negation Bit-wise and, nand Bit-wise inclusive or, nor Bit-wise exclusive or Bit-wise equivalence Left shift Right shift Ternary conditional Concatenation, replication Description Real operands Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No Yes Yes PSCAD r a a a a a a r a a r r r r r r r a r

6.2.1 Mathematical
Real operands Yes Yes Yes Yes Yes Yes Yes 50

Function log (x) log10(x) log2(x) exp(x) sqrt(x) min(x,y) max(x,y) Natural logarithm Decimal logarithm log base 2 Exponential Square root Minimum Maximum

Description

PSCAD a a r a a r r

abs(x) pow(x,y) floor(x) ceil(x) sign(x) round(x) trunc(x) cbrt(x)

Absolute Power x^y, same as ** above TODO: keep this?? Floor, largest int not >> x Ceiling, smallest int not << x return 1 if x > 0.0, 0 if x=0.0, -1 if x < 0.0 Round X to the nearest integer value Truncate X towards 0.0 Cube root

Yes Yes int returned as real int returned as real Yes int returned as real Yes Yes

a r a a r a r r

6.2.3 Transcendental
Function sin(x) cos(x) tan(x) asin(x) acos(x) atan(x) atan2(x,y) hypot(x,y) sinh(x) cosh(x) tanh(x) asinh(x) acosh(x) atanh(x) Sine Cosine Tangent Arc-sine Arc-cosine Arc-tangent Arc-tangent of x/y sqrt(x**2 + y**2) Hyperbolic sine Hyperbolic cosine Hyperbolic tangent Arc-hyperbolic sine Arc-hyperbolic cosine Arc-hyperbolic tangent Notes Real operands Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes PSCAD a a a a a a r r a a a r r r

6.2.4 Extended
Function real(x) imag(x) Notes Real part of complex number Imaginary part of complex number Real operands Yes Yes PSCAD a a

51

norm(x) int(x) frac(x) rand(x) r2rx(m,q) r2ry(m,q) r2pm(x,y) r2pa(x,y)

Norm of complex number (x2 + y2) Removes fractional part of real value Removes integer part of real value Random value between 0 and x Polar to rectangular Polar to rectangular Rectangular to polar conversion Rectangular to polar conversion

Yes Yes Yes Yes Yes Yes Yes Yes

a a a a a a a a

52

Appendix A

53


相关文章:
更多相关标签: