Системы реального времени.-7

91

Стандарт OSEK/VDX является комбинацией стандартов, которые изначально разрабатывались в двух отдельных консорциумах, впоследствии слившихся. OSEK берет свое название от немецкого акронима консорциума, в состав которого входили ведущие немецкие производители автомобилей — BMW, Bosch, Daimler Benz (теперь Daimler Chrysler), Opel, Siemens и Volkswagen, а также университет в Карлсруэ (Германия). Проект VDX (Vehicle Distributed eXecutive) развивался совместными усилиями французских компаний PSA и Renault. Команды OSEK и VDX слились в 1994 г. [6].

Первоначально проект OSEK/VDX предназначался для разработки стандарта открытой архитектуры ОС и стандарта API для систем, применяющихся в автомобильной промышленности. Однако разработанный стандарт получился более абстрактным и не ограничивается использованием только в автомобильной индустрии [6].

Стандарт OSEK/VDX состоит из трех частей [6]:

–стандарт для операционной системы (OS);

–коммуникационный стандарт (COM);

–стандарт для сетевого менеджера (NM).

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

4.7безопасности Стандарты

Всвязи со стандартами для ОСРВ стоит отметить широко известный стандарт критериев оценки пригодности компьютерных систем (TCSEC — Trusted Computer System Evaluation Criteria). Этот стандарт разработан Министерством обороны США и известен также под названием «Оранжевая книга».

Вряде других стран были разработаны аналогичные критерии, на основе которых был создан международный стандарт

92

«Общие критерии оценки безопасности информационных технологий» (Common Criteria for IT Security Evaluation, ISO/IEC 15408).

В «Оранжевой книге» перечислены семь уровней защиты

[6]:

–А1 — верифицированная разработка. Этот уровень требует, чтобы защиту секретной и другой критичной информации средствами управления безопасностью гарантировали методы формальной верификации.

–В3 — домены безопасности. Этот уровень предназначен для защиты систем от опытных программистов.

–В2 — структурированная защита. В систему с этим уровнем защиты нельзя допустить проникновение хакеров.

–В1 — мандатный контроль доступа. Защиту этого уровня, возможно, удастся преодолеть опытному хакеру, но никак не рядовым пользователям.

–С2 — дискреционный контроль доступа. Уровень С2 обеспечивает защиту процедур входа, позволяет производить контроль за событиями, имеющими отношение к безопасности,

атакже изолировать ресурсы.

–С1 — избирательная защита. Этот уровень дает пользователям возможность защитить личные данные или информацию о проекте, установив средства управления доступом.

–D — минимальная защита. Этот нижний уровень защиты оставлен для систем, которые проходили тестирование, но не смогли удовлетворить требованиям более высокого класса.

Что касается общих критериев, то в них введены похожие требования обеспечения безопасности в виде оценочных уровней (EAL — Evaluation Assurance Levels). Их также семь [6]:

–EAL7 — самый высокий уровень. Предполагает формальную верификацию модели объекта оценки. Он применим к системам очень высокого риска.

–EAL6 — определяется как полуформально верифицированный и протестированный. На уровне EAL6 реализация должна быть представлена в структурированном виде, анализ соответствия распространяется на проект нижнего уровня, проводится строгий анализ покрытия, анализ и тестирование небезопасных состояний.

93

–EAL5 — определяется как полуформально спроектированный и протестированный. Он предусматривает создание полуформальной функциональной спецификации и проекта высокого уровня с демонстрацией соответствия между ними, формальной модели политики безопасности, стандартизованной модели жизненного цикла, а также проведение анализа скрытых каналов.

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

–EAL3 — определяется как методически протестированный и проверенный. На уровне EAL3 осуществляется более полное, чем на уровне EAL2, тестирование покрытия функций безопасности, а также контроль среды разработки и управление конфигурацией объекта оценки.

–EAL2 — определяется как структурно протестированный. Он предусматривает создание описательного проекта верхнего уровня объекта оценки, описание процедур инсталляции и поставки, руководств администратора и пользователя, функциональное и независимое тестирование, оценку прочности функций безопасности, анализ уязвимостей разработчиками.

–EAL1 — определяется как функционально протестированный. Он обеспечивает анализ функций безопасности с использованием функциональной спецификации и спецификации интерфейсов, руководящей документации, а также независимое тестирование. На этом уровне угрозы не рассматриваются как серьезные.

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

94

ные определения профилей защиты в отношении операционных систем, брандмауэров, смарт-карт и прочих продуктов, которые должны соответствовать определенным требованиям в области безопасности. Например, профиль защиты систем с разграничением доступа (Controlled Access Protection Profile) действует в отношении операционных систем и призван заменить старый уровень защиты С2, определявшийся в соответствии с американским стандартом TCSEC. В соответствии с оценочными уровнями доверия сертификация на соответствие более высокому уровню означает более высокую степень уверенности в том, что система защиты продукта работает правильно и эффективно и, согласно условиям Общих критериев, уровни 5—7 рассчитаны на тестирование продуктов, созданных с применением специализированных технологий безопасности [6].

Следует отметить, что большинство усилий по оценке продуктов безопасности сосредоточены на уровне 4-го стандарта Общих критериев и ниже, что говорит об ограниченном применении формальных методов в этой области [6].

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

4.8самопроверки Вопросы для

1.Чем обусловлена важность стандартов на ОСРВ?

2.Какие основные цели определяет стандарт SCEPTRE?

3.Опишите стандарт POSIX 1003.1b.

4.Опишите стандарт POSIX 1003.1с.

5.Опишите пять уровней серьезности отказа стандарта DO-178B.

6.Что определяет стандарт ARINC-653?

7.Из каких основных частей состоит стандарт OSEK/VDX?

8.Для чего предназначен стандарт TCSEC?

9.Сколько уровней защиты перечислены в «Оранжевой книге»?

96

Системы на основе Linux (свободно распространяемой версии Unix). Она получила значительное распространение на настольных компьютерах благодаря своей бесплатности и качеству.

В настоящий момент времени система Linux может работать, помимо процессоров Intel 80x86, на процессорах Alpha, SPARC, PowerPC, ARM, Motorola 68xxx, MIPS. Открытость ее исходных текстов позволяет реализовывать на ее основе специализированные системы и обеспечивать поддержку нового оборудования.

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

Поддержка стандартов POSIX, касающихся реального времени. Стандарт POSIX 1003.1c (работа с задачами) уже поддержан, стандарт POSIX 1003.1b (работа расширения реального времени) поддержан лишь частично: реализованы механизмы управления памятью и механизмы планирования задач.

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

Реализация механизма preemption (приоритетное прерывание обслуживания) для ядра системы. Этот механизм является необходимым для того, чтобы систему можно было назвать системой реального времени, но он также является очень сложным для реализации. Linux, надолго запрещает прерывания при входе в ядро системы и не является preemptive.

Существует несколько проектов реализации preemption для ядра Linux. По способу решения этой задачи их можно разделить на две группы:

1. Механизм preemption реализуется путем переписывания ядра системы. На этом пути можно достичь самых качественных результатов, но на данный момент времени значительных успехов в этом плане нет по следующим причинам:

–слишком большой объем работы, связанный с большим объемом ядра;

–слишком высокая скорость изменения ядра, причем изменения вносятся без учета интересов реального времени.

97

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

–процессы, работающие под управлением только микроядра (не использующие функции ядра Linux);

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

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

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

Система RT-Linux является свободно распространяемой, разрабатываемой энтузиастами в ряде университетов мира. Создана в New Mexico Institute of Mining and Technology (USA).

Представляет собой простейшее микроядро, отвечающее за создание и планирование задач, обеспечение их взаимодействия

идиспетчеризацию прерываний. Реализован простейший приоритетный механизм планирования и единственный механизм взаимодействия — очередь сообщений FIFO. Ядро Linux работает как самая низкоприоритетная задача. В само ядро внесены исправления — макроопределения, отвечающие за

98

запрещения/разрешения прерываний, заменены на соответствующие функции микроядра. Задачи Linux не могут прервать ядро Linux, задачи же микроядра могут.

Такая структура накладывает некоторые ограничения на задачи реального времени. Они не могут легко использовать различные драйвера Linux, не имеют доступ к сети и т.д. Зато они могут обмениваться данными со стандартными задачами Linux.

Простые очереди FIFO реализованы для обмена данными между процессами реального времени и процессами Linux.

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

Самый короткий период для периодически вызываемых задач реального времени в RT-Linux на Pentium 120 — менее 150 мкс. Задачи, вызываемые по прерыванию, могут иметь намного меньший период.

Ядро реального времени не защищает от перегрузок. Если одна из задач реального времени полностью утилизирует процессор, ядро Linux, имея самый низкий приоритет, не получит управления и система повиснет.

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

Минимальный размер системы для записи в ПЗУ (без X-Window) — 2.7 Мб.

5.2.2Windows NT

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

Аргументы фирмы Microsoft за использование Windows NT в качестве ОСРВ:

–Многопроцессность и многозадачность системы.

–Поддержка многопроцессорности.

–Preemption задач.

99

–Preemption прерываний и возможность их маскирования.

–Асинхронный ввод/вывод.

–Прямой доступ к оборудованию посредством интерфейса HAL (Hardware Abstraction Level). HAL обеспечивает изоляцию приложения от деталей реализации оборудования, обеспечивая платформенно-независимый прямой доступ к оборудованию.

–Специальная схема приоритетов. Все приоритеты разделены на две класса:

o Класс динамических приоритетов (0…15). Приоритеты

меняются динамически по алгоритму близкому к принятому в Unix.

oКласс приоритетов реального времени (16, 22—26, 31).

Эти приоритеты фиксированы, задачи из этого класса планируются на основе приоритетной очереди и получают управление раньше задач с динамическими приоритетами.

– Пространство ввода/вывода для задач из класса реального времени не участвует в страничном обмене механизма виртуальной памяти.

– Для закрепления страниц задачи в памяти существует специальный системный вызов (VirtualLock()).

– Представляются объекты синхронизации: критические секции, таймеры, события, mutex и др.

Аргументы против использования Windows NT в качестве ОСРВ:

– Ядро системы не является preemptive.

– Механизм DPC (Differed Procedure Call), вызываемый обработчиком прерываний, имеет недостатки:

oВсе процедуры DPC получают один и тот же приоритет и

обрабатываются планировщиком в порядке поступления (FIFO). Тем самым низкоприоритетные прерывания будут обрабатываться ранее высокоприоритетных, но поступивших позднее.

oСистема не дает возможности узнать, сколько DPC стоит

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

– Для каждого прерывания только один экземпляр DPC может быть в очереди. Следовательно, процедура DPC должна