Читать Часть 1
От моделей приложений к исполняемому файлу
Специалисты домена разрабатывают модели, соответствующие заданию и цели DSL, позволяющие фиксировать независимые от платформы робототехники требования, связанные с действиями, свойствами и задачами робота и мира, в котором он работает. Полная роботизированная система моделируется агентом-роботом, агентом мира, множеством задач, множеством целей, а также моделью домена UML/P CD. Для устранения разрыва между этими концептуальными моделями и реализациями с учетом специфики платформы используют генераторы кода, создающие классы, содержащие информацию, полученную с помощью моделей, соответствующих различным DSL и реализациям компонентов, для некоторых компонентов опорной архитектуры, смоделированной на языке описания архитектуры MontiArcAutomaton. Генераторы кода создают класс задачи для каждой модели задачи и целевой класс для каждой модели цели. Каждый класс задач связан с целевыми классами, сгенерированными для целей, на которые ссылается модель задачи. Задачи и цели могут быть параметризованы параметрами типов, определенных в импортируемых ими доменных моделях. Задачи ссылаются на параметры в своих целях, а цели ссылаются на свои параметры в своих предикатах. Далее, генераторы создают класс для каждого типа домена, смоделированного компакт-диском UML/P CD. Примеры классов типа домена кодируют информацию во время выполнения. Экземпляры заданий могут быть переданы в справочную архитектуру для начала их выполнения.
Эталонная архитектура включает в себя компоненты с доменными реализациями, созданными на основе моделей агентов, типов доменов и целей, а также компоненты, не зависящие от домена, с предустановленными реализациями.
Некоторые из сгенерированных компонентов полностью реализованы, в то время как другие должны быть дополнены кодом ручной работы. Реализации компонентов ActionExecuter и StateProvider генерируются на основе доменных типов и моделей агентов, но имеют зависимости от артефактов кода, которые должны быть изготовлены вручную экспертами по робототехнике. Для этого генераторы кода создают интерфейс IRobot из агента-робота, а также интерфейс IWorld из типов домена и агента мира. Для завершения реализации компонентов эксперты по робототехнике обеспечивают реализацию этих интерфейсов для взаимодействия с конкретными используемыми платформами.
Это позволяет отделить планирование логических задач от фактического выполнения и позволяет повторно использовать задачи, цели и эталонную архитектуру с различными роботами и в разных мирах.
- Компонент StateProvider вызывает методы, генерируемые для свойств и типов доменов, для запроса текущего состояния системы во время выполнения, т.е. для вычисления текущих свойств владения и опроса существующих объектов, необходимых для планирования.
- Компонент ActionExecuter вызывает методы, генерируемые для действий, чтобы инициировать их физическое выполнение. Такой метод может, например, делегировать выполнение действия соответствующему промежуточному программному обеспечению.
Генерируемые интерфейсы абстрактны из специфических для платформы деталей реализации. Таким образом, модели и сгенерированные эталонные архитектуры могут быть повторно использованы в различных, концептуально схожих приложениях. Только зависящие от платформы реализации генерируемых интерфейсов должны быть адаптированы к специфическим для платформы технологиям. Это облегчает разделение проблем домена, зафиксированных моделями, соответствующими DSL, и разработки программного обеспечения для конкретных приложений, скрытых за сгенерированными интерфейсами. Абстрагирование от деталей реализации платформы особенно позволяет легко повторно использовать задачи и цели с платформами, обладающими разными возможностями: выполняется ли действие с помощью гуманоидного робота или беспилотного летательного аппарата, может быть неактуальным для концептуальных задач.
Исполнение заявки
Специалисты по интеграции моделей могут без особых усилий расширить архитектуру программного обеспечения RefArc, подключив к нему порты. Интерфейс RefArc состоит из одного порта для приема заданий и другого порта для передачи информации о состоянии. При инстанцировании задачи значения подставляются под параметры задачи и тем самым под параметры целей, из которых она состоит. После инстанцирования задачи ее выполнение может быть инициировано с помощью интерфейса базовой архитектуры. Пространство объекта, обусловленное параметрами задач и целей, потенциально бесконечно велико. Кроме того, типы областей и свойства субъектов могут моделировать бесконечно много экологических ситуаций. Таким образом, практически невозможно рассчитать все планы для всех возможных случаев цели до начала выполнения. Поэтому для достижения каждой отдельной цели компонент преобразует модели цели, объекта и домена, а также информацию о текущей экологической ситуации, полученную объектами, кодирующими информацию о времени выполнения.
Исследователи оценили эталонную архитектуру в условиях, когда удаленный оператор может получить доступ к камере робота и датчикам приближения, чтобы принять управление роботом. Если планирование выполнено успешно, контроллер пытается выполнить действия, указанные в плане, полученном от планировщика компонентов, в порядке их перечисления. Если действие успешно выполнено и соответствующий план содержит больше действий, контроллер пытается выполнить следующее действие. Если успешно выполненное действие является последним действием плана, то соответствующая цель выполняется. В этом случае система пытается выполнить следующую задачу, если таковая имеется, или готова приступить к выполнению новой задачи.
Применение робототехники iserveU
Была проведена обширная разработка программного обеспечения на основе моделей для комплексных приложений робототехники обслуживания на примере приложений для логистики больниц. Исследовательский проект осуществлялся с участием трех партнеров из научных кругов и трех промышленных партнеров из различных областей робототехники. Они протестировали всю систему, включая DSL, эталонную архитектуру и новое оборудование для робототехники в течение недели в больнице.
Специалисты домена представили 7 моделей задач, 5 целевых моделей, 2 модели агентов, содержащие 7 свойств и 6 действий, и 1 модель домена с несколькими классами. Эксперты по интеграции разработали 10 моделей MontiArcAutomaton для эталонной архитектуры и робототехники, подключив систему к платформе, оснащенной инфракрасными датчиками и лазерными сканерами. Для целей настоящей оценки эталонная архитектура была расширена за счет включения в нее компонентов, специфичных для конкретных приложений. Это позволило взаимодействовать с удаленным оператором, а также с персоналом больницы через пользовательский интерфейс, работающий на планшетном ПК, установленном на роботе. Система использовалась в повседневной больничной практике в динамичной среде, т.е. работала между пациентами и обслуживающим персоналом.
Для оценки языков моделирования использовались три задачи:
1. Соберите предмет из определенного места и доставьте его в пункт назначения.
2. Проводите человека из одного места в другое.
3. Следуйте за конкретным человеком.
Из этого следует, что наиболее часто использовалась задача сбора предметов. Это может быть связано с тем, что медицинские работники проявляют большую осторожность при взаимодействии пациентов с роботами. Расширение функциональности в сценарии просто увеличивает количество моделей задач и целей. Однако изменение используемой платформы или среды может потребовать адаптации действующих лиц.
Итак, была представлена модельная инфраструктура для спецификации и выполнения задач робототехники, включающую в себя коллекцию декларативных DSL для их разработки. Их модели трансформируются в реализации расширяемой программной архитектуры управления и сертификации, использующей современное планирование для решения задач в последовательности действий. С помощью небольших интерфейсов, созданных на основе моделей агентов, архитектура взаимодействует с базовой платформой робототехники, которая поддерживает повторное использование опыта в области приложений в форме задач, целей, агентов и доменных моделей с различными роботами. Специалисты успешно оценили внедрение эталонной архитектуры с тремя задачами в больничной среде и, следовательно, разработка программного обеспечения робототехнических приложений выигрывает от разделения задач на основе моделирования.
