Какие компьютеры могут быть отнесены к системам реального времени

Обновлено: 07.07.2024

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

Системы реального времени и встраиваемые системы работают в «стесненных» условиях, когда объем памяти и мощность процессора ограничены. Они должны обеспечивать работоспособность служб для пользователей и окружающего мира, с которым они взаимодействуют, в строгих временных рамках. Именно ограничения по времени, памяти и скорости навязывают использование ОС реального времени во встраиваемом программном обеспечении (ПО).
Ниже мы рассмотрим ядро ОС — часть операционной системы, предоставляющей большинство основных служб (функций) для прикладного программного обеспечения, работающего на процессоре. Обычно в службы ядра входят:
• распределение времени между задачами прикладного ПО;
• взаимодействие и синхронизация между задачами;
• динамическое распределение памяти ОЗУ (RAM);
• службы таймеров.

Ядро операционной системы реального времени (RTOS — Real-time Operating System) является абстрактным уровнем, скрывающим от прикладного ПО аппаратные особенности процессора (или набора процессоров), на котором прикладное ПО будет работать. Это обеспечивается за счет предоставления прикладному ПО доступа к пяти основным категориям базовых служб (функций) (см. рис. 1).


Рис. 1. Основные службы, предоставляемые ядром ОС реального времени Device I/O supervisor — управление задачами ввода/вывода

Наиболее общая категория служб ядра — это категория «управление задачами». Эта группа позволяет разработчикам прикладного ПО проектировать программные продукты как набор различных «частей» («chunks») — каждая часть содержит отдельную тему, отдельную цель, и, возможно, свое собственное ограничение по реальному времени выполнения. Такая отдельная часть ПО называется задачей. Службы из этой категории позволяют запускать задачи и присваивать им приоритеты выполнения. Основная служба RTOS в этой категории — это служба планирования задач (служба распределения задач по времени) во время работы встраиваемой системы. Эта служба контролирует выполнение задач прикладного ПО, и заставляет работать их своевременно и управляемо. (Позже мы рассмотрим в деталях, как это происходит.)
Вторая категория служб — это категория «взаимодействие и синхронизация между задачами». Эти службы организуют передачу информации между задачами, исключая опасность ее искажения. Они также позволяют координировать задачи для их более эффективного взаимодействия между собой. Без поддержки этих служб RTOS задачи смогут передавать искаженную информацию или мешать друг другу. Так как ко множеству встраиваемых систем предъявляют строгие требования по времени, большинство ядер RTOS также позволяют использовать некоторые основные таймерные службы, такие как тайм-ауты и задержки выполнения задач.
Многие (но не все) ядра RTOS поддерживают работу со службами динамического распределения памяти. Эта категория служб позволяет задачам «заимствовать» блоки памяти ОЗУ для временного использования в прикладном ПО. Зачастую эти блоки памяти затем переходят от задачи к задаче, посредством чего и передаются большие объемы данных между ними. В некоторых очень маленьких RTOS-ядрах, предназначенных для сильно ограниченной по объемам памяти среды, служб динамического распределения памяти нет.
Большинство (но опять же, не все) RTOS-ядер поддерживает также категорию служб по управлению устройствами ввода/вывода. Эти службы предоставляют унифицированную структуру для планирования и доступа к многочисленным аппаратным драйверам устройств, типичным для встраиваемых систем.
В добавление к службам ядра многие ОС реального времени предлагают набор необязательных подключаемых компонентов ОС для служб высокого уровня, таких как организация файловой системы, передача данных через сеть, управление сетями, управление базами данных и графический интерфейс пользователя. Также многие из этих добавочных компонентов занимают намного больший объем памяти и являются более сложными по сравнению с ядром RTOS; они опираются на ядро ОС и используют его базовые службы. Для уменьшения потребляемой памяти каждая из этих добавочных компонентов включается во встраиваемую систему только при необходимости.
В данной статье мы рассмотрим основные службы ядра ОС реального времени для решения проблем по управлению задачами, динамическому выделению памяти, взаимодействию и синхронизации между задачами.

Распределение задач по времени (планирование выполения)


Рис. 2. Пример работы планировщика с приоритетным прерыванием работы


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

Время, уходящее на переключение задач, представляет интерес при оценке операционной системы. Простая универсальная (без приоритетных прерываний) ОС позволяет переключать задачи только в моменты времени, отсчитываемые таймером. Единица отсчета может равняться десяти миллисекундам. Следовательно, если появится необходимость в переключении задачи где-нибудь в пределах десятимиллисекундного окна, фактическое переключение сможет произойти только по окончании текущего периода. Подобная задержка недопустима в большинстве встраиваемых систем реального времени.
В более сложных планировщиках с приоритетным прерыванием работы необходимо производить поиск в очередях задач для определения той, которую требуется запустить. Если просматриваемых задач много, поиск займет больше времени. Подобные операции поиска предусмотрены зачастую в универсальных ОС, что делает их недетерминированными. Операционные среды реального времени, с другой стороны, избегают этого, используя пошагово обновляемые таблицы, что позволяет планировщику идентифицировать задачу, которая должна выполняться следующей, за фиксированный короткий промежуток времени.
Для универсальных (не реального времени) ОС, время, затрачиваемое на переключение, как правило, возрастает с добавлением новых задач, требующих управления (см. рис. 3). Однако, фактическое время, затрачиваемое на переключение, не равняется времени, показанному на рисунке 3 наклонной пунктирной линией. Вместо этого, для любого рассматриваемого примера переключения оно может быть намного дольше или напротив, короче. Закрашенные области, окружающие наклонную пунктирную линию, показывают вероятность попадания фактического времени переключения задач в области над или под ней.
Горизонтальная сплошная линия характеризует время переключения ОС реального времени. Она постоянно и не зависит от нагрузки — количества задач в системе программного обеспечения.
Следует отметить, что в некоторых случаях, относящихся в крайней левой области рисунка, время переключения для универсальных ОС может быть меньше, чем для ОС реального времени. Это не снижает «пригодность» ОС реального времени для встраиваемых приложений реального времени. Ибо, по существу, термин «реальное время» не означает «как можно быстрее». Скорее, реальное время требует последовательных, повторяемых, заранее известных временных характеристик. Хотя универсальная ОС может иногда осуществлять быстрые переключения при небольшом количестве задач, в следующий раз при переключении тех же задач она может выдать большую задержку. Достоинство RTOS в ее заранее известных, повторяемых временных характеристиках, которые, к тому же, обычно лучше, чем у недетерминированного планировщика в случаях большого числа задач в системе программного обеспечения. ОС реального времени показывает намного меньшие времена переключения чаще, чем ее конкурент — ОС не реального времени, при количестве задач больше 5…10.



Вопрос детерминированности времени в службах ОС возникает и в области динамического распределения памяти ОЗУ (RAM). Многие универсальные ОС используют для динамического размещения данных область памяти, называемую «кучей» (heap). Распространенные функции (службы) malloc и free, известные Си-программистам, работают, используя именно этот подход. Задачи могут временно заимствовать память из «кучи» операционной системы, вызывая malloc и указывая треуемый объем. После завершения этой (или другой) задачей работы с выделенной памятью, она может быть возвращена операционной системе функцией free. После этого операционная система вернет ее в heap, где она, возможно, будет использоваться как часть другого блока — возможно, большего объема, или напротив, разбита на более мелкие части.
На память, выделяемую под heap, влияет так называемый эффект «фрагментации внешней памяти» (external memory fragmentation), который может привести к ухудшению работы служб, управляющих «кучей». Дробление связано с тем, что при возвращении блока памяти в «кучу» он при последующем вызове функции malloc и соответствующем задании требуемого объема может быть разбит на более мелкие куски. После выполнения многих циклов malloc и free между используемыми блоками могут появиться маленькие «полоски» памяти. Они настолько малы, что являются бесполезныи для задач. Но «полоски» располагаются между блоками памяти, используемыми задачами, что приводит к невозможности объединения («склеивания») блоков в большие объемы памяти. Со временем в «куче» будет все больше и больше таких «полосок». Это в конечном счете приведет к ситуаци, при которой задачи попытаются зарезервировать блок памяти определенного объема (malloc), а ОС откажет им в этом — даже несмотря на наличие необходимого объема памяти в «куче».


Проблема фрагментации может быть решена с помощью дефрагментирующего ПО, реализующего алгоритм, называемый «сборка мусора» (garbage collection). К сожалению, зачастую это абсолютно недетерминированный алгоритм — он вносит в управление «кучей» беспорядочно возникающие задержки случайной длины. Подобную ситуацию можно часто наблюдать при работе служб динамического распределения памяти в универсальных ОС.
С другой стороны, ОС реального времени избегают реализации этого алгоритма и временных последствий его применения, предлагая нефрагментируемые схемы распределения памяти вместо «кучи». Они обходят фрагментацию памяти, ограничивая размер блоков памяти, доступных для прикладного ПО. Несмотря на то, что данный подход не столь гибок, как схема с применением «кучи», он позволяет избежать дробления внешней памяти и необходимости ее дефрагментации. К примеру, схема распределения буферной памяти (pools memory) позволяет прикладному программному обеспечению использовать блоки памяти от четырех до восьми различных размеров для каждого буфера. Подобная схема полностью исключает возможность дробления внешней памяти, т.к. не предусматривает в будущем деления возвращенного буфера на более мелкие части. Вместо этого при освобождении буфера он помещается в список свободных блоков буферной памяти прежнего размера, доступных в будущем для повторного использования (см. рис. 6). Память распределяется и перераспределяется с детерминированным, часто неизменным, временем.
Проблема детерминированности времени является основной при определении различий между универсальными ОС и ОС реального времени. Эта проблема прослеживается во многих составляющих частях ядер операционных систем, таких как планировщики задач, динамическое распределение памяти и передача информации между задачами. В то время как универсальные ОС в этих областях зачастую используют недетерминированные службы, в этой статье были описаны полностью детерминированные решения. OSE является примером ОС, реализующей все описанные решения в компактном высокопроизводительном ядре.
Детерминированность времени особенно важна во встраиваемых системах реального времени, применяемых в бортовых вычислительных машинах, медицинских системах и системах связи.

Узнайте о влиянии систем реального времени на приложения интернета вещей в разных отраслях от производства до здравоохранения, нефтегазовой промышленности и робототехники.

Основные выводы

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

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

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

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

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

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

Потребность в системах реального времени

Расширение глобальных связей, изменение требований потребителей к постоянно доступным данным и постоянно работающим системам и появление корпоративных сред с сенсорными возможностями вызывают необходимость создавать, собирать и анализировать экспоненциально растущие объемы данных. По оценкам IDC, к 2025 году в мире будет создано 79,4 1 зеттабайт данных, и почти 30 процентов 2 этих данных нужно будет обрабатывать в реальном времени с помощью систем реального времени.

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

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

Содержание

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

Принято различать системы мягкого (soft) и жесткого (hard) реального времени. Жесткая ОС реального времени имеет меньше джиттера [Источник 2] . , чем мягкая операционная система реального времени.В системах жесткого реального времени неспособность обеспечить реакцию на какие-либо события в заданное время ведет к отказам и невозможности выполнения поставленной задачи. В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем. При практическом применении время реакции должно быть минимальным. Системами мягкого реального времени называются системы, не попадающие под определение "жесткие", т.к. в литературе четкого определения для них пока нет. Системы мягкого реального времени могут не успевать решать задачу, но это не приводит к отказу системы в целом. В системах реального времени необходимо введение некоторого директивного срока (в англоязычной литературе – deadline), до истечения которого задача должна обязательно (для систем мягкого реального времени – желательно) выполниться. Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.

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

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

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

Отличительные черты RTOS

Таблица сравнения операционных систем реального времени (ОСРВ) и обычных операционных систем.

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

Архитектура

Cтруктура ОСРВ эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер:

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

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

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

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

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

Важной частью любой ОСРВ является планировщик задач, чья функция - определить, какая из задач должна выполняться в системе в каждый конкретный момент времени. К основным методам планирования обычно относят: циклический алгоритм (в стиле round robin), разделение времени с равнодоступностью (time sharing with fairness), кооперативную многозадачность. Наиболее часто используемый в ОСРВ принцип планирования - приоритетная многозадачность с вытеснением. Основная идея состоит в том, что высокоприоритетная задача, как только для нее появляется работа, немедленно прерывает (вытесняет) низкоприоритетную. Однако диапазон систем реального времени весьма широк, начиная от полностью статических систем, где все задачи и их приоритеты заранее определены, до динамических систем, где набор выполняемых задач, их приоритеты и даже алгоритмы планирования могут меняться в процессе функционирования. Существуют, например, системы, где каждая отдельная задача может участвовать в любом из трех алгоритмов планирования или их комбинации (вытеснение, разделение времени, кооперативность). Кроме того, приоритеты тоже можно назначать по-разному. В общем случае алгоритмы планирования должны соответствовать критериям оптимальности функционирования системы. Однако, если для систем жесткого реального времени такой критерий очевиден , то для систем мягкого реального времени это может быть, например, минимальное максимальное запаздывание или средневзвешенная своевременность завершения операций. В зависимости от критериев оптимальности могут применяться алгоритмы планирования задач, отличные от рассмотренных. Например, может оказаться, что планировщик должен анализировать момент выдачи критичных по времени управляющих воздействий и запускать на выполнение ту задачу, которая отвечает за ближайшее из них (алгоритм earliest deadline first, EDF).

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

Планирование задач

Работа планировщика

Планировщик задач - это модуль (программа), отвечающий за разделение времени имеющихся процессоров между выполняющимися задачами. Отвечает за коммутацию задач из состояния блокировки в состояние готовности, и за выбор задачи (задач - по числу процессоров) из числа готовых для исполнения процессором. Наиболее часто используемый в ОСРВ принцип планирования - приоритетная многозадачность с вытеснением . Каждой задаче в приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путём реализации подхода приоритетного вытесняющего планирования (preemptive priority scheduling), суть которого в том, что высокоприоритетная задача, как только для нее появляется работа, немедленно прерывает (вытесняет) низкоприоритетную. Но из этого выходит, что если какая-то задача в высоким, которая использует все возможные ресурсы, то никакие другие задачи с низким приоритетом не будут выполняться до тех пор, пока этот процесс не прекратит свою работу. Таким образом, разработчикам нужно тщательно программировать свои приложения с учетом приоритетов. Каждый раз, когда планировщику задач получается сигнал о наступлении некоторого внешнего события ( триггер ), он действует по след алгоритму:

  1. Определяет, должна ли текущая выполняемая задача продолжать работать.
  2. Устанавливает, какая задача должна запускаться следующей.
  3. Сохраняет контекст остановленной задачи (чтобы она потом возобновила работу с места остановки).
  4. Устанавливает контекст для следующей задачи.
  5. Запускает эту задачу.

Выполнение задачи

В обычных ОСРВ, задача имеет три состояния

  • Выполняется
  • Готова к выполнению
  • Заблокирована

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

Алгоритмы планирования

В настоящее время для решения задачи эффективного планирования в ОСРВ наиболее интенсивно развиваются два подхода [Источник 5] ..

  • Статические алгоритмы планирования (RMS, Rate Monotonic Scheduling). Используют приоритетное вытесняющее планирование. Приоритет присваивается каждой задаче до того, как она начала выполняться. Преимущество отдается задачам с самыми короткими периодами выполнения.
  • Динамические алгоритмы планирования (EDF, Earliest Deadline First Scheduling). Приоритет задачам присваивается динамически, причем предпочтение отдается задачам с наиболее ранним предельным временем начала (завершения) выполнения.

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

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

Вытесняющее планирование с использованием круговой стратегии

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

Невытесняющее планирование на основе приоритетов

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

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

Вытесняющее планирование на основе приоритетов с точками вытеснения

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

Вытесняющее планирование на основе приоритетов с немедленным вытеснением

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

Взаимодействие между задачами и разделение ресурсов

Многозадачным системам необходимо распределять доступ к ресурсам. Одновременный доступ двух и более процессов к какой-либо области памяти или другим ресурсам представляет определённую угрозу. А именно Deadloc и Priority inversionСуществует три способа решения этой проблемы:

  • Временное блокирование прерываний
  • Двоичные семафоры
  • Посылка сигналов.

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

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

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

Распределение (Выделение) памяти

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

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

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

Операционные системы реального времени ОСРВ ( Real Time Operating Systems — RTOS ) относятся к программным средствам и предназна­чены для обслуживания цифровых систем в тех случаях , когда:

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

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

Принцип работы ОСРВ

При поступлении запроса производится проверка на входные данные для решения задачи. При их наличии задача начинает вы­полняться. ЕСЛИ необходимые входные данные отсутствуют, то ОСРВ переходит к следующей задаче (при наличии запроса на ее выполнение). Для получения входных данных и запуска соответствующей задачи используются прерывания. Запуск задачи обычно производится путем ее пересылки из очереди ожидающих задач в очередь задач, предназначенных для выполнения.

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

Требования к ОСРВ.

Современные ОС PB должны удовлетворять следующим требованиям:

● малое время отклика (получение результата);

● реализация многозадачного режима с гибким механизмом приоритетов;

● малый объем памяти (достаточный для размещения в резидентной памяти прикладной системы);

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

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

Типы ОСРВ

Можно выделить два типа ОСРВ:

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

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

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

Этот вид систем рассмотрим на при­мере системы OS–9 фирмы Microwave Systems . В качестве инструментально­го компьютера OS –9 использует IBM – PC , работающие в среде Windows , или рабо­чие станции Sun, HP, IBM RS /6000 с операционными системами типа UNIX . Характерные особенности OS –9:

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

● гибкость структуры, обеспечивающая реконфигурацию системы и расширение ее функциональных возможностей. Функциональные компоненты OS–9:

● ядро реального времени ( OS –9 kernel );

● общие средства ввода/вывода ( I / O man );

● средства разработки программ.

Функциональные компоненты OS –9 выполнены в виде автономных модулей, которые могут удаляться или добавляться с помощью простых команд, не требу­ющих повторной компиляции или перекомпоновки. Комбинируя модули, можно создавать целевые операционные системы с различными функциональными воз­можностями.

Рассмотрим Перечисленные выше функциональные компоненты.

Ядро реального времени

Система содержит два вида ядер:

● ядро Atomic , реализующее минимальное количество сервисных функций (ди­станционную загрузку, связь с локальной сетью, управление ведомыми микро­контроллерами). Ядро применяется в системах, встраиваемых в различную аппаратуру, имеет малый объем (24 Кбайт) и обеспечивает минимальное вре­мя отклика (3 мкс при тактовой частоте 25 МГц);

● ядро Standard , обеспечивающее выполнение широкого набора функций сер­виса и разработки прикладных программ, для реализации которых требуется больший объем памяти (до 512К байт ПЗУ и 38К байт ОЗУ). Путем изменения функциональных модулей ядра можно реализовать системы различной слож­ности и назначения: от встраиваемых в аппаратуру контроллеров с резидент­ным программным обеспечением и простейшими средствами ввода/вывода до сложно функциональных систем класса рабочих станций с развитой сете­вой поддержкой и обеспечением разнообразных функций сервиса, включая мультимедиа.

Система OS –9 предоставляет пользователю возможность выбора ядра в зави­симости от функционального назначения системы. Общие средства ввода/вывода. Физический интерфейс OS –9 с разно­образными внешними устройствами обеспечивается большим набором драйве­ров, созданных как фирмой Microwave Systems , так и многочисленными разработ­чиками аппаратуры, использующей эту операционную систему для конкретных приложений. Файловые менеджеры. К ним относятся модули, управляющие логичес­кими потоками данных. Каждый из модулей имеет определенное функциональное назначение и спецификацию. Файловые менеджеры можно разделить на три группы:

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

● сетевые и коммуникационные менеджеры, обеспечивающие работу OS –9 с различными сетями и обмен данными по каналам связи с наиболее распро­страненными стандартами протоколов обмена;

● менеджеры графического интерфейса и работы с мультимедиа–приложениями. Средства разработки программ. В составе OS –9 имеется пакет про­грамм (BSP) для поддержки плат развития, который обеспечивает совместную работу OS–9 с целым рядом SBC (Single Board Computer — одноплатный компью­тер). Совместное использование BSP и OS–9 позволяет сконфигурировать целе­вую систему для конкретного приложения.

Система OS–9 содержит средства поддержки программирования: компилято­ры Ultra C/C++, текстовый редактор ЕМ ACS , три вида (в том числе символьных) отладчиков, набор утилит для организации контроля и сборки программных продуктов. Помимо этого имеется большой набор (совместимых с OS –9) средств поддержки программирования, которые разработаны другими фирмами. Интегрированная среда разработки FasTra к. Среда FasTrak постав­ляется совместно с OS–9 и предоставляет пользователю наиболее полный комп­лект средств программирования и отладки. Часть программных средств FasTrak инсталлируется на инструментальном компьютере, а часть — на целевой системе пользователя. Среда FasTrak интегрирует все средства, необходимые для под­держки проектирования/отладки целевых систем. Версия среды FasTrak для ра­боты на инструментальном компьютере IBM – PC содержит:

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

● компиляторы Ultra C/C++;

● отладчики, обеспечивающие два режима отладки: пользовательский — для создания прикладных программ, и системный — для обслуживания прерыва­ний, системных вызовов и обращения к ядру реального времени;

● средства интерфейса с логическими анализаторами фирмы.

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

Фирма Microware Systems поставляет ряд системных пакетов, ориентирован­ных на различные сферы приложения:

● Wireless OS –9 — для разработки устройств беспроводной связи: сотовых те­лефонов, пейджеров, портативных цифровых ассистентов ( PDA );

● Internet OS –9 — для разработки устройств с доступом к сети Internet ;

● Digital Audio / Video Interactive Decoder ( DAVID ) OS –9 — для разработки распре­деленных систем цифрового интерактивного телевидения.

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

Особенности этого вида систем рассмотрим на примере системы VxWorks фирмы WindRiver Systems , предназна­ченной для работы с семействами микропроцессоров многих производителей. Система VxWorks инсталлируется на отлаживаемой целевой системе и работает совместно с интегрированной средой разработки Tornado , функционирующей на инструментальном компьютере. В качестве инструментального компьютера исполь­зуются IBM – PC , работающие в среде Windows , или рабочие станции SUN, HP и др. Краткое описание системы VxWorks. Нижним уровнем иерархической организации системы служит микроядро реального времени, выполняющее базо­вые функции планирования задач и управления их связью и синхронизацией. Ми­нимальный набор модулей ядра занимает 20–40К байт памяти. Все остальные функции — управление памятью, вводом/выводом, сетевым обменом и другие, реализуются дополнительными модулями. Для поддержки графических приложе­ний VxWorks располагает графическим интерфейсом VX–Windows.

● пакет программ для поддержки плат развития;

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

Для комплексной отладки целевых систем VxWorks обеспечивает интерфейс со схемными эмуляторами и эмуляторами ПЗУ. Интегрированная среда разработки Tornado . В состав Tornado вхо­дит система VxWorks 5.3, включающая ядро реального времени и системные биб­лиотеки, средства программирования, высокоуровневый отладчик и ряд других средств системы. Дополнительные средства среды Tornado обеспечивают управ­ление процессом отладки, визуализацию состояния целевой системы, другие сервисные функции. Открытая архитектура среды Tomado позволяет пользовате­лю подключать собственные специализированные инструментальные средства и расширять возможности стандартных средств.

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

Читайте также: