Программное управление
Египетский царь Птолемей I спросил Евклида:
— Как побыстрее познать геометрию?
— Царских путей в геометрию нет.
— ответил Евклид.
9.1. Программное обеспечение коммутационных узлов и станций
Приведенный в эпиграфе ответ Евклида справедлив по отношению не только к геометрии, но и к программному обеспечению (ПО) узлов коммутации, изучение которого требует сложных и глубоких курсов гораздо большего объема, чем может вместить одна глава учебника. К тому же, на ПО приходится более 80% стоимости разработки современной АТС, и оно практически полностью определяет ее функциональные возможности. Вот почему эта глава оказалась для автора самой сложной с точки зрения того, как ее построить. В результате получилась такая структура: следующий параграф посвящен аппаратной поддержке ПО узла коммутации и анализу разных вариантов ее архитектуры; далее рассмотрены основы программирования задач обслуживания вызовов в реальном времени, элементы алгоритмического обеспечения на языках SDL и МSС и качественные характеристики ПО.
Вместе с тем, в этом подходе к структуре главы учитывается то обстоятельство, что современные средства программного управления коммутацией подразделяются даже не на два, а на три уровня.
Самый нижний уровень ПО обычно встраивается в абонентские и линейные комплекты и другие модули станции. Программные средства на этом уровне, как правило, зависимы от аппаратных средств и в язычной литературе называются middleware, что подчеркивает их промежуточное положение между аппаратными средствами hardware и основным программным обеспечением software. Реализуемые здесь функции связаны, в основном, с контроллерами линейных и станционных интерфейсов и с поддержкой нижнего уровня обработки вызова. Например, когда абонент поднимает трубку, первый уровень управления абонентским модулем детектирует состояние снятия трубки (off hook) и запрашивает у контроллера второго уровня информацию о данной абонентской линии, классе ее обслуживания, возможностях абонентского терминала, каких-либо ограничениях. Затем первый уровень обеспечивает посылку абоненту сигнала ответа станции. После набора номера накопленные первым уровнем цифры передаются выше.
Второй уровень управления обычно реализуют процессоры управления коммутацией с распределенными функциями, взаимодействующие друг с другом через коммутационное поле или через общую шину. Для межпроцессорных связей используют разнообразные протоколы, причем в большинстве цифровых АТС применяются модификации стандартных протоколов ОКС7 или Х.25. Основные процессоры управления коммутационным полем для надежности дублируются. На этом уровне анализируются набранные абонентом цифры и выбирается путь через коммутационное поле. После того как соединение установлено, второй уровень управления поддерживает его и разрушает, как только обслуживание вызова переходит в фазу разъединения.
Третий уровень управления обычно бывает связан с центральным процессором цифровой АТС, выполняющим функции технического обслуживания, конфигурации, администрирования, статистики и начисления платы. Раньше на этом уровне применяли мэйнфреймы, в которые встраивались базовые управляющие функции цифровой системы коммутации, но программное обеспечение АТС более поздних типов тяготеет к полностью распределенной архитектуре и предоставляет больше автономии двум первым уровням управления. Рассмотрим эти варианты архитектуры несколько подробнее.
Описанию различных вариантов организации устройств программного управления коммутацией в недавнем прошлом было посвящено немало публикаций, объем которых постепенно уменьшался по мере качественного изменения самих этих устройств в полном соответствии с законом Мура. Описываемое этим законом снижение стоимости микропроцессорных управляющих устройств одновременно с радикальным увеличением их производительности погасило былые споры между сторонниками централизованной и распределенной архитектур программного управления и привело к тому, что в большинстве современных цифровых АТС используется архитектура, представляющая собой что-то среднее между двумя названными подходами. Сегодняшние варианты архитектуры управления цифровой коммутацией можно разделить на три типа: централизованное управление, иерархическое управление и распределенное управление.
9.2.1. Централизованное управление
Архитектура централизованного управления условно изображена на рис. 9.1. Эта архитектура восходит к началу сорокалетней истории развития электронных узлов коммутации, управляемых ЭВМ, которая началась в ноябре 1960 года в г. Морис (штат Иллинойс, США) испытаниями прототипа электронной АТС. В 1965 году в г. Саккасана (Нью-Джерси, США) была сдана в эксплуатацию серийная электронная система коммутации ESS-1 с управлением по записанной программе, базирующаяся исключительно на центральном процессоре, который управляет всеми функциями системы. Отечественный ИВТУ, рассмотренный в главе 6, полностью соответствует структуре, показанной на рис. 9.1.
Централизованное программное управление этих АТС предусматривает выполнение следующих трех групп функций:
• управление обслуживанием вызова, включая анализ имеющейся в базе данных информации, относящейся к вызываемому абоненту, прием набираемого номера, контроль процесса обслуживания вызова во всех фазах этого процесса, включая фазы отбоя и разъединена;
• управление коммутацией, для чего в зависимости от структуры АТС используются разные методы, но в любом случае центральный процессор хранит отображение всех путей (и свободных, и используемых), находит и резервирует путь для запрашиваемого абонентским или линейным модулем соединения;
• контроль, диагностика неисправностей и восстановление рабочей конфигурации системы, что обсуждается в следующей главе. Здесь отметим лишь, что при централизованном управлении центральный процессор управляет, наряду с коммутацией, и функциями технического обслуживания, административного управления, контроля, диагностики и восстановления системы, для чего он должен обладать достаточной вычислительной мощностью.
9.2.2. Иерархическое управление
Архитектура иерархического управления отличается от архитектуры, приведенной на рис. 9.1, тем, что она предусматривает не один, а несколько периферийных процессоров, которые оказывают помощь центральному процессору, беря на себя функции управления отдельными периферийными подсистемами станции (абонентскими модулями, модулями соединительных линий и др.). Периферийные процессоры обычно представляют собой микропроцессорные устройства, управляющие каждый своей подсистемой. Они сканируют линии, запрашивают информацию от центрального процессора и передают ему данные, нужные для обновления абонентской базы данных и для управления соединениями, тогда центральный процессор выполняет основные функции обработки вызовов и управления коммутационным узлом в целом и несет при этом меньшую нагрузку, чем тот же процессор в архитектуре централизованного управления. В результате, как правило, пропускная способность управляющей системы увеличивается.
Определенный недостаток этой архитектуры — ограниченная масштабируемость управляющего комплекса по мере роста емкости АТС: ведь, как и в архитектуре централизованного управления, вся обработка вызовов централизована. Кроме того, восстановление системы в случае сбоя полностью зависит от центрального процессора. Он же обрабатывает и в информацию, связанную с начислением платы за услуги связи.
9.2.3. Распределенная архитектура
Концепция распределенного программного управления появилась еще в 60-х годах прошлого века и была воплощена в цифровой системе коммутации Е10 (Франция). Она предусматривала разбиение множества задач управления на несколько составных частей по принципу разделения функций (function sharing) и/или разделения нагрузки (load sharing). Концептуально полностью распределенная архитектура соответствует архитектуре управления в Системе 12 или в DX-200, которые были рассмотрены, соответственно, в главах 6 и 5. Ее можно также определить как архитектуру без центрального процессора (central-processor-less).
Все функции управления разделяются на специализированные наборы задач, содержащиеся в независимых процессорах и обеспечивающие в совокупности выполнение всех связанных с управлением операций. К примеру, процессор абонентской ступени периодически (с интервалом порядка 10 мсек) сканирует абонентские линии, включенные в эту ступень, отслеживает все возникающие в ней вызовы, поддерживает базу данных абонентов, ведет наблюдение за каждым вызовом и даже проводит локальное восстановление и локальную диагностику своей схемы. Все процессоры общаются друг с другом путем обмена сообщениями через коммутационное поле, общую шину или иным способом — и это является основой конструкции системы программного управления узлом коммутации. Что же касается задачи обеспечить работу всех этих процессов в реальном времени, то даже с приходом гораздо более быстродействующих процессоров, усовершенствованных протоколов обмена сообщениями и улучшенных архитектурных средств актуальность этой проблематики не становится меньшей, о чем будет идти речь в следующем параграфе — да и не только в нем.
9.3. Основы программирования обслуживания вызовов в реальном времени
В наше время нельзя описывать станции автоматической коммутации, не уделяя основного внимания их программному обеспечению — самой сложной (и самой трудоемкой при разработке) части цифровой АТС. Эта сложность обусловлена двумя рассматриваемыми в данной главе составляющими: функциональное наполнение ПО и выполнение задач в реальном времени. Кроме того, в следующей главе 10 мы поговорим о ПО технического обслуживания и административного управления, а в главе 11 — о ПО телекоммуникационных услуг.
Для лучшего восприятия излагаемого в этом параграфе материала полезно с самого начала привести следующие цифры. Станционному ПО АТС, обслуживающей 10000 абонентов, необходимо одновременно держать под контролем приблизительно 1000 соединений в фазе разговора плюс 200 соединений в фазе установления/разрушения плюс 20 транзакций эксплуатационного управления, причем требования реального времени ограничивают время отклика программного обеспечения для обработки сигнализации интервалом 10 — 100 мс, для функций обработки вызова — интервалом 100 — 1000 мс, для диалога человек-машина — 1 — 3 с, для транзакций технической эксплуатации — 1 — 10 с.
В новых цифровых АТС, например, 5ESS компании Lucent, DMS-100 компании Nortel, EWSD компании Siemens и др. функционирование ПО в реальном времени отчасти скрыто за их операционными системами, что хотя и упрощает разработку программ для этих систем, но и затемняет реальное понимание работы систем. В ранних системами коммутации с монолитной программной архитектурой, подобной архитектуре 1ESS или ИВТУ, поведение программного управления в реальном времени более очевидно. И хотя среда, в которой специалисты должны были разрабатывать ПО первых АТС с управлением по записанной программе, была весьма сложной и не очень комфортной, педагогические возможности объяснить поведение ПО этих АТС в реальном времени намного лучше.
Например, уже рассматривавшийся в главе 6 проект программного управления коммутационной станцией с помощью специализированной электронной управляющей машины «Нева» предусматривал разработку программ для этого компьютера на языке Ассемблера, используя косвенную адресацию, макрокоманды и подпрограммы. Язык высокого уровня не применялся, т.к. хотя Алгол, Кобол и Фортран уже были изобретены, их использование для задач реального времени в системе управления узлом коммутации, да еще на таких «тихоходных» компьютерах, было попросту невозможно. Система команд «Невы» содержала, кроме универсальных команд (сложение, вычитание, логические операции, сдвиги и т.п.), большое количество специализированных команд, обеспечивавших выигрыш времени в процессе обработки вызовов или экономию памяти машины. Так, в группе команд арифметических операций к четырем обычным командам были добавлены часто использовавшиеся команды сложения кода с единицей и вычитание из кода единицы.
Логические операции включали в себя логический сдвиг влево и вправо (ЛСД); циклический сдвиг (ЦСЖ); размножение операционного регистра (РМ). Была введена специальная группа операций побитовой обработки информации, содержавшая восемь (а с учетом модификаций — 18) разных по смыслу команд: единица в разряде (РЕ); нуль в разряде (РН); инверсия разряда (РИ); проверка разряда (РП); номер левой единицы (НЕ); номер левой единицы с инверсией (НЕИ); номер несовпадений в массиве (ННМ) и номер не совпадений с инверсией в массиве (ННИМ). Можно представить себе, как непривычно это выглядит сейчас, но для тогдашних программистов, к которым принадлежал и автор этих строк, латинский алфавит ограничивался практически шестью буквами А, В,С,D,Е,F, необходимыми для шестнадцатеричной системы счисления, а мнемоника ассемблерных команд вполне привычно сочеталась с кириллицей.
К этим ассемблерным командам относились также операции ассоциативного поиска, содержавшие две команды поиска в упорядоченном и в неупорядоченном массивах. Операции с циклическими массивами и команды системы прерывания («возбудить сигнал прерывания», «гасить сигнал», «маскировать сигнал», «демаскировать сигнал», «есть прерывание», «нет прерывания» и «конец программы») как раз и обеспечивали специфику обслуживания вызовов в реальном времени.
Для управляемого ЭУМ «Нева» импульсно-временного транзитного узла ИВТУ, также рассмотренного в главе 6, был выбран единый цикл сканирования всех комплектов, равный 10 мс. Результаты сканирования использовались для формирования очередей к программам обработки вызовов. При этом смысловое содержание вводимой из периферийных управляющих устройств (ПУУ) информации определялось по таблицам решений, которые составлялись для всех типов АТС, связанных с ИВТУ, и в которых учитывались способ передачи сигналов, скорость этой передачи и ряд других факторов. Проблемы реального времени обусловили разработку специализированной телефонной операционной системы (ТОС), основной частью которой являлась подсистема приоритетного обслуживания, определявшая последовательность вызова программ, к которым в данный момент имеются запросы. Все программы были распределены по абсолютным и относительным уровням приоритета. При этом программы сканирования и ввода вызывались на нулевом (высшем) уровне приоритета по расписанию, т.е. через за данные интервалы времени. Система приоритетного обслуживания проектировалась таким образом, чтобы, с одной стороны, обеспечить необходимую последовательность выполнения отдельных программ и, с другой, — сократить до минимума затраты времени на переключение программ, а вместе с тем и минимизировать объем памяти, необходимой для хранения отложенных программ.
Система прерывания содержала поле для запоминания сигналов прерывания, делившихся на 17 абсолютных приоритетных уровней, из которых наивысшим приоритетным уровнем обладал единственный аппаратный уровень; остальные 16 были программными. На каждом из абсолютных приоритетных уровней было предусмотрено до 256 относительных приоритетов, которые не вызывали прерывания текущих программ, но определяли порядок обслуживания программ данного уровня. Для определения оптимального числа уровней прерывания, распределения всех программ по абсолютным и относительным приоритетным уровням, определения размеров циклических массивов очередей заявок и решения других задач телефонной операционной системы последняя должна была быть тщательно рассчитана и оптимизирована, так как от этого зависела правильность распределения ресурсов управляющего компьютера и, в первую очередь, использование ресурса времени центрального процессора. Оптимизация телефонной операционной системы производилась с помощью разработанных автором математического аппарата и инженерных методов расчета и оптимизации приоритетного обслуживания программ [47].
Концептуально иные подходы к решению тех же задач программирования в реальном времени были разработаны для архитектуры программного обеспечения 1ESS. Время выполнения программ в процессоре 1ESS распределяется между классами программ, которые отвечают за ввод/вывод с запуском от таймера, обработку вызовов и техническое обслуживание системы. Распределение времени процессора между этими тремя классами программ весьма подробно рассмотрено в книге Р Томпсона [200]. Там указано, что сканирование свободных абонентских линий в 1ESS производится каждые 100 мс, и что такая частота вызовов соответствует, в среднем, одному новому вызову во временном интервале опроса при интенсивности потока вызовов, составляющей 36000 вызовов в ЧНН. Если бы эти вызовы были распределены во времени строго равномерно (что невероятно), распределение рабочего времени процессора между тремя классами программ в интервале, равном 1 минуте, было бы гладким, равномерным и неизменным. В реальных условиях поток вызовов имеет случайный характер, а распределение рабочего времени процессора определяет усредненная величина — интенсивность нагрузки.
На рис. 9.2 показано, как распределяется между тремя классами программ рабочее время процессора в зависимости от интенсивности телефонной нагрузки в системе. На оси у показано рабочее время процессора, а на о сих — интенсивность телефонной нагрузки в системе. В левой стороне рис. 9.2 состояние системы соответствует 3 часам ночи, когда телефонная нагрузка практически равна О. В правой стороне рисунка состояние системы соответствует часам наибольшей нагрузки, когда процессор с ней едва справляется. Цифры на рис. 9.2 условны, для простоты предполагается, что распределение рабочего времени процессора является линейной функцией интенсивности нагрузки.
Программы опроса спланированы на выполнение с постоянной частотой. Но исполнение программы, которая ищет и находит заявку, занимает больше рабочего времени процессора, чем исполнение той же программы, когда она ищет заявку и не находит ее. Предположим, что программы опроса расходую от 40% рабочего времени процессора именно на вспомогательные действия, связанные с поиском заявок — сканирование датчиков состояния снятия трубки, изменений во внутренних буферах контроля, сигналов от таймера и пр. В левой части рис. 9.2, которая соответствует нулевой телефонной нагрузке и отсутствию заявок, общее рабочее время процессора складывается только из времени опроса. Предположим, что программы опроса расходуют на каждое исполнение, в среднем, на 50% больше рабочего времени процессора при телефонной нагрузке чем на их же исполнение при телефонной нагрузке О. В таком случае рабочее время процессора, выделяемое программам опроса, в правой части рис. 9.2 возрастает до 60%.
Расходование 40-60% рабочего времени только на поиск заявок может показаться неэффективным. Но лучшим показателем эффективности служит рабочее время процессора, затрачиваемое на обслуживание найденной заявки. Пусть n — среднее число заявок, найденных программами опроса в типовом 5-миллисекундном интервале времени. Если нагрузка мала, программы опроса расходуют 2 миллисекунды (40%) из 5 миллисекунд интервала и, возможно;. находят только n=1 заявку. На одну найденную заявку расходуется 2 мс. Если нагрузка большая, программы опроса расходуют 3 мс (60%) из 5 миллисекунд интервала, но могут найти и n=60,заявок. На одну найденную заявку, в среднем, израсходуется 0.05 мс. В.том случае, когда ввод/вывод запускается прерыванием, и на каждое прерывание расходуется дополнительно 0.1 мс рабочего времени, одна задача расходует 0.1 мс, а 60 задач расходуют 6 мс. Таким образом, ввод/вывод с запуском от прерывания может быть в 20 раз эффективней ввода/вывода с запуском от таймера при малой телефонной нагрузке, но при высокой телефонной нагрузке он вдвое менее эффективен. Поскольку архитектуру определяет ситуация с высокой интенсивностью телефонной нагрузки — эффективность важна только для загруженной системы программного управления, а когда интенсивность телефонной нагрузки невысока — рабочее время управляющего процессора экономить незачем, потому что у, процессора все равно немного работы.
Предположим, что программы обработки вызовов, регулярно выполняемые вне зависимости от наличия или отсутствия телефонной нагрузки, расходуют 10% рабочего времени процессора, а сама обработка вызовов занимает дополнительно 30% рабочего времени процессора, что соответствует точке Тmax. В левой части рис. 9.2, где интенсивность телефонной нагрузки равна О, и обрабатываемых вызовов нет, общее рабочее время процессора, выделяемое для обработки вызовов, составляет только 10% рабочего времени, занимаемого регулярными программами. В правой части рис. 9.2, где интенсивность телефонной нагрузки равна Тmax обработка вызовов занимает 40% рабочего времени процессора.
Заметим, что при интенсивности телефонной нагрузки Тmax опрос и обработка вызовов вместе занимают 100% рабочего времени процессора. Поскольку свободного рабочего времени не остается, интенсивность телефонной нагрузки Тmax определяют как предельную. Если интенсивность нагрузки превысит Тmax процессор не сможет выполнить необходимый объем работы и перейдет в режим кратковременной перегрузки.
Существуют различные программные средства сглаживания кратковременных всплесков нагрузки, Например, во время таких всплесков могут приостанавливаться те программы периодического техобслуживания, которым обычно присваивают низкий приоритет, а их выполнение производится тогда, когда время процессора не занято опросом или обработкой вызовов. В левой части рис. 9.2, где интенсивность нагрузки нулевая, для техобслуживания доступно 50% рабочего времени, а в правой его части для задач техобслуживания рабочего времени не остается. Однако очень длительный период повышенной нагрузки может привести к переполнению очереди и к аварийному отказу всей программной системы.
Рассмотрим интенсивность нагрузки, равную половине максимальной величины. В результате интерполяции между двумя крайними точками на рис. 9.2 получим, что опрос занимает 50% рабочего времени процессора, обработка вызовов — 25% этого времени, а 25% остается для техобслуживания. Хотя рис. 9.2 хорошо иллюстрирует зависимость распределения рабочего времени процессора от интенсивности телефонной нагрузки, он не показывает поведение программ в реальном времени. В 1ESS и в машинах «Нева» оно определяется приоритетами.
В 1ESS имеются приоритеты базового уровня, обозначаемые буквами от А до Е и I. Для предотвращения перегрузки периодическому сканированию абонентских линий назначается низкий приоритет О. В условиях обычной нагрузки сканирование абонентских линий выполняется каждые 100 мс. Когда процессор очень занят, время между двумя запусками программ приоритета D может достигать 700 мс, и при этом экономятся шесть циклов сканирования. Единственная расплата за такую экономию — малозаметная задержка сигнала ответа станции при перегрузке системы.
Практически такое же решение было реализовано в конце 80-х годов в АТС DX-200, после того как лавиной телефонных поздравлений по случаю 8 Марта была остановлена одна из первых цифровых АТС в стране. Эффект, который дает это решение, иллюстрирует рис. 9.3.
И все же. разработчики 1ЕSS не только сильно недооценили трудности разработки программного обеспечения, но и сильно переоценили производительность своего процессора 1Е. Эти два важнейших вопроса, конечно, тесно связаны — если программа оказывается длиннее, чем ожидалось, время ее выполнения, по-видимому, становится больше, и требуется больше рабочего времени процессора, чем ожидалось. Хотя было обещано, что процессор 1Е будет управлять коммутационной станцией емкостью несколько сотен тысяч абонентских линий, первоначально процессор 1Е с трудом обслуживал несколько тысяч абонентских линий и вскоре был заменен более быстродействующим процессором 1А. В отличие от этого, все процессоры «Нева» в до сих пор успешно работающих междугородных АМТС «Кварц», как ив выпущенном всего в единственном экземпляре транзитном узле ИВТУ, не достигли предельных значений производительности. Разные судьбы машин 1ESS и машин «Нева» были обусловлены отнюдь не техническими решениями.
9.4. Технологические аспекты разработки программного обеспечения АТС
1ESS и ИВТУ были новаторскими работами, обобщенный опыт которых дал начало современной теории проектирования программного обеспечения реального времени.
Независимо от используемой теоретической модели, жизненный цикл программного обеспечения системы коммутации разделяется на четыре фазы:
• разработка,
• тестирование,
• внедрение,
• сопровождение, из которых в этом параграфе основное внимание уделяется первой.
Одной из ранних моделей разработки программного обеспечения является модель водопада (waterfall model), или, иначе, — каскадная модель, представленная на рис. 9.4. Дальнейшая эволюция этой модели, обусловленная, в частности, рассматриваемыми в следующей главе требованиями надежности и эффективности эксплуатационного управления системами коммутации, а также необходимостью оперативного ввода новых телекоммуникационных услуг на основе их быстрого макетирования, привел к V-модели, являющейся развитием каскадной модели и представленной на рис. 9.5.
Обе эти модели предполагают, что любая фаза работы завершается до того, как начнется работа следующей фазы. Однако сегодня при разработке ПО используется методология объектное ориентированного программирования, для которой больше подходит предложенная Б.Боэмом [21] спиральная модель, приведенная на рис. 9.6 и соответствующая итерационному процессу создания ПО путем последовательных приращений.
Не вдаваясь в детали других фаз жизненного цикла ПО, сосредоточимся на процессе разработки телекоммуникационного программного обеспечения. В схеме этого процесса, приведенной на рис. 9.7, предусмотрена иерархическая декомпозиция процесса разработки на последовательность шагов, уточняющих проект. Такими укрупненными шагами (уровнями проектирования) являются анализ и формализация требований и интерфейсов коммутационного оборудования (В-уровень), определение архитектуры (системной и функциональной) и модульной структуры ПО (А-уровень), разработка SDL-спецификаций модулей (блоков, процессоров, процедур, макросов, структур данных) и межмодульных интерфейсов (S-уровень) и собственно программирование и отладка программ (P-уровень).
Уровни проектирования различаются как степенью конкретизации (возрастающей сверху вниз), так и языковыми средствами описания. Представление системы ПО на вышестоящем уровне является в известном смысле общим прародителем» семейства ее представлений на нижестоящих уровнях. На всех уровнях проектирования (а не только на S-уровне) производится последовательная спецификация задач, которые решает ПО. Под спецификацией здесь понимается описание в терминах, характерных для самой задачи, а не для ее реализации, служащее основой для дальнейшей детализации и разработки телекоммуникационного ПО. Можно считать, что каждый уровень проектирования получает спецификации от вышестоящего уровня и, в свою очередь, вырабатывает данные, необходимые для спецификации одного (или более) из нижестоящих уровней. Отличительные свойства спецификаций — однозначность, точность, формальность, понятность и читаемость. Как отмечено в [44], язык программирования более высокого уровня может считаться языком спецификаций по отношению к языку более низкого уровня. При этом спецификация программного модуля не обязана быть короче самого модуля, ибо от нее требуется не краткость, а точность и понятность.
Определение и спецификация требований к ПО узла коммутации являются основными задачами R-уровня проектирования. На этом уровне разрабатываются технические требования, структурная схема станции, интерфейсы ПО с коммутационным оборудованием и т.д. Языком описания, как правило, служит естественный язык со всеми присущими ему недостатками — неоднозначностью, связанной с тем, что естественный язык недостаточно точен для описания программных систем, и разные разработчики могут по-разному понять одну и ту же фразу технического задания, и неполнотой описания ПО, которая усугубляется тем, что при разработке большой и сложной системы телекоммуникационных программ проходит много времени, прежде чем становится ясно, какой информации R-уровня недостает.
Еще одна трудность, возникающая на R-уровне проектирования, — невозможность удержать семантику описания требований на одинаковом уровне детализации. В результате одни описания R-уровня оказываются несколько туманными, другие — излишне детализированными, предоставляя элементы реализации, причем, возможно, не самой удачной, выбранной без рассмотрения остальных частей системы и не позволяющей
разработчикам следующих уровней проектирования использовать эффективные структуры данных или приемы программирования.
После завершения R-уровня проектирования, т.е. когда точная внешняя спецификация системы программного управления коммутационного узла заменит ее неформальное описание, начинается разработка архитектуры ПО (А - уровень).
А-уровень проектирования можно условно разделить на два подуровня — разработка функциональной архитектуры и разработка системной архитектуры. Принципы проектирования этих подуровней претерпели за последние годы принципиальные изменения. Вычурные системные решения, хаотические управляющие структуры и тысяче строчные подпрограммы сменились тщательно определенными и хорошо документированными функциональными модулями. Произошло заметное смещение критериев проектирования — алгоритмам управления ресурсами управляющих процессов отводится значительно меньшая роль, чем проблемам структуризации системы и взаимодействия процессов. На том же А-уровне проектирования разрабатывается структурная модель программной системы, состоящая из иерархии содержательных функций, эффект выполнения которых влияет на функционирование коммутационного узла и обслуживание вызовов. Такая структурная модель в рекомендованном ITU-Т языке спецификаций и описаний SDL называется диаграммой дерева блоков. Блок представляет собой наиболее крупный объект в SDL, который, в свою очередь, содержит один или несколько процессов. Разбиение системы ПО на составные части делается таким образом, чтобы каждая из частей была небольшой, удобной для восприятия и соответствующей естественному функциональному разбиению, и чтобы связи между частями, возникающие в результате разбиения, были как можно более слабыми. На каждом этапе разбиения специфицируются также каналы, входные сигналы, выходные сигналы и данные.
Программная документация А-уровня служит исходными данными для проектирования SDL-спецификаций программных процессов, процедур и макросов, что в отечественной литературе иногда именуется алгоритмическим обеспечением АТС. Неформально алгоритм можно определить как совокупность правил, определяющих эффективную процедуру решения любой задачи из некоторого заданного класса задач. Сам термин произошел от арабского имени великого узбекского математика IX века Мухаммеда аль Хорезма и, следовательно, известен достаточно давно, но как математические объекты алгоритмы исследуются с 30-х годов прошлого столетия. Уточнения понятия алгоритма основываются, в частности, на понятиях частично-рекурсивной функции или машины Тьюринга. Строго говоря, составление алгоритма программного управления АТС является в математическом смысле алгоритмически неразрешенной проблемой, т.к. область аргументов такого алгоритма обязательно должна включать в себя состояния и текущие значения реального времени функционирования узла коммутации. С другой стороны, известен так называемый тезис Черча, состоящий в том, что любая вычислимая арифметическая функция является частично-рекурсивной. Следовательно, алгоритмическая неразрешимость проблемы составления алгоритма программного управления АТС вытекает из простых мощностных соображений: всех арифметических (числовых) функций — континуум, а частично-рекурсивных — счетное множество. Тем не менее, термин алгоритмическое обеспечение прочно укоренился в лексиконе специалистов по программному обеспечению систем коммутации. Интуитивно под этим термином понимаются спецификации телекоммуникационного программного обеспечения. Именно в таком смысле этот термин используется и в настоящей книге.
Детальное проектирование S-уровня включает в себя уточнение спецификаций интерфейсов программных модулей и структур данных и проектирование SDL-диаграмм модулей. При уточнении интерфейсов окончательно определяются порядок и структура параметров, глобалов и сообщений, составляющих интерфейс. Проектирование SDL-диаграмм на S-уровне тоже выполняется сверху вниз методом пошаговых уточнений каналов, сигналов, процессов, процедур, макроопределений. Точно так же, как конструкторские чертежи, например, в машиностроении, SDL-диаграммы — это не просто картинки, а законченный и богатый язык.
Механизмы SDL просты и обладают большой выразительной силой, что делает SDL естественным и удобным для применения. Требуется совсем небольшая практика, что бы научиться читать на SDL и точно воспринимать информационное содержание, передаваемое графическими обозначениями и словами языка. Однако, будучи языком с точно определенной семантикой, SDL налагает жесткие ограничения на правила толкования смысла спецификаций и на правила написания SDL-диаграмм.
Можно напомнить, что разработка языка SDL проводится ITU-Т сначала 70-х годов. Первая версия SDL была опубликована в 1977 г., вторая — в 1982 г., а третья, расширенная и модернизированная, — в 1985 г. Этим версиям присвоены наименования, соответственно, SDL-76, SDL-80, SDL-84. Первые версии представляли собой средства полуформального описания систем с помощью графического псевдокода, но постепенно возможности формального структурированного описания систем развились существенно глубже, вплоть до создания полностью формализованных и выполнимых спецификаций ПО узлов коммутации. В таблице 9.1 приведены основные операторы графической версии 801 .
Завершающим шагом разработки ПО является кодирование и отладка программ (Р-уровень проектирования). Именно Р-уровень многие называют программированием. В течение этого этапа программная разработка конвертируется в коды, которые могут исполняться в управляющих процессорах. Первые системы программного управления коммутацией создавались на языке Ассемблер, но значительное улучшение характеристик процессоров, в полном соответствии с законом Мура, привело к возможности эффективного использования языков высокого уровня, в число которых входит популярный для телекоммуникационных приложений язык Си++.
Наибольшую популярность приобрели некоторое время назад численные оценки качества программ, предложенные Холстедом. Согласно предложенной им метрике, длина программы N=ŋ1log2ŋ1+ŋ2log2ŋ2 , где ŋ1 — число простых операторов, а ŋ2 — число простых операндов в программе. Развитию этой программно метрики были посвящены сотни публикаций, а применительно к программному управлению узлами коммутации интересные результаты получены в [10]. 4
В практической же области в настоящее время используются иные модели оценки качества ПО, из которых мы упомянем две — одну, предложенную Институтом разработки программного обеспечения (SEI) университета Карнеги Меллона и называемую моделью мандатной зрелости (СММ), и другую, разработанную ISO (ТС-176). Обе модели поддерживают процесс сертификации организаций-разработчиков программного обеспечения. Полезная с педагогической точки зрения, модель мандатной зрелости СММ оперирует пятью уровнями зрелости процесса разработки ПО.
Первый уровень называют начальным (initial level). Он соответствует ситуации, когда процесс разработки ПО не организован, и разработка основана только на индивидуальных качествах, грамотности и опыте программистов.
Второй уровень называется уровнем повторяемости (repeatable level). На этом уровне зрелости существуют правила и процедуры разработки ПО, обеспечивается дисциплинированный подход к разработке, предусматривающий планирование и отслеживание проектов и позволяющий, когда это возможно, успешно повторять решения и подходы одного проекта в других проектах.
Третий уровень называется уровнем определенности (defined level). Это означает, что процесс проектирования ПО хорошо определен и документируется. Он включает в себя стандарты и процедуры выполнения работы, устойчивые и повторяемые элементы, общее понимание целевой функции ПО, сквозной контроль и критерии завершения.
Четвертый уровень называется уровнем управляемости (managed level) и предполагает, что качество процесса проектирования ПО, как и качество продукта, в определенной степени предсказуемо. Процесс этого уровня является устойчивым, измеряемым и корректируемым, что дает возможность влиять на качество продукта.
Последний, пятый уровень называется уровнем оптимизации (optimizing level). На этом уровне реализуется программа непрерывной модернизации, используются профилактические методики, которые сокращают время разработки и повышают качество ПО, применяются новые приемы и методики, направленные на постоянное улучшение процесса разработки и, следовательно, качества продукта.
Характеристика организации-разработчика ПО может уточняться в зависимости от достигнутого ею уровня проектирования, и командой сертифицированных специалистов ее программному продукту может быть присвоен соответствующий мандатный уровень зрелости.
Аналогична задача международного стандарта управления качеством ISO 9000-3, обеспечивающего гарантии качества разработки, поставки и сопровождения ПО. Он определяет систему оценки качества, включая его управляемость, а также функции жизненного цикла (разработку, тестирование и установку) и функции сопровождения (управление конфигурацией, документация, измерение и обучение). Соответствие организации-разработчика ПО этим требованиям проверяется организацией, которая имеет подтвержденные ISO право и полномочия выдавать сертификат согласия ISO, причем организация-разработчик должна сертифицироваться регулярно с определенной периодичностью.
На рис. 9.8 показана технология проектирования телекоммуникационного ПО, соответствующая приведенным в этом параграфе принципам обеспечения качества ПО.
9.6. Программные системы современных ATC
При рассмотрении коммутационных узлов и станций в предыдущих главах программное обеспечение подробно не обсуждалось, за исключением, пожалуй, 5ESS в главе 5. Это было сделано сознательно, чтобы в этой главе рассмотреть более раннее, но более поучительное программное обеспечение 1ESS.
Архитектура ПО станций АХЕ-10 компании Ericsson показана на рис. 9.9. Программное обеспечение АХЕ-10 подразделяется на ПО, общее для всей системы, ПО, общее для подсистем, центральное ПО, общее для CPS, и региональное ПО, общее для RPS.
ПО станций EWSD написано на языках высокого уровня SDL, CHILL, Ассемблер, С++ и формирует систему прикладных программ APS (рис. 9.10). Аппаратные средства технологически очень быстро изменяются, поэтому ПО спроектировано так, что только небольшая часть его зависит от аппаратных средств. Поскольку управление в системе EWSD распределенное, каждый процессор имеет собственное ПО. Для каждого процессора действительно следующее общее правило: его ПО содержит не связанную с конкретным применением часть и специализированную, связанную с применением часть. Не связанная с применением часть всегда содержит операционную систему, ориентированную на определенные аппаратные средства.
ПО станций NEAX 61 разделяется на две части: операционную систему (OS) и прикладную систему (APL). Операционная система включает в себя программу управления выполнением (EP), программу диагностики (DP) и программу обработки ошибки (FP). Прикладная система включает в себя программы обработки вызова (CP) и административные программы (AP), которые поддерживают и все станционные данные, и ввод/вывод, как это показано на рис. 9.11.
Архитектура программного обеспечения Supper Node DMS показана на рис. 9.12 и содержит четыре уровня: базовый уровень операционной системы Super Node DMS, уровень телекоммуникаций, поддерживающий базовые функции телефонии, уровень продукта, который поддерживает тот или иной конкретный продукт, работающий под архитектурой Super Node DMS, например, рассмотренную ранее систему DMS-100, и уровень абонента, который содержит ПО, обеспечивающее взаимодействие с абонентской линией и предоставление абоненту дополнительных услуг.
Более подробное описание ПО рассмотренных систем вряд ли целесообразно, ибо так много изменений происходит сегодня в программном обеспечении АТС, что к изложенному в этой главе материалу можно лишь добавить совет читателям-студентам приходить на экзамен со свежей головой т.к. во многом придется разбираться впервые.