Definição dos Bays
Como já mencionado a implementação da funcionalidade é orientada ao uso de templates e símbolos visuais para a definição dos bays da subestação.
Por exemplo, vamos mostrar uma implementação de um bay de um alimentador: Seja o template de nome FD, constituído de sub templates para cada conjunto funcional de dados:
Para este tipo de bay e template será definido um símbolo gráfico que representará o comportamento deste bay na tela de unifilar. A figura a seguir é o Símbolo FD:
Símbolo FD usado para o bay de alimentador
Exemplo de sub template com dados de medição do bay.
Quando se deseja instanciar ou criar os objetos para realmente modelar os bays da subestação se define na tabela Objects:
Objetos Bays definidos no primeiro nível
Template de Topologia
Na implementação da funcionalidade de Visualização de Energização é necessário definir a Topologia, por isto definimos um sub template a mais, que deve ser incluído no template principal do bay.
Para cada bay do projeto deverá ser inserido este template, com nome diferente para cada tipo de bay, porque ele conterá a codificação que descreverá a topologia de conectividade interna ao bay, que depende de cada tipo de bay.
A figura mostra este template, que deverá ser utilizado com estes nomes de membros como definidos a seguir, pois são os nomes utilizados no algoritmo de cálculo da energização em tempo real. 
Template de dados de topologia
Em TAGSCONNECTION, o atributo StartValue contém, para o bay e projeto atual, os nomes (folhas) dos tags que são utilizados para guardar o estado dos elementos de conexão existentes internamente no bay. Deve-se preencher este campo com os nomes (folhas) dos tags, separados por ponto e vírgula.
Este exemplo foi criado para um bay de alimentador que somente tem um disjuntor, como na figura seguinte. No sub template que define os tags de estados de equipamentos deste bay tem-se o tag P52A como sendo o único elemento de conexão (contém o estado aberto/fechado do disjuntor), como mostrado a seguir.
Este template também contém os tags que receberão a indicação de energizado ou não para cada ramo do bay: BRANCH[n]. Estes tags terão seus valores calculados pelos algoritmos da classe AllTopology e serão utilizados para alterar a cor dos ramos utilizados nos símbolos gráficos.
O algoritmo de tempo real vai considerar, ao verificar o tag TAGCONNECTION, que para cada elemento de conexão definido haverá dois ramais (branches), um antes e outro após o elemento de conexão.
Em BRIDXON, deve ser configurado no campo StartValue o índice do BRANCH que define se o bay está ou não energizado. Isto é, por exemplo, no caso de um alimentador deve-se identificar qual o BRANCH que, se de-energizado, determinará que o alimentador está de-energizado.
Neste exemplo, serão considerados o tag BRANCH[0] como o primeiro ramal e o tag BRANCH[1] como o segundo ramal, após o elemento de conexão, no sentido da alimentação elétrica.
O membro BAYSTATE, receberá, calculado pelo algoritmo de classe AllTopology, um 1 ou um 0 conforme o bay está energizado ou não.
Topologia com percurso secundário
Um segundo exemplo, representando um bay de uma Linha é mostrado a seguir. Neste caso há mais elementos de conexão, e inclusive um percurso secundário dentro do bay. Veja a figura com o símbolo utilizado.
Nesta figura (símbolo) estão mostrados os elementos conectores com seus nomes (folhas) e os ramos de unifilares com os tags cujos conteúdos serão utilizados para receber a indicação de energização e escolha da cor do ramo.
Para o percurso principal são utilizados os tags TAGCONNECTION e os tags BRANCH{n]
Para tratar o percurso secundário são utilizados o StartValue de TAGCONNECTIONALT e os tags BRANCHALT[n] do template de Topologia.
Veja na figura seguinte o template de dados de estado deste bay LINHA, de nome LT_STA
No Template de Topologia está a definição completa das conexões existentes nos ramos principal e secundário do bay. Veja que os nomes exatos dos tags, separados por ponto e vírgula, e na ordem correta de alimentação, são utilizados para a definição dos elementos de conexão. 
Observação: Somente utilize ponto e vírgula entre os nomes de tags. Não inclua ponto e vírgula no final, pois isto definiria um ramo adicional!
Observe também que BRIDXON contém no atributo StartValue o índice 3 do BRANCH que define a energização do bay.
Forçando separação de ramos
Caso se deseja forçar, para que em tempo real, sejam considerados dois ramos dentro de um símbolo que não possui conectores internos, pode-se definir como um conector a palavra NONE. Esta será considerada como um elemento para a separação, em dois ramos, porém, sempre serão considerados conectados.
Esta facilidade é utilizada no símbolo de Transformador mostrado abaixo. Precisamos dois ramos para que tivessem cores diferentes para cada uma das tensões.
Ao lado veja o template usado para a topologia deste bay, de forma que os círculos são considerados em ramos diferentes.
Definição dos Símbolos
Para cada bay devem ser definidos os símbolos apropriados. Para cada ramo que possa ser ou não energizado separadamente deve-se ter um a figura de unifilar, que em tempo real terá a cor imposta pelo valor dos tags BRANCH[n].
Se houver um percurso secundário ou alternado, suas cores serão definidas pelos tags BRANCHALT[n].
Se houver trechos de percursos diferentes que estarão energizados em qualquer que seja o percurso de fato ativo, a cor deve ser obtida por um OR lógico entre os tags apropriados. Veja o caso do trecho final do alimentador, mostrado na figura seguinte.
A expressão usada é
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 RELATEDCONNECTION, 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, you 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:
| Code Block |
|---|
IIf(#FD:(Tag.FDDUP).TOPG.BRANCHALT[1].Value==1 ||#FD:(Tag.FDDUP).TOPG.BRANCH[3].Value==1,1,0) |
Isto é: o ramal deve ser mostrado energizado se o percurso principal ou o alternado estiverem energizadosThat is: the extension must be shown energized if the main or alternating path is energized.
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
Nesta paginaOn this page:
|