Microsoft Windows Embedded

Операционные системы Microsoft Windows Embeddedдля встраиваемых систем имеют две разновидности в соответствии с версиями ОС Windows – NT и XP [MSEmb]. Версии систем Embedded корпорации Microsoft состоят из многочисленных конфигурируемых частей, которые позволяют легко манипулировать набором установленного программного обеспечения.

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

Набор средств разработки – Target Designer и Component Designer – позволяет OEM (original equipment manufacturer) производителям конфигурировать и создавать операционную систему для конкретной аппаратной платформы. Windows NT Embedded обладает специфическими компонентами для создания встраиваемых систем, которые позволяют работать в системах без видеоадаптера, осуществлять загрузку и работу накопителей в режиме "только чтение", выполнять удаленное администрирование и предоставляют дополнительные средства обработки ошибок и восстановления. Windows NT Embeddedдает возможность создавать устройства, с которыми работать так же просто, как и со стандартными ПК на основе Windows, и управлять этими новыми устройствами на основе существующих профессиональных продуктов, таких как Microsoft Systems Management Сервер, HP OpenView, IBM Tivoli, CA Unicenter TNG, и др.

Рис. 5. Процесс разработки встраиваемого ПО на основе Windows NT Embedded.

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

Windows XP Embedded насчитывает до 10000 отдельных компонентов, а в Windows NT Embedded их было чуть больше 300. Основной отличительной чертой Windows XP Embedded является четкое разграничение компонентов системы, что позволяет разработчикам встраиваемого набора функций при создании образа системы включать только необходимые файлы и максимально сократить размер результирующей системы. Этими компонентами служат отдельные части системы Windows XP Professional.

Компоненты Windows XP Embedded представлены сервисами, приложениями, библиотеками и драйверами – разработчику нужно сконфигурировать необходимый набор функций и собрать из компонентов необходимую конфигурацию в образ среды исполнения (runtime image). Все опции конфигурации собраны воедино в базу данных компонентов. Разработчик имеет к ней доступ и может ее редактировать с помощью специального инструмента – Component Database Manager.

Для каждого компонента в процессе создания определяется ряд параметров:

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

Сама база данных управляется СУБД MS SQL Server и может быть расположена как локально, на компьютере разработчика, так и на сервере.

TinyOS

Разработка операционной системы TinyOS [HSW00] связана с появлением новой концепции беспроводной связи – Motes. Motes (в переводе с английского – пылинки, соринки) – это реализация идеи "smart-dust" ("распыленной разумности"), предложенной оборонным агентством Darpa (Defense Advanced Research Projects Agency), в частности, для отслеживания передвижений противника.

Motes разработаны в Калифорнийским университете в Беркли совместно с Intel, и в настоящее время ведутся испытания этих самоорганизующихся сетей, построенных на основе открытых технологий Intel Mote и программного обеспечения TinyOS, TinyDB.

Умные сенсоры Motes, распределенные в пространстве, могут самостоятельно связываться друг с другом, образуя распределенную беспроводную информационную сеть. "Пылинка разума" состоит из 8-битового микроконтроллера семейства Amtel AVR, приемопередающего интегрального модуля TR1000 и двух микросхем средней степени интеграции – энергонезависимой памяти и дополнительного загрузочного микроконтроллера, позволяющего по радиоканалу обновлять ПО центрального процессора – AVR.

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

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

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

Архитектура TinyOS объединяет такое привычную составляющую, как планировщик задач (scheduler), и оригинальное понятие – компонентный граф. Термин "компонент" здесь одновременно и соответствует общепринятому пониманию, и существенно расширяет его. Так, интерфейс компонента TinyOS состоит из двух множеств – верхнего, предоставляемого этим компонентом, и нижнего, требуемого для его функционирования. Каждое из этих множеств содержит описания команд и событий – синхронных и асинхронных процессов.

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

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

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

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

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

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

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

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

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

Для обеспечения динамичности во время выполнения была разработана виртуальная машина, которая является надстройкой над ОС TinyOS. Код для виртуальной машины можно загрузить в систему во время выполнения. Для работы этой виртуальной машины необходимы 600 байт оперативной памяти и менее 8 KB памяти команд 8-битового микроконтроллера. Программы виртуальной машины представляются 8-битовыми инструкциями всего трех типов, объединяемых в "капсулы" – атомарные последовательности не более чем двадцати четырех инструкций.

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

OSEK/VDX

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

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

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

Задача в ОС OSEK может быть

• базовой или расширенной,
• вытесняемой или невытесняемой.

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

Рис. 6. Уровни обработки в ОС OSEK.

Концепция двух типов задач потребовала введения нового понятия – класс соответствия (conformance class) для описания своеобразной реализации ОС OSEK и системных сервисов. Определяются четыре класса соответствия – два для базового соответствия (BCC1 и BCC2 – Basic conformance Classes 1 и 2) и два для расширенного (ECC1 и ECC2 – Extended Conformance Classes 1 и 2). Реализации, которые соответствуют базовым классам, требуют использования только базовых задач, в то время как для расширенных классов нужны как расширенные, так и базовые задачи. Числа 1 и 2 в именах классов указывают количество запросов на задачу для базовых задач и количество задач на приоритет для всех задач. Таким образом, в BCC1 и ECC1 имеется только одна задача на приоритет, и базовые задачи могут быть запрошены только один раз. В BCC2 и ECC2 допускается множественность задач на приоритет и множественное запрашивание базовых задач.

Каждая задача должна находиться в одном из четырех состояний

• Выполняющаяся – только одна задача может быть в этом состоянии,
• Готовая к выполнению – планировщик может выбрать ее на выполнение на основании приоритетов и правил вытеснения,
• Ожидающая – задача ждет появления события,
• Приостановленная – задача в пассивном состоянии и ждет активации.

Рис. 7. Модель состояний задачи в ОС OSEK.

Каждая задача имеет приоритет. Стандарт ОС OSEK не ограничивает максимальное количество приоритетов – это определяет реализация.

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

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

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

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

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

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

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

OSE RTOS

Операционная система реального времени OSE RTOS, разработанная в корпорации ENEA, имеет ядро с приоритетным планированием [OSERTOS]. Это ядро сильно оптимизировано для обеспечения высокой производительности и достаточно компактно для использования во встраиваемых системах. OSE имеет архитектуру, управляемую сообщениями, с простыми системными вызовами. Передача сообщений в OSE служит концептуальным шлюзом в распределенных многопроцессорных встраиваемых системах. Задачи посылают сообщения друг другу напрямую через ОС без поддержки очередей, почтовых ящиков или других промежуточных механизмов. OSE RTOS поддерживает подкачку, дублирование, динамическое обновление кода и многие коммуникационные протоколы.

OSE RTOS предлагает три варианта ядра, построенные по одному принципу. OSE Epsilon – для глубоко встраиваемой и SoC (system-on-chip) разработки. OSEck – компактное ядро для DSP. OSE Link Handler – для многочисленных смешанных CPU/DSP проектов. Все они поддерживают очень маленькое количество системных вызовов – от шести до восьми.

Архитектура OSE RTOSоснована на многослойной модели (рис. 8).

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

OSE RTOSоперирует разными типами и категориями процессов.

Типы процессов:

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

Рис.8. Многослойная архитектура OSE RTOS.

Под категориями процессов в OSE RTOSпонимается разделение процессов на динамические и статические. Статические процессы создаются ядром, когда система стартует, и существуют на всем протяжении существования системы. Динамические процессы создаются и уничтожаются во время выполнения.

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

Contiki

Операционная система Contiki [DGV04] разработана в Швеции (Swedish Institute of Computer Science) для систем с ограниченной памятью. Система Contiki позволяет динамически загружать и отгружать приложения и сервисы. С целью минимизации размеров операционной системы было спроектировано ядро Contiki, которое основано на модели управления событиями [HSW00].

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

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

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

Системы, управляемые событиями, имеют свои проблемы. Модель программирования, управляемая состояниями, сложна для программистов. К тому же не все программы укладываются в конечно-автоматную модель.

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

Рис. 9. Сердцевина Contiki и загруженные программы.

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

Contiki написана на языке C и адаптирована для ряда микроконтроллерных архитектур, включая Texas Instruments MSP430 и Atmel AVR, а также для платформы ESB.

PSOS

ОСРВpSOS была разработана корпорацией Integrated Systems. В настоящее время она принадлежит корпорации WindRiver [PSOS], которая ее купила, видимо для того, чтобы она не мешалась на рынке сбыта ОСРВ.

Имя pSOSsystem присвоено операционной системе, имя pSOS+ – ее ядру. pRISM+ – это интегрированная среда разработки для создания приложений.

pSOS+ – это маленькое ядро встраиваемых приложений, представляющее собой некий вариант клиент-серверной архитектуры. Однако оно не имеет протокола взаимодействия, основанного на сообщениях. Для взаимодействия модулей используется программная шина (software bus). Есть возможность выбрать и встроить модули в систему во время компиляции. Такими модулями могут быть файловая система (pHILE+), отладчик (pROBE+), сетевые протоколы (pNA+), библиотека удаленных вызовов процедур (pRPC+) и стандартная библиотека ANSI C (pREPC+). Эти компоненты показаны на
рис. 10.

Рис. 10. Компоненты pSOSsystem.

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

pSOS+m является многопроцессорной версией ядра pSOS+. Она требует, чтобы один узел был главным, а остальные – подчиненными. К этому ядру добавлены системные вызовы, позволяющие оперировать через границы процессора.

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

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

Управление прерываниями в pSOSsystem довольно примитивное. Кроме того, отсутствуют мьютексы и механизм наследования приоритетов, что может привести к инверсии приоритетов.

INTEGRITY

Продукт INTEGRITY (компания Green Hills Software) [INTEGRITY] – это ОСРВ с предсказуемым временем отклика, рассчитанная на применение в тех ситуациях, когда необходимы масштабируемость ОС, её компактность и возможность работы в режиме реального времени. Платформа INTEGRITY построена на базе микроядра velOSity [Velosity] и хорошо подходит для использования в недорогих устройствах с ограниченными аппаратными ресурсами (сюда относится большая часть потребительской электроники). Для своей операционной системы компания Green Hills предлагает интегрированную среду разработки MULTI, полностью автоматизирующую процесс создания ПО. Поддерживая многоязыковую разработку и отладку, графический интерфейс пакета MULTI дает пользователю быстрый и удобный доступ к оптимизирующим C/C++ компиляторам и функциям MISRA C. В этом инструментальном пакете содержится отладчик уровня входного языка, компоновщик, анализатор событий, профилировщик производительности, программа обнаружения ошибок периода исполнения и средство отладки, не нарушающее основного режима функционирования.

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

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

Рис. 11. Структура INTEGRITY.

ОСРВ INTEGRITYвключает двухуровневый планировщик ARINC-653, основанный на сегментации (Partition Scheduler), который обеспечивает гарантированное временное окно центрального процессора для каждой выполняющейся задачи. Например, если выполняются две задачи, A и B, и каждой предоставлено по 50% времени, то порождение задачей B задач B1 и B2 не повлияет на выполнение задачи A, поскольку время центрального процессора, выделенное для задачи В (50%), разделится на 3 для задач В, B1 и B2, а для задачи A останутся ее прежние 50%. Таким образом, действия одной задачи никогда не смогут повлиять на выполнение других задач, что позволяет избегать воздействия злоумышленного кода, вирусов, проникновения хакера или просто ошибок в других адресных пространствах.

LynxOS

Операционная система LynxOS RTOS (LynuxWorks, Inc.) является операционной системой жесткого реального времени, которая предназначена для специализированной и телекоммуникационной аппаратуры [LynxOS]. Эта ОС является полностью детерминированной и обладает POSIX-, UNIX- и Linux-совместимостью. Областями применения ОС LynxOS являются также сложные системы безопасности.

Последняя выпущенная версия этого бренда ОС LynxOS-178 2.0 характеризуется производителем как коммерческая операционная система, обеспечивающая высокий уровень надежности и оперативности, необходимый для встраиваемых приложений с особыми требованиями к безопасности. В LynxOS-178 2.0 реализована поддержка интерфейса APEX (APlication/EXecutive – интерфейс приложения/управляющей программы) спецификации ARINC-653. Это означает, что данная операционная система отвечает самым строгим требованиям к безопасности и надежности электронных систем для военной и гражданской авиации. Система LynxOS-178 2.0 полностью соответствует положениям уровня А спецификации DO-178B.

ОСРВ LynxOS-178 2.0 соответствует требованиям стандартов POSIX и ARINC-653, а также DO-178B, что означает гарантию переносимости прикладного кода встраиваемых систем, многократного использования созданных программ, а также соответствие самым строгим нормативам операционных систем с повышенными требованиями к безопасности. Использование LynxOS-178 2.0 позволяет применять любые ранее сертифицированные программы и разработки.

Microware OS-9

Операционная система реального времени OS-9 корпорации Microware System является многозадачной, многопользовательской операционной системой для встраиваемых приложений, работающих в режиме реального времени [OS-9]. Эта система предназначена для работы в таких системах, как мобильные телекоммуникационные устройства, встраиваемые терминалы доступа в Интернет, интерактивные цифровые телевизионные приставки. OS-9 работает на таких процессорах, как Motorola 68K, ARM/StrongARM, Intel IXP1200 Network Processor, MIPS, PowerPC, Hitachi SuperH, x86 or Intel Pentium, Intel IXC1100 XScale.

Ядро OS-9 является масштабируемым, полностью вытесняемым, поддерживает функционирование до 65535 процессов, предоставляет 65535 уровней приоритета и обеспечивает работу до 255 пользователей. Ядро OS-9 содержит более 90 системных вызовов, к