Програмне забезпечення. Ієрархічне керування

Программное обеспечение коммутационных узлов и станций

Приведенный в эпиграфе ответ Евклида справедлив по отношению не только к геометрии, но и к программному обеспечению (ПО) узлов коммутации, изучение которого требует сложных и глубоких курсов гораздо большего объема, чем может вместить одна глава учебника. К тому же, на ПО приходится более 80% стоимости разработки современной АТС, и оно практически полностью определяет ее функциональные возможности. Вот почему эта глава оказалась для автора самой сложной с точки зрения того, как ее построить. В результате получилась такая структура: следующий параграф посвящен аппаратной поддержке ПО узла коммутации и анализу разных вариантов ее архитектуры; далее рассмотрены основы программирования задач обслуживания вызовов в реальном времени, элементы алгоритмического обеспечения на языках SDL и MSC и качественные характеристики ПО.

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

Самый нижний уровень ПО обычно встраивается в абонентские и линейные комплекты и другие модули станции. Программные средства на этом уровне, как правило, зависимы от аппаратных средств и в англоязычной литературе называются middleware, что подчеркивает их промежуточное положение между аппаратными средствами hardware и основным программным обеспечением software. Реализуемые здесь функции связаны, в основном, с контроллерами линейных и станционных интерфейсов и с поддержкой нижнего уровня обработки вызова. Например, когда абонент поднимает трубку, первый уровень управления абонентским модулем детектирует состояние снятия трубки (off hook) и запрашивает у контроллера второго уровня информацию о данной абонентской линии, классе ее обслуживания, возможностях абонентского терминала, каких-либо ограничениях. Затем первый уровень обеспечивает посылку абоненту сигнала ответа станции. После набора номера накопленные первым уровнем цифры передаются выше.

Второй уровень управления обычно реализуют процессоры управления коммутацией с распределенными функциями, взаимодействующие друг с другом через коммутационное поле или через общую шину. Для межпроцессорных связей используют разнообразные протоколы, причем в большинстве цифровых АТС применяются модификации стандартных протоколов ОКС7 или Х.25. Основные процессоры управления коммутационным полем для надежности дублируются. На этом уровне анализируются набранные абонентом цифры и выбирается путь через коммутационное поле. После того как соединение установлено, второй уровень управления поддерживает его и разрушает, как только обслуживание вызова переходит в фазу разъединения.

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

Управляющие устройства

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

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

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

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

 

Якість програмного забезпечення

Качество ПО

Наибольшую популярность приобрели некоторое время назад численные оценки качества программ, предложенные Хол-стедом. Согласно предложенной им метрике, длина программы N=ri₁log2r|₁+Ti₂log2ri₂, гдет), -число простых операторов, аг|₂-число простых операндов в программе. Развитию этой программометри-ки были посвящены сотни публикаций, а применительно к программному управлению узлами коммутации интересные результаты получены в [10].

В практической же области в настоящее время используются иные модели оценки качества ПО, из которых мы упомянем две - одну, предложенную Институтом разработки программного обеспечения (SEI) университета Карнеги Меллона и называемую моделью мандатной зрелости (СММ), и другую, разработанную ISO (ТС-176). Обе модели поддерживают процесс сертификации организаций-разработчиков программного обеспечения. Полезная с педагогической точки зрения, модель мандатной зрелости СММ оперирует пятью уровнями зрелости процесса разработки ПО.

Первый уровень называют начальным (initial level). Он соответствует ситуации, когда процесс разработки ПО не организован, и разработка основана только на индивидуальных качествах, грамотности и опыте программистов.

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

Третий уровень называется уровнем определенности (defined level). Это означает, что процесс проектирования ПО хорошо определен и документируется. Он включает в себя стандарты и процедуры выполнения работы, устойчивые и повторяемые элементы, общее понимание целевой функции ПО, сквозной контроль и критерии завершения.

Четвертый уровень называется уровнем управляемости (managed level) и предполагает, что качество процесса проектирования ПО, как и качество продукта, в определенной степени предсказуемо. Процесс этого уровня является устойчивым, измеряемым и корректируемым, что дает возможность влиять на качество продукта.

Последний, пятый уровень называется уровнем оптимизации (optimizing level). На этом уровне реализуется программа непрерывной модернизации, используются профилактические методики, которые сокращают время разработки и повышают качество ПО, применяются новые приемы и методики, направленные на постоянное улучшение процесса разработки и, следовательно, качества продукта.

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

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

На рис. 9.8 показана технология проектирования телекоммуникационного ПО, соответствующая приведенным в этом параграфе принципам обеспечения качества ПО.

 

Рис. 9.8. Технология разработки телекоммуникационного ПО