ЦЕЛИ КУРСОВОГО ПРОЕКТИРОВАНИЯ
Целью курсового курсовой работы является формирование у студентов навыков проектирования и программирования систем реального времени (СРВ) на основе теоретических и практических знаний, полученных в курсах «Операционные системы» и « Технологии программирования». В ходе выполнения курсовой работы, необходимо проанализировать функции, которые должна выполнять СРВ, выполнить проектирование СРВ как совокупности взаимодействующих задач, определить вычислительную технологию и реализовать СРВ в виде управляющей программы, отладить СРВ.
СТРУКТУРА КУРСОВОЙ РАБОТЫ
Дальнейшее изложение методики выполнения работы будет опираться на структуру пояснительной записки (ПЗ), примерное содержание которой приведено в приложении А. ПЗ состоит из следующих разделов:
ВВЕДЕНИЕ
Введение является первым пунктом пояснительной записки. Во введении приводятся краткие теоретические сведения по предмету дисциплины «Cистемы реального времени» и запланированные основные этапы выполнения данной курсовой работы (КР).
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Задание на выполнение КР выдаётся по вариантам. В исходном виде задание представляет собой функциональную схему, описывающую проектируемую СРВ. Вариант задания приведён в приложении Б. На данном этапе выполнения КР необходимо познакомиться с описанием блоков функциональной схемы, проанализировать функции выполняемые СРВ, согласно этой схемы, и сформировать техническое задание на разработку программной части СРВ. Неуказанные в исходном задании характеристики и параметры принять по согласованию с преподавателем. Необходимо выделить следующие пункты:
Назначение ( учебное задание )
Тип и количество входов и выходов СРВ
Временные параметры (по согласованию с преподавателем)
Описание работы СРВ
ЭТАПЫ РАЗРАБОТКИ СРВ
Согласно принятой модели, разработка СРВ включает следующие основные этапы:
1. Техническое проектирование системы – описание процесса управления как совокупности взаимодействующих процессов. Осуществляется на основе изучения и моделирования объекта управления (ОУ). Техническое описание является программно – независимым, то есть не связанным с любыми аспектами её программной реализации.
2. Проектирование на основе вычислительной технологии - реализация результатов технического проектирования в виде конкретных программно – аппаратных средств, позволяющих обеспечить требуемые технические характеристики с учётом существующих ограничений.
Структура пояснительной записки КР соответствует этим этапам.
ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ СРВ
В связи с учебным характером СРВ в КР не включаются этапы исследования, описания или моделирования ОУ. Вся необходимая информация формируется на этапе технического задания.
Техническое проектирование включает подразделы:
-Разработка диаграммы задач
-Разработка структуры состояний задач
РАЗРАБОТКА ДИАГРАММЫ ЗАДАЧ
Задача – это часть процесса управления, протекающая одновременно с другими аналогичными частями. Задачи являются независимыми, но связаны между собой каналами передачи данных, для обеспечения управления объектом вцелом.
Можно выделить следующие условия выделения задач:
-ОУ имеет несколько отдельно управляемых частей;
-в процессе управления есть несколько явно выраженных функций;
-управление разделено на несколько уровней иерархии;
-управляющие действия имеют различный характерный масштаб времени;
- в процессе управления необходимо ожидать некоторого условия, не прекращая управления другими процессами ОУ.
На данном этапе разработки необходимо:
-выделить и обозначить (задать имя и числовой идентификатор) каждую задачу;
-определить функции выполняемые каждой задачей;
-определить какие данные являются входными и выходными для каждой задачи;
-определить на каком уровне иерархии находится задача и как она связана с другими задачами системы;
-определить качественно, как часто должна выполняться задача и сколько машинного времени она будет потреблять.
В графической форме перечисленные выше пункты должны быть представлены в виде диаграммы задач – структурной схемы, содержащей обозначения задач и взаимосвязей между задачами. Все взаимосвязи должны быть обозначены и описаны. Также должны быть показаны связи с аппаратными средствами ОУ (входы и выходы). Пример диаграммы задач показан на рисунке 1.
Рисунок 1- Диаграмма задач СРВ.
Две специально обозначенные задачи I/O и OP должны присутствовать на диаграмме в обязательном порядке. Они отвечают за следующие функции:
- OP – (OPerator) Интерфейс оператора, задача отвечающая за вывод визуальной информации и ввод команд управления СРВ;
- I/O – Задача отвечающая за ввод/вывод сигналов в/из ОУ. Эта задача обеспечивает обмен с устройством связи с объектом (УСО), не показанную на схеме. Данная задача может отсутствовать, если все остальные задачи осуществляют операции ввода – вывода напрямую. Кроме того задача I/O может использоваться для моделирования, в отсутствие соответствующего ОУ. Часто удобно разделять задачу I/O на две задачи: задачу ввода сигналов (I), выполняющуюся в начале цикла, и задачу вывода сигналов (O) выполняющуюся в конце цикла.
Аппаратные средства ОУ могут быть представлены несколькими блоками, например датчик конечного положения подключённый к двоичному входу или ШИМ преобразователь, управляемый двумя выходами: двоичным выходом направления и импульсным выходом величины сигнала.
Разработка структуры состояний задач.
Многие задачи СРВ могут быть структурированы в соответствии с моделью состояний.
Состояние – это часть задачи, выполняемая при определённых условиях. Только одно состояние задачи является активным в данный момент времени. При изменении условий, задача может перейти в другое состояние.
Состояние ZI определяется:
- действиями выполняемыми постоянно, пока состояние активно - DI;
- условиями переходов в другие состояния - GI,J;
- действием при входе в состояния - EI;
- действием при выходе из текущего состояния в некоторое N-ное состояние – LI,N.
Некоторые элементы, перечисленные выше, могут отсутствовать.
При выполнении данного раздела работы необходимо:
1. Проанализировать задачи выделенные на предыдущем этапе и определить какие из них имеют структуру состояний;
2. Проанализировать, как работает управляемая данной задачей часть ОУ или в чём заключается функция процесса управления, реализованная в данной задаче;
3. Определить количество состояний;
4. Выявить действия в каждом состоянии, например: расчёт, формирование сигнала, обработка сигнала, ожидание события;
5. Определить условия переходов из каждого состояния;
6. Определить действия выполняемые однократно при переходах.
В графической форме структура состояний должна быть представлена как показано на рисунке 2.
где cond I – условие перехода.
Рисунок 2 – Структура состояний СРВ
Обязательное состояние с идентификатором 0 и именем InitState обозначает начальное состояние. Из этого состояния выполняется безусловный переход в любое другое состояние. Данная диаграмма должна быть дополнена описанием действий DI, EI, LI, N для каждого состояния.
В КР для каждой задачи, имеющей структуру состояний, должны быть разработаны и приведены в ПЗ:
- алгоритм задачи в текстовой форме;
- описание структуры в текстовой форме;
- структура состояний в графической форме;
- Описание действий в каждом состоянии в табличной форме.
Для задач не имеющих структуры состояний, в ПЗ приводится алгоритм и описание на языке псевдокода или неформализованное текстовое описание.
Проектирование интерфейса СРВ.
Интерфейс оператора (пользователя) служит для организации взаимодействия между человеком и системой управления (ОУ). В зависимости от назначения и функций СРВ может быть использован интерфейс оператора различного типа:
- Командный интерфейс. Для отображения информации используются символьные буквенно-цифровые сообщения. Вводимые команды и параметры также представляют наборы символов. Используется алфавитно-цифровой дисплей и клавиатура. Для временного или удалённого подключения к системе может использоваться последовательная линия. Командный интерфейс требует мало ресурсов процессора, ПОРВ на его основе обладают высокой мобильностью.
- Графический интерфейс. Для отображения информации используется как текстовые, так и графические элементы. Для управления используется клавиатура в сочетании с устройством указания. Как правило применяется цветной графический дисплей высокого разрешения с сенсорной панелью. Графический интерфейс требует большое количество ресурсов и затрудняет перенос ПО на другую аппаратную платформу.
- Приборный интерфейс. Информация отображается с помощью дискретных цифровых шкал, световых индикаторов и.т.п. Ввод команд производится с помощью тумблеров, переключателей, верньеров и.т.п. Требует мало ресурсов. Является специализированным.
- Специальный интерфейс. Ввод и вывод информации производится через специальные органы управления. Пример – штурвал самолёта или руль автомобиля. Применяется в специальных условиях.
В КР должен применяться в основном графический интерфейс, (допускается командный), так как это не требует разработки специальных аппаратных устройств ввода вывода.
При описании в ПЗ пользовательского интерфейса должны быть приведены иллюстрации экранных форм, снабжённые подробным описанием элементов интерфейса и порядка работы пользователя с интерфейсом.
Определение временных параметров задач.
Для каждой задачи составляющей СРВ необходимо определить временные параметры.
К таким параметрам относятся:
- минимально допустимая частота выполнения (просмотра, активации) задачи;
- максимально допустимое время между событием и началом (завершением) его обработки;
- Процентное распределение машинного времени между задачами.
Пример: Задача СРВ должна подсчитывать координату подвижного узла измеряемую с помощью импульсного датчика положения, имеющего дискретностью Dsk = 0.1 мм, тоесть формирующего 10 изменений сигнала на 1 мм перемещения узла. Узел движется со скоростю V=100 мм/с. Изменение значения координаты производится в момент регистрации изменения входного сигнала с 0 на 1 и с 1 на 0. Регистрация производится путём опроса разряда специального регистра УСО. Таким образом, время между опросами должно быть меньше, чем интервал времени между изменением сигнала датчика, равное
T=0.001 с. Принимая допустимую погрешность времени активации задачи ?T=0.2 мс, получим
минимально допустимую частоту выполнения задачи fЗ= 1250 гц. Максимально допустимое время обработки 0.8 мс. При этом все 100% ресурсов системы будут заняты задачей подсчёта координаты.
В КР требуется оценить временные параметры задач, непосредственно связанных с реакцией на входные сигналы и генерацией выходных сигналов.
Проектирование на основе вычислительной технологии.
На данном этапе необходимо перейти от системо - независимого представления процесса управления в виде задач, к конкретной реализации СРВ, определяющей её эксплуатационные характеристики.
Выбор аппаратной архитектуры.
При разработке архитектуры СРВ определяются:
1. Количество вычислительных устройств (ВУ) и специализированных аппаратных средств ;
2. Тип каждого ВУ;
3. Задачи, которые будут выполняться на каждом устройстве;
4. Дополнительные задачи, необходимые для связи отдельных частей аппаратной платформы.
В КР рекомендуется одна из двух архитектур:
1. Одно ВУ – компьютер – используется для решения всех задач управления в СРВ;
2. Два ВУ – компьютера. Компьютер №1 используется для решения всех задач управления, кроме интерфейса оператора. Компьютер №2 используется для реализации интерфейса оператора. В состав задач каждой вычислительной системы должны входить задачи обеспечивающие коммуникацию двух компьютеров по сети или другому последовательному каналу связи.
Выбор аппаратной архитектуры определяется:
- требуемыми временными параметрами задач;
- массо-габаритными показателями;
- специальными условиями работы;
- стоимостью аппаратных средств;
- затратами на разработку ПО.
В КР необходимо обосновать выбор архитектуры. При выборе архитектуры с двумя ВУ, должен быть определён канал связи и средства обмена информацией между задачами разных ВУ.
Выбор базового ПО и инструментальных средств
В качестве базового ПО в КР используется ОСРВ QNX / 2 /. Эта ОСРВ построена по принципам высоконадежной архитектуры на основе микроядра и четко детерминированного механизма обмена сообщениями, в том числе для взаимодействия процессов по сети.
В состав QNX входит также графическая оболочка Photon microGUI для построения встраиваемых приложений с графическим интерфейсом пользователя.
Инструментальные средства включённые в состав пакета QNX MOMЕNTICS включают : редактор, отладчик, в том числе для удалённой отладки, средства построения встраиваемых систем, различные анализаторы, средства разработки интерфейса пользователя, средства управления версиями, и конечно компиляторы с различных языков высокого уровня. В QNX одним из основных языком программирования является язык C.
Данные инструменты могут быть использованы могут быть использованы как из интегрированной среды разработки, так и как обычные инструменты с командным или графическим интерфейсом.
В КР рекомендуется использовать:
- компилятор с языка C – gcc;
- утилита make;
- отладчик gdb;
- редактор ws;
- Инструмент для визуальной разработки графического интерфейса PhAB;
Выбор модели процессов-потоков
Каждая задача должна выполняться во времени параллельно . Такого результата можно добиться несколькими способами:
1. Задача выполняется эксклюзивно на одном ВУ;
2. Задача выполняется совместно с другими задачами в рамках одного потока;
3. Задача выполняется в отдельном потоке но в рамках одного процесса;
4. Задача выполняется в отдельном процессе;
Если задача выполняется в отдельном потоке, возможны следующие варианты активации потока:
1. Задача активируется по времени. Используются аппаратные или программно – аппаратные таймеры вычислительной платформы;
2. Задача выполняется независимо, как отдельный поток в рамках многозадачной ОСРВ, подчиняясь выбранной дисциплине диспетчеризации и в соответствии с заданным приоритетом.
3. Задача является обработчиком прерывания и вызывается в при возникновении внешнего прерывания.
Для определения модели процессов – потоков, необходимо проанализировать временные параметры каждой задачи и определить основной способ диспетчеризации, а также в его рамках способ активации каждой задачи.
В КР в данном разделе необходимо обосновать выбор модели процессов – потоков и привести указанную информацию по каждой задаче. Должна быть представлена графическая схема взаимодействия задач.
В качестве базовой, рекомендуется следующая модель потоков – процессов:
Задачи, непосредственно участвующие в процессе управления реализуются совместно / 3 /, в одном потоке. Задача интерфейса оператора реализуется в виде отдельного процесса, обменивающегося данными с остальными задачами с помощью системного процесса MQUEUE. Графическая схема представлена на рисунке 3.
Рисунок 3 – Рекомендуемая в КР модель процессов – потоков
Разработка ПО РВ
Программирование СРВ включает в себя:
- определение архитектуры СРВ как совокупности программ и системных процессов;
- определение модульной структуры основной программы, реализующей задачи СРВ;
- спецификация модулей основной программы.
Архитектура СРВ должна соответствовать разработанной на предыдущем этапе модели потоков – процессов. Должны быть перечислены исполняемые файлы, составляющие СРВ, аргументы командной строки запуска каждой программы. Описывается порядок запуска и взаимодействие ( механизмы и особенности) программ в составе СРВ.
Модульная структура СРВ для задач выполняемых в едином потоке, как правило включает головной модуль верхнего уровня и по одному модулю на каждую задачу в данном потоке.
Спецификация модулей СРВ может быть представлена в следующей табличной форме:
Таблица 2 – Спецификация модулей СРВ
Модуль/задача |
Файлы |
Функции |
Переменные |
Используются в модуле |
Имя |
Чт/з |
Имя |
Чт/з |
головной |
main c |
- |
work |
чт. |
trace |
зап. |
Задача 1 |
task.c task1.h |
Task1() |
V 1 char, V3 int |
чт. чт. |
Задача 3 Задача 2 |
зап. зап. |
Задача 2 |
task2.c task2.h |
Task2() |
V4 float, V6 int cmd struct WM disp struct RM |
чт. чт. зп чт. |
Задача 3 Задача 4 - - |
зап. зап. - - |
Задача 3 |
task3.с task3.h |
Task3(), InitTask3 (a char) |
V2 struct E |
чт. |
Задача 1 |
зап. |
Задача 4 |
task4.c task4.h |
Task4() |
V5 unsigned char |
чт/зап |
Задача 3 |
чт/зап |
I/O |
|
IOTask.c, IOTask.h |
inbuf[3] char
outbuf[3] char |
зап. чт. |
Задача 3 outbuf[1]
Задача 1inbuf[1], Задача4 inbuf[2] |
чт. зап. зап. |
В КР в данном пункте должны быть описаны также все используемые типы и структуры данных, а также не описанные ранее процедуры и функции.
Отладка ПО РВ
Под отладкой ПО РВ, рассматриваемой в данном разделе ПЗ, будем понимать проверку правильности взаимодействия задач, проверку правильности логики переходов внутри задач, а также установление соответствия ПО РВ определённым в задании, временным соотношениям на основе испытаний ПО РВ в моделируемой или реальной среде.
Эти задачи решаются на основе протоколирования перехода каждой задачи из состояния в состояние и фиксации времени каждого перехода. Данный механизм встроен в шаблон задачи со структурой состояния, вызовом функции logE (TaskID, State.NextState) в момент изменения состояния каждой задачи. Полученный файл протокола log.dat содержит числовую информацию в строковом формате. Функция logE определена в файле trace.h.
В дополнение к протоколированию переходов, можно добавить протоколирование любых других интересующих разработчика переменных. При этом для привязки к протоколу переходов, необходимо помимо рассчитанного значения, указывать время расчёта переменной.
В КР в данном пункте, необходимо привести данные протокола работы СРВ, подтверждающие правильность логики переходов. Напрмер для задачи ШИМ, можно построить график изменения сигнала на соответствующем двоичном выходе и рассчитать среднюю и максимальную погрешность ширины импульса.
Заключение
В заключении перечисляются основные этапы выполненной работы по конкретной теме и констатируется степень выполнения каждого этапа.
Список использованных источников
Содержит перечень учебной, справочной и периодической литературы, а также информационных ресурсов, которые использовались при подготовке КР и на которые есть ссылки в ПЗ.
Приложения
В качестве обязательного приложения должен быть приведён полный или частичный (по согласованию с преподавателем) листинг разработанных программ, а также исполняемые файлы, исходные тексты программ и другие материалы по КР на электронном носителе.
© Донской государственный технический университет, 2008 г.
|