Концепция REST-PCA

Пару лет назад нашел интересную статью о применении REST технологии в системах автоматизация, как альтернативу семейству OPC протоколов. Руки дошли и я ее наконец перевел.  Вот вариант в PDF - rest-pca.ru.pdf.




Введение

Наиболее широко распространенные стандарты для коммуникации с устройствами промышленного автоматизации, вероятно, является семейство протоколов, продвигаемые организацией OPC Foundation. Из них, как технологий основанных на Microsoft Windows, сейчас платформонезависима только OPC UA (Unified Architecture), протокол OPC вырос в зрелое множество стандартов взаимодействия внутри промышленной индустрии.

Пока основная часть OPC спецификаций не вызывают сомнений, структура и механизмы OPC находится в постоянной разработке, что таит в себе несколько потенциальных проблем для производителей и покупателей продуктов и услуг промышленной автоматизации. REST-Process Control Architecture (REST-PCA) предлагает упрощенную модель взаимодействия в управлении процессами производства, как попытку решения этих проблем.

REST-PCA не является заменой OPC-UA. Вместо этого его целью является предоставление альтернативной модели для тех решений, где OPC UA не подходит. 

Проблемы с OPC UA

Протокол OPC UA основан на SOAP.
Протокол OPC UA предоставляет два способа передачи данных бинарный и SOAP, что является значительным улучшением для протокола основанного только на DCOM. Однако, оба подхода требуют компромиссов между читабельностью и скоростью, т.к. SOAP предоставляет прозрачную модель данных за счет увеличения объема данных передоверяемых по сети.

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

Выбор OPC Foundation SOAP -а для передачи данных в OPC UA обоснован очевидной важностью взаимодействия с бизнес системами, использующие данный протокол. Хотя затраты не так прозрачны для организаций выбиравших более простую модель как REST, в то время как, навязывание SOAP может добавить лишние затраты и сложность в их программное обеспечение.

OPC UA не полностью открыт

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

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

Мы считаем что текущее техническое и организационное состояние технологии делают OPC UA не подходящей во многих случаях, которые включают:

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

Кроме того, мы считаем, что бесспорная сложность OPC UA структуры представляет потенциальный барьер для инновации.

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

Введение в протокол REST-PCA

REST-PCA предлагает простую модель взаимодействия между программным обеспечением и системами промышленной автоматизации. Центром этой модели является REST протокол - подход к конструированию Веб служб впервые предложенным в 2000 Ройем Филдингом (Roy Fielding), одним из создателей протокола HTTP.

Короткая справка по REST

REST или REpresentation State Transfer - термин используемый для описания простого структурного стиля для передачи данных поверх HTTP протокола, без каких либо дополнительных транспортных уровней типа SOAP и XML-RPC.

Главным для REST является принцип информационного ресурса - источника данных, который может быть адресован через глобальный идентификатор (т.е. HTTP URI). Операции над REST ресурсами ограничено, так называемыми, CRUD методами (Create, Read, Update и Delete), проецируемые на HTTP методы POST, PUT, GET и DELETE. В REST URI могут быть использованы для доступа к любому единичному или массиву ресурсов, представленные с использованием основных форматов данных, таких как XML, JSON или HTML.

Например, веб клиент выполняет запрос на список всех доступных устройств и ожидает XML список содержащий сводку по доступным устройствам "ресурсам":

GET http://example.com/devices/

[returns]

<devices>
  <device name="device1">
    ...
  </device>
  <device name="device1">
    ...
  </device>
</devices> 

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

 

GET "http://example.com/devices/device1.json"

[returns]

{
  "device": {
    "name": "device1",
    "state": "running"
    "rpm": 120
  }
}

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

Предоставление ресурсов в REST также имеет высокую переносимость. Как простые ссылки URI HTTP, они могут быть использованы в закладках, в документации или отправлены по почте. И до тех пор,пока клиентские системы понимают возвращаемые форматы дынных (XML, JSON, HTML), они могу получить доступ и обновлять ресурсы с относительно небольшим количеством кода.

Благодаря использованию REST архитектуре, REST-PCA реализует практичный подход к предоставлению процесса управления как веб-доступного сервиса и создает возможность для интеграции с широким кругом бизнес систем.

Философия протокола REST-PCA

Движущие принципы:

• Простота
• Открытость
• Инновация через универсальность, а не изобретение заново

Ожидаемый результат:

• Простой доступ к различным представлениям данным, используя принципы REST 
• Открытый, основный на сообществе подход к разработке стандартов

Польза от использования протокола REST-PCA

Если сравнивать с OPC UA моделью передачи данных, REST-PCA находится посередине между бинарной и SOAP реализацией - предоставляя большую читаемость данных, чем чисто бинарное представление без дополнительных расходов на типичные для SOAP посылки сообщений.

Так как REST основан на HTTP протоколе, он может быть легко использован традиционными веб приложениями. Он задумывался, и действительно предназначен для того, что бы веб обозреватель и другие веб клиенты могли быть использованы, как HMI интерфейсы. REST-PCA также легко интегрируется со сторонними приложениями уровня предприятия.

REST-PCA адресное пространство

REST-PCA адресное пространство может рассматриваться, как последовательность узлов и контейнеров, представляемые в виде REST ресурсов.

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

Пример отображения ModBus

ModBus/TCP протокол следует такому же архитектурному стилю как и REST и в следствии отображается в REST-PCA напрямую. Интуитивная реализация подразумевает простое отображение ModBus контактов и регистров, как вложенные ресурсы в ведомых ModBus, которые сами представлены в виде ресурсов. Например, предположим "on" и "off" внутренне отображаются в ModBus 0xFF и 0x00 выходные значения:

GET http://example.com/modbus/remote-slaves/0xAF/coils/0xCA

Вернет XML фрагмент <coil address="0xCA" value="on" /> представляющий текущее состояние контакта с адресом 0xCA в ведомом с адресом 0xA, в то время как:

 

PUT http://example.com/modus/remote-slaves/0xAF/coils/0xCA ["value" => "off"]

Нет никаких причин, для того что бы адресам не могут быть даны осмысленные имена, например /modbus/agrigator/coils/top-valve. Любые имена предполагаются как часть реализации приложения, доступное через механизмы обнаружения REST-PCA.

Пример отображения в TC-6 XML

Форматом TC-6 от PLCOpen является суженным XML форматом для переноса программ PLC м/у различными системами. Он структурно приближен к внутреннему представлению данных PLC и становится кандидатом для отображения данных PLC во внешние системы. Отображение TC-6 в REST-PCA предоставляет механизм для дальнейшего мониторинга и манипуляции данными процесса. Например, запрос ресурса 'bin-6' вернет фрагмент TC-6 текущего состояния части полевого оборудования в XML:

 

GET http://example.com/tc6/devices/modicon-tsx/variables/bin-6

возращает

<variable name="bin-6">
<status alarms="0x000000A0" max-feed-tpm="1.2"
purged="false" stopped="true" />
</variable>

А запрос:

PUT http://example.com/tc6/devices/modicon-tsx/variables/bin-6 ["status" => ["stopped"="false"]]

Может перезапустить полевое оборудование.

Пример отображения сложного объекта автоматизации

REST-PCA также может использоваться для доступа к ресурсам представляющие состояние объектов, находящиеся в SCADA или в функционально похожей системе. Эти "богатые" ресурсы в смысле, количества значений снятые с PLC сырых данных процесса и включая абстрактные данные не существующие на уровне PLC и других устройств управления. В следующем примере, запрос JSON представления активной последовательной загрузки, возвращает обработанные значения предоставляемые SCADA системой:

 

GET http://example.com/loading-sequence/3d2d.json

возвращает

{
  "loading-sequence: {
     "id": "3d2d",
     "time_started": "2009-11-11T12:45:44",
     "amount_moved": "1505Ml",
     "state": "running",
     "down_time": "12.5mins",
     "predicted_end_time": "2009-11-11T12:59",

  }
}

Пример отображения объектов предприятия

Как и, представление модели сложных объектов автоматизации через REST ресурсы, можно представить бизнес данные через REST-PCA. В примере ниже, исторические данные поставок подсчитываются, а затем представляются в виде узла в некотором REST-PCA адресном пространстве, как и все другие данные.

GET http://example.com/shipments/daily-tallies/20090405

возвращает

<daily-tally date="2009-04-05"
  tonnes-moved="1205"
  estimated-co2-emissions="134kg" />

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

Модель безопасности REST-PCA

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

HTTP аутентификация

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

API ключ

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

API ключ + секретный ключ

Предоставляет два ключа: API ключ, посылаемый с каждым запросом и секретный ключ, используемый клиентом для "подписи" каждого запроса и проверяется сервером при авторизации. Даже если запрос перехвачен злоумышленником, он не сможет использовать его, для создания ложных запросов потому, что секретный ключ никогда не раскрывается. Данная модель используется Amazon Web Services и другими похожими поставщиками защищенных веб сервисов.

Использование SSL и HTTPS протоколов в REST-PCA обеспечивает дополнительнyю защиту. Другие схемы и технологии могут быть использованы в зависимости от требований приложения.

Механизм обнаружения REST-PCA

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

Какой бы механизм обнаружение REST-PCA не использовал, он должен быть основан на распространенном протоколе. Наиболее подходящий кандидат Atom Publishing Protocol - основанный на REST стандарт для публикации описаний веб служб.

Так как Atom PP использует такую же архитектурную модель как и REST-PCA, это делает его резонно подходящим, хотя на этот счет требуется некоторые исследования.

Лицензия протокола REST-PCA

Протокол REST-PCA будет доступен в соответствии с Creative Commons лицензией, которая снимает все ограничения на его использование.


Обновления:
Идеолог REST-PCA Том Тoденхэм переименовал технологю REST-PCA  в XPCA, таки образом все статии в моем блоге под названием XPCA тоже относятся к изложеной выше концепции.