Comments 81
Да автоматы в 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).
Дословно, теория очень хорошая, но хреново применимая к реальным системам.
И несмотря на то, что используемые в 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 виноват такие это жизнь такая :))))
...это жизнь такая
Звучит, прямо скажем, ... грусновато. Жизнь сейчас, действительно, не очень простая, атмосфера, скажем так, - не очень, да и настроение, порой, не всегда радостное, но ... рыба-то в Каме, надеюсь, еще есть! :)
Автоматы сейчас употребляются где не попадя, но ... часто. К месту и не. Esterel к автоматам имеет такое же отношение как DataFlow или StateFlow. Поэтому нужно уметь отделять котлеты от мух. Иначе будет полный фарш ;) При этом, конечно, не надо его выбрасывать насильно. Пусть будет. Кому-то он нравится и даже, видимо, приносит пользу. Ну, ... жизнь такая. Она разнообразна. Но жрем "чо не попадя" тоже часто...
Если чуть серьезнее, то выше я показал, как в SimInTech можно автоматы "наживить". Далеко не идеал, но все же не ... "фарш". Уже можно потреблять, не боясь отравится. Вот, как-то так. Если честно, то меня даже "отпустило" после последнего (надеюсь, крайнего :)) проекта. Все не так уж безнадежно. А то уж была совсем печалька...
Даже вспомнилось бодрое - "мы рождены, чтоб сказку сделать былью..." Вот, честно, раньше жизнь была и веселее, и бодрее, и перспективы были реальные... Но, наверное, это уже ... возрастное :(
Да,
Резюме Конечные автоматы в SimInTech не совсем те, о которых говорит теория ...
Они совсем не те. Это я говорю ответственно. Или, скажем мягче, я не вижу связи между ними и теорией. От слова совсем. Есть слова "конечный", "автомат", которые используются и там и там. И не более того. Может все это звучит резко, но ... есть колеты и есть мухи и они, как известно, не совместимы друг с другом. Точно также и здесь... :(
Согласен с потенцеальной возможностью "оживить" автоматы. Но реальная жизнь требуе совсем другого. Вот ребята в Esterl делают код для критических систем, важных для безопасности, причем код создают в графическиз диаграммах, а грузят его в контроллеры в виде кода си. И генератор кода, который из схемы выдает Си в железный контроллер у них сертифицированный по авиационным и транспортным стандартам.
И вот приходят к ними теоретики с 50 летней историей развития математической теории конечных автоматов и показывают, эти схемы. "Типа я так могу, я и так могу, я и так могу и чере этак..." смотрят на эти диаграммы инженегры Естерель и спрашивают, а как же я все это проверять буду и сертефицировать? Если в простом блоке упрааления идикатором 18 условий if? А если у меня система с тремя - пятью уровнями вложенности?
Нет, говорят инженеры, всю эту теоретическую красоту я в читаемую схему и сертифицированный кодогенератор запихнуть не смогу. Давайте мы из теории конечных автоматов, оставим состояния и простые переходы, мы их в коде операторами case заменим, и будет всем счастье при проверке и сертификсции. А все эти ваши изыски с возвратами, переходами через границы макросостояний состояний, и множествами if- ов в конечном коде нафиг. "А ты кто такой? Давай досвиданья!"
Ну а в SimInTech, прсмотрели на теорию конечных автоматов. Почесали затылок. Есть у нас блок условного выполнения субмодели? Есть. Что он делает? Он морозит диаграмму в субмодели. Так вот оно самое, конечные автоматы это когда одна субмодель выполняется - активное состояние, а другие - нет. Еврика, берем стандартные субмодели называем их состояниями, а переходы это те же линии связи, но соединяются с блоками условного выполнения, цвет поменяем что бы не путали и будет у пользователя счастье - конечные автоматы. Алах акабар!
Ну если кто-то хочет, свои правильные высоконаучные, кошерные автоматы - you are welcome - среда открыта. Mожно свою библиотеку блоков написать, даже на Си. И продавать всем страждущим.
С инженерами из Esterel мы еще пообщается и разберемся с их заблуждениями... Я пока хочу задать вопрос инженерам из Бауманки.
Я создал проект "Нагреватель" в SimInTech. Ну, люблю я ее. Очень! :) А она, ведь, насколько мне известно сертифицирована. Так? Но я ни кому не говорю, что в процессе проектирования использовал некие "мудреные автоматы". Так? Я также надеюсь, что при этом ни кто меня не заложит, что я такой "умный". Могу ли я на это рассчитывать? Но даже, если кто-то заложит, то я отрекусь и ни кто не докажет, что я использовал при проектировании некую автоматную модель (а графы просто сожру).
У меня вопрос. Ну, очень важный. Мой проект пройдет сертификацию?
Надо смотреть какие блоки и функции вы использовали при создании проекта. Библиотека постоянно расширяется, в приложении к сертификату есть набор блоков, и набор функций языка програмирования, которые проверялись сертифицирующими органами. Если блоки и функции из списка сертифицированных, то в процессе сертификии вашего ПО, созданного в SimInTech вы можете пропустить часть тестов (не все) оборудования управления для АЭС.
Например сертифткат гарантирует, что блок сравнения сгенерирует код Си, который обеспечит правильный результат сравнения значения давления в системе с уставкой (заданым значением в проекте). Но этот сертификат не гарантирует, что пользователь при создании проекта указал правильное згачение заданного давления. Может и ипанет если ошибся разработчик. Сертификат гарантирует только то, что дополнительных ошибок не будет.
Другая ситуация. Я чиновник, которой сертифицировал SimInTech. Я ставлю свою подпись, я рискую своей репутацией. Рабочим местом, в конце концов! И вот случайно мне попадается или мне приносят статью в которой приводится пример на SimInTech, содержащий явную ошибку, но выявленную сторонним программным средством. Проверка убеждает, что последнее не ошибается.
Что мне делать? Отзывать лицензию? Или "прикинуться ветошью и не отсвечивать"? Но, ведь, и то и другое - чревато последствиями. А там - подмоченная репутация, дети голодные, жена вся в бриллиантах (пока еще) ... Что Вы мне посоветовали бы? Стреляться не буду! Да, сидеть тоже не хочу (предупреждаю - сдам всех!)
Пока я не вижу никакой ошибки которая могла влиять на сертификацию здесь.
А если заказчик находит ошибку и рассхождение при генерации кода, то есть процедура определения риска, и процедура устранения ошибки, с документирован ем процесса тестирования.
Это нормальная ситуация дле сретифицированных продуктов. При выпуске новых версий указываются изменения и устранение выявленных ошибок.
И тут приходят ... инженеры из Esterel.
О, да, мсье Петухов, мы Вас очень понимать - говорят они. У вас в Россия есть сертификация, но она не действует у нас - во Франция! Мы есть проверять проект, который сделал Вы нам - Нагреватель. Ок! Очень корошо! Но у нас есть один въедливый инженер, который заметил один дефект. Вот он.
И они демонстрируют график:
График температуры исходного проекта
Это момент выхода на режим. О, да! Мы пытались улучшить - изменили настройки проекта - уменьшили шаг, изменили метод интегрирования, но только добились следующего:
Показывают другой график:
График температуры с новыми настройками
Здесь шаг на два порядка меньше - 0.00001, мы взяли метод интегрирования - Эйлера. Мы, есть, ждать аж 16 мин! Но... мало что изменилось - дефект не ушел.
Что есть у Вас сказать, мсье Петухов? Ведь мы не пройдем сертификацию во Франция! Ок?
...
И теперь уже серьезно говорю я...
Что нужно сделать, чтобы график соответствовал требованиям, предъявляемым к подобной весьма простой системе управления! При этом - есть такой промах - в ТЗ об этом - точности регулирования не сказано ни слова. Но говорить так - потерять заказчика! Ведь, все довольно очевидно. Где, как говорится, собака порылась?
А в чем здесь дефект? Нормальный выход на режим, что хотите получить нагревателе?
Смотрим на график второй - с более точными настройками. 475 сек- дошли до уставки и пошли остывать. Дошли до темр. 19.84 - пошли нагревать. Далее - дошли до 19.96 - пошли остывать. Но почему не дошли до 20.0? Время нагрева истекло? А тогда почему дальше - от такой же температуры доходим до 20.0 за это же время...После 550-сек пила-то другая - стабильная - 20.0-19.84, 20.0-19.84, 20.0-19.84...
Может, я что-то не учитываю? Но ВКПа дает "стабильную пилу" после достижения уставки. В ней ошибка? В чем? Подскажите - я учту это. Почему для Вас - это норма, а у меня - нет. Хотелось бы понять...
Да действительно дефект, время таймера не сбрасывается при выходе из состояния, и при следующем входе в состояение таймер включается не 20 секунд, а с уже накопленного времени! Через несколько циклов работы в режиме включения, таймер доходит до 20 секунд и вырубает нагреватель, хотя температура все еще ниже уставки! Курто! Я выше писал, что смесь конечных автоматов и dataflow, удобна, но черевата коллизиями, и конкретно приводил пример интегратора. А ведь таймер задержки это тот же самый интегратор!
Логика собранная из стандартных блоков работает так как должна, но не так как хотел разработчик ;))))
- А если ипанет?
- Не должно!
- Ипануло!
Самое интересное, что такая логика работы тоже имеет право на существование, например если, в требованиях стоит остановка процесса после заданного общего времени нахождения в рабочем состоянии.
Но, конечно не в нашем случае, у нас время должно сбрасываться согласно ТЗ. Это явная ошибка разработчика логики работы. На сертификат ПО разработчика это не повлияет, а вот на разработчику логики нагревателя нужно выписать большую звездюлину!
Именно поэтому теория конечных автоматов и порезана в Esterel , что бы меньше было таких коллизий.
А ведь таймер задержки это тот же самый интегратор!
Ну, я бы не стал так обобщать. А то появятся задержки Эйлера, Адаптивная1, 2... Хотя задержка Мерсона или там Гира звучало бы круто ;)
Именно поэтому теория конечных автоматов и порезана в Esterel , что бы меньше было таких коллизий.
Автоматы совсем тут ни при чем. Если что-то и надо резать, то только тем, кто покушается на автоматы.
Я так и не понял, что Вы сделали (но, если честно, то и не пытался :) Но надеюсь, что все теперь будет работать. Но я понял одно - у Вас задержка приостанавливала свою работу. Сделать-то это не проблема, но ... зачем? У меня в статье тоже была проблема с задержками (см. статью и рис. 3). Но, во-первых, она не останавливалась и не создавала проблем, но я все же ее обрубил и ввел режим сброса. Т.е. попросту расширил ее режимы. Мог бы, кстати, ввести и режим приостановки отсчета задержки. И, кстати, возможно, он бы и потребовался.
ошибка в том, что разработчик не читал хелп по блоку. А там описана логика работы данных блоков. Они предназначены для задания минимального времени нахождения в состоянии. Вошли в состояние, выдежали заданное время, - выходим из состояния. Тогда все работает отлично. А в модели данный блок используется для задания максимального времени работы, а не минимального. И получается что вошли в состояние, запустили блок и пошел обратный отсчет времени, до выхода. Но вышли-то мы из состояния по другому условию раньше минимального времени. При этом блок задержки уже насчитал какое-то время, и запомнил это время при заморозке состояния. (скорее всего там в коде стоит блок обычный интегатор). И при следующем входе в состояние мы обратный осчет ведем уже не 20 секунд задержки, как планировал разработчик, а с того времени которое запомнили при предыдушем выходе из состояния. И с каждым включение время задержки уменьшается, пока она не выключит нагреватель, до достижения заданной температуры. Пила не достигла заданного значения. После этого она сбросится и снова будет 20 секунд. И вот вам результат на графике. Кстати видно что в дальнешем эта ситуация снова повторится.
ошибка в том, что разработчик не читал хелп по блоку...
Навскидку. Основная ошибка в том, как вы работаете с состояниями. Для меня - это полный абзац! Вы входите в состояние, копошитесь там и т.д. и т.п. Состояние - неделимая единица. Это всего лишь элемент множества. И даже если оно само представлено, как множество - это только иерархия и не более того. Все, о чем Вы пишете - это нарушение концепции автомата. Из этого надо исходить.
Здесь опять нужно отделять котлеты от мух. Хотя, может, лучше апельсины от яиц :) Есть автомат - как модель управления и есть предикаты и действия, как дополнение к автомату. Вместе они - полноценная алгоритмическая модель. Без них автомат - ничто. И тогда легко уже понять что, где и как работает и кто за что отвечает. Разделяй, как говорится, и властвуй. Как-то так... ;)
ну это теория, а на практике я вот читаю ТЗ, переключение режимов работы системы связи самолета. А там список режимов и условия перехода из режима в режим. Для меня кажется очевидным и логичным, взять логику работы в различных режимах и пометсить ее в субмодель автоматов состояния, и тогда переключая автоматы состояний я буду получаю в каждый момент непрерывно работающие алгоритмы соотвествующие режиму выбранному автоматами. Красиво и наглядно. Смотрим на схему видим каое состояние активно входим в него, видим работающий алгоритм, переключилос сотстояние - работает другой алгоритм в дрругом активном состоянии.
Ну, я тоже читаю ТЗ, когда оно/они есть, конечно. Но наша практика такова, что часто тебе дают такое ТЗ, которое таковым можно считать лишь условно.. :) Поскольку хорошее ТЗ - это отдельная "теория" и, конечно, практика.
Для меня красивым можно считать решение, состоящее из множества параллельно работающих автоматов - сеть автоматов. Во-первых, в этом случае автоматы будут меньше (а, значит, проще), во-вторых, система будет гибче, в-третьих, их можно проектировать/отлаживать достаточно независимо и т.д. и т.д.
Для Вашего примера можно было бы сделать так (по крайней мере я бы делал так). Создать автомат режимов и в нем сконцентрировать логику управления режимами. Да, было бы удобно каждому режиму назначить свое состояние. Т.е. мы имели бы процесс, по состоянию которого можно было бы судить о текущем режиме работы.
Далее. Можно было бы для каждого режима создать свой процесс (автоматный, конечно). Каждый из них реагировал бы на соответствующее состояние процесса режима. Т.е. мы имели бы сеть из автоматов: автомат режима и автоматы для каждого режима.
Такая сеть, как мне кажется быстрее реагировала бы на смену режима, т.к. автомат выбора режима работает параллельно с автоматом реализации самого режима. Была бы только две проблемы - среагировать быстро на смену режима и завершить корректно текущий режим, чтобы перейти к новому режиму. Но все это уже дело техники. И, самое главное, все в рамках теории, работающей на практике. Любой практике :)
Из своей же практики я сделал вывод, что за критикой той или иной теории, как правило, скрывается непонимание \этой теории. Поэтому, например, я не критикую теорию инженеров Esterel, я даже не вправе критиковать Ваши подходы к проектированию Это Ваше право и право инженеров Esterel проектировать так, как нравится. Я критикую или даже возмущаюсь только в том случае, когда идет не справедливый наезд на автоматы, на их теорию, на ее ограниченность в смысле практики и т.д. Это все, мягко говоря, идет от не понимания теории и возможностей автоматов. Других причин я не вижу, т.к. в своей практике применения автоматов я ограничений не испытываю - только преимущества.
Кстати еще раз убедился как же это круто, когда логика в графическом виде и можно анализировать наглядную схему. И при этом гонять режимы работы. Если бы та же логика была бы в виде кода фиг бы я нашел ошибку так быстро, если вобще бы нашел. Визуальное программирование рулит!
Визуальное программирование рулит!
Я бы сказал Визуальное Компонентное Программирование автоматное рулит! :).
Но я бы не стал так уж графику "фетишизировать". Нужно чтобы одно дополняло другое. У кода несравненно больше возможностей. Особенно на С++. Но, например, полноценной визуализации ВКПа, конечно, не достает :( Хотя ее "компонентность" и "автоматность" во многом помогают не меньше, чем полноценные графические структурные схемы. Хотя, еще раз, графические возможности - это моя несбыточная мечта :) .До этого была мечта - автоматы. Вот ее я успел реализовал, как задумал много-много лет тому назад :) И пока я ошибки легко и просто нахожу именно в коде. А если бы еще графика была!...
А представте вы код отдаете кому то другому? Сможет он находить так же легко ошибки? А в SimInTech я просто на линиях связи поставил графики и посмотрел, что происходит на схеме в каждый момент времени. И это можно сделать вообще не зная кода.
Код коду рознь. В ВКПа - сможет. Я также могу обвесить блок/блоки графиками (в статьях это демонстрируется). Кроме того, я вижу состояние, я контролирую переходы, т.е. вся логика работы блока и его взаимодействие с другими блоками на виду. Я локализую ошибку до предиката или действия. А эти функции чаще всего небольшие и уже их понять - не проблема.
Просто автоматы у меня не покоцанные, как у некоторых инженеров из Esterel, а полноценные, нормальные - усовершенствованные до сетей, но при этом классические :)
А эти функции чаще всего небольшие и уже их понять - не проблема.
Вот про это инженеры 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.
Как только функции перстают быть небольшими, а становятся даже средними - все сливайте воду тушите свет. Черт ногу сломит, в ваших теоритических автоматах. Нужно резать!
Ну, во-первых, инженеры пишут про другое. Они пишут, что отсутствие иерархии порождает большие автоматы. Они сетуют за введение ее. И это правильно. Молодцы инженеры. Но только какую иерархию они вводят? Уточните, прежде чем мы их начнем пинать в ... самые больные места (а, может, наоборот - будем благодарить :)).
Еще раз. О какой иерархии говорят инженеры Esterel? Виды иерархии могут быть разные. О каких конкретно идет речь? Зная это, уже можно, например, сравнить и с моделью ВКПа. В этой модели, ведь, тоже есть иерархия автоматов. Пока одно только бла-бла-бла...
Не они не говорят, что вводят иерархию которой нет, они говорят что у них свои автоматы, более богаты чем другие иерархические автоматы.
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 можно поскольку состояние это таже субмодель, только морозится при выходе и запускается при входе в состояние.
...более богаты чем другие иерархические автоматы
Без указания какие - это беспредметный разговор, т.е. ни о чем. Например, есть книга А.Н.Мелихова, где приводится алгебра автоматов и в ее рамках - операции с ними, порождающие новые автоматы. Это конкретно. Это понятно о чем идет речь. "... более богаты" - это ни о чем. Чем "более", по сравнению с чем "более", насколько они "богаче" - в долларах, рублях, попугаях и т.д. Нет информации. От слова совсем.
Можно ли у них внутри состояния автомата соорудить пид регулятор, непонятно. В Simintech можно ...
Если можно, то сразу понятно, что это скорее плохо, чем хорошо. В моих базовых статьях по теории автоматной модели программ - это подробно расписано. Нельзя во внутрь невпихуемого что-то впихнуть. Ваше право соорудить что угодно, но давайте не будем это что-то называть "конечный автомат". Или Вы должны обосновать это. Делается это описанием приведения Вашей модели к модели классического автомата. Только так.
В конечном автомате нельзя что-то создать кроме того, что может состоять из его элементов. Интегратор, регулятор содержат память. Подобной памяти у автомата нет. Есть только состояния, которые обычно называют памятью. Но это другой вид памяти - память об предыстории его работы. .
Упомянутые объекты выполняют какие-то операции. Ни каких операций у автоматов нет. Но есть сигналы, которые могут запускать операции... Но все это известно, все это описано. В теории проектирования дискретных устройств (Майоров, Новиков, Баранов, Глушков...). Давно. Очень давно. И даже у меня ;) Почему все это игнорируется - не понятно. Мне не понятно... Открывай, читай и все поймешь. Но как-то Esterel больше заходит. Может, потому, что "нет пророков в своем отечестве"?
Конечный автомат - очень бедная по своим возможностям модель. Конечно, с точки зрения понятия алгоритма. Но она прекрасная модель управления для него же. А просто что-то хаять, просто заниматься "распальцовкой" - это позиция "для бедных". Нужна конкретика. Лучше на уровне теории. Иначе, еще раз, это будет всегда бла-бла-бла.
Ну нельзя по теории "внутри" состояния что-то соорудить. Тем более пид-регулятор. Можно создать его вариант с автоматным управление, может быть интегратор с автоматным управление, может быть что угодно с автоматным управлением, но ни что из упомянутого нельзя считать конечным автоматов. Где словам "конечный автомат" соответствует строго математическое определение. Сможете в его рамках описать хотя бы интегратор - другое дело. А так ...
Ну нельзя по теории "внутри" состояния что-то соорудить. Тем более пид-регулятор.
Ну вот, если практика противоречит теорию, тем хуже для практики! Или теория маркса ленина вечна, потому что она верна! Смешно.
На самом деле мы в SimInTech исходили как раз из практики, и наглядности формиования программ для АСУ ТП, в виде графических диагамм алгоритмов. Смотрели на Matlab, но сделали под другому.
Кстати вот картинка Esterel. У дураков - практиков мысли сходятся, не читают теоретиков марксизьма ленинизьма и математиков. Делают как удобно инженерам. Если перешол в состояние, то прямо в нем можно изобразить алгоритм управления. Перрешел в другое сотрясение - другой алгоритм. И прямо на диаграмме это видно, как в SimInTech. На картинке постые прямоугольник это DataFlow, где ПИД и все передача сигналов по линии связи, а прямоугольники с круглыми каями и заголовком это конечные автомты их состояния
Да. Вот ссылка на язык Esterel - ://studfile.net/preview/16383020/page:4/ Это про то, что мы обсуждаем?
Вот здесь есть болле подробное описание: https://ptolemy.berkeley.edu/projects/chess/design/2012/lectures/EE249_9_lecture-esterel.pdf
Господа инженеры из 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).
Будьте так добры, дайте свое заключение на представленное решение...
Нет не правильно. Сигнал нужно ассмативать как булевую переменнюу. Поэтому 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
Спасибо за ответ инженерам Бауманки. Они более ответственны в этом плане, чем инженеры 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 не понимают или совсем не знают элементарных логических операций. И уж сложно предположить, что они знают и понимают смысл двух видов формальных моделей реальных устройств - функциональной и последовательностной (на фиг им эта теория!). Но, может, во Франции такая теория проектирования дискретных устройств? А, скорее всего ,ее полное отсутствие?
Безусловно, Бурбаки внесли весьма значимый вклад в теорию математики, но было бы интересно знать кто во Франции отвечал за развитие дискретной математики (теории множеств, булевой алгебры и т.п.)?
Я конечно не истина в последней инстанции, могу
ошибаться или что-то не до конца понимать, но на мой взгляд без "абсента",
похоже, с подобной "спецификацией алгоритма" сложно будет разобраться.
Больно много "мелочей"...
По паузам там выше в тексте описана работа системы. Поскольку система предназначена для работы в реальных системах управления, а не в теоретических построениях, то время там разбивается на такты:
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.
И еще. Планировал написать, откуда проистекает такое мое отношение к технологиям вообще и к ТЗ в частности. Когда-то, уже давно, прочитал книгу Захаров В.Н., Поспелов Д.А., Хазацкий В.Е. Системы управления: Задание, Проектирование, Реализация. Великолепная книжка о том, как взаимодействовать с заказчиком, создавать ТЗ и проектировать. И это 1977 г. До сих пор считаю - актуальна.
Сегодня попытался найти ее в Инете (у меня есть бумажный экземпляр). Нашел. Вот ссылка: https://www.studmed.ru/zaharov-vn-sistemy-upravleniya-zadanie-proektirovanie-realizaciya_e794a6616e3.html. Кому интересна эта тема, а она должна быть интересна любому нормальному инженеру, можно скачать. Можно, конечно, обсуждать ее содержание, т.к. все же это конец 70-х годов, но замысел и посыл ее актуален и вечен, как и "марксизьм, ленинизьм" :)
И еще один факт в цепочке, которая привела меня к конечным автоматам. У нас в отделе был фото-координатограф (сейчас таких уже не делают:). Он был спроектирован, видимо, ровно по книжке Майорова, Новикова, которую я только что, будучи молоденьким инженером, проштудировал. Впечатление - "колоссаль" я вам скажу! Особенно на фоне векторного дисплея от серии ЕС ЭВМ, который мне нужно было подключить к СМ ЭВМ. На его стойке (примерно с большой холодильник) стоял даже знак качества! Но разрабатывали ее, видимо, инженеры-практики ;) Качества не было от слова совсем. Разобраться в этом хитросплетении проводов было просто невозможно, надежность - жуткая. Работал только от пинка ногой сзади по корзине с платами (а там был витой монтаж). Но свою задачу - подключить я, кстати, сделал. Но два таких разных подхода инженерного проектирования наглядно показали, как надо проектировать "по науке"(см. книгу;), а не от некой "практики". Первый в случае отказа ремонтировался по щелчку отставным военным (авиационный инженер), а второй - пинком сзади :)
Ну сравнение инженеров Esterl c монтажниками плат СССР в конце отчетного квартала, или после празднования великой октябрьской социалистической революции, мягко говоря не совсем справедливо.
Esterl это мировой признанный лидер в создании ПО для разработки критических систем в Авиации, жд транспорте. Все Боинги и Аирбасы летают без всяких пинков, и управляются ПО разработанным в системах Esterel, включая эти самые автоматы SSM, которые отличаются от теоретических, путем обрезания теоретических возможностей.
Прочел несколько ваших статей, но так и не понял цели их написания...
1. Вы хотите помочь программистам писать более эффективные параллельные программы?
2. Вы хотите обратить внимание аппаратчиков на конечные автоматы?
3. Вы хотите прорекламировать собственный пакет для аудитории Хабра?
Если последнее, то вопросов больше нет, цель вполне достойная. Если же первое, то не слишком понятно, как это поможет. Ведь жизнь не исчерпывается моделями нагревателя и функцией И-НЕ.
Я могу понять, в чем помогают индустрии парни из (бывшего) Esterel Technologies. Они дают возможность генерировать верифицированный код на базе формальных моделей исполнения. Удобны ли эти модели - другой вопрос. Так или иначе, за ними стоит достаточно проработанная научная база. Однако, хотите ли вы идти по этому пути - мне не ясно.
P.S. С модератором, кстати, тоже согласен.
Прочел несколько ваших статей, но так и не понял цели их написания...
1. Вы хотите помочь программистам писать более эффективные параллельные программы?
2. Вы хотите обратить внимание аппаратчиков на конечные автоматы?
3. Вы хотите прорекламировать собственный пакет для аудитории Хабра?
Я по мере своих возможностей стараюсь, чтобы Вы и остальные поняли, что - это ни 1-е, ни 2-е и ни третье ;) Я пытаюсь донести, показать, доказать, что программировать параллельно можно намного эффективнее. Я бы даже сказал - несравненно эффективнее. И это совсем другое - чем эффективные программы. Настолько другое, что даже можно сказать - качественно другое.
Я могу понять, в чем помогают индустрии парни из (бывшего) Esterel Technologies. Они дают возможность генерировать верифицированный код на базе формальных моделей исполнения. Удобны ли эти модели - другой вопрос. Так или иначе, за ними стоит достаточно проработанная научная база.
Я бы согласился, если бы кто-то эту "научную базу" представил. В той информации, которую я вижу, особой научной базы нет. Если они ссылаются на конечные автоматы - а это чаще всего и происходит - то от конечных автоматов там только название. Если они "проработали" что-то иное, то - что? Удобства - нет, теории - нет, технологии - нет. Есть "красивые слова" - Франция, Esterel, верифицированный код...? Чтобы решить простую задачу - можно "дуба дать" :) "Верификация". Блин, да Вы представляете, что нужно знать и сколько усилий потратить, чтобы строго верифицировать даже простейший алгоритм?! Это ж каждый программист должен быть, как минимум, кандидатом наук... Когда ему писать программы? А если проблемка чуть сложнее, то о какой-либо верификации вообще речи идти не может. Тут должен быть задействован целый научный коллектив. Вы это объясните нашим нынешним "торгашам от науки", эффективным менеджерам и разным там "хозяевам"... Они ж за копейку в своем большинстве удавятся. Даже, что часто случается, во вред себе ;)
P.S. С модератором, кстати, тоже согласен.
А я категорически нет! :) Только я объяснил почему, а Вы - нет ;) Я полагаю, что в подобных случаях, как минимум, надо предупреждать, как максимум - объяснять. И уж совсем несбыточное - выслушать и, если остались непонятки, прийти все же к согласию. Хотя, если честно, - это все же... Если же кратко, то все много проще - нужно больше доверять авторам что ли...
Ок. Начнем с первого пункта. Вы хотите донести факт "что программировать параллельно можно намного эффективнее". Наверное можно. Но, во-первых, эффективнее чем что? Во-вторых, как уже неоднократно замечали ваши оппоненты, data-driven подход дает достаточно эффективные методы для параллельного программирования. Если же вы, положим, претендуете на то, что ваш (условно "автоматный") подход еще лучше, то надобно привести какие-то примеры решения пусть простых модельных задач, но интересных широкому кругу программистов. Например, реализацию параллельного перемножения матриц, сортировки слиянием, задачи N-тел... Можно реализовать и какую-нибудь интересную структуру данных, concurrent hash map или что-то подобное. А не регулятор нагревателя.
По второму пункту - понятно, что "представлять" базу специально вам вряд ли кто-то будет. Парни из Esterel Technologies вероятно даже не в курсе, что кто-то их научной базой недоволен. Но при желании найти их теоретические наработки не сложно. Можно начать с работы Gérard Berry по конструктивной семантике языка Esterel. Там как раз есть и про преобразование в электрические схемы и про операционную семантику Плоткина.
https://www-sop.inria.fr/members/Gerard.Berry/Papers/EsterelConstructiveBook.pdf
И список литературы для дальнейшего изучения есть.
Но, во-первых, эффективнее чем что? Во-вторых, как уже неоднократно замечали ваши оппоненты, data-driven подход дает достаточно эффективные методы для параллельного программирования.
Чем то, что есть. Но главное даже не в эффективности (тут я немного пошел у Вас на поводу). Главное и самое существенное - в следовании верной модели параллельных вычислений. Мои оппоненты постоянно скатываются на вопрос "эффективности". Но все это вторично, т.к. проблема эффективности в любом ее виде/качестве решается техническими средствами. А вот проблема корректности, верности - только моделью вычислений. Этого фактически неет ни в одних параллельных вычислениях. Проверяется это и доказывается достаточно просто на "бытовом уровне" - реализацией тестовых параллельных задач, которые представляют модели реальных систем. Все остальное - от лукавого...
И как продолжение выше сказанного - моя Вам благодарность за ссылку. Материал очень интересный именно в смысле используемых примеров. В первую очередь в отношении цифровых схем. Это они молодцы, что выбрали их для примера. Просто они как раз убеждают хоть в чем-то. Среди приведенных схем я выделяю схему c13 (рис. 4.3, стр. 50). Остальные даже критиковать не хочется :)
Рассмотрим ее. В определенной ситуации, как убеждает мой анализ, она может войти в режим генерации. Это может выглядеть так:
В описании об этом ни слова. Могу, конечно, ошибаться и я, но не ошибается теория :) Но если серьезно. Может ли теория программ Esterel продемонстрированный результат подтвердить или опровергнуть? Теория автоматов - может. Я это могу продемонстрировать. Но сначала хотелось бы получить ответ от теории Esterel.
Это тем более интересно и даже важно, что, как дальше говорится, программы на Esterel с целью анализа переводятся в цифровые схемы (стр. 52). Там же говорится и о проблемах "циклических схем". Но здесь же на мой взгляд допущена и грубейшая ошибка - их утверждение о переводе циклических схем в эквивалентную ациклическую форму. Если я верно толкую все превратности перевода, то "наша" теория - теория конечных автоматов - подобного не допускает. Вот пока навскидку как-то так...
Не очень понятно, что делает ту или иную модель параллельных вычислений "верной". Это нужно как-то обосновать. Плюс, практически за каждой используемой сейчас моделью стоит своя теория, будь то CSP, функциональное программирование, модель акторов. Нужно просто их изучить, и вуаля.
Если же вернуться к эффективности, то я прекрасно понимаю ваших оппонентов. Хабр - по большей части сайт практиков от программирования. Даже будь какая-то модель супер-хорошей в теории, без примеров эффективной реализации она мертва.
Вот, к примеру, функциональный подход (в теории) предлагает прекрасное решение для параллельного программирования. Практически бесконечное масштабирование без какого либо напряга для программиста + доказуемая корректность. Однако с практическими реализациями пока не очень. Как результат - невысокая популярность этой парадигмы.
Не очень понятно, что делает ту или иную модель параллельных вычислений "верной".
Вот! Прежде чем что-то предлагать, обсуждать и даже критиковать нужно разобраться с этим, не побоюсь сказать, базовым вопросом параллельного программирования. Давайте с ним и разберемся и тогда уж можно и дальше...
Начнем с того, что есть мир реальный и мир абстрактный. И тот и другой живут по определенным законам. Должны ли эти законы быть одинаковыми? Насчет одинаковыми - не могу утверждать, но то, что аналогичными - можно утверждать. Не будет рассматривать все законы, а ограничимся законами параллельной работы. Реальный мир уже давно-давно организован по параллельному принципу. Это очевидно. Соответственно в нем действуют определенный законы, которым следуют реальные объекты, работающие/живущие параллельно друг другу. Мы эти законы можем вполне не знать, но наблюдать, ощущать - это пожалуйста. И ... сравнивать работу реальных объектов и абстрактных. Ну, то есть в нашем случае программ. Но перейдем к делу...
Возьмем пример простой - RS-триггер (поднадоел, но ... а что делать - проще и нагляднее не знаю). Есть реальная его реализация - на логических микросхемах И-НЕ. И вот он как-то работает. Мы это можем видеть, изучать фиксировать. Два параллельно работающих процесса, связанных между собой и потому обменивающихся постоянно информацией. Ну чем не параллельная программа? Ну, только в железе. А, может, внутри этих элементов даже микропроцессоры и программки? :) Т.е. во внутрь мы заглянуть пока не можем. Но исследовать можем и даже предполагать как они устроены. На неком абстрактном уровне...
Переходим к нему - абстрактному. По-нашему - модели программ. Берем какую-нибудь (да, любую) из названных Вами моделей и строим модель отдельного элемента И-НЕ. Yes! - построили. Создаем ее копию. Yes! - создали. Соединяем эти модели по схеме триггера. Yes! - соединили. И теперь - внимание! - смотрим как модель работает. Да, я забыл сказать про программную реализацию моделей, кjтороe мы тоже - Yes! - создали :)
Если созданная в такой последовательности программная реализация абстрактной модели работает точно также, как и реальный триггер, то это создает уверенность (до появления следующего параллельного объекта) и дает право называть нашу модель верной. Именно в смысле параллельности, т.к. и малюсенький триггерочек и большой банкомат, состоящий из множества электронных компонент работаю в смысле параллельности абсолютно одинаково...
Вот так на примере триггера мы протестировали свою идею/модель, которую с определенной долей уверенности (довольно большой, кстати) мы можем считать верной параллельной вычислительной моделью и использовать ее для реализации уже более сложных процессов. Вот такого доказательство "верности" на, так сказать, "пальцах". Если нужно формальное обоснование - изучаем, например, как в данном случае, теорию автоматов. В случае Esterel - и теорию, функциональный подход и т.д. и т.п. Т.е. идем от простого к сложному. Просто так "лопать" теории - гиблое дело. Точнее - очень тяжелое.И, к сожалению, как показывает опыт - мало благодарное... Но это уже другая тема :)
Пока вот так: берем формальную модель и строим на ее основе модель известного реального объекта, обладающего определенными свойствами. Затем ее программно реализуем. Если результаты работы реального объекта и программной реализации совпадают, то это во многом и есть критерий той "верности", в которой Вы еще сомневаетесь. Только так! :).
Да, а что Вы скажете про реализацию схемы С13 на Esterel, о которой я писал ранее?
Такой подход к "верности" возможно был бы интересен аппаратчикам, или, узкому кругу АСУ-шников, но для программистов он не слишком актуален.
Для них скорее подойдёт другой: параллельные вычисления должны гарантировать тот же результат, что дают последовательные. Скажем, у нас есть строго последовательный алгоритм сортировки массива, и он корректно работает. Мы переписали его в той или иной модели параллелизма. Далее, идеально было бы уметь доказать, что результат не изменился. Аналогично и для других алгоритмов.
P.S. Что касается схемы C13 я не вижу там проблем, но я далек от схемотехники, да и доступа к продуктам Esterel у меня нет.
...он не слишком актуален
Дело в смысле проблеме. Это основное. И отражает ли задача те качества которые мы изучаем. Здесь два - параллелизм и наличие обратных связей. Какая при этом задача рассматривается - вторично. Пусть программисты предложат столь же простую, но актуальную для них задачу, которая имеет такие же свойства.
Про сортировки... Предполагая, что Вы об этом спросите, я написал достаточно давно статью на эту тему. Вот пример ее критики. В статье пропали, похоже таблицы, но, надеюсь, общий смысл понятен. Может, я даже ее немного доработаю и повторю здесь на Хабре, но уже с таблицами.
P.S. Что касается схемы C13 я не вижу там проблем, но я далек от схемотехники, да и доступа к продуктам Esterel у меня нет.
Здесь не обязательно знать схемотехнику и даже Esterel. Нужно описать поведение данной системы, как некого множества параллельных процессов, реализующих элементарные логические операции (что может быть проще для любого и даже не очень крутого программиста?). Ну и конечно, дает ли теория/практика Esterel ответ на этот вопрос?
Теория автоматов - дает. Я привел лишь отдельное поведение процессов в определенной ситуации. И его, кстати, подсказала теория автоматов, а практика - лишь подтвердила правильность теоретических выводов. Способен ли на такое Esterel? Или он делает другие выводы о ее поведении, опровергая выводы автоматов? Если Esterel не может ответить на подобные вопросы - грош цена такой теории и собственно вычислительной модели им реализуемой...
А зачем мне в программе тригер который работает так же как "железный"? И почему если у меня в программе нужно ставить задержку на шаг квантования явно "в ручную", а в жлезном триггере это не нужно это недостаток? В железе уже встроена задержка, самой физикой реального мира. В программе ее нет, и ее нужно ставить развязывая агебраическю петлю. В чем зедсь проблема?
По вашему критерию "верности", можно рассуждать так:
В реальном объекте при замыкании любого ключа в любом контуре возникает ЭДС самоиндукции, которая вызывает появление в этом контуре дополнительных токов. Поэтому выражение любого языка программирования, где переменная a типа boolean, мняет свое знаяение с false на true, не явялется верным, так как происходит мгновенное замыкание контура, и смена сигнала с 0 на 1, не соотвесвует критерию "верности".
Поэтому любое программирование, на любом языке программирования явялется не верным по определению! И не важно паралельное или последовательное.
... В чем зедсь проблема?
Проблема в том, что используемая Вами вычислительная модель не отражает качеств параллельных процессов. Реальный мир не лепит "от фонаря" задержки. Он в них просто не нуждается. По большому счету он о них даже не знает :) Это мы придумали такое понятие, как задержка. Просто мир обладает таким свойством или качеством, которое мы называем еще инертность. Но замечу и сама инертность тоже не простая, а - инерционная. Отсюда и "искусственные" понятия транспортных и инерционных задержек. "Верная" параллельная модель должна обладать качествами реальных параллельных процессов и тогда у нее не будет большинства проблем, которые порождают современные подходы к реализации параллелизма. И если у нее будут упомянутые качества, а автоматы имеют эти качества, то сама собой отпадет и необходимость "врезать" задержки "на шаг квантования". В результате Вы несравненно улучшите качество и надежность своих программ. В том числе и дадите ответ на вопрос как же будет вести себя схема С13 (замечу, - в ней задержки не обозначены)
Поэтому любое программирование, на любом языке программирования явялется не верным по определению! И не важно паралельное или последовательное.
Здесь Вы явно перегнули палку ;) Последовательное программирование является, кстати, верным по определению. А параллельное - в зависимости от используемой модели. Но что здесь важно. Одна и та же задача, решенная вне зависимости - последовательно или параллельно должна, во-первых, порождать одинаковые результаты. Во-вторых, должны быть операции эквивалентного преобразования из параллельной формы в последовательную и обратно. В теории автоматов все это есть. В том же (или той же?) Esterel - не знаю. Они, конечно, говорят о преобразовании своих программ в цифровые схемы, только ... зачем? А также о сведении любых циклических схем к ациклическим, что очень сомнительно, если не сказать - нонсенс, по теории тех же цифровых схем.
P.S. Было бы интересно посмотреть на работу схемы С13 в SimInTech. Если, конечно, такое возможно... Схемка-то, вроде, - тьфу?
Верная" параллельная модель должна обладать качествами реальных параллельных процессов
Зачем? Зачем мне качество реального электрического ключа при замыкании цепи, в операторе присвоения? Зачем мне вообще свойства реальных цепей в коде?
Отсюда и "искусственные" понятия транспортных и инерционных задержек.
В чем их искусственность? Если в модели используют формулы транспортного запаздываня для трубопровода, то никакой искственности нет, это математическое отражение физики реального процесса. Никаких "инерционных задержек" у нас в коде просто нет. Инерционная задержка для кода это выдуманное вами понятие, которое зачем то и почему то должно быть. В нормальном математическом аппарате дикретных вычислений есть задержка на шаг расчета во времени, для развязывания алгебраических петел, при численно интегрировании дифференциальных уравнений. Это нормальный, логичный, математически однозначный, наглядный и широко используемый прием в струкутурном моделировании. Зачем сюда тащить какю то "инерционность"?
Вы не разделяете понятие операторов/операций и понятия процесса.
Для Вас все едино - что оператор присваивания, что процесс присваивания. Как оператор, присваивание мгновенно, а как процесс - инерционно. Соответственно, например, то же интегрирование, как оператор, мгновенно, а, как процесс, - инерционно. И т.д. и т.п. Или, по-другому, т.е. следуя теории программ, в модели программ (да и собственно в программе, есть операторы и есть управление, которое этими операторами управляет. Так вот, операторы - мгновенны, управление - инерционно.
У реальных процессов нет алгебраических петель. У вычислительных процессов, поскольку они тоже вполне очень даже реальны, тоже не должно быть алгебраических петель. В ВКПа их нет, но есть ... просто обратные связи. Ну так как они есть у реальных процессов.
Если Вы сталкивались с АВМ (аналоговые машины), то должны вспомнить, что при реализации на них алгоритмов ни о каких алгебраических петлях даже речи не было да и быть не могло...
Реальный мир не лепит "от фонаря" задержки. Он в них просто не нуждается.
Мы не лепим задержки от фонаря, мы ставим их для развязывания алгелраических петель. Либо для синхронизации. А что касается реального мира, то в реальном мире нет и цифр, там нет температуры в К, там нет давление в Па или АТМ. Там нет сухого трения, там вообще все не так, как в программных моделях. Как только мы нарисовали цифру температуры, мы ушли из реального мира в абстрактную математику. И даже цифр 0 и 1 в реальном мире тоже нет! Возьмем ячейки памяти компьютера запишем в них 0 во все ячеки одинаковый 0, но напряжение на всех ячейках будет разное! И что как это нам мешнает выполнять вычисления?
Мы не лепим задержки от фонаря, мы ставим их для развязывания алгелраических петель. Либо для синхронизации.
Что тут скажешь? Одно - насильно мил не будешь, наверное? Возможно, Вам это процесс - развязывания - нравится, возможно, - привычка :) Мне это не нравилось изначально: реальные процессы "вопили" - зачем эти "довески"? И сейчас в подобном я не нуждаюсь совсем. Ну, - совсем! :) Плохо ли это? Мне хорошо. Как минимум, не нужно думать о самих алгебраических петлях. Ну, совсем. Нет такой проблемы. Ну, совсем! :) А от скольких сопутствующих проблем я при этом избавился - не счесть!
А что с С13? Может, все же попробуете? А то я попробовал решить своим автоматным подходом и что-то сразу не сложилось, а потом дела отвлекли... :( Сейчас чуть разгрузился и как бы можно продолжить. Но все же хотелось бы увидеть и Ваш стандартный, так сказать, вариант. Не скрою - ну, очень! ;) Мне почему-то кажется, что это не отнимет у Вас много времени...
Совсем говорите не нуждаетесь. Ну тогда расскажите как вы посчитаете например такую простую схему. В нулевой момент времени чему у вас равен выход суматора?
У нас такую расчетную схему SimInTech назовет ошибочной и попросит явно указать, что конкретно от него требуется.
Как вы предлагаете обойтись в данном конкретном случает?
У нас такую расчетную схему SimInTech назовет ошибочной и попросит явно указать, что конкретно от него требуется.
SimInTech явно очень хитрый :) Он "рекомендует", но, тем не менее, работает (я проверил ;). Почему так? На мой взгляд потому, что Вы не определись с моделью вычислений и отсюда все "непонятки" и колебания. Если вычисления "мгновенны", то правильна только верхняя схема, а нижняя просто не имеет права на существование, т.к. ее результат работы "ваще" непредсказуем. Но... она работает!? Работает потому, что SimInTech вольно или нет, но моделирует задержку на вычисление выхода. "Дуализм" какой-то :)
Как вы предлагаете обойтись в данном конкретном случает?
Да просто - работать по нижней схеме. Просто потому, что физическое качество реальных систем - инертность (инерционность) является и внутренним качеством автоматной модели. Поэтому с реализацией схем, содержащих обратные связи проблем по определению совсем нет. От слова "ваще"...
...В нулевой момент времени чему у вас равен выход суматора?
А какой пожелаете :)
Но если уже серьезно. Автоматный объект (не автомат - объект/процесс!) имеет свойства, которые определяют его выход в том числе и в нулевой момент времени. Инициализируете выход нулем - будет ноль. Установите по умолчанию какое-то значение, например, N - будет именно это значение. А в момент t+1, соответственно, N+1 и далее по нарастающей. Таким образом, данная "модель слогателя" при ее запуске будет наращивать свой выход до бесконечности (или пока ее не отключат), начиная от нуля или от значения N.
Конечно нижняя схема не работает, внизу ошибка и пользователь должен явно указать что он хочет в данном конкретном случае. Либо мы считаем что на старте 0 либо 1. И SimInTech явно требует пользвателю указать это. И тот и другой случай вполне себе возможны и правильны и более того встречаются в практике.
Инициализируете выход нулем - будет ноль. Установите по умолчанию какое-то значение, например, N - будет именно это значение.
Тогда по вашему получается, для того что бы правильно создавать расчетную схему, я должен предусмотерть в качестве параметров значения выхода для всех сумматоров, которые у меня будут использованы? Каждый "правильный сумматор" дложен в параметрах задание начальных условий в 0 момнет времени? Но ведь кроме суматоров у меня есть еще множество блоков у которых несколько входов, и потенциально я их могу замкнуть обратной линией, там тоже я должен задавать произвольное значение для первого момента времени. Их просто сейчас сотни. И в каждом я должен буду завать состояние выходов?
Но на самом деле я должен задвать заначение не только в 0 момент времени для сумматора, а в нулевой и следующий за ним, поскольку у меня может быть схема расчета вот такая как на рисунке. Если начало можно изменить задав начальные условия в момент времени 0, то на следующем шаге мы опять получим расхождение, потому что у второй задержки на шаг другое начальное состояние.
Причем количество задваемых инициализирующих значений для каждого сумматора или вообще любого блока будет равно количеству входных портов, на которые потенциально может прийти обратная связь. Что с этим делать будем?
Прошу прощения, но я только еще учусь... :) Что на выходах сумматоров означают [3] и [5]? Как их "создать"? Ну и внутри задержек - [1], [2]?
Что-то я так и не смог повторить Ваш проект. Видимо, это пока за гранью моих знаний пакета SimInTech :(. Это первое.
Второе. Предположим эта схема имеет смысл. Хотя бы - познавательный. И в этом смысле, действительно, Вы наглядно показали насколько нелепы задержки там, где можно обойтись без них. Ну, совсем они здесь не нужны. С другой стороны, можно представить ситуацию, когда они могут потребоваться, но и тогда - в чем проблема? Я вставляю задержки и назначаю им число тактов/время на которое они должны задержать сигнал. В чем здесь проблема?
Но, если честно, то про задержки в Вашей схеме я совсем не понял, а когда не понимаешь смысла, то комментировать вряд ли что-то возможно (если только не гадать, предполагать...). Или, по-другому, в случае, что говорить, когда я не вижу проблем совсем (в ВКПа, конечно), Вы обсуждаете шаги, начальные состояния, моменты времени и т.п. Я могу создать любой автомат или сеть из них, но должен быть понятен смысл - алгоритм, который реализуется.
...Что с этим делать будем?
С чем? Где здесь проблема/проблемы? В создании связей? В инициализации? Так в чем? - уточните.
Это демонстрации проблем алгебраической петли. В SimInTech мы должны указать явно, последовательность вычисления используя задержку на шаг. Вы утверждаете что в сумматоре должны быть заданны начальные условия им "инерционная задержка" тогда все будет хорошо. Я же демонстрирую, что не будет, поскольку обратных связей моежт быть больше одной и каждоая может содержать в себе разные иницирующие значения и разные задержки.
Этот пример кстати хоти и вырван из задачи, но является типовым. Например расчет гидравлической сети. Расход работчего тела между узлами зависит от перепада давления, а перепад давления зависит от массы рабочего тела и его состояния (температура, паросодержание, и т.п.) в узле, а масса и состояние определяются расходом. Что считать первым? В моменте мы видем алггебраическю петлю. Что бы ее развязать, вводим задержку и считаем расход исходя из давления на предыдущем шаге, там ровно будет суматор (сравнение двух давлений).
Самое интересное в нашей дискуссии, то, что вы оправдывая наличие обязательно встроенной задержки в вашей среде создание автоматов, ссылаетесь на некие "реальныйе" свойства реальных паралельных процессов, в жизни, которые по вашему мненею тдолжны обязательно отражаться в математике программы. Должна быть встроена "инерционность", на самом деле судя по всему простая задержка на шаг, несколько я понял.
Для Вас все едино - что оператор присваивания, что процесс присваивания. Как оператор, присваивание мгновенно, а как процесс - инерционно. Соответственно, например, то же интегрирование, как оператор, мгновенно, а, как процесс, - инерционно. И т.д. и т.п. Или, по-другому, т.е. следуя теории программ, в модели программ (да и собственно в программе, есть операторы и есть управление, которое этими операторами управляет. Так вот, операторы - мгновенны, управление - инерционно.
Создатели SimInTech по большей части используют математику для расчета реальных процессов. Аэродинамики, телофизики, электических систем, механических систем. И не просто что бы была некая "инерционность", а по взрослому, что бы инерция системы в модели отражала инерцию физической массы в жизни. И что бы этого достичь нужно использовать нормальную математику, без всякой "инерционности" и разделения вычислений, на операторы и управления.
Несколько упростим задачу, перейдя от сумматоров (по ним - отдельный еще разговор) на простые инверторы. Собрал такие схемки:
Hidden text
Это по мотивам Глушкова (см. стр. 175 Глушков В.М. Синтез цифровых автоматов). Верхняя - три инвертора соединенные последовательно. Вопросов нет. Средняя - три инвертора, объединенные в петлю. Сделано как в книге - петля разорвана элементом "памяти" . Нижняя - выдаст ошибку, но это так, как будет в ВКПа. Другими словами, SimInTech (в Вашем лице :) работает по средней схеме, ВКПа - по нижней.
Продолжим... Вот собрал несколько схем и все на тему инверторов:
Hidden text
Вроде, одинаковые схемы из инверторов, но работают почему-то по разному. Почему? Верхние три вообще в разнобой.
В нижней тройке используется инвертор, правда, другой, но тоже из тех же стандартных элементов (рассматриваются варианты реализации ;).
Наверное, каждый разработчик имеет свои представление об инверторе и соответственно этим представлениям его и использует...
Итак, повторю. Какая какие из представленных схем правильные. С точки зрения практики. С точки зрения теории. А можно и вместе :)
PS
Да. Режим - отладка. 10 шагов. Шаг - 0.25
Вдруг всплыла на Хабре интересная статья. Прямо в тему, так сказать. В ней приведена схема на тему гонки сигналов. Собрал в SimInTech. Получил следующее:
Гонки сигналов
Получилось явно не то, что представлено в статье и наблюдается на практике :(.
Что не так? Я то знаю, т.к. смоделировал в ВКПа и даже подправил в SimInTech.
А как сей факт объяснят "Создатели SimInTech"? Особенно те, которые "используют математику для расчета реальных процессов", а? ;)
Вот вы сами все себе и объяснили. В реальной логикие железа всегда существуют задержки при устновки уровней сигнала. В математике нам это задержка в принципе не нужна, поскольку все вычисления у нас дискретные и выполняются с заданным тактом интегрирования. Для того что бы выполнить вычисления мы должны определеить все входы, если для вычислений одновременно используется выходной сигнал, мы должны взять его из предыдущего шага, установив задержку. В случае если я хочу моделировать гонку сигналов из статьи, я должен задать шаг расчета системы, таким что бы у меня наростание сигнала, который мы имеем в реальности, отразилось в модели, чем точнее мне нужно получит данное нарастание сигнала тем меньше у меня должен быть шаг по времени моделирования.
В реальной логикие железа всегда существуют задержки при устновки уровней сигнала. В математике нам это задержка в принципе не нужна, поскольку все вычисления у нас дискретные и выполняются с заданным тактом интегрирования.
Какую бы математику Вы не используете, когда Вы ее перекладываете на программы, в "реальной логике" программ обязательно существуют задержки, выраженные реальным временем их работы. Мгновенных программ нет! Ну просто нет, как нет мгновенной телепортации :)
Поэтому все Ваши ухищрения с "тактом интегрирования", манипуляциями с "предыдущими шагами", временем моделирования и т.д. и т.п. - это все вынужденные меры для того, чтобы учесть задержки, вносимые процессами, реализующими даже "мгновенную математику".
А если мы хотим моделировать процесс "гонки сигналов" в электронной схеме, то мы должны не абстрактные задержки и мифическую "инерционность" переключателя автоматов ставит, а описывать физических процесс протекания тока, накопления заряда, с учетом паразитных емкостей и индуктивностей получившихся цепей. Например, в демо у нас есть пример моделирования коммутации транзистора IGBT.
После подачи импульса на включение напряжение на затворе растет и ток затвора заряжает ёмкость затвора, но транзистор закрыт. В момент достижения напряжения VTO транзистор включается, ток коллектора начинает расти, а напряжение коллектор-эмиттер уменьшаться. В некоторый момент напряжение на затворе практически перестает расти (возможно образование провала), ток коллектора продолжает расти, напряжение коллектор-эмиттер уменьшаться. Далее напряжение на затворе растет до напряжения управления затвором, напряжение коллектор-эмиттер падет до напряжения в открытом состоянии.
Процесс отключения происходит в обратном порядке. Однако, в отличие от MOSFET, для IGBT характерно появление так называемого «хвоста» тока коллектора, когда ток продолжает протекать значительное время.
Как здесь поможет "инерционность"?
А если мы хотим моделировать процесс "гонки сигналов" в электронной схеме, то мы должны ....
Для моделирования процессов гонок вполне достаточно оперировать идеальным двоичным сигналом, имеющим идеальные фронты установки в 1 и сброса в 0, которые дополнены понятиями задержки, которые вносят эти процессы. Где единичная задержка - это один такт дискретного времени системы. Если нужен расчет фронтов, то нужен и соответствующий их расчет. Что Вы и продемонстрировали :) Просто фронт в этом случае "под микроскопом" будет ступенчатый. Надеюсь, что и у Вас он именно такой :)
Конечно можно упростить модель и считать, что вместо нарастания тока переключения, есть просто задержка, вполне себе рабочее приближение, для некоторого вида анализа работы цепей. Например, для определения времени вычислений в схеме, как в статье по вашей ссылке. Но причем здесь математические вычисления записанные в виде структурных схем? Задержка, как упрощение реального процесса нарастания сигнала в цепи это понятно. Упростили модель электрической цепи. А зачем ту же задержку встраивать в виде загадочной "инерционности" в математические вычисления, например для гидравлического расчета. У меня есть диапазоны скоростей, для которых используется разные формулы расчета трения течения, я использую в программе "конечный автомат" переключения между формулами, при изменении скорости потока. Мне нужно просто поменять формулу в расчете. Зачем мне в этом автомате "инерционность" которая является упрощение переключения транзистора в электрической цепи?
Итак, повторю. Какая какие из представленных схем правильные. С точки зрения практики. С точки зрения теории. А можно и вместе :)
Все схемы правильные и работают так расчетчик задал на схеме. Каждая из схем стартует инициализируются с значения задержки, которая в такой схеме задает значение для всех линий связи в 0 момент времени. Если задали начальное значение 0, то первая модель на нулевом шаге установит значение 1 после инвентора, для второй модели два инвентора вернут значение в 0 - никаких изменений. Третья модель после трех инвесторов инвесторов установит 1. Вторая модель должна выдавать константу, 0 или 1 в заивимости от начального значения, что мы и видим. 1 и третья должны на каждом шаге менять значения 0 и 1, начальное значение определяется задержкой. Раз они стартуют с разных значений занчит в задержки заданы разные условия.
Все схемы правильные...
Если речь идет о процессах, то нет и еще раз нет. Процессы, в отличие от операторов-действий, имеют обязательное время исполнения. Не может быть схема правильной и неправильной одновременно. Как в этом - безынерционном случае. Когда схема разомкнута SimInTech считает ее правильной. Когда мы замыкаем ее выход на вход - сразу - опс!- сообщение - обнаружена алгебраическая петля. Это как представить рассматриваемую логическую схему, которая "мгновенно сгорает", если ее выход соединить со входом первого элемента. Т.е. до этого была вполне себе рабочая, а потом - бздым, КЗ! - сгорела. Грустно как-то даже :(
А что вы называете процессом? Для меня нарисованная струкутрная схема из последовательных инвенторов, это просто математическая формула, которая однозначно связывает вход с выходом и обеспечивает дискретное вычисление всех переменных на каждом временном шаге расчета. Это математика, а не электрическая схема. С помощью этой записи я могу описать любой физический процесс (в том числе и в электрических схемах). Я знаю систему диффренциальных уравнений для процесса, записываю их в виде схемы и получаю значения параметров процесса в дискретные моменты времени.
Для меня схема инвентеров изображенная в SimInTech не имеет никакого отноешения к схеме реальных электрических инвенторов, и там нет никакого "обязательного время исполнения". Например, я этот блок использую в схеме рассчета растояния ракеты до цели, где он просто меняет знак скорости ракеты, зачем мне в нем встроенная "инерционность"?
Или вот на картике кусочек алгоритма управления АЭС, который формирует команды на закрытия в случае если: 1) есть команда отклиючения насоса. 2) Отсутсвует команда на включения. Зачем мне в этом случае еще одна задержка "инерционность"?
Конечно схема, мгновенно "сгорает", если вход соединит с выходом, без явного указания задержки иначальных условий. Исчезает однозначная математическая логика вычислений в рамках дискретного шага. Например во алгоритм на который SimInTech выдаст ошибку, поскольку не понятно что выдавать в итоге. Есть комната открыть задвижку, нам нужно реализовать следующий алгоритм:
Если есть нет комнады закрыть задвижку KBA31AA001_YB02, или насос включен то надо выдать команду закрыть задвижку KBA31AA001_YB02.
А вот однозначная схема, если на предыдушем шаге не было команды KBA31AA001_YB02, или насос включен, то выдать команду KBA31AA001_YB02:
Еще более понята эта схема алгоритма будет в таком виде:
Мы получае все входные переменные перед началом такта вычисленй, проводит любые необходимы вычисления и сохраняем результаты в конце такта вычислений, зачем нам внутри на еще одна задержка "инерционность"?
Попробую показать отличие действия от процесса на рассматриваемом примере, который мне ближе и понятнее, чем процесс закрытия задвижки ;) И пусть я совсем отнюдь не математик, но все же постараюсь это сделать строго математически. Ниже от руки я напомнил схему и дал ее математическое описание (используя булеву алгебру), как операции, в коннотации SimInTech-а.
Индикатор фронта сигнала
Математически доказано, что изначально мы создали весьма "глупую" схему, которая реализует примитивное равенство: y=1. Но ведь понятно, что это явно не так. По исходному замыслу это схема, которая "ловит" передний фронт сигнала. Но делает это она в том случае, если является процессом. Как операция она же ни чего не ловит, а тупо выдавая на выходе 1. И если этот выход подать на счетчик - следующую схему, то, понятное дело, ни каких фронтов он не посчитает, хоть тысячу раз переключай входной сигнал схемы x. А если именно по этому фронту-то как раз и надо было бы закрыть задвижку, а? ;)
Но стоит нам вставить хотя бы одну задержку картина качественно меняется - схема сразу становится процессом, в котором почти каждый элемент имеет смысл. Вот так - одним мановением руки действие превращается в процесс (так что получается, что задержка способна превратить любое действие в процесс? Ни чего не напоминает?) А всего-то надо учитывать, что действие формально мгновенно, и тогда, действительно, схема представляет собой глупое математическое выражение, а процесс имеет время задержки минимум на один такт и это уже будет качественно иная штука. Математически ее надо бы записать хотя бы так: y(t+1) = f(x(t)), где в нашем случае функция f это фактически инвертор (в схеме он состоит из нечетного числа элементарных инверторов).
Ниже мы эту схему может легко превратить в генератор, в котором сигнал x запрещает/разрешает генерацию схемы. При этом само число инверторов-процессов определяет частоту генерации.
Генератор на индикаторе фронта
Математика - удивительная, замечательная наука. Но она - изобретение человека, который в ней допускает наличие мгновенных вычислений :) Например, любую площадь можно вычислить мгновенно. Но в реальной жизни такого нет и в помине. Даже, как действие, вычисление площади требует определенного времени. Но человек еще хитрее. Он может многие процессы, даже требующие достаточно большого времени, трактовать, как мгновенные. Возьмем пузырьковую сортировку. Она сама по себе, наверное, самая медленная, но ни что не мешает нам считать ее мгновенной. Почему бы и нет? Правда, для этого нужно выбрать дискретный такт, превышающий ее длительность. Но все, ведь, в наших руках? :)
В целом SimInTech ни что не мешает превратить в среду автоматически учитывающую описанные выше нюансы. Сделать ли это как в ВКПа или как-то иначе - вопрос открытый. Но то, что надо, это точно. Безусловно, вставка задержек, выявление алгебраических петель и их разрыв как-то решает возникающие то там, то тут проблемы (которые, кстати, не все сразу проявляются). Но все это явно походит на "пляски с бубном", что серьезно снижает и качество и надежность проектирования.
А зачем вы ловите передний фронт сигнала блоками, которые для этого не предназначены? Это похоже на операцию на глазном дне через задний проход :) нас есть специальны блок который так и называется импульс по фронту, есть импульс по срезу. Там вообще целая отдельная закладка "Задержки и импульсы"
Зачем мне в блок инвентор добавлять новые свойства, которые не нужны в 99,99% процентах вычислений с его использованием? Для чего? для того что бы считать импульсы, на схеме из инвенторов? А нельзя просто использовать готвый блок "генератор единичных импульсов"?
Что касается учета времени процесса, и других "ньюансов" так среда SimInTech именно это и делает по умолчанию из коробки. Тольк без всяких "инерционностей". Для моделирования физических процессов ее и создавали. Мы из блоков записываем дифференциальные уравнения, расчитываемые мгновенно (и да можно сортировку пузырьком туда же загнать), а далее запускаем вычисления с заданным шагом по времени и получаем, расчет процесса, любого. Хоть электрического, хоть механического, хоть гидравлического, хоть гонки сигналов в микросхемах. Но для этого нам нужна чистая математика, без всяких "инертнностей"
И "мгновенный" расчет площади в рамках одного такта, вполне себе имеет место быть. На рисунке схема нечеткого вывода, выходная величина определяется центром тяжести фигуры полученой при применении правил нечеткой логики, (синий треугольник на схеме). И вычисление площади выполняется "мгновенно" на каждом дискретном шаге. Обратите внимание, в базе нечетких правил так же может быть инвентор и не один. Инвентор нечеткой логики внутри имеет вычислений больше чем у стандартного логического, но при этом он все так же вычислется "мгновенно" в пределах временного такта. А если в нем будет задержка на шаг, то вся схема расчет пойдет псу под хвост, поскольку задержку на шаг мы уже используем для расчета скорости изменения входной величины, в данном конкретном регуляторе.
Например, любую площадь можно вычислить мгновенно. Но в реальной жизни такого нет и в помине. Даже, как действие, вычисление площади требует определенного времени.
В реальной жизни, площадь вобщето вычисляется мгновено, она вообще просто существует как данность, но не сущетсвует как число. Например площадь проходного сечения трубопровода при работе клапана. В модели ее нужно определять персчитывая положение рабочего органа клапана, и стпень перекрытия сечения. В жизни поток воды без всякой "инерционной" задержки просто ускоряется в сужениях и замедляится в расширениях трубопровода, причем мгновенно. Без всяких вычислений уравнения неразрывности теченияи с изменением площади сечения. Если же вас интересуют образование вихрей в турбулентом потоке при сужение, то мы опять используем чистую математику без всяких задержек в какой нибудть 3D считалке.
Мне кажется вы зациклились на электрической аналогии расчетных блоках, и как с гонкой сигнала. По моему мнению эт узкий частный случай где "инерционноя" задержка упростила вычисления. И теперь получив результат в одном случае вы пытаетесь натянуть его как сову на глобус, на все случаи расчета в которых такая инерцеонность не нужна и вредна. А их в жизни на три порядка больше, в практике расчетов, чем электрической аналогии.
Есть, безусловно, площадь и есть процесс ее вычисления. Первое мгновенно, второе - категорически нет.
В жизни поток воды без всякой "инерционной" задержки просто ускоряется в сужениях и замедляится в расширениях трубопровода, причем мгновенно.
Вы меня сразили наповал. Ну, хоть где-то, оказываются, существуют мгновенные процессы. Значить на пневмоавтоматике можно создать мгновенный процессор. А то народ озабочен какими-то квантовыми вычислениями... Еще немного и я поверю в чудеса - телепортацию, Бога и т.п.
...такая инерцеонность не нужна и вредна.
Она не нужна и "вредна" только в одном случае - случае единственного изолированного процесса-расчета. Если этот расчет представлен множеством процессов - особенно взаимодействующих между собой - то верный его результат невозможен без учета времени работы этих самых процессов. Иначе бы в SimInTech понятие дискретного такта было бы лишено смысла. Но без него почему-то ни как? ;)
Вы меня сразили наповал. Ну, хоть где-то, оказываются, существуют мгновенные процессы. Значить на пневмоавтоматике можно создать мгновенный процессор. А то народ озабочен какими-то квантовыми вычислениями... Еще немного и я поверю в чудеса - телепортацию, Бога и т.п.
Я не говорю о процессах во времени, я говорю о параметрах, в данном пример площадь проходного сечения, она не вычисляется в трубопроводе, а она просто существует, а поток воды при сужении увеличивает скорость, а при расширении ее уменьшает, без всякой задержки по времени, и гидравлические сопротивления на сужениях и расширениях, также существуют, без всякой задержки это просто параметры системы в конкретный момент времени. Рассмотрим стационарное состояние, скорости в разных сечения разные. Для рассчета этих параметров мне нужно выполнить трехэтажные вычисления систем уравнений неразрывности, сохранения энергии, сохранения импульса, и еще если скучно и вода кипит, то нужно учитывать процессы испарения и кондесации и взаимодействия фаз вода-пар. И все эти вычисления позволяют нам вычислить скорость в точке трубопровода. И таких точек в моей модели 1000. Зачем нам при этих вычисления инерционность в блоке инвентор? Там инвенторов, суматоров, переключателей в этих вычисления сотни, каждый будет давать задержку на шаг?
После того как я посчитал ("мгновенно" без всяких непонятных "инерционностей") необходимые параметры в n-й момент времени, я делаю вычисления для следующего (n+1) шага используя полученные данные в качестве входных. Так работает компьютерное моделирование динамических процессов в SimInTech.
А зачем вы ловите передний фронт сигнала блоками, которые для этого не предназначены? Это похоже на операцию на глазном дне через задний проход :) нас есть специальны блок который так и называется импульс по фронту, есть импульс по срезу. Там вообще целая отдельная закладка "Задержки и импульсы"
У меня создается впечатление, что Вы о многих вещах судите весьма поверхностно, спешите и не пытаетесь вникнуть в суть проблемы. Эти " не предназначенные блоки" входят в универсальный набор элементов (в теории он называется базис или функционально полный набор), с помощью которых реализуются любые Ваши фантазии. У разработчика нет Вашего элемента "импульс по фронту" и он его сделал, используя те элементы, которые ему доступны. Это же очевидно.
Дальше. Каждый должен заниматься своим делом: программист - программированием, хирург - операциями. И последнему виднее что и как делать с глазом. Как он решит, так и должно быть. Т.е. ... хоть через задний проход :) Но... если у Вас есть еще и мед.образование, то, возможно, как бывшему хирургу, Вы точно знаете ,что можно, а что нельзя. Здесь я Вам доверяю.
Зачем мне в блок инвентор добавлять новые свойства, которые не нужны в 99,99% процентах вычислений с его использованием? Для чего? для того что бы считать импульсы, на схеме из инвенторов? А нельзя просто использовать готвый блок "генератор единичных импульсов"?
Опять Вы не врубились. Есть инвертор, как операция/действие, и есть инвертор, как процесс. Это разные вещи. Первый подходит для создания новых операций/действий, второй - для создания новых процессов. И эти новые операции и новые процессы по-прежнему разные вещи. Вот это надо понять. Не надо все смешивать опять и опять в одну кучу. Я не могу представить операцию "генератор единичных импульсов", но как процесс - без проблем.
Что касается учета времени процесса, и других "ньюансов" так среда SimInTech именно это и делает по умолчанию из коробки...
В том-то и дело, что не делает "по умолчанию". В том-то и дело, что разработчику нужно это - различие между операциями и процессами держать в своей головушке. И для процессов вставлять задержки. И хорошо, если среда это ему подскажет, как в случае алгебраических петель. А если промолчит, как в случае нашего "ловителя фронтов"?
И "мгновенный" расчет площади в рамках одного такта, вполне себе имеет место быть
Нет "мгновенных вычислений"! И Вы просто вынуждены согласовывать свои "мгновенные вычисления" с заданной длительностью такта системы. Если "мгновенная сортировка" его превысит, то Вы должны или разбить ее на такты или увеличить такт решения. Это же "элементарно ...". Собственно об этом Вы и пишите, рассматривая "нечеткий регулятор". Но только, чтобы демонстрировать нюансы согласованной работы процессов совсем не нужно приводить примеры узлов проектирования атомоходов или космических кораблей. Нужно упрощать. А для этого вполне реальные схемы из логических элементов вполне себе самодостаточны, чтобы изучить специфику работы параллельных физических процессов.
В том-то и дело, что не делает "по умолчанию". В том-то и дело, что разработчику нужно это - различие между операциями и процессами держать в своей головушке.
Как раз не надо держать в голове это выдуманное вами разделение. Нужно просто знать, что схема в SimInTech это просто математика (операции по вашему), и блок инвентор это просто математическая операция. Схема в SimInTech она не электрическая и "инвентора как процесса" просто не существует, вообще только это и надо держать в гловушке.
Мне кажется, что кроме выдуманной "инерционности", которая просто задержка на шаг интегрирования, вы теперь ввели еще одну абстракцию, это разделение блоков на "операции" и "процессы". Теория получается все более интересной и развесистой.
Давай те я объясню как работает среда моделирования. Для того что бы получился процесс, вам нужно просто в среде SimInTech, блоками записать математические выражения, которые "мгновенно", без всяких "инерцеонностей", вычислят параметры и производные параметров для интересующих вас процессов, там могут быть и сортировки, и определения площадей, объемов, и все что угодно с любой сложностью. Есть даже блоки, которые делают итерационный подбор, что бы привести уравнение к нулю. (Итерационно меняют выход что бы вход стал равен 0). Но все это для заданного мгновенного состояния в конкретный момент времени. В результате этих вычислений вы получите параметры в текущий момент времени, и скорость их изменения (производные). После этого вы делаете заданный шаг в SimInTech по времени. Тут и только тут появляется процесс. Имея рассчитанные "мгновенно" производные, вы выполняет дискретное интегрирования на один временной шаг. Получаете новые значения параметров. Повторяете все ваши "мгновенные" вычисления для следующего момента времени. Бинго! Процесс пошел!
Если метод интегрирования простой, например Эйлера, то повторяете с заданным шагом, серию "мгновенных вычислений" каждый раз сдвигаясь на шаг пока не кончится заданное время. Если методы сложные, то после вычисление очередного шага анализируется точность, иногда происходит откат обратно по времени, сокращение шага, и повторение расчета с меньшим шагом по времени.
Как будут работать предлагаемая вам "инерционность" задрежка на шаг, если у нас шаг по времени в процессе меняется? Например в папке демо есть задача, расчет диффузии радиокативных элементов. Расчет начинается с шагом 1e-17 сек, потом постепенно вырастает до 0.06 секуды. Потом на 5 секуде рассчета, когда скачком убирается расход радиоактивного элемента, шаг снова падает до 1e-17 сек, для уточнения разрыва и в конце идет с шагом 0.1 секунда.
Нет "мгновенных вычислений"! И Вы просто вынуждены согласовывать свои "мгновенные вычисления" с заданной длительностью такта системы. Если "мгновенная сортировка" его превысит, то Вы должны или разбить ее на такты или увеличить такт решения. Это же "элементарно ...".
Как раз нет, при моделировании процессов, мне не надо согласовывать "мгновенные вычисления" с заданной длительностью такта. Если они у меня вычисления "мгновенные", то меня в принципе не волнует сколько физического времени нужно для выполнения расчетов. Абсолютно все равно, поскольку "модельное время" не меняется, пока не завершатся все необходимые вычисления. Время в модели стоит на месте и терпеливо ждет завершения такта. Вот две модели одна быстрая и считает БЫСТРЕЕ реального времени в 16 раз. Другая модель. "Резонансный трансформаторный инвентор", содержит блок меандр, генерирующий сигналы с частотой 20000 Гц. И если стоит задача изучения формы синусоидального сигнала, то мне необходимо выполнять расчет шагом 1е-8 сек. И на мой 3,8 GHz 8‑ядерный процессор Intel Core i7, для этой задачи обеспечивает скорость почти в 6000 раз МЕДЛЕННЕЕ реального времени.
Можно ли эти два процесса запустить параллельно в SimInTech? Например смоделировать работу трансформатора выдающего электроток через раствор с диффузией радионуклидов?
Да легко, можно например ток полученный после трансформатора отправить в гальваническую ванну с диффузией радиоактивных элементов и посмотреть как диффузия и распад влияют на ток первичного контур в трансформаторе .
И именно "мгновенность" расчетов, делает совместное параллельное моделирование простым и легким, как два пальца об асфальт. Понятным даже ребенку из детского сада для детей с задержкой умственного развития. Мне достаточно задать начальные условия и шаг синхронизации. Каждая из моделей посчитает "мгновенно" свое состояние, одна в 16 раз быстрее реального времени, вторая в 6000 раз медленнее, и после завершения расчета обменяются значениями параметров (например, из инвентора заберем ток, обратно отдадим электрическое сопротивление ванны). И пойдем считать следующий шаг.
Понятно что первая "модель диффузии", будет большую часть времени ждать, когда завершить свои "мгновенные" расчеты вторая "модель инвентора", но это нам абсолютно не мешает иметь одинаковое время в обоих модель на каждом шаге такте синхронизации. А теперь скажите пожалуйста, как сюда можно прикрутить "инерционость" блока инвентора?
Ошибся веткой.
C++, параллелизм и введение в автоматное программирование в SimInTech