Михаил Русских
Приводятся типы реакций состояния и рассматривается их роль в рамках пакета visualSTATE, описываются процессы создания проекта, проверки модели, генерации кода и документирования проекта
Реакции состояния
Реакции состояния ведут себя подобно переходам, но в отличие от них реакции не изменяют состояние. К тому же переход обычно имеет исходное и целевое состояния, реакции же ассоциируются только с одним состоянием (целевое не предусматривается). В IAR visualSTATE поддерживаются четыре типа реакций состояния: входные реакции, выходные реакции, реакции действия и внутренние реакции.
Входная реакция представляет собой действие, которое будет выполняться всякий раз, когда автомат будет переходить в подразумевающее эту реакцию состояние. Графически она маркируется ключевым словом Entry, после чего через символ «/» указывается требуемое действие. Например, входная реакция, предполагающая выполнение функции включения дисплея, может выглядеть так: Entry / DisplayOn(). По сути, вместо этого можно указывать необходимое действие над переходом, для которого данное состояние является целевым. Но использование входных реакций характеризуется несколькими преимуществами. Во-первых, проще и удобнее записывать реакции внутри состояния, чем указывать действия над каждым переходом. Во-вторых, это позволяет создавать наглядные модели, поскольку действия определены в них только один раз. В-третьих, при изменении модели действие автоматически присваивается новому переходу. В целом, эти преимущества позволяют снизить вероятность появления ошибок при проектировании системы.
Выходная реакция представляет собой действие, которое будет выполняться всякий раз, когда конечный автомат будет выходить из подразумевающего эту реакцию состояния. Графически она маркируется ключевым словом Exit. Преимущества использования выходной реакции те же, что и входной.
Реакция действия подразумевает под собой деятельность, которая будет выполняться, когда ее родительское состояние станет активным. Причем она будет выполняться до тех пор, пока автомат не выйдет из этого состояния. Реакция действия маркируется ключевым словом Do. В visualSTATE она логически интерпретируется как отдельный конечный автомат, который является параллельным другим возможным конечным автоматам внутри данного родительского состояния. При этом содержимое реакции действия моделируется в новой диаграмме состояний.
Наконец, внутренняя реакция представляет собой переход, который срабатывает без необходимости выхода из текущего состояния. Она указывается также, как и обычное описание перехода, то есть внутри состояния могут быть изображены условная часть и часть действия, разделенные символом «/». Здесь следует помнить, что изображение перехода, целевым состоянием которого является исходное, логически не представляет собой тоже, что и внутренняя реакция, поскольку она никогда не выходит из своего состояния, и, следовательно, не приводит к выполнению каких-либо входных или выходных реакций.
Модули visualSTATE
Пакет IAR visualSTATE представлен рядом программных модулей, позволяющих на основе диаграмм состояния разрабатывать и тестировать приложения реального времени. Эти модули носят следующие названия: Navigator, Designer, Verificator, Validator, Coder и Documenter.
Navigator представляет собой графический инструмент управления проектами, дающий возможность вести свой проект от разработки модели и ее симуляции до генерации кода и документирования. Через Navigator можно легко получать доступ к другим модулям IAR visualSTATE.
Designer служит для разработки диаграмм состояния на основе UML. Впоследствии созданную модель можно верифицировать с помощью инструмента Verificator, а проверить функциональность этой модели, то есть выполнить симуляцию, анализ и отладку, позволит модуль Validator.
Для автоматической генерации кода на основе спроектированной модели служит Coder. И, наконец, Documenter предназначен для создания документированных отчетов.
Создание проекта и работа с ним
Для того чтобы начать работу с IAR visualSTATE следует запустить Navigator. Для создания нового проекта нужно нажать File->New, после чего можно будет выбрать тип начального рабочего пространства (Рисунок 1). Опция Blank Workspace позволит создать пустое рабочее пространство, которое пользователь будет настраивать полностью сам. Благодаря Workspace Wizard для проекта сразу можно задать количество систем, число главных состояний в каждой системе и число областей в каждом состоянии. Simple Workspace обеспечит пользователя начальным набором окон для быстрого старта. Иерархическая структура в данном случае будет содержать проект, систему и главное состояние. Этот вариант наиболее подходящий для знакомства со средой.
 |
|
| Рисунок 1. | Окно выбора типа рабочего пространства. |
Чтобы начать рисовать диаграммы состояний, нужно вызвать модуль Designer, выбрав в меню Project->Designer или нажав F7. В этом модуле, используя инструменты меню ввода Insert Menu (Рисунок 2), можно в окне диаграмм создавать состояния и соединять их необходимым образом. Здесь стоит пояснить назначение каждой иконки в этом меню, то есть, какие элементы они позволяют изображать. Последовательно сверху вниз, начиная с первой после иконки с курсором: простое состояние (Simple State), составное состояние (Composite State), система (System), переход (Transition), изогнутый переход (Curved Transition), ортогональный переход (Orthogonal Transition), переход в себя (Self Transition), начальное состояние (Initial State), историческое состояние (History State), глубокое историческое состояние (Deep History State), конечное состояние (Final State), слияние (Join), разветвление (Fork), переходное состояние (Junction), соединитель (Connector). Ранее были описаны все элементы, кроме последних четырех, которые рассмотрим ниже.
 |
|
| Рисунок 2. | Панель Insert Menu. |
Слияние используется для объединения нескольких переходов, источниками которых являются состояния, находящиеся в различных параллельных областях. Здесь нужно учитывать, что входящие в элемент Join переходы не могут иметь описания. Разветвление, напротив, необходимо для получения из одного перехода двух или более. При этом целевые состояния полученных переходов должны находиться в параллельных областях. В данном случае также переходы, выходящие из элемента Fork, не могут иметь описания.
Элемент Junction используется для создания составных переходных путей между состояниями. Например, его можно задействовать для объединения нескольких входящих переходов в один выходящий. И, наоборот, с помощью него можно разделить один входящий переход на несколько выходящих, имеющих разные сторожевые условия. Инструмент Connector применяется для разделения перехода на несколько фрагментов. Он графически представлен двумя элементами – начальным и конечным. Между этими элементами пользователь может изобразить переход, разделенный обычными состояниями.
С помощью перечисленных выше элементов создавать состояния и соединять их переходами интуитивно просто. Для того чтобы определить поведение перехода, нужно во вкладке View выбрать Element Browser и в нем во вкладке Event следует нажать на кнопку New. Далее можно указать имя создаваемого перехода и при желании добавить некоторые пояснения в поле Explanation. После этого можно вернуться к окну диаграммы состояния. Затем следует двойным щелчком мыши нажать на текстовом поле, принадлежащим переходу, которому нужно указать атрибуты. При этом откроется окно Compose Transition (Рисунок 3), где в секции Rule можно выбрать желаемый элемент описания перехода, например, триггер, сторожевое выражение, условие состояния, выражение действия. В этом же окне в секции Element следует уточнить назначение этого элемента. К примеру, триггер может представлять собой событие, группу событий или сигнал.
 |
|
| Рисунок 3. | Окно Compose Transition. |
Проверка модели
После создания диаграммы ее можно протестировать с помощью инструментов Validator и Verificator. Validator позволяет симулировать работу модели и производить ее отладку. Verificator может проверить правильность полученной диаграммы с точки зрения логики visualSTATE. С помощью него, например, можно выяснить, содержит ли поведение каких-либо переходов противоречия, или имеются ли на диаграмме недостижимые переходы.
Для того чтобы открыть Validator следует в главном меню выбрать Project->Validator или нажать F8. В этом модуле имеются три основных окна: Event, System и Action (Рисунок 4). Нажимая на события в окне Event, можно выполнить пошаговый анализ разработанной системы. В окне System при этом можно наблюдать текущее состояние, а в Action отображаются действия, которые генерируются выбранным событием.
 |
|
| Рисунок 4. | Интерфейс модуля Validator. |
Также анализ и отладку системы можно выполнять графически. Для этого в меню модуля Validator нужно выбрать Debug->Graphical Animation. После этого откроется Designer в режиме симуляции. Оставив открытым Validator и выбирая пошагово события в окне Event, в модуле Designer окружностью красного цвета будет обводиться текущее состояние, а окружностью синего цвета – предыдущее.
Чтобы запустить Verificator, следует в модуле Navigator выбрать Project->Verify System или нажать Ctrl+F10. В окне верификации отображается результат формальной проверки (за функциональную проверку полностью отвечает Validator), которая выявляет ошибки и несоответствия в логике построения системы. Например, с помощью нее можно определить присутствие неиспользуемых элементов, конфликтующих переходов или состояний, в которые конечный автомат может войти, но никогда не выйти (так называемые «dead end»-состояния). В случае отсутствия ошибок в проекте все пункты в окне верификации должны быть помечены галочками зеленого цвета, в противном случае разработчик должен вернуться в Designer и устранить имеющиеся ошибки.
Генерация кода
Для генерации кода на основе созданной модели служит Coder. Как уже указывалось в предыдущей части статьи, разработчику необходимо будет интегрировать полученный код в приложение с помощью специальных функций visualSTATE API. При этом разработчик должен сам позаботиться о написании кода для инициализации микросхемы, работы с портами ввода/вывода, обработки входных сигналов и других задач, не предусматриваемых логикой модели, созданной с помощью visualSTATE. Удобство такого подхода заключается в том, что этот грамотно написанный программистом код может вообще не изменяться в ходе проектирования, поскольку функционирование системы определяет модель visualSTATE.
При необходимости обработки конкретного входного сигнала или события разработчик должен вызвать готовую API-функцию, в которой ему нужно указать этот сигнал или событие в качестве параметра. Обычно в приложениях реального времени в определенные моменты могут возникать разные события. В связи с этим рекомендуется создать обработчик очереди событий по принципу FIFO (первый вошел, первый вышел), что позволит работать с ними последовательно в том же порядке, в котором они были получены. Для этого можно организовать массив, в котором должны храниться имена событий.
Для запуска модуля Coder нужно, находясь в Navigator с активным проектом, на основе которого необходимо получить код, выбрать в меню Project->Code Generate, после чего появится окно с файлом отчета, в котором будут указаны имена сгенерированных файлов и их месторасположение. Далее для создания полноценного исполняемого кода потребуются файлы, сгенерированные с помощью visualSTATE, файлы с visualSTATE API и файлы с кодом, написанным разработчиком. Желательно для этих трех групп создать по каталогу. По умолчанию генерируемые модулем Coder файлы создаются в папке Coder, находящейся в том каталоге, где имеется файл проекта. Чтобы поменять директорию, нужно в меню модуля Navigator выбрать Project->Options->Code generation. Затем во вкладке File output в поле Output directory прописать новый путь.
API-функции подразделяются на два класса: базовые (Basic API) и экспертные (Expert API). Базовые API обеспечивают более быструю работу сгенерированного кода и требуют меньшего объема памяти по сравнению с экспертными API, но экспертные API более универсальны и дают больше возможностей. Первые используются при создании относительно простых приложений, представляющих собой компактные системы управления для обработки сигналов и событий с помощью конечных автоматов. Базовые API желательно задействовать в случае, если в проекте предусматривается одна система. Если в достаточно сложном проекте систем несколько, возможно, будет эффективнее воспользоваться экспертными API. Базовые функции находятся в одном файле, который генерируется вместе с остальным кодом, в то время как экспертные разнесены по нескольким файлам, которые можно найти в папке API, находящейся в каталоге с установленной программой visualSTATE. В том же каталоге в папке doc имеется файл APIGuide.pdf, в котором описаны все API-функции.
Coder также может генерировать код не на ANSI C, а на C++. Для этого в меню модуля Navigator следует выбрать Project->Options->Code generation. В появившемся окне Coder options во вкладке Configuration нужно отметить пункт C++ code generation.
В итоге с помощью подходящего для целевого процессора компилятора можно создать исполняемую программу на основе файлов со сгенерированным кодом, с API-функциями и с кодом, написанным разработчиком.
Документирование проекта
Хотя Documenter не является столь значимым модулем по сравнению с рассмотренными выше, о нем все-таки стоит сказать несколько слов, поскольку он позволяет задокументировать результаты работы над проектом, что, возможно, впоследствии облегчит труд разработчика.
Documenter генерирует отчет, включающий в себя информацию о проекте, функциональной и формальной проверке и полученном коде. Эта информация предоставляется другими модулями и компонуется в определенный структурированный документ, который по выбору пользователя может иметь формат HTML или RTF.
Для создания отчета нужно в меню модуля Navigator с активным проектом, о котором требуется получить необходимые сведения, выбрать Project->Document. После чего начнется процесс сбора информации, которая в итоге будет отображена в окне этого же модуля. Созданный файл с отчетом можно будет найти в папке doc, содержащейся в каталоге с проектом.
Заключение
Большинство встраиваемых приложений реального времени можно разрабатывать на основе конечных автоматов, что делает проект более наглядным и облегчает его дальнейшую поддержку. Поэтому IAR visualSTATE является прекрасным помощником при создании таких приложений. Этот программный пакет позволяет существенно облегчить жизнь инженеров, разрабатывающих внутреннюю логику работы системы, благодаря удобным инструментам проектирования диаграмм состояния и возможностям проверки модели и генерации кода на основе этой модели. Хотя, как было показано в статье, visualSTATE представляет собой не монолитную программу, а набор модулей, каждый из которых решает определенную задачу, человек, разбирающийся в теории конечных автоматов, благодаря интуитивно понятному интерфейсу этого пакета сможет без особых затруднений создать свое приложение реального времени.
