Estruturas e transportes:escolhendo a melhor solução de conectividade IIoT

Construir uma infraestrutura de sistema distribuído no cenário atual da Internet das Coisas Industrial (IIoT) pode ser uma tarefa difícil, para dizer o mínimo. Se você é um desenvolvedor ou arquiteto de sistema, sabe que existem muitas ferramentas e protocolos disponíveis para usar para mover dados em seu aplicativo distribuído. Sem falar na possibilidade de construir sua própria solução customizada diretamente nos soquetes TCP ou UDP. Não seria ótimo se muito do trabalho que precisava ser feito antes que você pudesse tomar uma decisão sobre sua próxima infraestrutura já estivesse feito para você?

Você sabe o que? O trabalho foi feito e agora está disponível para ajudá-lo a tomar essa decisão. Você deve estar se perguntando:"Quem fez toda essa pesquisa? É tendenciosa por alguma empresa que procura vender sua própria solução?" A boa notícia é que a pesquisa foi concluída por um consórcio independente, o Industrial Internet Consortium (IIC). Ele foi conduzido de forma imparcial e neutra em relação ao fornecedor, e as informações resultantes estão agora disponíveis para você.

Isenção de responsabilidade total:Sim, eu trabalho para uma empresa que fornece infraestrutura para Internet Industrial, mas de forma alguma estou dizendo que nossa solução é a melhor. A verdadeira resposta à pergunta:"Qual é a melhor solução?" é, "Depende."

A resposta depende do que você precisa de uma solução de infraestrutura:

• Você só precisa enviar bytes de dados do ponto A ao ponto B?
• Você precisa que os dados sejam entregues de maneira confiável?
• Você precisa de alguma consciência centrada em dados para que a infraestrutura possa fornecer algumas decisões de entrega eficientes para uma solução mais inteligente?
• Quanto da manipulação de dados você deseja transferir para a infraestrutura?

As respostas a essas perguntas críticas, e muitas mais, são o que investigo neste artigo. Ao final desta postagem, esperamos que você tenha as informações de que precisa para tomar uma decisão informada sobre qual é a melhor solução para seu aplicativo exclusivo.

Sobre o Industrial Internet Consortium (IIC)

A CII foi formada em 2014 por alguns atores muito importantes no cenário da Internet industrial. As empresas fundadoras (Cisco, Intel, AT&T, IBM e GE) se propuseram a criar uma organização focada exclusivamente nas necessidades de aplicativos industriais de Internet. Agora o consórcio é formado por mais de 250 empresas, grandes e pequenas. Os resultados deste consórcio incluem um conjunto de documentos que delineiam as necessidades e soluções potenciais para este tipo de aplicações de Internet Industrial. O documento IIC Industrial Internet Connectivity Framework (IICF), um documento de orientação, é perfeito para ajudá-lo a determinar a melhor solução para exemplos baseados no mercado. Além de vários documentos, eles também estabeleceram bases de teste que serão usadas para provar a capacidade de várias tecnologias de atender a vários exemplos de mercado do mundo real. Informações sobre os documentos disponíveis e bases de teste baseadas no mercado podem ser encontradas no site da CII.

Fornecendo dados:transportes e estruturas

Existem muitas soluções disponíveis hoje para obter dados entre aplicativos. No documento IICF, essas soluções são divididas em duas categorias:transportes e estruturas. Vamos dar uma olhada nesses dois tipos de soluções de transferência de dados para ver onde eles se encaixam na pilha geral de camadas de conectividade. A Figura 1 abaixo mostra essa pilha de conectividade.


Figura 1. Pilha de estrutura de conectividade IIC
Quase todo mundo que lê este documento viu uma pilha de conectividade como esta, mas a pilha da CII tem uma distinção clara:as camadas de transporte e estrutura.

Normalmente, tendemos a agrupar todas as soluções que você vê nas categorias de transporte e estrutura, mas há uma diferença muito grande entre um transporte e uma estrutura. Um transporte é usado para entregar dados do ponto A ao ponto B, enquanto uma estrutura basicamente aproveita a capacidade de um transporte enquanto fornece um sistema de tipo de dados para interoperabilidade. Simplificando, ao usar apenas um transporte, o aplicativo deve formular os dados em um buffer genérico para entrega ao transporte. No entanto, com uma estrutura, o aplicativo precisa apenas entregar os dados para a estrutura, e a estrutura se encarregará de construir um buffer para o transporte subjacente prosseguir e enviar seus dados. Trabalhar no nível de dados de um aplicativo traz muitos benefícios para aplicativos que fornecem recursos como filtragem e descoberta de conteúdo, ao passo que, se o seu aplicativo usa apenas algo na camada de transporte, cabe ao aplicativo implementar a descoberta e a filtragem, se necessário. A Tabela 1 fornece todos os recursos disponíveis em cada camada de transporte ou estrutura.


Tabela 1. Recursos de transporte e estrutura
Você pode construir um aplicativo de Internet Industrial distribuído usando um transporte? sim. Você pode construir um aplicativo de Internet Industrial distribuído usando uma estrutura? sim. Um é melhor que o outro? A verdadeira resposta é:"Depende." Depende dos requisitos de seu aplicativo quanto à solução mais adequada para sua infraestrutura. O restante deste post passará por várias dessas estruturas e transportes para que você possa decidir qual é a tecnologia certa para o seu aplicativo.

Transportes

Existem muitas soluções disponíveis hoje para obter dados entre aplicativos. No IICF, existem transportes chamados que aproveitam as interfaces de soquete IP padrão de UDP ou TCP. Se seu aplicativo precisa de transferência de dados confiável, um desenvolvedor escolheria o TCP por seus recursos orientados a conexão e mecanismos confiáveis. Para uma conexão mais simples e transferência de dados não confiável, o UDP seria escolhido por sua facilidade de uso e entrega multicast. Durante anos, a maioria dos aplicativos de rede usou essas interfaces básicas para enviar e receber dados. Todos os recursos fornecidos pelos transportes de camada superior (listados na Tabela 1) teriam que ser desenvolvidos diretamente, dentro do aplicativo. Ao olhar para os transportes de camada superior de DDS-RTPS, CoAP, MQTT, HTTP e OPC-UA Bin, veremos realmente apenas os detalhes para CoAP e MQTT. Os transportes DDS-RTPS, HTTP e OPC-UA Bin são basicamente vinculados diretamente às estruturas acima deles de DDS, Web Services e OPC-UA, respectivamente. As capacidades desses transportes serão discutidas como parte da discussão da estrutura a seguir.

MQTT

Vamos dar uma olhada no Message Queuing Telemetry Transport (MQTT). Novamente, MQTT é listado aqui como um transporte porque não impõe nem implementa um modelo de dados para aplicativos. Ele fornece apenas um buffer no qual os aplicativos devem formular seus dados para envio e recebimento. Seu objetivo principal para o qual foi criado está listado diretamente em seu nome:Telemetria. Ter um dispositivo ou aplicativo em campo se conectar e relatar dados para uma nuvem de back-end ou local de processamento externo. Esse transporte é ótimo para coisas como um gateway IoT doméstico ou gerenciador de um conjunto de dispositivos implantados. A arquitetura primária para MQTT é baseada em broker, como pode ser visto na Figura 2.
Figura 2. Arquitetura do MQTT Broker
Nessa arquitetura, todos os clientes remotos enviam seus dados para o broker MQTT, e o broker é responsável por enviar seus dados a qualquer cliente que tenha solicitado esses dados. Essa arquitetura baseada em broker facilita o envio e o recebimento de dados de maneira fracamente acoplada, mas não se presta a suportar aplicativos industriais altamente determinísticos e de baixa latência. Como transporte, o MQTT tem um lugar no cenário geral de Aplicações Industriais Distribuídas. A seguir está uma ferramenta que você pode usar para determinar se MQTT é algo que você deve usar para seu próximo projeto ou projeto atual. Aqui estão cinco perguntas "sim" ou "não" para você. Se sua resposta a três ou mais dessas perguntas for "sim", MQTT é a escolha certa para você.

Perguntas MQTT

1. Você pensa em seu aplicativo como uma coleta de dados?
2. Há pouca comunicação dispositivo-dispositivo?
3. A interoperabilidade não é considerada?
4. Você tem muitos dispositivos pequenos?
5. O software é um pequeno desafio?

MQTT é o único transporte listado no documento IICF que não está realmente vinculado a uma estrutura de camada superior. Este é o motivo pelo qual o separamos separadamente como um transporte. Agora, vamos dar uma olhada nas estruturas listadas no documento da CII.

Estruturas

Conforme mencionado anteriormente, a diferença distintiva entre uma estrutura e transporte é o fato de que uma estrutura inclui um recurso para manter e impor um modelo de dados que é usado pelos aplicativos que participam da estrutura. Das quatro estruturas chamadas, OPC-UA, OneM2M, DDS e Web Services, examinaremos apenas as três primeiras. Web Services é um framework muito conhecido com muitas referências online que podem ser encontradas para pesquis

[1] [2] 下一页