OEE и Plant Historian: къде принадлежат данните от времеви серии

Ключови изводи

• Historian = високочестотна база данни за времеви серии, съхраняваща всеки PLC таг с подсекундна каденция.
• OEE платформите се нуждаят от данни с качество на historian: всяка промяна на състоянието, всеки цикъл, всяка грешка, с времева отметка и възможност за извличане.
• Можете да работите с OEE без отделен historian, ако самата OEE платформа съхранява данните с historian-каденция. Много платформи го правят.
• Често използвани отделни historianc-и: OSIsoft PI (сега AVEVA PI), Aspen IP21, Honeywell PHD, Wonderware Historian. Еквиваленти в облака: InfluxDB, TimescaleDB, AWS Timestream.
• Заводи с вече наличен historian обикновено подават данни към OEE платформата от него; заводите без такъв обикновено позволяват OEE платформата да служи като historian за производствените данни.

Кратък отговор: Заводският historian е високочестотна база данни за времеви серии, която съхранява всеки PLC таг с подсекундна резолюция. OEE платформите или четат от наличен historian, или сами съхраняват данните с historian-каденция. Въпросът не е „имам ли нужда от historian или OEE платформа“, въпросът е „къде живеят данните от времеви серии и достатъчно ли е тяхното разделение, за да поддържа OEE аналитика.“ Вижте също OEE vs Utilization.

Какво представлява historian

Historian е специализирана база данни, оптимизирана за времеви серии, милиони тройки (времева отметка, таг, стойност) в секунда, съхранявани с години, извличаеми за всеки времеви прозорец. Типични приложения:

• Графики на процесни тенденции през дълги времеви прозорци.
• Регулаторна проследяемост за партидни записи.
• Анализ на надеждността на поведението на оборудването.
• Разследване на коренната причина при отклонения в качеството.

Често използвани отделни historianc-и: OSIsoft PI (сега AVEVA PI), Aspen IP21, Honeywell PHD, Wonderware Historian (сега AVEVA Insight). В облака / с отворен код: InfluxDB, TimescaleDB, AWS Timestream, Azure Time Series Insights.

Защо OEE се нуждае от данни с качество на historian

OEE математиката изисква прецизно проследяване на състоянията във времето:

• Промените в работното състояние с времеви отметки до секундата.
• Броят на циклите записан за всяка детайлна единица, а не агрегирано на час.
• Кодовете за грешки записани в момента на възникване, а не когато някой ги въведе по-късно.
• Сигналите за качество свързани с цикъла, от който произхождат.

Ако липсва някое от тези, OEE става приблизителен. Historian (или сторидж с качество на historian вътре в OEE платформата) е това, което прави OEE достатъчно прецизен за вземане на решения.

Две архитектури

Архитектура A: посветен historian подава данни към OEE. Заводът има наличен PI или InfluxDB. OEE платформата се абонира за релевантните тагове и изчислява OEE в реално време, а historian-ът служи като дългосрочно хранилище.

Предимства: дългосрочното съхранение вече е решено. Много инструменти могат да четат от един и същ historian.

Недостатъци: още една система за поддръжка. Добавена латентност от кръглия път.

Архитектура B: OEE платформата е historian за производствените данни. Няма отделен historian. OEE платформата улавя PLC сигналите директно и ги съхранява вътрешно с висока каденция.

Предимства: по-опростена стека. По-ниска латентност.

Недостатъци: дългосрочното съхранение може да е ограничено. Други потребители (инженеринг, лаборатория) може да не могат лесно да правят заявки.

Повечето малки и средни заводи се справят добре с архитектура B за производствени данни. Заводи със задължения за регулаторна проследяемост (фарма, хранителна промишленост) обикновено се нуждаят от отделен historian независимо.

Какво да търсите в слоя за данни на OEE платформата

• Нативна база за времеви серии. Не обща релационна база данни, пригодена по-късно. Специализирани хранилища за времеви серии (InfluxDB, TimescaleDB, Cassandra със схема за времеви серии) обработват правилно обема.
• Конфигурируем период на съхранение. Колко дълго се пазят суровите данни? Колко дълго се пазят агрегатите?
• Намаляване на детайлността (downsampling). Автоматично обобщаване до по-ниска резолюция с възрастта на данните, за да се поддържа управляем обем на съхранение.
• API за заявки. SQL, Flux или REST, които инженерите да използват без да минават през UI-то на OEE платформата.
• Интеграция с външни historianc-и. Дори ако платформата съхранява собствените си данни, тя трябва да може да чете от PI / Aspen / Honeywell за заводи, които ги имат.

Чести грешки

1. Обрязване на производствените данни с ниска честота на семплиране. 1-минутните средни стойности пропускат микростопове и кратки цикли. OEE, изградено върху 1-минутни агрегати, е фикция.

2. Третиране на SCADA базата данни като historian. SCADA базите са оптимизирани за текущото състояние, а не за дългосрочни времеви серии. Те се провалят в мащаб.

3. Пропускане на планиране на периода на съхранение. Три години високочестотни PLC данни са голям обем. Планирайте downsampling от първия ден.

4. Липса на управление на таговете. Добавянето на тагове без стандартни имена прави historian-а неизползваем. Въведете конвенции за именуване преди да мащабирате.

Как OEE платформите се свързват с PI и подобни

За заводи с PI, OEE платформата обикновено е PI клиент, абониран за релевантните тагове. PI продължава да е системата за запис за времеви серии; OEE платформата изчислява и представя OEE върху него.

За заводи без PI, OEE платформата често е фактическият historian за производствените данни, което е достатъчно за повечето случаи, но не замества PI за процесен инженеринг или регулаторни архиви.

Модулът за OEE на Fabrico се доставя с вътрешно хранилище за времеви серии и се интегрира с външни historians (PI, InfluxDB, TimescaleDB) за заводи, които ги имат, давайки на екипа гъвкавост в слоя за данни.

Вижте как Fabrico улавя това автоматично, проучете OEE за производството или запишете демо.

Свързано четиво

• OEE vs Utilization
• OEE и ISO 22400
• OEE за партидно производство
• OEE vs Availability

Често задавани въпроси

Имам ли нужда от посветен historian, ако имам OEE платформа?

Обикновено не за самите производствени данни. Да, ако имате изисквания за регулаторна проследяемост, множество потребители/системи, или нужди на процесния инженеринг, които надхвърлят OEE.

Мога ли да използвам обикновена SQL база данни като historian?

Работи за малък мащаб. В индустриален мащаб (хиляди тагове, резолюция в милисекунди, години съхранение) се нуждаете от специализирано хранилище за времеви серии.

Колко дълго трябва да пазя суровите данни?

Зависи от употребата. Отстраняване на проблеми в производството обикновено изисква 30, 90 дни сурови данни; дългосрочните тенденции могат да се пазят като понискорезолюционни агрегати.

InfluxDB същото ли е като PI?

И двете са бази данни за времеви серии. PI е дългогодишният индустриален стандарт с добре развити интеграции. InfluxDB е с отворен код/популярна в облачните и модерните стекове. И двете работят за OEE.

Може ли OEE платформата да записва обратно в historian-а?

Някои могат. Полезно за съхраняване на изчислените OEE стойности заедно със суровите PLC тагове, така че външни потребители да могат да четат OEE от един и същ източник.