O PRESIDENTE DO INSTITUTO NACIONAL DE METROLOGIA, NORMALIZAÇÃO E QUALIDADE INDUSTRIAL - INMETRO, no uso de suas atribuições, conferidas pelo § 3º do art. 4º da Lei nº 5.966, de 11 de dezembro de 1973, e tendo em vista o disposto nos incisos II e III do art. 3º da Lei nº 9.933, de 20 de dezembro de 1999, no inciso V do art. 18 da Estrutura Regimental do Inmetro, aprovada pelo Decreto nº 6.275, de 28 de novembro de 2007, e pela alínea a do subitem 4.1 da Regulamentação Metrológica aprovada pela Resolução nº 11, de 12 de outubro de 1988, do Conselho Nacional de Metrologia, Normalização e Qualidade Industrial - Conmetro, Considerando as disposições contidas na Portaria Inmetro nº 371, de 28 de setembro de 2007, que estabelece as condições mínimas a que devem satisfazer os sistemas de medição centralizada, doravante denominados sistemas distribuídos de medição de energia elétrica;

Considerando a necessidade de implementar o controle metrológico dos software para sistemas distribuídos de medição de energia elétrica;

Considerando os requisitos de software descritos na Norma WELMEC 7.2: Software Guide - Measuring Instruments Directive 2004/22/EC, Maio 2008), bem como no Documento Internacional da Organização Internacional de Metrologia Legal - OIML D31/2008:

General Requirements of Software Controlled Measuring Instruments,

Resolve:

Art. 1º Aprovar o Regulamento Técnico Metrológico, anexo à presente Portaria, estabelecendo as condições mínimas a que deverão satisfazer os software para sistemas distribuídos de medição de energia elétrica para uso em unidades consumidoras.

Art. 2º Estabelecer as seguintes características funcionais para o dispositivo indicador, doravante denominado dispositivo mostrador, instalado no local da unidade consumidora que forneça a totalização de consumo de energia elétrica:

a) Tamanhos dos dígitos: a altura dos dígitos das grandezas e códigos identificadores apresentados no mostrador, não deve ser inferior a 5,0 mm e a largura não deve ser inferior a 2,50 mm.

b) Quantidade de dígitos: deve ter a quantidade de dígitos suficiente no mostrador para atender ao requisito específico estabelecido no Regulamento Técnico Metrológico, anexo à presente Portaria.

Art. 3º Estabelecer para o cálculo de consumo de energia elétrica a resolução mínima de 100 watts-horas (Wh).

Art. 4º Determinar que a infringência a quaisquer dispositivos da presente Portaria sujeitará os infratores às penalidades previstas no art. 8º da Lei nº 9.333, de 20 de dezembro de 1999.

Art. 5º Esta Portaria entrará em vigor na data de sua publicação no Diário Oficial da União.

JOÃO ALZIRO HERZ DA JORNADA

ANEXO
REGULAMENTO TÉCNICO DE SOFTWARE

1. OBJETIVO E CAMPO DE APLICAÇÃO

1.1 Este Regulamento estabelece os requisitos técnicos de software para sistemas distribuídos de medição de energia elétrica SDMEE) para uso em unidades consumidoras.

1.2 Para efeito de aplicação deste Regulamento, o SDMEE alvo é composto por todos os elementos envolvidos na captura, processamento e publicação do resultado (dispositivo mostrador) ao usuário final (consumidor).

1.3 Os elementos do SDMEE diretamente envolvidos ou que de alguma forma interfiram nos processos de captura, processamento publicação do resultado ao usuário final, são ditos "legalmente relevantes" e devem atender na totalidade ao conjunto de requisitos contidos neste Regulamento.

1.4 As Figuras 1 e 2 exemplificam as duas diferentes configurações arquiteturais possíveis do SDMEE com seus respectivos elementos considerados legalmente relevantes destacados por linha pontilhada. Os demais elementos não contidos no interior do espaço pontilhado não são considerados legalmente relevantes por não envolverem diretamente, ou interferirem de alguma forma, nos processos de captura, processamento e publicação do resultado ao usuário final.

Figura 1

Figura 2

1.5 Todas as evidências para o convencimento quanto ao cumprimento dos requisitos estabelecidos no presente Regulamento devem ser providas pelo fabricante.

2. TERMINOLOGIA

2.1 Legalmente relevante Software/hardware/dados que interferem nos requisitos regulamentados pela metrologia legal, por exemplo, a exatidão de medição, ou no correto funcionamento do referido sistema.

É de responsabilidade da autoridade nacional encarregada da regulamentação de metrologia legal especificar qual software/hardware/dados é considerado legalmente relevante.

2.2 Interface de comunicação Qualquer tipo de interface que habilite a transferência de informações entre os componentes dos sistemas de medição (óptica, rádio, eletrônica, etc).

2.3 Autenticação Comprovação da identidade declarada/alegada de um usuário, processo ou dispositivo.

2.4 Integridade Garantia de que os dados/software/parâmetros não foram alterados durante o uso, reparo, manutenção, transferência ou armazenamento sem que haja a autorização.

2.5 Confidencialidade Garantia de que os dados/parâmetros não foram divulgados à pessoas físicas ou jurídicas ou processos sem autorização durante o uso, reparo, manutenção, transferência ou armazenamento.

2.6 Disponibilidade Garantia de que os dados/software/parâmetros/sistema estão disponíveis aos processos ou pessoas jurídicas autorizadas quando solicitados.

2.7 Ataque Qualquer ação não autorizada que possa comprometer a segurança dos dados/parâmetros/software/ sistema.

2.8 Carga (download)

Processo de transferência automática de software para o sistema distribuído de medição usando qualquer meio apropriado local ou remoto.

2.9 Identificador de software Seqüência de caracteres legíveis atribuída univocamente a um software.

2.10 Interface de usuário Permite a troca de informações entre o usuário humano e o sistema distribuído de medição, ou seus componentes de hardware e software.

2.11 Validação Confirmação através de análise e geração de evidências objetivas que os requisitos específicos de uso foram satisfeitos integralmente.

2.12 Hash Função matemática que mapeia valores de um bloco de dados em um número de tamanho fixo e reduzido (código hash), com as seguintes propriedades:

(i) a mudança em qualquer bit de um bloco de dados implica em um código hash diferente;

(ii) não é viável a partir de um código hash retornar ao bloco de dados original;

(iii) não é viável encontrar dois blocos que gerem o mesmo código hash.

2.13 Assinatura digital Código univocamente atribuído a um arquivo de texto/dados/software de forma a provar a sua integridade e autenticidade quando da transmissão ou armazenamento. Usualmente uma assinatura digital é gerada em duas etapas:

(i) calcula-se inicialmente o código hash do arquivo;

(ii) codifica-se este código usando uma chave privada.

3. REQUISITOS P: SOFTWARE EMBARCADO PARA SISTEMAS DE MEDIÇÃO

Sistemas de medição do tipo P são aqueles que fazem uso de um software embarcado, de acordo com as seguintes considerações:

a) Todo o software aplicativo foi desenvolvido para medição, incluindo as funções sujeitas ao controle metrológico legal, assim como as restantes;

b) O software é projetado e tratado como um todo, a menos que exista uma separação de software conforme os requisitos descritos no item 5 (requisitos S - Separação de software);

c) A interface do usuário é dedicada à aplicação de medição;

d) Não existe um sistema operacional para compartilhamento dos recursos computacionais com outros usuários;

e) O software e o seu ambiente são invariáveis: não existem meios disponíveis para se alterar o software legalmente relevante; a carga de software só é permitida quando os requisitos descritos no item 6 (requisitos tipo D - Download de software legalmente relevante) forem atendidos;

f) Interfaces para a transmissão dos dados das medições através de redes de comunicação são permitidas desde que atendam aos requisitos de 3.5 (Influência da interface de comunicação no SDMEE).

3.1 Os requisitos do tipo P são divididos em:

a) Documentação;

b) Identificação do software;

c) Influência da interface do usuário no SDMEE;

d) Influência da interface de comunicação no SDMEE;

e) Proteção contra mudanças acidentais/não-intencionais;

f) Proteção contra mudanças intencionais;

g) fProteção dos parâmetros.

3.2 Documentação Além da documentação específica necessária para a avaliação dos demais requisitos descritos na totalidade deste documento, o regulamento deve basicamente incluir:

a) Descrição arquitetural e código fonte comentado de todo o software legalmente relevante;

b) Descrição da exatidão dos algoritmos de medição (cálculo e arredondamentos dos resultados);

c) Descrição da interface do usuário, menus e diálogos (se existir);

d) Identificação inequívoca do software;

e) Descrição do sistema de hardware, que contemple: topologia, diagrama de blocos, tipo de processador, e tipo de rede;

f) Manual operacional.

3.3 Identificação do software Os softwares legalmente relevantes devem ser claramente identificados. A identificação do software deve ser indissoluvelmente ligada ao software. Deve ser apresentada sob comando ou automaticamente durante a operação do SDMEE.

3.3.1 Requisitos técnicos

a) Cada mudança no software definido como legalmente relevante deverá ser avaliada e aprovada pelo Inmetro e possuir um novo identificador.

b) O identificador de software deve ter uma estrutura que identifica claramente as versões que necessitam de avaliação e aprovação e aquelas que não precisam.

3.3.2 Documentação exigida A documentação deve descrever os identificadores de software, a forma como foram criados, como os identificadores estão indissoluvelmente ligados aos softwares, como os identificadores podem ser acessados para visualização e como estão estruturados de forma a diferenciar entre as versões que requerem ou não aprovação das alterações.

3.4 Influência da interface do usuário no SDMEE

Nenhum dos comandos gerados através da interface da distribuidora de energia elétrica deve influenciar o software legalmente relevante, nem os dados das medições, de forma não prevista na descrição apresentada no processo de aprovação de modelo.

3.4.1 Requisitos técnicos

a) Os comandos podem ser disparados através de uma única atuação de uma tecla ou por uma seqüência de atuações realizadas manualmente.

b) Deve haver uma atribuição unívoca e não ambígua de cada comando e de sua função ou do procedimento de mudança de dados.

c) O acionamento das teclas que não são explicitamente declaradas e documentadas como comandos não pode ter qualquer efeito sobre as funções do sistema ou medições.

3.4.2 Documentação exigida

a) Uma lista completa de todos os comandos existentes junto com uma declaração de completude.

b) Uma descrição do significado de cada comando e seus efeitos nas funções e dados do sistema.

c) Descrição dos procedimentos realizados para validar a completude dos comandos.

d) Descrição dos ensaios realizados para provar a funcionalidade declarada dos comandos.

3.5 Influência da interface de comunicação no SDMEE

Comandos introduzidos através de interfaces de comunicação do SDMEE não devem influenciar o software legalmente relevante ou os dados das medições, de forma não prevista na descrição apresentada no processo de aprovação de modelo.

3.5.1 Requisitos técnicos

a) Deve existir uma atribuição unívoca e não ambígua de cada comando para uma função ou uma alteração de dados.

b) Sinais ou códigos que não são declarados e documentados como comandos não podem ter qualquer efeito sobre as funções e os dados do sistema.

c) Comandos podem ser uma seqüência de sinais (elétricos, ópticos, eletromagnéticos), canais de entrada ou códigos de protocolos de transmissão de dados.

d) Esta exigência aplica-se apenas em interfaces que não estão seladas.

3.5.2 Documentação exigida

a) Uma lista completa de todos os comandos juntamente com uma declaração de completude.

b) Uma descrição do significado de cada comando e o seu efeito sobre as funções e os dados do SDMEE.

c) Os procedimentos empregados para validar a completude dos comandos documentados.

d) Descrição dos ensaios realizados para provar a funcionalidade declarada dos comandos.

3.6 Proteção contra mudanças acidentais ou não intencionais Os softwares legalmente relevantes e os dados de medição devem ser protegidos contra modificações acidentais ou não intencionais.

3.6.1 Os possíveis motivos para modificações acidentais e não intencionais são:

a) Influências físicas imprevisíveis - O armazenamento dos dados das medições deve ser protegido contra a corrupção ou supressão na presença de uma falhas ou, alternativamente, a falha (erro) deve ser detectável.

b) Efeitos causados por funções de usuário - A confirmação deve ser exigida antes de suprimir ou alterar os dados.

c) Defeitos residuais do software - Devem ser tomadas medidas adequadas para proteger os dados de mudanças não intencionais que possam ocorrer através de um projeto incorreto ou erros de programação, por exemplo, verificações da plausibilidade.

3.6.2 Documentação exigida

A documentação deve mostrar as medidas que foram tomadas para proteger o software/dados contra alterações não intencionais.

3.7 Proteção contra mudanças intencionais

Os softwares legalmente relevantes devem ser protegidos contra modificações, cargas e substituição (swapping) de memória.

3.7.1 Requisitos técnicos

a) Sistema sem interface: deve-se garantir que o gabinete do sistema seja seguro (inviolável), ou que a memória física não possa ser removida sem autorização.

b) Sistema com interface: a interface deve conter apenas funções passíveis de serem examinadas.

c) Os dados são considerados suficientemente protegidos se forem processados apenas por software legalmente relevante. Caso haja a necessidade de alteração de software que não seja legalmente relevante, depois da avaliação e aprovação por parte do Inmetro, os requisitos do tipo 'S', definidos no item 5, devem ser atendidos.

3.7.2 Documentação exigida A documentação deve fornecer garantias de que o software legalmente relevante não pode ter modificações inadmissíveis, sendo que as medidas de proteção tomadas contra mudanças intencionais devem estar destacadas no código fonte.

3.8 Proteção dos parâmetros Os parâmetros que fixam as características legalmente relevantes do sistema distribuído de medição devem ser protegidos contra modificações não autorizadas.

3.8.1 Requisito técnico Parâmetros específicos de modelo são idênticos para todos os exemplares do mesmo modelo e são, em geral, parte do código do programa. Além disso, devem satisfazer aos requisitos descritos no subitem 3.7.

3.8.2 Documentação exigida Descrição de todos os parâmetros legais pertinentes, incluindo:

a) valores nominais e margens de variação;

b) onde são armazenados;

c) como podem ser visualizados;

d) como são protegidos;

e) quando (se antes ou depois da avaliação e aprovação pelo Inmetro).

4. REQUISITOS T: TRANSMISSÃO DOS DADOS ATRAVÉS DE REDES DE COMUNICAÇÃO

O conjunto de requisitos T se aplica apenas quando o sistema utiliza internamente uma rede de comunicação para transmitir e receber dados das medições que são legalmente relevantes. O conjunto de requisitos para a transmissão dos dados via rede são:

a) Completude dos dados transmitidos;

b) Proteção contra mudanças acidentais ou não intencionais;

c) Integridade dos dados;

d) Autenticidade dos dados transmitidos;

e) Confidencialidade das chaves;

f) Manipulação de dados corrompidos;

g) Atraso de transmissão;

h) Disponibilidade dos serviços de transmissão.

4.1 Completude dos dados transmitidos Os dados transmitidos devem incluir todas as informações necessárias à apresentação ou processamento da medição no dispositivo receptor.

4.1.1 Requisitos técnicos

O conteúdo metrológico dos dados transmitidos é composto de:

a) um ou mais valores de medição na resolução correta;

b) a unidade de medida;

c) uma informação temporal;

d) a identificação do ponto da medição.

4.1.2 Documentação exigida

Descrição de todos os campos das unidades de dados transmitidas.

4.2 Proteção contra mudanças acidentais ou não intencionais Os dados transmitidos devem ser protegidos contra mudanças acidentais ou não intencionais. Alterações acidentais de dados são causadas por fenômenos físicos, e mudanças não intencionais são causadas pelo usuário do sistema.

4.2.1 Requisito técnico

Devem ser providenciados meios para a detecção de erros de transmissão.

4.2.2 Documentação exigida

a) Descrição do algoritmo de checksum (se utilizado), incluindo o comprimento do polinômio gerador.

b) Descrição do método alternativo (se for o caso, ex: hash).

4.3 Integridade dos dados transmitidos

Os dados legalmente relevantes transmitidos devem ter sua integridade verificada e somente podem ser usados se esta for constatada.

4.3.1 Documentação exigida

Descrição do método de verificação de integridade.

4.4 Autenticidade dos dados transmitidos

Deve ser possível verificar a autenticidade e a atribuição dos valores de medição a um determinado ponto de medição na recepção dos dados.

4.4.1 Requisitos técnicos

a) É necessário identificar a origem, sem ambigüidade, dos dados de medição transmitidos.

b) Para fazer frente aos possíveis atrasos da transmissão dos dados, é necessário que o instante da medição seja registrado junto ao valor da medição.

c) Para garantir a autenticidade não é necessário criptografar os dados.

4.4.2 Documentação exigida

Descrição dos mecanismos (TI) que garantem a correta atribuição do valor de uma medição a um medidor específico.

4.5 A confidencialidade das chaves

As chaves criptográficas (e dados correlatos), caso sejam utilizadas, devem ser tratadas como dados legalmente relevantes e devem ser mantidas em segredo e protegidas para que não sejam corrompidas.

4.5.1 Requisito técnico

A proteção deve cobrir tentativas de mudanças intencionais a partir de ataques.

4.5.2 Documentação exigida

Descrição dos principais mecanismos de manipulação e gerência das chaves para mantê-las secretas.

4.6 Manipulação de dados corrompidos

Os dados que são detectados como corrompidos não devem ser utilizados.

4.6.1 Documentação exigida

a) Descrição do mecanismo de detecção de erros de transmissão ou mudanças intencionais.

b) Descrição dos mecanismos usados para a manipulação dos dados corrompidos.

4.7 Atraso de transmissão

Uma medição não pode ser influenciada pela comunicação.

4.7.1 Requisitos técnicos

O fabricante deve garantir que, mesmo sob as piores condições do meio de comunicação (alto tráfego por exemplo), a mesma não invalidará as medições.

4.7.2 Documentação exigida

Descrição de como a medição é protegida contra a atuação dos dispositivos de comunicação e do processamento decorrente destes.

4.8 Disponibilidade dos serviços de transmissão

Mesmo que os serviços de rede de comunicação se tornem indisponíveis, não deve haver perda de dados das medições, e o dispositivo mostrador instalado no consumidor deve sinalizar tal situação.

4.8.1 Requisito técnico

O usuário do sistema distribuído de medição não deve ser capaz de corromper dados das medições em função da supressão da transmissão. O sistema distribuído de medição deve ser capaz de lidar com problemas de transmissão.

4.8.2 Documentação exigida

Descrição dos procedimentos de proteção contra a interrupção da transmissão ou outros erros.

5. REQUISITOS S: SEPARAÇÃO DE SOFTWARE

Os SDMEE controlados por software podem ter funcionalidades complexas e conter módulos que são legalmente relevantes e módulos que não são. A separação de software é uma metodologia que permite ao fabricante modificar facilmente o software que não é legalmente relevante.

Os requisitos de separação de software são:

a) Realização da separação de software;

b) Apresentação compartilhada;

c) Interface de software protetora.

5.1 Realização da separação de software

Deve haver uma parte do software que contém todos os módulos e parâmetros legalmente relevantes, claramente separada dos outros componentes de software.

5.1.1 Requisitos técnicos

a) Pertencem ao software legalmente relevante, no caso de separação de baixo nível, todas as unidades de programa (sub-rotinas, procedimentos, funções, classes) e, no caso de separação de alto nível, todos os programas e bibliotecas que contribuem para:

- o cálculo de medição de valores ou que tenham um impacto sobre o mesmo;

- funções auxiliares como a exibição de dados, segurança de dados, armazenamento de dados, identificação de software, carga de software, transmissão ou armazenamento de dados, checagem ou armazenamentos dos dados recebidos.

b) Pertencem ao software legalmente relevante todas as variáveis, arquivos temporários e os parâmetros que tenham impacto sobre os valores da medição ou funções legalmente relevantes, ou ainda, dados.

c) Os componentes da interface de software protetora (ver 5.3) são parte do software legalmente relevante.

d) O software legalmente não relevante inclui as unidades de programa restantes e os dados ou parâmetros não incluídos nas categorias anteriores. Modificações a esta parte são permitidas desde que os requisitos de separação de software sejam observados.

5.1.2 Documentação exigida

Descrição de todos os componentes descritos acima que pertencem ao software legalmente relevante. A correta implementação da separação de software deve estar demonstrada na documentação.

5.2 Apresentação compartilhada

Informações adicionais geradas pelo software que não é legalmente relevante só podem ser exibidas (ou impressas) caso elas não possam ser confundidas com as informações que se originam a partir da parte legalmente relevante.

5.2.1 Documentação exigida

a) Descrição do software que realiza a apresentação.

b) Descrição de como a apresentação da informação legalmente relevante é feita, sendo que a existência de apresentação compartilhada deve ser explicitamente documentada.

5.3 Interface de software protetora

A troca de dados entre os softwares legalmente relevantes e não relevantes deve ser realizada através de uma interface protetora que abranja todas as interações e fluxos de dados.

5.3.1 Requisitos técnicos

a) Quaisquer interações e fluxos de dados não devem influenciar de forma inadmissível o software legalmente relevante, incluindo o comportamento dinâmico do processo de medição.

b) Deve haver uma atribuição inequívoca de cada comando enviado através da interface de software para uma função ou uma alteração de dados do software legalmente relevante.

c) Códigos e dados que não são declarados e documentados como comandos não devem ter nenhum efeito sobre o software legalmente relevante.

d) A interface deve ser completamente documentada e quaisquer outras interações/fluxo de dados não documentadas não devem ser realizadas nem pelo programador do software legalmente relevante, nem pelos programadores do software não relevante.

5.3.2 Documentação exigida

a) Descrição da interface do software.

b) Uma lista completa de todos os comandos juntamente com uma declaração de completude.

c) Uma descrição dos comandos e os seus efeitos sobre as funções e os dados do SDMEE.

6. REQUISITOS TIPO D: CARGA DE SOFTWARE LEGALMENTE RELEVANTE

Os requisitos do tipo 'D' devem ser utilizados para possibilitar a carga (download) de software legalmente relevante. A carga de software legalmente não relevante não está sujeita a estes requisitos.

O conjunto de requisitos para carga de software legalmente relevante consiste de:

a) Mecanismo de carga (download);

b) Autenticação do software carregado remotamente;

c) Integridade do software carregado;

d) Rastreabilidade do software carregado;

e) Permissão para carga.

6.1 Mecanismo de carga (download)

A carga e a subsequente instalação de software devem ser automáticas e devem garantir o não comprometimento do ambiente de proteção do software no final do processo.

6.1.1 Requisitos técnicos

a) O procedimento de carga deve ser automático visando assegurar que o nível de proteção existente não seja comprometido.

b) O dispositivo alvo deve ter um software legalmente relevante permanentemente residente e invariável, com todas as funções necessárias para verificar os requisitos definidos nos subitens '6.2' a '6.5'.

c) O dispositivo deve ser capaz de detectar uma falha de carga ou instalação, gerando uma sinalização do ocorrido. Se a carga ou a instalação fracassar, ou se for interrompida, o estado inicial do sistema não deve ser afetado. Caso não seja possível, o sistema deve exibir uma mensagem de erro permanente e o seu funcionamento metrológico deve ser impedido, até que o erro seja corrigido.

d) No caso de uma instalação bem sucedida, todas as formas de proteção devem ser restauradas para o seu estado original, a menos que o software carregado tenha a devida autorização para alterá-las.

e) Durante a carga e a instalação de novo software as funções de medição do sistema devem ser impedidas, caso não possam ser completamente garantidas.

f) Mesmo que os requisitos definidos nos subitens '6.2' a '6.5' não possam ser cumpridos, ainda sim é possível fazer a carga da parte do software legalmente não relevante, desde que as seguintes exigências sejam cumpridas:

- exista uma clara separação entre o software legalmente relevante e o não relevante, de acordo com os requisitos do item 5 (Requisitos S - Separação de software);

- toda a parte do software legalmente relevante seja permanente e invariável, isto é, não possa ser carregada ou alterada sem a quebra de um selo.

6.1.2 Documentação exigida

A documentação deve descrever: o processo automático da carga, o processo de verificação e instalação, como o nível de proteção é garantido no final, e o que acontece quando ocorre uma falha.

6.2 Autenticação do software carregado remotamente

Devem ser empregados meios para garantir a autenticidade do software carregado, e para indicar que este software foi previamente avaliado e aprovado.

6.2.1 Requisitos técnicos

a) Antes da utilização do software carregado, o SDMEE deve verificar automaticamente se:

- o software é autêntico (e não uma fraude);

- o software é aprovado para esse tipo de sistema distribuído de medição.

b) Os meios pelos quais o software identifica a sua autorização prévia devem ser protegidos para evitar a falsificação.

6.2.2 Documentação exigida

A documentação deve descrever como:

a) A autenticidade da identificação do software é garantida;

b) A autenticidade da aprovação prévia é garantida;

c) É garantido que o software carregado foi aprovado para o tipo de SDMEE em questão.

6.3 Integridade do software carregado

Devem ser empregados meios para garantir que o software tenha sua integridade verificada e somente possa ser usado se esta for constatada.

6.3.1 Documentação exigida

A documentação deve descrever a forma como a integridade do software é garantida.

6.4 Rastreabilidade do software carregado

Devem ser garantidos por meios técnicos apropriados que todos os softwares carregados são devidamente identificados e registrados no sistema distribuído de medição, para fins de controle a posteriori.

6.4.1 Requisitos técnicos

Os procedimentos e registros responsáveis pela rastreabilidade são parte do software legalmente relevante e devem ser protegidos como tal.

6.4.2 Documentação exigida

A documentação deve:

a) Descrever a forma como a rastreabilidade é implementada e protegida;

b) Demonstrar como as cargas de software são rastreadas.

6.5 Permissão para carga

Deve ser garantido por meios técnicos que o software só possa ser carregado com a permissão explícita da distribuidora de energia elétrica proprietária do SDMEE.

6.5.1 Requisitos técnicos

a) Depois que um sistema distribuído de medição tenha sido posto em serviço, a distribuidora de energia elétrica é responsável por controlar a permissão de carga. Este requisito garante que o fabricante não possa alterar o software legalmente relevante do SDMEE sem o consentimento explícito da distribuidora.

b) O meio pelo qual a distribuidora de energia elétrica proprietária exprime a sua permissão é parte do software legalmente relevante e deve ser protegido como tal. Sua permissão é necessária por "default" a menos que se estabeleça em contrário.

c) A disponibilidade do dispositivo para carga deve ser indicada para a distribuidora de energia elétrica.

6.5.2 Documentação exigida

A documentação deve descrever os meios técnicos pelos quais o processo de carga considera a permissão da distribuidora de energia elétrica.

7. AUTO-DIAGNÓSTICO DE FALHAS

O software deve ser capaz de diagnosticar um estado de mau funcionamento.

7.1 Documentação exigida

a) Descrição do mecanismo de diagnóstico de falhas e quando ele é invocado;

b) Descrição dos testes realizados pelo fabricante.

7.2 Cópias de segurança (backup)

Deve haver um mecanismo que preveja cópias periódicas dos dados legalmente relevantes, tais como os resultados de medição e o 'status' atual dos processos, de forma a possibilitar uma posterior recuperação do sistema distribuído de medição após um mau funcionamento.

Esses dados devem ser salvos em mídia não-volátil.

7.2.1 Requisitos técnicos

A freqüência de atualização das cópias de segurança deve ser compatível com o mecanismo de diagnóstico de falhas.

7.2.2 Documentação exigida

Uma descrição dos dados com cópia, uma descrição da freqüência de atualização e o cálculo usado para justificar esta freqüência.

8. ADEQUAÇÃO DO DISPOSITIVO MOSTRADOR (DISPLAY)

8.1 O dispositivo mostrador eletrônico ou eletromecânico deve ser capaz de registrar, partindo do zero, por um tempo mínimo de 1150h, a energia correspondente à máxima corrente na maior tensão nominal e fator de potência unitário.

8.2 O tempo máximo de atualização permitido para cada kWh consumido é de 1min.

8.3 O dispositivo mostrador deve ser capaz de exibir as informações requeridas no subitem 4.1.1.

8.4 Documentação exigida

Documentação referente à forma de parametrização das informações apresentadas pela interface do usuário final (dispositivo mostrador). Por exemplo: número de dígitos, resolução, tempo de apresentação, etc.

9. COMPORTAMENTO DINÂMICO

O software que não é legalmente relevante não pode influenciar negativamente no comportamento dinâmico de um processo de medição. Isso significa que, caso haja um compartilhamento de recursos de processamento, o software legalmente relevante deve sempre ter a disponibilidade necessária para o seu bom funcionamento (ex. prioridade superior ao software não relevante).

9.1 Requisitos técnicos

a) Este requisito aplica-se em complemento aos requisitos definidos em 5.1, 5.2 e 5.3 de separação de software.

b) Esse requisito adicional garante que, para aplicações em tempo real de medidores, o comportamento dinâmico do software legalmente relevante não é influenciado por software legalmente não relevante, ou seja, os recursos do software legalmente relevante não podem ser alterados de forma não admitida pela parte não relevante.

9.2 Documentação exigida

a) Descrição da hierarquia de interrupção.

b) Diagrama temporal das tarefas de software. Limite de tempo de execução destinado às tarefas legalmente não relevantes.

10. REQUISITOS DE VALIDAÇÃO DO SOFTWARE

Deve-se enumerar as técnicas usadas para a validação do software, junto com o resultado dos testes implementados. Espera-se como resultados desta fase de validação a erradicação de erros previsíveis como: extrapolação dos limites de entrada/saída e divisão por zero.

11. CAPACIDADE DE CARGA DE PROCESSAMENTO

Todos os elementos constituintes do sistema distribuído de medição de energia elétrica (SDMEE) de uso compartilhado (concentradores, redes de comunicação) devem ser dimensionados em função dos instantes de maior carga. Todos os cálculos que comprovem a capacidade de compartilhamento devem ser fornecidos.