Урок10 Стандартные методы и образцы проектирования

C.Конечные автоматы

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

Конечный автомат (КА) описывается множеством состояний и функцией перехода из одного состояния в другое. Существует много разновидностей КА. Наиболее распространенными являются автомат Мили (Mealy) и автомат Мура (Moore). Автомат Мили выполняет действие при каждом переходе. Автомат Мура выполняет определенное действие в каждом состоянии. Шаблон образца конечного автомата, который есть в LabVIEW, позволяет реализовать любой алгоритм, описываемый автоматом Мура.

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

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

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

Использование КА имеет то преимущество, что после создания диаграммы переходов можно сравнительно легко построить ВП.

Инфраструктура конечного автомата

Для перевода диаграммы переходов на язык блок-диаграмм LabVIEW требуется следующие компоненты инфраструктуры:

• Цикл While — многократно повторяет различные состояния.

Урок10 Стандартные методы и образцы проектирования

•Структура Case — содержит вариант с кодом для каждого состояния.

•Сдвиговый регистр — содержит информацию о переходе.

•Функциональный код состояния — реализует основную функцию состояния.

•Код перехода — определяет следующее состояние в последовательности состояний.

На рис. 11-6 показана базовая структура КА, реализующего алгоритм сбора температурных данных.

1

2

3

Рис. 11-6. Базовая инфраструктура конечного автомата LabVIEW.

Поток состояний диаграммы переходов реализуется циклом While. Отдельные состояния представлены вариантами структуры Case. Сдвиговый регистр цикла While хранит информацию о текущем состоянии и передает ее на вход структуры Case.

Управление конечным автоматом

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

Элемент управления перечислимого типа

Наилучший метод управления инициализацией и переходами КА — это использование элемента управления перечислимого типа. Эти элементы управления широко используются в качестве селектора вариантов в КА, но им присущи определенные недостатки. Если пользователь попытается добавить или удалить состояние в перечислимом типе, то проводники, соединенные с копиями элемента управления, будут разорваны. Одно из решений данной проблемы состоит в том, чтобы создать определение типа, щелкнув правой кнопкой на элементе управления и выбрав typedef в

Урок10 Стандартные методы и образцы проектирования

контекстном меню. После этого все копии данного элемента управления будут автоматически обновляться при добавлении или удалении состояний.

Переход по умолчанию

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

Рис. 11-7. Одиночный переход по умолчанию.

Переход между двумя состояниями

Следующий метод основан на принятии решения о переходе между двумя состояниями. Для него также существует несколько распространенных образцов проектирования. На рис. 11-8 показан переход при помощи функции Select, реализованный в системе сбора температурных данных.

Рис. 11-8. Переход между двумя состояниями.

Этот метод хорошо работает, если заранее известно, что из отдельного состояния возможен переход только в два других состояния. Масштабируемость системы в этом случае ограничена. Если потребуется переходить более чем в два состояния, приведенное решение не будет работать и код перехода придется радикально менять.

Урок10 Стандартные методы и образцы проектирования

Переход между двумя и более состояниями

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

•Структура Case. Используется вместо функции Select. На рис. 11-9 показано, как при помощи Case можно реализовать переход в системе сбора температурных данных.

Рис. 11-9. Переход при помощи структуры Case.

Одним из достоинств структуры Case является самодокументируемость кода. Каждый вариант структуры соответствует элементу перечислимого типа, поэтому код легко читать и понимать. Структура Case хорошо масштабируется. По мере роста программы можно добавлять к каждому состоянию другие переходы, просто добавляя варианты в структуру. Недостаток структуры Case в том, что в каждый момент можно видеть только один вариант. Это ограничение, присущее структуре, не позволяет одним взглядом охватить все возможные варианты переходов.

•Массив переходов. Если требуется видеть больше кода, чем позволяет структура Case, можно поместить все переходы из данного состояния в массив и индексировать этот массив.

На рис. 11-10 показан массив переходов для системы сбора температурных данных.

Рис. 11-10. Массив переходов.

В этом примере массив перечислимых элементов управления индексируется первой логической True-константой в логическом массиве, индекс которой соответствует индексу нового

Урок10 Стандартные методы и образцы проектирования

состояния в массиве перечислимых элементов. Такой образец проектирования позволяет сделать код масштабируемым и легко читаемым. Одним из его недостатков является то, что при разработке необходимо внимательно следить за однозначным соответствием элементов логического массива и элементов массива переходов. Кроме того, функция Search 1D Array возвращает –1, если элемент не найден. Чтобы функция индексирования работала ожидаемым образом, необходимо увеличить выходное значение Search 1D Array на 1. Если на рис. 11-10 элемент не найден, КА остается в состоянии Analyzer.

•State Diagram Toolkit. Еще один образец, реализующий переходы, можно найти в пакете NI LabVIEW State Diagram Toolkit. Этот образец содержит большую структуру Case для каждого состояния и малый цикл While, который перебирает переходы, пока не будет найден нужный. На рис. 11-11 показана реализация системы сбора температурных данных на основе

State Diagram Toolkit.

State Diagram Toolkit добавляет к LabVIEW редактор диаграмм состояний (State Diagram Editor), который позволяет схематически нарисовать логику приложения. После создания визуального представления логики, редактор генерирует код LabVIEW, который будет служить основой приложения.

Примечание LabVIEW State Diagram Toolkit не входит в LabVIEW Professional Development System. Его нужно приобретать отдельно.

Рис. 11-11. Реализация конечного автомата в State Diagram Toolkit.

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

Урок10 Стандартные методы и образцы проектирования

на диаграмме переходов. Большая структура Case содержит по одной поддиаграмме для каждого состояния. Поддиаграммы, в свою очередь, содержат набор инструкций, которые выполняются, когда соответствующее состояние становится активным. Условие перехода проверяется в цикле While, который является частью кода каждого состояния. Этот цикл содержит еще один перечислимый тип (для каждого состояния свой), элементы которого соответствуют состояниям, в которые можно перейти из данного состояния. Элементы упорядочены по приоритету переходов. Переходы с наибольшим приоритетом имеют меньшие числовые значения. При выполнении цикла эти значения по очереди (от меньшего к большему) подаются на вход малой структуры Case. Целые значения индексного терминала преобразуются в тип данных transition. Структура вырабатывает два значения: значение условия перехода для проверяемого перехода, и значение нового активного состояния (в предположении, что для этого перехода условие было определено как TRUE). Как только встречается переход TRUE, цикл останавливается, и КА переходит в следующее активное состояние.

Конечный автомат State Diagram Toolkit должен удовлетворять следующим условиям:

•Всегда должен существовать переход по умолчанию.

•Переход по умолчанию всегда должен иметь низший приоритет, чтобы он проверялся последним.

•Условием перехода по умолчанию всегда должно быть TRUE. Для этого перехода с выходом условия можно соединить логическую константу.