Новые проекты: LoraWan и ScadaAdminWeb

Стартовая страница Форумы Вопросы без категории Новые проекты: LoraWan и ScadaAdminWeb

В этой теме 43 ответа, 6 участников, последнее обновление a80808 a80808 1 неделя, 4 дн. назад.

Просмотр 14 сообщений - с 31 по 44 (из 44 всего)
  • Автор
    Сообщения
  • #12912
    Аватар
    Kazam
    Участник

    Наше вам =)
    Приятно, что не я один ковыряю вегу с точки зрения стороннего софта.

    Прошу простить, что статья про лору еще не вышла. Но есть объективные причины в виде большого количества заказов.

    На данный момент разработка КП для работы с LoraWan остановлена в связи с изменением концепции итогового решения.

    Некоторые вводные: 230 типовых прибором работающих по ModBus.
    Задача: раз в интервал, получать значения регистров с каждого прибора, их интерпретировать и визуализировать. При этом должна быть возможность отправлять запрос на изменения некоторых.
    Первоначально была идея использовать прозрачный канал обмена через приложение LoraToTCP. Но при увеличении количества объектов, время сеанса связи возросло до неприличия, да и отсутствие гарантии что ответ будет получен, тоже не торт.
    А потому стал внимательно смотреть, на то что предоставляет API.

    После переговоров с Вегой Абсолют, была выпущена специальная прошивка под ModBus устройства, которая позволяет вписать регистры прямо в модем и он (модем) будет их спрашивать с modbus, а потом выдавать в эфир в виде Lora кадром специального формата (так же согласованного с производителем).
    Чего я добился: инициатором сеанса связи стал модем. Что значительно сократило время занятия эфира всей сети (ведь раньше БС постоянно отправляла кадры на каждый модем).
    На React JS было написано приложение, позволяющее асинхронно по websocket получать уже обработанные кадры Lora и реализующее логику работы с конечным устройством.

    Выглядит приложение вот так:
    Регуляторы ГВС

    #12913
    Аватар
    Kazam
    Участник

    что-то с картинкой не так. Ссылку даю так : https://ibb.co/nksp8jT

    #12916
    Mikhail
    Mikhail
    Модератор

    На React JS было написано приложение, позволяющее асинхронно по websocket получать уже обработанные кадры Lora

    Красиво выглядит.
    То есть приложение получает данные прямо от сервера Веги в браузер?

    #12920
    Аватар
    Kazam
    Участник

    именно так

    #12936
    Mikhail
    Mikhail
    Модератор

    А какой архив для хранения ретроспективы используется?

    #12984
    a80808
    a80808
    Участник

    Добрый день, коллеги!
    Не настаиваю, но почему бы нет?
    У меня так: — сервер под Виндовс, там же в режиме службы шлюз Lora2Modbus. Там несколько «веселые» принципы по обновлению конфигурации, но тут больше наши внутренние политики безопасности мешают. Все это на разных филиалах.
    На настоящий момент число устройств больше полсотни и число каналов (они же тэги в другой транскрипции) больше тысячи. Привязаны две системы отображения:
    1. RAPID SCADA — вполне приличные отображалки, натренировался на ней. На нашей станции на Урале это сейчас основная система отображения.
    2. PI System (PI AF, PI Vision) — понятно что не SCADA но там очень сильная аналитика да и нам она уже стоила крупных денег — грех не попользоваться.

    Как уже выше написал стык — Modbus TCP. поскольку принципы стыка в RsSCADA и PI — держу два экземпляра шлюзов на сервере (на самом деле больше — например через СИ-13-485 подключено две метеостанции, у которых передача идет в регистрах ModBus (MK26). Пришлось переделывать конфигурационный файл шлюза, а он определяет устройство по имени файла и внутренним ключам — ну никак без еще одного шлюза не обошлось :)). Здесь проблем нет, как то 5 штук было на одном сервере — не мешают друг другу (имена сервисов разумеется разные) и с данными конфликта нет. Поскольку «штатный» шлюз ВЕГА Lora2Modbus не умеет 9пока) передавать данные к устройству пришлось написать на Python програмку — опросник — вот она идет уже на сервер ВЕГА и напрямую ставит пакет в очередь.

    Так что если кому интересно — могу рассказать больше. Один момент — у нас жесткие критери на «служебную информацию» поэтому название компании и кто я и где я — не могу сказать без разрешения определенных служб, а они в Италии 🙂

    #12985
    a80808
    a80808
    Участник

    По тем же причинам картинки могу только в личку как и подробности по реализации и личности 🙂

    #12997
    Mikhail
    Mikhail
    Модератор

    Очень интересная и полезная информация. Думаю, что Lora только набирает обороты.
    Шлюз Lora2Modbus предоставляется Вегой? — да, увидел
    Не рассматривали вариант, чтобы данные для PI System забирались из Rapid SCADA?

    • Ответ изменён 2 мес., 2 нед. назад пользователем Mikhail Mikhail.
    #13007
    a80808
    a80808
    Участник

    А зачем? У PI свой шлюз — ModBusE, единственное что если для RAPID SCADA надо каждому устройству (желательно, чтобы не плодить множество конфигурационных файлов) давать свой TCP порт, то для PI я делаю один порт со смещением регистра. Тут еще накладывает свои «удобства» то, что для меня не очень удобно что то менять в конфигурации PI — каждый раз идти на поклон к админам PI и выслушивать что мне это не надо и вообще…
    В общем работаю на том, что есть :).

    #13034
    Mikhail
    Mikhail
    Модератор

    Оффтоп: Хотелось бы понять, какими данными оперирует PI при построении аналитики? Только измерениями, которые собираются автоматически или что-то, например, ещё вводится оператором дополнительно?

    #13042
    a80808
    a80808
    Участник

    Насколько мне известно любыми. Вообще это система очень сложная. Само собой мы используем далеко не полный функционал. В Инете есть много чего по PI.

    #13794
    Аватар
    talbutdinov
    Участник

    Спустя некоторое время возвращаемся в проект по сбору показаний с приборов учета.

    И еще одно замечание участнику talbutdinov и именно по ВЕГА. Как раз наше решение базируется на оборудовании этого производителя.
    Предлагаемый Вами алгоритм ничем не отличается от прямого доступа к базе сервера ВЕГА (что можно легко реализовать простым написанием View в MySQL — мы это делали на первом этапе) — смысл брать пакет один раз в час, если он пришел почти час назад.

    Хотелось бы отметить, что у каждого свое видение и подход, по этому замечание не принимается! ) Нам достаточно получать данные и лезть для этого в структуры базы данных, которая кстати со временем может измениться, нам не нет необходимости, когда есть описанный API. Да и открывать базу хотя бы на чтение для нас не совсем с точки зрения безопасности, так как сервисы стоят на разных машинах и общаются по интернету. Так что в нашем случае API — это оптимальный вариант.

    А так я тоже рад, что мы не одни «ковыряемся» с LoRaWan и Вегой. С Вегой разговариваем на тему выпуска прошивки для СИ-13-485, чтобы была возможность отправления определенных команд в канал для опроса каких-либо устройств, чтобы не опрашивать их с сервера. По логике устройство отправляет пакет с адресом устройства в канал, устройства получившее его и имеющее этот адрес отправляет ответ обратно и этот пакет записывается на сервере, мы лишь опрашиваем сервер раз в период. Пока как-то так.

    На днях должны доделать обработку событий и карты, постараемся все описать и выложить.

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

    #13798
    Mikhail
    Mikhail
    Модератор

    Пишите по мере появления информации. Это интересно и полезно.

    #13811
    a80808
    a80808
    Участник

    Ну вот как раз я и не приветствую таких подходов, как прямой доступ в базу — с этим я с вами согласен (у нас к сожалению в компании определенный бардак, обусловленный в том числе и национальными особенностями :)). Сам я стараюсь строить из «готовых» кирпичиков. Что то получается, что то не очень.
    Буду стараться побольше писать сюда.

Просмотр 14 сообщений - с 31 по 44 (из 44 всего)

Для ответа в этой теме необходимо авторизоваться.