A convergência de TI/OT é apenas um termo de zumbido?

Então, “convergência de TI/OT” é apenas mais um termo de zumbido enigmático?

Você poderia argumentar que sim. Sempre que alguém pega uma nova ideia, há uma tentativa de torná-la memorável e fazê-la soar como “a melhor novidade desde o pão fatiado”. Então, é claro, alguém vai inventar uma frase cativante que deve inspirar mudanças e que eles podem usar para marketing.

A questão é, no entanto, essa “convergência” de TI e OT é realmente apenas a próxima extensão de tornar os dados utilizáveis.

O que é convergência de TI/OT?

Algum tempo atrás, vimos o início da automação na fabricação. O equipamento automatizado foi projetado para executar uma função específica que precisava ser executada em uma velocidade ou nível de potência que os humanos não poderiam alcançar. Mas quando o equipamento automatizado falhava, o engenheiro de controles precisaria entrar no sistema para determinar o que deu errado. Isso exigia entrar nos registros dos sistemas PLC para procurar pistas da falha. Este foi o início do uso de dados de tecnologia operacional (OT) .

Ter alguns dados que levam ao ponto de falha era bom para o diagnóstico — para ver o que acontecia antes. Como resultado, os sistemas PLC começaram a usar historiadores para manter fluxos mais longos de dados de sensores, aquecedores e atuadores de automação – usando grandes quantidades de dados OT.

Ao monitorar os dados de OT de historiadores, as funções SCADA podem fornecer aos operadores algumas informações sobre como o equipamento estava operando. Quando uma falha era iminente, as funções SCADA permitiriam aos operadores (ou supervisores) uma chance de agir antes que a falha ocorresse. Isso exigia que o sistema SCADA tivesse acesso aos dados dos historiadores e usasse comunicações proprietárias como MODBUS ou PROFIBUS para disponibilizar esses dados aos operadores por meio de interfaces homem-máquina (IHMs). Mas o monitoramento era exclusivo do desempenho do equipamento, ampliando ainda mais o uso de dados OT.

Através da observação desses fluxos de dados (medidores, telas do operador e assim por diante) e entendendo mais sobre a deriva dos dados, pode-se reconhecer - através dos sistemas SCADA - não apenas quando a falha do equipamento é iminente, mas também que os dados podem ser usado para analisar falhas na qualidade do produto no teste e na inspeção – operações que podem ter sido várias etapas posteriores no processo.

Isso criou a necessidade de ter dados de OT vinculados a dados de TI. Isso resultou na criação de interfaces complexas de PLCs e SCADA para sistemas de tecnologia da informação (TI) como MES, permitindo que dados relacionais de falha do produto fossem vinculados aos dados operacionais dos equipamentos que fabricam o produto. Alguns tentaram direto para o ERP também (e ainda estão tentando), mas os sistemas ERP não estão equipados para processar e apresentar esses dados com rapidez e detalhes suficientes em relação a outros eventos durante o processo de fabricação.

O problema com as interfaces para MES é que elas são altamente personalizadas e caras, às vezes adicionando até 40-50% do custo de implementação de um projeto. O próximo passo na melhoria do acesso aos dados seria tornar os dados do PLC mais acessíveis ao MES e outros bancos de dados relacionais. Quando essa necessidade de acesso é combinada com o custo de computação e memória do computador se tornando mais barato e a comunicação de rede se tornando mais estável (entre em redes 5G), fazia sentido conectar os sensores e atuadores do PLC diretamente às redes de TI (o que chamamos de IIoT) e disponibilizar seus dados para... quem precisa deles.

Todo esse histórico serve para destacar que tornar os dados de TO mais prontamente disponíveis para os sistemas de TI é simplesmente o próximo passo em um processo mais longo da evolução tecnológica que nos trouxe para a Indústria 4.0.

Como a convergência de TI/OT pode ser usada?

A interface de dados de TO com sistemas de TI agora encontrou um novo problema.

Os sistemas PLC/SCADA que monitoram sensores em historiadores podem criar grandes fluxos de dados (até megabytes de tamanho) em segundos. Da perspectiva de entender a caracterização de um evento de volta aos sistemas de TI, no entanto, esse fluxo de dados - mesmo em pequenos prazos - é simplesmente demais para os bancos de dados relacionais de sistemas de TI como MES. Muitas implementações tentaram registrar uma instância de dados do sensor (retirados de um fluxo de dados) para capturar um único elemento de dados, para tentar alguma representação de eventos de OT no nível de TI. Muitos descobriram, no entanto, que vincular uma instância de dados OT a um evento de qualidade de um produto durante a fabricação não é muito eficaz para monitorar a qualidade de um processo em geral.

Agora precisamos determinar maneiras de agregar fluxos de dados de sistemas OT de uma maneira que mantém as características importantes de um evento de produção. O relato de OEE é uma dessas tentativas de agregação. É importante reconhecer que, ao usar qualquer forma de agregação de dados, haverá alguma perda dos detalhes importantes de um evento de qualidade. É por isso que o OEE é usado como um objeto de dados no nível de monitoramento e não como um objeto no nível de análise. No entanto, ao monitorar o valor em tempo real da alteração do OEE, um sistema de TI pode reconhecer a taxa e a magnitude das alterações e criar um alarme para alertar sobre um problema.

Para analisar esse problema real, você precisará voltar ao fluxo de dados original que foi usado para criar o valor OEE. Pelo menos com o valor do OEE sendo fornecido em tempo real, os engenheiros de manufatura e controles obtêm visibilidade de um problema com antecedência suficiente para que possam voltar ao historiador para análise antes que o evento seja enterrado por mais dados do fluxo de dados OT.

A questão é:como você agrega os dados?

A resposta, como sempre, é... depende!

Como agregar os dados dependerá de quais dados você está agregando e o que você está tentando monitorar no processo. Também dependerá da capacidade de interpretar as mudanças no modelo de agregação de dados.

Nesta seção, examinarei um desses métodos de agregação e apresentarei algumas das maneiras de interpretar as alterações nesse conjunto de dados.

A “curva de distribuição natural” ou histograma é uma das representações gráficas mais comuns de dados de dispositivos como sensores. A premissa primária da curva é que, se há apenas variação aleatória normal em um processo, a distribuição das instâncias de dados cairá em um padrão semelhante a uma curva de distribuição natural.

A Figura 1 mostra como pode ser a distribuição das leituras de um sensor de forno com variação normal quando plotada em um histograma.

Figura 1:Curva de distribuição da temperatura do forno mostrando média, mediana e moda. Cortesia do autor.



As principais características da curva são que a média (média), mediana (valor médio do fluxo de dados) e a moda (valor com mais ocorrências) são todas aproximadamente iguais . Isso pode ser usado como referência para determinar se o processo está com problemas. Desde que haja uma indicação de que o processo está sob controle, há valor em determinar os valores +/-3 sigma e compará-los com os limites de controle superior e inferior e os limites de especificação do produto.

Um exemplo de cenário

Para monitorar o processo de uma unidade de produção passando por um forno de cura, o sistema MES anotava a hora em que a unidade entrava e saía do forno. Durante esse tempo, o sistema PLC (usando um sensor inteligente) criaria um fluxo constante de dados do sensor de temperatura que seriam armazenados em um banco de dados de historiador local no dispositivo sensor. Quando a unidade de produção saísse do forno, o MES faria uma solicitação ao dispositivo para uma agregação dos dados de temperatura durante esse período de tempo definido. Mesmo com o poder de computação limitado disponível no nível do dispositivo, o dispositivo pode receber centenas (ou mesmo milhares) de pontos de dados e fornecer um conjunto de dados agregados de volta ao MES - em vez de fornecer uma única instância dos dados do sensor, como é típico , ou tentando processar todo o fluxo de dados.

O seguinte seria um conjunto de valores de dados agregados para esta unidade de produção:

• Média:90,0
• Mediana:seria muito próximo de 90,0
• Modo:aproximadamente 90,0 graus também
• +/- distribuição 3 Sigma:87,0, 93,0 (a ser verificado com UCL e LCL)

Ao fazer uma análise rápida das diferenças entre a média, a mediana e a moda, o MES pode procurar monitoramento de controle de processo aceitável, bem como mudanças de tendências de unidades de produção anteriores que já passaram pelo forno. Se os valores de +/- 3 sigma estiverem além dos limites aceitáveis, o MES sinalizará automaticamente a unidade de produção como suspeita, da mesma forma se a média, a mediana ou o modo diferirem significativamente um do outro ou dos produtos anteriores.

A Figura 2 apresenta um exemplo de como esses mesmos valores indicariam um processo que não estava sob controle. Neste caso, no entanto, ainda é possível que os valores de +/- 3 sigma estejam dentro dos limites.

Figura 2:Exemplo de diferenças de média, mediana e moda em um processo enviesado. Cortesia do autor.



Agora, tecnicamente, se a distribuição for distorcida como mostrado, os valores de +/- 3 sigma podem não ser considerados válidos como resultado da natureza distorcida do conjunto de dados. Mas a análise imediata pelo dispositivo ainda pode ser usada para determinar se os limites de controle foram violados.

O ponto-chave:se este é o tipo de conjunto de dados fornecido por um sensor inteligente, é uma indicação para a engenharia de fabricação de que o forno não operando apenas com variância aleatória - e, portanto, deve ser investigado.

Outras diferenças na média, mediana e moda (por exemplo, a média e a mediana são iguais, mas a moda é diferente) também podem indicar condições como uma distribuição bimodal que sugere múltiplas influências do processo em jogo. Mais uma vez, a engenharia de fabricação deve analisar o processo.

Quando os conjuntos de dados acima são vinculados diretamente à unidade de produção no nível MES, esses dados podem ser usados ​​- com resultados de teste e inspeção - para indicar se há uma ligação entre a variação na temperatura do forno e a falha da unidade de produção.

Se o produto falhou como resultado dos problemas do processo ou não, ver os valores dos dados se desviarem durante uma execução de produção também pode indicar problemas fundamentais de gerenciamento de processos que precisam ser investigados.

Resumo

Os exemplos anteriores de agregação de dados refletem apenas um cenário específico, mas visam fornecer uma visão dos motivos para a convergência de dados de TO e TI bem como o valor potencial desta convergência . Em cada cenário de produção, o método correto de agregação de dados precisaria ser avaliado e a programação de dispositivos inteligentes precisaria disponibilizar essa funcionalidade. Ou, como alternativa, os sistemas de computação de borda seriam programados para substituir a funcionalidade descrita para os dispositivos inteligentes.

A conclusão é que, embora o setor use muito a “convergência de TI/OT” como um termo popular para descrever a mudança de tecnologia, há uma mudança legítima no processamento de dados que a tecnologia por trás do termo buzz oferece. As empresas que aproveitam a tecnologia de convergência e aprendem a agregar e interpretar adequadamente os dados apresentados por meio da convergência podem obter vantagens práticas na eficácia dos programas de qualidade e gerenciamento de instalações. No ambiente global competitivo de hoje, usar qualquer vantagem é bom para o resultado final.

Então, a resposta é não. A convergência de TI/OT não é apenas um termo de buzz. É uma ferramenta valiosa na evolução da tecnologia de aquisição e gerenciamento de dados que pode beneficiar muito as empresas de manufatura. Aprender como agregar os dados do nível de TO para que os sistemas no nível de TI possam lidar com eles é uma parte importante da convergência.