Современные телекоммуникационные архитектуры и создаваемые для них новые протоколы сигнализации вызвали необходимость в дополнительных языках их спецификаций и описаний: ASN.l (Abstract Syntax Notation One) для протоколов модели Взаимодействия открытых систем (ВОС или OSI в английской аббревиатуре), TTCN (Tree and Tabular Combined Notation) для создания тестовых сценариев при тестировании конформности в рамках телекоммуникационных архитектур, GDMO для информационных моделей в рамках архитектуры TMN и др. Проблемы стандартизации, развития и совместного использование SDL, MSC и этих языков для спецификаций и описаний новых телекоммуникационных

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

А именно, не будет рассматриваться используемая российскими НИИКБ система ГОСТов ЕСКД, традиционно сопровождавшая НИОКР в областях телекоммуникации и вычислительной техники вплоть до присвоения литеры 01 «посмертно» большинству из них и породившая целый ряд трудно объяснимых сегодня силлогизмов типа «калькодержатель» (насилие не только над языком, но и над здравым смыслом). С другой стороны, необходимость стандартизации в электросвязи была осознана еще в 1865 г., когда был основан Международный союз электросвязи -МСЭ (в книге используется и английская аббревиатура этой международной организации - ITU - International Télécommunications Union). В настоящее время ITU является агентством Организации Объединенных Наций и состоит из трех секторов: сектора стандартизации электросвязи (ITU-T), сектора радиосвязи и сектора развития телекоммуникаций.

В области вычислительной техники стандартизация началась со стандартов де-факто и в 50-х годах привела к повсеместному использованию 80-колонных перфокарт в качестве единого для всех систем носителя данных. В 60-х годах была достигнута совместимость накопителей на магнитных лентах и дисках с интерфейсом IBM-360. Затем произошло резкое смещение акцентов на программное обеспечение и наряду со стандартами на операционные системы, программные оболочки и интерфейсы начали разрабатываться стандартные языки спецификаций и описаний. Три из них достигли статуса международных стандартов: SDL, разработанный ITU в 70-х годах, Estelle (IS09074) и LOTOS (IS08807), стандартизованные ISO в 1988 г.

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

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

К необходимости единодушия (правда, не такого) приводит и наблюдающаяся тенденция к интеграции различных телекоммуникационных архитектур. Соответственно возрастает необходимость единообразия нотаций, описывающих различные архитектуры. Впрочем, уже сегодня ни один язык ни в одной архитектуре не используется изолированно. Так, например, TTCN используется совместно с ASN.l, т.к. само тестирование конформности предполагает структуру PDU (Protocol Data Unit), написанную на ASN.l. По совместному использованию SDL и ASN.l уже принята ITU-T рекомендация Z. 105, а по MSC и SDL - рекомендация Z. 120.

Итак, для описаний современных телекоммуникационных архитектур в рамках ITU используются следующие языки: SDL, MSC, ASN.l, TTCN и GDMO. Этот перечень может быть дополнен языком IDL (Interface Définition Language), разрабатываемым OMG (Object Management Group) и ISO, языком ODL (Object Definition Language) из TINA-C, который является расширением IDL и поддерживает современные концепции объектов с разнообразными интерфейсами, групповых объектов, потоковых интерфейсов и описаний QoS (Quality of Service).

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

Существенно также, что перспективные проекты, например, TINA-С, уже не связываются с какими-либо конкретными архитектурами типа TMN или IN. Протоколы взаимодействия в этих проектах в основном выражаются в терминах прикладных программных интерфейсов (API - Application Programm Interface).

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

Одним из основных используемых совместно с SDL языков является ASN.l (Abstract Syntax Notation 1). Он предназначен в основном для спецификации данных и является признанным стандартом для описания данных в протоколах ISO, строящихся в соответствии с моделью взаимодействия - открытых систем (ВОС, или OSI согласно английской аббревиатуре) и рекомендаций ITU-T серии X. Например, ASN.l широко используется в рекомендациях Х.400 и Х.500, при описании протоколов ROSE (Remote Operations: Protocol Specifications, рекомендация Х.229) и ТСАР (Transaction Capabilities, рекомендации Q.771-775 и глава 10 данной книги).

ASN. 1 состоит из двух частей: описания композиционных типов данных и преобразования этих данных в битовые потоки для передачи (правила кодирования/декодирования). Сегодня фактически существуют две модификации языка ASN. 1. Первая модификация определена рекомендацией Х.208, а вторая - рекомендациями Х.680-683, которые должны были заменить Х.208, но до сих пор сосуществуют на равных с ней.

С учетом совместного использования с SDL в контексте данной книги особенно важна рекомендация Z.I 05, основными принципами которой стали следующие тезисы:

• SDL используется для описания поведения и структуры системы, тогда kbkasn. 1 используется для описания данных в дополнение к данным SDL. Данные ASN. 1 используются для спецификации сообщений и порядка их кодирования.

• Версия ASN.l, используемая в Z.I 05, основана на рекомендации Х.680 без расширений, содержащихся в рекомендациях Х.681 -Х.683.

• При совместном использовании необходимо модифицировать и SDL и ASN.l. В SDL наибольшие изменения - это расширения в лексических правилах. Используемый в Z.I 05 язык ASN.l не имеет различий между знаками верхнего и нижнего регистров клавиатуры, и дефис «-» заменяется подчеркиванием «_», что необходимо для обеспечения совместимости этих двух языков.

Значительный интерес представляют графические нотации GDMO (Guidelines for the Definition of Managed Objects).

Эти языковые средства определены рекомендацией Х.722 для описания управляемых объектов в TMN (Telecommunications

Management Network) и также упоминаются в главе 10 данной книги.

Имеет смысл остановиться несколько более подробно на языке современных протокол-тестеров TTCN (Tree and Tabular Combined Notation). Язык комбинированных древовидных и табличных нотаций TTCN был разработан в ISO для абстрактного описания режимов функционирования и обмена сигналами между тестируемой протокольной реализацией и тестирующей системой. Протокол может быть представлен в форме древовидного графа, отображающего реакции нате или иные входные (в частности - тестовые) сигналы. Как следует из названия, язык TTCN использует табличные представления таких деревьев для описания динамики поведения протоколов, а также дополнительные таблицы для записи самих тестовых сценариев.

Тестер представляет собой тестовый комплект, выполняющий тесты и наблюдающий за результатами. TTCN базируется на концепции верхнего и нижнего тестеров. Набор тестирующих компонент, взаимодействующих с тестируемой системой (IUT - Implementation Under Test) в точках управления и наблюдения (РСО - Point of Control and Observation) через интерфейс нижнего уровня, называется нижним тестером (LT - Lower Tester). Набор тестирующих компонент, взаимодействующих с тестируемой реализацией (IUT) в точках управления и наблюдения (РСО) через интерфейс верхнего уровня, называется верхним тестером (UT - Upper Tester).

Система должна содержать по крайней мере одну из тестирующих компонент. Эта компонента будет являться мастер-компонентой (МТС -Master Test Component), ответственной за координацию и управление ходом теста и за вынесение окончательного вердикта. Связь между тестирующими компонентами каждого из тестеров осуществляется через точки координации (СР - Coordination Points). Координация между верхним и нижним тестером осуществляется посредством процедур координации тестирования (TCP - Test Coordination Procedures).

Нижний тестер является более сложным, чем верхний, вследствие необходимости выполнения им функций управления и наблюдения за блоками данных протокола (PDUs - Protocol Data Units). Блоки данных протокола являются частью абстрактных примитивов (ASP - Abstract Service Primitives), которые нижний тестер посылает и принимает во время выполнения теста. Фактически в любой момент времени нижний тестер, исполняя какой-то тест, реализует определенную часть соответствующего протокола.

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

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

Как уже отмечалось выше, TTCN представляет собой нотацию, разработанную для спецификации тестов на абстрактном уровне. Абстрактные тесты содержат всю информацию, необходимую для полной спецификации цели проведения теста (ТР - Test Purpose) в терминах блоков данных протокола, который данная система должна реализовывать в процессе функционирования. Абстрактные тесты не содержат информации, специфичной для конкретной системы. Однако сама нотация как таковая не является абстрактной; определение TTCN достаточно точно, как в части синтаксиса, так и в части семантики операций, что позволяет приблизить TTCN к языку программирования.

На рис. 2.21 показано соответствие TTCN семиуровневой модели взаимодействия открытых систем (OSI), согласно которой требуются спецификации тестов в терминах абстрактных примитивов ASP уровня (N-1), а также в терминах абстрактных примитивов ASP уровня N и блоков данных протокола уровня N. Для того, чтобы удовлетворять таким требованиям, TTCN должен обеспечивать как минимум: возможность спецификации абстрактных примитивов, которые должна принимать или посылать тестируемая система; возможность спецификации блоков данных протокола, которые являются частью абстрактных примитивов; возможность спецификации последовательности, в которой абстрактные примитивы посылаются или принимаются в определенной точке управления и наблюдения (РСО).

Для выполнения перечисленных функций TTCN позволяет:

• декларировать типы абстрактных примитивов и блоков данных протокола;

• декларировать точки контроля и наблюдения;

• специфицировать реальные абстрактные примитивы и блоки данных протокола;

• специфицировать различные варианты поведения системы. Рассмотренные в первом параграфе данной главы методы спецификации протоколов на SDL используют для описания их поведения диаграммы состояний. Однако в связи с тем, что тестирование соответствия

Рис.2.21. Общая архитектура тестирования TTCN

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

В ТТСЫ такое дерево взаимодействий называется деревом поведения. Структура дерева представляется посредством увеличивающихся уровней отступов для показа продвижения по дереву относительно времени (рис. 2.22).

Узел дерева называется линией поведения. Линия поведения содержит следующие компоненты:

• номер линии,

• метку,

• строку описаний,

• ссылку на ограничения,

• вердикт,

• комментарий линии поведения.

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

Рис.2.22. Представление дерева TTCN посредством сдвига Поведение тестируемой системы (например, прием или посылка абстрактных примитивов) описывается при помощи описаний TTCN. Описания бывают трех типов:

• события,

• действия,

• квалификаторы.

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

. RECEIVE,

. OTHERWISE,

⇐Сценарии протоколов сигнализации на языке msc | Сигнализация в сетях связи | Timeout.⇒