Комментарии 43
что-то неуловимо меня смущает как минимум во вступлении к этому посту, то ли он нейросеткой написан, толи стиль такой необычный у автора.
У меня в институте препод такой был, который подобным образом выступал на парах. Это не нейронка, это вот некоторые так видят преподавание, как шоу или что-то типа того.
Где вы тут увидели шоу? Наоборот, все нацелено на строгое и подробное описание и как можно .ближе к теории - теории автоматов. Здесь есть какие-то вопросы к "преподу" :)
А что плоходо в шоу? Я тоже считаю что главное в преподавании это шоу. Книжку я и сам почитать могу, а преподователь долже жечь глаголам сердца студентов.
В SimInTech библиотека "Конечные автоматы" сделана на основе такой штуки как субмодель с условным выполнением - это в чём-то более общая концепция (потому что выполнять одновременно можно и несколько моделей сразу). Смысл именно такой реализации был в том, чтобы обеспечить возможность задания внутренней структуры каждого состояния в виде структурной схемы (и соответственно использовать имеющийся набор вычислительных блоков) и обеспечить сортировку модели до её исполнения, чтобы: 1. исключить неявно заданные алгебраические петли. 2. минимизировать задержки на шаг расчёта. 3. совместить всё с моделью в виде сигнального графа (входо-выходной блочной диаграммой, это основной способ задания моделей для реакторного АСУТП). Т.е. по сути в данной библиотеке используется расширение понятия структурной схемы за счёт усовершенствованной сортировки и переменной структуры, которое позволяет задавать карту состояний.
Вот в этих статьях мы делали сравнение с "ручным" расчётом и с моделью в SimInTech как раз в таком виде и оно у нас совпало:
Шорников Ю. В., Тимофеев К. А. "Событийно-дискретные модели управления движением",
Автометрия. Т. 60, № 2. С. 119-127. DOI: 10.15372/AUT20240214. EDN: LTWEUQ
https://www.elibrary.ru/item.asp?id=65660464
Y.V. Shornikov, K.A. Timofeev, Event-Discrete Traffic Control Models. Optoelectron.Instrument.Proc. 60, 276–283 (2024).
https://doi.org/10.3103/S875669902470033X
А так вообще если операции внутри состояния не в виде структурной схемы задавать, а в виде текста во встроенном языке программирования есть оператор case.
Автор явно апологет конечных автоматов, до фундаметального фанатизьма. Когда у человека в руках молоток, каждая проблема кажется гвоздем. Тут все в мире конченные автоматы. Даже таймер это тоже конечный автомат. Нужно еще операции сложения в виде конченных автоматах записать и будет вообще заипись. Что-то слабенький наезд, не очень понятно что тут ответить. На статью пока не тянет вот видео ответ:
К сожалению, ютуб глухо виснет и на компе я не вижу видео. К счастью, есть китайский телефон, которые его позволяет смотреть. Не айс, но хоть что-то. Итак, смотрим. Время 11:06 зеленый тренд. Имеем странный пичок потом через паузу пошел мигать светодиод (зеленый, кажется) через 5 сек. Время 13:06 начинает мигать красный. Опять все начинается с пичка (чуть пошире) а потом мигает с паузой 2 сек. Как-то так на тоненького...
Я не критикую сейчас автоматы (для меня пока они все еще не кошерны ;) Но опять же каждый питается тем, что любит и кому доверяет). Я о другом. Я не могу понять почему светодиоды не начинают работу с нормального включения и не держат заданное время в этом состоянии, а настнают иногда работу с этакого игривого подмигивания. Я не могу понять почему эта проблема так и понята. Я, ведь, о ней специально написал в статье и опять к этому же возвращаемся. Сложно это сделать или не царское дело отслеживать работу мигалки. Греет и хорошо, не взорвалось и ладно, пролетел мимо и счастье.. А кто и как мигает - а кто его знает? В моем понимании хороший разработчик должен учитывать малейшие нюансы работы системы управления. Даже мигание светодиода. Ведь, если он так мигает, то, может, в следующий раз не мигнет совсем?
Вот как-то так. Прошу прощения, за настырность. В данном случае не к автоматам в SimInTech, а к качеству проектирования. Слова "на какой-то там секунде(475?) индикатор включился и тут же выключился" явно обращают на себя внимание. Может быть, и наш аппарат облетая . Луну как-то так включился и потом тут же выключился. Но этого вполне хватило, чтобы со всей русской удалью въехать в поверхность обратной стороны нашего любимого спутника. Эх, прокачу!!! :)
К сожалению, Борисов не уточнил, какой продукт был использован при создании программы для спутника. А было бы интересно узнать... А вдруг... Simulink? :)))
Да нет проблем никаких с включением, видно что такты работы (включения - выключения) светодиодов сдвинуты, на шаг интегрирования. Который в процессе моделирования тоже меяется.
Во время старта после инициализации меандр, который внутри неактивного состояния, не исполняется поскльку вся модель отключена и не расчитывается. Поэтому в этом источнике сигнала расчет такта начинается только с момента активации состояния. В итоге получаем сдвиг относительно меандра который находился в активном состоянии.
Если важно получать оновременный старат индикатора, нужно просто вынести источник меандр из состояниия и оставить внутири только ключ. На следующем рисунке меанд вынес из субструктуры состояния и не замирает при его выключении, соотвесвенно нет сдвига по времени:
В это случае источник импульса постоянно работает и не останавливается когда состояние выключается. Разработчик сам должен решить важно ему синхронизация или нет. Если не важно мы экономим вычислительные ресурсы, все что находится в неактивной субструктуре не вычисляется, и не занимают процессор.
В том то и дело, что скорее всего товарищи с нашей лунной программой писали совой софт согласно теории автоматов Миля, Мура и какого то еще Хера, но хер проверяли с моделью объекта. Был бы у них SimInTech для моделирования этот лунный трактор у них кувыркунулся бы при моделирование на компьюторе и не раз. Даже в простой модели невооруженны глазом вы увидели что моргает состояни индикатора как то не так, как хочется. Для этого SimInTech и делали после Чернобыля, что бы видеть как лунный тарактор кувыркается в модели, не вокруг луны.
Вот только без наездов на теорию и, тем более, на ее авторов. Ну, кто не без греха..:)
С теорией все понятно, как и с теми спецами, которые ее используют. Вот только индикатор по-прежнему моргает "не так, как хочется". А, судя по картинкам, появились еще большие паузы. И обнаружил изначально это, кстати, какой-то "Хер", используя теорию автоматов (достал, блин, уже:)? А вот те кто создавал, между прочим, в SimInTech-е, почему-то не углядели это дело. Хотя причина проще, чем теория, - речь идет просто о качестве проектирования... С другой строны, ведь, качество тоже зависит почти напрямую от теории. Или как?
Ну, так я продолжу :)
Еще раз покажу как работают "херовые автоматы" ...
a) режим набора температуры
b) режим регулирования температуры
Все четко включается, все четко выключается...
Можно сказать - ну, что ты, мол, прицепился? Ведь, смотрим задание на проектирование (см. список литературы [6]), а там...
Состояние выключен.
...
Индикатор мигает зеленым цветом с частотой 5 секунд.
...
Состояние включен
...
Индикатор нагрева красным моргает с частотой 1 секунду.
...
Данное ТЗ можно вполне трактовать так, как это удобно исполнителю (в данном случае одновременно и заказчику :)). Где например, написано, что при переходе из одного состояния в другое индикатор включается мгновенно в нужный цвет? И, вообще, сколько должно быть индикаторов, когда есть просто "Индикатор" - это про зеленый свет и "Индикатор нагрева" - про красный свет?
Искусство написания ТЗ - это, знаете ли, большое искусство, которое редкий программист может осилить ;). Да и его задача другая - срубить бабло по-быстрому :) Поэтому, чем путанее/расплывчатее ТЗ, тем ему же лучше, родному. Как получилось - так и написал. Или, как было записано, так и сделал. А если что-то не прописано, то это уже не его забота - гоните бабки за сделанную работу! Плавали -знаем! :)
Ну, так как - добьем наконец-то индикатор/индикаторы или пусть уж моргают как есть? :)
та уже решение выше, вынести истончник меандр из блока состояние автомата, что бы он не попадал в остановку, когда состояние не активно. Теория автоматов это маленький частный случай математики, ну совсем маленький. По сути это правила как связать руки разработчику ограничить его инструменты, что бы он дебил сделал меньше ошибок. Функционально блочные диаграммы это раздел дифференциального исчиления который гораздо шире узкой темы конечных автоматов. Если бы я хотел издеватся я бы вам вмето интегратора в модель предложил поставить бак с нагревателем и попросил бы создать это в виде конечных автоматов. Как например в этой статье:
При этот сам SimInTech хорошая штучка. Обраруживаю знакомые черты. Например пакет проектов. Здесь отдельный проект пакета - это как бы отдельное автоматное пространство в ВКПа. Как-то так :)
При этот сам SimInTech хорошая штучка. Обраруживаю знакомые черты. Например пакет проектов. Здесь отдельный проект пакета - это как бы отдельное автоматное пространство в ВКПа. Как-то так :)
Не совсем так. Автоматы с разными временами переключения можно и внутри одного проекта запускать. В пример как раз переключение автомата индикторов происходит, то с частотой 5 секунд, то с частостой 1 секунда, сама выдережка задается в дргом автомате.
Если говорить про то, что индикатор четенько включается и отключается то это конечно хорошо и даже местами замечательно. Только вот нахуа это нужно совсем не понятно. Будет ли какой зведец если моргнет не так, или всем пох на его моргание не в такт? Ответить на этот вопрос может только модель объекта к которому ваш автомат присобаен в реальности. А без модели объекта можно хуачть уеву тучу автоматов и непонять как они будут с объектом взаимодействовать. Если вдруг не так и не в такт моргнет.
Можно продолжить Вашу мысль - "нахуа" он моргает - можжно просто менять цвет, и "науха" он вообще нужен (без него дешевле только будет и хлопот меньше)...
Дело-то не в индикаторе и об это я прямо написал в статье. Повторю, если не обратили внимание, дело в точности и качестве проектирования.. Ну, сделайте так, как должно оно быть, и вопрос закрыт. А мы трем, трем... И как итог - а "нахуа" ? ;)
тремя постами выше уже это сделано. Выносите блок менадр из блоков состояний конечных автоматов, где он выпадает из расчета, и нет никакого смещения.
Насколько я понимаю, это именно эта диаграмма:
Буквально - "Не верь глазам своим"!
эти диаграмма когда меандры отбивающие такт находятся в сосотояниях и замирают на врем когда состояние не активно, в момент активации состоянии меандры на ходистя в том состоянии в котором они были при дезактивации. Поэтому они сдивнуты относительно друг друга. По зеленому индикатору это отлично видно. При выходе из состояния меандр находится в нулевом состоянии и замирает, при входе начинает работать с нулевого сосотояния выдерживает 5 секунд и включается, именно так они и должне работать, когда находится вутири блока состояние. Тоже самое с красным.
если важно получить такты, просто вынесите меандры из блоков состояний выше уже указано:
...если важно получить такты, просто вынесите меандры из блоков состояний выше уже указано:
Важно получить то, что указано в ТЗ. Это первое. И почему "выносить" должен я, если схему создали Вы. Это второе.
В ВКПа я получил, что нужно. Это представлено диаграммами сигналов индикаторов. Ход, думаю, за Вами и в SimInTech. Желательно без привлечения сторонних сил. Т.е. и вынисите и приведите полученные диаграммы. Я не увиливаю, а просто могу сделать что-то не так и не хочу быть "левым" в этой игре ;).
А как должно быть кстати? У нас три процесса 1) перключения красного индикатора, 2) перключение зеленого индикатора) 3) переключения нагревателя. Каждый работает с заданой частотой но со сдивгом, почему они вообще должны синхронно работать - то?
...почему они вообще должны синхронно работать - то
Здрасьте! Приехали! Что за сдвиг? ... А что им мешает или запрещает так работать. И без сдвига, заодно. Не знаю, как в SimInTech, а в ВКПа - ничто.
Все просто есть такты переключения состояний, которые связаны с работой нагревателя, они вообще могут просходит в любое время, поскольку нагреватель в реальности работает с реальной средой где есть изменения, например воду слили горячую и добавили холодную. Нагреватель может в произвольны момент времени включится. Автомат переключения состояния для мигания диодами включается с задержкой, которая зависит от плавающего шага интегрирования, которые меняются в зависимости от процессов, быстрые процессы мы считаем с мелким шагом, что бы попасть в заданную точность расчета - меньше шаг интегрирования, - меньше задержки при перклюяения состояний. Когда процесс плавный SimInTech увеличиваетс шаг интегрирования. Сответвенно задрежки при перключении тоже меняются. В предеалах заданной точности расчета
Если нужно без задержек и сдвигов - вынесите источники моргания из блоков состояния, тодгда они будут работать без задержек в отключеннос состояния.
Либо задайте фиксированый шаг для модели контроллера
А вот вам еще пример, где в SimInTech конечные автоматы с сотояниями внутри которые работает регулятор на базе нечеткой логики, и все это в виде функционально блочных диаграмм выполнено
Я все же хочу добить нечеткую логику в ВКПа, чтобы повторить аналогичные проекты из SimInTexh (фазификатор Гаусса уже есть и работает). Дайте ссылочку и на этот проект. Обещаю справиться и с этой проблемой;)
https://disk.yandex.ru/d/KQ_3mkpe_OtFnA
Не получится, конечные автоматы это просто математическая абстракция, которая в программе представляет собой правила написания кода. Эти правила упрощают работу с кодом, анализ и отладку, но ограничивают в возможности создания моделей. Это как нарисовать портерет Дажконды используюя только треугольную линиейку и карандаш. Жизнь она всегда богаче математических абстракций
А если получится? :)
может и получится, операцию на глазном дне через задний проход тоже говорят делают :))) Только вряд ли. Абстракция автоматов накладывает ограничения. Тот же самый выход из состояния и тут же возврат в него, вместо нормального счетчика или таймера, это я лично считаю извращением, но высокие абстракции требуют и наверное кому-то это кажется удобным и очевидным.
Но я бы проще сделал зачнитесь, сделай те на конечных автомах на нечеткую логику, а ПИД регулятор. Тогда будет понятны все ограничение теории. Причем вот здесь в видео простейший ПИД регулятор
А про Джаконду - это, кстати, хорошо!:) И SimInTech и MATLAB да и ВКПа используют фактически одну палитру и краски. Имеется в виду процессор, систему команд, язык реализации платформы (не язык самой платформы). А уже выше идут всякие там "треугольники", "линейки" и т.п. Замечу, что скорость рисования, конечно, важна, но с точки зрения результата фактически это дело десятое. Так что соревнование SimInTech-а с MATLAB - это соревнование фактически "линеек" и "треугольников". И если чего-то где-то не хватает, то все можно поправить - создать/добавить "треугольник", "линейку" и т.п. Нет качественного отличия этих платформ.Все это по сути "рисование на плоскости". Когда-то, кстати было популярно распечатать Джаконду на АЦПУ. Сейчас об этом можно попросить ИИ. Но смысл все тот же - плоскость. ;)
ВКПа создает объем. И в этом ее рачественно отличие от всех упомянутых выше. Об этом моя давняя статья - Фантазия или программирование? (https://www.osp.ru/pcworld/1997/10/158015).
Да ладоно вам, какой объем. Паралельные синхронные и асинхронные программы уже давно работают, как только к интел 80086 прикрутили сопроцессор, уже на уровне железе вычсиления были параллельные. А прямо сейчас у меня 12 ядер физических на процесоре 3500 потоков и 600 процессов запущено и все это прекрасно работет. Это только на моем компьторе сейчас. А представляет сколько одновременно людей сейчас пишут коментарии на Хабр, прямо сейчас
...Паралельные синхронные и асинхронные программы уже давно работают,
Архтектура железа и архитектура программы - это достаточно слабо связанные вещи. Если, конечно, речь не идет об ассемблере. Этот случаем пропускаем ;)
Вы ж математик? Давайтерассуждать... строго. Параллельные программы - значит в их основе лежат параллельные алгоритмы. В свою очередь параллельные алгоритмы базируются на параллельной модели вычислений. Так?
Давайте начнем с начала... О какой параллельной модели вычислений идет речь? Ограничим фронт рассмотрения более знакомыми рамкми ;). В SimInTech есть параллелизм? Если есть, то что за параллельные алгоритмы в нем реализованы/реализуются. На какой модели/моделях параллельных вычислений они базируются?
все просто когда есть назависимые вычисления запускаются потоки treads в windows в частности когда вычисленно давление во всех узлах гидравлической системы можно паральлено запустить расчеты расходов используюя програмный механизьм treads. При этом у нас система проверяет время затраченое на вычисления и произвольно меняет количество асинхрнных процессов. С тем что бы выремя вычсиления было минимальным вот здесь на риснуки используется 3 асинхронных потока.
Поэтому говорит, что вы придумали новое слово и получили качественный изменение вычислений новую размерность никак не приходится. Все современные программы по умолчанию уже лет 50 параллельные. И выполняется это различныем средствами от процессор операционной системы и программными. Поэтому для каждый проект в пакете это отдельностям thread ображение информации это отдельный thread ну и внутри модели в случае теплогидравлических расчетов система сама выбирает количество thread
Все это сделано давно встроеными и известными средствами
Поэтому говорит, что вы придумали новое слово и получили качественный изменение вычислений новую размерность никак не приходится. Все современные программы по умолчанию уже лет 50 параллельные.
Повторяю вопрос. О какой параллельной модели в Вашем случае идет речь? Свое "слово" я сказал, когда сформулировал формальное определение модели паралельных вычислений. Там же я рассказал и о качественной стороне дела.
Просто сказать, что я использу потоки и привести примеры их применения, это еще совсем не понятие вычислительной модели.
Просто потоки со всеми механизмами их синхронизации - это не вычислительная модель. Это приемы структурной организации процессов, условно называемых параллельными.
Оставим пока теорию... Практические вопросы к Вам:
Почему у меанда (источники) наклонные фронты?
Почему коэффициент усиления у интегратора и интегратора с ограничением относится к входному сигналу (см. справку)?
Последнее совсем неожиданно для меня. Обычно усилитель усиливает выходной сигнал. В математике почему-то не так?
Включите в графике опцию использования ступенчатой интерполяции и будут строго вертикальные. А вообще при постоянном шаге интегрирования время когда меандр равен например 0 и время когда он стал например 1 отличается как раз на этот самый шаг интегрирования. При этом если включить метод с переменным шагом и опцию учета формы для источников в настройках то можно снизить шаг в момент переключения меандра до заданного минимума.
Интегратор является линейным звеном поэтому на входе его умножать или на выходе значения не имеет. Ограничение выполняется не просто по выходу а по переменной состояния, что есть правильно. В симулинке был косяк когда делали именно ограничение чисто выхода интегратора и получалось, что когда переменная состояния там не ограничивалась и например при постоянном входном воздействии он выходил на ограничение, но при этом накопление все равно шло. Из за этого там при смене входного воздействия на обратное возникала задержка которой быть не должно. Основное назначение блока интегратора с ограничениями это имитация приводов имеющих конечное положение (например привод клапана с концевыми выключателями) - вот собственно у нас он как положено так и работает.
...но при этом накопление все равно шло.
Да, именно такой косяк пришлось исправлять и мне в моей реализации Вот только использование Вами понятия "переменной состояния" как-то напрягает. Просто потому, что автоматов, вроде, нет, а вот "состояние" как-то появилось. ;)
По поводу коэффициента. Действительно, умножать формально оно так. Но ограничивать по выходу все же на мой дилетантсткий взгляд как-то правильнее. Исходя из физического принципа. Усилитель все же усиливает не прямо входной сигнал, а использует его чтобы, преобразовав (транзисторы там вссякие, лампы и т.п.),, выдать на выход. Ну, это так - навскидку...
Вот только использование Вами понятия "переменной состояния" как-то напрягает. Просто потому, что автоматов, вроде, нет, а вот "состояние" как-то появилось. ;)
Как я и подозревал, диференциальное исчесление для вас "Terra Incognita":)) А ведь в книге на которую вы ссылаетесь, прямо сказано что изучать дискретную исчесления рекомендуется после знакомства с диференциальным исчислением, тогда многие чудесатости котрые вы выдумываете, окажутся уже известными науке велосипедами. С другой стороны вам предстоит много чудных открытий.
Могу порекомендовать начать вот с этой статьи
A state variable is one of the set of variables that are used to describe the mathematical "state" of a dynamical system. Intuitively, the state of a system describes enough about the system to determine its future behaviour in the absence of any external forces affecting the system. Models that consist of coupled first-order differential equations are said to be in state-variable form.[1]
Исходя из физического принципа. Усилитель все же усиливает не прямо входной сигнал, а использует его чтобы, преобразовав (транзисторы там вссякие, лампы и т.п.),, выдать на выход. Ну, это так - навскидку...
У вас какая то дикая путаница в голове, абстрактная математика пермешана с физическим принципом работы электрического усилителя? А причем здесь усилитель? Это же просто математика умножение на коэффициент. Есть куча физияеских процессов где нет никаких усилений. Ну например для вычисления коффициента преломления используется то же самое математическое выражения умножения на коэффициент, преломление и отражения происходять на границе. Причем здесь лампы, транзисторы, входы выходы? Это математика!
Свое "слово" я сказал, когда сформулировал формальное определение модели паралельных вычислений.
Нигеде не нашел вашего формального поеределения "модели паралельных вычислений" скорее всего это выдуманный вами велосипед, обозначающий одному вам изветную абстракцию.
Если говорить об общепринятых определения, а не о ваших фантазиях, то использование потоков для распаралеливания расчетов в теплогидравлике соотвесвует The Data-Parallel Model (поскольку данные в вычислениях расхода внутри теплогидравлических объема не зависят друг от друга (паралельные потоки), а зависят только от давления в узлах, рассчитанных в начале шага интегрирование) Определения и схемы вычисления в данной паралельной модели можно посмотреть здесь...
Для меня паралельные вычисления когда я запускаю модель, она инициализируются, запускает потоки, формирует задачи на расчет и грузит 8 процессоров которые у меня есть. И я это вижу наглядно в диспетчере задач Windows, после запуска моей модели в SimInTech
Это паральные вычисления как они есть и для чего они были созданы 50 лет назад. И если для вас это
Это приемы структурной организации процессов, условно называемых параллельными.
То для всего мира и для меня это и есть паралельные вычисления. А что считаете воистину исконно посконными параллельными вычислениями вы, это мне неведомо, боюсь и вам неведом так же, поскольку вы тут на ходу пытаетесь теорию дифференциальных уравнений выдумать заново. Не надо старина Эйлер уже все придумал. Читайте Эйлера.
Нигеде не нашел вашего формального поеределения "модели паралельных вычислений" скорее всего это выдуманный вами велосипед, обозначающий одному вам изветную абстракцию.
Странно, конечно. Думаю, что не очень-то и искали ;) Ну, да ладно... Все есть на Хабре. Это, например, статьи Автоматная модель управления программ, и Модель автоматных параллельных вычислений.
На Эйлера я совсем не покушаюсь. Даже не мечтаю ;) Каждый должен заниматься своим делом. Эйлер же,как я полагаю, про теорию автоматов еще не знал, хотя, возможно, и использовал понятие состояния. Тут Вам виднее, как его знатоку. Но, похоже, именно тут "собака порылась" ;)
Да нет там никакого определения. Все сводится к жалкому триггеру в поределении которого есть запретные состояния.
Типовое описание работы RS-триггера дается в подавляющем числе случаев в форме таблицы истинности. Но поступать так, понимая, что триггер — это последовательностная схема, это, по сути дела, сознательно вводить в заблуждение изучающих эту тему. Ну, нет и не может быть у триггера «запрещенных состояний»!
Тригер это не последовательная схема, это вообще не схема! Это математическая абстракция, которая содержит в себе запретные состояния именно потому что, она абстракция. Это как 2+2 = 4. Это правила вычисления выхода по входу.
А последовательная схема, про которую вы говорите, это вариант ее реализация в виде электронных элементов. И вот именно эта реализации триггера, не имеет запрещенных состояний (поскольку это физическое реализация математической абстракции). Вы берете свойства электронный элементов в которых есть время перключения и требуете изменить математическую абстаркцию. Но так не работает математика. Если есть запретное состояние входов тригера в математике занчит оно есть.
2+2 = 4, нельзя тербовать что бы 2+2 = 2 + 1 + 1. Поскольку нельязы к двум яблокам добавить два, сначала добавляетя 1 и получается 3 а птомом добавляется еще 1 и получается 4. Только так работает сложение! А 2+2=4 этого не может быть! И только конечные автоматы правильно складываюте 2+2 за два такта! Истиное паральльнео счисление аллилуя!
Если вы не можете получить бесконечное напряжение при резонансе в реальной жизни, это не повод отменять математическую формулу резонанса.
И числа 0 не сущетсвует! Поскольку это вводит в заблуждение, не бывает нулевой высоты, есть высота на уровнем море, а до дна еще никто не доставал, потоэтому 0 не существует. И нулевое напряжение в электронных компонентах оно не равно 0! Нет и не может быть "нуля"
Ну а то, что вы по умолчанию в автоматы воткнули задержку, это не делает ваши автоматы единственно воистину параллельными, а все остальные алгоритмы реализации триггера, где в схему в ручкую водят задержку на шаг, неверными гайдзынам непостигшими единственно верного учения о параллельных конечных автоматах.
Ну, вот - получилось! (см. выше) Я же предупреждал...:) Пришлось, конечно, повозиться, но только не с автоматами, а с моделями проекта. Сделан полный аналог Вашего проекта управление водонагревательным котлом на нечеткой логике.
А вот что получилось.
Выше - это быстрый вариант Нечеткого регулятора.
А вот работа варианта регулятора у которого все блоки - автоматные процессы. Он медленнее, но по структуре соотвествует схеме исходного проекта:
Диаграммы немного не такие, как в исходном проекте, но это уже - мелочи. Главное - управляет уже в этом варианте ;)
Разговор с быдло-кодером