本研究では、リモート相互運用プロトコル(RIP)に基づく自動Webユーザーインターフェース生成を、ファンモデルと直流モーター位置制御モデルという2つの異なるLabVIEWシステムを用いて検証し、これら両方の例における構築、登録、展開、およびテストのための再現可能な手順を提供します。
本研究では、リモート相互運用プロトコル(RIP)に基づく自動Webユーザーインターフェース生成を、ファンモデルと直流モーター位置制御モデルという2つの異なるLabVIEWシステムを用いて検証し、これら両方の例における構築、登録、展開、およびテストのための再現可能な手順を提供します。
リモート実験プラットフォームにより、ネットワーク経由でローカルのシミュレーションモデルや物理デバイスへのアクセスが可能になりますが、従来のWebフロントエンドでは、通常、実験ごとに個別のページ、コントロールレイアウト、およびデータ通信ロジックが必要となり、開発コストが増大します。本研究では、リモート相互運用プロトコル(RIP)を用いてLabVIEWバーチャルインストゥルメント(VI)からWebユーザーインターフェース(UI)を自動生成するための確立されたワークフローを検証し、その実装のための再現可能なプロトコルを提供します。このワークフローでは、フロントパネル上の入力コントロールと出力インジケータを定義するLabVIEW VIを構築し、各VIをRIPサーバー構成に登録して、得られた変数メタデータを読み取り、対応するWebコントロールと出力表示を生成します。フロントエンドの静的ファイルパスとRIPアプリケーションプログラミングインターフェース(API)リクエストパスを統合するために、リバースプロキシとしてCaddyを使用します。このワークフローは、ファン速度モデルと直流(DC)モータの比例・積分・微分(PID)位置制御モデルという2つの異なるシステムで評価されました。どちらの場合においても、Webページは公開された変数を特定し、ユーザー入力をLabVIEWバックエンドに書き込み、モデル出力を読み取り、RIPメタデータからインターフェースを生成します。これらの結果により、2つの異なる動的システムにおいて同一のUI自動生成プロセスが有効であることが検証され、それを再現するために必要な手順が文書化されました。
遠隔実験、オンライン教育、およびモノのインターネット(IoT)技術の発展に伴い、ローカルなシミュレーションモデルや実験装置へのWebベースのアクセスを提供することが、実験プラットフォーム開発における重要な方向性となっています1,2,3,4。近年の研究では、IoTを導入した研究室をプロジェクトベース学習(PBL)やローカルおよびリモートアクセスとさらに統合させており、工学教育における柔軟でネットワーク化された実験プラットフォームの継続的な発展が示されています5。制御システム実験において、ユーザーは通常、ブラウザで入力パラメータを調整し、出力状態をリアルタイムで観察する必要があります6,7。従来の手法では、通常、個々の実験対象に対して個別のWebページ、制御バインドロジック、およびデータ通信インターフェースが必要でした8,9。バックエンドモデルの変数が変更されると、フロントエンドのページもそれに応じて修正しなければならないことが多く、これが大幅な重複開発作業を生み出し、実験プラットフォームの迅速な拡張を制限しています。
Remote interoperability protocol (RIP)は、バックエンドの実験モデルとWebフロントエンドの間にミドルウェア層を提供します10,11。先行研究で述べられているRIPベースの自動UI生成アプローチでは、RIPサーバーが各実験のメタデータ(変数名、入出力属性、データ型、最小値、最大値、精度、説明、および利用可能なリード/ライトメソッドを含む)を提供します11。Webクライアントは、ページの読み込み時または更新時に、このメタデータを用いてラベル、数値入力フィールド、スライダー、Booleanコントロール、出力ディスプレイなどの対応するHTML要素を作成できます11。本プロトコルでは、RIP仕様の再実装や再定義は行いません。その代わりに、既存のオープンソースRIPサービスおよびRIPベースのメタデータからHTML UIへの生成ロジックを通信とインターフェース生成の基盤として利用し、2つのLabVIEW VI例の再現可能な構築、登録、プロキシ展開、および検証に焦点を当てます。
従来のカスタムWebインターフェース開発と比較して、RIPベースの自動UI生成は、複数のLabVIEW実験で同様のスカラー入出力変数が公開されている場合、コントロールレイアウト、変数バインディングロジック、および基本的な通信機能の実装の必要性を低減します8,9,10,11。新しいVIが登録され、その変数がRIPサーバーで利用可能になると、同一のメタデータ読み取りおよびコントロール生成ロジックを再利用して、基本的なWebインターフェースを構築できます10,11。この機能は、迅速な展開、教育用デモンストレーション、および複数の類似した実験への一貫したアクセスを必要とするリモートラボプラットフォームに有用です3,8,9。しかし、自動生成されたインターフェースには制限もあります。変数間の物理的な関係を完全に推論したり、チャートのマッピングを自動的に決定したり、ドメイン固有の可視化や安全に関するインタラクションを設計したりすることはできません11。したがって、実験に高度にカスタマイズされたグラフィックス、複雑なユーザーワークフロー、高度な可視化、ハードウェアの安全インターロック、またはマルチユーザーの書き込み調停が必要な場合は、引き続き手動でのWebインターフェース開発が推奨されます。
プロトコルの全体的なワークフローを図1にまとめます。このワークフローでは、まずLabVIEW VIを用いて、フロントパネル上の必要な入力コントロールと出力インジケータを定義します。次に、実験名とVIパスを指定して、RIPサーバー構成にVIを登録します。登録後、RIPサーバーは選択した実験のメタデータを読み取り、利用可能な変数への読み取り/書き込みアクセスを提供します。XHTMLウェブページは、返されたメタデータを使用して対応する入力コントロールと出力ディスプレイを自動的に生成し、Caddyが静的ウェブページとRIP通信ルートへの統合されたアクセスパスを提供します。本研究では、同じワークフローの2つの実装例として、ファンと直流モーターのモデルを使用しています。互換性のあるスカラー変数、数値変数、およびブール変数を提供する他のLabVIEW実験についても、開発者は同様の「構築-登録-展開-検証」のワークフローに従うことで、自動生成されたウェブインターフェースを作成でき、必要に応じて実験固有の可視化、安全ロジック、または複雑なデータ処理を追加することが可能です。
本記事では、新しいRIPアーキテクチャを提案したり、RIPで既にサポートされているデータ型の範囲を拡張したりするものではありません。その代わりに、確立された通信およびメタデータに基づくUI生成メカニズムとしてRIPを利用し、再現可能な実装プロトコルを文書化しながら、2つの異なるLabVIEWシステムで同一のプロセスを検証することに焦点を当てています。先行研究では、RIPメタデータに基づくWeb UI自動生成の基本手法が提示され、オンラインサーボモータ実験がケーススタディとして用いられました11。また、インタラクティブなインターフェースとエンジニアリングソフトウェアおよびLabVIEWを組み合わせた、Web対応のリモートラボラトリーアーキテクチャについても、以前の研究で報告されています9,12。しかし、実際に再現を試みたところ、元のケースにおける一部のLabVIEWモデルがソフトウェアのバージョンやモジュールの互換性の影響を受けており、新しい環境で直接使用することが困難であることが分かりました。したがって、本研究では、互換性のある2つのバックエンドVI(ファンモデルと直流(DC)モータの比例積分微分(PID)位置制御モデル)を再構築し、両方に同一のメタデータ駆動型UI生成プロセスを適用します。本研究の貢献は、RIPの汎用性を拡張することではなく、確立されたRIPワークフローのクロスシステム検証と、そのプロセスを再現するための詳細なプロトコルの提供にあります。
本プロトコルの想定利用者は、すでにLabVIEW VIを使用しており、モデルごとに個別にカスタムフロントエンドを完全に実装することなく、Webブラウザを通じてシミュレーションモデルや低リスクの実験システムを公開する必要がある研究者、指導者、およびラボ開発者です。本プロトコルは、標準的な数値変数やブーリアン変数、パラメータ調整、およびリアルタイムの状態監視を使用する実験に特に適しています10,11。一方で、複雑なデータ構造、特殊な可視化、厳格なハードウェア安全インターロック、またはマルチユーザーによる書き込み調停を必要とする実験に対する単独のソリューションとしては不向きです11。本研究の目的は、2つの異なるLabVIEWシステムを用いてRIPベースの自動Web UI生成を検証し、バックエンドVIの構築からブラウザベースのインタラクションに至るまでの完全で再現可能なプロトコルを提供することです。本プロトコルには、入出力変数の定義、RIPサーバーへの実験登録、メタデータに基づくUI生成、Caddyプロキシの展開、およびリモート読み書きの検証が含まれます。ファンおよびDCモーターモデルに同一のワークフローを適用することで、例ごとにWebフロントエンドを完全に手動で書き直すことなく、確立されたプロセスを再現できることが実証されます9,10,11。
図1にまとめられたワークフローに従い、以下の手順で2つのRIPアクセス可能なLabVIEW実験の構築、登録、デプロイ、および検証を行います。本研究で使用したすべてのツールとプラットフォームは、材料表に記載されています。
1. ファンモデル実験の構築と展開
2. DCモータPID位置制御実験の構築と展開
上述のワークフローを完了すると、ファン実験とDCモーターPID位置制御実験の両方に、自動生成されたWebフロントエンドを通じてアクセスできるようになります。成功した結果は、3つの観察事項によって示されます。第一に、Webページに、RIPサーバーから返された変数メタデータに基づいた入力コントロールと出力表示フィールドが自動的に生成されることです。第二に、ユーザーがWebページ上の入力変数を変更すると、修正された値がRIPインターフェースを介してLabVIEWバックエンドVIに書き込まれることです。第三に、バックエンドVIで計算された出力変数がRIPを通じて返され、Webページ上でリアルタイムに更新されることです。ファン実験では、ブラウザで http://localhost:8090/fan にアクセスすると、Figure 7 に示すように、RIPメタデータから入力コントロールと出力フィールドが自動的に生成されます。入力側には Enable, PWM, Load, Tau, KMaxRPM, および Disturbanceが含まれ、出力側には SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA, および PowerW が表示されます。正常な動作中、TimeS は継続的に増加し、これはバックエンドの fengshan.vi が実行されていることを示しています。PWM を上げると、それに伴いSpeedRPM とSteadyRPM が増加します。Loadを上げると、load によって定常動作速度が低下するため、ファン速度が低下します。Disturbanceを調整すると、SpeedRPM, CurrentA, および PowerW に対応する変化が観察されます。これらの観察結果は、Web側の入力がLabVIEWバックエンドに正しく送信され、計算された出力がRIPを通じてフロントエンドに返されていることを裏付けています。
DCモータのPID位置制御実験では、ブラウザでhttp://localhost:8090/motorを入力すると、図に示すように、RIPメタデータから対応する制御項目および出力フィールドがページ上に自動的に生成されます。 図12入力変数には以下が含まれます。 設定値、比例ゲイン(Kc)、積分時間(Ti)、微分時間(Td)、外乱、および リセット 制御し、出力変数には以下が含まれる。 位置、電圧、時間、 および 測定された角速度y. 時 設定値 変更されます。 配置 新しい目標値に反応します。PIDパラメータが Kc, Ti, および Td 調整される、出力応答、コントロール 電圧、および 測定された角速度 適切に変更し、ウェブページに入力されたパラメータ値がLabVIEWバックエンドモデルに正しく書き込まれ、制御計算に組み込まれていることを示します。「Reset control(制御リセット)」が有効になると、リセットロジックに従ってモデル変数が初期状態に戻ります。
ブラウザ側の失敗および通信状態を図 13, 図 14, 図 15に示します。図 13は、Caddyが動作していない場合のブラウザアクセス失敗例を示しています。ブラウザが http://localhost:8090/motor へのアクセスを試みますが、ERR_CONNECTION_REFUSED メッセージが表示されます。これは、ローカルプロキシサービスが利用不可であるか、選択したアクセスポートで待機していないことを示しています。図 14は、ページ読み込み後の RIP POST 通信失敗を示しています。この場合、ブラウザのコンソールに RIP POST リクエストに対する 502 Bad Gateway エラーが報告されており、これはフロントエンドがプロキシアドレスに到達したものの、リクエストが RIP WebService バックエンドに正常に転送されなかったか、処理されなかったことを示しています。対照的に、図 15は正常なブラウザ側の通信状態を示しています。ブラウザの開発者ツールにより、ページの読み込み、RIP POST リクエスト、および expId=fan を持つアクティブな SSE リクエストが成功していることが確認でき、Web フロントエンドが Caddy プロキシを介して RIP WebService と通信し、SSE チャネルを通じてリアルタイムアップデートを受信していることがわかります。
ファンとモーターにおける良好な結果とブラウザ側の診断結果を合わせると、同一のメタデータに基づく自動UI生成ワークフローが、2つの異なるLabVIEW実験において再現可能であることが示されます。また、これらの結果は、通信の成功と代表的な導入失敗を区別するための観察可能な基準を提供しており、対応するトラブルシューティングの手順については「考察(Discussion)」セクションで論じています。

図1実験システムの全体構成本システムは、LabVIEWバックエンドVI、RIPサーバー、Caddyプロキシ、および自動生成されたWeb UIで構成されています。LabVIEW VIがモデル変数を提供し、RIPサーバーがVIのメタデータと変数値を読み取り、Caddyがアクセスパスを統一してクロスオリジンアクセスを解決し、Web UIがコントロールを自動的に生成します。Caddyの名前とロゴは、ワークフローで使用されているCaddy Webサーバー/プロキシコンポーネントを識別するためだけに表示されています。 こちらの図の拡大版を表示するには、ここをクリックしてください。

図 2: ファンVIのフロントパネル。フロントパネルには、Enable、PWM、Load、Tau、KMaxRPMおよびDisturbanceの入力コントロールと、SpeedRPM、SteadyRPM、TimeS, SpeedNorm, CurrentAおよびPowerWの出力インジケーターが含まれています。このスクリーンショットは、著者のローカル実験環境におけるLabVIEW 2026のfengshan.viのフロントパネルからキャプチャされたものです。第三者のユーザーデータや機密情報は含まれていません。こちらのリンクをクリックして、この図の拡大版を表示してください。

図 3: ファンVIのブロックダイアグラム。 ファンモデルは、While Loop、シフトレジスタ、Enableロジック、フォーミュラノード、および出力インジケータを用いて実装されている。このスクリーンショットは、著者の独自のローカル実験環境におけるLabVIEW 2026のfengshan.viのブロックダイアグラムからキャプチャしたものである。第三者のユーザーデータや機密情報は含まれていない。この図の拡大版を表示するには、ここをクリックしてください。

図4fan.viの設定ページ。 ファン実験は、実験名「fan」、実際のVIパス、キーワード情報、説明、およびサンプリング周波数とともに、RIP Configurationに登録されています。このスクリーンショットは、著者らの独自のローカル実験環境で使用されているLabVIEW 2026およびRIP WebServiceを用いたRIP Configurationインターフェースからキャプチャされたものです。第三者のユーザーデータや機密情報は含まれていません。 この図の拡大版を表示するには、ここをクリックしてください。

図5: XHTMLフロントエンドファイルにおける実験ID設定およびメタデータに基づくUI生成ロジック。XHTMLコードのスクリーンショットは、Visual Studio Codeで開いたFan_Automatic_UI.xhtmlおよびMotor_Automatic_UI.xhtmlからキャプチャしたものである。ファンとモーターのページは同一のメタデータ読み取りおよび制御生成ロジックを使用しており、RIP Configurationの対応するNameフィールドに一致するように実験IDのみが変更されている。XHTMLコードのスクリーンショットは、著者自身のローカル開発環境において、Visual Studio Codeで開いたFan_Automatic_UI.xhtmlおよびMotor_Automatic_UI.xhtmlからキャプチャしたものである。コードファイルは、本プロトコルのために著者によって作成された。第三者のユーザーデータや機密情報は含まれていない。この図の拡大版を表示するには、ここをクリックしてください。

図 6: Caddyfileの設定。Caddyfileでは、ローカルプロキシアクセスポートを定義し、フロントエンドのルートディレクトリを設定し、/fanおよび/motorルートを対応するXHTMLファイルに書き換え、/RIP/SSE*および/RIP*のリクエストをLabVIEW/RIP WebServiceポートにリバースプロキシします。Caddyfile構成のスクリーンショットは、著者のローカル開発環境でVisual Studio Codeを用いて開いたCaddyfileからキャプチャしたものです。Caddyfileは、CaddyをローカルWebサーバーおよびリバースプロキシとして構成するために著者によって作成されました。第三者のユーザーデータや機密情報は含まれていません。この図の拡大版を表示するには、ここをクリックしてください。

図7: fan.viのWeb UIページ。このWebインターフェースのスクリーンショットは、Mozilla Firefoxを用いて、著者がローカルに展開したファンのWebページからキャプチャされたものである。フロントエンドページは、RIPサーバーから返された変数メタデータに基づいて、入力コントロールと出力ディスプレイを自動的に生成する。このWebインターフェースのスクリーンショットは、Mozilla Firefoxを用いて、著者がローカルに展開したファンのWebページからキャプチャされたものである。表示されているコントロールおよび出力フィールドは、著者のローカル実験環境におけるRIPメタデータから生成された。第三者のユーザーデータや機密情報は含まれていない。この図の拡大版を表示するには、ここをクリックしてください。

図8モーターVIのフロントパネル。 フロントパネルには、以下のコントロールが配置されています。 設定値, 比例ゲイン, 積分時間, 微分時間, 外乱および リセット 対照、および〜の指標 位置, 電圧, 時間, および 測定された角速度。 このスクリーンショットは、著者自身のローカル実験環境におけるLabVIEW 2026のMotor.viのフロントパネルからキャプチャしたものです。第三者のユーザーデータや機密情報は含まれていません。 この図の拡大版を表示するには、ここをクリックしてください。

図 9: DCモータのPID位置制御モデル図。この図は、設定値誤差、PID制御、電圧制限、外乱の重畳、電気的ダイナミクス、機械的ダイナミクス、そして位置更新からフィードバックに至る信号経路を示している。こちらをクリックして、この図の拡大版を表示してください。

図10: モーターVIのブロックダイアグラム。 モーターモデルは、Whileループ、シフトレジスタ、フォーミュラノード、タイミングロジック、および出力インジケータを用いて実装されています。このスクリーンショットは、著者自身のローカル実験環境におけるLabVIEW 2026のMotor.viのブロックダイアグラムからキャプチャしたものです。第三者のユーザーデータや機密情報は含まれていません。こちらのリンクをクリックして、この図の拡大版を表示してください。

図 11: Motor.vi の構成ページ。モータ実験は、実験名「Motor」、実際のVIパス、キーワード情報、説明、およびサンプリング周波数とともにRIP Configurationに登録されています。このスクリーンショットは、著者のローカル実験環境で使用されたLabVIEW 2026およびRIP WebServiceのRIP Configurationインターフェースからキャプチャしたものです。第三者のユーザーデータや機密情報は含まれていません。この図の拡大版を表示するには、ここをクリックしてください。

図 12: Motor.viのWeb UIページ。フロントエンドページにより、DCモーターPID位置制御実験用の入力コントロールと出力ディスプレイが自動的に生成されます。このWebインターフェースのスクリーンショットは、Mozilla Firefoxを使用して著者がローカルに展開したモーターWebページからキャプチャしたものです。表示されているコントロールおよび出力フィールドは、著者のローカル実験環境におけるRIPメタデータから生成されました。第三者のユーザーデータや機密情報は含まれていません。この図の拡大版を表示するには、ここをクリックしてください。

図13Caddyが動作していない場合のブラウザアクセス失敗Caddyが起動していない場合、プロキシされたローカルアドレス http://localhost:8090/motor にアクセスできず、ブラウザにERR_CONNECTION_REFUSEDメッセージが表示されます。この不具合の症状は、ローカルのCaddyプロキシサービスが利用不可であるか、選択したアクセスポートでリスニングしていないことを示しています。このブラウザのスクリーンショットは、著者らのローカルテスト環境でMozilla Firefoxを使用してキャプチャしたものであり、ローカルのCaddyプロキシが動作していない時のアクセス失敗状態を示しています。第三者のユーザーデータや機密情報は含まれていません。 この図の拡大版を表示するには、ここをクリックしてください。

図 14: ページ読み込み後のRIP POST通信失敗。 ブラウザのコンソールに、RIP POSTリクエストに対する502 Bad Gatewayエラーが表示されています。この結果は、WebページがCaddyプロキシアドレスに到達したものの、リクエストをRIP WebServiceバックエンドに正常に転送できなかったか、あるいは処理できなかったことを示しています。このブラウザコンソールのスクリーンショットは、著者自身のローカル展開環境においてMozilla Firefox Developer Toolsを用いてキャプチャされたものであり、RIP POST 502 Bad Gateway通信失敗を示しています。第三者のユーザーデータや機密情報は含まれていません。こちらのリンクから、この図の拡大版をご覧いただけます。

図15通常動作時におけるブラウザ側の通信状態。 ブラウザの開発者ツールでは、ページの正常な読み込み、RIP POSTリクエスト、およびexpId=fanを含むアクティブなSSEリクエストが示されています。これらのリクエストは、WebフロントエンドがCaddyプロキシを介してRIP WebServiceと通信し、SSEチャネルを通じてリアルタイムアップデートを受信していることを示しています。このブラウザ開発者ツールのスクリーンショットは、著者自身のローカル展開環境においてMozilla Firefoxを使用してキャプチャしたものであり、正常なRIP POSTおよびSSE通信を示しています。第三者のユーザーデータや機密情報は含まれていません。 この図の拡大版を表示するには、ここをクリックしてください。

図 16: ファン実験におけるブラウザコンソールおよびプロセスレベルのリソース監視の代表例。 このスクリーンショットは、ローカルでのファン実験テスト中に記録されたものである。コンソールには、メタデータの要求/応答時間、メタデータの変数カウント、メタデータに基づくUI生成時間、SSE接続の開始時間、および受信したSSEデータが表示されている。タスクマネージャーのビューには、キャプチャ時点におけるブラウザおよびLabVIEWプロセスのプロセスレベルのCPUおよびメモリ値が表示されている。これらの値はこの個別のテストにおける記述的な観察結果であり、再現された性能測定値や統計的なベンチマークではない。このスクリーンショットは、著者らの独自のローカルテスト環境において、Mozilla Firefox Developer ToolsおよびWindowsタスクマネージャーから取得された。ブラウザコンソールの出力を記録するためにMozilla Firefoxが使用され、ブラウザおよびLabVIEWプロセスのCPUおよびメモリ使用量を監視するためにWindowsタスクマネージャーが使用された。第三者のユーザーデータや機密情報は含まれていない。こちらのリンクをクリックして、この図の拡大版を表示してください。

図 17: デスクトップブラウザとモバイルブラウザからの同一のRIPベースのWebページへの同時アクセス。 PCとモバイルデバイスでファンの実験ページを同時に開き、両方のクライアントで自動生成された制御項目と出力変数が表示されている。デスクトップのWebページにはMozilla Firefoxを使用してアクセスし、モバイルのWebページには同一のローカルネットワーク環境内のモバイルブラウザを使用してアクセスした。スクリーンショットは著者自身のローカルテスト環境でキャプチャされたものである。第三者のユーザーデータや機密情報は含まれていない。 この図の拡大版を表示するには、ここをクリックしてください。
| 変数名 | データ型 | 入力/出力 | 物理的意味 | モデルにおける役割 | 範囲/設定 | ||
| 有効にする | ブール値 | 入力 | ファン作動スイッチ | モデルがPWM入力を受け取るかどうかを制御します。Trueの場合、u = PWMとなり、Falseの場合、u = 0となります。 | 正 / 誤 | ||
| パルス幅変調 | DBL | 入力 | ドライブ入力 | 基本的なファン駆動強度を決定し、定常状態の回転数であるSteadyRPMを算出するための主要な入力値として使用されます。 | 0-1、ステップ0.01 | ||
| ロード | DBL | 入力 | 負荷係数 | 負荷が定常速度に及ぼす弱化効果について記述する。負荷が増加すると、定常速度は低下する。 | 0-1、ステップ0.01 | ||
| タウ | DBL | 入力 | 応答時定数 | 前状態から定常速度に達するまでのファン速度の到達速度を決定します。 | 0.1-5、ステップ0.1 | ||
| 最大回転数 | DBL | 入力 | 最大速度 | モデルが許容する最大速度を設定し、速度制限および正規化に使用されます。 | 500-6000、ステップ100 | ||
| 攪乱 | 二重結合(DBL) | 入力 | 外乱入力 | 外部乱れまたは負荷変動が、定常状態の速度、電流、および電力に及ぼす影響を示します。 | 0-1、ステップ0.1 | ||
| 回転速度(RPM) | DBL | 出力 | 実際の速度 | ファンの現在の出力速度を表し、1次慣性系(1次遅れ系)を通じて更新される。 | モデルによって算出 | ||
| 定速RPM | 二重体積結合 (Double Volume Binding) | 出力 | 定常速度 | 現在の入力条件下における理論的な定常状態速度を表します。 | モデルにより算出 | ||
| TimeS | 二重結合(DBL) | 出力 | 実行時間 | モデルの連続実行時間を表します。 | モデルにより算出 | ||
| SpeedNorm | 二重結合(DBL) | 出力 | 正規化速度 | SpeedRPMとKMaxRPMの比を表します。 | 0~1、またはモデルによる算出値 | ||
| CurrentA | DBL | 出力 | 電流 | 駆動入力および外乱入力に応じて変化する、推定モデル電流を表します。 | モデルにより算出 | ||
| PowerW | DBL | 出力 | 検出力 | 電圧定数と電流から算出された、推定モデル電力を表します。 | モデルにより算出 | ||
| 設定値 | DBL | 入力 | 希望職種 | モーターが到達すべき目標位置を設定し、実際の位置(Position)との間に誤差eを形成します。 | -3-3、ステップ 0.1 | ||
| Kc | DBL | 入力 | 比例ゲイン | PIDコントローラの誤差に対する応答強さを調整します。 | 0-10、ステップ0.1 | ||
| チタン | DBL | 翻訳するテキストを入力してください。 | 積分時間 | PIDコントローラの積分動作を調整し、定常偏差を減少させるために使用します。 | 0-10、0.1刻み | ||
| Td | 二重結合ライゲーション | 入力 | 微分時間 | PIDコントローラーの微分動作を調整し、急激すぎる誤差の変化を抑制して動的応答を改善するために使用されます。 | 0-5、ステップ0.1 | ||
| 撹乱 | 二重結合連結(DBL) | 入力 | 外乱入力 | 制御電圧とともにモータモデルに作用し、モータ入力に重畳される外乱を表します。 | 0-10、ステップ0.1 | ||
| リセットコントロール | ブーリアン | 入力 | リセットコントロール | モデルの状態クリアをトリガーし、位置、角速度、電流、誤差、および積分項を初期状態に戻します。 | 正 / 誤 | ||
| 位置 | DBL | 出力 | 実位置 | モーターの現在の角度位置を表し、PID制御のフィードバック変数として機能します。 | モデルにより算出 | ||
| 電圧 | DBL | 出力 | 制御電圧 | 電圧制限後のPIDコントローラー出力を表し、モーター入力に作用します。 | モデルにより算出。-24 Vから24 Vに制限。 | ||
| 時間 | DBL | 出力 | 実行時間 | モーターモデルの連続運転時間を表します。 | モデルにより算出 | ||
| 測定角速度 | 二重結合ライゲーション(DBL) | 出力 | 測定角速度 | モーターの現在の角速度を表しており、モーターの機械的状態出力となります。 | モデルにより算出 | ||
表1:ファンおよびDCモーターの例で使用される入力および出力変数。 この表には、各変数名、データ型、入出力の役割、物理的意味、推奨範囲、およびステップサイズが記載されています。
| パラメータ | 値 | 物理的意味 | モデルにおける役割 | ||
| R | 1 | 電機子抵抗 | モーター電機子回路における抵抗項を表し、電流方程式における電圧降下 R × im を決定します。 | ||
| L | 0.5 | 電機子インダクタンス | 電機子回路のインダクタンスを表し、電流の変化率を決定します。Lが大きいほど、電流応答は遅くなります。 | ||
| J | 0.01 | 慣性モーメント | モーターローターの角加速度の変化に対する抵抗を表し、角速度が変化する速さを決定します。 | ||
| b | 0.1 | 粘性減衰係数 | 機械的減衰を表し、回転中の角速度の増加を妨げる減衰トルクを記述します。 | ||
| Kt | 0.01 | トルク定数 | 電機子電流を電磁トルクに変換する比例係数を表します。 | ||
| Ke | 0.01 | 逆起電力定数 | 角速度によって逆起電力が生成される比例係数を表し、速度が電流に及ぼすフィードバック効果を記述する。 | ||
| 最大反応速度 | 24 | 最大制御電圧 | コントローラの出力電圧の制限を表し、電圧を-24 Vから24 Vの範囲内に維持します。 | ||
| dt | 0.001 | 離散シミュレーションステップ | ループベースの状態更新における各時間間隔を表し、電流、角速度、位置、および動作時間の更新に使用される。 | ||
表2:DCモーターPID位置制御モデルに使用される内部パラメータ。この表は、電気的および機械的パラメータ、記号、数値、単位、およびモデル内での役割を示している。
補足コーディングファイル:ファンおよびDCモーターの例を再現するための完全なソースファイルおよび設定ファイル。補足コーディングファイルには、本プロトコルで使用されるLabVIEW Formula Nodeコード、Caddyリバースプロキシ設定、XHTMLフロントエンドファイル、およびLabVIEW VIソースファイルが含まれています。Code in LabVIEW Formula Node.docxには、ファンおよびDCモーターのPID位置制御モデル用のFormula Nodeコードが含まれています。Caddyfile.txtには、ローカルWebサーバーおよびリバースプロキシの設定が含まれています。Fan_Automatic_UI.xhtmlおよびMotor_Automatic_UI.xhtmlには、メタデータに基づくWebフロントエンドのロジックが含まれています。fengshan.viおよびMotor.viは、ファンおよびモーターの実験に使用されるLabVIEWバックエンドVIファイルです。こちらをクリックしてファイルをダウンロードしてください。
本プロトコルにおける重要なステップは、LabVIEWバックエンドVIの標準化された構築と登録です。フロントパネルのコントロールとインジケータには、明確で固有の変数名を使用する必要があり、そのデータ型はモデル計算およびRIP読み書きプロセスで想定される変数と一致していなければなりません。本プロトコルで使用する2つの例では、スカラー数値変数はDBLコントロールまたはインジケータとして定義され、ブーリアン変数はブーリアンコントロールとして定義されています。また、ブロックダイアグラムでは、Whileループ、シフトレジスタ、およびフォーミュラノードを通じて継続的な状態更新を維持し、実行中にファン速度、モーター位置、モーター角速度、電圧、時間などの変数を更新できるようにする必要があります。VIの構築後、RIP Configurationの実験名(experiment Name)は、対応するXHTMLファイルで使用されている実験IDと正確に一致させる必要があり、VIパス(VI Path)は実際に保存されたVIを指している必要があります。Webフロントエンドは各実験の変数をハードコードせず、代わりにRIPサーバーから返されるメタデータに依存して、書き込み可能な変数、読み取り可能な変数、データ型、および数値プロパティを識別するため、これらの設定は非常に重要です10,11。
主なトラブルシューティングの問題は、XHTMLの実験ID、RIP構成、RIP WebService、およびCaddyプロキシ設定の一貫性に関連しています。XHTMLファイル内の実験IDがRIP構成の実験名と一致しない場合、Webページが正しいメタデータをリクエストできず、その結果、期待されるコントロールや出力フィールドを生成できなくなります。VIパスが正しくないか、RIP WebServiceが起動していない場合、Webページは開く可能性がありますが、LabVIEWバックエンドと通信できません。Caddyが動作していない場合、ブラウザは選択したローカルプロキシアドレスにアクセスできず、図 13に示すようにERR_CONNECTION_REFUSEDメッセージが表示されることがあります。Caddyは動作しているがリバースプロキシのターゲットがRIP WebServiceポートと一致していない場合、ページは読み込まれる可能性がありますが、RIP POSTリクエストが502 Bad Gatewayエラーで失敗し、図 14のように表示されます。/RIP/SSE*ルートが正しく機能していない場合、ページは開きコントロールも表示されますが、出力値がリアルタイムで更新されません。正常な動作状態では、ブラウザの開発者ツールにページの正常な読み込み、RIP POSTリクエスト、および正しい実験IDを持つアクティブなSSEリクエストが表示されるはずであり、これは図 15に示されています。したがって、トラブルシューティングは、実験ID、VIパス、RIP WebServiceのステータス、Caddyの動作ステータス、プロキシポート、およびSSEルートの確認から始める必要があります。それでも通信に異常がある場合は、RIP WebServiceとCaddyの両方を再起動し、ブラウザのキャッシュをクリアするか、別のブラウザでテストを繰り返すことで、ブラウザ固有の動作かRIP/Caddyの構成上の問題かを切り分けることができます。
本プロトコルでは、ファン速度モデルとDCモータPID位置制御モデルの両方に同一の「ビルド・レジスタ・デプロイ・検証」ワークフローを適用しているため、2つの例にわたって再現可能です。特殊なツールボックスへの依存を減らすため、バックエンドVIは、フロントパネルのコントロールとインジケータ、Whileループ、シフトレジスタ、フォーミュラノード、および標準的なスカラー数値変数とブーリアン変数を含む、基本的なLabVIEW構造を用いて再構築されています。ただし、LabVIEWのバージョン、Windowsのインストール状況、およびローカルネットワーク環境における再現性は、依然としてファイルパス、アクセス権限、ローカルポート、サービスの起動コマンド、およびブラウザの動作などの設定詳細に依存します。このワークフローはハードウェアに関連するリモート実験にも拡張可能ですが、本手法をWeb側での直接的なハードウェア認識と解釈すべきではありません。Webフロントエンドは、RIPメタデータを通じてLabVIEWフロントパネルのコントロールとインジケータを識別します。したがって、センサ、アクチュエータ、計測器、またはプロセス制御デバイスは、まず適切なハードウェアドライバ、データ収集モジュール、計測器制御モジュール、またはその他のハードウェア適応メカニズムを介して、LabVIEWバックエンドVIに接続および処理される必要があります。ハードウェアの測定値と制御コマンドがフロントパネルのインジケータおよびコントロールにマッピングされた後、RIPベースのWebフロントエンドは、本プロトコルで使用されるシミュレーション変数と同様に、これらの変数を認識できます。従来のLabVIEWベースのリモートラボラトリ研究により、LabVIEWがリモート制御工学実験、ロボット実験、プロセス制御装置、センサデータ収集、および物理デバイスのインタラクションのためのバックエンド環境として利用可能であることが示されています9,12,17,18,19,20
図 16は、ローカルファン実験中に記録された単一の代表的な実装例を示しています。フロントエンドコードには、メタデータの要求/応答時間、メタデータ変数数、メタデータに基づくUI生成時間、SSE接続の開始時間、および受信したSSEデータを記録するためのインストルメンテーションが施されました。この例では、ブラウザコンソールにメタデータの要求/応答時間として68.00 msが報告され、RIPメタデータから7つの書き込み可能変数と7つの読み取り可能変数が特定され、対応するUI要素が2.00 msで生成され、SSE接続が16.00 msで開始されました。繰り返されるSSEデータエントリにより、SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA、およびPowerWなどの出力変数がLabVIEWバックエンドから継続的に受信されていることが示されました。同じローカルテスト状態のタスクマネージャービューでは、FirefoxプロセスのCPU使用率は約1.5%、メモリは391.7 MBであり、キャプチャ時のLabVIEWプロセスのCPU使用率は0%、メモリは9.2 MBでした。これらの観察結果は、ローカル展開環境において、メタデータの取得、メタデータに基づくUI生成、RIP/SSE通信、およびプロセスレベルのCPUオーバーヘッドが観察可能であるという基本的な根拠を提供するものです。ただし、これらのデータは実装レベルの検証を目的としたものであり、包括的なパフォーマンスベンチマークではありません。異なるブラウザ、反復試行、より多くの変数負荷、物理ハードウェア、および複数の同時ユーザー条件下での体系的なパフォーマンス評価が、今後の課題として引き続き必要です。
本手法には制限もあり、特に複雑なデータ構造、ハードウェア実験、およびマルチユーザー操作に拡張する場合に顕著です。現在のワークフローは、スカラー数値およびBoolean型の入出力変数に最適です。複雑な配列、クラスター、ネストされたデータ構造、チャート間の関係、またはドメイン固有の可視化を自動的に完全にサポートすることはできません。これらのケースでは、追加のメタデータマッピングルールや、手動で記述したフロントエンドコンポーネントが必要になる場合があります。自動生成されたUIは、変数のメタデータから基本的なコントロールと表示を作成できますが、変数間の物理的な関係を完全に推論したり、最も適切な可視化を選択したり、実験固有の安全インタラクションを設計したりすることはできません。ワークフローを実際の装置に拡張する場合、ハードウェアドライバ、デバイスのキャリブレーション、サンプリング制約、アクチュエータの制限、非常停止ロジック、認証、およびマルチユーザー書き込み制御メカニズムを含む追加の検討事項が必要となります。現在のデプロイメントでは、同一のローカルネットワーク環境内にある標準的なWebブラウザを通じて、複数のクライアントデバイスからアクセスすることも可能です。Figure 17に示すように、同一のファン実験ページをデスクトップブラウザとモバイルブラウザで同時に開き、どちらのクライアントでも自動生成されたコントロールと対応する出力変数が表示されました。この観察結果は、同一の実験ページを閲覧し、操作するための基本的な同時マルチクライアントアクセスが可能であることを示しています。しかし、現在の実装には専用のユーザー認証、コントロールロック、並行書き込み調停、書き込みキュー、または競合解決メカニズムが含まれていないため、これを完全なマルチユーザー制御フレームワークと解釈すべきではありません。これらの制限は、複雑または共同的なリモートラボラトリーにおいて、通常、実験固有のインターフェース設計、同期メカニズム、安全制約、およびユーザー管理ロジックが必要とされるという、過去のリモートラボラトリー研究の結果と一致しています13,14,15,16,17
本プロトコルの手法的な価値は、新しいRIPアーキテクチャを導入することや、RIPでサポートされるデータ型を拡張することにあるのではなく、確立されたRIPベースの自動UI生成メカニズムを異なるLabVIEWシステムに適用するための、完全で再現可能な実装パスを提供することにあります。個々の実験に合わせてカスタムWebインターフェースを構築する場合と比較して、バックエンドのVIが互換性のある変数を公開していれば、このワークフローにより、基本的なコントロールレイアウト、変数バインド、および読み書き通信ロジックの重複した実装を削減できます8,9,10,11。したがって、本プロトコルは、工学教育、リモートラボの開発、およびブラウザベースのパラメータ調整とリアルタイムの状態監視を必要とする低リスクのシミュレーションや教育用実験の迅速な展開に有用です。今後の課題としては、このワークフローをより複雑なデータ構造、物理的な実験装置、正式なマルチユーザーアクセス制御、およびインターフェース生成時間、通信レイテンシ、同期安定性、サーバー負荷、CPUオーバーヘッド、フロントエンドのユーザビリティを含む定量的な性能評価へと拡張することが挙げられます。
著者は、言語の推敲のみを目的としてAI支援ツールを使用しました。すべての科学的内容、実験手順、ソフトウェアの実装、図、結果、解釈、および最終的な文言は、著者によって確認、修正、および承認されました。実験データの生成にAIツールは使用されていません。
本研究は、武漢大学の学部生イノベーション育成プログラムの支援を受けて行われました。
| 名前 | 会社 | カタログ番号 | コメント |
|---|---|---|---|
| Caddyプロキシサーバー | Caddy | N/A | Web UIの提供および/RIPリクエストをRIP WebServiceへ転送するために使用されるリバースプロキシ |
| Caddyfile | 著者により作成 | N/A | RIP通信のための静的ファイルルートおよびリバースプロキシルートを定義 |
| Fan_Automatic_UI.xhtml | 著者により作成 | N/A | ファン実験用のメタデータベースWebフロントエンド |
| LabVIEW | National Instruments | 2026 | fengshan.viおよびMotor.viの構築と実行に使用されるソフトウェア |
| Microsoft Windows オペレーティングシステム | Microsoft | Win11 | LabVIEW、RIP WebService、Caddy、およびブラウザを実行するために使用されるオペレーティングシステム |
| Motor_Automatic_UI.xhtml | 著者により作成 | N/A | モーター実験用のメタデータベースWebフロントエンド |
| Mozilla Firefox デスクトップブラウザ | Mozilla | 2026 | Web UIへのアクセス、デベロッパーツール、タイミング/リソースの観察、およびネットワーク/コンソールのスクリーンショットに使用されるデスクトップブラウザ |
| RIP WebService | UNEDLabs | https://github.com/Nebulous-Systems/rip-server_labview | RIP POSTリクエストを受信し、ブラウザフロントエンドで使用されるWebService通信レイヤーを提供 |
| Windowsタスクマネージャー | Microsoft | Windowsに組み込み | ブラウザおよびLabVIEWプロセスのプロセスレベルのCPUおよびメモリの観察を記録するために使用 |
この記事は公開されました
動画は近日公開