Принципы и методы построения датчиков, приборов и систем
УДК 681.5
СИСТЕМА УПРАВЛЕНИЯ СЛОЖНЫМ ТЕХНИЧЕСКИМ ОБЪЕКТОМ НА ОСНОВЕ РАСПРЕДЕЛЕННОЙ ОПЕРАЦИОННОЙ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ
А.Ф. Каперко, В.Э. Карпов, A.B. Королев
Представлен опыт разработки системы управления роботом на основе операционной системы С^Х. Описаны общая структура и принципы построения надежной распределенной системы управления, а также протокол обмена данными и программное обеспечение.
ОБЩАЯ СТРУКТУРА УПРАВЛЕНИЯ
Для обеспечения требуемой скорости обработки информации при управлении сложным техническим объектом необходима операционная система (ОС) реального времени, а для эффективной обработки информации система управления должна быть распределенной.
Нами разработана система управления, базирующаяся на ОС ОЫХ и включающая в себя сеть с несколь-
кими компьютерами. Для повышения ее надежности разработан специальный протокол обмена данными. Система позволяет надежно и эффективно управлять сложным техническим объектом.
В рассматриваемом в настоящей статье примере объект управления представляет собой макетный робо-тотехнический комплекс. В его состав входят (рис. 1) набор датчиков Д исполнительные механизмы ИМ и устройство сопряжения (УС) робота с системой управления, предназначенное для приема сигналов от датчиков и передачи их распределенной системе управления, а также для передачи ее команд исполнительным механизмам. Связь с узлом сопряжения системы управления осуществляется через параллельный порт.
Распределенная система управления содержит три узла, связанные между собой сетью: узел сопряжения (21, узел обработки данных 02 и узел принятия решения ОЗ. Узел сопряжения реализует безусловно-рефлекторное поведение объекта, т.е. реализует фиксированный набор простых правил. Он играет роль связующего звена объекта управления с системой управления: узел принимает набор сигналов от датчиков, интерпретирует их и выдает "сырые" данные второму узлу; он же выдает сигналы исполнительным механизмам. Узел обработки данных служит для быстрой и эффективной обработки множества сигналов от датчиков. Узел принятия решений осуществляет распознавание данных и выбор управляющего воздействия, требующий больших временных затрат.
Распределение задач обработки информации и процесса принятия решения о выборе управляющего воздействия между тремя узлами системы обеспечивает быстрое и эффективное их выполнение. При параллельной обработке данных нагрузка распределяется между тремя различными процессорами (узлами), и скорость обработки информации существенно повышается.
ВЫБОР ОПЕРАЦИОННОЙ СИСТЕМЫ
Реализация рассмотренной схемы управления требует обеспечения работы в реальном масштабе времени, необходимой степени надежности, возможности организации локальной вычислительной сети (и, жела-
18 _ Sensors & Systems • № 2.2001
тельно, встроенной поддержки ее работы), возможности быстрого запуска и обмена информацией с удаленными задачами, а также наличия эффективного компилятора для получения компактного кода [1].
Одной из систем, которая может удовлетворить всем этим требованиям, является ОС QNX. Среди ее достоинств можно выделить модульную архитектуру, соответствие стандарту POSIX, большие сетевые возможности, заложенные на уровне ядра, компактность [2]. Операционная система QNX принадлежит к классу ОС, в который входит программное обеспечение автоматизации технологических процессов в промышленности и других областях деятельности, где требуются одновременно мул ьти задачи ость и высокая надежность [3]. Сетевые возможности QNX благодаря специальному внутреннему протоколу FTL (FLEET Transport Layer) позволяют организовать быстрый и высоконадежный механизм обмена данными.
Для разработки системы использовались возможности организации исполнения многозадачных приложений ОС. Это механизм обмена сообщениями с помощью функций Send( ), Receive( ) и Reply( ). Обмен сообщениями считается медленным механизмом, но в QNX он реализован на прерываниях и поэтому максимально эффективен [4]. Обмен сообщениями синхронизован таким образом: процесс-получатель выполняет функцию Receive( ) и блокируется ядром системы — ждет посылки сообщения (Receive - блокированное состояние). Процесс, пославший сообщение с помощью функции Send( ), также блокируется ядром (Send — блокированное состояние). После получения сообщения процесс-отправитель переходит в блокированное состояние Reply, а процесс-получатель разблокируется, обрабатывает его и посылает ответ (Reply( )), который разблокирует процесс-отправитель. Важно, что возможна передача сообщений как в прямом, так и обратном направлениях. Это обстоятельство было использовано для инициализации системы. С учетом отмеченных особенностей было разработано программное обеспечение системы.
РАЗРАБОТКА ПРОТОКОЛА ОБМЕНА ДАННЫМИ
Основные реальные проблемы, возникающие в сети, заключаются в нарушении топологии сети, перераспределении (реконфигурации) вычислительных ресурсов и обеспечении надежности системы. С ростом числа узлов сети, осуществляющих распределенное решение задачи управления, сильно растет вероятность сбоя или вообще выхода из строя одного или нескольких ее компонентов. Чтобы получить обратный эффект, необходимо создать такой альтернативный протокол, который обеспечивал бы, кроме основных своих функций, реконфигурацию сети в процессе ее работы таким образом, чтобы при увеличении числа узлов в сети возрастали бы и скорость управления объектом, и надежность системы.
Хотя для QNX существуют реализации большинства распространенных протоколов, таких как IPX, Netbios, TCP/IP и др., они все подразумевают, что в рамках локальной сети все узлы доступны. Другими словами, эти транспортные протоколы рассчитаны на то, что между всеми узлами локальной сети имеется прямая видимость (все узлы сети образуют полный граф). Таким образом, при ее отсутствии передаваемая информация будет теряться. Поэтому, для увеличения надежности и гибкости системы межпроцессорного взаимодействия был разработан специальный протокол передачи мета-IP (MIP), в котором учтены недостатки транспортных протоколов. Так как MIP базируется на общей подсистеме поддержки сети в QNX, он использует достоинства про-
токола операционной системы. Кроме этого, он осуществляет маршрутизацию на локальном уровне. В реализации механизма передачи сообщений были использованы системные вызовы 8е1^( ), Reply( ), Receive( ), позволяющие обеспечивать синхронизированную передачу пакета с подтверждением о приеме, и виртуальные каналы для связи между узлами сети.
Ниже приведена структура пакета протокола М1Р.
Отпра- Адре- Коман- Адрес Матрица Данные прото-
витель сат да инициали- кола непосред-
зации ственной связи
Поле " Отправитель" обозначает номер узла процесса, отправляющего сообщение. В поле "Адресат" процесс, отсылающий сообщение, указывает номер узла получателя. "Команда" — это число, принимающее значение от нуля до шести и обозначающее номер соответствующей глобальной команды. Поле "Адрес" представляет собой массив целых чисел, в котором содержится информация о размещении прикладных процессов. " Матрица инициализации" — это квадратная матрица порядка М, где N — максимальное число узлов в сети.
Структура протокола непосредственной связи выглядит следующим образом:
Имя Имя Команда Длина Данные
отправителя получателя пакета
данных
" Имя отправителя" и " имя получателя" — это строки, в которые отсылающий процесс прикладной программы заносит свое имя и имя процесса-получателя, соответственно. "Команда" — число, обозначающее номер локальной команды. Поле "Данные" представляет собой массив нулей и единиц, в который заносятся интерпретированные узлом сопряжения Q1 данные от датчиков.
Таким образом, к основным функциям протокола MIP относятся пересылка данных, системные функции и сохранение последовательности передаваемых пакетов.
Для решения проблемы реконфигурации сети в процессе управления (в случае отказа ее компонентов либо в случае изменения ее топологии) были разработаны специальные программы — "демоны". В задачу демонов входит обеспечение правильной и бесперебойной работы системы управления.
Главный демон отвечает за принятие всех необходимых решений управления, а вспомогательные демоны предназначены для локального управления запускаемых ими процессов. К основным функциям главного демона MIP относятся принятие решения о запуске вспомогательных демонов и посылке им команд управления соответствующими программами обработки данных в различных узлах сети, а также постоянный контроль конфигурации сети. Основные функции вспомогательных демонов MIP заключаются в инициализации сети и обеспечении доступа пакетов данных между обрабатывающими их компьютерами даже при отсутствии прямой видимости между узлами.
В общем виде схема управления с учетом демонов MIP выглядит так: в узле сопряжения запускается главный демон, в остальных узлах сети запускаются вспомогательные демоны (предполагается, что узел сопряжения должен функционировать постоянно). Главный демон осуществляет инициализацию системы и принимает решение, где будут запущены прикладные программы. Затем он посылает матрицу инициализации и адреса запуска прикладных программ вспомогательным
Датчики и Системы • № 2.2001_ 19
демонам. Далее осуществляется посылка команд запуска соответствующих процессов демонам, находящимся на этих узлах. При отсутствии прямой видимости между узлами процессы прикладных программ посылают свои пакеты данных вспомогательным демонам, а те, в свою очередь, пересылают их по адресу, определяемым ими на основе той информации, которая была передана главным демоном ранее; иначе используется более компактный протокол — непосредственной связи. При любых изменениях конфигурации сети главный демон может при необходимости дать команды завершения процессов обработки информации от датчиков одним демонам и команды запуска этих процессов другим вспомогательным демонам, расположенным в других узлах. Таким образом осуществляется реконфигурация сети.
Рассмотрим работу программ более детально на примере "некорректно" раб
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.