Software & Systems

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На основе анализа современных ВПК можно сделать вывод о существовании тенденции, обусловливающей перемещение описаний взаимодействий между задачами с уровня задач на системный уровень (рис. 3). При этом из тела задачи исчезают операторы, которые могут приостановить задачу или напрямую повлиять на порядок выполнения других задач. К таким операторам относятся приостановить/возобновить, послать/принять, ожидать/установить и т.д. Задачи, не содержащие операторов приостановки, называют простыми (simple [1]), или базовыми (basic [2]); задачи, содержащие такие операторы, называют составными (complex [1]), или расширенными (extended [2]). В качестве примера перемещения межзадачных взаимодействий на системный уровень можно указать механизм передачи сообщений в ОС ERCOS [3], где нужные задаче сообщения передаются ей в момент порождения задачи, а посылка генерируемых задачей сообщений выполняется в момент ее завершения. Другой пример представляют невытесняемые задачи. В них вместо использования внутри задачи операторов динамической смены приоритета задача специфицируется в системе как невытесняемая, что эквивалентно присвоению задаче высшего приоритета в момент ее активизации.

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

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

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

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

Обратные вызовы. Еще одной специфической особенностью ВПК является наличие обратных вызовов (hooks). В состав приложения включаются процедуры, которые в определенных ситуациях вызываются из ОС. Так, например, после выполнения начальных настроек только что стартовавшей ОС может требоваться и начальная настройка каких-то структур приложения. Последние задаются процедурой с обусловленным именем (например, StartOS_Hook). Формат обращения к процедуре StartOS_Hook является одной из составляющих интерфейса прикладных программ. Ее текст является частью приложения, а вызывается она из обслуживающей функции ОС. В качестве другого типичного примера обратного вызова можно указать ErrorHook – прикладную процедуру, вызываемую из ОС в момент обнаружения ошибки в работе ВПК.

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

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

Операционная система OSEK-OS. Разработка стандарта спецификаций OSEK-OS является плодом коллективной работы целого ряда фирм, координируемой комитетом с одноименным названием [2]. Аббревиатура OSEK в переводе с немецкого означает "Открытые системы и соответствующие интерфейсы для автомобильной электроники".

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

Комитет дает также ряд рекомендаций (на уровне примеров) по построению языка задания конфигурации приложения. Этот язык получил наименование OIL (Object Implementation Lan-guage). Однако в настоящее время язык OIL не доведен до уровня стандарта.

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

Программные приложения, написанные для конкретного класса согласованности, могут переноситься на любые другие реализации OSEK-OS того же класса. Это обеспечивается определением системных функций ОС, набором их возможностей и поведением, определенным для каждого класса соответствия. Системные функции являются интерфейсом между программным приложением и ОС. Этот интерфейс является единым для всех реализаций ОС на различных процессорных платформах. Системные функции определены в соответствии с синтаксисом ISO/ANSI-C, но способ реализации и, в частности, язык программирования системных функций не специфицирован.

Системные функции OSEK-OS сгруппированы в соответствии с их функциональным назначением в пять групп: 1) управления задачами, 2) синхронизационные, 3) управления прерываниями, 4) караульные, 5) обработки ошибок.

Как отмечалось выше, OSEK-OS поддерживает базовые и расширенные задачи. Базовые задачи освобождают процессор в трех случаях: задача завершается; OSEK-OS выполняет задачи с более высоким приоритетом; пришло прерывание, которое вызывает переключение процессора на программу обработки прерывания. Расширенные задачи отличаются от базовых тем, что они могут использовать системный вызов WaitEvent, который может перевести задачу в состояние ожидания. Когда задача находится в этом состоянии, процессор освобождается и может быть использован задачей более низкого приоритета.

Операционная система ERCOS. ERCOS разработана в компании ETAS GmbH &Co.KG (Германия) [3] в соответствии с требованиями, предъявляемыми к ВПК автомобильной промышленностью. Она имеет инструментальную и целевую части. Инструментальная часть состоит из программных средств, обеспечивающих оптимизацию структуры целевой части для конкретного программного приложения. Структура целевой части построена на основе понятия объекта, то есть система подразделяется на автономные активные объекты, называемые подсистемами, по функциональному принципу: ввод, вывод, вычисле- ния и т.п. Кроме того, вводится понятие процесса, который представляет собой функционально замкнутый блок, выполняющий некие последовательные действия, и который, в принципе, может выполняться параллельно с другими процессами. В однопроцессорной системе параллельное выполнение процессов обеспечивает ОС.

Одним из важных функциональных требований, предъявляемых к ОСРВ, является обеспечение разделения ресурсов. Наиболее часто для этой цели используется механизм семафоров. Однако этот механизм не годится для использования во встроенных системах из-за известного эффекта инверсии приоритетов. В ERCOS для организации доступа к ресурсам используется оптимизированный стековый протокол предельного приоритета (optimized stack based priority ceiling protocol), который представляет собой оптимизированный вариант протокола наследования приоритета и заключается в следующем. Когда процесс обращается к ресурсу (или критическому участку программы), он получает приоритет, соответствующий максимальному значению приоритета среди всех процессов, которые могут затребовать этот ресурс. При этом изменение приоритета происходит не при возникновении конфликтной ситуации доступа к ресурсу, а непосредственно при обращении процесса к ресурсу, что характеризует стековый вариант этого протокола. ERCOS поддерживает этот протокол благодаря своей инструментальной части, которая обеспечивает статический анализ предельно высоких приоритетов для каждого ресурса ВПК. Оптимизация протокола также осуществляется инструментальной частью. Она заключается в том, что, во-первых, для процесса с максимальным приоритетом среди всех процессов, обращающихся к данному ресурсу, нет необходимости обращаться к функциям ОС для изменения приоритета и возврата его в прежнее состояние, поэтому эти обращения в нем подавляются. Во-вторых, если длительность использования ресурса (или выполнения критического участка программы) примерно равна длительности обращений к функциям ОС для смены приоритета, то просто осуществляется выполнение доступа к данному ресурсу при блокированных прерываниях. Помимо реализации оптимизированного стекового протокола предельного приоритета, инструментальная часть во время статического анализа исходного текста программы обеспечивает выявление незаконного обращения к критическим ресурсам вне участков программы, защищенных данным протоколом.

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

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

Операционная система SSX5. Встроенная OC SSX5 [4], разработанная компанией NRTA (North Real-Time Applications) (Великобритания), внедрена во встроенных системах, управляющих узлами и агрегатами автомобиля Volvo S80. ОС SSX5 позволяет строить приложения, реализующие синхронный подход. Она предусматривает использование статически конструируемых графиков выполнения вытесняемых и невытесняемых периодических задач. В состав статических функций включен инструментарий, позволяющий экспериментально выполнять измерения худшего времени исполнения задач. Надежная информация о худшем времени исполнения периодических задач позволяет строить статические графики, обеспечивающие предсказуемое поведение приложения при высокой степени загрузки процессора. Вместе с тем в состав OC SSX5 включены средства, позволяющие включать в приложение задачи, управляемые событиями. Для этого используются семафоры, реализованные с использованием оптимизированного протокола предельных приоритетов. Таким образом, OC SSX5 сочетает свойства событийных и синхронных систем. Отмечается высокая компактность и эффективность OC SSX5: в таблице даны накладные расходы при реализации тестового примера с десятью задачами, в микроконтроллерах 68HC08 и MPC505 компании Motorola.

Операционная система TTPos. Примером чисто синхронных систем является разработанная в компании TTTech Computertechnik GmbH (Австрия) ОС TTPos [5]. Система предназначена для реализации распределенных ВПК, использующих синхронные сетевые протоколы TTP (Time-Triggered Protocol) [6]. В части организации интерфейса прикладных программ TTPos следует спецификациям OSEK-OS с той разницей, что устранены все функции, связанные с использованием событий. Приложение, использующее TTPos, функционирует в режиме интерпретации статически генерируемых графиков (time-tables) активизации периодических задач и передачи сообщений.

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

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

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

2. OSEK/VDX. Operating system. Version 2.0, revision 1, 15 October 1997: http://www.etec.uni-karlsruhe.de/~osek. 76 p.

3. ERCOS White paper. Version 1.00. ETAS GmbH & Co: http://www.etas.de. 36 p.

4. Tindel K. Embedded systems in the automotive industry. Northern Real-Time Applications: http://www.nrtg.com/nrta. 66 p.

5. Time-Triggered Fault-Tolerant Operating System with TTP support. Version 1.0.0, 15February 1999: http://www.tttech.com. 36 p.

6. Kopetz H., Grunsteidl G. TTP - A Protocol for Fault-Tolerant Real-Time Systems. Computer, Vol. 27, No. 1, January 1994, pp. 14-23.