Является ли конвергенция IT/OT просто модным термином?

Итак, является ли «конвергенция ИТ/ОТ» просто еще одним модным термином?

Вы можете возразить, что это так. Всякий раз, когда кому-то приходит в голову новая идея, делается попытка сделать ее запоминающейся и сделать так, чтобы она звучала как «лучшая новая вещь после нарезанного хлеба». Так что, конечно, кто-то придумает броскую фразу, которая должна вдохновить на изменения и которую они могут использовать в маркетинге.

Дело, однако, в том, что эта «конвергенция» ИТ и ОТ на самом деле является просто следующим шагом к тому, чтобы сделать данные пригодными для использования.

Что такое конвергенция ИТ/ОТ?

Некоторое время назад мы увидели начало автоматизации производства. Автоматизированное оборудование было разработано для выполнения определенной функции, которая должна была выполняться со скоростью или уровнем мощности, недостижимым для человека. Но когда автоматизированное оборудование вышло из строя, инженеру по управлению необходимо было войти в систему, чтобы определить, что пошло не так. Для этого требовалось зайти в регистры систем ПЛК, чтобы найти признаки сбоя. Это было началом использования данных операционных технологий. .

Наличие некоторых данных, ведущих к моменту отказа, было полезно для диагностики — чтобы заранее увидеть, что произошло. В результате системы ПЛК начали использовать архиваторы для хранения более длинных потоков данных от датчиков, нагревателей и приводов автоматизации, используя большие объемы данных OT.

Отслеживая данные OT от архиваторов, функции SCADA могли предоставить операторам некоторое представление о том, как работает оборудование. Когда сбой был неизбежен, функции SCADA давали операторам (или руководителям) возможность принять меры до того, как произошел сбой. Это требовало, чтобы система SCADA имела доступ к данным от архиваторов, и использовала проприетарные средства связи, такие как MODBUS или PROFIBUS, чтобы сделать эти данные доступными для операторов через человеко-машинные интерфейсы (HMI). Но мониторинг касался исключительно производительности оборудования, что еще больше расширило использование данных OT.

Благодаря наблюдению за этими потоками данных (манометры, экраны операторов и т. д.) и лучшему пониманию дрейфа данных можно было распознать — с помощью систем SCADA — не только неизбежный отказ оборудования, но и то, что данные могут также использоваться для анализа отказов в качестве продукции при испытаниях и проверках — операциях, которые могут быть выполнены на несколько шагов позже в процессе.

Это создало потребность в том, чтобы данные ОТ были связаны с данными ИТ. Это привело к созданию сложных интерфейсов от ПЛК и SCADA к системам информационных технологий (ИТ), таким как MES, позволяющим связать реляционные данные об отказах продукта с рабочими данными оборудования, из которого производится продукт. Некоторые пробовали это прямо в ERP (и все еще пытаются), но системы ERP не приспособлены для обработки и представления этих данных достаточно быстро и достаточно подробно по отношению к другим событиям в процессе производства.

Проблема с интерфейсами MES заключается в том, что они сильно настраиваются и стоят дорого, иногда добавляя до 40-50% стоимости реализации проекта. Следующим шагом в улучшении доступа к данным будет повышение доступности данных ПЛК для MES и других реляционных баз данных. Когда эта потребность в доступе сочетается со стоимостью вычислений и компьютерной памяти, которые становятся дешевле, а сетевая связь становится более стабильной (вход в сети 5G), имеет смысл подключать датчики и исполнительные механизмы ПЛК напрямую к ИТ-сетям (то, что мы называем IIoT) и сделать свои данные доступными для... всех, кто в них нуждается.

Все это подчеркивает, что сделать данные OT более доступными для ИТ-систем — это просто следующий шаг в более длительном процессе. эволюции технологий, которая привела нас к Индустрии 4.0.

Как можно использовать конвергенцию ИТ/ОТ?

Взаимодействие данных ОТ с ИТ-системами столкнулось с новой проблемой.

Системы PLC/SCADA, которые контролируют датчики в архиваторах, могут создавать большие потоки данных (размером до мегабайт) за считанные секунды. Однако с точки зрения понимания характеристики события обратно в ИТ-системы, этот поток данных — даже за небольшие промежутки времени — просто слишком велик для обработки реляционными базами данных ИТ-систем, таких как MES. Многие реализации пытались записать экземпляр данных датчика (взятых из потока данных), чтобы зафиксировать один элемент данных, чтобы попытаться представить события OT на уровне ИТ. Однако многие обнаружили, что привязка экземпляра данных OT к событию качества продукта во время производства не очень эффективна для мониторинга качества процесса в целом.

Теперь нам нужно определить способы объединения потоков данных из систем OT. таким образом, чтобы сохранить важные характеристики производственного события. Отчетность OEE является одной из таких попыток агрегирования. Важно осознавать, что при использовании любой формы агрегирования данных может произойти потеря некоторых важных деталей качественного события. Вот почему OEE используется как объект данных уровня мониторинга, а не объект уровня анализа. Тем не менее, отслеживая в режиме реального времени значение изменения OEE, ИТ-система может распознавать скорость и величину изменений и создавать аварийные сигналы для предупреждения о проблеме.

Чтобы проанализировать эту реальную проблему, вам нужно будет вернуться к исходному потоку данных, который использовался для создания значения OEE. По крайней мере, благодаря тому, что значение OEE предоставляется в режиме реального времени, инженеры-технологи и инженеры по контролю получают представление о проблеме достаточно рано, чтобы они могли вернуться к архиватору для анализа до того, как событие будет скрыто дополнительными данными из потока данных OT.

Вопрос в том, как вы агрегируете данные?

Ответ, как всегда,... зависит от обстоятельств!

Способ агрегирования данных будет зависеть от того, какие данные вы агрегируете и что вы пытаетесь отслеживать в процессе. Это также будет зависеть от способности интерпретировать изменения в модели агрегации данных.

В этом разделе я рассмотрю один из таких методов агрегирования и представлю некоторые способы интерпретации изменений в этом наборе данных.

«Кривая естественного распределения» или гистограмма — одно из наиболее распространенных графических представлений данных с таких устройств, как датчики. Основная предпосылка кривой заключается в том, что if в процессе есть только нормальные случайные вариации, распределение экземпляров данных будет следовать схеме, напоминающей естественную кривую распределения.

На рис. 1 показано, как может выглядеть распределение показаний датчика духового шкафа при нормальном отклонении при построении гистограммы.

Рисунок 1:Кривая распределения температуры духовки, показывающая среднее значение, медиану и моду. Предоставлено автором.

Ключевыми характеристиками кривой являются то, что среднее (среднее), медиана (среднее значение потока данных) и мода (значение с наибольшим числом вхождений) все приблизительно равны . Это можно использовать в качестве эталона, чтобы определить, испытывает ли процесс проблемы. Пока есть признаки того, что процесс находится под контролем, имеет смысл определить значения +/-3 сигма и сравнить их с верхним и нижним контрольными пределами и пределами спецификации продукта.

Пример сценария

Чтобы контролировать процесс прохождения производственной единицы через печь для отверждения, система MES будет учитывать время, когда единица входит в печь и выходит из нее. В течение этого времени система ПЛК (использующая интеллектуальный датчик) будет создавать постоянный поток данных датчика температуры, которые будут храниться в базе данных локального архива на сенсорном устройстве. Когда производственная единица выходит из печи, MES будет запрашивать у устройства совокупность данных о температуре за этот определенный период времени. Даже при ограниченной вычислительной мощности, доступной на уровне устройства, устройство может принимать сотни (или даже тысячи) точек данных и предоставлять набор агрегированных данных обратно в MES — вместо предоставления одного экземпляра данных датчика, как это обычно бывает. или пытаться обработать весь поток данных.

Ниже будет набор агрегированных значений данных для этой производственной единицы:

• Среднее:90,0
• Медиана:будет очень близка к 90,0
• Режим:примерно 90,0 градусов.
• Распределение +/- 3 сигма:87,0, 93,0 (необходимо проверить с помощью UCL и LCL)

Выполняя быстрый анализ различий между средним значением, медианой и режимом, MES может искать приемлемый контроль управления процессом, а также отслеживать изменения по сравнению с предыдущими производственными единицами, которые уже прошли через печь. Если значения +/- 3 сигма выходят за допустимые пределы, MES автоматически помечает производственную единицу как подозрительную, а также если среднее значение, медиана или режим значительно отличаются друг от друга или от предыдущих продуктов.

На рис. 2 представлен пример того, как эти же значения могут указывать на процесс, который не находится под контролем. В этом случае, однако, все еще возможно, что значения +/- 3 сигма могут находиться в определенных пределах.

Рисунок 2. Пример различий между средним значением, медианой и модой в асимметричном процессе. Предоставлено автором.

Теперь, технически, если распределение асимметрично, как показано, значения +/- 3 сигмы могут не считаться действительными из-за асимметричного характера набора данных. Но непосредственный анализ устройства все же может быть использован для определения того, были ли нарушены контрольные пределы.

Ключевой момент:если такой набор данных предоставляет интеллектуальный датчик, это указывает инженерам-технологам на то, что печь не работает. работающие только со случайной дисперсией, и поэтому должны быть исследованы.

Другие различия в среднем значении, медиане и моде (например, среднее и медиана равны, но мода различна) также могут указывать на такие состояния, как бимодальное распределение, которое предполагает множественное влияние процессов. Еще раз, инженеры-технологи должны изучить процесс.

Когда приведенные выше наборы данных связаны непосредственно с производственным блоком на уровне MES, эти данные могут использоваться — вместе с результатами испытаний и проверок — для определения наличия связи между изменением температуры печи и отказом производственного блока.

Независимо от того, произошел ли сбой продукта в результате проблем с процессом или нет, дрейф значений данных во время производственного цикла также может указывать на фундаментальные проблемы управления процессом, которые необходимо исследовать.

Обзор

Предыдущие примеры агрегирования данных отражают только конкретный сценарий, но они предназначены для предоставления представления о причинах. для объединения данных ОТ и ИТ а также потенциальное значение этой конвергенции . В каждом производственном сценарии необходимо будет оценить правильный метод агрегирования данных, а программирование интеллектуальных устройств должно сделать эту функцию доступной. Или, в качестве альтернативы, системы периферийных вычислений будут запрограммированы для замены функций, описанных для интеллектуальных устройств.

Суть в том, что, хотя в отрасли широко используется «конвергенция ИТ/ОТ» в качестве модного термина для описания меняющихся технологий, в обработке данных происходят законные изменения. что технология, стоящая за модным термином, обеспечивает. Компании, которые воспользуются преимуществами технологии конвергенции и научатся правильно агрегировать и интерпретировать данные, представленные с помощью конвергенции, могут получить практические преимущества в эффективности программ управления качеством и объектами. В сегодняшней глобальной конкурентной среде использование любого преимущества полезно для конечного результата.

Итак, ответ - нет. Конвергенция ИТ и ОТ — это не просто модный термин. Это ценный инструмент в развитии технологии сбора и управления данными, который может принести большую пользу производственным компаниям. Изучение того, как агрегировать данные с уровня ОТ, чтобы системы на уровне ИТ могли с ними работать, является важной частью конвергенции.