Инициализация конечного автомата после сбоя, теория и практика Опции

[Litkevich Yuriy]

оговорка: использую Qt и её QStateMachine, но интересует и абстрактная система.

Дано:
- Имеется оборудование с насосами,
- имеется средство двусторонней связи оборудования с компьютером и
- ПО управляющее этим оборудованием.
Программно реализован конечный автомат управления насосами.

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

Для простоты предположим, что комбинация сигналов однозначно определяет текущее состояние автомата.

В практике программирования автоматов обычно из одного состояния в другое можно перейти только по событию, в частности в QStateMachine реализовано так же.


Проблема:
Т.к. физическая система находится в неком стабильном состоянии, то и событий в ней не происходит.
Как заставить автомат перейти в некое состояние минуя, возможно, многие другие?

Есть ли у кого-нибудь опыт/идеи как это сделать?

Сообщение отредактировал Litkevich Yuriy - 27.10.2015, 12:47

[Iron Bug]

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

[Litkevich Yuriy]

нельзя работу физической системы прерывать, там процесс измерительный длится несколько часов и её перезапуск - дорогое удовольствие.
Отчасти можно сказать, что программа на ПК - вспомогательный "управитель", само измерение может быть произведено без его помощи.
Поэтому и хочется, чтобы запуск программы не переводил физическую систему в исходное состояние.

Сообщение отредактировал Litkevich Yuriy - 28.10.2015, 19:56

[Iron Bug]

ну, тогда гипотетически тебе нужен автомат с N-факториал состояниями, где N - количество возможных положений всех устройств. но в этом случае сама суть конечного автомата будет дискредитирована. он на то и конечный, чтобы от N! избавиться. впрочем, если там не слишком много устройств, то, может, это и реализуемо. но обычно всё-таки система имеет начальное состояние и работа начинается с него.

[Litkevich Yuriy]

Дело не в том какой автомат мне нужен, а в:

В практике программирования автоматов обычно из одного состояния в другое можно перейти только по событию, в частности в QStateMachine реализовано так же.

Проблема:
Т.к. физическая система находится в неком стабильном состоянии, то и событий в ней не происходит.
Как заставить автомат перейти в некое состояние минуя, возможно, многие другие?

Т.е. пытаться искусственно генерить цепочку событий?

[Iron Bug]

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

[ahalaj]

...
тебе лучше поискать другую реализацию или вообще самому написать то, что тебе нужно.

Насчёт "самому написать то, что тебе нужно". Я думаю что это или это (у второго уши растут из первого) вполне можно использовать чтобы уловить основной принцип. Хотя это и на C#, но в качестве отправной точки IMHO вполне подойдёт. И наверное реализация Simple State Machine поменьше чем QStateMachine, и к тому же Simple State Machine реально работает, я лично видел использование в нескольких проектах (не моих и без исходников, найдено было путём реверсинга тех самых проектов, сейчас просто вспомнилось в процессе чтения этого треда).

Сообщение отредактировал ahalaj - 1.11.2015, 12:39

[Iron Bug]

по-моему, это как раз примеры сферического программирования в вакууме. то есть, чисто софтварные теоретические навороты.
с железом всё куда сложнее и его не получится впихнуть в такую идеальную систему, где всё строго упорядочено. поэтому для реальных систем заранее готовых библиотек не бывает. можно что-то взять за основу, но дорабатывать под свою специфику всё равно придётся.

[ahalaj]

по-моему, это как раз примеры сферического программирования в вакууме. то есть, чисто софтварные теоретические навороты.
с железом всё куда сложнее и его не получится впихнуть в такую идеальную систему, где всё строго упорядочено. поэтому для реальных систем заранее готовых библиотек не бывает. можно что-то взять за основу, но дорабатывать под свою специфику всё равно придётся.

Позвольте. Я же сказал что

к тому же Simple State Machine реально работает, я лично видел использование в нескольких проектах (не моих и без исходников, найдено было путём реверсинга тех самых проектов

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

[Iron Bug]

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