Данный топик просвещен проблеме обмена данными в системах промышленной автоматизации м\у ПЛК и различным программном обеспечении. Прежде чем приступить непосредственному к изложению, хочу сказать, что нахожусь в дурацком положении… Дело в том, что основная часть моих коллег по цеху не являются ИТ-специалистами и работаю в рамках тех инструментальных средств, которые являются стандартом «де-факто» — SCADA пакеты, среды разработки для ПЛК и OPC сервера. Мало кого из них интересует, что находится под «капотом» этих инструментов, хотя большинство проблем, об которые они спотыкаются, кроются именно там и заложены в базовых технологиях. С другой стороны АСУ ТП довольно специфичная область и я не уверен, что программист без опыта работы в данной сфере сможет проникнутся тем, что я попытаюсь донести в этом посте. Вот и получается, что данный топик предназначен для небольшого процента специалистов, которые разбираются в ИТ и АСУ ТП одновременно.
С развитием АСУ ТП перед производителями ПЛК и программного обеспечения встала проблема взаимодействия м\у устройствами и ПО работающими по разным протоколам. Решением этой проблемы по инициативе Microsoft стал протокол OPC в основе которого первоначально лежала DCOM технология. Данный протокол на текущий момент используется повсеместно и не смотря на довольно развитую номенклатуру спецификаций, подавляющее большинство реализаций основывается на DCOM технологии, что и стало причиной множества проблем:
Как видите проблем достаточно много, чтобы начать поиск альтернативы.
Когда я в качестве хобби занимался разработкой веб приложений на RubyOnRails, я был поражен как просто решаются задачи передачи данных с помощью REST модели! Тогда я задумался о возможности применения такого подхода в АСУ ТП. Как позже оказалась, что данная идея уже сформулирована специалистом из Австралии Томом Тoденхэмом, здесь можно прочитать его труд по этой теме (или мой перевод). Чтобы пробудить интерес к этой идеи, приведу тезисы о ее преимуществах:
Как пример простой реализации на Ruby, можете почитать мою статью. Так же есть проект для REST доступа к периферии Arduino - RESTdunio
Автор статьи о REST-PCA Том создал сайт xpca.org/ и инициировал создание новой архитектуры для систем промышленной автоматизации XPCA (eXtensible Process Control Architecture), которая включает в себя обмен данными в стиле REST, после чего ушел в тень… Так же существует рассылка по данной теме — XPCA Google Group, которая в данный момент не активна. По задумке автора, спецификации нового протокола будут разрабатываться на основе краудсорсинга и будут открытыми.
Я же в свою очередь запустил опенсорсный проект первой реализации XPCA сервера на .NET\Mono — Galilei. На данный момент Galilei поддерживает REST интерфейс для конфигурации и симулятор случайных чисел, в ближайшем будущем планирую написать драйвера для ModBus и OPC. Если есть желающие помочь проекту и присоединиться к сообществу буду очень рад.
Спасибо за внимание)
Критика OPC
С развитием АСУ ТП перед производителями ПЛК и программного обеспечения встала проблема взаимодействия м\у устройствами и ПО работающими по разным протоколам. Решением этой проблемы по инициативе Microsoft стал протокол OPC в основе которого первоначально лежала DCOM технология. Данный протокол на текущий момент используется повсеместно и не смотря на довольно развитую номенклатуру спецификаций, подавляющее большинство реализаций основывается на DCOM технологии, что и стало причиной множества проблем:
- Работа в сети. OPC имеет клиент северную архитектуру на базе DCOM технологии компании Microsoft. Поддержка обмена данными по сети в DCOM ограничена и требует дополнительной настройки безопасности узлов. Таким образом внедрение OPC в многоуровневых корпоративных сетях Intranet затруднено, а передача данных через Internet просто невозможна. Данный недостаток критичен при построении систем уровня MES или ERP, что приводит к необходимости внедрения специальных шлюзов, которые транслируют данные между собой в своём формате не ограниченным DCOM и предоставляют данные по OPC.
- Привязка к Windows. DCOM технология поддерживает только ОС Windows, что не позволяет разворачивать OPC сервера в контроллерной части и создавать клиентское ПО АСУТП для мобильных устройств (на базе iOS, Android и т. д.). По той же причине нет возможности использовать устойчивые к вирусным атакам системы на базе Unix(Linux) для сбора и хранения данных.
- Конфигурация. Основным понятием OPC технологии является тег, чтобы получить данные о каком либо сигнале необходимо «завести» его в конфигурации OPC сервера и в конфигурации каждого клиентского ПО. Таким образом затраты на конфигурацию возрастают пропорционально количеству клиентов и уровней в системе автоматизации. Кроме того, часто эти уровни или клиенты обслуживаются разными организациями, которые просто могут не узнать оперативно о новых данных, что приводит к неактуальности показаний их систем.
- Закрытость протокола. Технология OPC позиционируется как «открытая» технология, но это совсем не так. Доступ к спецификации и к инструментам для разработки предоставляется только членам OPC Fundation на платной основе. Такая бизнес модель сплотила между собой крупные компании производители, а все остальные стали потребителями уже готовых продуктов. Даже для тривиальной задачи в области АСУ ТП на базе OPC приходится что-то покупать.
Как видите проблем достаточно много, чтобы начать поиск альтернативы.
REST в промышленной автоматизации
Когда я в качестве хобби занимался разработкой веб приложений на RubyOnRails, я был поражен как просто решаются задачи передачи данных с помощью REST модели! Тогда я задумался о возможности применения такого подхода в АСУ ТП. Как позже оказалась, что данная идея уже сформулирована специалистом из Австралии Томом Тoденхэмом, здесь можно прочитать его труд по этой теме (или мой перевод). Чтобы пробудить интерес к этой идеи, приведу тезисы о ее преимуществах:
- Работа в сети. Использование HTTP протокол, как транспорт, позволяет передавать данные через интернет и многоуровневые корпоративные сети. Так же он не требует дополнительной настройки узлов в отличие от OPC технологии.
- Независимость от платформы. HTTP поддерживаться всеми операционными системами, что позволяет создавать клиенты под мобильные устройства. К тому же, ввиду простоты HTTP возможно реализовывать REST сервера на уровне контроллеров и снимать с них данные без промежуточных шлюзов.
- Конфигурация. Так как основным понятием REST является ресурс, то возможен групповой доступ к данным (подобно доступу к таблице в SQL), таким образом, новые данные в системе могут обрабатываться автоматически без дополнительной конфигурации. Так же стоит отметить, что HTTP позволяет не только получать данные с ресурсов, но и создавать и настраивать их, что позволяет управлять REST сервером со стороны клиентской части с помощью универсальных методов.
- Открытость. REST использует открытые стандарты передачи и представления данных (HTTP, HTML, XML, JSON …), которые поддерживаются всеми языками программирования и платформами, что позволяет создавать приложения автоматизации с минимальными вложениями в инструментальные средства.
Как пример простой реализации на Ruby, можете почитать мою статью. Так же есть проект для REST доступа к периферии Arduino - RESTdunio
Текущее положение дел и планы на будущее
Автор статьи о REST-PCA Том создал сайт xpca.org/ и инициировал создание новой архитектуры для систем промышленной автоматизации XPCA (eXtensible Process Control Architecture), которая включает в себя обмен данными в стиле REST, после чего ушел в тень… Так же существует рассылка по данной теме — XPCA Google Group, которая в данный момент не активна. По задумке автора, спецификации нового протокола будут разрабатываться на основе краудсорсинга и будут открытыми.
Я же в свою очередь запустил опенсорсный проект первой реализации XPCA сервера на .NET\Mono — Galilei. На данный момент Galilei поддерживает REST интерфейс для конфигурации и симулятор случайных чисел, в ближайшем будущем планирую написать драйвера для ModBus и OPC. Если есть желающие помочь проекту и присоединиться к сообществу буду очень рад.
Спасибо за внимание)