Всего несколько лет назад промышленный интернет вещи (IIoT) были не больше чем просто модным словечком. Но сегодня это реальность, которая позволяет значительно расширить возможности устройств используемых для автоматизации производств, источников возобновляемой энергии, интеллектуальных сетей и транспортных средств, а также могут быть применены в нефтегазовой отрасли.
Тем не менее, системы, использующие различные протоколы, могут привести к значительным проблемам в промышленных IoT. Если устройства не поддерживают обмен данными на одном языке, то это значит, что нет обмена данными между ними. А если нет обмена данными – нет IoT.
Давайте рассмотрим пример автоматизированного завода по переработке отходов. Интеллектуальные устройства собирают непрерывные данные в реальном времени, включая скорость двигателя, температуру, состояние системы (пуск/стоп), а также видеонаблюдение за некоторыми процессами. Но что делать если некоторые из устройств использую свои протоколы, в то время как другие используют стандартные протоколы? Как построить управление такой системой?
Чтоб избежать такой ситуации делают несколько шагов:
- Выбор подходящего протокола;
- Интеграция различных средств информации и протоколов;
- Эффективная обработка собственных протоколов;
Эти факторы нельзя недооценивать при внедрении современных индустриальных интернет вещей.
Выбор подходящего протокола
Во-первых, для того, чтобы решить проблемы промышленности и позволить руководству успешно разрабатывать и развертывать свои приложения промышленные IoT должны иметь возможность обмениваться информацией и свободно взаимодействовать. Проблема заключается в том, что полевые устройства используют различные языки или протоколы, и каждый из них, имеет свои собственные уникальные свойства и особенности.
Такой широкий и нелегкий выбор стоит практически перед всеми инженерами, работающими с IoT, но в промышленности немного проще, так как там используют два основных протокола обмена данными Modbus и Ethernet / IP.
Протокол Modbus является простым, легким в использовании и экономически эффективным, что делает его идеальным для сбора данных каждые несколько секунд. На Modbus основывается большинство приложений автоматизации. Это де-факто протокол промышленных коммуникаций, после архитектуры master-slave, имеет два основных формата: Modbus RTU и Modbus TCP, модифицированную версию прежнего.
В сущности, оба формата выполняют те же самые функции. Основное различие между ними относится к физическим уровням: Modbus RTU используется в последовательные связи (RS-232 или RS-485), в то время как Modbus TCP обеспечивает связь через TCP/IP -сети. Кроме того, пакеты данных Modbus TCP используют дополнительный заголовок для TCP соединений.
Необходимо обмениваться данными гораздо быстрее и надежнее? Протокол EtherNet / IP отличное решение. Он предоставляет сетевые инструменты для развертывания стандарта Ethernet технологии IEEE 802.3 в сочетании с TCP / IP Suite для приложений промышленной автоматизации при одновременном обеспечении предприятия интернетом и связью.
EtherNet / IP предлагает различные варианты топологии, в том числе обычной звезды со стандартными устройствами инфраструктуры Ethernet или кольца на уровне устройств (DLR) с EtherNet / IP. Функциональность QuickConnect позволяет механизмам обмениваться данными, в то время как сеть работает.
При обновлении системы или развертывания нового приложения IIoT очень важно, что полевые устройства поддерживают открытые стандартные протоколы для гарантии взаимодействия с устройствами других производителей. Протоколы на основе Ethernet используются чаще на полевых участках. Большинство из них являются открытыми стандартными протоколами, такими как Modbus / TCP, Ethernet / IP, OPC UA в области автоматизации, или ONVIF в области видео.
Интеграция различных протоколов и средств информации
Слой поля, управления и контроля, как правило, включают в себя сеть IIoT, при этом каждый слой обладает своим временем отклика и факторами окружающей среды, влияющими на него:
Различные протоколы развернуты для удовлетворения потребностей каждого из этих трех слоев, добавляя по необходимости различные связи между ними. Решение? Развертывание шлюза протокола. Он позволяет собирать информацию от устройств на каждом уровне, хотя они не используют один и тот же протокол. Например, шлюз протокола может преобразовать протокол полевого уровня, используемый в измерителе Modbus RTU к протоколу управления уровнями, например, Ethernet / IP.
Очень важно, что право передачи информации можно использовать для создания наиболее надежной системы IIoT связи. Ваш поставщик должен предоставить ошибкоустойчивое решение в отношении любого вопроса связи, начиная от интерфейсов устройств, таких как RS-232 / RS-485 или удаленного ввода-вывода. Различные сетевые интерфейсы, такие как оптическое волокно, Ethernet и беспроводная связь, а также поддержка различных протоколов, таких как OPC UA или ONVIF.
Обработка собственных протоколов
Большое количество существующих полевых устройств: от счетчиков электроэнергии до серьезных систем автоматизации используют собственные протоколы. В большинстве случаев они используют последовательные интерфейсы.
Для подключения устаревших систем с последовательным интерфейсом к Ethernet на основе IIoT сети, необходимо преобразовать последовательный интерфейс к Ethernet, также называемый как сервер последовательного устройства. Серверы последовательных устройств поддерживают два интерфейса: последовательный интерфейс с одной стороны, и интерфейс Ethernet с другой стороны. Кроме того, серверы последовательного устройства поддерживают виртуальные порты COM, чтобы они работали, как наследие СОМ-портов в существующей системе SCADA, экономя затраты на разработку нового. Также серверы поддерживают сокеты, которые прозрачно преобразует последовательные данные в TCP или UDP пакеты.
Подключение последовательных устройств к одной системе SCADA является простым и легким. Когда дело доходит до IoT все становится гораздо сложнее, поскольку собранные данные, возможно, должны быть переданы в облако. Система SCADA и приложение удаленного облака может выдать команду одновременно к последовательному устройству через сервер. Таким образом, сервер должен обрабатывать запросы по очереди по принципу первый вошел – первый вышел (FIFO). То есть первым будет обработан тот запрос (отправлен к последовательному устройству), который пришел на сервер, остальные будут ожидать в очереди.
После того, как сервер последовательного устройства получает ответ, он будет посылать ответ на соответствующие запросы SCADA системы или облачного приложения и обработает следующий запрос в очереди FIFO. Этот вид командной обработки является очень важным в IoT приложениях многократного опроса из-за большого количества последовательных устройств, поддерживающих собственные протоколы.
Последовательный сервер не знает, как разделить последовательные данные в TCP пакетах. Серверы не понимают последовательные форматы данных, так что они могут поместить ответ от устройства последовательной передачи данных в два или более пакетов TCP. Это приведет к тому, что система SCADA или облако приложения будут отвергать эти пакеты как неправильные ответы, так как они ожидают, что каждый пакет TCP будет представлять один ответ от последовательного устройства.
Чтобы обойти эту проблему, серверы последовательного устройства должны поддерживать гибкие варианты данных упаковки, так как собственный протокол может иметь различный формат. Например, фиксированные длины данных или специальные символы-разделители могут быть использованы для идентификации ответов одиночных серийных устройств. Это означает, что сервер будет продолжать получать данные из последовательного устройства, а не передавать его на Ethernet, пока он не получит фиксированное количество данных или разделительных символов. Без поддержки вариантов данных упаковки, вам придется разрабатывать сложные SCADA программные приложения для обработки TCP пакетов должным образом. Эти альтернативы тратят время и также могут создавать ошибки в системе.
Для обработки большого числа удаленных соединений надлежащим образом, серверы последовательного устройства должны поддерживать гибкое управление соединением. Лучший способ сделать это так, чтобы открыть соединение только тогда, когда последовательные данные, получены от устройства. Когда передача завершена, то сервер должен закрыть соединение как можно скорее. Без поддержки гибкого управления соединением, вам придется потратить дополнительные время на соединение и обработку в центральном узле или облаке приложения.
Выводы
Промышленные системы IIoT гораздо более сложны, чем любые другие потребительские IoT или традиционные M2M. Среда промышленные интернет вещей состоит из устаревших устройств с более старыми протоколами обмена и требует разнообразных средств для организации обмена данными с широким спектром других подключенных устройств в сети, начиная от датчиков и роботов для 3D принтеров, и заканчивая резервуарами для смешивания химических элементов. Связь, очевидно, является ключевым компонентом IIoT. Понимание того, как преодолеть проблемы протокола связи, помогает выполнить обещание IoT для более эффективного и прибыльного производства экосистемы.
