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

обработки и анализа {S}. Далее в цикле i по элементарным сообщениям (в соответствии с принятой диагностической моделью – данные о статусе модуля на конкретной плате или по плате в целом) проверяется, имеется ли в базе данных БД (в терминологии систем управления – оперативном отчете тревог) запись об этом сообщении. Если такой записи нет (новое сообщение), то она добавляется в БД и по межпрограммному интерфейсу передается для добавления в БД внешнего менеджера системы управления. Затем в цикле j по выборке БД {R}, соответствующей данному блоку, определяется, есть ли устраненные сообщения (в выборке {R} есть, а в сообщении {S} нет). Если таковые находятся, то записи удаляются из БД оперативного отчета тревог, а также уходит команда об их удалении из БД внешнего менеджера системы управления по межпрограммному интерфейсу.

Рассмотрим пример использования предложенного алгоритма (см. рис. 3.5) в рамках иллюстрации п. 1 и 2 рекомендации по повышению контролепригодности управляющих элементов РИУС (параграф 3.1). Он основан на организации взаимодействия программного обеспечения СУМ (КПО-01) с сервером базы данных (КПО-10) через внешний программный модуль в виде динамически загружаемой библиотеки (DLL – EvLogClient.dll). В данном варианте применяется принцип

распределенного управления и мониторинга, при котором все задачи СУМ разби-

ваются на уровни, ответственные за их выполнение. Для этого должны быть организованы технические центры, в которых сконцентрированы информационные и аппаратно-программные средства СУМ. На основании результатов проведенного анализа требований к центрам управления по данным отечественных и зарубежных публикаций и нормативной документации предлагается выделить два типа таких центров:

Центр технического управления (ЦТУ), выполняющий следующие функции:

 распределение и контроль использования ресурсов сети связи,  формирование конфигурационных файлов для загрузки в модули обору-

дования,  получение агрегированной информации о техническом состоянии интере-

сующего оборудования, группы (подсети) оборудования или всей сети в целом,  накопление и обработка статистики работы сети,  взаимодействие с ЦТО.

Центр технического обслуживания (ЦТО), выполняющий следующие функции:

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

 загрузка конфигурационных файлов, полученных от ЦТУ,  взаимодействие с ЦТУ.

Указанная двухуровневая модель согласуется с моделью управления сетью электросвязи, рекомендуемой Международным союзом электросвязи (МСЭ)

92

в рамках концепции TMN (Telecommunication Management Network) [199]. При этом ЦТО выполняет функции управления сетевыми элементами, а ЦТУ – функ-

ции управления сетью.

В случае организации распределенного управления и мониторинга схема взаимодействия строится по иерархическому принципу [130] (рис. 3.6).

ЦТУ

Рис. 3.6. Организация двухуровневого распределенного управления и мониторинга распределенных объектов

Остановимся на интерфейсах, присутствующих в рассматриваемой схеме. Интерфейс между ЦТО и подсетью аппаратуры связи реализуется как стек протоколов СУМ. Указанные протоколы могут придерживаться рекомендаций международных организация по стандартизации (ITU-T, ISO и т.д.), а могут быть разработаны производителем аппаратуры, входящей в подсеть [20]. Интерфейс между ЦТО и ЦТУ должен передавать информацию СУМ с одного уровня на другой. Можно выделить общие требования к указанному интерфейсу:

высокое быстродействие и скорость обработки данных,

обеспечение возможности многопользовательского режима доступа к ресурсам системы как со стороны ЦТУ, так и со стороны ЦТО,

высокая надежность и отказоустойчивость,

возможность резервирования,

средства резервного копирования данных и восстановления информации. Указанным требования в полной мере удовлетворяет информационная сис-

тема, построенная на базе современных систем управления базами данных (СУБД). При этом средства реализации интерфейсов выбранного типа СУБД интегрируются в информационно-программные средства на уровнях ЦТУ и ЦТО.

Для того чтобы отличать аппаратно-программные средства СУМ уровня ЦТУ и ЦТО, введем понятие «рабочее место управляющего персонала» (РМУП) и «рабочее место обслуживающего персонала» (РМОП).

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

93

Рис. 3.7. Взаимодействие РМУП и РМОП через сервер БД

Примечание. 1. Количество контролируемых подсетей на уровне ЦТО равно N и совпадает с количеством РМОП. Количество РМУП M может не совпадать с N, поскольку оборудование на уровне ЦТУ может быть произвольным образом перегруппировано.

2. На уровне ЦТУ (в одном из РМУП) может выполняться и функция управления сервером базы данных (БД) при помощи специализированного программного обеспечения.

Далее рассмотрим, как предложенная методика контролепригодного проектирования управляющих элементов РИУС нашла отражение в реализации схем диагностирования и управления в процедурах взаимодействия между РМУПi и РМОПj через сервер БД в разных режимах (выбранной группы оборудования).

Режим управления. При помощи специализированного программного обеспечения, выполняющего функции управления и контроля использования ресурсов (цифровых и аналоговых окончаний, компонентных потоков Е1, Е2 и т.д.), создаются конфигурационные файлы. Они предназначены для загрузки в модули управления контролируемой аппаратуры. Далее РМУП формирует команду для РМОП, в ведении которого содержится конфигурируемое оборудование. Команда представляет собой текст и прикрепленные конфигурационные файлы. Оператор РМОП, получив команду, квитирует ее и приступает к выполнению, в частности, к загрузке. После окончания работы оператор РМОП высылает квитанцию о выполнении команды. Администратор на РМУП получает ее и считает процесс взаимодействия оконченным. В указанном процессе возможен обмен дополнительной информацией в диалоговом режиме для уточнения действий оператора. Вся статистика обмена сохраняется на сервере БД для фильтрации и печати.

Режим мониторинга. РМОП собирает информацию о техническом состоянии оборудования контролируемой подсети и заносит ее на сервер БД. Администратор РМУП получает информацию об интересующем оборудовании через сервер БД, формируя соответствующий запрос либо автоматически при появлении новых

94

сообщений. Таким образом, поддерживается идентичность информации о техническом состоянии контролируемого оборудования на уровнях ЦТО и ЦТУ.

Сервер базы данных представляет собой компьютер, на котором установлено программное обеспечение БД, включая непосредственно файлы данных и приложение СУБД, выполняющее следующие функции:

настройка параметров сервера БД,

регистрация пользователей и разграничение доступа к ресурсам системы,

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

регистрация действий подключенных (активных) пользователей. Предложенный вариант повышения контролепригодности в формате двух-

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

Рис. 3.8. Распределенная система управления и мониторинга

95

КПО-01 [55] – программный продукт, выполняющий функции и РМОП,

иРМУП в зависимости от настройки режима работы и имеющий интерфейс взаимодействия с СУБД.

КПО-10 [56] – программный продукт, реализующий функции организации и управления сервером базы данных, а также интерфейс с КПО-01.

Между КПО-01 и КПО-10 поддерживается единая база регистрации пользователей, в которой каждому присваиваются определенные полномочия по обслуживанию ИСУМ. Построенная на базе КПО-01 и КПО-10 двухуровневая система управления и мониторинга технического состояния аппаратуры позволяет выполнить следующие функции:

разграничение полномочий по управлению ресурсами сети между РМУП

иРМОП;

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

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

За сбор и занесение информации о состоянии элементов системы управления в базу данных КПО-10 отвечают менеджеры КПО-01, которые непосредственно взаимодействуют с оборудованием и работают в режиме «записи в БД» (алгоритм приведен выше). Удаленные клиенты, работающие в режиме «чтения из БД», используют то же самое программное обеспечение КПО-01, в котором ведутся карта сети, база данных оборудования, оперативные отчеты тревог и статистика. Количество «пишущих клиентов», как правило, в несколько раз меньше, чем «читаю-

щих клиентов», что позволяет не увеличивать загрузку каналов управления, а оперативно получать информацию через высокоскоростную локальную сеть. Внедрение указанной системы выполнено в рамках Октябрьской железной дороги (г. Санкт-Петербург) ОАО «РЖД»:

–общее количество сетевых элементов: более 2 тысяч;

–количество «пишущих клиентов»: 8 (по количеству направлений Октябрьской ж/д);

–количество «читающих клиентов» (удаленных пользователей): 40-60.

По основным показателям контролепригодности отметим, что средняя трудоемкость диагностирования (время обновления информации по элементу в КПО-01 администратора) составляет в среднем 2-3 с после занесения в БД. Аналогичный показатель до внедрения системы измерялся в часах, поскольку информация передавалась в виде отчетов с необходимостью обработки и фильтрации. В данном случае карта сети для администратора верхнего уровня полностью совпадает с реальной, что позволяет отображать информацию в удобном для пользователя виде (графическом, текстовом и т.д.). Коэффициент безразборного тести-

96

рования (в формате соответствия представляемой на верхний уровень информации данным уровня взаимодействия с сетевыми элементами) оценивается равным 1, поскольку операторы и администраторы работают с одинаковыми базами MIB, и представляемая им информация абсолютно идентична. До внедрения системы данный параметр был существенно меньше, поскольку из отчетов формировалась только агрегированная информация об обобщенных показателях оборудования, без детализации по предложенному иерархическому представлению объектов.

Таким образом, можно сделать вывод, что реализация и внедрение двухуровневой СУМ позволили повысить контролепригодность элементов и устройств РИУС за счет увеличения быстродействия, доступности и полноты информации процессов управления, мониторинга и диагностирования.

В сочетании с объектно-ориентированным представлением структуры информационного обеспечения и программно-реализованной поддержки стандартных протоколов управления для повышения контролепригодности менеджеров систем управления также применены следующие способы и подходы (рассмотрены на примере системы управления оборудованием ПАО «Морион»):

–взаимодействие программного обеспечения системы управления (КПО-01)

спрограммным шлюзом SNMP (КПО-SNMP [77]) через внутренний программный модуль передачи данных через Socket по протоколу UDP;

–взаимодействие программного обеспечения системы управления (КПО-01)

сменеджером единой системы мониторинга и администрирования (КПО-11 [76]) через внешний программный модуль в виде динамически загружаемой библиоте-

ки (DLL – Gate_kpo11.dll);

–контролепригодное реконфигурирование структуры двухуровневой СУМ на основе разработанного информационного и программного обеспечения преобразователя протоколов (далее рассмотрено более подробно).

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

Введение. Постановка задачи. Управление и мониторинг (контроль) оборудования являются важными задачами технической эксплуатации сети [23]. Указанная задача решается с использованием специально разработанных систем управления и мониторинга, которыми комплектуется поставляемое производителем оборудование либо которое может быть разработано сторонней организацией. Система управления осуществляет взаимодействие с оборудованием по протоколу управления, который реализует функции прикладного уровня модели OSI/ISO. Протоколы управления, как правило, являются оригинальными и разрабатываются изготовителями, при этом они реализуются либо не по общепринятым стандартам, либо с отклонениями от них, при этом декларируя наличие под-

97

держки стандартных протоколов управления [20]. Таким образом, оператор связи вынужден использовать набор систем управления, каждая из которых управляет конкретным перечнем оборудования разных производителей в составе мультивендорной гетерогенной сети. Между тем взаимодействие таких систем управления трудно реализуемо или практически нереализуемо из-за существенных отличий в реализованных протоколах и информационных моделях [150]. Отсюда можно сделать вывод о том, что отсутствие интегрированной платформы управления и диагностики у оператора связи является существенным негативным фактором, снижающим количественные качественные показатели работы РИУС и предоставляемых ею услуг [151].

При организации оператором связи единой системы управления и мониторинга для всего оборудования, входящего в сеть оператора, возникают проблемы из-за несоответствия протоколов управления, реализованных в сетевых элементах, и протоколов единой системы управления. Наиболее эффективным путем ее решения является преобразование протоколов (шлюзование) между разными сис-

темами управления (информационное, аппаратное, программное или комплексное шлюзование) [143]. С учетом изложенного сформулируем актуальную задачу данного раздела: разработка и апробация аппаратурно-программного обеспечения преобразователя протоколов для управления и мониторинга промышленного оборудования с нестандартным («фирменным») протоколом управления на базе стандартного протокола управления SNMP. В качестве примера объекта выбрано промышленное оборудование ТЛС-31 производства ПАО «Морион» (г. Пермь), применяемого в транспортных коммуникационных системах.

Принципы построения преобразователя протоколов. Задача мониторинга по стандартному протоколу, которая в данной работе представляется первичной относительно задачи управления, может быть разбита на две составляющие: мониторинг конфигурационной и аварийной информации. Конфигурационная информация содержит сведения о типе оборудования, версии установленного программного обеспечения, типе и месте расположения в блоке модулей (плат), а также о режимах работы мультиплексорного оборудования в составе блока. Аварийная информация может быть представлена в обобщенном виде («есть аварии» – «нет аварий») или конкретизирована.

Существуют три основных современных протокола управления прикладного уровня – SNMP, CMIP, CORBA. Наибольшее распространение получил протокол SNMP из-за достаточной простоты алгоритма взаимодействия. Большинство используемых операторами связи систем мониторинга поддерживают протокол SNMP версий с 1-й по 3-ю. Поэтому наиболее целесообразной является использование протокола SNMP.

В зависимости от конкретной ситуации при мониторинге оборудования возможны следующие варианты решения (рис. 3.9):

98

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

SNMP

Рис. 3.9. Варианты реализации SNMP-мониторинга

1.Реализация SNMP-агента в сетевом элементе. В этом случае необходимо выполнить аппаратно-программную доработку существующего или разработку дополнительного модуля управления и мониторинга в составе оборудования (вариант 1). Реализация указанного варианта возможна только на предприятииизготовителе оборудования и подразумевает большие затраты на разработку и производство дополнительных узлов.

2.Разработка аппаратно-программного шлюза (преобразователя протоко-

лов). Шлюз может быть реализован в качестве специализированного внешнего устройства и подключен к каждому сетевому элементу (вариант 2а). В другом случае шлюз в виде программного обеспечения может быть установлен на управляющем устройстве (компьютере) и обслуживать всю сеть или выделенные подсети оборудования (вариант 2б).

Очевидно, что в условиях отсутствия возможностей по доработке аппаратуры вариант с реализацией шлюза является единственно приемлемым решением. Решение задачи упрощается за счет того, что функции транспортной сети управления в данной аппаратуре решаются при помощи стандартных протоколов (стек протоколов RS-232/SLIP/IP/UDP). Поэтому задача сводится к разработке программного шлюза. Для этого достаточно иметь информацию о «фирменном» протоколе управления (форматы команд и ответов).

Разработка программного обеспечения шлюза. Поясним организацию

SNMP-мониторинга аппаратуры ТЛС-31 по рис. 3.10. Выделим основные элементы системы:

М – SNMP-менеджер (программное обеспечение платформы управления, взаимодействующей с сетевыми элементами или шлюзами по протоколу SNMP);

99

СЭ – сетевые элементы (например, блоки аппаратуры ТЛС-31);

МВСЭ – модули взаимодействия с сетевыми элементами (реализуются в виде динамически загружаемых библиотек – DLL и предназначены для сбора информации с сетевых элементов по «фирменному» (Ф) протоколу);

МВМ – модуль взаимодействия с SNMP-менеджером (реализуется в виде динамически загружаемой библиотеки – DLL и предназначен для обмена информацией с менеджером системы по протоколу SNMP);

Ш – программное обеспечение шлюза (обеспечивает взаимодействие между модулями с целью обменаи преобразования информации в нужные форматы).

Программное обеспечение шлюза может выполняться как на том же компьютере, на котором установлен менеджер, так и на любом другом, к которому есть доступ по протоколу TCP/IP. Это позволяет говорить об аппаратурно-про- граммной реализации данного преобразователя протоколов.

Программное обеспечение разработано автором в среде Borland Delphi 2007 for Win32 Enterprise, получено свидетельство о государственной регистрации программы для ЭВМ [98].

Алгоритм работы системы:

1.SNMP-менеджер формирует запрос интересующей его конфигурационной или аварийной информации о сетевом элементе. На карте сети располагаются сетевые элементы, но запрос адресуется к шлюзу.

2.Модуль взаимодействия с менеджером в составе шлюза принимает входящий запрос менеджера, сохраняет его в память, формируя очередь для эффективной обработки и оптимального быстродействия.

3.Очередной запрос из очереди обрабатывается, из него извлекается описание запрашиваемого сетевого элемента (адрес и тип).

4.Через соответствующие модули взаимодействия с сетевыми элементами шлюз опрашивает нужный СЭ. МВСЭ складируют полученную информацию

вфайл определенного формата. После этого шлюз извлекает информацию из файла и размещает ее в собственных структурах в памяти (переменных и массивах).

100