Приложение З Принципы распределенного управления мобильными сервисными робо­тами

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

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

Рис.1. Функциональная схема системы управления мобильного робота.

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

управления [36,266,276].

Рассмотрим вариант функциональной схемы системы управления мобиль­ным роботом (рис.1). Существенной проблемой здесь является то, что моду­ли, реализующие высокоуровневые интеллектуальные функции, требуют больших вычислительных ресурсов, что заставляет искать новые подходы для реализации СУ.

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

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

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

- усложняется настройка и отладка взаимодействующих модулей СУ;

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

- повышается энергопотребление от автономных бортовых источников пи­тания;

- достаточно трудно модифицировать структуру системы управления в случае необходимости;

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

Избежать этих нежелательных явлений можно в СУ реализованной по распределенному принципу, за счет использования нескольких компьютеров, связанных в единую сеть [108,109]. Тогда задачи, требующие больших вы­числительных ресурсов, могут решаться на отдельных и даже удаленных компьютерах.

Распределенная реализация СУ дает также большие преимущества в виде открытости архитектуры, возможности наращивания вычислительной мощ­ности, динамической расширяемости, мобильности и совместного использо­вания модулей системы управления несколькими роботами [302, 315].

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

Для экспериментального мобильного робота (рис.2) созданного в качестве прототипа сервисного робота используемого в качестве помощника в офисах, социальных учреждениях была разработана распределенная СУ на основе трех персональных компьютеров, объединенных в единую быстродействую­щую (100 Мбит/с) вычислительную сеть.

Рис.2. Конфигурация мобильного сервисного робота

Рис.З. Пример реализации распределенной СУ

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

реальном времени интерфейсные адаптеры управления приводами робота и движения видеокамер, подключения ультразвуковых датчиков препятствий, а также адаптеры ввода видеоизображений в компьютер, сенсорный LCD эк­ран и средства мультимедиа были подключены к различным компьютерам (рис.З).

На рис.4 проиллюстрированы некоторые преимущества распреде­ленной СУ мобильного робота.

Рис.4. Некоторые преимущества распределенной системы управления мо­бильного робота: (а) - наращиваемые вычислительные ресурсы; (б) - откры­тая архитектура; (в) - динамическая расширяемость; (г) - совместное использование сервиса; (д) - мобильность

1. Архитектура системы управления

Структурная схема распределенной СУ основана на иерархическом под­ходе к построению сложных управляющих систем [217, 287]. В системе имеются два вертикальных уровня управления: нижний уровень управления аппаратными средствами и верхний уровень управления функционировани­ем робота (рис.5). Уровень управления аппаратными средствами (уровень аналитического управления) включает набор средств и процедур для управ­ления аппаратными устройствами робота (двигателями, вращающимися ви­деокамерами, другими исполнительными устройствами) и опроса сенсорных систем робота (импульсных датчиков положения и скорости, ультразвуковых и других сенсоров, изображения от видеокамер, и т.д.). Данный уровень изо­лирует все аппаратно-зависимые низкоуровневые детали управления техни­ческими средствами робота от верхнего уровня, представляя верхнему уров­

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

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

Рис.5. Архитектура распределенной системы управления.

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

Уровень управления функционированием робота (уровень интеллекту­ального управления) включает процедуры, относящиеся к проблемам управ­ления верхнего уровня: управление движением робота, интерпретация дан­

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

При реализации распределенной системы на основе вычислительной сети существует ряд дополнительных проблем. В такой системе тесная взаимо­связь между модулями СУ роботом уже невозможна, потому что модули вы­полняются на различных компьютерах и не имеют свободного доступа к внутреннему состоянию других модулей. Таким образом, в распределенной системе связи между модулями системы должны быть ослаблены, а обмен информацией между ними должен происходить только через сетевые меха­низмы взаимодействия. Эти механизмы взаимодействия должны быть доста­точно гибкими, чтобы позволить модулям системы использовать различные стратегии взаимодействия и обмена информацией, таких как широковеща­тельная рассылка, индивидуальные каналы обмена информацией между мо­дулями по типу «один к одному» и «один ко многим» (сервер-клиент), а так­же обеспечить однородный интерфейс и динамическую расширяемость. В нашей системе мы используем открытую распределенную объектную архи­тектуру CORBA (Common Object Request Broker Architecture - Обобщенную Архитектуру построения Брокеров Объектных Запросов), для того чтобы вы­полнить все поставленные нами задачи при реализации механизмов взаимо­действия модулей. Особенности архитектуры CORBA:

• имеет открытую, объектно-ориентированную структуру;

• является инструментом разработки распределенных вычислительных систем;

• разрабатываемая система представляется в виде совокупности взаимо­действующих объектов;

• поддерживает разработку распределенных СУ в реальном времени;

• обеспечивает жестко запрограммированные взаимодействия (объект­ные интерфейсы);

• поддерживается множеством языков программирования на множестве платформ.

Распределенные модули и протоколы их взаимодействия также должны корректно поддерживать совместное использование ресурсов и обеспечивать

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

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

2. Механизмы связи

Рассмотрим механизмы взаимодействия модулей, используемые для по­строения распределенной СУ. Как уже было сказано выше, для этой цели ис­пользуется CORBA - открытая распределенная объектная архитектура и ин­фраструктура, предназначенная для построения распределенных вычисли­тельных систем. Благодаря принятому стандарту эта архитектура является независимой от выбора компьютерной платформы (от больших компьютеров до микроЭВМ и встроенных систем), операционной системы и языка про­граммирования. CORBA реализует стандартную схему интеграции компью­теров и программ от разных поставщиков для построения распределенных приложений, включая прикладные системы реального времени. Для реализа­ции нашей системы мы использовали свободно распространяемую версию Брокера Объектных Запросов - omniORB.

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

• реализует интерфейсы нижнего уровня между модулями системы;

• позволяет осуществлять тесное интегрирование модулей системы;

• обеспечивает открытость и расширяемость.

Уровень обмена сообщениями (рис.6,6) позволяет узлам взаимодейство­вать, используя сообщения. Данный уровень:

• обеспечивает наибольшую гибкость взаимодействия за счет использо­вания однородного интерфейса;

• позволяет реализовать различные стратегии взаимодействия и динами­чески перестраивать конфигурацию;

• скрывает внутренние детали и механизмы библиотеки CORBA.

Рис.6. Уровни взаимодействия между модулями системы: (а) - объектный

уровень; (б) - уровень обмена сообщениями

Рис.7. Распределенные механизмы связи

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

доступ экспортируемым процедурам и данным модуля путем вызова методов объектов CORBA.

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

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

Уровень взаимодействия с помощью обмена сообщениями обеспечивает более удобный и гибкий обмен информацией между модулями системы за счет скрытия большинства деталей и механизмов архитектуры CORBA. Для обмена информацией на этом уровне используется однородный интерфейс - процедуры посылки и приема сообщений определенного формата. Здесь так­же возможны такие стратегии взаимодействия как посылка сообщений не­скольким модулям сразу и «подписка» на получение сообщений от других модулей. Механизмы уровня сообщений автоматически находят модули- адресаты сообщений в распределенной системе, гарантируют надежную дос­тавку сообщений, извещают адресаты о их прибытии, обеспечивают диагно­стику ошибок.

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

Обмен сообщениями между модулями системы производится при помощи таких объектов, как очереди сообщений и маршрутизаторы сообщений (см. рис.6). Очереди и маршрутизаторы сообщений используют внутренние объ­екты CORBA, чтобы передавать сообщения в распределенной сетевой среде. Очереди сообщений используются для пересылки сообщений между двумя взаимодействующими модулями. Они обеспечивают отправку и получение сообщений, а также определяют очередность их обработки модулями в соот­ветствии с приоритетами. Маршрутизаторы сообщений обеспечивают обмен

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

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

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

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

Маршрутизаторы сообщений в нашей системе обеспечивают динамиче­ски конфигурируемые схемы обмена сообщениями между модулями: рас­сылку сообщений получателям по их запросу («подписка» на сообщения) и рассылку одного сообщения любому числу получателей (широковещательная рассылка). Данный механизм, например, может быть использован модулем управления движением робота для рассылки изменений в векторе состояния

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

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

Программный интерфейс серверной части минимален - в нем имеется лишь один метод, который используется модулем для передачи отправляе­мых сообщений маршрутизатору. Серверная часть маршрутизатора сообще­ний имеет динамический реестр «подписчиков» на отправляемые сообщения, который управляется через CORBA-объект клиентскими частями других мо­дулей. Аналогично, клиентская часть имеет единственный метод, который - позволяет посылать запросы на «подписку» маршрутизатору с определенным именем в распределенной среде. Запрос на «подписку» содержит имя очере­ди сообщений, в которую требуется помещать отправляемые по запросу со­общения, категорию и идентификатор (или их диапазон) интересуемых со­общений. Запрос может также отменить ранее сделанный запрос. Запрос по­мещается в динамический реестр маршрутизатора, который используется для фильтрации и доставки исходящих сообщения маршрутизатора в указанные в запросах очереди. Сама доставка сообщений осуществляется при помощи клиентских частей очередей сообщений. При помощи процедур подсистемы CORBA маршрутизатор поддерживает реестр запросов в состоянии, отра­жающем текущую ситуацию в распределенной среде. Если маршрутизатор обнаружит, что указанная в запросе очередь сообщений отсутствует в рас­пределенной среде в течение некоторого времени, то он удалит из реестра связанный с ней запрос.

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

зования.

3. Управление роботом в распределенной вычислительной среде

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

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

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

пы она использует и для управления параллельным исполнением множества сценариев.

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

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

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

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