Protokół automatycznego generowania interfejsów internetowych dla aplikacji LabVIEW z wykorzystaniem protokołu zdalnej interoperacyjności

Podsumowanie

Niniejsze badanie waliduje automatyczne generowanie interfejsu użytkownika w sieci w oparciu o protokół zdalnej interoperacyjności (RIP) z wykorzystaniem dwóch odrębnych systemów LabVIEW — modelu wentylatora oraz modelu sterowania pozycją silnika prądu stałego — i dostarcza odtwarzalną procedurę konstruowania, rejestrowania, wdrażania i testowania obu przykładów.

Streszczenie

Zdalne platformy eksperymentalne umożliwiają dostęp do lokalnych modeli symulacyjnych lub urządzeń fizycznych poprzez sieć, jednak konwencjonalne interfejsy WWW zazwyczaj wymagają osobnej strony, układu sterowania i logiki komunikacji danych dla każdego eksperymentu, co zwiększa koszty rozwoju. Niniejsza praca waliduje ustanowiony schemat automatycznego generowania interfejsu użytkownika (UI) WWW z wirtualnych instrumentów (VI) LabVIEW przy użyciu protokołu zdalnej interoperacyjności (RIP) i dostarcza odtwarzalny protokół jego implementacji. Schemat ten polega na budowie instrumentów LabVIEW VI, które definiują sterowniki wejściowe i wskaźniki wyjściowe na panelu przednim (Front Panel), rejestracji każdego VI w konfiguracji serwera RIP, odczycie wynikowych metadanych zmiennych oraz generowaniu odpowiadających im sterowników i wyświetlaczy wyjściowych w wersji WWW. Caddy jest wykorzystywany jako odwrotny proxy w celu ujednolicenia ścieżki do statycznych plików front-endu oraz ścieżki zapytań do interfejsu programistycznego (API) RIP. Schemat został oceniony na dwóch różnych systemach: modelu prędkości wentylatora oraz modelu proporcjonalno-całkująco-różniczkowego (PID) sterowania pozycją silnika prądu stałego (DC). W obu przypadkach strona WWW identyfikuje udostępnione zmienne, zapisuje dane wejściowe użytkownika w backendzie LabVIEW, odczytuje wyjścia modelu i generuje interfejs na podstawie metadanych RIP. Wyniki te potwierdzają poprawność tego samego procesu automatycznego generowania UI w dwóch różnych systemach dynamicznych i dokumentują kroki niezbędne do jego odtworzenia.

Wprowadzenie

Wraz z rozwojem zdalnych eksperymentów, nauczania online oraz technologii Internetu Rzeczy, zapewnienie dostępu przez sieć do lokalnych modeli symulacyjnych lub urządzeń doświadczalnych stało się ważnym kierunkiem rozwoju platform eksperymentalnych^1,2,3,4. Niedawne prace doprowadziły do dalszej integracji laboratoriów wyposażonych w Internet Rzeczy z nauczaniem opartym na projektach oraz dostępem lokalnym lub zdalnym, co dowodzi ciągłego rozwoju elastycznych i sieciowych platform eksperymentalnych w edukacji inżynieryjnej⁵. W przypadku eksperymentów z systemami sterowania użytkownicy zazwyczaj muszą dostosowywać parametry wejściowe w przeglądarce i obserwować stany wyjściowe w czasie rzeczywistym^6,7. Konwencjonalne metody zazwyczaj wymagają oddzielnej strony internetowej, logiki wiązania sterowania i interfejsu komunikacji danych dla każdego obiektu eksperymentalnego^8,9. Gdy zmieniają się zmienne w modelu zaplecza (back-end), strona front-end często musi zostać odpowiednio zmodyfikowana, co powoduje znaczny powtarzalny nakład pracy programistycznej i ogranicza szybką rozbudowę platformy eksperymentalnej.

Protokół zdalnej interoperacyjności (Remote interoperability protocol, RIP) zapewnia warstwę pośrednią (middleware) pomiędzy eksperymentalnymi modelami backendowymi a front-endami WWW^10,11. W podejściu do automatycznego generowania interfejsu użytkownika (UI) w oparciu o RIP, opisanym w poprzednich pracach, serwer RIP dostarcza metadane dla każdego eksperymentu, obejmujące nazwy zmiennych, atrybuty wejścia/wyjścia, typy danych, wartości minimalne i maksymalne, precyzję, opisy oraz dostępne metody odczytu i zapisu¹¹. Klient WWW może następnie wykorzystać te metadane do utworzenia odpowiadających im elementów HTML, takich jak etykiety, numeryczne pola wprowadzania, suwaki, przełączniki logiczne oraz wyświetlacze wyjściowe, podczas ładowania lub odświeżania strony¹¹. Niniejszy protokół nie implementuje ponownie ani nie redefiniuje specyfikacji RIP. Zamiast tego wykorzystuje istniejącą usługę RIP o otwartym kodzie źródłowym oraz logikę generowania UI HTML na podstawie metadanych RIP jako fundament do komunikacji i generowania interfejsów, skupiając się na powtarzalnej konstrukcji, rejestracji, wdrożeniu proxy i weryfikacji dwóch przykładów VI w środowisku LabVIEW.

W porównaniu z konwencjonalnym tworzeniem niestandardowych interfejsów WWW, automatyczne generowanie interfejsu użytkownika (UI) w oparciu o RIP ogranicza konieczność implementowania układów sterowania, logiki wiązania zmiennych oraz podstawowych funkcji komunikacyjnych w sytuacjach, gdy wiele eksperymentów w LabVIEW wykorzystuje porównywalne skalarne zmienne wejściowe i wyjściowe^8,9,10,11. Po zarejestrowaniu nowego VI i udostępnieniu jego zmiennych serwerowi RIP, ta sama logika odczytywania metadanych i generowania elementów sterujących może zostać ponownie wykorzystana do budowy podstawowego interfejsu WWW^10,11. Funkcja ta jest przydatna przy szybkim wdrażaniu, pokazach dydaktycznych oraz w platformach laboratoriów zdalnych, które wymagają spójnego dostępu do kilku podobnych eksperymentów^3,8,9. Jednak automatycznie generowany interfejs posiada również ograniczenia. Nie wnioskuje on w pełni o relacjach fizycznych między zmiennymi, nie określa automatycznie mapowań wykresów ani nie projektuje specyficznych dla danej dziedziny wizualizacji i interakcji bezpieczeństwa¹¹. Dlatego ręczne tworzenie interfejsu WWW pozostaje preferowane, gdy eksperyment wymaga wysoce spersonalizowanej grafiki, złożonych przepływów pracy użytkownika, zaawansowanej wizualizacji, sprzętowych blokad bezpieczeństwa lub arbitrażu zapisu dla wielu użytkowników.

Ogólny schemat procedury przedstawiono na Rysunku 1. W tym schemacie instrument wirtualny (VI) LabVIEW definiuje najpierw wymagane sterowniki wejściowe i wskaźniki wyjściowe na Panelu Przednim. Następnie VI jest rejestrowany w Konfiguracji Serwera RIP poprzez określenie nazwy eksperymentu i ścieżki do VI. Po rejestracji Serwer RIP odczytuje metadane wybranego eksperymentu i zapewnia dostęp do odczytu/zapisu dla dostępnych zmiennych. Strona internetowa XHTML wykorzystuje zwrócone metadane do automatycznego generowania odpowiednich sterowników wejściowych i wyświetlaczy wyjściowych, natomiast Caddy zapewnia ujednoliconą ścieżkę dostępu dla statycznej strony internetowej oraz tras komunikacyjnych RIP. Modele wentylatora i silnika prądu stałego zostały wykorzystane w niniejszej pracy jako dwie implementacje tego samego schematu działań. W przypadku innych eksperymentów w LabVIEW, które dostarczają kompatybilne zmienne skalarne, numeryczne i booleowskie, programiści mogą stosować ten sam schemat budowania-rejestracji-wdrażania-weryfikacji w celu stworzenia automatycznie generowanego interfejsu internetowego, dodając przy tym specyficzną dla danego eksperymentu wizualizację, logikę bezpieczeństwa lub złożoną obsługę danych, jeśli jest to wymagane.

Niniejszy artykuł nie proponuje nowej architektury RIP ani nie rozszerza zakresu typów danych obsługiwanych już przez RIP. Zamiast tego wykorzystuje RIP jako uznany mechanizm komunikacji i generowania interfejsu użytkownika (UI) w oparciu o metadane, koncentrując się na walidacji tego procesu w dwóch różnych systemach LabVIEW przy jednoczesnym udokumentowaniu odtwarzalnego protokołu implementacji. Wcześniejsze prace przedstawiły podstawową metodę automatycznego generowania interfejsu Web UI na podstawie metadanych RIP, wykorzystując w ramach studium przypadku eksperyment z serwomotorem online¹¹. W poprzednich badaniach opisano również architektury zdalnych laboratoriów z dostępem przez sieć WWW, łączące interaktywne interfejsy z oprogramowaniem inżynieryjnym i LabVIEW^9,12. Jednak podczas praktycznej reprodukcji niektóre modele LabVIEW w pierwotnym przypadku badawczym były obarczone problemami związanymi z wersją oprogramowania i kompatybilnością modułów, co utrudniało ich bezpośrednie zastosowanie w nowszym środowisku. Niniejsza praca rekonstruuje zatem dwa kompatybilne instrumenty wirtualne (VI) back-endu — model wentylatora oraz model sterowania położeniem silnika prądu stałego (DC) za pomocą regulatora proporcjonalno-całkująco-różniczkującego (PID) — i stosuje ten sam proces generowania UI sterowany metadanymi w obu przypadkach. Wkładem pracy jest walidacja uznanego przepływu pracy RIP w różnych systemach oraz szczegółowy protokół reprodukcji tego procesu, a nie rozszerzenie ogólności RIP.

Zamierzonymi użytkownikami niniejszego protokołu są badacze, instruktorzy i twórcy systemów laboratoryjnych, którzy korzystają już z VI LabVIEW i potrzebują udostępnić modele symulacyjne lub niskoryzykowe systemy eksperymentalne za pośrednictwem przeglądarki internetowej, bez konieczności niezależnego wdrażania pełnego, niestandardowego interfejsu front-end dla każdego modelu. Protokół jest szczególnie odpowiedni dla eksperymentów wykorzystujących standardowe zmienne numeryczne i logiczne, regulację parametrów oraz monitorowanie stanu w czasie rzeczywistym^10,11. Jest on mniej odpowiedni jako samodzielne rozwiązanie dla eksperymentów wymagających złożonych struktur danych, specjalistycznej wizualizacji, rygorystycznych blokad bezpieczeństwa sprzętowego lub arbitrażu zapisu wieloużytkownikowego¹¹. Celem niniejszej pracy jest walidacja automatycznego generowania interfejsu Web w oparciu o RIP przy użyciu dwóch różnych systemów LabVIEW oraz dostarczenie kompletnego, reprodukowalnego protokołu – od konstrukcji VI back-end po interakcję w przeglądarce. Protokół obejmuje definicję zmiennych wejściowych i wyjściowych, rejestrację eksperymentu w serwerze RIP, generowanie interfejsu użytkownika na podstawie metadanych, wdrożenie serwera proxy Caddy oraz weryfikację zdalnego odczytu i zapisu. Zastosowanie tego samego przepływu pracy dla modeli wentylatora i silnika DC wykazuje, że ustalony proces może zostać zreprodukowany bez konieczności ręcznego przepisywania pełnego front-endu Web dla każdego przykładu^9,10,11.

Protokół

Wykonaj następujące kroki, aby zbudować, zarejestrować, wdrożyć i zweryfikować dwa eksperymenty LabVIEW dostępne przez RIP, zgodnie z przebiegiem prac przedstawionym na Rysunku 1. Wszystkie narzędzia i platformy wykorzystane w tej procedurze są wymienione w Tabeli materiałów.

1. Budowa i uruchomienie eksperymentu z modelem wentylatora

1. Zbuduj model wentylatora VI.
   1. Uruchom program LabVIEW, utwórz nowy program VI i zapisz plik jako fengshan.vi. Zapisz program VI w dowolnym katalogu dostępnym dla procesu RIP WebService. Folder Private służy jedynie jako katalog przykładowy i nie jest na stałe wpisany w kod RIP. Podczas rejestracji eksperymentu w RIP podaj faktyczną ścieżkę do wybranego programu VI.
   2. Na panelu przednim dodaj sterowniki wejściowe dla modelu wentylatora. W tym przykładzie nazwij sterowniki wejściowe Włącz, PWM (modulacja szerokości impulsu), Obciążenie, Tau, Maksymalna prędkość obrotowa (KMaxRPM), i ZaburzenieUstawić Włącz jako kontrolę logiczną (Boolean) oraz ustawić PWM, obciążenie, tau, KMaxRPMi Zaburzenie jako numeryczne elementy sterujące typu double-precision floating-point (DBL). Patrz Tabela uzupełniająca 1 dotyczące fizycznego znaczenia i roli modelowej zmiennych wentylatora.
   3. Dodaj wskaźniki wyjściowe dla modelu wentylatora. W tym przykładzie nazwij wskaźniki wyjściowe PrędkośćRPM, StałaPrędkośćRPM, CzasS, PrędkośćZnormalizowana, PrądA, i PowerWUstaw wszystkie wskaźniki wyjściowe jako wskaźniki DBL.
      ​UWAGA: Tabela 1 opisuje fizyczne znaczenie i rolę w modelu tych zmiennych wyjściowych. Gotowy przedni panel wentylatora przedstawiono na Rycina 2Nazwy zmiennych, zakresy i wielkości kroków przedstawione w Tabela 1 Opisano dwa przykłady zaimplementowane w niniejszym protokole. Nie stanowią one sztywnych wymagań systemu RIP. W przypadku innych eksperymentów w środowisku LabVIEW programiści mogą zdefiniować inne nazwy zmiennych na panelu przednim (Front Panel) oraz inne właściwości numeryczne. Serwer RIP odczytuje rzeczywiste nazwy zmiennych, typy danych, atrybuty wejścia/wyjścia oraz dostępne właściwości numeryczne z metadanych VI, a strona internetowa generuje odpowiadające im elementy sterujące i wyświetlacze na podstawie zwróconych metadanych.
   4. Dodaj pętlę While do diagramu blokowego. Dodaj dwa rejestry przesuwne w celu przechowywania prędkość_poprzednia i czas_poprzednioraz zainicjuj obie wartości do 0.
   5. Dodaj węzeł formuły (Formula Node) wewnątrz pętli While. Połącz Włącz, PWM, Obciążenie, Tau, KMaxRPM, Zakłócenie, prędkość_poprz., i czas_poprzedni do lewych terminali wejściowych węzła Formula Node i ustaw SteadyRPM, speed_next, SpeedNorm, CurrentA, PowerW, i następny czas jako prawostronne terminale wyjściowe.
   6. Zbuduj Włącz logikę sterującą poza węzłem formuły. Użyj Włącz jako sygnał wyboru, tak aby u = PWM kiedy Włącz jest prawdziwe i u = 0 kiedy Włącz jest fałszywe.
   7. Wprowadź kod modelu wentylatora w węźle formuły. Użyj tego kodu do obliczenia prędkości stanu ustalonego, prędkości rzeczywistej, prędkości znormalizowanej, natężenia prądu, mocy oraz czasu pracy; pełny kod znajduje się w Uzupełniającym Pliku Kodowania 1.
   8. Podłącz przyspiesz_dalej wyjście węzła Formula Node do Prędkość RPM wskaźnik i podłączyć przyspieszenie_dalej powrót do prawego rejestru przesuwności dla prędkość_poprzedniaPodłącz StałeRPM do SteadyRPM wskaźnik
   9. Połącz następny_czas do TimeS wskaźnik i podłączyć następny_czas powrót do prawego rejestru przesuwnego dla czas_poprzedniPołącz SpeedNorm, CurrentA, i PowerW do odpowiednich wskaźników wyjściowych.
   10. Dodaj funkcję Wait (oczekiwanie) wewnątrz pętli While i ustaw czas oczekiwania na 50 ms. Dodaj przycisk Stop Local i podłącz go do terminala warunkowego pętli While.
   11. Zapisz plik fengshan.vi. Ukończony schemat blokowy wentylatora przedstawiono na Rycina 3.
       PRZERWA: Po zapisaniu ukończonego VI dla wentylatora pracę można przerwać. Należy ją wznowić później, ponownie otwierając zapisane VI i upewniając się, że wszystkie elementy sterujące, wskaźniki na panelu przednim (Front Panel) oraz połączenia na schemacie blokowym (Block Diagram) są nadal obecne.
2. Zarejestruj eksperyment z wentylatorem w serwerze RIP.
   1. Otwórz plik RIPWebService.lvproj w Eksploratorze Projektów LabVIEW (LabVIEW Project Explorer)
      .
   2. Otwórz plik Configuration.vi z drzewa projektu i zlokalizuj tabelę konfiguracji eksperymentu.
   3. Dodaj nowy wiersz eksperymentu. W polu Name wpisz fan. W polu pełnej ścieżki wskaż zapisaną plik fengshan.vi. Pola rejestracyjne dla eksperymentu fan są przedstawione w Rycina 4.
   4. Uzupełnij pozostałe pola konfiguracji. W polu Authors wpisz autora eksperymentu, w polu Keywords wpisz Fan, w polu Description wpisz fan speed model, a w polu Sampling Freq wpisz 200.
   5. W menu programu LabVIEW wybierz Edytuj > Ustaw aktualne wartości jako domyślneZapiszKonfigurację.vi.
   6. Zrestartuj usługę sieciową (WebService) RIP i potwierdź, że eksperyment z wentylatorem nadal widnieje w interfejsie konfiguracyjnym (Configuration) po ponownym uruchomieniu.
      UWAGA: Nazwa eksperymentu rozróżnia wielkość liter. Wartość fan w konfiguracji RIP (RIP Configuration) musi być dokładnie zgodna z identyfikatorem eksperymentu (experiment ID) użytym w pliku XHTML front-endu. Aby wdrożyć inny instrument LabVIEW VI z tą samą logiką automatycznego generowania interfejsu użytkownika, należy dodać nowy wpis eksperymentu w konfiguracji RIP (RIP Configuration), ustawić nową wartość Name oraz wskazać Path do odpowiedniego pliku VI. Następnie należy użyć tej samej wartości Name jako identyfikatora eksperymentu w pliku XHTML. Strona front-endu nie wymaga ponownego pisania dla każdej zmiennej.
      ​PUNKT ZATRZYMANIA: Po zapisaniu pliku Configuration.vi i ustawieniu aktualnych wartości jako domyślne, można przerwać proces. Należy go wznowić później, restartując RIP WebService i potwierdzając, że eksperyment z wentylatorem jest nadal zarejestrowany.
3. Przygotuj stronę front-endową do eksperymentu z wentylatorem.
   1. Umieść plik Fan_Automatic_UI.xhtml w katalogu Client, który służy jako główny katalog front-endu.
   2. Otwórz plik Fan_Automatic_UI.xhtml za pomocą edytora tekstu.
   3. Zlokalizuj zmienną identyfikatora eksperymentu (experiment ID) w sekcji skryptu i ustaw jej wartość na fan.
      UWAGA: Wartość ta musi być identyczna z wartością w polu Name eksperymentu typu „fan” w konfiguracji RIP (RIP Configuration). Ustawienia identyfikatora eksperymentu oraz wspólna logika generowania interfejsu użytkownika w oparciu o metadane dla plików XHTML front-endu są przedstawione w Rysunek 5.
   4. Upewnij się, że strona pobiera aktualne źródło dostępu za pomocą window.location.origin i przesyła żądanie o metadane eksperymentu poprzez rip.info()i przekazuje zwrócone metadane do autobuildUI().
      UWAGA: Strona nie powinna zawierać ręcznie wpisanych nazw zmiennych wentylatora, zakresów ani wielkości kroków. Zamiast tego zmienne zapisywalne są generowane z lista.zapisywalnych.meta, generowane są czytelne zmienne z lista.czytelnych.meta, a atrybuty numeryczne, takie jak min, max i step, są pobierane z metadanych zwróconych przez serwer RIP.
   5. Zapisz plik Fan_Automatic_UI.xhtml.
      ​UWAGA: Aby zastosować tę samą logikę generowania front-endu dla innego VI w środowisku LabVIEW, należy ustawić nowy identyfikator eksperymentu (experiment ID) w pliku XHTML oraz zarejestrować odpowiadającą mu nazwę eksperymentu (experiment Name) i ścieżkę do VI (VI Path) w konfiguracji RIP. Elementy sterujące stroną internetową oraz wyświetlacze wyjściowe są generowane zgodnie z metadanymi zwróconymi przez wybrany eksperyment.
4. Skonfiguruj ścieżkę dostępu Caddy dla eksperymentu z wentylatorem.
   1. Otwórz plik Caddyfile za pomocą edytora tekstu.
   2. Ustaw główny katalog front-endu na katalog Client zawierający plik Fan_Automatic_UI.xhtml.
   3. Wybierz nieużywany lokalny port dla serwera Caddy, aby umożliwić dostęp przez przeglądarkę do strony internetowej oraz tras RIP. W niniejszym protokole jako przykładowy port dostępu proxy wykorzystano port 8090.
      UWAGA: Port 8090 nie jest wymagany przez RIP ani Caddy. Jeśli port 8090 jest zajęty, należy zastąpić go innym niewykorzystanym portem lokalnym i użyć tego samego portu w adresie przeglądarki.
   4. Dodaj trasę, która przekierowuje /fan na Fan_Automatic_UI.xhtml.
   5. Zidentyfikuj port usługi sieciowej RIP (RIP WebService) skonfigurowany w programie LabVIEW. W niniejszym protokole jako adres usługi sieciowej RIP wykorzystano http://localhost:8001.
      UWAGA: Port 8001 jest portem zaplecza (back-end) usługi LabVIEW/RIP WebService stosowanym w środowisku testowym. Można go zmienić w konfiguracji LabVIEW/RIP WebService. Jeśli używany jest inny port, należy zastąpić adres http://localhost:8001 w pliku Caddyfile odpowiednim adresem usługi RIP WebService.
   6. Dodaj regułę odwrotnego proxy, która przekierowuje żądania /RIP/SSE* pod adres usługi internetowej RIP WebService, na przykład http://localhost:8001.
   7. Dodaj regułę odwrotnego proxy (reverse proxy), która przekierowuje żądania /RIP* na adres usługi sieciowej RIP WebService, na przykład http://localhost:8001. Konfiguracja pliku Caddyfile przedstawiona jest w Rysunek 6.
   8. Otwórz Wiersz poleceń w systemie Windows. Przejdź do lokalnego katalogu pobierania lub instalacji programu Caddy, wpisując następujące polecenie:
      cd /d D:\caddy
      UWAGA: W niniejszym protokole ścieżka D:\caddy jest lokalną ścieżką pobierania lub instalacji programu Caddy wykorzystaną w środowisku testowym. Jeśli program Caddy znajduje się w innym katalogu, należy zastąpić D:\caddy odpowiednią ścieżką lokalną.
   9. Uruchom program Caddy z określonym plikiem Caddyfile, wpisując następującą komendę:
      caddy.exe run --config Caddyfile
   10. Upewnij się, że program Caddy uruchamia się bez zgłaszania błędu konfiguracji. Otwórz adres http://localhost:8090/fan w przeglądarce internetowej i zweryfikuj, czy interfejs użytkownika (Web UI) aplikacji fan został wygenerowany, zgodnie z przedstawionym w Rysunek 7.
       ​UWAGA: Jeśli przeglądarka zwróci błąd 502, należy potwierdzić, że usługa RIP WebService jest uruchomiona, że port usługi RIP WebService w programie LabVIEW jest zgodny z adresem odwrotnego proxy w pliku Caddyfile oraz że wybrany port dostępu Caddy nie jest zajęty.
5. Zweryfikuj wyniki działania eksperymentu z wentylatorem.
   1. Zweryfikuj, czy strona front-end automatycznie generuje Włącz, PWM, obciążenie, tau, maksymalna prędkość obrotowa (KMaxRPM), i Zakłócenie kontrole wejściowe
   2. Zweryfikuj, czy strona front-end wyświetla PrędkośćRPM, StałeRPM, CzasS, PrędkośćNorm, PrądA, i PowerW zmienne wyjściowe
   3. Dostosuj PWM (Modulacja szerokości impulsu) i zaobserwuj, czy Prędkość RPM wraz ze wzrostem Modulacja szerokości impulsu (PWM) rośnie i maleje w miarę jak PWM (modulacja szerokości impulsu) spada.
   4. Dostosuj obciążenie i zaobserwuj, czy SteadyRPM i Prędkość (RPM) spada wraz ze wzrostem obciążenia.
   5. Dostosuj zakłócenie i zaobserwuj, czy PrędkośćRPM, PrądA, i PowerW zmiana w odpowiedzi na sygnał zakłócający.
   6. Zweryfikuj, czy TimeS nadal wzrasta, co potwierdza, że tylny wentylator VI pracuje w trybie ciągłym.

2. Budowa i wdrożenie eksperymentu sterowania położeniem silnika DC za pomocą regulatora PID

1. Zbuduj model VI sterowania położeniem silnika prądu stałego za pomocą regulatora PID.
   1. Uruchom program LabVIEW, utwórz nowy VI i zapisz plik jako Motor.vi. Zapisz VI w dowolnym katalogu, do którego dostęp ma proces RIP WebService.
      UWAGA: Folder Private służy wyłącznie jako przykładowy katalog i nie jest na stałe zaprogramowany w RIP. Podczas rejestracji eksperymentu RIP należy wprowadzić rzeczywistą ścieżkę wybranego VI.
   2. Na panelu przednim (Front Panel) dodaj sterowniki wejściowe dla modelu regulacji pozycji silnika DC za pomocą regulatora PID. W tym przykładzie nazwij sterowniki wejściowe Wartość zadana, Kc, Ti, Td, Zakłócenieoraz Resetowanie kontroliUstawić Wartość zadana, Kc, Ti, Td, i Zakłócenie jako sterowniki numeryczne DBL, a sterownik Reset ustaw jako sterownik typu Boolean.
      UWAGA: Tabela 1 opisuje znaczenie fizyczne, rolę w modelu oraz zalecany zakres zmiennych wykorzystanych w tym przykładzie.
   3. Dodaj wskaźniki wyjściowe dla modelu sterowania pozycją silnika prądu stałego za pomocą regulatora PID. W tym przykładzie nazwij wskaźniki wyjściowe Położenie, Napięcie, Czas, i Zmierzona prędkość kątowaUstaw wszystkie wskaźniki wyjściowe jako wskaźniki DBL. Tabela 1 opisuje znaczenie fizyczne i rolę modelową tych zmiennych wyjściowych. Kompletny panel przedni (Front Panel) dla silnika przedstawiono na Rysunek 8.
      UWAGA: Nazwy zmiennych i zakresy wymienione w Tabela 1 Opisz dwa przykłady zaimplementowane w niniejszym protokole. Nie stanowią one sztywnych wymagań dla przepływu pracy automatycznego generowania interfejsu użytkownika (UI) opartego na RIP. W przypadku użycia innego VI LabVIEW, RIP odczytuje rzeczywiste nazwy zmiennych, typy danych, atrybuty wejścia/wyjścia oraz dostępne właściwości numeryczne z metadanych VI. W związku z tym logika generowania front-endu nie musi zawierać na sztywno zakodowanych nazw zmiennych, wartości maksymalnych, wartości minimalnych ani kroków dla każdego eksperymentu.
   4. Dodaj pętlę While do diagramu blokowego. Dodaj sześć rejestrów przesuwnych w celu przechowywania theta, omega, im, e_prev, integ, i czas, oraz zainicjuj wszystkie sześć wartości do 0.
   5. Dodaj węzeł formuły (Formula Node) wewnątrz pętli While. Zgodnie ze schematem modelu regulacji położenia silnika DC za pomocą regulatora PID przedstawionym w Rysunek 9wykorzystaj ten węzeł formuły (Formula Node) jako główny moduł obliczeniowy do wyznaczania błędów, sterowania PID, ograniczania napięcia, modelu elektrycznego, modelu mechanicznego oraz aktualizacji pozycji.
      UWAGA: Wewnętrzne parametry silnika wykorzystane w tym modelu, takie jak R, L, J, b, Kt, Ke, i Vmax, są znormalizowanymi parametrami modelu dydaktycznego, a nie parametrami skalibrowanymi konkretnego silnika fizycznego. Zostały one dobrane w celu uzyskania stabilnej i możliwej do zaobserwowania odpowiedzi symulacyjnej przy wybranym kroku czasowym i ograniczeniu napięcia, tak aby efekty Wartość zadana, Kc, Ti, Td, i Zaburzenie można wyraźnie zademonstrować podczas pracy w środowisku internetowym.
   6. Zestaw sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, zakłócenie, reset, i dt aterminale wejściowe węzła Formula Node. Ustaw theta_następne, omega_następne, im_następne, e_następne, integ_następne, i napięcie elektryczne jako terminale wyjściowe węzła formuły (Formula Node).
   7. Podłącz Wartość zadana kontrola do Sposób wykonania (sp) wejście węzła formuły (Formula Node). Połącz Kc, Ti, Td, i Zakłócenie do Kc, Ti, Td, oraz dzaburzenie iodpowiednio wejścia węzła Formuła (Formula Node).
   8. Przekonwertuj logiczny sygnał sterujący Reset na sygnał numeryczny i podłącz go do resetuj wejście terminalne węzła Formuła (Formula Node). Wykonaj reset stanu, gdy reset nie jest równe 0, a następnie wykonaj sterowanie PID i aktualizację stanu silnika, gdy resetuj wynosi 0.
   9. Dodaj stałą numeryczną dt or ustaw jego wartość na 0,001 s. Podłącz dt do dt terminal wejściowy węzła Formula Node i wykorzystaj go do aktualizacji czasu.
   10. Ustaw wewnętrzne parametry modelu silnika prądu stałego w węźle Formula Node. Patrz Tabela uzupełniająca 2 dotyczącą znaczenia fizycznego i roli modelowej zmiennych motorycznych.
   11. Wprowadź kod sterowania pozycją silnika DC za pomocą regulatora PID do węzła Formula Node. Użyj tego kodu do implementacji logiki resetowania, obliczania błędu, obliczania składnika całkującego, obliczania składnika różniczkującego, sterowania PID, ograniczania napięcia, aktualizacji prądu, aktualizacji prędkości kątowej oraz aktualizacji pozycji; pełny kod znajduje się w uzupełniających plikach z kodem.
   12. Połącz theta_następny do Położenie wskaźnik oraz połączyć theta_następna powrót do odpowiedniego rejestru przesuwności dla theta Połącz omega_next do Wskaźnik zmierzonej prędkości kątoweji podłączyć omega_next powrót do prawego rejestru przesuwnika dla omega
   13. Podłącz napięcie do wskaźnika napięcia. Podłącz im_następne, e_następne, i integ_next powrót do prawych rejestrów przesuwnych dla im, e_prev, i integ, odpowiednio.
   14. Użyj funkcji Add poza węzłem Formula Node, aby obliczyć time_next = time + dt. Połącz następny_czas do Czas wskaźnik i podłączyć następny czas powrót do prawego rejestru przesuwnika czasu.
   15. Dodaj funkcję Wait wewnątrz pętli While i ustaw czas oczekiwania na 1 ms. Dodaj przycisk Stop i podłącz go do terminala warunkowego pętli While.
   16. Zapisz plik Motor.vi. Ukończony schemat blokowy silnika przedstawiono w Rysunek 10.
       PUNKT ZATRZYMANIA: Po zapisaniu ukończonego instrumentu wirtualnego (VI) silnika można przerwać procedurę. Aby ją wznowić, należy ponownie otworzyć zapisany VI i upewnić się, że wszystkie elementy sterujące, wskaźniki na Panelu Przednim (Front Panel) oraz połączenia na Diagramie Blokowym (Block Diagram) są nadal obecne.
2. Zarejestruj eksperyment motoryczny w serwerze RIP.
   1. Otwórz plik RIPWebService.lvproj w Przeglądarce Projektów LabVIEW (LabVIEW Project Explorer).
   2. Otwórz plik Configuration.vi z drzewa projektu i zlokalizuj tabelę konfiguracji eksperymentu.
   3. Dodaj nowy wiersz eksperymentu. W polu Name wprowadź Motor. W polu Path wprowadź pełną ścieżkę do zapisanego pliku Motor.vi. Pola rejestracji eksperymentu silnika przedstawiono w Rycina 11.
   4. Wypełnij pozostałe pola konfiguracji. W polu Autorzy ustaw autora eksperymentu, w polu Słowa kluczowe wpisz Silnik, w polu Opis wpisz Model sterowania położeniem silnika DC, a w polu Częstotliwość próbkowania wartość 200.
   5. W menu LabVIEW wybierz Edytuj > Ustaw aktualne wartości jako domyślne. Save Configuration.vi.
   6. Zrestartuj usługę sieciową (WebService) RIP i potwierdź, że po ponownym uruchomieniu eksperyment Motor nadal znajduje się na liście w interfejsie konfiguracji.
      UWAGA: Nazwa eksperymentu jest rozróżniana ze względu na wielkość liter. Wartość Motor w konfiguracji RIP (RIP Configuration) musi być dokładnie taka sama, jak identyfikator eksperymentu użyty w pliku Motor_Automatic_UI.xhtml. Aby wdrożyć inny program LabVIEW VI z tą samą logiką automatycznego generowania interfejsu użytkownika, należy dodać nowy wpis eksperymentu w konfiguracji RIP, ustawić nową wartość Name oraz wskazać Path do odpowiedniego pliku VI. Następnie należy użyć tej samej wartości Name jako identyfikatora eksperymentu w pliku XHTML. Strona front-end nie musi być przepisywana dla każdej zmiennej.
      ​MOMENT PRZERWANIA: Po zapisaniu pliku Configuration.vi i ustawieniu aktualnych wartości jako domyślne, można przerwać procedurę. Należy ją wznowić później, restartując RIP WebService i potwierdzając, że eksperyment Motor jest nadal zarejestrowany.
3. Przygotuj stronę główną (front-end) dla eksperymentu motorycznego.
   1. Umieść plik Motor_Automatic_UI.xhtml w katalogu Client, który służy jako główny katalog front-endu.
   2. Otwórz plik Motor_Automatic_UI.xhtml za pomocą edytora tekstu.
   3. Zlokalizuj zmienną identyfikatora eksperymentu (experiment ID) w sekcji skryptu i ustaw jej wartość na Motor. Wartość ta musi być identyczna z polem Name eksperymentu motorowego w konfiguracji RIP (RIP Configuration). Strona front-endowa eksperymentu motorowego wykorzystuje tę samą logikę generowania interfejsu użytkownika w oparciu o metadane, która została przedstawiona w Rysunek 5; zmieniono jedynie identyfikator eksperymentu, aby był zgodny z wpisem Motor w konfiguracji RIP.
   4. Należy sprawdzić, czy strona zawiera logikę odczytu metadanych RIP, logikę generowania elementów sterujących HTML, funkcję zapisu RIP oraz funkcję aktualizacji wyjściowej.
      UWAGA: Strona nie powinna zawierać ręcznie wpisanych nazw zmiennych silnika, zakresów ani wielkości kroków. Właściwości te są pobierane z metadanych zwracanych przez serwer RIP, zgodnie z opisanym wcześniej mechanizmem generowania treści HTML z metadanych w oparciu o RIP¹¹.
   5. Zapisz Motor_Automatic_UI.xhtml.
      ​UWAGA: Aby wykorzystać tę samą logikę generowania front-endu dla innego instrumentu wirtualnego (VI) LabVIEW, należy ustawić nowy identyfikator eksperymentu w pliku XHTML oraz zarejestrować odpowiadającą mu nazwę eksperymentu i ścieżkę do VI w konfiguracji RIP. Elementy sterujące stroną internetową oraz wyświetlacze wyjściowe są generowane zgodnie z metadanymi zwróconymi przez wybrany eksperyment.
4. Skonfiguruj ścieżkę dostępu Caddy dla eksperymentu motorycznego.
   1. Otwórz plik Caddyfile za pomocą edytora tekstu.
   2. Ustaw katalog główny front-endu na katalog Client, który zawiera plik Motor_Automatic_UI.xhtml.
   3. Wybierz niewykorzystany lokalny port dla Caddy, aby zapewnić dostęp przez przeglądarkę do strony internetowej i tras RIP. W niniejszym protokole w przykładzie wykorzystano port 8090 jako port dostępu do serwera proxy.
      UWAGA: Port 8090 nie jest wymagany przez RIP ani Caddy. Jeśli port 8090 jest zajęty, należy zastąpić go innym niewykorzystanym portem lokalnym i użyć tego samego portu w adresie przeglądarki.
   4. Dodaj trasę, która przekierowuje /motor do Motor_Automatic_UI.xhtml.
   5. Zidentyfikuj port usługi sieciowej RIP (RIP WebService) skonfigurowany w programie LabVIEW. W niniejszym protokole jako adres usługi sieciowej RIP wykorzystano http://localhost:8001.
      UWAGA: Port 8001 jest portem zaplecza (back-end) usługi sieciowej LabVIEW/RIP WebService wykorzystywanym w środowisku testowym. Można go zmienić w konfiguracji LabVIEW/RIP WebService. W przypadku użycia innego portu należy zastąpić adres http://localhost:8001 w pliku Caddyfile odpowiednim adresem RIP WebService.
   6. Dodaj regułę odwrotnego proxy (reverse proxy), która przekierowuje żądania /RIP/SSE* na adres usługi internetowej (WebService) RIP, na przykład http://localhost:8001.
   7. Dodaj regułę odwrotnego proxy, która przekierowuje żądania /RIP* do adresu RIP WebService, na przykład http://localhost:8001. Konfiguracja Caddyfile przedstawiona jest na Rysunku 6.
   8. Otwórz Wiersz poleceń w systemie Windows. Przejdź do lokalnego katalogu pobierania lub instalacji programu Caddy, wpisując następujące polecenie:
      cd /d D:\caddy
      UWAGA: W niniejszym protokole ścieżka D:\caddy jest lokalną ścieżką pobierania lub instalacji programu Caddy użytą w środowisku testowym. Jeśli program Caddy znajduje się w innym katalogu, należy zastąpić D:\caddy odpowiednią ścieżką lokalną.
   9. Uruchom Caddy z określonym plikiem Caddyfile, wprowadzając następujące polecenie:
      caddy.exe run --config Caddyfile
   10. Upewnij się, że program Caddy uruchamia się bez zgłaszania błędu konfiguracji. Otwórz adres http://localhost:8090/motor w przeglądarce internetowej i zweryfikuj, czy interfejs użytkownika (Web UI) silnika został wygenerowany, zgodnie z przedstawionym w Rysunek 12.
       ​UWAGA: Jeśli strona internetowa silnika ładuje się, ale wartości wyjściowe nie są aktualizowane, należy potwierdzić, że usługa RIP WebService jest uruchomiona, motor VI jest w trakcie wykonywania, port RIP WebService w programie LabVIEW jest zgodny z adresem odwrotnego proxy w pliku Caddyfile oraz że trasa /RIP/SSE* jest poprawnie przekierowana przez proxy.
5. Zweryfikuj wyniki operacyjne eksperymentu z silnikiem.
   1. Upewnij się, że strona front-end automatycznie generuje Wartość zadana, Kc, Ti, Td, Zakłócenie, i Resetuj kontrola wejść sterujących.
   2. Zweryfikuj, czy strona front-end wyświetla Położenie, Napięcie, Czas, i Zmierzona prędkość kątowa zmienne wyjściowe
   3. Dostosuj Wartość zadana oraz zaobserwuj, czy położenie reaguje na zmianę położenia zadanego.
   4. Dostosuj Kc, Ti, i Td i zaobserwować, czy Napięcie, Pozycja, i Zmierzona prędkość kątowa zmiana
   5. Dostosuj zakłócenie i zaobserwowanie, czy pozycja, napięcie sterujące lub zmierzona prędkość kątowa jest pod wpływem zakłócenie Proszę podać tekst źródłowy do tłumaczenia.
   6. Kliknij Reset control i sprawdź, czy Położenie, Napięcie, Pomierzona prędkość kątowa, a powiązane stany wewnętrzne powracają do swoich stanów początkowych zgodnie z logiką resetowania.

Wyniki

Po zakończeniu opisanego powyżej procesu przepływu pracy, zarówno eksperyment z wentylatorem, jak i eksperyment sterowania położeniem silnika DC za pomocą regulatora PID są dostępne poprzez automatycznie generowany interfejs WWW. O pomyślnym wyniku świadczą trzy obserwacje. Po pierwsze, strona WWW automatycznie generuje elementy sterujące wejściem i pola wyświetlania wyjść zgodnie z metadanymi zmiennych zwróconymi przez serwer RIP. Po drugie, gdy użytkownik zmienia zmienną wejściową na stronie WWW, zmodyfikowana wartość jest zapisywana w programie VI w module back-end LabVIEW poprzez interfejs RIP. Po trzecie, zmienne wyjściowe obliczone przez program VI w module back-end są zwracane przez RIP i odświeżane na stronie WWW w czasie rzeczywistym. W przypadku eksperymentu z wentylatorem, po wpisaniu adresu http://localhost:8090/fan w przeglądarce, strona automatycznie generuje elementy sterujące wejściem i pola wyjściowe na podstawie metadanych RIP, jak pokazano na Rysunku 7. Strona wejściowa obejmuje Enable, PWM, Load, Tau, KMaxRPM, oraz Disturbance, natomiast strona wyjściowa wyświetla SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA, oraz PowerW. Podczas normalnej pracy wartość TimeS zwiększa się w sposób ciągły, co wskazuje, że program back-end fengshan.vi jest wykonywany. Gdy wartość PWM zostaje zwiększona, SpeedRPM oraz SteadyRPM odpowiednio rosną. Gdy zwiększono Load, prędkość wentylatora spada, ponieważ load redukuje stabilną prędkość pracy. Po dostrojeniu Disturbance można zaobserwować odpowiednie zmiany w SpeedRPM, CurrentA, oraz PowerW. Obserwacje te potwierdzają, że wejścia ze strony WWW są prawidłowo przesyłane do modułu back-end LabVIEW, a obliczone wyjścia są zwracane do front-endu za pośrednictwem RIP.

W przypadku eksperymentu dotyczącego regulacji położenia silnika prądu stałego za pomocą regulatora PID, po wprowadzeniu adresu http://localhost:8090/motor w przeglądarce, strona automatycznie generuje odpowiednie elementy sterujące i pola wyjściowe na podstawie metadanych RIP, co przedstawiono na Ryc. 12. Zmienne wejściowe obejmują Setpoint, Kc, Ti, Td, Disturbance oraz sterowanie Reset, a zmienne wyjściowe obejmują Position, Voltage, Time oraz Measured angular velocity. Po zmianie wartości Setpoint, Position reaguje na nową wartość docelową. Po dostrojeniu parametrów PID Kc, Ti oraz Td, odpowiednio zmieniają się odpowiedź wyjściowa, voltage sterowania oraz measured angular velocity, co wskazuje, że wartości parametrów wprowadzone na stronie internetowej są poprawnie zapisywane w modelu zaplecza LabVIEW i biorą udział w obliczeniach sterowania. Po aktywacji sterowania Reset zmienne modelu wracają do swoich stanów początkowych zgodnie z logiką resetowania.

Błędy po stronie przeglądarki oraz stany komunikacji przedstawiono na Rysunku 13, Rysunku 14, Rysunku 15. Rysunek 13 przedstawia przypadek nieudanego dostępu z poziomu przeglądarki, w którym program Caddy nie jest uruchomiony. Przeglądarka próbuje uzyskać dostęp do adresu http://localhost:8090/motor, ale wyświetla komunikat ERR_CONNECTION_REFUSED, co wskazuje, że lokalna usługa proxy jest niedostępna lub nie nasłuchuje na wybranym porcie dostępu. Rysunek 14 pokazuje błąd komunikacji RIP POST po załadowaniu strony. W tym przypadku konsola przeglądarki zgłasza błąd 502 Bad Gateway dla żądania RIP POST, co oznacza, że front-end dotarł do adresu proxy, ale żądanie nie może zostać pomyślnie przekazane do zaplecza RIP WebService lub przez nie przetworzone. W przeciwieństwie do tego, Rysunek 15 przedstawia normalny stan komunikacji po stronie przeglądarki. Narzędzia programistyczne przeglądarki pokazują pomyślne ładowanie strony, żądania RIP POST oraz aktywną żądanie SSE z expId=fan, co wskazuje, że front-end strony internetowej komunikuje się z RIP WebService poprzez proxy Caddy i otrzymuje aktualizacje w czasie rzeczywistym za pośrednictwem kanału SSE.

Łącznie pomyślne wyniki dla wentylatora i silnika oraz wyniki diagnostyki po stronie przeglądarki wykazują, że ten sam przepływ pracy automatycznego generowania interfejsu użytkownika w oparciu o metadane może zostać zreplikowany dla dwóch różnych eksperymentów w LabVIEW. Wyniki te dostarczają również mierzalnych kryteriów pozwalających odróżnić udaną komunikację od reprezentatywnych błędów wdrożenia, natomiast odpowiadające im procedury rozwiązywania problemów zostały omówione w sekcji Dyskusja.

Rysunek 1: Ogólna struktura systemu eksperymentalnego. System składa się z zaplecza w postaci LabVIEW VI, serwera RIP, proxy Caddy oraz automatycznie generowanego interfejsu użytkownika Web UI. LabVIEW VI dostarcza zmienne modelu, serwer RIP odczytuje metadane VI i wartości zmiennych, Caddy ujednolica ścieżkę dostępu i rozwiązuje problem dostępu międzydomenowego, a Web UI automatycznie generuje elementy sterujące. Nazwa i logo Caddy służą wyłącznie do zidentyfikowania komponentu serwera Web/proxy Caddy wykorzystanego w procesie. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rycina 2: Panel przedni instrumentu VI wentylatora. Panel przedni zawiera elementy sterujące wejściem dla Enable, PWM, Load, Tau, KMaxRPM oraz Disturbance a także wskaźniki wyjściowe dla SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA oraz PowerW. Zrzut ekranu został wykonany z panelu przedniego fengshan.vi w programie LabVIEW 2026 w lokalnym środowisku eksperymentalnym autorów. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.

Rysunek 3Schemat blokowy VI wentylatora. Model wentylatora zaimplementowano z wykorzystaniem pętli While oraz rejestrów przesuwnych, Włącz logikę, węzeł formuły (Formula Node) oraz wskaźniki wyjściowe. Zrzut ekranu ten został wykonany z diagramu blokowego pliku fengshan.vi w programie LabVIEW 2026 w lokalnym środowisku eksperymentalnym autorów. Nie zawarto w nim żadnych danych użytkowników stron trzecich ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.

Rycina 4: Strona konfiguracyjna fan.vi. Eksperyment z wentylatorem jest zarejestrowany w RIP Configuration pod nazwą eksperymentu fan, z podaniem rzeczywistej ścieżki VI, informacji słownikowych, opisu oraz częstotliwości próbkowania. Zrzut ekranu został wykonany z interfejsu RIP Configuration używanego z LabVIEW 2026 i RIP WebService w lokalnym środowisku eksperymentalnym autorów. Nie zawarto danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.

Rysunek 5: Ustawienia identyfikatora eksperymentu oraz logika generowania interfejsu użytkownika na podstawie metadanych w plikach front-endu XHTML. Zrzuty ekranu kodu XHTML zostały wykonane z plików Fan_Automatic_UI.xhtml i Motor_Automatic_UI.xhtml otwartych w programie Visual Studio Code. Strony dotyczące wentylatora i silnika wykorzystują tę samą logikę odczytywania metadanych i generowania sterowania; zmieniono jedynie identyfikator eksperymentu, aby odpowiadał odpowiedniemu polu Name w konfiguracji RIP. Zrzuty ekranu kodu XHTML zostały wykonane z plików Fan_Automatic_UI.xhtml i Motor_Automatic_UI.xhtml otwartych w programie Visual Studio Code w lokalnym środowisku programistycznym autorów. Pliki kodu zostały przygotowane przez autorów na potrzeby niniejszego protokołu. Nie zawarto w nich żadnych danych użytkowników stron trzecich ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rycina 6: Konfiguracja Caddyfile. Plik Caddyfile definiuje lokalny port dostępu proxy, ustawia główny katalog front-endu, przekierowuje trasy /fan i /motor do odpowiadających im plików XHTML oraz przesyła zapytania /RIP/SSE* i /RIP* przez odwrotny proxy do portu LabVIEW/RIP WebService. Zrzut ekranu konfiguracji Caddyfile został wykonany z pliku Caddyfile otwartego w Visual Studio Code we własnym lokalnym środowisku programistycznym autorów. Plik Caddyfile został przygotowany przez autorów w celu skonfigurowania Caddy jako lokalnego serwera WWW i odwrotnego proxy. Nie zawarto w nim żadnych danych użytkowników stron trzecich ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.

Rycina 7: Strona interfejsu WWW fan.vi. Ten zrzut ekranu interfejsu WWW został wykonany z lokalnie wdrożonej przez autorów strony internetowej wentylatora przy użyciu przeglądarki Mozilla Firefox. Strona front-end automatycznie generuje elementy sterujące wejściem i wyświetlacze wyjściowe na podstawie metadanych zmiennych zwróconych przez serwer RIP. Ten zrzut ekranu interfejsu WWW został wykonany z lokalnie wdrożonej przez autorów strony internetowej wentylatora przy użyciu przeglądarki Mozilla Firefox. Wyświetlane sterowniki i pola wyjściowe zostały wygenerowane z metadanych RIP w lokalnym środowisku eksperymentalnym autorów. Nie uwzględniono danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.

Rysunek 8: Panel przedni VI silnika. Panel przedni zawiera sterowniki dla Setpoint, Kc, Ti, Td, Disturbance oraz sterowanie Reset, a także wskaźniki Position, Voltage, Time oraz Measured angular velocity. Zrzut ekranu wykonano z panelu przedniego Motor.vi w programie LabVIEW 2026 w lokalnym środowisku eksperymentalnym autorów. Nie zawarto danych użytkowników osób trzecich ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rysunek 9: Schemat modelu sterowania położeniem silnika DC za pomocą regulatora PID. Schemat przedstawia ścieżkę sygnału od błędu wartości zadanej, przez sterowanie PID, ograniczanie napięcia, superpozycję zakłóceń, dynamikę elektryczną, dynamikę mechaniczną i aktualizację położenia, aż po sprzężenie zwrotne. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rysunek 10: Schemat blokowy VI silnika. Model silnika zaimplementowano z wykorzystaniem pętli While, rejestrów przesuwnych, węzła formuły, logiki czasowej oraz wskaźników wyjściowych. Zrzut ekranu wykonano z schematu blokowego Motor.vi w programie LabVIEW 2026 w lokalnym środowisku eksperymentalnym autorów. Nie zawarto danych użytkowników osób trzecich ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rycina 11: Strona konfiguracji Motor.vi. Eksperyment z silnikiem jest zarejestrowany w Konfiguracji RIP pod nazwą eksperymentu Motor, wraz z rzeczywistą ścieżką VI, informacjami o słowach kluczowych, opisem oraz częstotliwością próbkowania. Zrzut ekranu został wykonany z interfejsu Konfiguracji RIP używanego z LabVIEW 2026 i RIP WebService w lokalnym środowisku eksperymentalnym autorów. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.

Rycina 12: Strona interfejsu Web programu Motor.vi.Strona front-end automatycznie generuje sterowniki wejściowe i wyświetlacze wyjściowe dla eksperymentu sterowania położeniem silnika DC za pomocą regulatora PID. Ten zrzut ekranu interfejsu Web został wykonany z lokalnie wdrożonej przez autorów strony internetowej silnika przy użyciu przeglądarki Mozilla Firefox. Wyświetlone sterowniki i pola wyjściowe zostały wygenerowane z metadanych RIP w lokalnym środowisku eksperymentalnym autorów. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.

Rysunek 13: Błąd dostępu w przeglądarce, gdy Caddy nie jest uruchomiony. Gdy Caddy nie jest uruchomiony, lokalny adres proxy http://localhost:8090/motor jest nieosiągalny, a przeglądarka wyświetla komunikat ERR_CONNECTION_REFUSED. Ten objaw błędu wskazuje, że lokalna usługa proxy Caddy jest niedostępna lub nie nasłuchuje na wybranym porcie dostępu. Ten zrzut ekranu z przeglądarki został wykonany przy użyciu programu Mozilla Firefox w lokalnym środowisku testowym autorów i pokazuje stan braku dostępu w sytuacji, gdy lokalne proxy Caddy nie było uruchomione. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tego rysunku.

Rycina 14: Błąd komunikacji RIP POST po załadowaniu strony. Konsola przeglądarki wyświetla błąd 502 Bad Gateway dla żądania RIP POST. Wynik ten wskazuje, że strona internetowa dotarła do adresu proxy Caddy, ale żądanie nie może zostać pomyślnie przekazane do backendu RIP WebService lub nie może zostać przez niego przetworzone. Ten zrzut ekranu z konsoli przeglądarki został wykonany przy użyciu narzędzi Mozilla Firefox Developer Tools w lokalnym środowisku wdrożeniowym autorów i przedstawia błąd komunikacji RIP POST 502 Bad Gateway. Nie zamieszczono żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.

Rycina 15: Status komunikacji po stronie przeglądarki podczas normalnej pracy. Narzędzia deweloperskie przeglądarki pokazują pomyślne ładowanie strony, żądania RIP POST oraz aktywne żądanie SSE z expId=fan. Żądania te wskazują, że front-end WWW komunikuje się z usługą RIP WebService poprzez serwer proxy Caddy i otrzymuje aktualizacje w czasie rzeczywistym za pośrednictwem kanału SSE. Zrzut ekranu z narzędzi deweloperskich przeglądarki został wykonany przy użyciu przeglądarki Mozilla Firefox w lokalnym środowisku wdrożeniowym autorów i przedstawia prawidłową komunikację RIP POST oraz SSE. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.

Rysunek 16: Pojedyncza reprezentatywna obserwacja zasobów na poziomie konsoli przeglądarki i procesu dla eksperymentu z wentylatorem. Zrzut ekranu został wykonany podczas lokalnego testu eksperymentu z wentylatorem. Konsola pokazuje czas żądania/odpowiedzi metadanych, liczbę zmiennych metadanych, czas generowania interfejsu użytkownika w oparciu o metadane, czas otwarcia połączenia SSE oraz odebrane dane SSE. Widok menedżera zadań pokazuje wartości CPU i pamięci na poziomie procesu dla procesów przeglądarki i LabVIEW w momencie przechwycenia obrazu. Wartości te są opisowymi obserwacjami z tego pojedynczego testu i nie stanowią powtarzalnych pomiarów wydajności ani benchmarku statystycznego. Zrzut ekranu został wykonany za pomocą narzędzi programisty Mozilla Firefox oraz Menedżera zadań systemu Windows w lokalnym środowisku testowym autorów. Do rejestracji wyjścia konsoli przeglądarki użyto przeglądarki Mozilla Firefox, a do obserwacji zużycia CPU i pamięci dla procesów przeglądarki i LabVIEW – Menedżera zadań systemu Windows. Nie dołączono żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby wyświetlić większą wersję tego rysunku.

Rycina 17: Jednoczesny dostęp do tej samej strony WWW opartej na RIP z przeglądarki komputerowej i mobilnej. Strona eksperymentu z wentylatorem została otwarta równolegle na komputerze PC i urządzeniu mobilnym, a oba klienty wyświetlają automatycznie generowane sterowniki i zmienne wyjściowe. Dostęp do strony WWW na komputerze uzyskano za pomocą przeglądarki Mozilla Firefox, a do strony mobilnej za pomocą przeglądarki mobilnej w tym samym lokalnym środowisku sieciowym. Zrzuty ekranu zostały wykonane we własnym lokalnym środowisku testowym autorów. Nie zawarto żadnych danych użytkowników zewnętrznych ani informacji poufnych. Kliknij tutaj, aby zobaczyć powiększoną wersję tej ryciny.

Nazwa zmiennej	Typ danych	Wejście/Wyjście	Znaczenie fizyczne	Rola w modelu			Zakres/Ustawienie
Enable	Boolean	Wejście	Przełącznik pracy wentylatora	Steruje tym, czy model odbiera sygnał PWM. Gdy True, u = PWM; gdy False, u = 0.			True / False
PWM	DBL	Wejście	Sygnał sterujący napędem	Określa podstawową intensywność napędu wentylatora i jest głównym wejściem używanym do obliczania prędkości stanu ustalonego SteadyRPM.			0-1, krok 0,01
Load	DBL	Wejście	Współczynnik obciążenia	Opisuje efekt osłabiający wpływ obciążenia na prędkość stanu ustalonego. Wraz ze wzrostem Load, prędkość stanu ustalonego maleje.			0-1, krok 0,01
Tau	DBL	Wejście	Stała czasowa odpowiedzi	Określa, jak szybko prędkość wentylatora zbliża się do prędkości stanu ustalonego ze stanu poprzedniego.			0,1-5, krok 0,1
KMaxRPM	DBL	Wejście	Prędkość maksymalna	Ustawia maksymalną prędkość dopuszczalną w modelu; służy do ograniczania prędkości i normalizacji.			500-6000, krok 100
Disturbance	DBL	Wejście	Wejście zakłóceń	Reprezentuje wpływ zakłóceń zewnętrznych lub wahań obciążenia na prędkość stanu ustalonego, prąd i moc.			0-1, krok 0,1
SpeedRPM	DBL	Wyjście	Prędkość rzeczywista	Reprezentuje aktualną prędkość wyjściową wentylatora, aktualizowaną poprzez dynamikę bezwładności pierwszego rzędu.			Obliczana przez model
SteadyRPM	DBL	Wyjście	Prędkość stanu ustalonego	Reprezentuje teoretyczną prędkość stanu ustalonego przy obecnych warunkach wejściowych.			Obliczana przez model
TimeS	DBL	Wyjście	Czas pracy	Reprezentuje ciągły czas pracy modelu.			Obliczana przez model
SpeedNorm	DBL	Wyjście	Prędkość znormalizowana	Reprezentuje stosunek SpeedRPM do KMaxRPM.			0-1 lub obliczana przez model
CurrentA	DBL	Wyjście	Prąd	Reprezentuje szacowany prąd modelu, który zmienia się wraz z sygnałem sterującym i wejściem zakłóceń.			Obliczana przez model
PowerW	DBL	Wyjście	Moc	Reprezentuje szacowaną moc modelu, obliczaną na podstawie stałej napięcia i prądu.			Obliczana przez model
Setpoint	DBL	Wejście	Pozycja zadana	Ustawia pozycję, którą powinien osiągnąć silnik; wraz z rzeczywistą pozycją Position tworzy błąd e.			-3-3, krok 0,1
Kc	DBL	Wejście	Wzmocnienie proporcjonalne	Reguluje siłę odpowiedzi regulatora PID na błąd.			0-10, krok 0,1
Ti	DBL	Wejście	Czas całkowania	Reguluje działanie całkujące regulatora PID i służy do redukcji błędu stanu ustalonego.			0-10, krok 0,1
Td	DBL	Wejście	Czas różniczkowania	Reguluje działanie różniczkujące regulatora PID; służy do tłumienia zbyt gwałtownych zmian błędu i poprawy odpowiedzi dynamicznej.			0-5, krok 0,1
Disturbance	DBL	Wejście	Wejście zakłóceń	Reprezentuje zakłócenie zewnętrzne nałożone na wejście silnika, działające na model silnika wraz z napięciem sterującym.			0-10, krok 0,1
Reset control	Boolean	Wejście	Reset sterowania	Wyzwala czyszczenie stanu modelu, aby pozycja, prędkość kątowa, prąd, błąd i człon całkujący powróciły do stanów początkowych.			True / False
Position	DBL	Wyjście	Pozycja rzeczywista	Reprezentuje aktualną pozycję kątową silnika i służy jako zmienna sprzężenia zwrotnego dla sterowania PID.			Obliczana przez model
Voltage	DBL	Wyjście	Napięcie sterujące	Reprezentuje wyjście regulatora PID po ograniczeniu napięcia; działa na wejście silnika.			Obliczana przez model; ograniczone do -24 do 24 V
Time	DBL	Wyjście	Czas pracy	Reprezentuje ciągły czas pracy modelu silnika.			Obliczana przez model
Measured angular velocity	DBL	Wyjście	Zmierzona prędkość kątowa	Reprezentuje aktualną prędkość kątową silnika i stanowi wyjście stanu mechanicznego silnika.			Obliczana przez model

Tabela 1: Zmienne wejściowe i wyjściowe użyte w przykładach z wentylatorem i silnikiem DC. Tabela zawiera nazwę każdej zmiennej, typ danych, rolę wejścia/wyjścia, znaczenie fizyczne, zalecany zakres oraz wielkość kroku.

Parametr	Wartość	Znaczenie fizyczne	Rola w modelu
R	1	Rezystancja stojana	Reprezentuje człon rezystancji w obwodzie induktora silnika i określa spadek napięcia R × im w równaniu prądu.
L	0.5	Indukcyjność prądu szczotkowego	Reprezentuje indukcyjność obwodu stojana i określa szybkość zmiany prądu. Większa wartość L powoduje wolniejszą odpowiedź prądową.
J	0.01	Moment bezwładności	Reprezentuje opór rotora silnika przeciwko zmianom przyspieszenia kątowego i określa, jak szybko zmienia się prędkość kątowa.
b	0.1	Współczynnik tłumienia lepkościowego	Reprezentuje tłumienie mechaniczne i opisuje moment tłumienia, który utrudnia wzrost prędkości kątowej podczas obrotu.
Kt	0.01	Stała momentu obrotowego	Reprezentuje współczynnik proporcjonalności, który przelicza prąd stojana na moment obrotowy elektromagnetyczny.
Ke	0.01	Stała przeciwprądu elektromotorycznego	Reprezentuje współczynnik proporcjonalności, z którym prędkość kątowa generuje przeciwemf, i opisuje wpływ prędkości na natężenie prądu w mechanizmie sprzężenia zwrotnego.
Vmax	24	Maksymalne napięcie sterujące	Reprezentuje limit napięcia wyjściowego kontrolera i utrzymuje napięcie w zakresie od -24 V do 24 V.
dt	0.001	Dyskretny krok symulacji	Reprezentuje odstęp czasu dla każdej aktualizacji stanu w pętli i jest wykorzystywany do aktualizacji prądu, prędkości kątowej, położenia oraz czasu pracy.

Tabela 2: Parametry wewnętrzne wykorzystane w modelu regulacji położenia silnika DC za pomocą kontrolera PID. W tabeli wymieniono parametry elektryczne i mechaniczne, symbole, wartości liczbowe, jednostki oraz role w modelu.

Dodatkowe pliki kodu: kompletne pliki źródłowe i konfiguracyjne do odtworzenia przykładów z wentylatorem i silnikiem prądu stałego. Dodatkowe pliki kodu obejmują kod węzła formuły (Formula Node) LabVIEW, konfigurację reverse-proxy Caddy, pliki front-endu XHTML oraz źródłowe pliki VI LabVIEW użyte w tym protokole. Plik Code in LabVIEW Formula Node.docx zawiera kod węzła formuły dla modeli PID sterowania położeniem wentylatora i silnika prądu stałego. Plik Caddyfile.txt zawiera konfigurację lokalnego serwera WWW i reverse-proxy. Pliki Fan_Automatic_UI.xhtml oraz Motor_Automatic_UI.xhtml zawierają logikę front-endu WWW opartą na metadanych. Pliki fengshan.vi oraz Motor.vi to pliki VI back-endu LabVIEW dla eksperymentów z wentylatorem i silnikiem.Kliknij tutaj, aby pobrać ten plik.

Dyskusja

Kluczowym krokiem w tym protokole jest ustandaryzowana konstrukcja i rejestracja instrumentu VI (Virtual Instrument) w programie LabVIEW pełniącym rolę backendu. Elementy sterujące i wskaźniki na panelu przednim (Front Panel) muszą posiadać jasne i unikalne nazwy zmiennych, a ich typy danych muszą być zgodne ze zmiennymi oczekiwanymi przez obliczenia modelu oraz przez proces odczytu/zapisu RIP. W dwóch przykładach wykorzystanych w tym protokole zmienne numeryczne skalarne zdefiniowano jako sterowniki lub wskaźniki typu DBL, a zmienne Boolean jako sterowniki Boolean. Diagram blokowy (Block Diagram) musi również zapewniać ciągłą aktualizację stanu poprzez pętlę While (While Loop), rejestry przesuwne (Shift Registers) i węzeł formuły (Formula Node), aby zmienne takie jak prędkość wentylatora, pozycja silnika, prędkość kątowa silnika, napięcie i czas mogły być aktualizowane podczas wykonywania programu. Po skonstruowaniu VI, nazwa eksperymentu w konfiguracji RIP musi być dokładnie zgodna z identyfikatorem eksperymentu użytym w odpowiadającym mu pliku XHTML, a ścieżka VI (VI Path) musi wskazywać na rzeczywistą zapisaną lokalizację VI. Ustawienia te są istotne, ponieważ front-end internetowy nie posiada na stałe zakodowanych zmiennych dla każdego eksperymentu. Zamiast tego polega on na metadanych zwracanych przez serwer RIP w celu zidentyfikowania zmiennych zapisywalnych, zmiennych odczytywalnych, typów danych oraz właściwości numerycznych^10,11.

Główne problemy wymagające rozwiązywania dotyczą spójności pomiędzy identyfikatorem eksperymentu w pliku XHTML, konfiguracją RIP, usługą RIP WebService a ustawieniami serwera proxy Caddy. Jeśli identyfikator eksperymentu w pliku XHTML nie zgadza się z nazwą eksperymentu w konfiguracji RIP, strona internetowa nie może przesłać żądania o poprawne metadane, a w konsekwencji nie może wygenerować oczekiwanych elementów sterujących i pól wyjściowych. Jeśli ścieżka VI jest nieprawidłowa lub usługa RIP WebService nie została uruchomiona, strona internetowa może się otworzyć, ale nie będzie mogła komunikować się z zapleczem LabVIEW. Jeśli program Caddy nie jest uruchomiony, przeglądarka nie może uzyskać dostępu do wybranego lokalnego adresu proxy i może wyświetlić komunikat ERR_CONNECTION_REFUSED, jak pokazano na ryc. 13. Jeśli Caddy działa, ale cel odwrotnego proxy (reverse-proxy target) nie zgadza się z portem usługi RIP WebService, strona może zostać załadowana, podczas gdy żądania RIP POST zakończą się błędem 502 Bad Gateway, jak pokazano na ryc. 14. Jeśli trasa /RIP/SSE* nie działa poprawnie, strona może się otworzyć i wyświetlić elementy sterujące, ale wartości wyjściowe nie będą aktualizowane w czasie rzeczywistym. W warunkach prawidłowego działania narzędzia deweloperskie przeglądarki powinny wykazać pomyślne ładowanie strony, żądania RIP POST oraz aktywne żądanie SSE z poprawnym identyfikatorem eksperymentu, jak pokazano na ryc. 15. W związku z tym rozwiązywanie problemów należy rozpocząć od sprawdzenia identyfikatora eksperymentu, ścieżki VI, stanu usługi RIP WebService, stanu działania programu Caddy, portów proxy oraz trasy SSE. Jeśli komunikacja nadal przebiega nieprawidłowo, pomocne w odróżnieniu problemów z konfiguracją RIP/Caddy od zachowań specyficznych dla przeglądarki może być ponowne uruchomienie zarówno usługi RIP WebService, jak i programu Caddy, wyczyszczenie pamięci podręcznej przeglądarki lub powtórzenie testu w innej przeglądarce.

Niniejszy protokół jest powtarzalny w obu przykładach, ponieważ ten sam schemat pracy (budowa-rejestracja-wdrażanie-weryfikacja) został zastosowany zarówno do modelu prędkości wentylatora, jak i do modelu sterowania pozycją silnika DC za pomocą regulatora PID. Aby zmniejszyć zależność od specjalistycznych bibliotek (toolboxes), tylne instrumenty VI zostały zrekonstruowane przy użyciu podstawowych struktur LabVIEW, w tym elementów sterujących i wskaźników Front Panel, pętli While, rejestrów przesuwnych (Shift Registers), węzłów formuł (Formula Nodes) oraz standardowych skalarnych zmiennych numerycznych i typu Boolean. Niemniej jednak, powtarzalność w zależności od wersji programu LabVIEW, instalacji systemu Windows i środowisk sieci lokalnych wciąż zależy od szczegółów konfiguracji, takich jak ścieżki do plików, uprawnienia dostępu, lokalne porty, polecenia uruchamiania usług oraz zachowanie przeglądarki. Schemat pracy można rozszerzyć na zdalne eksperymenty związane z urządzeniami sprzętowymi, jednak metody tej nie należy interpretować jako bezpośredniego rozpoznawania sprzętu po stronie sieci Web. Interfejs Web identyfikuje elementy sterujące i wskaźniki Front Panel programu LabVIEW za pomocą metadanych RIP. W związku z tym czujniki, aktuatory, instrumenty lub urządzenia sterowania procesem muszą zostać najpierw podłączone i przetworzone w tylnym instrumencie VI LabVIEW poprzez odpowiednie sterowniki sprzętowe, moduły akwizycji danych, moduły sterowania instrumentami lub inne mechanizmy adaptacji sprzętowej. Po zmapowaniu pomiarów sprzętowych i poleceń sterujących na wskaźniki i elementy sterujące Front Panel, interfejs Web oparty na RIP może rozpoznawać te zmienne w ten sam sposób, w jaki rozpoznaje zmienne symulacyjne użyte w niniejszym protokole. Poprzednie badania nad zdalnymi laboratoriami opartymi na LabVIEW wykazały, że LabVIEW może być wykorzystywane jako środowisko backendowe dla zdalnych eksperymentów z zakresu inżynierii sterowania, robotyki, stanowisk sterowania procesami, akwizycji danych z czujników oraz interakcji z urządzeniami fizycznymi^{9,12,17,18,19,20}.

Rysunek 16 przedstawia pojedynczy reprezentatywny przykład implementacji zarejestrowany podczas eksperymentu z lokalnym wentylatorem. Kod front-endu został wyposażony w instrumentację do rejestrowania czasu żądania/odpowiedzi metadanych, liczby zmiennych metadanych, czasu generowania interfejsu użytkownika (UI) na podstawie metadanych, czasu otwierania połączenia SSE oraz odebranych danych SSE. W tym przykładzie konsola przeglądarki wykazała czas żądania/odpowiedzi metadanych wynoszący 68.00 ms, zidentyfikowała 7 zmiennych zapisywalnych i 7 zmiennych odczytywalnych z metadanych RIP, wygenerowała odpowiednie elementy UI w czasie 2.00 ms oraz otworzyła połączenie SSE w ciągu 16.00 ms. Powtarzające się wpisy danych SSE wykazały, że zmienne wyjściowe, takie jak SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA oraz PowerW, były stale odbierane z back-endu LabVIEW. Widok menedżera zadań w tym samym stanie testu lokalnego wykazał zużycie procesora na poziomie około 1.5% i 391.7 MB pamięci dla procesu Firefox, podczas gdy proces LabVIEW wykazał 0% zużycia procesora i 9.2 MB pamięci w momencie przechwycenia danych. Obserwacje te stanowią podstawowy dowód na to, że pobieranie metadanych, generowanie UI na podstawie metadanych, komunikacja RIP/SSE oraz obciążenie procesora na poziomie procesu mogą być obserwowane w lokalnym środowisku wdrożeniowym. Jednakże dane te mają służyć jako weryfikacja na poziomie implementacji, a nie jako kompleksowy benchmark wydajności. Systematyczna ocena wydajności przy użyciu różnych przeglądarek, powtórnych prób, większego obciążenia zmiennymi, sprzętu fizycznego oraz wielu jednoczesnych użytkowników pozostaje niezbędna w przyszłych pracach.

Metoda ta posiada również ograniczenia, zwłaszcza gdy jest rozszerzana o złożone struktury danych, eksperymenty sprzętowe oraz pracę wielu użytkowników. Obecny przepływ pracy jest najbardziej odpowiedni dla skalarnych zmiennych wejściowych i wyjściowych typu liczbowego oraz logicznego (Boolean). Nie zapewnia on automatycznie pełnego wsparcia dla złożonych tablic, klastrów, zagnieżdżonych struktur danych, relacji wykresów ani wizualizacji specyficznych dla danej dziedziny. Przypadki te mogą wymagać dodatkowych reguł mapowania metadanych lub ręcznie napisanych komponentów front-endowych. Automatycznie generowany interfejs użytkownika może tworzyć podstawowe elementy sterujące i wyświetlacze na podstawie metadanych zmiennych, ale nie potrafi w pełni wywnioskować fizycznych zależności między zmiennymi, wybrać najodpowiedniejszej wizualizacji ani zaprojektować interakcji bezpieczeństwa specyficznych dla danego eksperymentu. W przypadku rozszerzenia przepływu pracy na rzeczywisty sprzęt wymagane są dodatkowe rozważania, w tym sterowniki sprzętowe, kalibracja urządzeń, ograniczenia próbkowania, limity elementów wykonawczych, logika zatrzymania awaryjnego, uwierzytelnianie oraz mechanizmy kontroli zapisu dla wielu użytkowników. Obecna implementacja może być również dostępna z wielu urządzeń klienckich poprzez standardowe przeglądarki internetowe w tej samej lokalnej sieci. Jak pokazano na Rysunku 17, ta sama strona eksperymentu z wentylatorem została otwarta jednocześnie w przeglądarce komputerowej i mobilnej, a oba klienty wyświetlały automatycznie wygenerowane sterowniki i odpowiadające im zmienne wyjściowe. Obserwacja ta wskazuje na podstawowy jednoczesny dostęp wielu klientów do przeglądania i interakcji z tą samą stroną eksperymentu. Nie należy jednak interpretować tego jako kompletnego frameworka sterowania wieloużytkownikowego, ponieważ obecna implementacja nie zawiera dedykowanego uwierzytelniania użytkowników, blokad sterowania, arbitrażu współbieżnego zapisu, kolejek zapisu ani mechanizmów rozwiązywania konfliktów. Ograniczenia te są zgodne z wcześniejszymi badaniami nad laboratoriami zdalnymi, w których złożone lub kolaboracyjne laboratoria zdalne zazwyczaj wymagają projektu interfejsu specyficznego dla eksperymentu, mechanizmów synchronizacji, ograniczeń bezpieczeństwa oraz logiki zarządzania użytkownikami^{13,14,15,16,17}.

Wartość metodologiczna niniejszego protokołu nie polega na wprowadzeniu nowej architektury RIP ani na rozszerzeniu typów danych obsługiwanych przez RIP. Zamiast tego jego wartość tkwi w zapewnieniu kompletnej i powtarzalnej ścieżki implementacji dla zastosowania ugruntowanego mechanizmu automatycznego generowania interfejsu użytkownika opartego na RIP w różnych systemach LabVIEW. W porównaniu do pisania niestandardowego interfejsu internetowego dla każdego eksperymentu, ten przepływ pracy redukuje powtarzającą się implementację podstawowego układu sterowania, wiązania zmiennych oraz logiki komunikacji odczyt/zapis w przypadkach, gdy VI backendu udostępnia kompatybilne zmienne^8,9,10,11. Protokół ten jest zatem przydatny w edukacji inżynieryjnej, rozwoju laboratoriów zdalnych oraz szybkym wdrażaniu niskoryzykowych eksperymentów symulacyjnych lub dydaktycznych, które wymagają regulacji parametrów w przeglądarce i monitorowania stanu w czasie rzeczywistym. Przyszłe prace powinny rozszerzyć ten przepływ pracy o bardziej złożone struktury danych, fizyczne urządzenia eksperymentalne, formalną kontrolę dostępu dla wielu użytkowników oraz ilościową ocenę wydajności, w tym czas generowania interfejsu, opóźnienia komunikacyjne, stabilność synchronizacji, obciążenie serwera, narzut CPU oraz użyteczność front-endu.

Materiały

Lista materiałów użytych w tym artykule

Nazwa	Firma	Numer katalogowy	Komentarze
Serwer proxy Caddy	Caddy	N/A	Odwrócony proxy używany do obsługi interfejsu Web UI i przekazywania żądań /RIP do usługi RIP WebService
Caddyfile	Przygotowany przez autorów	N/A	Definiuje trasy plików statycznych oraz trasy odwróconego proxy dla komunikacji RIP
Fan_Automatic_UI.xhtml	Przygotowany przez autorów	N/A	Interfejs Web front end oparty na metadanych dla eksperymentu z wentylatorem
LabVIEW	National Instruments	2026	Oprogramowanie używane do konstrukcji i uruchamiania programów fengshan.vi oraz Motor.vi
System operacyjny Microsoft Windows	Microsoft	Win11	System operacyjny używany do uruchamiania LabVIEW, RIP WebService, Caddy oraz przeglądarki
Motor_Automatic_UI.xhtml	Przygotowany przez autorów	N/A	Interfejs Web front end oparty na metadanych dla eksperymentu z silnikiem
Przeglądarka stacjonarna Mozilla Firefox	Mozilla	2026	Przeglądarka stacjonarna używana do dostępu do Web UI, narzędzi deweloperskich, obserwacji czasu i zasobów oraz wykonywania zrzutów ekranu z sieci i konsoli
RIP WebService	UNEDLabs	https://github.com/Nebulous-Systems/rip-server_labview	Odbiera żądania RIP POST i zapewnia warstwę komunikacyjną WebService wykorzystywaną przez front end przeglądarki
Menedżer zadań systemu Windows	Microsoft	Wbudowany w system Windows	Używany do rejestrowania obserwacji zużycia procesora i pamięci na poziomie procesów dla przeglądarki i procesów LabVIEW