Рефераты. Разработка системы реального времени в виде планировщика исполнения заданий

· Добавление задачи.

Планировщик принимает сообщение об активации задачи, и помещает в число готовых к запуску с учётом абсолютных и относительных ограничений. Добавляется запись в процесс-таймер.

· Изменение интервала выполнения задачи.

Принимается сообщение об изменении интервала. Если задача, для которой он должен быть измен, активна, то она приостанавливается. Интервал изменяется. Затем цикл вычислений продолжается, начиная с этой задачи.

· Изменение периода выполнения периодической задачи.

Планировщик принимает сообщение и посылает к процессу-таймеру сигнал на изменение метки времени, соответствующей данной задаче.

· Изменение времени реакции, времени выполнения или приоритета.

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

· Удаление задачи.

Задача завершает своё выполнение и посылает планировщику сообщение на удаление её из списка готовых к выполнению. Или планировщик удаляет задачу, вышедшую за пределы выделенного ей времени выполнения.

3.3. Реализация протокола ARINC A.415 на основе разработанного модуля СРВ.

3.3.1. Модель требований к системе.

3.3.1.1. Описательная модель.

Протокола A.415 ARINC, используется во встроенных системах реального времени самолётов ведущих авиаперевозчиков, таких как Airbus, McDonnel Douglas и др. Это протокол опроса бортовых устройств, позволяющий в заранее обозначенный промежуток времени получить от них информацию и сигнализировать о неисправности в оборудовании.

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

3.3.1.2. Модель случаев использования.

Данная модель представлена на рисунке 11.

У разрабатываемой системы будет 2 вида взаимодействий с «внешним окружением»: в Диалоговом режиме и в Обычном режиме. Диалоговый режим используется при взаимодействии с оператором в самолёте. Обычный режим используется при стандартной работе интерфейсной подсистемы по индикации неисправностей.

3.3.1.3. Функциональная модель.

Функциональная модель системы представлена в виде диаграмм 12 и 13.

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

В Диалоговом режиме система реализует следующие функции: получение сообщения от бортовой системы, отсылка сообщений к CFDIU, получение команд от CFDIU, переход в Нормальный режим.

3.3.2. Динамическая модель.

3.3.2.1. Модель объектов.

· Сообщение от бортовой системы.

Бортовая система - OMSI И Бортовая система - Энергонезависимая память

· Получить настройки из APM.

APM - OMSI

· Отправить отчет к CFDIU.

OMSI - Шина передачи данных - CFDIU

ИЛИ

General Format Manager

· Запуск диалогового режима.

CFDIU - Шина передачи данных - OMSI

· Начало работы.

Инициализация ИЛИ Тёплый старт

· General Format Manager.

Шина передачи данных - OMSI

· Получить команду.

Шина передачи данных - OMSI

· Инициализация.

OMSI - APM

· Тёплый старт.

Энергонезависимая память - OMSI И APM - OMSI

· Получить команду от CFDIU.

CFDIU - Шина передачи данных - OMSI

· Запуск Обычного режима.

CFDIU - Шина передачи данных - OMSI

3.3.2.2. Модель взаимодействий.

· Сообщение от бортовой системы.

OMSI начал работу. Бортовая система начала работу. Бортовая система сохранила сообщение о неисправности в Энергонезависимой памяти. Бортовая система отправила сообщение о неисправности.

· Получить настройки из APM.

OMSI начал работу. OMSI запросил настройки у APM. APM передало необходимые настройки.

· Отправить отчет к CFDIU.

CFDIU начал работу. OMSI начал работу. Шина передачи данных активна. OMSI проверил активность Шины передачи данных. OMSI отправил отчет. Шина передачи данных переправила отчет к CFDIU. CFDIU получил отчет.

ИЛИ

General Format Manager.

· Запуск диалогового режима.

CFDIU начал работу. OMSI начал работу. Шина передачи данных активна. CFDIU отправил команду ENQ. Шина передачи данных передаёт команду на нужный OMSI. OMSI переходит в диалоговый режим.

· Начало работы.

Инициализация ИЛИ Тёплый старт

· General Format Manager.

OMSI начал работу. Шина передачи данных неактивна. OMSI проверил активность Шины передачи данных.

· Получить команду.

Шина передачи данных активна. Шина передачи данных передаёт команду на OMSI. OMSI предпринимает действие в соответствии с командой.

· Инициализация.

OMSI размещение в памяти, инициализация переменных, запрос настроек. APM поиск и передача необходимых настроек.

· Тёплый старт.

OMSI размещение в памяти, инициализация переменных, запрос настроек. APM поиск и передача необходимых настроек. OMSI восстановление ранее передававшегося сообщения из Энергонезависимой памяти.

· Получить команду от CFDIU.

CFDIU начал работу. OMSI начал работу. Шина передачи данных активна. CFDIU отправил команду. Шина передачи данных передаёт команду на нужный OMSI. OMSI предпринимает действие в соответствии с командой.

· Запуск Обычного режима.

CFDIU -> начал работу. OMSI -> начал работу. Шина передачи данных -> активна. CFDIU -> отправил команду Log Off. Шина передачи данных -> передаёт команду на нужный OMSI. OMSI -> переходит в номальный режим.

3.3.2.3. Поведенческая модель.

· OMSI.

Диаграмма 14. Старт Проверить Энергозависимую память. Выбор: Есть ли непереданные сообщения в Энергонезависимой памяти? Да - Инициализация; Нет - Тёплый старт. Тёплый старт Забрать сообщения из Энергонезависимой памяти Загрузить настройки из APM. Инициализация Загрузить настройки из APM Работа Принять сообщения Получить команду Сформировать отчет Проверить активность Шины передачи данных Выбор: Шина активна? Да - Отослать вопрос; Нет - Ждать активизации Шины передачи данных. Отослать отчет Принять сообщения. Ждать активизации шины Отослать отчет.

· CFDIU.

Диаграмма 15. Старт Включено Направить команду (необязательное действие) Получить отчет Отобразить отчет Выбор: Окончить работу? Да - Выключено; Нет Направить команду (необязательное действие).

· APM.

Диаграмма 16. Старт Получение запроса Передать настройки Получение запроса.

· Шина передачи данных.

Диаграмма 17. Старт Неактивна Включение CFDIU => Активна Выбор: Перенаправление команды; Передача отчета. Выбор: Выключение CFDIU => Неактивна; Активна.

· Бортовая система.

Диаграмма 18. Старт Работает Отправка сообщения в Энергонезависимую память Отправка сообщения к OMSI Работает.

· Энергонезависимая память.

Диаграмма 19. Старт Активна Записать сообщение от Бортовой системы Передать сохраненные сообщения OMSI (необязательное действие) Уничтожить сообщения, не нужные OMSI Активна.

3.3.3. Статическая модель.

3.3.3.1. Модель классов.

На диаграмме 9 представлены основные классы создаваемой системы: OMSI, CFDIU, Шина передачи данных, APM, Энергонезависимая память, Бортовая система.

· OMSI - интерфейсная система, обеспечивающая взаимосвязь функциональной системы, (например, T2CAS - системы предупреждения сближения самолетов, правильнее «предотвращения столкновения») с центральным устройством отображения данных CFDIU.

· Задача CFDIU предоставлять экипажу самолета данные о функционировании всех бортовых систем. С помощью меню экипаж (или техник на земле) может вступить во взаимодействие с конкретной функциональной бортовой системой (интерактивный режим). В остальных случаях CFDIU просто отображает (нормальный режим) состояние бортовых систем, которые через свои OMSI сообщают CFDIU свои состояния, посылая сообщения Label350.

· Процесс взаимодействия OMSI и CFDIU происходит через Шину передачи данных. Если шина не активна, то это может означать, что бортовая система к CFDIU не подключена, а, следовательно, некому слать сообщения.

· APM - это подсистема (таблица данных с интерфейсом) хранящая настройки данного самолета. Бортовая система типа T2CAS может ставиться на различные самолеты, и должна подстраиваться к работе конкретного борта. В частности, CFDIU не единственный вариант устройства отображения данных для экипажа. Могут быть и другие (на разных типах самолетов), тогда и протокол обмена реализуется с учетом соответствующей центральной системы.

· После сбоя в электропитании OMSI должен извлечь отчет о неисправности из энергонезависимой памяти, которая в данном случае будет представлена отдельным объектом создаваемой программной системы.

· Объект Бортовая система моделирует те сведения, которые должна иметь интерфейсная система о функциональной для взаимодействия.

Заключение.

Был проведён анализ предметной области систем реального времени. Определены основные отличия систем данного типа от других подобных систем и особенности управления исполнением задач. Были рассмотрены используемые классификации и отличительные особенности современных систем.

На основе проведенного анализа была спроектирована система, состоящая из двух основных подсистем: планировщика заданий реального времени и прикладного приложения - авиационного протокола.

Для обоих подсистем выполнены этапы создания системных и функциональных требований, определены используемые алгоритмы и архитектуры.

Для протокола использована современная методология разработки ПО и создана модель классов системы. В целом стоит отметить, что классы в проектируемой системе обладают простотой проектирования за счёт отсутствия иерархических связей, однако применяемый метод позволяет с относительной простотой усложнять структурные связи и расширять область проектирования.

На основе найденных при проектировании прикладного приложения недостатков используемой платформы в дальнейшем могут быть изменены функциональные или архитектурные особенности планировщика. Так же предполагается использование прикладного приложения для непосредственного тестирования планировщика.

Литература.

1. С. Кузнецов «Механизмы IPC в операционной системе Unix». учебные материалы конференции «Индустрия Программирования 96», Центр Информационных Технологий, 1996.

2. Алексей Быков «Системное администрирование IBM AIX 4.x».

3. Dr. Jurgen Sauermann, Melanie Thelen «Real-time Operating Systems. Concepts and Implementation of Microkernels for Embedded Systems».

4. See-Mong Tan, David K. Raila, Roy H. Campbell «A case for nano-kernels». Department of Computer Science, University of Illinois at Urbana-Champaign, 1996, 11 стр.

5. Michel Gien «Micro-kernel Architecture. Key to Modern Operating Systems Design». Chorus systems, 1990, 10 стр.

6. Booch G. «Object-oriented analysis and design with application, second edition». The Benjamin / Cummings Publishing Company, Inc, 1994, 589 стр.

7. Романовский К., Ивановский Б., Кознов Дм., Долгов П. «Обзор нотаций методологии Real». //http://www.tepcom.ru/produkts/real/Report_Notations_A .asp.

8. ITU «SDL methodology guidelines and bibliography». Appendices i to recommendation Z.100, 1993,107 стр.

9. Selic B., Gullekson G., Ward P.T. «Real-time object-oriented modeling». John Wiley & Sons. Inc, 1994, 525 стр.

10. ITU «Recommendation Z.100: Specification and Description Language (SDL)». 1993, 204 стр.

11. Бардзинь Я.М., Калкиньш А.А., Стродс Ю.Ф., Сыцко В.А. «Язык спецификаций SDL/PLUS и его применения». Рига, 1988, 313 стр.

12. IEEE Standards Project P1003.4a «Thread Extension for Portable Operating Systems. Draft 6». Draft 6.-IEEE, 1992.

13. Алан Джок «ОС реального времени».Приложение

Диаграмма 2. Стандартные прикладные интерфейсы.

Таблица 3. Время отклика.

Таблица 4. Сравнение различных операционных систем.

Рисунок 5. ОС в пространстве "адресация-класс-стандартизация".

Диаграмма 6. Время реакции различных систем на прерывание

Диаграмма 7. Время переключения контекста

ОСРВ

Разработчик

Область применения

Web-адрес

Комментарии

C Executive

JIMI Software Systems

Коммерческая

www.jmi.com

Система реального времени для программ на Си; поддерживает процессоры архитектур CISC и RISC

ITRON

ITRON Committee, TRON Association

Коммерческая

www.itron.gr.jp/home-e.html

Спецификация разработана японской технологической ассоциацией; ориентирована на промышленные приложения

LynxOS

LynuxWorks

Коммерческая

www.lynuxworks.com

Совместима с Linux; поддерживает Unix и Java

OS-9

Microware Systems

Коммерческая

www.microware.com

Поддерживает микроархитектуру Intel XScale; модульная структура стимулирует добавление к системе новых устройств

QNX

QNX Software Systems

Коммерческая

www.qnx.com

Изолирует приложения, библиотеки, данные и системное программное обеспечение

VxWorks, VxWorks AE

Wind River Systems

Коммерческая

www.windriver.com

Позволяет изолировать совместно используемые приложения, библиотеки, данные и системное ПО

Chimera

Университет Карнеги- Меллона

Экспери-
ментальная

www.cs.cmu.edu/afs/ cs.cmu.edu/project/ chimera/www/chimera/ chimera.html

Поддержка многозадачности и многопроцессорных систем; предназначена для роботов и автоматизированных систем

Maruti

Университет шт. Мэриленд

Экспери-
ментальная

www.cs.umd.edu/

Поддерживает режимы "жесткого" и "мягкого" реального времени

Таблица 8. Современные представители систем реального времени.

Диаграмма 9. Основные классы системы протокола.

Диаграмма 10. Схема взаимодействия объектов СРВ.

Рисунок 11. Модель случаев использования.

Диаграмма 12. Обычный режим.

Диаграмма 13. Диалоговый режим.

Диаграмма 14. OMSI.

Диаграмма 15. CFDIU.

Диаграмма 16. APM.

Диаграмма 17. Шина передачи данных.

Диаграмма 18. Бортовая система.

Диаграмма 19. Энергозависимая память.

Array

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10



2012 © Все права защищены
При использовании материалов активная ссылка на источник обязательна.