Почему возникает потеря потока данных

При классической настройке проекта в Alpha.DevStudio все серверы и ПЛК часто объединяются в одну общую логическую сеть через элемент Сеть Ethernet. Такая схема выглядит простой, но на практике может привести к потере данных на части серверов.

Причина в ограничениях конкретных контроллеров. Аппаратная и программная архитектура некоторых ПЛК устроена так, что по одному физическому коммуникационному порту они способны передавать строго один поток данных одному получателю.

Для решения этой задачи в Альфа платформе предусмотрено несколько архитектурных и программных механизмов. Выбор подхода зависит от возможностей ПЛК, сетевой топологии и того, кто именно должен получать данные: серверы ввода-вывода или клиентские АРМы операторов.

Три способа организации обмена

Способ 1: изоляция сетей и дублирование адаптеров

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

В Alpha.DevStudio логические адаптеры с одинаковым IP-адресом, подключенные к разным сетям, не вызывают конфликтов при компиляции. За счет этого для каждого сервера-получателя создается собственный выделенный логический канал связи до одного и того же физического ПЛК.

Шаг 1. Создание независимых сетей в Alpha.Domain

Вместо единой сети необходимо создать отдельные изолированные маршруты для каждого АРМа.

1. Перейдите в узел проекта Alpha.Domain и добавьте несколько независимых элементов Сеть Ethernet, например Ethernet1 и Ethernet2.
2. В узле первого АРМа, ARM1, настройте сетевой адаптер и подключите его строго к сети Ethernet1.
3. В узле второго АРМа, ARM2, настройте адаптер и подключите его строго к сети Ethernet2.

Шаг 2. Настройка адаптеров на стороне ПЛК

Далее нужно сымитировать наличие нескольких независимых интерфейсов у самого контроллера.

1. Перейдите в конфигурацию узла ПЛК, модуль ЦП, и добавьте несколько элементов Адаптер Ethernet, например Eth1 и Eth2.
2. Подключите адаптер Eth1 к сети Ethernet1, а Eth2 — к Ethernet2.
3. В свойствах всех адаптеров укажите одинаковый IP-адрес физического ПЛК, например 172.16.145.57.

Схема топологии в Alpha.Domain

В проекте контроллер N1 связывается с изолированными сетями Ethernet1 и Ethernet2 через отдельные логические адаптеры.

Шаг 3. Привязка логических станций к адаптерам

1. Перейдите в элемент Приложение внутри контроллера.
2. Добавьте общую Карту адресов Modbus, на которую будут ссылаться станции.
3. Создайте несколько логических станций Станция Modbus TCP, например ModbusTcpSlave_503 и ModbusTcpSlave_504.
4. В свойствах станций укажите единую карту адресов.
5. Привяжите первую станцию к адаптеру Eth1, а вторую станцию — к адаптеру Eth2.

Окно конфигурации модуля ЦП

В конфигурации модуля ЦП станции Modbus графически привязываются к адаптерам Eth1 и Eth2.

Результат настройки

После компиляции проекта в обработчике опроса Опросчик Modbus TCP на ARM1 будет доступна только станция ModbusTcpSlave_503, а на ARM2 — только Modуль ModbusTcpSlave_504.

Каждый Alpha.Server установит собственную независимую сессию с контроллером, что позволяет избежать ситуации, когда один сервер забирает весь поток данных.

Способ 2: использование шлюза данных

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

В этом случае используется паттерн маршрутизации через шлюз. На компьютер, подключенный к сети ПЛК, добавляется Alpha.Server, который выступает в роли шлюза данных, или Proxy.

Для настройки в Alpha.DevStudio серверам-получателям добавляется логический адаптер и ссылка на приложение источника. В качестве шлюза выбирается промежуточный Alpha.Server.

Способ 3: применение Alpha.AccessPoint

Если под несколькими серверами фактически подразумеваются клиентские АРМы операторов, установка полноценного Alpha.Server на каждый АРМ с прямым опросом ПЛК является избыточной и архитектурно неоптимальной.

Для таких задач в Альфа платформе предусмотрен компонент Alpha.AccessPoint. Он выполняет роль сервера приложений и межуровневого транспорта, ограничивая нагрузку от множества клиентов при прямых подключениях к серверам ввода-вывода.

Схема реализации

1. На нижнем уровне устанавливается один Alpha.Server или резервируемая пара Alpha.Server, которые опрашивают ПЛК.
2. На АРМах операторов устанавливаются компоненты Alpha.AccessPoint.
3. Alpha.AccessPoint подключается к Alpha.Server по внутреннему протоколу на базе TCP/IP — Alpha.Link.
4. Компонент объединяет адресное пространство серверов и предоставляет единую точку доступа для клиентских приложений Alpha.HMI и Alpha.Trends.

Категоризация данных и защита ПЛК

Независимо от выбранного способа Alpha.DevStudio предоставляет дополнительные инструменты защиты контроллеров от перегрузок и разделения потоков.

Логическое разделение потоков

Потоки данных можно разделять не только по разным физическим серверам, но и логически внутри одного соединения. Механизм категоризации позволяет распределить параметры одного ПЛК, например «Давление» и «Температура», по разным группам.

Для этого к сигналам добавляется атрибут Категория данных. После этого группы можно направлять через разные логические адаптеры — коммуникационные модули, которые выступают в роли опросчиков или клиентов.

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

Настройка очередей в Modbus TCP Master

При работе с ПЛК важно корректно настроить параметры опросчика Modbus TCP Master на сервере.

Вывод

Передача данных с одного ПЛК на несколько Alpha.Server требует учета ограничений контроллера и правильного выбора архитектуры обмена.

Если ПЛК допускает логическое разделение сессий, можно использовать изоляцию сетей и дублирование адаптеров. Если контроллер слабый или сеть сложная, надежнее применить шлюз данных. Для клиентских АРМов операторов оптимальным решением обычно становится Alpha.AccessPoint.