Ну на выбор:
0. Поставить штатный Pulse и смотреть через него - там свои недостатки и ограничения, но Pulse может понадобиться для настройки датчиков и оповещений (если нет желания лезть в программирование и базу MySQL), да и удобнее через нее без навков;
1. напрямую с сервера через API (есть в описании на портале), требует квалифицированного программирования;
2. Через SQL запросы к базе, например при помощи триггеров или встроенных процедур в MySQL - трудоемко, нагружает сервер, нет реакции на события...но так сделали у нас на филиалах (им виднее) - потому как у них отображалка MES (PI System). не мой путь...
3. (мой путь) Поставить штатный шлюз на сервер (можно не один в зависимости от задач - у меня до 4-х бывает
) Lora2Modbus (на выходе поле холдинг регистров Modbus) а уж к нему цеплять любую SCADA по ModBus TCP (например Rapid SCADA, TraceMode, InTouch Wonderware, PI System и т.п. - хоть все сразу, для чего и могут понадобиться несколько шлюзов). Тут одна проблема - этот шлюз не позволяет управлять устройствами ModBus, т.е. писать в регистры. Преодолимо, см. п.5;
4. То же что и п.3, но через MQTT. Для сервера есть шлюз к транспорту, сейчас много уже отображалок с его поддержкой. Недостаток - поскольку у MQTT нет жесткой структуры данных как у modbus, OPC и т.п. придется как то писать обработчики (у Rapid SCADA например есть модуль, который позволяет подключать обработчики на java script. Ну в общем есть над чем голову поломать...
5. Ну и скажем так "обобщенный" метод - я его и использую - основной поток на чтение на Rapid SCADA идет через Lora2Modbus (traceMode конечно интереснее, но уж очень дорого...) и через второй шлюз к PI System (у них разные структуры данных и разные датчики нужны, так что два люза вполне оправдано). Плюс на сервере еще крутится MQTT Broker Mosquitto, шлюз к VEGA MQTT - через него я управляю датчиками при помощи маленьких программ на Python - напрямую через WebSock и VEGA API. Также через API и модули на Python на одном из филиалов организован опрос двух метеостанций через СИ-13-485 (штатная программа опроса уж больно корявая и требует - если использовать виртуальный СОМ порт для VEGA Lora2TCP - и требует опять же виртуальный СОМ потр...я не смог найти за приемлемое время нормальный эмулятор, поделитесь, если есть у кого...) - т.е. на проге реализована посылка запроса через API и СИ-13 в метеостанцию, а уже обратно возвращается через СИ-13 и отдельный шлюз Lora2Modbus. Отдельный шлюз понадобился потому, что конфигурационный файл шлюза для СИ-13 пришлось переписывать (там в возврате 512 регистров с плавающей точкой...брррр...).
Ну вот как то так. Я давно все хочу здесь описать архитектуру своих решений (которые уже третий год работают на нескольких филиалах компании - крупных электростанциях), останавливает отсутствие времени, лень и несколько вялая активность местного сообщества - не вижу я особого интереса...буду рад, если ошибаюсь.
Если есть вопросы - готов всегда ответить (и задать
), можно и в личную почту.