Архитектура, базирана на събития, за производството е модел на данни, при който машините публикуват съобщение само когато нещо значимо се промени, вместо да бъдат питани за своя статус отново и отново на фиксиран интервал.
На съвременния производствен цех стотици сензори, ПЛК и контролери искат да докладват състояние, и начинът, по който премествате тези данни, определя дали вашите табла са наистина в реално време или тихо изостават с минути. Полингът, традиционният подход, означава, че всяко устройство се запитва по график независимо дали нещо се е случило.
Дизайнът, базиран на събития, обръща потока: източникът натиска ъпдейт в момента на възникване, което мащабира много по-добре с добавянето на машини.
Полингът изглежда прост. Сървър пита всяко устройство „Каква е вашата стойност сега?“ на всеки няколко секунди, записва отговора и повтаря. Проблемът е, че повечето от тези отговори са идентични с предишния. Мотор на транспортьор, който работи непрекъснато в продължение на час, все още бива питан стотици пъти, и всяка заявка консумира мрежова честотна лента, процесорно време и запис в база данни, въпреки че състоянието не се е променило.
Разходът се натрупва по три начина. Първо, латентността е ограничена от интервала на полинга: ако полвате на всеки 5 секунди, микростоп, който започне една милисекунда след полинга, е невидим почти 5 пълни секунди. Второ, мрежовото натоварване расте линейно с броя устройства по честотата на полинга.
Трето, генерирате огромни обеми ненужни данни, които увеличават обема на съхранение и забавят всяко запитване, което трябва да ги прегледа. За всеки, който следи общата ефективност на оборудването ( OEE ), тези пропуснати кратки спирания директно подценяват загубите в наличността ви.
Системите, базирани на събития, се строят върху две взаимно подсилващи се идеи:
Леки протоколи като MQTT (често в комбинация със спецификацията Sparkplug за индустриални полезни натоварвания) са проектирани именно за това. Брокерът седи между периферията (edge) и предприятието, така че добавянето на нов потребител, например приложение за качество, следящо за нарушения на правилата на Нелсън , не изисква никакви промени от страна на машината.
Това се различава от моделът заявка-отговор на традиционна SCADA система, където логиката за полинг и картата с тагове са стриктно свързани с всеки клиент.
Да приемем завод с 200 машини, всяка експонираща 50 тага, и интервал на полинг 1 секунда. Полингът засяга всеки таг във всеки цикъл:
Сега преминете към отчитане по изключение при същия 2-процентов темп на промяна, плюс heartbeat (периодичен сигнал за живот) веднъж в минута на машина:
Версията, базирана на събития, не само намалява натоварването, тя подобрява и вярноста на данните. Понеже променящите се 2 процента се изпращат в мига, в който се случат, латентността пада от „до 1 секунда“ до милисекунди, и най-накрая улавяте подсекундните събития, които полингът изглажда. По-малко записи означава и по-бърз Парето анализ на основните причини за простоите.
Производствените метрики са толкова честни, колкото и данните, които ги захранват. Микростоповете под 5 минути са класическа слепа точка и те директно се отразяват на загубите ви по скорост и наличност. Когато полингът изглажда 3-секунден засичане, което се повтаря 400 пъти на смяна, губите 20 минути документиран престой, който никога не достига до вашия процент брак или анализ на пропускателната способност.
Потоците от събития също носят точни времеви марки от източника, така че можете да реконструирате точната последователност при отказ: сработил сензор, отворена защита, спрян мотор, оператор потвърдил. Тази подредена времева линия е суровият материал за смислени MTBF и MTTR метрики за надеждност и за стесняване на цикъла между засечено състояние и реакцията на поддръжката, която трябва да предизвика.
Събитие е ценно само ако нещо го потреби. Най-полезният долупоток често е система за поддръжка. Когато вибрационен праг е преминат или машина публикува код за грешка, абонат може автоматично да отвори работна поръчка, да прикачи данните от събитието и да я маршрутизира към правилния техник. Това е практичният мост между сигналите от цеха и CMMS.
Така е и начинът, по който екипите преминават от чисто реактивни навици към дисциплините, описани в реактивна срещу проактивна поддръжка и поддръжка, базирана на състоянието . Слоят, базиран на събития, доставя сигнала за състояние; вашите правила и работни потоци решават какво да се прави с него.
Забележете, че превръщането на суровите събития в надеждни прогнози за повреди остава напреднала, модели-наситена дисциплина в целия отрасъл, нещо, което само архитектурата не може да гарантира.
Fabrico е основата за данни в реално време за този модел. Той доставя мониторинг на OEE и производството в реално време, така че събитията, излизащи от вашия цех, да се превърнат в живи числа за наличност, производителност и качество, а не в отчети след факта.
Когато машина няма ПЛК, откъдето да публикува, Fabrico добавя компютърно зрение на машината, за да генерира събитийните промени на състоянието директно, което разширява видимостта, базирана на събития, до оборудване, което иначе не би могло да бъде полвано изобщо.
От страна на действието, Fabrico е готов за полева употреба CMMS: работни поръчки, регистри на активи, планиране на превантивна поддръжка и управление на резервни части, така че засечено състояние да може да стане планирана или изпратена задача.
Fabrico е разработено в ЕС с резидентност на данните в ЕС, което има значение, когато потокът ви от събития носи чувствителни оперативни данни. Можете да видите как мониторингът и поддръжката се свързват в прегледа на MES и OEE решение и в прегледа на CMMS решение .
Не универсално. За няколко бавно променящи се тага, където няколко секунди латентност са приемливи, полингът е по-прост за изграждане и разбиране. Дизайнът, базиран на събития, печели решително с увеличаване на мащаба, броя устройства и нуждата от подсекундна вярност, описание, което пасва на повечето съвременни фабрики, следящи кратки спирания и детайлни причини за загуби.
Затова и сигналът за живот е задължителен. Всяко устройство публикува периодично съобщение за ливнес, за да може системата да разграничи „стойността не се е променила“ от „устройството е офлайн“. Буферирането на периферията със съхранение и препредаване допълнително предпазва от кратки мрежови прекъсвания, като задържа съобщенията до възстановяване на връзката.
Да. Машините без ПЛК или достъпни тагове не могат да публикуват сами, но компютърното зрение може да наблюдава машината и да изпраща събития за промяна на състоянието (работи, спряна, блокирана) въз основа на това, което вижда. Това интегрира наследено и самостоятелно оборудване в същия поток в реално време като вашите свързани активи.
Готови ли сте да превърнете събитията от цеха в жив OEE и автоматични работни поръчки? Запазете демонстрация на Fabrico и вижте мониторинг в реално време и готов за полева употреба CMMS, работещи върху вашите машини.
Вход
Блог
