Комментарии 17
В фреймворке QPc тоже есть возможность проектировать КА в графическом виде. Там есть очень удобное понятие - вложенные конечные автоматы. Они сильно помогают бороться со сложностью болших конечных автоматов. Умеет ли такое ВКП?
В фреймворке QPc
Это Quantum Leaps? Квантовое программирование, так кажется?
Там есть очень удобное понятие - вложенные конечные автоматы.
В ВКПа это тоже, конечно, есть. Без этого - ни как и ни куда. И даже дано формальное определение вложенного автомата. Есть даже вложенные инерционные автоматы. Обо все этом в статьях по ссылкам, о которых я говорил в предисловии (т.е. в 1-й статье на тему ВКПа)
И по поводу сложности Еще эффективнее бороться со сложностью с помощью параллелизма. Даже не имея вложенности, все вопросы можно решать с помощью параллелизма. Так что кто-то в параллелизме видит только средство для повышения скорости, а для меня главное в нем - это решение проблем со сложностью.
У меня есть подозрение, что все что здесь описано можно сделать на labview. Там есть все, и визуальные компоненты и виртуальные приборы и много ещё чего. И все это без кода, графический язык.
Хотелось бы, чтобы Ваши подозрения на чем-то основывались. Ну, например, реализуйте на LabVIEW простой алгоритм контроля датчиков гильотины. Получится - прекрасно. Можно будет сравнить. Если это просто "ля-ля", то к чему? Показать, что, мол, - "плавали-знаем"?
Например. При обсуждении моей статьи "Параллелизм без потоков: очевидно и вероятно" @AndreyDmitriev попробовал все, о чем он "подозревал", изложмить именно на LabVIEW. Вот за подобное - спасибо. Я за подобную критику, а не за некие "подозрения".
Итак, повторю. Если знаете LabVIEW, то воплотите свои "подозрения" в жизнь, реализовав мою просьбу - создать тот же алгоритм контроля датчиков. В ВКПа это совсем просто. А на LabWIEW?
Соотвественно и про Quantum Leaps. Я даже нашел статью на Хабре - Quantum Leaps QP и UML statecharts. Вроде про автоматы. Я думал, что про них если не все, то мное знаю. Но, прочитав статью, "подозреваю", что я просто дебил, т.к. совершенно ни чего не понял. Просто не понял какой там алгоритм рассматривается? Видимо про какрй-то счетчик, т.к. есть "count", но как над ним издеваются - за пределами моего разумения. Как, используя QP, т.е. материал этой статьи, реализовать тот же автомат контроля датчиков? Проблема - тьфу, а мозги выворачиваются на изнанку..
В ВКПа я легко преобразую любой автомат в презираемые всеми блок-схему (соотвественно и любую блок-схему в автомат) и реализую ее затем на любом языке. Без всякой ВКПа и автоматов. Но как это сделать в QP и том же UML? "Тайна сия велика есть"? ;)
Да понял, понял. А насчёт подозрений-достаточно прочитать мою статью о разработке и реализации программируемой системы тестирования датчиков. На хабре, в моем профиле можно её открыть. Вряд ли вы могли сделать просто нечто подобное на вашей системе. Это не учебные программки про гильотина создавать, тут намного все сложнее.
Вы так и поняли. Все, что можно сделать в Qt и на С++, можно сделать и в ВКПа. Нужны только знания, время и ... деньги. Это, так сказать, по умолчанию. Поэтому, если речь идет обо мне лично, то, может, и не смог бы. Тут даже и спорить не буду или что-то доказывать. Ну а тот, кто хорошо знает возможности Qt и C++, думаю, без проблем. Потому как о каких-то ограничениях здесь я не слышал. Может, подскажете? Да и Вы, судя по статье, намеревались применить что-то типа C#. Неужели на С# можно, а на С++ нельзя? Подозреваю, что можно ;)
Но чуть серьезнее. Если бы передо мной стояла такая же задача... Во-первых, реализовал/нашел бы протоколы. Во-вторых, сделал бы операции/команды, которых нет на визуальном уровне. В-третьих, оформил бы сценарии тестирования в форме автоматов. Ну и, в-четвертых, использовал любую базу данных. Кстати, есть интересный замысел, и, возможно, что-то подобное мне и предстоит сделать... ;)
Да, и еще. Визуальный уровень можно и не подключать, а сделать все на С++. По большей части так и делаю. Протоколы, "ителлектуальное общение", параллелизм - все это обычное дело. Есть готовое - применяю, нет - дорабатываю. И это не только "учебные программки" (они в первую очередь рассчитаны на тех, кто что-то "подозревает"), а вполне себе серьезые вещи. Кстати, разработка самой среды ВКПа, думаю, посложнее будет, чем описанный Вами проект.
А приведенный пример гильотины - это часть реального проекта. Один в один. Более того, в процессе написания статей обнаружились определенные проблемы. Но об этом уже в следующей части. Но вот если б Вы обнаружили эти или какие-то другие проблемы в работе модели, то я был бы, если честно, удивлен. Я бы их даже бы проверил ;)
Просто без базы данных, на логике конечных автоматов далеко не уедешь в подобных задачах, что я описал в своей статье. Ну а на чем писать интерпретатора конечно без особой разницы, на с# или с++ тоже можно, просто это было бы намного сложнее и дольше чем на labview, которая в общем тоже написана на С но сложность интегрирована в визуальные компоненты, что делает систему чрезвычайно стабильной. Я уж не говорю о стабильности SQL базы данных, которая управляет всей этой системой. Попытка ваша интересна, но в реальных задачах наверно её будет сложно использовать без поддержки БД.
Думаю, что Qt поддерживает SQL.Так уж сложилось что в ВКПа на Visual Studio я работал с БД, а тут как-то не было нужды. Но уверен, что с этим (БД) проблем не должно, т.к. и там и здесь все тот же C++. Вот даже нашел быстренько.
@AndreyDmitriev попробовал все, о чем он "подозревал", изложить именно на LabVIEW.
Теоретически можно и на LabVIEW гильотину измыслить, там в общем есть визуальные инструменты для создания автоматов. Хотя я вообще больше по части пром обработки изображений, ну вот к примеру, сортировка и проверка лего деталек:
Или проверка пинов:
Там довольно примитивно всё - есть состояния и есть транзакции-переходы между состояниями, которые срабатывают при наступлении определённых условий. Я притормозил немножко исполнение, чтоб нагляднее было.
Здравствуйте! Приятно вновь встретиться ;)
Все это очень интересно, но... Я вижу графы, которые, ну, очень похожи на графы автоматов, но как Вы их создали? Для меня автомат - это прежде всего язык проектирования, а здесь? Ну, например. Есть переходы, но нет условий переходов. А действия где? Есть состояния, а при них - имена или имена действий или и то и другое? Т.е. складывается впечатление, что данные автоматы - это некие анимированные картинки?
Рассейте мои сомнения... ;)
Приятно снова пообщаться, Вячеслав.
Вы правы, это картинка (Picture Control в терминах LabVIEW), но есть нюанс — она интерактивная.
Вот как создаётся такой автомат. Изначально у меня есть состояния Start (откуда я влетаю в машину состояний) и End (куда я выхожу, но так-то я могу сидеть в автомате так долго, как хочу):
Допустим я хочу сделать гильотину, которая по команде юзера (или внешнему сигналу) отрежет мне несколько ломтей чего либо. Опуская обвес датчиками, мне нужно три состояния - ожидание внешнего сигнала, собственно отрез и инкремент счётчика (в принципе я могу и двумя обойтись, засунув инкремент в отрез, но пусть будет три для наглядности), назову их Wait, Cut и Inc :
Теперь мне надо организовать транзакции между состояниями, тут всё довольно очевидно (у любого стостояния должна быть как минимум одна дефолтная транзакция, по умолчанию она замкнута сама на себя, но я их растяну вот так)
Теперь я набросаю наипростейший ГУЙ, ну пусть будет хотя бы так:
После этого мне надо настроить условия транзакций, заодно я их могу переименовать, чтоб нагляднее было (хотя я могу, конечно сделать х4х6х12 и т.д., но пусть будут осмысленные имена). Мне собственно только три надо — переход из ожидания в "отрез" срабатывает когда юзер жамкает по "Старт", затем переход из отреза в ожидание, когда число отрезов достигнуто, ну и выход, а дефолтные транзакции мне трогать не надо, они срабатывают автоматом, если другие не триггерятся:
Почти готово Осталось настроить состояния - собственно мне достаточно просто инкрементировать счётчик, ну и показывать его на экране (так то мне надо управлять гильотиной, так что в реальной жизни я добавлю больше кода для управления, чтобы послать сигнал, и.т.д). Каждое состояние может иметь несколько акций, они выполняются последовательно в пределах одного состояния, к примеру Inc будет выполнять два действия - никрементировать счётчик и потом обновлять интерфейс
Ну и вот, до тех пор пока не нажата кнопка старт, срабатывает дефолт транзакция состояния Wait, а если начинается работа, то мы прыгаем между состояниями Cut и Inc, и потом возвращаемся в Wait.
Это режим отладки с подсветкой - активное состояние обводится рамочкой, а активная транцакция подсвечивается синеньким (где-то в гифке имена транцакций потерялись, ну и ладно).
Технически линии транзакций рисуются безье кривой, так что я могу немного править диаграмму машины по вкусу, позиции лейблов тоже можно подвигать ну и состояния размещать как мне нравится (размер овалов менять нельзя), чистая косметика:
В принципе на C#/WPF это не очень сложно реализовать. В LabVIEW это где-то с седьмой версии появилось, стало быть где-то 2003 год, эх, двадцать лет прошло, вот ведь время летит.
Что касается примера из коммента выше, то там в первом стейте выполняется загрузка картинки и классификация
Собственно классификация - это предобученный классификатор
А транцзакции срабатывают соответственно классам. Вся иделогия в том, что из состояний наружу торчат их результаты, которыми и триггерятся транзакции.
Ну и дальше стейт для шестерёнок считает зубчики поиском границ
А другой для колёсиков считает в них дырочки
Как я уже писал, мне в принципе не надо заводить отдельный стейт на инкремент счётчика, вот, к примеру есля я хочу проверять упаковки шоколадок, чтобы быть уверенным, что автомат кладёт туда 12 штук:
то мне достаточно вот такой машины состояний:
Ну и в реальности оно, конечно сильно быстрее бежит, чем я поазал в режиме отладки с подсветкой выполнения:
Тот код, который выполняется внутри стейтов - суть как плагины организован, есть библиотека из готовых кирпичиков как для процесинга изображений, так и для общения с внешними устройствами (Modbus, OPC, OPC UA, TCP, платы ввода вывода и т.д.), но можно и самому написать, конечно.
Где-то так.
Вот, честно - впечатлен!
Никак не ожидал, что что-то подобное есть в LabVIEW. Конечно, вопросы по автоматам есть. Возможно, потому, что для понимания надо было бы прощупать их ручками.
Итак, по автоматам. Ну, например, во-первых, - переходы. На мой взгляд как-то слишком уж в лоб. Хотелось бы иметь, как минимум, конъюкции условий перехода. Т.е. что-то типа transition1transition3 - подобно x1x3 или transition1^transition3 - если нужно что-то типа x1^x3. Т.е. иметь возможность составлять логические выражения. Также важно, если условие перехода включает несколько transitions, то они должны восприниматься, как параллельные.
Во-вторых, - действия. В классических автоматах есть действия по типу Мили и/или типу Мура. Здесь, похоже, только по типу Мура. При этом я не воспринимаю их, как действия реализуемые В состояниях, а как действия ПРИ них. Хотя полное впечатление складывается, что они исполняются при входе в состояния. Это совсем не по автоматному :) Не устраивает и их последовательное исполнение. Надо бы, если операции в рамках отдельного действия, то они последовательные. Если это несколько действий, то - параллельные. Ну, как в ВКПа ;)
Хотелось бы иметь четкое понимание того, как ведут себя сети автоматов, если их, конечно, можно создавать вообще. В ВКПа - это рядовое дело. Собственно, ради них и следует занимться автоматным программированием. Отдельные автоматы - одно, сети - другой уровень. Это как последовательное и паралельное программирование. Два разных программирования.
О технологии проектирования автоматолв. В чем-то аналогично проектируются визуальные автоматы и в ВКПа. Конечно, в LabVIEW сделано много шикарнее и визуальнее, но принцип примерно тот же - через диалоги сформировать нужные предикаты/действия. Что-то подобное у меня тоже есть в планах, но пока до этого просто руки не доходят. .ВКпа, как мне представляется, пока берет моделью ;). Ну, а если мне нужен автомат посложнее, то я просто его делаю на С++. А с его возможностями ни какая визуализация не сравнится. Как мне показалось и в LabVIEWЮ когда не хватает визуальных возможностей, поступают также на уровне тех же библиотек. Собственно в ВКПа такие же библиотеки, но только на С++.
При этом, навскидку, модель автоматов Stateflow в MATLAB помощнее будет автоматов в LabVIEW. Хотя, не исключаю, модель и одна (типа UML). Но, еще раз, - красиво. Этого ВКПа, что там скрывать, не хватает. Но опять же это все дело техники. Примеры, как минимум, визуальной реализации автоматов в LabVIEW и в MATLAB, демонстатруют это Во-первых, КАК это можно сделать, а, во-вторых, что каких-то принципиальных препятствий для подобной реализации нет.
Еще раз - просто впечатлило! Пока мы тут боремся за первенство термина "автоматного програмирования" в рамках "СВИСТ-технологии" или увлечены некими "традиционными ценностями", кто-то просто "лопатит код" и уже давно не сводит проектирование автомтов к оператору типа SWITCH. Вы показали это очень убедительно и просто наглядно (хочется научиться делать такие же гифки:).
Я даже уверен, что когда-то автоматная модель ВКПа будет реализована в LabVIEW или MATLAB ;) Все идет в эту сторону. А ведь когда-то, лет этак 30-40 назад (эх, как время летит!:), было объявлено, что автоматы исчерпали свои возможности. Даже придумали было .сети Петри. Только, кто теперь помнит про эти сети Петри, и какой бум, особенно в последнее время, вокруг автоматов. Пусть тока это не те автоматы, но, как говорится, - еще не вечер ;)
Что ж, я рад, что хоть чем-то удалось удивить. Я так понял, что в "ВКП" эти диаграммы нарисованы чуть ли не MS Visio, а здесь у нас примитивное "Visio" прямо на борту, с возможностью редактирования и отладки, пошагового исполнения и т.п., что переводит программирование автоматов в разряд "как слышится — так и пишется". Нужно новое состояние — значит "New State", а новый переход — "New Transition", а больше там ничего и нет. В бекэнде там работает цикл обхода графа — состояние->переход->состояние и т.д. Не помню, что будет, если сработают два перехода (этим воскресным утром у меня нет компа под рукой), скорее всего выполнится тот, кто был создан первым, у него выше приоритет. Довольно элегантно решён вызов начинки стейта — там абстрактные интерфейсы, собственно стейт понятия не имеет что он там внутри вызывает — для него что коммуникация с ПЛК, что анализ изображения — всё едино. Ну там ещё по мелочи — есть переменные, само собой, которые я могу писать в одном состоянии и читать в другом и ими же могу управлять переходами. Элементы интерфейса тоже отражаются на переменные. Можно запустить несколько автоматов параллельно (скажем один управляет подающим конвейером, а второй — анализирует изображения), но это редко бывает надо, обычно у меня ПЛК есть для этого.
Кстати, помимо простенького LabVIEW State Diagram Toolkit, о котором шла речь выше, был ещё одно время навороченный LabVIEW State Chart Module. Визуально он чуть иначе выглядит:
Анатомия там вот такая:
помимо классических состояний (2), инициирующих (1) и терминальных (12) псевдосостояний и переходов (4) были введены супер-состояния (5), суб-состояния (9), ортогональные регионы (7 и 8), форки (6) и джойны (11), история состояний (10), порты (3) и вообще чёрта в ступе, всё это как синхронно, так и асинхронно и всё такое.
Но этот "швейцарский нож" не зашёл совершенно, в 2018 году вроде как разработка была прекращена.
(хочется научиться делать такие же гифки:).
Совсем забыл написать — они сдёрнуты с экрана при помощи ScreenToGif.
Спасибо, теперь я "вооружен и очень опасен" :) Но вернемся в тему....
Я так понял, что в "ВКП" эти диаграммы нарисованы чуть ли не MS Visio, а здесь у нас примитивное "Visio" прямо на борту, с возможностью редактирования и отладки, пошагового исполнения и т.п., что переводит программирование автоматов в разряд "как слышится — так и пишется".
Так оно и есть - Visio. А, конечно, хотелось бы иметь "на борту" графику, но ... Графическая форма, несомненно, наглядна, удобна и т.д. но табличная форма (текстовая) иногда удобнее и уж совсем проще в реализации. В любом случае графическая форма должна быть преобразована в исполняемую форму и здесь табличная форма является именно таковой. А отсутствие "бортовой графики" я компенсирую средствfми визуализации, внедренными в ВКПа (их я и представил в последних статьях). Конечно, это несколько не то, но и они здорово помогают. Конечно, лучше бы иметь и то и другое. Например, в MATLAB-е есть и графическая и табличные формы представления автоматов. И это и правильно и хорошо. А в LabVIEW есть табличная форма описания автоматов?
Но в любом случае форма формой, но все же нужно иметь представление, какой автомат она реализует. Именоо в математическом смысле. Именно от этого надо "плясать". Например, мне кажется, что LabVIEW реализует фактически автоматы Мура. Если это так, то это несколько ограниячивает их возможности.
Не очень понятно автомат в LabVIEW абстрактный или структурный. По первому впечатлению - аьстрактный. Почему? Во-первых я вижу только один "символ", как условие перехода. Фактически имеем и один "символ" на выходе. С ними можно, конечно, связать те или иные отдельные действия и даже их последовательность, но это все же не то. Структурный автомат (с абстрактным состоянием) - более гибкая модель и ближе к реалиям.
Можно запустить несколько автоматов параллельно - это хорошо. Но какой это параллелизм? Надо проверять. А что проверять и как проверять, если нет формального определения этого параллелизма? Как, например, можно проверить операцию умножения (хотя бы 2*2), не зная результат?
"Шведский нож", думаю, потому и не зашел, что за его "лесом" возможностей не видно "деревьев" - формальной модели автоматов. Или это диаграммы Харела, как в UML? Например, в тот же MATLAB в их Stateflow однозначно сказано - Харел. И с ними все ясно. В LabVIEW я пока не знаю - одни мои догадки.Где-то про это сказано? Т.е. про формальную модель отдельного автомата, про формальную модель множества автоматов? Если это есть, то есть и точка отсчета и одновременно цель, которой должна соотвествовать реализация. Если нет - то видим "шведские" варианты "леса" из завалов "деревьев".
Например, раньше к этому процессу - созданию новых вычислительных моделей подходили много строже. Считали, что та же машина Тьюринга - это абсолютный эталон, а потому, когда предлагалась новая модель, то приводилась и формальная процедура приведения к ней. То же самое делали по отношению к автоматам. Сейчас этим просто не замарачиваются. А так быть не должно. Хотя есть ;)
Как я убедился автоматы в LabVIEW достаточно интересны, но где "точка отсчета"? Например, срабатываение двух переходов - маразм с точки зрения теории обычной модели модели. Это грубейшая ошибка, а мы еще обсуждаем, какой переход может сработать ;) Подобную модель просто нужно корректировать или устранить подобную вещь, а не думать, что и за чем будет выполняться. Кто-то с этим явно не согласиться, но ... Реализаци математики, в которой 2*2=5 для кого-то может иметь важное значение, но, во-первых, необходимость такой математики нужно еще обосновать, а, во-вторых, сравнить с той математикой в которой 2*2= 4.
Например, я не понимаю, что такое квантовый компьютер. Как на нем реализовать простейший алгоритм, например, нахождение наибольшего общего делителя (НОД). Понятие алгоритма, ведь, ни кто еще не отменял. Он что - реализует какие-то иные алгоритмы? Но если ты "компьютер", то будь добр реализовать любые алгоритмы. Ну, ладно, ты что-то там считаешь очень сложное для понимания... Но неужели это нельзя представить в форме алгоритма и сымитировать вычисление на обычном компьютере? Пусть это будет даже очень и очень медленно.
К чему это я так пространно? Можно много обсуждать автоматы. но если нет процедур их сравнения, то это почти бессмысленный разговор дилетантов. Типа есть Бог или нет. Наука говорит - нет, вера - есть. Я почему-то больше доверяю науке ;) С автоматами проще - есть теория автоматов. Поэтому для меня автомат, имеющий несколько активных переходв - это "божественный автомат" ;-). Он выпадает из моего научного понимания модели автомата. Да, есть недетерминированные автоматы. Но это совсем другое дело. Там, во-первых, срабатывают все такие переходы, а, во-вторых, они приводятся к обычным - детерминированным автоматам. Есть еще, правда, вероятностные автоматы. Но, надеюсь, в LabVIEW речь совсем не о них ;)
Про маразм двух переходов я в общем согласен, просто в данной реализации можно задать скажем одно условие перехода по достижении переменной значения 5, а второе, в другое состояние при 10, и установив значение в 15 мы фактически активируем оба перехода, но выполнится только один (просто я знаю, как оно под капотом устроено). В статике это никак не проверяется, тут это на этапе дизайна автомата отсекать надо. Кстати не факт, что асинхронная модель расширенной версии как раз отработает оба перехода и следующие состояния параллельно, мне просто лень древнюю LabVIEW расчехлять, чтоб проверить.
Табличное представление в теории возможно, но в общем не очень нужно, потому что из представления автомата (а там просто граф) можно сгенерить нативный графический код LabVIEW, то есть одно графическое представление перебрасывается в другое, эквивалентное, и мне, мыслящему категориями потоков данных LabVIEW оно даже в чём-то понятнее (котя этот код мне не очень нравится).
А так там чистая незамутнённая логика, никакой магии, божественности и недетерминированности нет и в помине (с маленькой поправкой на то, что Windows не является ОСРВ в некоторых частных случаях).
Нужда появляется когда появляется реальная задача. Вот тут и проверяется на что годна система, которую разработал. Я ещё в начале 2000х сделал систему на связке delphi/sql и она прожила почти 10 лет. Но тогда это была торговая система. Сейчас уже сделано 5 систем, одна из них информационная с элементами документооборота на delphi/sql, четыре других под железо и датчики на labview/sql. Привлекает простота и скорость разработки десктопных приложений.
ВКПа. Введение, ч.2. Копирование автоматов и начала имитационного моделирования