На современном умном заводе каждую секунду генерируются сотни или даже тысячи точек данных. Эти данные могут поступать из самых разных источников, включая производственные машины, датчики и другие промышленные устройства. Ожидается, что с ростом использования подключенных устройств и Интернета вещей (IoT) в производстве объем генерируемых данных будет только увеличиваться.

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

Что производители сделали до сих пор, чтобы использовать эти данные?

Со временем было изобретено несколько приложений для использования этих точек данных для получения информации:

  • СКАДА (1970)
  • Производство ERP (1980)
  • МЧС (1992)
  • АМС (2006 г.)
  • и т. д.

Однако отправка промышленных данных в эти приложения была затруднена, поскольку разные устройства на заводе использовали разные протоколы связи. Были даже различия в протоколах между разными производителями устройств (например, ПЛК Siemens и Mitsubishi). Это создало растущую потребность в стандартизированном методе связи.

Как мы пытались это исправить?

Есть два протокола, которые пытались обеспечить взаимосвязь с помощью немного разных подходов: OPC-UA и MQTT. Обратите внимание, что существуют и другие протоколы, но эти два являются наиболее широко признанными и принятыми в производственной отрасли.

OPC-UA

В 2008 году OPC Foundation, в которую входят 890 членов, включая Rockwell, Microsoft, ABB, Siemens и т. д., разработала стандарт OPC-UA для открытой связи между промышленным оборудованием. Цель стандарта OPC-UA состояла в том, чтобы определить формат сообщения, который является открытым и не зависит от платформы. Типичная реализация выглядит так:

Существует сервер OPC, который подключается к периферийным устройствам, таким как ПЛК. Это связывается с приложением, которому нужны данные, которое называется клиентом OPC. Примером вашего клиента OPC является ваша система SCADA или MES.​

На картинке выше показано, как форматируется сообщение OPC-UA. OPC-UA — это набор функций. Когда вы создаете клиент или сервер, вам нужно будет выбрать, какие функции вам нужны. Например, существуют сопутствующие информационные модели, которые подобны драйверам для определенных устройств (бывшая спецификация CNC Companion может быть активирована для извлечения данных из станка с ЧПУ). Существуют также основные информационные модели, такие как A и E, которые включают сигналы тревоги, события и т. д.

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

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

Это заставляет нас задаться вопросом, есть ли что-то лучше?

Давайте вернемся в прошлое, за десять лет до изобретения OPC UA, чтобы проследить рождение MQTT.

MQTT

В 1998 году компании Philips 66 понадобился облегченный протокол для связи со своими удаленными станциями и получения данных в режиме реального времени. Чтобы разработать решение, они обратились к инженеру по имени Арлен Ниппер и попросили его сотрудничать с их ИТ-менеджером. ИТ-менеджер работал с IBM MQSeries в то время и объяснил, что серия MQ — это новый мир ИТ. кто будет его потреблять), и любое приложение-получатель, заинтересованное в этой теме, может подписаться на него и получить сообщение. Серия MQ была платформой промежуточного программного обеспечения для обмена сообщениями, которая по существу абстрагировала связь между отправителем и получателем. Арлен задался вопросом, можно ли применить эту концепцию и к промышленным данным.

В 1997 году провидец из IBM по имени Тим Холлоуэй задавался тем же вопросом. Его «проект Argo» исследовал эту идею публикации данных OT (операционных технологий), не беспокоясь о подписчиках.​

В конце концов Арлен встретил Тима, который познакомил его с инженером IBM Энди Стэнфордом Кларком, и вместе они разработали MQTT.

Благодаря архитектуре публикации-подписки MQTT промышленные приложения могут отправлять данные брокеру, не беспокоясь о том, кто их будет использовать. Теперь вы можете иметь ERP, Historian, SCADA и все промышленные устройства, открыто взаимодействующие друг с другом в режиме реального времени.

Это равносильно тому, что все присутствуют в комнате и общаются друг с другом в режиме реального времени

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

В 2018 году OPC UA даже разработала спецификацию подписки на публикацию, построенную на основе MQTT, и перечислила причины, по которым она превосходит их предыдущую клиент-серверную архитектуру.

Звучит отлично. В чем подвох?

Самое замечательное в MQTT то, что вы можете отправлять что угодно по протоколу.

Плохая сторона MQTT заключается в том, что по протоколу можно отправить что угодно.

Промышленным приложениям было сложно использовать данные из нескольких источников без их предварительной обработки. Разные производители устройств по-разному структурировали свои MQTT-сообщения.

Все присутствуют в комнате и общаются в режиме реального времени, но говорят на разных языках.

Решение этой проблемы появилось в 2016 году с изобретением спецификации SparkPlugB. Эта спецификация определяет, как структурировать темы в сообщении MQTT в стандартном формате. Это помогает с автообнаружением и позволяет приложениям plug and play. Чтобы увидеть конкретный пример этого, см. мою статью о реализации SparkplugB в Microsoft Azure:
Средний.

Все присутствуют в комнате и общаются в реальном времени на одном языке.

Другие функции SparkplugB включают управление состоянием (бывшие свидетельства о рождении и смерти) и средства для определения пространства имен тем. Хотя спецификация SparkplugB является новой, она получает признание среди поставщиков промышленного оборудования, включая Opto 22, Canary Historian, Phoenix Contact и т. д. Она также была принята поставщиками облачных услуг AWS и, совсем недавно, Microsoft Azure.

Подведение итогов

В заключение, объем данных, созданных производителями, и количество приложений, изобретенных для использования этих данных, создали потребность во взаимосвязи. MQTT и OPC UA были созданы для решения этой проблемы, однако оба имеют свои ограничения. Появление Sparkplug B сделало MQTT более надежным решением этой проблемы. Я с нетерпением жду возможности наблюдать за эволюцией этих протоколов и надеюсь увидеть дальнейшее распространение Sparkplug B среди промышленных поставщиков.