Отчитането при изключение е метод за събиране на данни, при който машина или крайно устройство изпраща стойност само когато тя се промени с повече от определен праг, вместо да предава четения на фиксиран интервал. Алтернативата, полингът, иска текущата стойност от всяко устройство на редовни интервали, независимо дали нещо се е променило. На модерен заводски под с стотици тагове, идващи от PLC, сензори и визионни системи, разликата между тези два подхода определя дали вашата мрежа остава здрава или се удавя в излишен трафик. Тази статия разглобява отчитането при изключение, техниките на мъртвата зона и докладването при промяна на стойността зад него, и как да мащабирате машинните данни икономично, без да изпускате сигнала, който има значение.
Полингът е по подразбиране в много стари SCADA и historian инсталации, защото е прост: главно устройство заявява всеки таг в цикъл, например веднъж в секунда, и записва каквото се върне. Проблемът е, че повечето процесни стойности са стабилни повечето време. Температура в съд, която стои на 72.0 градуса в продължение на десет минути, при полинг под секунда все пак генерира 600 идентични четения. Умножете това по всеки таг на линия и плащате за канална честотна лента, съхранение и CPU на периферията, за да премествате данни, които не казват нищо ново.
Полингът също мащабира зле. Всяко ново устройство удължава цикъла на полинг, така че или скоростта на сканиране забавя, или разделяте натоварването между повече канали и шлюзове. При ограничени връзки (мобилни, LoRa или споделен индустриален VLAN) фиксираният трафик на полинга може да избута четенията, които наистина ви интересуват. Разбирането на вашия истински профил на данните е предпоставка за всяко усилие за наблюдение в реално време — същото както разбирането на загубите е предпоставка за подобряване на общата ефективност на оборудването.
Отчитането при изключение (често наричано RBE или събитийно-ориентирано докладване) обръща модела. Крайното устройство запазва последната предадена стойност и непрекъснато я сравнява с текущото четене. То изпраща актуализация само когато новото четене пресече определен праг. Нищо не се променя по линията, докато процесът е стабилен, а в момента в който стойността се движи, промяната се разпространява незабавно. Резултатът е трафик, пропорционален на това колко реално варира процесът ви, а не на това колко тага имате или колко бързо полингът е настроен.
Два механизма правят това надеждно:
Повечето реализации комбинират и двете: мъртвата зона притиска шума, логиката COV се грижи за реалното докладване, а сигнал за живот (heartbeat) или настройка за максимално време гарантират периодична актуализация дори по време на дълги стабилни периоди, така че системите надолу по веригата да знаят, че връзката е жива.
Мъртвата зона обикновено се изразява като абсолютна стойност или процент от обхвата на сигнала. Да кажем, че имате температурен сензор с обхват 0 до 200 °C, който подава аналогов сигнал с около 0.3 °C електрически шум. Настройвате мъртва зона от 1.0 градус.
Сега аритметиката за пропускателната способност. При полинг от една секунда този единичен таг произвежда 86 400 съобщения на ден, независимо от поведението. Да предположим, че температурата действително пресича мъртвата зона от 1.0 градус около 40 пъти в час по време на производство, което е 960 събития на ден, плюс защитен heartbeat на всеки 15 минути добавя 96 съобщения. Отчитането при изключение изпраща приблизително 1 056 съобщения на ден спрямо 86 400 при полинга — намаление от около 98.8 процента. При 300 тага с подобни профили преминавате от 25.9 милиона съобщения дневно до около 317 000, като не губите нито една от значимите преходи.
Лостът е широчината на мъртвата зона. Твърде широка и изглаждате реални събития; твърде тясна и шумът просмуква. Настройте всеки таг към неговото ниво на шум и най-малката промяна, която има бизнес значение, по начина, по който добре изграден контролен план задава допуски за всяка характеристика, а не едно универсално правило.
Страхът при отчитане при изключение е да изпуснете нещо важно. Избягвате това като зададете мъртвата зона целенасочено, а не на око:
Направено по този начин, отчитането при изключение не е загубно. Запазвате всеки преход, който пресича вашия определения праг за значимост, и просто спирате да плащате за равните линии между тях. За работа по коренни причини на упорити загуби преходите са точно това, което искате, а Парето-анализ на събитията при изключение извежда най-големите нарушители по-бързо, отколкото претърсването на полинговия шум.
Това не е избор "всичко или нищо". Прагматична архитектура използва и двата подхода:
Компромисите, които да претеглите: отчитането при изключение изисква логика на периферията за задържане на последните стойности и оценка на мъртвите зони, и може да генерира внезапни пикове в трафика когато процесът рязко се промени. Полингът е много прост и детерминиран по отношение на времето, но е неефективен и лошо мащабируем. Много SCADA хисториани поддържат и двата модела на таг, което ви позволява да съпоставите метода със сигнала. Същото многослойно мислене, което разделя реактивната от проактивната поддръжка, важи и тук: използвайте по-евтиния събитийно-ориентиран метод по подразбиране и запазете по-тежкия метод с фиксирана честота там, където той оправдава разхода. Потоковете от събития също така се вписват добре в поддръжката, базирана на състоянието, където преминаването на прага е точно тригерът, на който действате.
Fabrico е основата за данни в реално време, която седи върху какъвто и да е метод за събиране, използван във вашия цех. Тя поема живи машинни и производствени сигнали за реално OEE и мониторинг на производството, и може да чете машини чрез компютърно зрение, където няма PLC за полинг или за изпращане на събития — което често е случаят при по-стари или самостоятелни активи. Този визионен път ви дава поток в стил отчитане при изключение (брой цикли, спирания, смени на състояния) от оборудване, което никога не е било инструментализирано за IIoT. От страна на поддръжката, Fabrico е готова за полето CMMS, покривайки работни нареждания, активи, превантивно планиране и резервни части, така че събитията, които вашият слой за данни изведе, да се превръщат директно в действия. Fabrico е изградена в ЕС с местопребиваване на данните в ЕС, което има значение, когато машинните ви данни не могат да напускат региона. Разгледайте прегледите на OEE мониторинга и CMMS, за да видите как частите се свързват.
Не, ако мъртвата зона е настроена правилно. Запазвате всяка промяна, която пресича определения от вас праг за значимост, и само потискате движения по-малки от него, които по дефиниция са или шум, или под нивото, на което някой предприема действие. Задължителен интервал за heartbeat гарантира периодично четене дори по време на дълги стабилни периоди, така че историците и системите надолу по веригата винаги да имат скорошна опорна точка и да могат да потвърдят, че връзката е жива.
Докладването при промяна на стойността е правилото, което задейства актуализация, когато стойност се различава от последно отчетената. Мъртвата зона е толерансната лента, която определя колко голяма трябва да е тази разлика, за да има значение. На практика те работят заедно: мъртвата зона филтрира трептенето и аналоговия шум, а логиката за промяна на стойността обработва самото предаване, когато сигналът напусне зоната.
Да, и повечето добре проектирани системи го правят. Използвайте отчитане при изключение за мнозинството непрекъснати аналогови тагове и за смени на състояния, и запазете полинга за случаи, в които ви трябва гарантирана стойност с фиксиран ритъм, като регулаторно логване или за наследени устройства, които не могат да подават събития. Много хисториани и шлюзове ви позволяват да задавате метода на таг, така че да съпоставите всеки сигнал с подходящия подход.
Готови ли сте да превърнете ефективните машинни данни в реално OEE и действия за поддръжка? Запазете демонстрация на Fabrico и вижте как жива база данни, включително визия за машини без PLC, се мащабира по вашия цех.
Вход
Блог
