Сложные программы Опции

[Буратино]

Доброго времени! Всех с НГ!

Занимаюсь созданием приборов с микроконтроллерным управлением. Ничего эдакого, как говорит ЛИ "автоматизация курятников". Из последнего у меня получилось 32К на Си. Освоил и пользуюсь методами из теории конечных автоматов. Сообщения, таймеры много канальные программные.
Однако новые требования заказчиков, косяки в архитектуре ПО и некоторые другие факторы вынуждали меня что то править, что то и вовсе переписывать. Это вылилось в трудно модифицируемую систему с костылями и тп хренью.
С нового года я работаю над еще более сложным прибором и понимаю, что так как было делать нельзя. Смотрю в сторону объектно ориентированных принципов построения ПО, а также подумываю над идеями из теории ОС.
Как вы решали свои задачи, что можете посоветовать посмотреть-почитать? Спасибо!

[syoma]

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

Что касается архитектуры ПО для системы управления, то у меня сложилась следующая архитектура, которую я реализовал не в одном успешном проекте:
К основным модулям данной архитектуры относятся: I/O менеджер, управляющй процесс, менеджер коммуникаций, логгер.

Задачей I/O менеджера является абстрагирование железа от остального ПО. Т.е он должен преобразовывать сигналы, получаемые от физических интерфейсов во внутренние "виртуальные" сигналы, которые затем будут использоваться управляющим процессом и менеджером коммуникаций. Под сигналами я понимаю состояния входов, измерения, команды на включение чего либо, статусные сигналы и т.д. Т.е смысл I/O менеджера в том, чтобы остальному ПО было наплевать откуда появляется нужный сигнал и куда он уходит. Сегодня это может быть пин А, завтра пин B, а послезавтра пин на слейве в Modbus RTU или SPI - все это должно конфигурироваться на данном уровне и только на нем. Также тут можно делать простые действия над сигналами - инвертировать, масштабировать. Неплохой функцией является возможность "подменить" значение какого либо сигнала на свое во время исполнения программы, чтобы упростить отладку. I/O менеджер должен работать в жестком реальном времени, с теми же циклами, что и управляющий процесс, поэтому важно его оптимизировать, чтобы он не занимал много процессорного времени.

Управляющий процесс - это сердце вашей системы. Он исполняет все управляющие алгоритмы, которые нужны в данной задаче - автоматы состояний, алгоритмы управления теплицей, курятником, турбиной и пр. Благодаря I/O менеджеру все выходы и входы управляющего процесса будут внутренними переменными, следовательно вы легко сможете изменять свои алгоритмы без необходимости изменять весь проект. Также это значительно упрощает повторное использование алгоритмов и функций, так как они становятся аппаратно-независимыми. Еще раз, важно - никакой непосредственной связи с железом в управляющем процессе. Управляющий процесс опять же исполняется в реальном времени в связке с I/O менеджером. Возможно иметь несколько управлящих циклов, работющие в многозадачном шедулере - самые быстрые с временем исполнения <1мс - например для различных защит, основные 10-100мс - где исполняются основные алгоритмы, медленные 100мс-1с - выборы режимов работы.

Управлящий процесс и I/O менеджер - это два модуля, работающих в реальном времени. Менеджер коммуникаций - уже нет. Его задачей является предоставление доступа различным нереалтаймовым интерфейсам типа HMI, HTTP , файловой систеы к виртуальным переменным I/O менеджера. Это собственно Scada интерфейс.

Логгер - подсистема, взаимодействующая с I/O менеджером и служащая для постоянной записи изменеий всех или выборочных виртуальных сигналов в лог-файл для следующей диагностики.

Приведенная архитектура возможно слегка сумбурна, так как по определенным соображениям не могу привести картинки - спрашивайте, если что не понятно. Как ее реализовывать - это уже дело каждого. Например ПЛК реализуют почти все из этой архитектуры, но на МК возможно вы на чем-то сэкономите. В простых системах все можно сделать даже без ОС, но в более сложных она понадобится. В самых высокопроизводительных системах, как у нас, вообще используется мультипроцессорная архитектура, а I/O менеджер частично реализован на ПЛИС.
Для разработки и отладки управляющего процесса при использовании данной архитектуры идеально подходит т.н. Модельно-ориентированный подход, реализованный, например, на Matlab/Sumulink. Тогда вы сможете сконцентрироваться на решении задачи, а не ее программировании. А все остальное за вас сделает программа, включая генерацию кода.
I/O менеджер в простейшем случае будет представлять shared memory, где хранятся различные переменные. А к этой памяти уже обращаются и драйверы и управляющий процесс. В сложных системах со многими сигналами это уже будет что-то наподобии быстрой базы данных.
Конечно, 8-и битник для всего этого слегка слабоват, так как такая архитектура имеет серьезный оверхед, но начиная с простого АРМ 32-х битника она уже легко позволяет получать циклы в 10мс на сотне-другой I/O сигналов.

[iosifk]

Буратино, я думаю, что ваша проблема в том,...

Вот это все было бы хорошо оформить в виде статьи!
Пусть она будет небольшая, но тем не менее...
Прямо так и начать: "В конференции шло обсуждение... И мое мнение таково..."
И к нам, в КиТ...
Что скажете?