На сайте Engee в разделе «Библиотека конечных автоматов» в наглядной форме представлены КА [1]. Полюбопытствуйте. Вполне достаточно для первого знакомства. Там есть раздел «Материалы Engee по Конечным автоматам», в который помещены проекты, демонстрирующие качества КА на практике. Сейчас это три проекта - «Регулирование температуры воздуха», «Электростеклоподъемник для автомобиля» и «Управление перекрестком». Подобно проекту браслета из первой части статьи [2] на их примере покажем возможности автоматного программирования (АП) в среде ВКПа в сравнении с автоматами Engee или, что будет точнее, в сравнении с моделью Харелла, реализованной здесь.
Выберем для этого проект с светофорами. На сайте имеется следующее его описание:
«Цель этого примера - разработать модель управления перекрестком, состоящим из двух автомобильных и одного пешеходного потоков, которые управляются двумя трёхсекционными и одним двухсекционным светофорами соответственно. Алгоритм переключения секций будет определяться согласно временной диаграмме. Управляющий алгоритм будет реализован при помощи нескольких блоков Chart, а снятие входных и формирование выходных сигналов - блоками C-Function.»
На рис. 1 показана структурная схема проекта в Engee. На ней несколько блоков, где основные - блок Commn_Counter, который моделирует временные такты диаграммы, блок Traffic_Lights, реализующий управление, заметим, сразу двумя светофорами и блок Crosswalk для светофора потока пешеходов. Временная диаграмма работы светофоров показана на рис. 2.
Здесь же на сайте имеется следующее пояснение к диаграмме:
«Три потока - два автомобильных и один пешеходный управляются асинхронно. При этом разрешение на движение (зелёный свет) одновременно формируется только для одного потока и длится 10 секунд. После окончания разрешения на движение автомобильного потока включается мигание зелёной секцией. Переход светофора из разрешающего сигнала в запрещающий (красный свет) сопровождается включением жёлтой секции на 5 секунд, обратный переход - одновременным включением красной и жёлтой секций на 5 секунд.»
В целом все понятно и нет ни чего сложного. Но блок управления сразу двумя светофорами вызывает вопросы. Не разумнее и не гибче ли будет реализовать управление светофорами по отдельности? А затем создать столько блоков, сколько светофоров.
В ВКПа, не прибегая даже к С++, используя лишь визуальные возможности среды, буквально за час-полтора можно собрать весь проект вместе с диаграммами. В процессе был создан блок, реализующий управление отдельным светофором, который затем был размножен до двух. При этом один из блоков начинал работу в исходном состоянии, отражающем красный свет светофора, другой - зеленый. Их дополнил блок для пешеходов.
Автоматы в данном случае весьма просты, если не сказать, элементарны. Каждый из них по отдельности реализует свою временную диаграмму, не обращая внимания на работу своих соседей. Их действия сводятся к включению нужного цвета через заданные промежутки времени (задержки) в соответствии с временной диаграммой. Что может быть проще?
На рис. 3 видна временная диаграмму трех циклов работы светофоров. Обратите внимание, что на диаграмму добавлена работа общего счетчика (см. блок Common-Counter на рис. 1) и текущее значение кода (строка «код» на рис. 2).
Диаграмма счетчика сразу вызывает вопросы. Он явно отстает от светофоров, хотя в исходном проекте значение счетчика должно синхронизироваться с тактами светофоров. Заметим, что сам счетчик и шифратор сигналов в нашем проекте не используются. Они созданы лишь из чистого любопытства и желания соответствовать исходной структурной схеме и диаграммам сигналов проекта на сайте.
Уже на первом кадре (рис. 3) видно небольшое отставание счетчика, которое к второму-третьему кадру (рис. 4) скрыть сложно, а дальше принимает совсем уж неприличный вид. В чем причина столь печального факта, если к моделям блоков - автоматам нет замечаний?
Чтобы отсечь сомнения, связанные с особенностями визуального проектирования, модели были реализованы на С++. Это сразу в два раза увеличивает скорость их работы. Но картина не изменилась. Пришлось задействовать личные резервы. Стало ясно, что между моментами создания задержек есть переходы, которые, как ни крути, влияют на общее время работы счетчика. Это, так сказать, «модельные издержки», которые и сдвигают график счетчика вправо.
Но это было лишь предположение, для подтверждения которого были предприняты следующие действия. Так, было минимизировано число переходов и изменена сама модель счетчика, которая была приведена к виду на рис. 5.. Здесь левая петля, если параллельная задержка не активна, создает параллельную задержку, равную по времени циклу работы светофоров. Одновременно обнуляется счетчик и создается последовательная задержка, равная 1 сек. Дуга справа, активна, пока активна параллельная задержка, и каждую секунду наращивает значение счетчика.
Далее сам счетчик был перенесен в автоматное пространство с минимальным значением дискретного такта. Это минимизирует «модельные накладные расходы», если таковые вдруг окажутся (а они всегда есть на уровне того же ядра). При этом, если дискретное время пространства моделей блоков 10 мсек, то дискретное время пространства счетчика (в асинхронном режиме работы пространства) стало не более 0.4 мсек.
В результате лишь примерно с 15-го кадра (напомним, ранее это бы уже 1-й кадр) стало заметно отставание графика счетчика по отношению к переднему фронту красного сигнала первого светофора (см. рис. 5). Но только к 50-му кадру отставание стало достаточно очевидным, хотя и заметно меньше, чем на рис. 4. Таким образом, версия с влиянием «лишних» переходов нашла свое подтверждение.
Почему диаграмме, а соответственно и работе, счетчика мы уделили столь большое внимание? Дело в том, что использование синхронной автоматной среды во многом может упростить решение, но не исключает так называемых гонок сигналов/данных. Именно они весьма наглядно проявились в данном проекте. А потому подобный эффект нужно обязательно иметь в виду.
Отметим, что если бы мы создали решение подобное проекту на сайте, т.е. с явной синхронизацией светофоров счетчиком, то с подобной проблемой мы бы не столкнулись. Но в противовес это потребовало бы наличие синхронизатора - блока счетчика и усложнило бы структурную схему решения за счет введения связей светофоров со счетчиком.
В синхронной среде всего это не нужно. Более того, если вы заметили, наше решение имеет и большую точность работы самих светофоров, т.к. нет зависимости от задержек, вносимых блоком счетчика.
Выводы
Чего мы все таки добились и/или доказали, реализовав помимо браслета еще и проект светофоров? Этот, казалось бы, более простой проект выявляет процессы, которые не видны на проекте предыдущем. Это процессы независимого, но синхронного функционирования моделей. В среде, которая синхронна, ее свойства можно использовать без использования явных механизмов синхронизации. Например, типа барьеров в многопоточности. Без них необходимо дополнительное внимание к синхронной работе процессов, если таковое необходимо.
Светофоры демонстрируют качества синхронной параллельной среды. Те же потоки по своей природе асинхронны, а чтобы сделать их другими - синхронными необходимо приложить определенные усилия. Синхронная среда упрощает решение без ущерба надежности работы процессов, а, скорее, даже повышает ее. Ведь, только в синхронной среде работает доказательная математика алгебры автоматов, аналога которой нет в среде асинхронных процессов.
Но отсутствие явных механизмов синхронизации процессов требует более строго учета скорости их работы. Наглядный аналог - парадная коробка. Солдаты в ней не имеют явных связей, но любое нарушение ритма строевого шага даже одним солдатом приведет к ее разрушению. Собственно такому принципу подчиняются объекты в нашем проекте, кода к финишу или любой промежуточной его стадии светофоры и счетчик должны прибыть одновременно.
Проект демонстрирует возможности управление скоростью работы автоматных пространств, которые, отметим, асинхронны по отношению друг другу. Это создает дополнительные преимущества и формирует эффективную среду исполнения процессов, в которой в медленные пространства помещают процессы, не требовательные к скорости работы, например, типа диалогов, а в быстрые – процессы критичные к скорости работы (наш счетчик, процессы реального времени и т.д. и т.п.).
Обладают ли описанными качествами автоматы в Engeу, а по большому счету модель Харелла, сказать сложно. Скорее нет, чем да. Но в наши планы и не входило давать ответы на подобные вопросы. Доказательно сделать бы это мог бы проект в Engee, полностью аналогичный нашему проекту. Может, есть желающие совершить своеобразное «алаверды» в рамках той же Engee?
Литература
1. Библиотека «Конечные автоматы». https://start.engee.com/state_machines
2. Браслет для Бони. https://habr.com/ru/articles/1030712/