Acelere Time-to-Market com Ferramentas Profissionais RTI Connext DDS

Restavam apenas duas semanas antes da demo.

Tínhamos uma única oportunidade de alto risco para entregar um sistema de controle de microgrid totalmente funcional que tinha que:

• Rodar em processadores Intel e ARM
• Alvo plataformas Linux e Windows
• Incluir aplicações escritas em C, C++, Java, Scala, Lua e LabVIEW
• Comunicar com equipamento legado usando protocolos ModBus e DNP3
• Realizar controle em tempo real enquanto atendia todos os requisitos acima

Neste post, compartilharei os desafios reais que enfrentamos e como as ferramentas incluídas no RTI Connext DDS Professional nos ajudaram a resolver problemas de integração em apenas alguns dias. Destacarei problemas comuns e as ferramentas RTI específicas que abordaram cada um, e fornecerei links para vídeos e artigos de suporte para quem quiser mergulho mais profundo. Meu objetivo é dar a você um ponto de partida prático para aplicar ferramentas RTI e acelerar seu desenvolvimento DDS.

A Grande Demo

Esta foi a primeira demonstração funcional do Open Field Message Bus (OpenFMB) do Smart Grid Interoperability Panel, uma nova abordagem para controle de dispositivos de borda de rede usando tecnologias IoT como DDS.

Abaixo está um diagrama de blocos do sistema, mostrando arquiteturas de hardware, sistemas operacionais e linguagens de programação:

À medida que trazíamos cada participante online, encontramos vários desafios. As seções a seguir descrevem cada problema e as ferramentas que usamos para resolvê-lo. Escaneie os títulos para ver se você enfrentou problemas similares em seu sistema DDS, então clique nos links para aprender novas técnicas de troubleshooting. Considere como você teria diagnosticado esses problemas sem as ferramentas mencionadas.

Problema: Questões de configuração de rede

Ferramentas: RTI DDS Ping

A equipe do Oak Ridge National Labs estava construindo uma GUI LabVIEW que serviria como display principal. O laptop deles não via dados de nenhum dos clientes em rede. Primeiro verificamos que a máquina estava na mesma sub-rede — o clássico passo "verifique o básico". Enquanto o utilitário ping padrão confirma alcance básico, ele não verifica se portas de descoberta DDS estão abertas. O utilitário rtiddsping faz exatamente isso, e revelou em segundos que um firewall de laptop emitido pelo governo estava bloqueando tráfego de descoberta DDS. Para guia completo sobre diagnósticos básicos, veja este post da comunidade.

Problema: Minha aplicação está publicando dados?

Ferramentas: Spy, Admin Console

Uma pergunta frequente entre fornecedores novos no DDS é se sua aplicação está se comportando corretamente: Está publicando dados nos intervalos esperados, e os dados fazem sentido? Usamos RTI DDS Spy, um assinante leve que pode filtrar por tipos e tópicos específicos e imprimir cada amostra que recebe. Todo fornecedor realizou verificação rápida com Spy imediatamente após lançar sua aplicação.

Se o mesmo tópico é atualizado por múltiplos publicadores, a chave "-showSampleIdentity" revela qual publicador enviou a amostra mais recente.

Spy é um app de console que pode rodar em targets embarcados para testes básicos. Sua pegada pequena, inicialização rápida e simplicidade o tornam ideal para verificação rápida. Instruções detalhadas de uso estão disponíveis aqui.

Problema: Incompatibilidade de tipo de dado

Ferramentas: Admin Console, Monitor

Um fornecedor relatou que após um teste anterior eles podiam ver dados de outra aplicação, mas durante a demo os dados desapareceram. Admin Console identificou imediatamente um mismatch de tipo de dado — dois tópicos compartilhando o mesmo nome mas definidos com estruturas IDL diferentes. Tais mismatches podem ser difíceis de detectar, especialmente para tipos grandes e complexos. Admin Console alavanca a natureza centrada em dados do DDS para introspecionar os tipos de dados entendidos por cada participante, apresentando tanto uma visão simplificada quanto uma visão "IDL equivalente" para comparação lado a lado. Isso é inestimável quando você não tem o IDL fonte para toda aplicação.

Neste caso, o fornecedor estava usando um IDL desatualizado de um commit GitHub mais antigo. Após puxar os arquivos mais recentes, rodar rtiddsgen gerou código específico de tipo atualizado, e uma recompilação rápida restaurou compatibilidade total.

Problema: Mismatch de QoS

Ferramentas: Admin Console, Monitor

Além da descoberta, mismatches de QoS são o problema de integração mais comum para usuários DDS. Com tantos botões para ajustar, como garantir compatibilidade? O projeto OpenFMB encontrou vários mismatches de QoS inicialmente. Admin Console detecta estes rapidamente e destaca configurações conflitantes. Você pode clicar no nome do QoS para pular direto para a documentação. Informação de QoS trocada durante descoberta permite Admin Console sinalizar mismatches automaticamente.

Problema: Verificando performance do sistema

Ferramentas: Admin Console, Monitor

Enquanto Spy fornece saída de texto bruta, visualizar dados ao longo do tempo dá imagem mais clara do comportamento do sistema. A visualização de dados integrada do Admin Console nos ajudou a avaliar rapidamente performance geral do sistema e rolar através de dados históricos para rastrear o estado atual. Para vídeo intro curto, veja este vídeo, e para mergulho mais profundo, assista este vídeo.

Problema: Ajuste de performance

Ferramentas: Monitor, Admin Console

Para tuning de performance, Monitor é a ferramenta de escolha. Ele funciona com versão especial das bibliotecas DDS que periodicamente publicam métricas de performance em tempo real da sua aplicação. As bibliotecas debug são minimamente intrusivas, e Monitor agrega os dados para análise.

Com Monitor você pode inspecionar:

• Estatísticas de transmissão e recepção
• Deadlines perdidos
• Marcas de água alta de cache
• Mismatches de QoS
• Conflitos de tipo de dado
• Amostras perdidas ou rejeitadas
• Perda de liveness

Muitas configurações QoS não são anunciadas durante descoberta porque afetam gerenciamento de recursos locais e tuning de performance. Monitor permite examinar estes também. Assista este vídeo introdutório para um tour rápido.

Problema: Transformando dados em voo

Ferramentas: Prototyper com Lua, DDS Toolkit para LabVIEW

Precisávamos de GUI grande para exibir estado de microgrid em tempo real. Oak Ridge National Labs se voluntariou para construir a GUI em LabVIEW. O DDS Toolkit para LabVIEW permite recuperar dados DDS e usá-los dentro de VIs LabVIEW. No entanto, o Toolkit não suporta arrays de sequências, que fazem parte do modelo de dados OpenFMB. Requeríamos solução rápida que pudesse ler estes tipos complexos.

Prototyper com Lua, novo recurso no Connext DDS Pro 5.2, permite criação rápida de aplicações habilitadas para DDS com codificação mínima: defina tópicos e domain participants em XML, adicione script Lua simples, e você está rodando em um domínio DDS em minutos. (Veja post do blog de Gianpiero sobre Prototyper.)

Naquela noite, escrevi script Lua instruindo Prototyper a ler tópicos DDS complexos contendo arrays de sequências e republicá-los em tópico achatado para a GUI LabVIEW. Testei o script offline usando dados ao vivo gravados anteriormente, o que levou à próxima seção.

Problema: Desenvolvimento desconectado

Ferramentas: Record, Replay, Prototyper com Lua

A demo OpenFMB foi construída por equipe geograficamente dispersa. Exceto por alguns dias em Knoxville, ninguém teve acesso simultâneo a todos componentes de microgrid. Como cada desenvolvedor poderia trabalhar em sua peça do quebra-cabeça sem o resto do sistema?

Ao trabalhar na bridge Lua para a GUI LabVIEW, usei os serviços Connext Pro Record e Replay. No laboratório, gravei cerca de dez minutos de dados ao vivo cobrindo todos casos de uso. Naquela noite, em hotel, re-reproduzi os dados enquanto refinava os scripts Lua. Replay permite reproduzir seletivamente tópicos, loopar reprodução para simulação contínua e ace

[1] [2]  >