Комментарии 20
Пардон-те, и где здесь C++ и параллельное программирование? Возможно, желательно точнее выставлять теги.
Сарказм:
ВКП - всесоюзная коммунистическая партия (https://ru.wikipedia.org/wiki/ВКП). А вы о чём?
Все что описано в статье реализовано на С++. Подробнее о реализации и о расшифровке названия (что-то оно Вас напрягло :)) - в ссылке на статью с определением автоматной программы.
Параллелизм - совсем уж просто. Здесь все параллельно друг другу. И созданные компоненты проекта Нагреватель, и все-все окошки (они же тоже отдельные процессы). Все работает параллельно и взаимодействует между собой.
С этим-то все понятно... Но вот чем или как объяснить разницу в результатах? Или это нормально и/или укладывается в какие-то нормы, о которых я не знаю?
В первую очередь для тех кто ставит минусы. Достали, блин! Вы, ребята, похоже не в курсе промышленного программирования. Погрязли там в своих "эджайлах"...
Вот пример из моей реальной практики. Стан гонит жесть, которую нужно рубить на листы или штамповать. Если программа будет работать с такой же точностью, как и нагреватель (нет ни какой принципиальной разницы в том, чтобы включить/отключить нагрев или отрубить/штампануть лист), то это заказчик заметит в момент (нужно только один лист наложить на другой) и скажет, мол, гудбай, Вася! Со всеми вытекающими...
А вы, блин, ... "минус". Думать и понимать надо, о чем идет речь... ребятки. Железо рубить - это вам не сайты клепать... Хотя, конечно, и сайты нужно делать с умом. А то, порой, думаешь - руки бы отрубил/штампанул :). Вот так-то... прошу прощения!
А давайте я вам пришлю одну дискретно событийную модель транспортного потока с диаграммами Харелла и ссылку на статью иностранную одну по данным которой эта модель и строилась. Интересно было бы сравнить способ реализации.
Результаты версии в SimInTech, созданной на внутреннем языке программирования:
Здесь они уже полностью совпадают с ВКПа. Надо ли что-то пояснять?
Схема SImInTech здесь просто ошибочная, блок выдержки состояния нельзя использовать в этой схеме, он предназаначен для минимального времени выдержки. В схеме же это блок используется для определения максимальной выдержки, получается что что выход из состояния 0, происходит без сброса. Из схемы видно, что выход из этого состояния так же используется в формировании сигнала индикатора.
В итоге неверный выход из состояния рушит и логику переключения индикатора.
В хлепе описание блока все написано верно: "Блок формирует на выходе единичный импульс, спустя заданное время после появления единицы на входе блока. Выходные импульсы продолжают формироваться с заданным шагом всё время, пока на входе блока сохраняется единица.Блок помещается внутри блока типа Состояние автомата и предназначен для задания минимального времени выдержки состояния конечного автомата."
Схема SImInTech здесь просто ошибочная ...
Похоже это не "просто ошибочна", а ошибочна просто ! Поскольку у меня наконец-то появилось время и можно вернуться в Хабр ;) Ошибаться не страшно. Страшно не знать причин ошибки. Здесь она достаточно очевидна - в используемой модели/технологии программирования. Она на подобные вещи провоцирует. Но если бы использовали правильные автоматы, то подобные вещи были бы почти исключены... Но одно дело так сказать, а другое - проверить сей тезис...
Поскольку уже дело давнее, то пришлось вспоминать... Помня, что дело в задержке, я просто для эксперимента увеличил время нагрева до 45 сек. В первом моем варианте получилась ожидаемая "бяка" (там задержка без сброса). Запустил последний вариант и Ваш - все совпало. Не скрою - это несколько удивило. Запустил ВКПа - то же самое. Как так? Ладно... Делаем 50 сек. Мои совпадают, Ваш - вот он:
График температуры
Явно не то. На душе полегчало... :) Сделал 55 сек. У меня ОК, в SimITech - кряк. Сделал - 60 сек. Везде внешне одинаково...Вот как тут быть? И еще. Когда запускал примеры, среда обновилась до последней версии. А в ней данный демо-пример до сих пор с ошибкой! Вопрос - почему? Надо бы, как мне представляется, "просто ошибку" исправить. Или это "сложно"?
Еще раз прошу прощения за "тормоза" с ответами - "автоматные дела" больно отвлекали ;)
Да потому что это же надо думать как реализовать теперь логику выдержки состояния изначально казалось что этим блоком можно обойтись а теперь придется самому ее реализовывать.
непонятная фраза "логику выдержки состояния"... Это как "вложенное состояние", "историческое состояние" и т.п. Нет, конечно, в "альтернативной теории автоматов" (АТА) можно придумать что угодно. И я это вполне понимаю и даже признаю.
Ели же говорить о классических автоматов, то там такого понятия, как "выдержка" нет. Состояние КА "выдерживается" ровно один такт. Далее в зависимости от состояний входов и функции переходов автомат или изменяет свое текущее состояние или остается в нем. Состояние автомата может быть "выдержано" только в двух случаях - когда не сработал ни один переход в текущем состоянии или сработавший переход - петля. Если из этого исходить, то все просто и понятно.
В случае Нагревателя условие "размораживания" его текущего состояния - или истечение времени задержки или достижение максимальной температура (так кажется?). У Вас насколько я понимаю проблема с задержкой. С одной стороны она, как процесс, должна быть параллельна автомату управления, с другой, ее надо отрубить, когда температура достигла максимума. Можно, конечно, и не отрубать. Но это тогда каждый раз нужно порождать новый процесс-задержку. Это не есть хорошо... Можно попробовать вложенную задержку, но ... прервать сложнее. Так что лучший вариант с задержкой параллельной....
Но это я объяснил, как я рассуждал в своем случае. У Вас, похоже, ситуация сложнее... Но это уже, как представляется, именно проблема выбранной модели автомата (Харелл).
Здесь она достаточно очевидна - в используемой модели/технологии программирования. Она на подобные вещи провоцирует. Но если бы использовали правильные автоматы, то подобные вещи были бы почти исключены...
Не согласен, если пользователь не читает инструкцию и лепит все подряд на схему, то никакая технология не поможет. Здесь как раз пример ошибки в логике построения модели, вместо + вставили -, и как тут "правильные автоматы" помогут? Да никак. Здесь же все оказалось еще проще. Вход в блок задержки нужно подключать не к входу в соттояние, а к блоку по температуре, тогда он будет спокойно сбрасываться при каждом входе, а не запомниать свое состояние до между выходами, и продолжать накапливать время задержки
Исправим в следующей версии, кстати описание примера окахывается в файле помощи, там то же нужно править.
А в общем большое спасибо за дотошное исследование SimInTech!
...как тут "правильные автоматы" помогут? ... Здесь же все оказалось еще проще. Вход в блок задержки нужно подключать не к входу в соттояние, а к блоку по температуре, тогда он будет спокойно сбрасываться при каждом входе, а не запомниать свое состояние до между выходами, и продолжать накапливать время задержки
Правильный чертеж помогает выточить правильную деталь. Конечно, если токарь может читать чертежи... Не думайте, что я придираюсь, но ... "вход в блок задержки". Не знаю, есть ли разница во фразах "вход в тоннель" или "вход тоннеля", но для меня "вход в задержку" звучит, скажем так, несколько загадочно, чем просто "вход задержки". Для меня фраза "автомат имеет входы и выходы" звучит математически точнее, чем "входы и выходы в автомат". Из таких "мелочей" и состоит технология. Это как чертеж, созданный по стандарту и чертеж "от руки".
Или "запомниать свое состояние до между выходами"... Суть автомата - "помнить" свое текущее состояние. Что значит "между выходами" ? У автомата есть начальное и заключительное состояния. Речь об этом? Если нет, то тогда я не понимаю о чем... Если речь о значении задержки, которая запоминается, то у автомата таких "способностей" в принципе нет. У него память только одна - его состояния. Чтобы от мог еще что-то помнить автомат нужно расширить. Например, добавить ему свойства (подобно свойству классам ООП). А чтобы автомат мог что-то делать, кроме простого оперирования с сигналами, ему нужно добавить действия/предикаты. Все это расширения модели автомата до полноценной алгоритмической модели. Ну, т.е. так, как это сделано в рамках определения формальной алгоритмической модели автоматного программирования. А такая модель - тоже часть технологии. Ну и т.д. и т.п. "Правильные чертежи" нужны и при проектировании программ. И, конечно, они должны быть в "умелых руках" программиста/пользователя, который следует требованиям этой технологии. Иначе он и будет "лепить все подряд". И тут, согласен, любая технология будет бессильна. ;)
Мы уже это обсуждали. Автомат который работает простым переключателем состояний, нам не интересен. Поскольку в реальной систем практически всгеда кроме сотояния есть постоянно действующие регуляторы. Может быть это связано с тем, что SimInTech в первую очередь это среда исследования непрерывных физических процессов. Первые реальные модели в SimInTech исторически это атомные реактор с турбинами, подземные хранилища газа и т.п. И основной вопрос исследование это процесс разогрева, снижения давления, увеличение расхода и т.п. То есть непрерывное отслеживание параметров процесса. Переключение соотояний в таких моделей пренебрежимо малая часть расчетов.
Может быть согласно правильной теории и нужно было сотавить автомат перключения состояний. И отдельно постоянно дествующие регуляторы напиример ПИД. Тогда используя автоматы мы расчитываем состояния (набор состояний), и на основании состояния выбираем выход одного из постоянно работющих регуляторов. В этом случае никаких проблем нет. Регуляторы работают постоянно, интеграторы и временные задержки в регуляторах всегда содаржать реальные данные накопленные в процессе непрерывного расчета. А все переключения вынесены в автомат.
Но мне кажется более интересным использовать автоматы как контейнеры которые могут содержать любую непрерывную логику. Тогда любое состояние автомата это просто субмодель которая в активном состоянии работает (с задержками, интеграторами, ключами и вообще любой произвольной логикой), в в отключенном состояини не работает (вся логика просто отключена).
И Esterel наш главный конкурент в области надежного ПО для авиации пошел именно по такому пути у них так же внутри автоматов состояния есть неперывно работающие блоки.
Согласен, что при этом нужно учитывать состояние блоков "с памятью" при входе в состояние и выходе из состояния автомата (ошибка в примере как раз связанао с запоминанеми накопленного времени при выходе из автомата и продолжением накопления после повторного входа), но зато наглядность и удобство работы кардинально повышаются. Ошибка становится очевидной и легко локализируемой. Мы ииследуюем только одно активное состояние автомата и на схеме определем элемент который завершает его до достижения заданной температуры. Найти ошибку может даже специалист не знакомый с моделью. Если бы это бы код, легче было бы его переписать.
Другой наш конкурент Matlab Simuink похоже сделал автоматы "как надо" и вынес их логику переключения в отдельный компонент. Но при этом получается менее удобно и меннее наглядно:
Мы уже это обсуждали. Автомат который работает простым переключателем состояний, нам не интересен.
Мы уже многое обсуждали, но ... Все (!) автоматы в определенном смысле "переключатели состояний". Интересная, кстати, мысль (про переключатель ;) Другого они просто не могут по определению. Потому-то и необходимо их расширение до алгоритмической модели. Это что-бы от них была польза, как от той же модели блок-схем...
Вы достаточно любопытно интерпретируете понятие автомата и от этого все (!) Ваши рассуждения об их работе. В реальности все конечно же совсем не так... Для меня здесь проблема в одном - убедить Вас в обратном, т.е. в том, что автоматы работают совсем не так :)
... Я прогнал Ваш и свой варианты нагревателей с синусом (увлекся Вашим "запалом":) и вот что получилось
Hidden text
Не знаю, как это будет выглядеть в симулинк, но здесь есть явная разница. Кто не прав - не знаю. Но кто-то явно немного, но "дурит". Не страшны ошибки, которые обнаружены (симулинк должен Вас, как минимум, поблагодарить), страшны те, о которых мы не знаем. Вы, насколько я понимаю, нагреватель не исправили. Может это и сказывается? Я же за свой вариант не могу ручаться пока лишь потому, что из почти десятка своих нагревателей выбрал наугад один и ... влепил в него синус... Вот что получилось, то и получилось :)
Кстати вариант, когда накопление значений непрерываными блоками в авктивном состоянии с сохранением из значений при выходе и продолжением накопления при повторно входе вполен себе может иметь место. Например если я использую два клапана последовательных клапана для регулирования расхода. Один для быстрого другой для точного регулирования. То я мого поместить два ПИД регулятора в два разных состояния автомата и переключатся между ними. В процессе рассчета. Тогда у меня в одном состоянии работате один ПИД и один регулятор в другом состоянии работает другой ПИД и другой регулятор.
1) Непрерывных блоков просто нет уже давно. Почти все современные блоки дискретные, т.к. АВМ мы давно уже пох...ли (т.е. отказались от них)! :)
2) Ну не может в состоянии автомата что-то работать! Ну, не может! Это - аксиома! Ну, прочитайте определение автомата. Где там хоть что-то, хоть немножко про ... "в состоянии"?
С другой стороны, если Вы не про классические автоматы, то тогда не спорю - может быть все что угодно. Человеческие фантазии с момента сотворения Мира, похоже, ни чем уже не ограничены :).
2) Ну не может в состоянии автомата что-то работать! Ну, не может! Это - аксиома! Ну, прочитайте определение автомата. Где там хоть что-то, хоть немножко про ... "в состоянии"?
Читаю определение автомата:
A finite-state machine (FSM) or finite-state automaton (FSA, plural: automata), finite automaton, or simply a state machine, is a mathematical model of computation. It is an abstract machine that can be in exactly one of a finite number of states at any given time.
И нигде не вижу запрета на работу хоть чего нибудь в любом состоянии автомата. Читаю примеры конечных автоматов и везде вижу как раз наоборот, конкретное указание, что в состояние автомата как раз и нужно для запуска какой то работы: (доставка нужного продукта в вединговых автоматах, перемещение лифта между этажами, сигналы светофора, и даже комбинация для открытия замка) везде сотояние автомата определеяется что будет работать (или не будет работать)
Simple examples are: vending machines, which dispense products when the proper combination of coins is deposited; elevators, whose sequence of stops is determined by the floors requested by riders; traffic lights, which change sequence when cars are waiting; combination locks, which require the input of a sequence of numbers in the proper order.
Поэтому логичное и наглядное решение поместить блоки модели обеспечивающие необходимую работу непосредственно в субмодел графически представляющую состояние.
В итоге Simulik при использовании автоматов, так же приходит к необходимости отключать и выключать части модели в зависимости от состояния автомата. Вот на рисунке например две субмодели (зеленые квадратики) включаются и выключаются в зависимости от состояния. Линии из автомата идут сверху в зеленые блоки.
В SimInTech так же можно сделать, а можно эти субмодели поместить непосредстванно в диаграмму состояния и тогда можно на диаграмме состояний видить какая из субмоделеи активна и работает, а какая в нективном состоянии.
1) Непрерывных блоков просто нет уже давно. Почти все современные блоки дискретные, т.к. АВМ мы давно уже пох...ли (т.е. отказались от них)! :)
Есть динамические блоки, это блоки в которых на каждом дикретном шаге, рассчитвается не только их значение переменных состояния, но и их производные. Для таких блоков мы, зная производную, можем получить значение не только на конкретном дискретном шаге, но и между шагами. Тем самым мы получем в дискретной системе модель непрерывного процесса.
Автоматное программирование в SimInTech и ВКПа