Основни изводи
Повечето производствени халета имат изобилие от данни. PLC-тата публикуват стойности на тагове на цикъл под секунда. SCADA ги агрегира и визуализира. ERP системите получават броя на произведените единици и потреблението. Къде настъпва разпадът е между тези слоеве: спиране на линията генерира преход на таг в PLC, става „събитие за престой“ в SCADA, обобщава се като „загубено производство“ в ERP и нито едно от тези три представяния не се съгласува какво е било събитието, кога е започнало или на кой актив принадлежи.
Резултатът е, че никой не може ясно да отговори на прости оперативни въпроси. „Колко престой причини активът L3-PKG-02 вчера?“ има три различни отговора в зависимост от това коя система попитате. Инструментът за OEE, CMMS и ERP всяка имат свои дефиниции, а ръчното им свързване е това, което поглъща сутрините на ръководителя на поддръжката.
Честото изкушение, особено в проекти, продавани като „интеграция Индустрия 4.0“, е да се подават данните от PLC директно в ERP. Това изглежда като проста интеграция. Почти винаги се проваля по три причини.
PLC-тата излъчват хиляди преходи на тагове в минута. ERP системите са проектирани да получават няколкостотин записа на ден на завод. Вкарването на сурови PLC данни в ERP или удавя базата данни, или принуждава агресивна агрегация на ръба — а точно тази агрегация унищожава резолюцията, от която OEE и CMMS се нуждаят.
PLC познава таговете. ERP познава разходните центрове. Никоя от тях не знае йерархията на активите по начина, по който поддръжката я дефинира (линия → позиция → актив → компонент). Без явна йерархия между тях не можете да отговорите „кой актив причини това спиране“ от записите в ERP.
Събитията в PLC са с прецизност до милисекунди. Събитията в ERP обикновено са с прецизност до деня. Спиране, което е започнало в 14:03:22 и е свършило в 14:08:45, се превръща в „5 минути престой на 27 юни“ до момента, в който ERP го види. Тази загуба на прецизност е причината повечето OEE отчети, базирани на ERP, да са неизползваеми.
Решението е да се вмъкне един слой между PLC/SCADA нивото и ERP. Слойът има четири задачи.
Всяко събитие — старт, стоп, брак, смяна на серията — получава едно и също име във всяка система. Тук на практика живее таксономията на класовете на загубите от статията за производствените KPI. Без нея аналитиките надолу по веригата никога не се стабилизират.
Оперативният слой е единственият източник на истината за „какво е актив“. Линии, позиции, активи и компоненти се дефинират тук и се картографират към PLC тагове от една страна и към ERP разходни центрове от другата. Когато поддръжката създаде работна поръчка, тя сочи към актив в тази йерархия — не към таг и не към разходно центро.
Всяко събитие, което слойът съхранява, получава времева маркировка към един часовник, обикновено UTC с прецизност до милисекундата, независимо кой PLC, SCADA или операторски интерфейс го е произвел. Проблемите със часови зони и дрейф се решават при вкарване на данните, не в таблата за управление.
ERP получава сумираната, финансово пригодена картина: производство по смени, брак, престой по причини — на дневна или сменна база. Детайлите с висока резолюция остават в оперативния слой, където OEE, CMMS и анализът на коренните причини се нуждаят от тях. Вижте свързаната статия за анализ на коренните причини защо именно този детайл движи подобренията.
Типична референтна архитектура за среден пазар:
Причината оперативният слой да трябва да хоства и OEE, и CMMS е, че йерархията на активите се споделя. Ако OEE е в един инструмент със своя йерархия, а CMMS е в друг инструмент с различна йерархия, цялата идея за един източник на истината се губи. Единна система за управление на работни поръчки, стояща върху същите данни като OEE двигателя, по подразбиране предотвратява това разминаване.
Грешката, която правят заводите, е да започнат с интеграцията към ERP, защото това изглежда като „реалното“ доставяне. Правилната последователност е обратната.
Започването първо с ERP интеграцията гарантира преизграждане, защото оперативните дефиниции все още са в движение и всеки ERP запис ще трябва да бъде преизпратен, докато тези дефиниции се стабилизират.
Описаният по-горе оперативен слой за данни е точно това, което представлява Fabrico: единна платформа, която хоства йерархията на активите, OEE потока от събития и работните поръчки на CMMS върху една и съща база данни, с edge конектори за PLC страната и планирани експорти за ERP страната. Причината да предлагаме единен продукт, а не два отделни, е, че пропастта OT/IT се свива, когато OEE и CMMS споделят йерархия, и остава отворена, когато не го правят. За да видите как би изглеждало това спрямо вашите собствени данни от линия, заявете демонстрация.
Не. Оперативният слой за данни седи върху съществуващия OT стек чрез edge конектор. PLC/SCADA слоят продължава да прави това, което прави; новият слой просто добавя нормализиран изглед над него.
Data lake без оперативен слой за данни съдържа високорезолюционни таг данни без семантика на събитията. Можете да изградите табла върху него, но не можете да задвижвате работни поръчки, изчисления на OEE или анализ на коренните причини без първо да реконструирате речника на събитията и йерархията на активите — точно това прави оперативният слой. Пропускането му просто отлага проблема.
Ако заводът вече има MES, MES често поема част от задачите на оперативния слой за данни, особено речника на събитията. Архитектурата работи по същия начин: MES захранва оперативния слой за данни (или самият MES е оперативният слой, ако покрива OEE и CMMS), който след това се агрегира към ERP.
От екипа на завода, който познава активите — не от ИТ. Оперативният слой трябва да направи йерархията редактираща се от екипите по поддръжка и производство без участието на разработчик, иначе тя се изкривява за едно тримесечие.
Речникът на събитията. Ако класовете на загубите не са стабилни между линиите, всяка аналитика и всяко правило надолу по веригата става ненадеждно. Посветете повече време, отколкото изглежда разумно, на таксономията през първата седмица.
Вход
Блог
