Вернемся к одному из проектов дистрибутива программной платформы SimInTeh,  который был рассмотрен в двух статьях(см. [1, 2]). Он же под именем "Управление водонагревательным котлом" включен в раздел "Лабораторные работы по библиотекам" справочной системы SimInTech. Последнее должно предъявлять к нему повышенные требования, как к примеру, поясняющему, рекламирующему те или иные стороны и возможности программной платформы. Одним словом, он должен быть идеальным ...

Только недавно одна из найденных в нем ошибок  была устранена. Но не это знаменательное событие было причиной вернуться к данной теме, а пришедшая примерно в это же время рассылка, рекламирующая возможности "новейшей российской инженерной платформы Engee". В числе прочих ее достоинств описывались включенные в платформу конечные автоматы  (КА)[3], а в видео по ссылке прослеживалась явная любовь к светофорам. Но  нагреватель в этом смысле ни чуть не хуже, а даже предпочтительнее.

Но "спусковым крючком" стал эмоциональный всплеск не самой положительной оценки данной конечным автоматам (подробнее см. [4]). Примечательно, что прозвучал он со стороны тех, кто ранее ввел этот инструментарий в свою платформу и, как можно предполагать, использует. Видимо, они лучше знают возможности своих автоматов? Но, если серьезно, то это, скорее всего, результат отмеченного "всплеска", который за истину воспринимать не стоит. Тем не менее, необходимо что-то уточнить,  чтобы учесть и такое мнение о КА. 

Итак, перед нами проект "Нагреватель" или "Управление водонагревательным котлом". Я не смог сразу найти проект в ВКПа к тем еще статьям, но, если честно, не сильно его и искал, т.к. решил, что проще создать новый. Хотелось проверить, что получится, если повторить в ВКПа автоматы, полностью аналогичные ранее созданным программным автоматам на внутреннем языке платформы SimInTech. А поскольку они были спроектированы согласно концепциям автоматного программирования, то препятствий не предполагалось. Но ... воистину - "не было этого никогда и вот опять".

На рис. 1 представлен проект "Нагреватель", созданный полтора года тому назад (время-то как летит?!). Коды его блоков (тип блоков PL) на языке платформы SImInTech приведены на рис. 2. Рядом с программным кодом блоков показаны их модели в форме графов КА. Именно эти автоматы, кроме интегратора,  мы и будем далее тестировать в ВКПа. Алгоритм библиотечного интегратора из ВКПа фактически такой же, как и на рис. 2. 

Окунемся в работу автомата управления...

Следуя алгоритму, блок управления на переходе из начального состояния 1) отключает нагреватель, 2) присваивает локальной переменной - y значение -0.1 (оно поступает на вход интегратора) и 3) запускает задежку 40 сек. Уже на следующем такте дискретного времени (см. петлю при состоянии "1") сигнал запуска задержки обнуляется для исключения ее повторного запуска. Дождавшись завершения задержки (x1()==false) и если температура воды меньше заданной (x2()==true), переходим в состояние 2, запуская по пути задержку 20 сек и включая нагреватель (y:=1). Далее сбрасываем, как и в состоянии 1, сигнал запуска задержки. В состоянии 2 ждем завершение задержки или превышения температуры воды. Дождавшись того или другого, переходим в состояние 1, как при первоначальном запуске. Проще что-то сложно придумать.

Рис. 2. Коды блоков проекта "Нагреватель" на ЯВУ платформы SimInTech

Проект на платформе ВКПа, полностью аналогичный проекту на рис. 1, приведен на рис. 3. В целом все кажется нормальным: нагреватель работает, температура регулируется. Но мы были бы не мы, когда бы не экспериментировали...

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

В ВКПа задуманное выше делается очень просто - нужно разнести процессы по разным автоматным пространствам, установив последним нужные времена дискретного времени. А, кстати, будет ли это столь же просто в случае других параллельных моделей - потоков, корутин и т.п.? Я не припомню, чтобы быстродействием потока можно было бы управлять напрямую, задавая ему скорость работы, а не вставляя искусственно в поток задержки, не вгоняя его в режим "сна" и т.п.

Но сначала обратим внимание на тренды задержек. На рис. 3 это зеленый и синий тренды. Напомним, что нагреватель может находиться только в одном состоянии - включенном или выключенном. Когда он включен, активна задержка 20 секунд, когда выключен - 40 сек.  При этом, когда она занимается отсчетом времени, то находится в состоянии 1. Все это отражают диаграммы сигналов на стадии набора температуры. Здесь тренды задержек находятся в противофазе друг другу. Однако при переходе в режим регулирования  подобное "соглашение" нарушается, а этого быть не должно. Следовательно, эту ситуацию мы, как минимум, "прошляпили", т.е. попросту пропустили.

Ну, пропустили и пропустили, что себя корить. Хорошо, что обнаружили. Но посмотрим, что будет, если скорость управления резко повысить. Например, сразу в пятьдесят раз, т.е.  установим дискретное время для пространства модели управления равное 1 мсек (до этого было 50 мсек). И то, что мы видим на графиках (см. рис. 4), явно противоречит пониманию, как должна работать система управления. Внимание на этом акцентируют и врезки 4a и 4b. В ситуации быстрого управления даже набор температуры происходит по непонятно кому ведомому закону. При этом, чего раньше не было, задержки нарушают соглашение о работе в противофазе (ср. рис. 3 и рис. 4).

А если мы уменьшим скорость процесса управления? Например, в 30 раз, установив дискретное время процессу управления 1500 мсек. Качество управления, судя по внешнему виду графика,  будет даже немного лучше, но зато при выходе на режим регулирования максимальная температура часто превышает заданное значение. Но это, скорее всего, потому, что медленное управление не успевает отключить нагреватель. Но, как можно видеть,  перекрытие работы задержек ни куда не ушло. С этим явно надо что-то делать...

Самый кардинальный способ - создать новые автоматы. Результат представлен на рис. 6. В автомат задержки введен сброс сигнала ее запуска на переходе 1->0, если температура воды превысит заданную (x2()==true). Так исключается ее повторный запуск.  В модель управления введены три новых состояния - 3, 4 и 5. В состояниях 3 и 4 ожидается срабатывание соотвествующих задержек, т.е. их единичные состояния. В состояние 5  попадаем из состояния 2, если температура "прыгнула" выше нормы. Здесь ждем, когда она вернется назад. И только дождавшись этого, запускаем задержку на переходе в состояние 3. Если же оставить, как оно было ранее, то часть времени задержки, а то и все ее время, уйдет на ожидание возврата температуры к заданному значению.  Более того, если задержка отработает, а температура не вернется в норму, то  автомат вообще зависнет в состоянии 3.   И все это происходит на скоростях процесса управления, которая меньше скоростей процессов задержек (см. врезки на рис. 5).

 Результаты тестирования  с новыми моделями показаны на рис. 6, 7 и 8. Это, соотвественно, при равенстве скоростей процессов, при скорости управления меньше скорости задержек и когда скорость процесса управления больше. Примечателен последний эксперимент. Помимо того, что времена задержек не пересекаются ни в какой ситуации, поддержание температуры происходит аккуратнее и с оговоренной выдержкой (40 сек) на остывания воды. А, например, на том же графике температуры на рис. 5 время остывания явно меньше необходимого по заданию на проектирование и, кроме того, величина его остатка непредсказуема.

Индикация работы нагревателя

Индикация процесса работы нагревателя, казалось бы, самое простое, что должно быть в проекте. Но для меня - это самое мутное место. Во-первых, до нее еще надо добраться. Индикация запрятана в тело блока "контроллер нагревателя" (см. рис. 9). Здесь она как бы "размазана" по его телу. Видна  1) "рассыпуха" для вычисления константы Led и 2) собственно автомат индикации. Хотя в схеме вычисления константы можно усмотреть и определенный смысл. Фактически это демонстрация, как наряду с блоками создать схему, реализующую попутные цели. В данном случае вычисление константы цвета. Действительно, не создавать же для этого целый автомат?!  ;)

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

Автомат индикации исходного проекта показан на рис. 10. Ничего особенного. Имеем, что напрашивается само собой, два состояния - индиктор включен и выключен, Алгоритм поведения также прозрачен - сначала включить, потом выключить светодиод и затем повторять все это в цикле. Не ясно, правда, как отключить индикатор? Но пусть моргает ... пока не сгорит.

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

Смотрим на состояния, которые показаны на рис. 11. Здесь также имеется весьма непревычное, если не сказать, странное представление функций переходов/выходов автомата. Но с учетом графического языка описания в в нотации SimInTech смиримся и с этим. Опять же - все это пресловутое дело привычки (о смысле пока речи нет).

Заметим, что это мы еще не заглянули в блоки "STATE SELECTION" и "COND". Но, если полюбопытствуем, то для обычного программиста, привыкшего к классической форме описания автомата, это, поверьте, будет то еще испытание (это я о себе). Почти сразу возникает вопрос - а нельзя ли извне блока определить номер/имя текущего состояния автомата? Ну, например, как это сделано для блоков на ЯВУ, где его отражает переменная inState (см. рис. 2). Думаю, не сложно было бы сделать что-то подобное и для любого автомата в SimInTech. Но в справке этого нет или запрятано очень глубоко в ее (справки) дебрях.

Автомат - один, а индикаторов - два (или один, но многоцветный?). Работать они должны с разной частотой - 5 сек (зеленый) и 1 сек (красный). И тут становится понятным назначение константы Led. Она позволяет отличить один светодиод от другого или, если светодиод один, один цвет от другого.

Но как управлять периодом индикации? Об этом подробно рассаказано во второй части статьи про автоматы в SimInTech[7]. Но, изучив это описание, мне не удалось задать фиксированную работу индикатору, определив при этом жесткие времена для его включенного состояния и выключенного (см. рис. 13). Не исключена, конечно, моя тупость, но неужели нужна бОльшая собразительность, чтобы сделать что-то подобное? Наверное, я что-то делал не так. Только что?

Работа индикации

В моем понимании светодиод сразу же загорается при включении. Может, какая-то задержка и есть (на разогрев?), но она наверняка не столь велика, чтобы на нее обращать внимание. Не знаю, как происходит переключение светодиода с одного цвета на другой, но почему-то представляется, что и это происходит быстро. Исходя из этих соображений и была построена модель для двух светодиодов, которая приведена на рис. 14.

На рис. 15 приведена визуализация работы индикаторов в SimInTech и ВКПа. В SimInTech светодиод порой тормозит при включении или может мигнуть столь кратко, что на фоне паузы это вряд ли будет замечено. Видно, что в какие-то моменты они работают даже в противофазе. Кажется мелочь - ну, кто обратит внимание на проблемы с миганием светодиодов? Но дело-то, как вы должны понимать, совсем не в этом.

Дело в аккуратности и качестве проектирования, что и должен демонстрировать учебный проект.  Так как одно дело - нагревать воду для студенту, который комфотно разместился в ней в костюме (см. видео [5])  и совсем другое - вляпаться с разгона в Луну.  И там и там система управления принимает решение, но ... эффект  при этом явно разный!  Так что о качестве разработки нужно думать всегда. Будь это простой демонстрационный пример, сложное управление ракетой или многокомпонентная система управления атомным реактором (это я уже начал отвечать на вопрос, который задан в [4]).

Надо ли создавать весьма громоздкую систему типа управления атомным реактором, чтобы доказать возможности автоматного программирования?  Считаю, что нет. Лучше сосредоточиться на качествах системы проектирования, технология работы в которой должна подобные ошибки микшировать.  Автоматам это удается. Иначе им не уделялось бы столь большое внимание. Но, конечно, многое зависит от реализации.  А как любой компонент любой по сложности и объему системы можно заменить конечным автоматом демонстрирует тот же проект на рис. 1 (см. также рис. 2). Надеюсь, я ответил на заданный вопрос?

Заключение

В SimInTech, на мой взгляд, автоматы сделаны не очень удачно. Подумайте, как может считаться удачной реализация модели КА, в которой от модели осталось ровно одно - название. Если это и удача, то для другой модели, отличной от модели КА. Может, по этой причине анализ даже такого простого проекта, как управление водонагревательным котлом, выявил достаточное число проблем.  Конечно, все можно объяснить небрежностью, невнимательностью или чем-то еще. В конце концов, есть опыт и искусство разработчика.

Безусловно ни чего исключать нельзя, но меня все же тревожит другое... Нельзя давать оценку, исходя только из названия и не вникая в суть.  Особенно, когда суть изложена в теории. Автоматы - редкий случай, когда теория есть и активно используется на практике. В комментарии (см. [4]) речь идет о конечных автоматах, их теории, ученых, которые эту теорию создавали, и все это объявляется недостойным внимания, устаревшим и т.д. и т.п. Нужно опять что-то доказывать, доказывать... управляя реакторами, летая на Луну, Марс. Конечно, не без этого и это тоже понятно. И я даже понимаю почему SimInTech должно быть "это наше все". Но все же, думаю, надо относиться к оценке строже и объективнее?

Управление ядерным реактором не самый убойный и объективный аргумент,  доказывающий  преимущества SimInTech над той же ВКПа или, особенно, над тем же МАТЛАБ.  На последнем, уверен на все сто, сделаны не менее масштабные проекты. Но этот факт не означает, что МАТЛАБ лучше SimInTech. Просто он используется чаще.

Иногда, а на мой взгляд даже почти всегда, много лучше и эффективнее что-то объяснять на не очень большом, а по меркам управления атомным реактором даже мизерном примере, демонстрировать качество и/или превосходство того или иного подхода к проектированию любых, даже самых больших, систем.  И тогда появляются проекты типа светофора, нагревателя, модели RS-триггера [8] и других на первый взгляд очень простых задач. Но зато в каждой из них есть своя изюминка, до которой сложно докопаться/разглядеть в большом проекте.

Все сказанное выше не очередная попытка "охаять" - упаси, Боже! - SimInTech. А кому-то это так и покажется. Это попытка восстановить истину. А она в том, что автоматы в SimInTech отличаются от автоматов в МАТЛАБ, а они в свою очередь отличаются от автоматов в ВКПа. Более того, первые две платформы не реализуют классические (правильные!) конечные автоматы, которые рассматриваются в теории автоматов, но которые реализует ВКПа. Поэтому все негативные слова и оценки сказанные в адрес конечных автоматов к классическим автоматам ни какого отношения не имеют. Все они, как минимум, в адрес моделей, которые случайно с ними совпадают по названию. 

Есть конечные автоматы, о которых говорят, есть конечные автоматы, которые рассматривает теория, а есть автоматы, которые использует на практике. В подавляющем числе случаев это разные модели. Именно в этом кроется подвох. И, возможно, хорошо, что Тьюрингу, Нейману, Мили, Муру или тому же академику Глушкову не довелось разрабатывать ядерные реакторы. Первый как-то без них доказал универсальность и общность своей модели, а Глушков, не ссылаясь на атомные проекты, положил автоматы в основу дискретной кибернетики и синтеза цифровых схем. "Симинтехи", "матлабы" и "вкпа"-шки приходят и уходят, а теории остаются. Они и есть то, что достойно обсуждения и сравнения.

Перефразируем известный анекдот - "о теории надо больше думать"... Без нее практика программирования мертва (в том числе и управление ядерными реакторами). В оригинале, правда, наоборот (мертва теория, а практика слепа), но в нашем случае это равносильно.

Ну, а причем тут быдло-кодер? С ним мы познакомились после публикации статьи [9]. Прочтите - не пожалеете. А уж как быть в аналогичной ситуации - ваш выбор. Но думать, конечно, надо...

Ссылка для скачивания примера: https://cloud.mail.ru/public/gEyC/GuK8iL86K

Данная статья: https://cloud.mail.ru/public/JHxF/nKvfre3DX

Литература

1.       Автоматное программирование в SimInTech и ВКПа. https://habr.com/ru/articles/717190/

2.       С++, параллелизм и введение в автоматное программирование в SimInTech. https://habr.com/ru/articles/719592/

3.       Создание конечного автомата в Engee. Создаем модель светофора. https://www.youtube.com/watch?v=9mW39zhGLbI

4.       Почем синтаксический сахар  в графических языках программирования? https://habr.com/ru/articles/822133/comments/#comment_27007724

5.       Нагреватель. https://www.youtube.com/watch?v=U4en3cPCvHs

6.       Конечные автоматы в среде динамического моделирования SimInTech. [Электронный ресурс], Режим  доступа: https://habr.com/ru/post/307090/ свободный. Яз. рус. (дата обращения 28.02.2023).

7.       Конечные автоматы в среде динамического моделирования SimInTech. Часть 2. [Электронный ресурс], Режим  доступа: https://habr.com/ru/post/307162/ свободный. Яз. рус. (дата обращения 28.02.2023).

8.       Модель параллельных вычислений. https://habr.com/ru/articles/486622/

9.       Как американская коррупция превратила физика-ядерщика в быдло-кодера. https://habr.com/ru/articles/824250/.

PS

Все же изменим задержку, сделав ее такой (рис. 16):

Изменили совсем немного - условие перехода по петле в состоянии "2". И этому есть объяснение: считать задержка должна только тогда, когда установлен флаг работы.   До изменения условия перехода она, будучи запущенной, продолжала считать и при сброшенном флаге работы. А причина тоже проста - нарушение условия ортогональности переходов (это и есть теория модели): срабатывала петля, а не переход в состояние "0". Это ошибка, которую мы и исправили. А проявилась она при тестировании, когда визуализация показала одновременную активность обоих задержек. Хотя в идеале она должна была быть обнаружена на этапе формального анализа модели. Пока, увы, его нет. Но это не означает, что он не возможен в принципе. В теории-то есть.

Меняем задержку

До этого задержку мы организовывали в форме счетчика тактов. Это явно не удобно, т.к. при изменении длительности такта нужно пересчитать их число и изменить локальную переменную .InpDelay у каждой из задержек. С другой стороны, в ВКПа есть готовые библиотечные задержки, которые можно использовать. Это последовательная и параллельная задержки. 

Последовательная задержка - вложенный автомат, при вызове которого автомат, создавший ее,  "подвешивается" в текущем состоянии, а переход в следующее произойдет при завершении работы вложенного автомата. Параллельная задержка - параллельный текущему процессу процесс, который завершит свою работу по истечении времени задержки. Он не тормозит создавший его автомат, а момент завершения задержки определяется по активности соответствующего процесса: процесс активен - задержка не истекла, процесс не активен - задержка истекла. В процесс FAutomaton введены операции, позволяющие создать эти задержки - CreateDelay(n) и CreateParDelay(n), а для параллельной задержки введен оператор проверки ее активности - IsActiveParDelay().  

Заменим в наших задержках счетчики на вызов параллельной задержки. Получим следующие модели управления и задержек (см. рис. 17):

Задержки работают по единому алгоритму. Получив команду на запуск - предикат x1() == true задержка проекта создает параллельную задержку из библиотеки и переходит в состояние "1". Здесь она проверяет, во-первых, флаг запуска и, во-вторых, активность процесса задержки. Если любой их предикатов принимает ложное значение, то происходит переход в состояние "0", т.е. задержка становится неактивной. Действие по сбросу сигнала запуска задержки - y4() запускается, когда задержка истекла самостоятельно. Это необходимо для исключения ложного запуска задержки.

Совсем небольшие изменения претерпел и автомат управления (ср. автомат управления на рис.6 и рис. 17).

Но можно пойти еще дальше - создавать задержки напрямую в автомате управления. Это сразу исключит автоматы самих задержек (не путать с библиотечными задержка платформы ВКПа). Получим модель, показанную на рис. 18.

Имеем очень простую модель нагревателя в сравнении с рис. 6. Два автомата задержек "самосократились". В управлении уменьшилось число состояний, стало меньше предикатов и действий Теперь на переходе в состояние "1" мы создаем параллельную задержку и ожидаем ее завершения. Из состояния "2" мы переходим в состояние "1" при полном завершении задержки 20 сек. Но, если температура превысила заданную, то мы не ожидаем завершения задержки, а сразу переходим в состояние "3", отключив нагреватель. В состоянии "3" мы ждем возврата температуры в норму и только после этого на переходе в состояние  "1" создаем задержку 40 сек - задержку на остывание нагревателя от нормальной температуры. 

Вот и все - ловкость рук и никакого мошенничества!

Догнать и перегнать?

Основой платформы ВКПа является ядро реального времени. Создание системы управления нагревателем по условиям ТЗ требует достаточно длительных задержек, при которых процесс регулирования наступает после 500-й секунды. Из-за этого наблюдение за процессом регулировании температуры представляет собой довольно утомительное занятие. Но в SimInTech на это  - расчет процесса управления уходят буквально секунды. Завидно, однако! :)

Чтобы не отставать от SimInTech,  введем в ВКПа режим работы в виртуальном дискретном времени. Задумано - сделано! Получилось так. Во-первых, прикладные процессы проекта необходимо перенести в  основное автоматное пространство и перейти на закладку управления реальным временем, нажав в диалоге "ядро: автоматные пространства" кнопку "Access rights". Здесь можно отключить режим реального времени, установив длительность дискретного такта виртуального  времени (см. рис. 19). Затем нужно вернутся к диалогу управления автоматными пространствами и задать желаемое реальное время пространству InitFsaWorld. Уменьшив его, мы ускорим время работы (теперь уже расчета) модели, а, увеличив, можем рассмотреть работу проекта в замедленном времени.

Поскольку в проекте используется интегратор и если он не находится в "пространстве виртуального времени", то нужно задать такое же дискретное время и пространству интегратора. В результате график управления нагревателем можно получить менее чем за 20 сек (при дискретном времени моделирования 2 мсек). Ускорение в 25 раз - весьма ощутимый эффект от нового режима (см. рис. 20). При дискретном времени 1 мсек ускорение будет уже в 50 раз. В режиме асинхронной работы скорость будет еще выше.

Мы не достигли (пока) скорости расчета в SimInTech-а. Но, во-первых, такой задачи  не ставилось, а, во-вторых, этому тоже есть объяснение. Основное то, что платформа ВКПа заточена под работу в реальном времени, а SimInTech система моделирования, назначение которой, если можно так сказать, расчетное. В ней, правда, можно установить режим моделирования/расчета в реальном времени, но это будет, хотя и что-то похожее на реальное время, но достаточно условно. Чтобы заставить SimInTech работать в этом режиме,  нужно в настройках установить синхронизацию с реальным временем и задать коэффициент ускорения. Эксперименты показали достаточно большую погрешность данного режима. На проекте "Нагреватель" она оказалась в пределах нескольких секунд. Кроме того, в режиме расчета можно вносить лишь отдельные изменения в проект. Например, уставку температуры поменять можно, но изменить схему "на лету" уже не получается.

"ХИЛяем" дальше?

Есть такое понятие в проектировании сложных технических систем - Hardware in the Loop (HIL).  О нем поведала статья [10]. А вот что ответил всезнающий искусственный интеллект (ИИ):

Проектирование в стиле Hardware in the Loop (HIL) — это метод, используемый в процессе разработки и тестирования сложных систем управления, таких как автомобильные системы, авиационные системы или промышленные контроллеры. Этот метод позволяет тестировать и верифицировать поведение встроенной системы управления в условиях, максимально приближенных к реальным, но без необходимости использования фактических физических объектов или системы.

Основные аспекты HIL включают:

Интеграция аппаратного обеспечения в цикл моделирования: В процессе HIL тестирования реальные электронные устройства (аппаратное обеспечение) интегрируются в виртуальную среду, где они взаимодействуют с моделями других частей системы.

Симуляция окружения: Виртуальные модели (симуляторы) используются для эмуляции внешней среды и реалистичных рабочих условий, в которых будет использоваться система. Это может включать модели двигателей, дорожных условий, атмосферных условий и т.д.

Тестирование в реальном времени: HIL позволяет проводить тесты в реальном времени, что необходимо для верификации быстродействия и корректности работы контроллеров и другого управляющего оборудования.

Безопасность и экономичность: HIL тестирование позволяет избегать рисков, связанных с тестированием новых систем в реальных условиях (например, опасные ситуации для людей или возможное повреждение оборудования), а также сокращает затраты, поскольку физическая сборка сложных систем может быть дорогостоящей.

Основные шаги процесса HIL тестирования обычно включают:

Разработка модели: Создание высокоточных математических моделей системы или процессов, которые система управления должна контролировать.

Интеграция контроллера: Встраивание реального контроллера в созданную виртуальную модель.

Симуляция и тестирование: Проведение серии тестов, оценивающих реакции контроллера на различные условия и сценарии, эмулируемые моделью.

Анализ и коррекция: Сравнение полученных результатов с ожидаемыми, выявление и устранение ошибок или отклонений.

HIL активно применяется в автомобильной промышленности для тестирования автомобильных контроллеров (например, системы управления двигателем, антиблокировочной системы тормозов и т.д.), в аэрокосмической и оборонной промышленности для тестирования систем управления полетом и навигацией, а также в энергетической отрасли и при разработке различных видов промышленного оборудования.

Это ничто вам не напоминает? Если нет - то перечитайте статью еще раз и... еще раз. Пока не разглядите. Этапы разработки нашей системы управления в том или ином виде отражают этапы проектирования по методологии HIL. И теперь, надеюсь, стало понятно, почему проект разработки системы управления нагревателем предпочтительнее в чем-то проекта управления светофором. Конечно, в случае светофора тоже можно говорить о моделировании внешней среды. Но это уже иная тема, чем проектирования технических объектов. А именно, - имитационное моделирование систем.  Первое - это больше про проектировании конкретных технических систем - тех же автомобилей, а второе - о моделировании достаточно сложной внешней по отношению к техническим объектам (светофорам) среды.    

В любом случае система управления светофором явно проще системы управления нагревателем. Первая  просто мигает с заданными интервалами времени, игнорируя внешние условия, вторая реагирует на внешнюю среду, контролируя ее температуру. Именно это потребовало создание модели объекта управления, что в свою очередь позволило достаточно эффективно и наглядно протестировать созданную систему управления.

Но, кстати, и светофор светофору рознь. Но это уже отдельный разговор. Был такой светофор в моей практике, о котором я, надеюсь, еще расскажу...

Таким образом, ничего не ведая про HIL, мы, тем не менее, проектируя систему управления обычным котлом, вовсю использовали этот подход. Надеюсь, что не нарушили при этом чьи-то авторские права.

Чудны дела твои, Господи!

Литература

10.   Hardware in the Loop (HIL) или как залупить модель с контроллером. Зачем и кому это надо? https://habr.com/ru/articles/833392/