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

1.5.3. Вывод.

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

1.6. Постановка задачи курсового проекта.

Перед созданием программной системы реального времени был проведен анализ действующих в данный момент разработок данного направления. Он показал, что существующий спектр ОС может обеспечить все потребности задач реального времени. Выбор системы (если абстрагироваться от цены, условий поставки и т.д.) диктуется только тем обстоятельством, удовлетворяет ли она условиям стоящей задачи. Например, если необходима хорошая операционная поддержка сетевых средств, то целесообразно использовать QNX - многозадачную операционную систему жесткого реального времени с архитектурой на основе микроядра. Если необходима очень высокая скорость реакции системы, можно использовать VxWorks. В данной работе при создании очень небольшой, не слишком сложной, встроенной прикладной программы было решено ориентироваться LynxOS, относящуюся к классу Unix'ов реального времени.

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

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

На основе планировщика будет реализован протокол, требующий поддержки реального времени. Для проектирования его реализации будет использована объектно-ориентированная методология. Такая методология характеризует скорее подход к планированию приложения, чем используемые средства языка, т.к. в авиационных системах, к которым и принадлежит реализуемый протокол A415 ARINC, не разрешено использование памяти из «кучи». В то время как динамическое выделение памяти является немаловажной частью использования языков, подобных C++ или Java.

2. Модели и методы предметной области.

2.1. Определения.

Сначала рассмотрим основное определение, вокруг которого и построена данная работа. Оно дано американским учёным Дональдом Гиллисом (Donald Gillies).

· Система реального времени - это система, в которой правильность вычислений зависит не только от логической корректности результата, но и от времени, в течение которого этот результат получен. Система работает неверно, если ее временные параметры не соответствуют заданным.

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

· Состояние -- стабильное положение объекта, когда он готов к принятию запросов на взаимодействие со стороны других объектов. С состоянием может быть связана некоторая деятельность объекта (например, входная и выходная). Состояние может быть сложным, т.е. содержать подсостояния.

· Событие -- получение сообщения или окончание срока действия таймера.

· Действие -- посылка сообщения, установка таймера, блок кода на целевом языке.

· Время прибытия задачи - время, когда возникает необходимость в выполнении данной задачи.

· Вызов задачи - начало выполнения данной задачи после прибытия.

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

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

Определения, непосредственно затрагивающие специфику данной работы.

· Масштабируемая ОС - операционная система, характеризующаяся высоким уровнем модульности, при котором отдельные функции системы можно динамически отключать/подключать без ущерба для общей функциональности системы. Такая ОС в зависимости от решаемой задачи, может быть установлена как на FLASH-носитель, так и на гигабайтный жесткий диск.

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

· Многопользовательская ОС - операционная система, ориентированная на одновременную работу с несколькими пользователями.

· Многозадачная ОС - операционная система, ориентированная на параллельное выполнение системой нескольких задач. Истинно многозадачной ОС может быть только при наличии более чем одного микропроцессора, но современные операционные системы обладают приемлемыми механизмами обеспечения псевдопараллельной работы.

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

2.2. Принципиальная структура.

2.2.1. Среда исполнения.

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

· небольшая память системы - для возможности ее встраивания;

· система должна быть полностью резидентна в памяти, чтобы избежать замещения страниц памяти или подкачки;

· система должна быть многозадачной - для обеспечения максимально эффективного использования всех ресурсов системы;

· ядро с приоритетом на обслуживание прерывания.

Приоритет на прерывание означает, что готовый к запуску процесс, обладающий некоторым приоритетом, обязательно имеет преимущество в очереди по отношению к процессу с более низким приоритетом, быстро заменяет последний и поступает на выполнение. Ядро заканчивает любую сервисную работу, как только поступает задача с высшим приоритетом. Это гарантирует предсказуемость системы;

· диспетчер с приоритетом.

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

Сочетание описанных выше свойств создает мощную и эффективную среду исполнения в реальном времени.

2.2.2. Ядро систем реального времени.

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

Ядро может обеспечивать сервис пяти типов:

2.2.2.1. Синхронизация ресурсов.

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

2.2.2.2. Межзадачный обмен.

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

2.2.2.3. Разделение данных.

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

2.2.2.4. Обработка запросов внешних устройств.

Каждая прикладная программа в реальном времени связана с внешним устройством определенного типа. Ядро должно обеспечивать службы ввода/вывода, позволяющие прикладным программам осуществлять чтение с этих устройств и запись на них. Для приложений реального времени обычным является наличие специфического для данного приложения внешнего устройства. Ядро должно предоставлять сервис, облегчающий работу с драйверами устройств. Например, давать возможность записи на языках высокого уровня - таких, как Си или Паскаль.

2.2.2.5. Обработка особых ситуаций.

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

2.2.3. Пикоядро.

Базовые требования современных систем реального времени стали столь обширны, что назрела необходимость в структуризации уже самого микроядра. Была выдвинута идея так называемого «пикоядра». Пикоядро - в данном случае это ядро, имеющее следующие свойства:

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

· Реализует и содержит в себе очень малое количество функций и данных - только функции для работы с объектами.

· Предоставляет объектно-ориентированный интерфейс системе в виде небольшого количества системных вызовов для работы с объектами.

· Является полностью пассивной частью кода операционной системы - код ядра выполняется только во время системных вызовов.

· В большинстве случаев является обычной статической библиотекой, которая компонуется с главной системной частью ОС - менеджером процессов.

2.3. Методы управления задачами в ОС РВ.

2.3.1. Классификация подходов.

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

2.3.1.1. Статическое планирование.

Большинство всех существующих методов относятся к статическому планированию. В этом случае считается, что всё множество задач системы и все их характеристики известны заранее. В этом случае расписание работы задач строится до начала работы системы и остаётся постоянным во время её функционирования. В этом расписании определены времена старта для всех задач системы. В течение работы системы планировщик выбирает следующую задачу для запуска в соответствии с этим расписанием. Расписание циклически повторяется.

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

2.3.1.2. Динамическое планирование.

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

2.3.1.3. Планирование, основанное на времени.

В этом случае производится статический анализ системы, в результате чего строится расписание, которое затем используется во время работы для того, чтобы решить, когда и какая задача должна начать своё выполнение. Это расписание содержит фиксированное время старта для каждого примера задач, основываясь на времени выполнения в худшем случае и всех взаимозависимостях между задачами. Затем это расписание может измениться.

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

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

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

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

2.3.1.4. Планирование апериодических задач

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

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

2.3.1.5. Планирование, управляемое приоритетами.

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

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

2.3.2. Обзор методов.

2.3.2.1. Rate-monotonic (RM).

Метод назначает статические приоритеты задачам основываясь на их периодах. В этом методе приоритеты определяются следующим образом: задача с самым маленьким периодом получает самый высокий приоритет.

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

Исходный RM подход имеет ряд ограничений:

· Все задачи должны быть независимы друг от друга, т.е. между ними нет ни взаимодействия, ни общих ресурсов.

· Все задачи должны быть периодическими.

· Все задачи могут быть приостановлены другими задачами с более высокими приоритетами. Однако ни одна задача не может блокироваться, ожидая внешнего события.

· Время выполнения постоянно.

· Для задач определено время выполнения в худшем случае.

· Все задачи имеют крайний срок, эквивалентный их периоду.

Было проведено большое количество исследований для расширения этих методов. В результате этих работ были сняты или ослаблены ограничения, налагаемые на задачи в исходной модели.

Так в протоколе приоритетных границ (Priority Ceiling Protocol) и некоторых других похожих (Stack Resource Protocol) удалось избавиться от ограничения на взаимодействие задач. Также было предложено много методов приведения непериодических задач к периодическим.

2.3.2.2. Deadline Monotonic (DM).

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

Такой метод расстановки приоритетов будет оптимальным, если выполняются следующие условия:

· множество задач - фиксированное множество жёстких задач;

· задачи периодические или спорадические;

· задачи имеют определённое (известное) время выполнения в худшем случае;

· для задач определён критический момент, то есть время выполнения в худшем случае.

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

2.3.2.3. Планирование апериодических задач.

2.3.2.3.1. Метод фонового выполнения.

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

2.3.2.3.2. Метод опроса.

Метод использует отдельную периодическую задачу с высоким приоритетом для поддержки выполнения апериодических задач.

Оба этих метода неэффективны, когда время ответа апериодической задачи важно.

2.3.2.3.3. Алгоритм безотлагательного сервера (IS)

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

2.3.2.3.4. Последний шанс.

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

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

Этот метод гарантирует своевременность выполнения периодических задач и максимизирует ответную реакцию апериодических задач.

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

2.3.2.4. EDF.

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

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

2.3.2.5. Сервер, допускающий задержку (DS) и Алгоритм обмена приоритетами (PE).

Эти методы сохраняют доступными ресурсы системы, первоначально выделенные для апериодических задач.

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

В отличие от него DS не отдаёт время выполнения этой задачи, когда не осталось ни одной апериодической задачи. Вместо этого он хранит это высокоприоритетное время выполнения либо пока не прибудет апериодическая задача, либо пока не закончится период сервера.

Этот метод проще в реализации, но хуже в исполнении.

2.4. Методология разработки программного обеспечения.

2.4.1. Основы методологии Real.

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

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

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

Модель случаев использования -- описывает требования, предъявляемые к системе ее окружением, т.е. отвечает на вопрос “что и для кого должна делать система?”.

Функциональная модель -- описывает разбиение случаев использования и функций на подфункции. Дает ответ на вопрос “как должны реализовываться функции системы в терминах своих подфункций?”.

· Динамическая модель:

Модель объектов -- описывает роли объектов системы и отвечает на вопрос “какие объекты взаимодействуют при выполнении функций системы?”.

Модель взаимодействий -- описывает сценарии взаимодействия объектов системы между собой и с пользователями, т.е. дает ответ на вопрос “как объекты взаимодействуют друг с другом для выполнения функций системы?”.

Поведенческая модель -- описывает алгоритмы поведения объектов системы, т.е. отвечает на вопрос “как должен вести себя каждый объект для реализации функций системы?”.

· Статическая модель:

Модель классов -- описывает внутреннюю структуру системы, структуры данных, используемые в ней, т.е. отвечает на вопрос “как должна выглядеть система изнутри?”.

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

2.4.2. Модель требований.

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

На основе требований заказчика формулируется полный список функциональных требований к системе, которые оформляются в терминах модели случаев использования и модели функций. Окончательное техническое задание на систему может быть сгенерировано по модели требований Real в том виде, который нужен заказчику (ГОСТ, какой-либо международный или внутрикорпоративный стандарт и т.п.).

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

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

Отметим, что модель случаев использования в Real является подмножеством одноименной модели UML. То, что в UML делается с помощью не вошедшей в Real части модели случаев использования, в Real предлагается делать с помощью модели функций, которая является вариацией функциональной модели из структурных методологий разработки программного обеспечения. Модель функций Real основана на модели функций SDL, однако оттуда были убраны некоторые детали (в Real не предполагается так широко использовать модель функций, поскольку не хотелось бы подталкивать разработчика к алгоритмическому методу разработки системы) и добавлены использование функций, группы функций, а также связь с моделью случаев использования.

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

Она описывает поведение системы -- взаимодействие между различными ее компонентами, взаимодействие системы с ее окружением и поведение самих компонент.

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

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

Построение сценариев для функции начинается с определения ”прямых веток”, т.е. идеального исполнения функции. При этом из рассмотрения исключаются граничные, ошибочные ситуации, частные случаи и т.п., для них впоследствии тоже строятся сценарии либо они специфицируются другими средствами.

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

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

После того, как созданы основные сценарии системы, можно переходить к спецификации их участников -- объектов, т.е. к построению модели классов. Эта модель классов строится на протяжении всего процесса разработки программного обеспечения.

В Real в модели классов могут быть следующие виды сущностей:

* класс -- описание группы однородных объектов;

* шаблон -- параметризованный класс с возможностью получения из него обычного класса подстановкой значений параметров;

* интерфейс -- описание правил взаимодействия классов;

* представление -- аналог конструкции VIEW языка SQL.

Модель классов Real реализует достаточно полное подмножество модели классов UML. Кроме того, в ней есть интерфейсы и порты из ROOM, при этом последние существенно расширены. Модель классов Real содержит также средства моделирования схемы баз данных.

3. Реализация прототипа системы реального времени.

3.1. Жизненный цикл разработки.

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

На диаграмме 1 представлены этапы разработки программной системы. Выполненные в рамках данной работы, выделены чёрным цветом, предполагаемые к исполнению в дальнейшем - серым.

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

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

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

3.2. Планировщик заданий.

3.2.1. Выбор алгоритма планирования.

3.2.1.1. Виды требований РВ, поддерживаемые планировщиком.

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

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

3.2.1.1.1. Абсолютные ограничения.

· Интервал выполнения.

Выражает интервал, предоставляемый задаче для выполнения. Задаётся в микросекундах или как часть интервала выполнения всех задач. Определяет приоритетность определённой задачи на данном этапе вычислений. Может динамически изменяться.

· Время реакции.

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

· Время выполнения.

Выражает время выполнения задач в худшем случае. При превышении времени выполнения задача останавливается. В специальный стек «неуложившихся в срок» записывается её идентификатор. Для мягких задач данный параметр не фиксирован. Этот показатель также важен для распределённых (многопроцессорных) систем, где время выполнения задачи может зависеть от узла, на котором она выполняется.

· Периоды.

Период показывает, как часто задача должна выполняться. Период может ограничивать время реакции задачи, поэтому время реакции предполагается меньшим периода.

3.2.1.1.2. Относительные ограничения.

Ограничения данного класса также называют локальными. Они выражают то, как две задачи связаны друг с другом.

· Приоритетные ограничения.

Данные ограничения определяют какие задачи предполагается блокировать при угрозе невыполнения срока данной задачи. В первую очередь блокируются мягкие задачи.

· Ограничения расстояния.

Определяют минимальное расстояние во времени между выполнением двух задач.

· Обновление.

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

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

· Гармонические ограничения

Эти ограничения связаны с периодами двух взаимодействующих задач. Они имеют место, например, когда период одной задачи (например, получателя) зависит от периода другой (отправителя).

3.2.1.1.3. Неподдерживаемые ограничения.

· Отношения.

Данные ограничения выражают максимальный интервал времени между временами завершения двух задач.

· Разделительные ограничения.

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

3.2.1.2. Используемые алгоритмы.

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

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

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

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

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

3.2.2. Описание функционирования приложения.

Схема взаимодействия объектов создаваемой системы показана на диаграмме 10.

3.2.2.1. Подготовка к запуску планировщика.

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

В планировщике создается список задач. Создаётся процесс-таймер, который будет формировать последовательность сообщений для планировщика.

3.2.2.2. Работа.

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

Таймер получает от планировщика сообщения и создаёт соответствующие метки отсылки сообщений для планировщика. В дальнейшем по достижении метки таймер посылает планировщику сообщение инициировать работу определённой задачи. Если это метка периодической или спорадической задачи, то таймер создаёт через «период» следующую. Планировщик посылает процессам-заданиям сигналы начала кванта времени для выполнения.

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

3.2.2.3. Управление задачами.

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

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

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

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

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

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

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

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

Принимается сообщение о необходимости изменения параметра. Если задача, для которой он должен быть измен, активна, то она приостанавливается. Удаляется соответствующая метка в таймере. Параметр изменяется. Устанавливается новая метка в таймере. Если время реакции равно 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 должен извлечь отчет о неисправности из энергонезависимой памяти, которая в данном случае будет представлена отдельным объектом создаваемой программной системы.

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

Заключение.

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