Первоначальный вариант стандарта POSIX (Portable Operating System Interface) появился в 1990 г. [1] и был предназначен для UNIX-систем, первые версии которых ведут свой отсчет с начала 70-х годов прошлого века. Спецификации POSIX определяют стандартный механизм взаимодействия прикладной программы и операционной системы и в настоящее время включают набор более чем из 30 стандартов [2].
Операционные системы реального времени (ОСРВ) обычно разделяют на две категории – жесткого и мягкого реального времени. Для ОСРВ жесткого реального времени отклик системы должен быть получен в строго ограниченном временном интервале и его превышение считается неприемлемым. В качестве примера такого приложения можно назвать систему наведения ракеты. Для систем мягкого реального времени временные характеристики не так важны и запоздалый отклик системы допустим (в разумных пределах). Например, в системах обработки видеоданных задержки приводят лишь к ухудшению качества изображения.
Чтобы соответствовать стандарту POSIX, операционная система должна быть сертифицирована по результатам соответствующего комплекта тестов [3]. В настоящее время комплекты тестов разработаны только для POSIX 1003.1a.
LynxOS 4.x фирмы LynuxWorks является результатом более чем 15-летнего опыта и предназначена для создания ПО встроенных систем, работающих в режиме жесткого реального времени. Ее могут использовать производители комплектного (OEM) и телекоммуникационного (TEM) оборудования, в частности изготовители бортовых систем военного применения. Разработка может осуществляться как на самой целевой системе (self-hosted), так и на инструментальном компьютере (host), готовое ПО работает на целевой системе (target).
Система сертифицирована по стандарту POSIX. Это означает, что LynxOS проверена аккредитованными независимыми экспертами на полное соответствие этому стандарту. В частности, LynxOS была сертифицирована на соответствие POSIX 1003.1-1996 фирмой Mindcraft (www.mindcraft.com). Это уникальное свойство отличает ее от большинства других ОСРВ, которые являются POSIX-совместимыми (compatible) и в лучшем случае соответствуют стандарту POSIX на 90–95% [2]. Среди других POSIX-сертифицированных ОСРВ следует назвать операционную систему QNX фирмы QSSL. Хотя надо отметить, что сертифицирована лишь версия QNX v.4, а не QNX Neutrino (которую только планируется сертифицировать). В значительно меньшей степени поддержка POSIX реализована в VxWorks [2] фирмы WindRiver, причем часто путем использования продуктов сторонних разработчиков. Существует целый ряд ОСРВ, в которых полностью отсутствует поддержка POSIX, например Nucleus фирмы Mentor Graphics.
LynxOS поддерживает многозадачные и многопотоковые приложения. Она может использоваться для приложений с высокими требованиями по времени реакции и надежности. Программы, написанные и скомпилированные в ОС Linux, могут запускаться и работать в среде LynxOS без каких-либо изменений в исходных текстах и без перекомпилирования. Это свойство LynxOS является уникальным для ОСРВ и очень удобным для пользователей (например, если отсутствуют исходные тексты). LynxOS обеспе чивает совместимость с Linux на уровне ABI (Application Binary Interface), фор матов объектных файлов, вызовов API, динамически подключаемых библиотек (DLL), компоновки и загрузки на этапе выполнения. Как уже отмечалось, систе ма полностью поддерживает стандарт POSIX.1003.la, а также подразделы POSIX. 1003. lb и POSIX. 1003.1с. Она может работать на разных аппаратных платформах (IA-32, PowerPC, MIPS, ARM, xScale) и поддерживает самые со временные сетевые средства и Интернет-технологии.
В ней предусмотрены необходимые средства для создания систем с возможностями "горячей замены" и "высокой доступности" (Hot Swap, High Availabili ty), а также устройств с высоким коэффициентом резервирования.
Существует версия LynxOS-178, сер тифицированная в соответствии со стандартом DO-178. Это означает полное соответствие требованиям к надежности для мобильных систем военного и аэрокосмического применения. Кроме того, LynxOS-178 имеет сертифици рованный стек TCP/IP для ответствен ных приложений в области авионики, медицины, атомной промышленности и связи.
Существует множество средств разработки как в рамках самой LynxOS, так и host-систем (Linux, Windows, Solaris). Для разработчиков в среде операционной системы VxWorks компания LynuxWorks предлагает специальный пакет VxWorks Compatibility Layer Package, который облегчает перенос программ из VxWorks в LynxOS. Как известно, в системах VxWorks с прямой адресацией между задачами могут возникать конфликты, поскольку все они обращаются к одному и тому же пространству глобальных имен. В LynxOS все процессы всегда независимы друг от друга и доступа к одному и тому же адресному пространству не имеют. VxWorks Compatibility Layer Package позволяет иметь в LynxOS отдельные пространства имен, обеспечивая одновременное существование нескольких виртуальных систем VxWorks. В состав пакета также включены рекомендации по выявлению кодов, требующих при переносе особого внимания из-за внутренних различий в реализации между LynxOS и VxWorks. Кроме того, имеется полный перечень поддерживаемых директив VxWorks и соответствующих ограничений на их использование.
В LynxOS 4.x реализован широкий спектр возможностей, позволяющих пользователю разрабатывать приложения жесткого реального времени. При этом количество задач не ограничено. Число приоритетов, с которыми может выполняться задача, составляет 256, а диспетчеризация происходит путем вытеснения по приоритетам. Могут применяться четыре алгоритма диспетчеризации (FIFO, Priority Quantum, Round Robin, невытесняемый).
Детерминированное время переключения контекста достигается благодаря эффективному алгоритму диспетчеризации реального времени. Средства межзадачных взаимодействий соответствуют как стандарту POSIX (семафоры, разделяемая память, сокеты, сигналы, каналы, мьютексы, условные переменные), так и терминам Unix SystemV (очереди сообщений, семафоры, разделяемая память).
Система обеспечивает поддержку таймеров реального времени и часов POSIX. При этом допускается конфигурирование квантов времени для различных уровней приоритетов.
И наконец, гарантируется выполнение задач в защищенном режиме с полной поддержкой MMU (Memory Management Unit).
LynxOS унаследовала от ОС BSD4.2 стек TCP/IP. На данный момент это самая популярная реализация в мире UNIX-подобных операционных систем. По быстродействию и богатству функций стек ТСРДР ОС LynxOS превосходит стеки большинства других ОСРВ.
Список поддерживаемых протоколов включает все сетевые средства, стандартные для ОС UNIX последних версий:
LynuxWorks поставляет пакеты поддержки целевых архитектур в LynxOS 4.0 (BSPs) для широкого спектра платформ, таких, как любые AT- и CompactPCI-платы с процессором Intel, Motorola Sand-point 750, Intel XScale IQ80310, IBM 440GP, Motorola FADS-ZU, Thales VM-PC6a/c, Force PowerCore 680 G3 & G4, Motorola CompactPCI for PPC MCP750, MCPN750, Motorola SPS FADS680T, Motorola PMC860, Radstone PowerXTreme 7a, Thales VCE405 и многие другие.
LynxOS поддерживает специальные возможности для встраиваемых приложений, среди которых – очень малое время загрузки, работа с флэш-памятью (M-systems TrueFFS), а также загрузка по сети или из ROM конфигураций исполняемой системы.
LynxOS предоставляет разработчику богатый выбор инструментальных средств как в ее собственных рамках, так и в среде host-систем. Среда разработки самой LynxOS поддерживает такие средства, как gcc, g++, gdb, различные версии системных библиотек (статические, динамические, многопотоковые), загрузчик динамических (ELF) библиотек, символьная отладка многопотоковых приложений, средства работы с графическими средами (X11R6, Motif, PosixDesk).
На рынке присутствует достаточно широкий спектр средств кросс-разработки для LynxOS. Отметим наиболее популярные.
VisualLynux IDE for Windows. Visual-Lynux является расширением Microsoft Visual Studio с добавленными функциями и возможностями разработки приложений для LynxOS и BlueCat Linux. Инструменты для администрирования целевых систем и дистанционной разработки делают его мощной интегрированной средой (IDE) кросс-разработки для встроенных систем. Продукт включает в себя встроенный компилятор GNU gcc и отладчик gdb, которые позволяют сократить временные затраты на весь производственный цикл – от написания кода и до отладки готовой программы. Встроенный клиент FTP переносит файлы на целевую систему, а утилита ВТР запускает серверы Bootp, Tftp и Pftp на машине разработчика и перезагружает целевую систему через параллельное соединение или по ТСРДР для отладки и исправления возникающих ошибок с помощью администратора целевых платформ.
С помощью VisualLynux можно создавать различные типы проектов – пользовательские приложения на Си и C++, приложения X/Motif, драйверы устройств, статические библиотеки. Один и тот же проект в VisualLynux может содержать множественные конфигурации, которые позволяют посредством VisualLynux Application Wizard легко менять тип целевой платформы. Каждому типу целевых платформ соответствует свой набор инструментов для кросс-разработки – компиляторов, интерпретаторов команд и т. д. Кроме того, проект VisualLynux может быть сохранен в типичном для ОС UNIX формате makefile.
В пакет поставки VisualLynux включены готовые шаблоны и примеры исходного кода, построенные в соответствии со стандартами POSIX, такие, как POSIX MultiThreaded, POSIX Signal Handler, Condition Variables and Mutexes, POSIX Semaphores, POSIX Shared Memory, PIPES, Priority Alteration, Interval Timers, POSIX Message Queues, Real-Time Events. В частности, VisualLynux Device-Driver Wizard позволяет создавать шаблоны статических или динамических драйверов устройств для Lynx-OS и BlueCat Linux.
CodeWarrior IDE. Реализация известной среды разработки CodeWarrior IDE в среде Linux или Solaris.
TotalView. Многозадачный графический отладчик для Lynx-OS. Единственный графический встраиваемый отладчик на уровне исходных текстов, разработанный специально для работы в современных распределенных многозадачных средах.
SpyKer. Инструмент отладки, диагностики и оптимизации быстродействия встроенной системы для LynxOS и BlueCat Linux. Позволяет осуществлять динамический мониторинг и запись всех событий во встроенной системе (события операционной системы и работы приложений) и представлять данные в графическом виде в наглядной форме:
SpyKer способен отслеживать системные вызовы, прерывания, переключения контекста и многие другие события.
Aphelion Java Toolkit. Устраняет препятствия, характерные для использования Java во встроенных системах, включая проблемы с переносимостью, совместимостью, временем разработки и быстродействием.
Lynxlnsure+ +. Предоставляет разработчикам детальную информацию, позволяющую глубже понять механизм работы приложения (ошибки в операциях с памятью, в том числе в присвоении ее разделов, в инициализации и присвоении переменных, проблемы с указателями, библиотеками, логические ошибки "утечки" памяти).
Porting Kit. Включает исходные тексты для всех BSP для конкретной архитектуры и может использоваться теми заказчиками, которые хотят портировать LynxOS на целевую систему.
С ростом популярности LynxOS многие независимые фирмы – разработчики ПО объявляют о выпуске версии своей продукции для этой среды. Назовем лишь некоторые примеры.
Компания Enea Embedded Technology анонсировала поддержку своего продукта в реляционной СУБД Polyhedra для LynxOS.
Empress Software объявила о реализации СУБД Empress v.8.62 для LynxOS.
Компания McObject объявила о поддержке в среде LynxOS своей оперативной базы данных eXtremeDB.
FairCom портировала свой пакет c-tree Plus в LynxOS.
Компания Highlander интегрировала свой CORBA-совмес-тимый продукт VisiBroker для разработки распределенных приложений в среде LynxOS.
Пакет CORBAplus (реализация протокола CORBA) фирмы Expersoft портирован в LynxOS.
PC Week/RE (484) 22`2005, Сергей Золотарев
В данном разделе рассматривается ОС 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 требует от разработчика ПО предъявления следующих данных (и, следовательно, выполнения соответствующих действий), относящихся к ПО.
Планирование должно включать следующие планы: план для программных аспектов сертификации (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 - это опытные и независимые специалисты, которых обычно привлекают к процессу сертификации ПО с начальных этапов сертификации.
На практике ни одна ОСРВ не удовлетворяет максимальным требованиям, предъявляемым к ним стандартами 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 на другой, причем оба работают на одном и том же процессоре в рамках одной и той же системы.
Компания 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-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.
Нет сомнений в том, что изложенные требования к ОСРВ для авиации являются очень существенными не только для авиации, но и для морского флота, военных и космических систем, телекоммуникационных систем, средств жизнеобеспечения, экологии, систем, используемых в чрезвычайных ситуациях. То есть для всех областей человеческой деятельности, где предъявляются высокие требования к времени реакции на события, надежности, живучести и безопасности применяемых средств, в том числе ПО. Авиация в контексте изложенных требований выбрана потому, что данные требования разрабатываются и контролируются организациями, деятельность которых сосредоточена вокруг авиационных систем.
|
|
 |
