В контексте автоматного программирования ВКПа опять вспомним про SimInTech. Представляется удобным и наглядным создать аналог проекта из в SimInTech, который основан на базе элементов ее библиотеки «Конечные автоматы». Так мы осваиваем проектирование в рамках данных сред и заодно проведем сравнение технологий автоматного программирования. Ну, а за основу для достижения поставленных целей возьмем проект «Нагреватель» из SimInTech.
Выбранный проект хорош тем, что описан детально в статье, позиционируемой как введение в автоматное проектирование в SimInTech. По этому пути пойдем и мы. Наш вариант ее решения в виде двух конечных автоматов приведен на рис. 1. По форме это графическая форма обычных классических конечных автоматов, к входным и выходным канала которых привязаны соответствующие предикаты и действия. В целом же это сеть автоматов, решающая поставленную задачу.
Графы на рис. 1 представляют собой модель автоматной программы в ВКПа. И уже на уровне модели видны основные отличия. Кратко или, так сказать, в первом приближении они сводятся к следующему. На уровне отдельного процесса (автомата) мы сразу разделяем программу на части. Это операторы, названные предикатами и действиями, и управление программы — собственно модель конечного автомата (КА). А на уровне самой программы в общем случае это сеть из автоматов. В соответствии с данным ранее определением все это вместе и составляет автоматную программу.
Алгоритмы в автоматной форме с расшифровкой операторов на некотором условном языке по сути представляет собой документ, предназначенный для последующей реализации модели. Для этого мы можем выбрать язык С++, среду МАТЛАБ или, как в статье, SimInTech. Мы выбираем ВКПа и ее диалоговые средства реализации автоматов. Почти все они, а это диалоги настройки среды, создания и отладки автоматов, представлены на рис. 2.
На рис. 2 приведена лишь часть решения — автоматная модель объекта управления — Модель нагревателя. В нашем случае вполне достаточно возможностей диалогов среды ВКПа, чтобы не пришлось прибегать к ее внутреннему языку программирования С++. И пусть не смущает обилие диалогов. Их число, размеры и положение — это все входит в несложную процедуру конфигурирования приложения.
Если модель на рис. 2 сравнить с решением в SimInTech, показанном на рис.3 (стрелки показывают основные пути раскрытия субмоделей проекта), то последнее вроде бы даже вне конкуренции. Однако, не будем в порыве ревности оспаривать почти очевидное, вникая при этом в детали описания и представления компонент проекта, а … просто продолжим дальше рассматривать процедуры создания автоматов в ВКПа и, что называется, по ходу разбираться и сравнивать. Собственно это и есть наша основная цель.
Среди стандартных диалогов ВКПа мы имеем, во‑первых, диалог управления автоматными пространствами (см. диалог «ядро: автоматные пространства» на рис. 2), в котором отражен список автоматных пространств, их настройки и текущее число автоматов в каждом из них. А каждое автоматное пространство — это своеобразная заготовка для сети автоматов в едином времени.
Для модели нагревателя мы создали свое автоматное пространство — HeaterModel, в котором, используя диалог создания автоматных переменных (см. «ядро: автоматные переменные» на рис.1), создали два автомата с именами К/s и Key (см. также рис. 2). Перед этим, правда, создали необходимые константы — 1 и 0.1.
Замечание. Если в SimInTech мы можем определить, похоже, дискретный шаг только в целом для проекта, то в ВКПа это можно сделать для каждого автоматного пространства.
Для настройки автоматов используется диалог с именем DIRVariables::FDIRVariables — диалог управления переменными среды (созданный в ней автомат в терминах ВКПа тоже переменная). При этом K/s — это готовый интегратор (он, напомним, тоже автомат) из библиотеки ВКПа, а Key — автомат, созданный нами.
Отдельно автомат Key показан на рис. 4 (см. также графовую модель автомата Key на рис. 1) в форме диалога с именем Key::FAutomaton. Он порожден от библиотечного блока FAutomaton, который, кстати, тоже автомат (в ВКПа фактически все алгоритмы и в том числе компоненты библиотек — автоматы).
С помощью диалога класса FAutomaton создаются компоненты автоматной программы. Среди них выделяются: 1) таблица переходов автомата, 2) предикаты и 3) действия. В результате Key представляет собой автомат с одним состоянием — s1 и двумя петлями, которые в зависимости от значения тестовой переменной OnOff (предикат x1 — OnOff?) ) выполняют действия y1 (K/x.x:= 1) или y2 (K/x.x:= 0.1). Так изменяется значение входа x блока (интегратора) K/s. Он примет значение 1 при нагреве и 0.1 при остывании воды.
Изменить значение входа автомата, как и любой другой переменной среды и/или ее параметры, можно в динамике в рамках диалога InputCanals::FSetInputVar, а отследить значение переменных — в диалоге типа OutputsCanal::FViewOutputCanal (см. рис. 5). Возможна и графическая форма отображения переменных, представленная в данном случае одним окном TickPlay(SysDlg).
Отметим также следующее. В ВКПа можно в процессе работы изменять значение дискретного шага автоматных пространств. А если автомат создан в рамках блока FAutomaton, то при необходимости можно динамически изменять и его элементы — таблицу переходов, предикаты и действия. Пользоваться этой возможностью нужно, конечно, продуманно и с предельной осторожностью. Хотя простое изменение автомата — не такая уж, как показал практика, рискованная процедура. Кроме того, диалог визуализирует работу автомата и позволяет перевести его в режим пошаговой работы.
Проверив модель нагревателя, переходим к модели управления. Создадим константы для задания задержек и уставки температуры. Это будут переменные с именами 20сек, 40сек и T_set. Автомат управления показан на рис. 6, где, кроме таблицы переходов, на рис. 6а представлены предикат x1 и действие y1, а на рис. 6б предикат x2 и действие y2.
Автомат из начального состояния st выполняет безусловный переход в состояние off (состояние выключение нагревателя), создавая при этом задержку 40 секунд (время остывания воды). Если в состоянии off по истечении времени задержки (см. предикат x2 на рис. 6б) текущее значение температуры воды будет меньше значения уставки (см. предикат x1 на рис. 6а), то выполняется переход в состояние включения нагревателя — on. В этом состоянии по истечению времени задержки в 20 секунд (максимальное время нагрева воды), или при достижении заданной температуры выполняется возврат в состояние выключения нагревателя опять же с созданием необходимой задержки.
Результаты тестирования созданной модели управления нагревателем видны на рис. 7. Они почти идентичны SimInTech, но в последней обращает на себя внимание область в районе 550 сек, где, если верить графику, выключение нагревателя случилось ранее, чем температура достигла заданного значения. Но, как оказывается, это еще не все проблемы в работе программы. Но о них мы еще поговорим ниже.
Пока же в соответствии с выданным заданием на проектирование (см. статью) нам нужно реализовать управление индикатором. При выключенном нагревателе он должен мигать зеленым цветом с частотой 5 сек, а при включенном — красным с частотой 1 сек. В SimInTech созданию модели управления индикатором посвящена отдельная статья. Мы поступим проще, создав два взаимодействующих автомата, отвечающих каждый за свой цвет индикатора. Они будут, с одной стороны, анализировать текущее состояние автомата управления, а с другой — определять текущие цвет и частоту мигания индикатора. Эти автоматы показаны на рис. 8.
Создадим еще две константы с именами 2 и ColorLed. Первая нужна для задания номера цвета (константа 1 уже есть), вторая — чтобы задавать цвет индикатора. Ее значение 0 будет означать, что индикатор выключен, 1 — зеленый цвет, 2 — красный. На рис. 7а с именем LedGreen представлен автомат мигания зеленым цветом, а на рис. 7б LedRed — красным.
Каждый из этих автоматов может включиться в работу (т. е. покинуть начальное состояние) только тогда, когда другой находится в начальном состоянии. За это отвечает предикат x3. В зависимости от состояния автомата управления (значение переменной HeatCntrl.(on)) переменная цвета принимает соответствующее значение. Автомат, переходя из состояния off в состояние on, создает при этом параллельную задержку. Параллелизм здесь важен, т.к. только в этом случае задержка может быть в любой момент прервана. При этом цвет индикатора без всякой паузы должен измениться, став с зеленого красным и наоборот. В остальных ситуациях индикатор мигает с паузой, равной величине задержки.
А теперь можно поговорить по поводу других проблем проекта в SimInTech. Их легче рассмотреть, если установить время моделирования, например, равное 105 сек. Из графика (см. рис. 9а) следует, что время переключения индикатора с одного цвета на другой постепенно сдвигается вправо. И это достаточно заметно, т.к. почти полсекунды уже сложно проигнорировать.
Следующую проблему демонстрирует рис. 10, где представлена работа модели на завершающем отрезке времени 500–700 сек. Если в ВКПа переключение индикатора происходит стабильно и весьма предсказуемо, то в SimInTech это происходит фактически случайно. Например, здесь почти нет пауз при переключении индикатора с одного цвета на другой (а такая пауза, как показывает моделирование в ВКПа, должна быть), да и красный индикатор при этом мигает не очень стабильно (от 1.5 до 2.5 раз).
В ВКПа система ведет себя более предсказуемо. Войдя в некий установившийся режим, управление на каждый нагрев тратит ровно четыре секунды. Индикатор при этом мигает ровно два раза и есть пауза (отключение) у индикатора при переключении между цветами.
Подведем итоги. Так, стала достаточно понятна разница в подходах к реализации автоматных программ в рассмотренных средах. Она обусловлена в основном двумя факторами. Первый — разные формальные модели, положенные в основу программ и их языки проектирования (в нашем случае — автоматов), второе — свойства среды исполнения/интерпретации автоматов.
Модель автоматной программы в SimInTech представляют диаграммы Харелла, в ВКПа — классические конечные автоматы. С точки зрения теории конечных автоматов это, конечно же, плохо. С точки зрения проектирования — каждому, как говорится, свое, любимое. Только в случае диаграмм Харрелла теорию автоматов придется забыть, как часто говорят, от слова совсем.
Заметно, что язык проектирования автоматов в SimInTech привязан к возможностям визуального языка среды. Это становится понятно, если сравнить с языком описания автоматов в MATLAB, где используются также диаграммы Харелла. Там пакет StateFlow достаточно точно отражает визуальную форму, графическое представление и функционирование автоматов в рамках модели Харелла. В SimInTech, если бы не было явной отсылки на модель Харелла, на мой взгляд, было бы сложно понять о какой вычислительной модели идет речь.
О влиянии среды исполнения на работу моделей. Наверное, если бы его не было, то отмеченных выше дефектов не должно было бы быть в ситуации, когда не предъявляется особых требований к производительности и точности. Безусловно, при реальной работе сложно будет заметить отмеченные особенности в работе системы управления нагревателем. Например, то же мигание индикатора. И уж вряд ли можно будет заметить отклонения в управлении нагревателем просто в силу инерционности процессов нагрева и остывания воды. Но дело, конечно, совсем в другом. Можно соглашаться или нет с моделью, языком проектирования и т. д. и т. п., но, если к процессу проектирования подходить строго, то выявленных проблем быть не должно. Просто потому, что по большей части проекты гораздо сложнее и более требовательны к вычислительным ресурсам.
…Стоп! Но, ведь, можно повысить точность вычислений? И если шаг уменьшить, например, на два порядка, мы, возможно, получим иной результат? Возможно, такой же, как и ВКПа? Опять же можно выбрать другой метод интегрирования? т. е. — открывается большой простор для множества экспериментов… Но... мы сохраним интригу. То, что я увидел, экспериментируя с настройками проекта, может увидеть каждый, если запустит тестовый пример, установив при необходимости SimInTech c сайта компании 3B.
А пока еще раз посмотрим на рис. 10б. Он отражает функционирование идеальной модели. В реальности, конечно же, будет несколько иначе. Возможно, даже с особенностями работы модели в SimInTech. Но мы, ведь, реализовали и тестировали идеальную модель, в которую не вносили элементов, отражающих определенную случайность в поведении реального нагревателя, разброс параметров компонент и т. д. и т.п?...
Так что я поневоле по‑прежнему на стороне ВКПа. Просто потому, что идеальная модель должна выдавать и идеальные результаты. Нужно учитывать, что именно идеальный результат — это тот результат, на который мы в целом рассчитываем, создавая ту или иную модель.
Ну а выводы, как всегда, делать вам, дорогие читатели, почитатели и … оппоненты.
