Технология разработки программного обеспечения
В настоящее время существует несколько технологий разработки программного обеспечения реального времени. Среди них можно отметить технологию функционально-модульногоописания [61], технологию представления архитектуры программного обеспечения в видеграфа состояниясистемы [4], технологиюзадачи/состояния [69], универсальный язык моделированияUML(Universal Modeling Language) [63]. Технология задачи/состояния имеет некоторые общие элементы с более формальной технологией UML, но значительно проще. Выбор той или иной технологии определяется пристрастиями разработчика, сложностью разрабатываемого проекта, наличием соответствующего инструментария.
Основу программного обеспечения встроенных систем (систем работающих в реальном времени) образует операционная система реального времени (ОС РВ). Основная единица работы ОС РВ – задача. Операционная система поддерживает и организовывает выполнение всех задач, а также управляет прерываниями.
В соответствии с ориентированием технологии задачи/состояния на данное представление и в силу ее простоты остановимся на ее рассмотрении.
Технология задачи/состояния
Встраиваемые системы для обеспечения реального масштаба времени используют разнообразные прерывания. Использование прерываний делает систему многозадачной – каждое прерывание можно рассматривать как отдельную задачу. Процесс представления программной части в виде структуры задачи/состояния – основная деятельность в проектировании программного обеспечения в реальном масштабе времени. Процесс не однозначен. Для одной и той же системы возможно несколько вариантов разбиения.
Первый этап – задачи
Разбиение проектируемого программного средстваназадачиявляется первым этапом получения модулей при модульном проектировании. Набор задач представляется в видедиаграммы.
Так как задачи описывают состояния физических систем, для которых свойственен параллелизм, то отдельные задачи могут быть активны одновременно.
При составлении диаграммы задач следует придерживаться принципа иерархии – задачи одного уровня располагаются в ряд, задача, как правило, должна быть связана только с задачами соседних уровней: по возможности с одной задачей предыдущего и одной задачей последующего уровней.
Диаграммы начинаются на самом низком уровне с технических средств, к которым непосредственно подключена система управления. Эти технические средства обычно состоят из датчиков и исполнительных механизмов. На следующем уровне могут быть включены конкретные устройства обработки данных (рис.5.2). Их включение позволит при необходимости легче осуществить перераспределение функций между аппаратными средствами и программным обеспечением (например, прямая обработка квадратурных сигналов от оптического кодирующего устройства вместо использования декодера из набора аппаратных средств).
Следующий уровень – самый низкий уровень программного обеспечения. На этом уровне оно обычно непосредственно связано с аппаратной частью системы.Все задачи, которые имеют прямой контакт с аппаратными средствами, должны быть помещены на этом уровне. Характер следующих уровней зависит от приложения. Большая часть творческого потенциала проектирования идет на определение этой организации.
Рис.5.2. Диаграмма задач управления объектом
Особенностью диаграммы задач, приведенной на рис.5.3, является непосредственная связь интерфейса оператора с аппаратной частью. Такая ситуация возникает при жестких временных требованиях к реакции системы на действия оператора, например, чтение показаний быстро вращающегося диска оптического датчика положения непосредственно программным обеспечением. Если для этой цели использовать специальные аппаратные средства, позволяющие снизить требования к реакции системы на действия оператора, то задача интерфейса пользователя может быть помещена на верхний уровень иерархии (как на рис.5.2).
Рис.5.3. Диаграмма задач управления объектом, где задача пользовательского интерфейса непосредственно связана с аппаратными средствами
На рис.5.4 представлена часть диаграммы задач при обработке прерываний от встроенного контроллера последовательного обмена (UART) с передачей данных в пользовательский процесс. Обработчик прерываний от последовательного порта представляет собой отдельную задачу, запускаемую асинхронно (по приходу прерывания) от пользовательского процесса.
Рис.5.4. Диаграмма задач последовательного обмена
Рис.5.5. Диаграмма задач со схемой их взаимодействия
Диаграмму задач удобно изображать со схемой взаимодействия. Так на рис.5.5 представлена часть диаграммы задач последовательного обмена, аналогичная рис.5.4, но со схемой взаимодействия. На ней отражены конкретные задействованные регистры контроллера UART(SBUF), флаги прерыванийRIиTI, буферы обмена между задачами WFIFO иRFIFO, а также API-функции (чтения байта из последовательного канала и записи байта в последовательный канал).
Управление обработчику прерывания передается тогда, когда UART либо готов к передаче очередного байта (TI=1), либо принял байт из канала (RI=1).
Второй этап – состояния
Представление каждой из задач в виде последовательности состоянийявляется вторым этапом получения модулей при модульном проектировании.
Состояния описывают определенные действия в пределах задачи; в какой-либо момент времени только одно состояние может быть активно. Активное состояние управляет текущей деятельностью данной задачи. Если задача, например, управляет двигателем, то состояния в пределах этой задачи могли бы соответствовать выключенному двигателю, двигателю, работающему с постоянной скоростью, замедлению двигателя до остановки и т.д. Типичные действия, связанные с состояниями:
перемещение;
ожидание;
обработка;
вычисление;
измерение.
Каждое состояние должно быть связано с четко определенной деятельностью. Когда эта деятельность заканчивается, происходит переход к новой деятельности. Возможно любое число переходов к состоянию и из состояния. Каждый переход связан с определенными условиями. Например, условием для перехода из состояния перемещения может являться достижение конца перемещения; возникновение нештатной ситуации типа остановки; чрезмерно большие ошибки перемещения.
Последовательность состояний и переходов между ними может быть представлена:
в форме графа;
в форме таблицы.
При представлении задачи в форме графа состояния показываются вершинами в виде окружностей, переходы – направленными дугами от одного состояния к другому. Описание состояния дается внутри каждой окружности, переходы помечаются условиями, которые их определяют. Графическое описание является хорошим средством визуализации. Если задача достаточно компактна и граф состояний помещается на одной странице, то графическое описание делает ее ясной для понимания и легко читаемой.
На рис.5.6 приведен пример графа состояния задачи обмена по UART.
Рис.5.6. Граф состояний для задачи обмена по UART
Табличная форма эквивалентна графу и более компактна. Она может применяться при описании сложных задач, когда граф состояния трудно читаем. Кроме того, табличная форма легко подключается к процессу автоматизированного проектирования.
Общая форма для представления состояния следующая:
Название состояния [описательный комментарий]
переход к i-му состоянию; условие перехода [комментарий]
переход к k-му состоянию; условие перехода [комментарий]
Третий этап – алгоритм состояния
На третьем этапе отдельные состояния представляются в виде или блок схемы, или в видеформальной структуры функций. В последнем случае для каждого состояния определены следующие функции:
Рис.5.7. Алгоритм функционирования состояния
вход – выполняется один раз при входе в состояние;
действие – выполняется при каждом просмотре состояния;
проверка – выполняется после функции действия при каждом просмотре состояния.
Блок-схема алгоритма выполнения состояния представлена на рис.5.7.
Функция входа выполняется только при первом входе в состояние. При последующих входах в состояние данная функция не выполняется, ее задача – инициализация состояния.
Функция действия выполняется всегда.
Далее выполняются функции проверки перехода из состояния. При выполнении соответствующего условия перехода, выполняется функция выхода, указывается следующее выполняемое состояние и флаг входа в состояние. Флаг указывает на то, что состояние уже выполнялось более одного раза.
Данный алгоритм является общим, в конкретной реализации могут отсутствовать функции входа, функции выхода и т.д.
Представление состояний в виде формальной структуры позволяет организовать параллельное выполнение задач даже в отсутствие какой-либо конкретной многозадачной операционной системы или диспетчера: можно организовать циклическое переключение задач без вытеснения (задача владеет ресурсом до тех пор, пока не завершится). Единица выполнения задачи – одно состояние. При переключении на очереднуюактивнуюзадачу осуществляется вход в состояние, определенное в предыдущем цикле выполнения задачи. Если это первый проход для текущего состояния, выполняетсяфункция входа,затем выполняетсяфункция действияи далеефункция проверки перехода. При переходе выполняется соответствующаяфункция выходаи осуществляется задание нового состояния для следующего переключения на задачу. После окончания просмотра всех задач снова осуществляется переключение на первую задачу. Такой метод диспетчеризации, называемый совместным мультиуправлением задачами, приемлем, если время полного просмотра всех задач достаточно короткое, чтобы удовлетворить временным ограничениям системы.
Последний этап – написание кода.
Далее рассмотрим особенности проектирования многозадачных систем, каковыми и являются системы реального времени.