МКИ: различия между версиями

Материал из EWiki
Перейти к навигации Перейти к поиску
Строка 173: Строка 173:
# Для интерфейса '''enp5s0''' вместо 192.168.2.15/24 следует указать нужный статический адрес сервера, также при необходимости следует указать фактически используемые адреса шлюза и DNS (в '''via''' и '''nameservers''' соответственно).
# Для интерфейса '''enp5s0''' вместо 192.168.2.15/24 следует указать нужный статический адрес сервера, также при необходимости следует указать фактически используемые адреса шлюза и DNS (в '''via''' и '''nameservers''' соответственно).
# В файле конфигурации заранее определяется мост '''docker0''', который будет использоваться Docker'ом после его установки. Таким образом, интерфейсы '''enp6s0/enp7s0/enp8s0''' заранее подключаются к мосту '''docker0''', и, соответственно, в будущем будут доступны из Docker.
# В файле конфигурации заранее определяется мост '''docker0''', который будет использоваться Docker'ом после его установки. Таким образом, интерфейсы '''enp6s0/enp7s0/enp8s0''' заранее подключаются к мосту '''docker0''', и, соответственно, в будущем будут доступны из Docker.
# Для удобства проще скопировать готовый файл '''01-network.yaml''' с компьютера администратора и положить его в '''/etc/netplan''' .
# Для удобства проще скопировать готовый файл '''01-network.yaml''' с компьютера администратора и положить его в '''/etc/netplan.''' Файлу  следует установить права по маске 0100600.
# Как показывает практика, существующий в '''/etc/netplan''' файл конфигурации по умолчанию '''50-cloud-init.yaml''' лучше переименовать во что-то типа '''50-cloud-init.yaml.bak,''' иначе у интерфейса '''enp5s0''' будет образовываться 2 адреса - статический из настроек в '''01-network.yaml''' и динамический, который будет дополнительно прилетать по DHCP и создавать путаницу. Вроде бы, должно лечиться установкой в файле '''50-cloud-init.yaml''' для интерфейса '''enp5s0''' параметра '''dchp4: false''', но по факту не помогает, поэтому лучше от греха подальше во избежание конфликтов держать в '''/etc/netplan'''  только один файл '''01-network.yaml''' с настройками интерфейсов.
# Как показывает практика, существующий в '''/etc/netplan''' файл конфигурации по умолчанию '''50-cloud-init.yaml''' лучше переименовать во что-то типа '''50-cloud-init.yaml.bak,''' иначе у интерфейса '''enp5s0''' будет образовываться 2 адреса - статический из настроек в '''01-network.yaml''' и динамический, который будет дополнительно прилетать по DHCP и создавать путаницу. Вроде бы, должно лечиться установкой в файле '''50-cloud-init.yaml''' для интерфейса '''enp5s0''' параметра '''dchp4: false''', но по факту не помогает, поэтому лучше от греха подальше во избежание конфликтов держать в '''/etc/netplan'''  только один файл '''01-network.yaml''' с настройками интерфейсов.
# Для применения настроек интерфейсов и сохранения настроек после перезагрузки сервера рекомендуется выполнение '''netplan generate''' . Это позволит проверить конфигурацию перед применением и отловить возможные ошибки. Саму конфигурацию лучше применять через '''netplan try --timeout  30''' (или другое не сильно большое количество секунд, чтобы она автоотменилась в случае косяков). Также рекомендуется в обязательном порядке выполнить контрольную перезагрузку сервера, чтобы убедиться, что настройки после нее восстанавливаются правильно.
# Для применения настроек интерфейсов и сохранения настроек после перезагрузки сервера рекомендуется выполнение '''netplan generate''' . Это позволит проверить конфигурацию перед применением и отловить возможные ошибки. Саму конфигурацию лучше применять через '''netplan try --timeout  30''' (или другое не сильно большое количество секунд, чтобы она автоотменилась в случае косяков). Также рекомендуется в обязательном порядке выполнить контрольную перезагрузку сервера, чтобы убедиться, что настройки после нее восстанавливаются правильно.
# Для проверки работоспособности моста '''docker0''' перед настройкой интерфейсов следует запустить постоянный пинг (с параметром '''-t''') с '''MCM-NODE1''' (10.0.0.1) на '''MCM-NODE2''' (10.0.0.2) и наоборот и убедиться в том, что узлы недоступны друг для друга. После настройки конфигурации интерфейсов и выполнения '''netplan try''' следует проверить, что пинг с MCM-NODE1 (10.0.0.1) на MCM-NODE2 (10.0.0.2) в обе стороны проходит успешно, т.е. узлы общаются между собой напрямую через мост '''docker0'''.
# Для проверки работоспособности моста '''docker0''' перед настройкой интерфейсов следует запустить постоянный пинг (с параметром '''-t''') с '''MCM-NODE1''' (10.0.0.1) на '''MCM-NODE2''' (10.0.0.2) и наоборот и убедиться в том, что узлы недоступны друг для друга. После настройки конфигурации интерфейсов и выполнения '''netplan try''' следует проверить, что пинг с MCM-NODE1 (10.0.0.1) на MCM-NODE2 (10.0.0.2) в обе стороны проходит успешно, т.е. узлы общаются между собой напрямую через мост '''docker0'''.
==== Установка сертификата Entcor ====
==== Установка сертификата Entcor ====
С компьютера администратора следует скопировать файл сертификата '''entcor.crt''' на узел '''MCM-SNIFFER''' по следующему пути (необходимо использовать фактический IP-адрес сервера MCM-SNIFFER):<syntaxhighlight lang="sh">
Перед установкой собственно компонентов МКИ с компьютера администратора следует скопировать файл сертификата '''entcor.crt''' и разместить его в каталоге /usr/local/share/ca-certificates (удобнее всего это сделать через Shell-link в панели Midnight Commander). Затем сертификат необходимо обновить, после чего выполнить перезагрузку:<syntaxhighlight lang="sh">
scp entcor.crt entcor@192.168.2.23:/home/entcor
</syntaxhighlight>Затем на компьютере '''MCM-SNIFFER''' следует перенести сертификат в необходимый каталог и выполнить его обновление:<syntaxhighlight lang="sh">
sudo mv entcor.crt /usr/local/share/ca-certificates
sudo update-ca-certificates  
sudo update-ca-certificates  
</syntaxhighlight>'''Примечание:''' после обновления сертификатов необходимо выполнить перезагрузку компьютера '''MCM-SNIFFER'''.
</syntaxhighlight>'''Примечание:''' после обновления сертификатов необходимо выполнить перезагрузку компьютера '''MCM-SNIFFER'''.
Строка 222: Строка 219:
Далее в том же каталоге следует создать/отредактировать файла '''.env''', в котором следует установить следующие параметры:
Далее в том же каталоге следует создать/отредактировать файла '''.env''', в котором следует установить следующие параметры:


* MONITOR_DATA_IF = <имя интерфейса на узле '''MCM-SNIFFER''',  на котором выполняется прослушка, например, enp7s
* MONITOR_DATA_IF = <имя интерфейса на узле '''MCM-SNIFFER''',  на котором выполняется прослушка, например, enp6s
* MODE = enode  
* MODE = enode  



Версия от 11:37, 3 апреля 2025

Система мониторинга качества измерений (МКИ)

Схема тестового стенда

Стенд для МКИ (декабрь 2024)
Стенд для МКИ (декабрь 2024)

Подключение и настойка оборудования

Подключение компонентов стенда производится в соответствии со схемой подключения. При этом для корректного выполнения дальнейших инструкций подключение устройств к физическим портам и сетевые настройки интерфейсов должны быть выполнены согласно табл. 1:

Таблица 1 - Параметры сетевых настроек устройств стенда

Хост Порт Интерфейс IP Подключен к

устройство/порт

Описание
MCM-SNIFFER Eth1 enp5s0 192.168.2.15/24 L2 Switch Интерфейс управления для Sniffer
MCM-SNIFFER Eth2 enp6s0 - MCM-NODE1 / Eth2 Участвует в L2 Bridge
MCM-SNIFFER Eth3 enp7s0 - MCM-NODE2 / Eth2 Участвует в L2 Bridge
MCM-SNIFFER Eth4 enp8s0 - ZLAN / Eth Участвует в L2 Bridge
MCM-NODE1 Eth1 EXTERNAL 192.168.2.156/24 L2 Switch Интерфейс управления для Node1
MCM-NODE1 Eth2 INTERNAL 10.0.0.1/24 MCM-SNIFFER / Eth2 Интерфейс обмена данными для Node1
MCM-NODE2 Eth1 EXTERNAL 192.168.2.195/24 L2 Switch Интерфейс управления для Node2
MCM-NODE2 Eth2 INTERNAL 10.0.0.2/24 MCM-SNIFFER / Eth3 Интерфейс обмена данными для Node2
ZLAN Eth - - MCM-SNIFFER / Eth4 Интерфейс обмена данными для ZLAN
ZLAN RS-485 #1 ZLDEV0001 10.0.0.241/24 Подключение датчика с MODBUS-адресом 5
ZLAN RS-485 #2 ZLDEV0002 10.0.0.242/24 Подключение датчика с MODBUS-адресом 6
ZLAN RS-485 #3 ZLDEV0003 10.0.0.243/24 Подключение датчика с MODBUS-адресом 7

Развертывание системы

Установка базовых систем

Установка ОС Windows на компьютерах MCM-NODE1 и MCM-NODE2 производится обычным образом, при этом соответствующим сетевым интерфейсам должны быть присвоены адреса согласно данным табл. 1, также для совместимости должны быть указаны следующие параметры настройки системы:

Таблица 2 - Параметры настройки узлов MCM-NODE1 и MCM-NODE2
Параметр Значение
Имя компьютера MCM-NODE1/MCM-NODE2
Имя пользователя c правами локального администратора entcor
Пароль 1

Установка базовой системы Ubuntu Server 24.0x на компьютер MCM-SNIFFER производится обычным образом в режиме инсталляции по умолчанию, при этом при выборе параметров установки необходимо включить установку сервера OpenSSH, а также для совместимости следует указать следующие значения прочих параметров:

Таблица 3 - Параметры настройки узла MCM-SNIFFER
Параметр Значение
Имя компьютера MCM-SNIFFER
Имя пользователя c правами root entcor
Пароль ng3-dcc20

После установки системы необходимо установить обновления:

sudo apt full-upgrade

а также проверить доступ к серверу по SSH с компьютера администратора:

ssh entcor@192.168.2.15 (текущий адрес сервера MCM-SNIFFER)

Примечание: для удобства работы с файлами настоятельно рекомендуется также первым делом вкатить Midnight Commander:

sudo apt install mc

Также в дальнейшем целесообразно запускать Midnight Commander через sudo:

sudo mc

Это позволит, во-первых, невозбранно редактировать все необходимые файлы и, во-вторых, при скрытии окон Midnight Commander выполнять из-под него с командной строки команды в режиме root без необходимости париться с sudo для каждой отдельной команды.

Настройка сетевых интерфейсов

Для корректной работы сетевых интерфейсов и сохранения их параметров после перезагрузки сервера необходимо в каталоге /etc/netplan создать файл с расширением .yaml (например, 01-network.yaml) со следующим содержимым:

network:
    version: 2
    ethernets:
        enp5s0:
            dhcp4: false
            addresses: 
                - 192.168.2.15/24
            routes:
              - to: default
                via: 192.168.2.254
            nameservers: 
                addresses: [192.168.2.60, 176.114.16.33]
        enp6s0:
            dhcp4: false
        enp7s0:
            dhcp4: false
        enp8s0:
            dhcp4: false
    bridges:
        docker0:
            interfaces: [enp6s0, enp7s0, enp8s0]

Примечания:

  1. Для интерфейса enp5s0 вместо 192.168.2.15/24 следует указать нужный статический адрес сервера, также при необходимости следует указать фактически используемые адреса шлюза и DNS (в via и nameservers соответственно).
  2. В файле конфигурации заранее определяется мост docker0, который будет использоваться Docker'ом после его установки. Таким образом, интерфейсы enp6s0/enp7s0/enp8s0 заранее подключаются к мосту docker0, и, соответственно, в будущем будут доступны из Docker.
  3. Для удобства проще скопировать готовый файл 01-network.yaml с компьютера администратора и положить его в /etc/netplan. Файлу следует установить права по маске 0100600.
  4. Как показывает практика, существующий в /etc/netplan файл конфигурации по умолчанию 50-cloud-init.yaml лучше переименовать во что-то типа 50-cloud-init.yaml.bak, иначе у интерфейса enp5s0 будет образовываться 2 адреса - статический из настроек в 01-network.yaml и динамический, который будет дополнительно прилетать по DHCP и создавать путаницу. Вроде бы, должно лечиться установкой в файле 50-cloud-init.yaml для интерфейса enp5s0 параметра dchp4: false, но по факту не помогает, поэтому лучше от греха подальше во избежание конфликтов держать в /etc/netplan только один файл 01-network.yaml с настройками интерфейсов.
  5. Для применения настроек интерфейсов и сохранения настроек после перезагрузки сервера рекомендуется выполнение netplan generate . Это позволит проверить конфигурацию перед применением и отловить возможные ошибки. Саму конфигурацию лучше применять через netplan try --timeout 30 (или другое не сильно большое количество секунд, чтобы она автоотменилась в случае косяков). Также рекомендуется в обязательном порядке выполнить контрольную перезагрузку сервера, чтобы убедиться, что настройки после нее восстанавливаются правильно.
  6. Для проверки работоспособности моста docker0 перед настройкой интерфейсов следует запустить постоянный пинг (с параметром -t) с MCM-NODE1 (10.0.0.1) на MCM-NODE2 (10.0.0.2) и наоборот и убедиться в том, что узлы недоступны друг для друга. После настройки конфигурации интерфейсов и выполнения netplan try следует проверить, что пинг с MCM-NODE1 (10.0.0.1) на MCM-NODE2 (10.0.0.2) в обе стороны проходит успешно, т.е. узлы общаются между собой напрямую через мост docker0.

Установка сертификата Entcor

Перед установкой собственно компонентов МКИ с компьютера администратора следует скопировать файл сертификата entcor.crt и разместить его в каталоге /usr/local/share/ca-certificates (удобнее всего это сделать через Shell-link в панели Midnight Commander). Затем сертификат необходимо обновить, после чего выполнить перезагрузку:

sudo update-ca-certificates

Примечание: после обновления сертификатов необходимо выполнить перезагрузку компьютера MCM-SNIFFER.

Установка Docker

# Add Docker's official GPG key:

sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Ссылка на руководство: https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

Установка компонентов системы МКИ

Установка компонентов системы МКИ может осуществляться посредством получения последней версии инсталляционного пакета (предпочтительно), либо из репозитория Git (может применяться для целей отладки или быстрого накатывания патчей/фикса ошибок).

Вариант 1: Установка с помощью инсталляционного пакета

Получение последней версии инсталляционного пакета производится с FTP-сервера Jenkins. Для этого необходимо подключиться к нему с устройства МКИ по протоколу FTP, используя соответствующую пару логин-пароль, и выкачать оттуда файлы install.sh и latest.tar.gz.

Перед запуском инсталляционного скрипта install.sh необходимо установить для него права на выполнение посредством команды chmod:

chmod +x install.sh

Также для корректной работы стека common необходимо предварительно авторизоваться под нужной учетной записью в docker-репозитории Harbor:

docker login registry.entcor

Далее непосредственное развертывание контейнеров производится запуском на выполнение скрипта install.sh.

После завершения установки компонентов ПАК «еNODE.МКИ» следует выполнить переход в каталог /opt/e-node/deploy, куда выполнялось развертывание компонентов системы инсталляционным скриптом install.sh.

Далее в том же каталоге следует создать/отредактировать файла .env, в котором следует установить следующие параметры:

  • MONITOR_DATA_IF = <имя интерфейса на узле MCM-SNIFFER, на котором выполняется прослушка, например, enp6s
  • MODE = enode

Примечание: вообще-то для работы МКИ параметр MODE должен иметь значение asutp, но работает пока только вот так.

Вариант 2: Установка непосредственно из репозитория Git

Получение последней версии инсталляционного пакета производится из Git-репозитория e-deploy, находящегося по адресу http://192.168.2.61, (нужно будет ввести соответствующие логин-пароль для доступа к репозиторию, а также выполнить переключение на ветку develop):

git clone http://192.168.2.61/e-node/e-deploy.git
git switch develop

Далее следует авторизоваться под нужной учетной записью в Docker-репозитории Harbor:

docker login registry.entcor

после чего нужно перейти в каталог e-deploy (в том каталоге, где выполнялся git clone) и выполнить следующую команду:

./enode.sh init

Далее в том же каталоге следует создать/отредактировать файла .env, в котором следует установить следующие параметры:

MONITOR_DATA_IF = <имя интерфейса на узле MCM-SNIFFER, на котором выполняется прослушка, например, enp7s0>

MODE = enode

Примечание: вообще-то для работы МКИ параметр MODE должен иметь значение asutp, но работает пока только вот так.

Запуск компонентов системы МКИ

После установки компонентов МКИ можно выполнить их запуск следующей командой:

enode <имя стека> start

Примечание: названия нужных стеков можно посмотреть в каталоге stacks в e-deploy (имена стеков соответствуют именам подкаталогов). Как минимум должны быть запущены следующие стеки:

enode analytic start
enode common start
enode asutp start

Примечание: стек analytic рекомендуется запускать перед стеком common из-за каких-то особенностей функционирования: Проверка запуска сервисов производится обычным образом с помощью команды:

docker ps

Проверка информационного обмена по протоколу МЭК-60870-5-104

Проверка информационного обмена по протоколу МЭК-60870-5-104 производится между узлами стенда MCM-NODE1 и MCM-NODE2 посредством программного обеспечения IEC Test, которое эмулирует передачу пакетов протокола МЭК-60870-5-104 поверх соединения Ethernet.

Для проверки работы протокола МЭК-60870-5-104 во внутренней сети обмена на одном из узлов ПО IEC Test запускается в режиме сервера с показанными ниже настройками:

TCP/IP Link Role - Server

IP Address - адрес внутреннего интерфейса для информационного обмена (в данном примере - 10.0.0.2)

Далее устанавливается канал обмена последовательным нажатием кнопок "Build String" и "Open Channel" (индикатор "1 channel" должен стать темно-зеленым).

Рис. 1 - Настройки программы IEC Test для организации обмена между узлами стенда MCM-NODE1 и MCM-NODE2 по протоколу МЭК-60870-5-104 (серверная часть)

Соответственно, на другом узле ПО IEC Test запускается в режиме клиента с показанными ниже настройками:

TCP/IP Link Role - Client

IP Address - адрес сервера, находящегося во внутренней сети для информационного обмена (в данном примере - 10.0.0.2).

Далее устанавливается канал обмена последовательным нажатием кнопок "Build String" и "Open Channel" (индикатор "1 channel" должен стать темно-зеленым).

Для начала непосредственно информационного взаимодействия следует послать с клиента на сервер специальную команду посредством нажатия кнопки "Start DT" (индикатор "1 channel" должен стать светло-зеленым как показано на рисунке ниже). С этого момента канал обмена установлен и активирован, а между экземплярами ПО IEC Test могут передаваться пакеты протокола МЭК-60870-5-104.

Рис. 2 - Настройки программы IEC Test для организации обмена между узлами стенда MCM-NODE1 и MCM-NODE2 по протоколу МЭК-60870-5-104 (клиентская часть)

Для создания трафика по протоколу МЭК-60870-5-104 между узлами MCM-NODE1 и MCM-NODE2 следует использовать специальный макрос, имитирующий последовательную передачу данных протокола МЭК-60870-5-104 между узлами. Для этого необходимо на любом из узлов в ПО IEC Test перейти во вкладку "870 Commander", нажатием кнопки "Загрузить" загрузить макрос "ДУ по циклу 5 сек.rtm" и выполнить его нажатием кнопки "Выполнить":

Выполнение макроса в ПО IEC Test для создания трафика по протоколу МЭК-60870-5-104
Рис. 3 - Выполнение макроса в ПО IEC Test для создания трафика по протоколу МЭК-60870-5-104

В случае правильно настроенных узлов стенда и экземпляров ПО IEC Test на принимающем узле во вкладке "870 Commander" в соответствующем окне можно будет увидеть информацию о принятых сообщениях, отправленных макросом с передающего узла, что свидетельствует о состоявшемся информационном обмене по протоколу МЭК-60870-5-104 между узлами.

Примечание: в случае, если система МКИ выполняет прослушивание на одном из интерфейсов, входящих во внутреннюю сеть информационного обмена, а также при правильном конфигурировании компонента Grafana, при подключении браузером по адресу сервера MCM-SNIFFER в соответствующих дашбордах должна появиться информация о перехваченных пакетах протокола МЭК-60870-5-104, создающих описанный выше трафик.

Проверка информационного обмена по протоколу MODBUS

Работа стенда по протоколу MODBUS осуществляется посредством ПО Modbus Poll, запущенного на узле MDM-NODE2 (см. схему). Modbus Poll подключается по протоколу MODBUS-TCP к железке-конвертору ZLAN (см. схему) и через него опрашивает устройства (температурные датчики), подключенные к RS-485-портам №1, №2 и №3 конвертора ZLAN. Также на датчиках изменены их базовые адреса следующим образом: ID = 5 – на 1 порту RS-485, ID = 6 – на 2 порту RS-485, ID = 7 – на 3 порту RS-485.

Для доступа к датчикам на конверторе ZLAN установлены адреса IP-портов с помощью прилагающейся к нему софтины ZLVirCom, которую можно запустить с рабочего стола на узле MCM-NODE2 (Примечание: в текущей конфигурации стенда вся работа с MODBUS производится с этого узла). ZLVirCom сам опрашивает локальную сеть и находит там конвертор, после чего подключается к нему, и его можно конфигурировать:

Рис. 4 - Главное окно ZLVirCom

При нажатии на кнопку Device в верхнем меню открывается список портов, в котором можно провалиться в конкретный порт и выполнить его настройки:

Рис. 5 - Окно со списком портов RS-485 на устройстве ZLAN5843

Настройки портов, к которым подключены датчики, должны выглядеть следующим образом:

Рис. 6 - Окно настройки параметров выбранного порта RS-485 на устройстве ZLAN

Если все настроено корректно, то Modbus Poll сможет подключится к соответствующим RS-485-портам конвертора по указанному для них IP Address и Port (см. рис. 6).

Непосредственно для выполнения опроса датчиков нужно запустить Modbus Poll с рабочего стола на узле MCM-NODE2:

Рис. 7 - Главное окно Modbus Poll


Далее в меню Connection следует выбрать Connect (или нажать F3), откроется окно настроек подключения, где нужно указать следующие параметры:

Рис. 8 - Параметры подключения к порту RS-485 на устройстве ZLAN


В поле IP Address or Node Name нужно указать адрес порта, который будем опрашивать (соответственно, 10.0.0.241, .242, .243 для портов 1, 2, 3 конвертора).

Далее будет выполнено подключение к железке ZLAN и при попытке опроса вылезет ошибка “Timeout error”, так как не сконфигурированы параметры опроса.

Рис. 9 - Окно программы Modbus Poll при несконфигурированных параметрах опроса


Для их настройки следует зайти в меню Setup -> Read/Write Definition (или нажать F8) и указать следующие параметры:

Рис. 10 - Настройка параметров опроса порта

В поле Slave ID нужно указать адрес датчика (5, 6 или 7), в поле Function выбрать «04 Read Input Registers (3х)», в полях Address и Quantity указать значение 1. Если номер датчика соответствует выбранному при подключении порту, то опрос пойдет корректно (Tx увеличивается, Err = 0):

Рис. 11 - Выполнение опроса порта в установленном режиме

Результат опроса можно увидеть, нажав кнопку Display communication traffic в панели инструментов (Tx – байты с запросом, Rx – байты ответа от датчика). В случае ошибки опроса или недоступности устройства Rx в трафике не будет, а будут только строки с отправкой (Tx).

Рис. 12 - Просмотр трафика при опросе порта


Примечание: Весь трафик между Modbus Poll на узле MCM-NODE2 и каким-либо из датчиков пролетает через сервер MCM-SNIFFER (см. схему). Соответственно, если в настройках перехвата указать порт на сервере MCM-SNIFFER,  к которому подключен MCM-NODE2 (например, enp7s0), то МКИ на сервере MCM-SNIFFER сможет перехватывать трафик MODBUS и, соответственно, его анализировать.