Sphere: how to monitor billions of kilowatt-hours

There is such a power station - “Three Gorges” . They spent 10 years on it and $ 26 billion. Two cities left under water, 1.3 million people were resettled. It generates 100 billion kWh per year, but this covers ... 1.7% of China's needs.

There are 192 nuclear power plants in the world with 444 power units with a total electrical capacity of about 386,276 MW. (Power of the Three Gorges 22 500 MW).
')
When I played C & C, RedAlert and Total Annihilation, it was nice to break through and destroy / capture a couple of enemy power stations, thereby slowing down the development of the enemy. No wonder that now the energy infrastructure is a tasty target for hackers: “Breaking the power grid: from a separate substation to a blackout” , “Details on the unprecedented breaking of the electrical network of Ukraine” .

Who writes software for systems of this scale?

The developers of the company EDISON told how they wrote a system for monitoring the electrical network and event visualization. In total, 14,984 man-hours were spent on the project, from April 2010 to August 2011.

Introduction

The energy sector provides the livelihoods of all sectors of the economy. Economic growth inevitably entails an increase in demand for energy resources and requires the solution of the accumulated problems of aging equipment.

For a long-term stable supply of the economy and the population of the region with energy resources, a sound electric energy policy is needed, based on sensitive control and monitoring of processes in the power grids.

The Sphere program is designed to increase the response of the power grid monitoring system to events occurring at the network nodes - replacing outdated event visualization software. "Sphere" is intended for displaying power grid diagrams on the screen with high resolution and size in the grid monitoring center. An important parameter that was required of the program was to work in real time with a local image update at the event point. For this, the WPF library was used. Tools have been developed for displaying and editing circuit elements also in real time. For event management, the Pascal script engine was used. The graphic part is developed on WPF / C #, the event logic is via Delphi / ScriptPascal. The Delphi language could not be avoided due to the requirements of backward compatibility with a number of old applications.

Main components

Modular architecture

Subsystem Delphi.

DB graphical representation.
The module scripts (scripts).

Subsystem C # / WPF.

Visualization of graphical presentation.
Editing of the diagram of graphic representation.

Graphics core

The graphics module of the system is designed for visualization of schemes based on CIM-model data. Displays of calculated values and telemetry data - both in real time and for a specified time. The graphics use the high-performance Windows Presentation Foundation (WPF) library for visualization, which can render both programmatically and using hardware acceleration of modern video cards.

Graphic diagrams automatically update the data when the data in the CIM model changes. A graphical representation can be customized using a scripting language, which allows for flexible implementation of business logic. Script scripts perform calculations and can completely determine the behavior of objects of graphical representation.

The appearance of a visual representation is similar to a graph, the vertices of which are nodes and equipment objects, and the edges are branches and communication objects. In addition to the nodes and branches, the visual presentation contains data output blocks that display some values from the repository and graphic primitives for the layout of the scheme.

Nodes can be represented as:

circle;
horizontal tires;
vertical tire.

At the site are located the point of attachment, which are used to attach additional equipment and components. They are located around the perimeter of the node with a certain step that can be customized. The connection of additional equipment is controlled by scenarios that, by custom logic, enable or disable the display of characters of additional equipment:

generator;
synchronous compensator;
load;
reactor;
battery of static capacitors;
active shunt

Branches interconnect nodes. The branch is represented by a broken line, the ends of which are attached to the connection points of the beginning and end node. The solid line shows the enabled branch, the dotted line - disabled. A sign can be placed on a branch, the display of which is controlled by scripts:

transformer;
longitudinal compensation device;
cable line;
current-limiting reactor;
switching device.

The display of the sign and state of the line depends on the parameters of the entity with which the branch is connected.

A view contains multiple layers, and any view object can be assigned to one or more layers. If at least one of the layers to which the object is assigned is included, then the object is visible. If the object is not assigned to any layer, then it is always visible.

Nodes in the view can be combined into groups to replace at a certain scale with the image of the group. For example, the nodes that are part of a substation can be combined into the “substation” group, and the substations combined into the “station” group. By adjusting the different scales of replacing the display of nodes to a group, it can be achieved that when approaching (increasing the scale) the image of the station is detailed to the images of substations, with a further approximation, individual substation nodes will be shown.

Objects-equipment and objects-connections unite nodes and branches. As in the case of groups, moving objects leads to the movement of the branches and nodes included in the composition.

To display maps or other graphic information, a graphical representation allows you to display raster and vector images. Images are always displayed below objects.

At the graphic level WPF, work went on with such elements as Visual, DrawingVisual, Drawing, XAML, for working with large volumes of graphic primitives, a quadtree was used, which optimized the VisualCollection and Canvas objects.

An additional graphics optimization in which the quadtree was used was a mode that is not inherent in the WPF system, but was added by us through the WinApi functions. This mode used WinApi functions that performed moving the image fragment visible on the screen pixel-by-pixel depending on the direction of scrolling, while WPF needed to update only a small fragment that remained after the image was shifted. Here, the quadtree was turned on and passed to the WPF engine, which works with the VisualCollection and getVisualChild, only the set of objects included in the update area. When the program is launched in the monitoring center on a large monitor made up of a variety of conventional monitors (about 20-30 pieces), when displaying events, the use of a quadtree substantially relieved the load from WPF and ensured high graphics performance.

Difficulties encountered in development and optimization

Hit test optimization

When working with the hit test in the WPF system, performance problems were identified for some types of primitives. It was decided to replace the mapped type with an equivalent one, but not having these problems during the hit test operation.

Since we manage the hit test to bypass WPF, we send the information about the actual visual element for which the hit test is performed to the hit handlers, and not about the element that WPF returns. In the main function of processing the hit test, it was optimized by us for using the quadtree. The WPF hit test system is not implemented efficiently enough or flexible enough for our tasks. Thus, in order to realize the optimization of a quadtree, we had to simulate the “micro-representation” hit test for each object separately by moving the displacement vector and transformation matrix from the Drawing objects to the DrawingVisual objects.

Inside the hit test itself, the algorithm is as follows.

We make the region in the form of a very short line and check it for intersection.
Create a micro-view stub, the equivalent of Canvas.
A special visual element is placed on the “micro-view” and encapsulates vector graphics from each visual element in turn.

We transfer information about the transformation to the visual element of the destination from the source and cancel the corresponding transformation of vector graphics.

var t = VisualTreeHelper.GetTransform(v); var o = VisualTreeHelper.GetOffset(v); destVisual.Transform = t; destVisual.Offset = o; if (drw.IsFrozen) drw = (DrawingGroup)drw.Clone(); drw.Transform = Transform.Identity;

In a special way, we form an element for the power flow hit test, which, when rendered, prepares a set of visual elements correctly for the hit test to replace low-level transformation operations.
Restoring the transformation of vector graphics. The undo-restore transformation operation is associated with incorrect operation of the hit-test system with transformation within the Drawing objects, while rendering into a bitmap, converting to EMF, etc. requires the assembly of vector graphics at a low level (Drawing), taking into account the transformation of the visual elements transmitted inside this graphic.

Optimize the rendering of vector objects

By default, WPF uses a vector model for drawing all objects, which reduces performance. For the correction, the system of bitmap caches on top of Visual vector objects was implemented. Caches were redrawn when changing the scale or updating the content of cached Visual.

The caching system is built in such a way that each visual element of the Visual type had to create a separate bitmap object through interaction with Windows OS and getting a handle to the bitmap, and since the number of available handles for the process is limited, it was necessary to take these limits into account. Accordingly, if a large number of objects were seen in the frame, then when this limit was exceeded, it was necessary to leave part of the objects without caches, but such cases are not often, and some of the cached images that still worked quite well, increased productivity. To calculate limits, use the following approach.

 RegistryKey hklm = Registry.LocalMachine; hklm = hklm.OpenSubKey("SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows"); GDIResourcesMax = (int)hklm.GetValue("GDIProcessHandleQuota"); double GDIUsageLimit = 0.7; double GDISafeResourcesLimit = GDIUsageLimit * GDIResourcesMax; public static int GetGuiResourcesGDICount() { return GetGuiResources(Process.GetCurrentProcess().Handle, 0); }

GDIUsageLimit - a coefficient that shows how many handles we can safely reserve for normal software operation;
GDISafeResourcesLimit - respectively, the number of objects, taking into account the coefficient;
GetGuiResourcesGDICount is a function that allows you to determine how many handles are allocated by the current process.

On the basis of these parameters, at the start of the application, the bitmap folders handled into the array, from which they were later extracted by the caching system as needed.

Each bitmap object is reserved with the following code:

 var bm = new BitmapCacheBrush(); bitmapCacheFree.Add(bm);

Database

The graphic file is a backup of the Firebird database and stores information about the graph visualization method. The visual presentation is created by the user and is located in the file with the extension “* .GVIEW”. A file may contain several schemas.

The main table is BASE_ENTITY, it stores all the basic properties of the view objects. For each specific type there is a table in which the remaining fields are stored. For example, for nodes it is BUS_ENTITY, for branches it is BRANCH_ENTITY. These detailing tables have a one-to-one relationship with the BASE_ENTITY table. Data integrity is mainly controlled by the referential integrity between tables. For example, deleting a view from a Gview table automatically deletes all objects belonging to it from the BASE_ENTITY table, and then cascadingly deletes the details from tables of specific types.

Block templates have a structure similar to views, and are also stored in the GView table with the HIDDEN flag set. The internal objects of blocks are not saved in the file, they are completely constructed when created on the basis of templates. Therefore, the settings of internal block objects made by scripts are lost during saving and loading.

Scenarios

Scenarios (scripts) control the signs of the equipment and other elements of the scheme depending on the events from the real equipment to the monitoring center. Depending on the events, the scripts control the visibility, the flickering effect, the color illumination, the output of data to the additional information elements that are attached by anchors to equipment signs, the visibility of groups, individual elements, etc.

Scripts are needed to fine-tune the visualization of CIM objects and to compute the data displayed by fields and output blocks. The module of scripts allows real-time execution of arbitrary calculations on objects of graphical representation and related entities, based on the obtained data, control the appearance and display the calculated data and telemetry data.

Thanks to the scripts, you can visualize different attributes of the graphic representation object in different ways, such as text, font, color, size and angle, arbitrarily control the visibility of the representations.

Before placing an object on a graphical representation or when changing the properties of an entity associated with an object, the script module calls the script and passes the context of the object and its environment to it. The essence of the script is to set the visibility, set the properties of the object passed to processing or calculate the data displayed for the object. For example, based on the accuracy of the data, you can change the color of the object or determine which additional fields should be displayed, and then hide or show the attached fields or data blocks.

Script execution

Script execution occurs in the context of the main application thread.

In order to improve performance, “lazy” execution is used, i.e. the execution of the script is always delayed until the moment when its data is really needed. For example, execution of scripts used to obtain text and other parameters of output fields is postponed until the moment of visualization. This means that if the view is tied to an invisible layer, or the value of the invisibility scale does not allow to see it, then the script that calculates the field will not be executed until the view becomes visible.

When the entity data changes, all the views attached to it are automatically updated, and for this, scripts that depend on the entity data are re-executed. Those. if the script accesses the context variable Entity, it is assumed that the script depends on the entity, and it will be recalculated.

On user actions by clicking or double-clicking, the corresponding scripts from the current script profile are launched immediately.
In the process of executing the script, erroneous situations may occur, leading to the throwing of exceptions. Unhandled exceptions are displayed by the notification module as pop-up notifications, and also saved to the user's local directory.

Common modules

Common modules are designed to determine the code of program modules reused by graphical scripts.

In the "Modules" section of the "Common Script Modules" dialog box, you can add, modify, or delete script modules by clicking the corresponding buttons. When defining a common module, you must specify its name, by which it will be accessible from the script. In the right part of the dialog box, in the “Module” section, the source code of the module is set using the script editor. The created modules can be reused when defining the code of various scripts.

To use the code for common modules in scripts, use the following script entry form, and in the script header, use the definition of uses to list the plug-ins separated by commas.

 {$MANUAL} //    uses 'common', 'math'; //    function __f__: Variant; begin //   A()  'common' Result := A(); end; Begin end.

Script Profiles

Script profiles allow you to create several sets of scripts that are called when the following graphical events occur:

change entity data;
single or double click on the graphic object;
Zoom the graphic representation.

When the entity data is changed, the text of the output fields and blocks attached to these entities is updated. To do this, run the scripts contained in the data output fields that calculate the output text and set the formatting.

With a single or double mouse click on a graphic object, it may be useful to display a pop-up dialog containing the details on the selected graphic object.

When you change the scale of the graphical representation, it may be useful to slightly zoom in or out the objects of the graphical representation, or to hide unnecessary objects so as not to clutter the screen.

The essence of the presentation scenario profiles is to provide the possibility to handle the above events in different ways, depending on the profile selected by the user. So you can create profiles that will adjust the colors of objects differently or differently will calculate the output data. In the ribbon menu of the graphical representation, the user can select the active script profile on which the current behavior of the graphical representation will depend. When changing the profile, all entities of the graphical representation are processed by the “Change Entity” script; if the script is complex and there are many objects, then it may take some time.

You can select the active profile of the scripts using the drop-down list.

Profile scripts in the ribbon menu.
To add a new script profile, you need to click the Add button located below the profile list in the Configure Script Profiles dialog box, and specify the name and description of the profile. After that, using the script editor, you can enter the profile code in the tabs:

change entity data;
mouse click;
double click;
change of scale.

Additional program features

Editing branches and primitives
The function of editing branches includes the ability to create fracture nodes on a branch and delete nodes. An orthogonal mode is also supported, in which the branches are respectively aligned along the coordinate axes at right angles. The functionality of integrating equipment signs onto a branch and moving them along the branch is supported.
When editing primitives, you can draw arbitrary elements, such as broken poly-lines, circles, sectors, text blocks, etc.

Work with equipment signs
The work with equipment signs in the case of placement on a branch includes the function of reflection of the sign on the branch relative to the axis of the branch. The ability to change the sign of the equipment and change the script control sign. As for ordinary characters, as well as for characters on a branch, additional anchor binding functions are available that can be controlled by the script and display additional information.

Object groups
Objects can be grouped and control the visibility of groups from scripts. The appearance of groups is determined by the specification of CIM-models. Groups can be nested into each other and automatically expand depending on the visible / invisible nested subgroups.

Data output unit

The tab "Output unit" allows you to configure a specific instance of the output unit, its position, block name for use in scripts, coordinates relative to the object to which the output unit is attached.

Block editing form

An example of the output blocks in the diagram

Using layers
The layer mechanism allows you to optimize the number of visible objects, depending on the scale, or on the script logic, or to tune in manually.

Copy to clipboard
The clipboard is multiformat and supports copying both in vector data and raster format.

Print
Available in both color and black and white. You can print any arbitrary area of the scheme.

Export to various formats
Export is available in various raster and vector formats (WMF, EMF, SVG).

Search
The function allows you to find the location of objects on a diagram by a piece of text, with automatic positioning of the viewing area.

Navigator
The navigator window allows you to see a sketch of the entire scheme in its entirety in a simplified form with the display of the current viewing area.

The equipment on which the software worked

The video card was specialized, which issued a resolution of 8192x3072, it did not have any accelerations, it only supported everything programmatically in order to draw a large resolution on the screen in the monitoring center.

Objects in the frame of about 100 thousand.

FPS in area 1.

Description of the installation in the control center.

The large screen in the control center consists of 24 sections, 8 wide and 3 high. Each section is a separate small screen with a resolution of 1024x1024 pixels. 24 projectors are installed on the reverse side, each shining on its own square.

Video fragment of the scaling circuit on the screen