Сходимость IT/OT: просто модный термин или реальная ценность?

Итак, является ли «сходимость IT/OT» просто еще одним модным жаргоном?

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

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

Что такое сходимость IT/OT?

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

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

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

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

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

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

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

Как можно использовать сходимость IT/OT?

Интерфейсирование OT-данных с IT-системами теперь столкнулось с новой проблемой.

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

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

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

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

Ответ, как всегда,... зависит!

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

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

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

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

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

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

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

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

• Среднее: 90.0
• Медиана: была бы очень близка к 90.0
• Мода: примерно 90.0 градусов тоже
• +/- 3 Сигма распределение: 87.0, 93.0 (подлежит проверке с UCL и LCL)

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

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

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

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

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

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

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

Резюме

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

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

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