flipback flipback

Я очень хорошо понимаю о чем вы говорите, перед тем как обратить внимание на REST, я как то пытался написать свободный OPC XML DA сервер c использованием WSDL… Для серверной части вообще штука очень даже клевая и у REST такого нет, а вот на клиенской части мне кажется REST обыгрывает, т.к. доступ к данным можно организовать без SDK или «рыб», а с помощью стандартных HTTP библиотек. Наверно поэтому я и пришел к REST, хотелось делать проще все)

Нету еще стандарта) Coming soon…

Уважаемый, я не в коем случае не хотел Вас пугать)

Я прекрасно понимаю разницу между стандартами и технологиями. Согласен, даже с тем что заголовок звучит не совсем корректно, верно что REST это технология, а OPC протокол. Но если бы я написал по другому, не думаю что из названия можно было бы понять о чем речь.

Насчет, вашего «отеческого совета», я хотел, что бы вы внимательней еще раз прочитали, что здесь написано… речь идет о создании, как раз таки, такого стандарта, причем открытого, на базе более легковесной технологий. Я лишь представляю идею над которой работаю. Не надо оскорбляться)

Кстати, именно поэтому в OPC используется SOAP, а не REST. В REST на сегодня даже нет единого формата описания схемы ресурсов (несколько черновых и недоделанных — не в счет)

У REST нет описания схемы ресурсов потому, что это задача уровня приложения. Так же, как в SOAP не описана симантика процедур. OPC UA как раз ее и описывает, я же предлагаю идею стандарта, который описывает схему ресурсов REST под задачи автоматизации.

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

Таски я не писал, писал только код. Но если действительно будет интересно, расскажу обо всем подробнее) И составлю более детальный план действий.
В принципе, в этом топике все ссылки на материалы для изучения, больше ничего пока нет. Если решите, что стоит этим заняться, пишите. Буду очень рад!

Извиняюсь, Вы же и писали ветку выше) Не увидел.

Все верно.

Почитайте пожалуйста ветку комментов над вашей. Я там пытаюсь разъяснить, какие преимущества дает REST модель, перед OPC UA.

К сожалению не имею OPC UA спецификации, но если я не ошибаюсь та часть которая работает по HTTP представляет собой SOAP. SOAP в свою очередь использует RPC модель взаимодействия м\у клиентом и сервером. Преимущество REST в данном случае, что я могу получить данные с помощью обычного HTTP запроса даже в обычном браузере, а вот для SOAP придется организовывать вызов — пример. Поправьте, пожалуйста если я ошибаюсь.

Использование REST идеологии, делает сервера и клиенты намного «тоньше», вот за что я воюю.

А по объему работы… конечно я согласен, что одному не по силам все это сделать. Надеюсь, что на каком то этапе появятся люди, которые смогут помочь не только на словах, но и делом. Если же этого не произойдет, то значит это было не нужно, и смысла работать над этим нет.

Если вы захотите организовать веб портал, на котором будут отображаться данные с OPC UA сервера, как вы поступите?

Честно говоря, мне вообще не понятно зачем системы АСУ ТП подключать к интернету? Для того, чтобы крутой начальник мог на мнемосхемы из своего домашнего туалета посмотреть? Это бред.

Конечно напрямую подключать АСУ ТП в интернет — бред. Но вот вытягивать необходимые параметры с узлов в систему более высокого уровня, последующая их обработка и предоставление данных через веб-портал для обзора работы предприятия как единого целого, интеграция с 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 в области промышленной автоматизации

Очень интересно! Можете рассказать пару слов о нем?

danlucraft/git.js

Лучше бы создатель к разработке RedCar вернулся(

Ну да мотивы могут быть разные… А можно выяснить какой ключ подбирается в данный момент или нет?? Такую возню трудно скрыть от корпорации,

Да есть конечно меркантильный интерес, но все таки дело не только в нем) Во всяком случае я надеюсь на это)

И какова мощность их сети?

Мое мнение, что объедение в сети подобные сетям майнинга bitcoin для взлома мало вероятна) Все таки у bitcoin есть светлая Идея — независимые деньги. Многие просто не захотят тратить время на деструктивные действия взлома, даже за деньги.

Спасибо за оперативный перевод, оригинал ведь сегодня был опубликован) И действительно в тему, сам столкнулся с проблемой rake-0.9.0)

На самом деле многие покупают виндоус и ставят на них virtualbox, а в них еще винодос! И это очень удобно, когда ты работаешь над проектами которые требуют ставить кучу всяких инструментов, которые не хило нагружают систему, но не нужны тебе постоянно. Или же у тебя 2-а проекта которые требуют совершенно разный набор инструментов и они вместе не живут. У меня так весь отдел работает, и большая часть его (я в том числе) использует Ubuntu как хост систему и не парится.

Познавательно… вот только в чем мораль? Я не понял)

Вот только объяснить своей маме что такое БРАУЗЕР я уже не могу много лет. Она все так же открывает ИНТЕРНЕТ)) И такое окошко у нее вызовет гамму эмоций и не уверен что положительных)

эээ… может я чет не понимаю. А что мешает просто в блог писать скрипт!?

Дело не в том кто виноват, а в том что сервис увеличивает шансы на ввод не той команды, что может привести к чему угодно. И не поймешь даже к чем) Я как обратно с помощью это сервиса проблемно расшифровать команду…

Не поверите… но и даже старика Брукса почитываем) Проблемы в сфере ИТ мало чем изменились с тех пор.

Интересная идея. Было бы круче если бы он целые скрипты поддерживал, а не отдельные команды. А вот полезность сервиса мне кажется сомнительной, все равно проще настроить доступ через shh и работать на прямую, чем что то пользователю объяснять. Да и к презентации подготовится заранее можно, подготовив скрипты.

Полностью согласен с Вами, большая часть людей занимается как правилом не своим делом. Но все же если бы при выборе своей профессии они прислушивались к себе и выбирали бы по душе «Труд» (в терминах автора поста), а не специальность для высокооплачиваемой «Работы», то ситуация была бы лучше. ИМХО

Да и тем у кого уже есть работа, тоже стоит читать. Есть о чем задуматься!

Насчет .NET не понял. Если .NET будет на ReactOS, то все что работает под .NET будет работать и там (в теории конечно).

Против Qt ничего не имею. Вы сказали «лучше уж пишут под Qt» — с этим я поспорил.

Успех проекта зависит от того как много приложений виндос будет на нем стабильно работать. По этому в первую очередь необходимо что бы в ней были реализованы в полном объеме виндовые технологии.

Не надо на Qt. Пусть приложения просто переносимые на винду будут, и пусть пишут под ReactOS люди которые привыкли писать под WIndows.

Надеюсь теперь проект наберет темпы) Сам заядлый линуксойд но проекту сочувствую.

Ну и славно) Не нужно значит было

Похоже офтоп творю) Сорри

Не видел более или менее серьезных применений… не приживаются скриптовые языки на .NET и JVM. Плохо с нативными библиотеками. Хотя вот у jRuby 1.6.0 (по слухам) появилась способность работать с Си расширениями, может у питона под .NET или Java тоже такое есть…

Только зачем это?
Не могу понять эту идею, нужна скорость и типы, пиши расширения на Си или возьми другой язык.
Зачем пытаться одним языком покрывать все парадигмы и технологии!?
Я как понимаю код написанный с этой опции не совместим с традиционным кодом?
И где тогда красота!? В табуляциях что ли(

А что двигало Вами? Т.е. обычно если с первого раза не зацепит больше не возвращаешься к этому, а тут 3 попытки)

Дело вкуса, я так Руби предпочел питону и никогда не жалел)

Хотя я бы хотел какой-то красивый питона со статической типизацией.

трудно представить…