Oprogramowanie Modbus PC/HMI dla projektów sprzętu rosyjskiego: integracja rejestrów, alarmów i dzienników

Projekt Modbus PC/HMI dla sprzętu rosyjskiego powinien rozpocząć się od jednego interfejsu bazowego z kontrolowaną wersją. Powinien rejestrować zarówno numer rejestru wyświetlanego w instrukcji, jak i adres początkowy PDU, typ danych, kolejność bajtów w rejestrze, kolejność słów w rejestrach, skalowanie, jednostkę, nieprawidłową wartość, prawa dostępu, obsługę wyjątków, maszynę stanu alarmu i pola korelacji dziennika. Pomyślne połączenie dowodzi jedynie, że wiadomości mogą być przesyłane; nie dowodzi, że wartości, alarmy lub ścieżki audytu są prawidłowe.

Beijing Winge Technology Co., Ltd. świadczy usługi rozwoju komputerów przemysłowych/HMI, protokołu Modbus i integracji systemów pod nazwami Winge Technology i Winge. Poniższy materiał wspiera definicję zakresu dla zespołów w Rosji; Tekst i dokumenty interfejsu użytkownika w języku rosyjskim stanowią zasoby w języku projektu i nie zmieniają protokołu urządzenia. Ta strona nie obejmuje rosyjskiego biura, rosyjskich klientów ani ukończonych projektów w Rosji.

Zamroź konwencję danych wejściowych i adresów przed rozpoczęciem programowania

Podaj przynajmniej dokładny model urządzenia, wersję oprogramowania sprzętowego, tryb Modbus RTU lub TCP, parametry szeregowe lub sieciowe, adres urządzenia podrzędnego lub identyfikator urządzenia, obsługiwane kody funkcji, mapę rejestrów, przykładowe ramki, blokady zapisu i zamierzony przepływ pracy. Specyfikacja Modbus definiuje rejestry jako słowa 16-bitowe i w przypadku adresów wielobajtowych i elementów danych wysyła najpierw najbardziej znaczący bajt. Kolejność słów wartości 32-bitowej obejmującej dwa rejestry, jej skalę, jednostkę i znaczenie biznesowe należy jeszcze potwierdzić w dokumentacji urządzenia. Adresy PDU zaczynają się od zera, podczas gdy instrukcja urządzenia może zawierać inną konwencję numeracji; zapisz oba, zamiast wyciągać adres z zapisu takiego jak „40001”.

Tabela interfejsów rejestrów, alarmów i dzienników

Jest to szablon interfejsu bazowego i protokołu akceptacji, a nie wniosek dotyczący kompatybilności dla konkretnego urządzenia lub danych pomiarowych z rosyjskiego projektu. Wypełnij każde pole, podając urządzenie docelowe, wersję oprogramowania i uzgodnione kryteria zaliczenia.

Obszar interfejsu	Pola wymagające potwierdzenia	Dowód przyjęcia
Podłączenie i adresowanie	tryb RTU/TCP; parametry szeregowe lub sieciowe; adres urządzenia podrzędnego lub identyfikator jednostki; kod funkcji; wyświetlany numer ręczny; Adres początkowy PDU; ciągły zakres odczytu	Zachowaj konfigurację oraz nieprzetworzone żądania i odpowiedzi; udowodnić, że wyświetlane liczby odpowiadają rzeczywistym przesunięciom komunikatów
Zarejestruj dane	Cewka, wejście dyskretne, rejestr wejściowy lub rejestr holdingowy; liczba całkowita ze znakiem lub bez znaku, zmiennoprzecinkowa lub tekst; liczba, kolejność bajtów, kolejność słów, skala, przesunięcie, jednostka, nieprawidłowa wartość i dostęp do odczytu/zapisu	Porównaj surowe 16-bitowe słowa, połączone wartości i wartości inżynieryjne ze znanymi danymi wejściowymi; oddzielnie rejestrować granice, wartości ujemne i nieprawidłowe znaczniki
Sondaże i pisze	Interwał odpytywania, odczyty grupowe, limit czasu, ponowna próba, liczba jednoczesnych urządzeń, rola zapisu, blokada, odczyt zwrotny i stan domyślny po ponownym uruchomieniu urządzenia	Rekordowa liczba żądań, przekroczenia limitu czasu i ponowne połączenie; weryfikacja autoryzacji, blokad, odpowiedzi zapisu, odczytu zwrotnego i przywracania cyklu zasilania
Wyjątki protokołu i stan komunikacji	Brak odpowiedzi, błąd CRC lub ramki, rozłączone łącze, nieaktualne dane i odpowiedzi wyjątków przy użyciu oryginalnego kodu funkcji plus 0x80 i kod wyjątku; oddzielnie zdefiniuj stan interfejsu użytkownika i zasady ponawiania prób	Wstrzyknij nielegalną funkcję, nielegalny adres, nieprawidłową wartość, przekroczenie limitu czasu i rozłączenie; sprawdź surowe klatki, flagi jakości, liczbę ponownych prób i stan końcowy
Maszyna stanu alarmowego	Pole źródłowe, warunek wyzwalacza, istotność, opóźnienie lub odrzucenie, stany aktywne, potwierdzone, przywrócone i wyciszone, źródło czasu oraz klucze zasobów dla tekstu interfejsu użytkownika w języku rosyjskim i innym	Przejdź przez normalne, aktywne, potwierdzone, odzyskane i gaworzące warunki; porównaj interfejs użytkownika, tabelę zdarzeń i rekordy powiadomień
Dzienniki i identyfikowalność	Identyfikator korelacji, tożsamość urządzenia i połączenia, kod i adres funkcji, surowa ramka lub wyjątek, zdekodowana wartość, użytkownik i rola, wersje oprogramowania i oprogramowania sprzętowego, znacznik czasu, strefa czasowa i kodowanie eksportu	Śledź działanie interfejsu użytkownika poprzez transakcję Modbus, przejście alarmu i wynik; odtwórz łańcuch z eksportu według identyfikatora korelacji, jednocześnie redagując dane uwierzytelniające lub wrażliwe pola

Warstwy oprogramowania, produkty dostarczane i akceptacja

Aplikację można podzielić na adapter komunikacyjny, warstwę semantyki rejestrów, warstwę stanu urządzenia, silnik alarmowy, interfejs użytkownika i magazyn dzienników. Pierwsza faza może dostarczyć rejestr luk, wersjonowany słownik rejestrów, macierz alarmów, tabelę zasobów w języku rosyjskim i innym języku docelowym, słownik pól dziennika, prototyp interfejsu użytkownika i przypadki akceptacji. Elementy implementacyjne mogą następnie obejmować uzgodniony kod źródłowy lub instalator, instrukcje dotyczące konfiguracji, kompilacji lub wdrażania, zapisy testów i znane ograniczenia. Komponenty stron trzecich, zakup urządzeń, prace na miejscu, prawa do kodu źródłowego i okresy konserwacji są objęte odrębnym zakresem.

Akceptacja powinna obejmować normalne odczyty i zapisy oraz wprowadzenie błędów do uzgodnionego urządzenia lub wspólnie akceptowanego symulatora: nieprawidłowa funkcja, nieprawidłowy adres, nieprawidłowa wartość, przekroczenie limitu czasu, błąd ramki szeregowej, rozłączenie i ponowne podłączenie, nieaktualne dane, drgania alarmów, potwierdzenie i odzyskiwanie, nieautoryzowane zapisy i ponowne uruchomienie urządzenia. Interwał odpytywania, liczba urządzeń, czas działania, tolerancja synchronizacji czasu i dozwolone różnice w danych należą do założeń projektu. Karnet symulatorowy nie zastępuje weryfikacji na urządzeniu docelowym i łączu terenowym.

Warunki językowe i wdrożeniowe dla projektu rosyjskiego

W przypadku przekazania do projektu rosyjskiego należy potwierdzić zakres dokumentów w języku rosyjskim/angielskim, listę terminologii interfejsu użytkownika, wyświetlanie i wprowadzanie danych w cyrylicy, kodowanie CSV lub raportu, format daty, liczby i jednostek, strefę czasową projektu, docelową wersję systemu Windows/Linux oraz granicę pomiędzy integracją zdalną i lokalną. Strony odpowiedzialne muszą potwierdzić cyberbezpieczeństwo, dostęp zdalny, zezwolenia branżowe i inne warunki zgodności dla rzeczywistej lokalizacji wdrożenia z bieżących źródeł głównych. Na tej stronie nie przyjmuje się żadnych założeń dotyczących rosyjskich przepisów, certyfikacji, podatków, czasu realizacji logistyki ani lokalnego wsparcia.

Często zadawane pytania

Jeśli w instrukcji urządzenia jest napisane 40001, czy żądanie aplikacji powinno mieć adres 40001?

Nie wnioskuj tego bezpośrednio. Adresy Modbus PDU zaczynają się od zera, podczas gdy w podręcznikach mogą być używane wyświetlane liczby z prefiksem obszaru danych. Zapisz razem numer ręczny, obszar danych, kod funkcji i adres początkowy PDU, a następnie potwierdź je nieprzetworzonymi żądaniami i odpowiedziami na urządzeniu docelowym.

Co należy sprawdzić w pierwszej kolejności, gdy rejestr można odczytać, ale wartość jest błędna?

Sprawdź przesunięcie rejestru, typ danych, znak, kolejność bajtów w każdym rejestrze, kolejność słów w rejestrach, skalę, przesunięcie, jednostkę i konwencję nieprawidłowych wartości. Następnie porównaj surowe 16-bitowe słowa i połączoną wartość ze znanym wejściem lub wyświetlaczem urządzenia. Sukces komunikacji nie weryfikuje semantyki pola.

W jaki sposób należy połączyć wyjątki Modbus, alarmy sprzętu i dzienniki operacji?

Zachowaj trzy warstwy: warstwa protokołu rejestruje żądania, odpowiedzi, przekroczenia limitu czasu i kody wyjątków; warstwa stanu urządzenia tworzy przejścia alarmowe z ustalonych warunków; warstwa operacyjna rejestruje działania i wyniki użytkownika. Połącz je za pomocą jednego identyfikatora korelacji, tożsamości urządzenia i źródła czasu, a następnie zlokalizuj tylko wyświetlany tekst. Nie zamieniaj każdego błędu komunikacji w alarm procesowy.

Powiązane usługi, opublikowany przykład i specyfikacje

Specyfikacje organizacji Modbus i instrukcje implementacji: sprawdź aktualnie wymienione wytyczne dotyczące protokołu aplikacji i linii szeregowej.

Specyfikacja protokołu aplikacji Modbus V1.1b3: sprawdź model danych, kodowanie, adresowanie, kody funkcji i odpowiedzi na wyjątki.

Rozwój protokołu Modbus RTU/TCP: przejrzyj istniejące dane wejściowe, produkty i zakres akceptacji usług Winge.

Aplikacja przemysłowa z enkoderem PC i dwuprotokołowa obudowa STM32: używaj wyłącznie opublikowanych granic dla oprogramowania PC, diagnostyki komunikacji, dzienników zdarzeń i dostarczania; nie wnioskuj o kompatybilności Modbus ani rosyjskich doświadczeniach projektowych.

Użyj Skontaktuj się z Winge, aby podać model urządzenia i oprogramowanie sprzętowe, tryb Modbus i mapę rejestrów, przykładowe ramki, przepływ pracy z alarmami, języki docelowe, środowisko wdrożenia i warunki akceptacji, aby można było najpierw sprawdzić przerwy w interfejsach i zakres faz.