Sparkplug B е отворена спецификация, която работи върху MQTT и точно определя как индустриалните устройства се анонсират, описват своите данни и сигнализират кога спират да са онлайн, превръщайки един универсален комуникационен канал в самоописващ се, със състояние телеметричен стандарт.
Plain MQTT е лек транспорт за publish/subscribe: пренася байтове от публикуващ към всеки абонат, но не казва какво означават тези байтове, в какви единици са или дали изпращачът е все още на линия. Sparkplug B запълва тази празнина.
Създаден под егидата на Eclipse Foundation и сега поддържан като отворен стандарт, той дава на всеки таг дефиниран тип данни, известна структура на топика и жизнен цикъл, така че всеки потребител, от OEE табло до хисториан, може да интерпретира полезното съдържание без ръчно създадена интеграционна карта.
Защо plain MQTT не е достатъчен за фабричния под MQTT е проектиран за ограничени, ненадеждни мрежи, което е точно причината да работи добре във фабриките. Но извън кутията остават три трудни проблема. Първо, именните пространства на топиците са без правила: един интегратор публикува на plant1/line3/oven/temp, друг на Oven_Temp_C, и нищо не налага консистентност.
Второ, полезните натоварвания са непрозрачни; стойност „72“ може да означава Целзий, Фаренхайт или код за грешка, и абонатът няма начин да разбере. Трето, MQTT няма вградено понятие за свежест на данните. Ако шлюз изгуби захранване, последната публикувана стойност остава в брокера и таблото продължава да показва остарялa стойност сякаш машината работи нормално.
На фабричния под тези пропуски не са академични. Остарели или неправилно означени данни корумпират изчисленията за наличност и производителност, затова отборите, които се интересуват от обща ефективност на оборудването (OEE), не могат да разчитат само на сурово MQTT. Sparkplug B е написан специално, за да затвори тези дупки в операционните технологии.
Свидетелства за раждане и смърт: осъзнаване на състоянието по дизайн Подписващата характеристика на Sparkplug B е жизненият цикъл със свидетелства. Когато граничен възел или устройство се свърже, то публикува свидетелство за раждане (NBIRTH за възел, DBIRTH за устройство). Това съобщение не е просто поздрав.
То съдържа пълния списък с всеки показател (metric), който устройството някога ще публикува, всеки със своето име, тип данни и начална стойност. Абонат, който получи свидетельството за раждане, незабавно познава цялата схема, без външен конфигурационен файл. Свидетелството за смърт е огледално на това.
Всеки Sparkplug клиент регистрира Last Will and Testament при брокера по време на връзка. Ако устройството отпадне от мрежата неелегантно, самият брокер публикува предварително регистрираното NDEATH от името на устройството. Потребителите моментално разбират, че източникът е офлайн и могат да маркират данните му като остарели вместо да вярват на замръзнала последна стойност.
Това е истинско осъзнаване на състоянието: системата знае разликата между „стойността е легитимно стабилна“ и „изпращачът е изчезнал“. За всеки, който изчислява показатели за надеждност като MTBF и MTTR, разграничаването на реално спиране от прекъсване на комуникацията е разликата между достоверен и фиктивен резултат.
Структура на полезното съдържание: как данните стават самоописващи се Полезните натоварвания в Sparkplug B са кодирани с Google Protocol Buffers, компактен двоичен формат. Всяко полезно съдържание носи времева отметка, номер на последователност и масив от метрики.
Метриката е именован, типизиран обект, така че температурно отчитане пътува като структурирана единица с явен тип Int, Float или Boolean, вместо като нееднозначен низ. Именният простор на топиците е също толкова дисциплиниран. Всеки Sparkplug топик следва фиксирания модел spBv1.0/group_id/message_type/edge_node_id/device_id.
Понеже структурата е стандартизирана, всеки инструмент може да се абонира с един универсален шаблон и автоматично да открие всяка група, възел и устройство в мрежата.
Този модел „съобщи само изключенията“ също има значение: след свидетелството за раждане устройствата публикуват само стойности, които са се променили (NDATA и DDATA съобщения), което намалява значително трафика по ограничените връзки, често срещани във фабриките.
Самоописващата се природа означава, че основата от данни остава достатъчно чиста, за да храни последващ анализ, от диаграми за статистически процесен контрол до Парето анализ на причините за престой. Пример на практика: трафик и OEE от Sparkplug данни Представете си бутилираща линия с 40 сензора, всеки от които отчита число с плаваща запетая.
При наивна схема на опитване може да публикувате всички 40 стойности всяка секунда: 40 съобщения в секунда, или 3 456 000 съобщения на ден. С report-by-exception на Sparkplug B приемете, че само 5 от 40-те метрики реално се променят във всяка дадена секунда (температурата се мени бавно, повечето състояния са стабилни).
Това е приблизително 5 DDATA съобщения в секунда плюс едно свидетелство за раждане при стартиране: около 432 000 съобщения на ден, намаление с около 87 процента в обема на съобщенията. В случай на клетъчна или споделена фабрична връзка това е разликата между наситен канал и наличен резерв. Сега възвръщането за OEE.
Да кажем, че свидетелствата за раждане и смърт на линията показват, че тя е била действително свързана и работеща 400 минути от 480-минутна смяна. Наличността е 400 / 480 = 83,3 процента.
Счетоводните метрики отчитайте 9 000 произвеждани единици срещу идеална скорост 25 единици в минута през тези 400 минути (10 000 идеални), така че производителността е 9 000 / 10 000 = 90 процента. Качествените метрики показват 8 730 годни единици, така че качеството е 8 730 / 9 000 = 97 процента.
Умножете ги: 0,833 x 0,90 x 0,97 = 72,7 процента OEE. Всеки вход в това изчисление идва от самоописващи се, със състояние Sparkplug метрики, без предположения дали прекъсване е истинско спиране или остаряло отчитане.
Къде Sparkplug B се вписва в по-широкия стек Sparkplug B често се съчетава с архитектура за унифицирано именуване, където един брокер става реалният източник на истината в реално време и всяко приложение както публикува, така и консумира от него.
Той допълва, а не замества съществуващите системи: данните могат да произхождат от PLC-та, от SCADA слоеве или от независими гранични шлюзове и след това да текат към CMMS за тригери за поддръжка или към мониторинг табла за видимост на живо.
Тъй като форматът е отворен и самоописващ се, той също подкрепя стратегии за поддръжка, базирана на състоянието, които разчитат на непрекъснати, достоверни сензорни потоци вместо на периодични ръчни проверки. Къде се вписва Fabrico Fabrico е основата за данни в реално време, която превръща чистата телеметрия от цеха в действие.
Тя доставя мониторинг в реално време на OEE и производството и готов CMMS с работни нареждания, активи, профилактично планиране и управление на резервни части, всичко разработено в ЕС със съхранение на данните в ЕС.
Когато машина няма PLC или достъпен мрежов таг за подхранване на Sparkplug поток, компютърното зрение на Fabrico чете оборудването директно, така че дори наследени активи допринасят за вашите показатели за наличност и производителност.
Философията за осъзнаване на състоянието и самоописване зад Sparkplug B е точно дисциплината, която Fabrico прилага към OEE данните: знайте какво означава всеки сигнал и знайте кога може да се довери на него, преди той да стигне до отчет. Често задавани въпроси Sparkplug B заместител ли е на MQTT? Не.
Sparkplug B работи върху стандартно MQTT и използва съвместим брокер. Той добавя дефинирано именнов пространство на топиците, формат на полезното съдържание с Protocol Buffers и жизнения цикъл със свидетелства за раждане/смърт. Все още ви е нужен MQTT брокер под слоя; Sparkplug B е конвенционният слой, който прави съобщенията интероперабилни и самоописващи се.
Каква е разликата между свидетелство за раждане и нормално данни съобщение? Свидетелството за раждане (NBIRTH или DBIRTH) се публикува веднъж при свързване на устройството и съдържа пълната схема: всяко име на метрика, тип данни и начална стойност.
Нормалните данни съобщения (NDATA или DDATA) се публикуват след това по изключение и носят само стойностите, които са се променили. Потребителите използват свидетелството за раждане, за да интерпретират всяко последващо данни съобщение без външно картографиране. Подобрява ли Sparkplug B точността на OEE? Непряко, но значително.
Като прави състоянието явно чрез свидетелствата за смърт, той позволява на системите да различават истинска стабилна стойност от офлайн сензор, което предотвратява надуване на наличността от остарели отчитания. Като типизира всяка метрика, той премахва неяснотата относно единици и формат в входните данни за производителност и качество.
По-чистите, със състояние входни данни означават, че изчисленото OEE отразява реалността. Искате ли да видите как самоописваща се, със състояние телеметрия управлява жив OEE без персонализирана интеграция за всяка машина? Запазете демонстрация на Fabrico и наблюдавайте как вашите реални производствени данни стават достоверна основа.
Вход
Блог
