Um sensor IIoT para solução de gateway de nuvem

Um dos principais casos de uso para a IIoT ( Industrial Internet of Things) é coletar dados do sensor e entregá-los a uma nuvem corporativa para visibilidade aprimorada em tempo real em sistemas operacionais remotos. Isso é muito importante para aplicações como óleo e gás, monitoramento de produção de instalações industriais, monitoramento de pacientes de saúde e monitoramento de subestações de energia. Com os avanços na infraestrutura de rede e a promessa de conexões WAN (Wide Area Network) de maior largura de banda, a capacidade de puxar dados brutos do sensor através da WAN para uma nuvem corporativa de back-end onde soluções de processamento de dados e manutenção preditiva podem ser implementadas e monitoradas. Habilitar esse tipo de arquitetura fornece grande agilidade para as organizações responderem e reagirem às mudanças nas condições de seus sistemas implantados.

Existem alguns problemas que surgem ao tentar atingir esse nível de arquitetura. O principal problema que se apresenta é o grande volume de dados que devem ser enviados do sistema implantado de volta para a empresa. Permitir pacotes de rede individuais de cada sensor não é viável. Além disso, a quantidade de dados de cada sensor é constante, independentemente de ser realmente necessária para avaliação por parte da empresa. Dado o diagrama a seguir abaixo, essa arquitetura não resolve nenhum dos problemas que existem hoje para obter dados dos sensores para a empresa. Gargalos serão vistos na WAN porque o número de pacotes de dados que devem ser tratados é grande e deve ser consistente. Assim que ocorrem picos de tráfego WAN, a capacidade da empresa de coletar dados para processamento torna-se cada vez mais difícil e imprevisível.
Tentar realizar Sensor para Nuvem com soluções tradicionais não é viável

Para habilitar uma solução viável hoje para obter os dados do sensor de volta para a empresa, é necessário que duas peças-chave de tratamento de dados sejam colocadas em prática. Primeiro, o número de pacotes de rede deve ser reduzido . Em segundo lugar, deve haver alguma inteligência no caminho dos dados que permita que o lado da empresa declare quais dados gostaria de acessar para que os dados irrelevantes não sejam enviados. Além disso, esse recurso deve ser mutável, pois as condições de mudança devem permitir que o lado da empresa ajuste o conjunto de dados que gostaria de acessar.

RTI fornece um recurso de ponte chamado Routing Service exatamente para aplicativos como esses. O Routing Service é uma solução de ponte baseada em lógica que permite aos administradores configurar rotas baseadas em tópicos que coletam dados de editores no lado da entrada e enviam dados para qualquer assinante no lado da saída. E como o Routing Service é baseado em DDS, ele permite a configuração individualizada de Quality of Service (QoS) em ambos os lados de uma rota de tópico.

Um QoS que está disponível para configuração no serviço de roteamento é o lote de dados . Esse recurso oferece uma oportunidade de agrupar ou aglutinar pequenos pedaços de dados em pacotes de rede maiores para uma transferência mais eficiente de dados pela WAN. O Batching tem controles de configuração que limitam o tamanho do pacote de dados e que limitam a quantidade de tempo que existe entre os pacotes de saída. Isso dá ao usuário controle completo sobre a largura de banda e os perfis de latência dos dados do sensor. O resultado líquido é uma solução de modelagem de largura de banda configurável que reduz drasticamente o número de pacotes enviados pela WAN por um fator de 10x ou mais.

O segundo recurso que o Serviço de roteamento fornece a habilitação do lado de recepção de uma rota de tópico para expressar um filtro de dados isso limitaria os dados realmente enviados pela ponte. Por exemplo, se os sensores no sistema implantado fossem sensores de temperatura e o lado receptor estivesse interessado em valores de temperatura "> 100 graus F", então a expressão este filtro poderia ser configurado no lado receptor da ponte e o Serviço de Roteamento se propagará esse filtro para o lado de envio original dos dados. Portanto, os dados serão filtrados no lado do gravador original e, portanto, limita quantos pacotes de dados devem ser enviados pela WAN. Esse recurso de filtragem é embutido no DDS e, portanto, o Routing Service permite o uso dele em qualquer rota de tópico no local.

O diagrama a seguir mostra onde o Routing Service seria usado em tal arquitetura.

Com o uso de DDS Filtering e Logical Based Routing que incorpora Batching, Sensor to Cloud é possível.

Esta solução apresenta uma arquitetura de nível muito alto com benefícios exclusivos para resolver o problema de obter dados do sensor de volta para a nuvem sem a necessidade de processar dados brutos no site implantado. Entre em contato conosco por e-mail para solicitar mais informações sobre os recursos do RTI Connext DDS e do Routing Service e como usar esses produtos para atender aos seus requisitos e desafios específicos.

Leitura adicional - Uso do Connext DDS em aplicativos:

• Monitoramento da subestação de energia >> Aplicativos de sistemas de energia: Infraestrutura escalável de alta confiabilidade e alto desempenho
• Petróleo e Gás >> RTI e a Internet industrial para petróleo e gás
• Monitoramento e automação da produção da planta de manufatura >> Automatize fluxos e sistemas de fabricação: Automação de fábrica mais rápida e confiável com o Connext DDS
• Monitoramento de pacientes de saúde >> Aplicativos de sistemas de saúde: Controle, monitoramento e integração de dispositivos e sistemas médicos com o Connext DDS

Saiba mais:

Produção autônoma de veículos »

O que é DDS? »

Connext DDS Pro »

Conectividade em sistemas autônomos »

O que é IIoT? »