Guide to rolling your own OSI Monarch Extractor #2 - Decisions, Decisions

Now that you really know your system, you need to make some high level decisions about what you are going to model, and how you are going to do it.

Import Strategy

Your import strategy defines how you import data from GIS and other systems into the ADMS to form the model. You can perform three types of import: Full, Incremental, or Group. Full imports import the entire data model, and for small systems you this might be all that's required. Incremental imports take only the data that has been changed since the last import, and group imports only import the specific groups requested. You can use any combination of methods that suits. If using incremental imports, you need a method of generating incremental change sets from your data, and need to decide which data changes need to trigger inclusion in the change set. For our import strategy we used weekly full imports, and nightly incremental imports. Our implementation was driven by checkpoints in the GIS system, which means that data changes in the asset management database do not trigger changes in the ADMS. This was an acceptable trade off for us, but may not be for other implementations.

Next, you need to decide how to group devices. There are many ways to do this; an obvious choice is to group by feeder. In our implementation we decided that this was to large, and we instead have more granular grouping at the low voltage level. It helps if you can name your groups with a human readable identifier but this isn't always possible; in our implementation there are many small groups, so using internal ids was a more straightforward option.


The first thing to decide is what you want to model. Do you want to model your entire network, from source to load, or just the high voltage network, just your zone substations down, or something else? This decision may be driven by the quality of your data, or you business processes.


Sources are the things that energize your network. You should energize your network from points that have metering telemetry and per phase voltage telemetry, otherwise DPF may have trouble calculating flows between the source and the next downstream point that has metering telemetry.

Line impedances

Line impedances may be supplied in one of three formats:

  • Construction codes
  • Sequence components
  • Impedance matrix

These formats are described in detail in OSI documents, but you may wish to attempt to integrate the data from any existing modelling tools you might use already. For example in our implementation we converted existing data calculated with Leika into impedance matrices in IDF format, so we can be sure that our modelling tools (Sincal) and eMap are using the same line parameters.


AORs are a method of splitting up your network into areas that can have different access permissions. I'd suggest avoid using AOR 1 for eMap devices if possible, as this area is often used for system level alarms. Some system alarms have a setting to change the AOR, others do not. Since filtering alarms based on AOR can be quite useful, it helps to keep these alarms in a separate AOR from your eMap devices.

Once you have the high level design sorted, it's time to implement your extractor. But watch out for some traps... see the next post for details.

| February 1st, 2020 | Posted in SCADA |

Leave a Reply