Comments 10
Для подобных задач правильнее было бы использовать OPC сервер для сбора данных и SCADA для GUI.
А то очень странно смотрится идея запуска web сервера на контроллере, да еще и на управляющем: банально, увеличение количества клиентов может отправить контроллер в аут.
OPC для меня звучит как приглашение в мир Windows). Вот как можно кратко описать промышленный компьютер — который у нас является сервером: должен быть небольшим без вентиляторов и при этом не греться естественно. Время старта тоже критично. Жестких дисков нет — флешки памяти впаяны в материнскую плату. Процессор может быть смесью ПЛИС и ARM. Система может быть read-only в целом — что бы флеш память не деградировала. Поэтому либо Linux, либо Qnx работают на этом железе.
Да и не всегда есть возможность и необходимость использования сторонних SCADA систем. Когда была необходимость интеграции с другими SCADA — то использовался другой сервер более высокого уровня, который был классическим сервером в стойке — он работает с описанными серверами и «зеркалирует» их во внешний мир по различным необходимым протоколам.
Число клиентов заранее известно и ограниченно — это ведь в интернет не выходит — поэтому нагрузки нет особой, да и в основном клиенты как правило в режиме монитора работают.
Да и не всегда есть возможность и необходимость использования сторонних SCADA систем. Когда была необходимость интеграции с другими SCADA — то использовался другой сервер более высокого уровня, который был классическим сервером в стойке — он работает с описанными серверами и «зеркалирует» их во внешний мир по различным необходимым протоколам.
Число клиентов заранее известно и ограниченно — это ведь в интернет не выходит — поэтому нагрузки нет особой, да и в основном клиенты как правило в режиме монитора работают.
Не спорю — просто с OPC я работал во времена разработки под Windows. С Linux честно говоря и не пробовал да и идеи не возникало. OPC использовали когда была нужна тесная интеграция с другими системами, да и другие протоколы — Modbus, МЭК 104 можно применять. Мое субъективное мнение что OPC это довольно много всего уневерсального, за что приходится платить.
И допустим внедрили OPC в свое железо — а смотреть все и управлять тогда через стороний продукт SCADA? Это не всегда уместно как мне думается.
И допустим внедрили OPC в свое железо — а смотреть все и управлять тогда через стороний продукт SCADA? Это не всегда уместно как мне думается.
OPC для меня звучит как приглашение в мир Windows).
пользуйте OPC UA… no problems на примере той же openSCADA…
magnum333 вообще ваша идея интересна (сам подумываю про движок сбора данных отдельно, а мордочка HMI на web — ибо браузер уже есть, а web технологии весьма развиты в отличие от проприетарного мира промышленной автоматизации)
вы бы побольше конкретики добавили: что делали, для какой задачи, какие требования, что получилось в результате… фото того, о чем речь…
вы бы побольше конкретики добавили: что делали, для какой задачи, какие требования, что получилось в результате… фото того, о чем речь…
Да если честно, то пока все в разработке и тестировании еще. Фото точно не будет — не моя прихоть. Сначала стали применять сетевой обмен между серверами — wireshark все наглядно показывает что происходит в реальности — поэтому все довольно прозрачно. Потом возникла идея что грубо говоря используя web можно нарисовать что угодно (у меня аналогия QML от QT возникла почему то) — осталось данные ему передать. Есть WebSocket на наше счастье — почему бы и нет?
я так понял вы данные прям c устройства тянете… какой протокол?
вообще из статьи непонятно сколько данных передаете, на каких скоростях…
статья на хабре предполагает, что другие смогут ченить полезное почерпнуть… а пока непонятно, что конкретно можно из статьи применить для своих задач… то что движок можно делать на c++, а морда на web это и так понятно… вопрос в конкретной реализации…
вообще из статьи непонятно сколько данных передаете, на каких скоростях…
статья на хабре предполагает, что другие смогут ченить полезное почерпнуть… а пока непонятно, что конкретно можно из статьи применить для своих задач… то что движок можно делать на c++, а морда на web это и так понятно… вопрос в конкретной реализации…
Измерения берем не по сетевому обмену а со встроенных АЦП грубо говоря. По сети обмен идет между вычислителями и клиентами (браузерами). Весь сетевой обмен посредством Ice на основе tcp. (можно udp). По поводу сколько передавать и на каких скоростях — но это в зависимости от желания и возможностей — ведь так мне кажется.
То что софт на с++ а морда web — да тут ничего нового нет. Но как и что использовать, что бы это было легко реализовано и при необходимости модернизировано при необходимости без особых мучений?
Предлагается использовать инструмент RPC (Ice) — который позволяет разрабатывать клиентов на разных языках (используем с++ и javascript). Удаленное взаимодействие идет через вызов функций — аргументы и возвращаемые значения автоматически сериализуются при передаче — работаем на более высоком уровне, чем socket. И далее предложен набор компонент для построения web — так, что бы воспользоваться элементами интерфейса и учесть особенности отображения различных браузеров и мобильных устройств — вот в этом и хотел показать конкретику.
То что софт на с++ а морда web — да тут ничего нового нет. Но как и что использовать, что бы это было легко реализовано и при необходимости модернизировано при необходимости без особых мучений?
Предлагается использовать инструмент RPC (Ice) — который позволяет разрабатывать клиентов на разных языках (используем с++ и javascript). Удаленное взаимодействие идет через вызов функций — аргументы и возвращаемые значения автоматически сериализуются при передаче — работаем на более высоком уровне, чем socket. И далее предложен набор компонент для построения web — так, что бы воспользоваться элементами интерфейса и учесть особенности отображения различных браузеров и мобильных устройств — вот в этом и хотел показать конкретику.
Sign up to leave a comment.
Web приложение реального времени для простых устройств