Definition of the Bays

As already mentioned the implementation of the functionality is oriented to the use of templates and visual symbols for the definition of the bays of the substation.
For example, let's show an implementation of a bay from a feeder: Be the name template FD, consisting of sub templates for each functional set of data:

For this type of bay and template will be defined a graphic symbol that will represent the behavior of this bay on the unifilar screen. The following figure is the Symbol FD:

FD symbol used for feeder bay

Each member of the bay template is another template, specializing in a data type. For example, the sub template FD_MEA contains the definition of the tags that will contain the data for each of the measurements available in the feeder:

Example of sub template with measurement data from bay.
When you want to instantiate or create the objects to actually model the bays of the substation is defined in the table Objects:

Bays objects defined in the first level

Topology Template

In implementing the Energizing View it is necessary to define the Topology, so we have defined an add-on sub template, which should be included in the main bay template.
For each project bay, this template must be inserted, with a different name for each bay type, because it will contain the encoding that will describe the topology of internal connectivity to the bay, which depends on each type of bay.
The figure shows this template, which should be used with these member names as defined below, as they are the names used in the real-time energization calculation algorithm.

Topology data template
In TAGSCONNECTION, the attribute StartValue contains, for the bay and current project, the names (sheets) of the tags that are used to save the state of the existing connection elements internally in the bay. You must fill this field with the names (sheets) of the tags, separated by semicolons.
This example was created for a feeder bay that only has one circuit breaker, as in the following figure. In the sub template that defines the tags of equipment states of this bay you have the tag P52A as being the only connection element (contains the open/closed state of the circuit breaker), as shown below.
This template also contains the tags that will receive the indication of energized or not for each branch of the bay: BRANCH[n]. These tags will have their values calculated by the algorithms of the class AllTopology and will be used to change the color of the branches used in the graphic symbols.

The real-time algorithm will consider, when checking the tag TAGCONNECTION, which for each connection element defined there will be two branches, one before and one after the connection element.
In BRIDXON, the BRANCH index that defines whether or not the bay is energized must be configured in the StartValue field. This is, for example, in the case of a feeder one should identify which BRANCH, if de-energized, will determine that the feeder is de-energized.
In this example, the tag will be considered BRANCH[0] as the first extension and the BRANCH tag[1] as the second extension, after the connecting element, in the direction of the electrical supply.
The member BAYSTATE, will receive, calculated by the class algorithm AllTopology, a 1 or a 0 as the bay is energized or not.

Topology with secondary route

A second example, representing a bay of a Line is shown below. In this case there are more connection elements, and even a secondary route within the bay. See the picture with the symbol used.
In this figure (symbol) are shown the connector elements with their names (sheets) and the branches of unifilares with the tags whose contents will be used to receive the indication of energization and choice of the color of the branch.
For the main route are used the tags TAGCONNECTION and the tags BRANCH{n]
To treat the secondary route, the StartValue of TAGCONNECTIONALT and the tags BRANCHALT[n] topology template.

See the following figure the state data template of this bay LINE, named LT_STA

In the Topology Template is the complete definition of the existing connections in the primary and secondary branches of the bay. See that the exact names of the tags, separated by semicolons, and in the correct feed order, are used for defining the connection elements.

Observation: Only use semicolons between tag names. Do not include semicolons at the end, as this would define an additional branch!
Also note that BRIDXON contains in the StartValue attribute the BRANCH index 3 that defines bay energization.

Forcing separation of branches
If you want to force, so that in real time, two branches are considered within a symbol that does not have internal connectors, you can define as a connector the word NONE. This will be considered as an element for separation, in two branches, however, will always be considered connected.
This facility is used in the Transformer symbol shown below. We need two branches so that they had different colors for each of the tensions.
Next to see the template used for the topology of this bay, so that the circles are considered in different branches.

Definition of Symbols

For each bay, the appropriate symbols must be defined. For each branch that can or cannot be energized separately, one must have a unifilar figure, which in real time will have the color imposed by the value of branch[n] tags.

If there is a secondary or alternate route, its colors are defined by branchalt[n] tags.
If there are different route runs that will be energized on whatever route is actually active, the color must be obtained by a logical OR between the appropriate tags. See the case of the final section of the feeder, shown in the following figure.
The expression used is:

IIf(#FD:(Tag.FDDUP).TOPG.BRANCHALT[1].Value==1 ||#FD:(Tag.FDDUP).TOPG.BRANCH[3].Value==1,1,0)

That is: the extension must be shown energized if the main or alternating path is energized.