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

    Что такое I-IoT



    image

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

    image

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

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

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

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

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

    Термин 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 объединяет и определяет набор бизнес-процессов, регулирующих обмен информацией и данными между задействованными системами. Также собирает и передает данные о транзакциях, поступающие из разных отделов организации, обеспечивая тем самым целостность данных и, выступая в качестве единого источника.

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


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

    • Уровень 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


    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 с целью заменить все существующие версии на основе COM и преодолеть проблемы безопасности и производительности. Стандарт удовлетворяет потребность в независимых от платформы интерфейсах и позволяет создавать расширяемые модели данных для описания сложных систем без потери функциональности. Информация об архитектуре OPC UA представлена на сайте.
    Протокол 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 реализована посредством определения безопасного канала, на котором основан сеанс. Безопасный канал осуществляет обмен данными следующим образом:

    • Обеспечивает целостность данных с использованием цифровых подписей.
    • Обеспечивает конфиденциальность посредством шифрования.
    • Выполняет аутентификацию и авторизацию приложений с использованием сертификатов 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.
    Я выполнял установку симулятора версии 3 на систему с имеющимся пакетом Simatic TIA Portal V14 SP1. Перед установкой инсталлятор уведомил о том, что PLCSIM V14 не совместим с SIMATIC S7-PLCSIM V3, и его необходимо удалить. Я выполнил эти действия, после чего установка прошла успешно. В TIA Portal был создан тестовый проект с CPU 1512C-1 PN. Особенностью стало то, что выполнить имуляцию с помощью кнопки «Start simulation» стало невозможно, однако работает кнопка «Download 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, который можно скачать с сайта.
    Для подключения к OPC серверу необходимо добавить новое соединение и прописать Endpoint Url, ранее установленное в настройках проекта OPC сервера в TIA Portale, в моем случае – это opc.tcp://192.168.1.113:4840
    image

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


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

    pip install freeopcua
    pip install cryptography
    

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

    from opcua import Server
    from random import randint
    import datetime
    import time
    
    class 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 variable
    
    def 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 Client
    import time
    
    url = "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 или от партнеров Microsoft Cloud Interface. Позволяет удаленно администрировать и развертывать рабочие нагрузки из облака с помощью Центра Интернета вещей.

    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.
    Подробнее описание протокола можно посмотреть здесь или в моей презентации:



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

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


    EPAM
    Компания для карьерного и профессионального роста

    Похожие публикации

    Комментарии 4

      0
      Видео к теме.
      Международная конференция FIT-M 2019, спикеры В.А.Холопов и А.В.Парфенов,3 ноября 2019 г., Москва. Спикеры: заведующий кафедрой промышленной информатики Института информационных технологий РТУ МИРЭА Холопов В.А., исполнительный директор НИИ Вычислительных Комплексов им. М.А. Карцева Парфенов А.В. Доклад о перспективах использования технологии AFS/AFM (Advanced Forth System и Форт-машины) в современных системах «умного производства» Индустрии-4.0 и промышленного «интернета вещей» (Industrial IOT).


      P.S. Ну, и что то близкое, было в тематике разработки сенсорных сетей.
      Д.В. Рагозин «Экономичный интерпретатор для узлов сенсорной сети».pdf
        0
        Ну и где обзор прикладных (промышленных) платформ «Интернета вещей»?
        Например, PTC ThingWorx?
        Edge — это же конструктор, или скорее прослойка, между сетью и средой исполнения приложений. Поверх него ещё кода придется написать огромное количество.
          0
          Я думаю неплохие обзоры промышленных IoT платформ уже есть в сети. Например PTC ThingWorx — www.youtube.com/watch?v=f2lB9uvP_B4, Siemens MindSphere -https://www.youtube.com/watch?v=myb_l1OKLIg&t=1816s, GE IoT Predix — www.youtube.com/watch?v=74-J5nH4jlo. В данной статье я хотел более акцентировать внимание именно на Edge (не cloud) платформых. Не совсем понятно, откуда вы взяли такое определение Edge, и что такое «среда исполнения приложений». На счет кода — согласен, писать прийдеться, и я планирую привести простой пример в следующей статье
            0
            Среда исполнения приложений — это немного более высокий уровень, чем операционная система. Сейчас уже нет смысла делать прикладные системы в виде исполняемых (компилируемых в нативный код) модулей. Гораздо лучше использовать средство — среду, внутри которой будут реализованы ваши приложения, пусть даже на каком-нибудь скриптовом языке. Но очень важно наличие специализированных возможностей, интегрированных в эту «среду исполнения».

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

        Самое читаемое