Что собой представляют операционные системы реального времени. Что такое операционные системы реального времени

(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.

При ограничен­ном объеме памяти целевой системы можно воспользоваться графической биб­лиотекой RTGL, которая содержит базовые графические примитивы, наборы шрифтов и цветов, драйверы типовых устройств ввода и графических контролле­ров. В состав VxWorks входят также различные средства поддержки разнообраз­ных сетевых протоколов. Трассировку заданных событий и их накопление в бу­ферной памяти для последующего анализа выполняют в реальном времени спе­циальные средства отладки, а трассировку системных событий - динамический анализатор WindView . Анализатор WindView работает аналогично логическому анализатору, отображая на экране временные диаграммы переключения задач, записи в очередь сообщений и другие процессы. Монитор данных Stethoscope позволяет анализировать динамическое изменение пользовательских и систем­ных переменных, включая в себя также профилировщик процедур. В составе VxWorks имеется:

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

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

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

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

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

Операционная система реального времени , ОС РВ (англ. 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 Клиент-серверная архитектура ОС РВ

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

Контрольные вопросы

1. Дайте определение операционной системы реального времени
2. Что такое deadline ?
3. В чем отличие «жесткого» реального времени от «мягкого»
4. Сформулируйте основные требования к ОС РВ
5. Укажите основные отличия в требованиях к ОС РВ от универсальных ОС
6. Опишите модульную архитектуру
7. Опишите многослойную архитектуру
8. Опишите клиент-серверную архитектуру

Постоянный адрес этой страницы:

Что такое реальное время (real-time)?

Существует несколько определений понятия реального времени, часто противоречащих друг другу, что не позволяет, к сожалению, принять единую терминологию. Близким к каноническому можно назвать следующее определение: «Система реального времени — это такая система, корректность работы которой зависит не только от выполнения неких заданий, но и от времени их выполнения. Если временные параметры задания нарушены — оно считается невыполненным». Дополнение к этому определению: «Следовательно, сама система должна иметь гарантированные временные параметры, т.е. поведение системы должно быть предсказуемым. Это позволяет минимизировать количество невыполненных (вследствие нарушения временных параметров) заданий».

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

Иногда системой реального времени называют интерактивную систему с малым временем отклика. Рассмотрим следующий пример: набор текста в программе WinWord 2.0 на компьютере с процессором Athlon 1GHz. Время отклика в данном случае — это промежуток времени между нажатием клавиши и отображением соответствующей буквы в окне программы. Кажется очевидным, что эта величина в данном случае не имеет значения — все равно человек печатает медленнее. Ошибка заключается в подмене понятий — высокая скорость отклика совсем не означает гарантированность отклика. Загружая компьютер большим количеством ресурсоемких задач, мы можем увеличивать время отклика до бесконечности. Проделай следующий опыт: поместив ярлыки всех установленных программ (желательно, чтобы среди них были такие монстрообразные приложения, как Borland Delphi, Microsoft Office, и пара-тройка 3D-шутеров) на рабочий стол Windows95 (желательно билд 450 или более ранний:), выдели их мышью и нажми Enter. После этого винда будет громыхать жестким диском, жонглируя данными между своп-файлом и памятью, и не реагируя на какие-либо внешние воздействия, пока ты не нажмешь кнопку Reset. Обычно этого достаточно, чтобы понять, что быстрая система — не обязательно система реального времени. С другой стороны, реальное время не означает скорость выполнения программы; более того, алгоритмы, гарантирующие конечное время отклика, часто менее эффективны, чем обычные.

В англоязычной литературе упоминаются «soft real-time systems» и «hard real-time systems», но в этом случае не подразумевается программная (software) или аппаратная (hardware) реализация системы реального времени. Термин hard означает, что время отклика (LT — latency time) жестко задано, т.е. является константой. Мягкая (soft) система реального времени (RTS — real-time system) может изменять LT, что увеличивает эффективность RTS, манипулирующей процессами с различными приоритетами. Например, для оцифровки одного кадра видеопотока достаточно LT=0.033с (30 кадров/сек), а для процесса управления сервоприводами необходимо достичь значения LT порядка десятков микросекунд. Иногда термином hard обозначают классическую (описанную выше) модель RTS, а термином soft — систему, не являющуюся RTS в чистом виде, но LT которой снижена до необходимого уровня, обеспечивающего требуемую скорость обработки данных. Например, если компьютер под управлением DOS обрабатывает данные с электронного осциллографа, то это — SoftRTS, т.к. DOS — однозадачная операционная система, и, при условии достаточной скорости компьютера и нормальной работы осциллографа, ничто не должно помешать нам обрабатывать данные с достаточной скоростью (но гарантировать этого мы не можем!). В многозадачных операционных системах также возможна реализация SoftRTS, причем применяемая обычно в мультимедийных приложениях и 3D-играх, т.к. они позволяют обеспечить требуемое LT путем ухудшения качества обработки данных (снижение битрейта, уменьшение FPS, изменение разрешения экрана и глубины цвета).

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

Понимание принципа действия и основных свойств операционных систем реального времени (RTOS — Real Time Operating System) требует введения таких базовых определений, как микроядро (microkernel) и макроядро (macrokernel).

Существует две основные школы ядростроителей (не смог подобрать более точного перевода для kernel
developers:): одна считает, что ядро операционной системы должно быть компактным и быстрым, а функциональность рассредоточена в процессах, другая проповедует более традиционный подход, предоставляя ядру все базовые функции ОС, а процессам — ничего, кроме возможности вызова этих самых функций. Для обозначения первого (по перечислению, а не по времени появления) типа архитектуры в 1989 году Ирой Голдштейн и Полом Дейлом был введен термин микроядро (microkernel). Первая (теперь — в хронологическом смысле) архитектура ядра (традиционная, или монолитная (monolithic), как ее называют в англоязычной литературе) получила название «макроядро» (что наглядно доказывает низкий уровень воображения у программистов, особенно системных).

Споры о том, какая архитектура лучше, идут до сих пор. Большинство реализаций ОС UNIX построены на макроядре, в том числе наиболее популярные на сегодняшний день — Linux и FreeBSD. На микроядре построены такие операционные системы, как Mach и QNX. Впрочем, некоторые системщики не относят Mach к микрокернелам по причине большого размера ядра (оно включает в себя драйвера устройств, что типично скорее для макрокернелов). С ядром QNX сложилась обратная ситуация — оно настолько мало (и по размеру, и по
функциональности), что пришлось ввести новый термин — наноядро (nanokernel). Думаю, что споры вокруг Mach можно было бы решить тем же путем, т.е. изменением терминологии — но, судя по всему, слова сантикернел и децикернел показались программистам недостаточно благозвучными. Следует понимать, что разграничение ОС на микроядра и макроядра производится вовсе не по размеру ядра, а по его архитектуре, т.е. по соотношению между количеством функций, реализованных в ядре, и функций, реализованных вовне ядра. Другие параметры (производительность, гибкость, работа в реальном времени) не могут быть признаками такого разграничения. Кроме того, граница между макрокернелами и микрокернелами становится все более размытой благодаря тому, что многие современные монолитные ядра содержат так называемые нити (threads) и обладают способностью к «мелкозернистому» распараллериванию (а как еще перевести fine-grained parallerism?). Архитектурно такие ядра подобны микрокернелам с большим количеством процессов, работающих в разделяемой (shared) памяти.

Возможность операционной системы работать в реальном времени в значительной степени определяется архитектурой ядра. Наиболее удобными в этом плане являются микроядра (собственно, для этого они и разрабатывались), но это не означает, что все микрокернелы работают в реальном времени (Mach — микроядро, не работающее в реальном времени, что вовсе не умаляет других достоинств этой операционной системы, породившей множество потомков, в том числе NeXTStep, Hurd, BeOS и MacOSX). Существование макрокернела с полноценной поддержкой работы в реальном времени все еще под вопросом (я не нашел никаких сведений о подобном проекте, кроме, разве что, Sun Solaris 2.x, но по моему мнению (не претендующему на компетентность), это скорее SoftRTS, а не HardRTS), а вот частичная реализация — обычное дело. Например, в Linux активно внедряются упоминавшиеся ранее межпроцессорные (от слова процесс, а не процессор) нити, причем уже существует большое количество приложений (первым был Web-сервер Apache), пользующихся этим интерфейсом.

QNX RTOS

Самая популярная в России RTOS — QNX 4.0 (вообще-то Windows NT, но ты много видел людей, которые юзают эНТю именно из-за этого?). Среди других unix-клонов она также занимает уверенное положение — пенетрация (т.е. захваченная доля рынка) этой ОС составляет приблизительно 8-10% — большей распространенности добились только Linux и FreeBSD (захватившие в сумме около половины российского рынка unix-систем). Несмотря на то, что QNX изначально является коммерческой, закрытой и проприетарной, в настоящее время ее модель лицензирования допускает получение и использование на безвозмездной основе как самой ОС (в минимальной конфигурации, конечно, и не для коммерческого использования, но — повторюсь — абсолютно бесплатно и без ограничений по времени), так и исходных кодов (тоже не всех и не для всех — но и это уже немало).

В чем же крутость этой ОС? Тот факт, что она многозадачная, многопользовательская, модульная и POSIX-совместимая, может удивить разве что бородатых полярников, которые свято верят, что пингвин — это такая еда:). Кстати, ОС эта раза в 2 постарше Лынукса. Впрочем, это не показатель. Ты только подумай — 8К микроядро (да-да, восемь килобайт!). Вот это показатель! Именно так достигается рекордное время переключения контекста — 2,5 наносекунды. Дело в том, что ядро управляет только разделением времени между процессами и передачей сообщений. Даже управление процессами и распределение ресурсов для процессов осуществляется отдельной прогой, которая так и называется — менеджер процессов, причем делает это она в соответствии с POSIX 1003.4 (это специальный стандарт на ОСРВ — почитай его, если надумаешь делать GNU QNX:).

Другие характеристики тебя вряд ли заинтересуют — они и не каждому QNX-профи известны и нужны. Поэтому про 12 возможных вызовов микроядра, 32 уровня приоритета и три алгоритма разделения времени (FIFO, круговой и адаптивный) я даже и не заикаюсь.

А вот требования к оборудованию очень советую почитать внимательно:

CPU: 8088, 80286, 80386 и выше
RAM: менее 640Кб (для исполнения), 2Mб (для разработки)
HDD: 5Мб для ОС и утилит (для системы программирования
— еще 4Мб); возможна бездисковая конфигурация.

Только не думай, что требования такие скромные, потому что система примитивная. Самая современная версия QNX (Neutrino 6.2.1) почти такая же жадная до ресурсов, как ХР. Что, испугался? 🙂 Я же сказал — почти! К тому же никто не мешает тебе установить QNX4 на 386 и наслаждаться. Препарируй на здоровье!

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

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

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

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

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

Реального времени

Разделяют их в зависимости от программ: жесткие (hard), мягкие (soft) и интерактивные. Вкратце рассмотрим каждый вид.

Жесткие ОСРВ имеют строго определенное время отклика на событие в реальном времени. Пример: аппаратное прерывание, показ команд управления должен обрабатываться за что и происходит в 100% случаев.

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

Интерактивные ОСРВ включают (когда индивид ожидает отклика от системы после заданных им указаний или команд).

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

Большинство ОСРВ - закрытого типа, и о них сложно получить подробную информацию. Компания WindRiver Systems разработала VxWorks (жесткая ОСРВ) для разработки ПО на встраиваемых ПК. Она основана на работе компьютера-хоста, на котором ведется разработка программного обеспечения, и компьютера-клиента, где и используется под управления VxWorks.

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

Неограниченное количество решаемых задач.

Количество приоритетных задач - до 256.

Задачи планируются циклически или по приоритетам.

Семафоры, которые помогают управлять критическими системными ресурсами.

Операционные системы реального времени QNX Neutrino Realtime Operating System - детище компании QNX Software Systems. Она основана на кросс-серверной архитектуре и отличается большой многозадачностью с режимом приоритетов. Каждый элемент системы работает самостоятельно: при сбоях и неполадках любое звено может самостоятельно перезапуститься, не повлияв на работу ядра или других компонентов. Она также имеет глубокую конфигурацию, привязку к базовому ядру, что исключает работу в другой среде.

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

Отличие от ОС общего пользования и назначения

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

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

Примеры встроенных систем

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

Рис. 1.1.

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

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

Рис. 1.2. Таблица 1.1. Примеры встроенных систем

Авиационные & Военные системы	Автопилоты самолетов, авионика и навигационные системы, системы автоматической посадки, системы наведения, управление двигателем.
Биомедицинские системы	Cистемы компьютерной томографии и ультразвукового исследования, мониторинг пациентов, кардиостимуляторы.
Автомобили	Управление двигателем, антиблокировочные тормозные системы, противобуксовочная тормозная система, управление подушками безопасности, управление системой обогрева и кондиционирования воздуха, навигация GPS, спутниковое радио, системная диагностика.
Коммуникация	Коммуникационные спутники, сетевые маршрутизаторы, коммутаторы, концентраторы.
Потребительская электроника	телевизоры, духовки, посудомоечные машины, плееры DVD, стереосистемы, системы безопасности, управление поливом газонов, термостаты, фотокамеры, радиочасы, автоответчики, декодеры кабельного телевидения, другие устройства.
Устройства в/для компьютера	Клавиатуры, мыши, принтеры, сканеры, дисплеи, модемы, устройства жестких дисков, устройства DVD, графические платы, устройства USB.
Электронные инструменты	Системы сбора данных, осциллографы, вольтметры, генераторы сигналов, логические анализаторы .
Промышленное оборудование	Управление лифтами, системы наблюдения, роботы, станки с ЧПУ, программируемые логические контроллеры, промышленные системы автоматизации и управления.
Офисные машины	факс-аппараты, копиры, телефоны, калькуляторы, кассовые аппараты.
Персональные устройства	сотовые телефоны, переносные плееры MP3, видео-плееры, персональные цифровые помощники (PDA), электронные наручные часы, портативные видеоигры, цифровые камеры, системы GPS.
Роботы	Промышленные роботы , автономные транспортные средства, космические исследовательские роботы (например, роботы- марсоходы )
Игрушки	системы видеоигр, игрушки роботы типа "Aibo", "Furby", и "Elmo".

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

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

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

Рис. 1.3.

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

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

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

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

Операционные системы часто классифицируют по их характеристикам реального времени. Операционная система реального времени должна быть тщательно спроектирована, чтобы поддерживать приложения реального времени. Недавнее исследование приходит к выводу, что 95% приложений реального времени требуют ограниченного времени ответа в диапазоне от 0.5 до 10 мсек. Только 10% отклонение (колебание от 50 микросекунд до 1 мсек) во времени ответа может быть допустимо. Согласно таким требованиям большинство операционных систем общего назначения не являются системами реального времени. Согласно этим критериям встроенная ОС, такая как Windows XP, может рассматриваться в лучшем случае только как мягкая ОС реального времени . Для Windows XP существуют некоторые инструменты сторонних поставщиков, которые улучшают время ответа.

Операционные системы для встроенных систем

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

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

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

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