Neste artigo, apresentaremos diversas configurações gerais que entendemos como sendo boas práticas de configuração do EPM. Isso não significa que estas recomendações devam ser aplicadas em absolutamente todos os casos, mas uma maior atenção a estes detalhes durante a configuração, de acordo com o projeto, trará melhores resultados no uso do EPM.
Recomendamos aos usuários que revisem essa lista a cada nova configuração do sistema EPM.
Propriedade Cast Type das Basic Variables
Essa opção define como o tipo de valor coletado será convertido para armazenamento no EPM. Ela interfere diretamente no espaço de armazenamento, e também na posterior interpretação durante uma consulta aos dados.
Por exemplo, é importante avaliar se os valores numéricos requerem uma precisão do tipo float ou do tipo double. Quando utilizamos a opção Cast Type para converter os dados de double para float, isto implica na redução pela metade dos recursos necessários para o armazenamento no EPM Server.
Isto também se aplica a valores inteiros: a dupla Int e UInt também otimiza o espaço consideravelmente, semelhante ao que acontece com float/double, por exemplo.
Recomendação: para cada Basic Variable, avalie qual tipo de valor com leitura na fonte é o mais indicado, conforme sua natureza no processo.
Propriedade Domain das Basic Variables
A opção Domain corresponde ao domínio ao qual pertence a variável, que pode ser contínua ou discreta. Essa propriedade é fundamental para a apresentação dos dados em gráficos de tendência. Também é crucial para o modo como ele são processados quando o algoritmo de compressão é aplicado, ou mesmo em algumas consultas históricas com processamentos (agregações definidas no padrão OPC UA).
Recomendação: para cada Basic Variable, avalie qual é a natureza daquele tag, e ajuste-o de acordo com cada caso.
Propriedade Enable Real Time das Basic Variables
Essa opção define se a via de comunicação em tempo real está ou não habilitada. Esta via deve estar ativada para que se possa utilizar a variável nos cálculos ou no monitoramento de eventos de uma Expression Variable, por exemplo.
Ela também tem um impacto significativo no desempenho do sistema, já que os dados de tempo real são enviados diretamente para o respectivo tag.
Recomendação: para cada Basic Variable, avalie se ela precisa receber os dados em tempo real. Em sistemas com muitas variáveis isso pode impactar no desempenho, portanto estude cada caso individualmente.
Note que independentemente dessa opção, a coleta e armazenamento de dados permanecem acontecendo de acordo com as configurações do usuário. Assim, pode-se utilizar o tempo real apenas em os casos necessários, sem interferir nos dados já coletados para armazenamento no histórico.
Propriedade Store with milliseconds precision das Basic Variables
Esta opção define se é necessário ou não armazenar os dados com precisão de milissegundos.
Note que essa opção utiliza uma quantidade bem significativa de espaço de armazenamento dos dados. Assim, ao mantê-la habilitada, isso pode resultar em uma diferença considerável de uso do disco ao longo do tempo.
Recomendação: caso sua fonte dos dados não apresente precisão de milissegundos, ou seja, quando sua timestamp grava somente até segundos, então não faz sentido manter essa configuração habilitada no EPM. Portanto, desmarque esta opção em todas Basic Variables nessa situação.
Opção Disable Demo Mode no EPM Server Manager
Esta opção desabilita o modo Demo do EPM. Deste modo, caso o EPM Server seja reiniciado e a chave do produto não seja localizada, por exemplo, a opção evita que ele entre em modo Demo, o que provocaria o descarte de dados dos buffers dos Interface Servers.
Nesse caso, o EPM Server fica offline até a correção do problema com a chave, o que garante a permanência dos dados em buffer.
Recomendação: para sistemas EPM que são colocados em produção, é recomendável habilitar esta opção para impedir a entrada do modo Demo. Já quando o EPM é utilizado para testes, avaliações, etc., então pode ser interessante manter o modo Demo disponível, com esta opção desmarcada.
Opção Interface Server Activity Timeout no EPM Server Manager
Esta opção indica ao EPM Server quanto tempo aguardar antes de considerar uma sessão aberta com um Interface Server como inativa e que, portanto, deve ser encerrada por ele. Quando a coleta dos dados acontece em locais onde a rede entre o Interface Server e o EPM Server é de alta latência, sugerimos ajustar essa opção conforme o caso.
Recomendação: caso observe uma queda frequente da comunicação do Interface Server, ou então seguidas reconexões, indicamos aumentar o tempo de timeout dessa opção. Isso dá ao EPM Server mais tempo de espera pela resposta dos Interface Servers. Note que essa opção aplica-se a todos os Interface Servers.
Arquitetura na instalação do EPM
Embora não haja nenhuma restrição técnica na instalação do Sistema EPM em uma única máquina, quando falamos de projetos de maior escala, como uma indústria, por exemplo, pode ser interessante a separação de alguns módulos, tanto para facilitar a manutenção quanto para melhorar o desempenho geral.
Recomendação: é desejável que o EPM Server esteja em uma máquina própria, que pode ou não ser a mesma máquina do Microsoft SQL Server. O EPM Processor também requer sua própria máquina. Já que este módulo exige capacidade de processamento, indicamos que ele tenha um computador dedicado.
Evite instalar módulos como o EPM Server ou o EPM Processor junto a outros sistemas importantes/críticos, como um sistema SCADA, por exemplo. Por outro lado, a instalação do EPM Interface Server deve estar o mais próximo possível da fonte dos dados em que ele irá coletar.
Tanto o EPM Portal quanto o EPM Processor precisam do EPM Web Server para seu funcionamento. Caso estes módulos estejam em máquinas separadas, então devemos instalar um EPM Web Server para cada um. Mas se o EPM Portal e o EPM Processor estiverem na mesma máquina, não há problemas que eles compartilhem o mesmo Web Server.
Configuração dos usuários
A correta configuração dos usuários no EPM é importante não apenas para definir o nível de acesso que cada usuário terá, mas também para permitir identificar facilmente cada login na lista de sessões do EPM Server. Assim, em caso de manutenção do sistema, é possível diferenciar os acessos através das sessões abertas por cada login existente.
Recomendação: crie um login para cada usuário do EPM, a fim de definir o respectivo perfil de acesso de cada um. Ou seja, logins específicos para cada módulo do EPM, como Interface Servers, EPM Web Server, EPM Processor, etc.
Para os administradores do Sistema EPM, recomendamos que utilize o login SA apenas para manutenções/operações que requeiram tal login. Para o uso cotidiano, acesse o EPM com seu login particular.
Lembre-se de armazenar a senha do usuário SA com segurança. Uma vez perdida essa senha, diversas operações ficarão indisponíveis.
Publishing Interval do Interface E3
A opção Publishing Interval, na interface de comunicação E3, define o intervalo de envio dos valores coletados pela interface em tempo real para o EPM Server. Isto repercute diretamente sobre os valores monitorados em tempo real através de gráficos de tendência ou nas Expression Variables. Estas, por sua vez, também utilizam os valores provenientes desta via nos seus cálculos. O histórico, no entanto, continuará recebendo toda e qualquer mudança ocorrida.
Essa opção permite reduzir uma eventual perda de desempenho em projetos que tenham uma grande quantidade de tags com atualização em tempo real habilitada, ou em casos com muitas variações ocorrendo a cada segundo.
A função deste parâmetro é atender não apenas cenários onde a Interface E3 possui grande quantidade de tags, mas também os com elevado volume de dados trafegando pela via de tempo real.
Recomendação: avalie em cada caso qual é a taxa mínima aceitável para atualização dos dados em tempo real para os tags dessa Interface. Note que essa opção atua na via de tempo real; o histórico continuará recebendo toda e qualquer mudança ocorrida.
Algumas vezes, um grupo específico de tags necessita de uma taxa de atualização diferente da dos demais. Nesses casos, basta criar outra Interface E3 no mesmo Interface Server e configurá-la com o Publishing Interval desejado. Este grupo específico de tags deverá ser inserido na nova Interface E3.
Muitas variáveis de servidores OPC coletadas
A coleta de dados de servidores OPC é realizada através de assinaturas. Estas, por sua, vez possuem um limite de processamento. Ou seja, quando a assinatura possui uma grande quantidade de tags para leitura, a comunicação dela pode ficar mais lenta.
Embora não haja um número específico que determine a deterioração ou não da comunicação na Interface OPC, o usuário pode estabelecer qualquer número que considere excessivo para a coleta de um único Interface (por exemplo, acima de 10 mil tags). De qualquer forma, pode-se tomar a ação sugerida abaixo sempre que observada uma lentidão na atualização dos tags.
Recomendação: quando há muitas Basic Variables para coletar, uma alternativa é criar múltiplas Interfaces de Comunicação para o mesmo servidor OPC e, assim, distribuir a quantidade de tags nesses Interfaces. Com isso, dilui-se o número de cargas em mais assinaturas.
Consultas pesadas/longas em Interfaces Database
Existem casos em que é necessário coletar dados de outro banco de dados através do Interface Database. Note que as consultas utilizadas para realizar essa coleta não devem retornar uma quantidade muito grande de dados em uma única vez, ou então possuir muitos tags/endereços, pois assim a consulta acaba se tornando muito lenta.
Recomendação: o ideal nesses casos é dividir as consultas em vários Interfaces Database. Assim, cada consulta retornará menos tags.
Outra sugestão é “quebrar” a quantidade de dados que serão retornados a cada vez. Ou seja, o usuário pode adicionar uma cláusula na consulta que limita o número de registros retornados em cada execução. Assim, os registros serão retornados aos poucos, e não todos de uma única vez.
Com isso, o sistema será capaz de processar mais rapidamente todas as informações. Também recomendamos utilizar consultas mais curtas.
Redundância de Interfaces
Geralmente, o uso de redundância de Interfaces no EPM está relacionado com a coleta de dados de um Elipse E3 ou Elipse Power. Estes, por sua vez, também podem estar em redundância. De qualquer forma, é importante diferenciar os níveis de redundância. Isso quer dizer que é possível que exista redundância a nível de SCADA (Elipse E3 ou Elipse Power, por exemplo) e também, mas não obrigatoriamente, que exista redundância a nível de coleta de dados, que é o EPM Interface. O conceito é o mesmo para outros tipos de fontes de dados e não apenas SCADA.
Do ponto de vista da redundância no nível da coleta de dados, a lógica de funcionamento é que o usuário poderá definir dois Interface Servers aptos a executar um determinado Interface. Dessa forma, caso ocorra alguma falha nesse nível, o EPM Server irá recriar o Interface e iniciar a execução dele a partir do outro Interface Server da redundância.
No exemplo acima, temos redundância somente no nível de coleta dos dados, por isso existem duas máquinas distintas para os Interface Servers. Estes, por sua vez, estão separados do nível da fonte dos dados, já que neste exemplo, a fonte não possui redundância.
De qualquer forma, aqui é importante destacar que qualquer Interface de Comunicação do EPM poderá ter redundância, não apenas quando a coleta ocorrer com o Elipse E3 ou Power. Porém, a arquitetura de máquinas/hosts pode variar.
Note também que além da configuração de redundância do Interface, quando tratamos especificamente do Interface E3 (tipo responsável por coletar dados do E3 ou Power), existe nele também a possibilidade de configuração para lidar com a redundância do próprio sistema E3 ou Power.
Recomendação: agora que conhecemos um pouco mais sobre as arquiteturas e conceitos, vamos discutir dois cenários diferentes: (a) redundância de Interface, genericamente falando e (b) redundância de Interface específica do tipo E3, trabalhando em conjunto com a redundância do Elipse E3 ou Elipse Power.
(a) Redundância de Interface genérica:
Utilizaremos um Interface OPC DA como exemplo.
Nesse caso, temos duas máquinas com um OPC DA Server que funciona em redundância (nível da fonte dos dados). Em cada uma das máquinas, teremos um Interface Server instalado, e iremos criar dentro de um deles um Interface OPC DA (nível de coleta dos dados).
Na configuração de redundância do Interface, basta informar quais Interface Servers estarão aptos para rodar a redundância. Dessa forma, o Interface OPC DA poderá transitar em ambos, sempre coletando do OPC DA Server que estará ativo, ou seja, nesse caso a coleta sempre será localhost.
(b) Redundância de Interface E3 trabalhando em conjunto com redundância E3/Power:
Nesse exemplo (ver imagem abaixo) temos duas máquinas com um E3 em redundância (nível da fonte dos dados). Em cada uma das máquinas, temos um Interface Server instalado, e vamos criar dentro de um deles um Interface E3 para configurar a redundância em seguida (nível de coleta dos dados).
Como a redundância do E3/Power pode transitar entre as duas máquinas (Hot/Standby), ajuste a configuração do Interface E3 para suportar essa redundância do SCADA.
Após isso, vamos configurar a redundância a nível da coleta, ou seja, a redundância do próprio Interface E3. Para isso, basta informar quais Interface Servers estarão aptos para rodar a Interface de Comunicação.
Com isso, os componentes estão prontos para coletar os dados independentemente de qual máquina esteja rodando a redundância ativa, tanto a nível da fonte dos dados, quanto a nível da coleta.
Para concluir, na imagem acima da arquitetura deste exemplo, a linha contínua laranja seria a comunicação ativa, enquanto as linhas pontilhadas mostram um eventual caminho da comunicação, caso ocorra um chaveamento da redundância de um Interface ou então de um E3 Server.
Observações:
Para a configurar o Failover Trigger do Interface, pode-se optar por criar uma Basic Variable que leia uma informação de horário atual da fonte de dados, ou seja, que tenha variação contínua; e com isso, usar a Basic Variable como watchdog tag. De qualquer forma, as demais opções também são válidas de acordo com o caso e objetivo do usuário.
Também é desejável que os links/rotas de rede entre os módulos do EPM sejam redundantes, a fim de estabelecer maior garantia na continuidade do funcionamento, caso contrário, teremos novamente um ponto único de falha.
