Тема1.2. Особенности информационно-управляющих систем реального времени

Тема1.2. Особенности информационно-управляющих систем реального времени

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

1) универсальные ВС (высокопроизводительные системы, рабочие станции);

2) информационно-управляющие системы.

Информационно-управляющие системы (ИУС) – это вычислительные системы, в которых:

– есть взаимодействие с объектом контроля или управления;

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

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

Те подсистемы универсальных ВС, которые отвечают за выполнение задач реального времени (РВ), строятся по принципам ИУС.

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

ИУС рассматриваются как область вычислительной техники (ВТ), в которой системы можно поделить на две большие категории:

– встроенные вычислительные системы;

– распределённые информационно-управляющие системы.

Определение систем реального времени:

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

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

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

– требования по времени;

– возможность параллельного выполнения нескольких задач;

– предсказуемость;

– важно максимальное время отклика на событие, а не среднее;

– особые требования в вопросах безопасности;

– возможность безотказной работы в течение длительного периода времени.

СРВ должны реагировать на периодические и непериодические типы внутренних и внешних событий. Принадлежность системы к классу СРВ никак не связана с ее быстродействием. Исходные требования к времени реакции системы и другим временным параметрам определяются или техническим заданием на систему, или просто логикой ее функционирования. Быстродействие СРВ должно быть тем больше, чем больше скорость протекания процессов на объекте контроля и управления. Чтобы определить необходимое быстродействие для систем, имеющих дело со стационарными процессами, часто используют теорему Котельникова, из которой следует, что частота дискретизации сигналов должна быть как минимум в 2 раза выше граничной частоты их спектра. При работе с широкополосными по своей природе переходными процессами часто применяют быстродействующие АЦП с буферной памятью, куда с необходимой скоростью записывается реализация сигнала, которая затем анализируется и/или регистрируется вычислительной системой. При этом требуется закончить всю необходимую обработку до следующего переходного процесса, иначе информация будет потеряна. Подобные системы иногда называют системами квази-реального времени.

Классификация информационно-управляющих систем реального времени

Различают системы жесткого и мягкого реального времени:

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

2. Точного определения для мягкого реального времени не существует, поэтому отнесем к ИУС мягкого реального времени, не попадающие в категорию жестких. Так как система мягкого реального времени может не успевать решать поставленные задачи в заданное время, возникает проблема определения критериев успешности (нормальности) ее функционирования. Вопрос этот совсем не простой, так как в зависимости от функций системы это может быть максимальная задержка в выполнении каких-либо операций, средняя своевременность обработки событий и т.п. Более того, эти критерии влияют на то, какой алгоритм планирования задач является оптимальным.

Также СРВ можно разделить на системы специализированные и универсальные:

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

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

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

Внутренняя архитектура ОСРВ¹

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

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

Рис. 2.1. Архитектура монолитной ОС

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

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

Рис. 2.2. Архитектура уровневой ОС

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

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

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

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

Рис. 2.3. Построение ОС с использованием архитектуры клиент-сервер

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

Планирование и запуск задач

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

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

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

2. Необходимо упорядочить доступ нескольких задач к разделяемому ресурсу.

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

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

Связные задачи

Взаимное согласование задач с помощью сообщений является одним из важнейших принципов операционных систем реального времени. Здесь можно встретить такие понятия, как сообщение (message), почтовый ящик (mail box), сигнал (signal), событие (event), прокси (proxy) и т.п. Один и тот же термин для разных ОСРВ может обозначать разные вещи. Объем информации, передаваемой в сообщении, может меняться от одного бита до всей свободной емкости памяти системы. Во многих ОСРВ компоненты операционной системы, также как и пользовательские задачи, способны принимать и передавать сообщения. Сообщения могут быть асинхронными и синхронными. В первом случае доставка сообщений задаче производится после того, как она в плановом порядке получит управление, а во втором случае циркуляция сообщений оказывает непосредственное влияние на планирование задач. Например, задача, пославшая какое-либо сообщение, немедленно блокируется, если для продолжения работы ей необходимо дождаться ответа, или если низкоприоритетная задача шлет высокоприоритетной задаче сообщение, которого последняя ожидает, то высокоприоритетная задача, если конечно, используется приоритетная многозадачность с вытеснением, немедленно получит управление. Иногда сообщения передаются через буфер определенного размера (почтовый ящик). При этом, как правило, новое сообщение затирает старое, даже если последнее не было обработано.

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

Общие ресурсы

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

Вот возможные пути решения этой проблемы:

1. Не использовать алгоритм планирования задач с вытеснением. Это решение, правда, не всегда приемлемо.

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

3. Запретить прерывания на время доступа к разделяемым данным. Кардинальное решение, которое, впрочем, не приветствуется в системах реального времени.

4. Использовать для упорядочивания доступа к глобальным данным семафоры. Наиболее часто применяемое решение, которое, впрочем, может привести в некоторых случаях к инверсии приоритетов. Семафор – это средство, которое часто используется для синхронизации доступа к ресурсам. В простейшем случае семафор представляет собой битовую переменную, принимающую значение 0 или 1. Задача, перед тем как использовать ресурс, захватывает семафор, после чего остальные задачи, желающие использовать тот же ресурс, должны ждать пока семафор (ресурс) освободится. Существуют так называемые счетные семафоры, где семафор представляет собой счетчик. Предположим, что у нас имеется N одинаковых ресурсов (например, принтеров). Используя семафор с инициализационным значением N, можно произвести синхронизацию доступа множества задач к группе из N ресурсов.

Синхронизация с внешними событиями

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

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

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

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

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

Синхронизация по времени

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

На сегодняшний день существует большое количество коммерческих ОСРВ. Есть ряд бесплатных (или условно бесплатных) СРВ и систем, имеющих статус исследовательских или университетских проектов. В России хорошо представлены только несколько коммерческих систем (QNX, OS-9, VxWorks ). QNX на сегодня является самой распространенной ОСРВ в России. Многие популярные в Европе и США ОСРВ до сих пор практически не представлены на российском рынке. Дадим краткое описание некоторых систем реального времени.

QNX

Операционная система QNX является разработкой канадской компании QNX Software System Ltd. Впервые система появилась на рынке в 1981 году. Среди пользователей QNX значатся такие компании, как Du Pont, Eastman Kodak, General Mills, General Motors, Motorola, Texaco.

Операционная система QNX представляет собой гибрид 16/32-битовой операционной системы, которую пользователь может конфигурировать по своему усмотрению. Время, необходимое для полной инсталляции системы, включая сетевые средства, составляет всего 10-15 минут, после чего можно начинать работу. Нетребовательность системы к ресурсам проявляется уже в том, что система с необходимой и достаточной средой разработки в виде компилятора Watcom C/C++ (основной компилятор для QNX) умещается в 10 Мбайт.

Система построена по технологии FLEET [Fault-tolerance (отказоустойчивая), Load-balancing (регулирующая нагрузку), Efficient (эффективная), Extensible (расширяемая), Transparent (прозрачная)]. Эта технология выражается в следующих принципах. QNX является ОСРВ на основе микроядра (размером около 10 Кбайт). В качестве основного средства взаимодействия между процессами система использует передачу сообщений. Благодаря этому в 32-битовой среде возможно взаимодействие процессов с 32 и 16-битовым кодом. Причем сообщения передаются между любыми процессами, не зависимо от того, находятся ли процессы на одном компьютере или на разных узлах сети. Пользователь, работая на одном из узлов сети, может иметь доступ к любым ресурсам остальных узлов, включая порты, файловую систему и задачи. Пользователю нет никакой необходимости вникать в сетевой протокол, который не является тайной, вплоть до его структуры. Он содержит пакеты, которые применяются также и для передачи сообщений. Сетевой администратор распознает эти пакеты и переправляет их микроядру, которое переправляет их в шину локальных сообщений. QNX способна распознавать не только пакеты сообщений QNX-процессов. Вы можете легко обращаться к сетевому администратору для передачи таких пакетных протоколов, как TCP/IP и других. Возможно обращение к различным сетевым администраторам через один кабель. Операционная система QNX объединяет всю сеть персональных компьютеров в единый набор ресурсов с абсолютной прозрачностью доступа к ним. Узлы могут добавляться и исключаться из сети, не влияя на целостность системы. Сетевая обработка данных в QNX является настолько гибкой, что вы можете объединить в одну сеть любой разнородный набор Intel совместимых компьютеров соединенных через Arcnet, Ethernet, Token Ring или через последовательный порт, к которому также может быть подключен модем. Причем возможно участие компьютера одновременно в нескольких сетях, и если одна из них окажется перегруженной или выйдет из строя, то QNX автоматически будет использовать другие доступные сети без потери информации. Файловая система QNX полностью соответствует стандарту POSIX. Эти отличия в основном сказываются на ее живучести, то есть на целостности данных, хранимых на диске, и на производительности. QNX обеспечивает работу с различными типами файловых систем: POSIX, Embedded (FLASH, ROM, SROM), CD-ROM (с поддержкой стандарта ISO 9660 и его расширения Rock Ridge), DOS (доступ ко всем носителям информации в формате DOS), NFS (доступ к различным типам удаленных файловых систем), SMB (прозрачный доступ к Windows 2000 или NT-серверам).

В настоящее время вряд ли какая-нибудь операционная система сможет посоревноваться с QNX по количеству различных графических интерфейсов. Вы можете создавать графические приложения с помощью библиотечных функций, поставляемых вместе с компилятором Watcom C. Графический интерфейс для ограниченной в ресурсах встраиваемой системы – Photon, компактный (256Кб) оконный пакет, поддерживающий стандарт Motif. Photon – это новая оконная графическая система, которая по своему подходу к реализации графического интерфейса коренным образом отличается от всех существовавших ранее систем. Для широкого спектра графических интерфейсов используется X Window System.

Кроме того, для QNX разработано множество баз данных (db_Vista, Watcom SQL, Faircom C-tree, OnCmd и др.), которые по производительности часто превосходят аналоги под управлением других операционных систем. В Российской промышленности QNX можно встретить чаще, чем любую другую ОСРВ.

Одним из недостатков QNX является практически отсутствие версий для платформ, отличных от Intel.

OS-9

OS-9 – одна из наиболее традиционных операционных систем реального времени c 70-х годов. Первая версия системы была написана фирмой Microware Systems Corp. еще для процессора Motorola 6809. В дальнейшем основные идеи, заложенные в систему, стали опорными точками при создании многих известных сейчас систем этого класса и послужили исходным материалом при создании стандарта POSIX 1003.

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

Продукты OS-9 фирмы Microware включают в себя высокотехнологичное системное программное обеспечение РВ и инструментальные средства разработки для интеллектуальных устройств, ориентированных на следующие рынки:

1. Промышленные встраиваемые системы.

2. Системы телекоммуникации.

3. Рынок потребительской электроники.

Программные средства OS-9 поставляются пользователям в виде:

1. Комплексных лицензируемых пакетов для OEM.

2. Пакетов поддержки аппаратных вычислительных плат, устройств и систем.

3. Системное програмное обеспечение реального времени.

OS-9 относится к классу UNIX подобных операционных систем реального времени и предлагает к использованию многие привычные элементы среды UNIX. Модульность системы означает, что она может быть масштабирована для удовлетворения нужд, как маленьких встроенных систем, так и больших сетевых приложений. Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей. Комбинируя эти модули, разработчик может создавать системы с разной конфигурацией от миниатюрных автономных ПЗУ ориентированных ядер до полномасштабных многопользовательских систем разработки. Как правило, разработка программ ведется в полнофункциональных конфигурациях. После того как будет отлажен код программы реального времени, отсоединяются модули разработки и ввода вывода, и полученный код готов к исполнению под управлением ядра в целевой системе.

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

Компания Microware стала в 1994 году первым производителем программного обеспечения реального времени, который был сертифицирован по ISO9001.

OS-9 имеет самый широкий набор файловых менеджеров по сравнению с другими ОСРВ. Базовые файловые менеджеры OS-9 предназначены для организации обмена информацией между процессами и обеспечивают приложениям OS-9 доступ к различным последовательным устройствам типа принтеров и терминалов, а также к устройствам внешней памяти, таким как диски (жесткие, гибкие, электронные и оптические) и ленты. Сетевые файловые менеджеры обеспечивают доступ к самым разным сетевым устройствам по протоколу TCP/IP. Файловые менеджеры также поддерживают различные высокоуровневые сетевые протоколы и протоколы передачи файлов.

Модульная структура OS-9 позволяет разработчику выбирать именно те функциональные блоки, которые требуются данному приложению. Любая из опций легко может быть добавлена в систему для обеспечения соответствия изменившимся требованиям к системе. Для поддержки таких сложных приложений, как телекоммуникации, мультимедиа и системы выдачи видеоданных по запросу, фирма Microware разработала ряд дополнительных файловых менеджеров.

Файловый менеджер управления стеком протоколов поддерживает несколько типов коммуникационных протоколов типа X.25 и LAP-B. Он обеспечивает независимую от сети архитектуру для динамической сборки и разработки (stacking and unstacking) модулей протокола и драйверов устройств. В автономной встроенной системе такие приложения и стеки протокола могут быть как резидентными в устройстве, так и загружаться в устройство через сеть.

Пользовательский интерфейс мультимедиа-приложения MAUI содержит расширенный набор протоколов API для соответствия требованиям высокопроизводительных мультимедиа-протоколов либо протоколов пользователя. С данным интерфейсом могут общаться такие являющиеся промышленным стандартом пакеты, как Apple QuickDraw и QuickTime, Macromedia Director, Oracle Media Objects и Sybase Gain.

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

Основные характеристики OS-9:

- многозадачная (65535 процессов, 65535 уровней приоритета);

- многопользовательская (256 пользователей);

- переносимость приложений (ANSI C/C++, POSIX 1003.1, TCP/IP(NFS,RPC), X Windows X11.R6(OSF Motif)), JAVA;

- 100% размещение в ПЗУ системы и приложений пользователя;

- объектно-ориентированный модульный дизайн;

- полностью вытесняемое детерминированное ядро с минимальным временем реакции на прерывание;

- многоуровневая, основанная на приоритетах обработка прерываний;

- развитые сетевые средства (Arcnet, Ethernet, OMNInet, X.25, ISDN T1/E1, ATM NFM, TCP/IP, IPX Profibus, CAN, MIL STD 1553…);

- графические оконные интерфейсы – GUI;

- резидентные и кросс-средства разработки, прогрессивная технология высоко оптимизирующего ANSI C/C++ компилятора;

- поддержка HOST-систем (IBM PC(MS Windows 3.xx, 95, 98, 2000, NT), IBM RS6000/AIX, Sun4/SunOS/Solaris, HP9000 S/700, SGI IRIS/IRIX);

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

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

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

- специальные программные средства и лицензионная политика для OEM;

- более 5 млн. установленных копий;

- более 800 OEM-партнеров.

VxWorks/Tornado²

Операционная система реального времени VxWorks и инструментальная среда Tornado фирмы Wind River Systems предназначены для разработки ПО встроенных компьютеров, работающих в системах жесткого реального времени. Операционная система VxWorks является системой с кросс-средствами разработки прикладного программного обеспечения, разработка ведется на инструментальном компьютере (host) в среде Tornado для последующего исполнения на целевой машине (target) под управлением VxWorks.

VxWorks поддерживает целевые архитектуры (targets):

Motorola 680x0 и CPU32, PowerPC;

Intel 386/486/Pentium, Intel 960;

Spare, Mips R3000/4000;

AMD 29K, Motorola 88110;

HP PA-RISC;

Hitachi SH7600;

DEC Alpha.

Инструментальные платформы, поддерживаемые для Tornado (hosts):

Sun SPARCstation (SunOS и Solaris);

HP 9000/400,700 (HP-UX);

IBM RS6000 (AIX);

Silicon Graphics (IRIX);

DEC Alpha (OSF/1);

PC (Windows).

Поддерживаемые интерфейсы host-target:

host-target Ethernet;

RS232;

внутрисхемный эмулятор ICE (In-Circuit Emulator);

кросс-шина (backplane).

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

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

Все аппаратно-зависимые части VxWorks вынесены в отдельные модули. Этот комплект конфигурационных и инициализационных модулей называется (Board Support Package, BSP) и поставляется для стандартных компьютеров (VME-процессор, PC или Sparcstation) в исходных текстах. Разработчик нестандартной машины может взять за образец BSP наиболее близкий по архитектуре стандартный компьютер и перенести VxWorks на свою машину путем разработки собственного BSP с помощью BSP Porting Kit.

Базовые сетевые средства VxWorks: UNIX-networking, SNMP и STREAMS.

VxWorks была первой операционной системой реального времени, в которой реализован протокол TCP/IP с учетом требований реального времени. С тех пор VxWorks поддерживает все сетевые средства, стандартные для UNIX: TCP/UDP/ICMP/IP/ARP, Sockets, SLIP/CSLIP/PPP, telnet/rlogin/rpc/rsh, ftp/tftp/bootp, NFS (клиент и сервер).

Реализация SNMP-агента с поддержкой как MIB-I, так и MIB-II предназначена для применения VxWorks в интеллектуальном сетевом оборудовании (хабы, мосты, маршрутизаторы, повторители) и других устройствах, работающих в сети.

STREAMS – стандартный интерфейс для подключения переносимых сетевых протоколов к операционным системам, реализован в VxWorks как в версии SVR3, так и SVR4. Таким образом, в VxWorks можно инсталлировать любой протокол, имеющий STREAMS-реализацию, как стандартный (Novell IPX/SPX, DECNET, Apple-Talk и пр.), так и специализированный. Wind River Systems анонсировала (1994) программу WindNet, по которой ведущие фирмы-производители программных средств в области коммуникаций интегрировали свои программные продукты с VxWorks.

На сегодняшний день – это сетевые протоколы Х.25, ISDN, ATM, SS7, Frame Relay и OSI; CASE-средства разработки распределенных систем на базе стандартов ROOM (Real-Time Object Oriented Modelling) и CORBA (Common Object Request Broker Architecture); менеджмент сетей по технологиям MBD (Management By Delegation) и CMIP/GDMO (Common Management Information Protocol/Guidelines for Definition of Managed Objects).

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

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

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

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

Специально для систем с сильно ограниченным объемом памяти компания Wind River Systems разработала редуцированное ядро WindStream, которое требует для работы не более 8 Кб ПЗУ и 2 Кб ОЗУ. При этом для WindStream применим весь спектр инструментальных средств VxWorks, включая WindView.

В качестве интерфейса между инструментальной и встроенной целевой машинами можно использовать внутрисхемные эмуляторы ICE (In-Circuit Emulators), например, НР64700, которые включаются в гнездо микропроцессора целевой системы, не имеющей Ethernet, или RS232 для связи с инструментальной машиной.

Экономичной альтернативой внутрисхемным эмуляторам являются так называемые ROM-эмуляторы, включаемые в гнездо ПЗУ микропроцессора целевой системы, например, NetROM фирмы XLNT Designs. К Ethernet-разъему эмулятора NetROM подключается инструментальная машина, стандартный Ethernet-драйвер VxWorks заменяется драйвером NetROM и так на целевой машине появляется виртуальный Ethernet.

Инструментальная среда Tornado имеет открытую архитектуру, что позволяет другим фирмам-производителям инструментальных средств разработки ПО реального времени интегрировать свои программные продукты с Tornado. Пользователь может подключать к Tornado свои собственные специализированные средства разработки, а также расширять возможности инструментальных средств фирмы Wind River Systems.

В стандартную конфигурацию Tornado входят ядро VxWorks и системные библиотеки, GNU C/C++ Toolkit, дистанционный отладчик уровня исходного языка CrossWind, оболочка WindSh, конфигуратор BSP WindConfig и др.

Существует множество программных продуктов интегрированных с Tornado производства других фирм.

IA-SPOX

Это многозадачное ядро реального времени, разработанное компанией Spectron Microsystems, было, по-видимому, первой успешной попыткой соединения таких понятий, как Windows и жесткое реальное время. IA-SPOX спроектировано в виде набора виртуальных драйверов (VxD), которые работают совместно с ядром Windows 2000 на нулевом уровне привилегий процессора (Ring 0). Пользовательские программы, работающие на третьем уровне (Ring 3), могут вызывать функции и процессы реального времени, а также обмениваться данными с ними. Именно на IA-SPOX базировалась объявленная в 1994 году инициатива Intel по реализации мультимедиа-функций программным путем без использования специальных процессоров обработки сигнала. IA-SPOX показало свою эффективность в программной реализации синтеза звука, высокоскоростной модемной связи и решения других задач, требующих быстрой и детерминированной реакции системы.

RTX

Фирма VenturCom разработала подсистему реального времени RTX (Real-Time Extensions) для Windows NT при поддержке Microsoft. Microsoft передала лицензию на исходные тексты такого компонента Windows NT, как Уровень Абстракции Аппаратуры (HAL, Hardware Abstraction Level), который в основном и определяет характеристики ОС по обработке прерываний. RTX добавляет дополнительные вызовы к интерфейсу прикладного программирования (RTAPI, Real-Time API), а также загружает модифицированный HAL, который изолирует аппаратные прерывания от ядра Windows NT. RTX предоставляет для системы таймер реального времени с расширением 1мс и уменьшает время отклика. RTX обеспечивает для процессов доступ к физическим адресам памяти и портов ввода/вывода, а также специальные методы работы со страничной памятью, исключающие свойственные Windows NT задержки. Кроме того, предлагаются интерфейсы, замещающие функции WIN32, ответственные за планировку и синхронизацию задач, межзадачный обмен сообщениями, работу с аппаратными прерываниями и т.п. Самое интересное, что для этого не нужны изменения Windows NT и это не отразится на работоспособности существующих программ.

Для разработчиков встраиваемых систем VenturCom предлагает версию Windows NT, которая требует менее 10 Мбайт ПЗУ и 8 Мбайт ОЗУ. Подкачка страниц виртуальной памяти при этом запрещена, а в качестве дополнительных драйверов предлагаются драйверы Null-Display и Null-Input, позволяющие системе работать без дисплея и клавиатуры.

Falcon

После того как Intel передала права на эту ОСРВ компании RadiSys, последняя неустанно трудилась над интеграцией полученного продукта с платформой Windows NT. Фирма выбрала стандартный путь лицензирования у Microsoft исходных текстов уровня HAL, с их последующим изменением под требования жесткого реального времени.

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

Hyperkernel

Подсистема реального времени для Windows NT, которая предлагается фирмой Imagination Systems. Как и в других системах, Hyperkernel позволяет сочетать высокоскоростные задачи управления, требующие детерминированного времени отклика, и менее критичные приложения типа ПО операторского интерфейса. Microsoft и в этом случае предоставила исходные тексты HAL-уровня и разрешила распространение модифицированных версий.

RT-Linux

RT-Linux – это операционная система, в которой небольшое ядро реального времени сосуществует с Posix-like ядром Linux. Основная цель – сделать доступными сложные службы и оптимизированное поведение системы в стандартных ситуациях, для системы с разделением времени и в то же время выполнять задачи реального времени. В прошлом операционные системы реального времени примитивны – простые программы, которые предлагали пользователю чуть больше, чем просто библиотека основных функций. Но в наше время пользователи требуют доступ к TCP/IP, графическому дисплею и системе окон, базам данных и другим службам, которые не являются ни примитивными, ни простыми. Одно из решений – добавить non-real-time службы к базовому ядру реального времени, что и было проделано в VXworks и немного по-другому в микроядре QNX. Вторая возможность – модифицировать стандартное ядро и сделать его полностью прерываемым.

RT-Linux организован третьим способом, в котором простое ядро реального времени запускает обычное ядро как одну из задач реального времени с самым низким приоритетом, используя виртуальную машину для того, чтобы сделать стандартное ядро полностью прерываемым.

В RT-Linux все прерывания обслуживаются ядром реального времени, а затем, передаются стандартному ядру, но только в том случае, если нет необходимости запускать одну из задач реального времени. Для того чтобы минимизировать количество изменений в стандартном ядре, этот механизм реализован при помощи эмулирования ICH (Interrupt Control Hardware). Ядро реального времени и пользовательские задачи Linux могут обмениваться данными через неблокируемые очереди и сегменты разделяемой памяти.

С точки зрения программиста очереди выглядят как стандартные последовательные устройства UNIX, доступ к которым возможен при помощи системных вызовов POSIX read/write/open/ioctl. Разделяемая память доступна через системный вызов mmap.

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

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

На практике оказалось, что идея RT-Linux очень удачна. В самом худшем случае запаздывание прерываний на 486/33Mhz PC оказалось менее 30 мкс, что близко к аппаратному пределу. Наиболее часто используемая конфигурация RT-Linux – примитивные задачи реального времени со статически распределяемой памятью без ее защиты, простым планировщиком с фиксированными приоритетами без защиты от нереализуемых планов, аппаратным запретом прерываний, разделяемой памятью – механизм синхронизации задач реального времени и ограниченный набором операций над FIFO-очередями, подсоединенными к обычным процессам Linux.

Ядро Linux позволяет в динамике загружать и выгружать модули ядра, сделав отдельные части ядра реального времени в виде модулей, легко изменять ядро реального времени. Уже написаны альтернативные планировщики и модуль семафоров. Во время работы системы можно загрузить модуль с задачами реального времени, затем выгрузить стандартный планировщик и загрузить, например, EDF планировщик. Можно пробовать разные комбинации модулей, пока не будет найдена оптимальная.

Этот вариант Linux позволяет выполнять задачи в реальном времени. Это достигается путем вставки ядра реального времени между стандартным ядром Linux и аппаратными прерываниями и позволяет избавиться от главной причины непригодности Linux для задач реального времени – большого запаздывания прерываний.

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

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

Самый короткий период для периодически вызываемых задач реального времени в RT-Linux на Pentium 120 – менее 150 мкс. Задачи, вызываемые по прерыванию, могут иметь намного меньший период.

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

Необходимо отметить, что компания LinuxWorks начала поставки встраиваемой ОС BlueCat Linux для комплекта разработчика ПО Intel Internet Exchange Architecture Software Developers Kit (Intel IXA SDK) 2.0, предназначенного для семейства сетевых процессоров Intel IXP1200. ОС BlueCat Linux распространяется бесплатно совместно с Intel IXA SDK 2.0.

VxWorks давно стала де-факто стандартом для подавляющего большинства систем, использующих встроенные ОС. Флэш-память вычислительной системы IXP1200 содержит загрузчик ядра VxWorks. Для разработчиков это упрощает задачу написания новых программ. Кроме того, уже реализована возможность работы сетевого процессора под управлением ОС Linux (с расширениями реального времени). Осуществляется программная поддержка некоторыми производителями ОС Linux (например, LinuxWorks и т.д.).

1

2