Главная страница
Навигация по странице:

  • «___» __________

  • Тип планировщика

  • Обработка прерываний: нетМаксимальное количество задач: 32Максимальное количество приоритетов: 16Максимальное количество ресурсов

  • Максимальное количество событий

    		•

    Курсоваяработ а


    Скачать 426.04 Kb.
    НазваниеКурсоваяработ а
    Дата26.09.2019
    Размер426.04 Kb.
    Формат файлаdocx
    Имя файлаass.docx
    ТипКурсовая
    #87758
    страница1 из 5
      1   2   3   4   5

    Санкт-Петербургский политехнический университет

    Институт компьютерных наук и технологий

    Кафедра «Информационные и управляющие системы»

    К У Р С О В А Я Р А Б О Т А

    Моделирование операционной системы реального времени с использованием UML

    по дисциплине «Архитектура вычислительных систем»

    Вариант №8

    Выполнил:

    студент гр. 33504/2 Зайцев В.А.

    Шевченко Г.Г.

    Лапковский Е.А.

    Руководитель:

    старший преподаватель Александрова О. В.


    «___» __________ 2016 г.

    Санкт-Петербург

    2016

    Содержание


    Введение 3

    Цель работы 4

    Задание 4

    Основные понятия и определения 5

    Диаграммы исходной модели 9

    Реализация 11

    Тестирование реализации 14

    Вывод 16

    Список использованных материалов 17

    Введение



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

    Данная работа осуществляется в рамках курса операционный систем реального времени(ОСВР). ОСРВ предназначены для обеспечения интерфейса доступа к ресурсам критических по времени систем реального времени. Основной задачей в таких системах является своевременность выполнения обработки данных.

    Курсовая работа сделана на языке UML в среде разработки Rational TAU Telelogic 4.3. Работа c проектом будет осуществляться с среде разработки Rational TAU Telelogic 4.3 с использованием языка UML.


    Цель работы





    1. Изучить стандарт проектирования и разработки UML, изучить основные паттерны.

    2. Ознакомиться с основами проектирования в среде IBM Telelogic Rational TAU

    3. Дополнить существующую модель операционной системы реального времени OSEK реализацией механизма системных событий в среде TeleLogic Rational TAU 4.


    Задание



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

    Тип планировщика: POSIX

    Алгоритм планирования: preemptive, RMA

    Управление ресурсами: простые семафоры

    Управление событиями: системные события

    Обработка прерываний: нет

    Максимальное количество задач: 32

    Максимальное количество приоритетов: 16

    Максимальное количество ресурсов: 16

    Максимальное количество событий: 16

    Кроме того, в задание входит написание тестов, проверяющих соответствие проекта этим свойствам.

    Кроме того, в задание входит написание тестов, проверяющих соответствие проекта этим свойствам.

    Основные понятия и определения



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

    Все объекты ОСРВ создаются статически на этапе компиляции и редактирования связей.

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

    ОСРВ включает в себя подсистемы обеспечивающие следующие возможности:


    Задача (task) - единица обработки, выполняющаяся конкурентно с другими задачами. Задачи являются основным средством обработки внутренних событий. Задача имеет некоторое значение приоритета, определяющее ее относительные претензии на захват процессора. Эти претензии удовлетворяются ОС по определенному алгоритму. Вместо приоритета может использоваться значение срока исполнения.Задача имеет точку входа (entry point). Задача обычно является функцией, записанной на языке C (C++) и идентифицируется некоторым идентификатором (языка С). Задача обычно выполняет вызовы ОС для взаимодействия с другими задачами (хотя бы один вызов завершения задачи).Обычно задача встроенной ОС эквивалентна thread обычных ОС, т.е. работает в одном адресном пространстве с другими задачами.

    Обработчик прерываний (interrupt service routine, software interrupt handler) - единица обработки, инициированная аппаратным прерыванием асинхронно по отношению к выполнению задач и самой ОС.Обработчики прерываний являются основным средством Обработчики прерываний занимают процессор в соответствии с алгоритмом планирования, поддерживаемым аппаратурой.Для выполнения вызовов ОС обработчик прерываний обычно включает специальный пролог и эпилог, которые обеспечивают необходимый контекст выполнения.Обычно обработчики прерываний выполняют только предварительное обслуживание событий, и, генерируя внутреннее событие, планируют задачу для завершения обработки событий и выработки откликов.

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

    События (events) предназначены для обмена двоичными данными между задачами и обработчиками прерываний.События также реализуются в виде флагов (masks, flags) или сигналов (signals).Cобытия обычно принадлежат задачам (не разделяются между задачами).

    Таймеры (timers) предназначены для задания временных интервалов для задач, а также подсчета абсолютного значения времени.

    Счетчики (counters) предназначены для отслеживания абсолютного значения или перемещения механических устройств (например, угла поворота вала).
    Реализация протокола наивысшего приоритета (Highest Locker Protocol, HLP) является обязательным требованием к ОСРВ.

    Его применение гарантирует, что в процессе работы:

    • две задачи не могут одновременно обратиться к одному и тому же ресурсу

    • не возникает неограниченной инверсии приоритетов

    • не возникает тупиков в ходе выполнения программы

    HLP предписывает следующий подход при управлении ресурсами.

    • На этапе построения системы (но не на этапе выполнения) каждому ресурсу назначается наивысший приоритет (ceiling priority, CP). Наивысший приоритет вычисляется по формуле , где - наивысший приоритет k-го ресурса, а - приоритет i-й задачи, использующей k-й ресурс.

    • Если приоритет задачи, захватывающей ресурс, меньше наивысшего приоритета данного ресурса, то её приоритет увеличивается до значения наивысшего приоритета этого ресурса.

    • После освобождения ресурса приоритет задачи принимает значение, которое он имел до захвата этого ресурса.


    Планирование состоит из двух шагов, выполняющихся друг за другом:

    1. Собственно планирование (scheduling), т.е. составления расписания.

    2. Диспетчеризация (dispatching) - выбора задачи из списка и назначения ей процессора (переключение контекста).

    Планирование и диспетчеризация в системах реального времени должно удовлетворять следующим требованиям:

    • строгое соблюдение дисциплины планирования

    • полное исключение инверсии приоритетов между задачами (за исключением специальных планировщиков – например, невытесняющих)

    • сохранение контекста задачи при вытеснении ее с процессора

    • восстановление контекста задачи при назначении ей процесоора

    • минимально возможное потребление ресурсов - памяти и процессорного времени

    Битовый тип планировщика:

    • Контекст задачи обычно сохраняется на стеке задачи

    • Указатель на контекст (вершина стека) заносится в описатель задачи

    • Переключение контекста часто выполняется с помощью команд процессора, предназначенных для обработки прерываний («программное прерывание», «возврат из прерывания»)



    Вытесняющее (pre-emptive) планирование:



    Rate Monotonic Scheduling (RMS/RMA): задачам с более короткими периодами исполнения назначается более высокий приоритет.
    Проектируемая система, моделирующая работу части сервисов OSEK, имеет архитектуру, показанную на рисунке:



    На рисунке показана взаимосвязь двух пакетов модели и их внутренние компоненты. Пакет Kernel импортируется в пакет OSEKTest - это дает возможность создавать экземпляры класса OSEKClass внутри MainClass, что позволяет:

    1. Посылать сигналы Сonfig(установка параметров задач), StartOS(запуск операционной системы), ShutdownOS (остановка операционной системы) на ядро из окружения;

    2. Организовывать связь задач и OSEK. Создать коннекторы, соединяющие порты данных классов;

    3. Организовывать связь ресурсов приложения и OSEK. Создать коннекторы, соединяющие порты данных классов;

    Импорт пакета позволяет использовать сигналы, описанные в ядре, на вход/выход портов OSEKTest. Поэтому все сигналы, которые будут использоваться в модели, представлены на диаграмме классов в ядре.

    Алгоритмы планирования задач и смены приоритета при захвате ресурса реализованы в пакете Kernel соответственно в классах ScheduleClass и ResourceManagementClass.

      1   2   3   4   5

    написать администратору сайта