Estratégias de Padrões de Projeto do tipo Bridge para o

Desenvolvimento de Softwares para Simulação de Sistemas

Dinâmicos de Grande Porte
J. A. S. Sena, W. Barra Jr., J.A.L Barreiros, M. C. P. Fonseca, B. M. Campos e C. T. da Costa.
Programa de Pós-Graduação em Engenharia Elétrica – Centro Tecnológico – Campus Universitário do Guamá – UFPA –
CEP 66075-900 – BELÉM – PA – FAX (91)3183-1634 – Fone (91)3183-1680
adolfo.sena@ig.com.br, walbarra@ufpa.br, barreiro@ufpa.br, mconcei@yahoo.com.br

Resumo: Vários trabalhos têm sido publicados sobre estratégias de programação orientada a objetos (OOP),
no desenvolvimento de softwares para sistemas elétricos de potência, visando tornar mais flexível o
desenvolvimento e a atualização de programas de simulação e análise de sistemas de grande porte. Este
trabalho apresenta um Framework para desenvolvimento de softwares para simulação dinâmica baseado em um
novo conceito em engenharia de software chamado de “Padrões de Projeto”. A vantagem deste enfoque é
tornar as mudanças nas especificações dos programas de simulação, como parte de seus requisitos, permitindo
adaptar mais facilmente grandes sistemas de software. Um simulador para sistemas elétricos de potência é
apresentado como estudo de caso.

Bridge Pattern Design Strategies Applied To The Development of Simulation

Software for Large Scale Dynamic Systems.
Abstract: In last years, many works have been published about research studies addressing the
flexible development of electric power system simulation software, In this work, it is presented the
design and development of a Framework aimed to allow for a more flexible development of new
dynamic simulators for large systems. The Framework is based on a new software engineering
concept, named Design Pattern, which has the advantage to allow for the manage of new
requirements during, and after that, the software development. In this way, leading to implementation
of a more flexible software product. In order to ilustrate the methodology, a case study on the
development of a electric power system simulator is presented.

Keywords: Software Engineering, Electric Power Systems, Dynamic Simulation, Object-Oriented Design.

1. Introdução programação escolhida foi a C++, por ser uma

Neste trabalho é apresentada uma
metodologia baseada em padrões de projeto e
um Framework para o desenvolvimento de
softwares para análise de sistemas elétricos de
potência de grande porte. Um padrão de projeto
é baseado nas melhores práticas desenvolvidas
por projetistas e usuários nos últimos anos (ver
em Shalloway et al, 2002). Como resultado deste
estudo, foi desenvolvido um Framework para o
desenvolvimento de simuladores para sistenas
dinâmicos de grande porte. Como exemplo, é
apresentado, neste artigo, a aplicação da
estratégia desenvolvida na implementação e
teste de um sistema elétrico de potência do tipo
multimáquinas.
Um Framework pode ser definido como um
conjunto harmônico de classes, rotinas, tipos de
dados e regras de codificação para uma
aplicação específica. A linguagem de
linguagem portável para a maioria dos sistemas
operacionais.
1.1. Uma visão geral
A metodologia apresentada neste trabalho
difere das práticas de desenvolvimento orientado
a objetos adotados nos anos de 1980. Naquela
época, os desenvolvedores eram levados a
encontrar substantivos nas definições dos
requisitos do software e transforma-los em
objetos. Portanto, os desenvolvedores tinham
uma visão limitada e definiam como
encapsulamento a ocultação dos dados e os
objetos como uma estrutura de dados que
continha campos com informações e funções
para manipular estes campos. Isto restringia sua
visão na implementação dos objetos do
problema.
1.2. O problema dos requisitos
Na fase de planejamento, o desenvolvedor
necessita obter o máximo de informações sobre
os requisitos do software a ser desenvolvido. De
acordo com Shalloway et al (2002), ao perguntar-
se a um desenvolvedor o que ele acha sobre as
informações obtidas a partir dos requisitos
obtidos do usuário, provavelmente ele dirá que:
• Os requisitos são incompletos.
• Os requisitos normalmente estão
errados.
• Os requisitos (e a informação
fornecida pelos usuários) não são
confiáveis.
• Os requisitos não contam tudo.
A razão para estas respostas, na grande
maioria das vezes, consiste na seguinte
constatação: os requisitos, na verdade, mudam
freqüentemente ao logo da vida do programa, ou
até mesmo durante o desenvolvimento de sua
primeira versão.
Para a grande maioria dos desenvolvedores,
esta constatação é muito ruim. No entanto,
poucos desenvolvedores tem levada esta
constatação em conta ao escreverem seus
programas.
Considerando-se o objeto de estudo deste
trabalho, um simulador dinâmico para sistemas
de grande porte. Ele pode ser considerado como
um exemplo de software com requisitos que
variam com o tempo. Com as inovações
tecnológicas dos últimos anos, novos tipos de
controladores, cargas, etc., tem surgido. Então
como representa-los em um software que já
existe e é constituído por milhões de linhas de
código em um espaço de tempo que acompanhe
estas mudanças?
Talvez estes requisitos devam incluir ainda as
possíveis mudanças nas características e
funcionalidades do software, no decorrer de sua
existência. A seguir são apresentados alguns
prováveis requisitos para um software destinado
a simulação dinâmica de sistemas elétricos de
potência:
O usuário deverá fornecer informações sobre
as barras existentes no sistema. Deverá informar
um nome, um identificador e algumas
informações referentes às potências, tensões e
fases.
O usuário deverá fornecer dados que
informem a topologia da rede elétrica (como as
diversas barras estão conectadas). Para este
requisito pode-se supor que o usuário possa
fornecer estas informações através de um editor
de diagramas unifilares, o que aumentaria a
complexidade do software e, talvez, tornaria a
entrada de dados pelo usuário mais demorado.
Outra possibilidade é à entrada das informações
de forma textual, o que simplificaria o software e,
talvez, tornasse mais rápida a entrada de dados
pelo usuário.
Apesar de existir um repertório de
dispositivos elétricos predefinidos no software,
constantemente dispositivos com novas
características têm surgido, o que torna o
repertório rapidamente desatualizado no decorrer
do tempo. Portanto, deverá ser fornecida ao
usuário a possibilidade de definir os seus
próprios modelos de dispositivos. O usuário
poderá ainda montar o modelo do dispositivo
através de blocos básicos (funções de
transferência, limitadores, integradores, etc.) ou
através de equações que descrevem a dinâmica
do dispositivo.
O usuário poderá ainda obter vários relatórios
referentes aos fluxos de carga, gráficos com as
curvas de diversas variáveis, etc. No entanto,
pode surgir a necessidade de novos tipos de
análises, sendo necessário disponibilizar o maior
número de resultados possíveis.
Como foi apresentado até aqui, os requisitos
reais do software estão em constante mudança,
portanto, este trabalho será focalizado na
especificação de regras e classes que constituam
o padrão.
Esta introdução foi escrita para que o leitor
tenha uma idéia de algumas questões envolvidas
na definição de padrões de projeto aplicados a
sistemas elétricos de potência. Os padrões estão
muito relacionados com a experiência de quem
os desenvolveu. Portanto, não devem ser
consideradas entidades fechadas e acabadas.
Devem ser encaradas como sugestões de regras
e práticas que levam ao desenvolvimento mais
eficiente.
2. Formulação do problema
2.1. Simulação dinâmica de sistemas elétricos
de potência
Sistemas elétricos de potência de grande
porte podem ser modelados como é ilustrado
através da figura 1.
Figura 1: Sistema de Potência com Múltiplas Máquinas
Antes que uma simulação dinâmica possa ser
executada, é necessário que os valores iniciais
das variáveis de estado e saídas dos dispositivos estratégia simplifica a implementação dos
dinâmicos sejam precisamente calculados. Estes programas de simulação, mas pode trazer
cálculos são feitos com o resultado do cálculo de problemas de estabilidade numérica. Com esta
fluxo de carga, no caso de sistemas elétricos de estratégia, a solução das equações é feita em
potência. duas etapas:
O problema de fluxo de carga envolve o Integração numérica. Nesta etapa a equação
estudo de matrizes esparsas e a solução de (2) é integrada e as variáveis de estado são
sistemas de equações não-lineares. Existem determinadas. Dependendo do método de
vários trabalhos abordando estes problemas integração, esta etapa necessita que a equação
(Kundur, 1994). (2) seja avaliada para vários valores x(t), y(t) e
Neste artigo, é suposto que os cálculos do u(t).
fluxo de carga e das condições iniciais do Cálculo das saídas. Nesta etapa a equação
sistema já estejam executados e que os dados (1) é avaliada, utilizando-se x(t), obtida da
estejam convenientemente armazenados em um integração numérica, e do sinal de excitação.
banco de dados, para uso durante a fase de
simulação dinâmica. 2.2.2. Solução integrada
A análise do problema apresentado neste
artigo é feita representando-se um sistema Outra alternativa é considerar y(t) também
elétrico de potência por meio de diagramas em como variável de estado. Esta abordagem exige
blocos. Estes diagramas são constituídos por um que a função g(.) seja derivável. Caso g(.) seja
bloco que representa a rede elétrica, blocos que derivável, pode-se reescrever as equações (1) e
representam as máquinas, e seus respectivos (2) na forma:
controladores.
d d
2.2. Integração numérica e a simulação de y (t ) = g [x(t ), u (t )] (3)
dt dt
sistemas elétricos de potência
d
x(t ) = f [x(t ), y (t ), u (t )] (4)
Por se tratar de um sistema dinâmico, a dt
representação computacional de um sistema
elétrico de potência não difere da representação Então se pode criar um vetor de estado
da maioria dos sistemas físicos eletromecânicos. ampliado X:
Esta representação é constituída por um conjunto
de equações diferenciais, escritas na forma  y (t )  (5)
matricial, como apresentado através da equação X (t ) =  
 x(t ) 
(2) e um conjunto de equações algébricas,
representadas através da equação (1).
Portanto, pode-se representar as equações
(1) e (2) por um único conjunto de equações
y(t ) = g [x(t ), u(t )] (1)
diferenciais, como apresentado na equação (6).
d
x(t ) = f [x(t ), y (t ), u (t )] (2)
dt d
X (t ) = h[X (t ), u (t )] (6)
dt
Onde x(t) são as variáveis de estado, y(t) são
as variáveis de saída e u(t) são as variáveis de Onde:
entrada. A equação (2) depende também das
variáveis de saída calculada em (1), isto pode ser
d 
justificado lembrando-se que as correntes g (.)
h(.) =  dt (7)
injetadas são calculadas, através das equações  f (.) 
da rede, e que os valores destas correntes, são  
usados no cálculo das tensões internas da d 
máquina, que são variáveis de estado no d  dt y (t ) (8)
problema em questão. X (t ) =  
dt d
 x(t ) 
 dt 
2.2.1. Solução por partes
A equação (6) está em uma forma apropriada
Pode-se adotar várias estratégias para se
para a integração numérica pela maioria dos
resolver simultaneamente as equações (1) e (2).
métodos explícitos.
Uma estratégia consiste em usar o valor de y(t)
Utilizando a equação (6) para a simulação do
do passo de integração anterior e então integrar
sistema dinâmico, está-se, de fato, resolvendo
a equação (2) e, quando terminada a integração,
o resultado x(t) é usado no cálculo de y(t). Esta
simultaneamente as equações diferenciais e não
diferenciais.
d “blo”. Os métodos que definem o comportamento
Em situações onde a obtenção de g (.) é
dt
muito complexa (ou até impossível), pode-se
d
y (t ) = 0 e usar a equação (1) para o
fazer
dt
cálculo destas variáveis, ou seja, usa-se a
abordagem de solução por partes.
Neste trabalho, é usado o vetor de estados
ampliado X para permitir que, sempre que
possível, usar a solução simultânea das
equações diferenciais e algébricas.
3. O Padrão de projeto Brigde
3.1. Introdução
O padrão Brigde é descrito em detalhes em
Shalloway et al (2002). Os requisitos de um
software variam com o tempo e este é o principal
problema que o padrão Brigde trata. Para incluir
no software a possibilidade dos requisitos
mudarem, o padrão estabelece que se deve
desacoplar a abstração da implementação de
maneira que os dois possam variar de forma
independente.
3.2. Definição das classes
Considerando o problema ilustrado neste
artigo, de desenvolvimento de um simulador
dinâmico, segundo o padrão Brigde, deve-se
definir uma classe de abstração que representa
um bloco genérico e uma classe que representa
a integração numérica.
A classe de abstração é a classe TBloco, e a
classe de implementação é a classe TSistema.
Quando novos blocos são criados, derivando
da classe TBloco (herança), não há necessidade
de mudanças na implementação da integração
numérica, ou seja, na classe de implementação
TSistema, pois esta nova classe segue padrões
que são herdados de sua classe mãe, de forma
que a classe TSistema verá a nova classe como
um TBloco, devido ao polimorfismo.
O relacionamento entre as classes de
abstração (TBloco e suas derivadas) e a classe
de implementação TSistema são ilustradas
através da figura 2. Nesta figura pode-se ver que
a única relação que existe entre as classes
TBloco e TSistema é uma agregação (Em um
objeto de TSistema pode haver vários objetos de
uma classe derivada de TBloco, mas estes
objetos têm existência independente do objeto de
TSistema e vice versa).
Na figura 2 é apresentada uma
representação em UML da classe TBloco. São
apresentados apenas os principais métodos. O
método ConectaEntrada é usado para conectar a
entrada “ent” do bloco na saída “sai” do bloco
dinâmico de um bloco são os métodos:
1) CalculaDerivadas. Este método é
responsável por calcular os valores das
derivadas das variáveis do bloco. Cada classe
derivada de TBloco deve substituir este método.
2) CalculaSaidas. Este método é responsável
por calcular as saídas do bloco. Cada classe
derivada de TBloco deve substituir este método.
3) CalculaValorInicial. Este método é
responsável por calcular os valores iniciais das
variáveis do bloco, usando o teorema do valor
inicial.
4) CalculaValorFinal. Este método calcula os
valores das variáveis do bloco em regime
permanente, usando o teorema do valor final.
Por herança, um bloco de primeira ordem,
por exemplo, pode ser criado como exemplificado
na listagem 1. Os blocos seguem a formulação
matemática composta pelas equações (6) e (1).
A equação (6) é avaliada no método
CalculaDerivadas e a equação (1) no método
CalculaSaida.
A classe TSistema representa o sistema
físico como um todo, um sistema agrega um ou
muitos blocos. Para criar uma instância de uma
classe derivada de TSistema, deve-se passar ao
método construtor da classe o número máximo
de blocos que serão inseridos no sistema. Para
inserir um bloco no sistema, usa-se o método
RegistraBloco, onde seu único parâmetro é um
ponteiro para o bloco a ser inserido.
Im plem entação da
integração num érica
TSis tem aRK4
+Integracao(h:doub le&, tempo:doub le&,
TSistem a
+TSistema(nbloco:int)
+ObtemNumEstados(): int
+RegistraBloco(b:PBloco): void
+Integracao(h:doub le&, tempo:doub le&,
1
1..n
+TBloco()
TBloco
+TBloco(ent:int, est:int)
+ConectaEntrada(ent:int, sai:int, blo:PBloco): void
+CalculaDerivadas(F:TMatriz, tempo:doub le):
+CalculaSaidas(_X:TMatriz, tempo:doub le): void
+CalculaValorInicial(): void
+CalculaValorFinal(): void
TLim itador
TBloco1aOrdem
-Xmax: double
-Xmin: double +TBloco1aOrdem()
+CalculaDerivadas(F:TMatriz, tempo:doub le):
+TLimitador()
+CalculaDerivadas(F:TMatriz, tempo:doub le):
+CalculaSaidas(_X:TMatriz, tempo:doub le): void
+CalculaSaidas(_X:TMatriz, tempo:doub le): void
+CalculaValorInicial(): void
+CalculaValorInicial(): void
+CalculaValorFinal(): void
+CalculaValorFinal(): void
Abs tração
"bloco"
Figura 2: Diagrama de classes com a separação
entre abstração e implementação
 Deve-se reforçar que a abordagem das equações da rede elétrica e da interface com
apresentada neste artigo está em conformidade a rede.
com o padrão Brigde, como é apresentado no Após a inclusão de Ra + jX d (ou Ra + jX d′
diagrama de classes na figura 2, onde se pode
verificar que classe TBloco e suas derivadas ou Ra + jX d′′ ) e a modelagem das cargas (por
estão relacionadas à classe TSistema por uma impedâncias constantes) , deve-se reduzir a
relação de agregação. Neste diagrama pode-se matriz admitância resultante em uma matriz cuja
verificar que qualquer nova classe criada dimensão é igual ao número de máquinas
derivada de TBloco não vai interferir na classe
presentes no sistema, esta é a matriz de rede
TSistema e suas derivadas.
reduzida Yred . A equação para cálculo da matriz
4. Duas classes derivadas de TBloco para reduzida é encontrada em Sauer e Pai (1998)
sistemas de potência
nas páginas 184-188. Sendo δ i o ângulo de
4.1. Interface Máquinas-Rede potência da máquina i e m o número de
máquinas, em Anderson e Fouad (2002) define-
Na parte superior da figura 3 é mostrado a se:
representação da clássica de um máquina no
sistema elétrico: uma tensão interna E q + jE d  e jδ 1 0 L 0 
 jδ 2 
atrás de uma impedância série Ra + jX d . Para 0 e L 0 
T = (9)
representar as máquinas no sistema elétrico,
 M M L 0 
 
deve-se ter em mente que sua dinâmica é  0 0 L e jδ m  m×m
representada por um sistema de equações
diferenciais e algébricas e a rede elétrica é
M = T −1Yred T (10)
representada por um sistema de equações
algébricas. Para simplificar as soluções das Sendo E o vetor com as tensões internas das
equações da rede e das máquinas, várias máquinas, então:
equações algébricas do modelo das máquinas
podem ser eliminadas se a impedância série  E q1 + jE d 1 
Ra + jX d for considerado como parte integrante  E + jE 
E =
q2 d2  (11)
da rede elétrica, desta forma obtemos uma matriz  M 
admitância de rede Y ′ , como ilustrado na Figura  
3. Esta formulação é apresentada em Sauer e  E qm + jE dm  m×1
Pai (1998).
Portanto:

I = M ⋅E (12)

Onde:

 I q1 + jI d 1 
 I + jI 
(13)
I =
q2 d2 

 M 
Figura 3: Modelagem usando nó interno  
 I qm + jI dm  m×1

Dependendo do modelo matemático (modelo

de regime, transitório ou subtransitório), X d′ ou
X d′′ são usados no lugar de X d e E q′ + jE d′ ou
E q′′ + jE d′′ no lugar de E q + jE d .
A tensão E q + jE d é uma variável calculada
Agora que uma formulação matemática foi
estabelecida para a representação da interface
entre máquinas e rede elétrica, pode-se
apresentar as duas principais classes derivadas
de TBloco na Framework para sistema elétrico de
potência.

através de equações diferenciais que necessitam 4.2. A classe TRede

dos valores da corrente I q + jI d para ser
A classe TRede é o bloco que representa a
calculada. Estas correntes são obtidas através
rede elétrica. Da formulação do item anterior, as admitância da rede reduzida Yred .
tensões internas das máquinas são calculadas
pelas suas equações diferenciais do seu modelo, • obtemY. Esta método copia os
e então estas tensões, em conjunto com o ângulo elementos da matriz reduzida
de potência são usadas para calcular as atualmente presente no objeto da
correntes injetadas na rede. Então foi classe TRede para a matriz complexa
estabelecido que na classe TRede serão (TMatrizComp) passada como
resolvidas as equações (9), (10) e (12), com isso, parâmetro.
as entradas do bloco que representa a rede • CalculaDerivadas. Este método
elétrica serão as tensões internas e os ângulos substituiu o método ancestral
de potência de cada máquina do sistema elétrico correspondente. Nesta implementação,
a ser simulador e suas saídas são as correntes as derivadas são todas feitas iguais a
injetadas por cada uma destas máquinas na rede zero, desta forma, a rotina de
elétrica. Na figura 4, é representado, integração numérica vai manter os
graficamente, o modelo computacional do bloco valores do passo de integração
que representa a rede elétrica. anterior.
• CalculaSaidas. Este método substitui
o método ancestral correspondente.
Nesta implementação, as equações
(9), (10) e (12) são avaliadas para que
as saídas do bloco sejam calculadas.

4.3. A classe TMaqSincrona

A classe “TMaqSincrona” representa uma

máquina síncrona genérica. Esta classe é
abstrata, ela foi definida para que se tenha uma
interface comum entre as classes que
representam os diversos modelos de máquinas
síncronas e o restante da framework.
Foi definido que suas entradas são as
Figura 4: Bloco que representa a rede elétrica correntes injetadas na rede I q e I d que
correspondem a saídas da classe TRede, a
class TRede: public TBloco potência mecânica Pm fornecida pela(s)
{
private: turbina(s) e a tensão de campo E fd fornecida
TMatrizComp Ybus;
public: pelos controladores automáticos de tensão. As
TRede(int nummaq); saídas são o ângulo de potência δ , a velocidade
void defineY (TMatrizComp &);
void obtemY (TMatrizComp &);
ω , a tensão interna do eixo em quadratura E q e
virtual void CalculaDerivadas(TMatriz F, double tempo); do eixo direto E d , a tensão terminal Vt , a
virtual void CalculaSaidas(TMatriz _X, double tempo);
}; potência ativa injetada Pt e a potência reativa
injetada Qt .
Listagem 1: Declaração da classe TRede

A definição da classe TRede é apresentada na

listagem 1.
Os métodos desta classe são:
• TRede. Este método é o construtor da
classe, deve-se passar como Figura 5: Uma representação esquemática da
parâmetro o número de máquinas classe TMaqSincrona
presentes no sistema.
• defineY. Este método é usado para
passar para a classe a matriz
TBloco TMaqSincrona
um regulador de velocidade, esta classe
-Ra: double
-Xq: double
-Xd: double
é abstrata, deve-se criar classes
-Xq_: double
-Xd_: double
derivadas para definir os diversos tipos e
-Xq__: double
-Xd__: double
modelos.
-Tdo_: double
-Tqo_: double
• TTurbina. Esta classe representa uma
-Tdo__: double
-Tqo__: double turbina, esta classe é abstrata, deve-se
-Da: double
-H: double criar classes derivadas para definir os
-fo: double
+TGer4()
diversos tipos e modelos.
+DefineReat(a:double, q:double, d:double, q_:double, d_:double, q__:double, d__:double): void
+DefineTemp(qo_:double, do_:double, qo__:double, do__:double): void • TRede. Esta classe representa a rede
+DefineMeca(o:double, g:double, a:double): void
+ObtemEquivalente(Yor:double&, Yom:double&): void elétrica.
+ObtemReat(a:double&, q:double&, d:double&, q_:double&, d_:double&, q__:double&, d__:double&): void
+ObtemTemp(qo_:double&, do_:double&, qo__:double&, do__:double&): void TTurbinaTermica TTurbinaHidrica TGovernadorTermico TGovernadorHidrico
+ObtemMeca(:double&, :double&, :double&): void
+ValoresIniciais(P:double, Q:double, Vtr:double, Vtang:double): void
+CalculaDerivadas(F:TMatriz, tempo:double): void TTurbinasSimples
+CalculaSaidas(_X:TMatriz, tempo:double): void

TTurbina
Figura 6: Representação em UML da classe TGovernador TRede

TMaqSincrona
TMaqSincrona1

O modelo computacional da classe TMaqSincrona2

TBloco

TMaqSincrona é apresentado através da figura 7. TMaqSincrona3 TMaqSincrona TAVRIEEE

Para vários modelos de máquinas síncronas TMaqSincrona5

existem várias classes derivadas de

TMaqSincrona4 TAVRIEEE1 TAVRIEEE2

TMaqSincrona que os implementam. No

framework estão implementados os modelos Figura 7: Uma ilustração com parte da hierarquia
apresentados em Arrilaga e Arnold (1990). de classes da Framework de sistemas de
A limitação de espaço impede que sejam potência
apresentadas todas as classes implementadas
no framework, devido a isto, o item a seguir faz 5. Resultados
um pequeno resumo das principais classes
Para validar o desenvolvimento, foi feito um
existentes.
teste que consistia em simular o caso
apresentado em Kundur (1994).
4.3. Resumo e uma visão geral das classes O diagrama unifilar do sistema é apresentado
atualmente implementadas no Framework através da figura 8.
Cabe reforçar que a classe TBloco é abstrata,
ou seja, ela não pode ser instanciada. A
finalidade desta classe é fornecer uma abstração
para um bloco e para ser utilizada como uma
classe primitiva a partir do qual são derivadas as
classes que representam blocos específicos,
como por exemplo, fontes de sinal, blocos de Figura 8: Diagrama unifilar do sistema usado
primeira ordem, máquinas síncronas, reguladores para avaliação
de velocidades, etc.
Um sistema elétrico de potência é um sistema Este sistema é caracterizado por estar no
dinâmico, desta forma, pode-se definir algumas limite de sua estabilidade dinâmica. O programa
classes, derivadas de TBloco, que representam utilizado como padrão de teste foi um programa
componentes de um sistema deste tipo. científico, desenvolvido em Ferreira et al (2003).
Pode-se definir as seguintes classes derivadas O caso simulado utiliza o modelo quatro
de TBloco para um sistema elétrico de potência: (Arrilaga e Arnold, 1990), para as máquinas
• TMaqSincrona. Esta classe representa síncronas. A simulação feita foi com potência
uma máquina síncrona, esta classe é mecânica constante e o controle de excitação foi
feito utilizando uma excitatriz de alto ganho,
abstrata, deve-se criar classes derivadas
como apresentado na figura 9.
para definir os diversos tipos e modelos.
• TAVRIEEE. Esta classe representa um
regulador automático de tensão, esta
classe é abstrata, deve-se criar classes
derivadas para definir os diversos tipos e
modelos.
• TGovernador. Esta classe representa Figura 9: Controlador de tensão

A falta aplicada foi um curto – circuito trifásico
na barra 8 no instante de um segundo com uma
duração de 100ms. Esta simulação foi feita no
simulador proposto em Ferreira et al (2003) e as
curvas das potências ativas terminal nas quatro
máquinas são apresentadas na figura 10.
Figura 10: Potências ativas terminais, obtidas
pelo programa apresentado em Ferreira
et al (2003)
As curvas obtidas pelo programa protótipo
são apresentadas na figura 11.
Figura 11: Potências ativas terminais, curvas
obtidas com o programa protótipo
Comparando a figura 10 e a figura 11, pode-
se observar que as curvas são qualitativamente
idênticas. Esta mesma obervação foi feita para
todas as outras curvas obtidas através dos dois
programas, podendo-se concluir que o framework
representa de, forma adequada, sistemas
elétricos de potência.
6. Conclusões
Esta framework foi escrita de maneira
flexível, porque os programas de análise de
sistemas elétricos de potência devem ser
flexíveis. Ela foi desenvolvida para que as
implementações de novos modelos e de novos
métodos de integração numérica nos programas
de simulação sejam feitas da maneira mais
simples possível.
7. Referência bibliográfica
Hakavik, B. & A. T. Holen (1994), Power System
Modelling and Sparse Matrix Operations Using
Object-Oriented Programming, IEEE
Transactions on Power Systems, Vol. 9, No. 2,
May 1994, pp 1045-1051.
Neyer, Andréas F. & Felix F. Wu & Karl Imhof,
Object-Oriented Programming for Flexible
Software, IEEE Transactions on Power
Systems, Vol. 5, No. 3, August 1990, pp 689-
696.
Pandit, Shubha & S. A. Soman & S. A. Khaparde,
Design of Generic Sparse Linear System
Solver in C++ for Power System Analysis,
IEEE Transactions on Power Systems, Vol.
16, No. 4, November 2001, pp 647-652.
Hebel, Zdravko & Boris Kajgnanié & Marko
Delimar (2000), On Sparse Matrices in C++
using Templates and Collection Classes Part I
– Modelling Power Systems Matrices, 22 Inf.
Conf. Information Technology Interfaces ITI
2000, June 13-16, 2000, Pula, Croatia.
Soman, S. A. & S. A. Khaparde and Shubha
Pandit, Computational Methods for Large
Sparse Power Systems Analysis – An Object
Oriented Approach, KLUWER ACADEMIC
PUBLISHERS, 2002.
Larman, Craig (1999), Applying UML and Patters
– An Introduction to Object-Orientd Analysis
and Design, Prentice-Hall.
Shalloway, Alan & James R. Trott (2002), Design
Patters Explained: A New Perspective on
Objected-Oriented Design, Addison-Wesley.
Manzoni, A. & A. S. Silva & I. C. Decker (1999),
Power Systems Dynamics Simulations Using
Object-Oriented Programming, IEEE
Transactions on Power Systems, Vol. 14, No.
1, February.
Arrilaga, J. & C. P. Arnold (1990), Computer
Analysis of Power Systems, pp 157-163, John
Wiley & Sons.
Sauer, P.W. and M. A. Pai (1998), “Power
System Dynamics and Stability”, Prentice-Hall.
Anderson, P. M. & A. A. Fouad (2002), Power
System Control and Stability, Wiley IEEE
Press
Kundur, P. (1994), Power System Stability and
Control, McGraw-Hill
Ferreira, A. M. D., W. Barra Jr, J. A. L. Barreiros,
C. T. Costa Jr. (2003), Programa de
Simulação Multimáquinas para Análise de
Estabilidade em Sistemas Elétricos de
Potência, Fifth Latin American Generation and
Transmission, São Pedro, S.P., 2003.