Comunicação de dados para

sistemas escaláveis
Bruno Cesar: Partner BDM, CLA

ni.com
 Objetivos da sessão
• Discutir arquiteturas comuns para tratar a questão da
escalabilidade nos sistemas embarcados.
• Não discutiremos os fundamentos básicos de cada tipo de
mecanismo de comunição (o que é um TCP, o que é uma
fila etc).
• Para obter mais informações sobre os conceitos básicos, consulte
o guia de desenvolvedores do LabVIEW para CompactRIO
(ni.com/compactriodevguide).
• Discutiremos os prós e contras de diferentes mecanismos
- quando usar um e não outro.

ni.com 2
 Por que a escalabilidade é importante?

ni.com 3
 Por que a escalabilidade é importante?

ni.com 4 …
 Por que a escalabilidade é importante?

…
…

ni.com 5
 Objetivo da escalabilidade

Reduzir o trabalho e o risco de adicionar "mais um"

ni.com 6
 Estratégias da escalabilidade
• Use esquemas de comunicação flexíveis que minimizam
a exigência de conhecimento prévio dos sistemas.
• Sem endereços codificados se for possível.
• Use mecanismos de comunicação otimizados para cada
tipo de comunicação necessária
• Provavelmente você precisará mais de um.
• Se a única ferramenta que tiver for um martelo...
• Arquitete o sistema de forma que a comunicação tenha
mínimo impacto nas operações críticas.

ni.com 7
 Mecanismos de comunicação de dados
TCP e UDP Notificador
Streams de rede TCP simples/mensagem via IP (STM)
Variáveis compartilhadas AMC
DMAs HTTP
Actor Framework FTP
Streaming Peer-to-Peer DVR
Filas Serviços web
Eventos dinâmicos ZMQ
Variáveis globais funcionais AMQP
FIFOs RT DDS
Datasocket ….
Variáveis locais Há muitas outras...
Servidor de VIs
FIFOs com escopo de target

ni.com 8
 Tipos de comunicação de dados

Tag Dados do valor atual

Mensagens/comandos Dados intermitentes, envio confiável

Streaming Aquisição contínua, alta taxa transferência

ni.com 9
 Arquitetura com um nó

ni.com
 Arquitetura com um nó
Ótimo para 1:1
Foco na escalabilidade: baixa ou nenhuma
A funcionalidade é geralmente a primeira
preocupação

Aplicações:
Protótipos
Monitoramento e controle simples

Prováveis preocupações:
Fácil substituição do cliente ou nó

ni.com
 Sistema de controle autonômo
Computador arbitrário
Sem necessidade de instalação
Qualquer sistema operacional
Precisa ser conectado rapidamente a uma interface
de manutenção

HTTP, HTML, XML

Página web hospedada

Serviços web

ni.com
 Datalogger embarcado
Cliente do LV
Terminal de streaming já conhecido
Conecta-se a um nó por vez

Variáveis compartilhadas para status

Stream de rede de nó para comando
Stream de rede de cliente para monitoramento de forma
de onda
FTP/WebDAV para transferência de arquivo

O Shared Variable Engine hospeda os tags de status

Os streams se conectam a um HMI por vez

ni.com
 Replicação

ni.com
 Arquitetura com vários nós

ni.com
 Arquitetura com vários nós
Foco na escalabilidade: Código do cliente

Aplicações:
Diversas instâncias de nós idênticos para um cliente
Baixa (muitas vezes fixa) quantidade de nós

É muito difícil adicionar mais um?

•Código do nó: pouco ou nenhum esforço
•Código do cliente: esforço médio

Prováveis preocupações:
•Sincronização dos timestamps
•Reconfiguração das telas HMI
•Nomes dos terminais de streaming na rede

ni.com
 Sincronização dos Timestamps

ni.com 17
 Reconfiguração das telas HMI

ni.com 18
 Streaming em rede autônoma
• Os streams de rede são (por projeto) um tubo de
comunicação 1:1
• Exatamente 1 ponto terminal escritor e 1 leitor por stream
• As URLs de ponto terminal não podem ser utilizadas com vários streams
• A solução mais fácil é codificar uma URL para cada nó
• Para escalonar, é preciso uma nova camada

ni.com 19
 Streaming em rede com um nó

IU:

RT:

ni.com 20
 Arquitetura sem servidor
…

…
ni.com
 Arquitetura sem servidor
Foco na escalabilidade: Código do nó e código do cliente

Aplicações:
Diversas estações de monitoramento para sistemas complexos
Uma única estação em controle de qualquer nó

É muito difícil adicionar mais um?

•Código do nó: esforço médio
•Código do cliente: esforço médio

Prováveis novas preocupações:

•Carga nos nós devido ao acesso do cliente

ni.com
 Alertas sobre as Shared Variables
• As variáveis compartilhadas não são projetadas para
comandos ou streams.
• Elas são um mecanismo de comunicação com perdas
o Não é prudente enviar uma mensagem de parada de emergência
através de um variável compartilhada
• As variáveis compartilhadas funcionam melhor em taxas
baixas
• Taxas da ordem de 1Hz a 1/10 Hz
• A carga no serviço Shared Variable Engine é proporcional
à quantidade de assinantes e frequência das atualizações
• Existe uma ferramenta para avaliar o desempenho no seu
sistema
• Faça uma busca no ni.por ‘Shared Variable Benchmark Utility’

ni.com 23
 Arquitetura com um servidor
…

…
ni.com
 Arquitetura com vários servidores
…

ni.com
 Vários servidores com serviço lookup
Servidor(es) de diretórios

ni.com
 As melhores práticas para escalabilidade
• Seleção adequada do mecanismo de comunicação
• Provavelmente você precisará mais de um.
• Reduza o acoplamento entre os componentes (sejam
eles simples Loops ou Nós)
• Reduza os esforços de configuração
• Automatize ou exclua certas necessidades
• Os arquivos de configuração legíveis por humanos como INI ou
XML serão seus melhores amigos
• Reduza o tráfego
• Faça atualizações diferenciais, envie apenas para aqueles que
precisam deles
• Sincronização do Timestamp entre o hardware

ni.com 27
 Perguntas?

?
ni.com 28
 Guia do desenvolvedor do LabVIEW para CompactRIO

ni.com/compactriodevguide

ni.com 29
 Faça a sua certificação de sistemas embarcados!

A National Instruments está oferecendo agora o

Certified LabVIEW Embedded Developer Exam

Para verificar mais informações, acesse

ni.com/cled

ni.com 30