Русский
Русский
English
Статистика
Реклама

Edge платформа промышленного интернета вещей I-IoT

Что такое I-IoT


После появления парового двигателя в 1760 году пар использовался для снабжения энергией всего, от сельского хозяйства до текстильного производства. Это вызвало Первую промышленную революцию и эпоху механического производства. В конце 19-го века пришли электричество, новые способы организации труда и массовое производство, что положило начало Второй промышленной революции. Во второй половине 20-го века разработка полупроводников и внедрение электронных контроллеров дали начало эпохе автоматизации и Третьей промышленной революции. На Ганноверской выставке 2011 года Хеннинг Кагерманн, Вольф-Дитер Лукас и Вольфганг Вальстер ввели термин Industry 4.0 для проекта обновления немецкой производственной системы с использованием возможностей новейших цифровых технологий.

image



Ожидается, что Industry 4.0 сможет воплотить следующее:

  • Объединить производство с информационными и коммуникационными технологиями
  • Объединить данные клиента с производственными данными
  • Максимально использовать возможности межмашинного взаимодействия
  • Управлять производством автономно, гибко и эффективно сохраняя ресурсы

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

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

По определению, IoT это ключ к дальнейшему развитию промышленности, включая такие технологии, как анализ больших данных, облачные технологии, робототехника и, что наиболее важно, интеграция и конвергенция между ИТ и производством.
Термин I-IoT (Industrial internet of Things) относится к промышленному подмножеству IoT, представляющему собой цифровую трансформацию естественного бизнеса. I-IoT делает бизнес более гибким, более выгодным, понятным и создает новые цифровые цепочки ценности. Традиционные производственные цепочки это понятные последовательные этапы, например: разработка продукции, получение и поставка источников сырья, производство и обслуживание продукции. Суть новой цифровой трансформации в том, что вокруг некого цифрового ядра создается сервисная экосистема и новые бизнес-модели, придающие новые качества производству. Такие как снижение издержек между различными этапами подготовки производства, наладки и эксплуатации. Связи между различными департаментами и этапами становятся более быстрыми, что дает возможность работать более эффективнее и конкурентнее на рынке.

image

Ожидается, что I-IoT создаст большую ценность для бизнеса и окажет такое глубокое влияние на человеческое общество, что он введет Четвертую промышленную революцию.
Согласно Forbes:

  • Мировой рынок IoT вырастет с 157 млрд долларов в 2016 году до 457 долларов к 2020 году, достигнув годового темпа роста 28,5%
  • Производство, транспорт и логистика, а также коммунальные услуги приведут все отрасли к расходам на IoT к 2020 году, в среднем по 40 миллиардов долларов каждая.


IoT и I-IoT сходства и различия


  • Кибербезопасность является критически важной темой для любого цифрового решения, но его внедрение в промышленном мире требует особого внимания. Это связано с тем, что системы и устройства в промышленности имеют гораздо более длительный жизненный цикл и часто основаны на устаревших технологиях, которые не предназначены для подключения через Интернет. Часто они содержаться в изолированной локальной сети, защищенной от внешнего мира.
  • Очень важно, чтобы промышленные цифровые устройства продолжали работать, не смотря на кратковременные сбои в питании или сети; любое временное отключение может привести к большим экономическим потерям.
  • Решения I-IoT должны сосуществовать в среде со значительным количеством устройств и систем, выступающими в качестве источников данных.
  • Промышленные сети это специализированные и детерминированные сети, поддерживающие десятки тысяч контроллеров, роботов и машин. Поэтому решения I-IoT, развернутые в этих сетях, должны беспрепятственно масштабировать десятки тысяч датчиков и устройств.
  • Физические объекты в индустриальном мире являются более сложными и имеют более широкий спектр типов по сравнению с бытовым потреблением.
  • В промышленном мире надежность, устойчивость и доступность являются ключевыми факторы. Юзабилити и пользовательский опыт, однако, не так актуальны, как в мире потребителей.
  • Промышленные системы часто перепрограммируются и реконфигурируются для поддержки новых процессов. Решения I-IoT должны поддерживать и обеспечивать одинаковую гибкость и адаптивность в условиях эксплуатации.
  • Интеллектуальная собственность является важной темой в индустриальном мире, часто является коммерческой тайной и защищена патентом.


Понятие производственного процесса и промышленных устройств


CIM (computer-integrated manufacturing) это логическая модель для производственных систем, разработанная в 1990-х годах для интеграции производственных процессов, систем автоматизации и систем информационных технологий на уровне компании или предприятия. CIM не следует рассматривать как метод проектирования для создания автоматизированных фабрик, а скорее как эталонную модель для внедрения промышленной автоматизации, основанную на сборе, координации, совместном использовании и передаче данных и информации между различными системами и подсистемами посредством средства программных приложений и сетей связи. Модель CIM часто изображается в виде пирамиды, состоящей из шести функциональных уровней, как показано на следующей диаграмме

image

Уровень 1 датчики, преобразователи и исполнительный механизм


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

Уровень 2 RTU, микроконтроллеры, CNC, PLC и DCS


  • Удаленный терминал (Remote terminal unit RTU) это электронное устройство, управляемое микропроцессором. Он служит интерфейсом для датчиков, исполнительных механизмов и интеллектуальных устройств, передавая данные и получая командные сообщения от главной системы. Он в основном используется для централизации ввода и вывода от датчиков и исполнительных механизмов, уменьшая сложность кабельной проводки.
  • Микроконтроллер (Embedded controller), как правило, представляет собой один чип или плату, которая включает в себя все необходимые компоненты для выполнения необходимых задач управления. Они обычно предназначены для конкретного применения и построены на основе определенной архитектуре выбранного производителя.
  • Контроллеры с числовым программным управлением ЧПУ (CNC) электронное устройство, предназначенное для управления станками. Движения и функции станков с ЧПУ предопределены и устанавливаются с помощью специального программного обеспечения. Они используются для выполнения высокоточной обработки, которая требует длительного времени без какого-либо взаимодействия с внешней средой.
  • PLC это промышленный контроллер, предназначенный для управления производственными процессами. PLC выполняет программу циклически, обрабатывая сигналы, поступающие в качестве входных сигналов от датчиков и переключателей, и отправляя выходные значения в исполнительные механизмы для управления физическим процессом. Чтение входных данных, их обработка, а также запись выходных данных происходит в течение предварительно определенного максимального времени, называемого циклом сканирования. Обычно это занимает от 10 до 100 миллисекунд.
  • DCS обычно используются в непрерывных процессах, таких как нефтеперерабатывающие, энергетические или химические заводы. Они объединяют как функцию управления, реализованную в PLC, так и функцию системы диспетчерского контроля (SCADA). В то время как PLC и SCADA являются двумя отдельными системами, каждая из которых имеет свои собственные адресные пространства, в DCS эти системы используют одни и те же переменные и структуры данных


Уровень 3 SCADA, Historian


Система SCADA представляет собой программный пакет для выполнения функций сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления в реальном времени. Система сбора данных (Historian) позволяет собирать в режиме реального времени информацию о рабочем состоянии оборудования. Система SCADA реализует следующие основные функции:
  • Получает данные и информацию от PLC, состояние датчиков, RTU и других устройств, расположенных на нижних уровнях пирамиды CIM.
  • Обрабатывает собранные данные, сохраняя наиболее актуальную информацию.
  • Обнаруживает аварийные ситуации, формируя сигналы тревоги, которые передаются операторам.
  • Предоставляет информацию операторам в диспетчерской через человеко-машинный интерфейс (HMI).
  • С помощью HMI оператор контролирует производственные процессы и посылает необходимые команды в PLC.


Уровень 4 -MES


MES это программная система, расположенная между ERP и SCADA или PLC, предназначенная для эффективного управления производственным процессом компании. Основная функция MES заключается в синхронизации управления бизнесом и производственной системой путем объединения уровней планирования и контроля для оптимизации процессов и ресурсов.
Основными особенностями системы MES являются:
  • Управление заказами и планирование производства
  • Управление поступающим сырьем и полуфабрикатами
  • Управление активами и мониторинг
  • Отслеживание производства
  • Управление техобслуживанием
  • Проверка качества


Уровень 5 ERP


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

Производственные сети


В интегрированной производственной системе требуются различные типы сетей связи, каждая из которых предназначена для определенных задач
  • Уровень 1: полевая шина
  • Уровень 2: сеть котроллеров
  • Уровень 3, 4, 5: корпоративная сеть

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

OPC сервер


Ни один другой стандарт промышленных коммуникаций не получил такого широкого признания среди многих отраслей и производителей оборудования, как OPC. Он используется для объединения большого разнообразия промышленных и бизнес-систем. SCADA, системы обеспечения безопасности (SIS), программируемые логические контроллеры (PLC) и распределенные системы управления (DCS) используют OPC для обмена данными друг с другом, а также с базами данных Historian, MES и ERP-системами. Причина успеха OPC очень проста это единственный действительно универсальный интерфейс, который можно использовать для связи с различными промышленными устройствами и приложениями, независимо от производителя, программного обеспечения или протоколов, используемых в системе управления. После появления стандарта ОРС практически все SCADA были перепроектированы как ОРС-клиенты, а каждый производитель аппаратного обеспечения стал снабжать свои контроллеры, модули ввода-вывода, интеллектуальные датчики и исполнительные устройства стандартным ОРС сервером.

OPC classic (Data access DA)


В 1995 году различные компании решили создать рабочую группу для определения стандарта взаимодействия. Этими компаниями были следующие: Fisher Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell, Siemens AG.
Члены Microsoft также были приглашены для оказания необходимой поддержки. Задача рабочей группы состояла в том, чтобы определить стандарт доступа к информации в среде Windows на основе современных технологий того времени. Разработанная технология была названа Object Linking and Embedding (OLE) for Process Control (OPC). В августе 1996 года была определена первая версия OPC. На следующей диаграмме показаны различные уровни OPC Classic с основными протоколами связи COM, DCOM и удаленный вызов процедур (RPC):

image

COM это программная архитектура, разработанная Microsoft для создания компонентных приложений. В то время это позволяло программистам инкапсулировать повторно используемые фрагменты кода таким образом, чтобы другие приложения могли использовать их, не беспокоясь о деталях своей реализации. COM-объекты могут быть заменены более новыми версиями, без необходимости переписывать приложения, которые их используют. DCOM это сетевые версии COM. DCOM пытается скрыть от разработчиков программного обеспечения различия между COM-объектами, работающими на одном компьютере, и COM-объектами, работающими удаленно на другом компьютере. Для этого все параметры должны быть переданы по значению. Это означает, что при вызове функции, предоставляемой объектом COM, вызывающая сторона должна передать связанные параметры по значению. С другой стороны, COM-объект будет отвечать вызывающей стороне, передавая результаты также по значению. Процесс преобразования параметров в данные, передаваемые по сети, называется маршалинг (marshalling). После завершения маршалинга поток данных сериализуется, передается и восстанавливается в исходном порядке данных на другом конце соединения.
DCOM используют механизм RPC для прозрачной передачи и получения информации между COM-компонентами в одной сети. Механизм RPC был разработан Microsoft, чтобы позволить разработчикам системы запрашивать выполнение удаленных программ без необходимости разработки специальных процедур для сервера. Клиентская программа отправляет на сервер сообщение с надлежащими аргументами, а сервер возвращает сообщение, содержащее результаты, полученные из выполненной программы.

OPC Classic содержит ряд ограничений:
  • доступность только на операционных системах семейства Microsoft Windows;
  • связь c технологией DCOM, исходные коды которой являются закрытыми.
  • проблемы конфигурирования, связанные с DCOM;
  • неточные сообщения DCOM о прерываниях связи;
  • неприспособленность DCOM для обмена данными через интернет;
  • неприспособленность DCOM для обеспечения информационной безопасности.


Модель получения данных в OPC Classic


Цели стандарта OPC Classic заключаются в следующем:
  • Структурировать данные на стороне сервера, чтобы упростить сбор данных на стороне клиента.
  • Определить коммуникационные сервисы и стандартные механизмы обмена данными

По сути, стандарт OPC Classic работает следующим образом:
Сервер управляет всеми доступными данными.
Сервер отправляет запросы на данные, поступающие от устройств по требованию, и регулярно обновляет внутренний кэш. Сервер инициализирует и управляет кэшем для каждой группы переменных, запрошенных клиентом OPC. Частота сканирования на стороне клиента OPC не может быть меньше частоты сканирования OPC сервера для сбора данных с устройств и обновления своего внутреннего кэша. Рекомендуется настроить клиент OPC для чтения из кэша и его на обновление с удвоенной скоростью, по сравнению с которой сервер OPC сканирует устройства. Каждая часть обмениваемых данных имеет свое значение, обозначенное своей отметкой времени и качеством. Обмен данными включает в себя чтение, запись и автоматическое обновление при изменении значений. Чтение или опрос выполняется OPC-клиентом, который регулярно отправляет запросы на данные группы. Этап записи может быть синхронным или асинхронным. Автоматические обновления использует частоту запросов, предоставленную клиентом OPC. Сервер OPC для каждого обновления проверяет, больше ли абсолютное значение кэшированного значения минус текущее значение, чем мертвая зона, указанная клиентом, умноженная на диапазон, настроенный для этой переменной. Это можно записать следующим образом:
if (abs(last_cached_value  current_value) > (PERCENT_DEAD_BAND/100) * range) {//cache is updated, and the client is notified through a callback mechanism }


Информация с сервера OPC организована в группы связанных элементов для повышения эффективности. Есть два разных типа групп:

  • Public groups: доступны для любого клиента
  • Local groups: доступны только клиенту, который их создал


OPC UA


Первым ответом OPC Foundation на растущие ограничения, связанные с принятием архитектуры COM и DCOM, стала разработка OPC XML-DA. Это сохранило характеристики OPC, но приняло коммуникационную инфраструктуру, которая не связана ни с производителем, ни с конкретной программной платформой. Преобразование спецификаций OPC-DA в версии на основе веб-сервисов оказалось недостаточным для удовлетворения потребностей предприятий, которые все больше взаимодействуют и интегрируются с корпоративным и внешним миром.
Информация об архитектуре OPC UA представлена на сайте opcfoundation.org/developer-tools/specifications-unified-architecture
Поэтому был разработан протокол OPC UA с целью заменить все существующие версии на основе COM и преодолеть проблемы безопасности и производительности. Стандарт удовлетворяет потребность в независимых от платформы интерфейсах и позволяет создавать расширяемые модели данных для описания сложных систем без потери функциональности. OPC UA основан на сервис-ориентированном подходе, определенном стандартом IEC 62451. Он преследует следующие цели:

  • Использование компонентов OPC на платформах, отличных от Windows
  • Позволяет встроить его основные компоненты в небольшие устройства
  • Реализует стандартное взаимодействия через системы на основе файрвола

С технической точки зрения OPC UA работает следующим образом:

  • API изолирует код клиента и сервера от стека OPC UA
  • Стек UA преобразует вызовы API в сообщения
  • Стек UA получает сообщения, отправляя их клиенту или серверу через API


image

Информационная модель OPC UA


Основные принципы информационного моделирования в OPC UA:

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

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

image

Узлы могут принадлежать к разным классам узлов, в зависимости от их конкретной цели. Некоторые узлы могут представлять экземпляры, другие могут представлять типы и т. д. В OPC UA есть восемь стандартных классов узлов: variable, object, method, view, data type, variable type, object type, и reference type. В OPC UA наиболее важными классами узлов являются объект, переменная и метод

OPC UA сессии


OPC UA предоставляет модель связи клиент-сервер, которая включает информацию о состоянии. Эта информация о состоянии связана с сессией. Сессия определяется как логическое соединение между клиентом и сервером. Каждый сессия не зависит от базового протокола связи; любые проблемы, возникающие на уровне протокола, не приводят к автоматическому завершению сессии. Сессия заканчивается после явного запроса от клиента или из-за бездействия клиента. Интервалы бездействия устанавливаются во время создания сеанса.

Модель безопасности OPC UA


Модель безопасности OPC UA реализована посредством определения безопасного канала, на котором основан сеанс. Безопасный канал осуществляет обмен данными следующим образом:
  • Обеспечивает целостность данных с использованием цифровых подписей.
  • Обеспечивает конфиденциальность посредством шифрования.
  • Выполняет аутентификацию и авторизацию приложений с использованием сертификатов X.509.

На рисунке показаны следующие уровни: прикладной уровень, сеансовый и транспортный уровень:
Уровень приложений используется для передачи информации между клиентами и серверами, которые установили сеанс OPC UA. Сеанс OPC UA устанавливается на защищенном канале. Транспортный уровень это уровень, отвечающий за передачу и прием данных через сокетное соединение, к которому применяются механизмы обработки ошибок, чтобы гарантировать защиту системы от таких атак, как denial-of-service (DoS)

image

Обмен данными OPC UA


Самый простой способ обмена данными между клиентом OPC UA и сервером использовать службы чтения и записи. Сервисы чтения и записи оптимизированы для передачи группы данных, а не одного фрагмента данных или нескольких значений. Они позволяют читать и записывать либо значения, либо атрибуты узлов. Сервис чтения имеет следующие параметры:
maxAge: это максимальное время, необходимое для получения значений. Это указывается клиентом. Он заставляет сервер обращаться к устройству (например, к датчику), если копия в его кэше старше, чем параметр maxAge, настроенный клиентом. Если maxAge установлено в ноль, сервер должен предоставить текущее значение, всегда считывая его непосредственно с устройства.
Тип отметок времени: в OPC UA определены две отметки времени: отметка времени источника и отметка времени сервера. Исходная временная метка это временная метка, которая поступает от устройства, а серверная временная метка это временная метка, которая поступает из опреационной системы, на которой работает сервер OPC UA.
Список узлов и атрибутов выглядит следующим образом:

  • NodeId
  • AttributeId для значения экземпляра
  • DataEncoding: это позволяет клиенту выбрать подходящую кодировку данных, и значения по умолчанию XML, UA двоичный


Особенности OPC протокола


OPC протокол нельзя в полной мере назвать свободным. Для разработки ПО с использованием OPC SDK необходимо быть членом OPC Foundation. Однако сейчас существуют свободные реализации библиотеки клиента и сервера, например freeopcua.github.io, но в них отсутсвует пока реализация pub/sub.
По сравнению с другими протоколами, как MQTT, OPC не является легковесным

Программируемый логический контроллер PLC


Термин ПЛК (Programmable Logic Controller, PLC) впоследствии был определен в стандартах EN 61131 (МЭК 61131). ПЛК это унифицированная цифровая управляющая электронная система, специально разработанная для использования в производственных условиях. ПЛК постоянно контролирует состояние устройств ввода и принимает решения на основе пользовательской программы для управления состоянием выходных устройств.
Требования, предъявляемые к PLC:
  • Он должен быть способен функционировать в жестких производственных условиях, такими как температурные перепады, наличие грязи, некачественная сеть электропитания.
  • Он должен работать с дискретными входными и выходными сигналами характерными для промышленности 24В постоянного тока или 240В переменного тока, а также с аналоговыми сигналами (10В, 4-20мА и т.д.)
  • Язык программирования должен быть понятен инженерам по автоматизации
  • PLC должен непрерывно контролировать работу промышленного объекта
  • Операционная система должна обладать достаточным быстродействием для выполнения скан-цикла (20 100мс)

На следующем рисунке приведена структура основного режима работы PLC (на примере CPU Simatic)

image

OPC UA с SIMATIC S7-1500


Предварительные требования должен быть установлен программный пакет Simatic TIA Portal V13 16
Для выполнения симуляции контроллера с OPC сервером необходимо установить и настроить SIMATIC S7-PLCSIM Advanced версии 2 или 3. support.industry.siemens.com/cs/document/109772889/trial-download%3A-simatic-s7-plcsim-advanced-v3-0?dti=0&lc=en-WW Я выполнял установку симулятора версии 3 на систему с имеющимся пакетом Simatic TIA Portal V14 SP1. Перед установкой инсталлятор уведомил о том, что PLCSIM V14 не совместим с SIMATIC S7-PLCSIM V3, и его необходимо удалить. Я выполнил эти действия, после чего установка прошла суспешно. В TIA Portal был создан тестовый проект с CPU 1512C-1 PN. Особенностью стало то, что выполнить имуляцию с помощью кнопки Start simulation стало невозможно, однако работает кнопка Dowload to device при работающем PLCSIM Advanced.
Для доступа по сети к симулятору необходим включить PLCSIM Virtual Eth. Adapter, для чего предварительно необходимо установить софт WinPcap. Далее идут стандартные настройки Ethernet сети. После нажатия кнопки Start симулятор становится активным и виден в сети

image

Далее необходимо установить чекбокс Support simulation during block compilation на вкладке Protection в диалоговом окне вызова пукта Properties контекстного меню в корне проекта

image

Следующим этапом необходимо активировать OPC сервер в проекте и выбрать тип лицензии (можно упустить из вида, после чего не скомпилируется проект)

image

Далее процесс заливки софта в PLCSIM Advanced аналогичен загрузки в стандартный симулятор за исключением описанного ранее.
В тестовом проекте TIA Portal были созданы блок данных DB1 с одним тегом pressure, а также назначен цифровой выход Q0.1 Tag_2.
Для подключения к OPC серверу и мониторингу сети, узлов и тегов можно воспользоваться OPC клиентом UaExpert, который можно скачать с сайта www.unified-automation.com/products/development-tools/uaexpert.html. Для подключения к OPC серверу необходимо добавить новое соединение и прописать Endpoint Url, ранее установленное в настройках проекта OPC сервера в TIA Portale, в моем случае это opc.tcp://192.168.1.113:4840

image

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

image

Для программной реализации взаимодействия OPC клиента и сервера можно воспользоваться opensource реализацией библиотеки на Python github.com/FreeOpcUa/python-opcua, там же находятся и примеры с кодом. Перед использованием необходимо установить нужные зависимости:

pip install freeopcuapip install cryptography


Простейший пример создания OPC сервера c тремя тегами

from opcua import Serverfrom random import randintimport datetimeimport timeclass Opc:    def __init__(self):        self.server = Server()        self.url = "opc.tcp://127.0.0.1:4848"        self.server.set_endpoint(self.url)        self.namespace_uri = "OPCUA_SIMULATION_SERVER"        self.namespace = self.server.register_namespace(self.namespace_uri)        self.root_node = self.server.get_objects_node()        self.parameters = self.root_node.add_object(self.namespace, "Parameters")    def create_variable(self, name, initial=0):        variable = self.parameters.add_variable(self.namespace, name, initial)        variable.set_writable()        return variabledef main():    opc = Opc()    tag_1 = opc.create_variable("Temperature", 25)    tag_2 = opc.create_variable("Pressure")    tag_3 = opc.create_variable("Time")    opc.server.start()    print("Server started at {}".format(opc.url))    while True:        #tag_1.set_value(randint(10, 50))        tag_2.set_value(randint(200, 999))        tag_3.set_value(datetime.datetime.now())        time.sleep(2)if __name__ == '__main__':   main()


Такой же простейший пример клиенской части

from opcua import Clientimport timeurl = "opc.tcp://127.0.0.1:4848"client = Client(url)client.connect()print("Client connected")Temp = client.get_node("ns=2;i=2")Temp.set_value(25)if __name__ == '__main__':    while True:        temperature = Temp.get_value()        print(temperature)        time.sleep(1)


Наблюдать подключение также возможно с помощью клиента UaExpert

image

Понятие I-IoT Edge


Edge это узел между производственной средой и миром IoT в облаке. Edge может быть разложен на три макрокомпонента: Граничный шлюз (Edge Gateway), Утилиты для конфигурирования (Edge tools), Граничные вычисления (Edge Computing)

image

В 2017 году Gartner объявил следующее: The Edge will eat the cloud.. Хотя это утверждение может показаться немного спорным, оно подчеркивает роль, которую Edge играл за последние годы. Промышленные компании, после фазы перехода к облачным технологиям, осознали, что не всегда можно сделать все в удаленном месте. Причины этого заключаются в следующем:

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


Граничный шлюз (Edge Gateway)


Edge gateway является ядром граничного устройства. Основная обязанность граничного шлюза подключиться к промышленному источнику для сбора и отправки данных их в I-IoT хаб с помощью протокола передачи, такого как MQTT, CoAP, HTTPS или AMQP.
Наиболее важными компонентами пограничного шлюза являются промышленный адаптер и адаптер IoT. Промышленный адаптер обычно подписывается на данные из Field области и публикует их на шине данных. Как правило, он реализует коннектор для выбранного устройства, выступая в качестве источника в потоке данных I-IoT и делает их доступными на шине данных Edge. Адаптер IoT, с другой стороны, получает значения с шины данных и передает их в IoT Data Hub. Важной частью Edge шлюза является компонент Store-and-Forward. Это общий механизм хранения данных во временном локальном хранилище. Он обеспечивает устойчивость передачи данных к нестабильности сети. В глобальной сети нестабильность и задержка канала связи очень высоки. Механизм хранения и пересылки может представлять слудующее:

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

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

Утилиты для конфигурирования (Edge tools)


Edge tools должны иметь следующие особенности:

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


Граничные вычисления (Edge Computing)


Граничные вычисления имеют следующие особенности:
  • Возможность выполнять действия с помощью промежуточного программного обеспечения I-IoT (middleware), как в автономном режиме, так и в сети.
  • Возможность размещения пользовательских приложений
  • Возможность запуска аналитики в автономном оффлайн режиме, совместно с middleware I-IoT или удаленно.
  • Возможность выполнять действия или загружать аналитику из middleware I-IoT
  • Возможность отправлять неструктурированные и специфические данные в middleware I-IoT по требованию или при запуске по условию


Edge реализации


Поставщики облачных и OEM(original equipment manufacturer)-производители разрабатывают различные решения на основе собственной операционной системы или предлагают независимые от облака комплекты разработки программного обеспечения (SDK).

Azure IoT Edge


Azure IoT Edge это Edge решение, предложенное Microsoft для Azure IoT. Платформа поддерживает хранение и пересылку, Edge Analytics и несколько адаптеров для преобразования собственных или стандартных протоколов в интернет-протоколы. Azure IoT Edge также поддерживает OPC-сервер в своих реализациях: OPC Classic и OPC-UA. Обзор продукта:
  • Работает с устройствами Linux или Windows, поддерживающими подсистемы контейнеров.
  • Бесплатная среда выполнения с открытым кодом и лицензией MIT
  • Совместимые с Docker контейнеры из служб Azure или от партнеров Майкрософ Облачный интерфейс. Позволяет удаленно администрировать и развертывать рабочие нагрузки из облака с помощью Центра Интернета вещейт


Greengrass


Greengrass это новое поколение IoT Edge от AWS. AWS предоставляет SDK для создания Edge AWS и расширяет облачные возможности для граничных устройств с Greengrass. Это позволяет устройствам выполнять действия локально, при этом все еще используя облако для управления, аналитики и постоянного хранения. Greengrass поддерживает OPC UA, и не поддерживает OPC Classic. Преимущества:
  • Реакция на события в режиме, близком к реальному времени
  • Работа в автономном режиме
  • AWS IoT Greengrass выполняет аутентификацию и шифрование данных устройств при обмене как по локальной сети, так и с облаком
  • Упрощенное программирование устройств с поддержкой контейнеров


Android Things


Google предоставляет SDK для Edge разработки. Он спонсирует Android как следующее поколение Edge устройств. Особенности платформы:
  • Разработка с использованием Android SDK и Android Studio
  • Доступ к аппаратным средствам, таким как дисплей и камера, через платформу Android
  • Подключение приложения к сервисам Google
  • Интеграция дополнительных периферийных устройств через API периферийного ввода / вывода (GPIO, I2C, SPI, UART, PWM)
  • Использование консоль Android Things Console для отправки обновлений по беспроводной сети и обновления безопасности


Node-RED


Это инструмент визуального программирования для интернета вещей, позволяющий подключать друг к другу устройства, API и онлайн-сервисы. Среда выполнения Node-RED разработана на базе Node.js и благодаря этому максимально использует его событийно-ориентированную, неблокирующую модель. Node-RED это инструмент потокового программирования, первоначально разработанный командой IBM Emerging Technology Services и в настоящее время являющийся частью JS Foundation.
Особенности:
  • Создание программной логики прямо в браузере
  • Среда выполнения Node-RED разработана на базе Node.js
  • Потоки (логические модули), созданные в Node-RED, сохраняются в JSON-файлы, которые можно без труда экспортировать и импортировать
  • Запуск возможен на любом устройстве, поддерживающем node.js
  • Огромное количество расширений


Intel IoT Gateway


Особенности:
  • Связь облака и предприятий.
  • Возможность подключения к датчикам и существующим контроллерам.
  • Предварительная фильтрация выбранных данных для доставки.
  • Локальное принятие решений, обеспечивающее легкое подключение к устаревшим системам.
  • Аппаратный шифрование данных и блокировка программного обеспечения.
  • Локальные вычисления и аналитика в устройстве.


Flogo IOT


Project Flogo это легковесная экосистема с открытым исходным кодом на основе Go для создания приложений, управляемых событиями. Триггеры и действия используются для обработки входящих событий. Интерфейс взаимодействия предоставляет ключевые возможности, такие как интеграция приложений, обработка потоков и т. д.
  • Integration Flows Application движок с условным ветвлением и визуальной средой разработки
  • Потоковая обработка простое действие обработки потока на основе конвейера с возможностью объединения событий по нескольким триггерам и агрегации во временных окнах.
  • Декларативные правила для контекстных решений в реальном времени
  • Шаблон Microgateway для условной маршрутизации на основе содержимого, проверки JWT, ограничения скорости, circuit breaking и другие паттерны


Eclipse Kura


Eclipse Kura это расширяемый IoT Edge Framework с открытым ис ходным кодом, основанный на Java / OSGi. Kura предлагает доступ API к аппаратным интерфейсам шлюзов IoT (последовательные порты, GPS, сторожевой таймер, GPIO, I2C и т. Д.). Он включает в себя готовые к использованию полевые протоколы (включая Modbus, OPC-UA, S7), контейнер приложений и визуальное программирование на основе веб-интерфейса для получения данных, их обработки и публикации в облачные платформы.

EdgeX Foundry


EdgeX FoundryTM это независимый от поставщика проект с открытым исходным кодом, поддерживаемый Linux Foundation, который создает общую открытую среду для граничных вычислений IoT. В основе проекта лежит инфраструктура взаимодействия, размещенная на полной аппаратно-ОС-независимой платформе эталонного программного обеспечения, позволяющей создать экосистему компонентов plug-and-play, которая объединяет рынок и ускоряет развертывание решений IoT.

Варианты подключения Edge к промышленным источникам данных


  • Edge on fieldbus
  • Edge on OPC DCOM
  • Edge on OPC Proxy
  • Edge on OPC UA
  • OPC UA on the controller


Edge on OPC UA and on the controller


Подключение к серверу OPC UA является предпочтительным сценарием, поскольку это позволяет максимально использовать возможности OPC UA. Связь с OPC сервером можно развернуть двумя различными способами. В первом случае Edge подключается к серверу OPC UA через его клиентский интерфейс OPC UA. Источник данных может быть одним из: PLC, DCS, SCADA или Historian.

image

Во втором случае Edge подключается к OPC серверу, установленному прямо на PLC, как ранее было рассмотрено на примере Simatic CPU 1500.

image

MQTT протокол


Издание-подписка (pub/sub), является способом отделить клиента, передающего сообщение от другого клиента, получающего сообщение. В отличие от модели клиент-сервер, клиенты не осведомлены о каких-либо физических идентификаторах, наподобие IP-адреса или порта. MQTT это архитектура pub/sub, но не очередь сообщений. Очереди сообщений по природе своей хранят сообщения, а MQTT нет. В MQTT, если никто не подписывается (или не слушает) на тему, она просто игнорируется и теряется.

image

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

В MQTT есть три уровня качества обслуживания:

  • QoS-0 (незаверенная передача) это минимальный уровень QoS. Это аналогично модели сжечь и забыть, подробно описанной в некоторых беспроводных протоколах. Это самый эффективный процесс доставки без подтверждения получателем сообщения и без повторной передачи сообщения отправителем;
  • QoS-1 (гарантированная передача) этот режим гарантирует доставку сообщения хотя бы один раз получателю. Сообщение может быть доставлено несколько раз, и получатель отправит обратно подтверждение с ответом PUBACK;
  • QoS-2 (гарантированный сервис для приложений) это самый высокий уровень QoS, который убеждается в доставке и информирует отправителя и получателя, что сообщение было передано правильно. Этот режим генерирует больше трафика из-за многошагового рукопожатия между отправителем и получателем. Если получатель получает сообщение с уровнем обслуживания QoS-2, он ответит отправителю сообщением PUBREC. Это подтверждает сообщение, и отправитель ответит сообщением PUBREL. PUBREL позволяет получателю безопасно отбросить любые повторные передачи этого сообщения. Затем PUBREL подтверждается получателем с помощью PUBCOMP. Пока сообщение PUBCOMP не будет отправлено, приемник будет кэшировать исходное сообщение для обеспечения безопасности.


На данный момент существует две версии спецификации протокола MQTT: 3.1.1 и 5.0 github.com/mqtt/mqtt.github.io/wiki/Differences-between-3.1.1-and-5.0. Подробнее описание протокола можно посмотреть здесь docs.oasis-open.org/mqtt/mqtt или запись моей презентации github.com/vladipirogov/Message-Queue-Telemetry-Transport, www.youtube.com/watch?v=fYoGubQFz5c&t=5s и www.youtube.com/watch?v=8mupuCjedlc

В следующей статье я постараюсь на примере показать реализацию кастомной Edge I-IoT платформы используя Node-red в качестве Edge Gateway, Apache Kafka как диспетчер данных и временное хранилище, Kafka Streams как Rule Engine, Mosquitto(возможна другая реализация) как MQTT коннектор. Для хранения данных временных рядов будет использоваться технологии InfluxData.

Источники информации


Источник: habr.com
К списку статей
Опубликовано: 05.07.2020 16:17:42
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Инженерные системы

Интернет вещей

Производство и разработка электроники

Промышленное программирование

Интернет вещей iot

Siemens 1500

Opc-ua

Mqtt

Scada

Edge iot

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru