Banco de dados vs. banco de dados:as 6 perguntas que todo desenvolvedor de IIoT precisa fazer

mento de dados substituem a interação aplicativo-aplicativo pela interação aplicativo-dados-aplicativo. Essa abstração é absolutamente crítica. Ele desacopla aplicativos e facilita muito o dimensionamento, a interoperabilidade e a integração do sistema. A diferença está realmente entre os dados antigos armazenados em um banco de dados (provavelmente centralizado) e os dados futuros enviados diretamente para os aplicativos a partir de um espaço de dados distribuído.

Pergunta 4:"A infraestrutura entende e pode, portanto, filtrar seletivamente os dados." Isso não é verdade para todos os pub-sub, onde você pode se inscrever para "eventos" do seu interesse?

A maioria dos pub-sub é muito primitiva. Um aplicativo "registra interesse", e então tudo é simplesmente enviado para aquele aplicativo. Assim, por exemplo, um algoritmo de detecção de colisão de interseção pode inscrever-se em "posições de veículos". A infraestrutura então envia mensagens de qualquer sensor capaz de produzir posições, sem nenhum conhecimento dos dados dentro dessa mensagem. Até mesmo o pub-sub de "filtragem de conteúdo" oferece especificações muito simples e exige que o sistema pré-selecione o que é importante para todos. Não há controle real de fluxo.

Um barramento de dados é muito mais expressivo. Essa interseção poderia dizer "Estou interessado apenas nas posições dos veículos dentro de 200m, movendo-se a 10m / s em minha direção. Se um veículo se enquadrar nas minhas especificações, preciso ser atualizado 200 vezes por segundo. Você (o barramento de dados) precisa me garantir que todos os sensores que alimentam este algoritmo prometem fornecer dados tão rápido ... nem mais lento nem mais rápido. Se um sensor for atualizado 1000 vezes por segundo, envie-me apenas a cada 5 atualizações. Também preciso saber se você realmente está em contato com -sensores vivos (que eu defino como produzidos nos últimos 0,01 segundos) em todas as abordagens possíveis da estrada em todos os momentos. Cada sensor deve ser capaz de armazenar 600 amostras antigas (no valor de 3 segundos) e atualizar-me com os dados antigos se eu precisar isto." (Estas são algumas das mais de 20 configurações de QoS no padrão DDS.)

Observe que um aplicativo de assinatura no caso pub-sub primitivo é muito dependente das propriedades reais de seus produtores. Ele tem que confiar de alguma forma que eles estão vivos (!), Que eles têm buffers suficientes para salvar as informações de que podem precisar, que eles não vão inundá-los com informações nem fornecê-los muito lentamente. Se houver 10.000 carros sendo detectados 1000x / seg, mas apenas 3 dentro de 200m, ele terá que receber 10.000 * 1000 =10m amostras a cada segundo apenas para encontrar 3 * 200 =600 que precisa prestar atenção. Ele terá que executar ping a cada sensor 100x / segundo apenas para garantir que esteja ativo. Se houver sensores redundantes em caminhos diferentes, ele terá que executar ping em todos eles independentemente e, de alguma forma, certificar-se de que todos os caminhos sejam cobertos. Se houver muitos aplicativos, todos eles terão que executar ping em todos os sensores independentemente. Ele também deve conhecer o esquema dos produtores, etc.

A aplicação no segundo caso irá, ao contrário, receber exatamente as 600 amostras com as quais se preocupa, confortável por saber que pelo menos um sensor para cada caminho está ativo. A taxa de fluxo é garantida. Confiabilidade suficiente é garantida. O fluxo de dados total é reduzido em 99,994% (precisamos apenas de amostras de 600 / 10m, e o middleware inteligente faz a filtragem na origem). Para completar, observe que o algoritmo de colisão é completamente independente dos próprios sensores. Ele pode ser reutilizado em qualquer outro cruzamento e funcionará com um sensor por caminho ou 17. Se durante o tempo de execução, a rede ficar muito carregada para atender às especificações de dados (ou algo falhar), o aplicativo será notificado imediatamente.

Pergunta 5:Como um barramento de dados difere de um mecanismo CEP?

Resposta curta:um barramento de dados é um conceito fundamentalmente distribuído que seleciona e fornece dados de produtores locais que correspondem a uma especificação simples. Um mecanismo CEP é um serviço executável centralizado que é capaz de especificações muito mais complexas, mas deve ter todos os fluxos de dados enviados para um lugar.

Resposta longa:um mecanismo de Processamento de Eventos Complexos (CEP) examina um fluxo de entrada de dados, procurando padrões que você o programa para identificar. Quando ele encontra um desses padrões, você pode programá-lo para agir. Os padrões podem ser combinações complexas de dados passados ​​e futuros recebidos. No entanto, é um serviço único, rodando em uma única CPU em algum lugar. Não transmite nenhuma informação.

Um barramento de dados também procura padrões de dados. No entanto, as especificações são mais simples; ele toma decisões sobre cada item de dados à medida que são produzidos. As ações também são mais simples; a única ação que pode tomar é enviar esses dados a um solicitante. O poder de um barramento de dados é que ele é fundamentalmente distribuído. A procura ocorre localmente em potencialmente centenas, milhares ou mesmo milhões de nós. Portanto, o barramento de dados é uma maneira muito poderosa de selecionar os dados corretos das fontes corretas e enviá-los para os lugares certos. Um barramento de dados é uma espécie de conjunto distribuído de motores CEP, um para cada fonte possível de informação, que são programados automaticamente pelos usuários dessas informações. Claro, o barramento de dados tem muitas outras propriedades além da correspondência de padrões, como mediação de esquema, gerenciamento de redundância, suporte de transporte, um protocolo interoperável, etc.

Pergunta 6:Qual aplicativo impulsionou o padrão DDS e os barramentos de dados?

As primeiras aplicações foram em robôs inteligentes, "superioridade de informação" e grandes sistemas coordenados, como gerenciamento de combate da marinha. Esses sistemas precisavam de confiabilidade mesmo quando os componentes falhavam, os dados eram rápidos o suficiente para controlar os processos físicos e a descoberta seletiva e a entrega em escala. A centralização de dados realmente simplificou o código do aplicativo e as interfaces controladas, permitindo que equipes de programadores trabalhem em grandes sistemas de software ao longo do tempo. O padrão DDS é uma família de padrões ativa e crescente que foi originalmente conduzida por fornecedores e clientes. Ele tem uso significativo em muitos setores, incluindo medicina, transporte, cidades inteligentes e energia.

Se você gostaria de saber como o software inteligente está varrendo a IIoT, certifique-se de baixar nosso white paper sobre o futuro da indústria automotiva, "The Secret Sauceof Autonomous Cars".

上一页  [1] [2] 

5 dos melhores webinars sob demanda para inspirar sua IIoT e designs de sistema Visualizando dados em aplicativos de microssensor