Вопрос 48. Определение и основные особенности операционных систем реального времени.

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

Принцип построения: Различают сильные hart и слабые soft требования реального времени. Если запаздывание программы приводит к полному нарушению работы управляющей системы, то говорят о сильном реальном времени. Если это ведет только к потере производительности, то говорят о слабом реальном времени.

Стандарт POSIX 1003:1 описывает требования: Реальное время в ОС – это способность системы обеспечивать требуемый уровень сервиса за определенный промежуток времени. Иногда система реального времени вызывает систему постоянной готовности или интерактивную систему с достаточным временем реакции. Процесс цифровой обработки сигнала будет происходить в реальном времени, если анализ при вводе и генерация при выводе тех же данных, что и без цифровой обработки, будет происходить за то же время. Вычисление установки, на которых системы реального времени:

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

Промышленные компьютеры – состоят из одной платы, на которой размещены процессор, память, контроллеры шины, разъемы для подключения внешних устройств. VME или компакт PCI – в качестве шины. Отсутствует жесткий диск, в качестве памяти ОЗУ или flash. Плата в специализированном корпусе, в котором блок питания, подводят контакты шины. Используется для управления промышленным оборудованием. Нет клавиатуры и монитора.

Встраиваемая система – устанавливается внутри оборудования, которым управ­ляет.

Типы задач: •Циклические задачи (для процессов управ-ния) •Периодические задачи •Импульсные задачи

Типы архитектур: •Монолитная •Модульная •Объектная

Монолитную архитектуру можно представить в виде прикладного уровня, состоящего из системного уровня, который пред­ставляется монолитным ядром, в котором выделяется интерфейс между приложением и ядром, непосредственно ядром, ядром и оболочкой. Интерфейс управляет взаимодействием прикладных процессов и систем, обеспечивает непрерывность выполнения кода системы, т.е. отсутствия переключения задач во время выполнения кода системы, иначе выполнение запроса неограниченное количество времени. Достоинство состоит в относительной быстроте работы по сравнению с другими архитектурами за счет разработки системы на ASSEMBLER. Недостатки в том, что ядро не может быть прервано пользовательской задачей (невытесняющая многозадачность), и сложность переноса на новые архитектуры процессора.

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

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

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

Критерии выбора: •производительность •надежность •круглосуточная готовность •поддержка различных типов процессора •поддержка многопроцессорности •наличие средств разработки на различных языках

67аличние механизмов реального времени

Поддержка файловой системы

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

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

Все ОСРВ предоставляют приложениям определенный набор объектов синхронизации: •POSIX 1003: В определяет объекты синхронизации (должны присутствовать семафоры, очереди сообщений и разделяемая память). •POSIX 1003: С определяет объект синхронизации, которые присутствуют в системах, использующие задачи: MUTEX, COUDVAR. •Объект MUTEX представляет собой развитие семафоров, которые состоят из семафоров и идентификатора задач, который определяет текущего владельца.

Для доступа к MUTEX три операции: •lock – блокировать MUTEX. Если он заблокирован другой задачей, то эта операция переводит в состояние ожидания разблокирования. •unlock – разблокировать объект.

try lock – попробовать блокировать MUTEX, если MUTEX не заблокирован, то она эквивалентна lock.

Объекты MUTEX: •Локальные и доступные для синхронизации между потоками одного процесса. •Глобальные и доступные для синхронизации между потоками различных процессов.

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

Встроенные ОС (ВОС)

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

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

ВОС должна быть пригодна для переноса на другие аппаратные платформы. Достигается за счет разделения ОС на аппаратно-зависимую и аппаратно-независимую части. Аппаратно-зависимая часть пишется на assembler и при переносе на другую платформу полностью переписывается. Результатом стремления сделать эту часть как можно меньше стало микроядро. Аппаратно-независимая часть пишется на Си и включает выполнение алгоритмических функциях.

ВОС должна представлять собой унифицированный и стандартный интерфейс для прикладных программ (например, POSIX).

ВОС должна быть ОС реального времени.

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

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

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

ВОС должна иметь малый объем ядра.

Механизмы:

Начальная загрузка

Управление процессами (2 стандарта – вытесняющая многозадачность либо разделение по времени)

Механизм межпроцессорного взаимодействия (сообщения, сигналы, каналы и т.д.)

Управление памятью

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

Доступ к периферическим устройствам (поддержка специализированного интерфейса, посредством ввода-вывода, порты ввода-вывода)

Поддержка различных коммуникативных протоколов (должны поддерживать стандартные коммуникативные протоколы (изернет, Win 32, USB)

Аппаратура. APP – приложение пользователя

1 – механизм межпроцессорного взаимодействия 2 – планировщик выполнения задач 3 –управление памятью 4 – коммуникативные протоколы 5 – драйверы устройств 6 – начальный загрузчик 7 – обработчик прерываний 8 –подсистема ввода – вывода

Обзор ОС реального времени По способу разработки программного обеспечения:

1)Sell – HOSTED 2)HOST – TARGET

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

HOST – TARGET – это системы, в которых ОС или компьютер, на котором разрабатываются приложения, и ОС и компьютер, на котором запускаются приложения, различны.

В качестве HOST выступают обычные компьютеры Windows NT, а в качестве TARGET – промышленные компьютеры или встраиваемые компьютеры под управлением ОСРВ.

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

	CHORUS	QNX	RTS	VxWork
тип	HOST – TARGET	Sell – HOSTED	Sell – HOSTED и HOST – TARGET	HOST – TARGET
архитектура	микроядро	микроядро	монолитное ядро	монолитное ядро
стандарт	POSIX 1003 и свой собственный	POSIX 1003	свой собственный	POSIX 1003 и свой собственный
многопроцессорность	поддерживает	поддерживает	поддерживает	поддерживает
многозадач-ность	поддерживает вытесняющую многозадачность	поддерживает вытесняющую многозадачность	поддерживает вытесняющую полностью	поддерживает полностью
приоритет	поддерживает	уровни приоритетов 32	уровни приоритетов 65532	уровни приоритетов 256
ОС	своя собственная, Unix, Windows	– (нет сведений)	Unix, Windows	Unix, Windows
процессоры	Intel, Motorola, Spark, Power PC, MIPS, JMP (crazy), Alfa	Intel	Intel, Motorola, Intel 80С166 – микроконтроллер	Intel,Motorola, Spark, Power PC, MIPS, JMP (crazy), Alfa
линия связи	последовательный канал, изернет	последовательный канал, изернет	изернет	последовательный канал, изернет, линия UPD
размер (для ядра)	min 10 кб (микро), 50 кб – классический	– (нет сведений)	min 4 кб, 1, 5 кб	min 58 кб
средства разработки	своя собственная интегральная среда, включающая компилятор С/C++, отладчик	компилятор С/C++, разработанные под Unix, Windows	компилятор С, отладчик	компилятор С
алгоритм планирования	– (нет сведений)	FIFO, Round robin	планирование приоритетное и FIFO	– (нет сведений)