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

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

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

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

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

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

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

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

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

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

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

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

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