Поводом для написания статьи послужило не очень приятное для меня событие: модератор Хабра убрал теги – «С++» и «Параллельное программирование» из моей крайней статьи [1]. Этому предшествовало сообщение пользователя, который по его словам не заметил в статье ни С++, ни параллелизма и поспешил об этом известить весь свет. На самом деле он, скорее всего, просмотрел статью по диагонали и попросту "не врубился". Другим объяснить сей казус сложно. Я объяснил причины его заблуждения, но это не было принято во внимание. В ответ – тишина и, более того, пошли у него на поводу.
А до этого, но тоже в контексте рассматриваемой статьи (теперь все это складывается в один пазл), произошло еще одно событие. Другой пользователь, решивший, видимо, поддержать автора, выразил благодарность, но допустил не очень лестные высказывания в адрес специалистов Бауманки. Не то, чтобы я с ним был во всем согласен, но поскольку на асфальте розы не растут, то в чем-то он был все же прав.
Но дело даже не в содержании постов. Если раньше управлять спорными постами доверялось автору, то теперь модератор решил взять на себя это право. Может, у нас месячник усиленной модерации? Но только в чем причины столь сильного недоверия автору? Ведь, модератор явно не очень вникал в суть проблемы и причины появления подобных постов. Логично было бы предоставить, как и ранее, автору решать вопросы, связанные с содержанием его же статей. Последнее сообщение, хотя и содержало критику, но в целом не нарушало правила сообщества. Хотя, обобщать на всю Бауманку, конечно, не стоило бы.
Однако, оставим пересуды в стороне, а поговорим про С++, параллелизм и об автоматном программировании. А тут без ВКПа и, как ни странно, без SimInTech не обойтись. Так уж сложилось, что есть, что сказать на обозначенные темы и для нее.
1. С++ и ВКПа
Автором только на Хабре написано более двух десятков статьей на тему ВКПа. И если не в каждой, то в большинстве из них подчеркивается, что ее основой является С++. Говоря ВКПа, мы должны подразумевать С++ ровно также, как мы это делаем в контексте упоминания тех же Visual Studio или Qt. Для ВКПа С++ не просто язык, на котором она разработана, но и ее внутренний язык программирования (ЯП). И если, например, MATLAB или SimInTech имеют свои внутренние ЯП, то здесь им является именно С++.
Иметь С++ в двух ипостасях, языка проектирования самой среды и ее внутреннего ЯП, весьма удобно, т.к. не требует специализированного языка программирования среды. Создание последнего - сама по себе задача весьма сложная и трудоемкая. В ВКПа же есть все то, что есть или будет в С++. На текущий момент сюда подключаются также возможности библиотеки Qt и ее средств проектирования (до этого – Visual Studio).
Безусловно, на уровне среды также есть потребность в неком языке программирования. Во многих случаях он позволяет быстро сделать пусть некий набросок решения или реализовать простые функции, не погружаясь в С++. И по существу подобные возможности также можно считать расширением С++. В рамках самого С++ они, во-первых, вылились в создание шаблона описания автоматов в форме таблиц переходов и формирование новой алгоритмической модели.
Активные автоматные объекты качественно расширяют С++. Могу ошибаться, но, думаю, пока в стандартах С++ на эту тему нет и речи. В него внедрили другое: так называемое, многопоточное параллельное программирование, корутины и им подобное. Все это по большей части вызывает только большое сожаление, т.к. добавленные "языковые конструкции" не отвечают теории и только усложняют язык, создавая ему проблемы.
Если говорить о надстройке над С++, то в ВКПа он был расширен диалоговыми средствами реализации простых автоматных алгоритмов. Именно такая ситуация была показана в рамках «забаненной» статьи. Там была создана модель управления нагревателем без привлечения мощи языка С++. Получилось проще, быстрее и под силу тем, кто не знает С++, но должен хоть немного понимать в автоматах. Причем речь идет не о диаграммах Харелла, а о более простых и строгих – классических автоматах.
Покажем разницу двух подходов, приведя реализацию блоков проекта «Нагреватель» из упомянутой выше статьи на С++. Первый листинг (листинг. 1) – автомат управления, второй – простейший переключатель (листинг 2). По технологии проектирования автоматов на С++ требуется внести определенные дополнения в код их реализации, что не так уж сложно. Сюда, во-первых, входит создание необходимых ссылок на переменные среды и указателей на другие процессы, используя стандартный метод автоматного класса - FCreationOfLinksForVariables. Во-вторых, добавить в автомат петлю при начальном состоянии, нагруженную предикатом и действием (см. листинги). В процессе работы только после создания ссылок автомат выполняется переход в те или иные рабочие состояния автомата. Заметим, что эти же действия на уровне диалогов среды (см. применение диалога FAutomaton в [1]) реализуются средой автоматически. Потому-то автомат там и выглядит проще.
Листинг 1. Код блока управления нагревателем
#include "lfsaappl.h"
class FHeatingControl :
public LFsaAppl
{
public:
LFsaAppl* Create(CVarFSA *pCVF) { Q_UNUSED(pCVF)return new FHeatingControl(nameFsa, pCVarFsaLibrary); }
bool FCreationOfLinksForVariables();
FHeatingControl(string strNam, CVarFsaLibrary *pCVFL);
virtual ~FHeatingControl(void) { }
CVar *pVarStrT; // имя переменной температуры
CVar *pVarStrT_set; // имя переменной уставки температуры
CVar *pVarCoolingDelay; // время охлаждения
CVar *pVarHeatingDelay; // время нагрева
protected:
int x1(); int x2(); int x12();
void y1(); void y2(); void y12();
CVar *pVarT; // температура воды
CVar *pVarT_set; // уставка температуры
};
#include "stdafx.h"
#include "FHeatingControl.h"
static LArc TBL_HeatingControl[] = {
LArc("st","st", "^x12","y12"),
LArc("st","off","x12","y2"),
LArc("on","off","^x2","y2"),
LArc("on","off","^x1","y2"),
LArc("off","on","x1^x2","y1"),
LArc()
};
FHeatingControl::FHeatingControl(string strNam, CVarFsaLibrary *pCVFL):
LFsaAppl(TBL_HeatingControl, strNam, nullptr, pCVFL)
{ }
bool FHeatingControl::FCreationOfLinksForVariables() {
pVarCoolingDelay = CreateLocVar("dCoolingDelay", CLocVar::vtInteger, "cooling time");
pVarHeatingDelay = CreateLocVar("dHeatingDelay", CLocVar::vtInteger, "heating time");
pVarStrT = CreateLocVar("strNameT", CLocVar::vtString, "current temperature");
string str = pVarStrT->strGetDataSrc();
if (str != "") { pVarT = pTAppCore->GetAddressVar(pVarStrT->strGetDataSrc().c_str(), this); }
pVarStrT_set = CreateLocVar("strNameT_set", CLocVar::vtString, "temperature setpoint");
str = pVarStrT_set->strGetDataSrc();
if (str != "") { pVarT_set = pTAppCore->GetAddressVar(pVarStrT_set->strGetDataSrc().c_str(), this); }
return true;
}
// predicates
int FHeatingControl::x1() { return pVarT->GetDataSrc() <= pVarT_set->GetDataSrc(); }
int FHeatingControl::x2() { return FIsActiveParDelay(); }
int FHeatingControl::x12() { return pVarT != nullptr && pVarT_set; }
// action
void FHeatingControl::y1() { FCreateParDelay(pVarCoolingDelay->GetDataSrc()); }
void FHeatingControl::y2() { FCreateParDelay(pVarHeatingDelay->GetDataSrc()); }
void FHeatingControl::y12() { FInit(); }
Листинг 2. Код переключателя
#include "lfsaappl.h"
class FHeatingSwitch :
public LFsaAppl
{
public:
LFsaAppl* Create(CVarFSA *pCVF) { Q_UNUSED(pCVF)return new FHeatingSwitch(nameFsa, pCVarFsaLibrary); }
bool FCreationOfLinksForVariables();
FHeatingSwitch(string strNam, CVarFsaLibrary *pCVFL);
virtual ~FHeatingSwitch(void) { }
CVar *pVarStrInput;// имя входной переменной
CVar *pVarStrInput1;// имя входной переменной
CVar *pVarStrInput2;// имя входной переменной
CVar *pVarStrOutput;// имя выходной переменной
protected:
int x1(); int x12();
void y1(); void y2(); void y12();
CVar *pVarInput;// адрес входной переменной
CVar *pVarInput1;// адрес входной переменной
CVar *pVarInput2;// адрес входной переменной
CVar *pVarOutput;// адрес выходной переменной
};
#include "stdafx.h"
#include "FHeatingSwith.h"
static LArc TBL_HeatingSwitch[] = {
LArc("st","st","^x12", "y12"),
LArc("st","s1","x12", "--"),
LArc("s1","s1","^x1", "y2"),
LArc("s1","s1","x1", "y1"),
LArc()
};
FHeatingSwitch::FHeatingSwitch(string strNam, CVarFsaLibrary *pCVFL):
LFsaAppl(TBL_HeatingSwitch, strNam, nullptr, pCVFL)
{ }
bool FHeatingSwitch::FCreationOfLinksForVariables() {
pVarStrInput = CreateLocVar("strNameInput", CLocVar::vtString, "input");
string str = pVarStrInput->strGetDataSrc();
if (str != "") { pVarInput = pTAppCore->GetAddressVar(pVarStrInput->strGetDataSrc().c_str(), this); }
pVarStrInput1 = CreateLocVar("strNameInput1", CLocVar::vtString, "input1");
str = pVarStrInput1->strGetDataSrc();
if (str != "") { pVarInput1 = pTAppCore->GetAddressVar(pVarStrInput1->strGetDataSrc().c_str(), this); }
pVarStrInput2 = CreateLocVar("strNameInput2", CLocVar::vtString, "input2");
str = pVarStrInput2->strGetDataSrc();
if (str != "") { pVarInput2 = pTAppCore->GetAddressVar(pVarStrInput2->strGetDataSrc().c_str(), this); }
pVarStrOutput = CreateLocVar("strNameOutput", CLocVar::vtString, "output");
str = pVarStrOutput->strGetDataSrc();
if (str != "") { pVarOutput = pTAppCore->GetAddressVar(pVarStrOutput->strGetDataSrc().c_str(), this); }
return true;
}
// predicates
int FHeatingSwitch::x1() { return int(pVarInput->GetDataSrc()); }
int FHeatingSwitch::x12() { return pVarInput != nullptr && pVarInput1 && pVarInput2 && pVarOutput; }
// action
void FHeatingSwitch::y1() { pVarOutput->SetDataSrc(nullptr, pVarInput1->GetDataSrc()); }
void FHeatingSwitch::y2() { pVarOutput->SetDataSrc(nullptr, pVarInput2->GetDataSrc()); }
void FHeatingSwitch::y12() { FInit(); }
Код на С++ позволяет, создавать автоматы любой сложности (или, по-другому, активные объекты), которые легко превращаются в элементы библиотек. Включенные в библиотеки подобные активные объекты можно многократно использовать в любом проекте среды ВКПа.
2. О параллелизме ВКПа
"Уж сколько раз твердили миру", что сеть автоматов - параллельная модель, в которой каждый автомат - параллельный процесс, синхронизация которых реализуется путем обмена информацией о состояниях (подробнее о параллелизме автоматов см. [3]). В автоматной сети фактически нет проблем, порождаемых типовым подходом к реализации параллелизма.
Если же мы вернемся к проекту нагревателя, то только прикладных, т.е. относящихся к самому проекту, параллельных автоматов пять. Это рассмотренные выше два автомата, еще два автомата управления индикацией и автомат-интегратор (см. также [1]). Необходимо еще учесть динамически порождаемые параллельные процессы задержек. С учетом диалогов управления средой в нашем проекте в общей сумме одномоментно крутится до двадцати параллельных автоматов. И после этого кто-то еще смеет может утверждать, что в проекте нет параллелизма!? Ну, а если нужно знать точное число параллельных процессов, то их отражает стандартный диалог автоматных пространств. Можно о них получить и более детальную информацию, открыв диалог автоматных переменных. Здесь отражается информация о библиотеке и ее элементе, от которого порожден процесс, и его имя, как процесса. Еще один параллельный диалог позволят управлять локальными переменными процесса. Это ли не в целом параллельное решение, заслуживающее соответствующего тега?
Модель параллельных процессов ВКПа - пример совершенно иного подхода к созданию параллельных решений. В ней все проблемы современных параллельных решений - гонки, тупики, проблемы синхронизация и т.п. решаются на уровне модели процессов, где, повторимся, каждый автомат - это математическая модель отдельного процесса, а все они вместе – формальная модель параллельного множества процессов. Они «по щелчку» синхронизируют свою работу, обмениваясь состояниями. Последнее не просто удобно, а это одновременно формально выверенная процедура взаимодействия автоматов, которая, если потребуется, верифицируется операцией параллельной композиции автоматов.
Сетевая автоматная модель - суть ВКПа. Не признавать ее параллелизм - это лишать человека права дышать, рыбе жить в воде, а птице летать. Ведь, не нужно уточнять, что человек дышит, рыба плавает, а птица летает, а потому нет нужды каждый раз долбить и долбить оговаривать, что ВКПа - это про параллелизм. Можно, правда, называть это "авторским взглядом", но это тот взгляд, который отражен во множестве статей автора и не только на Хабре. Нужны ли еще какие-то аргументы, чтобы отрицать параллелизм ВКПа?
На мой взгляд, если какие-то аргументы и понадобятся, то только в ситуациях, которые невозможно создать/описать в рамках алгоритмической параллельной модели среды ВКПа. И если вдруг (!) такое случится, то это будет крушением основ дискретной кибернетики, в которой автоматы составляют базу [4]. Формально, конечно, подобное исключать нельзя. Допускаю даже, что, может быть, это когда-либо и случится. Но это сродни тому, как пока нельзя доказать отсутствие/наличие Бога. Здесь все сходится к тому, что, как минимум, при жизни автора это не произойдет. Хотя, как знать… Может, где-то что-то уже есть и осталось только опубликовать?
3. Автоматы и SimInTech
Перейдем от общих слов к конкретным делам. И тут вспомним про SimInTech, представив свой вариант реализации автоматных процессов на примере его демонстрационного проекта "Нагреватель" [2]. В этот раз блоками приложения будут автоматные параллельные процессы, реализованные по определенному шаблону на внутреннем ЯП среды. Пример такого решения приведен на рис. 1.
В нем созданы аналоги всех блоков исходного решения в SimInTech (см. рис. 2, а подробнее в [2]). Можно было "упаковать" блоки в субмодели, как это сделано в исходной модели (а мы это еще сделаем), но пока все они будут открыты для оценки структуры и связей проекта.
Рассмотрение начнем с задержки, код которой приведен в листинге 3. Она стартует, когда ее вход (bStart) примет значение не равное нулю. Далее задержка измеряется в дискретных шагах проекта. При этом само ее значение задается в микросекундах - вход delay. На выход блока задержки выдается текущее значение числа шагов задержки – выход value и признак ее активности – выход State (0 - не активна, 1 – активна).
Листинг 3. Код блока «Задержка»
Замечание 1. Чтобы задержка отработала верно, необходимо не только установить значение входа, но до ее истечения его сбросить. В противном случае задержка будет запущена повторно.
Листинг 4. Код блока «Управление»
На листинге 4 представлен код контроллера нагревателя (на рис. 1 – блок «Управление»). Здесь сразу же, т.е. на первом переходе, запускается задержка (40 сек). Для этого нужно установить выход out40 и затем, перейдя в состояние 1 (состояние отключения нагревателя), дождавшись инициации задержки, сбросить тот же сигнал out40. Когда интервал задержки истечет, а температура воды будет меньше заданной, переходим в состояние включения нагревателя – 2, выдав при этом сигнал запуска задержки 20 сек – выход out20. Затем, аналогично состоянию 1 сбрасываем сигнал запуска задержки и ожидаем ее завершения или превышения температуры уставки. Дождавшись или того, или другого, переходим в состояния отключения нагревателя. Далее все повторяется.
Замечание 2. Код автомата на листинге 4 демонстрирует использование «теневого состояния» - tmpState. В процессе работы новое текущее состояние автомата записывается сначала в него, чтобы на новом цикле работы модели стать текущим состоянием.
На рис. 3 приведены результаты тестирования модели. Обращают на себя внимание графики работы задержек. Если до 460-й секунды задержки работают строго последовательно, то далее они пересекаются. На работе модели это не сказывается, но, если подходить строго, такого быть не должно. Для устранения замеченного «непорядка» достаточно ввести сигнал сброса/останова работы задержки.
Замечание 3. Графики задержек демонстрируют параллелизм работы блоков в SimInTech.
4. Где собака порылась?
Но все же, в каком блоке скрываются проблемы «автоматов» исходного проекта? Для локализации ошибки провернем «обратный рефакторинг». В этих целях заменим блоки интегратора – «Интегратор» и ключа – «Key» (см. рис. 1) блоком «Модель нагревателя» из исходного проекта. Получим модель, показанную на рис. 4. Тестирование показало, что результаты работы не изменились. Следовательно, проблема скрывается в блоке «контроллер нагревателя» (см. рис. 2). Только в чем же конкретно эта проблема – вопрос к авторам проекта.
5. Создание модели управления индикацией работы нагревателя
Мы создали модель управления и модель нагревателя, но для реализации в полном объеме технического задания необходимо создать еще и управление индикатором. Возьмем за основу модель, предложенную в статье [1]. Но сначала, используя правильные и хорошие качества SimInTech, запрячем наше управление в субмодель. Такое решение показано на рис. 5.
Теперь можно приступать к модели управления индикатором. Она, как и в [1], будет состоять из автоматов – параллельных автоматов (!) - автоматы зеленого и красного цветов. Именно такое решение показано на рис. 6, где кроме самого проекта – рис. 6а, раскрыта структурная модель субмодели «Индикация» - рис. 6б и далее субмодели «Остывание» и «Нагрев» - рис. 6в и рис. 6г соответственно. А уже их блоки, реализованные на ЯП, приведены соответственно на листингах 5 и 6.
И все бы хорошо, если бы не график индикации, приведенный на рис. 7. Сильно смущает однократный всплеск при переключении индикатора с красного на зеленый (после 475-й секунды). Похоже, что в этот момент суммируются (см. оператор суммы на рис. 6б) значения, определяющие текущий цвет индикатора. По замыслу этого быть не должно.
И такая, казалось бы, небольшая погрешность, на которую реальный индикатор, скорее всего, даже не успеет среагировать, привела к достаточно заметной корректировке моделей. Автоматные модели блоков в окончательном виде приведены на рис. 8.
Структуру модели «Управление нагревателем» с учетом новых задержек (задержки с сигналом сброса) демонстрирует рис. 9. Заметим, что буферный блок для выхода numstate введен, чтобы транслировать на его выход только состояния 0 и 1, игнорируя остальные состояния блока «Управление» (см. на рис. 8 автомат HeatCntrl и его состояния - 77, 40 и 20).
Листинг 5. Коды блоков управления индикатором.
input bInStateHeat, bInStateLed, bIn5sec;
output nOutColorLed, curState, out5sec;
var tmpState=0;
curState = tmpState;
if curState=0 and bInStateHeat = 0 and bIn5sec = 0 and bInStateLed = 0 then
begin out5sec=1; nOutColorLed = 1; tmpState = 51; end
if curState=51 and bIn5sec > 0 then begin out5sec=0; tmpState = 1; end
if curState=1 and bIn5sec = 0 then begin out5sec = 1; nOutColorLed = 0; tmpState = 50; end
if curState=1 and bInStateHeat = 1 then
begin nOutColorLed = 0; tmpState = 0; end // переход при резком изменении режима
if curState=50 and bIn5sec > 0 then begin out5sec=0; tmpState = 0; end
input bInStateHeat, bInStateLed, bIn5sec;
output nOutColorLed, curState, out5sec;
var tmpState=0;
curState = tmpState;
if curState=0 and bInStateHeat = 1 and bIn5sec = 0 and bInStateLed = 0 then
begin out5sec=1; nOutColorLed = 2; tmpState = 51; end
if curState=51 and bIn5sec > 0 then begin out5sec=0; tmpState = 1; end
if curState=1 and bIn5sec = 0 then begin out5sec = 1; nOutColorLed = 0; tmpState = 50; end
if curState=1 and bInStateHeat = 0 then
begin nOutColorLed = 0; tmpState = 0; end // переход при резком изменении режима
if curState=50 and bIn5sec > 0 then begin out5sec=0; nOutColorLed = 0; tmpState = 0; end
А теперь поговорим начистоту. Среда SimInTech – программная реализация, как представляется, гениальной идеи, однако, требующее существенной проверки и доработки. Это пояснит почти любой программист, хорошо знакомый с обычными универсальными языками программирования и средами их разработки - IDE. С гениальностью – сложнее. Лично меня давно «сразила» среда МВТУ, которая единственная на тот момент ввела RS-триггер в режим генерации (правда, ненадолго). А поскольку она – предтеча SimInTech, то восхищение первой естественным образом распространилось и на вторую. Тем более, что в SimInTech есть и другие интересные и интересующие меня черты.
В контексте обсуждения понятия «гениальность» хочется возразить тем, кто считает Россию лучшей страной в мире. Она – не лучшая. Но Россия в чем-то гениальная страна, выживающая в жестком мире рыночной экономики за счет своих гениальных качеств, которые пока еще работают. Помнится, когда-то меня очень впечатлил мультик «Самый, самый, самый, самый». В нем львенок стремится стать самым сильным, самым красивым, самым отважным, самым умным или, короче, самым, самым, самым. Хотя бы потому, что по определению он «Царь зверей». В конечном итоге он им и становится (а куда тут денешься – по праву рождения), но до него доходит, что каким бы сильным он не был – найдется сильнее, каким бы ты красивым не стал – найдется красивее, найдутся отважнее, быстрее, умнее и т.д. и т.п. Бывает и такое – умный царь! И лев - уже взрослый лев - понимает, что главное счастье - найти того, в глазах кого ты будешь самым-самым-самым-самым. И он находит – ее (правда, что уж там скрывать, она его). Ту, для которой он самый-самый. Счастливый конец. Конец, ради которого стоит жить и творить льву и, наверное, любому другому… Так что – смотрите мультики. Лучше старые, советские мультики... А не этот, как его, - «Король Лев».
Россия – далеко не лучшая страна мира. Это факт – статистический. Но есть много, очень много, даже миллионы людей, для которых она самая-самая. И это главное для России, да и, надо понимать, для любой другой страны мира. Смысл жизни: не стремиться быть самым-самым и для этого лезть из кожи. Быть «халифом на час» - не тот путь, который приведет к счастливой жизни. Ну и, конечно, Россию.
Среда SimInTech – явно не лучшая среди себе подобных. Но в ней есть нечто, что на текущий момент делает ее для меня единственной и неповторимой. Познакомившись с SimInTech лишь недавно (с конца прошлого – 2022 года) и, что там скрывать, зная ее достаточно поверхностно, это, тем не менее, позволило в ней реализовать важные для меня «автоматные идеи». Со средой МАТЛАБ такой «любви» как-то не случилось, хотя знаком с ней достаточно давно. Почему так – объяснять, наверное, долго и нудно. Но факт остается фактом – не случилось и все тут. Хотя, как теперь понимаю, в ней можно тоже провернуть нечто подобное. Но все равно SimInTech – первая. Как первая любовь…
Автоматы в SimInTech – совсем не те автоматы, которые я могу признать и даже назвать автоматами. Безусловно, есть и, вероятно, будут те, кто со мной не согласится, и для них они - самые-самые конечные автоматы (как и диаграммы Харелла). Но только, похоже, они теорию автоматов давно не пересматривали. Или они ее просто не признают или уж, что совсем крайний случай, о ней они просто не знают…
Но, как ни крути, в теорию автоматов я все же влюбился раньше. Но ни что не мешает ее чертами наградить и SimInTech. Как это сделать в первом приближении мы показали выше. Может это сложнее того, чем можно было бы сделать, если подумать, но, зато, много надежнее. И уж точно лучше, чем ничего.
Литература
1. Автоматное программирование в SimInTech и ВКПа. [Электронный ресурс], Режим доступа: https://habr.com/ru/post/709358/ свободный. Яз. рус. (дата обращения 28.02.2023).
2. Конечные автоматы в среде динамического моделирования SimInTech. [Электронный ресурс], Режим доступа: https://habr.com/ru/post/307090/ свободный. Яз. рус. (дата обращения 28.02.2023).
3. Модель параллельных вычислений. [Электронный ресурс], Режим доступа: https://habr.com/ru/post/486622/ свободный. Яз. рус. (дата обращения 28.02.2023).
4. Глушков В.М. Введение в кибернетику. Изд-во АН Украинской ССР. К.: 1964. - 324с.
5. Автоматная модель управления программ. [Электронный ресурс], Режим доступа: https://habr.com/ru/post/484588/ свободный. Яз. рус. (дата обращения 28.02.2023).
Комментарии (37)
petuhoff
00.00.0000 00:00+2И несмотря на то, что используемые в Esterel более богатые "richer concept", чем абстрактные теории конечных автоматов, Esterel тоже сильно порезали теорию конечных автоматов, из того же руководста Esterel по созданию высоконадежных системы мы узнаем что:
The definition of SSMs specifically forbids dubious constructs found in other hierarchical state machine formalisms: transitions crossing macro state boundaries, transitions that can be taken halfway and then backtracked, and so on.
These are non modular, semantically ill-defined, and very hard to figure out, hence inappropriate for safety-related designs. They are usually not recommended by methodological guidelines.
Резюме Конечные автоматы в SimInTech не совсем те, о которых говорит теория, но это не SimInTech виноват такие это жизнь такая :))))
lws0954 Автор
00.00.0000 00:00...это жизнь такая
Звучит, прямо скажем, ... грусновато. Жизнь сейчас, действительно, не очень простая, атмосфера, скажем так, - не очень, да и настроение, порой, не всегда радостное, но ... рыба-то в Каме, надеюсь, еще есть! :)
Автоматы сейчас употребляются где не попадя, но ... часто. К месту и не. Esterel к автоматам имеет такое же отношение как DataFlow или StateFlow. Поэтому нужно
уметьотделять котлеты от мух. Иначе будет полный фарш ;) При этом, конечно, не надо его выбрасывать насильно. Пусть будет. Кому-то он нравится и даже, видимо, приносит пользу. Ну, ... жизнь такая. Она разнообразна. Но жрем "чо не попадя" тоже часто...Если чуть серьезнее, то выше я показал, как в SimInTech можно автоматы "наживить". Далеко не идеал, но все же не ... "фарш". Уже можно потреблять, не боясь отравится. Вот, как-то так. Если честно, то меня даже "отпустило" после последнего (надеюсь, крайнего :)) проекта. Все не так уж безнадежно. А то уж была совсем печалька...
Даже вспомнилось бодрое - "мы рождены, чтоб сказку сделать былью..." Вот, честно, раньше жизнь была и веселее, и бодрее, и перспективы были реальные... Но, наверное, это уже ... возрастное :(
Да,
Резюме Конечные автоматы в SimInTech не совсем те, о которых говорит теория ...
Они совсем не те. Это я говорю ответственно. Или, скажем мягче, я не вижу связи между ними и теорией. От слова совсем. Есть слова "конечный", "автомат", которые используются и там и там. И не более того. Может все это звучит резко, но ... есть колеты и есть мухи и они, как известно, не совместимы друг с другом. Точно также и здесь... :(
petuhoff
00.00.0000 00:00+1Согласен с потенцеальной возможностью "оживить" автоматы. Но реальная жизнь требуе совсем другого. Вот ребята в Esterl делают код для критических систем, важных для безопасности, причем код создают в графическиз диаграммах, а грузят его в контроллеры в виде кода си. И генератор кода, который из схемы выдает Си в железный контроллер у них сертифицированный по авиационным и транспортным стандартам.
И вот приходят к ними теоретики с 50 летней историей развития математической теории конечных автоматов и показывают, эти схемы. "Типа я так могу, я и так могу, я и так могу и чере этак..." смотрят на эти диаграммы инженегры Естерель и спрашивают, а как же я все это проверять буду и сертефицировать? Если в простом блоке упрааления идикатором 18 условий if? А если у меня система с тремя - пятью уровнями вложенности?
Нет, говорят инженеры, всю эту теоретическую красоту я в читаемую схему и сертифицированный кодогенератор запихнуть не смогу. Давайте мы из теории конечных автоматов, оставим состояния и простые переходы, мы их в коде операторами case заменим, и будет всем счастье при проверке и сертификсции. А все эти ваши изыски с возвратами, переходами через границы макросостояний состояний, и множествами if- ов в конечном коде нафиг. "А ты кто такой? Давай досвиданья!"
Ну а в SimInTech, прсмотрели на теорию конечных автоматов. Почесали затылок. Есть у нас блок условного выполнения субмодели? Есть. Что он делает? Он морозит диаграмму в субмодели. Так вот оно самое, конечные автоматы это когда одна субмодель выполняется - активное состояние, а другие - нет. Еврика, берем стандартные субмодели называем их состояниями, а переходы это те же линии связи, но соединяются с блоками условного выполнения, цвет поменяем что бы не путали и будет у пользователя счастье - конечные автоматы. Алах акабар!
Ну если кто-то хочет, свои правильные высоконаучные, кошерные автоматы - you are welcome - среда открыта. Mожно свою библиотеку блоков написать, даже на Си. И продавать всем страждущим.
lws0954 Автор
00.00.0000 00:00С инженерами из Esterel мы еще пообщается и разберемся с их заблуждениями... Я пока хочу задать вопрос инженерам из Бауманки.
Я создал проект "Нагреватель" в SimInTech. Ну, люблю я ее. Очень! :) А она, ведь, насколько мне известно сертифицирована. Так? Но я ни кому не говорю, что в процессе проектирования использовал некие "мудреные автоматы". Так? Я также надеюсь, что при этом ни кто меня не заложит, что я такой "умный". Могу ли я на это рассчитывать? Но даже, если кто-то заложит, то я отрекусь и ни кто не докажет, что я использовал при проектировании некую автоматную модель (а графы просто сожру).
У меня вопрос. Ну, очень важный. Мой проект пройдет сертификацию?
petuhoff
00.00.0000 00:00+1Надо смотреть какие блоки и функции вы использовали при создании проекта. Библиотека постоянно расширяется, в приложении к сертификату есть набор блоков, и набор функций языка програмирования, которые проверялись сертифицирующими органами. Если блоки и функции из списка сертифицированных, то в процессе сертификии вашего ПО, созданного в SimInTech вы можете пропустить часть тестов (не все) оборудования управления для АЭС.
Например сертифткат гарантирует, что блок сравнения сгенерирует код Си, который обеспечит правильный результат сравнения значения давления в системе с уставкой (заданым значением в проекте). Но этот сертификат не гарантирует, что пользователь при создании проекта указал правильное згачение заданного давления. Может и ипанет если ошибся разработчик. Сертификат гарантирует только то, что дополнительных ошибок не будет.
lws0954 Автор
00.00.0000 00:00+1Другая ситуация. Я чиновник, которой сертифицировал SimInTech. Я ставлю свою подпись, я рискую своей репутацией. Рабочим местом, в конце концов! И вот случайно мне попадается или мне приносят статью в которой приводится пример на SimInTech, содержащий явную ошибку, но выявленную сторонним программным средством. Проверка убеждает, что последнее не ошибается.
Что мне делать? Отзывать лицензию? Или "прикинуться ветошью и не отсвечивать"? Но, ведь, и то и другое - чревато последствиями. А там - подмоченная репутация, дети голодные, жена вся в бриллиантах (пока еще) ... Что Вы мне посоветовали бы? Стреляться не буду! Да, сидеть тоже не хочу (предупреждаю - сдам всех!)
petuhoff
00.00.0000 00:00Пока я не вижу никакой ошибки которая могла влиять на сертификацию здесь.
А если заказчик находит ошибку и рассхождение при генерации кода, то есть процедура определения риска, и процедура устранения ошибки, с документирован ем процесса тестирования.
Это нормальная ситуация дле сретифицированных продуктов. При выпуске новых версий указываются изменения и устранение выявленных ошибок.
lws0954 Автор
00.00.0000 00:00+1И тут приходят ... инженеры из Esterel.
О, да, мсье Петухов, мы Вас очень понимать - говорят они. У вас в Россия есть сертификация, но она не действует у нас - во Франция! Мы есть проверять проект, который сделал Вы нам - Нагреватель. Ок! Очень корошо! Но у нас есть один въедливый инженер, который заметил один дефект. Вот он.
И они демонстрируют график:
График температуры исходного проекта
Это момент выхода на режим. О, да! Мы пытались улучшить - изменили настройки проекта - уменьшили шаг, изменили метод интегрирования, но только добились следующего:
Показывают другой график:
График температуры с новыми настройками
Здесь шаг на два порядка меньше - 0.00001, мы взяли метод интегрирования - Эйлера. Мы, есть, ждать аж 16 мин! Но... мало что изменилось - дефект не ушел.
Что есть у Вас сказать, мсье Петухов? Ведь мы не пройдем сертификацию во Франция! Ок?
...
И теперь уже серьезно говорю я...
Что нужно сделать, чтобы график соответствовал требованиям, предъявляемым к подобной
весьма простойсистеме управления! При этом - есть такой промах - в ТЗ об этом - точности регулирования не сказано ни слова. Но говорить так - потерять заказчика! Ведь, все довольно очевидно. Где, как говорится, собака порылась?petuhoff
00.00.0000 00:00А в чем здесь дефект? Нормальный выход на режим, что хотите получить нагревателе?
lws0954 Автор
00.00.0000 00:00+1Смотрим на график второй - с более точными настройками. 475 сек- дошли до уставки и пошли остывать. Дошли до темр. 19.84 - пошли нагревать. Далее - дошли до 19.96 - пошли остывать. Но почему не дошли до 20.0? Время нагрева истекло? А тогда почему дальше - от такой же температуры доходим до 20.0 за это же время...После 550-сек пила-то другая - стабильная - 20.0-19.84, 20.0-19.84, 20.0-19.84...
Может, я что-то не учитываю? Но ВКПа дает "стабильную пилу" после достижения уставки. В ней ошибка? В чем? Подскажите - я учту это. Почему для Вас - это норма, а у меня - нет. Хотелось бы понять...
petuhoff
00.00.0000 00:00Да действительно дефект, время таймера не сбрасывается при выходе из состояния, и при следующем входе в состояение таймер включается не 20 секунд, а с уже накопленного времени! Через несколько циклов работы в режиме включения, таймер доходит до 20 секунд и вырубает нагреватель, хотя температура все еще ниже уставки! Курто! Я выше писал, что смесь конечных автоматов и dataflow, удобна, но черевата коллизиями, и конкретно приводил пример интегратора. А ведь таймер задержки это тот же самый интегратор!
Логика собранная из стандартных блоков работает так как должна, но не так как хотел разработчик ;))))
- А если ипанет?
- Не должно!
- Ипануло!
Самое интересное, что такая логика работы тоже имеет право на существование, например если, в требованиях стоит остановка процесса после заданного общего времени нахождения в рабочем состоянии.
Но, конечно не в нашем случае, у нас время должно сбрасываться согласно ТЗ. Это явная ошибка разработчика логики работы. На сертификат ПО разработчика это не повлияет, а вот на разработчику логики нагревателя нужно выписать большую звездюлину!
Именно поэтому теория конечных автоматов и порезана в Esterel , что бы меньше было таких коллизий.
lws0954 Автор
00.00.0000 00:00+1А ведь таймер задержки это тот же самый интегратор!
Ну, я бы не стал так обобщать. А то появятся задержки Эйлера, Адаптивная1, 2... Хотя задержка Мерсона или там Гира звучало бы круто ;)
Именно поэтому теория конечных автоматов и порезана в Esterel , что бы меньше было таких коллизий.
Автоматы совсем тут ни при чем. Если что-то и надо резать, то только тем, кто покушается на автоматы.
Я так и не понял, что Вы сделали (но, если честно, то и не пытался :) Но надеюсь, что все теперь будет работать. Но я понял одно - у Вас задержка приостанавливала свою работу. Сделать-то это не проблема, но ... зачем? У меня в статье тоже была проблема с задержками (см. статью и рис. 3). Но, во-первых, она не останавливалась и не создавала проблем, но я все же ее обрубил и ввел режим сброса. Т.е. попросту расширил ее режимы. Мог бы, кстати, ввести и режим приостановки отсчета задержки. И, кстати, возможно, он бы и потребовался.
petuhoff
00.00.0000 00:00ошибка в том, что разработчик не читал хелп по блоку. А там описана логика работы данных блоков. Они предназначены для задания минимального времени нахождения в состоянии. Вошли в состояние, выдежали заданное время, - выходим из состояния. Тогда все работает отлично. А в модели данный блок используется для задания максимального времени работы, а не минимального. И получается что вошли в состояние, запустили блок и пошел обратный отсчет времени, до выхода. Но вышли-то мы из состояния по другому условию раньше минимального времени. При этом блок задержки уже насчитал какое-то время, и запомнил это время при заморозке состояния. (скорее всего там в коде стоит блок обычный интегатор). И при следующем входе в состояние мы обратный осчет ведем уже не 20 секунд задержки, как планировал разработчик, а с того времени которое запомнили при предыдушем выходе из состояния. И с каждым включение время задержки уменьшается, пока она не выключит нагреватель, до достижения заданной температуры. Пила не достигла заданного значения. После этого она сбросится и снова будет 20 секунд. И вот вам результат на графике. Кстати видно что в дальнешем эта ситуация снова повторится.
lws0954 Автор
00.00.0000 00:00+1ошибка в том, что разработчик не читал хелп по блоку...
Навскидку. Основная ошибка в том, как вы работаете с состояниями. Для меня - это полный абзац! Вы входите в состояние, копошитесь там и т.д. и т.п. Состояние - неделимая единица. Это всего лишь элемент множества. И даже если оно само представлено, как множество - это только иерархия и не более того. Все, о чем Вы пишете - это нарушение концепции автомата. Из этого надо исходить.
Здесь опять нужно отделять котлеты от мух. Хотя, может, лучше апельсины от яиц :) Есть автомат - как модель управления и есть предикаты и действия, как дополнение к автомату. Вместе они - полноценная алгоритмическая модель. Без них автомат - ничто. И тогда легко уже понять что, где и как работает и кто за что отвечает. Разделяй, как говорится, и властвуй. Как-то так... ;)
petuhoff
00.00.0000 00:00ну это теория, а на практике я вот читаю ТЗ, переключение режимов работы системы связи самолета. А там список режимов и условия перехода из режима в режим. Для меня кажется очевидным и логичным, взять логику работы в различных режимах и пометсить ее в субмодель автоматов состояния, и тогда переключая автоматы состояний я буду получаю в каждый момент непрерывно работающие алгоритмы соотвествующие режиму выбранному автоматами. Красиво и наглядно. Смотрим на схему видим каое состояние активно входим в него, видим работающий алгоритм, переключилос сотстояние - работает другой алгоритм в дрругом активном состоянии.
lws0954 Автор
00.00.0000 00:00Ну, я тоже читаю ТЗ, когда оно/они есть, конечно. Но наша практика такова, что часто тебе дают такое ТЗ, которое таковым можно считать лишь условно.. :) Поскольку хорошее ТЗ - это отдельная "теория" и, конечно, практика.
Для меня красивым можно считать решение, состоящее из множества параллельно работающих автоматов - сеть автоматов. Во-первых, в этом случае автоматы будут меньше (а, значит, проще), во-вторых, система будет гибче, в-третьих, их можно проектировать/отлаживать достаточно независимо и т.д. и т.д.
Для Вашего примера можно было бы сделать так (по крайней мере я бы делал так). Создать автомат режимов и в нем сконцентрировать логику управления режимами. Да, было бы удобно каждому режиму назначить свое состояние. Т.е. мы имели бы процесс, по состоянию которого можно было бы судить о текущем режиме работы.
Далее. Можно было бы для каждого режима создать свой процесс (автоматный, конечно). Каждый из них реагировал бы на соответствующее состояние процесса режима. Т.е. мы имели бы сеть из автоматов: автомат режима и автоматы для каждого режима.
Такая сеть, как мне кажется быстрее реагировала бы на смену режима, т.к. автомат выбора режима работает параллельно с автоматом реализации самого режима. Была бы только две проблемы - среагировать быстро на смену режима и завершить корректно текущий режим, чтобы перейти к новому режиму. Но все это уже дело техники. И, самое главное, все в рамках теории, работающей на практике. Любой практике :)
Из своей же практики я сделал вывод, что за критикой той или иной теории, как правило, скрывается непонимание \этой теории. Поэтому, например, я не критикую теорию инженеров Esterel, я даже не вправе критиковать Ваши подходы к проектированию Это Ваше право и право инженеров Esterel проектировать так, как нравится. Я критикую или даже возмущаюсь только в том случае, когда идет не справедливый наезд на автоматы, на их теорию, на ее ограниченность в смысле практики и т.д. Это все, мягко говоря, идет от не понимания теории и возможностей автоматов. Других причин я не вижу, т.к. в своей практике применения автоматов я ограничений не испытываю - только преимущества.
petuhoff
00.00.0000 00:00Кстати еще раз убедился как же это круто, когда логика в графическом виде и можно анализировать наглядную схему. И при этом гонять режимы работы. Если бы та же логика была бы в виде кода фиг бы я нашел ошибку так быстро, если вобще бы нашел. Визуальное программирование рулит!
lws0954 Автор
00.00.0000 00:00Визуальное программирование рулит!
Я бы сказал Визуальное Компонентное Программирование автоматное рулит! :).
Но я бы не стал так уж графику "фетишизировать". Нужно чтобы одно дополняло другое. У кода несравненно больше возможностей. Особенно на С++. Но, например, полноценной визуализации ВКПа, конечно, не достает :( Хотя ее "компонентность" и "автоматность" во многом помогают не меньше, чем полноценные графические структурные схемы. Хотя, еще раз, графические возможности - это моя
несбыточнаямечта :) .До этого была мечта - автоматы. Вот ее яуспелреализовал, как задумал много-много лет тому назад :) И пока я ошибки легко и просто нахожу именно в коде. А если бы еще графика была!...petuhoff
00.00.0000 00:00А представте вы код отдаете кому то другому? Сможет он находить так же легко ошибки? А в SimInTech я просто на линиях связи поставил графики и посмотрел, что происходит на схеме в каждый момент времени. И это можно сделать вообще не зная кода.
lws0954 Автор
00.00.0000 00:00Код коду рознь. В ВКПа - сможет. Я также могу обвесить блок/блоки графиками (в статьях это демонстрируется). Кроме того, я вижу состояние, я контролирую переходы, т.е. вся логика работы блока и его взаимодействие с другими блоками на виду. Я локализую ошибку до предиката или действия. А эти функции чаще всего небольшие и уже их понять - не проблема.
Просто автоматы у меня не покоцанные, как у некоторых инженеров из Esterel, а полноценные, нормальные - усовершенствованные до сетей, но при этом классические :)
petuhoff
00.00.0000 00:00А эти функции чаще всего небольшие и уже их понять - не проблема.
Вот про это инженеры Esterl в своем руковдстве и пишут:
However, in practice, they have not been adequate even for medium- size applications, since their size and complexity tend to explode very rapidly. For this reason, a richer concept of hierarchical state machines was introduced.
Как только функции перстают быть небольшими, а становятся даже средними - все сливайте воду тушите свет. Черт ногу сломит, в ваших теоритических автоматах. Нужно резать!
lws0954 Автор
00.00.0000 00:00Ну, во-первых, инженеры пишут про другое. Они пишут, что отсутствие иерархии порождает большие автоматы. Они сетуют за введение ее. И это правильно. Молодцы инженеры. Но только какую иерархию они вводят? Уточните, прежде чем мы их начнем пинать в ... самые больные места (а, может, наоборот - будем благодарить :)).
Еще раз. О какой иерархии говорят инженеры Esterel? Виды иерархии могут быть разные. О каких конкретно идет речь? Зная это, уже можно, например, сравнить и с моделью ВКПа. В этой модели, ведь, тоже есть иерархия автоматов. Пока одно только бла-бла-бла...
petuhoff
00.00.0000 00:00Не они не говорят, что вводят иерархию которой нет, они говорят что у них свои автоматы, более богаты чем другие иерархические автоматы.
a richer concept of hierarchical state machines was introduced
"более богатая концепция иерархических автоматов". Судя по гайду у них есть вложеность автомата в атомат и совместное использование автоматов и диаграмм алгоритмов на одной схеме. А вот все осталное богатство теории конечных автоматов, включая другие иерархические автоматы, обьявлено сомнительным и обрезано.
The definition of SSMs specifically forbids dubious constructs found in other hierarchical state machine formalisms: transitions crossing macro state boundaries, transitions that can be taken halfway and then backtracked, and so on.
These are non modular, semantically ill-defined, and very hard to figure out, hence inappropriate for safety-related designs. They are usually not recommended by methodological guidelines.
У меня нет проекта Esterel только их руководство, маемо шо маемо.
Можно ли у них внутри состояния автомата соорудить пид регулятор, непонятно. В Simintech можно поскольку состояние это таже субмодель, только морозится при выходе и запускается при входе в состояние.
lws0954 Автор
00.00.0000 00:00...более богаты чем другие иерархические автоматы
Без указания какие - это беспредметный разговор, т.е. ни о чем. Например, есть книга А.Н.Мелихова, где приводится алгебра автоматов и в ее рамках - операции с ними, порождающие новые автоматы. Это конкретно. Это понятно о чем идет речь. "... более богаты" - это ни о чем. Чем "более", по сравнению с чем "более", насколько они "богаче" - в долларах, рублях, попугаях и т.д. Нет информации. От слова совсем.
Можно ли у них внутри состояния автомата соорудить пид регулятор, непонятно. В Simintech можно ...
Если можно, то сразу понятно, что это скорее плохо, чем хорошо. В моих базовых статьях по теории автоматной модели программ - это подробно расписано. Нельзя во внутрь невпихуемого что-то впихнуть. Ваше право соорудить что угодно, но давайте не будем это что-то называть "конечный автомат". Или Вы должны обосновать это. Делается это описанием приведения Вашей модели к модели классического автомата. Только так.
В конечном автомате нельзя что-то создать кроме того, что может состоять из его элементов. Интегратор, регулятор содержат память. Подобной памяти у автомата нет. Есть только состояния, которые обычно называют памятью. Но это другой вид памяти - память об предыстории его работы. .
Упомянутые объекты выполняют какие-то операции. Ни каких операций у автоматов нет. Но есть сигналы, которые могут запускать операции... Но все это известно, все это описано. В теории проектирования дискретных устройств (Майоров, Новиков, Баранов, Глушков...). Давно. Очень давно. И даже у меня ;) Почему все это игнорируется - не понятно. Мне не понятно... Открывай, читай и все поймешь. Но как-то Esterel больше заходит. Может, потому, что "нет пророков в своем отечестве"?
Конечный автомат - очень бедная по своим возможностям модель. Конечно, с точки зрения понятия алгоритма. Но она прекрасная модель управления для него же. А просто что-то хаять, просто заниматься "распальцовкой" - это позиция "для бедных". Нужна конкретика. Лучше на уровне теории. Иначе, еще раз, это будет всегда бла-бла-бла.
Ну нельзя по теории "внутри" состояния что-то соорудить. Тем более пид-регулятор. Можно создать его вариант с автоматным управление, может быть интегратор с автоматным управление, может быть что угодно с автоматным управлением, но ни что из упомянутого нельзя считать конечным автоматов. Где словам "конечный автомат" соответствует строго математическое определение. Сможете в его рамках описать хотя бы интегратор - другое дело. А так ...
petuhoff
00.00.0000 00:00Ну нельзя по теории "внутри" состояния что-то соорудить. Тем более пид-регулятор.
Ну вот, если практика противоречит теорию, тем хуже для практики! Или теория маркса ленина вечна, потому что она верна! Смешно.
На самом деле мы в SimInTech исходили как раз из практики, и наглядности формиования программ для АСУ ТП, в виде графических диагамм алгоритмов. Смотрели на Matlab, но сделали под другому.
Кстати вот картинка Esterel. У дураков - практиков мысли сходятся, не читают теоретиков марксизьма ленинизьма и математиков. Делают как удобно инженерам. Если перешол в состояние, то прямо в нем можно изобразить алгоритм управления. Перрешел в другое сотрясение - другой алгоритм. И прямо на диаграмме это видно, как в SimInTech. На картинке постые прямоугольник это DataFlow, где ПИД и все передача сигналов по линии связи, а прямоугольники с круглыми каями и заголовком это конечные автомты их состояния
petuhoff
00.00.0000 00:00Вот здесь есть болле подробное описание: https://ptolemy.berkeley.edu/projects/chess/design/2012/lectures/EE249_9_lecture-esterel.pdf
lws0954 Автор
00.00.0000 00:00Господа инженеры из Esterel! Давайте решим одну Вашу задачу. Она представлена графом ниже.
Автомат ARBO
Рассмотрим следующую спецификацию контроллера:
Выдайте выходной сигнал O, как только будут получены оба входных сигнала A и B.
Сбрасывайте поведение всякий раз, когда поступали входные данные.
Это все еще немного двусмысленно; для завершения:
Если происходит R, ничего не излучайте
Ничего не делайте во время инициализации
Входные сигналы могут быть одновременными
Выше описано поведение некоего, прошу прощения у научного сообщества, "автомата". Все это творчество переводчика Яндекса :). Он также перевел и название: Пример ABRO—Мучнистый стиль. Вот уж, действительно, "оговорка по Фрейду :)
Ну, да ладно.
Во-первых давайте поймем что это за "мучнистый автомат". Он явно не абстрактный. У абстрактного один вход и один выход, а потому на переходах комбинаций сигналов не должно быть. Как бы, автомат и не структурный (это уж совсем другая "песня"). Имея множество входных каналов он смахивает на автомат с абстрактных состоянием, который рассматривается Закревским. Но опять же, на вход поступают явно символы, а не логические переменные. Короче - винегрет!
Поэтому мне понятны метания и страдания инжнеров Esterel: им подсунули автомат и сказали, что это теории автоматов. Нет, может, у вас во Франции, действительно, такая теория автоматов?! Но у нас в СССР, а теперь, надеюсь, и в России (как правоприемницы) - другая. Поэтому, когда вы критикуете теорию автоматов, то, очевидно, речь идет о разных теориях. Так, по-видимому?
Хорошо. Приведем вашу теорию к нашей. Точнее, попробуем привести. Поскольку речь идет не о символах, а сигналах, то пусть они будут логические A-x1, B-x2, R-x3, O-y1. А сигналы какие - потенциальные или импульсные? В нашей теории они по умолчанию потенциальные (в абстрактной теории, правда, - символы). Но с такими будут явные проблемы, т.к. они могут длиться дольше одного такта. Тогда с поведением будут проблемы. Пойдем, как это ни противно, на компромисс и посчитаем их, во-первых, импульсными, во-вторых, что они попадают ровно на границы дискретного такта.
А, блин, ... а как обозначать отсутствие сигнала - 0? Когда, например A-1, ^A (не A) - 0, а отсутствие сигнала A как? Может, тогда пусть останутся символами? Блин! Но... Действительно, на фиг такая теория! Вы молодца инженеры из Esterel, когда критикуете свою теорию! А если дальше копать... Это частичный или полностью определенный автомат? Вроде частичный. А как он будет себя вести в ситуациях, которые не определены (для трех сигналов на входах - это 8 разных комбинаций и должно быть для каждой определен переход)?... Да ну их, в конце-то концов!...
Нет! "Такой хоккей нам не нужен"! ...
Не исключено, что каждая страна имеет cвою теорию. Но как тогда найти общий язык? Ведь, одно из предназначений теории - формирование единого языка, однозначно понимаемого специалистами и учеными все стран. А иначе получается ровно, как у нас. Я говорю конечный автомат - это то-то и то-то. А инженеры из Esterel - это так-то и так-то. Я хвалю, они - ругают. Но получается, что мы имеем в виду разные вещи? Так к чему "копья ломаем"?
Это хорошо, когда есть теория и очень плохо, когда ее нет. Но еще хуже, когда теория есть, но ее игнорируют, обосновывая некими "практическими удобствами" или самим отрицанием необходимости теории - мол, мы практики и без нее жили хорошо и будем жить еще лучше, если она не будет мешаться под ногами и капать нам на мозги. Нормально? Зачем нам какой-то "вечный марсизм-ленинизм", ведь, мы и сами с усами! На фиг сжечь эти "сильно умные" книжки (более мягкий вариант - не читали и не будем читать)!
Но вдруг- откуда бы? - проблемы! Возникшие из ниоткуда они часто объясняются именно теорией, а не некой верой в незнамо что... Кто такие Нейман, Глушков, Тьюринг, Минский, Баранов, Майоров и Новиков, Поспелов, Варшавский, Гилл, Гаврилов и сонм менее известных?... Так, какие-то лауреаты, академики, доктора, а кто-то просто кандидаты. А тут еще без всяких степеней нам что-то советуют! Совсем "кукуха поехала"?! Писаришки жалкие, бумагомараки! Практики-то, небось, в глаза не видели? Жизни не знают... Не то, что мы - инженеры Esterel! ;)
Вот... и поговорили с инженерами Esterel :)...
Поймут, примут - будем очень рады помочь, объяснить, доказать, показать, поделиться опытом и т.д. и т.п. И от их
полезногоопыта не откажемся... Не поймут - не беда. У них своя теория, у нас - своя. Оставим времени рассудить кто прав, а кто не очень... А, может, перефразируя классика, - "все теории важны, все теории нужны"? Но мне, как и самим инженерам из Esterel, их теория автоматов, ну, совсем не нравится! Как минимум, в том варианте, который они представили.И еще, так сказать, в догонку. Господа французские инженеры из Esterel, мы, инженеры Советской школы (а ныне Росссиянские инженеры - есть такой казус в нашей истории и мы пока еще живы) и ученики академика АН СССР и президента АНУССР Глушкова В.М. (подробнее о нем см. ВикипедиА), предлагаем наше решение вашей серьезной проблемы ABRO. Ее, похоже, "по шелчку" решает (может решить) фактически простенький логический элементик И. Достаточно строго представить это можно следующим автоматным алгоритмом:
Автомат ARBO
Для этой модели не нужен сигнал сброса R. Она без него "ловит" одновременное появление символов A и B, выдавая символ O и, сбрасывая его, если любой из этих символов пропадает (см. выше ТЗ на проектирование: Выдайте выходной сигнал O, как только будут получены оба входных сигнала A и B).
Будьте так добры, дайте свое заключение на представленное решение...
lws0954 Автор
00.00.0000 00:00+1Что-то инженеры из Esterel отмалчиваются :(
Может, инженеры из Бауманки помогут разрулить ситуацию?
Повторю вопрос (по сути - их два): 1) правильно ли мы преобразовали исходную модель автомата в новую? 2) отвечает ли требованиям ТЗ новая модель?
petuhoff
00.00.0000 00:00Нет не правильно. Сигнал нужно ассмативать как булевую переменнюу. Поэтому A,B, R, O это просто логические переменные presetn - 1, absent - 0. И это не автомат, а спецификация алгоритма. Поэтому выкидывать из ТЗ сигнал R, нельзя. А может это какой то аварийный режим который должен глушить O, несмотря на состояние А и B?
Esterel programs/SSMs communicate through signals
These are like wires
- Each signal is either present or absent in each tick
- Can’t take multiple values within a tick
- Presence/absence not held between ticks -
- Broadcast across the program
- Any process can read or write a signal
lws0954 Автор
00.00.0000 00:00Спасибо за ответ инженерам Бауманки. Они более ответственны в этом плане, чем инженеры Esterel. Но...
Замечу, что я также рассматриваю сигналы, как булевские переменные. По поводу сигнала R. Да, в новой модели его нет и он сбрасывает сигнал O. Но он сбрасывается логикой работы алгоритма. Но и в старой "спецификации" сброса фактически нет тоже. От слова совсем. Я приведу старую модель в форме новой. Она будет следующей (замечу, что это будет именно конечный автомат Мили).
Конечный автомат Мили ABRO
Где в ней сброс сигнала O? Предположим, мы выдали сигнал O, а потому находимся в состоянии S4. Тут же возникает практический вопрос - кто и как его фиксирует. Ну, да ладно, не будем размениваться на мелочах. Пусть он как-то зафиксировался в S4. Сбросить его можно на переходе в S1. Но где команда на его сброс?
И вообще на графе я вижу установку O, но нет ни одного сброса выходного сигнала. Хорошо, забудем и про эту "мелочь" (что-то они начинают копиться). Но, если входы остались в том же состоянии AB, а мы при этом успели убрать R, то тут же будет переход в состояние S4 и O будет опять установлен. Т.е. пока держим R O будет сброшен, а только его сбросим, то при установленных AB он опять будет установлен.
Поэтому, чтобы сбросить реально сигнал O сигнал R должен достаточно длинным (как минимум, более такта автомата). И надо ли ждать предыдущего сброса сигналов AB, чтобы распознать их новую установку. Еще одна мелочь? Не много ли для начала?
Далее. Зачем "пустой переход" S0->S1? Если нужен, то где его необходимость отражена в ТЗ? Напомню также: а как в "спецификации" представлен сброс однажды установленного сигнала O?
Дальше - больше. В ТЗ говорится об обнаружении ситуации "A и B", где ключевое - союз "и". Я могу представить, что заказчик не имеет понятия о логических операциях, но исполнитель-то булеву алгебру знать должОн. В исходной "спецификации" ловится не только ситуация AB (см. переход с условием x1x2^x3), но последовательная во времени установка сигналов, т.е. A,B и B,A. Как это звучит в ТЗ? И не оговаривается также пауза (или ее отсутствие) между этими сигналами. Снова "мелочь"?
Короче, если следовать строго формулировке ТЗ, то я бы, как разработчик, настаивал бы на новом варианте. А если бы заказчик настаивал бы по сути на создании фильтра для сигналов А и B, то это требовало бы новой формулировки ТЗ и дальнейшего уточнения "спецификации алгоритма".
Хотя, с другой стороны, почему "спецификация алгоритма" не может быть представлена и называться моделью конечного автомата? Ведь, в она в ТЗ так и называется - "мучнистый автомат" :)
Возникает просто "туча" вопросов по данному ТЗ и его "мучнистой спецификации", которые затрудняют процесс создания практической реализации этого самого ТЗ.
Но самое удивительное, что, похоже, инженеры Esterel не понимают или совсем не знают элементарных логических операций. И уж сложно предположить, что они знают и понимают смысл двух видов формальных моделей реальных устройств - функциональной и последовательностной (на фиг им эта теория!). Но, может, во Франции такая теория проектирования дискретных устройств? А, скорее всего ,ее полное отсутствие?
Безусловно, Бурбаки внесли весьма значимый вклад в теорию математики, но было бы интересно знать кто во Франции отвечал за развитие дискретной математики (теории множеств, булевой алгебры и т.п.)?
Я конечно не истина в последней инстанции, могу
ошибаться или что-то не до конца понимать, но на мой взгляд без "абсента",
похоже, с подобной "спецификацией алгоритма" сложно будет разобраться.
Больно много "мелочей"...petuhoff
00.00.0000 00:00По паузам там выше в тексте описана работа системы. Поскольку система предназначена для работы в реальных системах управления, а не в теоретических построениях, то время там разбивается на такты:
Time is divided into discrete ticks (also called cycles, steps, instants)
Two types of statements: I Those that take “zero time” (execute and terminate in same
tick, e.g., emit) - Correspond to Connectors in SSMs
Those that delay for a prescribed number of ticks (e.g., await) - Correspond to States in SSMsПоэтому никакого время возникновения А и B нет. Все происходит в рамках такта одновременно. A,B,R это просто входные сигналы. Если только, А ничего, если А и B тогда 0 = true (present). Если R то все сбрасываем и 0= flase (absent). На следующем такте A,B,R снова рассматриваются как внешне сигналы.
To summarize: the synchronous model of computation of
SSMs/Esterel is characterized by:Computations considered to take no time (synchrony hypothesis)
Time is divided into discrete ticks
Signals are either present or absent in each tick Sometimes, “synchrony” refers to just the first two points (e. g., in the original Statecharts as implemented in Statemate); to explicitly include the third requirement as well, we also speak of the strict synchrony.
lws0954 Автор
00.00.0000 00:00И еще. Планировал написать, откуда проистекает такое мое отношение к технологиям вообще и к ТЗ в частности. Когда-то, уже давно, прочитал книгу Захаров В.Н., Поспелов Д.А., Хазацкий В.Е. Системы управления: Задание, Проектирование, Реализация. Великолепная книжка о том, как взаимодействовать с заказчиком, создавать ТЗ и проектировать. И это 1977 г. До сих пор считаю - актуальна.
Сегодня попытался найти ее в Инете (у меня есть бумажный экземпляр). Нашел. Вот ссылка: https://www.studmed.ru/zaharov-vn-sistemy-upravleniya-zadanie-proektirovanie-realizaciya_e794a6616e3.html. Кому интересна эта тема, а она должна быть интересна любому нормальному инженеру, можно скачать. Можно, конечно, обсуждать ее содержание, т.к. все же это конец 70-х годов, но замысел и посыл ее актуален и вечен, как и "марксизьм, ленинизьм" :)
И еще один факт в цепочке, которая привела меня к конечным автоматам. У нас в отделе был фото-координатограф (сейчас таких уже не делают:). Он был спроектирован, видимо, ровно по книжке Майорова, Новикова, которую я только что, будучи молоденьким инженером, проштудировал. Впечатление - "колоссаль" я вам скажу! Особенно на фоне векторного дисплея от серии ЕС ЭВМ, который мне нужно было подключить к СМ ЭВМ. На его стойке (примерно с большой холодильник) стоял даже знак качества! Но разрабатывали ее, видимо, инженеры-практики ;) Качества не было от слова совсем. Разобраться в этом хитросплетении проводов было просто невозможно, надежность - жуткая. Работал только от пинка ногой сзади по корзине с платами (а там был витой монтаж). Но свою задачу - подключить я, кстати, сделал. Но два таких разных подхода инженерного проектирования наглядно показали, как надо проектировать "по науке"(см. книгу;), а не от некой "практики". Первый в случае отказа ремонтировался по щелчку отставным военным (авиационный инженер), а второй - пинком сзади :)
petuhoff
00.00.0000 00:00Ну сравнение инженеров Esterl c монтажниками плат СССР в конце отчетного квартала, или после празднования великой октябрьской социалистической революции, мягко говоря не совсем справедливо.
Esterl это мировой признанный лидер в создании ПО для разработки критических систем в Авиации, жд транспорте. Все Боинги и Аирбасы летают без всяких пинков, и управляются ПО разработанным в системах Esterel, включая эти самые автоматы SSM, которые отличаются от теоретических, путем обрезания теоретических возможностей.
petuhoff
Да автоматы в SimInTech, конечно не те автоматы про которые говорит теория. Если посмотреть на Simulink, то там автоматы даже собиаются в другом интерфейсе. Схема автомата Simulink это не схема диагаммы simulink. DataFlow (стандарнатя диаграмм симулинк) и StateFlow (колнечные автоматы), это разные модели:
В SimInTech конечные автоматы это просто дополнительные блоки, для стандартной диагаммы DataFlow, и пользователь может внути состояния использовать динамический блок, например интегатор. С одной стороны это расширяет возможности и повышает гибкость системы. В конечный автомат можно запихнуть какую либо логику вычислений. С другой стороны это может вызывать коллизии. Например нужно помнить, что будет на выходах обычной логике которая помещена в состояние, при его отключении. Напрример если в состоянии есть интегратор, то его накопленное заначение сохранится при выходе из состояния, это может быть как правильно так и нет. Во этом случае нужно предусотреть сброс этого интегратора. Его можно сделать как при выходе из состояния, так и при входе в него. Оба варианта правильные и неправильные в зависимости от задачи.
Использование конечных автоматов в стандартной схеме SimInTech, позволяет получить сгенерированный код Си для контролееров из диагравммы состояний без переделки кодогенератора, раз блоки стандартные то и код получается такой же.
Но кстати ту проблему решал и Esterel, когда они создавали свой генератор кода повышенной надежности для авиации и железных дорог. Вот что они пишут в руководстве:
As a topic of very extensive studies over the last fifty years, state machines and their theory are well-known and accepted. However, in practice, they have not been adequate even for medium- size applications, since their size and complexity tend to explode very rapidly. For this reason, a richer concept of hierarchical state machines was introduced. Scade hierarchical state machines are called SCADE State Machines (SSMs).
Дословно, теория очень хорошая, но хреново применимая к реальным системам.