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

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

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

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

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

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

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

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

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

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

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

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

ОСОН в роли задачи реального времени. Известен подход к интеграции ОСОН в СРВ, отличающийся тем, что ОСОН (вместе со своими прикладными задачами) включается в интегрированный программный комплекс в качестве одной из задач СРВ [2].

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

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

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

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

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

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

1) накладываются ограничения на состав операций, выполняемых прикладными задачами ОСОН: в рамках этих задач запрещается использование команд явного управления приоритетом процессора;

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

Такие ограничения могут оказаться неприемлемыми. Поэтому актуален поиск других схем интеграции ОСОН и ОСРВ.

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

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

Задачи реального времени в среде виртуальной Java-машины. Для эффективного программирования СРВ требуются специальные языки. Попытки создания таких языков не прекращаются на протяжении последних 20–25 лет, предоставляя разработчикам различные варианты языков программирования реального времени (ЯПРВ), обеспечивающих программирование взаимодействующих процессов; возможность прямого доступа к адресному пространству вычислительной системы; возможность обработки асинхронных событий и максимально возможную независимость программного обеспечения от аппаратной платформы.

К наиболее известным разработкам в этом направлении следует отнести Modula-2 и ADA, которые, однако, так и не получили широкого признания в секторе производства программного обеспечения СРВ.

В начале 90-х годов компания Sun Microsystems представила спецификацию языка Java, призванного реализовать концепцию мобильности программного обеспечения write once – run anywhere. Переносимость программ обеспечивается за счет использования виртуальной машины, конфигурируемой под различные платформы и интерпретирующей байт-код строго определенного формата, являющийся результатом компиляции платформо-независимого исходного текста. Успех предложенной разработки следует отнести как на счет изящных решений, предложенных авторами, так и на счет больших средств, которые вкладывались в раскрутку данного продукта. Спецификация и реализация Java предусматривают возможность программирования приоритетных потоков – нитей, обеспечение взаимного исключения с помощью монитора и синхронизации посредством механизма сигналов. Однако с точки зрения требований реального времени предлагаемые средства не могли выдержать сколько-нибудь серьезной критики.

Во-первых, планирование и диспетчеризация нитей, реализованных в виртуальной машине, не обеспечивают их предсказуемого поведения. Вторым фактором является недостаточно прозрачная спецификация конструкций, поддерживающих работу с нитями: монитора (synchronized), механизма синхронизации (методы wait() и notify()), методов прекращения прерывания работы нитей (stop(), interrupt()) и т.п. Третий и, пожалуй, основной фактор заключается в том, что автоматическое управление памятью (размещение объектов и сборка мусора) не позволяет обеспечить гарантированное время реакции системы. Тем не менее, несомненные достоинства Java как современного объектно-ориентированного языка программирования вызывают к нему постоянно растущий интерес как к базовому средству для программирования СРВ и инициируют усилия специалистов по доработке существующих на сегодняшний день решений.

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

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

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

Методы Java-классов, к которым предъявляются строгие требования с точки зрения времени выполнения, реализуются на языке C как Native-методы, связанные с их вызовом при интерпретации байт-кода через специально специфицированный Native Interface.

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

Программный интерфейс реального времени включает в себя классы, позволяющие программировать обработку асинхронных событий, параллельные процессы с предсказуемым приоритетным управлением, операции синхронизации, свободные от инверсии приоритетов. В настоящее время в США две рабочие группы занимаются разработкой рекомендаций и спецификаций такого программного интерфейса с целью его стандартизации [3,4]. Положительный результат этой деятельности, который предполагается получить в начале 2000 года, позволил бы строить в значительной степени переносимые приложения реального времени.

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

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

Список литературы

1. Kopetz H. Real-time Systems. Design principles for Distributed Embedded Applications. Kluwer Academic Publisher, Boston, 1997, 338 p.

2. Yodaiken V. The RTLinux Manifesto. New Mexico Institute of Technology, http://www.rtlinux.edu, 1999, 12 p.

3. Real-Time API. Sun Microsystems real-time API preliminary specifications, 01.02.99. http://www.sdct.itl.nist.gov/~carnahan/real-time/sun/api.html

4. Functional Requirements for Core Real-Time Extensions for the Java Platform. http://www.j-consortium.org/rtjwg.html