Linux операционная система реального времени

Журнал «Открытые Системы», #09-10/1999
Алексей Черемисин,
Олег Кобызев

До недавнего времени для решения задач автоматизации в основном использовались операционные системы (ОС) реального времени (РВ). Это компактные системы, основанные на микроядерной архитектуре, — такие так VxWorks, OS-9, PSOS, QNX, LynxOS. Эти системы обладают быстрым временем реакции на события и прерывания, компактностью кода, хорошей встраиваемостью и другими преимуществами, характерными для операционных систем с микроядерной архитектурой.

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

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

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

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

Куда податься?

Мечта любого разработчика — операционная система на все случаи. Чтобы и управляла, и печатала, и т. д. Однако универсальные ОС, такие как Windows NT и Unix, не предназначены для задач реального времени и зачастую с ними не справляются. Приведем достаточно типичный пример. Разработчик перенес свою программу из DOS в Unix. Программа должна сохранять на диске снятую с видеокамеры информацию, а также управлять работой камеры. В DOS все шло гладко, но при переходе в среду Unix появились задержки в передаче на камеру управляющих сигналов. В результате анализа ситуации выяснилось, что задачи пользователя простаивают из-за процесса sync, который призван синхронизировать кэш файловой системы при обращении к диску. Попытки отключить подкачку и установить программе управления камерой наивысших приоритетов результатов не дали.

Так как же быть разработчику? Закупать операционную систему реального времени? Или все же есть способ добиться предсказуемого поведения и компактной реализации при использовании традиционных операционных систем?

Смесь бульдога с носорогом

В настоящее время происходит активный процесс слияния универсальных OC и ОС реального времени. На программном рынке появляются различные инструменты поддержки режима реального времени, встраиваемые в привычные операционные системы. Этот класс продуктов обладает значительными преимуществами со стороны пользователей и программистов, сочетая в себе привычный пользовательский интерфейс, средства разработки программ и API-интерфейс реального времени. Правда, пока еще нет оснований утверждать, что подобные решения полностью заменят собой обычные системы реального времени. У традиционных ОС реального времени есть пока большое преимущество — встраиваемость и компактность. Однако и на этом рынке происходят изменения: корпорация Microsoft выпустила Windows NT Embedded (NTE), использование которой позволяет «ужать» NT до 8-10 Мбайт. Уже появились и продукты реального времени, рассчитанные на эту операционную систему, например, RTX.

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

Бурный рост популярности Linux побуждает разработчиков внимательнее присмотреться к этой операционной системе. У Linux много достоинств: открытость кода; большое количество сопутствующего программного обеспечения, пока в основном ориентированного на серверные применения; наличие неплохой документации на API-интерфейс и ядро операционной системы; работа на процессорах различных классов. В данный момент эта ОС готова к стабильной работе, а открытость ее исходных текстов и архитектуры наряду с растущей популярностью заставляет программистов переносить свои наработки на многие аппаратные платформы: SGI, IBM, Intel, Motorola и т.д. В частности, Motorola активно работает в своей традиционной сфере встраиваемых систем и продвигает на рынок продукт LinuxEmbedded. Вообще говоря, Linux прекрасно подходит для компактных встроенных применений; на рынке уже появились поставщики, предлагающие усеченные варианты этой операционной системы, которые занимают 1-2 Мбайт на жестком диске. В качестве примера можно привести проект Linux Router Project.

Для задач реального времени сообщество разработчиков Linux активно применяет специальные расширения — RTLinux, KURT и UTIME, позволяющие получить устойчивую среду реального времени. RTLinux представляет собой систему «жесткого» реального времени, а KURT (KU Real Time Linux) относится к системам «мягкого» реального времени. Linux-расширение UTIME, входящее в состав KURT, позволяет добиться увеличения частоты системных часов, что приводит к более быстрому переключению контекста задач.

Проект KURT (http://hegel.ittc.ukans.edu/projects/kurt) характеризуется минимальными изменениями ядра Linux и предусматривает два режима работы — нормальный (normal mode) и режим реального времени (real-time mode). Процесс, использующий библиотеку API-интерфейсов KURT, в любые моменты времени может переключаться между этими двумя режимами. Программный пакет KURT оформлен в виде отдельного системного модуля Linux — RTMod, который становится дополнительным планировщиком реального времени. Данный планировщик доступен в нескольких вариантах и может тактироваться от любого системного таймера или от прерываний стандартного параллельного порта. Так как все процессы работают в общем пространстве процессов Linux, программист использует в своих программах стандартные API-интерфейсы Linux и может переключаться из одного режима в другой по событиям, либо в определенных местах программы. При переключении в режим реального времени все процессы в системе «засыпают» до момента освобождения ветви процесса реального времени. Это довольно удобно при реализации задач с большим объемом вычислений, по своей сути требующих механизмов реального времени, например в задачах обработки аудио- и видеоинформации.

Стандартно такты планировщика RTMod задаются от системного таймера — время переключения контекста задач реального времени (time slice) равно 10 мс. Используя же KURT совместно с UTIME, можно довести время переключения контекста задач до 1 мс. Прерывания обрабатываются стандартным для ОС Linux образом — через механизм драйверов.

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

• set_rtparams позволяет добавить процесс в ядро с маской SCHED_KURT. Только процессы, чья политика в планировщике установлена как SCHED_KURT, смогут работать в режиме реального времени;
• get_num_rtprocs получает идентификатор «rt_id» процесса из планировщика реального времени RTMod;
• rt_suspend позволяет приостановить планировщик реального времени;
• get_rt_stats получает статус процесса из таблицы планировщика процессов реального времени.

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

RTLinux

rtlinux) — это дополнение к ядру Linux, реализующее режим «жесткого» реального времени, которое позволяет управлять различными чувствительными ко времени реакции системы процессами. По сути дела, RTLinux — это операционная система, в которой маленькое ядро реального времени сосуществует со стандартным POSIX-ядром Linux.

Разработчики RTLinux пошли по пути запуска из ядра реального времени Linux-ядра как задачи с наименьшим приоритетом. В RTLinux все прерывания обрабатываются ядром реального времени, а в случае отсутствия обработчика реального времени — передаются Linux-ядру. Фактически Linux-ядро является простаивающей (idle) задачей операционной системы реального времени, запускаемой только в том случае, если никакая задача реального времени не исполняется. При этом на Linux-задачу накладываются определенные ограничения, которые, впрочем, для программиста прозрачны.

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

Все аппаратные прерывания перехватываются ядром операционной системы реального времени. Когда происходит прерывание, ядро RTLinux решает, что делать. Если это прерывание имеет отношение к задаче реального времени, ядро вызывает соответствующий обработчик. В противном случае, либо если обработчик реального времени говорит, что хочет разделять это прерывание с Linux, обработчику присваивается состояние ожидания (pending). Если Linux потребовала разрешить прерывания, то прерывания, которые находятся в состоянии «pending», эмулируются. Ядро RTLinux спроектировано таким образом, что ядру реального времени никогда не приходится ожидать освобождения ресурса, занятого Linux-процессом (рис. 1).

Рис. 1. Механизм работы RTLinux — Linux-расширения жесткого реального времени

Для обмена данными между операционными системами реального времени и Linux могут использоваться следующие механизмы:

• разделяемые области памяти;
• псевдоустройства, предоставляющие возможность обмена данными с приложениями реального времени.

Ключевой принцип построения RTLinux — как можно больше использовать Linux и как можно меньше собственно RTLinux. Действительно, именно Linux заботится об инициализации системы и устройств, а также о динамическом выделении ресурсов. «На плечи» RTLinux ложится только планирование задач реального времени и обработка прерываний. Для простоты запуска в контексте ядра, сохранения модульности и расширяемости системы процессы реального времени реализованы в виде загружаемых модулей Linux. Как правило, приложение реального времени с RTLinux состоит из двух независимых частей: процесса, исполняемого ядром RTLinux, и обыкновенного Linux-приложения.

Для иллюстрации работы приложения реального времени рассмотрим прикладной модуль, который использует ядро реального времени RTLinux в виде загружаемого модуля Linux:

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

Рис. 2. Механизм межпроцессной связи через очереди сообщений FIFO

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

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

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

На наш взгляд, оба подхода в реализации механизмов реального времени, заложенные в KURT и RTLinux, применимы для большинства задач реального времени. Правда, до определенного времени проект KURT находился в «подвешенном» состоянии и почти год не развивался, что вывело команду RTLinux в лидеры этого технологического направления. Однако совсем недавно вышла новая версия KURT 2.0 для Linux-ядер версий 2.2.5, 2.2.9 и 2.2.13.

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

Источник

Real-Time Linux (RT- Linux)

Базовые концепции реального-времени (RT) . Жесткое реальное время и LINUX.

Что такое реальное-время?

» система реального времени это информационная система , в которой корректность выходной информация зависит не только от примененных алгоритмов, но и от момеyнтов времени появления информации. «

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

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

Давайте теперь более детально рассмотрим понятие «временые ограничения» (temporal restriction), предположим кто-либо хочет управлять скоростью двигателя с различной нагрузкой на валу с использованием ПИД-закона регулирования. (ПИД-закон это пропорционально- интегрально- дифференциальный закон регулирования). С нашей точки зрения, ПИД-закон, это функция со своим набором параметров. В этом примере скорость двигателя — параметр, получаемый от двигателя и напряжение питания двигателя — параметр, управляющей скоростью вращения двигателя. Теория алгоритмов управления, которая кстати весьма обширна, не принимает в расчет время вычисления алгоритма ПИД-функции, т.е. время от измерения скорости двигателя, до момента, когда мы воздействуем на двигатель, очень мало. В обычных условиях системы позволяют иметь небольшую задержку. Другая характеристика ПИД-закона это периодичность, другими словами необходимо постоянно, через определенные интервалы времени, вычислять ПИД-функцию. Если время между последовательными вызовами ПИД-функции слишком велико, двигатель может достичь нежелаемой скорости. Подводя итог, ПИД-закон может быть рассмотрен как функция, исполняемая периодически с периодом (Pi); с максимальной допускаемой ПИД-законом задержкой, (Di), и, в соответствии от скорости процессора исполнение ПИД кода требует определенного количества времени (Сi). .

Pi: Период задачи i.

Di: Максимальная допустимая задержка выдачи управления, задачи i.

Ci: наихудшее время выполнения задачи i.

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

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

Не все системы реального времени идентичны, совсем не одно и то же, что управлять системой вспрыска топлива двигателя самолета или показом mpeg-файлов. В первом случае, малейшая задержка в выполнении может привести к потере человеческих жизней или большим материальным потерям, во втором случае это означает простое ухудшение качества системы — картинка может замирать или часть кадров будет пропадать. Первый тип известен как системы «жесткого реального времени» (hard real time, HRT), а второй, как системы «мягкого реального времени» (soft real time, SRT). . Мы будем иметь дело c системами HRT.

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

Подведем итог. Задачи определяются трямя временными параметрами Pi, Di и Ci. Система должна гарантировать время выполнения задач, т.е. при выполении любого набора задач, все задачи остануться внутри своих временных границ. Гарантировать время выполнения — это значит что система должна быть предсказуемой (predictable). Говоря, что система является системой реального времени или система предсказуема, обычно подразумевают одно и то же. .

Какая связь между операционной системой и реальным временем?

Семантическая реализация сигналов управления — ответственность программиста а временные ограничения зависят от операционной системы.

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

• Алгоритм планирования выполнением задач.
• Механизм взаимодействия процессов в системе ( семафоры, сообщения . )
• Управление прерываниеми.
• Запуском задач в указанные для каждой моменты времени.

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

Более предпочтительными являются такие ОС, где контекст обычно меняется за 10 условных временных тактов, в худшем случае за 12, чем ОС, где хотя в среднем это происходит за 3, но иногда может быть и за 20 условных временных тактов.

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

POSIX RT рассширения.

POSIX это абревиатура Portable Operating Systems Interface (Переносимый интерфейс операционных систем). Cтандарт, предназначенный для достижения переносимости программного обеспечения на уровне исходных кодов. Другими словами, программа для POSIX совместимой операционной системы должна компилироваться и выполняться на любой другой POSIX совместимой ОС, даже, если последняя и от другого поставщика. POSIX стандарт определяет интерфейс который ОС предлагает прикладным программам: набор системных вызовов (set of system calls). POSIX стандарт разрабатывается IEEE (Instiute of Electrical and Electronic Engineering) и стандартизуется ANSI (American National Standards Institute) and ISO (International Standards Organisation). Очевидно, что POSIX основан на UNIX. Большинство ОС, включая Windows NT, стремятся от версии к версии достичь совместимости с POSIX стандартом.

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

POSIX.4-дополнение, переименованное в 1003.1b в 1993 г., позволяет использовать ОС для реального времени. Совершенно очевидно что большинство этих расширений относится к управлению временем и приоритетами процессов, а также системным вызовам для взаимодействия между процессами (the inter-process communication).

POSIX-дополнения разрабатываются для повышения контроля над системой управления ресурсами ОС.

LINUX 2.0 поддерживает многие POSIX-совместимые системные вызовы реального времени . но этот аспект LINUX мы будем обсуждать в будущей статье. Версия 2.2. с большой вероятностью будет на 100% совместима с POSIX 1003.1b.

Linux реального времени (real-time Linux, RT-LINUX)

Victor Yodiken и Michael Barabanov разработали RT-LINUX будучи на факультете компьютерных наук института добычи полезных ископаемых и технологий, расположенного в New Mexico. Michael сделал эту работу частью диплома, Master of computer science. Последняя доступная версия 0.6. На момент написания этой статьи RT-LINUX был доступен только для Intel платформ.

RT-Linux решает проблему поновому. Вместо того, чтобы менять ядро LINUX, пытаясь сделать его предсказуеммым, они написали не зависимое от основного ядра свое маленькое ядро — планировщик. Основное ядро LINUX запускается, как задача этого ядра, разделяя процессор с другими задачами реального времени. Linux использует процессор наравне c другими задачами реального времени, более точно LINUX является фоновой задачей, и исполняется только, если не исполняется ни одна из задач реального времени.

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

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

Ядро LINUX (как и большинство ОС) обычно запрещает прерывания, как средство синхронизации или при выполнении критических участов кода. Если во время, когда Linux запретит прерывания, придет прерывание от часов, оно будет блокированно и, следовательно, потеряна временная точность. В RT-LINUX применено оригинальное решение: все вызовы cli, sti, and iret (ассемблерные команды управления прерываниями) заменены на S_CLI, S_STI и S_IRET, и LINUX никогда не может запретить прерывания.

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

В случае RT-LINUX мы не только имеем систему реального времени, но и класическую ОС. Мы можем гонять WEB, в то время как измеряется и контролируется физический объект.

Установка RT-LINUX.

Файлы дистрибутива находятся на: http://luz.cs.nt.edu/

Для преобразования LINUX в RT-LINUX, нужно модифицировать исходные коды ядра, наложив заплату, которая приходит с RT-LINUX и скомпилировать ядро. Теперь, как это сделать. Я предполагаю, что файл rtlinux-0.6-2.0.33.tgz лежит в директории /usr/src и что он был распакован в директорию /usr/src/rtlinux-0.6. Я также допускаю, что ядро уже сконфигурировано ( make config), и тогда:

Новое ядро появится как и «нормальное» ядро, однако уже приготовленное стать системой реального времни. В директории /usr/src/rtlinux-0.6-2.0.33/testing находятся различные демонстрационные программы.

Кроме примеров, пришедших с дистрибутивом (директория testing), вы можете взять на интеренет (Internet) другой пример подготовленный Олегом, который позволяет нам создать карту времени выполнения задач. Один из файлов этой демо-программы, планировщик с изменениями, он не только планирует выполнение задач, но так же посылает информацию, связанную с принятыми решениями. Это информация накапливается и сохраняется в файле, который может быть отображен графически. В результате мы увидим, в каком порядке различные задачи выполнялись и как задачи с высшим приоритетом захватывали время задач с низшим приоритетом. LINUX, как задача, не представлен.

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

Будущее RT-LINUX.

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

Несколько недель назад начато создание руководства по RT-LINUX.

Заключение

До появления RT-LINUX многие инженеры, которые хотели использовать системы реального времени, были вынужденны использовать MS-DOS и писать все необходимые драйверы или покупать системы реального времени (за запредельные цены). Теперь разработчики имеют полнофункциональную ОС и возможность разрабатывать приложения на той же системе, где они будут запущены. В действительности мы можем запустить несколько приложений реального времени, и в то же время рабоатать на интернет, и без всяких проблем.

Наша следующая статья в этой серии будет рассматривать несколько примеров приложений реального времени, и мы обсудим написание собственных приложений реального времени.
Перевод: dobrozhelatel’ —>

Источник