Модельно-ориентированная разработка системы управления беспилотным летательным аппаратом

В.В. Макаров,
с.н.с, к.т.н., makarov@ipu.ru
ИПУ РАН, г. Москва

В докладе рассматривается модель сложной технической системы, разработанной по технологии MDD, на основе когерентного набора ряда UML-диаграмм. Это модель беспилотного летательного аппарата (БЛА) – иерархическая система для целенаправленного управляемого перемещения в атмосфере или космосе.

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

Описана модель БЛА UML-диаграммами, с точки зрения требований к проекту, системная архитектура, организация всей модели системы, диаграммы объектов, диаграммы вариантов использования, диаграммы состояний. Используя средства быстрого создания прототипов, визуальной отладки и выполнения модели, с помощью IBM Rational Rhapsody удалось получить конечные продукты, соответствующие заявленным требованиям. В итоге удалось сгенерировать исполняемый код на С++.

Тhe model of the complex technical system developed on technology MDD, on the basis of a coherent set of some UML-diagrams is considered. It is model of a Unmanned Aircraft Vehicle (UAV) - hierarchical system for purposeful operated moving to atmosphere or space.

UAV hand-operated - the dynamic object, continuous change of a condition is described by mathematical model of flight UAV in the form of the differential equations set. Into model are entered a number of simplifications of movement. For simplification of integration of the equation of movement of center of inertia UAV it is convenient to use initial starting system of co-ordinates at the moment of start which does not change further the orientation concerning absolute space (stars), i.e. is inertial. The direction of axes of this system of co-ordinates can be set onboard UAV.

Model UAV by UML-diagrams, from the point of view of requirements to the project, system architecture, the organization of all model of system, the diagram of objects, diagrams of variants of use, the diagram of conditions is described. Using means of fast creation of prototypes, visual debugging and model performance, by means of IBM Rational Rhapsody it was possible to receive the end-products corresponding to declared requirements. As a result it was possible to generate an executed code on C++. .

Объектно-ориентированный MDD/MDA-подход

Model Driven Development (MDD) – разработка, управляемая моделями. При этом, модель – главный артефакт разработки, из которого генерируются остальные артефакты и исполняемый код. Модель – это абстрактное описание программного обеспечения, которое скрывает информацию о некоторых аспектах и упрощённо описывает остальные. Одной из наиболее известных разновидностей концепции «разработки, управляемой моделями» (MDD) на сегодняшний день является концепция модельно-ориентированного подхода к разработке программного обеспечения (MDA).

Model Driven Architecture (MDA) – «архитектура, управляемая моделью» предлагает новый интегральный подход к созданию информационных систем. Сутью подхода является построение абстрактной метамодели управления и задания способов её трансформации в поддерживаемые технологии программирования.

Основная идея MDA состоит в том, что для разработки приложения, изначально должна быть построена подробная и формально точная модель, которая определяет состав, структуру и поведение будущего программного продукта. Из этой модели генерируется программный код приложения. Такая модель создается не на языке программирования, а посредством языка унифицированного моделирования (Unified Modelling Language, UML) и является независимой от применяемой технологии (Platform Independent Model, PIM). PIM привязана к постановке задачи и предметной области, и при этом, не зависит от других деталей, таких как реализующий язык программирования, платформа под которую разрабатывается приложение, тип базы данных и т.п. MDA не специфицирует, на каком языке описана PIM, но требуется, чтобы описание происходило на формально определённом языке и чтобы он был пригоден для автоматической обработки.

После построения PIM, определяются детали реализации – язык программирования, платформа, архитектура, и на основе этого выбора, PIM трансформируется в платформенно-зависимую модель PSM (Platform Specific Model). PSM обеспечивает интеграцию PIM с одной или несколькими технологиями разработки ПО.

Наконец, на заключительном этапе на основании PIM и PSM с помощью инструментальных программных средств генерируется исполняемый код приложения. В случае наличия нескольких PSM процедура генерации может проводиться несколько раз — для каждой из используемых платформ. Хоть преобразование и происходит автоматически, выбор их настроек остаётся за разработчиком.

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

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

Преимущества, которые дает MDA разработчикам, очевидны: локализация всей логики приложения в одном месте (в модели), автоматическая генерация кода, баз данных и графического интерфейса пользователя. Поэтому, в настоящее время всё значимее становится не конкретная реализация продукта, а модель, разработанная на стадии проектирования. Современные средства проектирования в качестве языка для описания моделей используют унифицированный язык моделирования UML.

Описание разрабатываемой системы

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

Летательный аппарат и его система управления – неразделимые вещи, поэтому, характеристики и специфические особенности БЛА определяют качественные показатели системы в целом.

Система беспилотного летательного аппарата (СБЛА) позволяет выполнять полёты средней дальности над территорией. В системе используется высоконадёжный ЛА среднего радіуса действия, способный нести на борту различное оборудование для применения в наземных, воздушных и морских операциях. СБЛА состоит из ЛА и наземной Системы Планирования и Управления Операциями, которые связаны каналом передачи данных.

Одной из наиболее важных задач в работе инженеров является определение требований к разрабатываемой системе. Ошибки в требованиях – это один из наиболее серьёзных видов стратегических ошибок в системах и наиболее дорогие в исправлении, поскольку вносятся они на ранних стадиях, а обнаруживаются, как правило, на поздних стадіях проекта, оказывая влияние на многие компоненты системы. Рассмотрим основные компоненты БЛА и требования предъявляемые к ним.

1. Беспилотный летательный аппарат – универсальный летательный апарат многоцелевого назначения и многоразового использования. Он предназначен для выполнения полётов со скоростью до 280 км/ч при движении по маршруту. Он способен нести бортовое оборудование в процессе полёта, продолжительностью более 24 часов. БЛА предназначен для беспрепятственных полётов в условии ограниченной видимости. При управлении с наземной станции он способен выполнять сложные полётные задания с различными операционными целями. Средства связи с БЛА являються устойчивыми к помехам, однако при применении средств радиопротиводействия помехозащищённость средств связи не гарантируется. Команды управления летательным апаратом должны бать зашифрованы, а данные телеметри когут бать сжаты, а не зашифрованы. Дальность полёта летательного апарата определяется зоной прямой видимости. БЛА оснащён средствами навигации, а также полностью управляем с наземной станции. Для БЛА не требуется специализируемых средств для выполнения взлёта и посадки, он может использовать короткую полосу для автоматического взлёта и посадки.

2. Система Планирования и Управления Операциями. Управление летательным апаратом должно включать передачу навигационных команд, которыми когут быть: изменение угла тангажа, угла рыскания, тяги двигателя и другие. Стабильность полёта поддерживается самим летательным аппаратом. Система планирования и управления операціями позволяет в реальном времени отображать получаемые данные.

3. Подсистема передачи данных БЛА. Подсистема передачи даннях используется для обмела данням и между БЛА и СПУО. Все команды для БЛА должны бать зашифрованы для предотвращения возможности неприятельського вмешательства в операцию, телеметрические данные, передаваемые в режиме реального времени также шифруются. Подсистема передачи даннях является системой связи в зоне прямой видимости, она является помехоустойчивой, хотя не снабжена системой противодействия помехам.

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

В UML отсутствует отдельная сущность с названием «требование». Хотя варианты использования, диаграммы последовательности, конечне автоматы, диаграммы деятельности и ограничения разных видов могут использоваться для моделирования свойств требований, отдельная сущность с названием требование отсутствует. По этой причине дання сущность была добавлена в языке SysML (Systems Modeling Language – Язык Моделирования Систем), а IBM Rational Rhapsody (использовалась версия 8.0) позволяет нам добавлять элементы требований в моделях.

На следующем рисунке (рис.1) приведён пакет требований к проектируемой системе БЛА.

В сложных проектах обычно начинают с более абстрактной модели, описывающей алгоритмические и архитектурные аспекты, а затем создают более подробную модель, содержащую информацию необходимую для синтеза. Более абстрактные модели легче понимать, читать и отлаживать [1-3]. Такую более абстрактную модель часто называют прототипом модели устройства или системы. Эта модель имеет большое значение при взаимодействии разработчиков и заказчика, т.к. она помогает заказчику увидеть и понять, какую систему действительно нужно, а главное, можно создать. С помощью прототипа уточняется техническое задание на систему.

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

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

рис. 1. Пакет требований к системе БЛА.

Рассмотрим на следующем рисунке (рис.2) из пакета требований (рис.1) Требования к проекту.

рис. 2. Требования к проекту СБЛА.

Взаимодействие пользователя с системой управления проиллюстрировано на рисунке 3.

рис. 3. Взаимодействие удалённого пилота (оператора) с полезной нагрузкой системы БЛА.

Проектирование и реализация

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

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

Архитектура проекта определяется пакетами, которые помогают логически разделить проект на подсистемы.

При построении модели СБЛА на верхнем уровне абстракции находилось два пакета – пакет требований к проекту (рис. 1) и требования к проекту БЛА (рис.2). Система располагалась в двух подпакетах – Пакет наземной станции управления и Пакет БЛА. Архитектура проекта изображена на рисунке 4. Подсистема блока связи не обособлялась в отдельный пакет, а отдельные её части располагались на наземной базе и на летательном аппарате.

Окончательное тестирование и отладка модели

После разработки всех схем системы, следует выполнить комплексную отладку всей модели. Для этого в Rhapsody можно использовать анимированные версии диаграмм, расстановку breakpoint’ов и выполнение модели «по шагам».

В среде разработки имеется встроенный генератор тестов Test Conductor. Это средство автоматически создаёт так называемые test-case для модели и прогоняет через них всю модель. Система, как единый инструмент длявыполнения огромного количества самых разнообразных тестов, при охвате всего цикла разработки ПО позволяет в автоматическом режиме фиксировать обнаруженные дефекты, управляя каждым этапом цикла; расширять и параметризовать саму систему автоматического тестирования, исходя из объёма имеющихся ресурсов, количества, типа и назначения тестов и тестируемых продуктов. Дружественный пользовательский интерфейс позволяет легко выполнять множество операций по управлению и контролю действительного статуса ожидаемых/исполняемых/выполненных тестов, планированию тестов на разных версиях продукта с установкой приоритетов, параметризации системы в зависимости от окружения и условий функционирования и многое другое.

рис.4. Архитектура проекта СБЛА.Пакет наземной станции управления: 1.Класс наземной станции управления;2.Класс блока связи на наземной станции;3.Класс генератора ключей;4.Класс шифратора команд наземной станции;5.Класс дешифратора параметров БЛА. Пакет БЛА: 6.Класс летательного аппарата;7.Класс блока связи летательного аппарата;8.Класс дешифратора команд БЛА;9.Класс шифратора параметров БЛА.

рис.5. Интерфейс системы управления БЛА.

При использовании автоматических тестов для контроля качества, вне всякого сомнения, разработчик получает выигрыш по сравнению с ручным тестированием. Благодаря автоматическому тестированию покрытие кода равно 100%, что немаловажно в системах управления, таких как система управления СБЛА, т.к. она является критической системой и малейшая ошибка в ПО способна привести к краху всей системы. К тому же, автоматизированное тестирование экономит время разработчика, пока выполняются тесты, он может заниматься другими делами.

Написание документации

При создании программного продукта значимым моментом является написание документации по проекту. Как правило, при создании программного продукта разработчики не уделяют должное внимание отчетам и написанию документации по своей разработке, не смотря на необходимость написания документации. Отсутствие документации для конкретного программного продукта не допустимо. При подготовке документации не следует забывать, что она разрабатывается для того, чтобы ее можно было использовать, и потому она должна содержать все необходимые сведения. Документирование программного обеспечения осуществляется в соответствии с Единой системой программной документации (ГОСТ 19.ХХХ). Так ГОСТ 19.101-77 устанавливает виды программных документов для программного обеспечения различных типов. Поэтому возможность создание документации непосредственно в среде разработки является неоспоримым преимуществом среды Rational Rhapsody. В этой среде есть возможность сгенерировать документацию для всех элементов системы с помощью инструмента Reporter Plus.

Используя Reporter Plus, можно выбрать формат выходного отчёта генерируемой документации. Это может быть: файл Word, HTML, PowerPoint, Rtf или просто текстовый файл.

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

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

Литература

1. Грушин А.И. Верификация в вычислительной технике. (Электронный ресурс). – Режим доступа: http://www.ipmce.ru/about/press/popular/potencial4-2007.

2. Douglass B. P. Real-Time UML Workshop for Embedded Systems. – Oxford, UK, Elsevier Inc., 2007. p.408.

3. Зыль С.Н. Проектирование, разработка и анализ программного обеспечения систем реального времени. – СПб.: БХВ-Петербург, 2010. 336с.