Особенности организации управляющей программы, работающей в реальном времени

Поясним, что обозначает понятие "режим реального времени".

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

Пример 1. При перемещении подвижной части объекта управления, сработал датчик, сигнализирующий о скором достижении этой подвижной частью крайнего положения, далее которого двигаться нельзя. Программа должна в ответ выключить соответствующий привод (или может быть переключить его на обратный ход для быстрого торможения) – задержка может грозить поломкой.

Пример 2. Наступил заранее предопределенный момент времени (о чем сигнализировал входящий в состав контроллера таймер). Программа должна провести измерение некоей величины, характеризующей состояние объекта и сформировать (если требуется) нужное управляющее воздействие.

Отметим особенности, характерные для приведенных примеров.

1) Время реакции программы на наступившее событие не должно быть слишком большим, иначе качество регулирования сильно ухудшится, (возрастет риск повреждения объекта из-за выхода подвижной части за допустимую границу; измерение будет произведено с большим запаздыванием, что приведет к ухудшению точности и т.п.)

2) Интервалы времени между наступлением отдельных событий могут быть заранее неизвестны, либо могут быть весьма малыми.

3) "Плотность" событий во времени может сильно варьировать, т.е. в отдельные периоды события могут происходить часто, а в другие периоды редко. Это приводит к тому, что в периоды "повышенной" интенсивности событий программа, будучи занятой обработкой одного события, отреагирует на последующие с задержкой, в то время, как в периоды пониженной активности объекта программе будет "нечего делать".

Отмеченные особенности обусловливают структуру построения управляющей программы, которая состоит в следующем. Для реакции на каждое событие пишутся отдельные программные фрагменты (модули, функции), сравнительно независимые друг от друга. Затем каким-либо способом организуется "мониторинг" состояния объекта, т.е. выявление наступающих событий. Если какое-либо событие наступило, вызывается соответствующий, программный модуль, который организует формирование управляющего действия, после чего вновь происходит возврат к анализу состояния объекта. Выявление событий программа может осуществлять либо 1) путем принудительного периодического опроса соответствующих источников информации (датчиков), либо 2) реагировать на события по мере их возникновения, используя механизм аппаратных прерываний от сигналов тех же датчиков.

Построение управляющих программ требует наличия в микроконтроллере:

1) развитой системы прерываний с малым временем реакции на запросы и с развитыми возможностями программного управления прерываниями (запрет-разрешение отдельных запросов, изменение приоритетов и т.п.).

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

Порядок проектирования и обоснование выбора технических решений

Обычно принято думать, что основой для проектирования микроконтроллера является “хорошо” сформулированное техническое задание. На практике такие случаи крайне редки. Процесс проектирования является обычно сложным взаимодействием между двумя сторонами, которые мы в дальнейшем будем обозначать словами “ Заказчик ” и “ Разработчик ”.

Начальным этапом является интуитивное осознание Заказчиком необходимости решения какой-либо (новой) задачи. На этом этапе Заказчик обычно не только плохо представляет, какими средствами можно решить задачу, но и весьма приблизительно (лишь в общих чертах) может описать сущность задачи.

Уточнение задачи всегда происходит во взаимодействии Заказчика и Разработчика. При практическом проектировании выбор тех или иных технических решений входит в обязанности разработчиков на всех уровнях - от руководителя проекта до рядовых исполнителей, поэтому учащимся надо представлять особенности этого взаимодействия.

Общий принцип принятия решений при проектировании: максимизация эффекта при минимизации затрат. Естественными единицами и для того и для другого являются конечно денежные единицы. Однако на начальных стадиях проектирования весьма трудно количественно определить сколько-нибудь точно как эффект так и затраты. В большинстве случаев единственно конструктивной (т.е. приводящей к какому-то результату) является экспертная оценка, даваемая специалистами - разработчиками и системными аналитиками на основании их предшествующего опыта разработки.

Заказчик стремится получить систему с максимумом выполняемых функций по минимальной цене. Обычно он формулирует требования к системе на языке (жаргоне) своей предметной области.поэтому существенным оказывается преодоление барьера непонимания. При формулировке задания Заказчик чаще всего недостаточно ясно представляет себе в деталях, как должна вести себя будущая система. Кроме того почти всегда Заказчик описывает только алгоритмы “штатного” поведения системы и в недостаточной степени определяет, как система должна реагировать на нештатные ситуации. Количество возможных нештатных ситуаций бесконечно велико, поэтому все их в принципе не удастся обработать, но принятие определенного решения в этом вопросе может изменить (обычно в сторону увеличения) требования к необходимым ресурсам. Наконец, Заказчик редко отчетливо представляет возможности, предоставляемые микроконтроллерной техникой и не учитывает особенностей конкретных компонентов, которые в одних случаях облегчают, а в других наоборот затрудняют реализацию отдельных функций, необходимых Заказчику.

Разработчик всегда стремится снизить как свои трудозатраты так и затраты ресурсов. Естественный путь к этой цели - проранжировать все требуемые Заказчику функции по отношению “эффект/затраты” и реализовать в первую очередь наиболее дешевые и эффективные. Такое ранжирование может быть выполнено только в процессе тесного взаимодействия между Разработчиком и Заказчиком, так как Разработчик может верно оценить затраты ресурсов, требуемые для реализации отдельных функций, в то время как Заказчик способен определить относительную значимость этих функций.

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

Вы должны построить не ту систему, о которой вас просит Заказчик, а ту, которая ему действительно нужна!