ANEXO I - LISTA DE REQUISITOS FUNCIONAIS OBRIGATÓRIOS rv01

ANEXO I - LISTA DE REQUISITOS FUNCIONAIS OBRIGATÓRIOS_rv01

1. SCADA

1.01 Aquisição de Dados e Comunicação

Id RF Critério Descritivo do RFAtende SEM

customização

Atende COM

customização

RO 1.01.01 Aquisição dos dados O sistema proposto deve suportar uma arquitetura de FEPs (Front End Processors) distribuídos,

e conforme a necessidade decorrente de expansões do sistema, serem configurados em vários

pares redundantes.

RO 1.01.02 Aquisição dos dados O sistema a ser fornecido nos FEPs deve prover um ambiente com multiprotocolos de

comunicação e oferecer flexibilidade para a instalação de novos protocolos, sem interferir na

operação dos existentes.

RO 1.01.03 Aquisição dos dados Os FEPs devem realizar a troca de dados, via protocolos de comunicação listados, com os

seguintes dispositivos instalados em campo:

- os dispositivos RTUs (Remote Teminal Units) ;

- os IEDs (Intelligent Electronic Devices)

- os concentradores de dados instalados nas subestações;

- os concentradores de dados existentes que tem a função de agrupar as RTUs e IEDs

instalados na rede de distribuição da Copel;

- outros Centros de Controle, como é o caso de centros regionais da ONS.

RO 1.01.04 Aquisição de dados Para a aquisição de dados dos dispositivos de campo, o sistema deverá suportar e disponibilizar,

no mínimo, os seguintes protocolos de comunicação:

- DNP 3.0 nível 3, modo Mestre (serial)

- DNP 3.0 nível 3, modo Escravo (serial)

- DNP 3.0 nível 3, modo Mestre (TCP/UDP/IP)

- DNP 3.0 nível 3, modo Escravo (TCP/UDP/IP)

- IEC 60870-5-101, modo Mestre (serial)

- IEC 60870-5-101, modo Escravo (serial)

- IEC 60870-5-104, modo Mestre (TCP/UDP/IP)

- IEC 60870-5-104, modo Escravo (TCP/UDP/IP)

- Modbus RTU, modo mestre (TCP/UDP/IP)

- Modbus RTU, modo mestre (serial)

- ICCP (IEC 870-6 TASE 2) modo Servidor

- ICCP (IEC 870-6 TASE 2) modo Cliente

- IEC61850

RO 1.01.05 Aquisição de dados Todos os componentes dos protocolos devem estar baseados no seu respectivo padrão e

nenhum deles pode ser implementado por meio de emuladores ou conversores de protocolos.

RO 1.01.06 Aquisição dos dados Os FEPs devem ter suporte a múltiplos meios de acesso, para estabelecer a comunicação com

um dispositivo, nos casos da existência de mais de uma rota de comunicação disponível. O FEP

deve realizar de forma automática a transferência para uma rota alternativa caso a rota primária

tornar-se indisponível.

RO 1.01.07 Aquisição dos dados Os FEPs devem determinar se o canal de comunicação com os dispositivos remotos está

comunicando com sucesso. Caso o canal de comunicação seja identificado como defeituoso, os

FEPs deverão executar um número máximo de tentativas de recuperação da comunicação

(configurável). Se a comunicação não for restabelecida, o canal deve ser identificado como fora

de operação, e os indicadores de qualidade da informação devem ser atualizados, indicando que

respectivo canal de comunicação não está operando.

(nome e assinatura do representante legal)

Marque com um "X" a forma de

atendimento ao requisito


Advanced Distribution Management System (ADMS) - Lista de Requisitos Funcionais (RF) Obrigatórios

Observação - Esta planilha deverá ser assinada pelo representante legal.

PROPONENTE:

_________________________,__________ de______________________de___________

___________________________________________________________

ORIENTAÇÕES GERAIS

Este documento contem os requisitos funcionais obrigatórios do presente processo.

O PROPONENTE deverá assinalar com um "X" somente uma das seguintes colunas: "Atende SEM customização" ou "Atende

COM customização".

Requisitos funcionais assinalados com mais de uma opção serão considerados como “Atendidos COM customização”.

Todos os requisitos deverão ser assinalados com pelo menos uma opção.

Pg. 1 de 43


RO 1.01.08 Aquisição de dados O sistema deve comportar situações de avalanche de eventos decorrentes de distúrbios no

sistema elétrico, sem que com isso haja degradação, perda de confiabilidade ou de desempenho

do sistema de supervisão e controle.

RO 1.01.09 Aquisição de dados Quando um canal de comunicação estiver fora de operação, deve gerar a indicação dos pontos

de supervisão a ele relacionados com a condição de falha de telemetria.

RO 1.01.10 Aquisição de dados A adição ou remoção de dispositivos na configuração dos FEPs deve ser feita de forma on-line,

sem gerar a indisponibilidade dos FEPs , por interrupção de serviços ou necessidade de reinício

do sistema.

RO 1.01.11 Processos de

comunicação

Deverá ser informada a lista de protocolos suportada, bem como os que estão inclusos no

sistema, além dos mínimos exigidos. Adicionalmente deve-se detalhar através de manuais e

instruções técnicas as características de implementação dos protocolos fornecidos.


comunicação

O sistema de comunicação deve suportar canais de comunicação do tipo ponto-a-ponto,

multiponto e redes Ethernet , através de trocas de dados via protocolos de comunicação. Deve

suportar no mínimo comunicação serial RS-232C e pilha TCP/IP.


comunicação

A utilização dos protocolos TCP/IP e UDP/IP devem prever portas TCP e UDP configuráveis,

independente do protocolo de automação utilizado.


comunicação

Os concentradores de dados locais, existentes nas instalações da Copel (subestações e

concentrando dados da rede de distribuição), trabalham de forma redundante, no esquema Hot-

Standby, com um par de concentradores primário e secundário. Cada um destes concentradores

possui um endereço IP distinto. O FEP deve permitir a configuração e a comunicação com estes

concentradores locais.


comunicação

Os FEPs devem ser fornecidos com portas multi-seriais, com velocidades de comunicação

configuráveis entre 300 e 115200 bps.


comunicação

O sistema deverá ser capaz de aquisitar e processar, no mínimo, as informações abaixo

relacionadas, conforme as características dos protocolos de comunicação utilizados:

- os dados de eventos com estampa SOE,

- os dados de eventos sem estampa de tempo,

- os dados estáticos de estados binários,

- a leituras de classes;

- os valores analógicos,

- os valores de contadores,

- os envios e recebimentos de comandos,

- a sincronização de tempo,

- procedimentos de inicialização do dispositivo remoto

- o tratamento e a interpretação de códigos indicadores de qualidade,

- transferência de arquivos


comunicação

A aquisição dos dados deve incluir a possibilidade de realizar varreduras dos dispositivos

remotos, possibilitando a identificação de falhas de comunicação com os mesmos, bem como o

reestabelecimento para a condição normal.


comunicação

O processo de aquisição de dados deve incluir a codificação e a decodificação das mensagens,

conforme os protocolos de comunicação utilizados, bem como realizar a verificação e a indicação

de condições internas de qualidade disponibilizadas pelos respectivos protocolos (como a

indicação de módulos off-line, overflow de medição, etc), alimentando a etapa de processamento

de indicadores de qualidade.


comunicação

O sistema de aquisição dos dados deve permitir a leitura dos dados provenientes dos

dispositivos remotos utilizando-se os modos balanceados e não-balanceados, com o envio de

mensagens espontâneas, mensagens cíclicas e de integridade.


comunicação

As comunicações com as RTUs e demais dispositivos do campo (IEDs/concentradores) devem

usar a técnica de varredura (polling), onde o FEP deve iniciar todas as varreduras e os envios

de comandos. Adicionalmente o FEP deve aceitar mensagens não-solicitadas iniciadas pela

RTU/IED/concentrador.


comunicação

As solicitações de leitura de dados devem ser processadas de forma paralela nos dispositivos

configurados em canais de comunicação diferentes, e sequencialmente para dispositivos

configurados no mesmo canal de comunicação.


comunicação

Qualquer ponto recebido do protocolo de comunicação pode ser ignorado e não ser armazenado

na base de dados.


comunicação

O sistema deve permitir múltiplos protocolos em uma mesma conexão IP.


comunicação

As características das mensagens a serem enviadas nas requisições cíclicas e de integridade

(como por exemplo o tipo do objeto, variação, qualificador, range,etc), bem como os tempos de

varredura de cada mensagem configurada, devem ser parametrizáveis.


comunicação

Deve ser permitido configurar múltiplas requisições cíclicas (por exemplo, deve ser possível

configurar leituras temporizadas de objetos que tratam entradas analógicas, leitura de

contadores, entradas binárias, saídas binárias, etc).


comunicação

A periodicidade da varredura, tanto cíclicas quanto de integridade, devem ser configuráveis, para

cada tipo de informação solicitada, com uma escala mínima de 0,1 a 86400 segundos, com

degraus de 0,1s.


comunicação

Além das requisições cíclicas e de integridade configuradas no FEP, o sistema deverá ter a

capacidade de inserir varreduras solicitadas pelo operador, através da Interface Homem-Máquina

(IHM), e também varreduras solicitadas por programas e ferramentas integrantes do sistema ou

desenvolvidos pelo usuário.


comunicação

Quando for utilizado modo de envio de dados por exceção, deve ser possível inserir uma

varredura de integridade, caso seja configurado. O FEP deve solicitar a varredura de integridade

decorrido tempo configurável, disparado pelo recebimento de eventos, com intervalo de 0,1 a

86400 segundos, com degraus de 0,1s.


comunicação

O sistema deve permitir a leitura seletiva de pontos de estado, dos valores analógicos, de

valores de contadores nos dispositivos remotos, conforme as características dos protocolos

listados (leitura por faixa de pontos, por quantidade, por grupo de dados, etc).

Pg. 2 de 43



comunicação

O tipo de mensagem de varredura quando da primeira comunicação com o dispositivo remoto

deve ser parametrizável. Esta será a mesma mensagem que deverá ser enviada após

esgotarem-se as temporizações (timeouts) e o dispositivo ser desatualizado no sistema, após a

falha de telemetria.


comunicação

A mensagem de comando a ser enviado deve ser parametrizável, por ponto configurado,

conforme as opções disponíveis pelo protocolo de comunicação utilizado.


comunicação

O FEP deve possuir parametrizações que permitam estabelecer critérios para geração de

eventos analógicos para os canais escravos configurados, como indicação de banda morta. A

configuração deverá estar adequada as características do protocolo utilizado.


comunicação

A remoção, assim como a inserção de varreduras em uma RTU/IED/concentrador deve ser

possível sem comprometer a comunicação com outros dispositivos no sistema, mesmo para

aqueles configurados no mesmo canal de comunicação.


comunicação

Para a detecção de eventos no dispositivo remoto, o sistema deve permitir trabalhar com as

seguintes possibilidades, através de parametrizações disponíveis no FEP:

- tratamento de mensagens não-solicitadas recebidas pelo dispositivo remoto

- leitura periódica de mensagem de eventos, com tipo de mensagem e periodicidade

configurável;

- inserção automática de mensagem de evento pelo FEP, quando existir no protocolo algum

mecanismo de indicação de eventos no dispositivo remoto (como é caso das flags IIN -Internal

Indications, Class 1, 2, 3, existentes no protocolo DNP3.0).


comunicação

Deve ser possível parametrizar fatores multiplicadores (fatores de escala) e offsets para cada

ponto analógico, adequando o valor bruto enviado no protocolo de comunicação.

RO 1.01.36 Troca de dados ICCP Conforme a definição padrão TASE.2 Services and Protocol (IEC 60870-6-503) estão previstos

nove blocos de conformidade, os quais se associam com serviços para o gerenciamento da

comunicação. Baseados no padrão, deve ser fornecido no mínimo os seguintes serviços

completamente integrados ao FEP:

Bloco 1 – Serviços Básicos

Bloco 2 – Supervisão de Condições estendidas para Conjuntos de Dados (Data Sets)

Bloco 5 – Controle de Dispositivos

RO 1.01.37 Troca de dados ICCP Deve permitir que futuras expansões no sistema possam acrescentar links ICCP adicionais com

outros sistemas de controle.

RO 1.01.38 Troca de dados ICCP A solução deve prever a possibilidade de tratar a operação redundante, permitindo uma

configuração de dois trajetos de comunicações com cada conexão remota, sendo possível

designar uma trajeto principal e um trajeto secundário.

RO 1.01.39 Troca de dados ICCP O protocolo ICCP poderá também trabalhar no modo seguro, sobre uma conexão TCP/IP.

RO 1.01.40 Troca de dados ICCP Deve permitir uma combinação de links ICCP seguro e normal no mesmo sistema

RO 1.01.41 Identificação de erros O sistema deve ser capaz de detectar e identificar os erros abaixo listados, tendo a possibilidade

de gerar alarmes, eventos e registros no banco de dados e históricos para análise e identificação

de problemas:

- Ausência de resposta – situação na qual o dispositivo remoto não responde a solicitação do

FEP.

- Resposta inválida – situação na qual os dados recebidos são incompatíveis com os dados

solicitados.

- Pergunta inválida – os dados enviados não são aceitos pelo dispositivo remoto, indicando que a

varredura solicitada deve ser alterada no FEP.

- Resposta corrompida - o FEP recebe do dispositivo remoto mensagem com dados

corrompidos, decorrentes de checagem de algoritmos de detecção de erros , como LRC e CRC.

RO 1.01.42 Identificação de erros Para as condições de erros levantadas, devem existir parametrizações de novas tentativas,

antes que a condição de erro seja registrada.

RO 1.01.43 Identificação de erros O sistema deve permitir a configuração de comando de reset de link de comunicação, bem como

reset do equipamento remoto, quando o perfil de implementação do protocolo de comunicação

possibilite, na tentativa de restabelecer a comunicação com o mesmo.

RO 1.01.44 Identificação de erros Para evitar a geração de logs excessivos, como nos casos de canais com ruído, devem existir

filtros para a geração dos logs, definindo limites de erro a serem considerados.

Todos os detalhes com relação a gestão e armazenamento dos alarmes, eventos e condições de

geração de erro devem ser detalhados pelo fornecedor.

RO 1.01.45 Sincronismo SOE O sistema deverá tratar (solicitar, processar e armazenar) informações com estampa SOE

(Sequence of Events), conforme as características do protocolo de comunicação utilizado.

RO 1.01.46 Sincronismo SOE Deverá existir um sistema de tempo para determinar o Tempo Universal (UTC). A sincronização

de relógio do FEP deve ser possível por dispositivo GPS e por servidor NTP dedicado.

RO 1.01.47 Sincronismo SOE Deverá existir configuração que permita o descarte da estampa SOE enviada pelo dispositivo

remoto e haja a inserção da estampa local do FEP. Quando é realizada este procedimento, deve

existir alguma indicação que aponte que esta estampa foi inserida. Este caso serve para

dispositivos em que os eventos são reportados com estampa SOE, entretanto por algum motivo,

não é possível realizar o sincronismo de tempo no dispositivo remoto, estando a estampa com

erro temporal.

RO 1.01.48 Sincronismo SOE Uma configuração que permita conversão de fuso horário entre a estampa SOE enviada e a

estampa local do FEP deve ser disponibilizada.

RO 1.01.49 Sincronismo SOE O FEP deve permitir configuração que habilite/desabilite o sincronismo de tempo por protocolo de

comunicação, de forma individual, para cada sessão configurada.

RO 1.01.50 Ferramentas de

diagnósticos e

estatísticas

Para efeitos de diagnóstico, deve ser possível habilitar a captura das mensagens dos protocolos

que estão trafegando no canal de comunicação. Devem existir parametrizações que habilitem

níveis diferentes de detalhamento dessas informações.

Pg. 3 de 43



diagnósticos e

estatísticas

O sistema deve permitir a visualização em tempo real e a gravação de arquivos contendo as

informações de captura das mensagens dos protocolos. Deve ser possível parametrizar a

quantidade de arquivos a ser gerado, bem como o tamanho máximo dos mesmos.


diagnósticos e

estatísticas

O sistema deve manter as estatísticas de erro para todos os canais com os dispositivos remotos,

assim como o estado de cada canal de comunicação.


diagnósticos e

estatísticas

As estatísticas de erro de comunicação devem ser atualizadas e mantidas na base de dados de

históricos, permitindo análises posteriores. Devem também ser disponibilizadas aos usuários em

telas específicas.


diagnósticos e

estatísticas

Deve existir parametrização que defina o intervalo no qual as estatísticas serão resetadas. O

usuário deverá ter a capacidade de habilitar/desabilitar a funcionalidade de reset automático.

Poderá também realizar o reset manual e individual da estatística de um dispositivo. Em todas as

situações descritas, deve ser gerado log que indique as ações efetivadas.


diagnósticos e

estatísticas

O sistema deverá monitorar e registrar a integridade da rede local (LAN).


diagnósticos e

estatísticas

Os controles estatísticos deverão informar no mínimo:

a. Estatísticas de varreduras de dados

- Quantidade de Bytes transmitidos durante o período, sendo o período definido pelo usuário

- Quantidade de Bytes recebidos durante o período definido

- Número de Varreduras bem sucedidas durante o período definido

- Número de falhas de varreduras durante o período.

- Percentual de disponibilidade por RTU/IED/Concentrador baseado em tempo

(dia/semana/mês/ano).

b. Estratificação de Erros

- Não respostas (timeouts) durante o período definido

- Respostas inválidas durante o período definido

- Perguntas inválidas durante o período definido

- Outros erros de mensagem e de status (conforme o protocolo de comunicação utilizado)

c. Percentual da taxa de erro durante o período definido

d. Falhas de componente, equipamento ou módulo de software.

e. informações relativas a rede local (taxa média de ocupação, valores máximos de carga

obtidos, problemas detectados)

RO 1.01.57 Tolerância a falhas Deverá contemplar processadores primários de comunicação, e processadores secundários,

trabalhando no modo hot-standby. Os processadores secundários assumem a comunicação por

falha dos processadores primários, garantindo a redundância e a disponibilidade do sistema.

RO 1.01.58 Tolerância a falhas Além da implementação de FEPs primários e secundários, também deve existir a funcionalidade

de centro principal e de centro redundante (backup) implementada. A solução proposta deve

prever a existência de um centro principal, que realizará a leitura e a aquisição das informações,

e de um centro redundante (backup), que assumirá em caso de perda total do centro principal.

RO 1.01.59 Tolerância a falhas O sistema deve prever que, no chaveamento entre centros, as bases de dados entre os dois

locais estão sincronizadas.

RO 1.01.60 Tolerância a falhas Após a detecção de falha, o sistema deverá reconfigurar os dispositivos periféricos e

interconexões para trabalhar com as funções no servidor secundário.

RO 1.01.61 Tolerância a falhas Quando houver a necessidade de chaveamento manual entre a instalação primária e secundária

essa só poderá ser iniciada por um usuário autorizado.

RO 1.01.62 Tolerância a falhas A solução e a arquitetura proposta devem garantir a continuidade do serviço do centro de

operação, sem que haja perda ou corrompimento de dados quando do chavemento tanto do

esquema FEP primário/secundário, quanto do esquema Centro Principal / Backup.

RO 1.01.63 Tolerância a falhas Para os esquemas de chaveamento citados deve ser gerado alarme acompanhado de uma

mensagem que deverá ser automaticamente registrada em um arquivo histórico/estatístico.

RO 1.01.64 Tolerância a falhas O projeto deverá prever recursos e procedimentos que garantam o funcionamento do sistema na

presença ou existência de falhas momentâneas, intermitentes, ou permanentes, simples ou

múltiplas, evitando a perda do sistema como um todo.

RO 1.01.65 Tolerância a falhas No sentido de aumentar a confiabilidade e a disponibilidade, deve-se prever redundância de

equipamentos, de recursos de rede e de dispositivos de chaveamento para casos de falhas.

RO 1.01.66 Tolerância a falhas As falhas de um componente, equipamentos ou módulos de software devem ser detectadas,

identificadas e registradas no sistema de históricos e estatísticas.

RO 1.01.67 Tolerância a falhas A arquitetura do sistema deve prever troca de dados entre subsistemas de comunicação do

centro de operação principal e backup com redundância de LAN.

RO 1.01.68 Tolerância a falhas Em caso de falha da LAN ativa, a troca de dados deverá ser automaticamente chaveada para a

outra LAN, sem que haja qualquer interrupção da operação do sistema ou perda de informação.

1.02 Processamento de dados


customização

Atende COM

customização

RO 1.02.01 Geral O sistema deve ser capaz de processar dados provenientes dos dispositivos de campo e de

outros sistemas SCADA. Os seguintes dados devem ser suportados:

- Estados;

- Analógicos;

- Contadores;

- Indicadores (flags) de qualidade;

- Dados calculados.

Pg. 4 de 43


RO 1.02.02 Pontos de estado O sistema deve ser capaz de processar valores de estado, acompanhados de suas estampas de

tempo SOE, caso possuam. Adicionalmente, o sistema deve registrar as estampas de tempo do

instante do recebimento dos dados pelo SCADA.

RO 1.02.03 Pontos de estado O sistema deve processar os estados recebidos no banco de dados, comparando o valor atual

com o armazenado, reportando qualquer mudança. Deve detectar se a mudança foi proveniente

de uma ação de controle, para tratamento diferenciado de alarmes.

RO 1.02.04 Pontos de estado O sistema deve ser capaz de tratar múltiplas mudanças, conseguindo compreender alterações

coletivas de estados de um ponto, recebidas em um único ciclo de varredura. Cada mudança

recebida deve ser processada com o seu evento registrado.

RO 1.02.05 Pontos de estado O sistema deve permitir criar e atribuir indicativos de classificação para pontos, de modo a ser

possível definir os descritivos para os estados '0' e '1' de cada ponto.

RO 1.02.06 Pontos de estado O sistema deve permitir associar aos pontos indicações de normalidades do estado, como por

exemplo estado normal 'aberto' ou 'fechado'. O estado anormal de um ponto deve ser

representado através de indicador de qualidade.

RO 1.02.07 Pontos de estado O sistema deve comportar pontos de estado de equipamentos que possuam mais de dois

estados associados, tipicamente estado aberto, fechado e em curso.

RO 1.02.08 Pontos de estado Tratamento 'anti-bouncing':

O sistema deve ter controle de modo a prevenir número excessivo de mudanças em um ponto

de estado provenientes de um equipamento de campo, evitando que alarmes e registros de

eventos fiquem sobrecarregados.

Quando um número máximo de eventos em um espaço de tempo for identificado, a atualização

do ponto de estado deve ser desativada e o operador deve ser avisado.

O retorno da atualização do ponto pode ser manual pela operação ou automática, quando o

sistema identificar que o problema cessou.

RO 1.02.09 Pontos de estado Pontos de estado devem possuir opção de inversão dos valores recebidos pela telemedição

antes da inserção no banco de dados.

RO 1.02.10 Pontos de estado Pontos de estado de equipamentos, como chaves e disjuntores, devem possuir contadores

associados para controle de número de operações.

O valor de um contador pode ser provieniente de um equipamento remoto, recebido através de

protocolo de comunicação. No caso dessa informação não estar disponível no equipamento, o

valor do número de operações deve ser processado pelo sistema.

RO 1.02.11 Pontos analógicos O sistema deve processar todos os dados analógicos recebidos, registrando as estampas de

tempo do instante do recebimento dos dados pelo SCADA.

Eventos analógicos provenientes de telemetria que possuem estampa de tempo devem ser

processados.

RO 1.02.12 Pontos analógicos Histerese em zero:

O sistema deve permitir configurar um valor de banda morta ou histerese para pontos analógicos,

de forma a permitir que o valor de um ponto permaneça em zero quando o seu valor ficar

oscilando em torno de zero. Isso permite diminuir ruídos das medições.

RO 1.02.13 Pontos analógicos –

conversão de valores

Valores analógicos devem ser convertidos de valores brutos para valores de engenharia, para

armazenamento na base de dados.

A conversão do valor é feita da seguinte forma: valor = (F * valor lido) + D

onde 'F' é o fator de escala (multiplicador) e 'D' é o deslocamento ('offset').

Os coeficientes 'F' e 'D' devem ser configurados por ponto a ser convertido.


limites

O sistema deve possuir funções que gerenciem o estabelecimentos dos limites. Deve ser

permitido configurar limites para todos os pontos analógicos da base de dados.

Os limites configurados devem ser verificados a cada nova entrada no banco, seja por varredura,

por cálculo ou por entrada manual. A estampa de tempo do momento da violação de um limite

deve ser registrada.


limites

O gerenciamento dos limites devem suportar definição de bandas mortas ou histereses.


limites

Limites de razoabilidade:

Deve ser possível configurar limites superiores e inferiores de razoabilidade, para que a medição

fique em uma faixa que seu valor seja considerado válido para o ponto.

Ao ocorrer uma violação de um limite de razoabilidade, o valor do dado deve ser descartado,

mantendo o último valor válido na base de dados. Ao ocorrer o retorno do valor para dentro do

limite o ponto deve voltar a ser atualizado na base de dados.


limites

Limites operacionais:

Deve ser possível configurar ao menos quatro conjuntos de limites superiores e inferiores por

ponto. Quando um dos limites for excedido, o seu valor deve ser armazenado na base de dados

e o evento deve ser registrado .

Esses limites devem ser possíveis de serem substituídos em tempo real pela operação. Ao se

remover a substituição os limites devem voltar a configuração padrão da base de dados. Essas

substituições devem ficar registradas, devendo conter a estampa de tempo e a identificação do

usuário que a realizou.

Tanto os limites configurados na base de dados como os substituídos devem respeitar os limites

de razoabilidade de cada ponto.


limites

Limites operacionais devem poder ser alterados através de tabelas, de acordo com horário, dia

(dia de semana, sábado, domingo, feriado) e de acordo com o patamar de carga (leve, média,

pesada).


limites

Taxa de variação:

Taxas de variação devem ser opcionalmente configuradas para pontos da base de dados.

Cada limite deve ser temporizado com um valor parametrizável, em segundos, de forma com que

a violação do limite possa ser validada pelo tempo configurado, evitando múltiplas violações

devido a oscilações dos valores de um ponto sobre um limite.

Taxas de variação poderão ser desativadas pela operação.

RO 1.02.20 Substituição de valores O sistema deve permitir que, no caso de valores incorretos ou faltantes, os dados possam ser

substituídos manualmente ou por valores estimados, provenientes do módulo de estimador de

estados.

Valores substituídos devem possuir indicador de qualidade, e informações da estampa de tempo

do momento da substituição e identificação do agente que a realizou.

Pg. 5 de 43


RO 1.02.21 Fonte alternativa de

dados

O sistema deve ter a capacidade de substituir um ponto da base de dados, telemedido ou

calculado, por um ponto de uma fonte alternativa configurada.

Pontos da fonte primária devem ser considerados inválidos em situações de falha de telemetria,

violação de limites de razoabilidade, falha no cálculo e por comando manual.

A comutação entre fonte de dados primária e alternativa deve ser feita automaticamente, de

acordo com a disponibilidade da fonte primária. Dados que estejam sendo atualizados por uma

fonte alternativa devem ter indicador dessa qualidade.

O sistema deve prover meios do operador visualizar os dados da fonte alternativa, para tomada

de decisão de comutação manual.

RO 1.02.22 Indicadores de

qualidade

Cada ponto da base de dados do sistema deve possuir códigos que indiquem a sua condição

atual. A base de dados deve armazenar todos os indicadores de qualidade que estejam ativos

para um ponto.

O sistema deve tratar os indicadores de qualidade provenientes dos protocolos de comunicação.

Os indicadores de qualidade ativos devem ser visualizados pela operação e devem ficar

disponíveis para outras funções do sistema.

RO 1.02.23 Indicadores de

qualidade

O sistema deve processar pelo menos os seguintes indicadores de qualidades, de acordo com

as funcionalidades presentes:

- Alarme inibido: alarmes não são gerados para o ponto;

- Evento inibido: registros de eventos não são gerados, mas a base de dados continua sendo

atualizada;

- Limite violado: ponto está com limite superior ou inferior ultrapassado;

- Limite de razoabilidade violado: ponto está com limite de razoabilidade superior ou inferior

ultrapassado;

- Taxa de variação inativa: taxa de variação de um limite está desabilitada;

- Desatualizado ou antigo: ponto não foi atualizado por um período, definido pelo usuário;

- Falha na telemetria: o dado não está sendo coletado por telemetria;

- Estado anormal: o estado do ponto não está em seu valor normal;

- Substituído: dado do ponto foi inserido manualmente;

- Modo teste: eventos e alarmes não são gerados;

- Cálculo suspeito ou inconsistente: ponto calculado está com valor inconsistente;

- Desabilitado ou cancelado: o ponto não é atualizado pelo sistema;

- Fonte alternativa: a fonte alternativa do dado está em uso.

RO 1.02.24 Cálculos O sistema deve fornecer recursos para permitir definir e executar cálculos em tempo real.

RO 1.02.25 Cálculos Os cálculos devem envolver grandezas analógicas e de estados, telemedidos, não telemedidos e

calculados, podendo ser utilizados nos cálculos qualquer ponto da base de dados.

RO 1.02.26 Cálculos Os resultados dos cálculos devem ser armazenados no banco de dados da mesma forma que

dados telemedidos, sem restrições. Esses dados devem ser acessados pelo historiador e

qualquer outra aplicação do sistema.

RO 1.02.27 Cálculos O sistema deve permitir escolher a forma e a frequência de atualização dos dados calculados,

bem como as suas prioridades.

Os cálculos devem ser atualizados das seguintes maneiras:

- Periodicamente, com a periodicidade configurável;

- Devido a uma mudança de valor de um dos seus argumentos;

- Sob demanda da operação, a partir de uma tela.

RO 1.02.28 Cálculos Pontos calculados devem herdar indicadores de qualidade dos pontos utilizados como

argumentos do cálculo realizado, quando aplicável. Por exemplo, um ponto utilizado no cálculo

está com seu valor substituído, o ponto resultante do cálculo deve possuir o indicador de

qualidade substituído.

RO 1.02.29 Cálculos O sistema deve possuir recursos que detectem falhas e inconsistências nos valores dos dados

calculados, como por exemplo fora de escala e a divisão de um valor por zero. O ponto calculado

deve possuir indicação de qualidade para reportar esses problemas.

RO 1.02.30 Cálculos gerais O sistema deve possuir ferramentas que permitam a configuração e realização de cálculos

gerais, através de scripts ou linguagem de programação.

RO 1.02.31 Cálculos gerais O sistema deve suportar ao menos as seguintes operações:

1) Operações algébricas

- Operações aritméticas (+, -, *, /)

- Módulo, valor absoluto

- Somatórios

- Exponenciais

- Raíz quadrada

- Funções logarítmicas

- Cálculos trigonométricos (seno, cosseno, tangente)

2) Funções Booleanas (OR, AND, NOT, XOR)

3) Cálculos Condicionais (IF, THEN, ELSE)

4) Comparadores (>, =>, =, =<, <, ≠)

Deve ser permitido cálculos complexos, com operadores sequenciais como parênteses e

colchetes.

RO 1.02.32 Cálculos gerais O sistema deve permitir utilizar indicadores de qualidade de um ponto como argumento de um

cálculo.

RO 1.02.33 Cálculos gerais O sistema deve permitir configurar lógicas de controle, que possibilitem o envio de telecomandos

para equipamentos ou SCADAs, via protocolo de comunicação.

RO 1.02.34 Cálculos predefinidos O sistema deve permitir armazenar equações algébricas utilizadas, de forma que seja possível

definir um cálculo apenas especificando a equação e os pontos de dados a serem utilizados.

RO 1.02.35 Cálculos – funções

embutidas

O sistema deve fornecer bibliotecas de funções para cálculos de grandezas elétricas típicas, tais

como potência e fator de potência.

RO 1.02.36 Cálculos dinâmicos O sistema deve permitir que cálculos possam ser definidos dinamicamente pelo operador,

devendo possuir interface adequada para introdução dos mesmos.

Pg. 6 de 43


RO 1.02.37 Cálculos de mínimo/

máximo e média

O sistema deve possuir funções para calcular mínimos e máximos, bem como a média, de um

valor telemedido ou calculado, de acordo com um período de tempo definido.

Os resultados dos valores mínimos e máximos devem estar acompanhados da estampa de

tempo de quando esses valores foram detectados.

RO 1.02.38 Cálculos de integração O sistema deve ter a capacidade de realizar cálculos integrais, com variáveis analógicas e

contadores de qualquer ponto da base, de acordo com um período de tempo especificado.

RO 1.02.39 Registro de eventos O sistema deve ter a capacidade de registrar todos os eventos, de origem interna do sistema ou

externa recebidos através de telemetria.

RO 1.02.40 Registro de eventos O sistema deve detectar e registrar os seguintes eventos:

- Mudanças provenientes da telemetria;

- Mudanças provenientes de dados calculados;

- Mudanças devido a entradas manuais, como substituição de valores e alterações de limites;

- Mudanças devido a comandos;

- Violação de limites analógicos;

- Reconhecimento e inibição de alarmes;

- Aplicação ou remoção de marcadores operacionais.

RO 1.02.41 Registro de eventos Cada evento registrados deve conter pelo menos as seguintes informações, quando aplicável:

- Estampas de tempo;

- Nome do ponto;

- Estado ou valor do ponto;

- Descrição da mensagem do evento;

- Identificação do usuário;

- Identificação da aplicação ou função.

RO 1.02.42 Registro de eventos –

SOE

O sistema deve registrar todas as estampas SOE das mudanças recebidas dos dispositivos de

campo, mantendo a precisão de tempo de milisegundos. Deve ser capaz de suportar as

características do SOE de acordo com o protocolo de comunicação.


SOE

Para garantir a precisão do SOE, deve ser possível realizar sincronismo de tempo com os

dispositivos de campo, de acordo com as definições do protocolo de comunicação utilizado.


SOE

Deve permitir que o tratamento das estampas de tempo SOE possa ser desabilitado, de forma a

permitir descartar as estampas vindas dos dispositivos ou sistema que esteja comunicando,

mantendo apenas a estampa de tempo do recebimento pelo SCADA.


SOE

Deve ser possível fazer tratamento das estampas de tempo recebidas, considerando fusos

horários e horário de verão, a critério do usuário.


relatório

Os registros de eventos devem estar disponíveis para exibição em forma de relatório, que deve

ficar disponível para visualização em tempo real em tela para a operação, sob solicitação.


relatório

O relatório deve ser em forma tabular, sendo que cada evento deve ficar registrado em uma linha

separada.


relatório

Deve ser possível organizar os registros de eventos cronologicamente. Mecanismos adicionais

de filtros e pesquisas devem estar disponíveis, de modo a facilitar a visualização.


relatório

Deve permitir que o operador possa adicionar um texto de comentário para cada registro de

evento.


relatório

Os registros de eventos devem devem ficar distribuídos em telas de acordo com a área de

responsabilidade do operador.


histórico

Os registros de eventos devem ficar disponíveis para análises posteriores, devendo ser

arquivadas pelo historiador.

RO 1.02.52 Cálculo LOC FALTA Apresentar após evento de abertura por relés de proteção de redes, a distância estimada do

defeito, disponibilizando ao DMS para indicação de possível ponto de defeito.

1.03 Controle Supervisório (Telesupervisão e Telecomando)


customização

Atende COM

customização

RO 1.03.01 Telecomando Deve permitir o envio de comandos de operação (manobra) tais como abertura/fechamento de

dispositivos de campo ou comandos de configuração através de interface gráfica onde é

apresentado o diagrama unifilar de Subestações e de equipamentos instalados na rede de

distribuição.

RO 1.03.02 Telesupervisão Deve ter a capacidade de apresentar ao operador, sob forma gráfica ou através de desenhos

esquemáticos, os valores provenientes das medições realizadas em tempo real de todos os

equipamentos automatizados, além das indicações de estado dos dispositivos. (valores

analógicos e digitais).

RO 1.03.03 Telesupervisão Deve, dependendo da situação, emitir comandos de controle automaticamente por uma

aplicação inteligente do sistema, ou manualmente pelo operador.

RO 1.03.04 Marcadores

operacionais

O sistema deve possuir marcadores (tags) operacionais. Esses marcadores servem para que os

operadores possam definir características e qualidades de pontos da base de dados. Um ponto

pode possuir múltiplos marcadores associados.

Marcadores devem possuir indicativos visuais, como nome, cor e símbolo, preferencialmente

configuráveis.

O sistema deverá registrar a identificação do operador e a estampa de tempo, ao se colocar e

retirar marcadores.


operacionais

O sistema deve permitir que marcadores possam ser colocados e removidos para um

agrupamento de pontos, através de uma única operação.


operacionais

O sistema deve permitir incluir comentários para cada marcador colocado.


operacionais

O sistema deve fornecer um sumário de todos os marcadores inseridos para visualização do

operador.

Pg. 7 de 43



operacionais

O sistema deve suportar pelo menos os seguintes marcadores:

- Bloqueio de controle: nenhum pedido de controle é permitido.

- Modo teste: nenhum evento ou alarme é gerado. Caso o ponto esteja sendo repassado para

outros sistemas deve ser enviado o indicador de qualidade.

- Manutenção: não são gerados alarmes e o controle não é permitido. Eventos são gerados

normalmente.

- Alarme inibido: alarmes não são gerados.

- Desabilitado: não são feitas atualizações do valor pelo sistema.


operacionais

Os marcadores devem relacionar-se às “tag's” referenciadas no item 2.12 da especificação DMS

deste documento.

RO 1.03.10 Relatório Anormalidades

Pendentes

Deve possui relatório demonstrando estados e configurações ANORMAIS de equipamentos, afim

de verificar necessidade de providências a pendências temporárias.

1.04 Gerenciador dos procedimentos de manobras


customização

Atende COM

customização

RO 1.04.01 Geral Função que permite ao operador criar, modificar e executar sequências de operações. Estas

sequências podem ser usadas no modo de simulação, ou no modo tempo-real.

RO 1.04.02 Telecomando Deve fornecer ao operador interface para seleção de equipamentos ou trechos no diagrama

unifilar afim de apresentar solução de manobra para a retirada de operação do

equipamento/trecho selecionado com possível necessidade de intervenção.

RO 1.04.03 Simulações Deve simular a manobra, prevendo determinado horário, demonstrando o impacto de requisitos

de qualidade do fornecimento de energia.

RO 1.04.04 Simulações Deve consistir manobra programada ou em simulação, em período coincidente com outra

manobra que possa interferir na execução.

RO 1.04.05 Simulações Em caso de indisponibilidade de um equipamento, o SCADA pode sugerir manobra para

recomposição ou correção da qualidade no fornecimento. Exemplo: Quando um banco de

capacitor indisponível na SE, sugere correção por banco de regulador de tensão. Quando um

religador indisponível, sugere qual outro religador de melhor opção para transferência de carga.

RO 1.04.06 Simulações Deve permitir cadastrar uma manobra, que será executada em caso de um possível contingência

prevista, para que se realize automaticamente, após decisão do operador.

1.05 Processamento e Reconhecimento de Alarmes


customização

Atende COM

customização

RO 1.05.01 Geral Deverá ser previsto um sistema de processamento de alarmes onde seja permitido alertar o

usuário sobre condições não usuais no sistema, tais como: abertura de dispositivos elétricos,

ultrapassagem de limites, ocorrências no sistema de comunicação e equipamentos pertencentes

à configuração computacional. Deverá prover um sistema de gerenciamento de alarmes que

comporte situações de avalanche de alarmes decorrentes de distúrbios no sistema elétrico, sem

que com isso haja a degradação, confiabilidade e desempenho do Sistema de Supervisão e

Controle.

RO 1.05.02 Geral O processamento de alarmes deve ter por objetivo notificar os controladores da ocorrência

espontânea no sistema elétrico, a irregularidade funcional de alguns equipamentos ou do sistema

digital ou ainda de ultrapassagem de limites operativos de medições.

RO 1.05.03 Geral Deverá ser dimensionada pelo Fornecedor capacidade para o processamento de alarmes,

displays e registros associados, tal que não ocorra degradação do Sistema no Estado de Pico.

Em nenhuma condição deverá haver perda de alarme ou de registro (“logging”).

RO 1.05.04 Geral Somente o alarme não reconhecido mais recente para cada ponto deve permanecer na lista de

Resumo de Alarmes.

RO 1.05.05 Geral A cronologia de alarmes deve ser respeitada, marcadas no tempo e suportar sequencia de

eventos (SOE).

RO 1.05.06 Geral Os controladores poderão visualizar os alarmes através de filtros e prioridades configuráveis.

RO 1.05.07 Geral O sistema deve apresentar menu de ajuda sobre como responder os alarmes.

RO 1.05.08 Geral Os controladores deverão ter a capacidade de registrar informações (textos de forma livre) em

qualquer alarme ou seleção de alarmes.

RO 1.05.09 Geral Os controladores devem ter a capacidade de visualização do histórico de alarmes com base em

um período determinado pelo usuário.

RO 1.05.10 Geral Todos os alarmes devem ser registrados na base de dados históricos e disponibilizados para

outras aplicações

RO 1.05.11 Geral Os controladores devem ter a capacidade de acessar qualquer tela de unifilar ou documento,

através de seleção de qualquer alarme.

RO 1.05.12 Geral As mensagens dos alarmes devem ser apresentadas em formato padrão definido pelo usuário e

apresentadas em uma única linha de texto disponível em telas tabulares dedicadas.

RO 1.05.13 Geral As mensagens dos alarmes devem apresentar no mínimo as seguintes informações:

- data e hora de atuação.

- Descrição do ponto atuado.

- Descrição do estado ou valor de atuação.

- Mensagem do alarme (descrição definida pelo usuário).

- O limite violado das medidas analógicas.

- Identificação do usuário quando associado à uma ação do controlador.

- Identificação do subsistema, aplicação ou função de atuação do alarme.

Outras informações poderão ser apresentadas através de edição de filtros.

RO 1.05.14 Geral O relatório de alarmes deve ser dinâmico em relação a sua prioridade. O sistema de alarmes

deve ser configurável e com capacidade de filtros.

RO 1.05.15 Geral Todas as mensagens de alarmes devem ser registradas na base de dados históricos.

RO 1.05.16 Geral Além das características descritas acima, o fornecedor deve descrever as características

adicionais disponíveis em seu sistema para a gestão de alarmes.

Pg. 8 de 43


RO 1.05.17 Geral O sistema deve prever um buffer mínimo de 5000 mensagens de alarmes.

RO 1.05.18 Geral Os fornecedores devem informar a capacidade de seus sistemas em processar os alarmes

quando os sistema estiver em estado normal e de pico.

RO 1.05.19 Geral No sistema em seu estado normal, a ocorrências de um alarme (estado ou analógico) deverá ser

anunciada aos controladores, em todos os telas associadas, em até 1 segundo após o

recebimento pelo sistema de sua atuação.

RO 1.05.20 Geral No sistema em seu estado de pico, a ocorrências de um alarme (estado ou analógico) deverá ser

anunciada aos controladores, em todos os telas associadas, em até 2 segundos após o

recebimento pelo sistema de sua atuação.

RO 1.05.21 Atribuições de Alarmes

e responsabilidade

Os alarmes devem ser exibidos ao operador conforme a área de responsabilidade (AOR)

atribuída para o mesmo; de tal forma que cada operador somente visualize os alarmes de sua

área de responsabilidade.


e responsabilidade

Durante a operação do sistema, todos os alarmes deverão ser dirigidos corretamente aos

usuários conforme suas respectivas AORs.


e responsabilidade

O acesso às AORs, pelos controladores, deve ser dinâmica e utilizado na aplicação de privilégios

de acesso e visualização.


e responsabilidade

A AOR definida aos controladores deve determinar o conteúdo dos alarmes atuando como filtro.

Os controladores devem visualizar apenas o conteúdo que pertencem a sua AOR. O sistema

deverá assumir uma AOR Default (a ser definida pelo usuário) caso não seja designado uma

AOR específica.

RO 1.05.25 Atributos de alarmes Os usuários qualificados devem ser capazes de configurar a importância dos alarmes e

requisitos de processamento de alarmes, ou seja, configuração de importância dos limites

superior e inferior de um ponto analógico.

RO 1.05.26 Atributos de alarmes Os alarmes devem possuir características ou atributos por prioridade e cor para definir nível de

severidade e cor de apresentação associada.

RO 1.05.27 Atributos de alarmes Os alarmes devem possuir sinalização sonora configurável para habilitar, nenhum ou repetição, e

atribuir arquivos sonoros.

RO 1.05.28 Atributos de alarmes O sistema deve apresentar de forma tabular um resumo de alarmes desde que não apresente

inibição de alarme.

RO 1.05.29 Atributos de alarmes O alarme poderá ser configurável de modo que quando o alarme retornar a sua condição normal

para pontos de estado o mesmo seja suprimido do resumo de alarmes, ou para pontos

analógicos que não excedam qualquer limite de violação.

RO 1.05.30 Atributos de alarmes Os alarmes poderão ser deletados da lista de resumo de alarmes quando estes forem

reconhecidos por um ou mais controladores.

RO 1.05.31 Prioridades de alarmes

(classes de alarmes)

O relatório de alarmes deve possuir atributos de configuração mínima de 16 (dezesseis)

prioridades de alarmes.



A classe definida ao alarme deve determinar o processamento do alarme. Para uma determinada

classe, manipulação de seus atributos deve ser especificada.



Cada estado possível de um ponto de estado deve ser atribuído a uma das classes de maneira

que um alarme com prioridade alta seja processado de modo mais rápido. Por exemplo, quando

um ponto de estado sair de seu estado normal devido à abertura de um disjuntor, o sistema

sinalize mais rapidamente (e na cor vermelha com sonorização), do que a sinalização de alarme

ao retornar para seu estado normal (sinalizando com outra cor e sem sonorização).



Cada violação de limites inferior/superior, razoabilidade, e/ou taxa de variação possível de um

ponto analógico deve ser atribuído a uma das classes de maneira que quando, por exemplo, há

violação de razoabilidade de um ponto analógico, o sistema processe e informe aos

controladores com mais rapidez do que quando a violação volte ao seu limite normal.



Os pontos de acumuladores devem conter múltiplos grupos de processos. Cada grupo de

processo deve permitir a acumulação de alguma quantidade de valores durante um período de

tempo. Como exemplo podemos utilizar acumuladores para megawatts (MW) para cálculo de

MWh. Os grupos de processos devem ser períodos de tempo configuráveis para 15 minutos, 1

hora, 8 horas e 24 horas. Estes grupo devem possuir limites e classes de alarmes configuráveis

de forma similar a um ponto analógico.

RO 1.05.36 Reconhecimento de

alarmes

Os controladores devem ser capazes de reconhecer um ou mais grupos de alarmes apenas de

sua área de responsabilidade, seja no diagrama unifilar, resumo de alarmes, etc.

RO 1.05.37 Reconhecimento de

alarmes

Todas as ações de reconhecimento de alarmes devem ser registradas como eventos.

RO 1.05.38 Inibição/Habilitação de

alarmes

Os controladores devem ser capazes de inibir ou habilitar a geração de alarmes de qualquer

ponto configurado em sua área de responsabilidade.


alarmes

A ação de inibição ou habilitação de alarmes pelos controladores deve registrar um evento.


alarmes

Quando qualquer ponto de estado ou analógico estiver com a condição de inibição, estes devem

ser processados apenas com evento.


alarmes

O sistema deve fornecer uma resumo de todos os pontos de estado e analógico com inibição de

alarmes.

RO 1.05.42 Remoção de alarmes Os controladores devem ser capazes de remover individualmente ou um grupo de alarmes

através de diagramas unifilares, resumo de alarmes, etc.

RO 1.05.43 Remoção de alarmes Todas as remoções de alarmes devem ser registradas como evento.

RO 1.05.44 Remoção de alarmes Ao remover um ou mais alarmes, o resumo de alarmes deve se readequar removendo da lista e

reordenando os demais alarmes.

RO 1.05.45 Acesso ao histórico de

alarmes

O sistema deve gravar na base histórica todas as mensagens de alarmes.

Pg. 9 de 43



alarmes

O sistema deve possuir uma interface que permita aos controladores o acesso às mensagens de

alarmes de tempo real e histórica. Esta interface deve possuir configuração de período de coleta

de dados históricos com data e hora inicial e final, e horas/dias anteriores para recuperar e

visualizar os alarmes gravados no intervalo de tempo definido.


alarmes

A interface de alarmes deve possuir recursos de filtros e classificação de alarmes.

RO 1.05.48 Contador de tempo de

abertura de

equipamentos

O sistema deve possuir um contador de tempo (cronômetro) para informar o tempo de abertura

de um ponto digital. O ponto digital dever ser configurável para habilitação ou não o cronômetro.

Os controladores deverão ter acesso ao cronômetro através da seleção do equipamento

disponível nos diagrama unifilares ou no resumo de alarmes, desta maneira uma janela (popup)

deverá abir.

1.06 Geração de gráficos de tendência


customização

Atende COM

customização

RO 1.06.01 Geral Deve permitir a geração de gráficos que permitam o monitoramento de grandezas analógicas

instantâneas e observar tendências analógicas extraídas a partir de dados históricos. No sentido

de separar o fluxo de dados entre o sistema de tempo real e o corporativo, que deve ter uma

única ligação entre as duas redes deverá ser os servidores de dados históricos. Estes servidores

deverão utilizar redundâncias (tanto servidor como disco) capazes de garantir o seu

funcionamento mesmo em caso de falhas simples, em quaisquer de seus componentes.

RO 1.06.02 Geral Devem possibilitar ao operador observar a evolução das grandezas analógicas no tempo em que

durar a monitoração. Também deve ser possível observar tendências analógicas extraídas a

partir de dados históricos.

RO 1.06.03 Geral Tipos de fontes de dados deverão ser considerados:

- Dados dinâmicos: são os dados em tempo-real coletados do banco de dados de aplicações.

Este tipo de dado é enviado para o equipamento de visualização na mesma frequência da

amostragem.

- Dados estáticos: são os dados históricos lidos de um arquivo e enviados para o equipamento

de visualização.

- Dados manuais: são dados inseridos manualmente que representem uma determinada curva

num dado intervalo de tempo.

RO 1.06.04 Geral Deverá ser possível definir o período de amostragem, tanto para tendência de dados em tempo-

real, quanto para dados históricos.

RO 1.06.05 Tendência de dados em

tempo real

Os dados de tempo-real solicitados para tendência deverão ser selecionados pelo operador nos

displays gráficos. Qualquer dado proveniente de qualquer banco de dados das aplicações poderá

ser selecionado para tendência. A taxa de amostragem deverá ser definida ponto a ponto,

através da interface do usuário da função de Tendências. A tendência de dados em tempo-real

não deve ser entendida de uma maneira restritiva.

RO 1.06.06 Tendência de dados

Históricos

A ferramenta de tendência proposta deverá fornecer um meio para definir um ponto selecionado

como histórico. Isto significa que os valores amostrados deste ponto deverão ser salvos por um

dado período de tempo. Uma vez todos os valores tenham sido reunidos para este intervalo de

tempo, eles podem ser enviados, todos de uma vez, para apresentação ao usuário.

RO 1.06.07 Seleção de dados Os dados deverão ser selecionados para tendência a partir de displays gráficos. Para cada ponto

selecionado, o operador poderá definir os atributos a seguir. Caso contrário estes atributos serão

preenchidos com valores pré-definidos:

- Taxa de amostragem,

- Início e fim da escala,

- Selecionar ou não a opção histórica.

RO 1.06.08 Características gráficas Deve disponibilizar janelas dedicadas, onde as áreas de desenho correspondentes às curvas

deverão ser mostradas.

Estas janelas deverão suportar pelo menos 8 (oito) áreas simultaneamente;

Cada uma destas áreas devem suportar pelo menos 6 (seis) curvas simultaneamente.

Dentro de cada área de desenho, cada curva deverá ser mostrada usando uma cor diferente.

O nome de cada curva deverá aparecer na cor correspondente,

Cada área deverá mostrar os valores das escalas utilizadas em cada curva.

RO 1.06.09 Características gráficas O operador deverá ter a possibilidade de modificar a apresentação gráfica dos valores em

tendência. A seguir os quatro tipos diferentes de apresentação que deverão estar disponíveis:

- Curvas: Um gráfico X-T básico.

- Gráficos de barras: Um ou mais pontos plotados a partir de uma linha básica comum.

- Gráficos em pizza: Gráficos mostrando a porcentagem relativa de valores em relação ao todo.

- Medidores: Gráficos mostrando um valor pontual instantâneo em relação às escalas mínima e

máxima.

RO 1.06.10 Características gráficas Deverá ser possível representar as curvas horizontalmente e verticalmente.

RO 1.06.11 Características gráficas Cálculo e armazenamento de valores máximo e mínimo no período.

RO 1.06.12 Características gráficas Deverá ser prevista a opção de ajuste automático da escala, que adapta os valores mínimos e

máximos ao dado amostrado. Os valores mínimos e máximos deverão ser inseridos

manualmente.

RO 1.06.13 Características gráficas A definição da escala deverá ser dada em valores inteiros arredondados (por exemplo: 1, 5, 10,

etc.).

RO 1.06.14 Características gráficas Deverá ser possível definir pelo menos dois limites (superior e inferior) para cada ponto

amostrado. Porções de curva acima do limite superior e abaixo do limite inferior deverão ser

mostradas hachuradas em cores diferentes.

RO 1.06.15 Características gráficas Características de “zoom” e rolagem deverão estar disponíveis.

Pg. 10 de 43


RO 1.06.16 Características gráficas A designação de um ponto na curva deverá resultar na apresentação precisa do valor do eixo Y

juntamente com o tempo da ocorrência;

RO 1.06.17 Características gráficas Deverá estar disponível a opção de impressão a fim de permitir imprimir a tendência corrente

mostrada (preferencialmente no formato “postscript”);

RO 1.06.18 Características gráficas Uma função de salvamento e restituição deverá ser proposta. Isto deverá permitir ao usuário

salvar tendências de interesse num arquivo e chamá-las de volta para apresentação (como

dados estáticos).

RO 1.06.19 Históricos Deve exibir gráfico de grandezas elétricas referente a múltiplos alimentadores conforme seleção

pelo usuário. Exemplo: Gráfico de corrente contendo três alimentadores, com linhas sobrepostas.

RO 1.06.20 Oscilografia Deve demonstrar gráfico contendo a oscilografia do equipamento de proteção, afim de possibilitar

análise do tipo de falta em tempo real.

1.07 Sistema de informação de históricos


customização

Atende COM

customização

RO 1.07.01 Geral As medições, indicações de estado, alarmes, informações calculadas e ações executadas pelo

operador ou proveniente de algoritmos devem ser armazenados, a fim de permitir a análise ou

auditoria posterior. Os dados históricos deverão ser disponibilizados a aplicativos externos

através de banco de dados padronizados, e relatórios gerados em arquivos texto.

RO 1.07.02 Geral No sentido de separar o fluxo de dados entre o sistema de tempo real e o corporativo, deve ter

uma única ligação entre as duas redes, que deverá ser os servidores de dados históricos,

conforme requisitos definidos de segurança cibernética. Estes servidores de históricos deverão

utilizar redundâncias capaz de garantir o seu funcionamento mesmo em caso de falhas simples,

em quaisquer de seus componentes. Esta aplicação deve ser escalável para manusear grandes

volumes de dados. Deve possuir função auditoria com os registros de modificações.

RO 1.07.03 Banco de dados O sistema gerenciador de dados históricos deve ser concebido para atender o número de

licenças simultâneas contratada para busca de dados, garantindo que a segurança e o

desempenho do ADMS não sejam comprometidos.

RO 1.07.04 Banco de dados O sistema gerenciador de dados históricos deve utilizar um banco de dados relacional (RDBMS)

comercialmente disponível, compatível com Open Database Conectivity (ODBC), de alta

performance e disponibilidade, devendo estar acessível mesmo em caso do ADMS não estar

disponível.

RO 1.07.05 Banco de dados O sistema de gerenciador de dados históricos deve ser implementado com servidores

redundantes e independentes do restante do ADMS.

RO 1.07.06 Banco de dados Deve existir controle de permissões de acesso de usuários ao banco de dados.

RO 1.07.07 Banco de dados O sistema deve possuir a funcionalidade de limpeza automática de dados armazenados quando

o período de retenção expirar.

RO 1.07.08 Banco de dados Período de retenção dos dados: 5 anos para acesso on-line e 10 anos para acesso em arquivos

(recuperação de dados em mídia). Com rotina automática para transferência de dados do banco

on-line para o off-line (arquivos).

RO 1.07.09 Banco de dados O sistema deve ser dimensionado para manter na base, no mínimo, os dados históricos relativos

aos últimos 45 dias mais recentes com periodicidade parametrizável, sem que haja qualquer tipo

de compactação. O tempo mínimo de registro deve ser de 1 (um) segundo.

RO 1.07.10 Banco de dados O sistema deve prever backup automático para dispositivo de armazenamento de massa.

RO 1.07.11 Banco de dados A aplicação deverá implementar técnicas de “buffering” no processo de amostragem de dados de

tempo real para serem armazenados nos servidores históricos de forma a evitar a perda de

dados nos casos de indisponibilidade de ambos os servidores históricos ou da rede.

RO 1.07.12 Banco de dados Deve informar, caso implemente algum algoritmo de compactação de dados de forma seletiva ao

ponto, sobre alguma perda de precisão, truncamento ou arredondamento.

RO 1.07.13 Banco de dados O sistema deve absorver automaticamente as atualizações da versão da base de dados de

tempo real, sem intervenção manual.

RO 1.07.14 Coleta O sistema deve permitir ao usuário a configuração de coleta automática de dados de forma

periódica, baseada em exceções ou orientada a eventos.

RO 1.07.15 Coleta A frequência de armazenamento deve ser parametrizada, pelo usuário, por tipo de dado.

RO 1.07.16 Tipos de Dados O Banco de Dados Histórico e seu software associado deve atender aos seguintes requisitos de

armazenamento de grandezas:

- telemedidas (estados e analógicos, contadores),

- indicadores de qualidade (telemedidos e internos do sistema),

- sequência de eventos (SOE),

- grandezas calculadas,

- dados programados,

- alarmes e eventos,

- mensagens do sistema,

- dados de interrupções,

- ações do operador por console,

- resultados de programas de tempo real (varredura, estimador, configurador, Controle

Automático de Tensão - CAT, funções de integração, etc.),

- cálculo de médias, máximas e mínimos,

- estatísticas de erro de comunicação,

- notas do operador colocadas nos equipamentos, alarmes e eventos,

- execução de funções e scripts,

- marcadores de restrição colocadas pelo operador no equipamento,

- todas as ações executadas pelo usuário.

RO 1.07.17 Estampa de tempo Todos os dados históricos devem ser armazenados com base em horário UTC

RO 1.07.18 Estampa de tempo Para efeito de exibição e cálculo, os dados devem ser convertidos para o fuso horário local,

também levando em conta os períodos de horário de verão.

Pg. 11 de 43


RO 1.07.19 Ferramenta de

visualização e análises

Deve permitir a visualização dos dados históricos na rede corporativa (preferencialmente WEB) e

também na rede tempo-real através das consoles de operação.



Deve permitir a apresentação em forma tabular ou gráfica de uma ou várias medidas

simultaneamente.



Deve prever transferência de dados para outros aplicativos que a Copel utiliza (Gasa, ATB, ACT,

PI), através de relatórios normatizados em formato CSV, planilha e acesso ao banco de dados

relacional.



O sistema deverá permitir a tendência de dados históricos à medida que forem sendo atualizados

na base.



O sistema deve prever a restauração automática, via comando do usuário, de dados que tenham

sido retirados da base de dados.



O usuário poderá realizar consultas utilizando diferentes períodos de amostragem, podendo

integralizá-los por período



O usuário poderá definir grandezas calculadas a partir de dados do banco contidos no histórico,

sendo executado de forma periódica ou espontaneamente, podendo recalcular outros valores da

base de dados históricos.



No mínimo devem ser suportados os seguintes cálculos:

a) Operações algébricas:

-aritméticas (+,-,/,*),

-somatório,

-integral,

-exponencial,

-sen, cos, tg (radianos ou graus),

-arc sen, arc cos, arc tg (radianos ou graus),

-raiz quadrada,

-valor absoluto,

-exponenciação

b) operações condicionais

- >, >=, =, =<, <

- If, Then, Else

c) operações booleanas

- AND, OR, NOT, XOR



Deve suportar medidas estatísticas de valores: mínimo, máximo, média, mediana, desvio padrão

e totais por período de tempo selecionado pelo usuário.



Os dados calculados devem possuir flag de qualidade derivado dos dados fontes.



O sistema deve possuir interface para exportar os dados armazenados no historiador, dados

calculados e gráficos para outros aplicativos comercialmente conhecidos como Microsoft Office

(planilhas, processadores de texto, etc), arquivos texto (CSV) e outros bancos de dados padrão

SQL ou drivers ODBC.

RO 1.07.30 Relatórios A solução deve incluir recursos e ferramentas que permitam gerar e gerenciar relatórios de

qualquer dado armazenado no banco de dados histórico.

RO 1.07.31 Relatórios Deve possuir filtros configuráveis pelo usuário para limitar as informações selecionadas para o

relatório.

RO 1.07.32 Relatórios Deve permitir gerar relatórios de forma automática (em arquivo, configurado como script) ou sob

demanda do usuário.

1.08 Interação com Usuário


customização

Atende COM

customização

RO 1.08.01 Interface Homem-

máquina

A IHM deverá oferecer recursos gráficos de animação que permitam ao operador, de forma

intuitiva, reconhecer de imediato os estados dos equipamentos, as medições realizadas e as

sinalizações de alarmes.

A interface deve ser projetada com requisitos de ergonomia de software para que esta seja

amigável ao operador.

O Subsistema IHM deverá incluir os consoles de operação, dotados de capacidade gráfica (“full

graphics”) e janelas múltiplas.

O operador deverá ter recursos para:

- “trending” (tendência) de variáveis;

- “panning” (movimento panorâmico);

- “zooming” (zoom negativo ou positivo de uma parte da tela) e

- “decluttering” (capacidade de fazer as informações aparecerem e desaparecerem em níveis

diferentes de ampliação).

- Criação de interfaces através de software de configuração;

- A manobra de dispositivos de campo através de interface gráfica onde é apresentado o

diagrama unifilar.

Apresentar ao operador, sob forma gráfica ou através de desenhos esquemáticos, os valores

provenientes das medições realizadas, além das indicações de estado dos dispositivos.

RO 1.08.02 Anotações do Operador Deverá ser previsto um recurso que permita aos operadores fazerem anotações nos displays e

comunicarem estas informações para outros operadores. As anotações deverão ser usadas

pelos operadores como etiquetas em um display, caracterizando algo que requeira atenção.

RO 1.08.03 Ajuda On-line um recurso de ajuda on-line deverá existir para auxiliar os operadores no uso dos recursos

computacionais do sistema. Este recurso deverá prever a possibilidade de acréscimos

posteriores de informações de interesse do usuário.

Pg. 12 de 43


RO 1.08.04 Controle de acesso do

usuário

O sistema deverá prever múltiplos níveis de acesso, conforme o perfil do usuário

(operador/supervisor/manutenção/engenharia, etc). Todas as ações executadas devem estar

registradas em relatório específico.

RO 1.08.05 Áreas de

responsabilidade

Deverá ser prevista a capacidade de atribuir áreas de responsabilidade para o controle do

sistema. Esta área, por exemplo, pode ser uma área geográfica que um usuário pode ser

responsável. A designação dos responsáveis pode ser feita em tempo de execução. Deverá

existir um controle que monitore todos os usuários ativos, assegurando que em caso de logout

de algum usuário, não existam área desatendidas. Também deverá existir controles que

previnam interferências entre operações de controle simultâneas em um mesmo dispositivo.

1.09 Núcleo do Sistema


customização

Atende COM

customização

RO 1.09.01 Plataformas abertas de

desenvolvimento e

manutenção

Possuir interfaces de programas de aplicação para simplificar a incorporação e facilitar o

desenvolvimento de novos aplicativos. Fazer uso de linguagens de programação de alto nível

padronizadas, com ambientes de desenvolvimento (compiladores, depuradores, bibliotecas, etc.)

disponíveis para as diversas plataformas computacionais (CPU e sistema operacional), evitando-

se o uso de recursos proprietários e/ou somente disponíveis para uma plataforma específica.


desenvolvimento e

manutenção

A solução ADMS deverá permitir o desenvolvimento de programas contendo lógicas baseadas

nas informações de estado e medidas, e solicitação de comandos.


desenvolvimento e

manutenção

O sistema conterá um ambiente de programação de software completo, para permitir o

desenvolvimento de aplicações customizadas pela Copel.


desenvolvimento e

manutenção

As ferramentas fornecidas incluirão ferramenta de controle de versão, editor com suporte a

idiomas, todos os compiladores necessários, depurador de programas simbólico/interativo e

software de auditoria de mudanças.


desenvolvimento e

manutenção

O Fornecedor descreverá, em sua resposta a esta especificação, o processo detalhado para

propagar a base de dados e as mudanças de software executadas nos ambientes de

desenvolvimento (PDS) e de produção.

RO 1.09.06 Servidor de manutenção

de base de dados

O sistema deverá possuir um servidor para suportar o desenvolvimento de aplicativos e

geração/manutenção de base de dados, com réplica fiel da base de dados do servidor de tempo

real

RO 1.09.07 Suporte a Banco de

dados em tempo real

Capacidade de armazenamento de dados em tempo real confiável, redundante para tolerar

falhas simples, e, preferencialmente, utilizando, em tempo real, gerenciador

de base de dados relacional. Gerenciar base de dados fonte com técnicas apropriadas para

modelagem em tempo real, com estruturas de dados relacionais interativas, e comunicação com

a referida base de dados.


dados em tempo real

A solução ADMS deverá utilizar um sistema de banco de dados em tempo real para

armazenamento temporário dos dados e com garantia de replicação imediata entre os ambientes

principal e secundário.


dados em tempo real

Este banco de dados em tempo real deverá tolerar falhas através dos mecanismos de

redundância existentes no ambiente principal.


dados em tempo real

Utilizar banco de dados tempo real apoiado em base de dados relacional de mercado.


dados em tempo real

O banco de dados em tempo real deverá verificar e garantir a consistência temporal do dado,

para cada conjunto de dados a ser gravado no banco, dentro de um determinado intervalo de

tempo.

1.10 Possibilidade de expansão do sistema


customização

Atende COM

customização

RO 1.10.01 Geral O sistema deve permitir expansões futuras, de hardware e software, prevendo recursos para

possibilitar sua expansão, sem necessidade de substituição total, ou parcial, e sem degradação

de confiabilidade, disponibilidade e performance.

O sistema deve permitir futuras atualizações de software.

RO 1.10.02 Possibilidade de

expansão do sistema

A solução ADMS deverá ter capacidade de expansão horizontal e vertical de seus componentes

de hardware e de software, para o atendimento das necessidades da Copel. Ao longo de cinco

anos de operação, a solução deve atender a uma crescimento total de 20% de sua capacidade

inicial.

1.11 Centro Backup


customização

Atende COM

customização

RO 1.11.01 Geral O centro backup é um sistema de controle redundante que deve espelhar o sistema do centro de

controle primário.

RO 1.11.02 Geral O centro de controle de backup deve possuir comunicações paralelas ou redundantes com as

remotas.

RO 1.11.03 Geral O centro de controle de backup deve permitir a transferência completa do controle do sistema de

controle primário para o sistema de backup em caso de emergência ou operações planejadas

sem perder o controle operacional de emergência e a capacidade de monitoramento para o

processo associado aos sistemas.

RO 1.11.04 Geral O sistema de controle backup deverá possuir minimamente as seguintes funcionalidade

equivalentes às do sistema de controle principal:

- Ambiente de produção secundário (SCADA,EMS,DMS/OMS).

- Zona desmilitarizada (interface com usuários remotos, historiador, ICCP e outros serviços).

RO 1.11.05 Geral Todas as requisitos, características e especificações descritos neste documento, para o sistema

de controle principal, deverão ser adotados no sistema de controle backup.

RO 1.11.06 Requisitos operacionais A comutação entre operação do sistema elétrico de distribuição através do sistema de controle

principal e backup devera ser manual, opcionalmente a comutação poderá ser automática desde

que configurado pelo usuário desta forma (seja configurável a comutação manual/automática).

Pg. 13 de 43


RO 1.11.07 Requisitos operacionais O tempo máximo para comutação das operações entre o centro principal e o centro backup

deverá ser de, no máximo, 1 (um) minuto.

RO 1.11.08 Requisitos operacionais A comunicação de alta velocidade entre os sistemas principal e backup deverá ser redundante.

2. DMS

2.01 Modelo de Rede


customização

Atende COM

customização

RO 2.01.01 Geral O Modelo de Rede é um modelo orientado a objetos de redes de energia elétrica adaptado para

fins específicos do ADMS. Ele modela todos os componentes da rede da mesma maneira,

independentemente do seu nível de tensão (AT, MT ou BT) para fins de cálculos e de

apresentação no ADMS.

RO 2.01.02 Geral Inicialmente o modelo de rede do ADMS deve ser importado a partir dos dados saneados do GIS

da Copel.

RO 2.01.03 Geral O modelo de rede deve ter a opção de atualização via importação periódica de dados do GIS

(com validação prévia pelo operador) ou via Editor Gráfico.

RO 2.01.04 Geral Deve estar apto a comparar a base de dados da rede elétrica do ADMS com a base do GIS da

Copel, identificando as mudanças, e apresentar essas mudanças para o usuário.

RO 2.01.05 Geral Deve possibilitar a criação de conexões temporárias que afetem o modelo de conectividade

(deve ser possível incorporar no modelo de rede), como fontes temporárias, cargas temporárias,

jumpers, bypass de equipamento, entre outros.

RO 2.01.06 Geral Deve possibilitar a modelagem do grid desde a subtransmissão, passando pelas subestações,

rede de distribuição MT, incluindo também a BT.

RO 2.01.07 Geral Pelo menos os seguintes elementos devem estar incluídos no modelo de rede:

- Transformadores(enrolamento primário/secundário/terciário; com e sem comutação de TAP;

Transformador de potencial; Transformador de corrente; Transformador de serviço auxiliar)

- Cargas

- Chaves (fusíveis, disjuntores, seccionadores, religadores, etc.)

- Bancos de capacitores

- Geradores distribuídos

- Barramentos (principal, transferência, tipo H, BP 1 e BP 2)

- Linhas de distribuição aéreas e subterrâneas

- Medições de status digitais e analógicas

- Cabos

- Postes

- Junções aéreas

- Linhas de Distribuição de alta tensão

- Linhas de Transmissão de alta tensão

- Jumpers (equipamentos temporários de operação)

- Aterramentos (temporários e fixos)

- Barramentos auxiliares

- Transformadores móveis

- Indicadores de falta

- Reatores

- Reguladores de tensão

- Seccionamento temporário

- Subestação Móvel / Transformador Móvel

- Acessantes de Geração

RO 2.01.08 Geral O ADMS deverá obter a conectividade a partir da conectividade fornecida pela importação do

GIS.

RO 2.01.09 Geral O ADMS deve suportar a operação monofásica (não agrupada) de equipamentos polifásicos

(religadores trifásicos com trip monofásico). Ele deve ser capaz de representar a conectividade

da rede de forma adequada em tempo real.

RO 2.01.10 Geral O ADMS deve considerar em todas as suas funções, as divisões e sub-divisões da organização

da Copel.

2.02 Processador Topológico


customização

Atende COM

customização

RO 2.02.01 Geral Deve calcular a conectividade das seções de linha baseada na topologia construtiva de rede e no

estado dos dispositivos de seccionamento(Disjuntores, Chaves, etc)atualizados em tempo real e

aqueles atualizados off-line (Chave não supervisionada por exemplo).

RO 2.02.02 Geral O processador de topologia deve ser atualizado em tempo real para qualquer mudança no

estado da rede (uma manobra, por exemplo).

RO 2.02.03 Cálculo de Impedância Deve calcular os valores de impedância dos trechos primários da rede conforme modelo a ser

apresentado.

RO 2.02.04 Validação da

Conectividade

Deve ser capaz de validar a conectividade entre os elementos conforme informações do GIS da

COPEL.

2.03 Fluxo de Potência Desbalanceado e de Tempo Real - LFC


customização

Atende COM

customização

RO 2.03.01 Descrição Utiliza o modelo do sistema de distribuição assim como os dados do SCADA para calcular

condições elétricas em qualquer ponto no alimentador, incluindo pontos que não são

supervisionados/telemedidos. Os cálculos deverão gerar como resultado no mímino, perfil de

tensão da rede, fluxo de potência, fluxo de corrente, fator de potência, queda de tensão, perdas

em MW e Mvar, geração e demanda total. A solução deverá prover perfil de carga de

alimentadores com base em período de tempo parametrizável.

Pg. 14 de 43


RO 2.03.02 Descrição O sistema deve dispor de LFC trifásico não balanceado. A rede de distribuição poderá ser

trifásica, bifásica ou monofásica, incluindo o MRT (monofásico com retorno pela terra). O cálculo

deve ser fase por fase.

RO 2.03.03 Descrição O LFC deve utilizar como dados de entrada os dados do modelo de rede, assim como os dados

do SCADA (relés, religadores, unidades terminais remotas, sensores) e de unidades

consumidoras com telemedição).

RO 2.03.04 Modelagem O LFC deve contemplar desde a sub-transmissão, subestações e rede de distribuição. O LFC

deverá calcular o fluxo de potência de redes de baixa tensão, incluindo redes reticuladas

subterrâneas considerando os equipamentos e modelos próprios destes sistema.

RO 2.03.05 Cálculo O LFC deve possibilitar cálculo com redes elétrica ilhadas, alimentadas por geração distribuída,

baterias, etc..

RO 2.03.06 Cálculo O LFC deve ser atualizado em qualquer um dos casos:

* intervalos periódicos configuráveis;

* após uma manobra na rede, mesmo que a configuração gerada represente um sistema em

anel momentâneo;

* a pedido do usuário/operador.

RO 2.03.07 Geral O LFC deve ser capaz de redistribuir/atualizar os dados de carga ao longo do alimentador a partir

dos dados do SCADA.

RO 2.03.08 Modelagem O LFC deve ser capaz de considerar elementos de Geração Distribuída em seus cálculos, tais

como Geradores Fotovoltáicos, Geradores Eólicos, Máquinas Síncronas e Assíncronas, Baterias,

Carros Elétricos, etc. Para realização dos cálculos o LFC deve ser capaz de considerar

elementos variáveis tais como incidência solar e velocidade do vento, caso estes sejam

fornecidos para a ferramenta.

RO 2.03.09 Modelagem Modelagem de todos os componentes da rede de distribuição incluindo todos os tipos de cargas

(separadas por tipo – potência constante, corrente constante e impedância constante),

geradores, motores, transformadores de 2 e 3 enrolamentos – incluindo todos os tipos de ligação

no primário e secundário bem como banco de transformadores monofásicos, comutador de tapes

em transformadores, transformador de aterramento, reguladores de tensão, indutores e

capacitores.

RO 2.03.10 Resultados Apresentar na forma gráfica e em tabelas qualquer violação de parâmetros pré-definidos. O

operador deverá poder alterar estes parâmetros a qualquer tempo.

RO 2.03.11 Resultados Todas as manobras (individual ou conjunto) deverão ser arquivadas para uso futuro a critério do

usuário.

RO 2.03.12 Cálculo O LFC deve calcular o fluxo de potência quando do acoplamento entre circuitos, inclusive quando

provenientes de subestações diferentes, informando também diferenças de tensão e ângulo entre

os pontos.

RO 2.03.13 Descrição Todas as funcionalidades do LFC devem ter também um módulo de treinamento e simulação.

RO 2.03.14 Resultados Os resultados gráficos e tabelas devem possibilitar exportação para uso em outras plataformas

(ex: exportar em .xlsx e .pdf).

2.04 Violação de Limites


customização

Atende COM

customização

RO 2.04.01 Descrição Funcionalidade para verificar violações de tensão, corrente (sobrecarga) e fator de potência em

tempo real, em todas as seções de rede e componentes da mesma (geradores, transformadores,

reguladores de tensão, etc..).

RO 2.04.02 Cálculo Deve verificar violações de tensão, corrente, potência e fator de potência em cabos, TFs, LTs,

rede de distribuição e demais componentes da rede.

RO 2.04.03 Resultados As violações em questão quando ocorrem devem originar alarmes para o operador (ponto de

estado com alarme).

RO 2.04.04 Cálculo Funcionalidade deve ser atualizada automaticamente após cada cálculo de load flow (LFC).

RO 2.04.05 Resultados Sistema deve possibilitar emissão de relatório contendo todas as violações, agrupadas por

componente e tipo, assim como os respectivos valores violados, quantidade e tempo sob

violação de limites individual e acumulado (período de tempo parametrizável pelo usuário).

RO 2.04.06 Resultados Todos os resultados devem ser agrupados em tabelas e devem possibilitar exportação de dados

em formato .xlsx, pdf dentre outros.

RO 2.04.07 Modelagem Os limites de cada componente deverão ser importados do sistema Scada.

2.05 Estimador de Estados


customização

Atende COM

customização

RO 2.05.01 Definição Deve estimar valores analógicos (pseudomedições) de todo sistema elétrico operado, a partir

dos parâmetros construtivos da rede elétrica (modelo de rede) e das telemedições disponíveis no

sistema da operação em tempo real (sistema principal) ou informadas pelos operadores. Busca a

melhoria da confiabilidade das medições aquisitadas e disponibilizar pseudomedições onde não

houver, ou estiver indisponível.

RO 2.05.02 Básico Deve estimar magnitude e ângulo de tensão, injeção de MW e MVAr (carga e geração) nas

barras; corrente, fluxo de MW e MVAr nas linhas; posição do tap de transformadores e

reguladores de tensão; operação de compensação reativa (banco de capacitores); e outras

grandezas aplicadas à distrbuição.

RO 2.05.03 Básico O estimador deve ter capacidade para detecção e correção de erros grosseiros com notificação

do operador para autorizar a substituição do valor telemedido pela pseudomedida ou não; e

ainda, deve haver uma forma de ativar um processo automático de uso dos valores estimados

sem solicitação específica ao operador.

RO 2.05.04 Básico Deve ser capaz de gerar alarme na ocorrência de sobrecargas e/ou violações de tensão em

dispositivos, monitorados ou não, com a possibilidade de inibição desses alarmes pelo operador.

Pg. 15 de 43


RO 2.05.05 Básico Os resultados devem ser armazenados em casos arquivados, para uso posterior em outras

funcionalidades do sistema de operação em tempo real, como: fluxo de potência em tempo real,

análise de manobras, análise de contingência em tempo real, simulador de treinamento e outras.

RO 2.05.06 Básico O estimador deve ter uma interface com operador para definição das condições de

processamento: por demanda, por evento ou periodicamente (configurável).

RO 2.05.07 Básico Deverá prever a exibição de todos os valores da solução nas telas de diagramas unifilares

disponíveis para operação em tempo real ou em tela espelhada.

RO 2.05.08 Básico O estimador deve possuir interface para exportação dos resultados para utilização externa, no

formato XLS, TXT, CSV e outros.

RO 2.05.09 Básico O estimador deve apresentar relatórios diversos, incluindo resultados, análises e detalhamento

de processamento para auxílio na análise e consistência dos resultados dessa funcionalidade.

RO 2.05.10 Básico A criação e/ou edição de uma pseudomedida deve ser possível (mesmo onde não houver

medição) pelo operador, visando a melhoria da solução desta funcionalidade.

RO 2.05.11 Modelagem O estimador deve contemplar a análise de todos os pontos observáveis, seja na rede de média

tensão, quanto na rede de alta tensão.

RO 2.05.12 Modelagem Deve contemplar a análise em redes com malha aberta (circuitos radiais) ou fechada (circuitos

em anel), conforme a topologia.

RO 2.05.13 Modelagem Deve contemplar análise de desbalanceamentos na rede trifásica.

RO 2.05.14 Modelagem O estimador deve distribuir carga ao longo de trecho de redes com tensão de 13,8kV e 34,5kV.

RO 2.05.15 Modelagem A consistência do estado dos equipamentos de manobra com suas medições analógicas, assim

identificando e exibindo as inconsistências detectadas tem que ser possível.

RO 2.05.16 Modelagem Possuir capacidade para identificar erro de topologia nas áreas observáveis.

RO 2.05.17 Modelagem Possuir capacidade para identificar erro nos parâmetros construtivos da rede elétrica, nas áreas

observáveis.

RO 2.05.18 Modelagem Contemplar os seguintes elementos de rede nas tensões de 13,8 kV até 138 kV: linhas de

distribuição, transformadores com tap em derivação, banco de capacitores, reguladores de

tensão, geração distribuída e outros aplicados à distribuição.

2.06 Controle de Tensão e Reativos, Otimização e Controle Volt/VAR


customização

Atende COM

customização

RO 2.06.01 Descrição Esta aplicação identifica e coordena um conjunto de ações de controle para tensão de

distribuição, com objetivo de melhorar perfil de tensão ao longo da rede, reduzir perdas elétricas,

diminuir o carregamento e melhorar o fator de potência.

RO 2.06.02 Controle A aplicação deve ter possibilidade de controlar nas SEs e na rede: Tape de transformadores,

reguladores de tensão, bancos de capacitores, baterias, etc.. Para o caso de baterias a aplicação

deverá controlar potência ativa e reativa.

RO 2.06.03 Lógica A aplicação deve viabilizar a escolha de qual grandeza deverá ser otimizada, sendo possível

alterar a grandeza a cada subestação. Entre os requisitos de otimização parametrizáveis devem

estar contidos a melhora do perfil de tensão em todo alimentador, melhora do fator de potência,

redução de carregamento no circuito, minimização de violações de limites. A lógica para

minimização das perdas elétricas no circuito deve ser considerada em todas as ações de

controle.

RO 2.06.04 Limites Caso não seja possível atender aos requisitos de otimização (melhorar perfil de tensão, reduzir

perdas, etc..) a aplicação deverá atender o mais próximo possível aos requisitos e indicar quais

os componentes limitantes do sistema elétrico. Esta aplicação deverá considerar os limites de

todos os componentes da rede elétrica sob controle.

RO 2.06.05 Lógica O controle de tensão e reativos deverá ser implementando considerando o histórico de curva de

carga em cada alimentador e/ou subestação.

RO 2.06.06 Controle A execução da aplicação deve ocorrer a pedido do usuário ou periodicamente. Usuário pode

revisar ou propor modificações para a solução encontrada.

RO 2.06.07 Controle Após definição das ações a serem tomadas a aplicação volt / Var deve elaborar sequência de

chaveamentos para execução da atividade, com base na topologia da rede.

RO 2.06.08 Controle Deverá ser possível ao usuário especificar os valores limite das faixas de tensão admissíveis nos

barramentos controlados, nos diferentes períodos de carga e sob diferentes condições de

operação (normal ou emergência).

2.07 Modo de Simulação


customização

Atende COM

customização

RO 2.07.01 Descrição O ambiente de simulação permite criar dinamicamente uma simulação de uma parte selecionada

da rede em memória enquanto mantém o modo tempo-real, para fins de estudo da rede ou

validação de manobras.

RO 2.07.02 Geral Deve ser capaz de simular a rede de distribuição a partir do estado atual em que a rede se

encontra no ambiente em tempo real, utilizando as ferramentas de fluxo de carga, estimador de

estados, modelo de rede, previsão de carga, enfim aplicações avançadas de distribuição.

RO 2.07.03 Contextualização Entenda-se como estado atual da rede como sendo uma réplica (uma foto) do sistema no

instante em que se iniciou a simulação, valores das medições daquele momento, assim como

valores de estado daquele momento, e demais conexões de rede.

RO 2.07.04 Geral O sistema deve possibilitar ao operador/usuário utilizar o modo simulação sob demanda, isto é,

em qualquer momento que for necessário.

RO 2.07.05 Segurança Qualquer ação tomada pelo usuário/operador no modo simulação e suas respectivas

consequências devem ficar restritas a este modo, não podendo interferir no modo tempo real sob

hipótese alguma.

RO 2.07.06 Geral Deve ser capaz de prever a nova situação da rede de distribuição após uma manobra efetuada

no ambiente de simulação, utilizando as ferramentas de fluxo de carga, estimador de estados,

modelo de rede, previsão de carga, entre outros.

Pg. 16 de 43


RO 2.07.07 Geral O sistema deve ser capaz de executar um conjunto de manobras a partir do estado atual da

rede, sem afetar a operação de tempo real, de forma a validar essa manobra sob aspectos

diversos como por exemplo, violação de limites, assim como possibilitar um estudo do estado da

rede pós-manobra.

RO 2.07.08 Geral O ambiente de simulação deve conter interface gráfica com aspecto diferente da interface gráfica

de tempo real, de forma a alertar o usuário/operador de que ele está em ambiente simulado.

RO 2.07.09 Geral Com exceção da identificação gráfica de modo simulação, os demais aspectos do modo

simulação devem ser iguais ao do modo tempo real, como perfil de cores para trechos,

disjuntores, barramentos, equipamentos, etc.

RO 2.07.10 Geral As funcionalidades avançadas de distribuição presentes no modo tempo-real também devem

estar presentes no modo simulação.

RO 2.07.11 Geral O modo simulação deve ser uma réplica do modo tempo real no que diz repeito às

funcionalidades.

RO 2.07.12 Geral Deve ser possível alternar entre modo tempo-real e modo simulação para, por exemplo, validar

uma manobra ou investigar situações diversas no sistema.

RO 2.07.13 Geral A partir de uma manobra validada no ambiente de simulação, deve ser possível criar uma lista de

manobras a ser executada no ambiente de tempo real.

RO 2.07.14 Geral A partir de uma manobra validada no ambiente de simulação, deve ser possível agendar uma

manobra ou interrupção em equipamentos.

RO 2.07.15 Geral A lista de manobras criada pelo simulador seja para execução em tempo real, seja para

agendamento, deve conter informações como descrição, comentários, solicitante, data, horário,

etc, além das informações da manobra propriamente dita.

RO 2.07.16 Geral O sistema deve possibilitar ao operador/usuário armazenar as simulações realizadas em

memória, de forma a reproduzí-las quando for necessário.

RO 2.07.17 Geral O sistema deve possibilitar a reprodução de simulações armazenadas em memória, tanto por

quem as elaborou, quanto por demais usuários do sistema.

RO 2.07.18 Geral Deve ser possível ao usuário/operador inserir a hora do dia a ser utilizada como condição inicial

para a simulação, assim como dia da semana, mês do ano. Nesse caso, o sistema deverá ter

como estado inicial da rede as condições representadas pela data e horário escolhidas,

considerando dados históricos de dia e horário equivalentes.

RO 2.07.19 Abrangência O ambiente de simulação e suas funcionalidades devem contemplar as áreas de operação de

linhas de subtransmissão, subestações e rede de distribuição.

RO 2.07.20 Geral Nas simulações de desligamento programado e não programado o sistema deve sugerir

condições de manobra otimizadas, baseadas em critérios escolhidos pelo usuário, como:

violação de tensão, de carregamento, menor número de operações, menor quantidade de

clientes desligados, etc, nos casos em que há mais que uma opção de recomposição.

RO 2.07.21 Geral O modo de simulação deve possibilitar a carga de casos de estudo armazenados em memória,

analisando e indicando possíveis conflitos entre as manobras programadas. Casos de conflitos

podem ser: atuação do mesmo equipamento e/ou trecho em duas manobras programadas.

RO 2.07.22 Geral O ambiente de simulação deve permitir a inclusão de trechos e equipamentos temporários (como

big jumper) na topologia da rede de distribuição e considerar tal trecho nos casos de simulação.

RO 2.07.23 Geral No caso da inclusão de trechos e equipamentos temporários no ambiente de simulação, deve ser

possível ao usuário configurar tais techos e equipamentos. Por exemplo, determinar bitola de

cabo ou ampacidade, tipo de equipamento (chave, religador, regulador de tensão, etc.).

RO 2.07.24 Atualizações O sistema ADMS deve ser capaz de identifcar mudanças de configuração, atualização da rede,

como por exemplo entrada ou mudança de equipamentos, condutores, etc, quando o usuário

carregar um caso de simulação salvo em memória, criado para um estado anterior da rede. Deve

alertar o usuário que houve mudanças após a data de realização da simulação salva.

RO 2.07.25 Representação O ambiente de simulação deve demonstrar ao operador as Unidades Consumidoras que serão

desenergizadas conforme manobra (por meio de tabela por exemplo), equipamentos da rede em

que poderá haver invesão de fluxo de potência (por exemplo BRTs, RAs, BCs e CFs).

RO 2.07.26 Representação O ambiente de simulação deve apresentar a funcionalidade de visão ortogonal para uma

determinada área da rede pré-selecionada pelo usuário.

2.07.01 Processo Pré Operação MT_Simulador de Manobras


customização

Atende COM

customização

RO 2.07.28 Descrição Habilidade do sistema de suportar o agendamento de uma sequência de manobras contendo

informações como descrição, comentários, solicitante, data, horário, etc, além das informações

da manobra propriamente dita.

RO 2.07.29 Geral O sistema deverá possuir um módulo de simulação de manobras. Este deverá conter a base

cartográfica, geográfica e unifilar de redes AT/ MT/ BT, podendo ser ativada através de camadas,

contendo todos os equipamentos e dispositivos de manobra, esquemáticos de Subestações e

demais atributos pré-estabelecidos. Deverá permitir consulta de equipamentos e informações

destes.

RO 2.07.30 Simulação de Manobras Deverá conter uma ferramenta de simulação, em função dos equipamentos atuados e que isolam

o trecho, apontados no pedido de desligamento de forma automática ou através de indicação por

seleção manual, indicando as opções de manobra e o percurso de rede (trace) sugerido em caso

de equipamentos automatizados.

RO 2.07.31 Histórico de Manobras Possuir uma ferramenta para armazenar as informações de trecho simulado ou a ser desligado,

visando a análise por parte do solicitante ou programador.

RO 2.07.32 Analisador de Manobras Identificar conflitos entre os trechos de manobras gravadas, visando posterior definição sobre os

aproveitamentos, agrupamentos de manobras e dos pedidos de desligamentos simulados.

Pg. 17 de 43


RO 2.07.33 Marcação e Trace Permitir diferenciar graficamente as sinalizações e marcações dos equipamentos e dispositivos,

em função de interrupções decorrentes de manobras Emergenciais, Voluntárias e Programadas,

de forma a auxiliar usuários da Operação e Programação nas análises e ações.

RO 2.07.34 Configuração do

Simulador

Possuir ferramentas de configuração de modo em função de curvas de carga/horários,

redefinição de rede alterada/projetada ou rede em tempo real, visando simular em diferentes

situações ou definição de critérios pré-estabelecidos para emissão e execução de manobras.

RO 2.07.35 Integração Deverá integrar-se a outros sistemas internos e externos (GEO, SOD, SAP, ERP/ CIS, por

exemplo), possibilitando comunicação para consulta, exportação ou replicação de dados

conforme parâmetros pré-estabelecidos.

2.08 Ordens de Manobra


customização

Atende COM

customização

RO 2.08.01 Geral O sistema deverá permitir que as informações pré-estabelecidas sejam preenchidas de forma

automática, através da integração dos módulos de Pedidos de Intervenções Programadas,

Simulador de Manobras e Avisos de Desligamentos Programados, contendo as atuações dos

equipamentos necessários a simulação.

RO 2.08.02 Geral Deve contemplar a opção de execução automática das manobras da lista com data e horário

previstos pelo técnico verificador, programador ou operador.

RO 2.08.03 Geral Deve contemplar a opção de execução completa da lista de manobra a partir de um disparo do

operador.

RO 2.08.04 Geral Deve contemplar a opção de execução da lista de manobra passo a passo com ciência do

operador antes de cada passo.

RO 2.08.05 Geral Deve contemplar a opção de execução da lista disparada por um evento (originado no SCADA

por exemplo).

RO 2.08.06 Interface O sistema deverá conter uma interface, permitindo a atuação através de diagrama esquemático

dos itens de operação pelo programador, visando gerar uma simulação de forma automática ou

manual.

RO 2.08.07 Campos Conter os diversos campos, trazendo as informações de resultados das simulações de

manobras.

RO 2.08.08 Emissão de Manobras Emitir uma manobra a partir de uma simulação, através de indicação manual ou padrão pré-

definidos, com sequência indicada pelo programador ou sugerida pelo sistema.

RO 2.08.09 Emissão de Manobras Emitir uma manobra a partir de uma simulação, através de interligação temporária ou em anel,

com sequência indicada pelo programador ou sugerida pelo sistema.

RO 2.08.10 Registro de Manobras Incluir, alterar ou excluir registros, de acordo com o perfil pré-estabelecido do usuário.

RO 2.08.11 Lista de Clientes

Afetados

Gerar listagem dos clientes afetados na simulação, com todas as informações de cadastro e

contatos, para análise e avaliação dos critérios de desligamento e manobras pré-estabelecidos.

RO 2.08.12 Simulação de

Parâmetros

Possbilitar a simulação e cálculo dos níveis de queda de tensão, carregamento de condutores e

aspectos de proteção dos equipamentos e dispositivos envolvidos na manobra. ou outros

parâmetros pré-estabelecidos.

RO 2.08.13 Consulta das Manobras O sistema deverá conter um tela de consulta e seleção das manobras gravadas, com todos os

dados necessários pré-estabelecidos, com configuração de filtros conforme necessidade dos

usuários e parâmetros pré-estabelecidos.

RO 2.08.14 Simulação de

Equipamentos

Conter ferramenta de simulação, visando identificar e indicar alguns pré-requisitos a definir, que

deverão ser avaliados pelo programador antes de gerar a manobra, tais como: indicação de

equipamentos especiais (BC, BRT, RA) e elos fusíveis em manobras de anel ou interligação de

trechos.

RO 2.08.15 Relatórios de

Impedimentos

O sistema deverá emitir/ gerar relatórios, na forma de lista e outras se necessário, visando

consulta e avaliação de impedimentos operacionais sinalizados nos demais módulos do ADMS,

dos equipamentos e dispositivos envolvidos na simulação, visando subsidiar a área de operação

e programação na tomada de decisão ou alterações de solicitações.

RO 2.08.16 Histórico de Registros Permitir arquivamento de registros de simulações, possibilitando a consulta e emissão de

manobras ou novas simulações a partir destas, criando uma biblioteca para consulta pelos

usuários.

RO 2.08.17 Integração O sistema deverá integrar-se a outros sistemas internos e externos (GEO, SOD, SAP, ERP/ CIS,

por exemplo), possbilitando comunicação para consulta, exportação ou replicação de dados

conforme parâmetros pré-estabelecidos.

2.09 Fault Location, Isolation and Service Restoration - FLISR


customização

Atende COM

customização

RO 2.09.01 Descrição Detectar e localizar uma falta na rede a partir dos dados originados no SCADA; isolar o trecho

sob falta e realizar a restauração dos trechos que não estão sob falta.

RO 2.09.02 Contextualização Ponto de falta: local exato onde ocorreu a falta na rede de distribuição.

Trecho sob falta: trecho que contém o ponto sob falta e é delimitado por equipamentos capazes

de reportar (via SCADA) passagem de corrente de falta.

RO 2.09.03 Contextualização O algoritmo FLISR deve ser capaz de realizar funções matemáticas e lógicas para implantação

de funções que possam ser utilizadas na identificação e localização de defeitos na rede.

RO 2.09.04 Detecção O algoritmo FLISR deve ser capaz de detectar um trecho sob falta a partir dos dados de tempo

real. Em casos de jumper aberto ou rompimento de cabo lado carga nos alimentadores de 13,8

kV não haverá atuação do RA, assim uma lógica de detecção deste defeito pode ser implantada.

Neste caso, deverá ser utilizado os dados de correntes dos alimentadores, inclusive

componentes simétricas. O Algoritmo FLISR deverá ser capaz de realizar a lógica e verificar a

relação de corrente de sequência negativa e positiva. A utilização dos dados dos medidores

inteligentes também deverá ser utilizada, pois será possível identificar a falta de fase no

alimentador bem como estimar o possível local do rompimento e informando ao operador em

tempo real.

Pg. 18 de 43


RO 2.09.05 Detecção O algoritmo FLISR deve respeitar/aguardar a sequência de religamentos de RAs de rede e/ou de

subestação que estiverem alimentando o trecho sob falta, para não concorrer com a função de

religamento automático.

RO 2.09.06 Localização da falta O algoritmo FLISR deve ser capaz de localizar de forma única um trecho sob falta, processando

os dados de tempo real originados do SCADA, e as informações disponívels no modelo de rede

e topologia de rede.

Em não ocorrendo o desligamento permanente (abertura e bloqueio de equipamento com

telecomando), o algoritmo deve estimar o local de defeito utilizando dados dos outros

equipamentos, tais como medidores inteligentes, equipamentos de localização de falta, etc.

RO 2.09.07 Localização da falta O algoritmo FLISR deve utilizar a informação de distância de falta originada no RA, quando

disponível, para estimar dentro do trecho sob falta, o ponto onde ocorreu a falta.

Nestes e nos demais casos, deve ser considerado o erro da estimaiva de distância dos

religadores. Para defeitos envolvendo as fases a estimativa é mais próxima ao real, todavia para

defeitos envolvendo a terra (principlamente os de alta impedância), a estimativa acaba tendo um

erro muito grande. Para estes casos pode-se sugerir que o algoritmo tenha uma lógica para

utilizar ou não os dados do localizador de falta de acordo com o tipo de falta ou um limiar de

distância como comparação.

RO 2.09.08 Localização da falta O sistema deve considerar as informações originadas nos medidores inteligentes, quando

disponíveis, e as utilize para compor o processo de localização de falta, de forma a a refinar a

estimativa do ponto de falta.

RO 2.09.09 Localização da falta A localização deve se dar de forma que o trecho identificado como faltoso seja o menor possível,

considerando o sensoriamento da rede.

O algoritmo deve possuir restrição de reconfiguração quando for identificado um possível defeito

de alta impedância (para evitar desligamento da fonte alternativa, por exemplo). Para esta

restrição, sugere-se que o algoritmo bloqueie a reconfiguração automática.

Deve-se considerar os dados de tensão dos medidores inteligentes para auxiliar nesta estimativa

de localização.

RO 2.09.10 Localização da falta O ADMS deve dispor de sinalização visual na IHM que informe ao operador graficamente onde a

falta está localizada.

RO 2.09.11 Localização da falta A inserção da sinalização visual na IHM do local da falta deve ser automática, imediatamente

após a falta ser localizada, e a sua retirada deverá ser feita pelo operador.

RO 2.09.12 Isolamento do trecho Deve ser capaz de isolar automaticamente (sem a necessidade de intervenção/autorização do

operador responsável) o trecho identificado sob falta por meio de manobras na rede utilizando

somente equipamentos com controle e comando remotos.

RO 2.09.13 Isolamento do trecho Para o isolamento, o algoritmo deve considerar os equipamentos de manobra telecomandáveis

que são vizinhos imediatos ao ponto de falta.

RO 2.09.14 Isolamento do trecho Em caso de falha/impedimento de comando sobre um desses equipamentos, o algoritmo deve

considerar isolar uma área maior da rede a partir do equipamento telecomandável a montante

daquele sob falha/impedimento, desde que não cause mais desligamentos (não aumente a área

desligada).

RO 2.09.15 Isolamento do trecho O sistema ADMS deve dispor de sinalização visual na IHM que informe ao operador, durante a

etapa de isolamento, imediatamente antes/depois de uma manobra, que aquele dispositivo

manobrado está sob restrição de operação (devido a alimentar trecho sob falta).

RO 2.09.16 Isolamento do trecho O sistema ADMS deve dispor de sinalização visual na IHM que informe ao operador, durante a

etapa de isolamento, imediatamente antes/depois de uma manobra, que aquele dispositivo foi

manobrado pela função FLIRS.

RO 2.09.17 Restauração do Serviço Deve ser capaz de restaurar os trechos que não estão sob falta utilizando outras fontes/vias de

energia.

RO 2.09.18 Restauração do Serviço Deve ser possível ao operador/usuário escolher se as manobras de restauração da rede devem

ser realizadas automaticamente ou por disparo do operador.

RO 2.09.19 Restauração do Serviço Deve ser possível ao operador/usuário escolher se as manobras de restauração da rede devem

ser realizadas automaticamente ou por disparo do operador.

RO 2.09.20 Restauração do Serviço O ADMS deve apresentar na função FLISR opções de restauração seguindo critérios de

otimização, incluindo minimizar o impacto nos índices de mérito (DEC);

RO 2.09.21 Restauração do Serviço Quanto à opção por manobras de reastauração automaticas, o critério de otimização deverá ser

aquele escolhido em tempo de configuração.

RO 2.09.22 Restauração do Serviço Quanto a opção por manobras de restauração disparadas pelo operador, é desejável que o

critério de otimização possa ser escolhido em tempo de operação, pelo operador/usuário, a partir

de uma lista oferecida pelo sistema.

RO 2.09.23 Restauração do Serviço Antes de iniciar a sequência de manobras de restauração, o sistema deve realizar uma

verficação de violação dos limites de tensão e de carregamento, levando em consideração a

condição/estado do sistema após as manobras.

RO 2.09.24 Restauração do Serviço Para fins de restauração de serviço na função FLIRS, a violação de limites de tensão e

carregamento deve ser verificada na rede de distribuição, assim como deve ser verificado

violação de carregamento no transformador de potência conectado à barra de carga do

alimentador envolvido na restauração.

RO 2.09.25 Restauração do Serviço Para fins de restauração de serviço na função FLIRS, a violação de limites de tensão e

carregamento deve ser verificada levando também em consideração dados de tempo real

(carregamento e perfil de tensão do momento).

RO 2.09.26 Restauração do Serviço Caso o disparo de manobras seja feito pelo operador, então o sistema deve informar

previamente, para cada opção de restauração apresentada ao operador, se haverá violação

como consequência da manobra.

RO 2.09.27 Restauração do Serviço Caso o disparo das manobras seja automático, então as violações de carregamento, quando

verificadas, devem ser impeditivas para a restauração e as de tensão podem ser opcionalmente

(escolha a critério do usuário) impeditivas.

Pg. 19 de 43


RO 2.09.28 Restauração do Serviço Nos casos de violação de limites verificados, o sistema deve informar ao usuário/operador, de

qual tipo é a violação (tensão, carregamento) e onde a mesma está localizada.

RO 2.09.29 Restauração do Serviço O sistema deve identificar possíveis violações futuras de limites de carregamento (previsão de

violação futura de carregamento) sendo desejável que para isso ele utilize uma previsão de

carga a curto prazo.

RO 2.09.30 Restauração do Serviço A janela de tempo na previsão de violação futura de carregamento deve ser uma opção de

escolha do usuário.

RO 2.09.31 Restauração do Serviço Caso o disparo de manobras seja feito pelo operador, então é desejável que o sistema informe

previamente, para cada opção de restauração apresentada ao operador, se há previsão de

violação futura de carregamento como consequência da manobra.

RO 2.09.32 Restauração do Serviço Esta funcionalidade deve considerar a hipótese de dividir em mais de um alimentador a carga a

ser recomposta, quando não for possível atribuir todo o montante desligado a somente um

alimentador.

RO 2.09.33 Restauração do Serviço Esta funcionalidade deve apresentar a opção de desconsiderar a restauração de um ou mais

blocos de carga quando não for possível, devido à violação de limites, recompor 100% da carga

pertencente aos trechos sadios desligados. Nesse caso, deve-se restaurar o montante máximo

de carga que for possível sem a violação de limites.

RO 2.09.34 Geral Deve ser compatível com uso de dispositivos diversos na rede como: religadores de rede

automatizados, chaves de rede automatizadas, sensores de falta automatizados.

RO 2.09.35 Geral Deve considerar no processamento dos dados (topológicos por exemplo) elementos de secção

de rede, sejam eles supervisionados ou não, como chaves de redes não supervisionadas e

jumpers inseridos pelo operador/usuário no sistema.

RO 2.09.36 Requisito de segurança Por questões de segurança, deve ser possível selecionar em tempo-real pelo operador/usuário

um trecho de rede (área de impedimento) no qual o a funcionalidade FLISR não pode

atuar/efetuar manobras.

RO 2.09.37 Requisito de segurança Deve ser possível selecionar a área de impedimento da função FLIRS de forma gráfica.

RO 2.09.38 Requisito de segurança Deve permitir ao usuário/operador bloquear/desativar em tempo real as funções de isolação e

restauração automática em todo o sistema, assim como em circuitos específicos e também em

equipamentos específicos.

RO 2.09.39 Geral Esta funcionalidade deve desconsiderar a hipótese de colocar alimentadores operando em

paralelo (dois ou mais alimentadores interligados).

RO 2.09.40 Requisito de segurança Por questões de segurança, esta funcionalidade deve respeitar as tags de restrição de operação

em cada elemento de rede, como bloqueios de linha viva, de religamento, de comando, modo

chave no RA.

RO 2.09.41 Geral O ADMS deve apresentar uma funcionalidade de remanejamento automático de carga por

desligamento de barra de carga em subestação. Situação na qual outras fontes podem assumir a

carga total ou parcial que estava conectada à barra desligada.

RO 2.09.42 Pós operação Quando da atuação da funcionalidade FLIRS, o sistema deve disponibilizar um relatório (log) de

atuação, o qual deve conter informações que subsidiaram as tomadas de decisão do algoritmo, a

fim de possibilitar uma investigação pós operação da atuação (correta ou não) desta função.

RO 2.09.43 Requisito de Inteligência

Computacional

Os algoritmos de detecção, localização e isolamento de falta, assim como o algoritmo de

restauração do serviço devem ter inteligência computacional o suficiente para que no mínimo

desempenhem suas respectivas funções como um operador o faria de posse de todas as

informações contidas no ADMS, desconsiderando a diferença de tempo necessário para o

operador e para o sistema realizarem tal tarefa.

RO 2.09.44 Requisito de

Desempenho

Considerando somente o tempo de processamento na funcionalidade, isto é, descontados os

tempos de chegada das medições e estados (tempo entre a ocorrência do evento em campo e

seu registro no SCADA) retorno de comando e possíveis decisões do operador, o algoritmo

FLIRS deve ser capaz restaurar o serviço em um tempo menor que 1 minuto.

RO 2.09.45 Plano Recomposição Deve possuir algorítmo que resulte a sequência de equipamentos para manobra de

recomposição trecho a trecho, incluíndo o direcionamento e melhor trajeto para as equipes.

RO 2.09.46 Recomposição Deve haver um cadastro de plano de recomposição de trechos e alimentadores, prevendo

chaves estratégicas ou não, e melhor prática de trajeto para se inspecionar e recompor trechos

de um alimentador que estiverem desligados acidentalmente, sem o devido conhecimento do

ponto de falha. Entende-se que este será utilizado após recomposição parcial remota executada

no DMS para casos específicos não resolvido pelo algorítmo de plano de recomposição em

tempo real.

2.10 Playback


customização

Atende COM

customização

RO 2.10.01 Descrição Funcionalidade que possibilita visualizar dados históricos na interface gráfica de operação a partir

de uma data e horário pré-definido e escolhido pelo operador/usuário.

RO 2.10.02 Geral Deve permitir a visualização em IHM de dados históricos originados no SCADA e internamente,

de forma a permitir que o operador/usuário possa visualizar esses dados em IHM como se

estivessem acontecendo no momento atual, inclusive utilizando as mesmas interfaces do

sistema em tempo real, nas telas de alarme, eventos e navegar entre subestações e áreas de

rede distintas.

RO 2.10.03 Geral A função de recuperação de dados deverá ser capaz de recriar uma configuração já passada do

sistema de potência e possibilitar uma visão geral do estado do sistema de potência em qualquer

ponto histórico no tempo passado.

RO 2.10.04 Geral Uma vez recuperado o banco de dados SCADA, a função deverá permitir ao operador:

•Recuperar os dados para um outro momento

•Pular para frente para um próximo momento, no qual houve mudança nas informações

•Entrar no modo “playback” no qual a recuperação dos dados deverá ser contínua. A velocidade

de recuperação deverá ser ajustável de maneira mais rápida ou mais lenta, em relação ao

período de hora normal

Pg. 20 de 43


RO 2.10.05 Geral Em modo “playback” o operador poderá selecionar valores e utilizar os recursos de curvas

fornecidos com o Sistema.

RO 2.10.06 Geral As telas devem ter uma indicação clara de que se está trabalhando em modo “Playblack”

RO 2.10.07 Geral Deve ser capaz de selecionar um determinado período para carregar no modo de Treinamento,

para reproduzir, modificar e estudar o que foi armazenado no sistema naquele momento. Neste

caso os dados recuperados serão usados como ponto de partida para uma sessão de simulação.

2.11 Previsão de carga à curto prazo


customização

Atende COM

customização

RO 2.11.01 Geral Deve fornecer ao operador/usuário do sistema e às funcionalidades que a utilizam, estimativas

de carregamento de um equipamento/dispositivo para as próximas horas.

RO 2.11.02 Geral O fornecedor de DMS deve informar como a previsão é feita para que haja uma avaliação de sua

eficácia pela equipe técnica.

RO 2.11.03 Geral Deve calcular as tensões e correntes complexas em todos os ramais das redes de distribuição.

RO 2.11.04 Geral A estimativa de cargas deve levar em consideração medições do sistema de automação.

Também deve estimar a condição futura com base na sazonalidade do alimentador.

RO 2.11.05 Geral Na impossibilidade momentânea de obter dados de medição para determinação da carga, deve

utilizar valores históricos de consumo e alertar o operador dessa condição na analise.

2.12 Interação com Usuário


customização

Atende COM

customização

RO 2.12.01 Geographical User

Interface

Deve oferecer uma interface gráfica de operação.

RO 2.12.02 Geographical User

Interface

Deve ser possível operar todas as instalações a partir de uma interface gráfica georeferenciada

RO 2.12.03 Tags de sinalização em

equipamentos

As tags devem ser incluídas e eliminadas pelos operadores a qualquer momento e para qualquer

equipamento, devendo ocorrer registro (através de log) do usuário que incluiu a tag e o que

eliminou a mesma. O histórico deve ser migrado ao registro de informações complementares de

registro do atendimento (+INFO) da ocorrência associado ao OMS.


equipamentos

Deve haver possibilidade de inclusão e vínculo de impedimento e (ou) restrição do equipamento

a uma ou mais equipes de campo. Não deve ser permitido que a tag seja eliminada até que todas

as equipes nela incluídas tenham liberado tal equipamento (para cada registro de inclusão e

liberação de equipes de campo deve haver o registro de log do usuário que realizou tal

operação). A tag deve possuir identificação da equipe, motivo, contato.


equipamentos

Na tela de ALARMES, sinalizará quando ocorrer alteração de estado do equipamento

automaticamente, para a incidência de tag's associada ao mesmo.


equipamentos

Deve permitir incluir “big-jumper”, sendo um trecho fictício ainda não previsto no GEO, o qual

servira de para alimentação de trecho provisoriamente.


equipamentos

Deve permitir incluir uma subestação móvel (fictícia), conectando-se a fonte e cargas através de

jumper manualmente pelo usuário.


equipamentos

A ferramenta deve permitir que sejam cadastrados alarmes nas tags com registro de ações a

serem realizadas pelo operador no instante determinado.

RO 2.12.09 User Interface Facilities Tracing: ao selecionar um elemento de rede pode-se percorrer o caminho upstream e

downstream do mesmo.

RO 2.12.10 User Interface Facilities Esquema dinâmico de cores na rede, para por exemplo diferenciar trechos energizados daqueles

não energizados, para identificar circuitos alimentadores diferentes, entre outros.

RO 2.12.11 Perfis de Usuários Deve possuir administração de restrição às diversas funcionalidades do sistema por tipo de

usuários (Administradores, Suporte, Operadores, Remotos, Auditores, etc).

As restrições, referem-se a nível de acesso, registro e consulta a informações e base de dados,

prioridade de processamentos em tempo real, acesso a aplicações em trâmites de Produção,

Homologação, Desenvolvimento.

RO 2.12.12 Perfis de Usuários Deve permitir manter o cadastro dos usuários por usuários administradores do sistema.

RO 2.12.13 Perfis de Usuários Deve possuir layout padrão para novos usuários, podendo ser customizado e gravado por estes

quando necessário, às características que não influenciaram na segurança operacional.

RO 2.12.14 Navegabilidade Deve possuir navegabilidade a múlltiplas telas, limitando-as quando necessário para exibição de

informações consistentes.

RO 2.12.15 Representação Deve modelar topologia por camadas de área elétrica (AT, MT e BT), com as demais simbologias

por camadas opcionais (equipes de campo, equipamentos operacionais, logradouros,UC's VIPS,

UC's de Serviço Básico a População, Hospitais, etc).

RO 2.12.16 Visão Geográfica Deve representar camada opcionais como ortofotos, fotos por satélite, visão panorâmica e GEO

Espacial (caso possua serviço de mapas fornecido).

2.13 Dispatcher Training Simulator - DTS


customização

Atende COM

customização

RO 2.13.01 Definição O simulador de treinamento do operador (simulador) deve apresentar um cenário de operação

pré-definido pelo instrutor para treinamento de operadores (treinandos), que a partir daí, passarão

a intervir em um sistema simulado como se fosse uma condição operativa real.

RO 2.13.02 Básico Deve ser uma cópia do sistema da operação em tempo real (sistema principal) com todas

funcionalidades fornecidas, com exceção das interfaces externas e aquisição de dados das

UTRs (unidades terminais remotas).

Pg. 21 de 43


RO 2.13.03 Básico Possuir a característica de estar em ambiente separado, com servidores exclusivos para essa

funcionalidade, porém interligado à rede, com função de treinamento e testes.

RO 2.13.04 Básico A operação do simulador (execução, manutenção da base de dados, telas e integração de novas

funções) deve ocorrer de forma simultânea com o sistema principal; e não deve afetar na

operação dos ativos da empresa e na performance do sistema principal.

RO 2.13.05 Básico O simulador deve aplicar as ações do treinando no sistema simulado, e a partir daí, revisar sua

topologia e estados (estado de equipamento de manobra, tensões nas barras, fluxos ativos e

reativos, cargas) conforme esperado para uma situação real, utilizando as diversas

funcionalidades fornecidas nesse sistema como: análise de topologia, estimador de estados,

fluxo de potência, funções automáticas de recomposição e outras.

RO 2.13.06 Básico Todas as alterações de topologia e de estados do sistema simulado deverão gerar uma resposta

dinâmica do sistema, conforme esperada para operação em tempo real (alarmes, eventos,

disparo de funções automáticas, atuação de proteções modeladas e outras).

RO 2.13.07 Básico Os simuladores do EMS, DMS, OMS devem ser únicos ou haver uma forma de integração para

possibilitar treinamento de todos os operadores da distribuidora de forma integrada, como

acontece na operação em tempo real.

RO 2.13.08 Básico As telas do simulador devem ser diferenciadas das telas do sistema principal por bordas, ou

fundos de tela ou outro recurso disponível, para que o operador não confunda os ambientes de

operação em tempo real do ambiente de simulação.

RO 2.13.09 Básico As interfaces do instrutor e do treinando devem ser as mesmas porém com privilégios

diferenciados.

RO 2.13.10 Básico O simulador deve ser capaz de replicar na sua base de dados para simulação: o cenário atual da

operação em tempo real, cenários do historiador (depois de ocorridos) ou cenários hipotéticos

para fins de treinamento, análise e estudos.

RO 2.13.11 Básico Deve permitir a construção de vários cenários de treinamento e testes de até 24 horas de

duração com eventos pré-definidos pelo instrutor, com a possibilidade de criação de outros

cenários a partir de um existente.

RO 2.13.12 Básico Deve ser possível inicializar o caso base de treinamento a partir de dados telemedidos oriundos

do sistema principal, dados estimados ou de casos arquivados.

RO 2.13.13 Básico A ações de começar, parar, suspender ou recomeçar uma sequência de treinamento devem ser

possíveis de serem executadas em qualquer período dentro de um cenário.

RO 2.13.14 Básico A solução deve permitir a alteração da velocidade de execução do cenário (acelerar ou

desacelerar o tempo).

RO 2.13.15 Básico O simulador deve gerar “Logs” e estatísticas de desempenho (sobrecarga, violação de tensão,

interrupção de carga) da sessão de treinamento para registrar todas as ações do instrutor e

treinandos.

RO 2.13.16 Modelagem O simulador deve responder aos comandos realizados pelos treinandos e revisar a topologia e

estados do sistema simulado.

RO 2.13.17 Modelagem Deve ser possível a simulação do controle remoto de tensão, com atuação automática em tapes

de transformadores.

RO 2.13.18 Modelagem As situações de faltas temporárias ou permanentes devem ser possíveis de simulação, com a

atuação automática em disjuntores/religadores.

RO 2.13.19 Modelagem Deve simular sobrecargas em equipamentos, e caso essas violações excederem algum tempo a

ser definido, deve ocorrer atuação automática em disjuntores/religadores.

RO 2.13.20 Modelagem Deve simular violações de limite de tensão inferior/superior no sistema simulado; e se essas

violações excederem algum tempo a ser definido, deve ocorrer atuação automática conforme a

função a ser simulada.

RO 2.13.21 Modelagem Deve simular religamento automático com atuação automática em disjuntores/religadores.

RO 2.13.22 Modelagem As falhas em UTR (unidade terminal remota) total ou parcial devem ser possíveis de simulação,

assim ocasionando falha na supervisão.

RO 2.13.23 Modelagem O simulador deve permitir mudança em cargas individuais em barra.

RO 2.13.24 Modelagem O simulador deve permitir mudança na carga de uma área (neste caso, o valor da carga deverá

ser distribuído pelas cargas individuais nas barras).

RO 2.13.25 Dimensionamento Devem ser previstas: 01 (uma) console para o instrutor responsável pela supervisão e controle

da sessão de treinamento; e 07 (sete) consoles para os treinandos (para todo o sistema ADMS).

RO 2.13.26 Básico Durante as simulações baseadas no historiador, o OMS, também deve replicar as reclamações

de unidade consumidoras, assim como função TCS.

RO 2.13.27 Básico O simulador deve possuir função Replay (repetição de um intervalo de tempo pré-definido), onde

exibirá o cenário e ações ocorridas, no EMS, DMS e OMS, salvas no historiador .

3. EMS

3.01 Modelo de Rede AT


customização

Atende COM

customização

RO 3.01.01 Contextualização O termo modelagem utilizado neste item refere-se a todos os parâmetros necessários para que

um dispositivo possa ser utilizado nas aplições avançadas do ADMS como por exemplo:

estimador de estados, cálculo de fluxo de potência, modo simulação, modo tempo real e

simulador de treinamento (OTS).

RO 3.01.02 Requisito Básico Deve permitir a modelagem de linhas de transmissão CA e CC

RO 3.01.03 Requisito Básico Deve permitir a modelagem de linhas de transmissão com uma ou mais derivações

RO 3.01.04 Requisito Básico Deve permitir a modelagem de transformador com dois e três enrolamentos

RO 3.01.05 Requisito Básico Deve permitir a modelagem de transformadores interligadores

RO 3.01.06 Requisito Básico Deve permitir a modelagem de transformadores elevadores de tensão

Pg. 22 de 43


RO 3.01.07 Requisito Básico Deve permitir a modelagem de transformadores de 3 enrolamentos em que: no primário e

secundário há uma configuração do tipo transformador interligador, e no terciário há barra de

carga conectada.

RO 3.01.08 Requisito Básico Deve permitir a modelagem de transformador com comutação de tap sob carga e com tap fixo

RO 3.01.09 Requisito Básico Deve permitir a modelagem de regulador de tensão com comutação de tap sob carga e com tap

fixo

RO 3.01.10 Requisito Básico Deve permitr a modelagem de bancos de capcitores

RO 3.01.11 Requisito Básico Deve permitir a modelagem de disjuntores, chaves secionadoras e chaves de aterramento

RO 3.01.12 Requisito Básico Deve permitir a modelagem de acessante com geração de energia

RO 3.01.13 Requisito Básico Deve permitir a configuração de arranjos diversos de barramentos

RO 3.01.14 Requisito Básico Deve permitir a modelagem de blocos de carga pontuais para conexão nas LTs.

RO 3.01.15 Requisito Básico Deve permitir a modelagem e conexão de dispositivos temporários como: transformadores

móveis, subestações móveis, unidades de geração, conexão temporária entre dois nós (jumper),

seccionamento temporário de LTs, aterramento temporário de barras e LTs, blocos de carga

pontuais nas LTs temporários.

RO 3.01.16 Requisito Básico Deve ser possível ao operador/usuário do sistema inserir, alterar e remover os dispositivos

temporários

RO 3.01.17 Requisito Básico As alterações customizadas pelo operador/usuário, como a inserção, alteração e remoção de

dispositivos temporários devem ser mantidas nas atualizações diárias do modelo originadas no

GIS.

RO 3.01.18 Requisito Básico O sistema deve ser capaz de importar modelos de rede de uma fonte externa, pelo menos nos

formatos utilizadops pela Copel como ANAREDE, SINAPgrid, GIS, GEO, etc.

RO 3.01.19 Requisito Básico O sistema deve analisar a conectividade entre os dispositivos modelados em tempo real, no

modo simulação e no ambiente de treinamento.

RO 3.01.20 Requisito Básico O sistema deve em tempo real e de forma automática monitorar os dispositivos modelados para

analisar e informar graficamente a condição de energizado e não enegizado de cada dispositivo.

RO 3.01.21 Requisito Básico Deve ser possível a customização por meio de cores nas barras, LTs e interligações para

representar níveis de tensão, em que cada cada nível nominal de tensão seja representado por

uma cor diferente no estado energizado.

RO 3.01.22 Ilhamento O ADMS deve dispor de funcionalidade para detectar ilhamento no sistema de subtransmissaão

seja ele proposital (por manobra do operador) ou não proposital (por eventos sistêmicos)

RO 3.01.23 Ilhamento A funcionalidade para detectar ilhamento deve sinalizar de forma visível e graficamente a(s)

ilha(s) formadas após a detecção do ilhamento.

RO 3.01.24 Carga interrompida Em casos de desligamento, o ADMS deve informar o valor total de carga interrompida em MW.

RO 3.01.25 Carga interrompida Deve ser possível a visualização do valor de carga interrompida em MW por

dispositivo/equipamento/elemento de rede.

RO 3.01.26 Rede de baixa tensão A rede de baixa tensão pode ser representada ou não no diagrama, conforme opção do

operador.

3.02 Estimador de Estados


customização

Atende COM

customização

RO 3.02.01 Definição O estimador de estados (estimador) deve estimar valores analógicos (pseudomedições) de todo

sistema elétrico operado, a partir dos parâmetros construtivos da rede elétrica (modelo de rede) e

as telemedições disponíveis no sistema da operação em tempo real (sistema principal) ou

informadas pelos operadores, visando melhorar a confiabilidade das medições aquisitadas e

disponibilizar pseudomedições onde não houver ou estiver indisponível.

RO 3.02.02 Básico O estimador deve estimar magnitude e ângulo de tensão, injeção de MW e MVAr (carga e

geração) nas barras; corrente, fluxo de MW e MVAr nas linhas; posição do tap de

transformadores e reguladores de tensão; operação de compensação reativa (banco de

capacitores); e outras grandezas aplicadas à distribuição.

RO 3.02.03 Básico O estimador deve ter capacidade para detecção e correção de erros grosseiros com notificação

do operador para autorizar a substituição do valor tele medido pela pseudomedida ou não; e

ainda, deve haver uma forma de ativar um processo automático de uso dos valores estimados

sem solicitação específica ao operador.

RO 3.02.04 Básico O estimador deve ser capaz de gerar alarme na ocorrência de sobrecargas e/ou violações de

tensão em dispositivos monitorados ou não, com a possibilidade de inibição desses alarmes pelo

operador.

RO 3.02.05 Básico O estimador deve armazenar os resultados em casos arquivados, para uso posterior em outras

funcionalidades do sistema de operação em tempo real, como: fluxo de potência em tempo real,

análise de manobras, análise de contingência em tempo real, simulador de treinamento e outras.

RO 3.02.06 Básico O estimador deve ter uma interface com operador para definição das condições de

processamento: por demanda, por evento ou periodicamente.

RO 3.02.07 Básico O estimador deve possibilitar a exibição de todos os valores da solução nas telas de diagramas

unifilares disponíveis para operação em tempo real ou em tela espelhada.

RO 3.02.08 Básico O estimador deve possuir interface para exportação dos resultados para utilização externa no

formato XLS, TXT, CSV e outros.

RO 3.02.09 Básico O estimador deve apresentar relatórios diversos de: resultados, análises e detalhamento de

processamento para auxílio na análise e consistência dos resultados dessa funcionalidade.

RO 3.02.10 Básico O estimador deve permitir a criação e/ou edição de uma pseudomedida (mesmo onde não

houver medição) pelo operador visando a melhoria da solução desta funcionalidade.

RO 3.02.11 Modelagem O estimador deve contemplar a análise de todos os pontos observáveis, seja na rede de média

tensão, quanto na rede de alta tensão.

Pg. 23 de 43


RO 3.02.12 Modelagem Deve contemplar a análise em redes com malha aberta (circuitos radiais) ou fechada (circuitos

em anel), conforme a topologia.

RO 3.02.13 Modelagem O estimador deve contemplar análise de desbalanceamentos na rede trifásica.

RO 3.02.14 Modelagem O estimador deve distribuir carga ao longo de trecho de redes com tensão de 13,8kV e 34,5kV.

RO 3.02.15 Modelagem O estimador deve fazer consistência do estado dos equipamentos de manobra com suas

medições analógicas, assim identificando e exibindo as inconsistências detectadas.

RO 3.02.16 Modelagem O estimador deve ter capacidade para identificar erro de topologia nas áreas observáveis.

RO 3.02.17 Modelagem O estimador deve ter capacidade para identificar erro nos parâmetros construtivos da rede

elétrica nas áreas observáveis.

RO 3.02.18 Modelagem O estimador deve contemplar os seguintes elementos de rede nas tensões de 13,8 kV até 138

kV: linhas de distribuição, transformadores com tap em derivação, banco de capacitores,

reguladores de tensão, geração distribuída e outros aplicados à distribuição.

3.03 Fluxo de Potência


customização

Atende COM

customização

RO 3.03.01 Geral O sistema deve possuir capacidade para modelagem de, no mínimo, todos os tipos de

transformadores e grupos de ligação (inclusive transformadores com controle de tapes), reatores

e capacitores conectados em série ou derivação, todos os tipos de geradores (máquinas

síncronas, assíncronas, geração solar fotovoltaica, baterias, etc.). Também deve ser possível a

modelagem de todos os tipos de cargas, que possam ser analisados em MW, MVAr, etc. a

critério da Copel, possibilitando a alteração da análise de forma simples e dinâmica, bem como

realizar análises de cargas especiais como grandes motores, etc.

RO 3.03.02 Geral Possuir simulação de desligamentos de Linhas de Transmissão (LTs), barras e cargas

RO 3.03.03 Geral Deverá permitir escolher entre as unidades MW, MVAr, corrente, ângulo e p.u.

RO 3.03.04 Geral Deverá disponibilizar os limites normal e de emergência das LTs

RO 3.03.05 Interface Possuir interface com o AnaRede e possibilitar a geração de arquivos .pwf e .lst que serão

disponibilizados como "casos bases" ao Operador Nacional do Sistema Elétrico (ONS) .

RO 3.03.06 Critério A ferramenta deve considerar cenários com variações de intercâmbio no sistema de transmissão

da rede básica (ativos com tensão >= 230kV).

RO 3.03.07 Critério A ferramenta deve considerar cenários com diferentes níveis de despacho das usinas

conectadas ao sistema de distribuição de alta tensão (geração distribuída conectada em tensão

>= 69kV).

RO 3.03.08 Interface Deve ser possível incluir manualmente modelagem de componentes do sistema elétrico que não

pertencem aos ativos da distribuidora (linhas, grandes motores, geração distribuída, etc..).

RO 3.03.09 Critério Além da integração com os limites dinâmicos dos componentes do sistema elétrico a ferramenta

deve possibilitar a definição manual de restrições específicas em componentes de rede.

RO 3.03.10 Interface Interface com outros Banco de Dados da Copel ( PET, GDMASE, etc.)

RO 3.03.11 Interface Realizar o registro da curva das unidades geradoras a fim de se avaliar o impacto no sistema

RO 3.03.12 Interface Possuir interface com os casos da Empresa de Pesquisa Energética (EPE), a fim de se avaliar o

impacto dos empreendimentos futuros

3.04 Fluxo de Potência Ótimo


customização

Atende COM

customização

RO 3.04.01 Geral A ferramenta deve proporcionar todas as lógicas e cálculos já incluídos no item de fluxo de

potência, porém, com possibilidade de indicar a "função objetivo" (controle de tensão,

carregamento de linhas, etc.) para otimização na solução do Fluxo de Potência Ótimo (FPO).

Dentre as possibilidades de otimização devem constar no mínimo: Fator de potência, redução de

perdas no sistema de transmissão (ativos com tensão >= 69kV), minimização na comutação de

tapes, minimização de corte de carga durante contingências, otimização no despacho (MW e

MVAr) de usinas conectadas ao sistema de distribuição, minimização de reativos circulantes (em

TFs e LTs).

RO 3.04.02 Critério A ferramenta deve suportar integração total e em tempo real com os dados de limites dinâmicos

dos componentes da rede (transformadores, bancos de capacitores, LTs, etc..).

RO 3.04.03 Resultado Para cada resultado do FPO deverão ser propostas as manobras e demais alterações (mudança

de tape, chaveamento de bancos, etc..) necessárias para atingir a solução do FPO. Todas as

manobras devem ser descritas em ordem de efetividade, ou seja, fazer primeiro a manobra que

mais contribui para atingir a solução. Dentre as soluções deverá ser considerada a necessidade

de remanejamento (redução) de carga. Mudanças na configuração do sistema elétrico de alta

tensão ( tensão >= 69kV) também deverão ser propostas se necessário (paralelismo de linhas ou

TFs, mudanças de bays, etc..).

RO 3.04.04 Critério Além da integração com os limites dinâmicos dos componentes do sistema elétrico, a ferramenta

deve possibilitar a definição manual de restrições específicas em componentes de rede.

RO 3.04.05 Critério Para cada função objetivo definida pelo usuário a ferramenta deve mostrar sua sensibilidade

(taxa de variação) em relação às restrições definidas pelo usuário.

RO 3.04.06 Resultado A execução de medidas definidas no FPO deverá considerar uma lista prioridades (na ordem)

definidas manualmente pelo usuário. Caso não hajam prioridades definidas pelo usuário, as

medidas devem ser executadas conforme grau de efetividade para atingir a solução do problema.

3.05 Análise de Contingência

Pg. 24 de 43



customização

Atende COM

customização

RO 3.05.01 Geral A ferramenta deve permitir a simulação em tempo real da perda de qualquer componente da rede

(linhas de transmissão, transformadores de distribuição, transformadores interligadores -

interface com a rede básica, barras, disjuntores, chaves, bancos de capacitores, etc..).

RO 3.05.02 Cálculo O sistema deve indicar quais as medidas necessárias para minimizar ao máximo as

consequências de contingência(s) - tipo n-1 e n-2. Deve ser possível cadastrar com ordem de

prioridade quais as consequências que cujos efeitos desejam-se eliminar ou minimizar.

RO 3.05.03 Cálculo Deve ser possível alterar condições sistêmicas para análise de contingências de longa duração

(ex: incluir ou excluir despacho de geração distribuída).

RO 3.05.04 Geral Disponibilizar soluções de medidas corretivas, quando da ocorrência de desligamentos não

programados

RO 3.05.05 Geral Modelar a transferência de carga, no caso de uma contingência que resulte em desconexão de

carga

RO 3.05.06 Geral Após atualização do caso base (cenário de simulação da análise de contingência), o sistema

deverá identificar os casos de contingência inválidos e reportá-los.

RO 3.05.07 Geral Possibilidade de especificar o número de contingências de uma região

RO 3.05.08 Geral Obedecer relações de prioridade de desligamento de circuitos ao simular cortes corretivos de

carga de alimentadores, definidos por porcentagem de carga a reduzir em uma região.

RO 3.05.09 Geral Simular reduções de demanda devido a cortes de carga distribuídos em alimentadores, porém

sem desligamento integral dos mesmos.

RO 3.05.10 Geral Simular atuações de ERAC (esquema regional de alívio de carga - subfrequência), EPROSS

(Esquema de proteção contra subtensão), PCMC (plano de corte manual de carga), etc.

RO 3.05.11 Geral Simular a atuação de Esquemas de Controle de Emergências (ECE) específicos, que venham a

ser implantados pela distribuidora em função de restrições de capacidade de equipamentos do

sistema.

RO 3.05.12 Geral Simulação de operação de sistemas ilhados, avaliando as grandezas de tensão, corrente e

consumidores atendidos

3.06 Automatismos de Regulação de Tensão na Alta Tensão


customização

Atende COM

customização

RO 3.06.01 Controle Funções de otimização para controle integrado de tensão e reativos com o objetivo de melhorar o

fator de potência, manter as tensões primárias dos transformadores (TFs) de carga dentro das

faixas admissíveis, reduzir as perdas em LT's, redução de demanda por redução de tensão

(somente se necessário, em contingência ou racionamento), etc.

RO 3.06.02 Controle Atuação em tapes de transformadores de carga de distribuição, chaves de bancos de

capacitores de MT, tapes de reguladores de tensão de MT.

RO 3.06.03 Controle Integração com função de otimização de controle de tensão das transmissoras, aplicada nas

barras supridas por transformadores interligadores (DIT's). Abrange manobras em bancos de

capacitores, reatores e otimização da posição do tape de transformadores conectados às barras

das DIT's.

Para esta integração, serão recebidas do controle de tensão das transmissoras, as seguintes

informações: fluxo de potência em MW, Mvar, Ampère e MVA; valores de tensão no primário,

secundário e terciário (quando houver) dos TFs interligadores; valor numérico da posição do

comutador de taps; valores do fluxo de potência (MW e Mvar) nas fronteiras das áreas de

influência dos TFs Interligadores e estados das chaves de bancos de capacitores e reatores das

Barras DITs.

Segue ainda a relação de ações automatizadas que a distribuidora pode tomar em contrapartida

a este controle de tensão externo: abertura e fechamento dos bancos de capacitores das Barras

de média tensão das SEs da Distribuição; solicitação de ajuste das tensões de campo dos

geradores ligados as Baras de AT da subtransmissão da distribuição; eventual corte de carga, se

necessário em casos extremos e eventual comutação de tap de reguladores de tensão.

RO 3.06.04 Controle Caso não seja possível atender aos requisitos de otimização (melhorar perfil de tensão, reduzir

perdas, etc..) a aplicação deverá atender o mais próximo possível aos requisitos e indicar quais

os componentes limitantes do sistema elétrico. Esta aplicação deverá considerar os limites de

todos os componentes da rede elétrica sob controle.

3.07 Visão ortogonal do sistema


customização

Atende COM

customização

RO 3.07.01 Geral Permitir a visão ortogonal do sistema que deverá ser gerada automaticamente a partir do modelo

de rede importado pela integração com o GIS.

RO 3.07.02 Geral Diagramas ortogonais utilizam somente linhas retas, ângulos de 90 graus e alguns elementos

para visualização da rede elétrica.

RO 3.07.03 Geração automática A partir da conectividade e da configuração dos dispositivos da rede importada do GIS, o ADMS

deve fazer a geração automática de diagramas ortogonais para visualização do estado dos

circuitos de distribuição pelos operadores do sistema, de forma a facilitar a monitoração e

supervisão dos componentes da rede.

RO 3.07.04 Geração automática Na geração automática de diagramas, o operador deverá ter a opção de definir a área elétrica

que diagrama deve representar, e quais tipos de equipamentos serão desenhados no diagrama.

RO 3.07.05 Layout O layout espacial do diagrama deve ser baseado na representação geográfica da porção de rede

que se está representando, preservando suas posições relativas entre si. Por exemplo, os

elementos ao norte de um elemento qualquer será desenhado acima deste. Os elementos nas

derivações laterais, serão colocados ao longo da linha principal conforme direção original do GIS,

e assim por diante.

Pg. 25 de 43


RO 3.07.06 Edição manual do

diagrama

Uma vez que a complexidade de visualização varia de acordo como o tamanho da parte da rede

que representa, o usuário deverá ter a opção de ajustar/editar manualmente a representação

final. O sistema deverá manter a visualização manualmente ajustada.

RO 3.07.07 Atualização do diagrama Durante a importação de dados do sistema GIS, caso exista diagrama ortogonal na área que se

está importando, este diagrama deverá sofrer atualização incremental, preservando os ajustes

manuais feitos previamente pelos operadores/usuários do sistema

RO 3.07.08 Zoom As operações básicas de "zoom" e "pan" podem ser aplicadas também na visão ortogonal do

sistema.

3.08 Informações sobre limites de operação em tempo real (Violações de limites)


customização

Atende COM

customização

RO 3.08.01 Geral Limite de operação de equipamentos e linhas; análise de contingências; Análise de

conectividade. Integração com sistemas para informação sobre capacidade e ajustes de

equipamentos

RO 3.08.02 Modelagem Deverá ser possível inserir limites dinâmicos de correntes de carregamento (calculados em

função de temperatura, velocidade dos ventos, sazonalidade, período diurno ou noturno). Deve

haver possibilidade de interface e importação de banco de dados com equipamentos e suas

características e limites.

RO 3.08.03 Especificação Deverá ser possível inserir limites de tensão específicos para cada barramento de AT ou MT

(com valores de operação máximo e mínimo).

3.09 Tratamento de Alarmes


customização

Atende COM

customização

RO 3.09.01 Geral O processamento inteligente de alarmes tem por objetivo diminuir a quantidade de informação

que os controladores precisam interpretar e consequentemente diminuir o tempo de resposta a

uma situação identificando suas causas.

RO 3.09.02 Tratamento inteligente

de alarmes

O processamento inteligente de alarmes deverá possuir regras configuráveis.


de alarmes

O processamento inteligente de alarmes deverá propor ações para restabelecimento do sistema

elétrico.


de alarmes

O processamento inteligente de alarmes deverá propor ações para evitar ou minimizar os

impactos das ocorrências no sistema elétrico.


de alarmes

O processamento inteligente de alarmes deverá combinar mensagens de alarmes relacionados.


de alarmes

O processamento inteligente de alarmes deverá suprimir alarmes com base em alarmes

relacionados.


de alarmes

O processamento inteligente de alarmes deverá prover avaliação das condições de alarmes

relacionados para determinar a verdadeira condição de alarme.


de alarmes

Os fornecedores deverão descrever em suas propostas as características adicionais disponíveis

em seu sistema de tratamento inteligente de alarmes.


de alarmes

Deve ter a capacidade de realizar consultas nas listas de alarmes baseadas em informações

como data, hora, estação, severidade do alarme, tipo de dispositivo, tipo de alarme ou qualquer

combinação entre estes.

3.10 Indicação de desligamentos e despacho de equipes


customização

Atende COM

customização

RO 3.10.01 Geral Controle de ocorrências

RO 3.10.02 Geral Possibilitar a indicação de desligamentos/manobras

RO 3.10.03 Geral Permitir a inclusão de equipamentos/linhas em tempo real

RO 3.10.04 Geral Envio de equipes para ocorrência

RO 3.10.05 Geral Indicação de equipes trabalhando em SEs ou LDATs

RO 3.10.06 Geral Informação de obras em andamento em SEs ou LDATs

RO 3.10.07 Reportar e notificar

incidentes

Enviar imediatamente notificações e informações de incidentes que ocorreram com o sistema,

via e-mail, sms ou outro aplicativo

RO 3.10.08 Atuações e controle em

cima de contingências e

programação de

desligamentos

Monitorar o sistema com critérios de geração, intercambio, adaptatividade com o clima

RO 3.10.09 Registros Deve possuir ambiente para registro dos detalhes operacionais envolvidos nos desligamentos e

rotina de restabelecimento.

3.11 - Ambiente de Treinamento


customização

Atende COM

customização

RO 3.11.01 Definição O simulador de treinamento do operador (simulador) deve apresentar um cenário de operação

pré-definido pelo instrutor para treinamento de operadores (treinandos), que a partir daí, passarão

a intervir em um sistema simulado como se fosse uma condição operativa real.

RO 3.11.02 Básico O simulador deve ser uma cópia do sistema da operação em tempo real (sistema principal) com

todas as funcionalidades fornecidas, com exceção das interfaces externas e aquisição de dados

das UTRs (unidades terminais remotas).

RO 3.11.03 Básico O simulador deve estar, em ambiente separado, com servidores exclusivos para essa

funcionalidade, porém interligado à rede, com função de treinamento e testes

RO 3.11.04 Básico A operação do simulador (execução, manutenção da base de dados, telas e integração de novas

funções) deve ocorrer de forma simultânea com o sistema principal; e não deve afetar na

operação dos ativos da empresa e na performance do sistema principal.

Pg. 26 de 43


RO 3.11.05 Básico O simulador deve aplicar as ações do treinando no sistema simulado, e a partir daí, revisar sua

topologia e estados (estado de equipamento de manobra, tensões nas barras, fluxos ativos e

reativos, cargas) conforme esperado para uma situação real, utilizando as diversas

funcionalidades fornecidas nesse sistema como: análise de topologia, estimador de estados,

fluxo de potência, funções automáticas de recomposição e outras.

RO 3.11.06 Básico Todas alterações de topologia e estados do sistema simulado deverão gerar uma resposta

dinâmica do sistema conforme esperada para operação em tempo real (alarmes, eventos,

disparo de funções automáticas, atuação de proteções modeladas e outras).

RO 3.11.07 Básico O simulador do EMS e o simulador do DMS devem operar em ambiente único, possibilitando a

integração do treinamento para todos os operadores da distribuidora de forma integrada, como

acontece na operação em tempo real.

RO 3.11.08 Básico As telas do simulador devem ser diferenciadas das telas do sistema principal por bordas, ou

fundos de tela ou outro recurso disponível, para que o operador não confunda os ambientes de

operação em tempo real do ambiente de simulação.

RO 3.11.09 Básico As interfaces do instrutor e do treinando devem ser as mesmas porém com privilégios

diferenciados.

RO 3.11.10 Básico O simulador deve ser capaz de replicar na sua base de dados para simulação: o cenário atual da

operação em tempo real, cenários do historiador (depois de ocorridos) ou cenários hipotéticos

para fins de treinamento, análise e estudos.

RO 3.11.11 Básico O simulador deve permitir construção de vários cenários de treinamento e testes de até 24 horas

de duração com eventos pré-definidos pelo instrutor, com a possibilidade de criação de outros

cenários a partir de um existente.

RO 3.11.12 Básico O simulador deve permitir inicializar o caso base de treinamento a partir de dados telemedidos

oriundos do sistema principal, dados estimados ou de casos arquivados.

RO 3.11.13 Básico O simulador deve permitir começar, parar, suspender ou recomeçar uma sequência de

treinamento em qualquer período dentro de um cenário.

RO 3.11.14 Básico O simulador deve permitir alterar a velocidade de execução do cenário (acelerar ou desacelerar o

tempo).

RO 3.11.15 Básico O simulador deve gerar “Logs” e estatísticas de desempenho (sobrecarga, violação de tensão,

interrupção de carga) da sessão de treinamento para registrar todas as ações do instrutor e

treinandos.

RO 3.11.16 Modelagem O simulador deve responder aos comandos realizados pelos treinandos e revisar a topologia e

estados do sistema simulado.

RO 3.11.17 Modelagem O simulador deve prever a atuação do controle automático de tensão, o qual realiza comutação

automática em tapes de transformadores de subestações.

RO 3.11.18 Modelagem O simulador deve ser capaz de inserir faltas temporárias ou permanentes no cenário de

treinamento com atuação automática em disjuntores/religadores.

RO 3.11.19 Modelagem O simulador deve provocar sobrecargas em equipamentos; e se essas violações excederem um

tempo definido (configurável), deve ocorrer atuação automática em disjuntores/religadores.

RO 3.11.20 Modelagem O simulador deve ser capaz de inserir violações de limite tensão inferior/superior no sistema

simulado; se essas violações excederem um tempo configurável, deve ocorrer atuação

automática em disjuntores/religadores.

RO 3.11.21 Modelagem O simulador deve possibilitar a atuação do religamento automático dos equipamentos (RAs) e

disjuntores

RO 3.11.22 Modelagem Deve simular falha em UTR (unidade terminal remota) total ou parcial, assim ocasionando falha

na supervisão.

RO 3.11.23 Modelagem O simulador deve permitir mudança em cargas individuais em barra..

RO 3.11.24 Modelagem O simulador deve permitir mudança na carga de uma área (neste caso, o valor da carga deverá

ser distribuído pelas cargas individuais nas barras).

RO 3.11.25 Dimensionamento Devem ser previstas: 01 (uma) console para o instrutor responsável pela supervisão e controle

da sessão de treinamento; e 07 (sete) consoles para os treinandos (para todo o sistema ADMS).

3.12 Customização de Telas


customização

Atende COM

customização

RO 3.12.01 Customização de telas Permitir customização de telas para o usuário

4. OMS

4.01 Requisitos Gerais e Cálculos de Indicadores


customização

Atende COM

customização

RO 4.01.01 Geral Deve realizar os cálculos dos indicadores de continuidade em conformidade com as regras do

Setor Elétrico vigentes.

RO 4.01.02 Flexibilidade de cálculo

de indicadores

Permitir a alteração do método de cálculo de indicadores de qualidade (DEC, FEC, DIC, FIC,

DMIC e DICRI), sempre obedecendo às regras do Setor Elétrico vigentes, sem ônus ao

contratante.

RO 4.01.03 Visualização, Registros

e Cálculos de

Interrupções

Monofásicas nas redes

de Baixa Tensão e

Média Tensão 13,8 e

34,5kV

O OMS e o OMS Móvel deverão possuir as opção de diagramas de redes Unifilares e Trifilares

na Média e Baixa na Tensão, desde a Subestação até a Medição do Consumidor, com a

possibilidade de escolha de visualização (Unifilar ou Trifilar) conforme desejo do usuário. Desta

forma, o OMS deverá possibilitar o registro das faltas nas redes de Baixa e Média Tensão de

acordo com a falta ocorrida na rede física, onde as interrupções mono, bi e trifásicas sejam

registradas e calculadas somente para os consumidores que realmente ficarão sem energia ou

com o nível de tensão comprometido.

RO 4.01.04 Registro Deve possuir algorítmo para caracterizar as interrupções em determinados períodos como por

exemplo Dia Crítico, ISE, referente a necessidade de expurgo dos indicadores ANEEL, conforme

regras do Setor Elétrico vigentes.

Pg. 27 de 43


RO 4.01.05 Registro Deve manter a quantidade real de consumidores afetados por interrupção, conforme regras do

Setor Elétrico vigentes, disponibilizando estas informações a outros sistemas da COPEL (IQS),

inclusive para o devido cálculo de indicadores individuais.

4.02 Registro de Serviços


customização

Atende COM

customização

RO 4.02.01 Geral A COPEL possui o sistema CIS onde são registradas as NRT's, compreendendo as reclamações

(originadas da Internet, COPEL Mobile, SMS, URA, Call-center, IoT, etc). Cada reclamação, que

ainda não possua evento associado, deve gerar um novo serviço para atendimento. A

reclamação será caracterizada conforme caracterização originada pelo CIS.

RO 4.02.02 Geral Deve disponibilizar ao CIS, informações das interrupções em andamento e concluídas de cada

UC afetada, para subsídio/histórico de informação pelo Call-center aos reclamantes.

RO 4.02.03 Dados da UC Os dados da reclamação da UC devem ser replicados no OMS permitindo a consulta

parametrizada. Dados necessários: EUSD, Nome, Endereço, Posto Transformador, Classe e

Sub-classe, identificação para contato telefone, potência do disjuntor, fase conectada, etc.

RO 4.02.04 Geral O ADMS deve permitir que o usuário do OMS, possa registrar um serviço com campos

necessários e similar aos advindos do CIS.

RO 4.02.05 Geral O ADMS deve permitir, automaticamente o registro de reclamação por falta de luz, ou falta de

fase originado por equipamentos de Telemedição. Este, deve possuir parametrização de grupos,

classes de UC's que possuiram o registro automático, e também o período mínimo para

percepção de interrupção duradoura e o registro deste.

RO 4.02.06 Geral No CIS, é permitido o registro de uma NRT sem vínculo, para os casos de acidente com a rede

de energia por exemplo, onde o informante não possui a identificação de UC. Desta forma,

baseando-se nas informações coletadas pelo atendente com referência ao logradouro

(endereço), o OMS deve registrar um serviço, indicando o possível ponto elétrico para que o

operador confirme a referência elétrica destinando-o para atendimento quando ainda não houver

conhecimento do caso, ou associe-o ao um caso (evento/ocorrência) já de conhecimento.

RO 4.02.07 Geral Deve permitir gerar serviço para uma reclamação específica que esteja agrupada em uma

ocorrência com outro serviço já em andamento, para atendimento distinto, podendo-se ou não

associar também a mesma ocorrência.

RO 4.02.08 Geral Deve gerar serviços automaticamente, conforme plano de recomposição. Nestes serviços estará

indicado o ponto ou equipamento estratégico para inicio das ações de recomposição pela equipe

de campo. Estes serviços serão designados a equipes através do modulo “Otimizador”

RO 4.02.09 Geral Deve permitir o tratamento de serviços emergenciais/comerciais/manutenção e ter a capacidade

de registrar no mínimo as seguintes informações das reclamações de consumidores: número da

UC ou do equipamento, nome do consumidor, endereço, telefone cadastrado, telefone do

solicitante, transformador que atende a UC, defeito informado pelo consumidor, tipo de

consumidor, prioridade, horário de início da interrupção e observações.

RO 4.02.10 Geral Deve suportar o recebimento em massa de grandes quantidades de reclamações e o

processamento ágil de tais informações, garantindo funcionamento eficiente da solução mesmo

em períodos de alta demanda, por exemplo durante contingências severas.

RO 4.02.11 Geral Deve permitir a criação de serviço para um consumidor a partir de uma pesquisa por nome do

consumidor, endereço e/ou telefone, ou fornecendo uma localização selecionada diretamente no

mapa.

RO 4.02.12 Geral Deve permitir a criação de serviço com localização fornecida como endereço, cruzamento de

ruas, coordenadas, PS (ponto significativo), pontos de interesse e equipamento elétrico.

RO 4.02.13 Geral Deve permitir a criação de serviços para equipe de campo inspecionar um alimentador, chave ou

transformador a partir da seleção do equipamento no mapa (serviço de manobras).

RO 4.02.14 Geral Deve permitir a criação de “serviço de manobra retroativo”, com o campo de horário de

solicitação editável.

RO 4.02.15 Geral Deve permitir a criação de serviços diretamente da interface Ordens de Manobra.

RO 4.02.16 Geral Deve permitir a criação de serviços para reclamações de consumidores para situações

emergenciais, que podem ou não resultar em interrupções no sistema, (ex. Oscilação,

faiscamento na rede, Iluminação pública, cabo baixo de telefonia, etc).

RO 4.02.17 Geral Deve permitir a classificação de serviços com prioridades diferenciadas utilizadas em situações

de risco (por exemplo cabo rompido, poste abalroado, etc).

RO 4.02.18 Geral Deve permitir a classificação de serviços com prioridades diferenciadas por classe e subclasse

de consumidor, por exemplo cliente VIP (podendo o cadastro deste tipo de consumidor ser

realizada diretamente no ADMS).

RO 4.02.19 Geral O registro de serviço deve possuir uma indicação visual diferenciada em casos de situações de

risco, quando for do tipo “Urgente” ou “VIP”.

RO 4.02.20 Geral Deverá enviar automaticamente para dentro da ocorrência um serviço duplicado, por exemplo

quando dois consumidores reportam um mesmo incidente na rede, fazendo com que apenas um

dos serviços permaneça aberto.

RO 4.02.21 Registro de NDS pelo

operador

Deve permitir que o operador crie um documento chamado “nota de serviço” (NDS), que possa

ser vinculada ao serviço.

RO 4.02.22 Informações

complementares no

serviço

Os documentos serviço, interrupção e ocorrência, devem possuir um campo específico com a

finalidade de complemento de informações a qualquer momento, pelo operador, até que o

documento seja oficializado pelo processo mensal dos índicadores (ANEEL). Este campo poderá

ser consultado em qualquer nível destes documentos, agrupando-os todos no nível maior

(ocorrência).

RO 4.02.23 Consulta serviços Deve permitir a consulta organizada de todas as mensagens pertinentes ao serviço, como

mensagens entre equipes e operadores, envio de macros pelas equipes, informações adicionais

ao serviço, etc.

Pg. 28 de 43


RO 4.02.24 Consulta serviços Deve permitir busca de serviços através de critérios definidos pelo usuário, tais como tipo de

serviço, área ou região, alimentador, localidade, período, etc.

RO 4.02.25 Consulta serviços Deve permitir a exibição dos dados detalhados de um serviço com possibilidade de observar

toda a sequência de alterações em seus dados desde sua criação, com os seguintes logs: Log

de alteração de estado (enviado, reconhecido, etc), Log de reordenação (otimização) e log de

realocação (funcionalidade do TCS) de UC para equipamento.

RO 4.02.26 Consulta serviços Deverá permitir consulta de serviços pendentes próximos a uma equipe com a informação da

distância entre eles.

RO 4.02.27 Alterações em serviços Deve permitir a alteração dos dados de um serviço, e manter um registro (log) de alterações com

a identificação do responsável.

RO 4.02.28 Alterações em serviços Deve permitir ao operador o cancelamento de serviços, ou um grupo de serviços com ou sem

interrupção, cancelando automaticamente ocorrência associada caso não haja outras

reclamações ou serviços associados.

RO 4.02.29 Alterações em serviços Deve permitir ao operador colocar um serviço em espera (Aguardando equipe).

RO 4.02.30 Alterações em serviços Deve permitir ao operador encerrar um serviço, mesmo que ele não tenha sido despachado para

uma equipe de campo.

RO 4.02.31 Alterações em serviços Deve permitir ao operador transferir um serviço para uma área ou região de atendimento

diferente da que foi atribuída automaticamente pelo sistema.

RO 4.02.32 Atualização de status Deve permitir que o operador atualize, insira ou corrija horários de status e quilometragem de

uma equipe no atendimento a um serviço.

RO 4.02.33 Tela de gerenciamento Deverá possuir tela de gerenciamento de serviços com todos estados possíveis de serviços: Em

análise, aguardando distribuição, enviado, reconhecido, equipe em curso, em execução,

deslocamento final, aguardando equipe, aguardando cancelamento, reenvio, aguardando

verificação, pendente inclusão, etc.

RO 4.02.34 Tela de gerenciamento O OMS deve apresentar tela com filtros, frames de abas diferentes, alarmes visuais e audíveis

configuráveis, e demais destaques afim de indicar ao usuário operador a priorização de análise

para providências de atendimento ao serviço. As priorizações serão conforme tipo de risco (cabo

rompido, poste abalrroado, acidente com terceiros, etc, conforme parâmetros do CIS) ou de

importância da UC reclamante (VIP's), ou com indicativo de possível falta de luz. Tipo RISCO ou

VIP diferentes destaques.

RO 4.02.35 Tela de gerenciamento Deve mostrar todas as equipes disponíveis cadastradas e todos os estados disponíveis das

equipes: Fora de serviço, disponível, associada, em curso, em serviço, em manobra,

indisponível, habilitada, etc.

RO 4.02.36 Tela de gerenciamento Deve mostrar a quantidade de serviços emergenciais/comerciais por equipe, a quantidade de

serviços urgentes, VIPS, com informações significativas, etc.

RO 4.02.37 Tela de gerenciamento Deve possuir filtro para visualizar serviços alocados em UC, alocados em transformador ou

alocados em chave (ou equipamentos).

RO 4.02.38 Tela de gerenciamento Deve possuir colunas com todas as informações possíveis do serviço: Número do serviço, região

de serviço, localidade, data e hora da solicitação, numero de consumidores cadastrados, número

de consumidores reclamantes, equipamento/UC, defeito, endereço, alimentador, agência

responsável, valor previsto de multas, distância, tempo de atendimento, etc.

RO 4.02.39 Tela de gerenciamento Deve ter capacidade de designar os serviços para o equipamento móvel das equipes de campo,

através de simples arraste do serviço até o ícone da equipe desejada no ambiente gráfico (visão

ortogonal).

4.02.01 Gerenciamento de Informações de Unidades Consumidoras


customização

Atende COM

customização

RO 4.02.40 Geral Deve manter atualizado um banco de dados, contendo dados das UC's necessário aos requisitos

de funcionalidades do OMS, que será integrado ao sistema CIS, utilizando na COPEL como

CRM.

RO 4.02.41 Geral Deve manter segurança das informações, conforme critérios de restrições utilizadas pela

COPEL.

RO 4.02.42 Geral Deve possuir consulta tabular, das UC's por vários parâmetros usuais de interesse às

funcionalidades do OMS.

RO 4.02.43 Geral Deve listar as últimas reclamações da UC, como também últimos serviços comerciais realizados

nesta, quando consultado. O período desta visualização deve possuir parametrização pelo

administrador.

4.03 Gestão das Interrupções


customização

Atende COM

customização

RO 4.03.01 Geral O OMS deve possuir um gerenciamento das interrupções e seus estados, organizando-as e

associando-as em Ocorrências, onde esta possuirá vínculos a demais registros e tipos de

documentos (serviços, alteração nos estados dos equipamentos, NDS, reclamações).

RO 4.03.02 Registro O registro de interrupção deve possuir campos caracterizando-a para posterior consulta e

relatórios. Exemplo dos campos: Horários Início, término e previsão, quantidade de

consumidores afetados, somatório do kva instalado, produto consumidor hora (CHI), grupo

componente, componente, causa, ps do defeito/falha quando localizado, tipo, área elétrica, área

específica, condição climática, fases atuadas, equipamento, total EUSD, histórico de alteração

do documento, etc. (demais requisitos ANEEL).

RO 4.03.03 Registro Deve permitir o registro de interrupções sequenciais originadas ao encerrar uma interrupção de

nível origem. Sugere-se adotar o conceito já utilizado na COPEL de Interrupção ORIGEM e

PARCIAL, atribuindo o horário inicial da interrupção PARCIAL, igual ao término da interrupção

ORIGEM. Todas devem listar as UC's afetadas. Este conceito deve ser aplicado para as

Interrupções Confirmadas e Possíveis.

Pg. 29 de 43


RO 4.03.04 Registro Deve permitir o registro de interrupções CASCATAS originadas ao registrar uma interrupção de

nível FONTE. Sugere-se adotar o conceito já utilizado na COPEL de Interrupção FONTE e

CASCATA. Exemplo: Quando desliga um disjuntor geral de barra de uma subestação, considera-

se este equipamento como originador da interrupção FONTE, e as interrupções CASCATA, dos

religadores conectados as barras. Este conceito também é utilizado para um alimentador fonte de

demais subestações alimentadas em média tensão, possuindo religadores em suas barras, que

também contabilizarão interrupções CASCATA.

RO 4.03.05 Registro Deve permitir que o operador realize alterações em interrupções de uma ocorrência, sem que

interfira em demais documentos, a não ser que possuam critério de campos herdados (exemplo:

Horário término de uma interrupção igual ao horário inicial de outra interrupção).

RO 4.03.06 Registro Conforme ocorrer o energizamento parcial de trechos e (ou) alimentadores, o OMS deve

considerar novas interrupções (PARCIAL) contabilizando as UC's que restaram desligadas.

RO 4.03.07 Registro Deve permitir a correção de horário da interrupções (inclusive as de FM que devem poder ser

transformadas em duradouras), assim como demais campos da interrupção. Deve permitir ainda

alterar o equipamento originador da interrupção, com consequente correção das UC's afetadas

por esta.

RO 4.03.08 Registro Deve manter histórico das interrupções e faltas de fase associados as UC's que possuem

Telemedição, por período pré-determinado pelo administradores do OMS. Este histórico deve

possuir filtros de consulta, por UC's, Alimentador, Região, Área de controle, etc.

RO 4.03.09 Registro Deve consistir e impedir o encerramento da ocorrência pelo usuário, quando possuir documentos

pendentes de atendimento, assim como trechos e ou UC's ainda desenergizadas (interrupções

abertas). Gerar alertas conforme necessidade da pendência.

RO 4.03.10 Registro Os documentos não poderão ser encerrados, até atender requisitos especificados/configurados

pelos administradores do OMS. Enquanto não encerrado, deve ser apresentado em uma lista de

pendência e suas necessidades de correção/confirmação, liberando-os para oficialização.

RO 4.03.11 Registro O campo para registro dos horários das interrupções deve permitir o cadastro da data, hora,

minuto e segundo das mesmas.

RO 4.03.12 Registro O período de FM (2m59s), deve permitir configuração.

RO 4.03.13 Registro Todas FM's de equipamentos automatizados devem ser registradas automaticamente pelo

ADMS (conforme critérios estabelecidos no sistema SCADA), permitindo ao usuário bloquear tal

processo tornado-o manual (quando consultado este registro, deve apresentar a lista de UC's

afetadas).

RO 4.03.14 Registro As FM's (até 2m59s), devem ser registradas como interrupção, porém não devendo considerar

para o algorítmo do TCS.

RO 4.03.15 Iteração DMS Caso ocorram 3 FM's em um período de 1 minuto, e permaneça o equipamento originador desta

como “aberto” no final do ciclo, deve-se registrar as FM's, inclusive a interrupção que

permaneceu aberta, na mesma ocorrência, considerando esta então para o algorítimo TCS.

RO 4.03.16 Registro O OMS deve registrar uma interrupção originada por atuação de equipamento tanto

automaticamente (origem SCADA), quanto manualmente pelo operador, neste caso, exigindo

preenchimento de alguns campos básicos (minimamente data de atuação, horário, motivo da

atuação, tipo da interrupção, campo para observação, localidade e área específica), impedindo a

atuação e o registro, caso não sejam informados.

RO 4.03.17 Registro Após ponto de interrupção confirmada no local, por equipe de campo, quando do atendimento a

serviço emergencial, deve possibilitar registrar a interrupção possível como confirmada. Este

registro será originado por OMS Móvel ou manualmente pelo operador.

RO 4.03.18 Registro Deverá permitir a atuação de equipamentos, sem gerar registro de interrupções, quando for o

caso de atualização de estado de equipamentos que estejam diferente do OMS, e que não

ocasionaram interrupções ou perturbações (trecho desenergizado sem interrupção).

RO 4.03.19 Registro Monofásico Deve permitir o cadastro de eventos monofásicos em equipamentos trifásicos, aplicando as

interrupções de energia somente aos clientes ligados na referida fase em falta.

RO 4.03.20 Iteração DMS Quando o ADMS reportar atuação de equipamentos, o operador confirmará a atuação deste

equipamento com o consequente registro automático da interrupção e seu devido estado.

RO 4.03.21 Cadastro Alimentadores O OMS deve atualizar as alterações dos alimentadores realizadas no sistema GEO, desde que

não afete eventos/ocorrências que estejam associadas a este alimentador. Caso necessário, um

administrador do OMS deverá analisar e regularizar as pendências do alimentador, permitindo a

atualização total do mesmo. Os equipamentos que não estiverem em seu estado normal,

deverão ser mantidos como estavam após a conclusão de atualização do alimentador.

RO 4.03.22 Representação Deve apresentar graficamente o possível equipamento ou fase aberta, assim como as

reclamações, posicionadas geograficamente no diagrama unifilar e(ou) trifilar. Após a

confirmação de interrupção aberta, a representação deve ser alterada.

RO 4.03.23 Representação Associado ao documento de interrupção, deve apresentar lista de todas UC's afetadas, inclusive

classificação e filtro para UC's do tipo VIP, Geração Própria, Sobrevida. Deverá permitir

posicionametro geográfico de uma ou mais UC's selecionadas na lista citada.

RO 4.03.24 Representação Associado ao documento de interrupção, deve apresentar lista de todas reclamações, inclusive

classificação e filtro das reclamações do tipo URGENTE com informação de risco de acidente.

Deverá permitir posicionametro geográfico de uma ou mais UC's selecionadas na lista citada.

Pg. 30 de 43


RO 4.03.25 Representação Deve permitir classificação das interrupções do tipo aberta, ordenando-se não somente pela

quantidade de UC's afetadas, como também pela carga e tipo de UC's (Sobrevida, VIP, Geração

Própria, etc), e tipos (ACIDENTAL, VOLUNTARIA e PROGRAMADA). O peso e priorização

destes parâmetros deve ser reconfigurada manualmente em tempo real.

RO 4.03.26 Representação Deve exibir graficamente os tipos de interrupções (ACIDENTAL, VOLUNTARIA e

PROGRAMADA), possibilitando habilitação/desabilitação destas simbologias e (ou) camadas.

Através desta funcionalidade, deve permitir transição direta ao modo simulador de manobras do

DMS.

RO 4.03.27 Representação Deverá haver representação da rede que possuem trechos desenergizados, mas não

gerenciáveis, não devendo ser considerados para registro de interrupção. Através desta

funcionalidade, deve permitir transição direta ao modo simulador de manobras do DMS.

RO 4.03.28 Representação Deve apresentar um diagrama esquemático (simplificado), contendo possibilidade de exibição de

determinadas informações/camadas de simbologia (quantidade de UC's afetadas, equipamentos

seccionadores dos trechos, níveis de rede tronco, etc).

RO 4.03.29 Representação Deve possuir impedir ou restringir a operação de equipamentos, mantendo-se observação textual

associada, e histórico destas. Quando da retrição, não impedirá atuação do equipamento

(mudança de estado), mantendo-se a observação de restrição. A restrição e impedimento, deve

ser associada ao histórico do equipamento, condicionalmente havendo relação com determinado

serviço, interrupção ou ocorrência, por decisão do operador.

RO 4.03.30 Monitoramento Lista de

Recomposições

Deve apresentar tela com informações tabuladas, de todas recomposições em andamento

(Interrupções Abertas), considerando o agrupamento por ocorrência e seus tipos (Recomposição

de Alimentador, SE, RA de trecho, Chaves Fusíveis, Manobra Voluntária, etc). Esta tela deve

permitir classificações e filtros referente as características dos registros (Operador responsável,

Tipo da Interrupção, Quantidade UC's afetadas, situação da recomposição, alimentador, tipo

equipamento principal aberto, região, somatória EUSD, total Kva, DMIC, etc). Deve possibilitar

atualização temporizada considerando as alterações do estado de equipamentos manobras,

estado das equipes.

RO 4.03.31 Monitoramento

Recomposições

Geográfico

Deve apresentar painel gráfico (mapa de calor) e geográfico das interruções, baseando-se nos

parâmetros de número de consumidores afetados, quantidade reclamações, etc.

RO 4.03.32 Plano Recomposição Deve possuir algorítmo que resulte a sequência de equipamentos para manobra de

recomposição trecho a trecho, incluíndo o direcionamento e melhor trajeto para as equipes.

RO 4.03.33 Recomposição A Recomposição deve ser visualizada, migrando-se da própria ocorrência originada pela

interrupção. Esta deve possuir gráfico de linha do tempo das equipes em andamento para suas

ações, quantidade de UC's afetadas, acesso ao diagrama esquemático do trecho em

recomposição, informações de alarmes do DMS que sejam necessárias para apoio na

identificação do ponto de falha (Exemplo: Distância da falta, proteções atuadas).

RO 4.03.34 Recomposição Deve possuir alarme indicando ao operador, quando equipe chegou ao ponto de destino para

execução das ações de recomposição.

RO 4.03.35 Pendências Tempo Real Deve possuir um relatório de turno, onde será tramitado a comunicação e conhecimento das

alterações e pendências dos sistema, as que os operadores em revezamento, necessitam tomar

conhecimento e (ou) providências. Cada pendência, possuirá um workflow de certificação de

reconhecimento pelo operador. Pendências exemplo (sistemas com a configuração alteradas,

equipamentos indisponíveis, subestações com restrições, eventos públicos em determinadas

regiões onde necessita atenção, sistemas com restrições, etc.)

RO 4.03.36 Registro Baixa Tensão Deve permitir conectar o trecho de rede de baixa tensão alimentada por um transformador a

outro trecho com alimentação por outro transformador. Objetivo exemplo: Manter aberto um

transformador de baixa tensão com impedimento, transferindo sua carga para outro

transformador com potência disponível.

RO 4.03.37 Registro parcial Baixa

Tensão

Deve permitir seccionar um corte em ponto indicado pelo usuário operador, afim de registrar-se

interrupção parcial em transformadores de baixa tensão afetando somente as UC's do trecho

desenergizado.

RO 4.03.38 Registro Baixa Tensão Deve permitir seccionar um determinado ponto e conectar o trecho de rede de baixa tensão a

outro ponto, transferindo assim a alimentação a outro transformador.

4.04 Trouble Call


customização

Atende COM

customização

RO 4.04.01 Geral Deve utilizar as informações das reclamações originadas do CIS ou de outros sistemas

apresentados no item de integração.

RO 4.04.02 Geral Deve representar as reclamações organizando-as automaticamente e as associando com

interrupções possíveis ou já confirmadas, direcionando-as ou não para até uma possível

intervenção do operador através do DMS, ou ainda alocação de equipe para atendimento no

local.

RO 4.04.03 TCS Proposta Algorítmo O Fornecedor deve apresentar uma ou mais proposta(s) de algoritmo e seus parâmetros para

função TCS.

RO 4.04.04 TCS Algorítmo Deve possibilitar alteração dos parâmetros, ou até adaptabilidade automática conforme situação

de contingência e permissão dos administradores.

RO 4.04.05 TCS Algorítmo Deve agrupar reclamações a interrupções no estado confirmada, sendo estas do tipo

ACIDENTAL, VOLUNTARIA e PROGRAMADA.

RO 4.04.06 TCS Algorítmo Sugere-se utilizar como parâmetros do algorítimo TCS: Período e frequência das reclamações

para tomada de decisão deste, quantidade de reclamações, quantidade de reclamações por

trechos elétricos trechos são delimitados eletricamente por equipamentos de seccionamento).

Pg. 31 de 43


RO 4.04.07 TCS Algorítmo Deve separar reclamação isolada a um período anterior, não agrupando a um novo caso de

análise do TCS. Exemplo: Quando o horário de solicitação da 2ª reclamação for muito tempo

(período de 1 hora para reclamações surgidas no período das 00h00 as 06h00) depois da 1ª

reclamação, considerar 2 casos (serviços/interrupção) distintos.

RO 4.04.08 TCS Algorítmo A parametrização do TCS deve ser permitida, sem necessidade de parada do OMS.

RO 4.04.09 TCS Algorítmo Deve possuir o algoritmo de organização e direcionamento das reclamações, originando novos

serviços, indicando possíveis equipamentos na rede de média tensão, que podem estar abertos

da forma mais assertivo possível.

RO 4.04.10 TCS Algorítmo Deve agrupar as reclamações cuja caracterização corresponde a uma interrupção confirmada ao

mesmo evento/ocorrência.

RO 4.04.11 TCS Algorítmo Deve prever a condição conforme parametrização por administradores do sistema, de incluir

reclamação originada por Telemedição, como variável de decisão do TCS.

RO 4.04.12 TCS Algorítmo Todas reclamações geradas posterior ao período de uma interrupção confirmada, ou até

encerrada, deverão ser tratadas como “atendidas”, se corresponderem a um determinado

período (configurável).

RO 4.04.13 TCS Algorítmo Quando ocorrer uma reclamação em situação de Risco de Acidente, que esteja contemplada a

um trecho com interrupção “Aberta” do tipo PROGRAMADA, deve-se gerar um serviço para

verificação no local por uma equipe de campo, impedindo o equipamento com previsão de

fechamento.

RO 4.04.14 TCS Algorítmo Deve prever parâmetro configurável referente ao período do tempo de retenção das

reclamações, aguardando para o processamento destas no TCS.

RO 4.04.15 TCS Algorítmo Deve permitir que o operador bloqueie/desbloqueie determinada alocação pelo TCS, afim de que

esta não evolua para alocação de um equipamento a montante.

RO 4.04.16 TCS Intervenção Deve permitir manualmente pelo operador ou originado por mensagem do OMS Móvel, a

alteração de indicação de atuação de um equipamento (realocação) para outro a jusante, ou a

montante, alterando-se o agrupamento das reclamações, e processando novamente o algorítimo

TCS para as demais UC's reclamantes, gerando um novo agrupamento se houver.

RO 4.04.17 TCS Tratamento

Individual/parcial

O TCS deve enviar mensagem adicional a equipe de campo (através do OMS Móvel), prevendo-

se a possibilidade de interrupções parciais/individual (realocação de equipamento durante o

atendimento pela equipe) referente ao serviço que está em atendimento por esta equipe.

Conforme parametrização a ser realizada, pode-se consistir pelo operador a realocação indicada

pela equipe de campo.

RO 4.04.18 TCS UC Telemedição Deve considerar o retorno de tensão da telemedição, como condição para novo processamento

do TCS, como o objetivo de reavaliar a indicação de possível equipamento aberto.

RO 4.04.19 Agrupamento As reclamações devem ser analisadas logicamente, agrupando-as ao documento ocorrência,

quando pertencerem ao mesmo evento de interrupção que também estará associada a esta.

Estas reclamações possuem uma identificação única, originada pelo CIS (SS do tipo NRT).

RO 4.04.20 Manter Reclamações O TCS deve manter o histórico das reclamações, incluindo suas associações aos demais

documentos (ocorrência, serviço, histórico da UC, etc) que comprovem o vínculo de atendimento

ou não. Este histórico deve ser consultado por tela contendo com filtros (Identificação da UC,

Alimentador, Posto Transformador, etc). Deve possuir rastreabilidade e possibilidade de

posicionamento no mapa.

RO 4.04.21 Tratamento

Reclamações

Deve analisar o registro de reclamações da mesma UC, caracterizando-a conforme necessidade

de priorização e desassociação da ocorrência. Por exemplo, caso a UC reclame novamente,

informando riscos de acidente, ou chave aberta na propriedade. Obs. nas reclamações

originadas pelo CIS, possuem campo específico para caracterização da urgência (Poste

quebrado, cabo rompido, chave aberta no local).

RO 4.04.22 Priorização Atendimento Deve associar e apresentar possibilidade de restrição em recomposição de sistema em

andamento, que podem estar associados a reclamação do tipo “Risco de Acidente” afim de evitar

energizamento indevido (risco de acidente).

RO 4.04.23 Priorização Atendimento Todas reclamações em atendimento, devem ser apresentadas em uma única tela, aceitando-se

agrupamentos por serviço conforme lógica de Trouble-call executada.

RO 4.04.24 Priorização Atendimento Quando houver um agrupamento de reclamações, com serviço indicando uma possível

interrupção e surgir uma reclamação de prioridade VIP ou Risco de Acidente, este agrupamento,

deve indicar a prioridade de atendimento elevada e o motivo, justificando-se a própria

reclamação.

RO 4.04.25 Parametrização Lógica

Agrupamentos

O TCS deve possuir configuração e parametrização do tipo de lógica utilizada conforme decisão

do Administrador, por exemplo, em período de contingência.

RO 4.04.26 Histórico Função TCS Deve possuir histórico das indicações de possíveis atuações de equipamentos realizadas pelo

TCS (alocação das interrupções).

4.05 Call Back


customização

Atende COM

customização

RO 4.05.01 Call Back – Geral A função Callback deve permitir o retorno das chamadas de forma automática ou programada

para as UC's solicitantes. Para o cliente, a funcionalidade deve permitir o retorno de informações

sobre o reestabelecimento da energia através de SMS ou realimentação da URA. Para o

operador do COD, deve dispor meios de confirmar se a restauração da interrupção foi bem

sucedida.

RO 4.05.02 Call Back – Geral Deve informar visualmente ao usuário o resultado do Callback e cancelar automaticamente a

solicitação caso a resposta da UC solicitante for positiva para o reestabelecimento da energia.

Pg. 32 de 43


RO 4.05.03 Call Back –

Configurações

Deve ser totalmente configurável, levando em conta no mínimo os seguintes critérios:

- horário permitido para o Callback aos clientes, ex: das 07h00 às 23h00.

- seleção de modos de retorno. Modo automático exige retorno a todas as UC's solicitantes de

uma interrupção após um tempo configurável. Modo manual, exige o retorno de um grupo

selecionável de UC's solicitantes

- perfis de Callback de acordo com tipo de consumidor: Normal, VIP, etc, com a opção de

envio de texto padrão ou livre, podendo ser configuradas de maneira diferente por hora do dia,

dias da semana, etc.

- capacidade de habilitar/desabilitar o envio de Callback as UC's que eventualmente optarem

pelo não recebimento de SMS.

RO 4.05.04 Call Back – URA Deve permitir o envio automático de informações sobre eventos à URA, para a realização de

Callback aos consumidores.

RO 4.05.05 Call Back – MDM A funcionalidade deve permitir o envio de “ping” aos medidores de uma UC ou grupos de UC's

como transformador ou chave, através do MDM para as UC's que possuam medidores

inteligentes, com o objetivo de confirmar o retorno da energia.

RO 4.05.06 Call Back – MDM Deve permitir a configuração do tempo para a resposta do ping e registrar a quantidade e

resultados de todos os eventos, sendo eles bem ou mal sucedidos.

4.06 Gerenciamento de Equipes


customização

Atende COM

customização

RO 4.06.01 Geral A Copel desenvolveu um sistema para o despacho otimizado de serviços emergenciais,

comerciais, escalas de serviço e sobreaviso chamado Otimizador. O sistema OMS deverá ser

integrado com o Otimizador já existente de maneira a manter as suas funcionalidades

compatíveis e integrar novas funcionalidades. A especificação dessas novas funcionalidades

está descrita no capítulo "Otimização e acompanhamento em tempo real", do ANEXO X – Lista

de Requisitos Funcionais Não Obrigatórios(Desejáveis).

RO 4.06.02 Geral Deve permitir verificação da tarefa atual e das tarefas planejadas para a equipe durante o seu

turno.

4.06.01 Acompanhamento em tempo real


customização

Atende COM

customização

RO 4.06.03 Sistema – Gráficos Permitir a exibição de painéis (dashboards) com gráficos de indicadores e estatísticas como:

barras, linha, pizza e gauge.

RO 4.06.04 Sistema – Perfis Deve permitir a configuração de todas as telas, possibilitando a criação de perfis de visualização

conforme o tipo de atividade em execução.

RO 4.06.05 Serviços - Consulta Permitir o acesso a grandes lotes de serviços e contabilizar de maneira imediata o quantitativo de

serviços.

RO 4.06.06 Serviços – Visualização Possibilidade de visualizar gráficamente a demanda total de serviços com opções de filtro por

tipos de serviço e prazos.

RO 4.06.07 Serviços – Visualização Possibilidade de visualizar no mapa os serviços no mapa com informações detalhadas.

RO 4.06.08 Serviços – Notificações Deve notificar atraves de alertas visuais e sonoros o usuario da existencia de novos serviços de

emergencia.

RO 4.06.09 Emergencia –

Visualização

Permitir a visualização em modo lista de todas as emergencias e suas informações

complementares

RO 4.06.10 Emergencia –

Visualização

Permitir a visualização gráfica de todas as emergencias com todo seu detalhamento.

RO 4.06.11 Emergencia – Gráfico Gráfico histórico de quantidade de emergencias

RO 4.06.12 Emergencia – Mapa Mapas geografico das emergencias

RO 4.06.13 Emergencia – Operação Possibilidde de visualizar a rede elétrica no mapa com as interrupções

4.07 Notas de Serviço (NDS)


customização

Atende COM

customização

RO 4.07.01 Geral Notas de Serviços (NDS) são as atividades que ficaram para serem resolvidas por equipes de

manutenção e/ou equipes preparadas (equipadas) para resolver o problema que ficou pendente

do primeiro atendimento e não pode ser feita pela equipe de emergência. Geralmente são

manutenções de grande porte (podas de árvores, restauração de cabos, substituição de postes,

etc).

RO 4.07.02 Inclusão Registro Deve permitir inclusão de documento, associado ou não a Interrupções e Serviços, contendo

campos informando as necessidades de reparos na rede MT ou BT, com possibilidade de anexar

fotos e arquivos, indicando as referências (PS) do trecho do defeito/falha.

RO 4.07.03 Pendências Deverá apresentar listas (relatórios) de Pendencias e estes deverão estar acessível para todos

com perfil definido, sendo que estes usuários poderão encerrar os serviços pendentes.

RO 4.07.04 Integração Deve possuir integração com sistema SAP de forma a garantir o controle dos documentos

gerados no OMS.

RO 4.07.05 Documento O OMS deverá enviar automaticamente este documento para o devido tratamento via SAP e

receber atualizações/notificações de encerramento das pendências.

4.08 Processo de Pré Operação


customização

Atende COM

customização

RO 4.08.01 Geral Deve possuir funcionalidades para gestão de desligamentos programados no sistema.

4.08.01 Pedidos de Intervenções Programadas


customização

Atende COM

customização

Pg. 33 de 43


RO 4.08.02 Geral O sistema deverá possuir um módulo de solicitação/ inclusão de: Pedidos de Análise de

Desligamentos, Pedidos de Desligamentos de Redes MT/BT e Subestações; Pedidos de

Manobras de Redes MT e Subestações; Pedidos de Desligamento de Consumidor Individual MT

(DES); e Pedidos de Intervenção na Rede MT com LV (sem interrupção).

RO 4.08.03 Acesso O sistema deverá possuir uma interface em ambiente web para emissão/registro prévio de PDE,

podendo ser posteriormente complementado e enviado para aprovação pela área responsável no

próprio OMS, e via estação de trabalho para inclusão total e complementação dos pedidos. Os

usuários deverão possuir acesso através de perfil preestabelecido, de acordo com as funções/

atividades desenvolvidas.

RO 4.08.04 Campos dos Pedidos O sistema deverá conter informações de campos de preenchimento opcional e obrigatórios, e

permitir incluir, alterar, excluir ou validar, conforme necessidade de informações dos pedidos e de

acordo com o perfil pré-estabelecidos dos usuários.

RO 4.08.05 Emissão O sistema deverá permitir incluir, alterar e validar pedidos. Deverá conter campos com dados

georeferenciados da rede MT/BT, visando simular o trecho a ser desligado e subsidiar o

solicitante na análise, estudos e agendamento em função dos parâmetros definidos pela

programação. Deverá conter um menu de ajuda, com as informações e orientações no correto

preenchimento do pedido e orientações a definir.

RO 4.08.06 Simulação de Pedidos O sistema deverá conter uma ferramenta de pré-análise e classificação dos pedidos, em função

de parâmetros e critérios a serem definidos, tais como: complexidade (simplificado, convencional

e complexo por exemplo), DEC, prazo, tipo de consumidores afetados e outros parâmetros a

definir. Deverão ficar armazenadas as informações de trecho a ser desligado, com representação

gráfica no Módulo Simulador, visando a análise por parte do solicitante ou programador, para

definição sobre os aproveitamentos ou agrupamentos de pedidos em uma mesma manobra.

RO 4.08.07 Simulação de Pedidos O sistema deverá manter armazenadas as informações de trecho a ser desligado, com

representação gráfica no Módulo Simulador, visando a análise por parte do solicitante ou

programador, para definição sobre os aproveitamentos ou agrupamentos de pedidos em uma

mesma manobra.

RO 4.08.08 Apresentação de

Pedidos

O sistema deverá conter um tela de apresentação dos pedidos emitidos por estados, com

configuração de filtros conforme necessidade dos usuários e parâmetros preestabelecidos

(região, complexidade, data/ período, etc).

RO 4.08.09 Tramitação de Registros O sistema deverá permitir a tramitação dos registros, de acordo com os estados

preestabelecidos e perfil dos usuários, permitindo ao solicitante e programador, emitir parecer e

solicitar informações adicionais em campo específico.

RO 4.08.10 Alteração de Estados O sistema deverá permitir a alteração dos registros, de acordo com os estados pré-estabelecidos

e perfil dos usuários, permitindo ao programador alterar, aprovar, cancelar ou reprovar pedidos.

RO 4.08.11 Agendador O sistema deverá conter regras de agendamento, em função de critérios preestabelecidos pela

área ou eventos que requeiram uma pré-analise pelo solicitante, antes da disponibilização para a

área de programação.

RO 4.08.12 Relatórios de Pedidos O sistema deverá emitir/gerar relatórios diversos, nas formas de gráficos, listas e outras se

necessário, visando consulta e avaliação do desempenho por usuário(programador), área ou

região conformeíndices e metas preestabelecidas.

RO 4.08.13 Anexos O sistema deverá permitir anexar documentos (PDF ou figuras por exemplo) de projetos/ croqui,

para envio e divulgação aos envolvidos.

RO 4.08.14 Arquivo O sistema deverá permitir arquivamento de registros por período previsto em resoluções ANEEL

em lei, possibilitando a consulta e emissão de parecer a solicitações de informações,

reclamações ou processos de ressarcimento e ouvidorias internas ou ANEEL.

RO 4.08.15 Integração O sistema deverá integrar-se a outros sistemas internos e externos (GEO, SAP, ERP, CIS, por

exemplo), possibilitando comunicação para consulta, exportação ou replicação de dados

conforme parâmetros preestabelecidos.

4.08.02 Avisos de Desligamentos Programados


customização

Atende COM

customização

RO 4.08.16 Geral O sistema deverá permitir gerar avisos de interrupções programadas de longa e curta duração

(AM), a partir de uma manobra simulada graficamente ou descrita em uma relação de

ações/itens em tela específica de simulação, permitindo exibir lista das UC's afetadas.

RO 4.08.17 Campos dos Avisos O sistema deverá conter os diversos campos, conforme necessidade de informações dos avisos,

permitindo ao usuário incluir, alterar ou excluir informações, de acordo com o perfil

preestabelecido.

RO 4.08.18 Formato e Controle O sistema deverá apresentar listagem dos clientes afetados por aviso gerado, replicando os

dados cadastrais das unidades consumidoras conforme sistema de gestão de clientes (CIS) ou

parâmetros pré-definidos e, de forma a permitir a análise e envio dos avisos de acordo com os

tipos de contato pactuados com o cliente ou critérios definidos conforme Prodist - Módulo 8.

Deverá conter resumo e somatório, conforme tipos de UC e forma de aviso atribuída. O controle

de status deverá ser através de alteração de estados preestabelecidos, conforme perfil do

usuário cadastrado no sistema.

RO 4.08.19 Envio de Avisos O sistema deverá conter ferramenta de envio automático de avisos, conforme critérios

preestabelecidos e tipos de contato pactuados com os clientes, tais como: e-mail, SMS, COPEL

Mobile, telefone/URA, carta personalizada ou aviso em massa (rádios), mantendo o registro da

forma atribuída. Adicionalmente a esta ferramenta, deverá conter recursos para atualização de

informações de contato e emissão de SS através de Web Service para outras áreas da empresa

ou externas se necessário.

RO 4.08.20 Arquivo O sistema deverá permitir arquivamento de comprovantes de envio, de entrega ou confirmação

de recebimento por período previsto em resolução ANEEL, possibilitando a consulta e emissão

de parecer a solicitações de informações, reclamações ou processos de ressarcimento e

ouvidorias internas ou ANEEL.


por exemplo), possibilitando comunicação para consulta, exportação ou replicação de dados


Pg. 34 de 43


4.08.03 Elaboração de Manobras Programadas


customização

Atende COM

customização

RO 4.08.22 Geral O sistema deverá possuir um módulo de elaboração de manobras. Este deverá conter

funcionalidades de incluir, alterar ou excluir manobras de redes MT/BT e Subestações, através

dos equipamentos e dispositivos de manobra, esquemáticos de Subestações e demais atributos

preestabelecidos. Deverá conter todas as informações preestabelecidas, através da integração

dos módulos de Pedidos de Intervenções Programadas, Simulador de Manobras e Avisos de

Desligamentos Programados, com preenchimento automático, das etapas, passos ou itens de

execução/operaçãoe outros campos a definir.

RO 4.08.23 Formato O sistema deverá conter em formato pré-definido, por tipos de intervenção conforme

classificação de complexidade a definir (simplificada, convencional e complexa por exemplo),

contendo uma tela de controle distribuída em abas, etapas, campos e itens (operação e

complementos), para preenchimento pelo programador.

RO 4.08.24 Campos das Manobras O sistema deverá conter os diversos campos, conforme necessidade de informações das

manobras, permitindo ao usuário incluir, alterar ou excluir informações, de acordo com o perfil

preestabelecidos dos usuários.

RO 4.08.25 Registro de Manobras O sistema deverá permitir incluir, alterar ou excluir registros, de acordo com o perfil

preestabelecido do usuário.

RO 4.08.26 Emissão de Manobras O sistema deverá permitir emitir uma manobra a partir de uma simulação, indicação manual ou

sequência de manobra padrão pré-definidos, além de copiar manobras salvas no simulador.

Também deverá permitir incluir, alterar ou excluir registros, de acordo com o perfil

preestabelecido do usuário.

RO 4.08.27 Emissão de Manobras O sistema deverá possuir ferramenta de emissão a partir de exportação da sequência emitida no

módulo Simulador ou incluída manualmente através do aviso gerado, com numeração sequencial

da manobra, etapas e passos, em ordem cronológica de execução ou sequência lógica definida

pelo programador.

RO 4.08.28 Emissão de Manobras O sistema deverá permitir incluir, alterar, excluir, copiar, renomear passos e etapas, inverter

sequência de operação de interdição na energização e outras ações que não envolvam alteração

de configuração da rede e subestações (textos livres).

RO 4.08.29 Emissão de Manobras –

Retorno

O sistema deverá simular automaticamente o retorno de configuração de manobras com

interdição já planejada.

RO 4.08.30 Emissão de Manobras O sistema deverá possuir nos passos e etapas a serem executadas, a possibilidade de

designação da equipe de campo executora, com validação pelo técnico responsável da agência

e posterior confirmação pelo operador no Centro de Operação, durante a etapa de execução da

manobra.O sistema deverá possuir nos passos e etapas a serem executadas, a possibilidade de

designação da equipe de campo executora, com validação pelo técnico responsável da agência

e posterior confirmação pelo operador no Centro de Operação, durante a etapa de execução da

manobra.

RO 4.08.31 Lista de Clientes

Afetados

O sistema deverá permitir gerar listagem dos clientes afetados no trecho interditado pela

manobra, com todas as informações de cadastro e contatos, para análise e avaliação dos

critérios de desligamento e manobras preestabelecidos.

RO 4.08.32 Simulação de Indices O sistema deverá possibilitar simulação e cálculo de índices (DEC/FEC, DIC/FIC e DMIC), de

uma manobra, de um grupo/total de manobras salvas por período, por critérios de

conjunto/região ou outros parâmetros preestabelecidos.

RO 4.08.33 Autorizações e Anexos O sistema deverá permitir incluir, alterar e excluir Autorização de Trabalho (AUT), a partir das

informações dos pedidos de desligamentos, além de anexar documentos (PDF, Figuras por

exemplo) para envio e divulgação aos envolvidos.

RO 4.08.34 Consulta das Manobras O sistema deverá conter uma tela de consulta e seleção das manobras emitidas por estados,

com todos os dados necessários preestabelecidos, com configuração de filtros conforme

necessidade dos usuários e parâmetros preestabelecidos.

RO 4.08.35 Conferência e Revisão O sistema deverá conter relatório informativo de pendências (tipo check list), visando indicar

alguns pré-requisitos a definir, que deverão ser avaliados pelo programador e complementar a

manobra antes de disponibilizar à execução. Exemplo de check-list: indicação de equipamentos

especiais (BC, BRT, RA), elos fusíveis em manobras de anel, ou interligação de trechos, etc.

RO 4.08.36 Conferência e Revisão O sistema deverá conter ferramenta para indicar se existem manobras com trechos coincidentes,

por equipamentos e dispositivos em uma determinada data/horário (anterior e posterior), a fim de

avaliar a possibilidade de agrupar, alterar, excluir ou aproveitar parte ou total entre as

programações.

RO 4.08.37 Tramitação de Registros O sistema deverá permitir a tramitação dos registros, de acordo com os estados

preestabelecidos, permitindo ao programador confirmar e enviar manobras (relatórios, anexos,

entre outros por e-mail).

RO 4.08.38 Tramitação de Registros O sistema deverá permitir a confirmação das programações pelo programador, e vinculá-las ao

módulo de execução de manobras pelo Centro de Operação, permitindo ao Operador acessar os

registros em tela de controle própria e dar continuidade no processo.

RO 4.08.39 Alteração de Estados O sistema deverá permitir a alteração dos registros, de acordo com os estados preestabelecidos,

permitindo ao programador alterar, aprovar, cancelar ou reprovar manobras, com registro de

justificativa em campo específico se necessário.

RO 4.08.40 Relatórios Desempenho

de Manobras

O sistema deverá emitir/gerar relatórios diversos, nas formas gráficas, listas e outras se

necessário, visando consulta e avaliação do desempenho por usuário, área ou região conforme

índices e metas preestabelecidas, visando subsidiar a área de programação na tomada de

decisão e emissão de pareceres ou alterações de solicitações em função de metas

preestabelecidas.

RO 4.08.41 Arquivo O sistema deverá permitir arquivamento de registros por período previsto em resolução ANEEL,

possibilitando a consulta e emissão de parecer a solicitações de informações, reclamações ou

processos de ressarcimento e ouvidorias internas ou ANEEL.


por exemplo), possibilitando comunicação para consulta, exportação ou replicação de dados


4.08.04 Execução de Manobras Programadas

Pg. 35 de 43



customização

Atende COM

customização

RO 4.08.43 Geral O OMS deve possuir um grupo de telas e funções, dedicadas ao monitoramento e execuções

das manobras programadas. Estas, destinadas geralmente à liberação de trechos e

equipamentos desenergizados para execução de trabalhos por equipes de obra e manutenção.

RO 4.08.44 Geral As OMB's, devem ser dispostas em telas tabuladas, apresentando as futuras e atuais manobras

a serem executadas. Esta tela, deve possuir gráficos, e colunas demonstrando a demanda de

manobras, afim de prever-se operador adicional para execução, ou até mesmo, solicitar a área

de programação, o reescalonamento destas (previsão de itens a executar por período).

RO 4.08.45 Geral A OMB deve possuir todos itens necessário para execução, com o acompanhamento por etapas

de cada item planejado e executado.

RO 4.08.46 Geral A OMB deve possuir consulta a todas reclamações registradas vinculadas a esta pelo TCS.

RO 4.08.47 Geral A OMB deve agrupar as interrupções, serviços, atuações de equipamentos, documento de

solicitação pelo responsável dos trabalhos na rede, AUT(s), relação de aviso a consumidores,

etc)

RO 4.08.48 Geral Deve existir função para simulação da OMB, afim de entendimento, certificação e planejamento

da mesma pelo operador. As certificações devem possuir histórico dos operadores.

RO 4.08.49 OMB tempo real do tipo

voluntária

Deve permitir-se ao operador, programar uma OMB para alteração ou retorno de configuração de

um alimentador, e (ou) demais intervenções na rede do tipo VOLUNTARIA. Exemplo: Liberar um

equipamento especial ou um trecho para manutenção emergencial. Este tipo de OMB deve

reportar ao CIS a informação de desligamento do tipo voluntário às UC's afetadas.

RO 4.08.50 Impedimentos/marcaçõe

s de equipamentos

Ao executar um item da OMB, e este indicar o impedimento de operação do equipamento, o

OMS deve impedir a operação do equipamento, até mesmo via DMS, afim de garantir a

segurança de equipes de campos envolvidas no trecho. O desbloqueio deste impedimento

ocorrerá após procedimentos de AUT realizadas em campo, e liberação pelo operador no OMS.

Devera-se incluir pontos de aterramento temporário, impedindo os energizamentos observando-

se em simulações de tempo real.

RO 4.08.51 Visualização gráfica

programação tempo real

O OMS deverá sinalizar graficamente o trecho desenergizado onde há equipes trabalhando em

uma determinada OMB, bem como simbologias dos pontos de aterramento inseridos através de

ações dentro da OMB ou manualmente pelo operador.

RO 4.08.52 Geral Ao simular OMB, o OMS deve apontar impossibilidade de execução quando a configuração da

rede não estiver atendendo a programação. Exemplo: Coincidência de OMB's, configurações

alteradas decorrente de outra ocorrência, restrições do sistema, etc.)

4.08.05 Módulo Intervenções Programadas AT


customização

Atende COM

customização

RO 4.08.53 Solicitação O sistema deverá possuir um módulo que possibilite receber solicitações de intervenção com ou

sem desligamento em subestações ou linhas de distribuição via integração com outros sistemas

(ex. GDmase) ou através da inclusão da solicitação diretamente no próprio módulo.

RO 4.08.54 Solicitação O sistema deverá conter informações de campos de preenchimento opcionais e obrigatórios, e

deverá efetuar o controle das programações fora do prazo previamente definido em instruções,

bloqueando o envio das solicitações fora do prazo, exceto se houver justificativa.

RO 4.08.55 Acesso O sistema deverá permitir distinguir perfis diferenciados de usuários (ex. pré, pós, tempo real,

consulta geral).

RO 4.08.56 Geral O sistema deverá permitir que o controle das atividades de programação de intervenção (ex.

envio de avaliações, lembretes, observações) seja efetuado através do sistema, sem

necessidade do uso de papel.

RO 4.08.57 Solicitação O sistema deverá permitir incluir, alterar e excluir informações nas solicitações de acordo com a

etapa do processo (solicitação, análise, aprovada, ...) e perfil preestabelecido do usuário.

RO 4.08.58 Recebimento da

solicitação

O sistema deverá permitir incluir e excluir funções e informações para uma solicitação de

intervenção, bem como consultar as informações dos documentos já inseridos. Deverá conter

campos com dados georreferenciados de Subestações e LDATs, visando simular desligamentos

e subsidiar a análise, os estudos e o agendamento em função dos parâmetros definidos pela

programação.


solicitação

O sistema deverá permitir que a análise e os encaminhamentos necessários sejam precedidos

por um checklist pré-definido, que possa ser alterado de forma a melhorar o processo de

intervenções.

RO 4.08.60 Solicitação O sistema deverá permitir associar programações de aproveitamento a uma intervenção já

cadastrada, podendo ser encaminhada por outros sistemas (ex. Gdmase) ou gerada no próprio

módulo.

RO 4.08.61 Geral O sistema deverá permitir programar em uma mesma intervenção, equipamentos com tempos

distintos de manobras ou condições diversas (ou seja, com ou sem desligamento).


solicitação

O sistema deverá conter uma ferramenta de pré-análise que possibilite organizar as solicitações

considerando a prioridade no atendimento de acordo com os prazos definidos para cada tipo de

intervenção.


solicitação

O sistema deverá conter uma tela de apresentação dos solicitações emitidas por estados, com

configuração de filtros conforme necessidade dos usuários e parâmetros preestabelecidos

(região, data, número da solicitação, etc).

RO 4.08.64 Geral O sistema deverá permitir de acordo com o perfil dos usuários alterar o estado da intervenção

(devolver, aprovar ou cancelar,...), com registro do responsável pela alteração.

RO 4.08.65 Geral O sistema deverá permitir o cancelamento da programação pelo solicitante em qualquer

momento do processo.

Pg. 36 de 43


RO 4.08.66 Relatórios de

solicitações

O sistema deverá emitir/gerar relatórios diversos, nas formas de gráficos, listas e outras se

necessário, visando consulta e avaliação do desempenho por usuário, área ou região conforme

índices e metas preestabelecidas (ex. envio e aprovação de programações dentro e fora do

prazo, quantidade de vezes que um equipamento/função foi impedido).

RO 4.08.67 Aprovação O sistema deverá permitir a verificação de critérios de aprovação (ex. quantidade de carga ou

consumidores interrompidos, tempo de liberação, período da intervenção).

RO 4.08.68 Geral O sistema deverá permitir anexar documentos (ex. projetos, croqui,...), para envio e divulgação

aos envolvidos.

RO 4.08.69 Geral O Sistema deverá permitir a criação de arquivo na extensão PDF de programação de

intervenção aprovada, mensagem operativa, sequência de manobra, etc.

RO 4.08.70 Mensagens O sistema deverá possibilitar envio de mensagens (MO, AI e ATEE) para outros agentes,

acessantes de geração e de carga em formato PDF, permitindo a busca destas através de filtro.

RO 4.08.71 Solicitação de parecer O sistema deverá permitir envio de avaliações para áreas internas visando a emissão de

pareceres, e também possibilitar o controle destas avaliações tanto pela área que solicitou a

avaliação como pela área responsável pela avaliação, através da emissão de relatórios, gráficos,

etc.

RO 4.08.72 Registro de eventos -

Histórico

O sistema deverá manter histórico das intervenções programadas (aprovadas, canceladas) e

registro das etapas tramitadas das solicitações (data de envio, recebimento, indeferimento,

aprovada, cancelada).

RO 4.08.73 Consulta O sistema deverá permitir simular interrupção, a partir de pontos e equipamentos, que possuem

seccionamento da instalação. Esta simulação, apresentará relatório e exibição do sistema

elétrico e esquemático, contendo os pontos (rede, equipamentos, subestações, etc.) que

permanecerão desenergizados no período estimado, assim a incidência de consumidores

afetados.

RO 4.08.74 Cadastro O sistema deverá permitir o cadastro de Subestações, Linhas de Distribuição de Alta Tensão

(ramal, derivação), transformador, regulador, etc; equipamentos de manobra (disjuntor,

seccionadora, chave 43, etc); agentes, acessantes de carga e geração, etc.

RO 4.08.75 Integração O sistema de programação deverá estar integrado com o supervisório (cadastro de

equipamentos e condição real).

RO 4.08.76 Integração O sistema deverá ser integrado a outros sistemas internos e externos (GEO, SAP, ERP, CIS,

GDmase, Anarede), possibilitando comunicação para consulta, exportação ou replicação de

dados conforme parâmetros preestabelecidos.

RO 4.08.77 Integração O sistema de programação Média Tensão deverá ser integrado com o sistema de programação

de Alta Tensão.

RO 4.08.78 Simulação de Manobras O sistema deverá permitir simulação de manobras em um sistema de supervisão de modo

isolado, possibilitando análise elétrica da intervenção e/ou a elaboração de sequência de

manobras com todas as informações relevantes, incluindo número/código (ex. 52-xx) dos

equipamentos, descrição, data e hora prevista para início e término das manobras e

observações. Podendo receber alterações com registro do usuário e de acordo perfil

preestabelecido. O sistema deverá permitir reiniciar o ambiente simulado, retornando à sua

condição original. O sistema deverá permitir incluir, excluir, editar, duplicar e inverter itens ou

etapas selecionados de uma sequência de manobras.

RO 4.08.79 Sinalização O simulador deverá permitir diferenciar graficamente as sinalizações com informações de

equipamentos, em função das manobras programadas, de forma a auxiliar usuários da Operação

e Programação nas análises e ações.

RO 4.08.80 Configuração do

Simulador

O sistema deverá possuir ferramentas de configuração em função das curvas de carga / período

(GASA, Anarede), redefinir configuração ou tempo real, visando simular em diferentes situações

ou definição de critérios preestabelecidos para emissão e execução de manobras.

RO 4.08.81 Simulação de Índices O sistema deverá disponibilizar para simulação de manobras a lista de acessantes atingidos com

os valores de compensação financeira em função de desligamento de carga e geração de Alta

Tensão que podem afetar indicadores de continuidade DIC/FIC e DMIC. Deverá apresentar os

resultados graficamente e através de relatórios, visando subsidiar a área de programação na

tomada de decisão e emissão de pareceres ou alterações de solicitações em função de metas

preestabelecidas.

4.08.06 Módulo Operação Tempo Real AT


customização

Atende COM

customização

RO 4.08.82 Registros de eventos O sistema deverá permitir o registro de ocorrências no sistema elétrico de acordo com o tipo de

ocorrência (ex. com ou sem desligamento, energização de nova função, sobrecarga, paralelo em

TFs, restrição operacional, transferência de circuitos, falha de supervisão/controle/automação,

controle de tensão, bloqueios operacionais diversos, controle de acesso a instalações,

gerenciamento de carga, atuação do erac, nota/comentário)

RO 4.08.83 Registros de eventos O sistema deverá permitir que o registro de ocorrência utilize os dados do próprio sistema (ex.

horário de abertura e fechamento dos disjuntores, proteções atuadas, atuação ou não do

religamento automático, religamento sob falta e a indicação da falta e distância da falta, quando

envolver linha de distribuição de AT, carga interrompida, sobrecargas em equipamentos, circuitos

que desligaram pelo ERAC) e também possibilite a inclusão de outras informações (ex. causa do

desligamento, condições climáticas, acionamento de equipes, reclamação de acessante).

RO 4.08.84 Registros de eventos O sistema deverá gerar de forma automática o envio de SMS para empregados e acessantes

cadastrados, dependendo do tipo de evento registrado.

RO 4.08.85 Registros de eventos Nas intervenções programadas, o sistema deverá permitir a inclusão de todas informações

necessárias para o controle das mesmas (antes da execução, na liberação para execução,

durante a execução e no término da intervenção), registrando os eventos necessários para

manutenção do histórico das intervenções programadas.

RO 4.08.86 Sistema – Integração Nas intervenções programadas, o sistema deverá apresentar as informações contidas nas

instruções relacionadas, através de integração com o sistema de gestão de documentos (PW -

Project Wise).

Pg. 37 de 43


RO 4.08.87 Registros de eventos O sistema deverá permitir o controle do acionamento de equipes permitindo a inclusão de

informações relativas ao acionamento (ex. horário de acionamento, horário de chegada no local),

assim como também a integração com outros sistemas de controle de equipes.

RO 4.08.88 Sistema – Integração Deve ser possível a integração com outros sistemas (ex. Telecomunicação, Manutenção, RH),

de forma a permitir por exemplo: a emissão de serviços, anomalias, acionamento de equipes,

escala de sobreaviso.

RO 4.08.89 Sistema – Integração Deve possibilitar a realização do controle de turnos dos operadores.

RO 4.08.90 Sistema – Integração Deve permitir o registro com o lançamento dos nomes dos operadores em serviço para cada

horário de turno de revezamento. Este sistema deve permitir que os horários do cumprimento da

jornada de trabalho possam ser alterados em caso de mudanças.

RO 4.08.91 Geral Deve permitir a geração de relatórios e a visualização de telas conforme critérios pré-definidos e

filtros diversos

4.09 Tempo estimado para Restabelecimento do Sistema


customização

Atende COM

customização

RO 4.09.01 Geral Deve possuir dinâmica pré estabelecida para cálculo automático do Tempo Estimado para

Restabelecimento para todas as interrupções baseado em informações históricas do sistema e

parâmetros como: tipo de atividade, tipo de interrupção,material, deslocamento, hora do dia,

disponibilidade de equipes, etc.

RO 4.09.02 Cálculo Ajustável Deverá ter capacidade de recalcular e atualizar o Tempo Estimado para Restabelecimento

conforme os recursos adicionais são designados para o local da interrupção.

RO 4.09.03 Modo de Operação Deverá ser ajustável conforme o modo de operação do momento, (modo normal/tempestade) e

ajustar o método do cálculo conforme esse modo de operação.

RO 4.09.04 Alteração Manual e

Rastreabilidade

Deverá ser ajustável pelo usuário, com a autorização para a alteração manual do tempo já

calculado. As intervenções manuais deverão ficar registradas com informações que identifiquem

o usuário. Deverá ter a opção de exportar lista com os parâmetros dos tempos estimados

calculados, tais como: classificação de maior tempo estimado, CHI, DMIC, DEC, etc.

RO 4.09.05 Ciclos de interrupção Deverá ter a capacidade de rastrear e registrar o tempo conforme as etapas do ciclo da

interrupção tais como: Tempo inicial gerado automaticamente, tempo fornecido pela equipe do

primeiro atendimento, tempo fornecido pela equipe de manutenção e tempo alterado

manualmente pelo operador.

RO 4.09.06 Notificação Notificar visualmente quando o tempo de interrupção estiver prestes a ser ultrapassado, para que

o usuário atualize parâmetros que recalculem o tempo automaticamente, ou para que o usuário

informe a nova previsão manualmente.

RO 4.09.07 Registro visual O sistema deverá distinguir visualmente o registro quando um horário do Tempo Estimado de

Restabelecimento for alterado manualmente.

RO 4.09.08 Desativação Deverá possuir uma opção ajustável que desative o tempo estimado para o restabelecimento de

todas as interrupções. Desta forma, o TCS considerará todas as interrupções ABERTAS com

previsão até um único horário informado, evitando a geração de novas ocorrências/serviços em

contingências. Ex: Desativar previsão de interrupção nas próximas 6 horas. Função destinada,

quando há grande quantidade de interrupções com previsões a serem analisadas.

RO 4.09.09 Tempo estimado em

OMB's

Notificar visualmente quando o tempo de interrupção de uma OMB estiver prestes a ser

ultrapassado e utilizar os tempos programados dos itens de manobra restantes como informação

para a atualização do Tempo estimado para o restabelecimento.

4.10 Dinâmica de Pós Operação


customização

Atende COM

customização

RO 4.10.01 Geral Deve possuir dinâmica preestabelecida para atividades de Pós Operação, como por exemplo,

correção e/ou validação de interrupções, etc.

RO 4.10.02 Atualização GEO Deve possuir função de verificação da atualização do GEO para o ADMS do cadastro da rede

elétrica. Deverá invalidar situações que comprometam a configuração do sistema elétrico

erroneamente, permitindo funções de correções e manipulações quando necessário afim de

promover a atualização.

RO 4.10.03 Registro Tempo

Real/Pós-operação

Deve possuir tela de consulta, afim de localizar determinada interrupção, em qualquer estado,

disponibilizando alguns campos usuais para filtro e localização do registro. Este registro

localizado poderá ser alterado, desde que não esteja oficializado para ANEEL (indicadores

mensais).

RO 4.10.04 Validação de registros Deve possuir função/tela tabular, para especificar/personalizar combinações de campos dos

registros, que devem ser validados durante o preenchimento em tempo real da ocorrência. Estas

validações em tempo real, poderão impedir ou alertar a forma do registro, possuindo descrição

de erro ou alerta. Esta especificação deverá ser configurável e opcional para que não

comprometa o tempo real quando em grande fluxo de trabalho.

RO 4.10.05 Relatórios de registros Deve apresentar relatórios com Pendências de transmissão (serviços e interrupções), incluindo

as ocorrências com estado CONFIRMADA e interrupções com estado ABERTAS, PENDENTE

DE INCLUSÃO, PENDENTE DE ALTERAÇÃO e PENDENTE DE EXCLUSÃO.

RO 4.10.06 Relatórios de registros Deve apresentar consulta tabular de Interrupções com períodos coincidentes em um ou vários

trechos, que afete um ou vários consumidores ao mesmo tempo. Função/relatório necessário

caso o OMS não possua uma solução possível prevendo invalidação do registro em tempo real.

Caso necessário esta consulta, deve haver funções de correção e expurgo das coincidências,

por intermédio do usuário Pós-operação.

RO 4.10.07 Relatórios de registros Deve apresentar consulta tabular, contendo registros de interrupções, com várias informações

(duração, causa, conjunto, sequência de manobras, etc). Deve possuir filtros e parâmetros afim

de validar o valor apurado dos indicadores individuais (DIC, FIC,DMIC e DICRI), e relatório

destas multas.

Pg. 38 de 43


RO 4.10.08 Gestão de conferência

dos registros

Deve apresentar relatórios(consulta tabular) contendo as certificações/gerenciamento dos

registros de interrupções conferidas, possuindo histórico (workflow) das análises e correções.

RO 4.10.09 Relatório Recomposição Deve apresentar consulta para determinada recomposição (mesmo não encerrada),

representando-a, demonstrando o desempenho de todas ações e etapas do operador e equipes

de campo envolvidas, quantidades de UC's afetadas, registro NDS(s), SDS(s), APD(s), e

observação de demais documentos corporativos. As etapas devem ser apresentadas

graficamente como linha do tempo. Deve relacionar os principais logradouros e (ou) localidades

afetadas.

RO 4.10.10 Configurações alteradas Deve apresentar consulta tabular e relatório, demonstrando os estados anormais de

equipamentos na rede, destacando as principais alterações com necessidade de retorno a

configuração original (exemplo: linha de sub-transmissão 34,5kv com prioridade).

RO 4.10.11 Pendências de

oficialização

Deverá possuir ambiente de telas, onde possuirá filtros e consultas personalizadas, afim de exibir

registros com inconsistências e impedimentos de oficialização destes, permitindo correções

pertinentes.

RO 4.10.12 Relatório Eventos

Severos

Deve permitir geração de relatório por demanda para fins de publicação externa. Neste relatório

deve possuir a quantidade de UC's afetadas, região e micro regiões geográficas, horários e

períodos, componente, causa e tipo da interrupção. Exemplo: Relatório Vendaval.

RO 4.10.13 UC's interrompidas Deve permitir consulta tabular e relatório, apresentando todas as UC's afetadas em uma

ocorrência, ou até várias em determinado período, considerando também filtros para determinar

que classe ou sub-classe de UC's, regiões, alimentador, deve ser apresentado.

RO 4.10.14 Restrição de consultas As consultas e alterações, de reclamações, serviços, ocorrências (demais registros), devem ser

limitados conforme perfil de usuário.

RO 4.10.15 Alterações em cascata Permitir cancelar e incluir, ou alterar as características de várias interrupções encadeadas,

baseando-se em uma sequência de atuações de equipamentos, que tiveram suas

ordens/sequências corrigidas.

RO 4.10.16 Consulta interrupções

trechos

Deve permitir pesquisar/selecionar um trecho primário especifico, e exibir todos registros de

interrupções recente que afetaram este.

RO 4.10.17 Consulta interrupções

equipamentos

Deve permitir pesquisar/selecionar um equipamento operacional especifico, e exibir todos

registros de interrupções recente que afetaram este e originados por este.

4.10.01 Módulo Pós-Operação AT


customização

Atende COM

customização

RO 4.10.18 Gestão de eventos Deve possibilitar a apuração e validação dos eventos de interrupção no fornecimento para

acessantes de carga e/ou geração que podem afetar os indicadores de continuidade DIC, FIC e

DMIC, em conformidade com as regras vigentes do Setor Elétrico, disponibilizando-os através da

integração com outos sistemas (IQS) de forma a permitir o cálculo dos referidos indicadores.

RO 4.10.19 Registro de evento Deve possibilitar a classiificação, apuração e validação dos eventos, em conformidade com as

regras estabelecidas pela área de manutenção da COPEL e responsabilidades e perfis definidos,

permitindo a medição do desempenho de equipamentos.

RO 4.10.20 Gestão de eventos Deve possuir um gerenciamento de interrupções (programadas ou não programadas),

organizando-as e associando-as em “Eventos”.

RO 4.10.21 Gestão de eventos Deve manter histórico das interrupções (programadas ou não programadas) associadas aos

acessantes de carga/geração de AT, LDATs, Barras, etc., que possuem Telemedição, por

período pré-determinado pelos administradores do OMS. Este histórico deve possuir filtros de

consulta, por tipo, causa, data, hora, função, instalação, equipamentos, região, área de controle,

etc.

RO 4.10.22 Gestão de eventos Os documentos não poderão ser encerrados, até atender requisitos especificados/configurados

pelos administradores do OMS. Enquanto não encerrados, serão apresentados em uma lista de

pendências e suas necessidades de correção/confirmação, liberando-os para oficialização.

RO 4.10.23 Gestão de eventos Todas FMs, devem ser registradas, e quando consultados estes registros, devem apresentar a

lista de Acessantes/Subestações/LDATs afetados por estas. O período de FM (<3min), deve

permitir configuração.

RO 4.10.24 Gestão de eventos Deverá permitir a atuação de equipamentos de AT, sem gerar registro de interrupções, quando

for o caso de atualização de estado de equipamentos que estejam diferentes do OMS, e que não

ocasionaram interrupções ou perturbações.

RO 4.10.25 Cadastro Deve permitir atualização de dados dos equipamentos/subestações/acessantes de AT, desde

que não afete eventos/ocorrências que estejam associados aos mesmos. Caso necessário, um

administrador do OMS deverá analisar e regularizar as pendências, permitindo a atualização total

do mesmo. Os equipamentos que não estiverem em seu estado normal, deverão ser mantidos

como estavam após a conclusão de atualização.

RO 4.10.26 Gestão de eventos Deve possuir tela de consulta, a fim de localizar determinada interrupção, em qualquer estado,

disponibilizando alguns campos usuais para filtro e localização do registro. Este registro

localizado poderá ser alterado pela equipe de pós-operação de AT.

RO 4.10.27 Gestão de eventos Deve apresentar consulta para determinada recomposição (mesmo não encerrada),

demonstrando o desempenho de todas ações e etapas do operador e equipes de campo

envolvidas, quantidade de acessantes de carga/geração AT, barras desligadas e observação de

demais documentos corporativos. A demonstração das etapas, deve ser apresentada como linha

do tempo.

RO 4.10.28 Gestão de eventos Deve apresentar relatório, demonstrando as alterações de equipamentos no Sistema de

Distribuição de Alta Tensão, destacando as principais alterações com necessidade de retorno à

configuração original (Exemplo: Linha de distribuição de AT 69 kV / 138 kV).

RO 4.10.29 Gestão de eventos Deverá possuir ambiente de telas para função Pós-operação, onde possuirá filtros e consultas

personalizadas, com o objetivo de exibir registros com inconsistências e impedimentos de

oficialização deste.

Pg. 39 de 43


RO 4.10.30 Relatórios e telas de

consulta

Deve permitir geração de relatório por demanda para fins de publicação externa. Este relatório

deve possuir o nome/sigla da subestação, equipamento e/ou acessantes de carga e/ou geração

afetados no sistema de alta tensão, região, horários e períodos, função, tensão nominal do

sistema, causa, MW interrompido, tipo da interrupção, proteções atuadas, condições climáticas,

etc. Exemplos: Relatório Explosão em Subestação de AT, Relatório Blecaute, etc.

RO 4.10.31 Gestão de eventos Possibilitar consulta/gerenciamento de registros, serviços, ocorrências, etc., mas devem ser

limitadas conforme o perfil de usuário.

RO 4.10.32 Gestão de eventos Permitir o cancelamento, inclusão, alteração e exclusão das características de interrupções

encadeadas, baseando-se em uma sequência de atuações de equipamentos, mas devem ser


RO 4.10.33 Gestão de eventos Permitir o cancelamento e exclusão de registros duplicados e/ou inválidos, pela equipe de pós-

operação de AT.

RO 4.10.34 Gestão de eventos Deverá apresentar listas (relatórios) de Pendências e estes deverão estar acessíveis para todos,

com perfil definido, sendo que estes usuários poderão encerrar os serviços pendentes.

RO 4.10.35 Retenção das

informações

Os documentos referentes às interrupções no sistema de distribuição de alta tensão devem ser

armazenados conforme intervalos pré-definidos.

RO 4.10.36 Integração de Sistemas Possibilitar o armazenamento e recuperação de dados históricos em outra base de dados.

RO 4.10.37 Gestão de eventos Todas as alterações deverão ser gravadas (manual ou sistema), com a identificação do

responsável pela mesma.

RO 4.10.38 Navegação Navegação em telas correlacionadas com todas as informações arquivadas de um evento.

RO 4.10.39 Consulta serviços/Pós-

Operação

Deve permitir a consulta de todas as mensagens pertinentes ao serviço, como mensagens entre

equipes e operadores do COSD e CODs, pela área de pós-operação de AT, para

complementação de relatórios e análises.


consulta

Deve permitir busca e filtros de serviços através de critérios definidos pelo usuário, tais como tipo

de serviço, área ou região, subestação, localidade, período, etc.


consulta

Deve disponibilizar dados das interrupções a acessantes de carga e geração de alta tensão e

eventos de vulto (conforme critérios previamente estabelecidos), para fins informativos

(Informativo Diário da Operação) e apresentação no Dashboard. Ex.: COPEL INFO AT.

RO 4.10.42 Modo Alerta – Pós-

operação

Deve permitir através de uma consulta, exibir recomposições (ocorrências, interrupções, etc),

resumidamente e detalhadamente, referente ao período de ativação, ex. alerta temporal, ERAC,

blecaute, etc.

RO 4.10.43 Gestão de eventos Deve possuir dinâmica pré-estabelecida para atividades de Pós-Operação de AT, como por

exemplo, correção e/ou validação de interrupções, etc.


consulta

Deve permitir seleção/importação/exportação para modelos de relatórios específicos

(INFORMATIVO, PARECER TÉCNICO, GAOP, ERAC, SOBRECARGA TFs e LDATs, BISE,

IPIE, etc.).

RO 4.10.45 Gestão de eventos Deve apresentar relatórios com possibilidade de certificar/gerenciar as interrupções conferidas.

RO 4.10.46 Gestão de eventos Deve permitir o cadastramento, apuração, registro, consulta, análise, cálculo e envio das

informações sobre interrupções a Pontos de Conexão de Alta Tensão existentes entre

DIS/GeT/Acessantes/Outras Concessionárias.

RO 4.10.47 Gestão de eventos Consistir e validar registros de interrupções a acessantes de carga e geração de alta tensão

(duração, causa, MW interrompido, região, horários e períodos, função, tensão nominal do

sistema, tipo da interrupção, proteções atuadas, condições climáticas, etc.), a fim de validar o

valor apurado dos indicativos individuais (DIC, FIC e DMIC).

RO 4.10.48 Gestão de eventos Deve possuir tela de consulta, com o intuito de localizar determinada interrupção, em qualquer

estado, disponibilizando alguns campos usuais para filtro e localização do registro. Este registro

localizado poderá ser alterado pela equipe de pós-operação de AT.


consulta

Deve apresentar consulta para determinada recomposição (mesmo não encerrada),

demonstrando o desempenho de todas ações e etapas do operador e equipes de campo

envolvidas, quantidade de acessantes de carga/geração AT, barras desligadas e observação de

demais documentos corporativos. A demonstração das etapas, deve ser apresentada como linha

do tempo.


consulta

Deve apresentar relatório, demonstrando as alterações de equipamentos no Sistema de

Distribuição de Alta Tensão, destacando as principais alterações com necessidade de retorno à

configuração original (exemplo: Linha de distribuição de AT 69 kV / 138 kV).


consulta

Deverá possuir ambiente de telas para função Pós-operação, onde possuirá filtros e consultas

personalizadas, com o objetivo de exibir registros com inconsistências e impedimentos de

oficialização deste.


consulta

Deve permitir geração de relatório por demanda para fins de publicação externa. Este relatório

deve possuir o nome/sigla da subestação, equipamento e/ou acessantes de carga e/ou geração

afetados no sistema de alta tensão, região, horários e períodos, função, tensão nominal do

sistema, causa, MW interrompido, tipo da interrupção, proteções atuadas, condições climáticas,

etc. Exemplos: Relatório Explosão em Subestação de AT, Relatório Blecaute, etc.


consulta

Possibilitar consulta/gerenciamento de registros, serviços, ocorrências, etc., mas devem ser


RO 4.10.54 Dados Históricos Pós-

operação

Deve armazenar todo o histórico de informações de registros e dados de pós-operação AT,

apresentando a facilidade de consultá-los, filtrá-los, alterá-los e redirecioná-los. (RELATO, Curva

de Carga, etc.).

RO 4.10.55 Estatísticas Deverá realizar levantamento estatístico de ocorrências/eventos envolvendo subestações de AT,

equipamentos, acessantes de carga/geração de AT, etc. Tendo ainda a possibilidade de gerar

relatórios estatísticos.

Pg. 40 de 43


RO 4.10.56 Estatísticas Deverá possuir a possibilidade de buscar/consultar/filtrar/dividir/copiar, por região, nome da

instalação, equipamentos, função, nome dos acessantes de carga/geração, tensão nominal do

sistema, causa, tipo da interrupção (Programada/Voluntária/Acidental), condições climáticas, etc.,

as estatísticas de ocorrências/eventos envolvendo o sistema de distribuição de AT.

RO 4.10.57 Visão Recomposições Deve permitir a visão gerencial e de pós-operação AT, do acompanhamento das recomposições

importantes com informações sobre a malha de distribuição de alta tensão, equipes e acessantes

de AT desligados, etapas de restabelecimento, linha do tempo, área responsável principal pelo

andamento do restabelecimento.

RO 4.10.58 Visão Dashboard Deve exibir gráficos em frames, contendo a Curva de Carga do Sistema de Distribuição,

acumulados e instantâneo. As curvas deverão apresentar: Carga Total do Paraná, Cargas

Distritais (regiões LES/OES/CSU/NRT/NRO, além de uma subcurva apresentando o Litoral do

Pr) Exemplo Dashboard COPEL CARGA AT. Este deve estar disponível no ambiente

WEB/Internet com restrições de login.

RO 4.10.59 Visão Dashboard Deve disponibilizar dados das interrupções a acessantes de carga e geração de alta tensão e

eventos de vulto (conforme critérios previamente estabelecidos), para fins informativos

(Informativo Diário da Operação) e apresentação no Dashboard. Ex.: COPEL INFO AT.

RO 4.10.60 Integração O ADMS deverá permitir que sejam feitas as análises das ocorrências do sistema elétrico da

Copel, sendo que haverá necessidade de anexar documentos referentes a Análise de

Oscilografias, arquivos em formatos diversos.

RO 4.10.61 Análise e Desempenho

de Proteção

Deve permitir a inclusão de dados relativos a atuação do sistema de proteção, assim como

possibilitar a análise e estatística do desempenho dos equipamentos de proteção e do

religamento automático, pela área responsável, conforme perfil associado.

RO 4.10.62 Análise e Desempenho

de Proteção

Deve ser capaz de calcular indicadores e emitir relatórios para avaliação do desempenho dos

sistemas de proteção e seus equipamentos.

RO 4.10.63 Integração de Sistemas Deve ser integrado com o banco de dados de equipamentos de proteção instalados (ex.

GDMaSE).

4.11 Regras de retenção das informações


customização

Atende COM

customização

RO 4.11.01 Tempo retenção Registros de Reclamação: 10 anos. Demais documentos (Serviço, Interrupção, Ocorrência, NDS,

Eventos Telemedição, PDE, AUT, PLV, OMB, etc.): 5 anos

RO 4.11.02 Permitir a guarda de

dados histórico

Possibilitar a guarda e recuperação de dados histórico em outra base de dados.

RO 4.11.03 Geral Deverá armazenar os dados de encerramento de todos os eventos do sistema

RO 4.11.04 Informações

Armazenadas

Deverá armazenar todas as informações registradas num evento, ex:

- Numeração dos eventos;

- Horários: previsão, início, término;

- Causas e componente;- Equipes, tipo veículo, status, horários de etapas; Etapas e

restabelecimento: solicitação, local, início, término, etc.;

- Equipamentos, circuitos e subestações;

- Dados dos equipamentos, índices;

- Tipo de Interrupção, Área Elétrica, área específica, condições climáticas;

- Localização Geográfica, distrital, agência;

- Manobras: atuações, equipamentos manobrados, horários, número de clientes, etc

- Ordens de Manobra: Itens de atuação, horários previstos, realizados, tipo, etc.- Comentários

pertinentes nas etapas de atendimento;

- Consumidores: clientes afetados, reclamações e call-backse, etc.

RO 4.11.05 Ligações entre

informações

Navegação em telas e abas correlacionadas com todas as informações relacionadas/arquivadas

de um evento.

4.12 Comunicação Alarmes e Informativos


customização

Atende COM

customização

RO 4.12.01 Envio Mensagem Deve prever enviar mensagens de texto por diversas tecnologias como: SMS, 3G/4G, etc.

Sugere-se utilizar aplicativos como COPEL Mobile, Whatsapp, Telegram, conforme cadastro e/ou

definição do destinatário.

RO 4.12.02 Envio Mensagem Deve permitir enviar mensagem de texto manualmente (contendo textos) a grupos de celulares

pré-definidos.

RO 4.12.03 Envio Mensagem Deve emitir mensagem de texto a celulares cadastrados previamente, automaticamente, de

acordo com nível de alerta (por grupo de regiões) registrado por um usuário administrador do

OMS.

RO 4.12.04 Envio Mensagem Deve emitir mensagem de texto a celulares cadastrados previamente, automaticamente,

informando andamento de serviços e interrupções específicas parametrizadas por prioridade de

emissão do alerta, por região e CHI.

RO 4.12.05 Envio Mensagem Deve emitir mensagem de textoa celulares cadastrados previamente, informando etapas de

recomposições, até o reestabelecimento total. Será parametrizado por região principal

responsável pelas ações de campo da recomposição.

RO 4.12.06 Envio Mensagem Deve emitir mensagem de texto a celulares cadastrados previamente, específicos para quando

houver determinada UC (indicada como VIP-COD) afetada em uma interrupção (mesmo na

condição de possível).

RO 4.12.07 Envio Mensagem Deve emitir mensagem de texto a celulares cadastrados previamente, específicos para quando

houver determinada região (logradouro/localidade) afetada em uma interrupção (mesmo na

condição de possível).

4.13 Modo de Operação Descentralizada


customização

Atende COM

customização

RO 4.13.01 Geral O OMS deve permitir modo de operação descentralizada, em outro local diferente do centro de

operação, como também por Ambiente Virtualizado (Ex. Citrix) em situações esporádicas.

Pg. 41 de 43


RO 4.13.02 Geral O OMS deve permitir modo de operação descentralizada, onde será possível um operador

alocado em uma base remota, auxiliar com determinado nível por usuário de atribuição de

atividades descentralizadas.

4.14 Modo Alerta Temporal


customização

Atende COM

customização

RO 4.14.01 Níveis de Alerta Deve permitir que usuário administrador, registre nível de alerta temporal (previsões ou em

tempo real), classificando-o como total, ou apenas sub-grupos de regiões. Texto livre poderá ser

complementado no ALERTA.

RO 4.14.02 OMS em modo de alerta Deve existir função para o administrador emitir um determinado alerta temporal (AMARELO,

LARANJA, VERMELHO, 1, 2 3, etc). Quando da ocorrência deste, deve-se alterar

automaticamente configurações específicas de funções do OMS, tais como: Previsão de término

das interrupções, algorítmo do TCS, validação de registros de tempo real, etc.

RO 4.14.03 TCS em modo de alerta Deve alterar comportamento do algorítmo TCS, para todos os casos, ou apenas as regiões

(geográfica ou elétrica) que estejam no determinado nível de alerta.

RO 4.14.04 TCS em modo de alerta Deve desconsiderar todas interrupções ou de determinadas regiões, sem tempo de previsão,

visto que o operador não poderá administrar todos registros por um período.

RO 4.14.05 Restrição de alertas Deve permitir parametrizar restrição de alertas por mensagem texto, referente a serviços com

CHI menos comprometidos.

RO 4.14.06 Relatório Eventos

Severos

Deve permitir emitir relatório de evento severo, ocorrido durante o período de duração de um

determinado alerta (Ex. Relatório do ALERTA VERMELHO 11/09/2001).

4.15 Paineis de Acompanhamento


customização

Atende COM

customização

RO 4.15.01 Visão Recomposições Deve permitir a visão gerencial de acompanhamento das recomposições importantes com

informações sobre a rede, equipes e consumidores desligados, etapas de reestabelecimento,

área responsável principal pelo andamento de reestabelecimento.

RO 4.15.02 Visão Dashboard Deve exibir gráficos em frames contendo CHI acumulados, instantâneo, serviços por hora,

interrupções abertas, interrupções por situação, etc. Exemplo: Dashboard COPEL. Este deve

estar disponível no ambiente WEB(https://www.copel.com/dtrweb) com restrições de login.

RO 4.15.03 Visão Reclamações Deve permitir painel gráfico com visão gerencial de quantidade de reclamações solicitadas por

período e regiões parametrizadas (Exemplo: Por mesa de controle).

RO 4.15.04 Visão Ocupação

Operadores

Deve permitir painel com visualização do resumo das atividades em trâmite com cada operador e

(ou) mesa de controle com mais de um operador. Exemplo: Resumo de recomposições, alarmes

do DMS, OMS, equipes em trâmite de serviços, consumidores desligados.

RO 4.15.05 Visão Mapa Calor Deve permitir painel gráfico tipo mapa de calor geográfico, baseando-se nos parâmetros de

consumidores afetados, equipes em regime de trabalho, equipamentos atuados, quantidade de

serviços, quantidade de reclamações.

RO 4.15.06 Visão NDS Deve permitir visualização dos trechos interrompidos aguardando regularização pelas equipes de

manutenção, contendo as etapas de previsão para o reestabelecimento.

RO 4.15.07 Visão linha do tempo de

Serviços

Deve permitir a geração de gráfico com resumo de tempos de atendimento de serviços incluídos,

com os seguintes tempos: (A) geração, (B) despacho, (C) aguardando equipe, (D) saída, (E)

deslocamento inicial, (F) execução, (G) deslocamento final.

RO 4.15.08 Visão linha do tempo de

Serviços

Deve permitir a geração de gráfico com parâmetros configuráveis de serviços como: tempo de

mobilização (tempo entre a geração do serviço e o primeiro deslocamento da equipe), número de

consumidores afetados (1 a 100, 100 a 1000. etc), entre outros.

4.16 Alarmes Relacionados ao OMS


customização

Atende COM

customização

RO 4.16.01 Geral Deve possuir uma tela de ALARMES automáticos baseando-se em parâmetros de algumas

funcionalidades, ou como também uma mensagem livre agendada por um usuário.

RO 4.16.02 Exemplos de Alarmes Exemplo ALARMES (configuráveis):

Mensagem LIVRE originada equipe de campo (computação móvel);

Mensagem LIVRE originada por usuário OMS (agendada);

Interrupção ABERTA com necessidade de NDS;

Trecho recomposto com necessidade de NDS;

Serviço significativo (parametrizável) com tempo de reestabelecimento expirado;

Interrupção com tempo de reestabelecimento expirado;

OMB prevista para execução;

Interrupção que afeta UC VIP (caracterização VIP configurável);

Interrupção gerada por abertura de equipamento (DMS);

Nível de alerta disparado;

Reclamação tipo Poste Quebrado/Cabo Rompido associada a recomposição em andamento;

Reclamação tipo Poste Quebrado/Cabo Rompido sem associação a recomposição em

andamento;

RO 4.16.03 Priorização de Alarmes Os ALARMES devem ser exibidos em ordem de priorização, podendo haver filtros das listagem.

RO 4.16.04 Histórico de Alarmes Os ALARMES devem possuir histórico de leitura e reconhecimento pelo usuário do OMS.

RO 4.16.05 Link com documentos

associados

Os ALARMES devem possuir link de acesso aos documentos quando associação existente.

Através do alarme, deverá ser possível ações a inclusão e consulta de documentos pertinentes.

RO 4.16.06 Visibilidade e Sons Deve permitir configurar o tipo de sinalização do ALARME (característica visual, e audível).

4.17 Visão ortogonal


customização

Atende COM

customização

Pg. 42 de 43


RO 4.17.01 Geral Elaborar a geração da visão ortogonal automática a partir da base GEO

RO 4.17.02 Diagrama Unifilar/Trifilar Deve exibir o arranjo elétrico, considerando a situação real da configuração de equipamentos e

trechos, garantindo a segurança operacional. O diagrama deverá possuir camadas e(ou)

simbologias para visões unifilar ou trifilar, baseando-se no GEO (rede geoferenciada),

possibilitando as funções de zoom e visões em escala.

RO 4.17.03 Diagrama Esquemático Deve exibir um diagrama esquemático, demonstrando o entendimento do arranjo elétrico, de

forma resumida, garantindo o entendimento e segurança operacional.

RO 4.17.04 Geral Deve modelar topologia por camadas de área elétrica (AT, MT e BT), com as demais simbologias

(equipes de campo, equipamentos operacionais, logradouros, bairros, ruas, estradas localidades

UC's VIPS, UC's de Serviço Básico a População, Hospitais, etc).

RO 4.17.05 Camadas Deve permitir inclusão e alteração de simbologias e cores que serão representadas nos

diagramas (Ex. Ocorrência, serviço, reclamação, equipe, aterramento temporário, trecho

desenergizado, trecho em manutenção, trecho em inspeção, UC's VIP's, Serviço público básico,

hospitais, etc).

RO 4.17.06 Alimentadores Deve possibilitar a configuração de cores dos trechos energizados para cada alimentador.

RO 4.17.07 Visualização de

Prioridades

Deve permitir a configuração da exibição de camadas em tempo real, de visualização das

simbologias, inclusive as prioritárias (Ex. Situações de risco, Período expirado, etc), quando

necessário.

RO 4.17.08 Visualização das

grandezas elétricas

Deve representar diagramas diferenciados visuais, em aspectos de proteção e área protegida,

nível de tensão e carregamento (quedas de tensão), trifásico e monofásicos, diferenciando AT,

MT e BT, alimentadores/equipamentos fontes e seus cascatas (Ex. Cores e

simbologias/preenchimento do traçado).

RO 4.17.09 Visão Geográfica Deve representar camada ortofotos, fotos por satélite e visão panorâmica (caso possua serviço

de mapas fornecido).

RO 4.17.10 Representação Deve permitir ao usuário, interatividade com as simbologias, gráficos, diagramas e esquemáticos

dispostos, afim de acessar os registros a estes objetos associados.

4.18 Modelagem da topologia de rede


customização

Atende COM

customização

RO 4.18.01 Geral Software modela topologia de rede para operações de campo seguras e eficientes, relacionadas

à recomposição de sistemas em caso de falhas.

RO 4.18.02 Geral Deve representar diagrama diferenciados visuais, em aspectos de proteção e área protegida,

nível de tensão e carregamento (quedas de tensão), trifásico e monofásicos,

alimentadores/equipamentos fontes e seus cascatas (Ex. Cores e simbologias/preenchimento do

traçado).

RO 4.18.03 Geral Deve modelar topologia por camadas de área elétrica (AT, MT e BT), com as demais simbologias

sendo equipes de campo, equipamentos operacionais, logradouros, bairros, ruas, estradas

localidades UC's VIPS, UC's de Serviço Básico a População, Hospitais, etc.

RO 4.18.04 Geral Deve representar camada ortofotos, fotos por satélite e visão paronâmica (caso serviço

fornecido).

4.19 Integração


customização

Atende COM

customização

Pg. 43 de 43

Documents

ANEXO I - LISTA DE REQUISITOS FUNCIONAIS OBRIGATÓRIOS rv01