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.


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