Створення динамічних людино-машинних інтерфейсів для систем промислового керування за допомогою Adobe Flash

Билл Грэхем (Bill Graham), Пол Леру (Paul N. Leroux)
QNX Software Systems

Введение

Благодаря разработкам компании Adobe Systems, более 300 миллионов мобильных устройств имеют графический пользовательский интерфейс (ГПИ/GUI), созданный на основе технологии Adobe Flash. Предполагается, что к 2010 году это число превысит один миллиард. Разработчики встраиваемых систем, которые используются в промышленности, медицине, автомобилях, тоже начинают обращать внимание на Flash-технологию поскольку с ее помощью можно сократить время на разработку ГПИ почти на 50%. Ранее команды разработчиков ПО должны были переводить имеющиеся у них прототипы ГПИ на язык С, С++ или Java – процесс трудоемкий, занимающий многие недели и месяцы. Сейчас же можно с помощью высокоуровневых инструментов технологии Flash проектировать, создавать, и запускать компоненты ГПИ непосредственно на встраиваемых Flash-плейерах, без необходимости писать графические коды.

Технология Adobe Flash стала завоевывать популярность среди разработчиков встраиваемых систем по нескольким причинам.

• Более миллиона разработчиков графических приложений по всему миру используют авторские разработки инструментальных средств технологии Flash, составляющие сейчас обширный фонд накопленного опыта, который могут заимствовать другие разработчики. Более того, тысячи существующих Flash-компонентов для рынка настольных систем и мобильных телефонов можно легко интегрировать в свои разработки.
• По сравнению с Flash-плейерами для настольных систем встраиваемые Flash-плейеры от Adobe (например, Flash Lite 3) требуют меньше памяти и обеспечивают более быстрое воспроизведение графики с меньшей загрузкой ЦПУ.
• ЦПУ и графические микросхемы для встраиваемых систем сейчас поддерживают частоты смены кадров, требуемые для воспроизведения Flash-разработок на дисплеях VGA и на дисплеях большего размера. Например, для того, чтобы получить плавное воспроизведение анимационной картинки на частоте 10 кадров в секунду, в системе необходимо иметь ЦПУ, работающий на скорости 100 миллионов команд в секунду (MIPS) – это значительно меньше предлагаемого сейчас значения в 300 MIPS или чуть более для большинства ЦПУ встраиваемых систем.

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

Безграничные возможности

В отличие от традиционных языков программирования и инструментальных средств во Flash-технологии предоставляется специальная среда для работы с графикой и мультимедиа, предлагаются почти безграничные возможности для реализации замыслов пользователя. В результате, разработчики встраиваемых систем могут создавать анимационные фрагменты и специальные эффекты в течение традиционно необходимого временного интервала. Кроме того, наличие сертификата для Adobe Flash Player гарантирует, что Flash-приложения буду вести себя одинаково на различных аппаратных платформах. В результате компоненты ГПИ могут создаваться единожды, после чего их можно устанавливать и использовать на различных системах, ориентированных на различные рынки и на различные ценовые категории.

Тем не менее, чтобы удовлетворять требованиям разработчиков встраиваемых систем, необходимо при реализации Flash-приложений ответить на несколько вопросов:

• Как разработчики смогут интегрировать Flash-контент и другие графические программы такие, например, как веб-браузеры или приложения визуализации 3D-графики? Можно ли на одном графическом дисплее визуализировать одновременно Flash-приложение и обычную 2D/3D-графику, несмотря на то, что они используют различные модели рисования?
• Как сделать так, чтобы поведение интерфейса пользователя, основанного на Flash-технологии, было бы единообразным при всех условиях загрузки? Для большинства встраиваемых систем ГПИ должен в любое время быстро реагировать на действия пользователя, что требует соответствующего управления уровнем приоритета и обеспечения производительности при работе в реальном времени.
• Как сделать, чтобы интерфейс пользователя на базе Flash-технологии был надежным? Сможет ли система контролировать сбои и успешно выходить из них? Сможет ли Flash-контент надежно сосуществовать с критическими процессами?
• Как разработчики могут контролировать взаимодействие Flash-контента со службами операционной системы (ОС), например, с аудио-выходом, сенсорным экраном, драйверами критических ко времени устройств, с файловыми системами и сетевыми стеками?

Интеграция Flash-программ с другими графическими приложениями

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

На рис. 1 дан пример использования Flash-технологии в качестве администратора экрана. Программа слева – это Flash-плейер, с помощью которого непосредственно в пространство приложения были загружены два компонента: графическая 2D-библиотека и графический драйвер, который управляет графическим оборудованием. Загрузив драйвер таким путем, оказывается возможным осуществлять непосредственное управление графическим оборудованием прямо из программы, а, следовательно, повышается производительность системы. Справа "родная" программа ОС рисует трехмерную картинку средствами OpenGL ES, стандартного интерфейса API для трехмерных приложений во встраиваемых системах. Как и Flash-программа, интерфейс API также напрямую управляет графическим оборудованием, обеспечивая высокую производительность вывода.

Рис. 1 — Интеграция Flash-приложений с другими графическими приложениями. В данном примере программа, основанная на Flash-технологии, управляет приложением для рисования трехмерных изображений, основанным на использовании функций 3D API пакета OpenGL ES.

Многие кристаллы для встраиваемых систем в настоящее время поддерживают работу с несколькими слоями, что дает возможность Flash-программам эффективно сосуществовать с другими графическими приложениями на одном и том же дисплее. На рис. 1 Flash-плейер прорисовывает слой переднего плана и управляет отображением трехмерных картинок на фоновом слое. Чтобы сделать видимым трехмерное полотно, разработчик использовал на слое переднего плана технику хроматического ключа (chroma key). Поскольку визуализация трехмерного изображения и Flash-картинки происходит в различных слоях, то графический контроллер может обновить трехмерную картинку без перерисовки Flash-контента. Это уменьшает мерцание изображения и снижает нагрузку на ЦПУ.

Разработчик может также использовать методы альфа-сопряжений (alpha blending) и хроматического ключа для того, чтобы сделать Flash-компоненты полупрозрачными, а затем разместить их прямо поверх другого контента. На рис. 2 можно видеть полупрозрачное окно с предупреждением поверх анимированной консоли управления, что демонстрирует подход к более плотному размещению информации на малом экране.

Обеспечение предсказуемого времени отклика

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

Рис. 2 — ГПИ, где используется альфа-сопряжение для отображения полупрозрачного окна с предупреждением (Warning) поверх анимированной консоли управления. Поскольку визуализация консоли и окна с предупреждением реализованы в разных слоях, графический драйвер может делать перерисовку консоли без перерисовки окна с предупреждением. Полупрозрачные компоненты дают возможность размещать информацию на малом экране более плотно.

При таком подходе некоторая программа, которой нужно получить доступ к графической среде (например, Flash-плейер для показа документального видео), посылает запрос администратору дисплея. Администратор принимает или отклоняет запрос в зависимости от того, имеет ли программа достаточный для доступа уровень разрешений. При разрешении доступа программе выделяется некоторый мутекс - элемент блокировки взаимного исключения (mutual exclusion lock, mutex). Когда в программе нужно выполнить рисование чего-либо на экране, то она ожидает получения разрешения через мутекс, запускается внутри него, выводит графические данные непосредственно на графическую микросхему и освобождает мутекс. Каждая из графических программ претендует на захват мутекса в зависимости от ее приоритета. Поскольку графические программы, имеющие самый высокий приоритет, всегда будут захватывать мутекс первыми, то такой подход гарантирует необходимый уровень производительности реального времени и быстрое реагирование на действия пользователя.

Но всё же при тяжелых условиях загрузки ЦПУ – например, когда система управляет многими программными потоками или выполняет синхронизацию тысяч точек данных – производительность ГПИ может спуститься до недопустимого уровня. В закрытых системах, где можно контролировать все случаи использования системных ресурсов, у команды разработчиков есть возможность предотвратить такие провалы в производительности. А вот в системах, где осуществляется динамическая поддержка нового контента или приложений, предотвратить такие ситуации становится значительно сложнее.

Одним из путей разрешения этой проблемы является использование технологии разделения времени. Используя ее, системный разработчик помещает программные компоненты в раздельные временные секции и выделяет для каждой секции гарантированный процент времени из ресурсов ЦПУ. Например, разработчик выделяет 20% ресурсов ЦПУ на работу ГПИ, 20% на управление работой запущенных процессов, 30% на синхронизацию с базой данных и так далее. При таком подходе пользователь получит реакцию от ГПИ за гарантированное время, независимо от того, насколько сильно загружают ЦПУ процессы в других секциях, даже если эти процессы имеют более высокий приоритет.

Часто процессы в секции не расходуют все выделенные на конкретную секцию циклы ЦПУ. В ОСРВ QNX® Neutrino® планировщик управления выделением времени может разрешить эту проблему, динамически перераспределяя неиспользуемые циклы ЦПУ тем секциям, где это неиспользуемое процессорное время может принести пользу. Такой подход позволяет ГПИ, основанному на Flash-технологии, работать более четко, и быстро, когда оказывается доступно дополнительное процессорное время. С другой стороны, и другие программные подсистемы смогут работать быстрее, когда ГПИ не использует выделенный для него бюджет ЦПУ.

Управление ситуациями отказа в работе

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

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

Управление взаимодействиями

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

• используя Flash-контент, запускать и управлять другим Flash-контентом – для этого нужен механизм, который позволяет главному Flash-приложению загружать, размещать, запускать и останавливать работу Flash-приложений;
• разрешать взаимодействие между Flash-контентом и службами ОС – для этого нужен механизм ретрансляции запросов данных.

На рис. 3 дан пример реализации таких взаимодействий. Ядро HMI (человекомашинного интерфейса) дает возможность главному Flash-приложению управлять вторичными Flash-приложениями (просмотр контрольных точек данных, администратор системной конфигурации и т.д.), пока сервер HMI предоставляет шлюз к исходным службам ОС.

Рис. 3 — Архитектура управления взаимодействиями между несколькими Flash-приложениями, а также между нескольким Flash- и не-Flash-приложениями.

Рассмотрим, как такой поход может быть применен к приложениям видеоплейера. Если посмотреть на рис. 4, то можно заметить, что интерфейс пользователя состоит из следующих частей:

• зона просмотра, где показывается видеоизображение (верхняя половина экрана);
• собственно Flash видеоплейер, где есть органы управления проигрыванием, перехода к следующему, предыдущему кадру и т.д. (средняя часть экрана);
• ядро HMI, написано на основе Flash-технологии, с помощью которого происходит управление кнопками меню (нижняя часть экрана)

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

Рис. 4 — В этом примере ядро HMI на базе Flash управляет кнопками меню (показаны в нижней части экрана), в то время как Flash-видеоплейер запускается на уровне захвата видеоизображения.

Превосходная смесь

Подводя итоги, можно сказать, что команды разработчиков встроенного ПО могут сохранить производительность и надежность в системах реального времени, используясилу и преимущества Adobe Flash для сокращения времени выхода продукции на рынок. Более того, разработчики могут создать структурные конструкции на основе компонентов HMI, которые смогут эффективно сочетаться с приложениями 2D/3D, Flash-приложениями и приложениями мультимедиа.