2. Построение информационной системы

2.1 Узлы информационной системы и протокол дистанционного управления

Разрабатываемая в настоящей работе информационная система предназначена для осуществления контроля за работоспособностью всех узлов спутниковой корпоративной сети Казтелерадио. Эти узлы представляют собой, как уже описывалось выше, более 300 РТС станций, расположенных по территории всей республики.

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

Передача данных - процесс физического переноса данных (цифрового битового потока) в виде сигналов. Есть несколько видов передачи данных. Такие как: от точки к точке либо от точки к нескольким точкам.

Для управления сетями передачи данных по протоколу IP существует протокол управления сетью SNMP (Simple Network Manager Protocol), который обеспечивает поддержку правил взаимодействия управляющей станции и объектов управления. А данные управления хранятся внутри объекта. Таким образом протокол SNMP позволяет управлять самыми разными объектами сети централизованно.

Простой протокол управления сетью (SNMP) – один из популярных протоколов для управления сетью. Он используется для сбора информации и конфигурирования от сетевых устройствах, такие как серверы, принтеры, концентраторы, переключатели и маршрутизаторы в сети Internet Protocol (IP). Сервера Microsoft Windows обеспечивает программное обеспечение агента SNMP, которое работает со сторонним программным обеспечением управления SNMP, чтобы контролировать состояние управляемых устройств и приложений.

Большими сетями с сотнями или тысячами узлов трудно управлять без многочисленного штата, который помогал бы контролировать каждый компьютер. SNMP, который широко используется в локальных сетях (LAN), позволяет контролировать сетевые узлы от узла управления. Таким образо контролируются сетевые устройства, такие как серверы, рабочие станции, принтеры, маршрутизаторы, мосты, и концентраторы, а также службы, такие как протокол динамического конфигурирования узлов (DHCP) или Windows Internet Name Service (WINS).

Можно использовать программное обеспечение управления SNMP, чтобы контролировать любое сетевое устройство, на котором установлено программное обеспечение агента SNMP. Агент SNMP, который является дополнительным компонентом, взаимодействует со сторонним программным обеспечением управления SNMP, чтобы включить совместное использование

25

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

Компьютер, управляющий менеджером по SNMP, просит информацию о положении от устройств, управляющих агентом SNMP.

Рисунок 2.1 - Принцип работы протокола

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

Разработанный в 1988, чтобы обеспечить контролирующую сетевое устройство возможность сетей TCP/IP-based, SNMP был утвержден как интернет-стандарт в 1990 Советом по архитектуре сети Интернет (IAB) и широко используется с этого времени. Позже, межсетевой пакетный обмен (IPX) - основанные сети добавил поддержку SNMP. В настоящее время поставщики наиболее сетевого оборудования предоставляют поддержку SNMP в своих продуктах.

Существуют версии 1 и 2,3 SNMP, которые основываются на промышленных стандартах.

26

Важной составляющей понятия SNMP является MIB (база информации управления).

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

MIB - тип базы данных, используемой, чтобы управлять устройствами в сети. Это - группа объектов в (виртуальной) базе данных, используемой, чтобы управлять механизмом, таким как маршрутизаторы в сети.

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

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

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

Менеджеру по SNMP нужен MIB, чтобы обработать сообщения от сетевых устройств. MIB – также лучшее руководство по реальным возможностям устройства SNMP При считывании MIB так, появляется понимание того, какая информация имеется

Рассмотрим же применение данных механизмов в нашем случае.

При использовании протокола SNMP, кроме данных MIB (всех существенных данных состояния блоков оборудования типовой РТС), блоками оборудования формируются сигналы обобщенного состоянии «Trap». У различных блоков оборудования могут использоваться различные варианты формирования сигналов «Trap». Эти сигналы могут содержать:

• только данные о отсутствии или наличии аварии блока без указания причины аварии;

• данные об аварии с указанием признаков и причин аварии;

• данные о выходе параметров MIB за допустимые пороговые значения

• т.д.

• любой системе управления реализуется итеративный цикл: - Сбор данных о параметрах управляемых объектов;

- Оценка состояния управляемых объектов в текущий момент времени,

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

• Формирование сигнала управления для перевода управляемых объектов в штатное состояние.

• Сбор данных о параметрах управляемых объектов и т.д..

27

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

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

Для большинства типовых отказов система контроля и управления обеспечивает полный цикл: сбор данных - оценка состояния - выработка управляющих сигналов - передача управляющих команд. В настоящем проекте рассмотрен вариант создания системы управления именно этого класса.Система контроля и управления предназначена для дистанционного управления и контроля технических средств объектов сети цифрового наземного телевизионного вещания.

АО «Казтелерадио» с ее использованием должны решаться задачи: - контроля состояния сети и ее элементов в реальном масштабе времени (дискретно, с заданным шагом от единиц до десятков секунд);

- обнаружения и локализации неисправностей; - контроля восстановления связей; - контроля оперативного перестроения сети;

- контроля устранения неисправностей.

- сбора и анализа статистических данных по функционированию сети и

• элементов;

- разработки рекомендаций по улучшению эксплуатационных характеристик сети;

- анализа функционирования систем управления, с целью усовершенствования методов управления сетью;

• дистанционного управления оборудованием сети.

Система контроля и управления должна обеспечивать:нгшнгшнгш

Создание единой информационной системы мониторинга состояния

объектов сети передающих центров АО «Казтелерадио». Автоматизированный сбор, анализ и хранение в единой

информационной системе аварийных сообщений, сообщений о конфигурации

28

• статистике использования ресурсов контролируемых объектов сети передающих центров.

Автоматизацию формирования отчетности о состоянии сети и предоставление доступа к отчетам для заинтересованных подразделений АО

«Казтелерадио».Система контроля и управления должна иметь иерархическую структуру с выделением следующих программно-аппаратных средств контроля и управления:

Республиканские Центры контроля и управления сетью (ЦУС-Р) основной в г. Алматы, ДРТ «Кок-Тобе» и резервный ДРТ г. Астана, областные центры управления (ЦУС-О), блоки контроля и управления РТС (БКУ РТС).

Длина IP –пакета с сигналом «Trap» для каждого блока оборудования равна 100 байт и каждые 4 секунды каждый блок оборудования формирует свой сигнал «Trap». Если на РТС не производится предварительная обработка сигналов «Trap» , то каждые 4 секунды необходимо передать число сигналов «Trap», равное числу блоков с агентами SNMP. Таких блоков в составе типовой РТС 9 единиц:

• коммутатор резервирования спутниковых трактов приема (1 ед.);

• приемник-ремультиплексор PVR-7100 (2 ед.);

• модулятор DVB-T2 (2ед);

• контроллер STC-1000 (1 ед.);

• контроллер системы электроснабжения (1 ед.);

• контроллер системы жизнеобеспечения (1 ед.);

• терминал VSAT (1 ед.).

Таким образом, суммарный объем, подлежащих передаче пакетов данных «Trap» обобщенного состояния непосредственно от блоков оборудования, составляет каждые 4 секунды 900 байт. Если на РТС производится предварительная обработка сигналов MIB оборудования и формируется один общий сигнал «Trap» обобщенного состояния РТС, то каждые 4 секунды необходимо передать один сигнал «Trap» средним объемом 250 байт. Рассмотрим возможные варианты передачи данных MIB и «Trap» от РТС к ЦУС. Данные состояния могут передаваться по инициативе РТС в случайные моменты времени, либо по инициативе ЦУС в жестком временном цикле, с заблаговременным выделение каждой РТС соответствующих временных окон. Оценим каждый из вариантов для сети сбора данных о состоянии «Trap».

Передача сигналов «Trap» от РТС в случайные моменты времени. Примем, что все блоки оборудования всех РТС сети без взаимной синхронизации друг с другом каждые 4 секунды формируют сигналы «Trap». Передача сигналов осуществляется с использованием многостанционного доступа к одному или нескольким системным каналам.

Выберем близкую к минимально допустимой символьную скорость в системном канале - 256 кбит/с. Тогда суммарная скорость передачи в системном канале без учета защитных интервалов (менее 5% от его пропускной способности) для оптимизированного режима QPSK (с

29

кодирование 9/10) составит около 450 кбит/с. Требуемая скорость передачи одного сигнала «Trap» - 100×8/4=200бит/с. Средняя интенсивность обслуживания для системы из 1000 РТС по 9 блоков в каждой1000×9×200/450×1000=4Эрл. При формировании сигнала «Trap» обобщенного состояния РТС требуемая скорость передачи одного сигнала «Trap» - 250×8/4= 500 бит/с. Средняя интенсивность обслуживания для системы из 1000 РТС по 9 блоков в каждой 1000×500/450×1000= 1,111 Эрл. В табл. 2.2. приведены оценки требуемой пропускной способности для передачи сигналов «Trap» в зависимости от заданной вероятности отказа в предоставлении канала (вероятности доведения сигнала до ЦУС за время 4 секунды) для системы случайного доступа без очереди на обслуживание.

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

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

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

Основные требования к системе контроля и управления сетью телерадиовещания АО «Казтелерадио».

• соответствии с п.6.1-6.4 «Решения Совещание №10 по вопросам разработки рабочих проектов Модернизация сети АО «Казтелерадио» для перехода на цифровое телевизионное вещание» от 06.08.2012 г.

Сбор данных о состоянии работоспособности всех РТС республиканской сети вещания должен осуществляться за время не более 30 сек. Система управления строится с распределением задач контроля и управления между республиканскими и областными центрами.

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

30

предварительную обработку (фильтрацию) данных о состоянии РТС и их хранение в течение 1 месяца.

• сети управления должна обеспечиваться возможность следующих вариантов передачи данных о состоянии РТС:

- в каждом цикле опроса передаются обобщенные данные состояния

РТС:

- формирование обобщенных данных с идентификацией причин аварии осуществляется в блоке контроля и управления РТС. При штатном состоянии всех параметров аппаратуры формируется 1-2 байта с номером РТС и идентификатором штатного состояния. При наличии аварий дополнительно передаются 8-10 байт с идентификаторами аварий;

- по инициативе областного (республиканского) центра управления должна обеспечиваться возможность передачи данных о состоянии аппаратуры РТС в объемах меню блоков оборудования за любой заданный промежуток времени;

- при отказе программно-аппратных средств, обеспечивающих предварительную обработку и хранение данных о состоянии РТС, должна обеспечиваться возможность передачи данных о параметрах блоков оборудования в реальном масштабе времени с организацией «обхода» отказавшего тракта. В системе контроля и управления сетью телерадиовещания АО «Казтелерадио» используется протокол SNMP (Simple Network Management Protokol, или простой протокол управления сетью). Этот протокол позволяет ЦУС и БКУ обращаться к MIB (Management Information Base, или базам данных управляющей информации) любого блока оборудования, имеющего агент SNMP.

Протокол SNMP стандартизует типы передаваемых команд (данных): - Get-request - запрос MIB по имени блока;

- GetNext-request - запрос MIB при последовательном по времени просмотре таблицы блоков оборудования;

- Get-response- ответ на команды Get-request и GetNext-request

- Set- передача команд управления на изменение состояния блока оборудования;

- Trap- сигнал обобщенного состояния, формируемый блоком на основе анализа собственного текущего состояния. В отличие от команд 1-4, передаваемых по запросу менеджера управления (ЦУС или БКУ), этот сигнал, как правило, предполагает передачу в реальном времени. В соответствии с данными настоящего раздела предполагается, что сигналы Trap от БКУ РТС к ЦУС передаются без запроса менеджера (ЦУС), однако по заранее установленному расписанию (в заданных временных окнах системы VSAT). Помимо стандартизации типов команд, протокол SNMP позволяет существенно снизить объем передаваемых данных за счет использования команды «Trap» - сигнала обобщенного состояния.

31

Отметим, что сам по себе выбор протокола SNMP еще не обеспечивает ни минимизации требуемой пропускной способности, ни адекватной локализации отказов сети.

Параметры MIB различных блоков оборудования РТС сложным образом

взаимообусловлены как общесистемными факторами (состояние республиканской и областных распределительных сетей с учетом погодных условий, помеховая обстановка и т.п.), так и внутренними факторами РТС:

-состоянием межблочных кабельных соединений;

-соответствием сигналов поступающих на входы блоков установленным режимам работы;

-текущей схемой резервирования.

После получения MIB блоков оборудования РТС, даже оператору высокой квалификации для локализации отказа путем логической обработки данных MIB различных блоков оборудования РТС требуется существенное время от единиц до десятков минут. При этом, не гарантируется адекватная локализация отказов. Для решения задачи локализации отказов в системе контроля и управления АО «Казтелерадио» в составе ЦУС-Р предусмотрено использование экспертной системы разрешения критических ситуаций.

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

Минимально необходимый объем данных MIB оборудования РТС для правильной локализации отказов в экспертной системе зависит от:

• объема данных о параметрах блоков, выдаваемых встроенными системами контроля и необходимости привлечения для идентификации отказа данного блока оборудования данных о параметрах других блоков оборудования, взаимосвязанных с данным блоком;

• схемы резервирования объектов;

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

32