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

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

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

Просмотр 15 сообщений - с 16 по 30 (из 41 всего)
  • Автор
    Сообщения
  • #12271
    Mikhail
    Mikhail
    Модератор

    Добрый день!
    Присоединяюсь к вопросу.

    В дополнение к API, насколько я знаю, возможен «прозрачный» режим обмена данными с приборами с помощью софта от производителя оборудования LoRa.

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

    Прозрачный режим не всегда к сожалению подходит, особенно при использовании стандартных приложений для обмена данными с устройствами, так как таймаут обычно не настроен на такой длительный период ответа. По этому и интересно направление, когда отправляется запрос и опрос ответа происходит через некоторое время, возможно уже в виде пакета с данными с сервера LoRaWAN. Тем более в ЛоРе есть устройства, которые не опрашиваются, а самостоятельно в определенный период отправляют данные на сервер в виде пакетов, что тоже с одной стороны удобно, остается только брать пакеты с сервера, разбирать их и отображать.

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

    Остальные режимы имеет смысл обсуждать в контексте конкретного оборудования. Поставщик ПО для Лоры предоставляет те или иные API и/или базы данных, с которыми нужно взаимодействовать. При этом может потребоваться разработка драйвера для Rapid SCADA.

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

    Однозначно придется! Очень хочется этим заняться. На сегодняшний день имеется развернутый сервер Веги, который дает возможность получать данные с БД сервера по API посредством JSON. Уже вытаскиваем необходимые нам данные посредством PHP, те логика запросов к серверу и разбора ответов ясна, нужно только это переложить в драйвер. Есть мануал по написанию драйверов?

    #12314
    Аватар
    manjey73
    Участник

    ага, есть, только бедный по комментариям и примерам 🙂

    Разработка драйверов устройств

    Плюс в исходниках примеры OpenKPs

    Вот мои потуги сделать комментарии Смотреть драйвер Пульсар Но как выяснилось есть у меня недоделки

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

    Если ли документация на БД, которую пишет Вега? Или может быть там не такая сложная структура базы.
    Напрямую из базы можно брать данные с помощью драйвера импорта из БД.

    При этом работа с API — это архитектурно верный путь, чем лезть напрямую в базу.

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

    KpHttpNotif работает с веб-запросами. Может быть из него что-то пригодится.

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

    Итак, изучив некоторые материалы, переосмыслив все, возвращаюсь к теме. Я программист со стажем, но в части SCADA систем ранее не работал, и буду иногда писать «глупые» вещи, так что прошу отнестись с пониманием. Для того чтобы начать писать драйвер для устройства, которые мы используем, я для начала хочу описать логику работы всего комплекса, чтобы возможно вы меня поправили.

    За основу взято оборудование производства компании Вега-Абсолют, которая поставляет вместе со своими устройствами и серверную часть. Сначала я посмотрел, что есть драйвер подключения к БД напрямую, но отказался от этого варианта, так как сервер Вега может использовать распределенную систему БД и не будет возможность отправлять команды в устройства.

    Сначала, если я все правильно понял, идет Линия связи, которая создается в режиме TCP-клиент и подключается к серверу. По сути это будет простое подключение к ресурсу, который принимает запрос и отдает ответ в формате JSON, попросту говоря web-страница. На линии оставаться не будем, подключились, получили данные отключились. В параметрах линии прописываем логин и пароль для подключения и получения данных от устройства.

    Дальше за работу берется КП (те само устройство), которое по выбранному каналу связи через выбранный драйвер осуществляет забор информации. Если рассматривать для начала устройство СИ-11, оно имеет 4 входных канала, считает импульсы на этих каналах, а потом с заданным интервалом в виде пакета передает на сервер, пусть будет один час. Так как адрес КП задается только целым числом, а адрес устройства выглядит типа ‘383336385A368B0F’, то прописываем его в позывной. В настройках коммуникатора мы указываем, что период опроса устройства 1 час.

    Далее мы создаем линии из КП, описание количества входных каналов и каналов управления я так понимаю будут описаны в драйвере, разработкой которого планирую заняться. По сути, через драйвер в определенный момент времени я буду через JSON забирать пакет, разбирать его и значения раскидывать по выходным каналам. У СИ-11 их 4 счетчика + он отправляет температуру и состояние заряда батареи, т.е. 6 входных каналов, каналов управления нет.

    По сути все, раз в час он будет подключаться, брать у сервера пакет, разбирать его, отправлять данные в каналы и отключаться. Если что-то не так описал в логике, поправьте пожалуйста. Если верно мыслю, буду начинать разработку драйвера.

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

    Вега хорошо описывает свои устройства, в частности:
    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.pdf

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

    Существующие каналы связи в Коммуникаторе, в том числе TCP, в основном предназначены для отправки и приёма пакетов либо в бинарном, либо в текстовом виде. Если Вы будете работать с JSON, то удобнее не использовать готовые каналы связи, а реализовать подключение самостоятельно. В какой-то мере примером может служить KpHttpNotif.

    Так как адрес КП задается только целым числом, а адрес устройства выглядит типа ‘383336385A368B0F’, то прописываем его в позывной.

    Да.

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

    В методе Session. В контексте драйвера входные каналы правильнее называть тегами КП. Теги привязаны ко входным каналам, но с каналами уже работает Сервер, а не Коммуникатор.

    Было бы замечательно, если Вы выложите данный драйвер на GitHub.

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

    Вопросы по разработке драйвера пишите в этой теме.

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

    Долго держался, но не стерпел 🙂
    Мной начиная с 2018 года в компании развернута сеть LoRaWAN и в настоящий момент практически на всех филиалах компании идет реальная работа с датчиками и модемами. Отображение реализуется внешними системами — Rapid Scada и PI Vision, был проведен удачный тест использования также TraceMode6, основной интерфейс взаимодействия TCP Modbus. Сейчас ведется тестирование протокола MQTT (правда в основном для получения «своего» обмена — без «платных» модулей системы (ниже поясню почему).
    Наша компания — межнациональный производитель электроэнергии, второй в Европе.
    В самом начале мы оценивали производителя оборудования и решения, которое подходило бы именно промышленности, а не ЖКХ, на который нацелены подавляющее количество решений по реализации LoRaWAN.
    Немного о «коммерческих» модулях и нашем «нежелании» их использовать — дело в том, что используемая система «привязки» модулей практически неприменима в корпоративной среде. Я не могу сказать, в какой момент может произойти смена машины с инсталляцией SCADA, тем более при работе в виртуальной среде. Тем более при развертывании машин на производственных филиалах каждый раз менять привязку совершенно неудобно. Прошу не рассматривать разработчиков это как попытку «наезда» — просто нам проще купить один раз например 10 лицензий на определенный модуль и в дальнейшем использовать его по собственному разумению. Существуют же лицензионные соглашения,и мы, как интернациональная компания, обязаны их придерживаться.

    Если интересно, могу поделиться опытом как по реализации так и по проработкам и идеям.

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

    Прошу прощения за «жирный» текст — не на то, похоже, нажал 🙂 Хотел только одно слово выделить 🙂

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

    И еще одно замечание участнику talbutdinov и именно по ВЕГА. Как раз наше решение базируется на оборудовании этого производителя.
    Предлагаемый Вами алгоритм ничем не отличается от прямого доступа к базе сервера ВЕГА (что можно легко реализовать простым написанием View в MySQL — мы это делали на первом этапе) — смысл брать пакет один раз в час, если он пришел почти час назад.
    Большинство устройств ВЕГА кроме простых «регулярных» пакетов могут генерировать и «внеочередные» пакеты по какому то событию (так в указанном Вами счетчике СИ-11 есть возможность входы перевести в состояние «охранный» — при этом пакет с определенным признаком будет генерироваться при наступлении этого события), а уж термодатчики и комплексные могут генерировать разнообразные пакеты по разнообразным событиям, например таким, как выход за пределы уставок, зашитых в самом датчике.
    В этом случае драйвер должен быть подключен к серверу по WebSock постоянно и с учетом аккаунтов и ловить ответы в непрерывно цикле.
    У меня есть похожая реализация для метеостанций МК-26 — там надо отправлять команду опроса через прозрачный модем RS-485. Свое ПО убогое, завели все в rsScada. Ну а опросник написан на Python — раз в минуту дает команду а прием идет через шлюз ModBus с «оригинальным» конфигурационным файлом. Просто на тот момент не было штатного модема ModBus (ВЕГА Modbus-1/2).
    Рад, если оказался полезным

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

    Немного о «коммерческих» модулях и нашем «нежелании» их использовать — дело в том, что используемая система «привязки» модулей практически неприменима в корпоративной среде.

    Для крупных внедрений мы можем рассмотреть индивидуальные подходы к лицензированию, такой опыт есть. Реализовывать и сопровождать собственные модули, которые делают то же самое или почти то же самое, что существующие — экономически неэффективно.
    Наша компания нацелена на участие в корпоративной разработке и тесном сотрудничестве. Будем рады, если Вы нам напишите, и мы обсудим варианты совместной работы.

Просмотр 15 сообщений - с 16 по 30 (из 41 всего)

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