Операционная система реального времени что это

Терминологическое введение

Универсальные и специализированные операционные системы. Операционные системы реального времени

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

К классу операционных систем общего назначения относят операционные системы, которые могут являться как однопроцессными, так и многопроцессными, как многопользовательскими, так и однопользовательскими. Это операционные системы, которые работают в составе обычных настольных систем. Их основное предназначение состоит в том, чтобы предоставить пользователю системы удобный и понятный механизм управления аппаратными средствами вычислительной системы, обрабатывать запросы пользователя, максимально изолируя его от низкоуровневых операций и интерфейсов. Такие операционные системы ориентируются в первую очередь на простоту применения, поскольку их основными пользователями обычно являются не программисты, а пользователи средней или низкой квалификации. Зачастую такие пользователи могут даже не представлять, что за красивой картинкой анимированных обоев и разнообразием всевозможных красот графических интерфейсов скрывается мощнейший программный комплекс, управляющий всем аппаратным комплексом компьютера. К подобным операционным системам относятся настольные версии операционных систем семейства Windows, Linux, Apple iOS и т.д. Иными словами, это те операционные системы, с которыми пользователь может иметь дело как на работе для выполнения каких-то необходимых задач, так и дома для развлечения.

В противоположность операционным системам общего н назначения ОС специального назначения относительно редко используются в повседневной жизни. Основные пользователи таких операционных систем — квалифицированные разработчики. Подобные операционные системы предназначены для управления ресурсами специальных вычислительных систем. Зачастую такие системы являются встраиваемыми, т.е. системами, которые должны работать, будучи встроенными непосредственно в устройство, которым они управляют. К ним можно отнести такие операционные системы, как Android, iOS, Windows CE и т.д.

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

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

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

Использование операционных систем реального времени позволяет сократить сроки разработки управляющего ПО и повысить предсказуемость его поведения в следующих случаях;

если разработанное управляющее ПО получается достаточно большим по объему;

если в процессе его выполнения требуется нескольких вычисли- тельных потоков;

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

Для управления процессами в таких операционных системах используется один из двух подходов:

1) управление на основе приоритетов событий. При использовании данной стратегии управление передается тому процессу, который связан с обработкой наиболее приоритетного события;

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

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

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

Created on Jekyll by
Ruslan Kornev

Данный учебник является частью учебно-метолического комплекта для всех специальностей укрупненной группы «Информатика и вычислительная техника».

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

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

операционная система реального времени , осрв (англ. real-time operating system, RTOS) — тип операционной системы, основное назначение которой — предоставление необходимого и достаточного набора функций для работы систем реального времени на конкретном аппаратном оборудовании.

Спецификация UNIX в редакции 2 дает следующее определение:

Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определенный промежуток времени.

Хорошая ОСРВ имеет предсказуемое поведение при всех сценариях нагрузки, включая одновременные прерывания и выполнение потоков.

Что такое реальное время ? Отклик в реальном времени – это гарантированный отклик на событие в пределах определенного промежутка времени.

Детерминизм по времени – свойство процесса, описывающее характер выполнения операций во времени

Длительность итерации цикла (период цикла) – время, необходимое на выполнение одной итерации цикла

Джиттер – отклонение фактического времени итерации цикла от заданного

Встраиваемая ( embedded ) система – компьютерная система, которая, как правило, является частью большей системы. Встраиваемая система обычно работает без интерфейса пользователя (без монитора, клавиатуры, мыши).

Системы жесткого и мягкого реального времени

Операционные системы реального времени иногда делят на два типа — системы жесткого реального времени и системы мягкого реального времени .

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

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

Системы жесткого реального времени не допускают задержек реакции системы, так как это может привести к:

потере актуальности результатов;
большим финансовым потерям;
авариям и катастрофам.

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

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

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

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

Большинство программного обеспечения ориентировано на «мягкое» реальное время. Для подобных систем характерно:

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

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

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

Операционная система реального времени, ОС РВ (англ. Real-Time Operating System) — тип операционной системы, как правило, специального назначения. Для этого термина есть различные определения, порой противоречащие друг другу:

ОС, в которой успешность работы любой программы зависит не только от ее логической правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в ее работе
Стандарт POSIX 1003.1 дает определение: «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определенный промежуток времени»
ОС, реагирующая в предсказуемое время на непредсказуемое появление внешних событий
Интерактивные системы постоянной готовности. В категорию ОС РВ их относят исходя из маркетинговых соображений и если интерактивную программу называют «работающей в реальном времени», то это лишь означает, что запросы от пользователя обрабатываются с задержкой, незаметной для человека.
Иногда понятие системы реального времени отождествляют с «быстрой системой», но это не всегда правильно, так как важно не время задержки реакции ОС РВ, а то, чтобы этого времени было достаточно для рассматриваемого приложения и оно было гарантированно.
Во многих специализированных сферах вводят свои понятия «реального времени». Например, процесс цифровой обработки сигнала называют идущим в реальном времени, если анализ и/или генерация данных может быть произведен за то же время, что и анализ/генерация тех же данных без цифровой обработки сигнала. Например, если при обработке аудио данных требуется 2,01 секунд на анализ 2,00 секунд звука, то это не процесс реального времени. Если же требуется 1,99 секунд, то это процесс реального времени.

Для систем реального времени характерно следующее:

гарантированное время реакции на внешние события (например на прерывания от оборудования);
жесткая подсистема планирования процессов (высокоприоритетные задачи не должны вытесняться низкоприоритетными, за некоторыми исключениями);
повышенные требования к времени реакции на внешние события или реактивности (задержка вызова обработчика прерывания не более десятков микросекунд, задержка при переключении задач не более сотен микросекунд)

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

Виды ОСРВ

Динамические свойства программ реального времени принято характеризовать тремя определениями: программы «жесткого» (hard), «мягкого» (soft) и интерактивного («условного») реального времени.

Жесткое реальное время. Предусматривает наличие гарантированного времени отклика системы на конкретное событие, например, аппаратное прерывание, выдачу команды управления и т.п. Абсолютная величина времени отклика большого значения не имеет. Так, если необходимо, чтобы программа отработала некоторую команду за 1 миллисекунду, но она справляется с этим заданием лишь в 95% случаев, а в 5% не укладывается в норматив, такую систему нельзя охарактеризовать как работающую в жестком реальном времени. Если же команду нужно отработать в течение часа, что и происходит в 100% случаев – налицо жесткое реальное время.

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

Мягкое реальное время. В этом случае ожидающееся время отклика системы является величиной скорее индикативной, нежели директивной. Конечно, предполагается что в большинстве случаев (процентов 80 — 90) отклик уложится в заданные пределы. Однако и остальные варианты – в том числе полное отсутствие реакции системы – не должны приводить к плачевным результатам. Обычно считается, что если временной норматив превышен на один порядок, то это еще терпимо .

Интерактивное реальное время. Является скорее психологической, нежели технической характеристикой. Определяет время, в течение которого оператор – человек – способен спокойно, без нервозности, ожидать реакции системы на данные им указания. В качестве примера можно привести весьма популярные сегодня игры из категории «стратегии реального времени» (real-time strategy, см. например квазар на основе Warhammer).

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

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

Основные требования к ОСРВ

Мартин Тиммерман (директор компании-разработчика встраиваимых систем Dedicated Systems Experts) сформулировал следующие необходимые требования для ОС РВ:

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

Особенности архитектуры ОСРВ

В течение последних 25-30 лет структура операционных систем эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер. Эти решения в той или иной степени нашли применение и при разработке операционных систем реального времени.

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

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

Рис.1. Монолитная архитектура ОС РВ

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

Рис.2. Многослойная архитектура ОС РВ

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

Рис.3 Клиент-серверная архитектура ОС РВ

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

Отличие ОСРВ и Отличия от операционных систем общего назначения

Таблица сравнения ОСРВ и обычных операционных систем :

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

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

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

Операционные системы общего назначения

• Процессорное время делится между программами

• Операционные системы могут прерывать выполнение Виртуальных Приборов (ВП) с высоким приоритетом – Множество программ выполняются в фоновом режиме — заставки , дисковые утилиты, антивирусные программы и т. д. – Должны выполняться сервисные прерывания – от клавиатуры, мыши, сетевой карты ( Ethernet ) и т. д.

• Не могут гарантировать детерминизм по времени – недетерминированные системы

Операционные системы реального времени (ОСРВ)

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

• Не требуют взаимодействия с пользователем через периферийные устройства (клавиатуру, мышь и т. д. )

Lab. VIEW Real-Time может выполнять программы на следующих платформах :

• Целевые RT системы под управлением ОСРВ Venturcom Phar Lap Embedded Tool Suite (ETS)
• Компьютеры под управлением ПСРВ Venturcom Real-Time Extension (RTX) В этом курсе изучаются ETS платформы

• Сбор данных (ввод, вывод сигналов)

Анализ данных в режиме Offline

• Регулирование по замкнутому циклу

• Принятие решений критических по времени

• Длительная непрерывная работа

Архитектуры ОСРВ

В своем развитии ОСРВ строились на основе следующих архитектур:

Монолитная архитектура. ОС определяется как набор модулей, взаимодействующих между собой внутри ядра системы и предоставляющих прикладному ПО входные интерфейсы для обращений к аппаратуре. Основной недостаток этого принципа построения ОС заключается в плохой предсказуемости ее поведения, вызванной сложным взаимодействием модулей между собой.
Уровневая (слоевая) архитектура. Прикладное ПО имеет возможность получить доступ к аппаратуре не только через ядро системы и ее сервисы, но и напрямую. По сравнению с монолитной такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позволяет осуществлять быстрый доступ прикладных приложений к аппаратуре. Главным недостатком таких систем является отсутствиемногозадачности.
Архитектура «клиент-сервер». Основной ее принцип заключается в вынесении сервисов ОС в виде серверов на уровень пользователя и выполнении микроядром функций диспетчера сообщений между клиентскими пользовательскими программами и серверами — системными сервисами. Преимущества такой архитектуры:

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

Архитектуры операционных систем реального времени

Особенности ядра

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

Основные сервисы

Указанный абстрактный уровень предоставляет для прикладного ПО пять основных категорий сервисов :

Управление задачами. Самая главная группа сервисов. Позволяет разработчикам приложений проектировать программные продукты в виде наборов отдельных программных фрагментов, каждый из которых может относиться к своей тематической области, выполнять отдельную функцию и иметь свой собственный квант времени, отведенный ему для работы. Каждый такой фрагмент называется задачей. Сервисы в рассматриваемой группе обладают способностью запускать задачи и присваивать им приоритеты. Основной сервис здесь — планировщик задач. Он осуществляет контроль над выполнением текущих задач, запускает новые в соответствующий период времени и следит за режимом их работы.
Динамическое распределение памяти. Многие (но не все) ядра ОСРВ поддерживают эту группу сервисов. Она позволяет задачам заимствовать области оперативной памяти для временного использования в работе приложений. Часто эти области впоследствии переходят от задачи к задаче, и посредством этого осуществляется быстрая передача большого количества данных между ними. Некоторые очень малые по размеру ядра ОСРВ, которые предполагается использовать в аппаратных средах со строгим ограничением на объем используемой памяти, не поддерживают сервисы динамического распределения памяти.
Управление таймерами. Так как встроенные системы предъявляют жесткие требования к временным рамкам выполнения задач, в состав ядра ОСРВ включается группа сервисов, обеспечивающих управление таймерами для отслеживания лимита времени, в течение которого должна выполняться задача. Эти сервисы измеряют и задают различные промежутки времени (от 1 мкс и выше), генерируют прерывания по истечении временных интервалов и создают разовые и циклические будильники.
Взаимодействие между задачами и синхронизация. Сервисы данной группы позволяют задачам обмениваться информацией и обеспечивают ее сохранность. Они также дают возможность программным фрагментам согласовывать между собой свою работу для повышения эффективности. Если исключить эти сервисы из состава ядра ОСРВ, то задачи начнут обмениваться искаженной информацией и могут стать помехой для работы соседних задач.
Контроль устройства ввода-вывода. Сервисы этой группы обеспечивают работу единого программного интерфейса, взаимодействующего со всем множеством драйверов устройств, которые являются типичными для большинства встроенных систем.

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

Читать:

Gameguru руль как подключить

Особенности часов и таймеров операционных систем реального времени

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

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

Большинство ОСРВ оперируют относительным временем. Что-то происходит «до» и «после» некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа «ждать одну секунду», то нужен тактовый генератор и/или таймер.

Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не используется.

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

Особенности управления памятью в ОСРВ

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

Модель без защиты
— системное и пользовательское адресные пространства не защищены друг от друга, используется два сегмента памяти: для кода и для данных; при этом от системы не требуется никакого управления памятью, не требуется MMU (memory management unit – специальное аппаратное устройство для поддержки управления виртуальной памятью).
Модель защиты «система/пользователь»
– системное адресное пространство защищено от адресного пространства пользователя, системные и пользовательские процессы выполняются в общем виртуальном адресном пространстве, при этом требуется MMU . Об этом говорит сайт https://intellect.icu . Защита обеспечивается страничным механизмом защиты.
Различаются системные и пользовательские страницы. Пользовательские приложения никак не защищены друг от друга. Процессор находится в режиме супервизора, если текущий сегмент имеет уровень 0, 1 или 2. Если уровень сегмента – 3, то процессор находится в пользовательском режиме. В этой модели необходимы четыре сегмента – два сегмента на уровне 0 (для кода и данных) и два сегмента на уровне 3.
Механизм страничной защиты не добавляет накладных расходов, т.к. защита проверяется одновременно с преобразованием адреса, которое выполняет MMU; при этом ОС не нуждается в управлении памятью.
Модель защиты «пользователь/пользователь»
– к моделисистема/пользователь добавляется защита между пользовательскими процессами; требуется MMU.
Как и в предыдущей модели, используется механизм страничной защиты. Все страницы помечаются как привилегированные, за исключением страниц текущего процесса, которые помечаются как пользовательские. Таким образом, выполняющийся поток не может обратиться за пределы своего адресного пространства.
ОС отвечает за обновление флага привилегированности для конкретной страницы в таблице страниц при переключении процесса. Как и в предыдущей модели используются четыре сегмента.
Модель защиты виртуальной памяти
— каждый процесс выполняется в своей собственной виртуальной памяти, требуется MMU.
У каждого процесса имеются свои собственные сегменты и, следовательно, своя таблица описателей.
ОС несет ответственность за поддержку таблиц описателей. Адресуемое пространство может превышать размеры физической памяти, если используется страничная организация памяти совместно с подкачкой. Однако в системах реального времени подкачка обычно не применяется из-за ее непредсказуемости. Для решения этой проблемы доступная память разбивается на фиксированное число логических адресных пространств равного размера. Число одновременно выполняющихся процессов в системе становится ограниченным.

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

Если поддерживается страничная организация памяти (paging), соответствующее отображение страниц в физические адреса должно быть частью контекста процесса. Иначе опять появляется непредсказуемость, неприемлемая для ОСРВ.

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

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

В системах жесткого

Продолжение:

См.также

OpenSPARC
S1 Ядро
OpenRISC
ERC32
FeiTeng-1000
Мягкий микропроцессор
Адаптивный планировщик разделов
Сравнение операционных систем реального времени
DO-178B
Первое планирование на самый ранний срок
Операционная система, работающая с прерываниями
Планирование минимального перерыва в работе
POSIX
Скоростно-монотонное планирование
Данные General RDOS
Операционная система робота
SCADA
Синхронный язык программирования
Система с синхронизацией по времени
Функция полезности времени

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

Вся правда об ОСРВ от Колина Уоллса

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

Заглянув во внутрь ОСРВ, мы посмотрим, как работает планировщик задач. Благодаря многопоточности создается впечатление, что ЦП выполняет несколько операций одновременно. Это не магия, понимание принципов работы планировщика задач доступно даже неопытному инженеру-программисту. Мы поговорим и о других объектах ОСРВ: о взаимодействии между задачами и синхронизации, о режиме реального времени, об управлении памятью и т. д., все будет точно описано и подкреплено примерами кода.

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

Ниже список тем, которые мы рассмотрим в ближайшее время:

Однако, чтобы объяснить внутреннее устройство ОСРВ, используются примеры кода реального продукта – Nucleus SE.

Вся правда об ОСРВ. Статья #2

ОСРВ: Структура и режим реального времени
Структура программы и режим реального времени

Эта серия статей о встраиваемых системах и, в частности, о программном обеспечении, работающем во встраиваемых системах. Начнем с определения. Что же такое встраиваемая система? В 1986 году, когда я писал первую книгу на эту тему, такого термина еще не существовало. Использовались понятия «выделенная система» или «микросистема», но они, конечно, не отражали всей сути. Через несколько лет в обиход вошло слово «встраиваемая», и все специалисты стали активно его использовать.

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

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

Зачем вообще использовать операционную систему?

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

Другое объяснение кроется в использовании десктопных приложений. С чего вы начнете, если будете писать программное обеспечение для ПК или Mac? Вы включите компьютер, запустите Windows/Linux или macOS и начнете программировать. Наличие операционной системы – это заданное условие, и оно предоставляет ряд полезных сервисов. Навряд ли вы вздумаете начать с нуля, программируя «голое» железо. Поэтому неудивительно, если инженер, у которого есть опыт написания ПО, но для которого встроенное ПО в новинку, будет рассчитывать на наличие операционной системы в разрабатываемой им системе.

Стоит отметить ключевой аспект десктопной ОС, о котором знают пользователи, — пользовательский интерфейс (англ. User Interface, UI). Спросите у кого-нибудь, что такое Windows, и вам ответят, что это окна, меню, диалоговые окна, иконки, но вряд ли упомянут файловую систему, межпрограммную коммуникацию и способность взаимодействовать с другими системами. В этом основное отличие десктопной от встраиваемой системы: в последней может и не быть пользовательского интерфейса, а если он и есть, то он достаточно незамысловатый. Это первое из многих ключевых отличий:

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

Во-первых, существует выполнение программ в стиле DOS, когда программы выполняются поочередно.

Каждая программа запускается, реализуется и завершается. Мы используем, скажем, программу 1, затем программу 2, затем, возможно, сделаем перерыв, обратимся к программе 3, а потом снова вернемся к программе 2. Второе использование программы 2 начинается заново: запуск не начинается с того места, где мы остановились до этого (кроме тех случаев, когда приложение само не предоставляет такую возможность).

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

В таком режиме создается впечатление, что программы работают одновременно, и этой иллюзией управляет Windows. Сначала запускается программа 1, затем в то же время начинает работу программа 2, затем программа 3. Программа 2 завершается, программы 1 и 3 все еще работают. Программа 3 завершается, остается только программа 1. Позднее возобновляется программа 2, а программа 1 завершается, остается только программа 2. Это реалистичный ход событий при использовании Windows обычным пользователем. Операционная система распределяет ресурсы таким образом, чтобы все программы корректно использовали процессор. Это также обеспечивает простую коммуникацию между программами (например, буфер обмена) и управляет пользовательским интерфейсом.

Некоторым портативным устройствам требуется больше гибкости, чем может предложить DOS, но с учетом ограниченных ресурсов, требуются более низкие, чем у Windows, накладные расходы. В итоге, имеем выполнение программ в стиле iOS, а именно:

Программы запускаются поочередно, но их состояние автоматически сохраняется, чтобы можно было продолжить с этого же места при закрытии. Например, запускается программа 1, затем приостанавливается для использования программы 2, затем, например, устройство на какое-то время выключается. При возобновлении загружается программа 3 (состояние программы 2 сохранилось автоматически), а потом пользователь возвращается к программе 2, продолжая работу в ней. Я понимаю, что модель выполнения iOS приложения гораздо сложнее, чем описанное выше, тем не менее, это описание — лишь краткое изложение первичного восприятия пользователя.

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

Модели встраиваемых программ

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

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

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

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

Если требуется что-то посложнее, можно попробовать разместить некритичную по времени часть кода в основном цикле, а чувствительную ко времени — в обработчике прерываний (англ. Interrupt Service Routines, ISR). Действия обработчика прерываний в основном достаточно короткие, выполняющие только критически важные задачи и отмечающие участки основного цикла для завершения работы при первой же возможности. Трудности могут возникнуть, когда понадобится распределять работу между основным циклом и обработчиком прерываний (а также между несколькими разработчиками).

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

Что такое реальное время?

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

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

Если не выполняются временные ограничения системы, считается, что произошел системный сбой».

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

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

ОСРВ (при правильном использовании) обеспечивает очень точный контроль за распределением времени процессора на выполнение задач и, следовательно, делает приложения полностью детерминированными. Единственное, что может испортить эту картину, – это прерывания. Есть ОСРВ, которые полностью контролируют прерывания. Их работа заключается в том, чтобы управлять обслуживанием прерываний в рамках работы планировщика задач. Несмотря на то, что это должно было бы приводить к предсказуемому поведению, этот механизм достаточно сложно устроен и заключает в себе высокие накладные расходы.

Большинство ОСРВ просто позволяет обработчику прерываний «красть» время у задачи, запущенной в момент прерывания. Это, в свою очередь, вынуждает программиста писать код обработчика прерывания как можно короче. В результате имеем допустимую погрешность реального времени. Единственная сложность состоит в выполнении вызовов служб ОСРВ в рамках задачи-обработчика. Некоторые вызовы могут быть вполне безобидными, в то время как другие станут причиной переключения контекста при возврате из прерывания. Такая ситуация должна быть специально улажена, что возможно с помощью различных ОСРВ.

Когда мы работали над нашей собственной операционной системой реального времени ОСРВ МАКС (ранее уже публиковал статьи о ней), наша команда «наткнулась» на блог Колина Уоллса (Colin Walls), эксперта в области микроэлектроники и встроенного ПО компании Mentor Graphics. Статьи показались интересными, переводили их для себя, но, чтобы не «писать в стол» решили опубликовать. Надеюсь, они будут вам также полезны. Если так, то дальше планируем опубликовать все переведенные статьи серии.

ОСРВ: что такое операционная система реального времени

встроенные схемы печатных плат

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

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

Что такое ОСРВ?

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

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

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

Типы ОСРВ

Несколько тип операционные системы реального времени или RTOS:

Жесткий режим реального времени: это операционная система строгого режима реального времени, где ее процессы должны выполняться в определенное время.
Мягкое реальное время: гибкое реальное время, где при выполнении процессов иногда могут теряться почти ничтожные мгновения, то есть оно не такое строгое, как предыдущее. Кроме того, они сконструированы так, что эти временные ходы становятся все меньше.
Фирма в реальном времени: Твердые SSOO в реальном времени — это еще один тип, в котором время может быть потеряно, но поздние ответы не будут действительными.

Приложения RTOS

RTOS — это простая, легкая система, используемая для ограниченных или простых систем, таких как встроенные устройства. Это делает их идеальными для применения как:

промышленный контроль.
Переключение телефона.
Управление полетом.
Моделирование в реальном времени.
военные применения.
Бытовая техника.
Основные устройства бытовой электроники.
Роботы.
И т.д.

Характеристики ОСРВ

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

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

Если вам интересно, что Операционные системы RTOS существуют, правда в том, что их большое количество, как проприетарных, так и с открытым исходным кодом:
Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.

Полный путь к статье: Бесплатное оборудование » Общие » ОСРВ: что такое операционная система реального времени