• управление коммутацией, для чего в зависимости от структуры АТС используются разные методы, но в любом случае центральный процессор хранит отображение всех путей (и свободных, и используемых), находит и резервирует путь для запрашиваемого абонентским или линейным модулем соединения;

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

9.2.2 Иерархическое управление

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

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

9.2.3 Распределенная архитектура

Концепция распределенного программного управления появилась еще в 60 X годах прошлого века и была воплощена в цифровой системе коммутации Е10 (Фртн1 \.\ля) Она предусматривала разбие НИР мио косгпа пдпч упр тле ния на несколько составных частей по

принципу раздоления функции (function shanng) и/или разделения нагрузки (load sharing). Концептуально полностью распределенная архитектура соответствует архитектуре управления в Системе 12 или в АТСЦ-90, которые были рассмотрены, соответственно, в главах 6 и 5. Ее можно также определить как архитектуру без центрального процессора (central-processor-less).

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

9.3 Основы программирования обслуживания вызовов в реальном времени

в наше время нельзя описывать станции автоматической коммутации, не уделяя основного внимания их программному обеспечению - самой сложной (и самой трудоемкой при разработке) части цифровой АТС. Эта сложность обусловлена двумя рассматриваемыми в данной главе составляющими: функциональное наполнение ПО и выполнение задач в реальном времени. Кроме того, в следующей главе 10 мы поговорим о ПО технического обслуживания и административного управления, а в главе 11 - о ПО телекоммуникационных услуг

Для лучшего восприятия излагаемого в этом параграфе материала полезно с самого начала привести следующие цифры. Станционному ПО АТС, обслуживающей 10000 абонентов, необходимо одновременно держать под контролем приблизительно 7000 соединений в фазе разговора плюс 200 соединений в фазе установления/ разрушения плюс 20 транзакций эксплуатационного управления, причом тробоиаиия роального времени ограничивают время откли

ка программного обеспечения для обработки сигнализации интер валом 10 100 мс, для функций обработки вызова интервалом 100 1000 мс, для диалога человек-машина - 1-3 с, для транзакций технической эксплуатации - 1-10 с.

В новых цифровых АТС, например, 5 ESS компании Lucent, DMS-100 компании Nortel, EWSD компании Siemens и др. функционирование ПО в реальном времени отчасти скрыто за их операционными системами, что хотя и упрощает разработку программ для этих систем, но и затемняет реальное понимание работы систем. В ранних системах коммутации с монолитно1;1 nporpaMMHoili apxHTOKTypoili, подобной архитектуре 1 ESS или ИВТУ, поведение программного управления в реальном времени более очевидно. И хотя среда, в которой специалисты должны были разрабатывать ПО первых АТС с управлением по записанной программе, была весьма сложной и не очень комфортной , педагогические возможности объяснить поведение ПО этих АТС в реальном времени намного лучше.

Например, уже рассматривавшийся в главе 6 проект программного управления коммутационной станцией с помощью специализированной электронной управляющей машины «Нева» предусматривал разработку программ для этого компьютера на языке Ассемблера, используя косвенную адресацию, макрокоманды и подпрограммы. Язык высокого уровня не применялся, т.к. хотя Алгол, Кобол и Фортран уже были изобретены, их использование для задач реального времени в системе управления узлом коммутации, да еще на таких «тихоходных» компьютерах, было попросту невозможно. Система команд «Невы» содержала, кроме универсальных команд (сложение, вычитание, логические операции, сдвиги и т.п.), большое количество специализированных команд, обеспечивавших выигрыш времени в процессе обработки вызовов или экономию памяти машины. Так, в группе команд арифметических операций к четырем обычным командам были добавлены часто использовавшиеся команды сложения кода с единицей и вычитание из кода единицы. Логические операции включали в себя логический сдвиг влево и вправо (ЛСД); циклический сдвиг (ЦСЖ); размножение операционного регистра (РМ). Была введена специальная группа операций побитовой обработки информации, содержавшая восемь (а с учетом модификаций - 18) разных по смыслу команд: единица в разряде (РЕ); нуль в разряде (РН); инверсия разряда (РИ); проверка разряда (РП); номер левой единицы (НЕ); номер левой единицы с инверсией (НЕЙ); номер несовпадений в массиве (НИМ) и номер несовпадений с инверсией в массиве (ННИМ).

Можно представить, как непривычно это выглядит сейчас, но для тогдашних программистов, к которым принадлежал и автор этих строк, лагинскии алфавит ограничивался практически шестью бук Н.1ми А В C,D,E,F, нообходимыми для шестнадцатеричнои системы