Стартовая страница › Форумы › Вопросы без категории › Новые проекты: LoraWan и ScadaAdminWeb
- В этой теме 43 ответа, 6 участников, последнее обновление 4 года, 6 месяцев назад сделано a80808.
-
АвторСообщения
-
17.06.2019 в 11:26 #12271MikhailМодератор
Добрый день!
Присоединяюсь к вопросу.В дополнение к API, насколько я знаю, возможен «прозрачный» режим обмена данными с приборами с помощью софта от производителя оборудования LoRa.
17.06.2019 в 19:59 #12282talbutdinovУчастникПрозрачный режим не всегда к сожалению подходит, особенно при использовании стандартных приложений для обмена данными с устройствами, так как таймаут обычно не настроен на такой длительный период ответа. По этому и интересно направление, когда отправляется запрос и опрос ответа происходит через некоторое время, возможно уже в виде пакета с данными с сервера LoRaWAN. Тем более в ЛоРе есть устройства, которые не опрашиваются, а самостоятельно в определенный период отправляют данные на сервер в виде пакетов, что тоже с одной стороны удобно, остается только брать пакеты с сервера, разбирать их и отображать.
18.06.2019 в 12:49 #12296MikhailМодераторОстальные режимы имеет смысл обсуждать в контексте конкретного оборудования. Поставщик ПО для Лоры предоставляет те или иные API и/или базы данных, с которыми нужно взаимодействовать. При этом может потребоваться разработка драйвера для Rapid SCADA.
18.06.2019 в 19:03 #12313talbutdinovУчастникОднозначно придется! Очень хочется этим заняться. На сегодняшний день имеется развернутый сервер Веги, который дает возможность получать данные с БД сервера по API посредством JSON. Уже вытаскиваем необходимые нам данные посредством PHP, те логика запросов к серверу и разбора ответов ясна, нужно только это переложить в драйвер. Есть мануал по написанию драйверов?
18.06.2019 в 20:29 #12314manjey73Участникага, есть, только бедный по комментариям и примерам 🙂
Разработка драйверов устройств
Плюс в исходниках примеры OpenKPs
Вот мои потуги сделать комментарии Смотреть драйвер Пульсар Но как выяснилось есть у меня недоделки
19.06.2019 в 17:12 #12332MikhailМодераторЕсли ли документация на БД, которую пишет Вега? Или может быть там не такая сложная структура базы.
Напрямую из базы можно брать данные с помощью драйвера импорта из БД.При этом работа с API — это архитектурно верный путь, чем лезть напрямую в базу.
19.06.2019 в 17:14 #12333MikhailМодераторKpHttpNotif работает с веб-запросами. Может быть из него что-то пригодится.
21.06.2019 в 16:46 #12356talbutdinovУчастникИтак, изучив некоторые материалы, переосмыслив все, возвращаюсь к теме. Я программист со стажем, но в части SCADA систем ранее не работал, и буду иногда писать «глупые» вещи, так что прошу отнестись с пониманием. Для того чтобы начать писать драйвер для устройства, которые мы используем, я для начала хочу описать логику работы всего комплекса, чтобы возможно вы меня поправили.
За основу взято оборудование производства компании Вега-Абсолют, которая поставляет вместе со своими устройствами и серверную часть. Сначала я посмотрел, что есть драйвер подключения к БД напрямую, но отказался от этого варианта, так как сервер Вега может использовать распределенную систему БД и не будет возможность отправлять команды в устройства.
Сначала, если я все правильно понял, идет Линия связи, которая создается в режиме TCP-клиент и подключается к серверу. По сути это будет простое подключение к ресурсу, который принимает запрос и отдает ответ в формате JSON, попросту говоря web-страница. На линии оставаться не будем, подключились, получили данные отключились. В параметрах линии прописываем логин и пароль для подключения и получения данных от устройства.
Дальше за работу берется КП (те само устройство), которое по выбранному каналу связи через выбранный драйвер осуществляет забор информации. Если рассматривать для начала устройство СИ-11, оно имеет 4 входных канала, считает импульсы на этих каналах, а потом с заданным интервалом в виде пакета передает на сервер, пусть будет один час. Так как адрес КП задается только целым числом, а адрес устройства выглядит типа ‘383336385A368B0F’, то прописываем его в позывной. В настройках коммуникатора мы указываем, что период опроса устройства 1 час.
Далее мы создаем линии из КП, описание количества входных каналов и каналов управления я так понимаю будут описаны в драйвере, разработкой которого планирую заняться. По сути, через драйвер в определенный момент времени я буду через JSON забирать пакет, разбирать его и значения раскидывать по выходным каналам. У СИ-11 их 4 счетчика + он отправляет температуру и состояние заряда батареи, т.е. 6 входных каналов, каналов управления нет.
По сути все, раз в час он будет подключаться, брать у сервера пакет, разбирать его, отправлять данные в каналы и отключаться. Если что-то не так описал в логике, поправьте пожалуйста. Если верно мыслю, буду начинать разработку драйвера.
21.06.2019 в 16:49 #12357talbutdinovУчастникВега хорошо описывает свои устройства, в частности:
API по работе с сервером http://iotvega.com/content/ru/soft/server/API%20VEGA-lora%20rev23.pdf
Описание устройства и его пакетов http://iotvega.com/content/ru/si/si11/01-%D0%92%D0%95%D0%93%D0%90%20%D0%A1%D0%98-11%20%D0%A0%D0%9F_rev%2021.pdf21.06.2019 в 19:01 #12362MikhailМодераторСуществующие каналы связи в Коммуникаторе, в том числе TCP, в основном предназначены для отправки и приёма пакетов либо в бинарном, либо в текстовом виде. Если Вы будете работать с JSON, то удобнее не использовать готовые каналы связи, а реализовать подключение самостоятельно. В какой-то мере примером может служить KpHttpNotif.
Так как адрес КП задается только целым числом, а адрес устройства выглядит типа ‘383336385A368B0F’, то прописываем его в позывной.
Да.
драйвер в определенный момент времени я буду через JSON забирать пакет, разбирать его и значения раскидывать по выходным каналам.
В методе Session. В контексте драйвера входные каналы правильнее называть тегами КП. Теги привязаны ко входным каналам, но с каналами уже работает Сервер, а не Коммуникатор.
Было бы замечательно, если Вы выложите данный драйвер на GitHub.
21.06.2019 в 19:02 #1236319.07.2019 в 11:13 #12862a80808УчастникДолго держался, но не стерпел 🙂
Мной начиная с 2018 года в компании развернута сеть LoRaWAN и в настоящий момент практически на всех филиалах компании идет реальная работа с датчиками и модемами. Отображение реализуется внешними системами — Rapid Scada и PI Vision, был проведен удачный тест использования также TraceMode6, основной интерфейс взаимодействия TCP Modbus. Сейчас ведется тестирование протокола MQTT (правда в основном для получения «своего» обмена — без «платных» модулей системы (ниже поясню почему).
Наша компания — межнациональный производитель электроэнергии, второй в Европе.
В самом начале мы оценивали производителя оборудования и решения, которое подходило бы именно промышленности, а не ЖКХ, на который нацелены подавляющее количество решений по реализации LoRaWAN.
Немного о «коммерческих» модулях и нашем «нежелании» их использовать — дело в том, что используемая система «привязки» модулей практически неприменима в корпоративной среде. Я не могу сказать, в какой момент может произойти смена машины с инсталляцией SCADA, тем более при работе в виртуальной среде. Тем более при развертывании машин на производственных филиалах каждый раз менять привязку совершенно неудобно. Прошу не рассматривать разработчиков это как попытку «наезда» — просто нам проще купить один раз например 10 лицензий на определенный модуль и в дальнейшем использовать его по собственному разумению. Существуют же лицензионные соглашения,и мы, как интернациональная компания, обязаны их придерживаться.Если интересно, могу поделиться опытом как по реализации так и по проработкам и идеям.
19.07.2019 в 11:22 #12863a80808УчастникПрошу прощения за «жирный» текст — не на то, похоже, нажал 🙂 Хотел только одно слово выделить 🙂
19.07.2019 в 11:40 #12865a80808УчастникИ еще одно замечание участнику talbutdinov и именно по ВЕГА. Как раз наше решение базируется на оборудовании этого производителя.
Предлагаемый Вами алгоритм ничем не отличается от прямого доступа к базе сервера ВЕГА (что можно легко реализовать простым написанием View в MySQL — мы это делали на первом этапе) — смысл брать пакет один раз в час, если он пришел почти час назад.
Большинство устройств ВЕГА кроме простых «регулярных» пакетов могут генерировать и «внеочередные» пакеты по какому то событию (так в указанном Вами счетчике СИ-11 есть возможность входы перевести в состояние «охранный» — при этом пакет с определенным признаком будет генерироваться при наступлении этого события), а уж термодатчики и комплексные могут генерировать разнообразные пакеты по разнообразным событиям, например таким, как выход за пределы уставок, зашитых в самом датчике.
В этом случае драйвер должен быть подключен к серверу по WebSock постоянно и с учетом аккаунтов и ловить ответы в непрерывно цикле.
У меня есть похожая реализация для метеостанций МК-26 — там надо отправлять команду опроса через прозрачный модем RS-485. Свое ПО убогое, завели все в rsScada. Ну а опросник написан на Python — раз в минуту дает команду а прием идет через шлюз ModBus с «оригинальным» конфигурационным файлом. Просто на тот момент не было штатного модема ModBus (ВЕГА Modbus-1/2).
Рад, если оказался полезным19.07.2019 в 17:35 #12880MikhailМодераторНемного о «коммерческих» модулях и нашем «нежелании» их использовать — дело в том, что используемая система «привязки» модулей практически неприменима в корпоративной среде.
Для крупных внедрений мы можем рассмотреть индивидуальные подходы к лицензированию, такой опыт есть. Реализовывать и сопровождать собственные модули, которые делают то же самое или почти то же самое, что существующие — экономически неэффективно.
Наша компания нацелена на участие в корпоративной разработке и тесном сотрудничестве. Будем рады, если Вы нам напишите, и мы обсудим варианты совместной работы. -
АвторСообщения
- Вы должны авторизироваться для ответа в этой теме.