- •Обозначения и сокращения.
- •Ietf – Internet Engineering Task Force – инженерный совет интернета.
- •Iana – Internet Assigned Numbers Authority – администрация адресного пространства Интернет.
- •Введение.
- •1 Системы массового обслуживания.
- •1.1 Основные определения теории телетрафика.
- •1.2 Основы теории вероятностей.
- •1.3 Законы распределения случайных величин.
- •1.4 Общие сведения о системах массового обслуживания.
- •1.4.1 Информационные процессы и конфликты обслуживания.
- •1.4.2 Классификация Кендалла-Башарина.
- •1.4.3 Пример классификации смо.
- •2 Потоки заявок в пакетных сетях на примере сети sip.
- •2.1 Принципы построения сети sip.
- •2.2 Интеграция протокола sip с ip-сетями.
- •2.3 Адресация.
- •2.4 Архитектура сети sip.
- •2.5 Пример sip-сети.
- •2.6 Переадресация соединения по sip.
- •3 Операционные системы реального времени.
- •3.1 Системы реального времени. Системы жесткого и мягкого реального времени.
- •3.2 Архитектурные особенности операционных систем реального времени.
- •3.2.1 Системы исполнения и системы разработки в операционных системах реального времени.
- •3.2.2 Время реакции системы.
- •3.2.3 Время переключения контекста.
- •3.2.4 Размеры системы.
- •3.2.5 Возможность исполнения системы из пзу (rom).
- •3.2.6 Механизмы реального времени.
- •3.2.7 Система приоритетов и алгоритмы диспетчеризации.
- •3.2.8 Механизмы межзадачного взаимодействия.
- •3.2.9 Средства для работы с таймерами.
- •3.3 Классы систем реального времени.
- •3.4 Исполнительные системы реального времени.
- •3.5 Ядра реального времени.
- •3.6 Unix'ы реального времени.
- •3.7 Расширения реального времени для WindowsNt.
- •3.8 Операционная система реального времени qnx.
- •3.8.1 Сочетание преимуществ.
- •3.8.2 Полная совместимость со стандартом posix.
- •3.8.3 Единая среда.
- •3.8.4 Открытая архитектура для устранения неполадок и модификации операционной системы.
- •3.8.5 Сокращение повторных трудозатрат.
- •3.8.6 Дополнительные службы микроядра.
- •3.8.7 Развитая поддержка многопроцессорной обработки для многоядерных процессоров.
- •3.8.8 Безопасность и готовность систем за счёт гарантированного выделения процессорного времени.
- •3.8.9 Модель среды исполнения с повышенной надёжностью.
- •3.8.10 Динамическое обновление системных служб.
- •3.8.11 Прозрачная распределённая обработка.
- •3.8.12 Отказоустойчивое сетевое взаимодействие.
- •3.8.13 Меньшее потребление памяти.
- •3.9 Сравнение параметров операционных систем реального времени.
- •3.10 Предоставление «жесткого» реального времени аппаратными средствами.
- •3.11 Критерии согласия.
- •4 Технико-экономические расчеты.
- •4.1. Расчет затрат на проведение научно-исследовательской работы.
- •4.2 Расчет экономической эффективности.
- •Заключение
- •Список использованных источников.
- •Приложение а
3.2 Архитектурные особенности операционных систем реального времени.
3.2.1 Системы исполнения и системы разработки в операционных системах реального времени.
Одно из коренных внешних отличий систем реального времени от систем общего назначения – четкое разграничение систем разработки и систем исполнения (рисунок 3.1) [9]. Система исполнения в операционных системах реального времени – набор инструментов (ядро, драйверы, исполняемые модули), обеспечивающих функционирование приложения реального времени.
Большинство современных ведущих операционных систем реального времени поддерживают целый спектр аппаратных архитектур, на которых работают системы исполнения (Intel, Motorola, RISC,MIPS, PowerPC, и другие). Это объясняется тем, что набор аппаратных средств – часть комплекса реального времени и аппаратура должна быть также адекватна решаемой задаче, поэтому ведущие операционные системы реального времени перекрывают целый ряд наиболее популярных архитектур, чтобы удовлетворить самым разным требованиям по части аппаратуры. Система исполнения операционных системах реального времени и компьютер, на котором она исполняется называют «целевой» (target) системой. Система разработки – набор средств, обеспечивающих создание и отладку приложения реального времени [7].
Системы разработки (компиляторы, отладчики и всевозможные tools) работают, как правило, в популярных и распространенных ОС, таких, как UNIX и Windows. Кроме того, многие операционные системы реального времени имеют и так называемые резидентные средства разработки, исполняющиеся в среде самой операционной системы реального времени – особенно это относится к операционным системам реального времени класса «ядра».
Заметим, что функционально средства разработки операционных систем реального времени отличаются от привычных систем разработки, таких, например, как Developers Studio, TaskBuilder, так как часто они содержат средства удаленной отладки, средства профилирования (измерение времен выполнения отдельных участков кода), средства эмуляции целевого процессора, специальные средства отладки взаимодействующих задач, а иногда и средства моделирования.
Рисунок 3.1 - Время реакции различных систем на прерывание.
3.2.2 Время реакции системы.
Почти все производители систем реального времени приводят такой параметр, как время реакции системы на прерывание (interrupt latency) [7].
В самом деле, если главным для системы реального времени является ее способность вовремя отреагировать на внешние события, то такой параметр, как время реакции системы является ключевым.
Поймем, какие времена мы должны знать для того, чтобы предсказать время реакции системы.
События, происходящие на объекте, регистрируются датчиками, данные с датчиков передаются в модули ввода-вывода (интерфейсы) системы. Модули ввода-вывода, получив информацию от датчиков и преобразовав ее, генерируют запрос на прерывание в управляющем компьютере, подавая ему тем самым сигнал о том, что на объекте произошло событие. Получив сигнал от модуля ввода-вывода, система должна запустить программу обработки этого события [7].
Интервал времени от события на объекте и до выполнения первой инструкции в программе обработки этого события и является временем реакции системы на события, и, проектируя систему реального времени, разработчики должны уметь вычислять этот интервал.
Время выполнения цепочки действий – от события на объекте до генерации прерывания – никак не зависит от операционных систем реального времени и целиком определяется аппаратурой, а вот интервал времени от возникновения запроса на прерывание и до выполнения первой инструкции обработчика определяется целиком свойствами операционной системы и архитектурой компьютера. Причем это время нужно уметь оценивать в худшей для системы ситуации, то есть в предположении, что процессор загружен, что в это время могут происходить другие прерывания, что система может выполнять какие-то действия, блокирующие прерывания [7].
Неплохим основанием для оценки времен реакции системы могут служить результаты тестирования с подробным описанием архитектуры целевой системы, в которой проводились измерения, средств измерения и точным указанием, какие промежутки времени измерялись. Некоторые производители операционных систем реального времени результаты такого тестирования предоставляют. Их не увидишь в рекламных проспектах, но можно отыскать на WEB-страницах, в документах технической поддержки, в публикациях фирм, проводящих независимое тестирование.