Сигнализация в сетях железнодорожной связи

Одним из основных используемых совместно с SDL языков является ASN.l (Abstract Syntax Notation 1). Он предназначен в основном для спецификации данных и является признанным стандартом для описания данных в протоколах ISO, строящихся в соответствии с моделью взаимодействия - открытых систем (ВОС, или OSI согласно английской аббревиатуре) и рекомендаций ITU-Т серии 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

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

 Скачать реферат