Проектирование и моделирование телекоммуникационных систем

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

При построении моделей телекоммуникационных сетей и их сегментов сегодня часто используются онтологии — формализация области знаний с помощью концептуальной схемы. Онтологии могут относиться к трем уровням: верхнему (базовые), среднему (онтологии предметной области) и нижнему (онтологии приложений). Онтологии верхнего уровня содержат общие классы, которые затем детализируются в онтологиях предметных областей, при этом классы онтологий предметных областей наследуются от классов общих онтологий. Как правило, онтологии верхнего уровня достаточно компактны и их основное назначение состоит в ликвидации логического разрыва между различными предметными областями, например, онтология GEO позволяет унифицированным образом указывать местоположение объектов. Онтологии среднего уровня предметно-ориентированы (доменные онтологии) и определяют составляющие элементы телекоммуникационных сетей и связи между ними. Примерами таких онтологий являются онтологии TSDO [1] и ToCo. Дополнительные сведения о предметной области размещаются в онтологиях уровня приложения, к которым относится онтология мониторинга телекоммуникационных сетей TNMO [2].

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

Подходы к проектированию прикладных информационных систем

В сфере телекоммуникаций наиболее широко применяются объектно-ориентированный (ООП), модельно-ориентированный (Model Driven Architecture, MDA) и доменно-ориентированный подходы (Domain Driven Design, DDD) к проектированию информационных систем.

ООП

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

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

MDA

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

Стандарт MDA был создан некоммерческим консорциумом OMG [3] и представляет собой мощный инструмент, предусматривающий создание метамодели, описывающей структуру и поведение системы, а также принципы ее построения. Метамодель проектируется в соответствии со стандартом разработки MOF (Meta-Object Facility [4]), которая затем адаптируется под конкретный язык программирования и среду разработки. С одной стороны, у разработчиков появляется четкий план разработки, что позволяет точно спрогнозировать период создания системы, ее тестирования и запуска. С другой, команде предоставляется относительная свобода выбора решений. На рис. 1 представлен многошаговый процесс построения системной модели.

Рис. 1. Процесс построения системной модели

Внедрение методов модельно-ориентированного проектирования в области телекоммуникаций позволяет обеспечить: проработку потенциальных рисков межсистемной интеграции на полнофункциональных моделях; точный анализ временных параметров процессов предоставления услуг потребителям за счет имитации процессов на моделях; снижение рисков отказов системы за счет моделирования различных аварийных ситуаций. Однако, при всех достоинствах MDA, даже модель верхнего уровня, как правило, описывается в терминах конкретной информационной системы, а не предметной области, в результате чего возникает разрыв между информационными моделями систем и бизнес-моделями предметной области, что не позволяет специалистам предметной области работать с моделями. Для устранения этого ограничения был разработан доменно-ориентированный подход.

DDD

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

Использование DDD при проектировании сложных информационных систем позволяет упростить процессы внесения изменений в системы и повысить эффективность тестирования новых версий. При проектировании небольших и несложных программных систем применение DDD нецелесообразно.

DDD имеет много общего с MDA — оба подхода требуют использовать модели для описания предметных областей, при этом модели не должны зависеть от платформ, на которых они реализуются. В этом смысле MDA можно рассматривать как подход, который предоставляет средства для применения DDD на практике: методы моделирования предметной области, предметно-ориентированные языки (Domain-Specific Language, DSL) и пр., облегчающие общение между экспертами в предметной области и разработчиками. Кроме того, DDD позволяет построить модель предметной области, включающую описание ее структуры, правил поведения, динамики и т. д., а MDA предоставляет инструменты для преобразования моделей и генерации кода.

Референтные модели для проектирования телекоммуникационных систем

TMF вносит существенный вклад в развитие и оптимизацию бизнес-процессов операторов связи, занимаясь, в частности, построением систем поддержки операционной деятельности и бизнеса (Operation Support System/Business Support System, OSS/BSS), а также стандартизацией управления сетями связи. Применение моделей и использование разрабатываемых TMF стандартов позволяет операторам повысить эффективность работы за счет оптимизации бизнес-процессов, а также перейти к более эффективной ИТ-архитектуре, разработать и внедрить единую информационную модель, упрощающую взаимодействие с поставщиками информационных систем и облегчающую интеграцию с уже существующими системами. TMF предоставляет набор фреймворков для создания моделей телекоммуникационных систем: процессный (Enhanced Telecom Operations Map, eTOM); информационный (Shared Information & Data Model, SID); функциональный; приложений (Telecom Application Map, TAM).

Процессный фреймворк описывает многоуровневую эталонную модель бизнес-процессов — базу для анализа и проектирования бизнес-процессов в отрасли связи и ориентир при проектировании и разработке решений OSS/BSS.

Информационный фреймворк предоставляет модель данных, которая используется при реализации бизнес-процессов. Информационная модель не зависит от платформы, языка программирования или протокола и позволяет описывать бизнес-объекты, важные для поставщика услуг связи. При описании бизнес-объектов используется понятие агрегированных бизнес-объектов (Aggregated Business Entity, ABE). Информационная модель — основа для построения общей модели данных и общего словаря, используемых при разработке функций, компонентов и API телекоммуникационных систем.

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

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

Рис. 2. Фреймворк бизнес-процессов

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

В качестве контекстов рассматриваются: «Операционные процессы» (Operations), к которым отнесены процессы «Выполнение» (Fulfilment), «Гарантия» (Assurance) и «Выставление счетов» (Billing and Revenue Management), а также процессы «Операционная готовность и поддержка» (Operations Readiness & Support). За пределами области «Operations», в области процессов «От стратегии до готовности» (Strategy to Readiness), различают процессы «Управление стратегией» (Strategy Management), а также «Предоставление возможностей» (Capability Management) и «Управление жизненным циклом» (Business Value Development). Бизнес-циклы этих процессов существенно отличаются от циклов операционных процессов. Кроме того, процессы «Operations», в отличие от процессов «Strategy to Readiness», не поддерживают процессы, ориентированные на непосредственное взаимодействие с клиентами.

Фреймворк бизнес-процессов

Фреймворк eTOM предоставляет многократно используемые элементы процессов, позволяющие создавать конкретные процессы для реализации различных целей операторов связи. Значительная часть таких процессов определена на основе лучших практик. Модель бизнес-процессов — это эталонная модель для категоризации всех бизнес-операций, которые используются поставщиком услуг. На рис. 2 показаны процессы, необходимые для поддержки клиентов и управления бизнесом. Горизонтальные группы процессов определяются в соответствии с доменами. Пересечение доменов и контекстных вертикалей определяет внутреннюю матричную модель, которая составляет ядро фреймворка.

Рис. 3. Бизнес-процессы, лежащие на пересечении вертикального контекста первого уровня «Исполнение» и горизонтального домена клиента

На рис. 3 показаны бизнес-процессы, лежащие на пересечении вертикального контекста первого уровня «Операционные процессы» и горизонтального домена клиента. Создаваемые с помощью фреймворка процессы могут описываться в формате XML, MDB, электронных таблиц Excel. В результате создаваемые процессы понятны как бизнес-специалистам, так и разработчикам процессов. Модель eTOM имеет четырехуровневую структуру. На нулевом уровне выделяются три основные области бизнес-процессов: «Операционные процессы» (OPS), «Стратегия, инфраструктура и продукт» (SIP) и «Управление предприятием» (EM). На первом, втором и третьем уровнях детализируются процессы, определенные на нулевом уровне, — чем выше номер, тем более детально описываются элементы процессов.

Информационный фреймворк

Фреймворк обеспечивает использование общих понятий и общей информационной модели. Понятия определяют бизнес-сущности предметной области и связанные с ними характеристики. Бизнес-сущности описывают объекты, которые представляют интерес для бизнеса, а атрибуты сущностей соответствуют характеристикам объектов. Совокупность понятий составляет основу для построения информационной модели, которая представляется в виде диаграмм классов UML. Фреймворк SID разрабатывался путем анализа процессов и данных организаций, работающих в сфере предоставления телекоммуникационных услуг. Информационная модель имеет многоуровневую структуру и может использоваться как классификатор элементов информационного пространства. Агрегированные бизнес-объекты, являющиеся элементами информационной модели, включают четко определенный набор данных, для каждого объекта определены операции, которые могут над ним выполняться. В качестве примера на рис. 4 приведены агрегированные бизнес-объекты для домена клиента.

Рис. 4. Агрегированные бизнес-объекты домена клиента

Фреймворк может рассматриваться как организационная модель, в которой размещаются бизнес-объекты. Домены, рассматриваемые при построении информационной модели, согласуются с доменами первого уровня фреймворка бизнес-процессов. Таким образом, один и тот же набор понятий используется как при работе с процессами, так и при работе с данными.

Функциональный фреймворк

Функциональный фреймворк позволяет строить функциональные модели, связанные с моделями бизнес-процессов и информационными моделями: каждая функция из функциональной модели используется при реализации одного или нескольких процессов из модели бизнес-процессов; для реализации каждого процесса может потребоваться выполнение одной или нескольких функций, при этом в рамках процессов определяется порядок выполнения функций; в результате выполнения функций могут создаваться один или несколько ABE/BE из информационной модели, каждый ABE/BE создается уникальной функцией.

Рис. 5. Функции первого уровня, лежащие на пересечении вертикального контекста первого уровня «Исполнение» и горизонтального домена клиента

Создание и использование функциональной модели позволяют избегать дублирования функций и выявлять отсутствующие. Домены, используемые в функциональном фреймворке, согласуются с горизонтальными доменами первого уровня фреймворка процессов и информационного фреймворка. На рис. 5 показаны функции первого уровня, лежащие на пересечении вертикального контекста первого уровня «Операционные процессы» и горизонтального домена клиента.

Регистрация заявки на подключение услуги

Рис. A. Модель регистрации заявки на подключение услуги, разработанная с использованием фреймворков TMF

Модель регистрации заявки на подключение услуги (рис. A) строится с помощью следующих фреймворков: eTOM: домен клиента. Вертикальный контекст первого уровня «Операционные процессы», второго уровня — «Выполнение». Бизнес-процесс — «Обработка заказов»; SID: ABE из информационной модели — «Заявка клиента на подключение услуги»; функциональный фреймворк — функция «Регистрация заявки клиента».

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

Онтологические модели телекоммуникационных сетей

Онтологии используются как словарь, который описывает определенную предметную область в виде набора классов и отношений между ними. Основная цель онтологий — обмен знаниями и их повторное использование. Для домена телекоммуникаций онтологии применяются для описания множества сетевых узлов и связей между ними: коммутаторов, маршрутизаторов, устройств хранения, конечных пользовательских устройств. Для телекоммуникационных сетей разработано несколько онтологий:

• NDL (Network Description Language — язык описания сети) — основанная на RDF онтология для гибридных сетей, которая обеспечивает описание, визуализацию и предоставление данных о связях между элементами сети. NDL содержит схемы для описания независимой от применяемых технологий топологии гибридных сетей и их компонентов на различных технологических уровнях;
• TSDO (Telecommunications Service Domain Ontology — доменная онтология телекоммуникационных сервисов) — понятия концепции и отношения для описания знаний о домене телекоммуникационных услуг и описания функциональных и нефункциональных возможностей телекоммуникационных сетей;
• онтология беспроводных сетей 3G, разработанная для конфигурации транспорта беспроводных сетей и включающая две субонтологии (онтологию предметной области и онтологию решаемых задач);
• мобильная онтология, предоставляющая возможность реструктурировать онтологии — это масштабируемое решение с несколькими подключаемыми субонтологиями (сервисов, профилей пользователей, контента, сущностей, контекста, коммуникационных ресурсов);
• OOTN (Ontology for Optical Transport Networks — онтология для оптических транспортных сетей) — это низкоуровневая онтология, построенная в соответствии с рекомендациями ITU-T G.805 и G.872;
• онтология, принятая в «OpenMobileNetwork», — связанный открытый набор данных о мобильных сетях и устройствах;
• онтология ToCo (TOUCAN Ontology) — одна из современных онтологий домена телекоммуникационных сетей, позволяющая описывать физическую инфраструктуру сетей, качество каналов связи, услуги и пользователей в разнородных телекоммуникационных сетях [5];
• TNMO (Telecommunication Networks Monitoring Ontology — онтология мониторинга телекоммуникационных сетей) — онтология уровня приложений, разработанная как расширение доменных онтологий телекоммуникационных сетей (TSDO и ToCo) для целей проектирования систем мониторинга на основе графов знаний.

Рис. 6. Структура онтологии ToCo

Для построения моделей сегментов сетей обычно используются доменные онтологии предметной области телекоммуникационных сетей (TSDO, ToCo), которые могут дополняться онтологиями уровня приложения, например, может использоваться TNMO, включающая перечни типов элементов сетей с указанием их параметров и позволяющая описывать происходящие в сети события. В качестве примера на рис. 6 показана общая структура доменной онтологии ToCo, которая состоит из следующих модулей: Device (Устройства), Interface (Интерфейсы), Link (Связи), User (Пользоатели), Data (Данные) и Service (Сервисы).

Интеграция моделей

Рис. 7. Структура онтологической модели оператора связи и онтологических моделей, описывающих модели TMF

Интеграция онтологических моделей телекоммуникационных сетей с моделями TMF возможна путем формирования их онтологического описания. На рис. 7 показана предлагаемая с труктура онтологической модели оператора связи.

Онтологическая модель на основе фреймворков TMF

Рис. А. Онтологическая модель процесса «Обработка заказов» на момент создания новой заявки

В рамках реализации бизнес-процесса «Обработка заказов» при регистрации и выполнении заявки на подключение телекоммуникационного сервиса на момент создания новой заявки выполняется функция «Регистрация заявки». Данные для заявки размещаются в объекте ABE «Заявка на подключение». Заявка обрабатывается на сервере приложений Application #1 компонентом Component #1. Показатели качества выполнения регистрации заявки определяются в классе онтологии «Показатели качества обработки заявки и предоставляемого сервиса», в рассматриваемом примере показатель — время выполнения, значение N минут (рис. А).

Рис. Б. Онтологическая модель процесса «Обработка заказов» на момент проверки показателей качества предоставляемого сервиса

На рис. Б приведена онтологическая модель того же процесса, но на момент проверки показателей качества предоставляемого сервиса (Telecom service #1). Показатели качества определены в классе «Показатели качества обработки заявки и предоставляемого сервиса», в данном случае — это доступность сервиса, которая составляет 99,999%.

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

***

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

Литература

1. X. Li, H. Peng, Y. Li, X. Qiao. Research on Constructing Telecom Services Domain Ontology // 2010 International Conference on Computational Intelligence and Software Engineering, Wuhan, China, 2010, pp. 1–4.DOI: 10.1109/CISE.2010.5677112

2. Kulikov I., Vodyaho A., Stankova E., Zhukova N. Ontology for Knowledge Graphs of Telecommunication Network Monitoring Systems // Gervasi O. et al. (eds) Computational Science and Its Applications — ICCSA 2021. ICCSA 2021. Lecture Notes in Computer Science, vol 12956. Springer, Cham. DOI: 10.1007/978-3-030-87010-2_32

3. Наталья Дубова. Хороший стандарт — незаметный стандарт // Открытые системы.СУБД. — 2010. — № 9. — С. 38–41. URL: www.osp.ru/os/2010/09/13005730 (дата обращения: 21.09.2023).

4. Что такое OMG-UML и почему он важен // Открытые системы.СУБД. — 1999. — № 1. — С. 58–60. URL: https://www.osp.ru/os/1999/01/179653 (дата обращения: 21.09.2023).

5. Zhou, Qianru & Gray, Alasdair & Stephen, McLaughlin. ToCo: An Ontology for Representing Hybrid Telecommunication Networks. DOI: 10.1007/978-3-030-21348-0_33

Наталия Жукова (nazhukova@mail.ru) — доцент, СПбГУ, Александр Водяхо (aivodyaho@mail.ru) — профессор, Игорь Куликов (i.a.kulikov@gmail.com) — соискатель, Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» (Санкт-Петербург).

DOI: 10.51793/OS.2023.87.18.001