Aplicação Default Enterprise
Objetivo
Quando o usuário cria uma nova aplicação a partir da aplicação Enterprise, como apresentado na figura abaixo, esta já vem com um conjunto de tags, telas, alarmes, etc. pré-prontos. Estas informações são designadas “Aplicação Default” e permitem que o usuário às utilize para mais rapidamente gerar a sua aplicação.
A seguir são apresentadas as informações sobre a “Aplicação Default” e como usá-las no desenvolvimento de uma nova aplicação.
Deve-se observar que as informações apresentadas aqui deverão evoluir com o tempo, dado que a Spin, em função de solicitação de usuários, deverá sempre aprimorar a Aplicação Default, disponibilizando novas funcionalidades, Símbolos, Figuras, etc.
Objetos da Aplicação Default
A Aplicação Default já vem com um conjunto de telas prontas que o usuário poderá usar em sua aplicação. Para o tratamento destas tela também existe um conjunto de tags, pré-definidos.
Nesta seção são apresentados estes objetos.
Layout Default
Existe um único layout na Aplicação Default: o layout Startup que tem a forma de uma tela com cabeçalho e rodapé, conforme a configuração mostrada na figura abaixo:
O formato geral da tela que utiliza este layout Startup, é mostrado na figura seguinte:
Este layouts é usado para apresentar todas as telas prontas da Aplicação Default.
Caso os usuários desejam desenvolver novos layouts, basta criá-los e observar que antes de carregar uma tela deve-se carregar seu leiaute.
Abaixo, a título de exemplo, é mostrada a dinâmica do botão que abre a tela de informações, onde se executa duas expressões que abrem, respectivamente, o leiaute e a tela de informações:
Telas Disponibilizadas
Acima é apresentado o cabeçalho da aplicação default onde:
O símbolo quando selecionado, troca o idioma da aplicação default (inglês ßà/ português);
O símbolo retorna para a tela anterior;
O símbolo vai para a tela principal da aplicação default, que inicialmente é uma tela vazia com um compasso. O usuário pode alterar esta tela (AN_MainPage) para ser sua tela de abertura;
O símbolo abre a tela de consulta a medidas históricas (AN_HistoricMeasuresQuery);
O simbolo abre a tela de consulta ao sumário de tags da aplicação (AN_TagsSummary);
O simbolo abre a tela de alarmes correntes (AN_AlarmsSummary);
O símbolo abre a tela de eventos do dia (AN_EventsSummary);
O símbolo abre a tela de consulta a eventos históricos (AN_HistoricEventsSummary);
O simbolo abre a tela de tendência em tempo real e histórica (AN_TrendScreen);
O símbolo abre a tela de log de operação (AN_Operation_Log);
O símbolo cala o alarme sonoro;
O símbolo abre a tela de informações do projeto (AN_About).
Quando a Aplicação Default é ativada, estas telas estão vazias e sem filtros, pois não existem variáveis do usuário nesta aplicação.
Criação dos Níveis (Assets)
Todos os tags existentes na “Aplicação Default” foram criados para gerar as telas disponibilizadas nesta aplicação assim como fazer filtros destas telas que permitem selecionar coleções de tags associados à prioridade de alarme, categoria, nível, etc.
Estes tags são associados ao nível “SysInternals” que corresponde a um conjunto de variáveis internas da aplicação, não utilizáveis nas telas geradas automaticamente. Dessa forma, as variáveis utilizadas nestas telas têm como restrições:
n Não podem ser do tipo SysInternals;
n Devem ser de nível (Asset) similar ao SysInternal ou superior;
n Devem ser do domínio do servidor (isto é, não podem ser variáveis associadas a uma estação de trabalho = Client);
Antes do usuário criar seus templates e tags, ele deve fazer a árvore da sua aplicação (Assets) que corresponderá aos níveis utilizados para filtrar variáveis.
Como exemplo, abaixo é apresentada uma árvore de níveis considerando uma subestação com duas linhas de 138 kV uma barra B1, um transformador T1 de 138/13,8 kV e três bays de alimentadores de 13,8 kV.
No caso acima, serão criados seis bays (vãos):
n Line_01
n Line_02
n Trafo_01
n Alim_01
n Alim_02
n Alim_03
Categorias
Na “Aplicação Default” são disponibilizadas quatro categorias que tem as seguintes funcionalidades:
1. AN_GROUP_ALARM: Esta categoria deve ser associada a todo o bay / agrupamento ao qual se deseja associar um alarme de grupo. Assim, por exemplo, se a cada alimentador deseja-se criar uma variável que informa se existe algum tag deste alimentador em alarme, deve-se associar este alimentador a esta categoria;
2. AN_GRUALM_ALM: Todos os bays / agrupamentos que tem tratamento de alarme de grupo deverão ter uma variável calculada do tipo digital com esta categoria associada. Esta variável terá o valor igual a 1, se pelo menos um tag deste bay / agrupamento estiver em alarme;
3. AN_DESBALANCO: Esta categoria é utilizada para o cálculo de desbalanço de corrente de circuitos com duas e três fases. Circuitos com três fases também deverão incluir a categoria AN_TRIFASICA. Observar que no calculo feito na Aplicação Default pela rotina: (Script / Classes / AN_DesbalançoCorrente) é exigido que as variáveis sejam declaradas no template Correntes.
4. AN_TRIFASICA: Categoria usada em desbalanço de corrente trifásica.
Security da Aplicação Default
Na aplicação Default estão criados sete usuários com as permissões conforme a figura abaixo:
As senhas são:
Gest à sem senha Administrador à sem senha
User à sem senha Super à s
Admin à sdop3985 Opercom à o
Oper à o
Alarmes da Aplicação Default
Na Aplicação Default já estão criados vários comportamentos de Alarmes com procedimentos padronizados em relação a sua inserção nas telas geradas automaticamente. A figura abaixo mostra estes alarmes:
Na Aplicação Default as mensagens geradas pelos AlarmGroups que tiverem prioridades entre 1 e 10, serão inseridas no Sumário de Alarmes, e somente permanecerão lá enquanto estiverem no estado ACTIVE. Todas as mensagens, tanto de ativação quanto de normalização de alarmes são inseridas no Sumário de Eventos e permanecem lá durante todo o dia em que foram geradas.
Portanto a definição de prioridade deverá ser feita pelo usuário de acordo com sua preferência no tratamento das mensagens.
No ambito do Action.NET, denomina-se Eventos todas as ocorrências que devem ser registradas em histórico e denomina-se Alarmes as ocorrências que devem ser verificadas e requerem uma ação, pois se referem a situações de falha na aplicação.
Os textos utilizados para compor os nomes dos AlarmGroups tem o seguinte significado:
ACK - Exigem reconhecimento
NOACK = Não exigem reconhecimento
BIP - Causam alarme sonoro
NOBIP - Não utilizam alarme sonoro na sua ativação
Utilizam condition Change e são destinados a somente aparecer em Sumario de Eventos, Os itens devem ser criados com prioridade maior do que 10.
EVENTOS_BIP
EVENTOS_NOBIP
Utilizam condition HI
HI_ACK_BIP
HI_ACK_NOBIP
HI_NOACK_BIP
HI_NOACK_NOBIP
Utilizam condition HIHI
HIHI_ACK_BIP
HIHI_ACK_NOBIP
HIHI_NOACK_BIP
HIHI_NOACK_NOBIP
Utilizam condition LO
LO_ACK_BIP
LO_ACK_NOBIP
LO_NOACK_BIP
LO_NOACK_NOBIP
Utilizam condition LOLO
LOLO_ACK_BIP
LOLO_ACK_NOBIP
LOLO_NOACK_BIP
LOLO_NOACK_NOBIP
Utilizam condition Equal ou NotEqual
ACK_BIP
ACK_NOBIP
NOACK_BIP
NOACK_NOBIP
NOMSG_BIP
NOMSG_NOBIP
Tabelas Historian
Na Aplicação default existe uma tabela já criada que pode ser usada para armazenar medidas históricas. Esta tabela chama-se Table1 e tem os seguintes atributos:
n Table Name: Table1;
n Auto Create: sim;
n Save on Change: sim (gravará um registro sempre que um Tag da tabela for alterado);
n Trigger: nenhum;
n Life Time: 31 dias (apaga os registros mais antigos);
n Time Span: 1 minuto;
n Description: Default historian table, one minute time span.