Nesse breve artigo pretendo descrever um pouco do que é SoE e o porquê isso afeta tanto os projetos de controles voltados para automação em sistemas elétricos.
O mais fácil é explicar o que não é SoE através de um exemplo.
Vamos ao exemplo prático: consideremos dois PLC’s conectados a uma IHM via MODBUS. Essa comunicação MODBUS tem um ciclo de scan de 1 segundo, a cada 1 segundo todas as informações são requisitadas pela IHM dos dois PLC’s, primeiro do PLC1 e logo depois do PLC2. Os dois PLC’s 1 e 2 monitoram um relé que possui dois contatos.
O que acontece quando o contato é fechado?
Quando o contato se fecha, os PLC 's recebem através de uma entrada digital a informação de contato fechado que é materializada no “mundo digital” através de uma variável binária geralmente em estado alto, “1” lógico. Esse tempo de processamento demora geralmente dezenas de microsegundos.
Ainda dentro do PLC o sinal da variável é transmitido para o driver modbus e disponibilizado através de uma tabela para acesso externo. Quando o PLC diz que têm um driver nativo, significa que esse sinal é transmitido imediatamente, ou seja, não há tempo demandado entre a detecção do sinal e a disponibilização no driver. Em outros casos, e até mesmo por conta da boa prática na programação, esse sinal é transmitido através de lógica de controle o que demanda pelo menos um ciclo de trabalho completo do PLC para que o dado fique disponível na tabela MODBUS.
Uma vez que temos o dado materializado na interface MODBUS temos a necessidade de que a IHM “busque” esse dado para apresentar na tela. Para isso, a IHM têm um driver modbus que faz uma leitura dessas informações. Vamos considerar a existência de um único driver MODBUS na IHM, isso quer dizer que primeiro é feita a leitura de um PLC e depois do outro PLC, os dois PLC’s não são lidos simultaneamente.
A IHM lê todo o vetor de informações disponíveis pelo PLC1 e armazena essa informação internamente em algum tipo de banco de dados. A fim de dar uma cronologia todos os dados são estampados com uma data no momento que a informação entra nesse banco de dados da IHM. Instantes depois quando o PLC2 é lido ocorre a mesma coisa, o driver identifica a variação do ponto e estampa a entrada desse dado no banco de dados com uma data e hora levemente a frente da dada do PLC1.
Assim quando vemos na tela o mesmo contato que foi fechado no mesmo instante no pátio estampado na tela pelos dois PLC’s temos datas de ocorrência diferentes e nenhum deles reflete o tempo correto que o contato foi fechado em campo isso porque:
Temos uma latência inerente do processo de aquisição e transmissão da informação, assim o tempo t1 não é o tempo que o evento aconteceu de fato e sim o tempo em que a IHM detectou a primeira vez a informação acrescida do tempo de aquisição do PLC, o Tempo de processamento interno do PLC, o tempo do driver modbus e o tempo de transmissão da informação entre os dispositivos.
Como o driver não consegue saber o tempo em que o PLC recebeu a informação o PLC2 parece ter um atraso maior, mas na verdade isso é uma consequência da leitura da IHM.
O tempo decorrido nem sempre é fixo, pode variar, por exemplo, do congestionamento do dado na rede Ethernet ou dos conflitos de dispositivos presentes em uma rede RS485.
Na maior parte dos processos industriais não existem dois equipamentos aquisitando o mesmo ponto, tão pouco existe a necessidade de que a informação tenha um grau de precisão elevado. 1 segundo de taxa de amostragem é satisfatório para maior parte dos processos mecânicos.
Modbus, OPC, Profibus, EtherCAT, todas essas comunicações são plenamente aceitáveis nesses processos o que facilita muito a programação e a escalabilidade da solução. Nestes protocolos um dado binário é apenas uma entidade binária transmitida entre os dispositivos em que a IHM se encarrega de atribuir um dado temporal ao dado.
Outro aspecto é que a comunicação, o meio deve ser sempre uma via segura e inabalável. Isso quer dizer que se houver uma desconexão todos os pontos são transmitidos imediatamente ao retorno da conexão e estampados com esse momento, não há um buffer, não há uma estrutura que permita analisar esse dado a posteriori.
A necessidade do SoE veio exatamente desse tipo de fragilidade. Então como não ter essa dependência do tempo de comunicação entre os dispositivos para ter essa informação exata disponível na tela?
Um caso que é necessário SoE
Quando temos sistemas elétricos em que a velocidade de uma onda senoidal é 60Hz, ou seja, em 16,67 ms a tensão sai de zero e excursiona entre o máximo positivo e o máximo negativo os processos precisam acontecer nessa ordem de grandeza não seria aceitável que em um sistema dois disjuntores fossem estampados na tela com o mesmo segundo de abertura.
Neste exemplo temos um sistema radial entre um gerador e uma carga com dois disjuntores e uma linha de transmissão entre eles. Digamos que ocorre uma falta nas proximidades da carga e os dois disjuntores abrem e temos um sistema sem SoE para apresentar os alarmes na tela então temos a seguinte profusão de sinais na tela:
Como todos os eventos chegaram no mesmo segundo, não é possível estabelecer uma relação de causa e efeito, todos os eventos chegaram no momento em que foram adquiridos pelo dispositivo que está mostrando os dados.
A essa altura poderia se imaginar que seria possível deixar esses tempos mais rápidos de modo que fosse possível diferenciar estes sinais e permitir uma visualização temporal dos dados.
O SoE é exatamente isso, uma especificação que permite garantir que os sinais tenham uma discretização temporal de no máximo 1 ms.
SoE
SoE quer dizer sequence of events que trata de uma infraestrutura necessária para que um dispositivo consiga identificar e transportar uma informação até os terminais de saída (tela, impressora, histórico) a informação de um ponto digital que mudou de estado em uma discretização tal que os eventos possam ser diferenciados na ordem de 1 ms.
No mesmo exemplo acima se tivéssemos um sistema DCS com SoE teríamos algo como os eventos a seguir:
Veja que é possível identificar que ambos os disjuntores identificaram a falta, o DJ2 abriu, sinalizou uma falha durante a abertura, o que acarretou uma transferência da falta para o DJ1. O DJ1 não foi acionado pela falta em si mas pela falha no primeiro elemento de proteção DJ2.
Alguns aspectos do SoE
Como no SoE um ponto se torna uma sucessão de eventos de variação desse ponto, onde cada variação é identificada e transmitida com uma informação temporal;
Vários dispositivos com SoE podem transmitir informação de uma forma combinada e mesmo com origens distintas é possível organizar as informações cronologicamente no prompt de saída.
Como a informação de um ponto não é apenas um booleano puro é necessário que cada mudança de estado seja transmitida com informações de data, hora, qualidade dessa informação então é necessário um protocolo de comunicação que comporte essa informação de maneira adequada.
Note que do ponto de vista do SoE o ponto deixa de ser um booleano e passa a ser um controle de variações temporais de uma entrada booleana. Quando o SoE está funcionando podemos identificar pelo log de eventos todas as vezes que a variável mudou de status de fato.
Construindo uma solução com SoE
Então vamos agora reconstruir o exemplo inicial para uma configuração que permita que exista SoE entre as aquisições.
O primeiro passo para isso é identificar qual dispositivo será o elemento com SoE: Quem fará o carimbo da informação temporal no sinal proveniente do campo?
Neste caso serão os dois PLC’s, isso quer dizer que os PLC’s precisarão receber um sinal de sincronismo de tempo, afinal, para os dois precisam ter algum marco temporal interno para controlar qual dada a informação de variação do ponto ocorreu.
Nessa condição toda vez que a entrada sofre a variação 0->1 ou 1->0 um driver nativo captura essa informação e a inclui numa pilha de informações interna do PLC independente do processamento. Esse trabalho de empilhamento das informações internamente ao dispositivo é inútil se o dispositivo tiver uma IHM ou uma forma de externalizar por si só as informações. Se o dispositivo não possui essa alternativa é necessário transportar essa informação para o mundo exterior através de um protocolo que não descaracterize essa informação.
O protocolo MODBUS, por exemplo, não tem capacidade de enviar as informações correlatas para uma variação de um ponto digital. Assim sempre tratamos de SoE, tratamos também de protocolos que permitem o transporte de eventos com a estampa de tempo. Esse é o caso do IEC 60870-5-104, IEC 60870-5-101, IEC 61850, DNP3 etc.
Estes protocolos são protocolos desenvolvidos para transporte de eventos com estampa de tempo e por isso são adequados a transportar a informação.
Assim, no nosso exemplo, utilizaremos por exemplo a comunicação IEC 60870-5-104. No protocolo IEC 104 os eventos são enviados conforme são empilhados para o dispositivo mestre. A transmissão de um evento relacionado ao um ponto via IEC 104 é um pacote de informação completo, uma espécie de estrutura em que é enviado além do estado atual do ponto booleano, o momento que ele assumiu esse estado (data e hora), se o ponto está sendo simulado no PLC através de um comando de force, se o ponto está válido na origem (qualidade da informação).
Assim temos uma rede adequada para transmissão de pontos booleanos com SoE as informações são enviadas para IHM com a informação de tempo já gerada não importa quanto tempo demora a transmissão desse dado, ou até mesmo a retransmissão do dado a informação do momento que o ponto foi criado não se perde.
Assim para o nosso exemplo teríamos na tela a informação dos dois PLC’s sendo recebida em tempos diferentes pela IHM mas com a estampa original do momento exato que o evento aconteceu, isso é SoE: ter uma discretização menor que 1 ms entre pontos digitais no mesmo supervisório provenientes de diversas origens e sincronizados entre si.
Numa próxima oportunidade trarei aspectos interessantes que estão subliminarmente ligados ao SoE e as comunicações utilizadas quando o SoE está em funcionamento.
