Table of Contents

3.4.3 Описание модели NetSwitches.xls — настройка диагностики сетевых коммутаторов

3.4.3.1 Назначение модели NetSwitches.xls

Файл NetSwitches.xls является моделью верхнего уровня, по своей концепции аналогичной модели ПЛК, и служит входными данными для встроенного модуля системы AutomiqAutomation — «NetDevices: Генератор диагностики».

Его основное назначение — автоматическая генерация и настройка устройств с полной обвязкой (служебной структурой объектов) в проектах alpha.DevStudio (DS) и HMI.

🔗 Расположение:
JSC\USR\PRJ\Conf\NetSwitches\NetSwitches.xls

3.4.3.2 Назначение встроенного модуля «NetDevices: Генератор диагностики»

Модуль является встроенным компонентом системы AutomiqAutomation и предназначен для автоматизации создания и настройки объектов диагностики в проекте. Он может как создавать новые, так и модифицировать существующие устройства, структуры, настройки и свойства.

Генерируемые объекты:

  • Сетевые коммутаторы (Trei и Stez итд) — с настройкой SNMP-диагностики и созданием привязанной иконки в HMI.
  • Устройства диагностики по PING — с созданием служебной структуры объектов в DevStudio и привязанной иконкой в HMI.

Дополнительные функции:

  • Настройка карты адресов NetDiag.
  • Автоматическое создание доменов и приложений в DevStudio.
  • Привязка сигналов диагностики.

3.4.3.3 Пути к моделям устройств диагностики

Модели типовых объектов для диагностики размещаются в специализированных подкаталогах:

Тип диагностики Путь к моделям
SNMP JSC\Conf\Models\ObjTypes\Diagnostic\Snmp\
PING JSC\Conf\Models\ObjTypes\Diagnostic\Ping\

💡 Примечание: Модель NetDiag2 предназначена для диагностики резервированной сети.

3.4.3.4 Поддерживаемые типы коммутаторов

Модуль поддерживает следующие модели коммутаторов:

Производитель Модель Файл модели
TREI S304 TreiS304
STEZ 3208-12G Stez_3208_12G
STEZ 3208G-12GSFP v2 Stez_3208G_12GSFP_v2
STEZ 3308 Stez3308
STEZ 3216 Stez3216
STEZ 3208 Stez3208
STEZ 3000 Stez3000
STEZ 3108 Stez3108
ELTEX MES3710P Mes3710P
ELTEX MES3300-24F MES3300_24F
ELTEX MES3348 MES3348
ELTEX MES3300-24 MES3300_24

3.4.3.5 Лист Options — настройки для AutomiqAutomation и GAP-функции

Этот лист содержит глобальные параметры, определяющие поведение модуля при обработке модели.

Столбец Описание
SplitRegex Регулярное выражение для разбиения тега на части (например, _+).
ComposeRegex Регулярное выражение для склеивания частей вместе (например, -).

Пример:

d|_+|-|

Использование параметров в GAP-функциях

Параметры SplitRegex и ComposeRegex используются в GAP-функциях (Global Automation Platform) для преобразования тегов при генерации путей и имен объектов в DevStudio. Наиболее часто используется функция GAP.ScadaProjectBase.Tags.GetPrjTag.

Описание функции GetPrjTag:

Функция GetPrjTag преобразует входной тег (например, M0_85_050_JF01_CA1001_SW01) в формат, используемый в проекте DevStudio. Она работает следующим образом:

  1. Проверяет наличие параметров SplitRegex и ComposeRegex в листе Options.
  2. Если параметры заданы, функция разбивает тег с помощью SplitRegex и собирает его обратно с помощью ComposeRegex.
  3. Если параметры не заданы, применяются стандартные правила преобразования:
    • Если второй символ — подчёркивание (_), все подчёркивания заменяются на дефисы (-).
    • Если второй символ — дефис (-), тег остаётся без изменений.
    • В остальных случаях вставляется дефис после второго символа.

Пример результата:

Входной тег:

M0_85_050_JF01_CA1001_SW01

SplitRegex: _+

ComposeRegex: -

Результат:

M0-85-050-JF01-CA1001-SW01

🔗 Применение: Эта функция вызывается в моделях OBJTYPE (например, TreiS304.xls) на листе DevSt.attributes для формирования значения атрибута unit.CommonLib.Attributes.DevParams.SystemTag.

3.4.3.6 Листы OBJ.* — объявление экземпляров объектов

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

Ключевые столбцы:

Столбец Описание
IosServer Подстанция, к которой принадлежит устройство.
Domain Объект (например, шкаф, зона).
TAG Уникальный тег коммутатора (например, SW_01).
PathDevStudio Путь к объекту в DevStudio (например, root.M0_85_050.JF_CA_1001.Network).
HmiTag Имя кадра для HMI (мнемосхемы).
OBJTYPENAME Тип объекта, определяющий метод диагностики:
- NetSwitch_PING — диагностика по ICMP,
- NetSwitch_SNMP — диагностика по SNMP,
- TreiS304 — диагностика коммутатора Trei S304.
parentDescr Наименование коммутатора (например, Коммутатор 1).
EqtDescr Описание оборудования (например, SW_01).
Title Название (для отображения).
SystemPosition Расположение коммутатора (например, шкаф CA-1001).
NetName Имя сети (например, Сеть 1).
iTCPAddr_1, iTCPAddr_2, iTCPAddr_3, iTCPAddr_4 IP-адрес устройства (разделенный по октетам).
NetName2 Имя второй дополнительной сети.
iTCPAddr2_1, iTCPAddr2_2, iTCPAddr2_3, iTCPAddr2_4 IP-адрес резервной.
VS:portsTemplate Путь к шаблону портов (например, %JSC%\USR\PRJ\Conf\NetSwitches\Templates\[SystemPosition]\$S.xls).

Пример:

d|SW_01|root.M0_85_050.JF_CA_1001.Network|M0_85_050|NetSwitch_PING|Коммутатор 1|SW_01|Коммутатор 1|шкаф CA-1001|Сеть 1|192|168|1|10|||192|168|1|11|%JSC%\USR\PRJ\Conf\NetSwitches\Templates\[SystemPosition]\$S.xls|

3.4.3.7 Алгоритм обработки устройств SNMP

Для устройств с OBJTYPENAME, указывающим на диагностику по SNMP (например, TreiS304, Stez_3208_12G), модуль выполняет следующие шаги:

  1. Запуск модуля: Встроенный модуль NetDevices: Генератор диагностики обрабатывает файл NetSwitches.xls.
  2. Обработка модели OBJTYPE: Модуль на основании значения OBJTYPENAME загружает соответствующую модель из каталога JSC\Conf\Models\ObjTypes\. Эта модель содержит описание типового объекта.
  3. Определение типов объектов: На листе NetDiag.opt модели OBJTYPE модуль находит пути к базовым типам:
  • DevStudioAppTypePath — путь к типу приложения (например, unit.CommonLib.Types.Diagnostic.Trei.TREI_S304.S304_APP).
  • DevStudioIOSTypePath — путь к типу представления IOS (например, unit.CommonLib.Types.Diagnostic.Trei.TREI_S304.S304_IOS). Эти типы находятся в библиотечном проекте DevStudio: Libraries\DevStudio\Libs\DsLibraries.solution.

NetDiag.opt лист TreiS304.xls — выделены DevStudioAppTypePath и DevStudioIOSTypePath

Рис. 1. Лист NetDiag.opt из файла TreiS304.xls

  1. Создание объекта SNMP устройства в DevStudio Модуль создает в проекте DevStudio текущего проекта АСУ объект с именем, формируемым по шаблону [Domain].[TAG] (например, P0-72-140.P0-72-140-JF01-CA1001-SW01), используя тип DevStudioAppTypePath как основу.

Настройка сетевых адаптеров

Внутри созданного объекта добавляются адаптеры Ethernet:

  • Ethernet 1
    Создаётся, если заполнены поля NetName, iTCPAddr_1, iTCPAddr_2, iTCPAddr_3, iTCPAddr_4.
    Имя адаптера соответствует значению NetName.

  • Ethernet 2
    Создаётся, если заполнены поля NetName2, iTCPAddr2_1, iTCPAddr2_2, iTCPAddr2_3, iTCPAddr2_4.
    Имя адаптера соответствует значению NetName2.

Применение паролей в настройках SNMP агента

Параметры безопасности SNMP (Community String, User, пароли аутентификации и приватности) берутся из внешнего файла, путь к которому задаётся глобальной переменной [SNMP_KEY_HASH_DS_PATH].
Эта переменная объявляется с помощью утилиты SettingManager.

Пример пути:
JSC\Conf\Models\SnmpKey\AUCS.xls

Описание файла AUCS.xls

Файл AUCS.xls — конфигурационный файл с параметрами аутентификации для SNMP-агентов. Его структура:

  • password: Пароль (открытый текст или хеш)
  • SHA: Хеш SHA
  • MD5: Хеш MD5
  • AES: Хеш AES
  • DES: Хеш DES

Пример строки:

d|Gazauto123|e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855|5f4dcc3b5aa765d61d8327deb882cf99|2a300865462377d55d02308572382379|68a43d6637564d7d991c9e7c74572c43|

⚠️ Предупреждение: Временное решение

Текущий механизм применения паролей через файл, путь к которому задается глобальной переменной [SNMP_KEY_HASH_DS_PATH], является временным и неоптимальным решением. Оно не обеспечивает достаточного уровня безопасности и усложняет управление конфигурацией. В перспективе данный подход должен быть заменен на более защищенную и централизованную систему управления учетными данными, например, интеграцию с системой управления секретами (Secrets Manager) или использование зашифрованных хранилищ конфигурации.

  • Привязка к NetDiag: Если включено (Привязать сигналы NetDiag в карте адресов), добавляются необходимые данные в карту адресов NetDiag. Карта адресов SNMP находится внутри объекта, указанного в DevStudioAppTypePath.

Структура объекта SNMP-устройства с адаптерами Ethernet

Рис. 2. Пример структуры объекта SNMP-устройства с двумя адаптерами Ethernet

  1. Настройка SNMP-агента: Конфигурируется агент SNMP для опроса коммутатора. Используются настройки модуля: Добавить SNMP агент в менеджер и Пересоздавать сервисные SNMP каналы.

Скриншот вкладки 'Коммуникации' в DevStudio с SNMP-менеджером и добавленным устройством

Рис. 3. Вкладка «Коммуникации» в DevStudio: SNMP-менеджер с добавленным устройством

  1. Создание сервисного узла в IOS: После создания устройства SNMP и его добавления в SNMP-менеджер, в приложении IOS_App сервера ввода-вывода автоматически создается сервисный узел по пути Service.Modules.<Имя модуля>.Agents.<Имя агента>.Channels.Channel N.
    • Базовый тип объекта: Последнему узлу (каналу) устанавливается базовый тип из библиотечного проекта DevStudio: unit.CommonLib.Types.Diagnostic.Communication.Snmp.SnmpEqtService.
    • Служебные сигналы: Внутри этого узла создаются служебные сигналы диагностики:
      • Active — признак активности канала.
      • Available — признак доступности канала.
      • IpAddress — IP-адрес канала.
  • Расположение: Сервисный узел создается в приложении IOS_App сервера, имя которого определено в переменной [IosServer].

Дерево IOS в DevStudio с сервисным узлом SnmpEqtService и служебными сигналами

Рис. 4. Пример дерева IOS в DevStudio: сгенерированный сервисный узел с базовым типом SnmpEqtService и служебными сигналами (Active, Available, IpAddress)

  1. Генерация объекта представления: Создается объект представления в приложении сервера. Объект создается по пути, указанному в переменной [PathDevStudio].[TAG], и ему присваивается базовый тип DevStudioIOSTypePath. Помимо создания объекта, инициализируются две ссылки:
    • Ссылка на созданный сервисный узел (для получения данных диагностики).
    • Ссылка на созданное устройство SNMP в приложении PLC_App (для связи с данными опроса).
    • Расположение: Объект представления создается в приложении IOS_App сервера, имя которого определено в переменной [IosServer].
  2. Генерация HMI: Создается иконка в проекте HMI (если включено в настройках).

3.4.3.8 Алгоритм обработки устройств PING

Данный тип диагностики состояния связи применяется для устройств, которые не предоставляют информацию о своем статусе посредством промышленных протоколов (SNMP, Modbus, Unet, OPC итд ). В таком в проекте DevStudio создается модуль NetDiag2, для получения информации об устройстве.

Краткое назначение модуля NetDiag2

Модуль NetDiag2 — это модуль DevStudio, предназначенный для диагностики связи с сетевыми устройствами в сетях TCP/IP путем периодической отправки ICMP-запросов (Ping). Он проверяет доступность устройств и записывает результаты в статические сигналы сервера.

  • NetDiag2 использует статические сигналы, что позволяет гибко настраивать их свойства и расположение в проекте. Модуль NetDiag2 следует использовать, если требуется конфигурировать сигналы: размещать их в разных ветвях дерева сигналов и/или настраивать свойства (архивация, категория и т.д.).

Для устройств с OBJTYPENAME = NetDiag1 или OBJTYPENAME = NetDiag2, модуль выполняет следующие шаги:

  1. Запуск модуля: Встроенный модуль NetDevices: Генератор диагностики обрабатывает файл NetSwitches.xls.

  2. Обработка модели OBJTYPE: Модуль на основании значения OBJTYPENAME загружает соответствующую модель из каталога JSC\Conf\Models\ObjTypes\Diagnostic\Ping\. Эти модели содержат описание типовых объектов для диагностики по PING.

  3. Определение типов объектов: На листе NetDiag.opt модели OBJTYPE модуль находит пути к базовым типам:

    • DevStudioAppTypePath — остается пустым, т.к. модель генератора создает устройство с пустым приложением и сетевыми адаптерами.
    • DevStudioIOSTypePath — путь к типу представления IOS (например, unit.CommonLib.Types.Diagnostic.NetDiag2.NetDiag1 для NetDiag1.xls или unit.CommonLib.Types.Diagnostic.NetDiag2.NetDiag2 для NetDiag2.xls). Эти типы находятся в библиотечном проекте DevStudio: Libraries\DevStudio\Libs\DsLibraries.solution.

    Лист NetDiag.opt из файла NetDiag2.xls с выделенными DevStudioAppTypePath и DevStudioIOSTypePath

    Рис. 1. Лист NetDiag.opt из файла NetDiag2.xls — выделены ячейки DevStudioAppTypePath и DevStudioIOSTypePath

  4. Создание объекта устройства в DevStudio: Модуль создает в проекте DevStudio текущего проекта АСУ объект с именем, формируемым по шаблону [Domain].[TAG] (например, P0-80-030.P0-80-030-JF01-CA1001-PI002). Создается устройство с пустым APP и сетевые адаптеры.

    • Настройка IP-адреса: Внутри созданного объекта создается сетевой интерфейс, которому присваивается IP-адрес, собранный из полей iTCPAddr_1, iTCPAddr_2, iTCPAddr_3, iTCPAddr_4.
      • Привязка к NetDiag: Если включено (Привязать сигналы NetDiag в карте адресов), добавляются необходимые данные в карту адресов NetDiag.

    Структура объекта NetDiag1_APP или NetDiag2_APP с настроенным IP-адресом

    Рис. 2. Пример структуры объекта NetDiag1_APP или NetDiag2_APP с настроенным IP-адресом

  5. Создание модуля NetDiag2 в сервере ввода-вывода: Независимо от того, используется OBJTYPENAME = NetDiag1 или NetDiag2, в приложении IOS_App сервера, имя которого определено в переменной [IosServer], всегда создается или настраивается модуль NetDiag2. Этот модуль отвечает за отправку ICMP-запросов и сбор данных о доступности устройств. Различие между моделями NetDiag1 и NetDiag2 заключается исключительно в ссылке на библиотечный объект для создания представления в IOS сервера (атрибут DevStudioIOSTypePath).

    • Привязка переменных к карте адресов: После создания модуля NetDiag2 и его объекта представления, производится привязка переменных представления к карте адресов. Это позволяет отображать и архивировать данные диагностики (например, статус ONLINE/OFFLINE, время отклика) в соответствии с настройками проекта. Также в настройках модуля NetDiag2 прописывается путь к карте адресов.

⚠️ Предупреждение:

Генератор не создает автоматически карту адресов в приложении IOS_App сервера ввода-вывода.

Обязанности разработчика:

  1. Вручную создать карту адресов в приложении IOS_App сервера, имя которого определено в переменной [IosServer].

После этого генератор автоматически выполнит привязку каналов устройств к сигналам в этой карте.

Модуль NetDiag в сервере проекта DevStudio

Рис. 3. Модуль NetDiag в сервере проекта DevStudio

  1. Генерация объекта представления: Создается объект представления в приложении сервера. Объект создается по пути, указанному в переменной [PathDevStudio].[TAG], и ему присваивается базовый тип DevStudioIOSTypePath. Помимо создания объекта, инициализируется ссылка на созданное устройство PING.

    • Расположение: Объект представления создается в приложении IOS_App сервера, имя которого определено в переменной [IosServer].

  2. Генерация HMI: Создается иконка в проекте HMI (если включено в настройках).

Пример заполненной карты адресов

Ниже приведен пример записи в карте адресов для устройства P0-80-030-JF01-CA1001-PI002 с двумя сетевыми адаптерами (M — основной, R — резервный):

Сигнал Описание Тип Привязка Узел сети Адаптер Тип запроса Функция сигнала Номер
root.P0_80_030.NetDiagnostic.JF01_CA1001.P0-80-030-JF01-CA1001-PI002.M.IPaddress IP адрес сетевого устройства string непосредственно P0-80-030.P0-80-030-JF01-CA1001-PI002 P-AFA-L2-M1 Ping IPaddress
root.P0_80_030.NetDiagnostic.JF01_CA1001.P0-80-030-JF01-CA1001-PI002.M.Status Отфильтрованное состояние статуса запроса bool непосредственно P0-80-030.P0-80-030-JF01-CA1001-PI002 P-AFA-L2-M1 Ping Filtered.Status
root.P0_80_030.NetDiagnostic.JF01_CA1001.P0-80-030-JF01-CA1001-PI002.R.IPaddress IP адрес сетевого устройства string непосредственно P0-80-030.P0-80-030-JF01-CA1001-PI002 P-AFA-L2-R1 Ping IPaddress
root.P0_80_030.NetDiagnostic.JF01_CA1001.P0-80-030-JF01-CA1001-PI002.R.Status Отфильтрованное состояние статуса запроса bool непосредственно P0-80-030.P0-80-030-JF01-CA1001-PI002 P-AFA-L2-R1 Ping Status

💡 Пояснение:

  • M — указывает на основной (Master) адаптер.
  • R — указывает на резервный (Redundant) адаптер.
  • IPaddress — содержит строковое значение IP-адреса целевого устройства.
  • Status — содержит булево значение (True/False), отражающее состояние доступности устройства.
  • Filtered.Status — фильтрованная версия статуса, которая может учитывать задержки или фильтрацию по времени.

3.4.3.9 Преимущества использования

Задача Решение
Контроль сети Автоматический мониторинг доступности всех коммутаторов.
Быстрое реагирование Оперативное обнаружение обрывов связи.
Автоматизация Исключение ручного создания сотен объектов.
Единообразие Все коммутаторы имеют одинаковую структуру диагностики.

3.4.3.10 Вывод

Модель NetSwitches.xls — это ключевой компонент для обеспечения отказоустойчивости системы автоматизации. Она позволяет:

  • Автоматизировать настройку диагностики сети,
  • Обеспечить непрерывный контроль связи,
  • Сократить время настройки и сдачу в эксплуатацию.

Использование этого файла является обязательным этапом при разработке любого проекта АСУ.