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

MSC

instance SIGTEST

1. in SEIZURE

2. out SZ_IND

3. out ACK

setT1’

4. inB_NUMBER

reset Т1’

5. out DIGITS

6. inCONGIN

7. out CONGESTION

setT2'

8. in DISCONNECTION

reset T2'

9. in RLG_IN

10. out RELEASE_GUARD

11. out PASSED

end instance

end MSC

Проведя процедуру слияния (Merge) сценариев рис, 2.17 и 2.19, получаем результ

ирующий сценарий MSC Cong Test.

MSC Cong Test = MSC Cong II MSC Sim

При этом целесообразно ввести момент USER (оператор), описывающий интерфейс с пользователем. Сценарий MSC Cong Test приведен на рис. 2.20.

Рис.2.20. Сценарий проверки обмена сигналами при занятости соединительных путей

Итак, SDL-диаграммы, описанные в предыдущем параграфе, являются источником тестовых последовательностей, представляющих собой набор MSC-сценариев. Именно по набору такого рода сценариев проводится проверка правильности отработки протоколов сигнализации, описанных в книге. Эти же сценарии положены в основу работы протокол-тестеров из главы 11. С помощью этих протокол-тестеров сообщения о сбое в сценарии (получен не тот сигнал, который ожидался, или сигнал не пришел до срабатывания тайм-аута), поступающие оператору, позволяют провести не только проверку, но и отладку указанного программного обеспечения.

2.3. СТАНДАРТИЗАЦИЯ МЕТОДОВ СПЕЦИФИКАЦИИ И ОПИСАНИЯ СОВРЕМЕННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ АРХИТЕКТУР

Современные телекоммуникационные архитектуры и создаваемые для них новые протоколы сигнализации вызвали необходимость в дополнительных языках их спецификаций и описаний: ASN.l (Abstract Syntax Notation One) для протоколов модели Взаимодействия открытых систем (ВОС или OSI в английской аббревиатуре), TTCN (Tree and Tabular Combined Notation) для создания тестовых сценариев при тестировании конформности в рамках телекоммуникационных архитектур, GDMO для информационных моделей в рамках архитектуры ТМN и др. Проблемы стандартизации, развития и совместного использование SDL, MSC и этих языков для спецификаций и описаний новых телекоммуникационных Архитектур составляют предмет настоящего параграф|. — Как уже отмечалось во введении, данный параграф может быть пропущен без ущерба для понимания дальнейшего материала книги. Для читателя, готового, несмотря на сделанное предупреждение, продолжить рассмотрение этой чрезвычайно важной задачи стандартизации методов разработки телекоммуникационных систем, полезно прежде определить, какая стандартизация в этом параграфе рассматриваться не будет.

А именно, не будет рассматриваться используемая российскими НИИКБ система ГОСТов ЕСКД, традиционно сопровождавшая НИОКР в областях телекоммуникации и вычислительной техники вплоть до присвоения литеры 01 «посмертно» большинству из них и породившая целый ряд трудно объяснимых сегодня силлогизмов типа «калькодержатель» (насилие не только над языком, но и над здравым смыслом). С другой стороны, необходимость стандартизации в электросвязи была осознана еще в 1865 г., когда был основан Международный союз электросвязи -МСЭ (в книге используется и английская аббревиатура этой международной организации - ITU - International Telecommunications 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 Definition Language), разрабатываемым OMG (Object Management Group) и ISO, языком ODL (Object Definition Language) из TINA-C, который является расширением IDL и поддерживает современные концепции объектов с разнообразными интерфейсами, групповых объектов, потоковых интерфейсов и описаний QoS (Quality of Service).

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

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

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

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