Superintendência Comercial de Distribuição
MEDIÇÃO DE ENERGIA
ETC 3.16
SISTEMA DE GERENCIAMENTO DA
MEDIÇÃO DE FRONTEIRA
Março/2015
CÓPIA NÃO CONTROLADA – Verificar versão atualizada na Internet
DMED
ETC 3.16
SUMÁRIO
1- DESCRIÇÃO
2- NORMAS APLICÁVEIS
3- REQUISITOS GERAIS
4- ESPECIFICAÇÃO BÁSICA DO APLICATIVO
5- COMPATIBILIDADE DAS REMOTAS
6- GARANTIA
7- TREINAMENTO
8 – LOCAL DE ENTREGA / ACEITAÇÃO
9 - SUPORTE TÉCNICO E MANUTENÇÃO
ANEXO I - ACEITAÇÃO
2-20
DMED
1.
ETC 3.16
OBJETO:
Aquisição de Software de Sistema de Gerenciamento da Medição de Fronteira, que possibilita centralizar num sistema único todas as ferramentas necessárias para prover a operação e monitoramento
dos componentes do Sistema de Medição para Faturamento dos pontos de Fronteira e de clientes livres e especiais, atendendo a todos os quesitos de operação exigidos pela legislação pertinente,
abrangendo o fornecimento de suas respectivas licenças perpétuas de uso e a prestação de serviços
de instalação e operação com garantia de atualizações e correções, operação assistida, treinamento,
manutenção e suporte.
2.
NORMAS APLICÁVEIS
O Sistema deve atender as características constantes nesta especificação e as condições mínimas
exigíveis nas Normas Brasileiras relacionadas a seguir:
NBR 14522 - Intercâmbio de Informações para Sistemas de Medição de Energia Elétrica - Padronização; Procedimentos de Rede – Módulo 12 – ONS/ CCEE.
3.
REQUISITOS GERAIS
3.1
3.2
Documentação
a)
Fornecer manual, administração, de referência e de operação da solução, em meio magnético e impresso em português do Brasil.
b)
Fornecer documentação completa da instalação, configuração e desinstalação da solução, em meio magnético e impresso.
c)
Fornecer modelo físico de dados da solução para todas as versões que vierem a ser fornecidas à COPEL DIS durante a vigência do contrato, incluindo e não se restringindo a
diagrama do modelo entidade-relacionamento físico e descrição de cada objeto (tabela,
views, sequences, materialized views e outros) e de cada campo que a compõem, explicitando: formato, descrição, obrigatoriedade, tamanho e validação, de forma suficiente
para extração de dados através de ferramenta genérica de extração.
d)
Os manuais ou instruções técnicas e quaisquer documentos ou dados adicionais devem
ser fornecidos no idioma português do Brasil (PT-BR), contendo a descrição, funcionamento, manuseio, instalação, programação e manutenção. Os manuais e instruções devem ser apresentados preferencialmente em meio eletrônico, utilizando-se editor de texto
executável em ambiente LibreOffice ou equivalente.
Treinamento
A CONTRATADA deverá ministrar treinamento quanto a sua operação, programação, instalação e manutenção, conforme item 7 desta ETC.
3.3
Expansão do Sistema
Deve possibilitar a expansão futura do sistema com a inclusão de novos pontos, até o limite mínimo de acréscimo de 1000 pontos de medição (2000 medidores);
3.4
Código Fonte
Os códigos fonte da solução deverão ser fornecidos de forma ilimitada nas seguintes situações:
a) Em caso de falência da CONTRATADA;
b) Em caso de descontinuidade do produto;
c) Em caso de rescisão do contrato por qualquer motivo, por parte da CONTRATADA.
3-20
DMED
4.
ETC 3.16
ESPECIFICAÇÃO BÁSICA DO APLICATIVO
4.1
Descrição
4.1.1 O aplicativo deve ser baseado em tecnologia WEB e deve realizar o gerenciamento dos
pontos de medição de fronteira, atendendo todos os quesitos do Procedimento de Rede
e exigências do ONS / CCEE, e demais exigências descritas no item 4 da presente especificação. A quantidade mínima de medidores que o sistema deve suportar é de 1000
unidades, com possibilidades de expansão futura.
4.1.2 Administração
a)
Todos os usuários devem ser cadastrados e todas as suas ações deverão ser registradas em log, bem como o IP da origem de acesso;
b)
Os usuários devem ter acesso restrito a determinados Pontos de Medição / Medidores do sistema (configurável pelo administrador);
c)
Utilizar login e senha para identificação dos seus usuários em qualquer lugar que
disponibilize acesso (intranet e internet);
d)
Controle de acesso CRUD (Create, Read, Update and Delete), que permite definir
o nível de acesso para cada funcionalidade do sistema, para cada usuário;
e)
O administrador deve poder adequar o acesso do usuário para cada funcionalidade do sistema;
4.1.3 Cadastro
a)
Efetuar cadastro, pesquisa, edição e remoção de Usuários para o sistema, conforme SOX, com pelo menos as seguintes especificações: Nome, Área, Contato,
Senha, Confirmação de Senha, Perfil e Pasta;
b)
Efetuar cadastro, pesquisa, edição e remoção de Perfil de Acesso, conforme SOX,
com pelo menos as seguintes especificações: Nome, Módulo, Funcionalidade e
Tipo de Acesso;
c)
Efetuar cadastro, pesquisa, edição e remoção de Pontos de Medição com pelo
menos as seguintes especificações: Nome, nome do Ativo na CCEE, Código do
Ativo na CCEE, subestação, pasta, tipo de ponto (carga, conexão, geração, etc),
agente conectado, agente conectante, agente de medição, informações sobre origem da energia IN e OUT (geração ou consumo), nível de tensão de conexão, limites de potência de consumo e de geração, capacidade de conexão, informações
sobre compensação de perdas, medidores principal e retaguarda, TCs, TPs, cabos, informações sobre demandas contratadas na ponta e fora de ponta (Deve ser
cadastrável para o Ponto de Medição uma demanda dimensionada (de projeto) diferente da contratada);
d)
Efetuar cadastro, pesquisa, edição e remoção de Medidores com pelo menos as
seguintes especificações: nome, marca/modelo, versão de firmware, número de
série, código/número/identificação patrimonial, data de fabricação, período de garantia, dados dos lacres de segurança, classe de exatidão, constante de integração, constante de multiplicação por grandeza ou por canal, dados máximos e nominais de tensão, corrente e frequência, número de elementos de medição (dois
elementos, três elementos, etc), código CCEE de 14 dígitos, tipo de comunicação,
parâmetros para comunicação, dados de localização, dados de contato para suporte e manutenção;
e)
Efetuar cadastro, pesquisa, edição e remoção de TC e TP com pelo menos as seguintes especificações: nome, marca/modelo, aplicação, número de série, patrimonial, data de fabricação, período de garantia, dados dos lacres de segurança,
classes de exatidão, relação de transformação, classe de isolação, fator térmico(%), dados nominais de tensão, corrente e frequência, número de secundários,
meio de isolação, Comutação de Tap, dados de localização, dados de contato para
suporte e manutenção;
f)
Efetuar cadastro, pesquisa, edição e remoção de Níveis de Tensão, com pelo menos as seguintes especificações: Valor, Unidade;
g)
Efetuar cadastro, pesquisa, edição e remoção de Subestação no sistema, com pelo menos as seguintes especificações: Nome, Descrição, Endereço, Bairro, CEP,
4-20
DMED
ETC 3.16
Alimentador Auxiliar, Observações, Proprietário, Responsáveis e contatos Telefônicos e email.
h)
Efetuar cadastro, pesquisa, edição e remoção de Localização Geográfica e Regional no sistema, com pelo menos as seguintes especificações: Cidade, Estado, Região;
i)
Efetuar cadastro, pesquisa, edição e remoção de Tipos de Equipamentos do Sistema de Medição, com pelo menos as seguintes especificações: Marca, Modelo,
Espécie, Descrição;
j)
Efetuar cadastro, pesquisa, edição e remoção de Tipos de Ponto, com pelo menos
as seguintes especificações: Nome e Descrição;
k)
Efetuar cadastro, pesquisa, edição e remoção de Pontos Virtuais com pelo menos
as seguintes especificações: Nome e dados de identificação: tipo de ponto (carga,
conexão, geração, etc), informações sobre origem da energia IN e OUT (geração
ou consumo), nível de tensão de conexão, limites de potência de consumo e de
geração, capacidade de conexão, informações sobre compensação de perdas, informações sobre demandas contratadas na ponta e fora de ponta. Regra para
composição do ponto virtual: as regras para composição dos valores do ponto virtual devem ser flexíveis para levar em conta as operações de soma, subtração, divisão, multiplicação, raiz quadrada e qualquer composição dessas operações. Devem possibilitar operações com múltiplos pontos de medição e ainda devem possibilitar a escolha do canal que será utilizado em cada calculo para cada ponto de
medição: IN ou OUT, além disso, também deve levar em conta a compensação de
perdas quando aplicável. As regras para composição devem ter um período de validade determinado e deve ser possível a criação de várias regras, para o mesmo
ponto virtual, desde que os períodos de validade não se sobreponham de modo
que as consultas ao ponto virtual (gráficos e relatórios) tenham consistência temporal. Pontos Virtuais devem ser disponibilizados como se fossem pontos de medição nas funcionalidades do sistema (ex: gráficos e relatórios, etc);
l)
Efetuar cadastro, pesquisa, edição e remoção de Ponto de Carga, com pelo menos as seguintes especificações: Nome, Descrição, Pasta, Regras e Validade. As
regras de composição do Ponto de Carga devem ser definidas a partir de dados
cadastrais dos Pontos de Medição para definir quais os Pontos de Medição pertencem ao Ponto de Carga, pelo menos os seguintes dados cadastrais dos Pontos de
Medição devem ser passíveis de escolha para a definição da regra de composição
do Ponto de Carga: status/situação comercial, pasta, tensão de medição, região e
tipo de ponto. - A regra de composição deve contemplar pelo menos as operações
lógicas "IGUAL", "DIFERENTE", "E" e "OU" sobre os dados cadastras dos Pontos
de Medição citados acima para definir quais os Pontos de Medição que fazem parte do Ponto de Carga. As regras de composição dos valores das grandezas dos
Pontos de Carga devem ser flexíveis para levar em conta pelo menos às operações matemáticas de soma e subtração sobre os dados dos Pontos de Medição
que pertence ao Ponto de Carga. As regras para composição devem ter um período de validade determinado e deve ser possível a criação de varias regras, para o
mesmo ponto de carga, desde que os períodos de validade não se sobreponham,
de modo que as consultas ao ponto de carga (gráficos e relatórios) tenham consistência temporal;
m)
Efetuar cadastro, pesquisa, edição e remoção de Feriados, horário de verão com
pelo menos as seguintes especificações: data, descrição, data de início, data de
término;
n)
Efetuar cadastro, pesquisa, edição e remoção de Pastas, com pelo menos as seguintes especificações: nome, pasta pai;
o)
Entidade do sistema que agrupa uma seleção de pontos, de forma que seja possível um mesmo ponto estar em mais de uma pasta, e que o controle de acesso de
usuário possa ser direcionado por pastas;
p)
A remoção de entidades do sistema deve ser confirmada, através de interface
amigável de confirmação, a remoção de entidades do sistema deve ser passível
de resgate, pelo menos através de contato de suporte técnico especializado da
CONTRATADA.
5-20
DMED
ETC 3.16
4.1.4 Processo de Coleta
a)
Realizar a coleta (telemedição) dos dados de medição (memória de massa) dos
medidores eletrônicos homologados pela CCEE para Sistemas de Medição de Faturamento. Pelo menos os seguintes medidores/modelos devem ser suportados:
ELO/2180, Q1000, SL7000, ION/7500 - 8800, SAGA 1000, E750.
b)
A coleta dos dados – Telemedição, deve ser compatível com diferentes tecnologias de comunicação e deve efetuar a coleta dos dados de forma satisfatória para,
pelo menos, os seguintes meios de comunicação e/ou suas composições: ADSL,
fibra óptica, links de rádio frequência, links de satélite, redes ethernet, redes
GSM/GPRS.
c)
A coleta dos dados através meios de comunicação citados no item anterior, ou suas composições, devem considerar um canal transparente entre o sistema e o
medidor, permitindo a utilização de equipamentos de rede e conectividade comuns
e de mercado como roteadores, switches, “terminal servers” (conversores serial/ethernet), etc.
d)
A coleta efetiva dos dados dos medidores deverá contemplar pelo menos as seguintes informações: memória de massa dos dados de energia nos 4 quadrantes,
ou seja: energia ativa DEL, energia reativa DEL, energia ativa REC e energia reativa REC, memória de massa dos dados de engenharia, ou seja: tensões e correntes nas fases A, B e C, registros de eventos do medidor, para medidores/modelos
que possuam esses registros.
e)
O software de medição deve identificar automaticamente qual é o “template” configurado no medidor para armazenamento dos dados descritos acima em sua memória de massa, ou seja, o sistema deve identificar automaticamente (assim como
fazem os softwares dos fabricantes dos medidores) a grandeza que está sendo
armazenada em cada canal ou LOG do medidor, isso reduz o risco de erros no
armazenamento de dados no banco e consequente envio de dados errados para
CCEE em caso de parametrizações de “templates” diferentes entre medidores.
f)
O processo de coleta deve possibilitar o tratamento da medição de pelo menos
dois medidores por Ponto de Medição, ou seja, medidor principal e medidor retaguarda. O sistema deve manter o histórico de dados de ambos os medidores por
um período determinado e de todo o histórico dos dados consolidados para o Ponto de Medição. Os dados consolidados para o Ponto de Medição deverão ter sua
integridade total garantida pelo sistema, pois serão a fonte dos dados a serem
analisados no restante do sistema e também distribuídos para outros sistemas
dentro da empresa. A fonte do dado que foi utilizado para consolidação no Ponto
de Medição também deve ser registrada para efeitos de rastreamento e auditoria.
g)
O processo de coleta de dados deve contar com uma validação das informações
básicas de identificação e parametrização dos medidores antes de efetuar a aquisição dos dados, essa validação deve verificar pelo menos as seguintes informações: número de série do medidor, código CCEE de 14 dígitos (quando aplicável),
constantes de multiplicação por canal ou RTC e RTP dependendo do tipo/protocolo do medidor, relógio do medidor, constante de integração. O procedimento de Validação deve gerar Alarmes caso haja discrepância entre os dados lidos no medidor e os dados armazenados na base de dados de cadastro do sistema. Para o caso do relógio deve ser verificado se existe atraso ou adiantamento
em relação a uma base de tempo confiável, caso haja, um alarme deve ser gerado.
h)
O processo de coleta deve possibilitar a configuração da frequência com que as
coletadas serão executadas e quando o protocolo de dos medidores permitir a coleta deve ser marginal, ou seja, devem ser coletados somente os dados desde a
última data/hora coletada até a data/hora da coleta corrente, sem que seja necessária a busca de toda a memória de massa do medidor a cada coleta. O processo
de coleta ainda deverá ser capaz de refazer automaticamente tentativas de coleta
quando por algum motivo os dados não forem coletados corretamente, caso depois de diversas tentativas a coleta não seja concluída alarmes devem ser gerados.
i)
O processo de coleta deve ser capaz de gerenciar a parada para manutenção e/ou
calibração ou substituição de medidores de forma inteligente, mantendo a integri6-20
DMED
ETC 3.16
dade dos dados armazenados e gerando alarmes quando for o caso. Da mesma
forma, o processo de coleta deverá tratar de forma inteligente qualquer outro tipo
de parada ou mau funcionamento do medidor informando via alarmes qualquer
ocorrência.
j)
O processo de coleta deve realizar análises automáticas em todos os dados que
forem coletados a fim de garantir a integridade das informações coletadas, essas
análises devem contar com pelo menos as seguintes verificações: detecção e tratamento de dados duplicados, detecção e tratamento de lacuna de dados, detecção e tratamento de dados zerados, detecção e tratamento de discrepância entre
medição principal e retaguarda, quando aplicável , detecção e tratamento de dados
fora dos limites de potência, quando aplicável, detecção e tratamento de dados
com valores atípicos, quando aplicável. Quando detectadas qualquer uma das situações listadas acima, um alarme deve ser gerado para informar aos operadores
do sistema e esse alarme deve orientar o processo de correção dos problemas detectados.
k)
O processo de coleta deve utilizar os dados coletados automaticamente (telemedidos) nos Medidor Principal e Retaguarda, para realizar consolidação dos dados para o Ponto de Medição. Essa consolidação deve garantir a integridade total dos
dados a serem registrados para o Ponto de Medição, quando por algum motivo essa integridade não for alcançada através dos dados coletados automaticamente
nos medidores o sistema deverá emitir alarmes e fornecer ferramentas/funcionalidades para que os operadores possam inserir/alterar os dados de
medição a fim de garantir a integridade total da consolidação dos dados para o
Ponto de Medição;
l)
O processo de coleta deve fornecer a possibilidade de a consolidação dos dados
para o Ponto de Medição ser realizada manualmente pelos operadores do sistema
quando não houver possibilidade de garantir a integridade dos dados através da
coleta automática - telemedição. Os operadores devem ser devidamente alertados
dessas ocorrências através de alarmes e esses alarmes devem orientar o processo de consolidação manual onde, pelo menos, as opções apresentadas nos itens a
seguir devem ser disponibilizadas para os operadores:
l.1)
Opção por consolidar os dados para o Ponto de Medição através da definição de um período e utilização dos dados do medidor retaguarda. Essa opção poderá ser automática, ou seja, caso haja falta ou inconsistência nos
dados do Medidor Principal o sistema automaticamente consolida os dados
para o Ponto de Medição utilizando os dados do Medidor Retaguarda. Para
a intervenção manual o sistema deverá apresentar opção para escolha de
preenchimento dos dados com os dados provenientes da mesma data e hora do medidor retaguarda para o Ponto de Medição. Esta transferência poderá ser optada em completa (transferência de dados de todos os intervalos), individual (transferência referente a cada hora individualmente) ou sequencial (transferência de dados de um período de tempo especificado);
l.2)
Opção por consolidar os dados para o Ponto de Medição através da inserção/digitação manual dos dados em uma interface no sistema;
l.3)
Opção por consolidar os dados para o Ponto de Medição através da importação dos dados de um arquivo. Nesse caso deve ser possível a importação
de um arquivo e seleção do período exato a ser utilizado ser necessário à
utilização de todos os dados contidos no arquivo.
l.4)
Opção por consolidar os dados para o Ponto de Medição através de Estimativa por dias semelhantes: Obtém-se o valor de cada intervalo através da
media aritmética entre os valores referente ao mesmo intervalo dos "N" dias
equivalentes das ultimas semanas
l.5)
Opção por consolidar os dados para o Ponto de Medição através da Estimativa direta: deverá ser feito a média entre os valores imediatamente anterior
e posterior ao valor ou período zerado.
l.6)
Opção por consolidar os dados para o Ponto de Medição através da Estimativa pela média CCEE: Será calculada através da metodologia da CCEE
7-20
DMED
ETC 3.16
l.7)
Opção por consolidar os dados para o Ponto de Medição através de Estimativa imediata: Obtém-se o valor de cada intervalo através da media aritmética entre os valores referente ao mesmo intervalo dos "N" últimos dias imediatamente anteriores ao dia que possua dados zerados.
OBS.: Para todas as ferramentas de consolidação descritas anteriormente o sistema deve solicitar a confirmação e uma descrição/justificativa do usuário antes da alteração/inserção dos dados no Ponto de Medição com a finalidade de manter um registro
de cada ação realizada no processo para fins de rastreamento e auditoria.
m)
O processo de coleta deve prever procedimentos de contingência caso ocorram
problemas no sistema de comunicação ou qualquer outro tipo de problema que
impeça a coleta - telemedição automática dos dados dos medidores, esses processos devem, pelo menos, permitir a coleta dos dados através da importação de
arquivos no formato dos softwares de coleta local fornecidos pelos fabricantes dos
medidores, entre eles: arquivos públicos ou FK7 (medidores ABNT), arquivos de
Load Profile (medidores ION), formatos de arquivos com padrão CSV de outros
softwares de fabricantes. Além desses formatos de arquivo o sistema também deve ser capaz de efetuar a importação dos dados a partir de arquivos XML com o
formato padrão da CCEE. O processo de inserção dos dados provenientes desses
arquivos deve passar por todas as etapas contempladas no processo de coleta automática com o objetivo de garantir a integridade da consolidação dos dados para
os pontos de medição. A importação de dados deve permitir a seleção de intervalos de períodos.
4.1.5 Gestão de Arquivos XML para CCEE
a)
O sistema deve gerar diariamente e automaticamente os arquivos XML no formato
padrão da CCEE, disponibilizando-os para envio via Client SCDE. Esse processo
deve ser executado para todos os medidores que tenham essa opção habilitada. O
Sistema deve garantir a integridade dos arquivos e dos dados contidos nesses arquivos, para isso deve executar todas as validações que a CCEE irá realizar no
processo de coleta dos dados, essas validações devem garantir o aceite dos arquivos pelo ClientSCDE para envio à CCEE e ainda o processamento dos dados
dos arquivos pelo SCDE da CCEE.
b)
O sistema deve gerar alarmes sempre que houver um problema no processo de
geração e disponibilização dos arquivos XML para CCEE, de modo que arquivos
incompletos ou inconsistentes não sejam enviados. Esses alarmes devem orientar
o operador no processo de correção dos dados ou mesmo no processo de intervenção junto a CCEE para fins de abertura de Boletins de Ocorrência. O sistema
deve verificar se o Client SCDE enviou os arquivos efetivamente e gerar alarmes
caso isso não ocorra.
c)
O sistema deve fornecer ferramentas que auxiliem os operadores no acompanhamento do processo de geração e envio dos arquivos XML para a CCEE, por
exemplo, um relatório de resumo semelhante ao disponibilizado pela CCEE aos
agentes (extrato de coleta) com informações sobre a geração e envio dos arquivos
ao Client SCDE, com listagem dos pontos e dos dias, com identificação de status
de envio por diferenciação de cores e ainda possibilidades de filtragens por grupo
de pontos, períodos ou status.
d)
O sistema deve fornecer a possibilidade de geração retroativa de arquivos XML,
de forma inteligente sendo possível seleção múltipla de Pontos e com Período configurável. O processo de geração retroativa deve conter todas as etapas de validação e acompanhamento do envio dos arquivos descritos para o processo de geração automático.
e)
Não interferir na memória de massa do medidor (o software não poderá alterar/apagar dados da memória de massa do medidor físico);
4.1.6 Inspeção Lógica
a)
O sistema deve gerenciar as conexões ao medidor, mesmo que o medidor possua
apenas um canal de acesso, ou seja, não permita acesso simultâneo, o sistema
deve priorizar quem acessa o medidor, de forma que a CCEE sempre consiga
acessá-lo, a fim de evitar multas de inspeção lógica.
8-20
DMED
ETC 3.16
b)
O sistema deve monitorar as conexões ao medidor, interpretando os dados trafegados, a fim de identificar o sucesso ou falha da comunicação.
c)
O sistema deve monitorar os canais de comunicação, verificando o seu estado de
disponibilidade.
d)
O sistema deve fornecer funcionalidades para monitoramento do canal de comunicação utilizado pela CCEE para as coletas de inspeção lógica. Essas funcionalidades devem possibilitar uma simulação, mesmo que parcial, da Inspeção lógica da
CCEE. Essas simulações devem ser repetitivas com agendamento configurável e
todos os resultados devem ser armazenados para apresentação em relatórios. As
simulações devem testar o canal de comunicação e a resposta do medidor a solicitações de coleta em seu protocolo padrão. Sempre que uma simulação falhar o
sistema deve gerar alarmes.
e)
O sistema deve ser capaz de monitorar o acesso da CCEE aos medidores nas
ocasiões de coletas para inspeção lógica. Nesse monitoramento o sistema deve
armazenar o máximo de informações sobre a conexão, pelo menos os seguintes
dados devem ser monitorados e armazenados: data/hora de inicio e fim da conexão da CCEE ao medidor, quantidade de bites trafegados entre a CCEE e o medidor em ambos os sentidos (perguntas e resposta), tempo de resposta entre cada
pacote enviado pela CCEE ou pelo medidor. Além do armazenamento dessas informações o sistema deve ser capaz de indicar com razoável margem de acerto se
a coleta realizada pela CCEE teve sucesso ou falhou. O sistema deve gerar alarmes sempre uma simulação de inspeção lógica falhar ou que um acesso da CCEE
for identificado como com falha e apresentar relatórios de acompanhamento.
4.1.7 Alarmes
a)
O sistema deve fornecer alarmes, a fim de orientar a própria operação do sistema.
Os alarmes devem ser mais que simples indicadores de problemas ou ocorrências, eles devem orientar os processos de correção dos problemas ou atuação sobre as ocorrências, levando os operadores a interfaces dentro do sistema ou
mesmo a sistemas externos onde essas ações devam ser executadas.
b)
O sistema deve enviar avisos diretos (email, sms, etc) e fornecer uma Interface
centralizada para consulta e acompanhamento dos alarmes com, no mínimo, as
seguintes especificações: criticidade, status de reconhecimento, data, tipo e origem do alarme. Essa interface deve gerenciar a disponibilização dos alarmes para
que sejam apresentados somente os que o usuário tenha permissão para visualizar.
c)
Relação mínima de Alarmes:
c.1)
Alarmes de Validação: o sistema deve gerar alarmes sempre que algum
dos itens analisados na etapa de Validação do Processo de Coleta não estiver de acordo com os dados cadastrados na base de dados de cadastro do
sistema;
c.2)
Alarmes de Consolidação: o sistema deve gerar alarmes sempre que alguma das condições da etapa de Coleta e Consolidação do Processo de
Coleta for detectada;
c.3)
Alarme de Valores Atípicos 1: Gerar Alarmes se o valor medido for superior ou inferior a um percentual (% ajustável) da medição referente a um período imediatamente anterior;
c.4) Alarme de Valores Atípicos 2: Gerar Alarmes se o valor da mesma hora no
dia coincidente da semana passada, for superior ou inferior a um valor ajustado (% ajustável);
c.5)
Alarme de Valores Atípicos 3: Alarmes de atipicidade sempre que os valores, (de energia e demanda) ultrapassarem os limites configuráveis, (de
grandeza e cronológicos) da curva típica;
c.6) Alarme de Ultrapassagem: Alarmes de demanda contratada, sempre que a
demanda ultrapassar um valor ajustado (configurável);
9-20
DMED
ETC 3.16
c.7)
Alarmes de Eventos 1: gerar alarmes quando a tensão medida estiver acima ou abaixo da faixa de aceitação percentual (% ajustável) da tensão de
nominal de fornecimento;
c.8) Alarmes de Eventos 2: quando eventos internos do medidor, que devem ser
coletados quando disponíveis, forem críticos o sistema deve gerar alarmes.
Os eventos a serem sinalizados por alarmes poderão ser definidos de acordo com o tipo/modelo do medidor e sua disponibilidade para coleta;
c.9)
Alarmes CCEE 1: o sistema deve gerar alarmes para qualquer inconsistência na geração ou processo de envio dos arquivos XML para CCEE conforme descrito nos sub itens 4.1.4 e 4.1.5. desta ETC;
c.10) Alarmes CCEE 2: o sistema deve gerar alarmes no caso de uma simulação
de inspeção lógica malsucedida ou caso identifique que um acesso da
CCEE para coleta de inspeção lógica ocorreu com falha, como descritos nos
sub itens 4.1.5 Inspeção Lógica;
c.11) Alarmes CCEE 3: gerar alarme quando o relógio do medidor, estiver defasado do servidor em um limite configurável;
c.12) Alarme de discrepância entre medidor principal e retaguarda: deve permitir a configuração de um percentual mínimo para detecção da discrepância entre os valores do medidor principal e retaguarda;
c.13) Alarme de dados zerados: deve permitir a configuração de um valor limite
para considerar o dado como zerado;
c.14) Alarme de Status de Comunicação: sempre que detectar problemas na
comunicação com os medidores.
4.1.8 Características Gerais:
4.2
a)
O zeramento dos alarmes não é espontâneo. Deve ser realizado através de comando específico.
b)
Havendo necessidade de monitoração do ponto de medição, o sistema deverá
possibilitar que as leituras sejam enviadas em intervalos de 15 (quinze) minutos.
c)
Deve ser possível a segmentação da programação e visualização dos alarmes para uso simultâneo de diversos analistas em diferentes universos de consumidores
(cinco pelo menos).
Características do Sistema
4.2.1 O sistema deve possibilitar o sincronismo dos relógios de todos os tipos de medidores,
via micro ajuste de horário conforme protocolo da ABNT, ou utilizando os comandos dos
protocolos nativos de cada medidor.
4.2.2 Deve também permitir descarga de arquivos em formato Público de leituras provenientes
de notebooks, PALM-OS e leitoras compatíveis com o protocolo ABNT nos computadores tipo PC da intranet COPEL.
4.3
Aplicativo Gestão Medição
4.3.1 Visualização de dados de cada ponto, com no mínimo, as seguintes informações: Modo
de apresentação, total geral, total ponta direta, total ponta reversa, total fora de ponta direta, total fora ponta reversa, demanda do último intervalo, demanda máxima de ponta,
demanda máxima fora de ponta, demanda acumulada em ponta, demanda acumulada
fora de ponta.
4.3.2 Possibilidade de exportar arquivos para planilha eletrônica. Deve possuir a funcionalidade
da geração de arquivo da memória de massa ( consumo ) , em formato TXT ou CSV,
automaticamente , para todos os pontos de medidores selecionados , após o fechamento
de fatura e disponibilizá-los em determinada pasta de rede.
10-20
DMED
ETC 3.16
4.3.3 Visualização em tempo real de leituras coletadas pelo menos há 13 meses. Arquivos anteriores devem ser passíveis de arquivamento pela área de TI da COPEL DIS.
4.4
Visualização Gráfica
4.4.1 O sistema deve possibilitar a visualização das ocorrências/alarmes listados no item 4.1.7
desta ETC, em tempo real.
4.4.2 O sistema deve fornecer interface, com no mínimo as seguintes informações sobre o
ponto de medição e seus medidores:
a)
Dados cadastrais;
b)
Dados de medição (energia ativa direta e reversa, reativa indutiva direta e reversa,
reativa capacitiva direta e reversa, 03 tensões e 03 correntes);
c)
Status da coleta;
d)
Status do canal de comunicação;
e)
Status dos arquivos xml enviados para CCEE.
4.4.3 Deve possibilitar a análise em tempo real da página fiscal (quando o medidor permitir). A
visualização de dados de medição online deve fornecer um diagrama esquemático do
circuito trifásico, com no mínimo, as seguintes informações:
a)
Tensões de linha;
b)
Tensões de fase;
c)
Desequilíbrio de tensões percentual;
d)
Corrente em cada fase;
e)
Corrente média;
f)
Desequilíbrio de correntes percentual;
g)
Potencia Ativa;
h)
Potencia Reativa;
i)
Frequência;
j)
Fator de potência.
4.4.4 Deve ser possível a exportação em formato de figura do diagrama vetorial e dos dados
numéricos, com no mínimo as seguintes informações:
a)
Tensões de fase;
b)
Tensões de linha;
c)
Corrente em cada fase;
d)
Defasagem angular entre a tensão e corrente em cada fase;
e)
Ângulo da tensão em cada fase em relação à origem;
f)
Ângulo entre as tensões de cada fase;
g)
Potência ativa, reativa e aparente em cada fase;
h)
Potência ativa, reativa e aparente trifásica;
i)
Fator de potência;
j)
Frequência.
4.4.5 Sistema deve possuir Interface para visualização e configuração remota dos medidores
com no mínimo os seguintes parâmetros:
4.4.5.1 Medidores com protocolo padrão ABNT:
11-20
DMED
ETC 3.16
a)
Data;
b)
Hora;
c)
Intervalo de demanda;
d)
Feriados;
e)
Constantes de multiplicação (numerador e denominador) para todos os
grupos de canais;
f)
Segmentos horários: ponta, fora ponta e reservado;
g)
Reposição automática de demanda;
h)
Sincronismo;
i)
Código do Ponto;
j)
Forma de trabalho do medidor (grandezas ou pulsos).
4.4.5.2 Medidores ION:
a)
Código do Consumidor;
b)
Horário de Ponta;
c)
Constantes RTC e RTP.
4.4.6 Os gráficos e/ou relatórios devem atender, no mínimo, as seguintes especificações:
4.5
a)
Um eixo em função do tempo;
b)
Um ou mais eixos em função da(s) grandeza(s) a ser(em) plotada(s);
c)
Possibilidade de plotar os dados consolidados dos pontos de medição e também
os dados dos medidores;
d)
Deve ser configurável o intervalo de dados a ser plotado, com data inicial e final;
e)
Deve ser configurável a unidade multiplicadora de plotagem;
f)
Deve ser configurável o intervalo de integração para apresentação dos dados. Os
seguintes períodos de integração devem estar disponíveis, exceto quando a grandeza não suportar: 5 minutos, 15 minutos, 60 minutos, 1 dia, 1 semana e 1 mês;
g)
Possibilidade de executar zoom em áreas específicas do gráfico para análises detalhadas;
h)
Possibilidade de gerar um relatório tabular com os mesmos dados apresentados
nos gráficos. O relatório deve ser exportável com, no mínimo, os seguintes formatos: TXT, CSV, XLS e XML;
i)
Exportação de dados em formato padrão .TXT e .XML para ajuste de dados na
CCEE.
4.4.7
Soma ou subtração de vários pontos de medições, permitindo relatórios, gráficos e arquivo formato público para o faturamento de pontos de medição fisicamente separados.
4.4.8
A visualização gráfica e tabela da análise fasorial aplicáveis à medição a 02 e 03 elementos, delta e estrela, apresentando em tela, no mínimo, tensões, correntes, potências
ativas, potências reativas e respectivos ângulos para cada uma das fases.
Aplicativo Visualização do Consumidor
4.5.1 Através da habilitação do usuário e/ou de funções através de senhas o sistema deve
permitir que as leituras dos medidores sejam realizadas na Internet através de um
“browser” de mercado, o sistema deve ser compatível pelo menos com Internet Explorer
5.0 ou superior e Firefox 2.0 ou superior.
4.5.2 Visualização de no mínimo das curvas de carga de Consumo, Demanda e Fator de Potência.
12-20
DMED
4.6
ETC 3.16
Aplicativo Gestão do Sistema
O Sistema deve possibilitar a geração de um Relatório de Auditoria sempre que o software de
gerenciador do sistema de telemedição for executado. As informações contidas neste relatório
deverão identificar quais funcionalidades um determinado usuário utilizou, quais modificações
na configuração foram feitas e quando iniciou e finalizou o uso do software gerenciador.
4.7
Requisitos de Arquitetura
a)
A arquitetura da solução deve ser baseada em processamento no lado servidor com pelo
menos três camadas (camada de apresentação Web, camada de aplicação e camada de
banco de dados).
b)
O SGBD e o servidor de aplicações devem ser isolados entre si em instâncias de sistema
operacional separadas.
c)
A solução deve permitir escalabilidade horizontal (adição de servidores) e vertical (upgrade de hardware) nas camadas servidoras.
d)
Todas as funcionalidades da solução que dependem de interação com o cliente / usuário
devem ser disponibilizadas por interface Web, que deve operar ser compatível com
browsers Internet Explorer versão 8, Firefox 17, e versões superiores, em computadores
com sistema operacional Windows XP, Windows Vista e Windows 7 (32 e 64 bits).
e)
A chave e a senha para autenticação de cada usuário devem ser independentes das
chaves e senhas do banco de dados.
f)
Todos os módulos da solução devem ser acessados a partir de um único procedimento
de login, sem necessidade de novas autenticações no acesso aos diversos módulos.
g)
A solução deve restringir o acesso a funcionalidades e dados de acordo com as permissões do perfil de usuário configurado na solução.
h)
A interface de usuário da solução deve estar no idioma português do Brasil (PT-BR).
i)
Fornecer, em português do Brasil (PT-BR), manuais do usuário em meio digital.
j)
O tráfego de informações pela Internet deve ser feita de forma segura usando HTTPS.
k)
A solução deve fornecer mecanismos para integração síncrona e assíncrona com aplicações da COPEL DIS , incluindo:
k.1) Ser capaz de prover e consumir serviços em WebServices e REST, sobre HTTP e
HTTPS;
k.2)
Ser capaz de trocar informações via arquivos de dados, em formatos de arquivo
texto, como XML, CSV e TXT.
l)
Não deve haver integração por meio de acesso direto a banco de dados e nem uso de
links entre bancos, salvo nos casos analisados e autorizados pela COPEL DIS.
m)
A decisão de qual mecanismo de integração deve ser aplicado em cada caso específico
de integração caberá a COPEL DIS. À solução, cabe prover os mecanismos conforme
especificados neste documento.
n)
Havendo integração da solução com serviço de email, deve ser utilizado servidor Lotus
Domino versão 8.5 com protocolos de email (SMTP, etc.), provido pela COPEL DIS. APIs
específicas para integração poderão ser utilizadas se analisadas e aprovadas previamente pela COPEL DIS.
o)
A integração entre aplicações externas e a solução deve ser feita de forma segura, havendo sigilo, autorização, autenticação e integridade no tráfego de informações nos casos em que a COPEL DIS julgar necessário.
p)
Deve garantir, em caso da instalação de novas versões ou atualizações da solução,
compatibilidade com mecanismos antecessores de integração para que sistemas externos já integrados ao produto não tenham que ser alterados.
13-20
DMED
4.8
ETC 3.16
q)
Todos os módulos da solução devem ser integrados de forma nativa, sem necessidade
de programação. Devem ainda funcionar sobre uma mesma plataforma, e possuir a
mesma identidade visual;
r)
A solução deve tratar a ocorrência de erros de forma padronizada, identificando-os, isolando-os e comunicando-os por meio de códigos padronizados e documentados.
s)
Qualquer software necessário para atendimento dos requisitos da solução, mesmo que
não explicitamente citados, devem ser fornecidos com a solução.
Requisitos de Infraestrutura de Rede
a)
O hardware (servidores e storage) que será utilizado para instalação e operacionalização
da Solução será fornecido pela COPEL DIS.
b)
A Solução deverá ser executada em máquinas virtuais VMware ESXi 5.0 e versões mais
novas. Utilizando o máximo de 4 máquinas virtuais. Deverão ser obedecidos os seguintes
limites para toda a solução exceto banco de dados:
b.1)
A soma da memória RAM alocada de todas as máquinas virtuais deverá ser de
máximo 24 GB;
b.2)
A soma de todos os núcleos de processador de todas as máquinas virtuais deverá
ser de no máximo 8;
b.3)
A soma do espaço em disco alocado de todas máquinas virtuais será de no máximo 500 GB. Está excluído deste valor o espaço utilizado pelo banco de dados.
c)
Deverão ser utilizados os seguintes sistemas operacionais: Microsoft Windows Server
2008 R2 ou versões mais novas ou CentOS 6 ou versões mais novas. A COPEL DIS fornecerá as licenças de sistema operacional.
d)
A COPEL DIS fornecerá toda a infraestrutura de rede necessária para a utilização da Solução.
e)
O banco de dados a ser utilizado pela Solução será o Oracle Enterprise Edition 11.2.0.3
rodando em AIX 7.1. A COPEL DIS será responsável pelos servidores de banco de dados, incluindo o fornecimento das licenças. O banco de dados de produção para a solução utilizará o máximo de 1 núcleo de processador da arquitetura IBM Power 7. Os bancos de dados dos ambientes de homologação e desenvolvimento serão compartilhados
com os servidores já existentes na COPEL DIS para este fim.
f)
A alta disponibilidade do ambiente de banco de dados será provida pelo IBM Power HA. A
alta disponibilidade dos servidores de aplicação será provida pelo Vmware.
g)
O software de backup a ser utilizado pela Solução será o Veritas Netbackup Enterprise
7.5 ou superior. Será utilizada a infraestrutura de backup da COPEL DIS (Licenças de
software, Media servers, robôs de backup e fitas) para armazenar a cópia de segurança
dos dados.
h)
A instalação e configuração, de forma assistida, de todas as máquinas virtuais são de
responsabilidade da CONTRATADA.
i)
No aceite da solução deverá ser fornecida documentação técnica completa da implementação da Solução, através de diagramas, mapas, planilhas ou textos que descrevam a
configuração da Solução a ser implantada.
j)
Fazem parte da proposta os serviços de instalação, configuração e operacionalização de
todos os componentes de software da Solução.
14-20
DMED
5.
ETC 3.16
COMPATIBILIDADE DAS REMOTAS
A COPEL DIS possui instaladas em seu parque, aproximadamente 500 remotas de fabricação Landis
Gyr, modelo CD103, que realizam a telemedição para o Sistema STM. O sistema deve possibilitar a
utilização destas remotas , como solução de comunicação para os pontos que a utilizem, considerando que as remotas possuem o modo de operação transparente.
Para novos pontos de telemedição, o Sistema deve ser capaz de realizar a comunicação com os medidores através da utilização de um canal transparente, permitindo a utilização de equipamentos de
rede e conectividade comuns e de mercado como roteadores, switches, “terminal servers” (conversores serial/ethernet), etc.
6.
GARANTIA
A garantia do sistema deve ser de, no mínimo, 12 (doze) meses, iniciando a partir da instalação efetiva do mesmo na COPEL DIS, em ambiente de produção. Dentro deste período, a CONTRATADA deve oferecer soluções à COPEL DIS, sem ônus, de quaisquer defeitos ocasionados por mau funcionamento do sistema.
A CONTRATADA deve garantir que completará o fornecimento e instalação e alcançar a aceitação do
sistema dentro dos prazos especificados.
A CONTRATADA deve garantir que o sistema, incluindo todas as tecnologias de informação e serviços fornecidos são livres de defeitos de projeto ,engenharia, mão de obra que impeçam o sistema
e/ou qualquer de seus componentes de cumprir seus requisitos técnicos ou limite seu desempenho.
15-20
DMED
7.
ETC 3.16
TREINAMENTO
A CONTRATDA deverá ministrar treinamento teórico e prático para instalação, configuração e utilização do sistema, em dois módulos distintos:
a)
Módulo 1 (um) para 2 (dois) profissionais de TI para instalação , mínimo de 8 horas;
b)
Módulo 2 (dois) para 4 (quatro) profissionais da área de medição para configuração dos medidores e utilização do sistema , mínimo de 8 horas;
Os treinamentos deverão ser ministrados nas dependências da COPEL DIS e após a instalação do
sistema. A infraestrutura (sala de aula, projetor, etc.) será fornecida pela COPEL DIS .
Deverão ser entregues manuais em português do Brasil (PT-BR) contemplando os procedimentos de
instalação (módulo 1) e utilização (módulo 2) em quantidade suficiente para o curso e por conta da
CONTRATADA. Cópias em mídia eletrônica também deverão ser fornecidas.
Os custos decorrentes de viagem, estadia e locomoção para os instrutores correm por conta da
CONTRATADA.
8.
LOCAL DE INSTALAÇÃO / ACEITAÇÃO
A instalação do software e/ou outros serviços deverão ser realizados na COPEL DIS - KM3 :
Rua José Izidoro Biazetto 158, Bloco E, Curitiba
A/C Nelson de Pauli Junior (SCD/DMED/VENM, ramal 3364).
9.
SUPORTE TÉCNICO E MANUTENÇÃO
A CONTRATADA deverá prestar os serviços de Suporte Técnico e Manutenção com SLA por um período de 12 ( doze ) meses, com possibilidade de prorrogação.
O Suporte Técnico e Manutenção com SLA entram em vigor imediatamente ao final dos serviços de
Operação Assistida, e devem ser prestados de acordo com as seguintes características:
9.1
Horários de Atendimento
a)
Horário Normal de Funcionamento
O Suporte Técnico deverá estar disponível 5 (cinco) dias por semana, de segunda a sexta-feira (exceto feriados), das 09:00h às 18:00h.
b)
Horário de Funcionamento no Período Especial de Atendimento
Durante o período especial de atendimento que corresponde aos 3 (três) últimos dias
úteis e aos 3 (três) primeiros dias úteis de cada mês, o Suporte Técnico deverá estar disponível das 08:00h às 20:00h.
9.2
Acesso ao Suporte Técnico
O Suporte Técnico poderá ser acessado por email e/ou telefone. Quando feito por telefone, deverá ser acompanhado de um email.
9.3
Chamados de Manutenção
Os acessos efetuados ao Suporte Técnico com o intuito de informar indisponibilidades do sistema ou degradação do serviço são denominadas Chamados de Manutenção (CM).
9.3.1 Classificação dos Chamados de Manutenção
16-20
DMED
ETC 3.16
Os Chamados de Manutenção (CM) são classificados em relação à severidade da indisponibilidade do sistema e da degradação do serviço, conforme a seguir:
SEVERIDADE
DEFINIÇÃO
Crítica
Indisponibilidade total do sistema, impossibilitando qualquer acesso à
plataforma pelos usuários. Falha em funcionalidades críticas do sistema.
Reduzida
Indisponibilidade parcial do sistema, impossibilitando apenas o acesso
a algumas funcionalidades. Falha de funcionalidades não críticas, causando apenas ligeiras perturbações.
Baixa prioridade
Incidências que não causam impacto imediato no negócio e cuja solução pode ser agendada com o usuário.
Nota Importante: Após análise da situação e com o consentimento da COPEL DIS , a CONTRATADA pode reclassificar um chamado quanto a sua severidade, passando este a ser tratado com a nova classificação, mantendo a data de horário de abertura do chamado.
9.3.2
Acesso Remoto para Solução dos Chamados de Manutenção
As soluções para os chamados de manutenção serão sempre implementadas de forma
remota, salvo a concordância de ambas as partes de que eventualmente tenham que
ser executadas manutenções locais na COPEL DIS. Neste caso, os custos de viagens
e estadias dos técnicos da CONTRATADA deverão ser pagos pela contratada.
9.3.3
Prazos de Solução de Chamados
Os Prazos de Solução dos Chamados de Manutenção dependem do tipo de chamado.
O Prazo de Solução inicia-se no momento em que os técnicos da CONTRATADA consigam acesso remoto ao sistema, a partir do registro do Chamado de Manutenção no
Suporte Técnico.
Para que os técnicos da CONTRATADA possam ter acesso remoto ao sistema, são
necessários:
a)
Conexão de internet ao sistema esteja ativa;
b)
Abertura do firewall para conexão, dentro dos padrões de segurança;
c)
Acesso total à Base de Dados e ao Windows, como usuários tipo “administrador”.
Caso a manutenção seja local, o Prazo de Solução começa a contar a partir do momento em que tenham acesso ao servidor onde o sistema está instalado.
A tabela a seguir possui os prazos máximos para a solução, de acordo o tipo de chamado:
SEVERIDADE
PRAZO DE SOLUÇÃO
(MÁXIMO)
PRAZO DE SOLUÇÃO
(MÁXIMO) DURANTE O
PERÍODO ESPECIAL
DE ATENDIMENTO
Crítico
16 horas úteis
8 horas úteis
Reduzida
36 horas úteis
36 horas úteis
Baixa Prioridade
A combinar (*)
A combinar (*)
(*) O Prazo de Solução de Chamados no caso com Severidade “Baixa Prioridade” deverá ser combinado entre os usuários cadastrados da COPEL DIS e os técnicos da CONTRATADA para cada chamado.
Obs.: Em todos os Tipos de Chamado, o Prazo de Solução de Chamados deve respeitar os Horários de Atendimento determinados no item 9.1. desta ETC.
Atualizações de software, bem como qualquer outra operação desta natureza, desde
que não emergencial, deverão ser agendadas com a COPEL DIS.
17-20
DMED
ETC 3.16
Paradas agendadas com a COPEL DIS não são enquadradas na SLA, desde que não
ultrapassem o período previamente negociado.
9.3.4
Acompanhamento das atividades
A COPEL DIS tem a prerrogativa de acompanhar todos os procedimentos e serviços
realizados em caráter de Chamado de Manutenção, Manutenção Programada ou Alterações e Melhorias do Sistema.
O acesso da CONTRATADA aos servidores da COPEL DIS, utilizados pela solução, será realizado exclusivamente por meio presencial e acompanhado de um funcionário designado para supervisionar a execução dos serviços necessários. Tal acesso deve ser
agendado com antecedência mínima de 01 dia útil.
Em caráter excepcional e por interesse da COPEL DIS, o acesso aos servidores da
COPEL, utilizados pela solução, poderá ser realizado através de VPN (Virtual Private
Network) disponibilizada segundo regras e parâmetros estabelecidos pela COPEL DIS.
9.3.5
Relatórios Gerenciais
A CONTRATADA deverá disponibilizar relatórios gerenciais mensais sobre o sistema e
respectivos chamados.
Os relatórios gerenciais devem conter as seguintes informações:
9.4
a)
Registros de eventos gerais;
b)
Registros dos Chamados de Manutenção e tempo de solução para cada chamado;
c)
Registros de Manutenções Programadas;
d)
Registros de Alterações e Melhorias do Sistema.
e)
As solicitações de envio dos relatórios gerenciais bem como qualquer comunicação gerencial referente a este serviço devem ser feitas através de e-mail, colocando-se no assunto o respectivo tópico.
Penalizações por Tempo de Solução
Em caso do não cumprimento dos níveis de serviço serão atribuídas penalizações, que serão
calculadas pela somatória da aplicação dos índices descritos neste documento ao valor contratual mensal, limitadas a 50 % desse valor.
A fatura dos serviços de manutenção e suporte deverá ser precedida do envio dos relatórios
mensais sobre os Níveis de Serviço de forma a permitir a conferência dos valores apresentados. No caso de impossibilidade de conclusão das negociações das penalidades a serem aplicadas em um determinado mês, as mesmas serão acumuladas às apuradas no mês seguinte.
O montante mensal pago deverá ser calculado da seguinte forma:
“Montante Pago (ref.: mês n) = Valor Mensal de Serviços (n) – Valor da Penalidade (n-1)”
i. Penalização por Tempo de Solução
Caso o tempo de solução de um determinado chamado seja maior que o previsto, a penalização aplicada ao valor mensal será igual à diferença entre o tempo de solução real e o previsto
multiplicada pelo valor mensal do contrato e por um índice de penalização definido de acordo
com a Severidade de cada Chamado.
Valor da Penalidade = (Tsr - Tsp) x Ip x Vmc
Tsr: Tempo de Solução Real
Tsp: Tempo de Solução Previsto
Ip: Índice de Penalização
Vmc: Valor mensal do Contrato
18-20
DMED
ETC 3.16
Os índices de penalização por nível de severidade de cada Chamado estão definidos
abaixo:
DE SOPREVIS-
TEMPO DE SOLUÇÃO PREVISTO NO PERÍODO
ESPECIAL
DE
ATENDIMENTO
ÍNDICE DE PENALIZAÇÃO
SEVERIDADE DO
CHAMADO
TEMPO
LUÇÃO
TO
Crítico
16 horas úteis
8 horas úteis
2,50%
Reduzida
36 horas úteis
36 horas úteis
1,25%
Baixa Prioridade
A combinar (*)
A combinar (*)
0,5%
9.5 Testes de Aceitação
A aceitação do sistema acontecerá nas dependências da COPEL DIS, com a aplicação de
simulações das rotinas completas descritas na presente ETC.
O Proponente deverá implantar sua solução em até 10 (dez) dias úteis após a disponibilização,
pela COPEL DIS , da Infraestrutura apresentada acima.
O prazo máximo para a verificação das funcionalidades é de 30 (trinta) dias uteis após a
disponibilização do Sistema em infraestrutura de testes a ser providenciada pela COPEL DIS.
A infraestrutura de TI para os testes de aceitação será disponibilizada pela COPEL DIS. As
características estão descritas no item 4.8 desta ETC .
O Proponente deverá implantar sua solução em até 10 (dez) dias úteis após a disponibilização,
pela COPEL, da Infraestrutura apresentada acima.
Por um período de até 20 (vinte) dias úteis, após a implantação, o proponente poderá aplicar
alterações/correções na solução que estará em testes de aceitação.
Os critérios de aceitaçaaceitação a serem verificados na aceitação do produto constam no
ANEXO I desta ETC.
19-20
DMED
ETC 3.16
ANEXO I – CRITÉRIOS PARA ACEITAÇÂO
Requisito
Critério Mínimo de Aceitação
Implementado
4.1 Acesso via WEB
4.1.2 Administração – Cadastro usuários , controle de acesso
4.1.3 Cadastro – usuário , perfil de acesso ,medidores , TC e TP ,
Ponto de Medição , pontos virtuais .
4.1.4.a Coleta – Realizar coleta de medidores homologados
4.1.4.b Coleta – Sistema de comunicação : fibra ótica, Satélite e
celular
4.1.4..e Coleta - Identificação do template do medidor
4.1.4.f Coleta Medidor Principal e retaguarda como mesmo ponto
de medição
4.1.4.g Coleta – Validação básica dos dados coletados
4.1.4.h Coleta – Configuração da frequência da realização
4.1.4.i Coleta- Gerenciar manutenções
4.1.4.j Coleta – Análises dos dados coletados
4.1.4.k Coleta – Consolidação dos dados coletados
4.1.4.l Coleta – Consolidação Manual
4.1.4.m Coleta - Contingência
4.1.5.a XML –Geração e disponibilização
4.1.5.b XML – Geração de alarmes
4.1.5.c XML - Relatório
4.1.5.d XML – Geração retroativa
4.1.5.e XML – Interferência na memoria de massa
4.1.6.a – Inspeção Lógica – Prioridade de acesso
4.1.6.b – Inspeção Lógica – Monitoramento de conexões CCEE
4.1.6.c – Inspeção Lógica – Status canais de comunicação
4.1.6.d – Inspeção Lógica - Simulações
4.1.6.e – Inspeção Lógica - Relatório
4.1.7.a – Alarmes - Disponibilização
4.1.7.b – Alarmes - Avisos
4.1.7.c – Alarmes – Relação mínima
4.2 – Sincronismo de Relógios
4.2 – Descarga de arqivos
4.3.1 – Visualização dos dados
4.3.2 – Exportação dos dados de memória de massa
4.4.3 – Visualização Gráfica – Análise da página fiscal
4.4.4 – Exportação diagrama vetorial
4.4.5 – Configuração remota de medidores
4.4.6 – Especificações dos gráficos
4.5 Visualização Consumidor
4.6 Aplicativo Gestão do Sistema
5- Teste Compatibilidade remotas CD 103
Fase Final de
Implementação
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
20-20