
- •ПЕРЕЧЕНЬ СОКРАЩЕНИЙ
- •ВВЕДЕНИЕ
- •1. КЛАССИФИКАЦИЯ СЕТЕВОГО ПО
- •1.1. ПО для активного телекоммуникационного оборудования
- •1.2. ПО для описания, моделирования и проектирования сетей связи
- •2. ОСНОВНЫЕ СОСТАВЛЯЮЩИЕ КОМПОНЕНТЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ OSS
- •2.1. Общий взгляд: TMF Application Framework (TAM)
- •2.2. Способы построения каркаса OSS-системы
- •2.3. Основы архитектуры OSS Аргус: инфраструктура, среда, приложения
- •3. СПОСОБЫ РЕАЛИЗАЦИИ ТИПОВЫХ КОМПОНЕНТОВ OSS
- •3.3. Типовой бизнес-процесс организации предоставления услуги абоненту с помощью OSS
- •3.4. Типовой бизнес-процесс организации устранения неисправности с помощью OSS
- •4.1. Изоляция между приложениями, связность между понятиями среды
- •4.2. Проектирование и разработка типовых интерфейсов интеграции
- •4.3. Основные способы организации взаимодействия между информационными системами
- •4.4. Интеграционная шина как элемент построения инфраструктуры взаимодействия
- •5.1. Многопользовательский доступ к данным
- •5.2. Масштабируемость, отказоустойчивость, балансировка нагрузки
- •5.3. Мониторинг
- •ВОПРОСЫ К ЗАЧЕТУ И ЭКЗАМЕНУ
- •СПИСОК ЛИТЕРАТУРЫ
и авторизации, оповещатель о поступивших заданиях, редактор бизнеспроцессов и т. д. Система RunaWFE внесена в Единый реестр российских программ для электронных вычислительных машин и баз данных по классу ПО «системы управления процессами организации».
Язык jPDL предназначен для разработчика-программиста и не может использоваться как средство общего назначения (в отличие, например, от BPMN). Описание процесса сохраняется в формате XML в файл processdefinition.xml. Наиболее важное, что в нем хранится – это граф бизнес-процесса. Его можно редактировать напрямую (любым текстовым редактором, подходящим для файлов формата .xml) или с помощью какого-либо визуального редактора (например, редактор GPD входя-
щий в состав пакета RunaWFE). Файл processdefinition.xml
содержит информацию о действиях (actions) и задачах (tasks). Также описание может включать другую относящуюся к процессу инфомацию, например, ссылки на классы и интерфейсные формы UI для работы с отдельными задачами и др.
3.3. Типовой бизнес-процесс организации предоставления услуги абоненту с помощью OSS
Процесс приема заявок – один из основных и наиболее часто повторяющихся в компании оператора связи. Ежедневно оператор принимает множество заявок от уже существующих и новых абонентов на подключение/отключение/изменение услуг связи.
На рис. 17 изображен наиболее простой процесс выполнения некоторых услуг (работ) по заявке абонента.
На рис. 18 показан более сложный процесс, с ветвлением в процессе принятия решения, с ожиданием на фазе заключения договора и другими особенностями.
Оба процесса описаны с помощью средств jPDL.
Во втором примере бизнес-процесс предполагает работы с участием персонала (менеджеров абонентского отдела). Если у оператора применяется NRI из комплекса OSS Аргус, то в описании бизнес-процесса может быть встроен вызов сервиса автоматического подбора и бронирования технических данных (оборудования) для предоставления новых услуг, поскольку система OSS Аргус предоставляет подобную возможность.
34

а)
б)
Рис. 17. Блок-схема (а) и jPDL-описание (б) процесса «Общие работы»
35

Рис. 18. АО – процесс установки
36
3.4. Типовой бизнес-процесс организации устранения неисправности с помощью OSS
КТП – это система, предназначенная для автоматизации процессов устранения неисправностей на сети оператора.
Бизнес цель внедрения системы КТП для современного оператора связи это снижение влияния неисправностей и ошибок на качество услуг связи и сокращение расходов на техническую поддержку сети.
Система КТП состоит из трех подсистем:
подсистема Service Desk;
подсистема Техническая Поддержка NGN;
подсистема ЦБР (Централизованное Бюро Ремонта).
Подсистема Service Desk выполняет все абстрактные функции, связанные с приемом обращений абонентов. Предметную нагрузку этим функцям дают подсистемы ЦБР и ТП NGN.
ЦБР предназначена для обработки инцидентов, связанных с предоставлением услуг традиционной телефонии, в то время как ТП NGN занимается обработкой инцидентов на мультисервисных IP/NGN сетях.
Рассмотрим функции КТП, а также некоторые специфические особенности системы, которые делают ее удобной в использовании, гибкой и многофункциональной:
работа с абонентской карточкой;
тестирование услуг и ресурсов;
управление инцидентом;
управление процессом решения проблемы;
взаимодействие с системой inventory;
управление персоналом;
редактирование пакетов услуг;
справочно-информационная система;
настройка и выполнение бизнес-логики системы (BPM).
Система КТП структурирует техническую поддержку оператора в виде первой, второй и третьей линии. На первой линии работают операторы, имеющие базовый уровень прав и компетенции в разрешении проблем, вторую линию составляют узкоспециализированные операторы.
В число пользователей системы также входят работники технических служб (монтажники, монтеры, техники), представляющие собой третью линию технической поддержки; администратор КТП, осуществляющий настройку системы; начальник службы технической поддержки, контролирующий производительность сотрудников и эффективность работы системы.
Система КТП является гибко настраиваемой, благодаря чему вышеприведенная структура не является единственно возможным вариантом.
37
Администратор может адаптировать систему под структуру технической поддержки конкретной компании, например, объединить функции первой и второй линий технической поддержки.
Любое событие, связанное с прекращением предоставления услуги связи или снижением качества обслуживания абонентов, которое фиксируется в системе – это инцидент. Зафиксировать прекращение или неправильную работу услуги может сам абонент, его обращение принимается первой линией технической поддержки и регистрируется в системе в виде инцидента. Также КТП поддерживает регистрацию абонентских интернет обращений через e mail, личный кабинет или формы на сайте. Неисправность может быть обнаружена техническим персоналом, либо оператором второй линии ТП в результате отслеживания аварийных сообщений непосредственно от самого оборудования или от систем мониторинга, и зафиксирована в системе как инцидент.
Инцидент может быть закрыт оператором первой линии техподдержки, если он не представляет собой сложную техническую проблему, требующую вмешательства квалифицированного специалиста. Примером такого инцидента может быть банальное отключение услуги за неуплату. Оператор может проверить состояние счета абонента, обратившись к его карточке, и объяснить ему причину сложившейся ситуации.
Оператор первой линии может собирать данные об инциденте, чтобы точнее его охарактеризовать и классифицировать. Для этого в его распоряжении имеется специальная форма вопросов, которые следует задать абоненту. После сбора этой информации инцидент может быть перенаправлен на вторую линию к специалисту соответствующего профиля. Перед тем, как принять перенаправленный вызов, оператор второй линии имеет возможность ознакомиться с этой предварительно собранной для него информацией.
Результатом анализа инцидента является определение проблемы, т. е. причины этого инцидента. Одна и та же проблема может стать причиной для нескольких инцидентов одновременно. Вторая линия технической поддержки осуществляет поиск проблемы, сопоставляя инцидент с известными ошибками, возникающими в телекоммуникационной сети.
Для разрешения проблемы и восстановления услуги производятся действия, которые оформляются в виде нарядов на проведение работ. После восстановления работы услуги происходит закрытие инцидента.
Типовые бизнес-процессы устранения неисправностей, как и в случае процессов предоставления новых услуг, декларируются с помощью языка описания бизнес-процессов, и далее управляются и контролируются средствами BPM-системы.
38

На рис. 19 и 20 приведены примеры диаграмм для процесса обработки инцидентов. Как видно на рис. 20, с ростом организационной структуры телеком-оператора и увеличением числа специализированных подразделений, вовлеченных в устранение повреждений, бизнес-процесс существенно усложняется, и выполнение его «вручную», без использования BPMсистем чревато нарушениями порядка работ и срывом обязательств SLA перед абонентами.
Рис. 19. Простой случай процесса обработки инцидента (заявка о неисправности от абонента телеком-оператора SMB-сегмента)
39

40
Рис. 20. Диаграмма сложного бизнес-процесса крупного телекоммуникационного оператора
3.5.Элементы геоинформационных систем (ГИС)
всоставе OSS
ГИС, геоинформационная система – в общем случае это система сбора, хранения, анализа и графической визуализации пространственных (географических) данных и связанной с ними информации о необходимых объектах [37].
В составе OSS для модуля Network Resource Inventory (технического учета) есть непосредственная необходимость наличия функций ГИС применительно к телекоммуникационному оборудованию, размещаемому на местности.
Обычно ГИС в составе NRI отображает геоинформацию о регионе (картографическую подложку), совмещенную с данными о линейно-техни- ческих объектах в виде интерактивного плана города.
Слои ЛТО накладываются поверх слоев картографической подложки (кварталы городской застройки, зеленые насаждения и др.) и отображают расположение объектов на местности, а также связи между ними.
Настольная ГИС, как самостоятельный программный продукт, обладает функциональностью реляционной СУБД и позволяет оперировать произвольной структурой хранения информации об отображаемых объектах. При использовании отдельных ГИС-компонентов для построения OSS, нет необходимости создавать структуру таблиц для слоев: данные уже сохранены в собственной структуре БД OSS. Поэтому для работы функций ГИС необходимо задать соответствие между объектами, отображаемыми в ГИС, и их данными, сохраненными в БД OSS, после чего «перенацелить» ГИС на работу с подключенными данными.
При работе с пространственными данными, используемая для хранения данных СУБД должна поддерживать расширение языка SQL для составления пространственных запросов, а также поддержку специализированных пространственных индексов (чаще всего используются индексы на основе R-деревьев [38] [39], рис. 21). Также, при работе в ГИС часто используются специализированные встроенные языки программирования для выполнения операций над географическими объектами и для настройки внешнего вида отображения карты.
Среди широко распространенных ГИС, работающих с векторными электронными картами, можно выделить семейства продуктов ArcGis (ESRI) [40] и MapInfo (Pitney Bowes) [41]. Каждое из них имеет как самостоятельные программные продукты ГИС, так и компоненты, предназначенные для включения разработчиком в состав других программных продуктов с целью быстрого появления в них ГИС-функций. Также функциональность
41

ГИС нередко добавляется производителями универсальных СУБД как опциональный набор возможностей поставки (в этой нише широко известны
Oracle Spatial, MS SQL Spatial, PostGIS для PostgreSQL и др.)
Рис. 21. Простой пример R-дерева
Встраиваемые ГИС-компоненты позволяют реализовать функции работы с картами внутри специализированной OSS (рис. 22–24). Пользователю нет необходимости получения специальных знаний в области ГИС-систем для использования этих возможностей. Также от пользователя не требуется выполнения сложной процедуры подключения ГИС – вся настройка должна быть выполнена на этапе разработки OSS.
42

Рис. 22. Карта кабельной канализации с фрагментами кабеля в OSS АРГУС
Рис. 23. Пример отображения зоны радиопокрытия антенны DECT
в OSS АРГУС
43

Рис. 24. Фрагмент программного кода на встроенном языке MapInfo MapBasic
44
4.ИНТЕГРАЦИЯ КОМПОНЕНТОВ OSS МЕЖДУ СОБОЙ
ИСО СМЕЖНЫМИ СИСТЕМАМИ АВТОМАТИЗАЦИИ
Ни для кого не секрет, что «уже все сделано до нас». Остается только собрать все фрагменты для решения поставленной задачи. И тут оказывается, что интегрировать разобщенные части не редко сложнее, чем их написать.
Все программисты любят создавать системы с нуля, когда идея может свободно приобретать любые формы. Конечно, сконструированная цельно система, при условии, что ее делал специалист, всегда выглядит монолитно и радует глаз. Но зачастую реальность непостоянна и со временем, любая концептуальная идиллия нарушается в ходе развития бизнеса, изменения процессов, поглощения или слияния предприятий, внедрения новых систем, смены аппаратных или программных платформ и даже законодательства.
Известно, что более двух третей всех усилий уходит на «склейку» несовместимого и попытки «подружить» модули, написанные разными людьми, в разное время, на разных языках и технологиях, под разные платформы.
Ниже представлены основные факторы, влияющие на интеграцию [42]:
ускорение процессов. Постоянное совершенствование и развитие организации требует все чаще и чаще менять структуры данных, бизнеспроцессы, а также дизайн и пользовательские интерфейсы;
распределенность. Организации становятся все более крупными, а решаемые задачи все более комплексными, появляется логическая, организационная и географическая рассредоточенность;
гетерогенность. В крупном проекте почти никогда нет возможности придерживаться платформ и инструментов от одного производителя, поэтому приходится учитывать и поддерживать особенности нескольких платформ;
наследственность. Невозможно полностью отказаться от устаревших технологий, старого аппаратного обеспечения, которые иногда дают вполне хорошие показатели по надежности и производительности, но не способствуют интеграции;
хаотичность. Не всегда имеется возможность полностью формализовать, специфицировать и структурировать данные, и часть модели остается «слабосвязанной», не поддающейся или слабо поддающейся машинной обработке, анализу, индексации;
обусловленность. К сожалению, информационные системы ограничены не только техническими рамками, но и привычками людей (которых сложно переучивать), особенностями законодательства (которое просто не готово к появлению таких систем), множеством других факторов, не зависящих от разработчиков;
45