Soluções IIoT | 6 Soluções de comunicação industrial IoT

Para dizer que a tarefa de selecionar sua IoT industrial ( IIoT ) infra-estrutura de comunicação é um empreendimento muito complexo seria um eufemismo. A avaliação da miríade de soluções disponíveis comercialmente é demorada e cara. Experimente baixar e avaliar várias soluções de cada tipo de infraestrutura e você se verá rapidamente no meio de um projeto que levará vários engenheiros a completar seis meses. Todos nós já passamos por isso e quero ajudá-lo a economizar um tempo valioso!

O objetivo desta postagem é apresentar a você as populares soluções de infraestrutura IIoT que estão disponíveis comercialmente - AMQP, CoAP, DDS, RTI Connext DDS, MQTT e ZeroMQ - e destacar os recursos de cada solução. As seis seguintes áreas de avaliação serão aplicadas:Arquitetura, Padrões de Comunicação, Transportes, Tipo e Filtragem de Dados, Qualidade de Serviço e Segurança.

Clique aqui para baixar a versão em PDF para impressão.

1. Arquitetura

Dependendo do padrão arquitetônico de uma determinada infraestrutura de comunicação, a conexão lógica (ilustrada na Figura 1, abaixo) que os aplicativos usarão para se comunicar com outros aplicativos na infraestrutura varia. As duas arquiteturas mais básicas usadas nas soluções de middleware de hoje são (1) arquiteturas ponto a ponto e (2) arquiteturas estrela baseadas em broker.

1. Arquiteturas ponto a ponto permitir que os aplicativos se comuniquem diretamente uns com os outros sem ter que enviar dados a um elemento intermediário. Essas arquiteturas são inerentemente mais eficientes na entrega de dados, uma vez que apenas os aplicativos de envio e recebimento estão gastando recursos da CPU para concluir a transferência. Portanto, apenas os aplicativos que possuem os dados e os aplicativos que precisam dos dados consumirão ciclos de CPU; assim, resulta em uma distribuição eficiente de processamento com base nos requisitos do aplicativo. O outro benefício para uma arquitetura ponto a ponto é que a entrega determinística de dados é muito mais alcançável porque não há um "intermediário" manipulando os dados entre os aplicativos de produtor e consumidor.

Figura 1. Diagramas de arquitetura para os vários protocolos IoT.

2. Soluções baseadas em corretor exige que todos os aplicativos que estão enviando dados transfiram os dados diretamente para o servidor do broker, após o que ele fará a recuperação e reenviará esses dados aos aplicativos de recebimento. O benefício dessa arquitetura é que o corretor gerencia toda a complexidade relacionada ao envio / recebimento de dados. Normalmente, essas soluções têm ferramentas integradas para ver exatamente quais caminhos de dados estão ativos, quem está enviando dados e quem está recebendo dados. Soluções baseadas em corretor introduzem latência para entrega de dados e também apresentam um único ponto de falha de tal forma que se o corretor falhar, todas as comunicações também falharão. Para resolver o problema de ponto único de falha, a maioria dessas implementações fornece servidores de corretor redundantes e altamente disponíveis.

2. Padrões de comunicação

O suporte ao padrão de comunicação é essencial para uma infraestrutura que você pode usar durante todo o ciclo de vida de seu projeto ou linha de produtos. O projeto inicial pode exigir apenas publicação / assinatura, mas projetos ou produtos subsequentes podem precisar de padrões adicionais, como solicitação / resposta ou enfileiramento. Nesse aspecto, nem todas as soluções de IoT existentes disponíveis hoje podem oferecer suporte a todos os padrões necessários de que seu projeto precisará. Para a tabela de comparação, identificamos os padrões mais comuns usados ​​hoje e se cada solução de infraestrutura fornece esse padrão. Estes são os padrões mais comuns em uso hoje:

• Publicar / Assinar :Um aplicativo (assinante) solicita dados 1 vez e, em seguida, todas as atualizações subsequentes dos dados são “enviadas por push” para o assinante. Não há necessidade de solicitar atualizações de dados continuamente.
• Solicitar / Responder / RPC ( Chamada de procedimento remoto ):Um aplicativo solicitante envia solicitações e um aplicativo respondente responde à solicitação.
• Fila ( ou Ponto a Ponto ):Os dados são enviados a um servidor que manterá as informações em uma fila. Os dados podem ser retirados da fila ou enviados aos consumidores. Ao contrário de Publicar / Assinar, cada parte dos dados é distribuída para apenas um aplicativo receptor.
• Um para muitos :Capacidade de fazer com que muitos aplicativos de recebimento obtenham os mesmos dados de uma única fonte.
• Muitos para um :Capacidade de receber dados de muitas fontes em um único aplicativo de consumo.

3. Transportes e rotas / ponte

A maioria das soluções de middleware de comunicação suporta TCP como seu protocolo de comunicação principal. O uso do TCP fornece uma entrega confiável de dados usando o mecanismo de confiabilidade embutido inerente ao TCP. Isso pode ser ideal para fluxos de dados específicos que exigem confiabilidade, mas é exagero e adiciona sobrecarga desnecessária a dados de sensor simples que não exigem entrega confiável. Algumas das soluções IoT como ZeroMQ e DDS também oferecem suporte a outros transportes, como memória compartilhada. Um transporte digno de nota é o uso do transporte UDP para DDS. Como a implementação da confiabilidade é integrada ao DDS, ela não requer um transporte confiável por baixo. Isso permite que os aplicativos selecionem quais fluxos de dados têm entrega confiável e quais fluxos representam o melhor esforço.

O roteamento de dados entre transportes e através da WAN é algo que todas essas soluções fornecem de uma forma ou de outra. No mundo de hoje, onde os sistemas corporativos, aproveitando as tecnologias ESB e Web, também devem acessar alguns dos dados em tempo real, é essencial que o middleware de comunicação também suporte a conexão com essas tecnologias. Por causa disso, você verá o roteamento e a ponte como um componente central para o middleware de sistema distribuído.

4. Tipo e filtragem de dados

O modo como os dados são encapsulados e representados na conexão também é exclusivo para a infraestrutura fornecida. Algumas soluções enviam apenas bytes de dados brutos e cabe ao aplicativo serializar e desserializar os dados. Outros enviam apenas dados de texto / string para que as informações possam ser representadas no formato XML ou JSON. Este cenário é muito comum nas tecnologias da web hoje, mas pode ser muito ineficiente porque a cada envio de dados o pacote também contém a descrição dos dados, às vezes tornando o tamanho do pacote mais de 3x seu tamanho original. Tamanhos de pacote maiores aumentam o uso da largura de banda, bem como aumentam o uso da CPU nos lados de envio e recebimento da transferência. Coloque um corretor no meio disso e agora você também dobrará o número de pacotes na transferência.

Outras soluções, como DDS, permitem o uso de dados fortemente tipados que são serializados e desserializados exclusivamente pelo middleware. O esquema é enviado separadamente, o que não acontece com XML ou JSON e, portanto, você não paga multa por mensagem (ou amostra). Isso também se torna muito importante para filtrar aspectos também. Digamos que você esteja configurando um único editor com muitos assinantes. Alguns dos assinantes podem querer todos os dados, mas alguns dos assinantes querem apenas uma parte dos dados. Sem ter uma solução de dados fortemente tipada, seus aplicativos terão que gerenciar toda essa funcionalidade de filtragem, que é ainda mais código que você precisa escrever. Com soluções como DDS, onde as informações de tipo são fortemente definidas, o middleware pode gerenciar toda a filtragem para você. Menos código =desenvolvedores mais felizes :). Na verdade, o RTI Connext DDS tem funcionalidade adicional para fornecer essa filtragem no lado do gravador da transferência de dados, resultando em menos uso de largura de banda na conexão e menos processamento de CPU em aplicativos que não precisam dos dados sendo filtrados.

5. Qualidade de serviço

Nem todos os dados são criados iguais. O que isto significa? Bem, alguns dados em um aplicativo distribuído em tempo real estão transmitindo dados do sensor. Na maioria das vezes, esse tipo de dados não precisa ser garantido como dados entregues. Para um determinado sensor, você pode apenas se preocupar se um determinado prazo para entrega de dados foi cumprido ou, o que é mais importante, não foi cumprido. Outros dados podem ser dados de Alarme / Evento. Esses dados não possuem uma periodicidade para sua frequênc

[1] [2] 下一页