
- •Введение
- •Глава 1. Основные принципы организации операционных систем реального времени
- •1.1. Общие положения и определения
- •1.2. Отличие механизма современных осрв
- •1.3. Параметры осрв
- •1.4. Программное обеспечение многозадачности ос
- •1.5. Архитектура осрв. Классы осрв
- •1.6. Синхронизация задач
- •1.7. Базовые понятия программного обеспечения реального времени
- •1.8. Асинхронный обмен данными
- •1.9. Надежность систем реального времени
- •1.10. Планирование задач
- •1.11. Планирование периодических процессов
- •1.12. Взаимоблокировки
- •Контрольные вопросы
- •Глава 2. Типовые операционные системы реального времени
- •2.1. Обзор систем реального времени
- •2.2. Операционная система Windows nt
- •2.2.1. Ужесточение требований к ос 90-х годов
- •2.2.2. Операционные системы реального времени и Windows nt
- •2.2.3. Процессы и потоки nt
- •2.2.4. Пути расширения реального времени для nt
- •2.2.5. Обработка прерываний и исключений
- •2.2.6. Особенности системы ввода/вывода системы nt
- •2.2.7. Windows nt как операционная система реального времени
- •2.2.8. Расширения Windows nt
- •2.3. Операционная система qnx
- •2.3.1. Общие положения
- •2.3.2. Системная архитектура qnx
- •2.3.3. Qnx как сеть
- •2.3.5. Оконная система Photon microGui
- •2.3.6. Phocus 4 для создания встраиваемых scada
- •2.4. Операционные системы реального времени для встраеваемых систем
- •2.5. Ос рв для встраиваемых модулей от компании Microsoft
- •2.6. Функциональные потребности scada-системы
- •Контрольные вопросы
- •Глава 3. Общий анализ контроллеров
- •3.1. Аппаратное обеспечение
- •3.2. Программирование plc
- •3.3. Выбор контроллерных средств
- •3.4. Классификация современных контроллеров
- •3.5. Взаимодействие компонентов
- •3.6. Проектирование распределенных систем управления
- •3.7. Открытая модульная архитектура контроллеров
- •3.8. Архитектура производственной базы данных реального времени
- •3.9. Эволюция стандарта pci для жестких встраиваемых приложений
- •3.11. Одно- и многоуровневые системы диспетчерского контроля и управления
- •3.12. Технологии и протоколы передачи данных в промышленности: Industrial Ethernet
- •3.13. Обеспечение надежности асу тп с использованием резервированного кольца Turbo Ring
- •3.14. Анализ архитектур контроллеров с параллельной шиной
- •3.15. Повышенные требования к устойчивости функционирования
- •Контрольные вопросы
- •Глава 4. Примеры реализации типовых контроллеров
- •4.1. Промышленные контроллеры для автоматизации технологических процессов
- •4.2. Модули adam-8000 от компании Advantech9 и система программирования adam-winplc7
- •4.3. LabView Real-Time LabView реального времени
- •4.4. Встраиваемые системы и ос для них
- •4.5. Промышленный контроллер р-130isa
- •4.6. Совместное использование hmi и pac
- •4.7. Система Реального Времени cf-mntr
- •4.8. Экономичные контроллеры Pico
- •4.9. RapidIo: технология для приложений реального времени
- •4.10. Trace mode 6 и t-factory 6: обзор исполнительных модулей
- •4.11. Контроллер Crestron cp2e
- •4.12. Асу тп на базе контроллеров micro-pc
- •4.14. Itv ndc-f18 – универсальные контроллеры ndc-f18
- •4.15. Сетевой контроллер компании Lenel для систем контроля доступа
- •4.16. Сетевой контроллер реального времени
- •Контрольные вопросы
- •Глава 5. Мультимедийные системы реального времени
- •5.1. Требования реального времени в системах мультимедиа
- •5.2. Требования к архитектуре мультимедиа-систем
- •5.3. Объединение графического и мультимедийного ядра в систему Freescale
- •5.5. Scsa: архитектура для систем мультимедиа реального времени
- •Контрольные вопросы
- •Заключение
- •Рекомендуемый библиографический список
- •Оглавление
- •Глава 1. Основные принципы организации операционных систем реального времени 6
- •Глава 2. Типовые операционные системы реального времени 55
- •Глава 3. Общий анализ контроллеров 179
- •Глава 4. Примеры реализации типовых контроллеров 236
- •Глава 5. Мультимедийные системы реального времени 292
- •Системы реального времени Программно-технический комплекс
- •346428, Г. Новочеркасск, ул. Просвещения, 132
1.9. Надежность систем реального времени
Для СРВ критерии надежности определяются факторами:
– защита кода ОС от воздействия процессов пользователя;
– защита одних процессов пользователя от других;
– защита свободных ресурсов системы от процессов пользователя (ограничение максимальной емкости ресурсов для процессов);
– наличие встроенных средств сигнализации и обработки внештатных (исключительных) ситуации.
Рассмотрим более подробно перечисленные выше факторы.
Под «воздействием» процесса понимается группа операций, которые как правило включает любая программа:
– чтение данных из памяти;
– запись данных в память;
– чтение данных из порта ввода/вывода;
– запись данных в порт ввода/вывода;
– прочие инструкции процессора (арифметические операции, команды ветвления, и т.д.).
Произвольное чтение из памяти может нарушить конфиденциальность информации. Попытка чтения данных по несуществующему адресу более опасна, поскольку она может привести к аварийному останову системы.
Возможность записи по произвольному доступу несет в себе серьезную угрозу, поскольку может повлечь разрушение рабочих таблиц или исполняемого кода ОС, что приведет к её аварийному останову. В результате записи в память могут быть разрушены данные в кэше файловой системы, что приведет к разрушению данных на устройстве долговременной памяти. Система должна регламентировать адресное пространство, доступное процессам, и уметь безопасно обрабатывать возникающие ошибки, связанные с некорректным доступом к памяти.
Произвольный доступ на чтение из порта ввода/вывода может привести к конфликтам между процессами. Так, если один процесс уже читает данные из порта и другой процесс начинает читать данные из этого же порта, первый процесс потеряет те данные, которые прочитает второй, а попытка чтения из несуществующего порта может привести к аварийному останову или зависанию системы.
Запись данных в порт ввода/вывода более опасна, поскольку одновременная попытка записи данных в порт двумя процессами влечет выдачу непредсказуемой команды устройству, что в свою очередь приводит к его выходу из строя. При этом ОС реализует механизм распределения прав доступа к портам ввода/вывода.
Для исключения вредного влияния прочих программных инструкций ОС должна регламентировать использование специальных команд (маскировка прерываний), либо обеспечивать режим эмуляции маскировки прерываний, а также обрабатывать ошибки выполнения арифметических инструкций.
1.10. Планирование задач
Необходимость планирования задач появляется, как только в очереди активных (готовых) задач появляется более одной задачи (в многопроцессорных системах – более числа имеющихся процессоров). Алгоритм планирования задач является основным отличием СРВ от "обычных" ОС. В последних целью планирования является обеспечение выполнения всех задач из очереди готовых задач, не допуская монополизацию процессора какой-либо из задач. В ОСРВ же целью планирования является обеспечение выполнения каждой готовой задачи к определенному моменту времени, при этом часто "параллельность" работы задач не допускается, поскольку тогда время исполнения задачи будет зависеть от наличия других задач.
Важнейшим требованием при планировании задач в ОСРВ является предсказуемость времени работы задачи. Это время не должно зависеть от текущей загруженности системы, количества задач в очередях ожидания (процессора, семафора, события) и т.д. При этом желательно, чтобы длина этих очередей не была бы ограничена (т.е. ограничена только объемом памяти, доступной системе).
Планировщик задач (scheduler) – это модуль (программа), отвечающий за разделение времени имеющихся процессоров между выполняющимися задачами, за коммутацию задач из состояния блокировки в состояние готовности, за выбор задачи (задач – по числу процессоров) из числа готовых для исполнения процессором (ами).
Ключевым вопросом планирования является выбор момента принятия решения:
а) когда создается новый процесс, необходимо решить, какой процесс запустить, родительский или дочерний. Поскольку оба процесса находятся в состоянии готовности, эта ситуация не выходит за рамки обычного и планировщик может запустить любой из двух процессов;
б) когда процесс завершает работу. Этот процесс уже не существует, следовательно, необходимо из набора готовых процессов выбрать и запустить следующий;
в) когда процесс блокируется по какой-либо причине, необходимо выбрать и запустить другой процесс;
г) решение по диспетчеризации должно приниматься после разблокировки процесса;
д) планировщик может принимать решение по истечении кванта времени, отпущенного процессу.
Алгоритмы планирования можно разделить на две категории согласно их поведению после прерываний. Алгоритмы планирования без переключений, иногда называемого также неприоритетным планированием, выбирают процесс и позволяют ему работать вплоть до блокировки либо вплоть до того момента, когда процесс сам не отдаст процессор. После обработки прерывания таймера управление всегда возвращается приостановленному процессу.
Алгоритмы планирования с переключениями, называемого также приоритетным планированием, выбирают процесс и позволяют ему работать некоторое максимально возможное время. Если к концу заданного интервала времени процесс все еще работает, он приостанавливается и управление переходит к другому процессу. Приоритетное планирование требует прерываний по таймеру, происходящих в конце отведенного периода времени (решения планирования могут, например, приниматься при каждом прерывании по таймеру или при каждом k-ом прерывании), чтобы передать управление планировщику.
Существуют несколько схем назначения приоритетов.
Фиксированные приоритеты – приоритет задаче назначается при ее создании и не меняется в течение ее жизни. В схемах планирования ОСРВ требуется, чтобы приоритет каждой задачи был уникальным, поэтому часто ОСРВ имеют большое число приоритетов (обычно 255 и более).
Турнирное определение приоритета – приоритет последней исполнявшейся задачи понижается.
Приоритет по алгоритму round robin – приоритет задачи определяется ее начальным приоритетом и временем ее обслуживания. Чем больше задача обслуживается процессором, тем меньше ее приоритет (но не опускается ниже некоторого порогового значения). Эта схема применяется в большинстве UNIX систем. В разных системах различные алгоритмы планирования задач могут вводить новые схемы изменения приоритетов, так в системе OS-9 приоритеты ожидающих задач увеличиваются для избежания слишком больших времен ожидания.
Возможные типы алгоритмов диспетчеризации.
«Первым пришел – первым обслужен» (алгоритм FIFO). Является алгоритмом планирования без переключений. Процессам предоставляется доступ к процессору в том порядке, в котором они его запрашивают. При FIFO диспетчеризации процесс продолжает выполнение, пока не наступит момент, когда он:
добровольно уступает управление;
вытесняется процессом с более высоким приоритетом.
При отсутствии второго условия возможен случай, когда высокоприоритетная задача будет ждать окончания работы низкоприоритетной.
«Кратчайшая задача–первая». Этот алгоритм без переключений предполагает, что временные отрезки работы известны заранее. В этом алгоритме первым выбирается самая короткая задача. Данная схема работает только в случае одновременного наличия задач.
«Наименьшее оставшееся время выполнения». Является версией предыдущего алгоритма с переключениями. В соответствии с этим алгоритмом планировщик выбирает процесс с наименьшим оставшимся временем выполнения. В этом случае необходимо знать заранее время выполнения каждого процесса. Когда поступает новый процесс, его время выполнения сравнивается с оставшимся временем выполнения текущего процесса. Если время выполнения нового процесса меньше, текущий процесс приостанавливается и управление передается новому процессу. Это позволяет быстро обслуживать короткие процессы.
|
Рис. 1.9. Карусельная диспетчеризация. Процесс A выполняется до тех пор, пока он не использовал свой квант времени; затем выполняется следующий процесс, находящийся в состоянии готовности (процесс B). |
1.10. Адаптивная диспетчеризация. Процесс A использовал свой квант времени; его приоритет снизился на 1. Выполняется следующий процесс в состоянии готовности (процесс B)
вытесняется процессом с более высоким приоритетом;
использовал свой квант времени (timeslice). После того, как процесс использовал свой квант времени, управление передается следующему процессу, который находится в состоянии готовности и имеет тот же уровень приоритета.
«Адаптивная диспетчеризация». При адаптивной диспетчеризации (рис. 1.10) процесс ведет себя следующим образом:
Если процесс использовал свой квант времени (он не блокировался), происходит снижение приоритета (priority decay) (его приоритет уменьшается на 1). "Пониженный" процесс не продолжает "снижаться", даже если он использовал еще один квант времени и не блокировался – он снизится на один уровень ниже своего исходного приоритета.
Если процесс блокируется, то ему возвращается первоначальное значение приоритета.