ASSUNTO: Temporizações do controle supervisório
PERGUNTA: Gostaríamos de saber qual o tempo máximo de atraso que poderemos ter no canal de comunicação para que a execução de um comando obtenha sucesso sem apresentar time-out ?

RESPOSTA: Existem tres parâmetros relacionados a execução e verificação de controle supervisório. São os atributos NTENT e RESPT da entidade UTR, gerenciados pelos módulos conversores de protocolo, e o atributo TRRAC da entidade CGS, gerenciado pelo módulo SAC.

O número de tentativas NTENT e o tempo de espera RESPT são usados também por outros tipos de mensagem nos protocolos de comunicação, além das de controle supervisório, e dizem respeito ao mecanismo efetuado pelos conversores de protocolo para recuperação de erros de comunicação em sessões onde o SAGE envia uma mensagem com um pedido e espera por uma mensagem de resposta que, caso não seja recebida no intervalo RESPT de centésimos de segundos, será repetida até NTENT vezes antes de declarar a ligação inoperante.

Já o temporizador TRRAC medido em segundos, é específico para aguardar a última mensagem de confirmação de término de cada ponto de controle, porque diferentes pontos de controle podem sinalizar o término da operação com diferentes tempos. Por exemplo, o controle sobre uma chave seccionadora pode demorar um tempo maior para sinalizar o término do que o controle sobre um disjuntor.

<< Voltar

ASSUNTO: Uso do SAGE em rede heterogênea
PERGUNTA: Em minha instalção disponho de máquinas PC com o sistema operacional Linux RedHat (plataforma Linux_x86) e máquinas RISC da SUN com o sistema operacional Solaris (plataforma SunOs_sparc). Gostaria de saber se é possível configurar um gateway-SAGE usando um par de máquinas constituído por uma máquina de cada tipo. Caso afirmativo, é necessária alguma configuração especial ?

RESPOSTA: Como o SAGE usa o formato XDR na difusão confiável da base de dados tempo real, a configuração de uma rede heterogênea (diferentes plataformas e sistemas operacionais) ou homogênea (plataformas e sistemas operacionais idênticos) segue os mesmos procedimentos, não sendo necessário nenhum procedimento específico para o caso em que ela é heterogênea. Além das plataformas citadas, será possível utilizar também máquinas RISC ALPHA com sistema o operacional DIGITAL-Unix (plataforma OSF1_alpha), máquinas RISC HP-64bits com o sistema operacional HP-UX (plataforma HPUX_hppa2w) e máquinas HP-Itanium2-64bits com o sistema operacional Linux RedHat (plataforma Linux_ia64).

<< Voltar

ASSUNTO: Uso de portas USB com transportadores de protocolo baseados em TTY
PERGUNTA: Disponho de um notebook com o SAGE e desejo estabelecer uma comunicação através da porta USB desse sistema, via protocolo IEC/60870-5-101, com uma UAC que possui uma porta serial RS-232. Conectei na porta USB do notebook um conversor USB/RS-232 e no arquivo SSC_Amb, a variável de ambiente TTY00 foi carregada com o valor ttyUSB0 (setenv TTY00 ttyUSB0). Quando o protocolo é ativado no SAGE, o SysLog passa a exteriorizar uma mensagem indicando a ocorrência do erro 111, que o comando perro traduz para ‘conection refused’. Gostaria de saber onde pode estar o problema desta comunicação ?

RESPOSTA: Verificando a entidade CNF de sua base de dados, observamos que a comunicação em questão está configurada para se estabelecer pela “placa 1 linha 5” (PlPr= 1 LiPr= 5). Como o valor da variável de ambiente TTY00 determina o dispositivo físico correspondente a “placa 1 linha 1”, essa configuração fêz com que o transportador de protocolo do SAGE tentasse acessar o quinto dispositivo na sequência iniciada em /dev/ttyUSB0, ou seja, o dispositivo /dev/ttyUSB4, que não existe. Considerando que o notebook dispõe de apenas uma porta USB, a porta /dev/ttyUSB0, o acesso a porta /dev/ttyUSB4 inexistente provoca o restart do transportador de protocolo e a consequente perda de sua comunicação com o conversor de protocolo, qua passa então a acusar erros na tentativa de conexão com aquele transportador. Nesse caso, a ação recomendada é alterar a base de dados para utilizar a “placa 1 linha 1” ao invés da “placa 1 linha 5”.

<< Voltar

ASSUNTO: Uso de placas de som pelo SAGE no Linux RedHat
PERGUNTA: Vou comprar uma placa de áudio CREATIVE SOUND BLASTER LIVE 5.1 e queria a orientação do CEPEL a fim de saber se tal placa funcionará no SAGE instalado em um PC com o sistema operacional Linux RedHat 7.2.

RESPOSTA: A placa de som em questão já foi testada pelo CEPEL e é utilizada por outros usuários do SAGE no mesmo tipo de instalação. Caso seja necessário verificar a compatibilidade de alguma outra placa de som com o SAGE, consulte o CEPEL porque nem todas as placas de som listadas no site da RedHat são compatíveis com o SAGE.

<< Voltar

ASSUNTO: Variáveis de ambiente NOH e LOCAL
PERGUNTA: Qual o significado das variáveis de ambiente NOH e LOCAL ? Em que situações devo alterá-las ?

RESPOSTA: A variável de ambiente NOH serve para o SAGE localizar o arquivo $BD/sites_$NOH que permitirá obter, inicialmente, os nomes dos nós da rede de difusão confiável para que, posteriormente, os IPs desses nós possam ser lidos do arquivo /etc/hosts. Uma condição mandatória de funcionamento é a de que o nome real da máquina onde o SAGE é executado deve estar listado no arquivo $BD/sites_$NOH.

A variável de ambiente LOCAL serve para que o SAGE, excetuando-se a condição descrita acima, ignore o nome real da máquina onde ele está sendo executado e, no lugar deste, use o nome contido nessa variável de ambiente para determinar as funções que devem ser executadas naquela máquina, após pesquisar este nome na tabela NOH da base de dados.

A alteração manual dessas variáveis serve quase que exclusivamente para atender casos de teste. O principal desses casos ocorre quando o nome real da máquina utilizada no teste não consta da tabela NOH cadastrada na base de dados, como por exemplo, o caso em que, numa maquina chamada est1, deseja-se executar uma base de dados que tem cadastrados os nós srv1 e srv2. Nesse caso o usuário deve providenciar que:

- no diretório $BD exista um arquivo chamado sites_est1;
- no conteúdo desse arquivo, esteja definido nome est1;
- o conteúdo da variável de ambiente NOH seja est1;
- o conteúdo da variável de ambiente LOCAL seja srv1 ou srv2.

As três primeiras ações descritas acima foram necessárias porque no arquivo sites_ALL, gerado pelo STI e comumente usado em conjunto com a variável de ambiente NOH contendo o valor ALL, não está listado, obviamente, o nome da máquina est1, mas apenas os nomes dos nós srv1 e srv2, configurados originalmente na base de dados. Por sua vêz, a quarta ação foi necessária porque, ao executar em uma máquina que se chama est1, o SAGE foi informado que deveria fazê-lo assumindo as funções definidas na base de dados para o nó srv1 ou srv2.

<< Voltar

ASSUNTO: Velocidade de canais de WAN para uso de protocolos no SAGE
PERGUNTA: Numa ligação do SAGE com uma UAC ou outro sistema, através de uma WAN, via protocolo IEC/60870-5-104 ou DNP-3.0, qual seria a velocidade mínima do canal de comunicação para garantir um bom desempenho ?

RESPOSTA: A velocidade a ser sugerida para o canal dependerá da forma que se pretende utiliza-lo. Caso o canal seja dedicado somente à comunicação tempo real sob IEC/60870-5-104 ou DNP-3.0, com eventual utilização de FTP pelo STI para transferência da base de dados fria, a velocidade de 64Kbps é suficiente. Caso o canal venha a ser utilizado para outros fins, com o uso frequente de FTP, TELNET, X-Windows, HTTP, etc, a velocidade recomendada seria de 128Kbps.

<< Voltar

ASSUNTO: Verificação de problemas na execução de cálculos codificados em ‘calculos.c’
PERGUNTA: Na tabela TCL da base fonte criei um novo tipo de cálculo com o nome ORORNOT. Através das tabelas RCA e PDS defini e relacionei respectivamente as parcelas e resultado desse novo cálculo. Após gerar a nova base, introduzi no arquivo calclulos.c a rotina equivalente de nome funcORORNOT e executei o comando instala_calculos. Agora, quando ativo o SAGE com a nova base de dados e o novo programa executável de cálculos, o processo calc não atualiza o watch-dog-timer e é desativado. Como posso fazer um ‘trace’ da nova rotina de cálculos que fiz ?

RESPOSTA: A maioria das rotinas de cálculo programadas no arquivo calclulos.c segue um padrão de programação que imprime com printf no arquivo $LOG/calc.log os erros detectados durante a sua execução. Esse método não é muito eficiente já que o usuário está acostumado a monitorar erros no SysLog do sistema e não nos arquivos individualizados de Log dos processos. Outro problema do arquivo calclulos.c é que a verificação do número de parcelas passadas para o cálculo deveria impedir o processamento do cálculo e não apenas sinalizar o erro e prosseguir. A nova versão do programa calculos.c da base demo_ems, disponível a partir do UPD-019/2002, corrige esses dois problemas sinalizando no SysLog as condições de discordancia no número de parcelas e evitando a execução desse cálculo quando esta condição ocorre.

Específicamente, o problema relatado está nesta discordância entre o número de parcelas definidas em RCA para a execução de um determinado ponto calculado PDS, e a verificação que a rotina fêz para o número de parcelas que deveriam ter sido passadas para sua execução. Ao ser acionada para realizar um cálculo que não tinha o número correto de parcelas, a rotina prosseguiu indevidamente com a execução do cálculo e o aviso dessa operação ficou registrado apenas no Log individualizado do processo, sem ser visualizado por quem acompanhava o SysLog. Além disso, o prosseguimento do cálculo tentando acessar parcelas não definidas provocou uma violação de acesso na sua execução. O exemplo abaixo mostra como deveria ser codificada a função ORORNOT:\

<< Voltar

ASSUNTO: Configuração de Grupos de diagnóstico
PERGUNTA: Como mecanismo de identificação de problemas que inviabilizam o rápido estabelecimento após ocorrências utilizamos a criação de grupos de diagnósticos do SAGE, através dos quais o operador identifica rapidamente os pontos de falha. Em alguns casos, o estado 0 (zero) do ponto digital intertrava um comando importante, assim como, outras vezes, é o estado 1 (um) que o faz. Com isso na mesma janela de diagnóstico temos alguns eventos que sinalizam em vermelho e não impedem um comando, enquanto outras vezes, outro evento é sinalizado verde e impede o comando, dificultando a identificação do ponto de falha e retardando o restabelecimento do sistema. Para resolver isso, gostaríamos que na configuração dos grupos de diagnóstico grcmp, fosse possível definir a cor (verde ou vermelha) para o estado 0 ou 1 independente da configuração do Visor de Telas e Alarmes. Assim seria possível configurar os pontos na janela de diagnóstico de forma que a cor vermelha indicasse uma necessidade de intervenção por parte do operador e a cor verde indicasse normalidade, independente do estado ser 0 ou 1. Desta forma, o operador ao abrir um grupo de diagnóstico identificaria facilmente um problema pela cor vermelha.

RESPOSTA: A configuração que está sendo usada deve ser "TPSIMB = FIGURA" nos componentes da entidade grcmp. Nesta opção, realmente os pontos digitais são representados com um desenho em verde para estado 0 e vermelho para estado 1. Para obter o efeito desejado, use:

Pontos que intertravam comandos no estado	TPSIMB	Representação no estado 0	Representação no estado 1
0 (zero)	CHECK
1 (um)	CHECK_INV

Deste modo, os pontos de falha serão apresentados no diálogo com o "X" vermelho.

Observação: Tabela completa de representação de pontos digitais em diálogos de grupo:

TPSIMB	Representação no estado 0	Representação no estado 1
FIGURA
ESTADO	Equipamento desligado	Equipamento ligado
CHECK
CHECK_INV
CHECK_SIMPLES	(vazio)
CHECK_SIMPLES_INV		(vazio)
CIRC
CIRC_INV
CIRC_SIMPLES	(vazio)
CIRC_SIMPLES_INV		(vazio)
QUAD
QUAD_INV
QUAD_SIMPLES	(vazio)
QUAD_SIMPLES_INV		(vazio)
NULO	(vazio)	(vazio)

Note que o par de textos de "TPSIMB = ESTADO" é obtido a partir da ocr de cada ponto.

A opção "TPSIMB = FIGURA" usa o desenho de retângulo para disjuntores, o desenho de chave para chaves seccionadoras e de distribuição e o desenho de uma ficha para os demais pontos digitais.

A opção "TPSIMB = NULO" é útil apenas quando se deseja apresentar o identificador ou a narrativa do ponto, sem representação de estado.