CC BY
40
мени С выполнения одного экземпляра этой задачи: С (к) = кС.
Однако в реальных системах нередко встречаются задачи с такими ветвями, которые имеют большое время выполнения, но выполняются достаточно редко и никогда не выполняются в двух подряд следующих экземплярах задачи. Следовательно, для таких задач имеет место отношение С (к) < кС{ , что позволяет соответствующим образом усилить выражения (3, 4, 6, 7) и все им подобные.
По мере развития технологии программирования расширяется состав свойств, параметров, атрибутов, отражающих особенности задач и структуры межзадачных отношений в программных комплексах, обеспечивающих функционирование СРВ. Соответственно усложняются языковые средства, используемые для спецификаций системных отношений в таких программных комплексах, расширяется состав целей и методов статической обработки спецификаций СРВ. В частности, в последнее десятилетие ин-
тенсивно развиваются методы построения жестких СРВ, эффективно использующих процессорное время. Предложенные в настоящей статье методы учета внутренних сроков выполнения задач учета времени выполнения последовательностей экземпляров задач представляют собой очередные шаги в этом направлении.
Список литературы
1. Никифоров В.В., Павлов В.А. Операционные системы реального времени для встроенных программных комплексов. // Программные продукты и системы. - 1999.- №4.- С.24-30.
2. Tindell K., Hansson H. Real Time Systems by Fixed Priority Scheduling. DoCS, Uppsala University, 1997.
3. Audsley N.C. Resource Control For Hard Real-Time Systems. University of York, UK, 1991.
4. Larsson J. ScheduLite: A Fixed Priority Scheduling Analysis Tool. Uppsala University, 1996.
5. Gerber R., Hong S. Semantic-Based Compiler Transformations for Enhanced Schedulability. University of Maryland, 1993.
6. Сорокин С. Системы реального времени: операционные системы. // Современные технологии автоматизации. - 1997.- №2.-С.22-29.
СОПРЯЖЕНИЕ ПАКЕТОВ ПРОГРАММ ОБЩЕГО НАЗНАЧЕНИЯ С ЗАДАЧАМИ ЖЕСТКОГО РЕАЛЬНОГО ВРЕМЕНИ
В.В. Никифоров, М.В. Данилов, М.В. Осипов
В ряду средств вычислительной техники выделяют два класса систем, различающихся назначением, характером использования. Один класс представляют компьютерные системы общего назначения, к которым относятся, в частности, персональные компьютеры и рабочие станции. Другой класс составляют встроенные системы, функционирующие в составе автоматизированных узлов, агрегатов, машин. Они являются частью их конструкции. Эти классы систем различаются характером требований к выполнению прикладных задач, составом услуг, предоставляемых прикладным задачам со стороны операционной системы и стандартных библиотек, критериями эффективности организации вычислений.
В частности, основным критерием оптимизации работы систем общего назначения является повышение средней производительности системы. Критерии оптимизации встроенных систем определяются требованиями корректного выполнения задач жесткого реального времени (РВ). Во встроенных системах требуется оптимизация худшего времени выполнения задач, гарантированные сроки выполнения задач, минимизация задержек обработки прерываний. К встроенным системам, как правило, предъявляются повышенные требования надежности исполнения функций, предсказуемости поведения системы при любой комбинации условий функционирования. Выполнение этих требований достигается за счет использования операционных систем реального времени (ОСРВ).
Подходы к сопряжению приложений операционных систем общего назначения (ОСОН) с задачами РВ. До недавнего времени типовые системы
общего назначения существенно отличались от типовых встроенных систем по архитектуре и производительности используемых процессоров. Процессоры систем общего назначения были, как правило, значительно более дорогостоящими и более мощными, чем процессоры встроенных систем. Однако в последнее время наметилась тенденция смягчения и даже устранения этого различия. Удешевление, уменьшение габаритов и энергопотребления мощных процессоров открывает возможности их использования во встроенных системах массового производства. Это создает предпосылки использования во встроенных системах широкого комплекса услуг, пакетов программ, разработанных в ходе десятилетий эксплуатации систем общего назначения. Но эти услуги, наборы программ созданы для исполнения под управлением ОСОН. В связи с этим возникает необходимость оценки перспективности следующих подходов к использованию программных средств общего назначения во встроенных системах:
- адаптация распространенных ОСОН к использованию во встроенных системах;
- использование адаптированных таким образом версий ОСОН к обслуживанию прикладных задач РВ;
- построение двуядерных систем, в которых работа адаптированной ОСОН сопрягается с работой ОСРВ, гарантирующей своевременное выполнение прикладных задач жесткого РВ;
- модификация ядер ОСОН, обеспечивающая обслуживание задач жесткого РВ с сохранением интерфейсов прикладных программ, реализуемых исходной версией ОСОН.
19
Работы по этим направлениям проводятся в последние годы для ОСОН различных типов. Так, фирмой Microsoft разработана ОС для встроенных приложений Windows CE (Compact Edition), реализующая интерфейс прикладных программ Win32, который широко использовался ОС Windows для персональных компьютеров. Фирмой Real-Time Consult выполнены исследования по оценке перспективности ОСОН Windows NT 4.0 в качестве ОС для приложений РВ [1]. Известен ряд работ по адаптации для работы во встроенных системах свободно распространяемой ОСОН Linux [5].
Характеристики системы Windows CE 2.0. Проект создания ОС Windows CE был ориентирован на реализацию интерфейса прикладных программ Win32 для приложений, обеспечивающих работу встроенных систем. Вместе с тем ОС Windows CE плохо приспособлена для поддержки приложений, обеспечивающих работу систем жесткого РВ [2]. Это утверждение обосновывается рядом факторов. Во-первых, ОС Windows CE не допускает вложенных прерываний. Поэтому обработку внешних событий приходится разделять на начальную фазу - аппарат-но-инициализируемый обработчик прерываний (interrupt service routine - ISR), и высокоприоритетную задачу (interrupt service thread - IST), которая выполняет завершающую фазу обработки внешнего события. Во-вторых, в системе предусмотрено всего восемь уровней приоритета задач (включая высший уровень, выделяемый для IST). Столь ограниченное количество уровней приоритета признается недостаточным для реализации принятых в системах РВ дисциплин обслуживания задач, в частности, дисциплины частотно-монотонного (rate monotonic) обслуживания. Кроме того, при наличии разно-приоритетных внешних событий некоторым IST приходится занимать пониженные уровни приоритета.
Результаты измерений характеристик быстродействия ОС Windows CE, выполненные фирмами Real-Time Consult и GM Powertrain, также демонстрируют ограниченную пригодность этой ОС для поддержки приложений РВ. В ряду характеристик быстродействия ОСРВ основное внимание уделяется величинам задержек обработки внешних событий и затратам на переключение контекстов (переключение процессора с выполнения одной задачи на выполнение другой).
Измерения задержек обработки внешних событий для ОС Windows CE дают удовлетворительные результаты только при отсутствии загрузки процессора системными задачами (для Intel Pentium с частотой 100-200 МГц задержка не превышает нескольких десятков мкс) [2,3]. Однако задержки обработки внешних событий на фоне вывода графики достигают сотен мкс для IST высшего приоритета и десятков мс для IST с пониженными уровнями приоритета. Таким образом, величины задержек обработки внешних событий в зависимости от условий могут различаться в тысячи раз. Это обстоятельство снижает возможности использования ОС Windows CE для реализации систем жесткого РВ.
По данным измерений затраты на переключение контекстов в Windows CE составляют несколько мкс. Однако если задача активизируется впервые, то эти затраты возрастают на порядок; это объясняется тем, что выделение задаче требуемых ресурсов осуществляется не в момент ее порождения, а в момент ее первой активизации. Значительные затраты времени на начальную активизацию задач могут стать препятствием для реализации техники одноразовых задач в системах РВ.
Возможности построения систем РВ на базе ОС Windows NT 4.0. При разработке этой системы были использованы эффективные принципы структурирования системы: клиент-серверный подход, рациональное расслоение ядра ОС, использование абстрактного низкоуровневого интерфейса (Hardware Abstraction Layer - HAL). Принципы структурирования способствуют повышению надежности системы, мобильности, снижению трудоемкости ее переноса на другие аппаратные платформы. Незначительное снижение быстродействия, которым оплачиваются эти преимущества, несущественно для ОСОН, однако остается открытым вопрос о том, насколько оно влияет на возможности использования ОС для реализации приложений РВ.
В ОС Windows NT имеется более двадцати уровней приоритета задач. Из них 16 выделено для задач, обслуживаемых по правилам, характерным для ОСОН и непригодным для задач РВ. Высшие 7 уровней приоритета ориентированы на использование задачами РВ, однако, как уже отмечалось, для использования современной техники построения приложений РВ необходимо наличие существенно большего числа уровней приоритета задач.
Измерения характеристик быстродействия ОС Windows NT дают результаты того же порядка, что и для Windows CE. Типовая задержка обработки внешних событий - порядка нескольких десятков мкс, типовые затраты на переключение контекстов задач -порядка нескольких мкс. Однако, как и в случае Windows CE, возможны ситуации, в которых время переключения контекста задач возрастает в сотни
20
раз [1], что существенно снижает возможности непосредственного использования ОС Windows NT для построения приложений РВ.
В связи с этим возникают разработки по адаптации ОС Windows NT к работе в системах жесткого РВ. К разработкам такого типа относится, в частности, система Intime (фирма RadiSys [4]), в основу которой положено сопряжение двух ядер: адаптированное ядро ОС Windows NT и ядро ОСРВ iRMX. При этом ОС Windows NT обеспечивает выполнение пакетов программ общего назначения; имеющая двадцатилетнюю историю разработок и эксплуатации ОСРВ iRMX обслуживает задачи жесткого РВ. Основа архитектурного решения: все задачи ОС Windows NT выполняются как низкоприоритетные задачи ОСРВ iRMX. Разработаны механизмы координации выполнения и обмена информацией между задачами РВ и задачами ОС Windows NT. Предусмотрены возможности конструирования распределенных систем, связываемых через Ethernet, последовательный интерфейс и другие сетевые средства.
Версии ОС Linux для встроенных приложений. Система Linux является свободно распространяемой ОСО^ ориентированной на поддержку стандарта пользовательского интерфейса POSIX. Хорошо сконструированная и реализованная [5], она привлекла внимание широкого круга разработчиков, которыми было создано большое разнообразие библиотек и инструментальных средств, ориентированных на использование системы Linux.
Доступность исходных кодов вместе с высоким уровнем структурирования системы Linux обеспечивает возможность ее переноса на новые архитектурные платформы, поэтому первоначальная разработка, выполненная для ПК с 38б-м процессором, впоследствии была перенесена на большинство широко распространенных архитектур, включая Alpha, ARM, IA-64, MIPS, PA-RISC, PowerPC, SPARC.
Среди большого числа проектов создания ОС на основе Linux выделяются специализированные версии этой ОС, в частности, ориентированные на использование во встроенных системах (Embeddix, ET-Linux, Hard Hat Linux). Разработчики фирмы Lineo считают, что сегодня рынок встроенных систем простирается от управляющих устройств (УУ) для небольших механических узлов до сравнительно дорогостоящих вычислительных комплексов с объемами оперативной памяти до б4 Мб (см. табл.). Использование ОС Linux возможно для большинства встроенных систем, за исключением микроуправляющих устройств и нижнего слоя мини-управляющих устройств.
Объем Микро- Мини- Миди- Макси- Портатив-памяти УУ УУ УУ УУ ные ПК ОЗУ (Мб) 0 -.1 .1 - 4 2 - 8 8 - 32 1б - б4 ПЗУ, .1-.5Мб .5 - 2Мб 2 - 4 Мб 4 - 1б Мб Гб диски______
В большей части проектов, связанных с модификацией Linux, для применения во встроенных системах с ядром ОС (оставляемым без изменений) интегрируется специфическое программное окружение, оптимизированное по использованию памяти. Такого рода программные комплексы требуют наличия в составе аппаратных средств полного набора устройств, характерных для систем общего назначения. Примером такого рода продуктов является Lineo Embeddix, требующая, в частности, 4 Мб ОЗУ и 2 Мб ПЗУ. Отметим, что Lineo Embeddix оснащена средствами разработки встроенных приложений.
В некоторых проектах с целью расширения спектра используемых платформ выполнена модификация ядра, снижающая требования к составу аппаратуры. В качестве примера можно привести ucLinux, предназначенный для процессоров без блока управления памятью. Существенным недостатком такого подхода являются обусловленные им изменения прикладного программного интерфейса ОС.
Для встроенных систем, работающих в условиях РВ, важно гарантированное время реакции на внешние события. В этой связи разрабатывается большое число версий ОС Linux, отвечающих требованиям поддержки выполнения задач в РВ, в частности в жестком РВ. При этом реализуется один из двух подходов: первый опирается на построение варианта планировщика с более эффективными алгоритмами планирования (системы KURT, Qlinux), второй основан на построении двуядерной ОС, где Linux в качестве нулевой задачи работает под управлением ОСРВ (RT-Linux, Zentronpx RealTime Linux).
Методика адаптации Linux для работы во встроенных системах. Встроенные версии ОС Linux, как правило, реализуют ограниченный состав системных услуг, ориентированный на конкретные область приложений и конфигурацию аппаратных средств, на специфические критерии оптимизации. Разработка на базе ОС Linux программных средств для нового класса встроенных систем во многих случаях требует создания новой модификации встроенной ОС типа Linux.
Простейший подход к созданию требуемой модификации ОС Linux возможен в ситуациях, когда доступна такая версия ОС Linux, которая позволяет построить требуемую модификацию имеющимися в данной версии средствами статического конфигурирования ядра. Такой подход, естественно, наиболее предпочтителен, поскольку гарантирует проверенное качество при минимальной трудоемкости. Однако его реализация требует существования (и доступности) встроенной версии Linux для выбранной целевой платформы; версия должна включать требуемые динамические механизмы и соответствующие средства статического конфигурирования. Если эти условия не выполнены, то простейший подход не реализуем, для создания требуемой версии ОС Linux необходимо
Таблица
Разбивка рынка ОС на сегменты по объемам доступной памяти
Встроенные системы
Обособленные, независимые системы
Настоль- Сетевые Большие ные ПК серверы серверы 32- 128 128+ Гб десятки Гб сотни Гб до терабайт
21
: 1200 Я 1000
модифицировать часть исходных кодов ОС.
Если ОС Linux переносится на новую платформу в полном объеме, то необходимо выполнить следующие задачи: а) разработку загрузчика; б) разработку архитектурно-зависимого кода; в) добавление необходимых драйверов; г) перенос требуемых приложений.
ОС Linux реализована таким образом, что основная часть кода не зависит от аппаратуры, поэтому объем работ по пункту б минимизирован. Пункт г относится не непосредственно к ОС, а к сопутствующим программным продуктам. Перенос собственно ОС Linux на новую платформу в полном объеме не связан с возникновением технических проблем.
Проблемы возникают в случае, если на целевой платформе отсутствуют аппаратные средства, используемые исходной версией ОС. Простейший пример - объем памяти (оперативной, постоянной): например, если исходная версия рассчитана на использование блока управления памятью, а на целевой платформе этот блок отсутствует. Технические сложности, возникающие в подобных случаях, обусловлены монолитностью ядра ОС Linux: несмотря на то, что ядро состоит из функционально самостоятельных подсистем, интерфейсы между ними не специфицированы и недостаточно упорядочены. Так, представленная на рисунке 1 схема связей подсистемы, ответственной за управление памятью [6], показывает, что эта подсистема сильно связана со всеми подсистемами ядра разными типами связей. Монолитность ядра приводит к тому, что при устранении одной из подсистем ОС Linux приходится отслеживать ее связи со множеством модулей ядра и вносить изменения в эти модули. Разработчик, переносящий Linux на новую целевую платформу, должен быть готов к преодолению этих трудностей.
Можно указать два противоположных подхода к разработке ограниченной версии ОС Linux для новой платформы на базе имеющегося исходного кода. В соответствии с первым подходом (разработка "сверху вниз") из полной версии системы последовательно устраняются ненужные механизмы ядра и подсистемы. При этом на каждом шаге приходится отслеживать разнотипные связи устраняемого механизма, подсистемы с остающимися фрагментами кода системы. Реализация второго подхода (разработка "снизу вверх") начинается с построения минимальной дееспособной версии ядра, к которой последовательно привязываются коды нужных подсистем.
Показатели эффективности управления задачами в ОС Linux. В ОС Linux реализованы два варианта дисциплины планирования исполнения задач. Первый вариант, ориентированный на приложения общего назначения, реализует дисциплину разделения времени [7]. Второй вариант, ориенти-
1 52 103 154 205 256 307 358 409 460 Номер этапа эксперимента
1 52 103 154 205 256 307 358 409 460 Номер этапа эксперимента
а) б)
Рис. 2. Операции порождения и ликвидации задач при изменении загрузки системы
рованный на приложения РВ, реализует механизм планирования с фиксированными приоритетами (100 уровней приоритета задач). Выполненные авторами эксперименты показывают, что реализация механизмов управления задачами РВ имеет особенности, затрудняющие использование ОС Linux для приложений жесткого РВ. Измерительные эксперименты проводились на рабочей станции Compaq с процессором Intel Pentium II 266 МГц и 64 Мб оперативной памяти. Некоторые из результатов этих экспериментов приведены на рисунках 2-4.
В ОС Linux предусмотрены две разновидности задач - процессы и потоки. На рисунке 2 приведены данные по продолжительности выполнения операций порождения и удаления процессов и потоков. Рост графика (рис. 2,а) вызван увеличением полезной загрузки системы (числа имеющихся в системе процессов или потоков); снижение продолжительности операций (рис. 2,б) вызвано уменьшением загрузки системы. Видно, что переход от процессов к потокам дает выигрыш по временным характеристикам. При небольшом числе задач порождение потока выполняется в несколько раз быстрее, чем порождение процесса.
На рисунке 3 приведены результаты экспериментов, в которых процесс (поток) уничтожается на том же этапе эксперимента, на котором создается. В этом случае среднее время создания потока не изменяется от этапа к этапу, а время создания/ликвидации потоков монотонно возрастает.
В экспериментах (рис. 3) загрузка системы остается неизменной: на каждом этапе эксперимента вновь порожденный поток (процесс) немедленно уничтожается. Видно, что расходы времени на создание/ликвидацию процесса не зависят от числа завершенных этапов эксперимента, а при операциях с потоками аналогичные расходы монотонно возрастают. Это вызвано разновидностью утечки ресурсов: потоки Linux не освобождают всех системных ресур-
1 50 99 148 197 246 295 344 393 442 Номер этапа эксперимента
99 148 197 246 295 344 393 442 Но мер этапа эксперимента
Рис. 3. Операции порождения и ликвидации задач при неизменной загрузке системы
1500
1000
1роцессы
1 50
22
> 5000 м 4000
> 3000
О 2000 : 1000 е 0
1 12 23 34 45 56 67 78 89 100 Номер этапа эксперимента
v 120 км100
1 1.1
1 50 99 148 197 246 295 344 393 442 Номер этапа эксперимента
а) б)
Рис. 4. Продолжительность выполнения операций создания процесса (а) и операций создания файла (б)
сов до завершения работы родительской задачи. Утечка затрагивает и строки задействованных системных таблиц. Размер этих таблиц фиксирован, откуда следует, что Linux не может использоваться для приложений, в которых широко применяется динамическое создание и уничтожение потоков.
На рисунке 4,а показана зависимость времени создания дочернего процесса Linux от размера родительского процесса. На каждом шаге эксперимента размер родительского процесса увеличивался на одну страницу (4 Кб). Как видно из графика, время создания дочернего процесса увеличивается в среднем на 40 мкс при увеличении объема используемых родительским процессом данных на одну страницу. Это объясняется необходимостью копировать весь объем данных родительского процесса, поскольку в Linux вновь создаваемый процесс является точной копией родительского [8]. Отметим, что в целях повышения эффективности ОС не выполняет реальную операцию копирования, пока в этом не возникнет необходимости. Дочерний и родительский процессы совместно используют страницу памяти, пока один из процессов не выполнит модификацию информации, располагающейся на этой странице. Следовательно, если при создании дочернего процесса не выполнить принудительного копирования страниц с данными, то простая операция присваивания может вызвать задержку выполнения процесса на несколько десятков мкс.
На рисунке 4,б показано время создания файла. Вид графика (возрастание с насыщением) объясняется тем, что реальное освобождение элементов файловой таблицы производится лишь по мере необходимости.
В начале каждого из приведенных графиков имеется выраженный всплеск. Это объясняется тем, что ядро Linux выполняет кэширование данных и команд. Механизм кэширования повышает среднюю производительность системы, но ухудшает предсказуемость ее работы.
Измерения задержек обработки внешних событий для ОС Linux также показывают ограниченную пригодность этой ОС для обслуживания приложений РВ. Многие подсистемы ядра Linux запрещают обработку внешних прерываний для защиты критических секций. При работе с такими устройствами, как жесткий диск или сетевая карта подобный подход приводит к задержкам начала обработки внешних событий до нескольких сотен мкс. Есть еще одно обстоятельство, препятствующее своевременной реакции
на внешние события: процесс в Linux может выполняться либо в режиме пользователя, либо в режиме ядра, при этом возможны ситуации, когда высокоприоритетный процесс не может захватить процессор до выхода низкоприоритетного из режима ядра.
Перечень характеристик ОС Linux объясняет необходимость ее доработки в случае возникновения требований поддержки ею приложений РВ.
Сопряжение Linux с ядром РВ. В [9] представлен один из возможных подходов к использованию ОС Linux в системах РВ. Суть подхода заключается в том, что Linux работает в качестве фоновой задачи под управлением небольшого ядра ОСРВ (система переключается на решение задач Linux только тогда, когда нет ни одной задачи РВ, требующей ресурса процессора). При этом коды Linux адаптируются к работе на виртуальной машине. Компоненты Linux не имеют доступа к аппаратным флагам запрещения/разрешения прерываний: все реальные прерывания перехватываются ОСРВ и при необходимости отображаются состоянием виртуальной машины (рис. 5).
Взаимодействие подсистем Linux и РВ осуществляется посредством программной эмуляции работы подсистем на разных машинах. Для обмена информацией предусмотрены разделяемая память и механизм очередей элементарных сообщений, передача которых не требует синхронизации.
Основное достоинство систем, реализуемых на базе принципа фоновой задачи - высокое качество работы подсистем РВ. Однако такая модель имеет два существенных недостатка. Во-первых, ОСРВ должна приостанавливаться на время обработки каждого из прерываний Linux. Во-вторых, реализация взаимодействия задач Linux и ОСРВ неэффективна и неудобна в использовании. В частности, вопросы синхронизации задач ОСРВ и Linux приходится решать на прикладном уровне. Авторами найдены конструктивные решения, позволяющие устранить эти недостатки.
Первый из отмеченных недостатков эффективно устраняется, если целевая система имеет два или более уровней прерываний. Примером такой целевой системы является 32-разрядный микроконтроллер M-Core фирмы Motorola. Ключевой для предлагаемого решения особенностью архитектуры микроконтроллера M-Core является то, что на уровне процессора осуществляется поддержка двух типов прерываний: быстрых (более приоритетных) и обычных (менее приоритетных). Предлагаемое решение характеризуется следующими положениями (рис. 6):
23
ч__ЗадачаТ|пих^)
С
Виртуальная
машина ОСРВ
J
Аппаратура
Рис. 5. Сопряжение Linux с ОСРВ через виртуальную машину
Л
Linux
JZZ
С^Задача F
Л
v ! ОСРВ
Т
т
Аппаратный интерфейс
| УстройсТва Linux | | Устройства ОСРВ~|
Рис. 6. Сопряжение Linux с ОСРВ в системе с архитектурой M-Core
Задача Linux
устройства делят- '
ся на работающие в режиме РВ (устройства ОСРВ и на контролируемые подсистемами Linux (устройства Linux);
• устройства Linux могут генерировать только обычные прерывания (INT), на рисунке прерывания типа INT обозначены тонкими стрелками;
• устройства ОСРВ генерируют более приоритетные, быстрые прерывания (FINT), на рисунке прерывания типа FINT обозначены жирными стрелками;
• выделяются два режима работы ВПК - режим Linux и режим ОСРВ;
• в режиме работы Linux все действия выполняются только с обычными прерываниями, в режиме ОСРВ - только с быстрыми прерываниями.
Таким образом, Linux, разрешая или запрещая прерывания, выполняет соответствующие операции только с флагом обычных прерываний. Во время работы в режиме Linux быстрые прерывания разрешены, причем при поступлении быстрого прерывания система переключается на решение задач РВ.
В режиме ОСРВ работа ведется только с быстрыми прерываниями, то есть модули ОСРВ, разрешая или запрещая прерывания, производят соответствующие действия только с флагом быстрых прерываний. Во время работы системы в режиме ОСРВ обычные прерывания запрещены. Переход встроенного программного комплекса в режим Linux происходит в момент, когда задачи РВ и модули ОСРВ не нуждаются в использовании процессора, при этом флаг разрешения/запрещения обычных прерываний приводится в состояние, в котором он находился в момент переключения системы в режим ОСРВ.
жЧастичное устранение второго недостатка (ускорение и упрощение взаимодействия задач общего назначения и РВ) достигается за счет выделения таких компонент ядра Linux, которые работают в режиме запрещенных прерываний и ведут себя предсказуе-Таким компо-
мо.
нентам ядра Linux предоставляется непосредственный доступ к системным сервисам ядра ОСРВ (рис. 7).
Аббревиатура МВ на рисунке 7 означает модули взаимодействия, оформляемые в виде задач ОСРВ.
Задача Linux
СЗаДачаОСрВ>
Аппаратура
Рис. 7. Оформление части компонент Linux в виде задач ОСРВ
Наряду с модулями ядра Linux в этой нише можно размещать и создаваемые прикладными программистами драйверы, включаемые в состав ядра Linux. МВ, являющиеся компонентами ядра Linux, удовлетворяют как требованиям, предъявляемым к компонентам ядра Linux, так и требованиям, предъявляемым к задачам ОСРВ.
Трудоемкость реализации предлагаемых решений невысока. Вместе с тем они позволяют эффективно объединить задачи ОС Linux с задачами РВ.
Показатели эффективности сопряжения Linux с ОСРВ. При реализации рассмотренных принципов сопряжения задач РВ с программами ОСОН Linux эффективность обслуживания задач ОСРВ не зависит от особенностей организации Linux: качество сервисов, предоставляемых задачам РВ, зависит только от характеристик ядра ОСРВ. Независимость разработки ядер ОС позволяет использовать накопленный опыт в разработке ОСРВ с повышенными требованиями к предсказуемости работы. Экспериментальный вариант системы с архитектурой, представленной на рисунках 6 и 7, имеет фиксированное, не зависящее от количества задач в системе время создания и уничтожения задач РВ (12 и 5 мкс соответственно). Задержка начала обработки внешнего события составляет несколько мкс. Данные получены на аппаратной платформе, значительно уступающей по производительности рабочей станции Compaq (тактовая частота процессора M-Core - 60 МГц).
Основным недостатком известной реализации RTLinux [9] является высокая сложность и низкая эффективность взаимодействия между задачами Linux и задачами ОСРВ. Представленный на рисунке 7 вариант сопряжения Linux с ОСРВ позволяет организовать более эффективную координацию действий и информационных потоков. Для сравнения двух механизмов взаимодействия был проведен ряд измерительных экспериментов (рис. 8).
40 30
Время , (мкс)
□ RTLinux
□ ERL
2 50 100
Объем данных (в словах)
Рис. 8. Продолжительность операций передачи данных
В ходе экспериментов измерялось время, необходимое для копирования блока данных из адресного пространства Linux в адресное пространство ОСРВ (выполнение этой операции с блоком, размер которого превышает слово процессора, требует синхронизации). Как видно из рисунка, использование предложенного авторами механизма взаимодействия (ERL - Enhanced Real-time Linux) сокращает время выполнения операции на 17 мкс.
Список литературы
1. RTOS Evaluation Program. Can NT 4 be used as an RTOS? Real-Time Consult, 1998, 18p. (http://www.realtime-info.be).
2. Timmerman M., VanBeneden B., Uhres L. Is Windows CE 2.0 a real threat to the RTOS World? // Real-Time Magazine -1998, no.3
Отформатировано
Драйвер Linux
MB
ОСРВ
Драйвер ОСРВ
24
(http : //www.realtime-info.be).
3. Frampton N., Tsao J., Yen J. Windows CE Evaluation Report. GM Powertrain, 1998 (http://www.arcweb.com).
4. Fischer P. Building Distributed Real-Time Systems with Windows NT and Intime. Real-Time Computer Show, Plano, TX, 1998 (http://www.radisys.com).
5. Tiemann M. EL/IX:Unifying APIs for Linux and Post-PC Computing. Cygnus Solutions, 1999 (http://sourceware.cygnus.com/elix).
6. Bowman I. Conceptual Architecture of the Linux Kernel.-
1996.
7. Goldt S., Meer S., Burkett S., Welsh M. The Linux Programmer's Guide. 1995.
8. Робачевский А. Операционная система UNIX. - BHV. -СПб. - 1998.
9. Yodaiken V. The RTLinux Maniffesto. New Mexico Institute of Technology. (http://www. rtlinux. org).
ЭФФЕКТИВНОЕ КОНФИГУРИРОВАНИЕ ПРИЛОЖЕНИИ ВО ВСТРОЕННЫХ СИСТЕМАХ РЕАЛЬНОГО ВРЕМЕНИ
А.А. Альховик, Я.А. Домарацкий, М.В. Перевозчиков
Технология построения встроенных программных систем предполагает наличие инструментальной и целевой машин. Инструментальная машина обеспечивает разработку программной системы, а целевая - ее исполнение [1]. При построении сложных встроенных программных систем общепринятым является подход, при котором разрабатываемая система состоит из двух основных частей: операционной системы (ОС) - системная часть, и приложения пользователя - прикладная часть. Важной частью технологии разработки в этом случае является фаза конфигурирования прикладной части системы для обеспечения ее функционирования под управлением ОС. При этом встает задача эффективного с точки зрения аппаратных затрат и накладных расходов времени выполнения конфигурирования.
Для встроенных программных систем реального времени, построенных в соответствии с синхронным (time-triggered) подходом, важнейшей системной структурой данных является график активации задач [2], поэтому построение эффективного графика является главной составляющей решения упомянутой задачи.
Структура прикладной части. Статический график строится на основе представленного разработчиком описания приложения. Основными объектами, которыми оперирует разработчик при построении приложения, являются задачи. В синхронных системах существуют задачи двух типов - периодические и спорадические. Периодические задачи реализуют действия, период которых заранее известен и строго определен. Спорадические задачи предназначены для реализации действий, период которых не определен (например, для обработки внешних и/или внутренних прерываний). Для спорадической задачи известен лишь минимальный интервал времени, который может пройти между двумя ее соседними активациями. Кроме периода периодической задачи и интервала спорадической, для построения эффективного графика необходима дополнительная информация. Ниже для каждого типа задач приведен полный список используемых в дальнейшем параметров. Если какому-либо из них может быть назначено разумное значение по умолчанию, оно приведено в скобках.
Параметры периодической задачи: tp - номинальный период выполнения задачи; Д - допуск на
действительное значение периода задачи (= 0%); ^ -крайний срок выполнения задачи (= действительное значение периода); 10 - смещение активации задачи (= 0); ^ - наихудшее время выполнения задачи; 1Ь -наилучшее время выполнения задачи (= 0).
Параметры спорадической задачи: 1Р - минимальный интервал времени между двумя соседними активациями задачи; - наихудшее время выполнения задачи.
При построении статического графика основой являются периодические задачи. Информация о спорадических задачах не указывается в нем в непосредственном виде. Чтобы учесть влияние спорадических задач на работу приложения, наихудшее время выполнения каждой периодической задачи увеличивается исходя из максимальной частоты появления спорадических задач. Если в системе только одна спорадическая задача, скорректированное значение наихудшего времени выполнения периодической задачи может быть найдено как величина, к которой сходится следующее рекуррентное уравнение:
tw,0—tw ; tw,i+1 = tw '
(1)
Если в системе несколько спорадических задач, то уравнение (1) усложняется следующим образом (когда спорадические задачи являются невытесняе-мыми):
w,i+1
N
w + I
k=1
( t \
W,l ' lw,k
< ïp,k J
где N - число спорадических задач в системе.
Поскольку для построения графика основой являются периодические задачи, то существует общий период выполнения приложения (ТП), который в простейшем случае равен наименьшему общему кратному (НОК) периодов всех задач. Размер статического графика пропорционален величине Тп, и для произвольного набора задач (их периодов) он может превысить физические ресурсы аппаратных средств. Уменьшить размер статического графика можно за счет использования информации о значении допусков (Д) на периоды активации задач. Введение даже небольших допусков (около 5%) часто позволяет на порядок уменьшить величину Тп. Ниже описана общая схема отыскания оптимального значения Тп (подробнее см. в [3]).
25
w
