Ekrany HMI: co operator musi zobaczyć

Stan maszyny, powód zatrzymania, alarmy i receptury. Jak ustalić zakres zmian wizualizacji z osobami, które używają panelu.

Panel operatorski z widokiem stanu maszyny i brakującego potwierdzenia urządzenia

Na ekranie zatrzymanej maszyny operator powinien znaleźć odpowiedź na konkretną sytuację: co zatrzymało sekwencję, czego układ oczekuje i w jakim trybie pracuje. Duża liczba tagów na jednym widoku nie zapewnia tych informacji. Przebudowę HMI warto zacząć od kilku rzeczywistych sytuacji przy stanowisku, a nie od wyboru nowych ikon, kolorów i efektów graficznych.

Pierwszy widok ma wyjaśniać stan

Operator powinien rozpoznać maszynę, tryb, bieżący krok i aktywną recepturę bez przechodzenia przez kilka ekranów. Odróżnij pracę, oczekiwanie, zatrzymanie i brak gotowości. Komunikat „automat” opisuje tryb, ale nie mówi, czy sekwencja wykonuje operację, czeka na materiał czy została wstrzymana. Dobrze, gdy przy oczekiwaniu można zobaczyć brakujący warunek, a nie tylko nieruchomy rysunek urządzenia.

Nazwy muszą odpowiadać dokumentacji i określeniom używanym na hali. Numer urządzenia pomaga serwisowi, lecz sam kod nie zawsze wystarcza operatorowi. Połącz go z krótkim opisem. Informacje najczęściej potrzebne podczas pracy powinny być dostępne na widoku głównym, a szczegóły techniczne w przewidywalnym miejscu. Nie ukrywaj alarmów pod dekoracyjnym ekranem powitalnym ani nie zmieniaj położenia podstawowych przycisków między podobnymi widokami.

Kolor ma znaczenie tylko przy spójnych zasadach

Ustal niewielki zestaw kolorów oraz ich znaczenie. Alarm, ostrzeżenie, stan aktywny i element możliwy do naciśnięcia nie powinny wyglądać tak samo. Unikaj „choinki kolorów”, w której wszystkie urządzenia świecą intensywnie podczas normalnej pracy. W takim obrazie rzeczywista nieprawidłowość przestaje się wyróżniać. Nie oznacza to konieczności zmiany całego stylu panelu, tylko uporządkowanie sposobu sygnalizacji.

Stan nie powinien być przekazywany wyłącznie kolorem. Dodaj tekst, symbol lub czytelną zmianę opisu. Sprawdź widok na docelowym panelu, w oświetleniu stanowiska i z odległości, z jakiej pracuje operator. Drobny napis czy cienka linia mogą wyglądać dobrze na monitorze projektanta i być trudne do odczytania przy maszynie. Weryfikacja na ekranie rzeczywistego urządzenia jest częścią sprawdzenia interfejsu.

Alarm z miejscem i warunkiem

Komunikat powinien wskazywać urządzenie oraz niespełniony warunek. „Błąd maszyny” nie rozróżnia braku komunikacji, potwierdzenia pozycji i zakończenia kroku. Ustal priorytety zgodnie z konsekwencją i potrzebną reakcją, a nie kolejnością dodawania alarmów do projektu. Przy dużej liczbie meldunków ważne jest odróżnienie pierwszego zdarzenia od późniejszych skutków. Przydatne są czas wystąpienia, ustąpienia i potwierdzenia.

Potwierdzenie alarmu, czyli acknowledgement, nie oznacza usunięcia jego przyczyny. Panel powinien pozwalać rozpoznać alarm nadal aktywny, już nieaktywny oraz oczekujący na potwierdzenie według zasad projektu. Przycisk zbiorczego kasowania nie może być jedynym sposobem orientacji w stanie maszyny. Jeśli istnieje opis dalszego działania, powinien odpowiadać procedurze obsługi, bez sugerowania obchodzenia blokad czy zabezpieczeń.

Oddziel obsługę od szczegółów serwisowych

Widok operatora pokazuje to, co potrzebne do prowadzenia procesu. Diagnostyka może zestawiać warunek startu, polecenie, sygnał zwrotny i czas oczekiwania. Uprawnienia do zmiany parametrów powinny wynikać z odpowiedzialności użytkownika. Samo schowanie przycisku w głębokim menu nie jest zabezpieczeniem dostępu. Ustal również, które wartości są tylko do odczytu, a które stanowią nastawy.

Trend warto dodać tam, gdzie przebieg wyjaśnia problem: przy niestabilnym pomiarze, opóźnionym potwierdzeniu czy zmianie temperatury procesu. Powinien mieć jednostkę, czytelną skalę i zakres czasu. Nie każdy sygnał potrzebuje własnego wykresu. Przy utracie komunikacji wartości muszą być rozpoznawalne jako nieaktualne lub niedostępne. Wyświetlanie ostatniej liczby bez takiej informacji może wprowadzać operatora w błąd.

Receptury, zapis i potwierdzanie działań

Rozróżnij wartość wpisaną na panelu od wartości przyjętej przez PLC. Użytkownik powinien wiedzieć, czy zmiana została zastosowana, odrzucona czy oczekuje na wykonanie. Określ dozwolone zakresy, jednostki oraz moment obowiązywania nowej receptury. Sprawdź zachowanie po ponownym połączeniu HMI. Niepotwierdzony zapis nie powinien wyglądać jak skutecznie zmieniona nastawa procesu.

Dla działań mających istotne konsekwencje zastosuj adekwatne potwierdzenie z opisem skutku, na przykład zastąpienia receptury. Nie dodawaj identycznego pytania do każdej zwykłej czynności, bo użytkownik zaczyna zatwierdzać je automatycznie. Dialog potwierdzenia nie zastępuje funkcji bezpieczeństwa maszyny. W projektowaniu HMI i SCADA takie zachowanie warto ustalić razem z interfejsem programu i sposobem pracy operatorów.

Odbiór przez zadania przy maszynie

Przed zmianą zbierz zrzuty istniejących ekranów oraz przykłady problemów zgłaszanych przez obsługę. Podczas sprawdzenia przejdź przez normalną pracę, brak warunku startu, alarm, zmianę receptury i utratę komunikacji. Obserwuj, czy operator potrafi sam znaleźć właściwy widok. Zapisz miejsca, w których musi pytać programistę o znaczenie komunikatu. To są konkretne punkty do poprawy, nawet jeśli nowy ekran wygląda już schludnie.

Wszystkie artykuły