Операционные системы реального времени чаще всего используются. Международный стандарт OSEKVDX для операционной системы реального времени. На что ориентирована

Реального времени (RTOS) - это ОС, которая гарантирует определенную способность в течение заданного временного отрезка. Например, она может быть спроектирована так, чтобы отображать, что некий объект стал доступен для робота на сборочном конвейере. Такие оболочки классифицируются на «жесткие» и «мягкие».

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

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

Прежде чем приводить примеры операционных систем реального времени, необходимо разобраться в особенностях их использования. Одни такие ОС создаются для специального применения, другие - для более общего. Кроме того, некоторые оболочки общего назначения также иногда используются для работы в режиме в реального времени. Как такого типа могут выступить общеизвестные Windows 2000 или IBM Microsoft/390. То есть даже если ОС не отвечает некоторым требованиям, она может иметь характеристики, которые позволяют рассматривать ее в качестве решения для конкретной задачи приложения в режиме реального времени.

Примеры операционных систем и их характеристика

В целом реального времени имеют следующие характерные черты:

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

ОС реального времени часто используются в составе небольших встраиваемых оболочек, которые применяются в формате микроустройств. Так, некоторые ядра можно рассматривать как однозадачные операционные системы (примеры: ядра в составе IOS, Android и т. д.) в режиме реального времени. Однако для выполнения ими поставленных задач требуются другие компоненты устройства, например, драйвера. Именно поэтому полноценная как правило, бывает больше, чем просто ядро.

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

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

VxWorks от компании WindRiver

VxWorks является операционной системой реального времени, разработанной как проприетарное программное обеспечение с помощью компании WindRiver. Будучи впервые выпущенной в 1987 году, VxWorks изначально была предназначена для использования во встраиваемых системах, требующих реального времени и детерминированной производительности. Так, примеры операционных систем такого типа находят применение в сферах охраны и обеспечения безопасности, различных отраслей промышленности (особенно аэрокосмической и оборонной), производстве медицинских приборов, промышленного оборудования, робототехники, энергетики, управления транспортом, сетевой инфраструктурой, совершенствования автомобильной и бытовой электроники.

VxWorks поддерживает Intel (x86, включая новый вариант IntelQuarkSoC и x86-64), MIPS, PowerPC, SH-4 и ARM-архитектуру. Данная ОСРВ поставляется с мощным ядром, промежуточным программным обеспечением, поддержкой платных дополнительных пакетов и аппаратных технологий сторонних производителей. В своем последнем выпуске - VxWorks 7 - система была модернизирована для модульности и апгрейда так, что ядро ​​ОС содержится отдельно от промежуточного программного обеспечения, приложений и других пакетов.

QNX Neutrino

Также классические примеры операционных систем указанного типа - некоторые Unix-подобные оболочки. Таковой является QNX Neutrino, первоначально разработанная в начале 1980-х годов канадской компанией Quantum Software Systems. В конечном счете, разработка была приобретена BlackBerry в 2010 году. QNX является одним из первых коммерчески успешных операционных систем микроядра, которая используется в различных устройствах, включая авто- и мобильные телефоны.

FreeRTOS

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

Windows CE

Windows Embedded Compact - это операционная система подсемейства, разработанная корпорацией «Майкрософт» в рамках семейства продуктов Windows Embedded. В отличие от Windows Embedded Standard, который основан на Windows NT, эти примеры операционных систем используют эксклюзивное гибридное ядро. Компания «Майкрософт» предоставляет лицензии Windows CE для производителей оригинального оборудования, которые могут изменять и создавать свои собственные пользовательские интерфейсы, обеспечивая техническую основу для этого.

(Real Time Operating System s - 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 является мощным средством реализации целевых систем, рабо­тающих в условиях жестких ограничений на объем используемой памяти и время отклика на внешние события.

Министерство образования и науки Российской Федерации

Поволжский государственный технологический университет

Реферат по дисциплине

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

Выполнил: студент ЭФ (группа ПИ-12)

Микушов Ю. В.

[email protected]

Преподаватель: Бородин А. В.

Йошкар-Ола

●Введение

●Определение

●Развитие современных операционных систем

●Современное состояние предметной области

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

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

●Типы задач ОС

●Пять важнейших невидимых задач ОС

●Особенности

●Применение

●Рынок операционных систем

●Будущее ОСРВ

●Заключение

●Список использованных источников

Введение

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

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

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

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

Определения

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

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

Компоненты системы реального времени.

Прикладное программное обеспечение		Диспетчеризация
		Меж–потоковое взаимодействие
Операционная система реального времени		Обработка прерывания
	Защита от инверсии приоритетов	Управление потоками
		Управление памятью
Аппаратное обеспечение			Устройства

Расшифровка Mac OS X:

“Mac” означает название компании Macintosh.

“OS” – operating system, то есть операционная система.

“Х” – римское число десять, означает номер версии ОС.

Развитие современных операционных систем

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

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

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

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

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

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

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

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

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

Современное состояние предметной области

Ассоциации, компании и продукты

Компании Microsoft и Apple Inc. являются наиболее популярными производителями операционных систем и программного обеспечения к ним в современном мире.

Современные операционные системы от Microsoft:

Windows XP (Windows NT 5.1)

Windows Vista (Windows NT 6.0)

Windows 7 (Windows NT 6.1)

Windows 8 (Windows NT 6.2)

Windows 10 (Windows NT 10)

Современные операционные системы от Apple Inc:

Современные мобильные операционные системы:

1. Linux-системы (Android)

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

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

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

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

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

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

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

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

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

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

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

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

Типы задач

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

1. Циклические задачи. Характерны для процессов управления и интерактивных процессов.

2. Периодические задачи. Характерны для многих технологических процессов и задач синхронизации.

3. Импульсные задачи. Характерны для задач сигнализации и асинхронных технологических процессов.

Пять важнейших невидимых задач операционной системы

1. Обеспечивает аппаратно-программное «сцепление»

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

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

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

2. Заставляет одно и то же приложение работать на разном «железе»

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

Но в наши дни ОС взяла на себя роль своего рода «переходника» между программами и компьютерным «железом». Если взять любые две модели компьютеров, то наборы компонентов, из которых они собраны, будут различаться. Это касается даже известных своим подобием друг другу «Макинтошей», не говоря уже о всем том огромном многообразии, которое можно найти на современном рынке ПК.

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

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

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

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

3. Поиск необходимого приложению файла

Одних только физических ресурсов компьютера программам было бы недостаточно для того, чтобы корректно справляться со своими задачами. Вся информация хранится в файлах и этим файлам следует подчиняться определенным правилам. Эти правила касаются того, как именовать и хранить файлы. Мы называем этот общий набор правил «системой управления файлами» (file management system) или просто «файловым менеджером» («file manager»).

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

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

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

4. Эффективное распределение доступной оперативной памяти

Раз уж речь зашла о памяти, то имеет смысл вспомнить о памяти оперативной (ОЗУ, RAM). О том самом хранилище, которое всегда находится «под рукой» у процессора.

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

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

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

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

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

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

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

5. Акцентирует внимание процессора на той или иной задаче

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

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

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

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

Незаметная и незаменимая помощница

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

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

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

Особенности

Положительные особенности

Широкая распространенность продукта

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

Приятный интерфейс

У современных OC довольно приятный и понятный интерфейс. Это способствует быстрому восприятию информации, простоте использования компьютера, быстрому обучению работе с ОС.

Стабильность ОС

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

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

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

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

4. На стабильность работы современной ОС большое влияние оказывает и само "железо", которое используется совместно с работающей ОС.

5. Также на стабильную работу современной OC далеко не последнее влияние оказывают драйверы устройств. Эти мини-программы, отвечающие за сопряжение определенного софта с определенным “железом”.

Хорошая совместимость с продуктами разных разработчиков (об OC Windows )

Современная OC способна корректно понимать любые типы файлов, появившиеся в ее ранних реинкарнациях. Если вспомнить те же расширения файлов, то станет ясно, что их родоначальником, по сути, является та самая примитивная и архаичная ОС, некогда перекупленная у стороннего разработчика и доведенная до ума Microsoft - MS-DOS. Эта преемственность файловых форматов тянется нитью через все версии Windows, что само по себе просто замечательно.

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

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

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

Зачем она нам нужна?

На то есть довольно много причин.
Во-первых ОСРВ поддерживает многозадачность, приоритеты процессов семафоры и многое другое.
Во-вторых она очень легкая и почти не требует ресурсов.
В-третьих все вышесказанное мы можем получить практически на любом железе (например, FreeRTOS запускается даже на 8-битных AtMega).
Ну и в-четвертых: просто поиграться и получить удовольствие.

Обзор 3 известных ОСРВ.

Внимание: дальше идет мое личное мнение.

FreeRTOS

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

Плюсы

1) Бесплатная
2) Портирована на большое количество железа
3) Мощный функционал
4) Есть различные библиотеки: графика, интернет и другое.
5) Хорошая документация.

Минусы

1)Довольно-таки сложный процесс портирования на новое железо.

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

KeilRTX

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

Плюсы

1)Бесплатная
2)Легко портируется на новое железо(в пределах архитектуры arm).
3) Есть различные библиотеки: графика, интернет и другое.

Минусы

1)Работать на в Keil с ней практически нереально
2) Немного урезанный функционал
3) Поддерживается только arm.
4)(на личном опыте) Проигрывает многим ОСРВ по скорости.
Вывод: идеально подойдет для новичка и мелких проектов.

uc/os

Мощная коммерческая ОСРВ. Сайт .

Плюсы

1) Огромное количество функций и библиотек.
2) Поддерживает много железа

Минусы

1)Коммерческая.
2) Сложна в использовании.

Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.

Другие интересные ОСРВ

RTLinux ОСРВ на основе обычного Линукса.
QNX ОСРВ на основе Unix.

Особенности разработки с использованием ОСРВ

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

Дополнительные библиотеки ОСРВ.

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

Программные продукты и системы № 4, 2001 г. garbage collection. Technical report, University of Texas at Austin, 1993. 3. Kim T., Chang N., Kim N., Shin H. Scheduling Garbage Collector for Embedded Real-Time Systems. Technical report, Seoul National University. 4. The real-time specification for Java. http://www.rtj.org. 5. International J consortium specification. Real-time Core extensions. www.j-consortium.org. 6. Никифоров В.В., Данилов М.В. Статическая обработка спецификаций программных систем реального времени. //Программные продукты и системы.- 2000.- №4.- С.13-18. 7. Henriksson R. Scheduling garbage collection in embedded systems. Lund, 1998. 8. Nilsen K., Lee S. PERC real-time API. NewMonics Inc., 1997. 9. Wilson P.R., Johnstone M.S., Neely N., Boles D. Dynamic storage allocation: a survey and critical review. Technical report, University of Texas at Austin, 1995. МЕЖДУНАРОДНЫЙ СТАНДАРТ OSEK/VDX ДЛЯ ОПЕРАЦИОННОЙ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ М.П. Червинский Одной из тенденций совершенствования конструкций современных автомобилей является расширяющееся внедрение встроенных компьютерных систем. Соответственно растет объем производства автомобильных приложений реального времени – программных продуктов, обеспечивающих функционирование этих систем. Рост объема производства сопровождается ужесточением сроков разработки программных приложений, требований снижения их стоимости с одновременным улучшением надежности, мобильности, пригодности к повторному использованию при разработке новых продуктов. Перечисленные факторы стимулируют разработку стандартов, регламентирующих архитектурные и технологические решения, специфицирующие программные и сетевые интерфейсы для автомобильных приложений реального времени. Подобные стандарты должны способствовать расширению возможностей интеграции программных продуктов, производимых различными поставщиками программных средств. Во внедрении таких стандартов заинтересованы и крупные автомобилестроительные концерны, ("Крайслер", БМВ, "Фольксваген" и другие), стремящиеся к созданию конкуренции на рынке программных продуктов, которые они используют, потому что конкуренция позволяет приобретать программные продукты поставщиков, предлагающих наилучшее соотношение цена/качество. Для того чтобы смена поставщика не приводила бы к необходимости переработки значительной части приложений, производители требуют использования стандартов всеми поставщиками программных продуктов. Большинство встроенных систем, применяемых в транспортных средствах, являются приложениями жесткого реального времени. Обработка событий, возникающих в них, ограничивается жесткими сроками, нарушение которых могло бы привести к катастрофическим последствиям . В настоящее время основной технологией, применяемой для создания автомобильных приложений реального времени и, в частности, приложений жесткого реального времени, становится использование ядра, или операционной системы реального времени (ОСРВ). ОСРВ позволя- 40 ет разработчикам приложений гарантировать работоспособность приложения на протяжении всего цикла работы системы при условии правильного выбора приоритетов задач и правильного проектирования приложения. Необходимость стандартизации автомобильных приложений, строящихся на базе ОСРВ, привела к созданию в 1995 году международного комитета, осуществляющего проект OSEK/VDX создания международных стандартов, регламентирующих разработку программных средств для компьютерных систем, встраиваемых в автомобили. Проект OSEK/VDX был инициирован группой ведущих европейских производителей транспортных средств (автомобилей), большинство из которых находятся в Германии. Именно поэтому выбранная аббревиатура OSEK является сокращением немецкого названия «Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug» – «Открытые системы и интерфейсы для автомобильной электроники». Сокращение же VDX означает «Vehicle Distributed eXecutive» – название другого проекта, интеграция с которым произошла практически одновременно с началом проекта OSEK. Таким образом, даже название проекта и серии стандартов отражает интернациональный характер разработки с некоторым доминированием немецких производителей. В рамках проекта OSEK/VDX разрабатываются несколько стандартов. 1. OSEK/VDX OS (Operating System) – спецификация ОСРВ . Спецификация содержит описание архитектуры ОС, определение программного интерфейса ОС, которое следует использовать приложению, а также детальное описание поведения ОС и ее компонент. Следует отметить, что стандарт специфицирует по сути архитектуру и функции ядра реального времени, а не полноценную ОС, так как не содержит таких существенных компонент ОС, как, например, подсистема управления вводом-выводом, или подсистема распределения памяти. 2. OSEK/VDX COM (Communication) – спецификация сетевой подсистемы . Спецификация определяет программные интерфейсы и протоколы, предназначенные для передачи данных между узла- Программные продукты и системы ми транспортного средства. Современный автомобиль содержит до нескольких десятков микроконтроллеров, обменивающихся информацией. Как правило, используются как минимум две подсети: высокоскоростная – для системы управления двигателем, трансмиссией и подвеской, и низкоскоростная – для кузовной электроники. Программный интерфейс обеспечивает прозрачную передачу данных, то есть единый набор функций используется для обмена сообщениями как внутри узла, так и между узлами сети. Несмотря на то что спецификация в целом обеспечивает пользователей всеми необходимыми средствами для создания локальной сети автомобиля и поддерживает другие стандарты, применяемые в автомобильной индустрии, внедрение продуктов, реализующих OSEK/VDX COM, в реальные проекты сопряжено с некоторыми проблемами. Главной является использование крупными производителями автомобилей других (нестандартных) протоколов, что затрудняет переход на OSEK/VDX COM, так как требуется либо менять сетевое обеспечение во всех узлах автомобиля, либо поддерживать одновременно как стандартный, так и нестандартный протокол, по крайней мере в некоторых узлах сети. Кроме того, в настоящей версии спецификаций отсутствует механизм передачи данных длиной в несколько бит, а именно данные такой длины составляют существенную долю сетевого трафика автомобиля. Поэтому разработка спецификаций OSEK/VDX COM продолжается. 3. OSEK/VDX NM (Network Management) – спецификация управления сетью. Спецификация определяет, каким образом информация о текущем состоянии каждого из узлов сети передается другим узлам. Для этого используется метод мониторинга, в частности, две его разновидности – прямой и косвенный. Прямой мониторинг основан на передаче специальных сообщений по логическому кольцу или логической звезде. Косвенный мониторинг основан на отслеживании обычных сообщений, передаваемых узлами. OSEK/VDX NM может быть интегрирован с другими сетевыми системами (а не только с OSEK/VDX COM), и поэтому используется в настоящее время вместе с нестандартными сетевыми системами. 4. OSEK/VDX OIL (OSEK Implementation Language) – спецификация языка конфигурации системы. Спецификация описывает язык, использующийся для конфигурации приложений, построенных на реализации OSEK/VDX. Во встроенных системах, применяемых в автомобилях, все объекты приложения конфигурируются статически на стадии компиляции. Язык OIL содержит конструкции, позволяющие описать свойства системных объектов, например, названия и приоритеты задач, параметры таймеров и сообщений и т.п. Описание конфигурации обрабатывается специальной утилитой (системным генератором), которая формирует заголовочные файлы и исходный код, описывающие системные таблицы. В настоящее время не все спецификации полностью покрываются OSEK/VDX OIL (в частности, отсутст- № 4, 2001 г. вуют описания для объектов OSEK/VDX COM), поэтому работа над этим стандартом продолжается. Перечисленные спецификации разрабатываются разными рабочими группами во многом независимо друг от друга, но на определенных этапах производится коррекция и синхронизация спецификаций. Синхронизированные версии заносятся в спецификацию связей – специальный документ, содержащий описание всего проекта и аннотации составляющих его частей. Помимо перечисленных спецификаций, в рамках проекта OSEK/VDX разрабатываются спецификации систем, управляемых временем (timetriggered) . В настоящее время, однако, разработка еще не доведена до стадии издания официальных документов. Спецификация OSEK/VDX OS. Последним официально выпущенным документом является редакция 1 версии 2.1 от 13 ноября 2000 года. Эта редакция является результатом тщательной переработки предыдущей редакции 1 версии 2.0, в которой было обнаружено несколько серьезных дефектов и сотни мелких замечаний. Дефекты были обнаружены как разработчиками собственно ОСРВ, так и создателями приложений. Несколько дефектов были настолько серьезны, что делали невозможным создание корректно работающей ОСРВ на некоторых аппаратных платформах. Рабочая группа крайне ответственно подошла к исправлению дефектов и замечаний. Достаточно сказать, что полный список проблем и предлагаемых решений содержал больше страниц, чем собственно спецификация. Спецификация OSEK/VDX OS определяет программный интерфейс для выполнения функций ОСРВ. Программный интерфейс специфицирован на языке программирования С (используется стандарт ANSI-C), хотя реализация ОСРВ возможна и на других языках программирования. Мобильность приложений поддерживается на уровне исходного кода. Предполагается, что приложение может быть просто перекомпилировано при замене реализации ОСРВ. Однако стопроцентная мобильность все же не гарантируется, и при переносе приложения с одной платформы на другую могут потребоваться некоторые изменения как исходного кода, так и описания конфигурации. Связано это с тем, что в спецификации определены функции, зависящие от реализации, а конфигурация может включать атрибуты, предназначенные для оптимизации ОСРВ и приложения для конкретной реализации. Однако усилия по переносу приложения все же существенно ниже, чем при использовании нестандартных ОСРВ, и перенос может быть выполнен на этапе интеграции, а не собственно разработки программного обеспечения. Содержание спецификации OSEK/VDX OS. Спецификация содержит разделы, регламентирующие: архитектуру ОС, управление задачами, обработку прерываний, обработку событий, синхронизацию с помощью разделяемых ресурсов, алармы (управление по таймерам и счетчикам), передачу сообщений, обработку ошибочных ситуаций и отладку, описание системных вызовов. 41 Программные продукты и системы Имеется также раздел, определяющий особенности реализации ОСРВ и список изменений (контроль версий). Следует отметить, что спецификация разделяет нормативные требования (обязательные) и просто описательные части, поясняющие особенности спецификации. Ниже рассматриваются основные особенности ОС, отвечающих спецификациям OSEK/VDX OS. Архитектура ОС. Строго говоря, архитектура ОСРВ не описана в спецификации, поскольку не отличается от традиционно используемой в ядрах реального времени, и раздел содержит скорее общее описание принципов работы ОСРВ. ОСРВ управляет двумя типами объектов, конкурирующих за право использования процессора, – задачами и обработчиками прерывания. Задачи конкурируют на основе программно задаваемых статических приоритетов, то есть ОСРВ поддерживает планирование с фиксированными приоритетами. Обработчики прерывания имеют более высокий приоритет, чем задачи и планируются с помощью аппаратного обеспечения. Вследствие такого распределения приоритетов любое переключение контекста задач, вызванное выполнением системных вызовов в обработчиках прерываний, задерживается до завершения обработчика прерывания или завершения самого внешнего обработчика при обработке вложенных прерываний. Соответственно двум типам конкурирующих объектов спецификация определяет два уровня работы – уровень задач и уровень прерываний. Определен также логический уровень планировщика, хотя этот уровень не используется в спецификации и не виден пользователю ОСРВ. Следует отметить, что, несмотря на полностью статическое распределение приоритетов задач и обработчиков прерываний, во время выполнения приложения могут возникнуть ситуации ограниченной по времени инверсии приоритетов. Это происходит, когда низкоприоритетная задача вытесняет более приоритетные задачи или задача запрещает выполнение обработчиков прерываний вплоть до некоторого порогового уровня аппаратного прерывания. Возникновение таких ситуаций объясняется использованием протокола синхронизации при доступе к критическим секциям и полностью контролируется приложением. Однако ни при каких обстоятельствах не возникает неограниченной по времени инверсии приоритетов, что позволяет гарантировать своевременность исполнения задач при правильном статическом назначении приоритетов. Классы соответствия. Одним из основных требований к OSEK/VDX OS является возможность применения ОСРВ на процессорах различной мощности, начиная с 8-битных микроконтроллеров, имеющих несколько десятков килобайт ПЗУ и несколько килобайт ОЗУ, и заканчивая 32-битными процессорами, имеющими сотни килобайт ПЗУ и ОЗУ. Для выполнения этого требования спецификация, в частности, описывает четыре класса соответствия. Классы соответствия определяются следующими характеристиками: а) множественный запрос 42 № 4, 2001 г. активизации (разрешен или нет в данном классе); б) поддержка задач с состоянием ожидания, то есть так называемых расширенных задач; в) количество задач на один уровень приоритета; г) обязательные (минимальные) количественные параметры ОСРВ (например, количество исполняемых задач, число поддерживаемых ресурсов для доступа к критическим секциям и т.п.). Спецификация определяет следующие классы соответствия. Базовый класс 1 (BCC1 – Basic Conformance Class 1). Задачи с состоянием ожидания и множественный запрос активизации не поддерживаются, только одна задача на уровень приоритета, то есть все задачи имеют разный приоритет. Базовый класс 2 (BCC2). То же, что базовый класс 1, но поддерживаются множественный запрос на активизацию и несколько задач на один уровень приоритета. Расширенный класс 1 (ECC1 – Extended Conformance Class 1). То же, что базовый класс 1, но поддерживаются задачи с состоянием ожидания. Расширенный класс 2 (ECC2). То же, что ECC1, но поддерживаются множественный запрос на активизацию для задач без состояния ожидания и несколько задач на один уровень приоритета. Классы соответствия помогают как разработчикам ОСРВ, так и пользователям корректно характеризовать и использовать реализации системы. Следует отметить, что поставщики OSEK/VDX OS могут реализовать только несколько классов соответствия, для того чтобы получить сертификат соответствия стандарту. Пользователи, особенно крупные корпорации, обычно требуют от разработчиков приложений использовать только определенные классы соответствия или даже только один класс, для того чтобы облегчить интеграцию, уменьшить требования к расходуемым ресурсам (например к памяти), и иметь гибкость при смене поставщика ОСРВ. Дело в том, что каждый следующий класс, хотя это и не описано явно, требует более громоздкой реализации, поэтому есть смысл ограничить требования приложений минимально необходимым классом. Например, множественный запрос активизации требует ощутимых дополнительных расходов как памяти, так и циклов процессора, поэтому нет смысла использовать классы, поддерживающие множественный запрос, если такая возможность не используется в приложении. Классы соответствия обеспечивают грубую классификацию ОСРВ, которой полезно придерживаться. В то же время поставщики ОСРВ вправе добавить улучшения в реализацию класса соответствия. Например, во многих реализациях поддерживается схема несколько задач на один уровень приоритета даже для базового класса соответствия 1. В целом приложения, требующие высокой производительности, например системы управления впрыском топлива в двигатель, могут использовать базовый класс 1, потому что он обеспечивает самое быстрое переключение задач, синхронизированное с углами поворота распредвала, и повторная активизация задачи (то есть множественный запрос активиза- Программные продукты и системы ции) рассматривается как перезагрузка. Для кузовной электроники зачастую используется расширенный класс 1, так как с помощью задач с состоянием ожидания удобно реализовывать конечные автоматы. Управление задачами. ОСРВ поддерживает планирование задач с фиксированными приоритетами и три различных способа диспетчеризации – вытесняющую, невытесняющую и смешанную (в спецификации диспетчеризация объединена с планированием, и отдельно этот термин не используется). При вытесняющей диспетчеризации задача с более высоким приоритетом всегда вытесняет из обработки задачу с более низким приоритетом. При невытесняющей диспетчеризации такое вытеснение происходит, только если низкоприоритетная задача сама освободит процессор. При смешанной диспетчеризации некоторые задачи являются вытесняемыми, а некоторые – невытесняемыми. Следует отметить, что обработка прерываний выполняется одинаково при любом способе диспетчеризации. При планировании равноприоритетных задач соблюдается принцип первой запланирована – первой выполняется. Как правило, приложения используют вытесняющую диспетчеризацию, позволяющую добиться соблюдения сроков исполнения с помощью относительно простых правил назначения приоритетов. Повидимому, невытесняющая диспетчеризация может использоваться в приложениях с существенно ограниченным числом задач и совместно используемых ресурсов. В связи с тем, что контекст невытесняемых задач содержит меньше регистров процессора, переключение контекста выполняется быстрее, и, следовательно, можно добиться более высокой производительности при более низких расходах памяти. Совмещенная диспетчеризация полезна в тех случаях, когда существует несколько задач не очень высокого приоритета, которые выполняются настолько быстро, что не имеет смысла расходовать время процессора на их вытеснение. OSEK/VDX OS специфицирует два типа задач – базовые и расширенные. Базовые задачи могут быть только в одном из трех состояний – неактивном, готовом и выполняющемся. Расширенные задачи могут дополнительно находиться в ждущем состоянии. Неактивное состояние задачи похоже на программу ОС общего назначения, находящуюся на жестком диске. Предполагается, хотя и не описано явно, что неактивная задача не использует ОЗУ. Спецификация также не накладывает ограничений на количество неактивных задач в приложении, что позволяет предположить, что таких задач может быть много больше, чем активизированных. Базовые задачи поддерживают принцип однократного выполнения, то есть при активизации задача переходит из неактивного состояния в готовое, затем, в зависимости от приоритета и способа диспетчеризации, занимает процессор, переходя в состояние выполнения. После окончания работы эта задача завершается и возвращается в неактивное состояние. Задачи такого рода никогда не используются в ОС общего назначения, но они эффективны во встроенных приложениях реального времени. № 4, 2001 г. Расширенные задачи могут переходить в состояние ожидания посредством механизма событий. Если все события, которые ожидает задача, не установлены, то задача переходит в состояние ожидания до тех пор, пока хотя бы одно из ожидаемых событий не будет установлено. Спецификация не определяет способа завершения одной задачи из другой или обработчика прерывания. Поэтому переход в неактивное состояние возможен только из состояния выполнения. Иными словами, задача может завершиться только по собственной инициативе. Разновидностью завершения задачи является завершение с одновременной активизацией другой задачи или нового экземпляра той же самой задачи, что позволяет создавать цепочки задач. Повторная активизация уже активной задачи приводит к ошибке в классах соответствия BCC1 и ECC1. В классах BCC2 и ECC2 соответствия при этом возникает множественный запрос на активизацию, означающий, что в момент завершения задачи будет активизирован ее новый экземпляр. Следует подчеркнуть, что для множественного запроса на активизацию выполняется тот же принцип планирования равноприоритетных задач: первой запланирована – первой выполняется. По-видимому, множественный запрос на активизацию может применяться в коммуникационных приложениях, например, когда сообщения, приходящие из сети, обрабатываются задачей, активизирующейся всякий раз, когда поступает новое сообщение. Обработка прерываний. Спецификация требований к обработке прерываний состоит из следующих разделов: обработчики прерываний (например, запросов на прерывания от внешних устройств), селективное управление источниками прерываний, быстрое управление распознаванием прерываний. Обработчики прерываний активизируются при возникновении запросов на прерывание, обычно от внешних устройств, или от самого процессора (например, для обработки исключительных ситуаций). Спецификация определяет три категории обработчиков прерываний. Категория 1 (ISR category 1). Обработчики этой категории не выполняют обращений к ОСРВ. Иными словами, они не изменяют состояния задач и других системных объектов. Обычно такие обработчики выполняются на самых высоких уровнях аппаратных приоритетов и предназначены для обработки событий с самыми короткими сроками выполнения, причем без участия ОСРВ. Категория 2 (ISR category 2). Для обработчиков второй категории ОСРВ автоматически предоставляет необходимые условия для возможности вызова сервисов ОСРВ. Технически это достигается с помощью ключевого слова ISR, поэтому разработчику приложений не надо заботиться о создании контекста, позволяющего обращаться к ОСРВ. Категория 3 (ISR category 3). Обработчики третьей категории являются как бы комбинацией обработчиков первой и второй категорий. Если в процессе выполнения обработчика нужно обратиться к 43 Программные продукты и системы ОСРВ, должен быть выполнен системный вызов EnterISR() для создания нужного контекста, а по окончании обработчика – вызов LeaveISR(), для того чтобы сообщить системе, что обработчик завершен (обработчики категории 2 неявно включают в себя эти вызовы). Практически все вызовы, которые имеет смысл вызывать из обработчиков прерываний, разрешены в обработчиках второй и третьей категории (между обращениями EnterISR/LeaveISR). Например, обработчики прерываний могут активизировать задачу, установить событие для задачи, послать сообщение, установить аларм и т.п. Обработчики прерываний могут быть вложенными, то есть один обработчик может прервать другой. Для этого должны быть созданы соответствующие аппаратные условия. При выполнении вложенных прерываний диспетчеризация задерживается до завершения самого внешнего обработчика. Отметим две проблемы, связанные с использованием обработчиков прерываний. Первая связана с потенциальными трудностями использования локальных переменных в обработчиках, относящихся к категории 3. Проблема состоит в том, что компиляторы обеспечивают выделение памяти под локальные переменные функции-обработчика в самом начале выполнения функции. При вызове EnterISR() стек может быть подменен, и эти локальные переменные становятся неадресуемыми, то есть обращение к ним после вызова EnterISR() приведет к ошибочной адресации. К сожалению, такая ситуация может возникнуть и в том случае, когда разработчик приложения даже не определяет локальные переменные явно. Поскольку компилятор может создать скрытые локальные переменные для выполнения некоторых операций (например, для выполнения битовых операций на 8-битных процессорах). Именно поэтому спецификация указывает на существование такой проблемы, которую можно полностью избежать, лишь отказавшись вовсе от использования обработчиков третьей категории. Вторая проблема связана с вложением обработчика категории 2 или 3 в обработчик первой категории. В таком случае диспетчеризация откладывается на неопределенное время, потому что она не может быть выполнена по завершении вложенного обработчика (поскольку еще есть внешний обработчик), но и не выполняется по завершении внешнего обработчика, потому что обработчик первой категории не взаимодействует с ОС. Чтобы избежать возникновения такой ситуации, спецификация рекомендует правильно назначать приоритеты обработчикам прерываний. Включенное в спецификацию описание селективного управления источниками прерываний подвергается критике в связи с тем, что интерфейсы прикладных программ, поддерживающие запрещение или разрешение распознавания запроса на прерывание от конкретного источника (устройства), не удается специфицировать в платформонезависимом виде, поэтому не достигается переносимость приложений, использующих такие сервисы. Кроме того, при использовании этих сервисов может возникнуть 44 № 4, 2001 г. неограниченное по времени запрещение прерываний, приводящее к аппаратным ошибкам. Например, низкоприоритетная задача, запретившая на короткое время прерывания по приему байта последовательного порта, может быть вытеснена более приоритетными задачами, и тогда «короткое время» затянется на неопределенный срок, что приведет к потере приема следующих байтов. Рабочая группа, разрабатывающая спецификации, согласна с этой критикой. Возможно, функции селективного управления источниками прерываний будут удалены из следующих версий спецификации. Быстрое управление распознаванием прерываний позволяет разрешать и запрещать либо все прерывания процессора, либо только те, которые влияют на работу ОСРВ. Обработка событий. События позволяют расширенной задаче переводить себя в состояние ожидания в том случае, если событие сброшено, и переводить задачу в состояние готовности, когда событие установлено. К сожалению, спецификация не очень четко определяет отображение глобальных событий на биты, используемые задачей, но предполагается, что каждая расширенная задача владеет собственной маской событий, битовыми флагами, которыми можно манипулировать с помощью системных вызовов ОСРВ. Для встроенных приложений, на которые ориентирована спецификация, задачи классов ECC1 и ECC2 приводят к накладным расходам, связанным с использованием выделенной области ОЗУ для стека каждой задачи, и манипулированию битами событий. Поэтому разработчикам приложений следует использовать расширенные задачи с большой осторожностью. Синхронизация с помощью разделяемых ресурсов. Спецификация использует специальный протокол для доступа к ресурсам, защищающим критические секции кода. Этот протокол называется OSEK Priority Ceiling Protocol, хотя он и описывает не собственно Priority Ceiling Protocol, а протокол, имеющий несколько синонимов, например, Highest Locker Protocol или Priority Protect Protocol (в стандарте POSIX). Протокол позволяет добиться исключения тупиков и неограниченной по времени инверсии приоритетов. Это достигается за счет того, что приоритет задачи, запрашивающей разделяемый ресурс, немедленно повышается до порогового значения приоритета ресурса, который вычисляется в процессе конфигурации системы как самый высокий (или выше) приоритет всех задач, имеющих доступ к этому ресурсу. Поэтому при запросе ресурса гарантируется, что никакая другая задача, имеющая доступ к этому ресурсу, не будет переведена в состояние выполнения. Большим достижением OSEK/VDX OS можно считать расширение этого протокола, обычно применяющегося только для задач, на обработчики прерываний для защиты критических секций кода, совместно используемых задачами и обработчиками прерываний. При этом подразумевается, что приоритеты обработчиков прерываний и задач как бы ото- Программные продукты и системы бражаются на одну шкалу и что ОСРВ способна манипулировать запрещением и разрешением уровней прерываний контроллера прерываний. Конечно, такая схема имеет вырожденный характер, если аппаратура поддерживает только один уровень прерываний, но все же может использоваться и в этом случае. Но особенно полезно использование расширения протокола на микропроцессорах, имеющих многоуровневую схему прерываний, например, Motorola 68K. Алармы (управление по таймерам и счетчикам). Спецификация определяет обобщенный объект, называемый алармом, который используется для активизации задач по значениям таймеров и счетчиков, например, измерителями линейных или угловых перемещений. Каждый аларм неявно подразумевает нижележащий счетчик, отсчитывающий значение некоторой величины. Спецификация не определяет программный интерфейс для управления счетчиками, потому что они могут быть полностью реализованы аппаратно, например, с помощью прерываний часов реального времени. Следует отметить, что к одному счетчику могут быть подключены несколько алармов. Спецификация требует, чтобы ОСРВ предоставляла системный таймер. Каждому аларму назначается задача или пара задача-событие. При срабатывании аларма задача активизируется или для нее устанавливается событие. Срабатывание аларма происходит в тот момент, когда значение счетчика достигнет значения установки аларма. Аларм можно установить как на абсолютное значение счетчика, так и на относительное. Также можно установить циклическое значение аларма, организовав таким образом обработку периодических событий. Можно заметить, что алармы обеспечивают очень гибкий и мощный механизм для обработки событий. Однако реализация алармов все же достаточно громоздка, особенно в случае подключения к счетчику нескольких алармов. Передача сообщений. Спецификация OSEK/ VDX OS не содержит описания механизма сообщений, отсылая к спецификации OSEK/VDX COM, в которой специально описаны два класса соответствия сети CCCA и CCCB (CCC – аббревиатура Communication Conformance Class) для локальных сообщений. CCCA описывает небуферизированные сообщения, то есть такие, содержание которых обновляется всякий раз, когда посылается сообщение. CCCB дополнительно определяет буферизированные сообщения, представляющие собой круговою очередь. Сообщения обоих типов имеют фиксированную длину (и размер очереди буферизированных сообщений), определяемую на этапе конфигурирования приложения. При поступлении сообщения может производиться активизация задачи-приемника, установка события для задачи-приемника или может вызываться пользовательская функция. Для сертификации реализации OSEK/VDX OS поставщику ОСРВ достаточно реализовать класс соответствия сети CCCA. № 4, 2001 г. Обработка ошибочных ситуаций и отладка. Для отладки и трассировки приложений спецификация описывает процедуры-ловушки и расширенную информацию об ошибках. Ловушки предоставляются пользователем, но вызываются самой ОС. В случае возникновения системной ошибки вызывается ловушка ошибки, для того чтобы приложение идентифицировало причину ошибки и предприняло корректирующие действия. Две ловушки предназначены для отслеживания переключения контекста задачи, помогая тем самым в трассировке приложения. При старте ОСРВ вызывается стартовая ловушка, в которой можно активизировать задачи, инициализирующие приложение, и выполнить инициализацию аппаратных средств. В случае фатальной ошибки приложение может завершить ОСРВ, при этом вызывается терминальная ловушка, в которой можно выполнить сброс аппаратных средств. Расширенная информация об ошибках предоставляется системными сервисами ОСРВ в том случае, если система статически сконфигурирована для этого. В описании каждой системной функции указывается, какие коды ошибок могут быть возвращены в стандартной и расширенной конфигурациях. Например, в стандартной конфигурации активизация задачи возвращает только код успешного выполнения, а в расширенной конфигурации сообщает о неправильном идентификаторе задачи и об ошибочном множественном запросе на активизацию. Предполагается, что расширенная конфигурация должна использоваться разработчиками приложений на этапе отладки, а отлаженное приложение конфигурируется в стандартном варианте, поскольку расширенная обработка ошибок приводит к существенным накладным расходам, в особенности в части использования процессорного времени. Существует, однако, проблема, связанная с различием временных характеристик исполнения приложения в стандартной и расширенной конфигурациях (разработчикам приложений следует иметь в виду возможные последствия этого различия). Стандарт OSEK/VDX OS отвечает практически всем сегодняшним требованиям разработчиков автомобильных приложений и используется такими концернами, как "Крайслер" и БМВ. Успех спецификации объясняется тесным партнерством заказчиков и поставщиков ОСРВ в разработке спецификации и тщательной проработкой деталей для достижения баланса функциональных возможностей и эффективности реализации, а также для стабильности работы встроенных систем. Список литературы 1. Kopetz H. Real-Time Systems. Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers. MA, 1997. 2. OSEK/VDX Operating System, Version 2.1 revision 1, 13. November 2000. 3. OSEK/VDX Communication, Version 2.2.2, 18th December 2000. 45