19. Тенденции развития ос рв.

Один из видимых процессов — сближение систем различных классов. Во многих ОС РВ с ядром РВ и UNIX РВ появились кроссовые системы разработки, характерные для исполнительных ОС РВ. И это - общая тенденция. Резидентные средства раз работки для ОС РВ, поддерживающих многие архитектуры, уже выглядят как архаизм. Мощные кроссовые системы разработки появились в OS9 (с ядром РВ) и LynxOS (UNIX PB).

Та же картина наблюдается в области систем исполнения ОС РВ: в продуктах класса "UNIX РВ" и "ядра РВ" появляются новые компактные варианты систем исполнения с малым временем переключения контекста (качество класса "исполнительные ОС РВ"). Примеры - OS9, QNX, LynxOS.

Еще одна тенденция — появление во многих ОС РВ таких продуктов, как Real-Time Java и Embedded Java. Сейчас Java один из обязательных атрибутов СРВ.

В последнее время в ряде ОС РВ (QNX, LynxOS) появились дополнительные библиотеки, реализующие подмножества программного интерфейса Win32. Аналогичные процессы происходили недавно в отношении стандарта POSIX 1003.1 (базовый программный интерфейс UNIX). В итоге многие ОС РВ стали POSIX-совместимыми. Видимо, в будущем они станут еще и Win32-совместимы.

Появляется много публикаций о Windows СЕ и ее позиционировании по отношению к ОС РВ. Версии СЕ, появившиеся сегодня (2.0 и 2.1), пока не назовешь системами РВ. Можно говорить скорее о поиске, в котором находится Microsoft, чем о какой-то линии развития. Программные интерфейсы для драйверов 2.1 и 2.0 несовместимы друг с другом, причем в версии 2.1 появились недостатки, обусловливающие большие задержки при операциях ввода-вывода. Появление версии 3.0, которая существенно отличается от предыдущих, позволит понять, как будет развиваться СЕ дальше. Несомненно одно: Microsoft открыла проект СЕ с целью выйти на рынок встроенных систем и, наверное, достигнет многого на этом поприще. Однако встроенные системы и СРВ — не одно и то же. Интеллектуальные калькуляторы, электронные записные книжки, переводчики, органайзеры и другие инструменты составляют огромный рынок сбыта — именно туда направлены интересы Microsoft, и требования именно этого рынка будут определять решения в области СЕ, а никак не требования жесткого РВ. Создать же универсальную систему, удовлетворяющую противоречивым требованиям, невозможно, поэтому маловероятно, что Windows СЕ составит серьезную конкуренцию системам, о которых говорилось выше. На рис. 10 показана сложившаяся на сегодня специализация различных видов ОС РВ в зависимости от масштаба использующей их системы.

20. Требования к ОС РВ для авиации.

Те же, что и к просто ОС РВ, плюс:

• Соответствие авиационным стандартам;

• Повышенный уровень подготовки обслуживающего персонала;

21. Документы, регламентирующие требования к ОС РВ для авиации

• Стандарт DO-178 (Software Consideration in Airborne Systems and Equipment Certification) определяет требования к процессу разработки программного обеспечения и тщательности его проверки в зависимости от его уровня критичности. Уровень критичности ПО определяется на основе анализа серьезности последствий отказа в ПО. Всего предусмотрено пять уровней критичности ПО (от A-самые критичные, до E – никак не влияющие).

• MILS (Multiple Independent Levels of Secutiry) представляет собой специальный подход к проектированию ОС, препятствующий распространению ошибок прикладного программного обеспечения во время выполнения, а также упрощающий верификацию программ за счет модульности ПО

• Стандарт ARINC-653 (Avionics Application Software Standard Interface) специфицирует интерфейс прикладного программного обеспечения APEX, поддерживающий концепцию разделов в духе MILS.

• POSIX (Portable Operating System interface for unIX) определяет переносимый интерфейс операционных систем на уровне исходных текстов.

2 наши госта:

• ГОСТ Р ИСО/МЭК 51904—2002 («ПО встроенных систем. Общие требования к разработке и документированию») — аналог DO-178B для военной авиации;

• КТ-178А («Квалификационные требования часть 178А») — аналог DO-178B для гражданской авиации;

22. Концепция изолированных разделов для программного обеспечения для авиации.

Многие документы пересекаются или дополняют друг друга. В результате многочисленных исследований в качестве основной была принята концепция изолированных разделов. Разделы должны жестко изолироваться друг от друга с точки зрения используемого процессорного времени и оперативной памяти. Удовлетворение требованиям жесткой изоляции разделов должно быть доказано поставщиками программных решений в соответствии с методологией сертификации, изложенной в DO-178B. В настоящее время по ARINC-653.

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

Время использования процессора. Фундаментальной концепцией ARINC 653 является то, что процессы в одном разделе либо не должны влиять на поведение процессов в другом разделе совсем, либо могут влиять на них заранее определенным и контролируемым способом.

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

23-24. Стандарт DO-178B. Сертификация ОС РВ для ЛА

Стандарт DO-178B описывает технику и методы, ориентированные на то, чтобы гарантировать целостность и надежность ПО. Он также охватывает все этапы жизненного цикла программного обеспечения: планирование, разработку требований, проектирование, кодирование, интеграцию и тестирование.

Планирование должно включать следующие планы: план для программных аспектов сертификации (PSAC), план программного проекта (SDP), план верификации ПО (SVP), план управления конфигурацией ПО (SCMP) и план обеспечения качества ПО (SQAP).

В соответствии с DO-178B каждый из разработанных компонентов должен быть верифицирован по разнообразным критериям. Верификация требований высокого уровня к ПО включает в себя проверку следующих моментов: соответствуют ли они системным требованиям и доступны ли для анализа вместе с ними; являются ли они точными и согласованными; совместимы ли с аппаратными средствами, что должно быть подтверждено результатами тестирования.

DO-178B определяет процесс верификации этапа интеграции программного обеспечения, проверку полноты самого процесса верификации, обеспечение менеджмента конфигураций (в том числе управление версиями), квалификацию автоматизированных средств.

В DO-178B определены три уровня структурного тестирования кода:

1. SC (Statement Coverage) - покрытие утверждений. Означает, что каждое утверждение в программе было вызвано хотя бы один раз.

2. DC (Decision Coverage) - покрытие решений. Означает, что каждая точка входа и выхода в программе была выполнена хотя бы один раз и что каждое решение в программе принимало все возможные (булевские) выходные значения хотя бы один раз.

3. MCDC (Modified Condition Decision Coverage) - покрытие решений модифицируемым условием. Это означает, что каждая точка входа и выхода в программе была выполнена хотя бы один раз, что каждое решение в программе принимало все возможные (булевские) выходные значения хотя бы один раз и что каждое условие в решении приводило к независимому изменению выходного значения