Databus vs. Database: 6 Perguntas-Chave que Todo Desenvolvedor IIoT Deve Considerar

A Internet Industrial das Coisas (IIoT) introduz muitos conceitos novos, frequentemente construindo sobre princípios de computação familiares mas remodelando como sistemas operam. Entre estes, o "databus" se destaca como elemento fundamental.

A futura IIC reference architecture v2 introduz um novo padrão chamado "layered databus". Embora detalhes ainda estejam sob revisão, o processo de documentação esclareceu definições-chave e melhores práticas.

Definição: Um databus é uma tecnologia de compartilhamento de informação centrada em dados que implementa um espaço de dados virtual e global. Aplicações de software leem e atualizam entradas neste espaço, e atualizações são propagadas via mecanismo publish-subscribe.

Características-chave:

1. As aplicações interagem diretamente com os dados, sem wrappers intermediários.
2. A infraestrutura compreende os dados, permitindo filtragem seletiva e ferramentas avançadas.
3. A infraestrutura impõe garantias de Quality-of-Service (QoS) como taxa, confiabilidade e segurança.

Estas propriedades levam a uma série de questões que surgem ao introduzir conceitos de databus em um ambiente IIoT. As seis seções a seguir abordam as indagações mais comuns.

Pergunta 1: Como um databus difere de um database?

Resposta curta: Um database armazena dados históricos para recuperação posterior, enquanto um databus gerencia dados vivos e chegando, filtrando-os pelas propriedades da nova informação.

Resposta longa: Centricidade em dados é expressa através de três dimensões:

• Interface: Os próprios dados são a interface primária; não há wrappers artificiais como mensagens ou arquivos.
• Compreensão: A infraestrutura pode interpretar os dados, permitindo filtragem, busca e integração de ferramentas.
• Governança: O sistema impõe regras para troca de dados, estabelecendo uma única fonte de verdade e gerenciando ciclos de vida, schemas e semântica CRUD.

Um database relacional, por exemplo, fornece camada de armazenamento estruturado que impõe consistência e oferece busca global. Ele define a "verdade" do sistema porque dados armazenados não podem ser corrompidos ou perdidos. Um databus, por outro lado, fornece um espaço de dados virtual global que permite aplicações escreverem e lerem fluxos de dados, enquanto o middleware aplica regras QoS e entrega apenas a informação que corresponde aos critérios do consumidor.

Pergunta 2: Um databus age como um database acessado via interface pub-sub?

Resposta curta: Não. Um database implica armazenamento persistente; um databus oferece um espaço de dados virtual e global puramente que pode ou não persistir dados.

Resposta longa: Considere um controlador de interseção assinando posições de veículos dentro de 200 m. O controlador recebe atualizações que satisfazem suas restrições QoS (ex: < 0.01 s latência, 100 atualizações/s). O databus pode entregar dados diretamente sem armazená-los, embora cache temporário possa ocorrer para atender requisitos de confiabilidade.

Pergunta 3: O que significa que participantes interagem diretamente com os dados?

Em middleware centrado em mensagens, aplicações devem saber detalhes sobre o peer, como schema e taxas de atualização esperadas, o que adiciona acoplamento e prejudica reuso. Um databus abstrai esses detalhes; aplicações leem ou escrevem no espaço de dados usando interface CRUD, especificando apenas os dados e QoS necessários. A infraestrutura lida com descoberta de fonte, filtragem, transporte e garantias.

Pergunta 4: Como a filtragem seletiva funciona em um databus comparado ao pub-sub tradicional?

Pub-sub tradicional meramente encaminha mensagens para assinantes, frequentemente sem inspecionar payloads. Mesmo pub-sub com filtro de conteúdo depende de seletores simples que não podem expressar QoS complexo. Um databus, por contraste, permite que um assinante especifique critérios detalhados (ex: veículo dentro de 200 m, movendo-se > 10 m/s em direção à interseção, atualizações 200 Hz). O middleware impõe estas restrições na fonte, throttling, descartando ou bufferizando dados para atender o contrato, e garantindo liveness.

Como a filtragem acontece no produtor, o assinante recebe apenas amostras relevantes (ex: 600 atualizações por segundo), drasticamente reduzindo largura de banda e overhead de processamento enquanto assegura confiabilidade.

Pergunta 5: Como um databus difere de um motor CEP?

Resposta curta: Um databus é middleware distribuído que encaminha dados baseado em filtros simples, enquanto um motor CEP é serviço centralizado que avalia padrões complexos de eventos.

Resposta longa: Motores CEP analisam fluxos para detectar padrões definidos pelo usuário e podem acionar ações, mas exigem que todos os dados sejam roteados para um único nó. Um databus realiza filtragem local em cada fonte de dados, entregando apenas amostras correspondentes a consumidores interessados, escalando assim para milhares de nós sem gargalos centrais.

Pergunta 6: O que impulsionou a criação do padrão DDS e conceitos de databus?

Adotantes iniciais em robótica, defesa e sistemas de coordenação de larga escala demandavam confiabilidade, baixa latência e descoberta seletiva diante de falhas de componentes. Estes requisitos levaram ao padrão DDS, que hoje encontra aplicação em saúde, transporte, cidades inteligentes e setores de energia.

Para saber mais sobre software inteligente moldando a IIoT, baixe nosso whitepaper, The Secret Sauce of Autonomous Cars.