[AlexandrY 3]

6 hours ago, andrey_p said:

Это просто говорит о разных подходах. Да, в текущих реалиях приходится подстраиваться под существующие ОС. Но я убеждён, что в идеале сервисы ОС должны быть сделаны на автоматах, а планировщик ОС заменён на автоматный процессор с поддержкой последнего на уровне железа. Об этом я и писал в статье. Но это ни в коем случае не говорит о том, что в текущих реалиях в обработчики action можно запихивать тяжеловесные вычисления. И зачем Вам инструменты профилирования, если расчёт времени выполнения цепочки action должен быть встроен в компилятор автоматов? А Вы уверены, что когда Вы занимаетесь профилированием, Вы проходите по всем возможным цепочкам?

Вы пилите свой велосипед и почему-то считаете что здесь тема об этом. 
Я не создаю автоматы и мои диаграммы не автоматы.  
Мне программирование автоматы не ускоряют и не облегчают, они сами получаются иногда как побочный продукт.
И что так приклеились к этому слову "автоматы"? 

Программирование облегчает среда разработки. Мне совершенно фиолетово конечный там автомат вдруг получился или бесконечный.
Все ли состояния обойдены или не все. Я даже не делаю полных тестов. Это невозможно с ограниченным бюджетом времени.  
Это не разработка под FPGA, это архитектура с неопределенностями. И Stateflow это позволяет сделать. 

[Segment 3]

1 час назад, AlexandrY сказал:

Я тут уже выкладывал, но ладно выложу еще раз. 

Простите, не видел эту публикацию. Огромное спасибо, на скриншоте в целом не очень хорошо видно, но проглядывается концепция. Есть ли возможность все-таки выложить проект, чтобы я например смог его полистать в матлабе? Компиляция не нужна, интересуют листы, хочется более детально посмотреть как Вы проектировали эту систему. Можно в личку.

[syoma 1]

On 4/23/2019 at 3:41 PM, AlexandrY said:

Весь проект не выкладываю потому как он много информации вам не даст. Нужно как минимум знать особенности  функционирования системы и ее состав. 
Тут еще загружается подготовленный workspace с переменными. Много внутренних переменных смысл которых вам будет непонятен, поскольку они берутся из фреймворка платформы. Ну и вся эта диаграмма опирается на сервисы платформы которые в самой диаграмме совершенно не описаны. 
Есть уровни ниже, как можно догадаться, в полупрозрачных блоках и есть выше. Выше стоит модель самого объекта управления, т.е. там симуляторы кнопок, конечников, датчиков, мотора, кинематики и т.д. 
Конечно это никакой не автомат состояний. Это типичная программа с множеством неопределенных состояний и с многочисленными вложениями чистого C или M кода.
Но только эта программа дает возможность ее реструктурировать за считанные  минуты, а в обычной текстовой нотации такая же реструктуризация занимает многие дни.  
Это живая архитектура совмещенная с кодированием. В этом сила метода.
    

Ну это в принципе и есть то о чем я говорил - реализация управляющего алгоритма управления лифтом, если я не ошибаюсь . Таким образом вы сможете отладить всю управляющую логику в модели у себя на компьютере без того, чтобы лазить и вылавливать баги на реальном объекте и полностью абстрагировавшись от железа. Кстати GUI не продемонстрируете? Это обычно более впечатляющее.

От проекта в личку тоже не отказался бы хотя бы самой машины. Я так понимаю, что events вы научились использовать. Не глючит?