Ограниченное время ответа
Особенности управления задачами
Ядра реального времени
Время переключения контекста
OS-9/Hawk фирмы Microware Systems
Методология разработки программного обеспечения
Вывод
Принципиальная структура
Обработка запросов внешних устройств
Планирование апериодических задач
Последний шанс
Динамическая модель
Абсолютные ограничения
Работа
Модель взаимодействий
Навигация
Ядра реального времени
Разработка системы реального времени в виде планировщика исполнения заданий
104513
знаков
2
таблицы
0
изображений
1.3.1.2. Ядра реального времени
В этот класс входят системы с монолитным ядром, где и содержится реализация всех механизмов реального времени этих операционных систем. Исторически системы этого типа были хорошо спроектированы. В отличие от систем других классов, которые появлялись как временные компромиссы и затем "наращивали мускулы" благодаря первым удачным реализациям (исполнительные системы реального времени и UNIX'ы реального времени), разработчики систем этого класса имели время для разработки систем именно реального времени и не были изначально ограничены в выборе средств (например фирма "Microware" имела в своем распоряжении три года для разработки первого варианта OS-9).
Одна из их особенностей - высокая степень масштабируемости. На базе этих ОС можно построить как компактные системы реального времени, так и большие системы серверного класса.
Как правило, ядра реального времени имеют два типа систем разработки - кроссовую и резидентную.
Системы этого класса, как правило, модульны, хорошо структурированы, имеют наиболее развитый набор специфических механизмов реального времени, компактны и предсказуемы. Наиболее популярные системы этого класса: OS9, QNX.
1.3.1.3. UNIX'ы реального времени
Исторически системы реального времени создавались в эпоху расцвета и бума UNIX'а и поэтому многие из них содержат те или иные заимствования из этой красивой концепции операционный системы (пользовательский интерфейс, концепция процессов и т.д.).
Часть разработчиков операционных систем реального времени попыталась просто переписать ядро UNIX, сохранив при этом интерфейс пользовательских процессов с системой, насколько это было возможно. Реализация этой идеи не была слишком сложной, поскольку не было препятствия в доступе к исходным текстам ядра, а результат оказался замечательным. Получили и реальное время, и сразу весь набор пользовательских приложений - компиляторы, пакеты, различные инструментальные системы.
В этом смысле создателям систем первых двух классов пришлось потрудиться не только при создании ядра реального времени, но и продвинутых систем разработки.
Однако Unix'ы реального времени не избавлены от следующих недостатков: системы реального времени получаются достаточно большими и реактивность их ниже, чем реактивность систем первых двух классов.
Наиболее популярным представителем систем этого класса является операционная система реального времени LynxOS.
1.3.2. Классификация по программной среде.
Становится очевидным то, что задачи реального времени необходимо реализовывать в рамках специфической системной программной среды. В соответствии с [12] системы реального времени можно разделить на 4 класса.
1.3.2.1. Программирование на уровне микропроцессоров.
В данном случае программы для программируемых микропроцессоров, встраиваемых в различные устройства, очень небольшие и обычно написаны на языке низкого уровня типа ассемблера или PLM. Внутрисхемные эмуляторы пригодны для отладки, но высокоуровневые средства разработки и отладки программ не применимы. Операционная среда обычно недоступна.
1.3.2.2. Минимальное ядро системы реального времени.
На более высоком уровне находятся системы реального времени, обеспечивающие минимальную среду исполнения. Предусмотрены лишь основные функции, а управление памятью и диспетчер часто недоступны. Ядро представляет собой набор программ, выполняющих типичные, необходимые для встроенных систем низкого уровня функции, такие, как операции с плавающей запятой и минимальный сервис ввода/вывода. Прикладная программа разрабатывается в инструментальной среде, а выполняется, как правило, на встроенных системах.
1.3.2.3. Ядро системы реального времени и инструментальная среда.
Этот класс систем обладает многими чертами ОС с полным сервисом. Разработка ведется в инструментальной среде, а исполнение - на целевых системах. Этот тип систем обеспечивает гораздо более высокий уровень сервиса для разработчика прикладной программы. Сюда включены такие средства, как дистанционный символьный отладчик, протокол ошибок и другие средства. Часто доступно параллельное выполнение программ.
1.3.2.4. ОС с полным сервисом.
Такие ОС могут быть применены для любых приложений реального времени. Разработка и исполнение прикладных программ ведутся в рамках одной и той же системы.
Системы 2 и 3 классов принято называть системами "жесткого" реального времени, а 4 класса - "мягкого". Очевидно, это можно объяснить тем, что в первом случае к системе предъявляются более жесткие требования по времени реакции и необходимому объему памяти, чем во втором. Как мы видим, среда разработки и среда исполнения в системах реального времени могут быть разделены, а требования, предъявляемые к ним, весьма различны. Рассмотрим их более подробно.
1.3.3. Технические характеристики ОС РВ.
1.3.3.1. Время реакции системы.
Почти все производители систем реального времени приводят такой параметр, как время реакции системы на прерывание (interrupt latency).
В самом деле, если главным для системы реального времени является ее способность вовремя отреагировать на внешние события, то такой параметр, как время реакции системы является ключевым. Однако в настоящий момент нет, к сожалению, общепринятых методологий измерения этого параметра, поэтому он является полем битвы маркетинговых служб производителей систем реального времени. Есть надежда, что в скором времени положение изменится, так как уже стартовал проект сравнения операционных системах реального времени, который включает в себя в том числе и разработку методологии тестирования.
События, происходящие на объекте, регистрируются датчиками, данные с датчиков передаются в модули ввода-вывода (интерфейсы) системы. Модули ввода-вывода, получив информацию от датчиков и преобразовав ее, генерируют запрос на прерывание в управляющем компьютере, подавая ему тем самым сигнал о том, что на объекте произошло событие. Получив сигнал от модуля ввода-вывода, система должна запустить программу обработки этого события. Интервал времени - от события на объекте и до выполнения первой инструкции в программе обработки этого события и является временем реакции системы на события, и, проектируя систему реального времени, разработчики должны уметь вычислять этот интервал.
Время выполнения цепочки действий - от события на объекте до генерации прерывания - никак не зависит от операционных систем реального времени и целиком определяется аппаратурой, а вот интервал времени - от возникновения запроса на прерывание и до выполнения первой инструкции обработчика определяется целиком свойствами операционной системы и архитектурой компьютера. Причем это время нужно уметь оценивать в худшей для системы ситуации, то есть в предположении, что процессор загружен, что в это время могут происходить другие прерывания, что система может выполнять какие-то действия, блокирующие прерывания.
Неплохим основанием для оценки времен реакции системы могут служить результаты тестирования с подробным описанием архитектуры целевой системы, в которой проводились измерения, средств измерения и точным указанием, какие промежутки времени измерялись. Некоторые производители операционных систем реального времени результаты такого тестирования предоставляют. Их не увидишь в рекламных проспектах, но можно отыскать на WEB-страницах, в документах технической поддержки, в публикациях фирм, проводящих независимое тестирование.
Время реакции на прерывание, характерное для некоторых операционных систем реального времени, представлено на диаграмме 6.
Похожие работы
... элементов, глобальное пространство имен, а также лавинообразную первоначальную загрузку сети. Таким образом ОСРВ SPOX имеет необходимые механизмы для создания отказоустойчивой распределенной операционной системы реального времени, концепция построения которой описана в главе 2. 4.3 Аппаратно-зависимые компоненты ОСРВ Модули маршрутизации, реконфигурации, голосования реализованы как аппаратно- ...
... запрошенный ею ресурс, произошло связанное с ней внешнее событие, исчерпался заданный интервал времени и т. п. Заканчивая рассмотрение основных принципов планирования задач, необходимо отметить, что тема эта далеко не исчерпана. Диапазон систем реального времени весьма широк, начиная от полностью статических систем, где все задачи и их приоритеты заранее определены, до динамических систем, где ...
... же порты ввода-вывода или линии запроса прерывания. С такими проблемами, как конфликты различных частей аппаратуры, приходится иметь дело в основном именно операционным системам. Наконец, в-восьмых, при разработке операционных систем часто учитывается необходимость совместимости с предыдущей версией операционной системы. Система может иметь множество ограничений на длину слов, имена файлов и т. ...
... заявить, что все его ресурсы доступны для всех пользователей группы. Такая схема может быть многоуровневой (группы делятся на подгруппы и т.д.) с соответственным распределением прав и возможностей. Сейчас появляются операционные системы, в которых права доступа могут определяться не только такой иерархической структурой, но и могут быть более сложными, т. е. права доступа можно добавлять, нарушая ...
0 комментариев