Учреждение образования

«Белорусская государственная академия связи»

ЯЗЫКИ МОДЕЛИРОВАНИЯ МСЭ

Конспект лекций по учебной дисциплине для специальности 2-45 01 33 – Сети телекоммуникаций

специализации 2-45 01 33 01 – Техническая эксплуатация сетей телекоммуникаций

Составитель: Т.В. Павловская

Утвержден на заседании филиала кафедры ТКС

Протокол № 2 от 29.09.2017

Зав. филиалом кафедры Л.А. Варнава

Витебск 2017

Содержание

Введение 3

1Основные концепции SDL 16

2Диаграммы систем и блоков 21

3Базовые средства описания динамического поведения системы 33

4Процессы 35

5Процедуры 40

6Вспомогательные диаграммы и дополнительные концепции 42

7Язык «человек-машина» MML 44

8Язык высокого уровня CHILL 62

9Моделирование телекоммуникационных систем и каналов 70

Литература 86

Введение

Понятие об алгоритмическом и программном обеспечении ЭУС

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

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

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

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

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

Современные средства программного управления коммутацией подразделяются на три уровня.

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

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

Третий уровень управления обычно связан с центральным процессором ЦАТС, который выполняет функции ТО, конфигурации, администрирования, статистики и начисления платы.

Структура ПО СКПУ

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

ПО СКПУ состоит из инструментального, системного и прикладного ПО.

Инструментальное ПО (ИПО) содержит средства автоматизации проектирования (САПР) на различных языках:

• САПР на языке высокого уровня SDL;

• САПР на языке высокого уровня CHILL;

• САПР на языке Ассемблер;

• САПР на машинно-зависимом языке.

ИПО служит для автоматизации проектирования программ на различных уровнях – от уровня алгоритмов до уровня машинных команд.

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

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

Прикладное ПО (ППО) служит для управления ЭВМ во время решения задач в определенной области – экономической, инженерной, задач управления техническими процессами.

Основное ППО содержит программы и данные, которые служат для обеспечения функционирования ЭВМ в процессе управления СКПУ, т.е. обеспечивает все этапы технологического процесса установления соединения и включает в себя:

• коммутационные программы;

• административные программы; - программы техобслуживания.

Вспомогательное ППО используется при разработке основного ППО и подготовке АТС в эксплуатацию.

ПО СКПУ делится при этом на две части в соответствии со степенью участия в обеспечении функционирования узла коммутации:

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

• внешнее ПО – это совокупность вспомогательных программ и данных, которые используются в процессе разработки, составления, отладки и т.д. ПО, но не используется в момент эксплуатации (нормальной работы) СКПУ; состоит из САПР на различных языках, системы автоматизации отладки программ, системы автоматизации производства внутреннего ПО, системы испытательно-наладочных программ.

Этапы разработки ПО

В общем виде процесс проектирования (разработки) АО и ПО является многоэтапным иерархическим итеративным (рисунок 1).

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

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

Рисунок 1 – Этапы проектирования алгоритмического и программного обеспечения

Рассмотрим более подробно содержание этапов проектирования АО и ПО.

На каждом из этапов разработки АО и ПО МСЭ-Т рекомендует использовать необходимые языковые средства (см. рисунок 1):

SDL – Specification and Discription Language (язык спецификаций и описаний);

CHILL – CCITT High Level Language (CHILL – язык высокого уровня

МККТТ);

MML – Man-machine Language (язык “человек-машина”).

Назначение каждого языка МСЭ оговорено в Рекомендациях МСЭ.

Язык спецификаций и описаний (Specification and Description Language - SDL) предназначен для описания структуры и функционирования систем реального времени (телекоммуникационных систем) в виде удобном для понимания человеком (специалистом).

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

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

Под описанием структуры системы понимается описание того, из каких компонентов (узлов, блоков) состоит система и как эти компоненты связаны между собой (линиями связи, каналами).

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

Язык SDL описывает функционирование (поведение) системы в терминах «стимул-реакция», при этом имеется в виду, что и стимулы, и реакции имеют дискретный характер и могут нести некоторую информацию.

В частности, SDL-описание системы представляет поведение системы как цепочку ответов на произвольную цепочку стимулов. Таким образом, язык SDL предназначен для описания таких управляющих систем, отдельные компоненты которых моделируются абстрактными машинами с конечным числом состояний (точнее, их некоторым расширением) и для которых существенны вопросы взаимодействия этих компонентов.

Естественно, что полное описание системы должно содержать еще и описание ее физических характеристик (массы, материала, размеров,...), однако средствами SDL это не может быть сделано.

Язык может с успехом применяться на всех этапах жизненного цикла системы: начального проектирования; создания модели для проверки принятых проектных решений; проверки на соответствие стандартам и прочим возможным требованиям; разработки и изготовления; текущего сопровождения; обнаружения и устранения неисправностей.

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

Является ли такой язык, как SDL, языком программирования? Дать на этот вопрос определенный ответ нельзя уже по одному тому, что не существует формального определения того, что такое язык программирования. Но если исходить из традиционно сложившихся представлений, то ответ, на взгляд авторов, мог бы звучать так. Язык программирования – это средство создания программ, а программа – это механизм, который получает некоторый набор данных (входную информацию), перерабатывает его, в результате чего выдает некоторый другой набор данных (выходную информацию). Основным содержанием этого механизма является детальное описание алгоритма переработки, ориентированное на реализацию алгоритма на цифровых машинах с программным управлением.

Если такое понимание языков программирования верно, то SDL несколько отличен от обычных языков программирования.

Во-первых, в SDL предусмотрены средства для описания структуры того комплекса, на котором будет происходить переработка информации, чего совершенно нет в языках программирования.

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

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

Язык "человек-машина" (Man-Machine Language - MML) - формализованный язык предназначен для общения оператора с управляющим комплексом АТС. Данный язык состоит из двух частей: языка ввода и языка вывода. Обе части MML обеспечивают связь человека с машиной в наиболее удобной для человека форме.

Язык диалога MML разработан МСЭ-Т (МККТТ) для систем коммутации с программным управлением (СКПУ). Этот язык спроектирован таким образом, что обеспечивает: простоту в изучении и использовании, легкость ввода команд, понимания выводимой информации, приспособления к различным категориям обслуживающего персонала и организационным добавлениям, а также работу в режиме «меню».

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

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

Основным понятием входящей части языка MML является понятие директивы. Директива представляет собой вопрос или приказ оператора в форме, доступной для понимания и исполнения в управляющей системе СКПУ.

Язык МККТТ высокого уровня (CCITT High Level Language - CHILL) предназначен для системных программистов при создании и документировании программного обеспечения телекоммуникационных систем.

Язык программирования высокого уровня МККТТ CHILL разработан по рекомендации МККТТ как средство для создания программного обеспечения АТС с программным управлением. При разработке языка CHILL использовался опыт, приобретенный при создании и использовании таких языков программирования высокого уровня, как Паскаль, Алгол, PL/1. Полное формальное определение языка CHILL приведено в Рекомендации МККТТ Z.200.

Программа, написанная на языке CHILL, должна содержать три обязательных компонента:

-описание объектов данных;

-описание действий, которые должны выполняться над объектами данных;

-описание структуры программы.

Описание объектов данных, являющихся информационными единицами программы, производится с помощью операторов описания и операторов определения.

Описание действий производится с помощью операторов действий, задающих как конкретные операции, выполняемые над объектами данных, так и порядок выполнения этих операций.

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

Следует отметить, что наряду с другими в CHILL определена программная структура PROCESS, которая используется как средство описания параллельных действий во времени. Включение в состав языка программной структуры PROCESS и определяет CHILL как язык реального времени.

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

Язык CHILL рассчитан на следующий круг применений:

-обработка вызовов;

-тестирование оборудования и сопровождение программ;

-операционные системы;

-поддержка диалогового и пакетного режимов; -реализация языка «человек-машина».

При создании CHILL принималось во внимание, что программное обеспечение АТС является сложным. Поэтому язык CHILL должен:

-повышать надежность программного обеспечения;

-способствовать генерации высокоэффективного объектного кода;

-быть гибким и мощным;

-поддерживать модульное и структурированное программирование; -быть простым в изучении и использовании.

Язык CHILL, записанный в Z.200 является машинно-независимым, но допускает включение некоторых средств, зависящих от реализации.

Рассмотрим более подробно каждый этап разработки ПО.

1. Этап составления спецификации и планирования системы начинается с момента получения технического задания на разработку СКПУ. Требования, предъявляемые к проектируемой системе, записываются в виде спецификаций.

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

Общими параметрами станции являются:

-место АТС на сети - это назначение станции с сетевой точки зрения (городская, междугородная, международная, оконечная, транзитная и т.д.). Различные виды АТС имеют различное ПО (особенно с точки зрения организации данных);

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

-набор систем сигнализации

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

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

-маршрутизация – список обслуживаемых кодов станции на сети, таблица пересчета каждого кода в номера пучков каналов прямого и обходных направлений, а также таблицы объединения каналов и линий в пучки по направлениям;

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

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

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

Спецификация составляется для всей станции в целом.

Все функциональные спецификации (желаемое поведение) системы связи задаются в самом общем виде.

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

2. На этапе системного проектирования выделяются стандартные процессы, определяются информационные связи между ними, порядок и способ обмена сигналами. Этот этап предназначен для детализации функциональной спецификации СКПУ, полученной на предыдущем этапе.

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

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

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

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

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

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

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

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

Уровень 3 осуществляет управление элементарными последовательностями сигналов, входящих в состав систем сигнализации. Последовательность действий на уровне 4 образует совокупность различных сигнальных протоколов. Наконец, высший уровень 5 определяет последовательность выполнения коммутации. Первоначально созданные виртуальные машины как бы распределяются на иерархические уровни, занимая каждая свое место.

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

Сложность ПО зависит от правильности выбора количества и содержания процессов. При этом возникает проблема определения числа процессов в ПО.

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

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

Оптимальным решением этой проблемы является выделение небольшого количества базовых (основных) процессов.

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

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

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

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

В зависимости от важности (приоритета) и отведенного времени выполнения возможны несколько типов процессов:

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

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

-циклические процессы, т.е. процессы, которые важны для всей системы в целом. Они начинаются в момент подачи заявки на обслуживание и продолжаются, пока заявка находится в системе. Если в таком процессе нет необходимости, то он находится в состоянии «ожидания» в программной памяти. К ним относятся такие процессы, как обработка вызовов, начисление оплаты, контроль нагрузки, управление памятью.

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

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

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

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

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

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

Результаты работы на этапе системного проектирования тщательно документируются.

3. На этапе детального проектирования разрабатываются алгоритмы, отображающие действительное поведение станции. Процессы, выделенные на этапе системного проектирования распределяются между управляющими устройствами СКПУ, выбираются состав и структура массивов памяти, необходимых для их реализации. Результатом работ на данном этапе является функциональное описание, которое служит основой дальнейшей разработки ПО СКПУ.

Так как каждый процесс можно представить в виде последовательности алгоритмических модулей, то это дает возможность:

-задавать и использовать модули, без учета их конкретной реализации;

-проводить их разработку и отладку автономно, независимо друг от друга, как только будут определены состав модулей и связи между ними;

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

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

Рисунок 1а – Состав алгоритмических модулей

Для облегчения и ускорения работ на первых трех этапах МСЭ-Т рекомендует использовать язык SDL.

4. На этапе кодирования алгоритмы, разработанные на этапе детального проектирования, записываются на одном из языков программирования, понятном ЭУМ

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

ПО следующего поколения АТС с программным управлением программировали на языке ассемблера.

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

Недостаток языка ассемблера состоит в сравнительно большой трудоемкости написания программ на этом языке.

Язык ассемблера широко используется при создании программ для микропроцессоров и целого ряда управляющих комплексов (УК).

В настоящее время для кодирования большинства детальных алгоритмов МСЭ-Т рекомендует использовать специализированный язык программирования высокого уровня CHILL (для таких систем коммутации, как EWSD, SI 2000, AXE-10). Язык CHILL был разработан на базе языков АЛГОЛ, ПАСКАЛЬ и ПЛ/1 и ориентирован на задачи коммутации.

Стремление использовать язык высокого уровня при создании ПО АТС обусловлено большой трудоемкостью его создания. Например, для создания ПО АТС объемом 1-2 млн. команд с помощью машинных языков потребуется более 300 человеко-лет.

Однако, несмотря на это некоторые алгоритмы, критичные по времени выполнения их ЭУМ, записываются на языках программирования низкого уровня типа ассемблер и макроассемблер, которые учитывают структуру и систему команд конкретной ЭУМ.

5. В процессе разработки ПО могут возникать ошибки, поэтому в состав разработки ПО вводится специальный процесс отладки, который занимает не менее 50% всего времени разработки ПО.

Этап отладки программного обеспечения разбивается на три подэтапа:

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

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

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

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

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

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

Использование модели внешней среды позволяет довести отлаженность ПО до 95% и сократить сроки проведения системной отладки на 30%.

6. Эксплуатация ПО подразумевает опытную (полевую) эксплуатацию в течение директивного срока (обычно - 1 год) и нормальную эксплуатацию АТС в течение 10-15 лет.

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

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

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

Для выполнения работ на этапах отладки и эксплуатации ПО используются специальные программные средства, взаимодействие с которыми осуществляется на языке “человек-машина” ММL (Man-machine Language).

Процесс проектирования ПО является достаточно сложным и трудоемким. Значительную трудоемкость имеют работы по документированию АО и ПО, которые выполняются на всех этапах. Суммарные затраты на составление документации равны 15 – 20 % затрат на проектирование АО и ПО в целом.

По зарубежному опыту разработки современных УК с программным управлением суммарная стоимость работ по проектированию АО и ПО в целом составляет около 50% стоимости разработки УК в целом.