CC BY
158
Проблемы актуализации и управления базами данных систем автоматизированного мониторинга волоконно-оптических кабелей
Наиболее перспективным для линейно-кабельных сооружений (ЛКС) волоконно-оптических линий передачи (ВОЛП) сетей связи является техническое обслуживание по фактическому техническому состоянию. Эта стратегия обслуживания базируется на техническом диагностировании и прогнозировании состояния объекта. При ее реализации технические эксперты разрабатывают сценарий обслуживания объекта на основе прогноза, а затем менеджеры корректируют его на основе управления рисками. Эффективность рассматриваемой стратегии во многом определяется точностью прогнозов, достоверностью и достаточностью информации для выработки управляющих решений. Важнейшим и необходимым условием реализации стратегии технического обслуживания ЛКС ВОЛП по фактическому состоянию является наличие системы автоматического мониторинга волоконно-оптических кабелей (САМ-ВОК). Далеко не все процессы технической эксплуатации ЛКС ВОЛП могут быть автоматизированы. Это создает определенные проблемы актуализации баз данных, требует обеспечения возможностей автоматической синхронизации баз данных, созданных в разных подразделениях, согласования баз данных системы с существующей базой ЛКС, возможности ввода в базу данных технологических карт, инструкций, схем оповещений. При этом требуется возможность осуществления выборки данных, формирования отчетов по подразделениям. Сформулированы проблемы актуализации и управления базами данных системы мониторинга ЛКС ВОЛП на примере разработанной совместно МТУСИ и ПГУТИ САМ-ВОК. Рассмотрены сценарии актуализации баз данных, их структура и алгоритмы управления.
Ключевые слова:
волоконно-оптическая линия передачи, линейно-кабельные сооружения, система автоматического мониторинга.
Бурдин ВА,
дт.н., профессор, проректор по науке и инновациям ФГОБУВПО ПГУТИ
Сивков В.С.,
к.т.н., доцент, начальник отдела информационных систем ФГОБУВПО ПГУТИ
Чадаев Д.Е.,
аспирант кафедрыы "Линий связи и измерений в технике связи" ФГОБУВПО ПГУТИ
Известно, что наиболее перспективной для линейно-кабельных сооружений волоконно-оптических линий передачи сетей связи является стратегия технического обслуживания по фактическому техническому состоянию [1-3]. Эта стратегия обслуживания базируется на техническом диагностировании и прогнозировании состояния объекта. При ее реализации технические эксперты разрабатывают сценарий обслуживания объекта на основе прогноза, а затем менеджеры корректируют его на основе управления рисками. Эффективность рассматриваемой стратегии во многом определяется точностью прогнозов, достоверностью и достаточностью информации для выработки управляющих решений. Соответственно важнейшим и необходимым условием реализации стратегии технического обслуживания ЛКС ВОЛП по фактическому состоянию является наличие актуальной базы данных, отображающей состояние объекта системы контроля и прогноза состояния объекта.
Модели OSS предусматривают учет ресурсов сети — систем передачи, сетевых элементов и т.п., данные о которых получают от активных элементов. Линейно-кабельные сооружения состоят из пассивных элементов, что требует оборудования специализированных систем контроля. В частности, применения систем автоматизированного контроля оптических волокон, систем контроля доступа в необслуживаемые пункты (НП), влажности и температуры в НП и т.п. Од-
нако, далеко не все процессы технической эксплуатации ЛКС ВОЛП могут быть автоматизированы. В частности, охранно-разъяснительная работа, профилактические работы по поддержанию состояния трассы кабельной линии, отдельные виды ремонтных работ и т.п. Все это определяет базовую роль регламентов, системы теху-чета. Эффективность внедрения систем мониторинга оптических кабелей (СМОК) на кабельной линии существенно зависит от того, насколько отлажена службой ее технической эксплуатации система те-хучета. Необходимость совместного функционирования системы те-хучета и системы мониторинг кабельной линии подробно рассматривались в работах [3-6]. Помимо проблемы актуализации баз данных, требуется обеспечение автоматической синхронизации баз данных, созданных в разных подразделениях, согласования баз данных системы с существующей базой данных ЛКС, возможности ввода в базу данных технологических карт, инструкций, схем оповещений, а также возможность осуществления выборки данных, формирования отчетов по подразделениям. Для реализации прогнозирующей стратегии технического обслуживания ЛКС ВОЛП необходимо решение, объединяющее для совместной работы систему мониторинга и программный продукт документирования сетевой информации.
В работах [7, 8] представлен пример диаграммы потоков данных и даталогической модели данных, разработанных на основе методологий проектирования данных IDEF0, DFD и IDEF1X, что позволило создать гибкую модель данных, позволяющую учитывать специфику совместного сбора, обработки и хранения данных автоматизированных процессов и процессов, не поддающихся автоматизации, технической эксплуатации ЛКС ВОЛП.
При разработке структурной схемы программной платформы системы мониторинга основным требованием, предъявляемым к ней, является максимальная универсальность и гибкость настройки, позволяющие использовать одну и ту же основу для построения различных сервисных систем телекоммуникационного предприятия [9]. Технологии, позволяющие создать максимально гибкую программ-
ную платформу для информационных систем различного назначения, как правило, предусматривают модульную структуру, базируются на концепции МУС и используют МЪЬ приложение.
Модульная структура. Одной из основных концепций для построения высокопроизводительных программных платформ на сегодняшний день является модульная структура. При этом различные составляющие программной платформы функционируют как самодостаточные модули, решающие тот или иной спектр задач. Связь между модулями реализована на основе стандартных интерфейсов или осуществляется через отдельный модуль, который обычно является ядром платформы. На рис. 1 представлен пример архитектуры программной платформы, построенной на основе модулей. Рассмотрим основные уровни данной архитектуры.
Модульная платформа
Модуль СУБД
£
Модуль выполнения асинхронных задач
Ядро
^ 1 N.
«• Модуль HMI Модуль GIS
ТГ
Операционная система Аппаратное обеспечение
Рис. l
Вопрос выбора аппаратного обеспечения для построения информационных систем выходит за рамки данной работы, однако стоит отметить, что модульная программная архитектура позволяет легко масштабировать аппаратную часть системы, а также реализовать распределенные вычисления и децентрализованное хранение данных. Взаимодействие программной платформы с аппаратным обеспечением происходит посредством стандартных протоколов и интерфейсов через операционную систему (ОС). Выбор ОС должен быть обусловлен рядом факторов: цена лицензии, поддержка необходимых для проекта аппаратных платформ и устройств, соответствие стандартам переносимости приложений, возможности работы в режиме мягкого или жесткого реального времени, устойчивость к заражению вредоносными программами и др. Кроме того, необходимо проанализировать возможный состав модулей программной платформы и их совместимость с выбираемой ОС. Здесь нужно отметить, что в рамках модульной архитектуры возможно использование различных ОС, развернутых на виртуальных машинах или на реальном оборудовании. Взаимодействие между модулями в этом случае может быть организовано посредством стандартного стека сетевых протоколов.
Следующим уровнем архитектуры является собственно модульная программная платформа. Центром такой структуры является модуль-ядро, организующее процессы передачи и обработки данных. Ядро обеспечивает функции диспетчеризации задач систем, организует процессы обработки данных, занимается вопросами взаимодействия с операционной системой. Важным преимуществом такой организации является возможность оптимизации состава модулей, в зависимости от потребностей информационных систем. Например, если для данного этапа развития информационных ресурсов телекоммуникационного предприятия не требуется выполнения
Рис. 2
большого количества асинхронных задач, то данный модуль может быть отключен от систем, однако если такая необходимость возникнет, то добавить данный модуль не составит труда.
Концепция MVC Bыбор концепции разработки модуля-ядра программной платформы является важным этапом, на котором можно предопределить будущее такой платформы и работающих на ней информационных систем. Одной из наиболее перспективных концепций разработки информационных приложений на сегодняшний день является концепция Model-view-controller (MVC, "Модель-представление-поведение", "Модель-представление-контроллер") [lO, ll]. Идея концепции состоит в разделении логики приложения (модели) от его визуализации (представления) — такая схема позволяет изменять какой-либо компонент приложения с минимальным влиянием на остальные компоненты. На рис. 2 представлена обобщенная структурная схема приложения, построенного с использованием MVC. Основными компонентами такого приложения являются модель (model), представление (view) и контроллер (controller). Модель предоставляет набор данных и методов работы с этими данными. Представление отвечает за визуализацию данных, формирование элементов пользовательского интерфейса. Контроллер организует связь между пользователями-клиентами и приложением, контролирует ввод пользовательских данных и формирует ответ, используя модель и представление.
Для построения модуля-ядра программной платформы на базе концепции MVC необходим архитектурный каркас (framework) [l2, l3]. Каркас создает постоянную основу с широкими возможностями по расширению функционала модуля. На этапе выбора каркаса определяется язык программирования, с помощью которого будет реализован функционал модуля. Далее рассматриваются варианты создания каркаса собственной разработки или использования готовых каркасов. Здесь нужно отметить, что использование готовых решений позволяет существенно сократить время разработки модуля. C другой стороны, самостоятельная разработка каркаса командой профессионалов позволит в большей степени адаптировать framework для специфических задач модуля.
бедующей важной задачей для разработчика программной платформы информационных систем является определение технологий предоставления интерфейса конечным пользователям. Традиционным способом организации интерфейса пользователя и информационной системы является инсталляция на рабочем месте специального приложения-клиента. Основными проблемами, которые возникают в этом случае, являются проблемы синхронизации приложений-клиентов и информационных систем. Эти проблемы не столь существенны для небольших организаций, однако для крупных предприятий с большим количеством удаленных филиалов техническая поддержка клиентского программного обеспечения (ПО) является достаточно сложной задачей. Кроме того, есть еще ряд проблем, связанных с разработкой приложений-клиентов для различных операционных систем и мобильных платформ.
Web приложение. Альтернативным подходом к решению задачи взаимодействия пользователей и информационных систем является создание web приложений [l4, l5]. B этом случае приложени-
ем-клиентом выступает браузер, что позволяет избавиться от дополнительных затрат, связанных с разработкой клиентского ПО для различных операционных систем и мобильных платформ. Одновременно решаются проблемы синхронизации версий клиентского ПО и значительно сокращается время организации новых рабочих мест пользователей информационной системы. На рис. 3 представлена обобщенная структурная схема web приложения. Для запуска web приложения пользователям не требуется проводить инсталляций дополнительного ПО, поскольку web браузер является неотъемлемым компонентом большинства современных ОС Зная адрес web сервера, который является посредником между информационными системами и браузером, пользователь может сразу начать работу с web приложениями. При этом всё описание интерфейса пользователя и необходимые данные формирует web сервер, а браузер отображает интерфейс пользователя в графическом виде и передает запросы пользователя на web сервер.
Таким образом, используя модульную концепцию построение модуля-ядра на основе MVC каркаса и организуя взаимодействие с пользователями посредством web приложений, возможно построить гибкую в настройке, легко масштабируемую программную платформу. На основе данной платформы могут быть построены как системы мониторинга, так и другие информационно-управляющие системы телекоммуникационных предприятий любого масштаба.
Примером реализации решения, объединяющего для совместной работы систему мониторинга и программный продукт документирования сетевой информации, является CMОK производства ОАО "Юрьев Польский завод "Промсвязь", разработанная совместно специалистами MWd и ПГУТИ. B данной системе одна централизованная база данных. При этом, CMОK использует ПО с открытым исходным кодом, что обеспечивает минимальную себестоимость ПО, высокую скорость модернизации и разработки новых модулей, возможность поддержки системы силами программистов заказчика и/или разработчика. Модульная платформа позволяет распределять нагрузки на систему как на уровне физических серверов, так и на уровне виртуальных машин, и обеспечивает готовность системы к развертыванию внутри "облака". Bозможно использование различных ОC для развертывания CMОK (Windows, Linux, *BSD)
B CMОK предусмотрено отображение информации на картах, создаваемых с помощью геоинформационных систем (IVIC). Картографические данные для составления цифровых карт доступны пользователям CMОK через сервис OpenStreetMap, что обеспечивает свободный доступ к источникам геоданных и позволяет проводить мероприятия по покупке цифровых карт и их загрузке (карты бесплатно доступны для любого участка территории планеты в рамках покрытия OpenStreetMap). Кроме того, платформа CMОK позволяет подключать дополнительные источники геоданных (данные дистанционного зондирования, спутниковые фотографии и т. д.).
Web приложение
Интерфейс
пользователя
HTTP
HTTPS
Web сервер РисЗ
Данная СМОК, каки аналогичные системы, включает систему удаленного тестирования, обеспечивает мониторинг как по "темным", так и "активным" ОВ, и, как правило, использует штатные модули удаленного тестирования. Но при этом она позволяет использовать в качестве модулей удаленного тестирования оптические рефлектометры с функцией внешнего управления другихпроизводителей, а также подключать измерительные платформы с функцией внешнего управления других производителей, например, для мониторинга качества DWDM. Удаленный комплект включает электронный коммутатор 1Х4 и позволяет дополнительно подключать внешние оптические коммутаторы, что расширяет его функциональные возможности. Также СМОК предусматривает подключение датчиков контроля пассивных элементов ЛКС ВОЛП (открытие дверей НП, температура и влажность в НП и т.п.).
Основное меню программного модуля состоит из четырех разделов: "Мониторинг", "Учет ЛКС", "Отчеты", "Справочники".
В левой части раздела "Мониторинг" отображаются все ВОЛС, к которым подключены измерительные модули СМОК (удаленные комплекты). Пользователь видит номер линии, оконечные пункты и статус исправности линии. В левой части экрана отображаются важные события (по степени важности и в хронологическом порядке). Далее отображаются 10 последних событий зарегистрированных системой (в хронологическом порядке). Весь журнал событий можно посмотреть нажав на гиперссылку "Все события". В журнале событий имеется возможность фильтрации событий по дате, номеру линии и типу события. Каждая строчка в журнале событий содержит гиперссылку, нажав на которую пользователь получает доступ к подробному описанию события. В правой части экрана "Мониторинг" отображается цифровая карта с объектами ЛКС и событиями, зарегистрированными системой. Развернуть карту на весь экран можно нажав гиперссылку "Карта" системы мониторинга (рис. 4).
Для каждой контролируемой линии на экране "Мониторинг" отображается гиперссылка "Измерения", активировав которую, пользователь попадает на страницу измерений линии. На данной странице отображаются информация о подключенных к линии удаленных комплектов, выводится информация об узле, на котором расположен удаленный комплект, инвентарный номер удаленного комплекта, номер канала удаленного комплекта и параметры телеметрии, полученные с удаленного комплекта. На странице автоматических измерений в левой части в табличном виде отображаются параметры текущей рефлектограммы. В правой части отображается графическое представление рефлектограммы, совмещенное со схемой размещения муфт на трассе (рис.5). В нижней части отображается цифровая карта местности с текущей линией, для которой выполнены измерения. Для подробного анализа рефлектограмм необходимо нажать гиперссылку "Работа с рефлектограммой" в верхней правой части страницы. На странице анализа рефлектограммы у пользователя имеется возможность проводить стандартные виды обработки измеренной рефлектограммы. Есть возможность перевести удаленный комплект в ручной режим измерений и работать с ним как с обычным оптическим рефлектометром. Для этого необходимо нажать гиперссылку "Ручные измерения".
Раздел "Учет ЛКС" предназначен для обеспечения доступа к базе данных ЛКС. Имеется возможность просмотра базы в соответствии с иерархией пользователей. Также имеется возможность непосредственного добавления ЛКС. Одной из основных страниц данного раздела является страница "Линии". На странице отображаются параметры ВОЛП, цифровая карта с объектами ЛКС, а также схема строительных длин ВОЛП.
В разделе "Отчеты" находятся страницы отчетов, формируемых различными выборками из базы данных. Например, инвентаризационная ведомость ЛКС ВОЛС для данного подразделения (и для дочерних подразделений).
Рис. 4
В разделе "Справочники" представлены справочники, обеспечивающие работу программного модуля. Использование единой базы данных и объединения для совместной работы системы мониторинга и программного продукта документирования сетевой информации, построенного на основе модульной концепции с модулем-ядром на основе MVC каркаса и web-интерфейсом, позволяет реализовать при внедрении данной СМОК, как минимум, преимущества корректирующей стратегии технического обслуживания ЛКС ВОЛП. В частности, применение данной СМОК обеспечивает следующее.
• Расширение сетевых возможностей, включая быстрое детектирование и определение мест аварий и деградации волокна, более точное определение места неисправности и уменьшение затрат на восстановление поврежденного элемента.
• Повышение уровня обслуживания за счет генерации отчетов для поддержки SLA agreements (MTTR, статистика аварий и тп.), удаленного тестирования, интеллектуальных переключений.
• Увеличение безопасности сети, за счет пресечения попыток взлома.
• Отображение сетевой информации на картах местности.
• Повышение качества управления, поскольку сетевая информация централизована в базе данных, представляется в доступной форме, легко корректируется.
• Упрощение модернизации и восстановления сети, помощь в поиске новых трасс прокладки, быструю идентификацию используемых волокон.
• Уменьшение стоимости процесса документирования.
• Автоматическое определение места аварии, автоматическую генерацию отчетов, настройку отчетов по форме заданной пользователем.
• Удаленное тестирование, предусматривающее полный набор инструментов для измерений и анализа ОВ, как в обычном оптическом рефлектометре.
• Локализацию мест расположения событий на линии с помощью GIS.
При этом обеспечивается гибкая техническая поддержка, возможность работы с СМОК с любого устройства (ПК, ноутбук, планшетный ПК, смартфон), исключается необходимость устанавливать программное обеспечение на клиентских персональных компьютерах, доступ к системе осуществляется через WEB-интерфейс.
Таким образом, организация техучета и строгое соблюдение регламентов совместно с внедрением СМОК, в которой объединены для совместной работы система мониторинга и программный продукт документирования сетевой информации, позволяют решить
Рис. 5
проблемы актуализации и управления базами данных в процессе технической эксплуатации ЛКС ВОЛП, что позволяет внедрить корректирующую, а при дальнейшем развитии функциональных возможностей мониторинга ОВ и прогнозирующую стратегии технического обслуживания.
Литература
1. Овсянников А Стратегии ТОиР и диагностика оборудования // Электроцех, №9, 2008. — С.6-9.
2. Бурдин В А., Воронков АА, Шафигуллин Л.Н., Чадаев Д.И. Прогнозирующие стратегии технического обслуживания и мониторинг линейно-кабельных сооружений ВОЛП// Вестник связи, №12, 2010. — С.45-47.
3. Бурдин В.А., Воронков АА., Шафигуллин Л.Н. Эффективность применения прогнозирующих стратегий технического обслуживания ОК// Вестник связи, № 7, 2012. — С.5-8.
4. Бакланов И. Система техучета или система мониторинга ВОЛС//Фотон-экспресс, №7, 2005. — С.45-49.
5. Андреев ВА, Бурдин В А. Проблемы внедрения систем автоматического мониторинга волоконно-оптических кабелей // X МНТК "Проблемы техники и технологии телекоммуникаций", Самара, 2009. — С. 406-407.
6. Андреев ВА., Бурдин ВА., Шафигуллин Л.Н. Проблемы внедрения систем мониторинга волоконно-оптических кабелей связи на сетях связи// XI МНТК "Проблемы техники и технологии телекоммуникаций", Уфа, 2010, — С.336-338.
7. D.l. Chaadev, I.V. Sharkevich, Fiber network telecommunication information system designing using modern design methodologies// Proceedings of SPIE, Vol. 5485, 192 (2004).
8. Чадаев Д.И, Семенов Е.С. Разработка информационных моделей информационно-телекоммуникационной системы "Проектирование и мониторинг ВОЛП"// Прикаспийский журнал: Управление и высокие технологии №2(18) 2012.
9. Сивков В.С., Сподобаев М.Ю. ^информационная система как интеграционная платформа электромагнитного мониторинга// Инфокомму-никационные технологии, 2011, №2. — С. 57-62.
10. Trygve М. Н. Reenskaug/MVC XEROX PARC 1978-79.
11. Гамма Э, Хелм Р, Джонсон R, ВлиссидесДж. Приёмы объектно-ориентированного проектирования. Паттерны проектирования 2001.
12. Riehle, Dirk (2000), Framework Design: A Role Modeling Approach, Sw'ss Federal Institute of Technology
13. Johnson, R E (1992), "Documenting frameworks using patterns", Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications (ACM Press): 63-76.
14. Марко Беллиньясо. Разработка Web-приложений в среде ASPNET 2.0: задача — проект — решение = ASPNET 2.0 Website Programming: Problem — Design — Solution. — М.: "Диалектика", 2007. — С. 640.
15. Олищук А.В. Разработка Web-приложений на PHP 5. Профессиональная работа. — М.: "Вильямс", 2006. — С. 352.
