SMAR Grid (IEC 61970 CIM) (12-50)
Case Study
DMS, GIS and Network Planning systems in a distribution utility address the same physical network and thus share a significant amount of common data.
Yet they typically exist as separate systems and on separate platforms. Reasons for that include the evolution of the systems, different ownership and responsibilities, and mainly different technical and operational requirements and constraints.
Establishing interfaces and workflows between the systems for exchanging common data offers a big potential for reducing data maintenance costs and improving data consistency and quality.
The article presents a case study that is in the acceptance phase at Sibelga, the distribution company responsible for the Brussels-Capital Region of Belgium. The solution implements interfaces and workflows between the DMS and the GIS system. It also enables close integration of the Network Planning system. this article focuses on the challenges that are quite typical for an integration project and how they were addressed in this particular case.
SYSTEM OVERVIEW
The Sibelga Network Sibelga is in charge of the operation, maintenance, and development of the gas and electricity distribution network infrastructure on the territory of the Brussels-Capital Region of Belgium. The electricity network infrastructure is currently composed of about 2,300 km of MV cables, 50 feeding stations, 93 repartition substations, 6,000 (network and client) substations, 6,950 busbars, and 15,000 bays containing 17,000 switching elements, and a total of 681,000 electricity supply points.
The major part of the electricity distribution network is operated at 11 kV. The Distribution Management System A distribution management system (DMS) with a data model based on an early version of the IEC 61970 CIM standard is in use since 2007 at Sibelga. It covers the electrical network, but not the gas network. In its initial version, the system task was to maintain the normal electrical network state on printed paper plans, and the current state on selected engineering workstations. In 2009, the system was integrated with the existing SCADA system to receive real-time updates for a total of about 9,500 indication and measurement instances, and to make the DMS user interface available for network operation. The number of workstations was increased and a web server interface was added for read-only access by office users. A switching order management system was installed for the planning and execution of network extensions and maintenance work. Outage reporting was added to meet regulatory requirements and to maintain the outage overview in the GIS system. In 2011, an interface to the new GIS/asset management system ATLAS was established. Figure 1 below gives an overview of the Network Management Systems, Activities, and Interfaces, with the DMS-GIS Interface, highlighted in red. This interface and its challenges and answers are discussed in the following sections.?
Business Goals
Main drivers for adding the DMS-GIS interface include:
An example of using the centralized data repository is the automatic generation of the planning system model using GIS data. The DMS system provides normal connectivity and schematic layout information to the GIS, such that the full planning model can be extracted from the GIS, including the schematics in the DMS layout that is familiar to the users. This eliminates manual network model maintenance for the planning system. Figure 2 lists some of the data being exchanged by the interface.?
Solution Approach
The DMS-GIS interface is realized by automatic, daily exchanges of XML messages, initiated by a synchronizer program that acts as a client to both the DMS and the GIS system.
The synchronizer uses a component interface that is identical to the DMS and the GIS system to request data from DMS or GIS using various selection criteria and to send the received data for processing to the other system. Processing in the receiving system can be synchronous and automatic, asynchronous, and under user control. Processing results are made available to the synchronizer as XML messages for immediate or later retrieval. The necessary correlation between requests and responses is provided by a message identification scheme.
Message Types
The interface uses the following 4 different message formats:
1) Substation List
This is a simple sequence of substation numbers, used mainly as selection criteria when retrieving data.
2) Route List
A route list is a very simple representation of the elements connecting two transformer stations, including the bays, the switching elements, and the ac line segments. Each route is a sequence of those elements connecting two stations, and a route list is a collection of all routes going out from a set of stations. See Figure 3 for an example.
3) Substation Collection
The substation collection is a hierarchical collection of the substation and all its contained elements, as defined in the CIM standard.
4) Error Collection
An error collection contains the detailed result of a processing request sent by the synchronizer to the DMS or GIS system. It makes the interface observable and is discussed in more detail in a separate section.?
CHALLENGES AND ANSWERS
Interface Definition
Challenges
Defining an interface can be time-consuming if a common vocabulary is not available, or if modeling preferences and techniques first need to be sorted out between the involved parties. The interface should support an implementation that can be adapted to later enhancements in a cost-effective way. The specification should be precise and easy to describe and understand.
Solution
The electrical network object model of both the DMS and the GIS system is based on different versions of the IEC 61970- 301 common information model (CIM). The vocabulary and semantics are the same, and for the purpose of the interface, the model differences were not relevant.
So it was an easy choice to use the CIM Power System Resource and its subclasses with their properties, containments, and relationships as a base for the interface.
A profile was defined with those CIM properties that are required, and with a few additions. For easy adaptation, the component interface methods are completely independent of the payload data. The interface signatures are simple, such as getSubstationCollection(), setSubstationCollection() or getRouteList(), with only few parameters that all represent XML document streams. The XML document stream payloads are defined using XML schema. They can be modified completely independent of the component interface definitions. Using XML schema was preferred due to its simplicity compared to the RDF schema. Experience Overall, the interface definition turned out to be a straightforward task.
领英推荐
CIM provided the necessary models and fosters a common understanding, and the pragmatic profiling approach made the interface simple and easy to read.?
Establish the Association between DMS and GIS Instances
Challenges
There are tens of thousands of instances in the DMS and the GIS system that need to be matched in a reliable and cost-effective way. Instance names might be different, they can be misspelled, or they can change over time and thus are not reliable and stable enough. Manual matching is far too expensive and time-consuming (and boring!).
Solution
The associations are established automatically based on connectivity and topology information available in both systems. Station numbers serve as “anchors”. Station numbers are human-readable and commonly used in daily work for identifying stations. Thus they are reliable enough to be used as starting and ending points of the routes. So in a first step, the “routes” between the stations, consisting of the stations, bays, switches, and ac line segments, are analyzed to match the instances in both systems. If an unambiguous match is found, those instances in the DMS get the Master Resource ID (MrId) assigned, which is supplied by GIS. The MrId is a number guaranteed to be unique within the system. It will not change and not be re-used for a different object when deleted. In a second step, all the objects contained in a station are exchanged using the Substation Collection message format. A large number can already be matched using the MrId assigned during route matching, especially the substations, bays, and switches. Those not yet matched are now compared with the unmatched objects, but the comparison can be limited to the objects in the same, already matched bay or substation. Other characteristics than the name are also used for the matching, such as number or object class.
Experience
The matching algorithm turned out to be very efficient and reliable. Matching errors revealed a number of database errors, such as wrong switch subclasses, or missing elements.
Respect Workflows and Responsibilities
Challenges
Daily imports from GIS might update DMS instances in a way that could create conflicts with pending local changes ready to be applied to the same instance. Or a change to an object, originating from GIS, might invalidate a switching order that already has been approved by people from the network operation department, or a change needs to be reviewed and approved using the "four eyes" principle.
Solution
No data are directly written into DMS and GIS. A server application processes the input and creates “Deferred Update” messages. Those messages are applied and installed within the job/version management under user control. Some fields which are sensitive to other operational workflows are only compared, and a warning is issued when updates are necessary. Possible conflicts between daily updates from GIS and pending operational changes from DMS are automatically?resolved based on explicit data ownership at the field level, as shown schematically in Figure 4.
Figure 4: Conflict resolution
Experience
People performing the daily work on the systems need to be included in reviews and testing.
Only they know all the workflow details. They are also finally responsible for the data, and it is important to get them early "in the boat" to have them accept new and changed workflows. Conflict resolution at the field level is essential for merging GIS updates with DMS updates. Make the Operations Observable and Traceable Challenges Should an operation fail, a useful error message must clearly identify the erroneous data and supply all the necessary information to analyze and fix the error. Searching for an error in large data collections without clear information is time-consuming, frustrating, and results in system rejection by the users. Data responsibility as mentioned above can only be assigned if modifications are observable and traceable.
Solution
The DMS-GIS interface includes an Error Collection XML message definition. For each synchronous and asynchronous operation, an Error Collection document is created. Using a message identifier scheme, the error collection can be correlated with the original message for that operation. The error collection includes a summary and statistics section, and an entry for each error that occurred. Each error entry contains erroneous or questionable data. Using XSL transformation, an XML error collection document can be converted to HTML for easy reading in a standard browser, as shown in Figure 5.
Experience
The error collection with the HTML formatting turned out to be essential for putting the system into production. Data errors were easy to understand, locate, and fix. It was also very helpful for testing the interface during program development, as it provided complete information on the data, whether processing failed or completed successfully.
Know your data
Challenges
Your database contains data that you did not expect, such as random errors; systematic deviations from “good” practice; constructs you did not think of during analysis (or were told they do not exist); rare, special cases that are justified; or incomplete, transitional structures. There will always be justified differences between the two systems that the interface has to cope with in some way.
Solutions
A number of approaches are used to cover the above challenges: Good error reporting, as described in the previous section, helps in understanding the issues. “Normal” errors are filtered out to not hide real problems. Scripting was provided to adjust data before going into production. Justified differences between the systems are bridged by transformations performed in the processing.
Experience
The interface was flexible enough to be adapted for extensions, and the project plan included resources for such surprises.
CONCLUSIONS
Using CIM as a base model made the interface definition straight-forward.
The automatic object association based on topology and containment works efficiently and reliably. Without this method, going into production would have been much more expensive and time consuming.
The workflow integration required the detailed know-how and buy-in of the daily users.
Data are always more complex and there are more special cases than you would think of.
There are errors in the data that you’d never find out without the systematic comparison and verification imposed and provided by the interface.
The business goals to eliminate duplicate data entry, to augment GIS data with up-to-date normal network and outage state, and to enable the GIS system as a central repository for different applications could be met as expected.
The data quality improvements achieved by data comparison and validation between the systems, resulting in a consistent set of data for all the different users were probably larger than expected. Its business value should not be under estimated.?