X-Robot

X-Robot (сокр. XR) — двухуровневый язык программирования контроллеров, предназначенный для управления динамическими объектами.

Низкий уровень позволяет внедряться в абсолютно любую микропроцессорную платформу, то есть ПО может быть установлено как на уже существующие типы контроллеров, так и возможно его применение при разработке платформ отечественного производства. Высокий уровень позволяет создавать разные сценарии управления динамическими объектами. Создателем языка является выпускник ТУСУРа, сотрудник научной группы «РЕВИКОМ» Мальцев Юрий Ильич.

Причина возникновения

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

Контроллер механизма можно программировать с использованием различных языков программирования. Чаще применяются универсальные языки типа «C». Но наибольшую эффективность обеспечивают такие языки программирования, которые наиболее адекватны управляемому механизму. При управлении роботом как сложным механизмом для достижения эффективности языка нужно обеспечить:

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

Всеми этими свойствами обладает язык программирования X-Robot.

Сценарий

Поведение механизма описывается на языке X-Robot (XR) сценарием, который представляет собой обычный текстовый файл, загружаемый в контроллер. В контроллере должна быть реализована операционная система реального времени и интерпретатор XR. Тип микропроцессора и возможности его периферии могут быть любыми. На текущий момент имеется реализация интерпретатора XR для микроконтроллера AtXMega фирмы Atmel. Загрузка сценария выполняется через шину USB и микросхему FTDI. Сценарий подготавливается в любом ASCII текстовом редакторе и загружается в контроллер с помощью программатора, написанного в системе LabVIEW или среде моделирования МАРС.

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

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

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

Инструкции

Текст описания процесса в сценарии состоит из инструкций, работающих с тремя адресными пространствами. Первое адресное пространство определяет до 256 исполнителей, второе — до 256 сенсоров, третье — до 255 глобальных рабочих ячеек. Размерность параметра в ячейке — 16 бит. Адрес 0 в пространстве рабочих ячеек определяет аккумулятор — единственная локальная ячейку памяти процесса (имеется в каждом процессе). В основном инструкции содержат два операнда. Первый операнд может относиться к любому из трех адресных пространств. Второй операнд может содержать 16-разрядную константу или адрес ячейки памяти.

Для каждого исполнителя определено 8 инструкций EXecut, а для каждого сенсора — 8 инструкций INput. Как выполняется конкретная инструкция EXx или INx — определяется конкретной версией интерпретатора. Так язык XR адаптируется к текущей конфигурации контроллера и набору исполнительных и сенсорных устройств робота. Дополнительный уровень адаптации обеспечивают необязательные инструкции задания параметров для каждого исполнителя или сенсора.

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

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

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

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

В XR предусмотрены инструкции, выполняющие арифметические и логические операции над данными в памяти, изменяющие регистр состояния процесса, а также инструкции управления процессами.

Интерпретатор

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

В состав интерпретатора входят следующие основные компоненты:

Загрузчик сценария.
Диспетчер процессов.
Диспетчеры асинхронных событий.
Блок обработки инструкций EX.
Блок обработки инструкций IN.

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

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

Загрузчик сценария получает текст сценария через входной порт контроллера, в данном случае — по шине USB. Текст сценария должен состоять из инструкций, подготовленных для загрузчика в 16-ричном виде. Подготовку сценария для загрузки выполняет транслятор, реализованный в программаторе, разработанном в системе LabVIEW или среде моделирования МАРС. Загрузчик размещает полученный текст в памяти микроконтроллера и строит блоки управления процессами. Флаги ожидания всех процессов сбрасываются, содержимое всех рабочих ячеек обнуляется, приводятся в исходное состояние все диспетчеры асинхронных событий, и запускается диспетчер процессов.

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

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

При обнаружении инструкций EXx или INx выполняется обращение к соответствующему блоку обработки, который анализирует адрес исполнителя / сенсора и запускает нужную подпрограмму. Существует определённый программный интерфейс между диспетчером процессов и блоками обработки, по которому в блок обработки передаются параметры инструкции, а из блока обработки поступают сигналы управления диспетчером.

Блоки обработки формируют подсистему инструкций для каждого исполнителя/сенсора, включающую до 8 инструкций EXx и/или INx. Не все 8 инструкций обязательны, это определяется сложностью исполнителя/сенсора. Если сенсор используется в инструкциях ожидания, то для опроса его состояния будет использована инструкция IN0, поэтому она имеет особое значение. Если какая-либо инструкция не определена в блоках обработки, то она воспринимается как NOP (нет операции) без генерации ошибок. Это может усложнить процесс отладки сценария, поэтому в будущих реализациях транслятора следует предусмотреть анализ такой ситуации.

Примеры использования

Разработками на языке X-Robot занимается томская фирма «Аниматроник» для написания сценариев для кукол-роботов.

Язык XR используется сотрудниками научной группы «РЕВИКОМ» и учёными ТУСУРа для стыковки измерительно-генераторных комплексов с программами на LabVIEW и с многоуровневыми компьютерными моделями, разработанными в среде моделирования МАРС^[1]. Команды представленного языка имеют соответствующие отображения в редакторе многоуровневых компьютерных моделей в виде компонентов, позволяющих управлять работой контроллера, считывать измеряемые им данные, а также формировать и посылать ему соответствующие команды, сформированные на языке X-Robot. На основе данного компонентного подхода разработана компьютерная лаборатория по дисциплине «Автоматизация проектирования систем и средств управления», являющейся базовой дисциплиной для студентов направлений бакалавриата по направлениям «Системный анализ и управление» и «Автоматизация и управление», а также для студентов магистратуры по направлению «Управление в технических системах».

Интеграция со средой моделирования МАРС

Помимо традиционного текстового представления программы, называемой сценарием, для языка X-Robot разработана графическая интерпретация, ставящая для каждой его команды определённый компонент. Графическое формирование сценариев осуществляется в среде моделирования МАРС на логическом уровне многоуровневой компьютерной модели, на объектном уровне которой располагается модель управляемого динамического объекта с включёнными в неё моделями исполнительных и измерительных устройств. Это открывает возможности формирования сценариев управления в графической форме и их предварительной отладки на модели динамического объекта. На визуальном уровне многоуровневой компьютерной модели располагаются управляющие компоненты, с помощью которых пользователь имеет возможность воздействовать на модель объекта и модель сценария, а также компоненты-визуализаторы, осуществляющие отображение для пользователя данных для визуализации, которыми могут быть как значения наблюдаемых переменных объекта, так и их обобщенные параметры-функционалы. В настоящее время разработанный графический язык моделирования сценариев адаптирован к контроллеру X-Mega, но ведутся исследования по его развитию и применению к управляющим контроллерам других типов.

Классы компонентов, из которых осуществляется формирование графических сценариев

Компоненты начала и окончания процессов и подпрограмм. Предназначены для обозначения определённых блоков сценария, а также позволяют отделить блок инициализации от основного потока, циклически выполняющегося при работе сценария.
Класс компонентов взаимодействия сценария с датчиками и исполнителями. Содержит 8 команд считывания информации с датчиков, а также 8 команд передачи команд исполнителям. Каждый датчик и исполнитель задаются своим номером от 0 до 255.
Класс компонентов команд ожидания. Предназначен для остановки некоторого процесса до выполнения определённого события или достижения определённого времени.
Класс компонентов работы с подпрограммами. Содержит команды, позволяющие представить один из процессов сценария в виде подпрограммы и вызвать его из другого процесса.
Класс компонентов арифметических и побитовых операций. Включает в себя компоненты для выполнения основных бинарных арифметических и побитовых операций. К ним относятся: присваивание переменной некоторого значения (MOV); суммирование (ADD), вычитание (SUB), побитовое И (AND), побитовое ИЛИ (OR), побитовое исключающее ИЛИ (XOR), команда перестановки байтов (SWAP), команды побитового сдвига влево (LSL) и вправо (LSR).
Класс компонентов изменения порядка выполнения процесса. Предназначен для осуществления изменения последовательного порядка выполнения команд процесса, ветвления, циклов и т. п.

См. также

Примечания

↑ Дмитриев В. М., Шутенков А. В., Зайченко Т. Н., Ганджа Т. В. МАРС — среда моделирования технических устройств и систем. — Томск: В-Спектр, 2011. — 278 с.

Литература

ATxmega8E5 | Microchip Technology [Электронный ресурс]. — Режим доступа: https://www.microchip.com/en-us/product/ATxmega8E5, свободный (дата обращения: 17.05.2023).
FTDI chip Home Page [Электронный ресурс]. — Режим доступа: http://www.ftdichip.com/, свободный (дата обращения: 17.05.2023).
Автоматизация физических исследований и эксперимента: компьютерные измерения и виртуальные приборы на основе LabVIEW 7 / Под ред. П. А. Бутырина. — М.: ДМК Пресс, 2005. — 264 с.

Ссылки

[1] Дмитриев В. М., Шутенков А. В., Зайченко Т. Н., Ганджа Т. В. МАРС — среда моделирования технических устройств и систем. — Томск: В-Спектр, 2011. — 278 с.

[1]