- В этой теме 43 ответа, 6 участников, последнее обновление 4 года, 6 месяцев назад сделано
.
-
Сообщения
-
Добрый день, коллеги!
Оцениваю реакцию аудитории, есть два интересных и уже практически выполненных проекта:1. развертывание сети LoraWan и сбор данных посредством RapidScada (160 объектов), modbus. Проблемы «медленного» радиоэфира и адаптация RapidScada для работы с Lora.
2. разработка ScadaAdminWeb (веб приложение, работающее с базой данных Postgres, умеющее передавать конфигурацию в ScadaServer и ScadaComm, без необходимости открытия последних приложений, управление одной кнопкой). Автоматическое построение конфигурационного файла для ScadaComm, формирование *.dat файлов для ScadaServer. Шаблоны устройств, для создания входных каналов и каналов управления.
Среда разработки: asp net core 2.0 mvcВыглядит это примерно так:
Стоит ли, оформлять в виде статей и если да, то с какой начать.
Конечно стоит с пошаговыми инструкциями от начало и до конца
Для медленного радиоэфира мне кажется нужен отдельный модуль, который уже бы отдавал Коммуникатору данные, вот только как скрестить ???
А в чем собственно медленность заключается ? много потерь пакетов ?
Вроде разработчики RapidScada делают тоже самое, может только не на Postgress. В любом случае, я только за.
Благодарю за отклики.
1. по Lora
«медлительность» радиоэфира в первую очередь это сама технология, скорость передачи составляет от нескольких сотен бит в секунду, до нескольких десятков килобит.
Далее, время на открытие приемного\передающего окна (это следствие полудуплексной системы передачи), не нулевое.
В момент передачи кадра, станция не видит ничего. и если произошла коллизия, то пакет будет потерян.
В общем нюансов много, а драйвер modbus — да, переделан чуть менее чем полностью )
Все таки, RapidScada как и любая аналогичная, это реалтайм система управления и мониторинга. А плавающее время ожидания (таймаут) это немного из другой оперы. Плюс не гарантированность передачи (приема) пакета.В моем случае, применительно к конкретным объектам и их физическому размещению:
БС поднята на высоту 42 м (высота 16 этажного дома) + 8 метров радиомачта для антенны в 1 м.
Уверенное покрытие подвалов домов (а именно там и установлены регуляторы которыми я хочу управлять), составляет радиус 1 км вокруг БС.
При этом покрытие выше уровня земли, существенно лучше, на данный момент крайний объект (это счетчик импульсов, с автономным питанием), уверенно передает на станцию с расстояния 7.5 км, установлен в квартире на 5 этаже в санузле.2. по ScadAdminWeb
в своих проектах, использую RS повсеместно, количество инсталляций перевалило за 20 уникальных решений (не считаю аналогичные системы, с одинаковыми задачами). В процессе работы приходиться сталкиваться с необычными задачами (например 200-300 однотипных объектов, с практически одинаковыми входными каналами) и заниматься ручным трудом ой как не хочется.
раньше приходилось писать генераторы каналов в SQL запросы типа Insert, чтобы потом их применить к базе CompactSQL и далее копировать файл SDF, запускать Администратор и передавать конфигурацию в scadaserver. Отдельной проблемой был импорт линий связи в коммуникатор (Михаил, где кнопка импортировать все линии? =))А если в процессе работы системы необходимо сделать изменения? нужно добавить\удалить каналы ? на 5, 10, 30 объектах ? Каждый раз лазить в Администратор надоело. Да и не всегда есть доступ по RDP на сервер.
Принял решение построить следующую схему работы:
1. Был переписан ScadaAdmin на работу с Postgres
2. Написаны сервисы по генерации Линий связи\объектов\каналов путем импорта из
csv файлов
3. Спроектированы ситуационные шаблоны для необходимых КП, примерно в следующем виде:new Incnl { Cnlnum = -1, Active = true, Averaging = false, Cnltypeid = 2, Formatid = 2, Paramid = 0, Signal = 1, Name = "Версия ПО" }, new Incnl { Cnlnum = -1, Active = true, Averaging = false, Cnltypeid = 2, Formatid = 2, Paramid = 100, Signal = 2, Name = "СП ТВ1" },которые в последствии складываются в таблицу incnl.
4. Все таблицы из Postgres импортируются в dat файлы и складываются в соответствующую директорию.
5. Путем использования Settings.CommLine и Settings.KP
формируем перечень линий связи и КП в виде дерева, так как это делает ScadaComm в интерфейсе. Далее дерево сохраняется в ScadaCommSvcConfig
6. Перезапускаем сервисы ScadaCommSvc и ScadaServerSvc с использованием ScadaAgent.Все это позволяет редактировать конфигурацию на «лету» через web интерфейс, и нажатием одной кнопки принять все изменения.
Да идея понятна и в Вашем случае дико востребована :).
Мне в администраторе не хватает фильтров по параметрам и возможности множественного изменения отфильтрованных каналов.
Да и для некоторых библиотек, в частности для opc напрашивается, в свойствах канала не хватает поля «внешний ключ», чтобы теги в коммуникаторе тоже налету формировались.Да и для некоторых библиотек, в частности для opc напрашивается, в свойствах канала не хватает поля «внешний ключ», чтобы теги в коммуникаторе тоже налету формировались.
Так поле сигнал же. Почти то что нужно))
А если серьезно, если для каждого типа КП творить свою историю , то придется делать разные таблицы)
У всех свои особенности ))
А конкретно по opc, если много тегов — проще писать свои инструменты )) на там же питоне или ruby.Михаил, где кнопка импортировать все линии? =))
Так в Коммуникаторе правой кнопкой в дереве давно уже есть импорт всех линий ))
1. развертывание сети LoraWan
Статью по Lora с удовольствием выложим на наш сайт. По 2-му пункту, на мой взгляд, делать статью пока рано, а вот краткий видео обзор был бы востребован.
2. разработка ScadaAdminWeb
Очень интересно. Появление альтернативных инструментов можно только приветствовать. Если ли он на GitHub?
Сейчас идёт полная переработка Администратора. Это будет десктоп приложение, которое объединяет в себе привычный Администратор, а также оболочки Сервера и Коммуникатора. Надеюсь, настройка станет прозрачнее и быстрее. Для проекта выбран формат XML, который затем конвертируется в привычные совместимые настройки приложений Rapid SCADA.
Веб-конфигуратор очень удобен, т.к. полностью кросс платформенный. Но, на мой взгляд, будет иметь ограничения, если нужно взаимодействовать с драйверами. В качестве примера можно привести драйвер OPC, где оболочка драйвера также соединяется с OPC-сервером.
Подход с полноценной БД для конфигурации с одной стороны мощный, но с другой стороны могут быть сложности с установкой системы, а также с переносом конфигураций. Как решаются данные проблемы?Среда разработки: asp net core 2.0 mvc
Есть желание сделать версии всех приложений Rapid SCADA на .NET Core, но работа немаленькая.
Kazam, Вы пробовали приложение Агент? Он для Вас может быть полезен для приёма и передачи конфигурации.
Про правую кнопку и не знал) век живи.
Kazam, Вы пробовали приложение Агент? Он для Вас может быть полезен для приёма и передачи конфигурации.
Его и использую для управления коммуникатором и серверов(перезапуск, остановка, старт).
А вот в части передачи конфигурации не совсем подошёл, но по своим причинам. Дело в том, что к стандартным таблицам, в некоторых проектах у меня есть добавленные колонки, и в scadaadminweb они фильтруются при экспорте в dat .. а переписывать агента не хотелось , приложение и так отличное )))На гитхаб в ближайшее время выложу, как только поправлю несколько неочевидных проблем… Не хочется краснеть за код )))
По статье про Лору: начинаю оформлять )
Скорее всего, Вы можете не убирать дополнительные столбцы. Они не должны влиять на приложения Rapid SCADA. Но надо пробовать, конечно.
Скорее всего, Вы можете не убирать дополнительные столбцы. Они не должны влиять на приложения Rapid SCADA. Но надо пробовать, конечно.
Пробовал. В некоторых случаях работает, а в некоторых нет )) с таблицей входных каналов нет)
Доброго времени суток! Планируется ли размещать статью по поводу связи с устройствами LoRaWAN? Очень интересно посмотреть результат, так как на самом деле технология сбора данных по данному протоколу специфична и имеется ряд ограничений:
1. Некоторые устройства самостоятельно отправляют пакеты на сервер, который занимается опрос устройств по данному протоколу и обратиться к ним напрямую нельзя, можно лишь брать данные в виде передаваемых пакетов из архива сервера по АPI и разбирать их.
2. Очередность опроса устройств тоже вносит свои коррективы, так как нет возможности опрашивать несколько устройств сразу, только если устройства подпадают в радиус действия нескольких базовых станций. Таким образом при запросе данных с устройства (как вариант через функцию прозрачного модема), время ответа будет зависеть не только от время отклика самой сети, но и от очередности выполнения запросов.
3. Некоторые устройства (например вычислители) имеют как показания на текущий момент, так и архивные данные (например часовые), которые тоже необходимо подтягивать для анализа ситуации.
Если что-то получилось, если можно, поделитесь опытом.
- Вы должны авторизироваться для ответа в этой теме.