книги / Диагностические модели и методы повышения контролепригодности элементов и устройств распределенных информационно-управляющих систем на основе комбинирования логик

ПРИЛОЖЕНИЕ В

Разработанное и внедренное информационное и программное обеспечение аппаратурно-программного преобразователя протоколов системы управления и мониторинга элементов и устройств РИУС

Рассмотрим структуру данных конфигурационной информации блока ТЛС31 в формате XML (рис. В.1).

Рис. В.1. Конфигурационный файл в формате XML

Сетевой элемент моделируется объектом NE, содержащим физическую и логическую структуры блока. Для объекта NE указываются параметры: тип блока, IP- и HDLC-адреса, версия программного обеспечения.

Физическая структура блока состоит из списка плат (объекты CPack). Логическая структура блока описывается в разделе Config и состоит из двух подгрупп: объектов AG (моделируются группы физических портов) и объектов LinkEnd (моделируются мультиплексированные (групповые) потоки). Каждому объекту

141

назначается идентификатор (поле id), с помощью которого реализуются связи между объектами.

Объекты AG – группы физических портов Е1/Е3 (свойства объекта phInterface = electrical/optical).

Физические порты Е1 – объекты TTPSource (входы) и TTPSink (выходы). Двунаправленный порт – объект TTPBid, объединяющий TTPSink и TTPSource.

Физические порты Е3 – объекты TTPSource (входы) и TTPSink (выходы). Двунаправленный порт – объект TTPBid, объединяющий TTPSink и TTPSource.

Объединение КИ в поток Е1 моделируется группированием объектов CTPSink/Source в соответствующие объекты LinkEndSink/Source. Число объектов CTPSink/Source равно числу КИ (для Е3 – 16 КИ Е1).

Объекты LinkEndSink/Source объединяют канальные интервалы (объекты

CTPSink/Source) в групповой поток. Свойства LinkEndSink/Source: ttpId =

идентификатор порта Е3 (объект TTPSink/Source).

Канальный интервал (КИ) группового потока моделируется объектом

CTPSink или CTPSource.

Операция кросс-коннекта моделируется ссылкой между объектами CTPSink и CTPSource. В случае кросс-коннекта между КИ атрибут tpId должен содержать идентификатор объекта CTPSource/Sink (другого КИ, на который выполняется кросс-коннект).

На рис. В.2 показана структура связей между объектами модели в формате XML для терминального мультиплексора Е3, имеющего один физический двунаправленный порт Е3 и три физических порта Е1 (один двунаправленный и два однонаправленных). Между КИ16 и КИ1 выполнен кросс-коннект (реализован разворот информации из входящего канала №16 в исходящий канал № 1).

Рис. В.2. Модель терминального мультиплексора Е3

142

Для данного типа оборудования разработан MIB-файл (рис. В.3):

–переменная versionOfSW с данными о версии программного обеспечения;

–переменная commonState с информацией о текущем состоянии блока;

–таблица platsTable с конфигурационной информацией о платах блока;

–таблицы e1ATable, e1BTable, e3ATable, e3BTable с информацией об авари-

ях в потоках Е1 и Е3 соответствующих направлений передачи (A и B).

Рис. В.3. Структура MIB-файла для блока ТЛС-31

Настройка и работа с менеджером SNMPc требуют выполнения следующих операций:

1.Подключить MIB мультиплексора ТЛС-31 в SNMPc.

2.В менеджере SNMPc создать карту из 4 узлов (рис. В.4), соответствующую схеме сети в лаборатории «Телекоммуникационные сети и интегрированные системы управления». Для каждого узла необходимо указать параметры:

– имя: TLS-[IP-адрес блока] (например, для первого блока ТЛС-31: TLS10.1.1.1);

– адрес: указывается IP-адрес компьютера, на котором запущен шлюз. Поскольку шлюз запущен на том же компьютере, что и сервер SNMPc, то адрес бу-

дет 127.0.0.1;

143

–параметр «Сообщество для чтения (Read Community)» задается в формате [IP-адрес блока].[HDLC-адрес].[тип оборудования (для ТЛС-31 тип равен 128)]. Например, для первого блока ТЛС-31: 10.1.1.1.0.128;

–в качестве переменной статуса (Status Variable) блока ТЛС-31 нужно указать переменную commonState модуля MIB ТЛС-31 (путь по дереву MIB: private/pstu/tls/commonState). Значение статусной переменной (Status Value)

должно быть равно 0 (no_problem). Интервал опроса (Pool Interval) следует задать 5 с.

Рис. В.4. Карта сети

3. Выполнить опрос общей информации для блоков ТЛС-31:

–опрос системных переменных (рис. В.5,а);

–опрос таблицы интерфейсов блока ТЛС-31 (пункт меню Interfaces/Display Entire Table) (рис. В.5,б).

4. Создать пункты меню для опроса таблиц блока ТЛС-31 и выполнить опрос всех таблиц из созданных пунктов меню. Сравните конфигурацию выделения портов для блоков ТЛС-31, полученную через КПО-01, с данными в таблицах плат и портов в SNMPc.

144

а

б

Рис. В.5. Опрос переменных: а – системных; б – интерфейсных

145

5. Выполнить моделирование различных аварийных ситуаций и проконтролировать их индикацию в менеджере SNMPc:

– нет ответа от блока (имитируется выключением блока 3) (рис. В.6);

Рис. В.6. Индикация аварии отсутствия ответа от блока

– авария LOS Е1 (проявляется при выделении порта Е1 № 4 на блоке № 3) (рис. В.7);

Рис. В.7. Индикация аварии отсутствия входного сигнала

146

– индикация аварии AIS (проявляется при выделении порта Е1 № 4 на третьем блоке и установке физического шлейфа по данному порту на блоке 1).

Апробация показала, что результаты мониторинга аварийных ситуаций и их отображение в менеджере SNMP аналогичны «фирменному» программному обеспечению КПО-01. Это означает, что разработанное программное обеспечение может быть использовано как основа для интеграции промышленного оборудования мультивендорной гетерогенной РИУС с «нестандартным» протоколом управления и системы управления и мониторинга верхнего уровня, работающей по стандартизированным протоколам управления [155].

Апробация разработанного программного обеспечения выполнена в рамках лабораторного практикума, построенного на стыке дисциплин, изучающих проектирование, управление и техническую эксплуатацию элементов и устройств подсистемы сбора, передачи и распределения информации РИУС в рамках подготовки бакалавров и магистров по направлениям «Управление в технических системах» и «Инфокоммуникационные технологии и системы связи», а также в программе повышения квалификации специалистов в области проектирования и эксплуатации элементов и устройств систем управления [156].

147

Приложение Г

Практическая реализация рекомендаций по повышению контролепригодности элементов и структур РИУС, построенных на основе промышленного коммуникационного оборудования

1. Контролепригодное проектирование элементов системы управления для включения ее в сеть управления SNMP

Подавляющее большое количество современных систем управления и мониторинга (СУМ) элементов и устройств РИУС реализуют функции транспортной сети на базе стандартных протоколов. Это связано в первую очередь с тем, что СУМ должна обеспечивать взаимодействие с вычислительной техникой и средствами сетей передачи данных (например, такими как компьютеры, коммутаторы, маршрутизаторы и т.д.). Поэтому указанные устройства и компоненты СУМ должны «понимать» друг друга. При этом данные, которыми обмениваются элементы СУМ по своей сети или по сети передачи данных, могут быть представлены в произвольном формате, потому что эта информация обрабатывается и анализируется только ими. Далее рассмотрим особенности построения систем управления и мониторинга элементов мультивендорных РИУС с возможностью применения шлюзов для контролепригодной реконфигурации структуры мультивендорной системы управления [120].

Взаимодействие между различными системами через шлюз представлено на рис. Г.1. В качестве шлюза может выступать либо программный компонент ПО СУМ, либо отдельное приложение, которое связывает между собой ПО СУМ и ЕСУМ [131].

В качестве примера организации ЕСУМ мультивендорной РИУКС можно привести интегрированную систему управления и мониторинга (ИСУМ) промышленной аппаратуры производства ПАО «Морион» (г. Пермь). Выделим несколько основных задач ИСУМ:

–реализация карты сети, на которой показываются физические связи между географическими объектами (узлами), в которых располагаются любой тип оборудования из выпускаемой номенклатуры изделий;

–поддержка единой базы данных оборудования и информационной модели (MIB – Management Information Base), благодаря чему реализована возможность интеграции в систему всех имеющихся в производстве типов аппаратуры, а также потенциальная возможность включать и аппаратуру стороннего производителя;

–ведение различных баз данных, позволяющих проводить политику безопасности при работе с системой, сбор и накопление статистики работы, представление оперативной информации о текущем состоянии сети и т.д.

Как уже рассматривалось в работе [143], можно применять несколько способов организации взаимодействия между системами управления аппаратурой связи

148

сетей производителей (СП). Одним из подходов является использование стека стандартных сетевых протоколов на всех этапах межсетевого взаимодействия. Это означает, что и агентами, и менеджерами систем управления производителей (СУПр), а также менеджером единой системы мониторинга и администрирования (ЕСМА) поддерживается весь стек стандартных сетевых протоколов. Такой подход позволяет значительно упростить проектирование и реализацию системы управления мультивендорной РИУС, а также повысить качественные и количественные характеристики ее обслуживания.

Сеть управления и мониторинга

Рис. Г.1. Взаимодействие в системе управления и мониторинга при помощи шлюзования

Достаточно часто СУПр реализуют собственный стек сетевых протоколов, частично построенный на стандартных (например, для транспортной сети), а частично – на «фирменных» (собственной разработки) протоколах. Как правило, в качестве «фирменного» разрабатывается протокол прикладного уровня модели OSI/ISO, отвечающий за логическое представление аппаратуры и описывающий ее модель для управления и мониторинга. Поэтому при двухуровневой системе сети возникает задача организации взаимодействия между ЕСМА и СУПр (рис. Г.2). Для объединения указанных систем необходимо использовать стандартные сетевые решения, особенно на прикладном уровне модели OSI/ISO.

ЕСМА Стандартный

СУПр1... СУПрi ... СУПрN

«Фирменные»

СПр1 ... СПрi ... СПрN

Рис. Г.2. Двухуровневая схема взаимодействия систем управления

149

Проиллюстрируем предложенный подход на примере системы управления и мониторинга промышленной аппаратуры РИУС производства ПАО «Морион» и ОАО «Такт» (г. Пермь). ПАО «Морион» и ОАО «Такт» производят: оборудование гибкого мультиплексирования, цифровые коммутационные станции, оборудование линейного тракта xDSL, PDH и SDH, аппаратуру вычислительных сетей (маршрутизаторы) и т.п. На указанной аппаратуре можно строить подсистемы сбора, передачи и распределения информации РИУС. Для управления всем многообразием выпускаемого оборудования спроектирована и реализована интегрированная система управления и мониторинга (ИСУМ) [55], включающая в себя информационное, аппаратное и программное обеспечение элементов сети – агентов и менеджеров. Выбраны следующие варианты реализации протоколов сети управления [27] (табл. Г.1).

Примечание:

1.«Уровни» – перечень уровней модели взаимодействия открытых систем (OSI/ISO).

2.F, Qx, Q3 – интерфейсы, описанные рекомендациями ITU-T на проектирование сети управления электросвязью (TMN).

Одним из обязательных атрибутов ЕСМА должен быть стандартный протокол управления, который позволит объединять системы управления производителей в единую сеть. Наиболее часто в качестве такого протокола выбирается Simple Network Management Protocol (SNMP), являющийся де-факто базовой плат-

формой для многих систем управления [170]. Поэтому для включения ИСУМ в ЕСМА, поддерживающую SNMP, возникла необходимость реализации шлюза между ИСУМ и ЕСМА. Указанный шлюз должен поддерживать протоколы SNMP

и«фирменный» протокол управления. Схема включения системы управления сетью аппаратуры ПАО «Морион» и ОАО «Такт» в ЕСМА показана на рис. Г.3.

Рассмотренный подход был использован при включении ИСУМ телекоммуникационной сети, построенной на аппаратуре производства ПАО «Морион»

иОАО «Такт», в ЕСМА ОАО «Российские железные дороги». Организация двухуровневой системы управления и мониторинга, построенная по указанным выше принципам, позволила обеспечить новое качество управления и контроля техни-

150