Pep 000 55105 3

3 11.07.
05 Revisão Geral EETP HC MDP WSF

2 20.05.04 Revisão para inclusão do SAGE e atualização de hardwares EETP MDP MDP WSF
1 07.03.03 Revisão geral pela RD - D.Eng.0053/03 EETP LJMM LJMM WSF
0A DEZ/01 Atualização EETP DRG DRG WSF
0 AGO/01 Emissão Inicial EETP DRG DRG WSF
REV. DATA DESCRIÇÃO PROJ. CONF. VISTO APROV.
CENTRAIS ELÉTRICAS DO NORTE DO BRASIL S.A

SUPERINTENDÊNCIA DE EXPANSÃO DA TRANSMISSÃO - EET
GERÊNCIA DE PROJETO DE PROTEÇÃO, CONTROLE E AUTOMAÇÃO - EETP
PROJ. DATA No
AGO/01
ESPECIFICAÇÃO TÉCNICA PARA PEP-000-55105
VISTO DATA FORNECIMENTO DE EQUIPAMENTOS NÍVEL 2
AGO/01
(SALA DE CONTROLE DE SPCS)
APROV. DATA
WSF AGO/01 Rev. 3
CENTRAIS ELÉTRICAS DO NORTE DO BRASIL S/A - ELETRONORTE
SISTEMAS DE PROTEÇÃO, CONTROLE E SUPERVISÃO
ESPECIFICAÇÃO TÉCNICA DE EQUIPAMENTOS DO NÍVEL 2
ÍNDICE
1 OBJETIVO 4
2 REQUISITOS GERAIS 5
2.1 SUBSISTEMA DE INTEGRAÇÃO (SIN) 5

2.2 SUBSISTEMA DE SUPERVISÃO E OPERAÇÃO (SSO) 6
2.3 SUBSISTEMA DE PROCESSAMENTOS ESPECIAIS (SPE) 7
2.4 SUBSISTEMA DE COMUNICAÇÃO (SCO) 8
2.5 SUBSISTEMA DE SUPORTE À MANUTENÇÃO (SSM) 8
2.6 SUBSISTEMA DE ENGENHARIA (SEG) 9
2.6.1 GERAL 9
2.6.2 CONFIGURADOR DA PROTEÇÃO. 10
2.6.3 CONFIGURADOR DA BASE DE DADOS. 10
2.6.4 EDITOR GRÁFICO DE DIAGRAMAS SINÓTICOS. 12
2.6.5 CONFIGURADOR DE COMUNICAÇÃO 13
2.6.6 CONFIGURADOR DE SEGURANÇA DE ACESSO 13
2.6.7 CONFIGURADOR DE TENDÊNCIA 14
2.6.8 CONFIGURADOR DE RELATÓRIOS 14
2.6.9 DESENVOLVIMENTO DE ROTINAS 14
2.7 SUBSISTEMA CONCENTRADOR DE INFORMAÇÕES (SCI) 16
2.7.1 GERAL 16
2.7.2 ARMAZENAMENTO DAS INFORMAÇÕES 17
2.7.3 PARAMETRIZAÇÃO E VISUALIZAÇÃO LOCAL 18
2.8 SUBSISTEMA CONCENTRADOR DE MEDIÇÃO DE FATURAMENTO (SCM) 18
2.8.1 GERAL 18
2.8.2 ARMAZENAMENTO DAS INFORMAÇÕES 19
2.8.3 PARAMETRIZAÇÃO E VISUALIZAÇÃO LOCAL 19
2.9 O SUBSISTEMA DE SINCRONISMO (SSI) 19
2.10 VIA DE DADOS (VDD) 20
2.11 AGRUPAMENTO DE SUBSISTEMAS 20
3 REQUISITOS DE SOFTWARE 22
3.1 SISTEMA OPERACIONAL 22

3.2 SOFTWARE DE SUPERVISÃO 23
3.3 PROTOCOLOS DE COMUNICAÇÃO DA REDE LOCAL - VDD 23
3.4 SOFTWARE DE COMUNICAÇÃO 24
3.5 SOFTWARE DE DESENVOLVIMENTO 24
4 REQUISITOS DE HARDWARE 26
4.1 MICROCOMPUTADORES 26
4.1.1 GABINETE 26
4.1.2 MEMÓRIA DE MASSA 26
4.1.3 MONITORES E CONTROLADORES DE VÍDEO 26
Pág. 2/29
4.1.4 RECURSOS MULTIMÍDIA 27

4.2 IMPRESSORAS 27
4.3 REDE LOCAL 27
4.4 FIBRAS ÓPTICAS 28
4.5 RECEPTORES GPS 28
4.6 ALIMENTAÇÃO DOS SUBSISTEMAS DO NÍVEL 2 29
Pág. 3/29
1 OBJETIVO
Este documento tem por objetivo estabelecer os requisitos técnicos para o
fornecimento de equipamentos do nível 2 (sala de controle) de Sistemas de
Proteção, Controle e Supervisão - SPCS’s para Subestações da
ELETRONORTE, devendo ser lido em conjunto com a ESPECIFICAÇÃO
TÉCNICA GENÉRICA PARA SISTEMAS DE PROTEÇÃO, CONTROLE E
SUPERVISÃO, número PEP-000-55103 (ETG), o Edital de Licitação e a
Especificação de Aplicação - EA correspondentes ao fornecimento em questão.
Pág. 4/29
2 REQUISITOS GERAIS
Os requisitos indicados nesta especificação se referem a subsistemas funcionais
que realizam as funções de Interface Homem Máquina, de comunicação interna
e de comunicação com demais níveis hierárquicos, de sincronização, de
parametrização e de configuração dos demais componentes dos SPCS’s das
subestações. Estes subsistemas funcionais são denominados SIN’s -
Subsistemas de Integração, SSO’s - Subsistemas de Supervisão e Operação,
SPE’s - Subsistemas de Processamentos Especiais, SCO's - Subsistemas de
Comunicação, SSM’s - Subsistemas de Suporte à Manutenção, SEG’s -
Subsistemas de Engenharia, SCI’s - Subsistemas de Concentração de
Informações, SSI’s - Subsistemas de Sincronismo e a Via de Dados - VDD.
A descrição dos subsistemas que se segue é essencialmente funcional, devendo
cada proponente oferecer os seus equipamentos e sistemas que atendam aos
requisitos, condições e restrições descritos na EA, nesta ET e na ETG.
2.1 SUBSISTEMA DE INTEGRAÇÃO (SIN)

Os Subsistemas de Integração serão responsáveis pela integração funcional de
SPD’s, SCD’s e outros sistemas digitais existentes ou fornecidos por terceiros ao
SPCS da SE, quando estes SPD’s, SCD’s e outros sistemas digitais existentes
ou fornecidos por terceiros não puderem se integrar diretamente ao SPCS objeto
deste fornecimento.
As interfaces físicas e lógicas a ser(em) utilizada(s) estará(ão) definida(s) na
Especificação de Aplicação. Os SIN deverão ser capazes de processar mais de
um protocolo de comunicação, de modo a poder integrar equipamentos
utilizando protocolos distintos.
Este subsistema deverá ser dotado de todos os recursos para permitir à
ELETRONORTE desenvolver e implantar outros Protocolos de Comunicação e
integrá-los funcionalmente ao sistema objeto deste fornecimento.
Para tanto, estes subsistemas deverão:
− Enviar e receber informações de e para os equipamentos de terceiros
a ele conectados,
− Comunicar-se com os demais dispositivos conectados à VDD
enviando dados, recebendo dados e respondendo às requisições dos
outros dispositivos,
− Sincronizar seu relógio calendário interno com sinal padrão de GPS
recebido diretamente ou através dos Subsistemas de Sincronismo
(SSI).
O SIN não deverá impor limitações intrínsecas de qualquer tipo quanto aos
sinais a serem adquiridos, desde que tais dados estejam disponíveis nos
equipamentos a serem integrados ao SPCS. Estes dados deverão ser
processados com os mesmos recursos utilizados para processar os dados
provenientes de subsistemas integrados ao SPCS diretamente através da VDD.
Deverá ser possível executar operações de Download e Upload do software,
lógica ou dados de parametrização implementados neste subsistema a partir do
Subsistema de Engenharia do SPCS.
Pág. 5/29
2.2 SUBSISTEMA DE SUPERVISÃO E OPERAÇÃO (SSO)

Os Subsistemas de Supervisão e Operação (SSO) serão responsáveis por
implementar uma IHM de alto nível para o operador da SE, permitindo facilidade,
rapidez e segurança na operação do sistema.
As telas, menus, relatórios, mensagens de erros e advertências, além de
comandos deverão ser apresentados em português, com exceção apenas a
alguns termos técnicos usualmente expressos em inglês.
As telas do monitor de vídeo deverão ser gráficas, com resolução mínima de
1024 x 768 pixels e trabalhar com paleta de cores de 24 bits.
Funcionalmente, as telas deverão ser divididas em duas regiões, de acordo com
o estabelecido no documento PADRÃO PARA DESENVOLVIMENTO DE
INTERFACE HOMEM MÁQUINA PARA EQUIPAMENTOS DO NÍVEL 2, número
PEP-000-55107:
− Região de uso dedicado, onde estarão colocadas as informações
comuns a todas as telas tais como data, hora e macro-alarmes.
− Região de uso geral, onde serão exibidos os diagramas sinóticos da
SE, sumários, unifilares, tendências e outros.
Os SSO’s deverão possuir também dispositivo apontador (“mouse” ou “tracking
ball”), teclado alfanumérico e impressora de modo a suportar a implantação de
todas as suas funções.
Para desempenhar as suas funções os SSO’s deverão ser capazes de:
− Exibir os diagramas sinóticos do sistema,
− Permitir a operação dos equipamentos do processo,
− Permitir gerenciar os alarmes do processo,
− Permitir a entrada manual de dados,
− Exibir gráficos de tendência instantânea e histórica,
− Exibir sumários e históricos de alarmes,
− Exibir diagnósticos dos equipamentos do processo,
− Imprimir relatórios periodicamente ou sob comando do operador ,
− Imprimir “hard-copies” sob comando do operador,
− Possibilitar a inibição e liberação de alarmes ou macro alarmes,
− Executar e exibir cálculos estatísticos sobre o comportamento de
todos os subsistemas componentes do sistema conectados à VDD,
inclusive a própria VDD.
− Comunicar com os demais dispositivos conectados à VDD enviando
dados, recebendo dados e respondendo às requisições dos outros
dispositivos,
(SSI).
Pág. 6/29

2.3 SUBSISTEMA DE PROCESSAMENTOS ESPECIAIS (SPE)

Os Subsistemas de Processamentos Especiais serão os responsáveis pela
execução dos algoritmos de controle e modelamentos matemáticos aplicáveis,
tais como Controle Automático de Geração e Controle Automático de Tensão.
Este subsistema deverá permitir o desenvolvimento e operacionalização de
novas tarefas aplicativas por parte do usuário. O software de programação
utilizado para o desenvolvimento de novas tarefas deverá ser amigável e utilizar
linguagem estruturada de programação, preferencialmente o C++.
Para desempenhar as suas funções o SPE deverá ser capaz de:
− Exibir os diagramas sinóticos e tabulares dos controles por ele
executados (*),
− Permitir a entrada manual de dados (parâmetros de controle) (*),
− Permitir a execução dos comandos inerentes aos modelamentos
matemáticos (*),
− Exibir gráficos de tendência instantânea e histórica dos pontos
inerentes aos modelamentos matemáticos (*),
− Exibir sumário e histórico de alarmes dos pontos inerentes aos
modelamentos matemáticos (*),
− Imprimir periodicamente ou sob comando do operador relatórios e
“hard-copy” (*),
− Prover kit de desenvolvimento, ferramentas e biblioteca de rotinas
que permita o desenvolvimento de novas rotinas com recursos para
leitura e gravação de dados no banco de dados do sistema em tempo
real sem interferência nas demais rotinas em execução,
dispositivos,
(SSI).
Observação: As funções acima listadas e marcadas com um (*)
poderão ser executadas pelos SSO’s.
O FORNECEDOR deverá garantir que o conjunto Subsistema de
Processamentos Especiais + Kit de Desenvolvimento + Ferramentas contém
todos os recursos necessários e suficientes para permitir o desenvolvimento,
depuração, implantação e avaliação de desempenho de tarefas aplicativas e
modelamentos matemáticos processados em tempo real.
Pág. 7/29
2.4 SUBSISTEMA DE COMUNICAÇÃO (SCO)

Os Subsistemas de Comunicação das SE’s deverão ser duais, trabalhando em
regime “hot-standby”, e serão os responsáveis pela troca de informações entre o
Sistema de Supervisão e Controle da SE e outros sistemas digitais de nível
hierárquico superior tais como COL’s, COT ou ONS, através de linhas
dedicadas. Estes subsistemas deverão implementar facilidades que permitam o
total telecontrole da instalação e deverão ser configuráveis individualmente
quanto às informações que serão intercambiadas e quanto ao protocolo que
será utilizado (no caso de haver mais de um protocolo residente no subsistema).
O protocolo de comunicação a ser utilizado para as trocas de informações com o
COL e o COT deverá ser o IEC-870-5-104.
Para cada conexão com os sistemas digitais de nível hierárquico superior os
SCO’s deverão prever vias de comunicação duplicadas trabalhando em regime
“Hot-Standby”.
Estes subsistemas deverão permitir o desenvolvimento e operacionalização de
novos protocolos de comunicação por parte do usuário.
Para desempenhar as suas funções, os SCO’s deverão ser capazes de:
− Receber comandos do nível hierárquico superior,
− Operar dois a dois em regime “Hot-Standby”,
− Verificar a integridade e a validade dos comandos recebidos,
− Buscar as informações solicitadas pelo nível hierárquico superior na
Via de Dados.
− Enviar os dados solicitados ao nível hierárquico superior.
dispositivos,
(SSI).
2.5 SUBSISTEMA DE SUPORTE À MANUTENÇÃO (SSM)

O Subsistema de Suporte à Manutenção será o responsável por implementar
uma interface dedicada para as equipes de manutenção da Subestação. A base
de dados deste subsistema deverá ser estruturada e relacional permitindo o
acesso por meio de linguagem estruturada (SQL) e também permitir o acesso
através de softwares de mercado tais como planilhas eletrônicas e pacotes de
análise estatística.
Para desempenhar suas funções, o SSM deverá ser capaz de:
− Exibir informações do banco de dados sob a forma de gráficos de
linha, barras, Paretto e etc.,
− Exibir informações do histórico do sistema elétrico,
Pág. 8/29
− Exibir informações do histórico de operação de disjuntores,

− Exibir informações de tempo de funcionamento de equipamentos,
− Imprimir sob comando do operador ou periodicamente relatórios de
histórico do sistema, de operação dos disjuntores e de funcionamento
de equipamentos,
dispositivos.
2.6 SUBSISTEMA DE ENGENHARIA (SEG)
2.6.1 GERAL
O Subsistema de Engenharia será o responsável por permitir alterações e novas
implantações nos dispositivos do SPCS. As funções deste subsistema deverá
possuir restrição de acesso. Por motivo de segurança, o SEG deverá trabalhar
de preferência “off-line”, logicamente desconectado da Via de Dados. As
alterações necessárias deverão ser efetuadas, testadas e validadas antes da
execução do “download” para o dispositivo que irá receber a alteração. De
preferência o “download” deverá ser executado através da Via de Dados desde
que o fornecedor comprove e garanta que, nestas situações, não haverá
nenhuma degradação na performance do sistema.
Para desempenhar as suas funções, o SEG deverá ser capaz de:
− Permitir a alteração, registro e exclusão dos pontos da base de dados
do Sistema.
− Permitir a alteração no desenho dos diagramas sinóticos tanto na
parte fixa quanto nas animações associadas,
− Permitir a alteração, registro, exclusão e ajustes dos esquemas de
proteção e parâmetros das UPD’s,
− Permitir a alteração, registro e exclusão de intertravamentos,
seqüenciamentos e automatismos,
− Permitir a alteração, registro e exclusão de gráficos de tendência
instantânea e histórica pré-formatados,
− Permitir a formatação, alteração, registro e exclusão de relatórios
impressos,
− Permitir a alteração, registro e exclusão de grupos e usuários para
controle de acessos,
− Prover um ambiente de simulação para teste e validação das
alterações e implantações,
− Gerar automaticamente a documentação da base de dados e dos
esquemas de proteção e controle,
Pág. 9/29
− Permitir a importação e exportação de dados de/para planilhas

eletrônicas e gerenciadores de banco de dados disponíveis no
mercado (preferencialmente EXCEL e ACCESS),
− prover ferramentas e utilitários de desenvolvimento de protocolos e
outras aplicações,
− Permitir o desenvolvimento de “drivers” de comunicação tanto para os
SCO’s quanto para os SIN’s,
− Permitir o desenvolvimento de outras aplicações inclusive
modelamentos matemáticos em tempo real,
− Executar operações de Download e Upload de software, lógicas (de
proteção e controle) dados de parametrização e etc em todos os
subsistemas cujos softwares de parametrização são processados
neste subsistema. Os arquivos adquiridos através de operações de
Upload deverão ser editáveis pelo usuário em todos os recursos
disponibilizados pelo software de configuração / programação /
parametrização dos diversos subsistemas.
dispositivos.
O FORNECEDOR deverá garantir que o conjunto Subsistema de Engenharia +
Kit de Desenvolvimento + Ferramentas contém todos os recursos necessários e
suficientes para permitir o desenvolvimento, depuração, implantação e avaliação
de desempenho de modelamentos matemáticos e protocolos de comunicação,
proprietários ou não, que utilizem portas padrão de mercado (EIA RS-232C, EIA
RS-485, Ethernet e outras).
Todos os programas, rotinas, configuradores, utilitários e etc. componentes do
Subsistema de Engenharia deverão permitir as operações “on-line” de download
(gravação) e upload (leitura) de programas, rotinas e parâmetros executadas
diretamente de todos os dispositivos finais do SPCS (relés de proteção,
unidades de controle, unidades de comunicação, unidades de supervisão e
operação, unidades de integração e etc.).
2.6.2 CONFIGURADOR DA PROTEÇÃO.

Consiste do conjunto dos recursos disponíveis para a parametrização dos
SPD’s, estabelecimento de estratégias de proteção e outros. O configurador da
Proteção deverá ter acesso direto aos SPD’s, de preferência via a VDD. Os
configuradores de proteção deverão ser compostos por telas amigáveis com
campos para preenchimento de valores e seleção de opções de atuação, de
modo a facilitar e conduzir os trabalhos de parametrização dentro dos requisitos
de segurança necessários.
2.6.3 CONFIGURADOR DA BASE DE DADOS.

Consiste no conjunto dos recursos a serem disponibilizados para permitir a
inserção, alteração e exclusão dos pontos adquiridos do processo ou calculados
internamente. Deverão existir no mínimo configuradores para os seguintes
pontos:
Pág. 10/29
− Entradas analógicas, com no mínimo os seguintes campos de

inicialização:
− “Tag”,
− Setor, grupo e macro-alarme,
− Texto,
− Unidade de engenharia,
− Limites superior e inferior ou relação do TC e/ou TP,
− Quatro limites de alarmes (muito baixo, baixo, alto e muito alto)
e histerese,
− Banda Morta,
− Oito seletores de alarmes (um para a violação de cada limite
no sentido ascendente ou descendente),
− Seletores para cálculo de valores médios,
− Seletores para cálculo de valores integrados,
− Nível de prioridade
− Entradas de pulsos, com no mínimo os seguintes campos:
− “Tag”,
− Texto,
− Fator grandeza/pulso,
− Limite superior de integração,
− Banda morta.
− Entradas digitais, com no mínimo os seguintes campos:
− “Tag”,
− Texto,
− Seletor variável normal ou rápida (SOE),
− Texto para estado lógico ON,
− Texto para estado lógico OFF,
− Seletor de alarme na transição ON à OFF,
− Seletor de alarme na transição OFF à ON,
− Seletor de evento na transição ON à OFF,
− Seletor de evento na transição OFF à ON,
− Seletor para contador de transições,
− Ajustes do tratamento de entrada batente
Pág. 11/29
− Saídas digitais, com no mínimo os seguintes campos;

− “Tag”,
− Texto,
− Texto para estado lógico ON,
− Texto para estado lógico OFF,
− Seletor de alarme na transição ON à OFF,
− Seletor de alarme na transição OFF à ON,
− Seletor de evento na transição ON à OFF,
− Seletor de evento na transição OFF à ON,
− Seletor para contador de transições,
− Valores calculados, com no mínimo os seguintes campos:
− “Tag”,
− Texto,
− Fórmula de cálculo (numérico e/ou lógico),
− Limites superior e inferior,
− Banda Morta,
− Quatro limites de alarmes (muito baixo, baixo, alto e muito alto)
e histerese,
− Oito seletores de alarmes (um para a violação de cada limite
no sentido ascendente ou descendente)
− Seletor para cálculo de valores médios,
− Seletor para cálculo de valores integrados,
O Configurador da Base de Dados deverá permitir a importação e exportação
dos parâmetros de configuração da Base de Dados de/para planilhas eletrônicas
e gerenciadores de banco de dados disponíveis comercialmente, de preferência
em formatos compatíveis com os programas EXCEL e ACCESS, de modo a
facilitar os trabalhos de configuração e verificação das bases de dados.
2.6.4 EDITOR GRÁFICO DE DIAGRAMAS SINÓTICOS.

Consiste no conjunto dos recursos para permitir a implantação e manutenção
dos diagramas sinóticos do sistema.
O Editor gráfico deverá ser orientado para objetos e permitir a mudança dos
atributos de cada objeto já construído sem a necessidade de apagar ou
redesenhar o objeto. Os objetos deverão poder ser armazenados em biblioteca
de símbolos para posterior utilização. O sistema deverá ser fornecido com uma
Pág. 12/29
biblioteca de símbolos especificamente desenvolvida para o setor elétrico que

atenda na íntegra o disposto no documento PADRÃO PARA
DESENVOLVIMENTO DE INTERFACE HOMEM MÁQUINA PARA
EQUIPAMENTOS DO NÍVEL 2, número PEP-000-55107.
O Editor gráfico deverá possuir no mínimo as seguintes funções:
− Desenho de linhas,
− Desenho de retângulos cheios e vazados,
− Desenho de elipses cheias e vazadas,
− Desenho de arcos cheios e vazados,
− Desenho de polígonos abertos,
− Desenho de polígonos fechados cheios e vazados,
− Desenho de textos com fontes escalonáveis do tipo “TrueType” ,
− Seleção de espessura e cor de linha, cor de enchimento,
− Seleção de estilo de linha (inteira, pontilhada, tracejada, etc.),
− Seleção de estilo de enchimento (sólido e padrões),
− Manipulação de “bitmaps”,
− escalonamento de objetos (aumentar, diminuir, reposicionar),
− definição de “softkeys”,
− encadeamento de áreas sensíveis,
− Configurador de animações:
− Visibilidade,
− Pisca,
− Deslocamento horizontal e vertical,
− Escalonamento,
− Giro livre,
− Cor de linha e cor de fundo.
2.6.5 CONFIGURADOR DE COMUNICAÇÃO

Consiste do conjunto dos recursos para permitir o registro, alteração e exclusão
dos pontos do processo que deverão ser intercambiados entre os diversos
Níveis Hierárquicos do Sistema através dos subsistemas SCO e SIN. O
Configurador de Comunicação deverá ser composto por janelas de configuração
contendo campos para preenchimento e campos para seleção de opções, de
modo a facilitar e conduzir os trabalhos de configuração.
2.6.6 CONFIGURADOR DE SEGURANÇA DE ACESSO

Consiste do conjunto dos recursos para permitir o registro, alteração e exclusão
dos grupos de acesso, seus privilégios e o cadastro dos usuários. No mínimo os
seguintes parâmetros deverão poder ser inicializados:
Pág. 13/29
− Determinação dos grupos de acesso, com a associação dos seus

direitos de acesso às funções do sistema.
− Cadastramento dos usuários com nome completo, nome de acesso,
senha e a associação a um grupo de acesso já inicializado.
O Configurador de acesso deverá permitir a documentação automática dos seus
parâmetros de inicialização.
2.6.7 CONFIGURADOR DE TENDÊNCIA

Consiste do conjunto de recursos para permitir a determinação dos pontos do
processo que irão compor os diversos gráficos de tendência e também o seu
período de amostragem. No mínimo os seguintes parâmetros deverão poder ser
inicializados:
− Nome do gráfico,
− Pontos de processo que irão compor cada gráfico,
− Limites Superior e Inferior de exibição,
− Associação de cor para cada ponto do processo,
− Período de aquisição dos pontos associados e traçado das curvas.
É desejável que gráficos de tendência possam ser configurados livremente pelo
operador do SSO sem necessidade de utilização do SEG.
2.6.8 CONFIGURADOR DE RELATÓRIOS

Consiste do conjunto dos recursos para permitir a implantação e manutenção
dos relatórios impressos a serem gerados pelo sistema, bem como a
determinação do modo de comando da impressão (periódico, sob solicitação do
operador, etc.).
O configurador de relatórios deverá ser composto por um editor gráfico que
permita formatar os relatórios e atribuir as características dos diversos campos
que serão impressos pelo sistema. Os campos poderão ser valores instantâneos
do processo ou valores históricos (médias, contadores, integradores, etc.).
2.6.9 DESENVOLVIMENTO DE ROTINAS

2.6.9.1 Rotinas de Controle
Consiste no conjunto de recursos a serem disponibilizados para permitir a
implantação de rotinas de intertravamentos, seqüenciamentos e automatismos
dos equipamentos do sistema através de programas de controle. A linguagem
de programação utilizada para a programação das rotinas de controle deverá ser
do tipo “ladder”, “grafcet”, ou outra que atenda os requisitos da norma IEC-
61131-3. O Configurador de Controle deverá ter acesso direto aos subsistemas
utilizados para implementar funções de controle, de preferência via VDD.
O Configurador de Controle deverá possuir um editor de programas, de
preferência gráfico, que trabalhe com símbolos e permita inserir comentários
específicos ao longo do código dos programas.
A linguagem de controle deverá possuir no mínimo os seguintes recursos de
programação:
Pág. 14/29
− Operadores lógicos (“e”, “ou”, “ou exclusivo”, “negação”, etc.)

− Operadores aritméticos (soma, subtração, multiplicação, divisão, etc.)
− Operadores trigonométricos (seno, coseno, tangente, etc.)
− Operadores de comparação (igual, maior, menor, maior ou igual, etc.)
− Temporizadores e contadores
− Funções de controle PID
− Referenciar pontos do processo (tanto entradas quanto saídas de
sinais) e pontos internos para leitura e gravação.
− manipular tabela de dados,
O configurador de Rotinas de Controle deverá possuir recursos de
documentação automática tais como listagem dos programas com comentários e
referências simbólicas livremente configuráveis pelo usuário, relação de
entradas e saídas, relação de pontos internos, diagramas de referências
cruzadas e outros. Deve possuir também recursos para depurar o programa
tanto em modo simulação quanto em tempo real (visualizar estado atual, forçar
valores e estados do processo). Devem também ser disponíveis listagem dos
pontos forçados ou com a varredura desabilitada.
2.6.9.2 Rotinas Genéricas - Modelamentos Matemáticos
Consiste do conjunto dos recursos para permitir o desenvolvimento, teste,
implantação e verificação do desempenho de rotinas aplicativas tais como
modelamentos matemáticos, simuladores e outros utilizando os dados do
processo coletados em tempo real, podendo interferir no andamento do
processo através da alteração de “set-points” ou da comutação de estado dos
equipamentos (ligar / desligar - abrir / fechar).
Os recursos oferecidos deverão no mínimo ser compostos por:
− Editor de programas com recursos típicos de editores de texto padrão
Windows, do tipo cortar, colar, copiar, procurar, substituir e outros,
− Linguagem de programação estruturada, de preferência o C++,
− Interface para possibilitar o desenvolvimento de aplicativos externos
que interajam em tempo real com o sistema através de chamadas de
bibliotecas API´s (“Application Program Interface”) de forma a não ser
necessárias ligações estáticas e parada do sistema para inclusão de
novos aplicativos,
− Biblioteca de rotinas, com recursos para manipular portas seriais,
aplicativos TCP/IP (“Socket”, RPC, Telnet, FTP), arquivos em disco,
gerenciamento de tempo, acesso à base de dados em tempo real,
etc.,
− Possuir recursos suficientes para trabalhar com conexões por linha
discada e modem (discagem e atendimento automáticos, dentre
outros),
− Possuir recursos para permitir a configuração e o manuseio direto dos
sinais de controle de portas seriais (CTS, RTS, DTR, XON, XOFF,
etc.),
Pág. 15/29
− Compilador de programas, com recursos para transformar os códigos

fonte em linguagem de máquina (módulo objeto),
− Ligadores, com recursos de criar os módulos executáveis a partir dos
módulos objeto e biblioteca de rotinas,
− Depurador simbólico com recursos de execução passo a passo,
monitoramento de valor de variáveis, etc.
2.6.9.3 Protocolos de Comunicação

Consiste do conjunto dos recursos para permitir o desenvolvimento, teste,
implantação e verificação de desempenho de “drivers” de comunicação com
outros dispositivos digitais. Os “drivers” de comunicação deverão poder ser
desenvolvidos tanto para os Subsistemas de Comunicação (SCO’s) quanto para
os Subsistemas de Integração (SIN’s) e Subsistemas Concentradores de
Informações (SCI’s).
Os recursos oferecidos deverão no mínimo ser compostos por:
Windows do tipo cortar, colar, copiar, procurar, substituir e outros.
− Linguagem de programação estruturada, de preferência o C++.
bibliotecas API´s (“Application Program Interface”) de forma a não ser
novos aplicativos.
Ethernet, arquivos em disco, gerenciamento de tempo, etc.
discada e modem (discagem e atendimento automáticos dentre
outros),
etc.),
− Possuir recursos para a criação, atracamento, utilização e destruição
de “sockets” padrão para a utilização e controle de portas Ethernet.
− Compilador de programas, com recursos para transformar os códigos
fonte em linguagem de máquina (módulos objeto),
− Depurador simbólico.
2.7 SUBSISTEMA CONCENTRADOR DE INFORMAÇÕES (SCI)
2.7.1 GERAL
O Subsistema Concentrador de Informações será o responsável pela aquisição
das informações de perturbações dos oscilógrafos (SRP’s), dos subsistemas de
análise de qualidade da energia (SQE’s) e dos subsistemas de proteção (SPD’s)
Pág. 16/29
do SPCS. Os protocolos de comunicação utilizados poderão ser os protocolos

específicos dos oscilógrafos, analisadores de qualidade de energia e
subsistemas de proteção, desde que sejam abertos ao usuário e formalmente
documentados.
O SCI deverá permitir o desenvolvimento e operacionalização de novos
protocolos de comunicação por parte do usuário.
Os registros gerados pelos SRP’s e SPD’s deverão ser armazenados em áreas
diferentes daqueles gerados pelos SQE’s.
Para desempenhar as suas funções, o SCI deverá ser capaz de:
− Adquirir automaticamente os registros de perturbações diretamente
dos SRP’s e dos SPD’s tão logo estas informações estejam
disponíveis,
− Adquirir automaticamente os registros de perturbações diretamente
dos SQE’s tão logo estas informações estejam disponíveis,
− Compatibilizar e sincronizar todas as informações (oscilogramas e
eventos digitais) adquiridas formatando-as em arquivos no padrão
COMTRADE,
− Armazenar as informações recebidas dos subsistemas de análise de
qualidade também no formato padrão COMTRADE,
− Processar o software de parametrização e visualização dos dados
coletados dos SRP’s a ele conectados,
coletados dos SQE’s a ele conectados.
− Enviar sob solicitação os arquivos formatados para o Nível
Hierárquico Superior através de linha telefônica discada,
(SSI).
Estes subsistemas deverão estar lógica e fisicamente isolados dos demais
subsistemas da rede.
2.7.2 ARMAZENAMENTO DAS INFORMAÇÕES

As informações das perturbações coletadas deverão permanecer armazenadas
em memória de massa no SCI, mesmo após transferidas para a central de
análise. Deverão ser previstos mecanismos para sobrescrever os registros mais
antigos no caso de falta de espaço para os novos registros que estiverem sendo
gerados, além da possibilidade de se apagar registros selecionados
manualmente pelo operador.
Deverão ser previstos também mecanismos para assegurar a integridade dos
dados coletados e transferidos para o SCI e deste para a central de análise.
Pág. 17/29
A estrutura de dados dos registros coletados para o SCI deverá ser de acordo
com a Norma IEEE C37.111 - “COMMON FORMAT FOR TRANSIENT DATA
EXCHANGE” - “COMTRADE”.
2.7.3 PARAMETRIZAÇÃO E VISUALIZAÇÃO LOCAL

Deverá estar incluído no SCI um Software de Parametrização e Visualização dos
registros de perturbações (tanto dos SRP’s e SPD’s quanto dos SQE’s) com no
mínimo as seguintes características:
− Capacidade de parametrização dos SRP’s e SQE’s conforme os
requisitos estabelecidos no documento ESPECIFICAÇÃO TÉCNICA
DE EQUIPAMENTOS DE OSCILOGRAFIA número PEP-000-55108 e
no documento ESPECIFICAÇÃO TÉCNICA DE EQUIPAMENTOS DE
QUALIDADE DE ENERGIA número PEP-000-55110.
− Deverá ser possível ao usuário selecionar registros residentes no SCI
e visualizá-los no vídeo de forma inteira ou parcial, pela redefinição
de parâmetros tanto no aspecto das coordenadas de tempo como na
especificação dos canais.
− Deverá ser possível o “zoom” escalonado (expansão ou compressão
no eixo de tempo e/ou eixo de amplitude), selecionável pelo usuário.
− Deverão existir no mínimo 3 cursores independentes, cada qual com
a sua respectiva tabela de apresentação de valores e tempo.
− Deverá ser possível exibir e imprimir as informações de pelo menos
até 16 canais por tela e folha de impressão, bem como
concomitantemente de 32 canais digitais.
− Deverá ser possível selecionar uma entre no mínimo 16 cores
possíveis para cada canal.
− Deverá ser possível alterar a posição de apresentação dos registros e
seus canais.
− Deverá ser possível a impressão sob a forma gráfica ou tabular dos
dados armazenados na memória de massa.
2.8 SUBSISTEMA CONCENTRADOR DE MEDIÇÃO DE

FATURAMENTO (SCM)
2.8.1 GERAL
O Subsistema Concentrador de Medição de Faturamento será o responsável
pela aquisição dos dados relativos ao consumo de energia coletados pelos
tarifadores (STA’s). Os protocolos de comunicação utilizados deverão ser
abertos ao usuário e formalmente documentados.
O SCM deverá permitir o desenvolvimento e operacionalização de novos
protocolos de comunicação por parte do usuário.
Para desempenhar as suas funções, o SCM deverá ser capaz de:
Pág. 18/29
− Adquirir cíclica e automaticamente os registros de medição de

faturamento dos STA’s,
− Armazenar as informações recebidas dos tarifadores em formato tipo
texto, aberto ao usuário,
coletados dos STA’s,
− Enviar sob solicitação os arquivos formatados para o Nível
Hierárquico Superior através de linha telefônica discada,
(SSI).
Estes subsistemas deverão estar lógica e fisicamente isolados dos demais
subsistemas da rede.
2.8.2 ARMAZENAMENTO DAS INFORMAÇÕES

As informações das medições de faturamento coletadas deverão permanecer
armazenadas em memória de massa no SCM, mesmo após transferidas para o
Nível Hierárquico Superior. Deverão ser previstos mecanismos para
sobrescrever os registros mais antigos no caso de falta de espaço para os novos
registros que estiverem sendo gerados, além da possibilidade de se apagar
registros selecionados manualmente pelo operador.
Deverão ser previstos também mecanismos para assegurar a integridade dos
dados coletados e transferidos dos STA’s para o SCM e deste para o Nível
Hierárquico Superior.
2.8.3 PARAMETRIZAÇÃO E VISUALIZAÇÃO LOCAL

Deverá estar incluído no SCM um Software de Parametrização e Visualização
dos registros de medições com no mínimo as seguintes características:
− Capacidade de parametrização dos STA’s conforme os requisitos
estabelecidos no documento ESPECIFICAÇÃO TÉCNICA PARA
MEDIÇÃO DE FATURAMENTO, número PEP-000-55109.
− Deverá ser possível ao usuário selecionar registros residentes no SCI
e visualizá-los no vídeo.
− Deverá ser possível exibir e imprimir as informações contidas no
SCM, tanto os dados coletados dos STA’s, quanto os dados de
parametrização.
2.9 O SUBSISTEMA DE SINCRONISMO (SSI)

O Subsistema de Sincronismo (SSI) será responsável por prover sinais para
sincronizar todos os subsistemas do SPCS. O SSI deverá receber sinal padrão
de tempo de satélites GPS - “Global Positioning System” e deverão transmitir os
sinais de sincronismo e a hora oficial para os demais subsistemas do Sistema.
Pág. 19/29
A transmissão do sinal de sincronismo deverá ser feita através de um meio físico

dedicado implementado em fibras ópticas, sendo que a transmissão da hora
oficial poderá ser feita através da Via de Dados. Deverá ser obtida uma
resolução de tempo de 1ms e precisão global de 2ms. Outras soluções para se
efetuar a sincronização dos equipamentos poderão ser aceitas, a critério
exclusivo da ELETRONORTE, desde que atendam o requisitos de resolução e
precisão acima especificados.
2.10 VIA DE DADOS (VDD)

A Via de Dados será responsável por prover um canal de comunicação rápido,
seguro e confiável entre os diversos subsistemas funcionais do Sistema. Esta
VDD poderá ser implementada utilizando diversas tecnologias e protocolos de
comunicação desde que os requisitos de segurança, desempenho e
interoperabilidade sejam integralmente atendidos.
Preferencialmente a Via de Dados deverá ser funcional e eletronicamente
passiva, isto é, não deverá executar nenhum tipo de processamento e nem
possuir “hardware” com componentes ativos. Em qualquer alternativa ou
tecnologia, o meio físico da Via de Dados deverá obrigatoriamente ser
implementado em fibras ópticas.
A topologia da VDD deverá ser tal que falhas singelas em qualquer componente
da mesma não provoquem qualquer perda de dados ou de desempenho. Estas
falhas deverão ser imediatamente detectadas e gerar um alarme
correspondente. Os alarmes gerados deverão indicar claramente o local ou
componente em que ocorreu a falha.
Deverão ser gerados automaticamente relatórios estatísticos do desempenho da
VDD.
2.11 AGRUPAMENTO DE SUBSISTEMAS

Os subsistemas funcionais poderão constituir, cada um, uma unidade
independente de hardware ou estarem diversos deles agrupados em uma
mesma unidade de hardware. O agrupamento dos subsistemas funcionais em
unidades de hardware deverá observar as diretrizes descritas a seguir:
− Quando forem especificados mais de um subsistema funcional de um
determinado tipo para a Subestação, estes subsistemas deverão
estar em unidades de hardware independentes. Não é permitido o
fornecimento de dois subsistemas funcionais idênticos em uma
mesma unidade de hardware.
− Os Subsistemas de Supervisão e Operação (SSO) e Subsistemas de
Processamentos Especiais (SPE) poderão constituir uma mesma
unidade de hardware desde que todos os requisitos funcionais e de
desempenho especificados sejam plenamente atendidos.
− Os Subsistemas de Comunicação (SCO) deverão ser implementados
em unidades de hardware dedicadas.
− Os Subsistemas de Sincronismo (SSI) deverão ser implementados
em unidades de hardware dedicada. Dependendo da tecnologia
utilizada o fornecedor poderá utilizar tantos SSI’s quantos forem
necessários para o Sistema.
Pág. 20/29
− Os Subsistemas de Engenharia (SEG) deverão ser implementados

em unidades de hardware dedicadas. Em subestações onde existem
mais de um SSO, o SEG poderá ser incorporado a um dos SSO’s.
− Os Subsistemas de Integração (SIN) deverão ser implementados em
unidades de hardware dedicadas.
− Subsistemas de Suporte à Manutenção (SSM) e Subsistemas de
Supervisão e Operação (SSO) poderão constituir uma mesma
unidades de hardware desde que todos os requisitos funcionais e de
desempenho especificados sejam plenamente atendidos.
− O Subsistema Concentrador de Informações (SCI) deverá ser
implementado em unidade de hardware dedicada.
− A configuração proposta preferencialmente não deverá conter
subsistemas funcionais ou unidades de hardware que constituam
gargalos para o sistema, tais como processadores centralizados de
comunicação, processadores centralizados de aquisição e/ou
tratamento de dados e outros.
Deverá ser levado em consideração que a falha em qualquer um dos
subsistemas funcionais ou unidades de hardware não deverá impedir e nem
degradar o correto funcionamento dos demais. Caso a configuração proposta
possua subsistemas processadores centralizados de comunicação, estes
deverão ser duplicados e operar em regime “dual” sendo que as linhas de
conexão com os dispositivos deverá ser duplicada. Nesta hipótese o
PROPONENTE deverá garantir explicitamente o desempenho do sistema dentro
das especificações do Edital.
Pág. 21/29
3 REQUISITOS DE SOFTWARE
Todos os módulos de softwares propostos para o Sistema deverão ter
comprovada a sua utilização em sistemas semelhantes ao aqui especificado,
funcionando de forma integrada na área de energia elétrica.
Todas as unidades computacionais do SPCS deverão utilizar o mesmo Sistema
Operacional e preferencialmente o mesmo Software de Supervisão e Controle.
Os desenvolvimentos de softwares específicos deverão ser mínimos, sendo que
o PROPONENTE deverá, obrigatoriamente, explicitar em sua proposta quais
funções demandarão desenvolvimento específico para a aplicação. Todos os
módulos de software desenvolvidos especificamente para a aplicação, inclusive
os “drivers” de comunicação com outros sistemas digitais deverão ser abertos
(módulos fontes deverão ser fornecidos), documentados (com utilização de
ferramentas CASE) e passarão a ser propriedade da ELETRONORTE.
Todos os softwares propostos para o Sistema deverão estar em sua versão mais
atual quando da entrada em operação dos sistemas e deverão estar de acordo
com o padrão POSIX IEEE Std. 1003.1-1990.
3.1 SISTEMA OPERACIONAL

O Sistema Operacional deverá ser voltado para processamento em tempo real e
ter aplicação largamente comprovada em sistemas similares. No mínimo as
características listadas a seguir deverão ser atendidas:
− Multitarefa Preemptivo
O Sistema Operacional proposto deverá suportar, gerenciar e
coordenar a execução de múltiplas tarefas baseadas no conceito de
prioridades. Tarefas de mesma prioridade deverão dividir igualmente
o tempo de processamento disponível. O chaveamento entre tarefas
deverá ser transparente para estas tarefas devendo ser executado
pelo Sistema Operacional.
− Tempo Real
O Sistema Operacional proposto deverá suportar o processamento
das tarefas e gerenciamento de eventos em tempo real e executar
tarefas periódicas.
− Gerenciamento de Memória
O Sistema Operacional proposto deverá gerenciar o espaço
disponível de memória para as tarefas ativas, otimizando a sua
ocupação, protegendo áreas proprietárias e compartilhando áreas
comuns.
− Gerenciamento de Recursos
O Sistema Operacional proposto deverá gerenciar o acesso
simultâneo aos recursos comuns do sistema (entradas e saídas,
discos rígidos, etc.) por mais de uma tarefa.
− Gerenciamento de Comunicação
Pág. 22/29
O Sistema Operacional proposto deverá implementar mecanismos de

troca de informações entre as tarefas nos modos síncrono e
assíncrono com facilidades de semáforos para acessos exclusivos,
“pipes”, DDE´s e outros.
− 32 bits
Todos os módulos que compõe o Sistema Operacional proposto
deverão ser constituídos de códigos nativos em 32 bits.
3.2 SOFTWARE DE SUPERVISÃO

O Software de Supervisão (IHM) proposto deverá ser um produto
completamente desenvolvido e disponível comercialmente. Não serão aceitos
produtos sem aplicação anteriores em sistemas similares, produtos ainda em
desenvolvimento ou qualquer tipo de “upgrade” que implique em migração de
plataforma de software básico (sistema operacional).
Este Software deverá possuir no mínimo as características listadas à seguir:
− Trabalhar em modo gráfico,
− Ser totalmente configurável pelo usuário,
− Possuir no mínimo os recursos de configuração e animação gráfica
especificados no item Subsistema de Engenharia (SEG) desta ET,
− Possuir todos os recursos de Operação, Supervisão e Gerenciamento
de Alarmes e Eventos especificados no documento Padrão de IHM e
no item Subsistema de Supervisão e Operação (SSO) desta ET.
− Permitir o desenvolvimento e integração de rotinas aplicativas
conforme especificado no item Subsistema de Engenharia (SEG)
desta seção.
− Possuir documentação automática da sua base de dados.
3.3 PROTOCOLOS DE COMUNICAÇÃO DA REDE LOCAL - VDD

O Protocolo de Comunicação da rede local deverá ser preferencialmente “não-
proprietário” e padrão, além de amplamente documentado e aberto ao usuário.
As considerações a seguir deverão ser observadas pelo PROPONENTE:
− O protocolo utilizado deverá preferencialmente permitir a
comunicação direta entre dois elementos quaisquer da rede (“peer-to-
peer” ou mestre flutuante),
− Caso exista na rede um processador mestre de protocolo (típico de
“front-end”) onde todas as mensagens da rede passem por ele, ele
deverá ser duplicado e o fornecedor deverá garantir que mesmo na
condição de falha de algum deles, o desempenho do sistema
atenderá aos requisitos colocados no item Requisitos de
Desempenho da ETG - PEP-000-55103, item 5.4.2.
− Caso o protocolo utilizado seja proprietário, mesmo que aberto ao
usuário, o PROPONENTE deverá ofertar pelo menos um Subsistema
de Integração (SIN) conforme especificados no item Subsistema de
Integração (SIN) desta ET.
Pág. 23/29
− Caso o protocolo seja padrão, o PROPONENTE deverá indicar

claramente em sua proposta para quais dispositivos de terceiros a
conectividade é garantida e a denominação comercial dos protocolos
disponibilizados. No caso de não haver garantias de conectividade o
PROPONENTE deverá ofertar Subsistemas de Integração (SIN’s)
conforme especificados no item Subsistema de Integração (SIN)
desta ET.
− Caso a rede ofertada seja não-determinística (por exemplo Ethernet),
o PROPONENTE deverá garantir uma taxa de ocupação menor que
20% da taxa de transferência nominal, mesmo nas situações de carga
especificadas no item Aferição do Desempenho do Sistema da
ETG.
Deverá ser considerado que não haverá troca de sinais entre dispositivos
através de entradas e saídas físicas para realizar funções de controle
(intertravamentos, comandos, bloqueios, etc.), devendo a troca de informações
ser realizada através da VDD. As trocas de informações necessárias para
garantir a perfeita operação das funções de proteção deverão ser efetuadas
através de entradas e saídas físicas.
3.4 SOFTWARE DE COMUNICAÇÃO

O Software de comunicação proposto deverá implementar a troca de
informações entre os Sistemas da ELETRONORTE processando o Protocolo de
Comunicação IEC 870-5-104, com recursos para transferência de arquivos em
ambas as direções (“File Transfer in Monitor Direction” e “File Transfer in Control
Direction” conforme definido na norma IEC 870-5-104).
Os pontos a serem enviados e/ou recebidos serão fornecidos quando da
elaboração do Memorial Descritivo do SPCS.
3.5 SOFTWARE DE DESENVOLVIMENTO

O Software de Desenvolvimento proposto deverá permitir o desenvolvimento de
tarefas aplicativas por parte do usuário incluindo os Protocolos de Comunicação
com outros Sistemas Digitais e com equipamentos de terceiros. Deverão ser
atendidas no mínimo as características listadas a seguir.
Windows do tipo cortar, colar, copiar, procurar, substituir e outros.
− Recursos para programação visual.
− Linguagem de programação estruturada, de preferência o C++.
bibliotecas API’s (“Application Program Interface”) de forma a não ser
novos aplicativos.
redes Ethernet, arquivos em disco, gerenciamento de tempo, acesso
à base de dados em tempo real, etc.
Pág. 24/29

discada e modem (discagem e atendimento automáticos dentre
outros),
etc.),
− Possuir ferramentas de desenvolvimento de aplicativos TCP/IP tais
como acesso via “socket”, “Remote Process Calling” (RPC), Telnet,
FTP, etc.,
− Compilador de programas, com recursos de transformar os códigos
fonte em linguagem de máquina (módulos objeto),
− Depurador simbólico.
Ressalta-se que todo e qualquer software desenvolvido especificamente para
esta aplicação deverá ser fornecido para a ELETRONORTE em linguagem de
alto nível e devidamente documentado.
Pág. 25/29
4 REQUISITOS DE HARDWARE
Todo hardware proposto deverá ter sido projetado e construído especificamente
para aplicações em controle de processos em ambiente eletricamente agressivo,
para funcionar 24 horas por dia, 365 dias por ano, sem interrupções.
Todos os microcomputadores fornecidos deverão ser padrão de mercado, de
modo a possibilitar a sua substituição futura por produtos mais avançados.
As características listadas a seguir deverão ser rigidamente observadas.
4.1 MICROCOMPUTADORES
Os microcomputadores a serem fornecidos deverão atender ou superar todos os
requisitos a seguir, além dos requisitos especificados na Especificação de
Aplicação:
− Barramento com no mínimo dois “slots” livres em sua configuração
máxima,
− Duas portas seriais EIA RS-232C e uma paralela padrão Centronics,
− Relógio Calendário interno com resolução de 1ms sincronizável
externamente por sinal proveniente de GPS.
− Porta padrão USB,
− Reinicialização automática no caso de falhas,
4.1.1 GABINETE
Os microcomputadores deverão ser acondicionados em gabinete industrial.
4.1.2 MEMÓRIA DE MASSA

A memória de massa deverá ser compostas por discos rígidos em quantidade e
capacidade suficientes para suportar a aplicação com folga de 50%.
Para a função de cópia de segurança, deverá ser utilizado driver para mídia
removível CD-RW (desde que a mídia utilizada seja amplamente disponível no
comércio varejista brasileiro) com capacidade de armazenamento de no mínimo
800 Mbyte.
4.1.3 MONITORES E CONTROLADORES DE VÍDEO

Os monitores de vídeo utilizados nos Sistemas para as funções de IHM
(Subsistema de Supervisão e Operação, Subsistema de Suporte à Manutenção
e outros) deverão ser LCD, policromáticos, tela mínima de 18”, resolução de
1024 X 768 ou melhor, freqüência de varredura de 72Hz ou maior, não
entrelaçado, e deverão ser conectados a placas controladoras com recursos de
gráficos avançados.
Os demais monitores que se fizerem necessários deverão ter as mesmas
características anteriores exceto a dimensão da sua tela que deverá ser de 15”.
Pág. 26/29
4.1.4 RECURSOS MULTIMÍDIA

Os microcomputadores deverão ser providos de recursos de multimídia com CD-
ROM de velocidade de leitura de no mínimo 48X, placa de som 32bits e caixas
acústicas, que não deverão ser do tipo incorporadas aos monitores de vídeo.
Estes recursos deverão ser utilizados para emitir alarmes sonoros para o
operador. O alarme sonoro deverá diferenciar de maneira clara o nível de
prioridade do alarme ocorrido.
4.2 IMPRESSORAS
Deverão ser fornecidas duas impressoras, uma para imprimir cópias de telas e
outra para relatórios em geral.
A impressora a ser fornecida para cópias de telas deverá ser de tecnologia de
jato de tinta a cores, com resolução mínima de 600 x 600dpi em formato A4. No
modo de impressão gráfica a cores deverá ser capaz de imprimir no mínimo 5
páginas por minuto.
As impressoras deverão ser conectadas diretamente à rede das Estações de
Operação do SPCS (rede nível 2).
Para a função impressão de relatórios em geral e de listas de alarmes e de
eventos a impressoras deverá ser do tipo laser, capaz de imprimir no mínimo 30
páginas por minuto na resolução de 1200 x 1200dpi.
4.3 REDE LOCAL

A rede local que irá compor a Via de Dados do sistema deverá ser
implementada em fibras ópticas. A sua configuração deverá ser em barramento
ou em anel, preferencialmente sem elemento ativo concentrador (“front-end”). O
PROPONENTE deverá propor uma rede que se enquadre nas considerações a
seguir.
− Define-se como elemento ativo de rede qualquer unidade que tenha
processamento do protocolo de comunicação, armazenamento,
redirecionamento ou tratamento de dados. “Hubs”, “star couplers”,
“splitters” e assemelhados não são considerados elementos ativos.
− Uma falha simples (inclusive causada por falta de tensão de
alimentação auxiliar em qualquer elemento ativo ou passivo da rede)
não deverá provocar a perda ou a degradação de performance da
comunicação.
− Se a rede for configurada como barramento passivo “radial” ela
deverá ser duplicada operando em regime “dual”.
− Se existir na rede algum elemento concentrador (do tipo “front-end”
ou “star coupler”) ele deverá ser duplicado. Todas as conexões das
unidades da rede para o “front-end” deverão ser conduzidas para os
dois “front-ends”. As unidades duplicadas deverão funcionar em
regime “dual”.
− A taxa de comunicação deverá ser igual ou superior à 10Mbit/s.
Pág. 27/29
− Cada cabo de fibra óptica deverão possuir individualmente uma

reserva correspondente à 100% da quantidade de veios utilizados
(mínimo 2 (dois)).
4.4 FIBRAS ÓPTICAS

As redes de comunicação de dados do SPCS, inclusive as de oscilografia, de
qualidade de energia e de medição de faturamento deverão ser implementadas
em fibras ópticas cujas características são especificadas neste item.
− Todos os lances de cabos ópticos deverão ser contínuos, não sendo
permitidas emendas.
− Deverão ser utilizadas fibras de vidro com conectores do tipo ST.
− A menos que explicitamente dispensado na Especificação de
Aplicação, as fibras deverão ser do tipo geleada. Deverão possuir
revestimentos primário, secundário e uma capa de proteção externa,
adequadas para passagem em locais sujeitos a água retida, e
também ao esforço mecânico usual para instalação em dutos
metálicos ou de material sintético.
− Os revestimentos deverão ser de material compatível com a fibra e
ainda possuir características químicas estáveis e não tóxicas.
− Os revestimentos deverão poder ser removidos adequadamente de
tal modo que não impeçam a realização de emendas e terminações.
Todos os cabos deverão ser fornecidos completos com os
conectores.
− A atenuação máxima permitida entre os conversores deverá ser
definida pelo FORNECEDOR, respeitando os limites de potência de
transmissão e de sensibilidade da recepção, de perdas nos
conectores, além de uma margem de segurança de pelo menos 6dB
para efeito de possíveis degradações e perdas em emendas
eventualmente necessárias no futuro.
− Os equipamentos e painéis que receberão as fibras deverão ter
“bandejas de serviço” dedicadas para a instalação dos cabos ópticos
e sua proteção mecânica, além de espaço adequadamente preparado
para o armazenamento do comprimento reserva de cabo óptico.
− No interior dos painéis deverão ser previstas canaletas para a
instalação das fibras ópticas com raio de curvatura adequado.
− Caso existentes, as conexões entre os cabos externos agrupados e
os cabos internos individuais deverão ser executadas em caixas
específicas.
4.5 RECEPTORES GPS

Para o sincronismo de todos os subsistemas do sistema deverão ser fornecidos
sistemas completos de relógios mestres sincronizados por receptores de GPS
compostos por antenas, receptores, conversores e demais dispositivos que se
fizerem necessários para a implantação da função de sincronismo (Subsistema
de Sincronismo). Estes equipamentos deverão ser apropriados para uso
industrial, montagem em bastidores.
Pág. 28/29
Deverão ser providos de teclado e “display” para ajustes dos equipamentos e

para indicação de data e hora com precisão até segundo, satélites visíveis e
seus dados, etc. Deverão ser providas saídas de pulso de sincronização
reservas (mínimo duas) e possibilidade de se incluir saídas de sinal de hora
absoluta adicionais (em formatos diferentes do fornecido originalmente para o
projeto).
4.6 ALIMENTAÇÃO DOS SUBSISTEMAS DO NÍVEL 2

Todos os subsistemas do nível 2 do SPCS deverão ser alimentados em 125 Vcc
provenientes de Sistemas de Corrente Contínua da Subestação.
Pág. 29/29

Pep 000 55105 3

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Pep 000 55105 3

Título original:

Enviado por

Direitos autorais:

3 11.07.

05 Revisão Geral EETP HC MDP WSF

CENTRAIS ELÉTRICAS DO NORTE DO BRASIL S.A

2.1 SUBSISTEMA DE INTEGRAÇÃO (SIN) 5

3.1 SISTEMA OPERACIONAL 22

4.1.4 RECURSOS MULTIMÍDIA 27

2.1 SUBSISTEMA DE INTEGRAÇÃO (SIN)

2.2 SUBSISTEMA DE SUPERVISÃO E OPERAÇÃO (SSO)

Deverá ser possível executar operações de Download e Upload do software,

2.3 SUBSISTEMA DE PROCESSAMENTOS ESPECIAIS (SPE)

2.4 SUBSISTEMA DE COMUNICAÇÃO (SCO)

2.5 SUBSISTEMA DE SUPORTE À MANUTENÇÃO (SSM)

− Exibir informações do histórico de operação de disjuntores,

2.6 SUBSISTEMA DE ENGENHARIA (SEG)

− Permitir a importação e exportação de dados de/para planilhas

2.6.2 CONFIGURADOR DA PROTEÇÃO.

2.6.3 CONFIGURADOR DA BASE DE DADOS.

− Entradas analógicas, com no mínimo os seguintes campos de

− Saídas digitais, com no mínimo os seguintes campos;

2.6.4 EDITOR GRÁFICO DE DIAGRAMAS SINÓTICOS.

biblioteca de símbolos especificamente desenvolvida para o setor elétrico que

2.6.5 CONFIGURADOR DE COMUNICAÇÃO

2.6.6 CONFIGURADOR DE SEGURANÇA DE ACESSO

− Determinação dos grupos de acesso, com a associação dos seus

2.6.7 CONFIGURADOR DE TENDÊNCIA

2.6.8 CONFIGURADOR DE RELATÓRIOS

2.6.9 DESENVOLVIMENTO DE ROTINAS

− Operadores lógicos (“e”, “ou”, “ou exclusivo”, “negação”, etc.)

− Compilador de programas, com recursos para transformar os códigos

2.6.9.3 Protocolos de Comunicação

2.7 SUBSISTEMA CONCENTRADOR DE INFORMAÇÕES (SCI)

do SPCS. Os protocolos de comunicação utilizados poderão ser os protocolos

2.7.2 ARMAZENAMENTO DAS INFORMAÇÕES

2.7.3 PARAMETRIZAÇÃO E VISUALIZAÇÃO LOCAL

2.8 SUBSISTEMA CONCENTRADOR DE MEDIÇÃO DE

− Adquirir cíclica e automaticamente os registros de medição de

2.8.2 ARMAZENAMENTO DAS INFORMAÇÕES

2.8.3 PARAMETRIZAÇÃO E VISUALIZAÇÃO LOCAL

2.9 O SUBSISTEMA DE SINCRONISMO (SSI)

A transmissão do sinal de sincronismo deverá ser feita através de um meio físico

2.10 VIA DE DADOS (VDD)

2.11 AGRUPAMENTO DE SUBSISTEMAS

− Os Subsistemas de Engenharia (SEG) deverão ser implementados

3.1 SISTEMA OPERACIONAL

O Sistema Operacional proposto deverá implementar mecanismos de

3.2 SOFTWARE DE SUPERVISÃO

3.3 PROTOCOLOS DE COMUNICAÇÃO DA REDE LOCAL - VDD

− Caso o protocolo seja padrão, o PROPONENTE deverá indicar

3.4 SOFTWARE DE COMUNICAÇÃO

3.5 SOFTWARE DE DESENVOLVIMENTO

− Possuir recursos suficientes para trabalhar com conexões por linha

4.1.2 MEMÓRIA DE MASSA

4.1.3 MONITORES E CONTROLADORES DE VÍDEO

4.1.4 RECURSOS MULTIMÍDIA

4.3 REDE LOCAL

− Cada cabo de fibra óptica deverão possuir individualmente uma

4.4 FIBRAS ÓPTICAS

4.5 RECEPTORES GPS

Deverão ser providos de teclado e “display” para ajustes dos equipamentos e

4.6 ALIMENTAÇÃO DOS SUBSISTEMAS DO NÍVEL 2

Você também pode gostar