Guide to rolling your own OSI Monarch Extractor #1 - Know Thy System

The company I work for recently embarked on a journey to implement an Advanced Distribution Management System, and the solution we landed on was Open Systems International's Monarch platform. The core part of any ADMS is the network model which contains all the geographic and asset information you need to calculate real time connectivity and power flows for your electricity network. The Monarch platform is does not contain a GIS - it is designed to extract the model from your existing GIS and run alongside, and the software that performs this process is colloquially known as the Extractor. OSI provide extractors for a few mainstream GIS platforms, for example Esri and Intergraph. They do not provide one (at the time of writing at least) for GE's Smallworld, so we had to roll our own. This is the first in a series of posts that describes this journey for anyone else that happens to need to head down this path because there is no documentation provided to help you. Which brings me to the subject of this post: Know Thy System.

I will assume that you have a comprehensive knowledge of electrical transmission/distribution systems, GIS systems and IT systems, but I will define product specific terms at the start of each post:

  • eMap - this is the Monarch software component that contains the network model
  • Maestro - this is the software component that imports your model into eMap
  • IDF - Intermediate Data Format, an XML based file format which contains the model data. These files are output by the Extractor, and used as input for Maestro.
  • Device - a device is any electrical object in the eMap model. For example a line, transformer, switch, load or capacitor. For a complete list, refer to the eMap documentation.

The first step in creating an extractor is to take a good hard look at your current systems, and evaluate what information you require vs what information you have, which systems that information lives in and how accurate your current information is.

To start with you should evaluate your GIS system for connectivity and phasing as these are the fundamentals on which everything else is based. If phasing and connectivity are not a fundamental concept to your GIS then I strongly recommend that you create rules that ensure phase consistency when adding new objects. It is also worthwhile tracing your entire network and checking that the phasing is consistent throughout - e.g. you should not have a three phase line downstream of a single phase line, have a RW line downstream of a BR line. You can also write routines to check that there are no disconnected devices i.e. devices that cannot be energized by an electrical source. If you can get 95%+ of the phasing and connectivity correct in your GIS before you start on an ADMS implementation you will save a lot of headaches later on.

Next, identify where all the asset data lives. If it is in your GIS, then great. If not, then you will need a way to pull this data into your model. In our implementation we had a two stage extractor - the first stage exported the model from GIS, and the second stage added additional data from other data sources such as the asset management system.

For a basic power flow to converge with meaningful results, you need some key information regarding your assets. For all the details refer to the eMap Model Import Intermediate Format document. Some of this information was incomplete or missing in our systems, so we either had to inspect the device in the field to find out, or take an educated guess. In particular:

  • The conductor type for lines and cables, and
  • either a full impedance matrix for the conductor, or all the relevant information to calculate the impedance matrix (refer to the documentation)
  • For transformers, the impedance (in X and R components), and
  • the number of taps, and tap step size

Once you know where all your data lives, and you are confident you have or can approximate all the required data, its time to make some design decisions about your model!

| January 17th, 2020 | Posted in SCADA |

Leave a Reply