Sparkplug B to otwarta specyfikacja działająca na warstwie MQTT, która dokładnie definiuje, w jaki sposób urządzenia przemysłowe ogłaszają swoją obecność, opisują swoje dane i sygnalizują, gdy przechodzą offline, przemieniając ogólny kanał wiadomości w standard telemetrii samoopisującej się i świadomej stanu.
Samo MQTT to lekki transport publish/subscribe: przesyła bajty od nadawcy do dowolnego subskrybenta, ale nic nie mówi o tym, co te bajty oznaczają, jakie jednostki niosą ani czy nadawca wciąż jest aktywny. Sparkplug B wypełnia tę lukę.
Stworzony w ramach Eclipse Foundation i obecnie utrzymywany jako otwarty standard, przypisuje każdemu tagowi zdefiniowany typ danych, znaną strukturę tematu oraz cykl życia, dzięki czemu każdy konsument, od pulpitu OEE po historian, może zinterpretować ładunek bez ręcznie budowanej mapy integracji.
MQTT został zaprojektowany dla sieci o ograniczonych zasobach i małej niezawodności, co dokładnie tłumaczy, dlaczego sprawdza się w przemyśle. Jednak domyślnie pozostawia trzy trudne problemy nierozwiązane. Po pierwsze, przestrzenie nazw tematów są wolną amerykanką: jeden integrator publikuje do plant1/line3/oven/temp , inny do Oven_Temp_C , i nic nie wymusza spójności.
Po drugie, ładunki są nieprzejrzyste; wartość "72" może oznaczać stopnie Celsjusza, Fahrenheita lub kod błędu, a subskrybent nie ma sposobu, by to rozpoznać. Po trzecie, MQTT nie ma wbudowanej koncepcji świeżości danych. Jeśli bramka straci zasilanie, jej ostatnia opublikowana wartość pozostaje na brokerze, a pulpit nadal pokazuje przestarzały odczyt, jakby maszyna działała poprawnie.
Na hali produkcyjnej te luki nie są teorią. Przestarzałe lub błędnie opisane dane zniekształcają obliczenia dostępności i wydajności, dlatego zespoły dbające o ogólną efektywność urządzeń nie mogą polegać wyłącznie na surowym MQTT. Sparkplug B został napisany specjalnie po to, by zamknąć te luki dla technologii operacyjnych.
Charakterystyczną cechą Sparkplug B jest cykl życia certyfikatów. Gdy węzeł brzegowy lub urządzenie się łączy, publikuje certyfikat uruchomienia (NBIRTH dla węzła, DBIRTH dla urządzenia). Ta wiadomość to nie tylko powitanie. Zawiera pełną listę wszystkich metryk, które urządzenie kiedykolwiek opublikuje, każdą z ich nazwą, typem danych i wartością początkową. Subskrybent, który otrzyma certyfikat uruchomienia, natychmiast zna cały schemat, bez potrzeby zewnętrznego pliku konfiguracyjnego.
Certyfikat zakończenia jest lustrzanym odbiciem. Każdy klient Sparkplug rejestruje Last Will and Testament u brokera w momencie łączenia. Jeśli urządzenie zniknie z sieci w sposób niegraceful, to sam broker publikuje uprzednio zarejestrowany NDEATH w imieniu urządzenia.
Konsumenci natychmiast dowiadują się, że źródło jest offline i mogą oznaczyć jego dane jako przestarzałe, zamiast ufać zamrożonej ostatniej wartości. To prawdziwa świadomość stanu: system rozróżnia „wartość jest rzeczywiście stabilna” od „nadawca zniknął”.
Dla każdego, kto liczy metryki niezawodności takie jak MTBF i MTTR , odróżnienie rzeczywistego zatrzymania od przerwy w komunikacji to różnica między wiarygodną liczbą a fikcyjną.
Ładunki Sparkplug B są kodowane za pomocą Google Protocol Buffers, zwartego formatu binarnego. Każdy ładunek zawiera znacznik czasu, numer sekwencyjny i tablicę metryk. Metryka to obiekt nazwany i typowany, więc odczyt temperatury przesyłany jest jako ustrukturyzowana jednostka z wyraźnym typem Int, Float lub Boolean zamiast niejednoznacznego ciągu znaków.
Przestrzeń nazw tematów jest równie zdyscyplinowana. Każdy temat Sparkplug podąża za ustalonym wzorcem spBv1.0/group_id/message_type/edge_node_id/device_id . Ponieważ struktura jest ustandaryzowana, dowolne narzędzie może zasubskrybować za pomocą jednokrotnego wildcarda i automatycznie odkryć każdą grupę, węzeł i urządzenie w sieci.
Ten model report-by-exception też ma znaczenie: po certyfikacie uruchomienia urządzenia publikują tylko wartości, które się zmieniły (wiadomości NDATA i DDATA), co drastycznie zmniejsza zużycie pasma na ograniczonych łączach typowych dla zakładów.
Samoopisujący charakter danych sprawia, że podstawa danych pozostaje wystarczająco czysta, by zasilać analizy dalszego poziomu, od wykresów statystycznej kontroli procesu po analizę Pareto przyczyn przestojów.
Rozważ linię rozlewniczą z 40 czujnikami, z których każdy raportuje wartość typu floating-point. W naiwnym schemacie odpytywania moglibyśmy publikować wszystkie 40 wartości co sekundę: 40 wiadomości na sekundę, czyli 3 456 000 wiadomości dziennie.
Przy Sparkplug B i report-by-exception załóżmy, że tylko 5 z 40 metryk faktycznie zmienia się w danej sekundzie (temperatura zmienia się powoli, większość stanów jest stabilna). To mniej więcej 5 wiadomości DDATA na sekundę plus jeden certyfikat uruchomienia przy starcie: około 432 000 wiadomości dziennie, redukcja wolumenu wiadomości o około 87 procent. Na łączu komórkowym lub współdzielonym w zakładzie to różnica między zapchanym kanałem a zapasem przepustowości.
Teraz korzyść dla OEE. Załóżmy, że certyfikaty uruchomienia i zakończenia linii pokazują, że była ona rzeczywiście podłączona i działała przez 400 minut z 480-minutowej zmiany. Dostępność to 400 / 480 = 83,3 procent .
Metryki licznikowe raportują 9 000 jednostek wobec idealnej prędkości 25 jednostek na minutę przez te 400 minut (10 000 idealnie), więc wydajność to 9 000 / 10 000 = 90 procent . Metryki jakości pokazują 8 730 dobrych jednostek, więc jakość to 8 730 / 9 000 = 97 procent .
Mnożąc: 0,833 x 0,90 x 0,97 = 72,7 procent OEE . Każde wejście w tym obliczeniu pochodziło z samoopisujących się, świadomych stanu metryk Sparkplug, bez zgadywania, czy przerwa w transmisji była rzeczywistym przestojem, czy przestarzałym odczytem.
Sparkplug B często łączy się z architekturą ujednoliconej przestrzeni nazw, gdzie jeden broker staje się źródłem prawdy w czasie rzeczywistym i każda aplikacja zarówno publikuje do niego, jak i z niego konsumuje.
Uzupełnia, zamiast zastępować istniejące systemy: dane mogą pochodzić z PLC, z warstw SCADA lub z niezależnych bram brzegowych, a następnie przepływać do CMMS w celu wyzwalania prac konserwacyjnych lub do pulpitów monitorujących dla widoczności produkcji w czasie rzeczywistym.
Ponieważ format jest otwarty i samoopisujący się, stanowi też podstawę strategii utrzymania ukierunkowanego na stan , które polegają na ciągłych, wiarygodnych strumieniach z czujników zamiast okresowych kontroli ręcznych.
Fabrico to fundament danych w czasie rzeczywistym, który zamienia czystą telemetrię z hali w działanie. Dostarcza monitorowanie OEE i produkcji w czasie rzeczywistym oraz gotowe do użycia CMMS z zleceniami roboczymi, majątkiem, harmonogramowaniem prewencyjnym i zarządzaniem częściami zamiennymi, wszystko zbudowane w UE z lokalizacją danych w UE.
Gdy maszyna nie ma PLC ani dostępnego tagu sieciowego, który mógłby zasilać strumień Sparkplug, widzenie komputerowe Fabrico odczytuje sprzęt bezpośrednio, dzięki czemu nawet zasoby legacy przyczyniają się do Twoich wskaźników dostępności i wydajności.
Filozofia świadomości stanu i samoopisania stojąca za Sparkplug B to dokładnie dyscyplina, którą Fabrico stosuje do danych OEE : wiedzieć, co oznacza każdy sygnał i wiedzieć, kiedy mu ufać, zanim trafi do raportu.
Nie. Sparkplug B działa na standardowym MQTT i korzysta z kompatybilnego brokera. Dodaje zdefiniowaną przestrzeń nazw tematów, format ładunku w Protocol Buffers oraz cykl życia certyfikatów uruchomienia/zakończenia. Nadal potrzebujesz brokera MQTT pod spodem; Sparkplug B to warstwa konwencji, która sprawia, że wiadomości są interoperacyjne i samoopisujące.
Certyfikat uruchomienia (NBIRTH lub DBIRTH) jest publikowany raz, gdy urządzenie się łączy i zawiera kompletny schemat: każdą nazwę metryki, typ danych i wartość początkową. Normalne wiadomości danych (NDATA lub DDATA) są publikowane później przez wyjątek i zawierają tylko wartości, które uległy zmianie. Konsumenci używają certyfikatu uruchomienia, aby interpretować każdą kolejną wiadomość danych bez zewnętrznego mapowania.
Pośrednio, ale znacząco. Dzięki jawności stanu przez certyfikaty zakończenia pozwala systemom odróżnić rzeczywistą stabilną wartość od offline'owego czujnika, co zapobiega zawyżaniu dostępności przez przestarzałe odczyty. Dzięki typowaniu każdej metryki eliminuje niejednoznaczność jednostek i formatów w danych wejściowych dotyczących wydajności i jakości. Czystsze, świadome stanu dane oznaczają, że obliczone OEE odzwierciedla rzeczywistość.
Chcesz zobaczyć, jak samoopisująca się, świadoma stanu telemetria napędza OEE na żywo bez indywidualnej integracji dla każdej maszyny? Zamów demo Fabrico i obserwuj, jak Twoje rzeczywiste dane produkcyjne stają się wiarygodną podstawą.
Zaloguj
Blog
