Визуальное моделирование систем реального времени, часть I

Системы реального времени

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

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

Исторически компьютеры и программное обеспечение возникли именно как способ создать более сложные целевые электромеханические системы. Так, один из первых в мире компьютеров EDVAC (1945 год), описанный фон Нейманом в знаменитом отчете "First Draft of a report on the EDVAC", с которого, фактически, началась вычислительная техника и программирование, предназначался для управления системой противовоздушной обороны США. А конструктор первых в России ЭВМ Сергей Александрович Лебедев пришел в эту область из энергетики, решая задачи устойчивости функционирования энергетических систем.

Структурное подобие СРВ и аппаратуры

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

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

Рис. 6.1. Упрощенная схема телефонной станции

В состав программной части системы входят следующие компоненты: "Концентратор1", "Концентратор2", "Коммутатор", "Абонент1" и "Абонент2". Эти компоненты, кроме реализации управляющей логики, хранят также текущие состояния соответствующих аппаратных устройств, в частности, историю работы аппаратуры, которая нужна для правильного принятия управляющих решений.

СРВ подобны аппаратуре не только в смысле разбиения на независимые компоненты, но также и в смысле связей компонент друг с другом. На рис. 6.1 можно увидеть, что сколько соединений имеют аппаратные узлы, столько же соединений имеют и соответствующие им программные компоненты. То же самое можно сказать про все другие аппаратные соединения, обозначенные на рис. 6.1. Зачем же в ПО повторять структуру соединений аппаратных компонент?

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

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

Многоуровневые открытые сетевые протоколы и блочная декомпозиция

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

Достичь легкого использования готовых компонент, а также обеспечить открытость и совместимость позволяет следование международным телекоммуникационным стандартам, которые развиваются уже не одно десятилетие такими комитетами, как ITU, ISO, ETSI и др. Большую роль в телекоммуникационных стандартах играет концепция многоуровневых открытых сетевых протоколов, стандартизованная международным комитетом ISO в модели ISO/OSI.

В рамках данных лекций не будет рассматриваться содержательный аспект этой концепции, а также конкретные телекоммуникационные стандарты ISDN, ATM, GSM и т. д. Остановимся лишь на самой идее многоуровневого сетевого протокола, которая широко используется при проектировании программно-аппаратных телекоммуникационных систем.

В основе многоуровневой модели лежит разбиение сложной телекоммуникационной функциональности на уровни или "слои" - чем выше, тем абстрактнее (см. рис. 6.2).

Рис. 6.2. Уровни многоуровневой модели

Нижний уровень обслуживает верхний, предоставляя ему нужные для работы примитивы и скрывая от него логику обработки этих примитивов. Как правило, через уровни "прыгать" не принято (например, уровню N+2 нельзя напрямую обратиться к уровню N ), хотя в некоторых телекоммуникационных стандартах такое встречается. Внутри себя каждый из уровней может содержать функциональные сущности ("листья декомпозиции") и подуровни (а те, в свою очередь, содержат другие подуровни и/или функциональные сущности) см. рис. 6.3. На этом рисунке показано, что уровень N+1 содержит три функциональных сущности, уровень N - два подуровня. Декомпозиция "в глубину" может быть продолжена аналогичным образом. Еще из рис. 6.3 видно, что все соединения между уровнями, подуровнями и функциональными сущностями п роисходят через точки подключения, в которых определены интерфейсы взаимодействия.

Рис. 6.3. Уровни, подуровни и функциональные сущности многоуровневой модели

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

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

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

Рис. 6.4. Peer-to-peer взаимодействие уровней

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

Уровни, подуровни и функциональные сущности связываются друг с другом через сервисные точки (access points), в которых определяются двусторонние интерфейсы обмена сообщениями. К сервисным точкам ведут каналы снаружи блоков и от их элементов, т. е. изнутри. Ниже мы увидим, что сервисные точки моделируются портами UML 2.0.

Итак, блочная декомпозиция является важнейшим принципом моделирования сложных телекоммуникационных систем.