LynxOS-178 - коммерческая ОСРВ для авиации

БОРТОВЫЕ ОС

В данной статье рассматривается ОС LynxOS-178 (версия 2.0) фирмы LynuxWorks, разработанная как коммерческая (COTS) операционная система реального времени (ОСРВ) для авиации в соответствии с современными требованиями, которые предъявляются различными зарубежными организациями, ответственными за безопасность полетов, и в первую очередь Федеральной администрацией по авиации США (Federal Aviation Administration, FAA). Хочется сразу подчеркнуть, что сегодня в авиации (и не только в ней) все шире применяются не "закрытые" ОСРВ, а коммерческие продукты с открытыми интерфейсами, такие, как LynxOS-178.

В чем особенности современных ОСРВ для авиации?

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

1. ОСРВ должны удовлетворять требованиям "жесткого" реального времени (детерминизму поведения при различных нагрузках на систему). Например, таким требованиям, как детерминированное время реакции задачи на прерывание или детерминированное время переключения контекста между процессами.

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

3. ОСРВ должна удовлетворять жестким требованиям по качеству ПО, что подразумевает соответствие различным отраслевым, национальным и международным стандартам. Особенностью требований к ОСРВ для авиации является то, что ПО должно иметь доказанное качество.

4. Требования по надежности: вероятность сбоя в ПО должна быть очень маленькой.

5. Требования по безопасности (safety) и секретности (security) данных: в системе должны быть предусмотрены средства защиты наиболее важной информации.

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

Каким стандартам должна удовлетворять ОСРВ для авиации?

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

  - Стандарт DO-178 "Software Consideration in Airborne Systems and Equipment Certification" разработан и поддерживается ассоциацией RTCA (Radio Technical Commission for Aeronautics, www.rtca.org). Первая его версия была принята в 1982 г., вторая (DO-178A) - в 1985-м, текущая DO-178B - в 1992 г., а принятие новой версии, DO-178C, намечено на сентябрь 2005-го. Стандартом предусмотрено пять уровней серьезности отказа, и для каждого из них определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня серьезности:

уровень A - ПО должно обеспечивать защиту от сбоев, приводящих к катастрофическим (catastrophic) последствиям, и удовлетворять 66 требованиям;

 уровень B - ПО должно обеспечивать защиту от сбоев, приводящих к опасным (hazardous) последствиям, и удовлетворять 65 требованиям;

 уровень C - ПО должно обеспечивать защиту от сбоев, приводящих к серьезным (major) последствиям, и удовлетворять 57 требованиям;

  уровень D - ПО должно обеспечивать защиту от сбоев, приводящих к незначительным (minor) последствиям, и удовлетворять 28 требованиям;

 уровень E - ПО должно обеспечивать защиту от сбоев, не приводящих ни к каким последствиям.

 - Стандарт ED-12B - европейский аналог DO-178B - определяется EUROCAE (The European organisation for civil aviation equipment, www.eurocae.org).

  - ARINC 653 - "Avionics Application Software Standard Interface" - разработан компанией ARINC (Aeronautical Radio, Inc.) в 1997 г. Этот стандарт определяет универсальный программный интерфейс APEX (Application/Executive) между ОС авиационного компьютера и прикладным ПО (www.arinc.com/cf/store/documentlist.cfm). Требования к интерфейсу между прикладным ПО и сервисами операционной системы определяются таким образом, чтобы разрешить прикладному ПО контролировать диспетчеризацию, связь и состояние внутренних обрабатываемых элементов. В 2003 г. принята новая редакция этого стандарта. ARINC 653 в качестве одного из основных требований для ОСРВ в авиации вводит архитектуру изолированных (partitioning) виртуальных машин.

- Общие критерии для оценки секретности информационных технологий (Common Criteria for Information Technology Security Evaluation, CCITSE) - это набор требований и условий секретности, одобренный Агентством национальной безопасности и Национальным институтом стандартов и технологий США (United States National Security Agency/National Institute of Standards and Technologies, http://csrc.nist.gov/cc/), а также соответствующими органами других стран (в данный момент еще 13 стран помимо США). Первая версия требований была опубликована в январе 1996 г., вторая - в апреле 1998-го. В 1999 г. CCITSE получил статус международного стандарта ISO 15408. Дополнительную информацию по сертификации CCITSE можно найти на сайте: www.commoncriteria.org.

Рис. 3. Rockwell Collins применяет LynxOS-178 в качестве встраиваемой

ОСРВ в адаптивной системе отображения полета бомбардировщика Challenger 300

CCITSE определяет уровни гарантии секретности - EAL (Evaluation Assurance Level). Common Criteria оценивает не только безопасность и надежность продуктов, но и процессы их разработки и поддержки, что гарантирует быстрое решение проблем. Применительно к операционным системам требования Common Criteria подробно изложены в [2]. Выделены семь EAL-уровней гарантии секретности [3]:

EAL1 ("Functionally tested"). Этот уровень применим там, где необходима минимальная конфиденциальность, но обеспечение секретности не рассматривается как важное требование.

EAL2 ("Structurally tested"). Применим там, где от системы требуется средний уровень гарантированной секретности в отсутствие полной информации обо всех процедурах разработки.

EAL3 ("Methodically tested and checked"). Применим там, где разработчики или пользователи требуют среднего уровня гарантированной секретности и исчерпывающего исследования операционной системы и этапов ее разработки, не прибегая к существенной переработке ОС.

EAL4 ("Methodically designed, tested and reviewed"). Применим там, где разработчики или пользователи требуют высокого уровня гарантированной секретности операционной системы и специальной доработки уже существующей ОС для обеспечения этих требований.

EAL5 ("Semi formally designed and tested"). Применим там, где разработчики или пользователи требуют высокого уровня гарантированной секретности операционной системы и строгого подхода к проектированию, так чтобы эти свойства были заложены уже на этапе проектирования, используя специальные средства обеспечения секретности.

EAL6 ("Semi formally verified, designed and tested"). Применим там, где существует высокий уровень опасных ситуаций и где оправданны высокие затраты на защиту от несанкционированного доступа.

EAL7 ("Formally verified, designed and tested"). Этот уровень должен применяться в приложениях с очень высокой ценой несанкционированного доступа.

 - MILS (Multiple Independent Levels of Security/Safety) делает возможной математическую верификацию программного ядра системы путем уменьшения функциональности за счет предъявления к системам четырех обязательных групп требований (Information Flow, Data Isolation, Period Processing, Damage Limitation). Развивается проект усилиями заинтересованных компаний и организаций, таких, как U.S. Air Force Research Laboratory, Lockheed Martin, Агентство национальной безопасности США и др. (http://mils.ois.com).MILS- архитектура представляет собой систему с изолированными разделами, каждый из которых включает ядро, middleware и приложение.

Рис. 4. Различные системы управления модернизированного

самолета-заправщика C/KC-135s работают в разделах LynxOS-178

 - POSIX (Portable Operating System interface for unIX) определяет переносимый интерфейс операционных систем на уровне исходных текстов (www.pasc.org). Основная спецификация разработана как спецификация IEEE 1003.1 и одобрена в качестве международного стандарта ISO/IEC 9945-1:1990. С точки зрения ОСРВ наибольший интерес представляют три стандарта: 1003.1a (OS Definition), 1003.1b (Realtime Extensions) и 1003.1c (Threads).

Концепция изолированных разделов для авиационного ПО

По многим аспектам указанные выше документы являются взаимно перекрывающимися и дополняющими друг друга. В результате многочисленных исследований [4-7] в качестве основной была принята концепция изолированных разделов. Разделы (partition) должны жестко изолироваться друг от друга с точки зрения используемого процессорного времени и оперативной памяти. Удовлетворение требованиям жесткой изоляции разделов должно быть доказано поставщиками программных решений в соответствии с методологией сертификации, изложенной в DO-178B. Хотя существуют различные подходы к реализации изолированных разделов [4], в настоящее время принята архитектура, соответствующая ARINC 653. Спецификация ARINC 653 определяет поддержку изолирования для ОСРВ и в качестве языка описания использует языки программирования Cи и Ada-95.

С точки зрения пользователя, ARINC 653 представляет собой спецификацию интерфейса (APEX - Application Executive) и при этом не определяет то, как должен быть реализован этот интерфейс. Например, некоторые поставщики программных средств реализуют диспетчеризацию (в соответствии с их "адаптацией" ARINC 653) с помощью одноуровневого диспетчера, другие - с помощью двухуровневого. Первый управляет разделами, второй - процессами внутри каждого раздела. Такая ситуация с поддержкой ARINC 653 влечет за собой значительные трудности при сертификации программных продуктов, соответствующих только ARINC 653, так как один и тот же API может отображаться на различные подходы к реализации интерфейса. Как следствие, появилось множество существенно различающихся ОСРВ, которые, однако, соответствуют спецификации ARINC 653. В LynxOS-178 реализована двухуровневая модель ARINC 653.

Все данные и программный код в каждом разделе (partition) компонуются вместе и выполняются в пользовательском режиме. Компоненты MOS (Module Operating System) и BSP (Board Support Package) работают в супервизорном (Supervisor) режиме. Дополнительно может существовать один специальный раздел с некоторыми специальными возможностями, такими, как средства ввода-вывода и переключения режимов.

Список данных жизненного цикла ПО в соответствии с DO-178B

ARINC 653 как раз и задает интерфейс для обмена информацией между разделами, каждый из которых представляет собой некое приложение плюс POS (Partition Operating System). Этот интерфейс должен гарантировать изоляцию следующих элементов друг от друга.

 - Оперативная память. Каждому разделу выделяется непрерывное линейное физическое адресное пространство, и границы этого пространства не могут меняться в процессе работы системы. Для каждого раздела выделение (из этого жестко определенного адресного пространства) и освобождение памяти выполняется и контролируется MOS. ОСРВ должна обеспечивать изолирование информации в адресном пространстве внутри выделенного каждому разделу линейного куска. Это относится к программному коду, константам, статическим данным, стеку, "куче" (heap - область, откуда берется память по запросу allocate).

  - Время использования процессора. Фундаментальной концепцией ARINC 653 является то, что процессы в одном разделе либо не должны влиять на поведение процессов в другом разделе совсем, либо могут влиять на них заранее определенным и контролируемым способом (например, путем установки некоторых флагов или условий). ARINC 653 требует, чтобы процессорное время выделялось каждому разделу строго циклически (round-robin), причем время владения процессором при этом должно задаваться заранее в конфигурационной таблице. Внутри того или иного раздела процессы (нити) могут конкурировать между собой за процессорное время на основе приоритетов ("вытеснять" друг друга), используя диспетчеризацию с вытеснением по приоритетам.

- Программный код. Для некоторых областей памяти MOS устанавливает (в режиме Supervisor) атрибут "только выполнение". Это означает, что приложения в пользовательском режиме не могут разрушить область кода.

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

Другим источником прерываний являются внешние устройства ввода-вывода. В соответствии с требованиями ARINC 653 для устройств с синхронной передачей данных рекомендуется использовать алгоритм опроса устройства. Однако некоторые устройства требуют обработки прерываний. Эти прерывания должны обрабатываться MOS и затем передаваться в POS в момент активизации раздела. Очевидно, что при этом могут возникать временные задержки и даже потеря информации, и, следовательно, разработчик должен это учитывать.

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

- обмен сообщениями с помощью команд send/receive путем установления канала связи, который должен быть заранее описан в конфигурационной таблице системы;

- обмен через буфер. При этом только один раздел может писать в конкретный буфер, а все другие - только читать. Это обеспечивает возможность широковещательного обмена информацией между разделами.

Стандарт DO-178B

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

Планирование должно включать следующие планы: план для программных аспектов сертификации (PSAC), план программного проекта (SDP), план верификации ПО (SVP), план управления конфигурацией ПО (SCMP) и план обеспечения качества ПО (SQAP). На протяжении всего жизненного цикла ПО должно быть обеспечено соответствие следующим стандартам к ПО: формулировке требований, проектированию, кодированию, верификации и документированию. В соответствии с приведенными стандартами должны быть разработаны такие компоненты, как требования к ПО (требования высокого уровня) - SRD, проект ПО - SDD (требования и архитектура), программный код в исходном и объектном виде. В соответствии с DO-178B каждый из разработанных компонентов должен быть верифицирован по разнообразным критериям. Верификация требований высокого уровня к ПО включает в себя проверку следующих моментов: соответствуют ли они системным требованиям и доступны ли для анализа вместе с ними; являются ли они точными и согласованными; совместимы ли с аппаратными средствами, что должно быть подтверждено результатами тестирования.

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

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

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

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

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

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

Теоретические аспекты верификации кода изложены в различных фундаментальных монографиях, в частности в работе [8].

Сертификация на соответствие DO-178B должна проводиться назначаемыми инженерными представителями (Designated Engineering Representative, DER), которые назначаются FAA для проверки данных, используемых при сертификации. DER - это опытные и независимые специалисты, которых обычно привлекают к процессу сертификации ПО с начальных этапов сертификации.

LynxOS-178 2.0: соответствие современным требованиям к ОСРВ для авиации

На практике ни одна ОСРВ не удовлетворяет максимальным требованиям, предъявляемым к ним стандартами POSIX, ARINC-653, DO-178B, и уровню 7 Common Criteria. Однако в значительной степени к ним приближена LynxOS-178 2.0 фирмы LynuxWorks (www.lynuxworks.com). Основу LynxOS-178 составляет LynxOS [9]. LynxOS v.3 сертифицирована на согласованность (conformance) со стандартом POSIX на платформе Intel и PowerPC по POSIX 1003.1-1996 компанией Mindcraft, Inc., являющейся IEEE POSIX Accredited POSIX Testing Laboratory по набору тестов NIST FIPS 151-2 Conformance Test Suite. Информацию об этом можно найти на сайте IEEE http://standards.ieee.org/regauth/posix/posix2.html.

Ключевое свойство LynxOS-178 2.0 - это поддержка нескольких полностью разделенных по времени, памяти и ресурсам разделов в соответствии с требованиями ARINC 653 (рис.1). LynxOS-178 2.0 поддерживает:

- до 16 разделов (виртуальных машин), включая корневой;

- до 64 процессов внутри каждого раздела;

- до 51 потока (нити) внутри каждого процесса;

- диспетчеризацию реального времени потоков внутри раздела;

- POSIX-функции межпроцессного взаимодействия внутри раздела.

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

Рис. 1. Структура LynxOS-178

С помощью LynxOS-178 фиксированные разделы обслуживаются как виртуальные машины LynxOS. Каждый прикладной процесс оперирует внутри его собственной среды операционной системы, как если бы он работал на своем собственном процессоре. Это применимо ко всем ресурсам процессора и именованным пространствам. Такая абстракция избавляет разработчика прикладной ОС от дополнительных усилий при программировании сложной системы. Управление разделами контролируется с помощью таблицы конфигурации виртуальных машин (Virtual-Machine Configuration Table - VCT) и является обязательным в среде LynxOS-178, что позволяет разработчику сконцентрироваться на создании приложений, а не на разделении системы.

Кроме того, LynxOS-178 поддерживает разделение систем, совместимых с RTCA DO-255, которое разрешает системе выполнять ПО с различными уровнями безопасности по DO-178B в разных разделах (виртуальных машинах). Это означает, что ОС может выполнять приложение с уровнем A (по DO-178B) на одной виртуальной машине и приложение с уровнем C на другой, причем оба работают на одном и том же процессоре в рамках одной и той же системы.

Сертифицируемый по стандарту DO-178 стек TCP/IP

Компания LynuxWorks разработала и сертифицировала на соответствие уровню A стандарта DO-178 стек TCP/IP - LCS (Lynx Certifiable Stack). Основные особенности LCS:

- выполняется на выделенном коммуникационном процессоре Motorola 8260 и может взаимодействовать с другими системами;

- является расширением стандартного стека TCP/IP, обеспечивающим детерминизм и повышенную надежность;

- обеспечивает полную реализация IPv4;

- верифицирован по 100%-ному покрытию кода по критерию MCDC;

- поддерживает статически преконфигурированные IP-адреса и порты, что повышает надежность и безопасность системы в целом;

- имеет прикладной интерфейс с LynxOS-178. Взаимодействие выделенной виртуальной машины LCS с виртуальными машинами LynxOS-178 ("хостами") осуществляется по PCI-шине, как это показано на рис. 2.

Примеры систем, основанных на ОС РВ LynxOS-178 и сертифицированных по стандарту DO-178

Версия LynxOS-178 в составе различных изделий была сертифицирована на разных уровнях по стандарту DO-178B.

Так, она была сертифицирована по уровню A стандарта DO-178B в составе самолета Bombardier Challenger 300 фирмы Rockwell Collins в июне 2003 г. (рис. 3).

В качестве другого примера приведем самолет KC-135 Stratotanker, главной задачей которого является дозаправка в воздухе стратегических бомбардировщиков дальнего действия (4). LynxOS-178 работает на основных вычислительных и коммуникационных модулях.

Рис. 2. Взаимодействие виртуальных машин через стек TCP/IP

LynxOS-178 работает также на самолете-танкере KC-767.

Более полный перечень областей применения решений LynuxWorks в военной и аэрокосмической отрасли можно найти на сайте www.lynuxworks.com/solutions/milaero/milaero.php3.

Заключение

Фирма LynuxWorks развивает LynxOS-178, чтобы обеспечить соответствие этой ОС максимальным требованиям Common Criteria: в 2006 г. должен выйти ее прототип, отвечающий EAL-7. LynuxWorks разрабатывает новое ядро ОСРВ, совместимое с требованиями MILS, - LynxSecure, которое будет содержать всего около 8000 строк исходного кода и будет также соответствовать требованиям EAL-7.

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

Литература

1. Philip Melanson, Siamak Tafazoli. A Selection Methodology for the RTOS Market, Canadian Space Agency, 2003.

2. COTS Security Protection Profile - Operating Systems (CSPP-OS), NISTIR 6985, April 2003.

3. Common Criteria for Information Technology Security Evaluation. Part 3: Security Assurance Requirements. August 1999, Version 2.1, CCIMB-99-033; доступен в электронном виде http://csrc.nist.gov/cc/Documents/CC%20v2.1/p3-v21.pdf.

4. Commercial Off-The-Self Real-Time Operating System and Architectural Consideration. Final Report, U.S. Federal Aviation Administration, DOT/FAA/AR-03/77, February 2004.

5. Partitioning in Avionics. Architecture: Requierements, Mechanics, and Assurance. Final Report, National Aeronautics and Space Administration, DOT/FAA/AR-99/ 58, NASA/CR-1999-209347, March 2000.

6. Study of Commercial Off-The-Self (COTS) Real-Time Operating System (RTOS) in Aviation Application. Final Report, U.S. Federal Aviation Administration, DOT/FAA/AR-02/118, December 2002.

7. Evaluation of realtime operating systems - the role of standards, Avionic Systems Standartisation Commitie (ASSC), Doc No: ASSC/330/2/141, March 1997.

8. Mayers, Glenford J.: The art of Software Testing, John Wiley & Sons, 1979.

9. Калядин А. Ю., Золотарев С. В. LynxOS - ОСРВ в стандарте POSIX. - PC Week/RE, N 31/2004, с. 18.