Стартовая страница › Форумы › Вопросы без категории › Новые проекты: LoraWan и ScadaAdminWeb
- В этой теме 43 ответа, 6 участников, последнее обновление 4 года, 6 месяцев назад сделано a80808.
-
АвторСообщения
-
23.07.2019 в 10:47 #12912KazamУчастник
Наше вам =)
Приятно, что не я один ковыряю вегу с точки зрения стороннего софта.Прошу простить, что статья про лору еще не вышла. Но есть объективные причины в виде большого количества заказов.
На данный момент разработка КП для работы с LoraWan остановлена в связи с изменением концепции итогового решения.
Некоторые вводные: 230 типовых прибором работающих по ModBus.
Задача: раз в интервал, получать значения регистров с каждого прибора, их интерпретировать и визуализировать. При этом должна быть возможность отправлять запрос на изменения некоторых.
Первоначально была идея использовать прозрачный канал обмена через приложение LoraToTCP. Но при увеличении количества объектов, время сеанса связи возросло до неприличия, да и отсутствие гарантии что ответ будет получен, тоже не торт.
А потому стал внимательно смотреть, на то что предоставляет API.После переговоров с Вегой Абсолют, была выпущена специальная прошивка под ModBus устройства, которая позволяет вписать регистры прямо в модем и он (модем) будет их спрашивать с modbus, а потом выдавать в эфир в виде Lora кадром специального формата (так же согласованного с производителем).
Чего я добился: инициатором сеанса связи стал модем. Что значительно сократило время занятия эфира всей сети (ведь раньше БС постоянно отправляла кадры на каждый модем).
На React JS было написано приложение, позволяющее асинхронно по websocket получать уже обработанные кадры Lora и реализующее логику работы с конечным устройством.Выглядит приложение вот так:
23.07.2019 в 10:48 #12913KazamУчастникчто-то с картинкой не так. Ссылку даю так : https://ibb.co/nksp8jT
23.07.2019 в 17:53 #12916MikhailМодераторНа React JS было написано приложение, позволяющее асинхронно по websocket получать уже обработанные кадры Lora
Красиво выглядит.
То есть приложение получает данные прямо от сервера Веги в браузер?24.07.2019 в 07:30 #12920KazamУчастникименно так
24.07.2019 в 17:31 #12936MikhailМодераторА какой архив для хранения ретроспективы используется?
30.07.2019 в 16:12 #12984a80808УчастникДобрый день, коллеги!
Не настаиваю, но почему бы нет?
У меня так: — сервер под Виндовс, там же в режиме службы шлюз Lora2Modbus. Там несколько «веселые» принципы по обновлению конфигурации, но тут больше наши внутренние политики безопасности мешают. Все это на разных филиалах.
На настоящий момент число устройств больше полсотни и число каналов (они же тэги в другой транскрипции) больше тысячи. Привязаны две системы отображения:
1. RAPID SCADA — вполне приличные отображалки, натренировался на ней. На нашей станции на Урале это сейчас основная система отображения.
2. PI System (PI AF, PI Vision) — понятно что не SCADA но там очень сильная аналитика да и нам она уже стоила крупных денег — грех не попользоваться.Как уже выше написал стык — Modbus TCP. поскольку принципы стыка в RsSCADA и PI — держу два экземпляра шлюзов на сервере (на самом деле больше — например через СИ-13-485 подключено две метеостанции, у которых передача идет в регистрах ModBus (MK26). Пришлось переделывать конфигурационный файл шлюза, а он определяет устройство по имени файла и внутренним ключам — ну никак без еще одного шлюза не обошлось :)). Здесь проблем нет, как то 5 штук было на одном сервере — не мешают друг другу (имена сервисов разумеется разные) и с данными конфликта нет. Поскольку «штатный» шлюз ВЕГА Lora2Modbus не умеет 9пока) передавать данные к устройству пришлось написать на Python програмку — опросник — вот она идет уже на сервер ВЕГА и напрямую ставит пакет в очередь.
Так что если кому интересно — могу рассказать больше. Один момент — у нас жесткие критери на «служебную информацию» поэтому название компании и кто я и где я — не могу сказать без разрешения определенных служб, а они в Италии 🙂
30.07.2019 в 16:13 #12985a80808УчастникПо тем же причинам картинки могу только в личку как и подробности по реализации и личности 🙂
30.07.2019 в 17:35 #12997MikhailМодераторОчень интересная и полезная информация. Думаю, что Lora только набирает обороты.
Шлюз Lora2Modbus предоставляется Вегой?— да, увидел
Не рассматривали вариант, чтобы данные для PI System забирались из Rapid SCADA?- Этот ответ был изменен 4 года, 8 месяцев назад от Mikhail.
31.07.2019 в 08:23 #13007a80808УчастникА зачем? У PI свой шлюз — ModBusE, единственное что если для RAPID SCADA надо каждому устройству (желательно, чтобы не плодить множество конфигурационных файлов) давать свой TCP порт, то для PI я делаю один порт со смещением регистра. Тут еще накладывает свои «удобства» то, что для меня не очень удобно что то менять в конфигурации PI — каждый раз идти на поклон к админам PI и выслушивать что мне это не надо и вообще…
В общем работаю на том, что есть :).31.07.2019 в 14:06 #13034MikhailМодераторОффтоп: Хотелось бы понять, какими данными оперирует PI при построении аналитики? Только измерениями, которые собираются автоматически или что-то, например, ещё вводится оператором дополнительно?
31.07.2019 в 15:31 #13042a80808УчастникНасколько мне известно любыми. Вообще это система очень сложная. Само собой мы используем далеко не полный функционал. В Инете есть много чего по PI.
05.10.2019 в 12:32 #13794talbutdinovУчастникСпустя некоторое время возвращаемся в проект по сбору показаний с приборов учета.
И еще одно замечание участнику talbutdinov и именно по ВЕГА. Как раз наше решение базируется на оборудовании этого производителя.
Предлагаемый Вами алгоритм ничем не отличается от прямого доступа к базе сервера ВЕГА (что можно легко реализовать простым написанием View в MySQL — мы это делали на первом этапе) — смысл брать пакет один раз в час, если он пришел почти час назад.Хотелось бы отметить, что у каждого свое видение и подход, по этому замечание не принимается! ) Нам достаточно получать данные и лезть для этого в структуры базы данных, которая кстати со временем может измениться, нам не нет необходимости, когда есть описанный API. Да и открывать базу хотя бы на чтение для нас не совсем с точки зрения безопасности, так как сервисы стоят на разных машинах и общаются по интернету. Так что в нашем случае API — это оптимальный вариант.
А так я тоже рад, что мы не одни «ковыряемся» с LoRaWan и Вегой. С Вегой разговариваем на тему выпуска прошивки для СИ-13-485, чтобы была возможность отправления определенных команд в канал для опроса каких-либо устройств, чтобы не опрашивать их с сервера. По логике устройство отправляет пакет с адресом устройства в канал, устройства получившее его и имеющее этот адрес отправляет ответ обратно и этот пакет записывается на сервере, мы лишь опрашиваем сервер раз в период. Пока как-то так.
На днях должны доделать обработку событий и карты, постараемся все описать и выложить.
На счет однотипности устройств, у нас пока с этим беда, порядка 10 разных, приходится под каждый прописывать драйвер, а точнее логику чтения пакетов.
06.10.2019 в 14:32 #13798MikhailМодераторПишите по мере появления информации. Это интересно и полезно.
07.10.2019 в 09:22 #13811a80808УчастникНу вот как раз я и не приветствую таких подходов, как прямой доступ в базу — с этим я с вами согласен (у нас к сожалению в компании определенный бардак, обусловленный в том числе и национальными особенностями :)). Сам я стараюсь строить из «готовых» кирпичиков. Что то получается, что то не очень.
Буду стараться побольше писать сюда. -
АвторСообщения
- Вы должны авторизироваться для ответа в этой теме.