CC BY
94
Рис. 6. Подход на основе базовых сценариев
рок (как в случае смешанных вычислений); например, область допустимых значений переменной, все нереализуемые пути от входных значений к выходным также устраняются из рассмотрения.
3. Удаление избыточных символических трасс: трассы разбиваются на классы эквивалентности, и из каждого класса берется только по одному представителю, что приводит к сокращению объема тестирования до 1:100.
4. Оптимальное число тестов с гарантированным 100 % покрытием: конкретные тесты для
прогона порождаются из символических трасс с отфильтровыванием избыточных; оставшиеся тесты по-прежнему гарантируют 100% покрытие исходных требований только этим сокращенным набором тестов.
5. Определение местоположения ошибки в случае неуспеха теста: каждый тест может или пройти, или не пройти. В случае неуспеха пользователь может определить, где скрыта причина: в приложении или в модели окружения. Вердикт с сообщением о неудаче прибавляется к модели окружения и повторно проверяется на взаимную непротиворечивость.
Список литературы
1. ITU-T z.100 (08/2002)// Telecommunication standardization sector of UTI, 202 с. - http://www.itu.int/rec/recommenda-tion.asp?type=items&lang=e&parent=T-REC-Z.100-200208-I
2. Recommendation z.120, 78 с. - http://www.itu.int/rec/re-commendation.asp?type=items&lang=e&parent=T-REC-Z. 120-200404-P.
3. Telelogic TAU 2.3 UML tutorial// Telelogic, 60 с. -https://support.telelogic.com/en/tau/download/product/product.cfm ?vid=97 (the document is included in the product box of TAU 2.3).
4. VRS User manual // Motorola, 82 с. - http://www.stc.corp. mot.com/twiki/bin/view/GSGSE/VrsDocumentation
ИНТЕГРАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РЕАЛЬНОГО ВРЕМЕНИ И ОПЕРАЦИОННЫХ СИСТЕМ ОБЩЕГО НАЗНАЧЕНИЯ
Я.А. Домарацкий
В последнее время разработчики встроенных систем управления все чаще и чаще сталкиваются с задачами перевода прикладного программного обеспечения (ПО) встроенных систем реального времени с одной программно-аппаратной платформы на другую. Как правило, наследованный код прикладного ПО работает под управлением операционной системы реального времени (ОСРВ). ОСРВ осуществляет диспетчирование задач реального времени, обработку прерываний от внешних устройств, предоставляет набор примитивов для организации межзадачного взаимодействия и другие системные средства. Конкретный набор средств, предоставляемых ОСРВ, определятся архитектурой ОСРВ, областью применения, аппаратной платформой, на которой работает ОСРВ, а также требованиями заказчиков, высказанными на этапе проектирования ОСРВ. В результате различие между коммерческими системами, представленными на рынке ОСРВ, достаточно велико.
Простейшие системы (например 08ЕК [1] или ЯТХС) работают на 8-, 16- и 32-разрядных микроконтроллерах и предоставляют только базовые
средства по диспетчеризации задач и обработки прерываний. Как правило, подобные системы (назовем их базовыми ОСРВ) не поддерживают стандартных интерфейсов разработки прикладного ПО (например Р081Х [2]) и не предоставляют механизмов защиты памяти. Достоинствами базовых ОСРВ является компактность систем, открытость исходного кода систем, прозрачность внутренней архитектуры и обеспечение высокого и гарантированного времени реакции системы на внешние воздействия.
Недостатками подобных систем является их низкая масштабируемость (как правило, отладка системы существенно усложняется, если число одновременно запущенных задач превышает несколько десятков), сложность интеграции компонентов системы в единое целое (отсутствие защиты памяти), сложность повторного использования программных компонентов, изначально разработанных для других проектов (отсутствие поддержки стандартных интерфейсов разработки прикладного ПО), ограниченность средств отладки (как правило, отладка кода прикладного ПО может быть завершена только на целевой аппа-
ратной платформе) и некоторые другие ограничения, обсуждение которых не является предметом данной статьи.
Более сложные системы (например VxWorks, QNX и Linux) работают, как правило, на 32- и 64-разрядных микроконтроллерах и предоставляют не только базовые средства по диспетчеризации задач и обработки прерываний, но и широкий набор дополнительных средств по организации межпотокового взаимодействия, по локализации сбоев в прикладном ПО и т.д. Как правило, подобные системы (назовем их расширенными ОСРВ) поддерживают не только внутренние интерфейсы разработки прикладного ПО, но и ряд стандартных интерфейсов, включая полную либо частичную поддержку POSIX стандарта. Достоинствами расширенных ОСРВ является поддержка системы защиты памяти, что повышает надежность конечной системы и снижает трудозатраты на этапе интеграции компонентов системы в единое целое, поддержка стандартных интерфейсов создания прикладного ПО (появляется возможность интеграции программных компонентов, изначально написанных для других продуктов), хорошая масштабируемость систем и чрезвычайно богатые средства отладки прикладного ПО (как правило, прикладное ПО может быть отлажено на инструментальной машине до того, как загружено на целевую аппаратную платформу). К недостаткам подобного рода систем необходимо отметить повышенные требования, предъявляемые к ресурсам целевой аппаратной платформы и увеличение времени реакции системы на внешние воздействия (не всегда возможно определить граничное значение времени реакции).
В некоторых сегментах рынка для 32-разрядных микроконтроллеров видна тенденция к переходу от базовых ОСРВ к расширенным. Рассмотрим один из подходов к решению задачи перевода прикладного ПО встроенных систем реального времени с базовой ОСРВ на расширенную с сохранением существующих функций продукта, реализованных с использованием базовой ОСРВ.
Нашей задачей является переход с базовой ОСРВ на расширенную с сохранением функций встроенной системы управления, ранее реализованных на основе базовой ОСРВ. Главной целью перехода является получение возможности использовать новые свойства ОСРВ как в области защиты памяти (повышение надежности конечной системы), так и в области использования стандартных интерфейсов построения прикладного ПО (повторное использование программных компонентов, изначально разработанных для других проектов). Возможность подключения дополнительных программных компонентов без перезагрузки системы так же является привлекательной. Прежде всего необходимо определить программ-
ную архитектуру и набор свойств существующей системы управления, построенной на основе базовой ОСРВ. Предположим, что аппаратная платформа базируется на основе 32-разрядного процессора с тактовой частотой порядка нескольких сотен мегагерц и существует несколько интерфейсов ввода-вывода с жесткими требованиями ко времени отклика системы. Также предположим, что прикладное ПО, обслуживающее интерфейсы ввода-вывода, разработано ранее на основе базовой ОСРВ.
С другой стороны, предположим, что такие программные компоненты, как расширенная поддержка стека протоколов TCP/IP, система поддержки оконного интерфейса с пользователем, система загрузки и запуска Java приложений разработаны для расширенных ОСРВ (например, QNX или Linux). Таким образом, стоит задача интеграции двух разнородных частей прикладного ПО - ПО, написанного для базовой ОСРВ, и ПО, написанного для расширенной ОСРВ.
Область применения систем варьируется от сетевых устройств (маршрутизаторы низшего класса) и систем автоматического сбора данных до систем управления, устанавливаемых в автомобили (телематические устройства (ТУ), бортовые компьютеры)). В случае ТУ интерфейсами ввода-вывода с жесткими требованиями ко времени отклика системы являются канал обмена данными между ТУ и внутренней сетью передачи данных автомобиля, каналы передачи звука и данных между ТУ и сотовым телефоном (как внутренним, так и внешним), канал обмена данными между центральным процессором и приемником сигналов от навигационных спутников [3].
Одноядерный и двуядерный подходы к построению систем на основе технологии Linux
Задача интеграции разнородных частей прикладного ПО не является новой. Пути решения задач могут различаться в зависимости от требований на конечную систему, свойств и архитектуры заимствованного прикладного ПО, а также от свойств и архитектуры расширенной ОСРВ. Обсудим задачи по переносу ПО на систему Linux. В случае Linux задача интеграции разнородных частей прикладного ПО связана с задачей сокращения времени реакции системы Linux на входные воздействия и с задачей обеспечения гарантированного отклика системы Linux на входные воздействия в заданный промежуток времени. Как правило, различают два подхода (рис. 1) к решению задачи обеспечения гарантированного отклика системы Linux на входные воздействия в заданный промежуток времени - одноядерный и дву-ядерный.
Одноядерный подход Процесс"
I Lini Процесс
Lini/ Процесс ' А Linii п
IL
/ Ядро Linux с улучшенными \ реактивными характеристиками ,
Аппаратная платформа
Двуядерный подход
Аппаратная платформа
Рис. 1. Архитектуры систем реального времени на основе Linux
В первом случае (одноядерный подход) ядро Linux должно быть расширено средствами повышения скорости реакции системы на входные воздействия, так как стандартное ядро Linux не удовлетворяет ряду требований, предъявляемых к приложениям реального времени. Во втором случае (двуядерный подход) компактное ядро реального времени осуществляет диспетчеризацию задач реального времени и обработку прерываний от устройств ввода-вывода. Ядро Linux осуществляет диспетчеризацию задач Linux, не критичных ко времени реакции системы на входные воздействия (подробнее см. в [4]). На первый взгляд кажется, что двуядерный подход позволит осуществить интеграцию наследованного прикладного ПО и нового прикладного ПО с наименьшими трудозатратами, так как не потребует переработки прикладного ПО, связанной с заменой нестандартных вызовов сервисов базовой ОСРВ на вызовы, поддерживаемые ядром Linux. Кроме того, двуядерный подход дает гарантию, что реактивные характеристики заимствованного прикладного ПО не ухудшатся после переноса системы на новую программную платформу, так как ядро ОСРВ по-прежнему будет иметь наибольший приоритет по сравнению с ядром Linux.
Интеграция заимствованного прикладного кода ОСРВ с ядром Linux в рамках двуядерного подхода
На рисунке 2 представлена схема распределения логических приоритетов в двуядерной архитектуре ПО, в которой обработчики прерываний ОСРВ, ядро ОСРВ и задачи ОСРВ имеют приоритет исполнения больший, нежели обработчики прерываний Linux, ядро Linux и процессы, работающие под управлением Linux.
Подобное логическое распределение приоритетов позволяет гарантировать неизменность времени реакции заимствованного прикладного ПО ОСРВ на входные воздействия. Необходимо отметить, что предложенная схема распределения приоритетов является идеальной и не всегда может быть реализована на нужных аппаратных платформах. Как правило, трудности возникают в области обработчиков прерываний, относящихся к подсистеме Linux. С одной стороны, необходимо
обеспечить целостность данных, с которыми приходится иметь дело в обработчиках прерываний Linux. С другой стороны, необходимо приостанавливать исполнение кода обработчиков прерываний Linux при возникновении запросов на обработку прерываний, логически относящихся к подсистеме ОСРВ. Более того, необходимость приостановки исполнения кода обработчиков прерываний Linux появляется и при возникновении запросов на запуск задач ОСРВ. В некоторых случаях приходится иметь дело с так называемым эффектом инверсии приоритетов в области обработчиков прерываний Linux и задач ОСРВ. Иногда удается найти частное решение данной проблемы, используя архитектурные особенности целевой аппаратной платформы и заимствованной ОСРВ. В иных случаях применима техника эмуляции аппаратных прерываний, обработчики которых находятся в подсистеме Linux [5].
Интеграция двух операционных систем (заимствованной ОСРВ и системы Linux) требует внесения некоторых изменений в исходный код обеих систем. К счастью, некоторые изменения, связанные с интеграцией высокоприоритетного ядра ОСРВ, уже сделаны в ядрах Linux версий 2.4.ХХ и выше. Существует механизм встраивания вызовов функций внешнего кода из кода инициализации ядра Linux, из кода обработки прерываний и непосредственно из ядра. Более того, существует возможность замены процедур аппаратного запрещения и разрешения прерываний в ядре Linux на соответствующие программные механизмы. Перечисленные свойства ядра Linux могут быть использованы при его интеграции с заимствованной ОСРВ.
Со стороны ядра заимствованной ОСРВ необходимо, как правило, изменить части кода, отвечающие за распределение физической и виртуальной памяти в системе.
Необходимо отметить, что схема распределения памяти (рис. 3) - частный пример. В некоторых реализациях двуядерной архитектуры ядро ОСРВ работает непосредственно в области логических адресов Linux и представляет собой загружаемый модуль ядра Linux.
ОСРВ ISR1 ОСРЕ ISR:
||
ОСРВ ISR;
Уровень обработчиков прерываний ОСРЕ
ОСРВ задача1 | ОСРВ задача^
Linux проц. Linux проц.2 Linux проц.З
Рис. 2. Логическое распределение приоритетов в двуядерной архитектуре
0x00000000
Кроме задачи распределения памяти между подсистемами ОСРВ и Linux обычно стоит задача организации взаимодействия между частями дву-ядерной системы. Следует выделить три группы функций по организации взаимодействия между частями двуядерной системы:
- по передаче загрузочной информации между ядром ОСРВ и ядром Linux (например, распределение физической и виртуальной памяти);
- по обмену данными между задачами ОСРВ и приложениями Linux;
- по синхронизации исполнения задач ОСРВ и приложений Linux.
Как правило, необходимо добавить модули по организации межъядерного взаимодействия как в ядро ОСРВ, так и в ядро Linux. Отметим, что наибольшую трудность вызывает разработка механизмов синхронизации исполнения задач реального времени и приложений Linux [6].
Некоторые достоинства и недостатки дву-ядерного подхода при построении приложений реального времени на основе Linux технологии освещены в [7]. Необходимо отметить, что использование двуядерного подхода позволяет достичь быстрых практических результатов, когда стоит задача разработки демонстрационных версий продукта с ограниченным набором функций, критичных ко времени исполнения. Как правило, достаточно легко запустить усеченную версию наследованного прикладного ПО ОСРВ и интегрировать ПО с подсистемой Linux. В подобной конфигурации возможна организация передачи данных из прикладного ПО ОСРВ в подсистему Linux для дальнейшей обработки и визуализации [5]. Это является несомненным преимуществом двуядерного подхода как подхода, пригодного для разработки демонстрационных версий продукта. Однако, как правило, запуск полной версии наследованного прикладного ПО ОСРВ, критичного ко времени исполнения, вызывает существенные затруднения. Эти затруднения связаны как с проблемой разделения ресурсов центрального процессора и периферийных устройств между ядрами ОСРВ и Linux, так и с существенным затруднением процесса отладки системы. Для отладки двуядерной системы необходимы большие усилия, так как локализация проблем требует анализа
взаимодействия между разнородными частями системы, что, как правило, не является тривиальной задачей. Более того, стандартные отладчики не поддерживают отладку двуядерных систем в терминах объектов операционных систем. Процесс анализа производительности систем затруднен в силу тех же причин. Таким образом, кажется разумным рекомендовать двуядерный Linux подход к построению систем реального времени с интегрированным заимствованным кодом прикладного ПО, если стоит задача разработки прототипов ПО и демоверсий ПО с ограниченным набором функций, критичных ко времени исполнения. Одноядерный подход и коммерческие операционные системы (например QNX) наиболее привлекательны при разработке полнофункциональных версий продуктов с существенными объемами заимствованного кода, критичного ко времени исполнения. Очевидно, что задача сохранения заданных реактивных характеристик системы является первоочередной при использовании одноядерного подхода.
В заключение отметим, что мы кратко рассмотрели круг задач по переносу прикладного ПО с базовых ОСРВ, таких как OSEK и RTXC, на расширенные ОСРВ, такие как Linux. Также рассмотрены одноядерный и двуядерный подходы к разработке систем управления реального времени на основе Linux технологии. Двуядерный Linux подход рассмотрен более подробно с точки зрения интеграции ОСРВ с ядром Linux.
Список литературы
1. OSEK/VDX Operating System, Version 2.2.1, January 16th, 2003, http://www.osek-vdx.org/
2. IEEE Std 1003.1 - 1996, (Incorporating ANSI/IEEE Stds 1003.1-1990, 1003.1b-1993, 1003.1c-1995, and 1003.1i-1995) Information technology - Portable Operating System Interface (POSIX®) - Part 1: System Application Program - Interface (API).
3. Telematics at a glance Automotive Industries, Nov, 1999 by Paul A. Eisenstein.
4. "Linux on ITRON": A Hybrid Operating System Architecture for Embedded Systems, Hiroaki Takada, Shin'ichi Iiyama, Tsutomu Kindaichi, Shouichi Hachiya, Proceedings of the 2002 IEEE Symposium on Applications and the Internet (SAINT.02w).
5. Open Source Real-Time Operating Systems for Plasma Control at FTU, C. Centioli, F. Iannone, G. Mazza, M. Panella, L. Pangione, V. Vitale, and L. Zaccarian, IEEE Transactions on Nuclear Science, Vol. 51, No. 3, June 2004.
6. Real-time synchronization between hard and soft tasks in RT-Linux, Terrasa, A.; Garcia-Fornes, A., Real-Time Computing Systems and Applications, 1999. RTCSA '99. Sixth IEEE International Conference, 13-15 Dec. 1999.
7. Experiences Using RT-Linux to Implement a Controller for a High Speed Magnetic Bearing System, Humphrey, M.; Hilton, E.; Allaire, P., Real-Time Technology and Applications Symposium, 1999. Proceedings of the Fifth IEEE , 2-4 June 1999.
Пространство логических адресов
OxCOOOOOOO 0xC03FFFFF 0XC0400000
Триложения Linu>
Ядро Linux
0x003FFFFF „Ш00400000
Ядро ОСРВ и задачи ОСРЕ
Пространство физических адресов
Рис. 3. Пример распределения памяти между ОСРВ и Linux
