Um Protocolo para Geração Automática de Interfaces Baseadas na Web para Aplicações LabVIEW Utilizando o Protocolo de Interoperabilidade Remota

Resumo

Este estudo valida a geração automática de interface de usuário da Web baseada em um protocolo de interoperabilidade remota (RIP) com dois sistemas LabVIEW distintos — um modelo de ventilador e um modelo de controle de posição de motor de corrente contínua — e fornece um procedimento reproduzível para construir, registrar, implantar e testar ambos os exemplos.

Resumo

Plataformas experimentais remotas permitem que modelos de simulação locais ou dispositivos físicos sejam acessados por meio de uma rede, mas interfaces Web convencionais normalmente exigem uma página separada, um layout de controle e uma lógica de comunicação de dados distintos para cada experimento, o que aumenta os custos de desenvolvimento. Este trabalho valida um fluxo de trabalho estabelecido para gerar automaticamente uma interface de usuário (IU) Web a partir de instrumentos virtuais (VIs) do LabVIEW utilizando o protocolo de interoperabilidade remota (RIP) e fornece um protocolo reprodutível para sua implementação. O fluxo de trabalho constrói VIs do LabVIEW que definem controles de entrada e indicadores de saída no Painel Frontal, registra cada VI na Configuração do Servidor RIP, lê os metadados resultantes das variáveis e gera os controles Web correspondentes e exibições de saída. O Caddy é utilizado como proxy reverso para unificar o caminho de arquivos estáticos do front-end e o caminho de solicitação da interface de programação de aplicações (API) do RIP. O fluxo de trabalho é avaliado com dois sistemas distintos: um modelo de velocidade de ventilador e um modelo de controle de posição proporcional-integral-derivativo (PID) de motor de corrente contínua (CC). Em ambos os casos, a página Web identifica as variáveis expostas, escreve as entradas do usuário no back-end do LabVIEW, lê as saídas do modelo e gera a interface a partir dos metadados do RIP. Esses resultados validam o mesmo processo de geração automática de IU em dois sistemas dinâmicos diferentes e documentam os passos necessários para reproduzi-lo.

Introdução

Com o desenvolvimento de experimentos remotos, ensino on-line e tecnologias da Internet das Coisas, fornecer acesso baseado na Web a modelos de simulação locais ou dispositivos experimentais tornou-se uma direção importante para o desenvolvimento de plataformas experimentais^1,2,3,4. Trabalhos recentes integraram ainda mais laboratórios equipados com Internet das Coisas ao aprendizado baseado em projetos e ao acesso local ou remoto, demonstrando o contínuo avanço de plataformas experimentais flexíveis e interconectadas na educação em engenharia⁵. Em experimentos de sistemas de controle, os usuários geralmente precisam ajustar parâmetros de entrada em um navegador e observar os estados de saída em tempo real^6,7. Os métodos convencionais normalmente exigem uma página da Web separada, lógica de vinculação de controle e interface de comunicação de dados para cada objeto experimental^8,9. Quando as variáveis no modelo de back-end mudam, a página de front-end frequentemente precisa ser modificada de forma correspondente, o que gera um substancial trabalho repetitivo de desenvolvimento e limita a expansão rápida da plataforma experimental.

O protocolo de interoperabilidade remota (RIP) fornece uma camada intermediária entre modelos experimentais de back-end e interfaces Web front-end^10,11. Na abordagem baseada em RIP para geração automática de interface do usuário descrita em trabalhos anteriores, o Servidor RIP fornece metadados para cada experimento, incluindo nomes de variáveis, atributos de entrada/saída, tipos de dados, valores mínimos, valores máximos, precisão, descrições e os métodos disponíveis de leitura/escrita¹¹. Um cliente Web pode então usar esses metadados para criar os elementos HTML correspondentes, como rótulos, campos de entrada numérica, controles deslizantes, controles booleanos e exibições de saída, durante o carregamento ou atualização da página¹¹. O presente protocolo não reimplementa nem redefine a especificação do RIP. Em vez disso, utiliza o serviço RIP de código aberto existente e a lógica de geração de interface do usuário em HTML a partir de metadados baseada em RIP como base para comunicação e geração de interface, concentrando-se na construção reprodutível, registro, implantação de proxy e verificação de dois exemplos de VI LabVIEW.

Em comparação com o desenvolvimento convencional de interfaces web personalizadas, a geração automática de interface de usuário baseada em RIP reduz a necessidade de implementar layouts de controle, lógica de vinculação de variáveis e funções básicas de comunicação quando múltiplos experimentos LabVIEW expõem variáveis escalares de entrada e saída semelhantes^8,9,10,11. Após um novo VI ser registrado e suas variáveis estarem disponíveis para o Servidor RIP, a mesma lógica de leitura de metadados e geração de controles pode ser reutilizada para construir a interface web básica^10,11. Esse recurso é útil para implantação rápida, demonstrações didáticas e plataformas de laboratórios remotos que exigem acesso consistente a diversos experimentos semelhantes^3,8,9. No entanto, a interface gerada automaticamente também apresenta limitações. Ela não infere completamente as relações físicas entre as variáveis, não determina automaticamente os mapeamentos de gráficos nem projeta visualizações e interações de segurança específicas do domínio¹¹. Portanto, o desenvolvimento manual da interface web continua sendo preferível quando um experimento exige gráficos altamente personalizados, fluxos de trabalho complexos para o usuário, visualização avançada, intertravamentos de segurança de hardware ou arbitragem de escrita para múltiplos usuários.

O fluxo de trabalho geral do protocolo é resumido na Figura 1. Neste fluxo de trabalho, um VI do LabVIEW primeiramente define os controles de entrada e indicadores de saída necessários no Painel Frontal. O VI é então registrado na Configuração do Servidor RIP mediante a especificação do nome do experimento e do caminho do VI. Após o registro, o Servidor RIP lê os metadados do experimento selecionado e fornece acesso de leitura e gravação às variáveis disponíveis. A página da Web XHTML utiliza os metadados retornados para gerar automaticamente os controles de entrada e exibições de saída correspondentes, enquanto o Caddy fornece um caminho unificado de acesso para a página da Web estática e as rotas de comunicação do RIP. Os modelos de ventilador e de motor de corrente contínua são utilizados neste estudo como duas implementações do mesmo fluxo de trabalho. Para outros experimentos do LabVIEW que ofereçam variáveis escalares, numéricas e booleanas compatíveis, os desenvolvedores podem seguir o mesmo fluxo de trabalho de criação-registro-implantação-verificação para criar uma interface da Web gerada automaticamente, acrescentando, quando necessário, visualizações específicas do experimento, lógica de segurança ou tratamento complexo de dados.

Este artigo não propõe uma nova arquitetura RIP nem amplia o leque de tipos de dados já suportados pelo RIP. Em vez disso, utiliza o RIP como mecanismo estabelecido de comunicação e geração de interface de usuário baseada em metadados, concentrando-se na validação desse mesmo processo com dois sistemas LabVIEW diferentes, ao mesmo tempo em que documenta um protocolo de implementação reproduzível. Trabalhos anteriores apresentaram um método básico para geração automática de interfaces web com base em metadados do RIP e usaram um experimento online com motor servo como estudo de caso¹¹. Arquiteturas de laboratórios remotos com acesso web, combinando interfaces interativas com softwares de engenharia e LabVIEW, também foram relatadas em estudos anteriores^9,12. No entanto, durante a reprodução prática, alguns modelos LabVIEW do estudo original foram afetados pela compatibilidade entre versões de software e módulos, tornando-os difíceis de serem utilizados diretamente em ambientes mais recentes. Este trabalho, portanto, reconstrói duas VIs de back-end compatíveis — um modelo de ventilador e um modelo de controle de posição proporcional-integral-derivativo (PID) para motor de corrente contínua (CC) — e aplica o mesmo processo de geração de interface baseado em metadados a ambos. A contribuição consiste na validação cruzada do fluxo de trabalho RIP estabelecido e em um protocolo detalhado para reproduzir o processo, e não em uma extensão da generalidade do RIP.

Os usuários pretendidos deste protocolo são pesquisadores, instrutores e desenvolvedores de laboratórios que já utilizam VIs no LabVIEW e precisam expor modelos de simulação ou sistemas experimentais de baixo risco por meio de um navegador Web, sem precisar implementar independentemente uma interface personalizada completa para cada modelo. O protocolo é particularmente adequado para experimentos que utilizam variáveis numéricas e booleanas padrão, ajuste de parâmetros e monitoramento em tempo real do estado^10,11. É menos adequado como solução autônoma para experimentos que exigem estruturas de dados complexas, visualizações especializadas, intertravamentos rigorosos de segurança de hardware ou arbitragem de escrita multiusuário¹¹. O objetivo deste trabalho é validar a geração automática de interface Web baseada em RIP com dois sistemas diferentes no LabVIEW e fornecer um protocolo completo e reprodutível, desde a construção do VI de back-end até a interação baseada em navegador. O protocolo inclui a definição de variáveis de entrada e saída, registro do experimento no RIP Server, geração de interface baseada em metadados, implantação do proxy Caddy e verificação remota de leitura e escrita. A aplicação do mesmo fluxo de trabalho aos modelos de ventilador e motor CC demonstra que o processo estabelecido pode ser reproduzido sem a necessidade de reescrever manualmente uma interface Web completa para cada exemplo^9,10,11.

Protocolo

Conclua as seguintes etapas para construir, registrar, implantar e verificar dois experimentos LabVIEW acessíveis por RIP seguindo o fluxo de trabalho resumido na Figura 1. Todas as ferramentas e plataformas utilizadas neste estudo estão listadas na Tabela de Materiais.

1. Construa e implante o experimento com o modelo de ventilador

1. Construa o modelo de ventilador VI.
   1. Abra o LabVIEW, crie um novo VI e salve o arquivo como fengshan.vi. Salve o VI em qualquer diretório acessível pelo processo do RIP WebService. A pasta Private é usada apenas como exemplo de diretório e não está codificada no RIP. Insira o caminho real do VI selecionado durante o registro do experimento no RIP.
   2. No Painel Frontal, adicione os controles de entrada para o modelo do ventilador. Neste exemplo, nomeie os controles de entrada Habilitar, PWM, Carga, Tau, KMaxRPM e Perturbação. Definir Habilitar como um controle booleano e definir PWM, Carga, Tau, KMaxRPM, e Perturbação como controles numéricos de ponto flutuante de precisão dupla (DBL). Veja Tabela Suplementar 1 pelo significado físico e papel no modelo das variáveis do ventilador.
   3. Adicione os indicadores de saída para o modelo do ventilador. Neste exemplo, nomeie os indicadores de saída SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA e PowerW. Defina todos os indicadores de saída como indicadores DBL.
      ​OBSERVAÇÃO: Tabela 1 descreve o significado físico e o papel do modelo dessas variáveis de saída. O painel frontal do ventilador concluído é mostrado em Figura 2. Os nomes das variáveis, intervalos e tamanhos de passo mostrados em Tabela 1 descrever os dois exemplos implementados neste protocolo. Eles não são requisitos fixos do RIP. Para outros experimentos em LabVIEW, os desenvolvedores podem definir diferentes nomes de variáveis no Painel Frontal e propriedades numéricas. O Servidor RIP lê os nomes reais das variáveis, tipos de dados, atributos de entrada/saída e propriedades numéricas disponíveis a partir dos metadados do VI, e a página da Web gera os controles e exibições correspondentes a partir dos metadados retornados.
   4. Adicione um Laço Enquanto ao Diagrama de Blocos. Adicione dois Registradores de Deslocamento para armazenar velocidade_anterior e tempo_anteriore inicialize ambos os valores com 0.
   5. Adicione um Nó de Fórmula dentro do Laço Enquanto. Conecte Habilitar, PWM, Carga, Tau, KMaxRPM, Perturbação, velocidade_anterior e tempo_anterior aos terminais de entrada esquerda do Nó Fórmula, e defina SteadyRPM, velocidade_próxima, VelocidadeNormalizada, CorrenteA, PotênciaW, e próximo_tempo como os terminais de saída direitos.
   6. Construa o Habilitar lógica de controle fora do nó de fórmula. Utilize Habilitar como o sinal seletor de modo que u = Modulação por Largura de Pulso quando Habilitar é Verdadeiro e u = 0 quando Habilitar é Falso.
   7. Insira o código do modelo do ventilador no nó da fórmula. Utilize este código para calcular a velocidade em regime permanente, a velocidade real, a velocidade normalizada, a corrente, a potência e o tempo de operação; consulte o Arquivo de Código Suplementar 1 para obter o código completo.
   8. Conecte o próximo_velocidade saída do Nó Fórmula para o VelocidadeRPM indicador e conectar próxima_velocidade de volta ao Shift Register direito para velocidade_anterior. Conectar SteadyRPM ao SteadyRPM indicador.
   9. Conectar próximo_tempo ao Tempo indicador e conectar próximo_tempo de volta ao Registrador de Deslocamento da direita para tempo_anterior. Conectar SpeedNorm, CorrenteA e PowerW aos indicadores de saída correspondentes.
   10. Adicione uma função Esperar dentro do Laço Enquanto e defina o tempo de espera como 50 ms. Adicione um botão Parar Local e conecte-o ao terminal condicional do Laço Enquanto.
   11. Salve fengshan.vi. O diagrama de blocos do ventilador concluído é mostrado em Figura 3.
       PONTO DE PAUSA: Após salvar o VI do ventilador concluído, o fluxo de trabalho pode ser interrompido. Retome posteriormente reabrindo o VI salvo e confirmando se todos os controles, indicadores do Painel Frontal e conexões do Diagrama em Blocos ainda estão presentes.
2. Registre o experimento do ventilador no RIP Server.
   1. Abra o RIPWebService.lvproj no LabVIEW Project Explorer
      .
   2. Abra o Configuration.vi na árvore do projeto e localize a tabela de configuração do experimento.
   3. Adicione uma nova linha de experimento. Defina o Nome como fan. Defina o caminho completo para o arquivo fengshan.vi salvo. Os campos de registro para o experimento fan são mostrados em Figura 4.
   4. Preencha os campos de configuração restantes. Defina Autores como o autor do experimento, Palavras-chave como Fan, Descrição como modelo de velocidade do ventilador e Frequência de Amostragem como 200.
   5. No menu do LabVIEW, selecione Editar > Tornar os Valores Atuais como Padrão. Salvar Configuração.vi
   6. Reinicie o RIP WebService e confirme que o experimento da ventoinha permanece listado na interface de Configuração após a reinicialização.
      OBSERVAÇÃO: O nome do experimento diferencia maiúsculas de minúsculas. O valor fan na Configuração do RIP deve corresponder exatamente ao ID do experimento utilizado no arquivo XHTML da interface. Para implantar outro VI do LabVIEW com a mesma lógica de geração automática de interface, adicione uma nova entrada de experimento na Configuração do RIP, defina um novo valor em Nome e configure Caminho para o arquivo VI correspondente. Em seguida, utilize o mesmo valor de Nome como ID do experimento no arquivo XHTML. A página da interface não precisa ser reescrita para cada variável.
      ​PONTO DE PAUSA: Após salvar o Configuration.vi e definir os valores atuais como padrão, o fluxo de trabalho pode ser interrompido. Retome posteriormente reiniciando o RIP WebService e confirmando se o experimento com o ventilador ainda está registrado.
3. Prepare a página inicial para o experimento do ventilador.
   1. Coloque o arquivo Fan_Automatic_UI.xhtml no diretório Client usado como diretório raiz do front-end.
   2. Abra o arquivo Fan_Automatic_UI.xhtml com um editor de texto.
   3. Localize a variável de ID do experimento na seção de script e defina-a como fan.
      OBSERVAÇÃO: Este valor deve corresponder exatamente ao campo Nome do experimento do ventilador na Configuração RIP. As configurações de ID do experimento e a lógica compartilhada de geração de interface baseada em metadados para os arquivos XHTML da interface frontal são mostradas em Figura 5.
   4. Verifique se a página obtém a origem de acesso atual por meio de window.location.origin e solicita metadados do experimento por meio de rip.info(), e passa os metadados retornados para autobuildUI().
      OBSERVAÇÃO: A página não deve codificar manualmente os nomes das variáveis do ventilador, intervalos ou tamanhos de passo. Em vez disso, as variáveis graváveis são geradas a partir de meta.writables.lista, variáveis legíveis são geradas a partir de meta.readables.lista, e atributos numéricos como min, max e step são obtidos a partir dos metadados retornados pelo Servidor RIP.
   5. Salvar Fan_Automatic_UI.xhtml.
      ​OBSERVAÇÃO: Para utilizar a mesma lógica de geração de interface para outro VI do LabVIEW, defina um novo ID de experimento no arquivo XHTML e registre o nome do experimento correspondente e o caminho do VI na Configuração do RIP. Os controles da web e as exibições de saída são gerados de acordo com os metadados retornados pelo experimento selecionado.
4. Configure o caminho de acesso do Caddy para o experimento do ventilador.
   1. Abra o arquivo Caddyfile com um editor de texto.
   2. Defina o diretório raiz do front-end como o diretório Client que contém o arquivo Fan_Automatic_UI.xhtml.
   3. Selecione uma porta local não utilizada para o Caddy fornecer acesso pelo navegador à página da Web e às rotas RIP. Neste protocolo, a porta 8090 é usada como exemplo de porta de acesso por proxy.
      OBSERVAÇÃO: A porta 8090 não é necessária pelo RIP ou pelo Caddy. Se a porta 8090 estiver ocupada, substitua-a por outra porta local não utilizada e utilize a mesma porta no endereço do navegador.
   4. Adicione uma rota que reescreva /fan para Fan_Automatic_UI.xhtml.
   5. Identifique a porta do RIP WebService configurada no LabVIEW. Neste protocolo, http://localhost:8001 é utilizada como o endereço do RIP WebService.
      OBSERVAÇÃO: A porta 8001 é a porta de back-end do WebService LabVIEW/RIP utilizada no ambiente de teste. Ela pode ser alterada na configuração do WebService LabVIEW/RIP. Se uma porta diferente for utilizada, substitua http://localhost:8001 no Caddyfile pelo endereço correspondente do WebService RIP.
   6. Adicione uma regra de proxy reverso que encaminhe as solicitações /RIP/SSE* para o endereço do WebService RIP, como http://localhost:8001.
   7. Adicione uma regra de proxy reverso que encaminhe as solicitações /RIP* para o endereço do WebService RIP, como http://localhost:8001. A configuração do Caddyfile é mostrada em Figura 6.
   8. Abra o Prompt de Comando no Windows. Altere para o diretório local de download ou instalação do Caddy inserindo o seguinte comando:
      cd /d D:\caddy
      OBSERVAÇÃO: Neste protocolo, D:\caddy é o caminho local de download ou instalação do Caddy utilizado no ambiente de teste. Se o Caddy estiver armazenado em outro diretório, substitua D:\caddy pelo caminho local correspondente.
   9. Inicie o Caddy com o Caddyfile especificado inserindo o seguinte comando:
      caddy.exe run --config Caddyfile
   10. Confirme que o Caddy é iniciado sem relatar um erro de configuração. Abra http://localhost:8090/fan em um navegador Web e verifique se a interface Web do ventilador é gerada, conforme mostrado em Figura 7.
       ​OBSERVAÇÃO: Se o navegador retornar um erro 502, confirme se o RIP WebService está em execução, se a porta do RIP WebService no LabVIEW corresponde ao endereço do proxy reverso no Caddyfile e se a porta de acesso do Caddy selecionada não está ocupada.
5. Verifique os resultados operacionais do experimento com o ventilador.
   1. Verifique se a página inicial gera automaticamente o Habilitar, PWM, Carga, Tau, KMaxRPM, e Perturbação controles de entrada
   2. Verifique se a página inicial exibe o SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA e PowerW variáveis de saída
   3. Ajustar PWM e observe se VelocidadeRPM aumenta à medida que PWM aumentos e diminuições conforme PWM diminui.
   4. Ajuste a Carga e observe se SteadyRPM e VelocidadeRPM diminui à medida que a carga aumenta.
   5. Ajuste a perturbação e observe se SpeedRPM, CurrentA, e PowerW mudança em resposta à entrada de perturbação
   6. Verifique se Tempo continua a aumentar, confirmando que o ventilador traseiro VI está funcionando continuamente.

2. Montar e implementar o experimento de controle de posição PID do motor CC

1. Construa o modelo VI de controle de posição PID do motor CC.
   1. Abra o LabVIEW, crie um novo VI e salve o arquivo como Motor.vi. Salve o VI em qualquer diretório que possa ser acessado pelo processo do RIP WebService.
      OBSERVAÇÃO: A pasta Privada é usada apenas como exemplo de diretório e não está codificada no RIP. Insira o caminho real do VI selecionado durante o registro do experimento no RIP.
   2. No Painel Frontal, adicione os controles de entrada para o modelo de controle de posição PID do motor CC. Neste exemplo, nomeie os controles de entrada Ponto de ajuste, Kc, Ti, Td, Perturbação, e Controle de reinicialização. Definir Setpoint, Kc, Ti, Td e Perturbação como controles numéricos DBL e defina o controle Reset como um controle booleano.
      OBSERVAÇÃO: Tabela 1 descreve o significado físico, o papel no modelo e a faixa recomendada das variáveis utilizadas neste exemplo.
   3. Adicione os indicadores de saída para o modelo de controle de posição PID do motor CC. Neste exemplo, nomeie os indicadores de saída Posição, Tensão, Tempo e Velocidade angular medida. Defina todos os indicadores de saída como indicadores DBL. Tabela 1 descreve o significado físico e o papel do modelo dessas variáveis de saída. O Painel Frontal concluído para o motor é mostrado em Figura 8.
      OBSERVAÇÃO: Os nomes e intervalos das variáveis listados em Tabela 1 descrever os dois exemplos implementados neste protocolo. Eles não são requisitos fixos para o fluxo de trabalho de geração automática de interface de usuário baseado em RIP. Quando outro VI do LabVIEW é utilizado, o RIP lê os nomes reais das variáveis, tipos de dados, atributos de entrada/saída e propriedades numéricas disponíveis a partir dos metadados do VI. Portanto, a lógica de geração da interface não precisa ter embutidos os nomes das variáveis, valores máximos, valores mínimos ou tamanhos de passo para cada experimento.
   4. Adicione um Laço Enquanto ao Diagrama de Blocos. Adicione seis Registradores de Deslocamento para armazenar theta, omega, im, e_prev, integ e tempo, e inicialize os seis valores para 0.
   5. Adicione um Nó de Fórmula dentro do Laço Enquanto. De acordo com o diagrama do modelo de controle de posição PID do motor CC mostrado em Figura 9, utilize este Nó de Fórmula como o módulo de cálculo central para o cálculo de erro, controle PID, limitação de tensão, modelo elétrico, modelo mecânico e atualização de posição.
      OBSERVAÇÃO: Os parâmetros internos do motor utilizados neste modelo, como R, L, J, b, Kt, Ke e Vmax, são parâmetros de modelo didático normalizados, e não parâmetros calibrados de um motor físico específico. Eles foram selecionados para produzir uma resposta simulada estável e observável sob o passo de tempo e o limite de tensão escolhidos, de modo que os efeitos de Ponto de ajuste, Kc, Ti, Td e Perturbação pode ser claramente demonstrado durante a operação baseada na web.
   6. Definir sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, perturbação, reset e dt as terminais de entrada do Nó Fórmula. Defina theta_next, omega_next, im_next, e_next, integ_next e tensão como os terminais de saída do Nó Fórmula.
   7. Conecte o Ponto de ajuste controle para o sp terminal de entrada do Nó Fórmula. Conecte Kc, Ti, Td e Perturbação ao Kc, Ti, Td e ddistúrbio iterminais de entrada do Nó Fórmula, respectivamente.
   8. Converter o sinal booleano de controle Reset em um sinal numérico e conectá-lo ao redefinir terminal de entrada do Nó Fórmula. Execute a redefinição do estado quando reiniciar não é igual a 0, e execute o controle PID e a atualização do estado do motor quando redefinir é igual a 0.
   9. Adicione a constante numérica dt e defina seu valor para 0,001 s. Conecte o dt ao dt terminal de entrada do Nó Fórmula e utilize-o para atualização do Tempo.
   10. Defina os parâmetros do modelo interno do motor CC no Nó Fórmula. Veja Tabela Suplementar 2 para o significado físico e o papel do modelo das variáveis do motor.
   11. Insira o código de controle de posição PID do motor CC no Nó Fórmula. Utilize este código para implementar a lógica de reinicialização, cálculo do erro, cálculo do termo integral, cálculo do termo derivativo, controle PID, limitação de tensão, atualização da corrente, atualização da velocidade angular e atualização da posição; consulte os arquivos complementares de código para obter o código completo.
   12. Conectar theta_próximo ao Posição indicador e conectar theta_próximo de volta ao Registrador de Deslocamento à Direita para teta Conectar omega_next ao Indicador de velocidade angular medida, e conectar omega_next de volta ao Registrador de Deslocamento à Direita para ômega
   13. Conecte a voltagem ao indicador de tensão. Conecte im_next, e_next e integ_next voltar aos Registradores de Deslocamento à Direita para im, e_prev, e integ, respectivamente.
   14. Use uma função Adicionar fora do Nó de Fórmula para calcular time_next = time + dt. Conectar próximo_tempo ao Tempo indicador e conectar próximo_tempo de volta ao registrador de deslocamento direito para o tempo.
   15. Adicione uma função Esperar dentro do Laço Enquanto e defina o tempo de espera como 1 ms. Adicione um botão de Parada e conecte-o ao terminal condicional do Laço Enquanto.
   16. Salve o Motor.vi. O Diagrama de Blocos do motor concluído é mostrado em Figura 10.
       PONTO DE PAUSA: Após salvar o VI motor concluído, o fluxo de trabalho pode ser interrompido. Retome posteriormente reabrindo o VI salvo e confirmando se todos os controles, indicadores do Painel Frontal e conexões do Diagrama em Blocos ainda estão presentes.
2. Registre o experimento motor no Servidor RIP.
   1. Abra o RIPWebService.lvproj no LabVIEW Project Explorer.
   2. Abra o Configuration.vi na árvore do projeto e localize a tabela de configuração do experimento.
   3. Adicione uma nova linha de experimento. Defina Nome como Motor. Defina Caminho como o caminho completo do arquivo Motor.vi salvo. Os campos de registro do experimento do motor são mostrados em Figura 11.
   4. Preencha os campos de configuração restantes. Defina Autores como o autor do experimento, Palavras-chave como Motor, Descrição como modelo de controle de posição de motor CC e Frequência de Amostragem como 200.
   5. No menu do LabVIEW, selecione Editar > Tornar os Valores Atuais como Padrão. Salvar Configuração.vi
   6. Reinicie o RIP WebService e confirme que o experimento Motor permanece listado na interface de Configuração após a reinicialização.
      OBSERVAÇÃO: O nome do experimento diferencia maiúsculas de minúsculas. O valor Motor na Configuração do RIP deve corresponder exatamente ao ID do experimento utilizado em Motor_Automatic_UI.xhtml. Para implantar outro VI do LabVIEW com a mesma lógica de geração automática da interface, adicione uma nova entrada de experimento na Configuração do RIP, defina um novo valor para Nome e defina Caminho como o arquivo VI correspondente. Em seguida, utilize o mesmo valor de Nome como ID do experimento no arquivo XHTML. A página frontal não precisa ser reescrita para cada variável.
      ​PONTO DE PAUSA: Após salvar o Configuration.vi e definir os valores atuais como padrão, o fluxo de trabalho pode ser interrompido. Retome posteriormente reiniciando o RIP WebService e confirmando que o experimento Motor ainda está registrado.
3. Prepare a página inicial para o experimento com motor.
   1. Coloque o arquivo Motor_Automatic_UI.xhtml no diretório Client utilizado como diretório raiz da interface frontal.
   2. Abra Motor_Automatic_UI.xhtml com um editor de texto.
   3. Localize a variável de ID do experimento na seção de script e defina-a como Motor. Esse valor deve corresponder exatamente ao campo Nome do experimento de motor na Configuração do RIP. A página inicial do motor utiliza a mesma lógica de geração de interface baseada em metadados apresentada em Figura 5; somente o ID do experimento é alterado para corresponder à entrada Motor na Configuração do RIP.
   4. Verifique se a página contém a lógica de leitura de metadados RIP, a lógica de geração de controle HTML, a função de gravação RIP e a função de atualização de saída.
      OBSERVAÇÃO: A página não deve codificar manualmente os nomes das variáveis do motor, suas faixas ou tamanhos de passo. Essas propriedades são obtidas a partir dos metadados retornados pelo Servidor RIP, seguindo o mecanismo descrito anteriormente de geração de HTML a partir de metadados baseado em RIP.¹¹.
   5. Salvar Motor_Automatic_UI.xhtml.
      ​OBSERVAÇÃO: Para utilizar a mesma lógica de geração de interface para outro VI do LabVIEW, defina um novo ID de experimento no arquivo XHTML e registre o nome do experimento correspondente e o caminho do VI na Configuração do RIP. Os controles da web e as exibições de saída são gerados de acordo com os metadados retornados pelo experimento selecionado.
4. Configure o caminho de acesso do Caddy para o experimento com motor.
   1. Abra o arquivo Caddyfile com um editor de texto.
   2. Defina o diretório raiz do front-end como o diretório Client que contém o arquivo Motor_Automatic_UI.xhtml.
   3. Selecione uma porta local não utilizada para o Caddy fornecer acesso pelo navegador à página da Web e às rotas RIP. Neste protocolo, a porta 8090 é usada como exemplo de porta de acesso por proxy.
      OBSERVAÇÃO: A porta 8090 não é necessária para o RIP ou o Caddy. Se a porta 8090 estiver ocupada, substitua-a por outra porta local não utilizada e utilize a mesma porta no endereço do navegador.
   4. Adicione uma rota que reescreva /motor para Motor_Automatic_UI.xhtml.
   5. Identifique a porta do RIP WebService configurada no LabVIEW. Neste protocolo, http://localhost:8001 é utilizada como o endereço do RIP WebService.
      OBSERVAÇÃO: A porta 8001 é a porta de back-end do WebService LabVIEW/RIP utilizada no ambiente de teste. Ela pode ser alterada na configuração do WebService LabVIEW/RIP. Se uma porta diferente for utilizada, substitua http://localhost:8001 no Caddyfile pelo endereço correspondente do WebService RIP.
   6. Adicione uma regra de proxy reverso que encaminhe as solicitações /RIP/SSE* para o endereço do WebService RIP, como http://localhost:8001.
   7. Adicione uma regra de proxy reverso que encaminhe as solicitações /RIP* para o endereço do WebService RIP, como http://localhost:8001. A configuração do Caddyfile é mostrada na Figura 6.
   8. Abra o Prompt de Comando no Windows. Altere para o diretório local de download ou instalação do Caddy inserindo o seguinte comando:
      cd /d D:\caddy
      OBSERVAÇÃO: Neste protocolo, D:\caddy é o caminho local de download ou instalação do Caddy utilizado no ambiente de teste. Se o Caddy estiver armazenado em outro diretório, substitua D:\caddy pelo caminho local correspondente.
   9. Inicie o Caddy com o Caddyfile especificado inserindo o seguinte comando:
      caddy.exe run --config Caddyfile
   10. Confirme que o Caddy é iniciado sem relatar um erro de configuração. Abra http://localhost:8090/motor em um navegador da Web e verifique se a interface da Web do motor é gerada, conforme mostrado em Figura 12.
       ​OBSERVAÇÃO: Se a página da Web do motor carregar, mas os valores de saída não forem atualizados, confirme se o RIP WebService está em execução, se o VI do motor está sendo executado, se a porta do RIP WebService no LabVIEW corresponde ao endereço do proxy reverso no Caddyfile e se a rota /RIP/SSE* está corretamente encaminhada.
5. Verifique os resultados operacionais do experimento do motor.
   1. Verifique se a página inicial gera automaticamente o Ponto de ajuste, Kc, Ti, Td, Perturbação e Redefinir controles de entrada de controle.
   2. Verifique se a página inicial exibe o Posição, Tensão, Tempo e Velocidade angular medida variáveis de saída
   3. Ajustar Ponto de ajuste e observe se a Posição responde à alteração na posição desejada.
   4. Ajustar Kc, Ti, e Td e observe se Tensão, Posição e Velocidade angular medida mudança
   5. Ajustar a perturbação e observe se a posição, a tensão de controle ou a velocidade angular medida é afetado pelo perturbação entrada.
   6. Clique no controle de reinicialização e observe se Posição, Tensão, Velocidade angular medida, e os estados internos relacionados retornam aos seus estados iniciais de acordo com a lógica de reinicialização.

Resultados

Após concluir o fluxo de trabalho descrito acima, tanto o experimento com ventilador quanto o experimento de controle de posição PID com motor CC podem ser acessados por meio da interface web gerada automaticamente. Um resultado bem-sucedido é indicado por três observações. Primeiro, a página web gera automaticamente controles de entrada e campos de exibição de saída de acordo com os metadados das variáveis retornados pelo RIP Server. Segundo, quando o usuário altera uma variável de entrada na página web, o valor modificado é escrito no VI de back-end do LabVIEW por meio da interface RIP. Terceiro, as variáveis de saída calculadas pelo VI de back-end são retornadas por meio do RIP e atualizadas na página web em tempo real. Para o experimento com ventilador, após inserir http://localhost:8090/fan em um navegador, a página gera automaticamente controles de entrada e campos de saída a partir dos metadados do RIP, conforme mostrado na Figura 7. O lado de entrada inclui Enable, PWM, Load, Tau, KMaxRPM e Disturbance, enquanto o lado de saída exibe SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA e PowerW. Durante o funcionamento normal, TimeS aumenta continuamente, indicando que o VI de back-end fengshan.vi está em execução. Quando PWM é aumentado, SpeedRPM e SteadyRPM aumentam proporcionalmente. Quando Load é aumentado, a velocidade do ventilador diminui porque a carga reduz a velocidade de operação em regime permanente. Quando Disturbance é ajustado, mudanças correspondentes podem ser observadas em SpeedRPM, CurrentA e PowerW. Essas observações confirmam que as entradas do lado web são transmitidas corretamente ao back-end do LabVIEW e que as saídas calculadas são retornadas ao front-end por meio do RIP.

Para o experimento de controle de posição PID do motor CC, após inserir http://localhost:8090/motor em um navegador, a página gera automaticamente os controles e campos de saída correspondentes a partir dos metadados RIP, conforme mostrado na Figura 12. As variáveis de entrada incluem Setpoint, Kc, Ti, Td, Perturbação e controle de Redefinição, e as variáveis de saída incluem Posição, Tensão, Tempo e Velocidade angular medida. Quando o valor de Setpoint é alterado, a Posição responde ao novo valor de referência. Quando os parâmetros PID Kc, Ti e Td são ajustados, a resposta de saída, a tensão de controle e a velocidade angular medida mudam de acordo, indicando que os valores dos parâmetros inseridos na página da Web são corretamente enviados ao modelo de back-end no LabVIEW e participam do cálculo de controle. Quando o controle de redefinição é ativado, as variáveis do modelo retornam aos seus estados iniciais de acordo com a lógica de redefinição.

Os estados de falha e comunicação no lado do navegador são mostrados na Figura 13, Figura 14, Figura 15. A Figura 13 mostra um caso de acesso falho pelo navegador no qual o Caddy não está em execução. O navegador tenta acessar http://localhost:8090/motor, mas exibe uma mensagem ERR_CONNECTION_REFUSED, indicando que o serviço proxy local está indisponível ou não está escutando na porta de acesso selecionada. A Figura 14 mostra uma falha na comunicação RIP POST após o carregamento da página. Nesse caso, o console do navegador relata um erro 502 Bad Gateway para a requisição RIP POST, indicando que a interface frontal alcançou o endereço do proxy, mas a requisição não pôde ser encaminhada com sucesso ou processada pelo back-end do RIP WebService. Em contraste, a Figura 15 mostra um estado normal de comunicação no lado do navegador. As ferramentas de desenvolvedor do navegador mostram o carregamento bem-sucedido da página, requisições RIP POST e uma requisição SSE ativa com expId=fan, indicando que a interface web está se comunicando com o RIP WebService por meio do proxy Caddy e recebendo atualizações em tempo real através do canal SSE.

Juntos, os resultados bem-sucedidos do ventilador e do motor e os resultados dos diagnósticos no lado do navegador demonstram que o mesmo fluxo de trabalho automatizado de geração de interface de usuário baseado em metadados pode ser reproduzido para dois experimentos LabVIEW diferentes. Esses resultados também fornecem critérios observáveis para distinguir comunicação bem-sucedida de falhas representativas de implantação, enquanto os procedimentos correspondentes de solução de problemas são discutidos na seção Discussão.

Figura 1: Estrutura geral do sistema experimental. O sistema é composto pelo VI de back-end do LabVIEW, servidor RIP, proxy Caddy e interface web gerada automaticamente. O VI do LabVIEW fornece as variáveis do modelo, o servidor RIP lê os metadados do VI e os valores das variáveis, o Caddy unifica o caminho de acesso e resolve o acesso entre origens distintas, e a interface web gera os controles automaticamente. O nome e o logotipo do Caddy são mostrados apenas para identificar o componente do servidor/proxy web Caddy utilizado no fluxo de trabalho. Clique aqui para visualizar uma versão maior desta figura.

Figura 2: Painel Frontal do VI do ventilador. O Painel Frontal contém controles de entrada para Enable, PWM, Load, Tau, KMaxRPM e Disturbance e indicadores de saída para SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA e PowerW. Esta captura de tela foi obtida do Painel Frontal do fengshan.vi no LabVIEW 2026 no ambiente experimental local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 3: Diagrama em Blocos do VI do ventilador. O modelo do ventilador é implementado com um Loop While, Registradores de Deslocamento, lógica Enable, um Nó de Fórmula e indicadores de saída. Esta captura de tela foi obtida a partir do Diagrama em Blocos do arquivo fengshan.vi no LabVIEW 2026 no ambiente experimental local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluída. Clique aqui para visualizar uma versão maior desta figura.

Figura 4: Página de configuração do fan.vi. O experimento com ventilador é registrado na Configuração RIP com o nome do experimento "fan", o caminho real do VI, informações de palavras-chave, descrição e frequência de amostragem. Esta captura de tela foi obtida a partir da interface de Configuração RIP utilizada com o LabVIEW 2026 e o RIP WebService no ambiente experimental local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 5: Configurações de ID do experimento e lógica de geração da interface do usuário baseada em metadados nos arquivos de front-end XHTML. As capturas de tela do código XHTML foram obtidas a partir dos arquivos Fan_Automatic_UI.xhtml e Motor_Automatic_UI.xhtml abertos no Visual Studio Code. As páginas do ventilador e do motor utilizam a mesma lógica de leitura de metadados e geração de controles; apenas o ID do experimento é alterado para corresponder ao campo Nome na Configuração RIP. As capturas de tela do código XHTML foram obtidas a partir dos arquivos Fan_Automatic_UI.xhtml e Motor_Automatic_UI.xhtml abertos no Visual Studio Code no ambiente de desenvolvimento local dos autores. Os arquivos de código foram preparados pelos autores para este protocolo. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 6: Configuração do Caddyfile. O Caddyfile define a porta de acesso local do proxy, define o diretório raiz do front-end, reescreve as rotas /fan e /motor para os arquivos XHTML correspondentes e faz proxy reverso das solicitações /RIP/SSE* e /RIP* para a porta do WebService LabVIEW/RIP. A captura de tela da configuração do Caddyfile foi obtida a partir do Caddyfile aberto no Visual Studio Code no ambiente de desenvolvimento local dos autores. O Caddyfile foi preparado pelos autores para configurar o Caddy como servidor Web local e proxy reverso. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 7: Página da interface web do fan.vi. Esta captura de tela da interface web foi obtida a partir da página web do ventilador implantada localmente pelos autores, utilizando o Mozilla Firefox. A página frontal gera automaticamente controles de entrada e exibições de saída com base nos metadados das variáveis retornados pelo Servidor RIP. Esta captura de tela da interface web foi obtida a partir da página web do ventilador implantada localmente pelos autores, utilizando o Mozilla Firefox. Os controles e campos de saída exibidos foram gerados a partir dos metadados RIP no ambiente experimental local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 8: Painel Frontal do VI do motor. O Painel Frontal contém controles para Setpoint, Kc, Ti, Td, Distúrbio e controle de Reinicialização, e indicadores para Posição, Tensão, Tempo e Velocidade angular medida. Esta captura de tela foi obtida a partir do Painel Frontal do Motor.vi no LabVIEW 2026 no ambiente experimental local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluída. Clique aqui para visualizar uma versão maior desta figura.

Figura 9: Diagrama do modelo de controle de posição PID para motor CC. O diagrama mostra o caminho do sinal desde o erro do ponto de ajuste, controle PID, limitação de tensão, superposição de perturbação, dinâmica elétrica, dinâmica mecânica e atualização da posição até a realimentação. Clique aqui para visualizar uma versão maior desta figura.

Figura 10: Diagrama em Blocos do VI do motor. O modelo do motor é implementado com um Loop While, Registradores de Deslocamento, um Nó de Fórmula, lógica de temporização e indicadores de saída. Esta captura de tela foi obtida a partir do Diagrama em Blocos do Motor.vi no LabVIEW 2026 no ambiente experimental local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 11: Página de configuração do Motor.vi. O experimento de motor é registrado na Configuração RIP com o nome do experimento Motor, o caminho real do VI, informações de palavras-chave, descrição e frequência de amostragem. Esta captura de tela foi obtida da interface de Configuração RIP utilizada com o LabVIEW 2026 e o RIP WebService no ambiente experimental local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluída. Clique aqui para visualizar uma versão maior desta figura.

Figura 12: Página da interface web do Motor.vi. A página frontal gera automaticamente controles de entrada e exibições de saída para o experimento de controle de posição PID do motor CC. Esta captura de tela da interface web foi obtida a partir da página web do motor implantada localmente pelos autores, utilizando o Mozilla Firefox. Os controles e campos de saída exibidos foram gerados a partir dos metadados RIP no ambiente experimental local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 13: Acesso falho pelo navegador quando o Caddy não está em execução. Quando o Caddy não é iniciado, o endereço local encaminhado http://localhost:8090/motor não pode ser acessado, e o navegador exibe uma mensagem ERR_CONNECTION_REFUSED. Esse sintoma de falha indica que o serviço de proxy local Caddy está indisponível ou não está escutando na porta de acesso selecionada. Esta captura de tela do navegador foi obtida usando o Mozilla Firefox no ambiente de testes locais dos autores e mostra o estado de acesso falho quando o proxy local Caddy não estava em execução. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 14: Falha na comunicação RIP POST após o carregamento da página. O console do navegador exibe um erro 502 Bad Gateway para a solicitação RIP POST. Esse resultado indica que a página da web alcançou o endereço do proxy Caddy, mas a solicitação não pode ser encaminhada com sucesso ou processada pelo back-end do WebService RIP. Esta captura de tela do console do navegador foi obtida usando as Ferramentas de Desenvolvedor do Mozilla Firefox no ambiente de implantação local dos autores e mostra uma falha de comunicação RIP POST 502 Bad Gateway. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 15: Status da comunicação no lado do navegador durante operação normal. As ferramentas de desenvolvedor do navegador mostram carregamento bem-sucedido da página, requisições POST RIP e uma requisição SSE ativa com expId=fan. Essas requisições indicam que a interface web está se comunicando com o WebService RIP por meio do proxy Caddy e recebendo atualizações em tempo real através do canal SSE. Esta captura de tela das ferramentas de desenvolvedor do navegador foi obtida usando o Mozilla Firefox no ambiente de implantação local dos autores e mostra comunicação POST RIP e SSE normal. Nenhum dado de usuário de terceiros ou informação confidencial está incluída. Clique aqui para visualizar uma versão maior desta figura.

Figura 16: Observação representativa única do console do navegador e recursos no nível de processo para o experimento com ventilador. A captura de tela foi registrada durante um teste local do experimento com ventilador. O console mostra o tempo de solicitação/resposta de metadados, contagem de variáveis de metadados, tempo de geração da interface baseada em metadados, tempo de abertura da conexão SSE e dados SSE recebidos. A visualização do gerenciador de tarefas mostra os valores de CPU e memória no nível de processo para os processos do navegador e do LabVIEW no momento da captura. Esses valores são observações descritivas desse teste individual e não correspondem a medições de desempenho replicadas ou a uma referência estatística. Esta captura de tela foi obtida usando as Ferramentas de Desenvolvedor do Mozilla Firefox e o Gerenciador de Tarefas do Windows no ambiente de testes local dos autores. O Mozilla Firefox foi utilizado para registrar a saída do console do navegador, e o Gerenciador de Tarefas do Windows foi usado para observar o uso de CPU e memória pelos processos do navegador e do LabVIEW. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Figura 17: Acesso simultâneo à mesma página da Web baseada em RIP a partir de um navegador de desktop e um navegador móvel. A página do experimento com o ventilador é aberta simultaneamente em dispositivos PC e móveis, e ambos os clientes exibem os controles e variáveis de saída gerados automaticamente. A página da Web no desktop foi acessada usando o Mozilla Firefox, e a página da Web móvel foi acessada usando um navegador móvel no mesmo ambiente de rede local. As capturas de tela foram obtidas no ambiente de testes local dos autores. Nenhum dado de usuário de terceiros ou informação confidencial está incluído. Clique aqui para visualizar uma versão maior desta figura.

Nome da variável	Tipo de dado	Entrada/Saída	Significado físico	Papel no modelo			Intervalo/Configuração
Enable	Booleano	Entrada	Interruptor de funcionamento do ventilador	Controla se o modelo recebe a entrada PWM. Quando Verdadeiro, u = PWM; quando Falso, u = 0.			Verdadeiro / Falso
PWM	DBL	Entrada	Entrada de acionamento	Determina a intensidade básica do acionamento do ventilador e é a entrada principal usada para calcular a velocidade em regime permanente SteadyRPM.			0-1, passo 0,01
Load	DBL	Entrada	Coeficiente de carga	Descreve o efeito atenuante da carga sobre a velocidade em regime permanente. À medida que Load aumenta, a velocidade em regime permanente diminui.			0-1, passo 0,01
Tau	DBL	Entrada	Constante de tempo de resposta	Determina com que rapidez a velocidade do ventilador se aproxima da velocidade em regime permanente a partir do estado anterior.			0,1-5, passo 0,1
KMaxRPM	DBL	Entrada	Velocidade máxima	Define a velocidade máxima permitida pelo modelo e é usada para limitação e normalização da velocidade.			500-6000, passo 100
Disturbance	DBL	Entrada	Entrada de perturbação	Representa o efeito de perturbação externa ou flutuação de carga sobre a velocidade em regime permanente, corrente e potência.			0-1, passo 0,1
SpeedRPM	DBL	Saída	Velocidade real	Representa a velocidade de saída atual do ventilador e é atualizada por meio de dinâmica inercial de primeira ordem.			Calculado pelo modelo
SteadyRPM	DBL	Saída	Velocidade em regime permanente	Representa a velocidade teórica em regime permanente sob as condições de entrada atuais.			Calculado pelo modelo
TimeS	DBL	Saída	Tempo de execução	Representa o tempo contínuo de execução do modelo.			Calculado pelo modelo
SpeedNorm	DBL	Saída	Velocidade normalizada	Representa a razão entre SpeedRPM e KMaxRPM.			0-1 ou calculado pelo modelo
CurrentA	DBL	Saída	Corrente	Representa a corrente estimada do modelo, que varia com a entrada de acionamento e a entrada de perturbação.			Calculado pelo modelo
PowerW	DBL	Saída	Potência	Representa a potência estimada do modelo, calculada a partir da constante de tensão e da corrente.			Calculado pelo modelo
Setpoint	DBL	Entrada	Posição desejada	Define a posição que o motor deve atingir e forma o erro e com a posição real Position.			-3-3, passo 0,1
Kc	DBL	Entrada	Ganho proporcional	Ajusta a intensidade da resposta do Controlador PID ao erro.			0-10, passo 0,1
Ti	DBL	Entrada	Tempo integral	Ajusta a ação integral do Controlador PID e é usado para reduzir o erro em regime permanente.			0-10, passo 0,1
Td	DBL	Entrada	Tempo derivativo	Ajusta a ação derivativa do Controlador PID e é usado para suprimir mudanças excessivamente rápidas do erro e melhorar a resposta dinâmica.			0-5, passo 0,1
Disturbance	DBL	Entrada	Entrada de perturbação	Representa uma perturbação externa superposta à entrada do motor, atuando no modelo do motor juntamente com a tensão de controle.			0-10, passo 0,1
Reset control	Booleano	Entrada	Controle de reinicialização	Aciona a limpeza do estado do modelo, fazendo com que posição, velocidade angular, corrente, erro e termo integral retornem aos seus estados iniciais.			Verdadeiro / Falso
Position	DBL	Saída	Posição real	Representa a posição angular atual do motor e serve como variável de realimentação para o controle PID.			Calculado pelo modelo
Voltage	DBL	Saída	Tensão de controle	Representa a saída do Controlador PID após limitação de tensão e atua na entrada do motor.			Calculado pelo modelo; limitado a -24 a 24 V
Time	DBL	Saída	Tempo de execução	Representa o tempo contínuo de execução do modelo do motor.			Calculado pelo modelo
Measured angular velocity	DBL	Saída	Velocidade angular medida	Representa a velocidade angular atual do motor e é a saída de estado mecânico do motor.			Calculado pelo modelo

Tabela 1: Variáveis de entrada e saída utilizadas nos exemplos de ventilador e motor CC. A tabela lista o nome de cada variável, tipo de dado, função de entrada/saída, significado físico, faixa recomendada e tamanho do passo.

Parâmetro	Valor	Significado físico	Papel no modelo
R	1	Resistência do armadura	Representa o termo de resistência no circuito do armadura do motor e determina a queda de tensão R × im na equação da corrente.
L	0,5	Indutância do armadura	Representa a indutância do circuito do armadura e determina a taxa de variação da corrente. Um valor maior de L produz uma resposta de corrente mais lenta.
J	0,01	Momento de inércia	Representa a resistência do rotor do motor às mudanças na aceleração angular e determina a rapidez com que a velocidade angular varia.
b	0,1	Coeficiente de amortecimento viscoso	Representa o amortecimento mecânico e descreve o torque de amortecimento que dificulta o aumento da velocidade angular durante a rotação.
Kt	0,01	Constante de torque	Representa o coeficiente de proporcionalidade que converte a corrente do armadura em torque eletromagnético.
Ke	0,01	Constante de força eletromotriz contrária	Representa o coeficiente de proporcionalidade pelo qual a velocidade angular gera a força eletromotriz contrária e descreve o efeito de realimentação da velocidade sobre a corrente.
Vmax	24	Tensão máxima de controle	Representa o limite da tensão de saída do controlador e mantém a tensão dentro da faixa de -24 V a 24 V.
dt	0,001	Passo de simulação discreto	Representa o intervalo de tempo para cada atualização de estado baseada em laço e é usado para atualizar corrente, velocidade angular, posição e tempo de execução.

Tabela 2: Parâmetros internos utilizados no modelo de controle de posição PID do motor CC. A tabela lista os parâmetros elétricos e mecânicos, símbolos, valores numéricos, unidades e funções no modelo.

Arquivos de Código Suplementares: Arquivos completos de código-fonte e configuração para reproduzir os exemplos com ventilador e motor CC. Os arquivos de código suplementares incluem o código do Nó de Fórmula do LabVIEW, a configuração do proxy reverso Caddy, os arquivos XHTML da interface frontal e os arquivos-fonte VI do LabVIEW utilizados neste protocolo. O arquivo Código no Nó de Fórmula do LabVIEW.docx contém o código do Nó de Fórmula para os modelos de controle de posição PID do ventilador e do motor CC. O arquivo Caddyfile.txt contém a configuração local do servidor Web e do proxy reverso. Os arquivos Fan_Automatic_UI.xhtml e Motor_Automatic_UI.xhtml contêm a lógica da interface frontal baseada em metadados. Os arquivos fengshan.vi e Motor.vi são os arquivos VI de back-end do LabVIEW para os experimentos com ventilador e motor.Clique aqui para baixar este arquivo.

Discussão

Uma etapa crítica neste protocolo é a construção padronizada e o registro do VI de back-end no LabVIEW. Os controles e indicadores do Painel Frontal devem utilizar nomes de variáveis claros e exclusivos, e seus tipos de dados devem corresponder às variáveis esperadas pelo cálculo do modelo e pelo processo de leitura/escrita do RIP. Nos dois exemplos utilizados neste protocolo, variáveis numéricas escalares são definidas como controles ou indicadores DBL, e variáveis booleanas são definidas como controles booleanos. O Diagrama de Blocos também deve manter a atualização contínua de estado por meio do Laço While, Registradores de Deslocamento e Nó de Fórmula, de modo que variáveis como velocidade do ventilador, posição do motor, velocidade angular do motor, tensão e tempo possam ser atualizadas durante a execução. Após a construção do VI, o Nome do experimento na Configuração do RIP deve corresponder exatamente ao ID do experimento usado no arquivo XHTML correspondente, e o Caminho do VI deve apontar para o VI salvo. Essas configurações são importantes porque a interface web não codifica rigidamente as variáveis de cada experimento. Em vez disso, depende dos metadados retornados pelo Servidor RIP para identificar variáveis graváveis, variáveis legíveis, tipos de dados e propriedades numéricas^10,11.

Os principais problemas de solução de problemas estão relacionados à consistência entre o ID do experimento em XHTML, a Configuração do RIP, o WebService do RIP e as configurações do proxy Caddy. Se o ID do experimento no arquivo XHTML não corresponder ao Nome do experimento na Configuração do RIP, a página da Web não poderá solicitar os metadados corretos e, portanto, não poderá gerar os controles e campos de saída esperados. Se o Caminho do VI estiver incorreto ou o WebService do RIP não estiver iniciado, a página da Web poderá abrir, mas não conseguirá se comunicar com o back-end do LabVIEW. Se o Caddy não estiver em execução, o navegador não poderá acessar o endereço de proxy local selecionado e poderá exibir uma mensagem ERR_CONNECTION_REFUSED, conforme mostrado na Figura 13. Se o Caddy estiver em execução, mas o destino do proxy reverso não corresponder à porta do WebService do RIP, a página poderá carregar, enquanto as requisições POST do RIP falham com um erro 502 Bad Gateway, conforme mostrado na Figura 14. Se a rota /RIP/SSE* não estiver funcionando corretamente, a página poderá abrir e exibir os controles, mas os valores de saída não serão atualizados em tempo real. Em funcionamento normal, as ferramentas de desenvolvedor do navegador devem mostrar o carregamento bem-sucedido da página, requisições POST do RIP e uma requisição SSE ativa com o ID do experimento correto, conforme mostrado na Figura 15. Portanto, a solução de problemas deve começar verificando o ID do experimento, o Caminho do VI, o status do WebService do RIP, o status de execução do Caddy, as portas do proxy e a rota SSE. Se a comunicação ainda apresentar comportamento anormal, reiniciar tanto o WebService do RIP quanto o Caddy, limpar o cache do navegador ou repetir o teste em outro navegador pode ajudar a distinguir comportamentos específicos do navegador de problemas de configuração do RIP/Caddy.

O presente protocolo é reproduzível nos dois exemplos porque o mesmo fluxo de trabalho de criação, registro, implantação e verificação é aplicado tanto a um modelo de velocidade de ventilador quanto a um modelo de controle de posição PID de motor CC. Para reduzir a dependência de toolbox especializadas, os VIs de back-end são reconstruídos utilizando estruturas básicas do LabVIEW, incluindo controles e indicadores do Painel Frontal, Laços While, Registradores de Deslocamento, Nós de Fórmula e variáveis numéricas escalares e booleanas padrão. Contudo, a reprodutibilidade entre versões do LabVIEW, instalações do Windows e ambientes de rede local ainda depende de detalhes de configuração, como caminhos de arquivos, permissões de acesso, portas locais, comandos de inicialização de serviços e comportamento do navegador. O fluxo de trabalho também pode ser estendido a experimentos remotos relacionados a hardware, mas o método não deve ser interpretado como reconhecimento direto de hardware no lado da Web. A interface Web identifica os controles e indicadores do Painel Frontal do LabVIEW por meio dos metadados RIP. Portanto, sensores, atuadores, instrumentos ou dispositivos de controle de processo devem primeiro ser conectados e processados no VI de back-end do LabVIEW por meio de drivers de hardware apropriados, módulos de aquisição de dados, módulos de controle de instrumentos ou outros mecanismos de adaptação de hardware. Após as medições de hardware e os comandos de controle serem mapeados para indicadores e controles do Painel Frontal, a interface Web baseada em RIP pode reconhecer essas variáveis da mesma forma que reconhece as variáveis de simulação utilizadas neste protocolo. Estudos anteriores sobre laboratórios remotos baseados no LabVIEW demonstraram que o LabVIEW pode ser usado como ambiente de back-end para experimentos remotos de engenharia de controle, experimentos robóticos, bancadas de controle de processo, aquisição de dados de sensores e interação com dispositivos físicos^{9,12,17,18,19,20}.

Figura 16 apresenta um exemplo representativo único de implementação registrado durante um experimento local com ventilador. O código front-end foi instrumentado para registrar o tempo de requisição/resposta de metadados, contagem de variáveis de metadados, tempo de geração da interface de usuário (UI) baseada em metadados, tempo de abertura da conexão SSE e dados SSE recebidos. Neste exemplo, o console do navegador registrou um tempo de requisição/resposta de metadados de 68,00 ms, identificou 7 variáveis graváveis e 7 variáveis legíveis nos metadados RIP, gerou os elementos correspondentes da interface em 2,00 ms e abriu a conexão SSE em 16,00 ms. As entradas repetidas de dados SSE mostraram que variáveis de saída, como SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA e PowerW, foram continuamente recebidas do back-end LabVIEW. A visualização do gerenciador de tarefas no mesmo estado do teste local mostrou aproximadamente 1,5% de uso da CPU e 391,7 MB de memória para o processo do Firefox, enquanto o processo LabVIEW mostrou 0% de uso da CPU e 9,2 MB de memória no momento da captura. Essas observações fornecem evidências básicas de que a recuperação de metadados, a geração de interface baseada em metadados, a comunicação RIP/SSE e a sobrecarga da CPU em nível de processo podem ser observadas no ambiente de implantação local. No entanto, esses dados destinam-se à verificação em nível de implementação, e não como uma avaliação abrangente de desempenho. Uma avaliação sistemática de desempenho sob diferentes navegadores, ensaios repetidos, cargas maiores de variáveis, hardware físico e múltiplos usuários simultâneos permanece necessária em trabalhos futuros.

Este método também possui limitações, especialmente quando é estendido a estruturas de dados complexas, experimentos com hardware e operação multiusuário. O fluxo de trabalho atual é mais adequado para variáveis numéricas escalares e de entrada/saída booleanas. Ele não fornece suporte completo automaticamente para arrays complexos, clusters, estruturas de dados aninhadas, relações entre gráficos ou visualizações específicas de domínio. Esses casos podem exigir regras adicionais de mapeamento de metadados ou componentes front-end escritos manualmente. A interface gerada automaticamente pode criar controles e exibições básicos a partir dos metadados das variáveis, mas não consegue inferir completamente a relação física entre as variáveis, selecionar a visualização mais apropriada ou projetar interações de segurança específicas para o experimento. Quando o fluxo de trabalho é estendido a equipamentos reais, são necessárias considerações adicionais, incluindo drivers de hardware, calibração de dispositivos, limitações de amostragem, limites de atuadores, lógica de parada de emergência, autenticação e mecanismos de controle de escrita multiusuário. A implantação atual também pode ser acessada por múltiplos dispositivos cliente por meio de navegadores web padrão no mesmo ambiente de rede local. Conforme mostrado em Figura 17, a mesma página do experimento com ventilador foi aberta simultaneamente em um navegador de desktop e em um navegador móvel, e ambos os clientes exibiram os controles gerados automaticamente e as variáveis de saída correspondentes. Essa observação indica acesso básico simultâneo para múltiplos clientes visualizarem e interagirem com a mesma página do experimento. No entanto, isso não deve ser interpretado como uma estrutura completa de controle multiusuário, pois a implementação atual não inclui autenticação dedicada de usuários, bloqueio de controle, arbitragem de escrita simultânea, filas de escrita ou mecanismos de resolução de conflitos. Essas limitações são consistentes com estudos anteriores de laboratórios remotos, nos quais laboratórios remotos complexos ou colaborativos geralmente exigem projeto de interface específico para o experimento, mecanismos de sincronização, restrições de segurança e lógica de gerenciamento de usuários^{13,14,15,16,17}.

O valor metodológico deste protocolo não reside na introdução de uma nova arquitetura RIP nem na extensão dos tipos de dados suportados pelo RIP. Em vez disso, seu valor está em fornecer um caminho de implementação completo e reprodutível para aplicar um mecanismo estabelecido de geração automática de interface de usuário baseado em RIP a diferentes sistemas LabVIEW. Em comparação com a escrita de uma interface Web personalizada para cada experimento, este fluxo de trabalho reduz a implementação repetida de estruturas básicas de controle, vinculação de variáveis e lógica de comunicação de leitura/escrita quando a VI de back-end expõe variáveis compatíveis^8,9,10,11. O protocolo é, portanto, útil para a educação em engenharia, desenvolvimento de laboratórios remotos e implantação rápida de simulações ou experimentos didáticos de baixo risco que exijam ajuste de parâmetros baseado em navegador e monitoramento em tempo real do estado. Trabalhos futuros devem estender o fluxo de trabalho para estruturas de dados mais complexas, dispositivos experimentais físicos, controle formal de acesso multiusuário e avaliação quantitativa de desempenho, incluindo tempo de geração da interface, latência de comunicação, estabilidade de sincronização, carga do servidor, sobrecarga da CPU e usabilidade do front-end.

Materiais

Lista de materiais utilizados neste artigo

Nome	Empresa	Número de catálogo	Comentários
Servidor Proxy Caddy	Caddy	N/A	Proxy reverso usado para servir a interface web e encaminhar as solicitações /RIP ao RIP WebService
Caddyfile	Preparado pelos autores	N/A	Define rotas de arquivos estáticos e rotas de proxy reverso para a comunicação RIP
Fan_Automatic_UI.xhtml	Preparado pelos autores	N/A	Interface web baseada em metadados para o experimento do ventilador
LabVIEW	National Instruments	2026	Software usado para construir e executar os arquivos fengshan.vi e Motor.vi
Sistema operacional Microsoft Windows	Microsoft	Win11	Sistema operacional usado para executar o LabVIEW, o RIP WebService, o Caddy e o navegador.
Motor_Automatic_UI.xhtml	Preparado pelos autores	N/A	Interface web baseada em metadados para o experimento do motor
Navegador Mozilla Firefox para desktop	Mozilla	2026	Navegador desktop usado para acesso à interface web, ferramentas de desenvolvedor, observações de tempo e recursos, e capturas de tela da Rede/Console.
RIP WebService	UNEDLabs	https://github.com/Nebulous-Systems/rip-server_labview	Recebe solicitações POST RIP e fornece a camada de comunicação WebService utilizada pela interface frontal do navegador.
Gerenciador de Tarefas do Windows	Microsoft	Incorporado ao Windows	Usado para registrar observações de CPU e memória em nível de processo para os processos do navegador e do LabVIEW.