Я очень хорошо понимаю о чем вы говорите, перед тем как обратить внимание на REST, я как то пытался написать свободный OPC XML DA сервер c использованием WSDL… Для серверной части вообще штука очень даже клевая и у REST такого нет, а вот на клиенской части мне кажется REST обыгрывает, т.к. доступ к данным можно организовать без SDK или «рыб», а с помощью стандартных HTTP библиотек. Наверно поэтому я и пришел к REST, хотелось делать проще все)
Уважаемый, я не в коем случае не хотел Вас пугать)
Я прекрасно понимаю разницу между стандартами и технологиями. Согласен, даже с тем что заголовок звучит не совсем корректно, верно что REST это технология, а OPC протокол. Но если бы я написал по другому, не думаю что из названия можно было бы понять о чем речь.
Насчет, вашего «отеческого совета», я хотел, что бы вы внимательней еще раз прочитали, что здесь написано… речь идет о создании, как раз таки, такого стандарта, причем открытого, на базе более легковесной технологий. Я лишь представляю идею над которой работаю. Не надо оскорбляться)
Кстати, именно поэтому в OPC используется SOAP, а не REST. В REST на сегодня даже нет единого формата описания схемы ресурсов (несколько черновых и недоделанных — не в счет)
У REST нет описания схемы ресурсов потому, что это задача уровня приложения. Так же, как в SOAP не описана симантика процедур. OPC UA как раз ее и описывает, я же предлагаю идею стандарта, который описывает схему ресурсов REST под задачи автоматизации.
По соображениям безопасности, я бы не стал так делать. Да и не дадут. Все таки отображение данных через интернет это одно, а вот управление и конфигурация это совсем другое дело.
Таски я не писал, писал только код. Но если действительно будет интересно, расскажу обо всем подробнее) И составлю более детальный план действий.
В принципе, в этом топике все ссылки на материалы для изучения, больше ничего пока нет. Если решите, что стоит этим заняться, пишите. Буду очень рад!
К сожалению не имею OPC UA спецификации, но если я не ошибаюсь та часть которая работает по HTTP представляет собой SOAP. SOAP в свою очередь использует RPC модель взаимодействия м\у клиентом и сервером. Преимущество REST в данном случае, что я могу получить данные с помощью обычного HTTP запроса даже в обычном браузере, а вот для SOAP придется организовывать вызов — пример. Поправьте, пожалуйста если я ошибаюсь.
Использование REST идеологии, делает сервера и клиенты намного «тоньше», вот за что я воюю.
А по объему работы… конечно я согласен, что одному не по силам все это сделать. Надеюсь, что на каком то этапе появятся люди, которые смогут помочь не только на словах, но и делом. Если же этого не произойдет, то значит это было не нужно, и смысла работать над этим нет.
Честно говоря, мне вообще не понятно зачем системы АСУ ТП подключать к интернету? Для того, чтобы крутой начальник мог на мнемосхемы из своего домашнего туалета посмотреть? Это бред.
Конечно напрямую подключать АСУ ТП в интернет — бред. Но вот вытягивать необходимые параметры с узлов в систему более высокого уровня, последующая их обработка и предоставление данных через веб-портал для обзора работы предприятия как единого целого, интеграция с ERP системами, и т.д — на настоящий момент актуальная задача. Я видел в ГазПромНефть прекрасный веб -портал которым пользовались практически все сотрудники предприятия и он действительно был нужен и полезен. И на нефтеперерабатывающих заводах РСУ интегрируют с системами MES уровня и организуют нечто подобное. Только системы на базе PI System работают оооочень коряво на мой взгляд, а вод веб решения куда более позитивно воспринимаются пользователями.
Да OPC UA — это шаг на встречу, но есть и там изъяны.
1. Опять же закрытый стандарт;
2. RPC модель довольно громоздка.
3. Поддержка SCADA систем намного меньше, чем у OPC DA. Хотя это со временем конечно измениться.
Согласен, но надеюсь, что ситуация измениться и REST (наверно лучше сказать XPCA) приживется если появятся работающие реализации, у меня в голове такой план:
1. Создание прототипа серверной части (мой проект Galilei). Кстати пишу на C# не потому что очень уж его люблю, а потому что надеюсь что под флагом .NET у него больше шансов прижиться в нашей отрасли.
2. Пилотный проект на реальном объекте (выпросил у начальства крохотный проект для этой цели)
3. Создание черновика спецификации, протокола XPCA.
4. Создание OPC сервера для XPCA, что позволит использовать XPCA как туннель OPC протокола.
5. Расширения для SCADA систем, где это возможно. Причем как драйвера, для получения данных с XPCA серверов, так и поддержку получения данных по XPCA для систем верхнего уровня.
Да ведь не работает… Я занимался глобальной интеграцией АСУТП достаточно большого предприятия в MES систему, не смогли мы использовать OPC для этого. Купили в результате OPC-тунель. Получилось и работы больше по настройке и денег кучу потратили.
Я не предлагаю отказаться от SCADA и начать писать самописные программы, я предлагаю другой способ взаимодействия. Если идея переродиться в открытый стандарт и будет работать, то появиться и драйвера для SCADA систем и поддержка производителей. Будем вспоминать OPC как страшный сон)) (Мечты конечно)
Совершенно с Вами согласен, а чтобы было больше «гражданских» применений нужны открытые стандарты и технологии. ModBus у нас есть, теперь нужен открытый и переносимый аналог OPC.
веду проект на базе Ruby on Rails в области промышленной автоматизации
Очень интересно! Можете рассказать пару слов о нем?
Мое мнение, что объедение в сети подобные сетям майнинга bitcoin для взлома мало вероятна) Все таки у bitcoin есть светлая Идея — независимые деньги. Многие просто не захотят тратить время на деструктивные действия взлома, даже за деньги.
Я прекрасно понимаю разницу между стандартами и технологиями. Согласен, даже с тем что заголовок звучит не совсем корректно, верно что REST это технология, а OPC протокол. Но если бы я написал по другому, не думаю что из названия можно было бы понять о чем речь.
Насчет, вашего «отеческого совета», я хотел, что бы вы внимательней еще раз прочитали, что здесь написано… речь идет о создании, как раз таки, такого стандарта, причем открытого, на базе более легковесной технологий. Я лишь представляю идею над которой работаю. Не надо оскорбляться)
У REST нет описания схемы ресурсов потому, что это задача уровня приложения. Так же, как в SOAP не описана симантика процедур. OPC UA как раз ее и описывает, я же предлагаю идею стандарта, который описывает схему ресурсов REST под задачи автоматизации.
В принципе, в этом топике все ссылки на материалы для изучения, больше ничего пока нет. Если решите, что стоит этим заняться, пишите. Буду очень рад!
Почитайте пожалуйста ветку комментов над вашей. Я там пытаюсь разъяснить, какие преимущества дает REST модель, перед OPC UA.
Использование REST идеологии, делает сервера и клиенты намного «тоньше», вот за что я воюю.
А по объему работы… конечно я согласен, что одному не по силам все это сделать. Надеюсь, что на каком то этапе появятся люди, которые смогут помочь не только на словах, но и делом. Если же этого не произойдет, то значит это было не нужно, и смысла работать над этим нет.
Конечно напрямую подключать АСУ ТП в интернет — бред. Но вот вытягивать необходимые параметры с узлов в систему более высокого уровня, последующая их обработка и предоставление данных через веб-портал для обзора работы предприятия как единого целого, интеграция с ERP системами, и т.д — на настоящий момент актуальная задача. Я видел в ГазПромНефть прекрасный веб -портал которым пользовались практически все сотрудники предприятия и он действительно был нужен и полезен. И на нефтеперерабатывающих заводах РСУ интегрируют с системами MES уровня и организуют нечто подобное. Только системы на базе PI System работают оооочень коряво на мой взгляд, а вод веб решения куда более позитивно воспринимаются пользователями.
1. Опять же закрытый стандарт;
2. RPC модель довольно громоздка.
3. Поддержка SCADA систем намного меньше, чем у OPC DA. Хотя это со временем конечно измениться.
1. Создание прототипа серверной части (мой проект Galilei). Кстати пишу на C# не потому что очень уж его люблю, а потому что надеюсь что под флагом .NET у него больше шансов прижиться в нашей отрасли.
2. Пилотный проект на реальном объекте (выпросил у начальства крохотный проект для этой цели)
3. Создание черновика спецификации, протокола XPCA.
4. Создание OPC сервера для XPCA, что позволит использовать XPCA как туннель OPC протокола.
5. Расширения для SCADA систем, где это возможно. Причем как драйвера, для получения данных с XPCA серверов, так и поддержку получения данных по XPCA для систем верхнего уровня.
Я не предлагаю отказаться от SCADA и начать писать самописные программы, я предлагаю другой способ взаимодействия. Если идея переродиться в открытый стандарт и будет работать, то появиться и драйвера для SCADA систем и поддержка производителей. Будем вспоминать OPC как страшный сон)) (Мечты конечно)
Очень интересно! Можете рассказать пару слов о нем?
Лучше бы создатель к разработке RedCar вернулся(