CC BY
649
тактов. Один сеанс моделирования с использованием САПР Verilog NC на рабочей станции Xeon X5560 с частотой 2,80 ГГц с оперативной памятью 49 Гб занимает около 1 сек.
На рисунке 3 приведены графики распределения результатов моделирования тестовыми программами BCRESPONSE (рис. 3 а) и BCREGTEST (рис. 3б).
Результаты показывают, что коэффициент чувствительности архитектуры к сбоям практически не зависит от числа сеансов, но очень сильно зависит от исполняемой программы.
Так, если для программы BC RESPONSE он приближается к 1 (Кач=0,97; нет ошибки - 0,03; ошибок - 0,60; «серых» - 0,37), то для программы BC REG TEST составляет менее 0,5 (Кач=0,4; нет ошибки - 0,60; ошибок - 0,38; «серых» - 0,02). Кроме того, очень сильно отличаются доли «серых» результатов. Таким образом, сделаем вывод, что, меняя алгоритм выполнения программы, можно повышать или понижать чувствительность архитектуры к одиночным сбоям и тем самым уменьшать или увеличивать частоту ошибочных ситуаций в реальных условиях эксплуатации.
На основании изложенного можно сделать следующее заключение. Разработаны методика и
набор программ, позволяющих проводить исследования коэффициента архитектурной чувствительности к сбоям в цифровых интегральных схемах. Проведена апробация данной методики на примере блока автомата состояний контроллера МКИО. Результаты показывают, что Кач очень сильно зависит от выполняемой задачи: для 2000 сеансов Кач данного блока для теста BC_RES-PONSE составил 0,97, а для теста BC REG TEST -0,38. Планируются дальнейшие исследования этого и других блоков с целью анализа влияния архитектурных решений и алгоритмов программ на Кач для его уменьшения.
Литература
1. Осипенко П.Н. Одиночные сбои - вызов для современных процессоров // Электронные компоненты. М.: 2010. № 1. C. 66-69.
2. Mukherjee S. Architecture Design for Soft Errors / Elsevier, 2008, 337 p.
3. Kim S. and Somani A.K. Soft Error Sensitivity Characterization for Microprocessor Dependability Enhancement Strategy // International Conference on Dependable Systems and Networks (DSN), June 2002, pp. 416-425.
4. Nguyen H.T., Yagil Y., Seifert N. and Reitsma M. ChipLevel Soft Error Estimation Method // IEEE Transactions on Device and Materials Reliability. September 2005. Vol. 5. No. 3, pp. 365-381.
УДК 004.451
ОПЕРАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ
БАГЕТ 3.0
А.Н. Годунов, к.ф.-ж.н. (НИИСИРАН, г. Москва, пкадфпИ^-газ.т)
В статье рассматриваются требования, архитектура и принципы построения высоконадежных операционных систем реального времени на примере отечественной операционной системы Багет 3.0.
Ключевые слова: реальное время, операционная система, надежность, РОБ1Х, ЛШЖ-653.
Системы реального времени (РВ) по мере развития становятся все более сложными, в их разработке принимают участие большие коллективы. Требования к надежности систем РВ постоянно возрастают. В силу этого назрела потребность в разработке средств повышения надежности систем РВ в случае сбоев в работе прикладных программ и операционной системы (ОС). В статье рассматриваются принципы и пути построения ОС РВ Багет 3.0, которая была разработана с целью решения указанных проблем. Данная система - развитие ОС РВ Багет 2.0 [1], которая используется специалистами более 100 организаций нашей страны в течение 10 лет.
Разработка ОС РВ Багет 3.0 базируется на следующих принципах:
- использование стандартов;
- мобильность (portability);
- разбиение системы на слабо взаимодействующие части (partitioning) с тем, чтобы сбои в одной части не влияли на работоспособность других;
- наличие средств восстановления после сбоев, а также развитые средства диагностики и обработки ошибок;
- гибкие средства планирования (периодическое, приоритетное планирование, планирование с вытеснением - preemptive scheduling);
- использование объектно-ориентированного подхода;
- управляемость (в частности, наличие средств конфигурирования).
При разработке ОС РВ использовались спецификация ARINC 653 [2] и стандарт POSIX 1003.1 [3], определяющие интерфейс прикладных программ с ОС.
Стандарт POSIX разрабатывался с целью унификации пользовательского интерфейса различных t/NIX-подобных систем и, как следствие, обеспечения мобильности прикладных программ. Изначально POSIX не был ориентирован на решение задач реального времени, но в процессе развития в него были добавлены функции, характерные для ОС РВ (таймеры, семафоры, мьютексы, сигналы реального времени и др.). Стандарт POSIX имеет большой объем и описывает многие сотни функций.
Спецификация ARINC 653 разрабатывалась специально для систем РВ. Основное внимание в ней уделено средствам повышения надежности (в частности, восстановлению работоспособности после сбоев), (псевдо) параллельным и периодическим вычислениям, а также средствам синхронизации и передачи данных. В спецификации используется небольшое число объектов ОС (семафоры, очереди сообщений, каналы и др.), для работы с каждым из которых применяется однотипный интерфейс. Спецификация имеет сравнительно небольшой объем и описывает несколько десятков функций.
Первая версия ARINC 653 вышла в 1996 году, и к настоящему времени основные фирмы-производители ОС РВ уже выпустили ОС, соответствующие этой спецификации: VxWORKS AE653 (Wind River) [4], LynxOS-178 2.0 (Lynux-Works, Inc.) [5], INTEGRITY-178B (Green Hills Software Inc.) [6].
POSIX и ARINC существенно отличаются друг от друга: имена функций не совпадают, используется различная терминология. Для ОС РВ спецификация ARINC 653 выбрана в качестве основной. Стандарт POSIX используется в той мере, в какой это допускается данной спецификацией.
Спецификация ARINC 653 предусматривает как пользовательские, так и системные процессы. Интерфейс пользовательских процессов должен соответствовать ARINC; на интерфейс системных процессов с ОС спецификация ARINC 653 не накладывает никаких ограничений. С целью обеспечения совместимости с ОС, соответствующими POSIX, для системных процессов используется POSIX-интерфейс. Таким образом, в рамках ОС РВ могут одновременно выполняться как ARINC-процессы (пользовательские процессы в терминологии ARINC), так и POSIX-процессы (системные процессы в терминологии ARINC).
В соответствии со стандартом POSIX реализованы функции, обеспечивающие поддержку потоков управления (threads), сигналов, средств синхронизации (семафоров, мьютексов и условных переменных), очередей сообщений, часов и таймеров, ввода/вывода, терминалов, сети, протоколирования.
Кроме того, в соответствии со стандартом POSIX реализованы математические функции,
функции обработки символов и строк, распределения памяти и др.
Все POSIX-процессы, за исключением главного системного процесса, выполняются в пользовательском режиме процессора. Главный системный процесс выполняется в привилегированном режиме процессора.
Реализованы все функции спецификации ARINC 653, отмеченные как обязательные, а также необязательные функции управления расписаниями. Эти функции обеспечивают:
- управление процессами (partition), включая планирование;
- управление потоками (process);
- синхронизацию потоков управления внутри одного процесса (семафоры и события);
- передачу данных внутри одного процесса (buffer и blackboard) и по каналам;
- службу времени;
- обработку ошибок.
Все ARINC-процессы выполняются в пользовательском режиме процессора.
Загрузка и порождение как POSIX-, так и ARINC-процессов в соответствии с ARINC 653 происходят только при инициализации модуля. Порождаемые процессы и выделяемые им ресурсы указываются при конфигурировании системы. По завершении этапа инициализации порождение процессов невозможно, но возможны рестарт (останов и запуск с начала) и останов ARINC-процессов. Рестарт POSIX-процессов невозможен (только вместе с рестартом модуля).
Программный код каждого процесса, работающего в пользовательском режиме, представляет собой отдельный модуль (может быть получен сборкой нескольких объектных модулей), который загружается в память независимо от программного кода ОС и других процессов. Программный код главного системного процесса объединяется с программным кодом ядра и загружается вместе с ним.
Существуют четыре режима работы ARINC-процессов: холодный старт (инициализация), горячий старт (инициализация), рабочий режим, простой.
Работа пользовательского процесса начинается с инициализации (режимы холодный или горячий старт). На этом этапе планирование запрещено и выполняется главная функция процесса. Создаются потоки управления и другие используемые процессом объекты ОС (семафоры, доски объявлений, очереди сообщений, описатели событий и порты), что в других режимах невозможно.
В случае успешного завершения инициализации прикладная программа переводит процесс в рабочий режим, в противном случае - в режим простоя или повторной инициализации. В рабочем режиме переключение потоков разрешено и выполняются потоки, созданные на этапе инициали-
зации, если, конечно, они находятся в работоспособном состоянии.
Смена режима работы процессов возможна по инициативе прикладной программы, по инициативе ОС (при обработке ошибок), а также при нажатии клавиши сброса или при включении питания.
Режим работы одного пользовательского процесса не зависит от режимов работы других. Например, один пользовательский процесс может находиться в режиме инициализации, тогда как другой - в рабочем режиме.
Планирование процессов в ОС РВ периодическое и определяется расписанием (циклограммой). В расписании указывается основной период (major frame), который разбивается на окна (непересекающиеся временные интервалы). По завершении основного периода он повторяется неограниченное число раз. Для каждого окна указывается, какие ARINC-процессы будут выполняться, а также будут ли здесь выполняться потоки POSIX-процессов. Никакие другие процессы в данном окне выполняться не будут, даже если это вызовет простой процессора.
Планирование процессов в пределах одного окна происходит на основе приоритетов процессов (которые могут изменяться от окна к окну). Каждый ARINC-процесс имеет собственный приоритет, отличный от приоритетов других процессов данного окна. Все POSIX-процессы имеют единый приоритет в данном окне (отличный от приоритетов ARINC-процессов).
Процесс считается работоспособным, если хотя бы один его поток управления работоспособен. В каждый момент выполняется наиболее приоритетный работоспособный поток наиболее приоритетного работоспособного процесса. Если наиболее приоритетным является POSIX-процесс (процессы), то выбирается наиболее приоритетный работоспособный поток управления среди всех POSIX-процессов.
Другими словами, потоки ARINC-процессов конкурируют за процессор с другими потоками того же процесса в соответствии с приоритетами потоков. Потоки POSIX-процессов конкурируют за процессор с потоками всех POSIX-процессов в соответствии с приоритетами потоков.
На разных стадиях выполнения прикладной программы могут использоваться разные расписания. У каждого расписания свой основной период и свой список окон, а у каждого окна свой список процессов (с приоритетами внутри данного окна), которые могут выполняться в пределах этого окна. Расписания создаются при конфигурировании системы.
Методы повышения надежности
Одним из важнейших методов повышения надежности и живучести является разбиение систе-
мы на слабо взаимодействующие части. При возникновении ошибки в одной части системы это позволяет сохранить работоспособность остальных частей и восстановить работоспособность той части, в которой произошел сбой. Получаемый эффект возрастает с ростом сложности ПО.
Указанный метод применим как для разработки приложений, так и для разработки самой ОС. Приложение разбивается на несколько процессов, слабо взаимодействующих друг с другом. Все процессы, кроме главного системного, работают в пользовательском режиме процессора и используют виртуальную адресацию, что исключает доступ одних процессов к памяти других. Главный системный процесс в основном использует виртуальную адресацию; физическая адресация применяется крайне редко. При использовании виртуальной адресации доступ к памяти других процессов невозможен.
Для хранения системных данных (описатели потоков, семафоров и др.), относящихся к конкретному АЛЖС-процессу, ОС использует сегмент системных данных этого процесса. Каждый АЛЖС-процесс имеет собственный сегмент системных данных. В силу этого ошибки в системных данных одного АЛЖС-процесса не влияют на работу других процессов. РО51Х-процессы используют общий для всех РО51Х-процессов сегмент системных данных. Сегменты системных данных процессов недоступны в пользовательском режиме процессора, в котором работают прикладные программы.
При обработке системных вызовов ОС в основном использует виртуальную адресацию; физическая адресация используется крайне редко. В случае АЛЖС-процесса виртуальная адресация позволяет производить запись только в память выполняемого процесса (как в пользовательскую, так и в системную). Обработчики прерываний также в основном используют виртуальную адресацию.
Единственным способом взаимодействия АЛЖС-процессов между собой и с РО51Х-процес-сами являются каналы. РО51Х-процессы могут взаимодействовать с помощью широкого набора средств, предусмотренных стандартом РОБ1Х (семафоры, очереди сообщений и др.). Такое ограничение на способы взаимодействия АЛЖС-про-цессов в случае сбоя одного АЛЖС-процесса позволяет сохранить работоспособность других процессов, которые взаимодействуют со сбойным процессом. В случае использования, например, семафоров сбой одного процесса может привести к потере работоспособности (зависанию) других процессов, использующих данный семафор.
Периодическое планирование процессов в ОС РВ, определяемое расписанием, позволяет обеспечить каждому АЛЖС-процессу требуемое количество процессорного времени независимо от активности других процессов.
Повышению надежности и живучести также способствуют развитые средства обработки ошибок и восстановления работоспособности после сбоев, описанные ниже. Чтобы избежать ошибок при работе как прикладных программ, так и ОС, производится контроль переполнения стека. При входе в каждую функцию проверяется, достаточно ли свободного места в стеке для работы этой функции. Если места мало, фиксируется ошибка.
При обслуживании системных вызовов перед выполнением запроса производится проверка аргументов.
Для отладки ОС была разработана обширная система тестов, реализующая, в частности, все требования спецификации ЛЯ/ЫС 653 к системе тестов. Работа над системой не прекращается, к ней добавляются новые тесты, а имеющиеся совершенствуются.
Обработка ошибок
ОС РВ содержит средства диагностики и протоколирования ошибок, обеспечивает защиту ОС и прикладных программ от ошибок в других прикладных программах, а также содержит средства восстановления работы приложений при сбоях. Диагностика ошибок производится аппаратурой, ОС и прикладной программой, обработка - ОС и прикладной программой.
В соответствии со спецификацией ЛЯ/ЫС 653 реакция на ошибку при выполнении ЛЛ/АС-про-цесса определяется при конфигурировании системы. В первую очередь при конфигурировании определяются уровни ошибок в зависимости от ошибки и состояния системы. Возможны уровни ошибок модуля, процесса, потока управления.
Ошибки уровня модуля и уровня процесса обрабатываются ОС. Реакция на эти ошибки определяется при конфигурировании системы и может зависеть от ошибки и состояния системы. Возможны следующие виды реакции на ошибки уровня модуля: рестарт модуля, останов модуля, игнорирование ошибки.
Для ошибок уровня процесса возможны реакции на останов процесса, рестарт процесса, команду игнорировать.
К ошибкам уровня потока управления можно отнести только ошибки, возникшие при выполнении потока управления в рамках ЛЛ/АС-процесса. Обработка ошибок уровня потока производится прикладной программой с помощью специального потока обработки ошибок. Реакция на ошибку возможна как на уровне потока, так и на уровне процесса. В частности, поток обработки ошибок может остановить, а также остановить и вновь запустить ошибочный поток, повторно запустить или остановить процесс.
Реакция на ошибки в РО5/Х-процессах определяется при конфигурировании ядра и может
принимать следующие значения: приостановка потока, посылка сигнала, перезагрузка.
Временные характеристики
При оценке систем РВ используются две важнейшие характеристики - время ответа на прерывание и время ответа потока управления.
Время ответа на прерывание - это время между моментом, когда был выставлен запрос на прерывание, и моментом, когда начала выполняться первая команда функции обработки прерывания. Оно включает в себя, в частности, задержку прерывания - время, на которое ОС запрещает прерывание.
Время ответа потока управления - это время между моментом, когда был выставлен запрос на прерывание, и моментом, когда начала выполняться первая команда потока, который должен отреагировать на это прерывание. Оно включает в себя, в частности, время ответа на прерывание, задержку планирования и время переключения контекста.
Задержка планирования - это промежуток времени, когда планирование (переключение потоков управления) запрещено. Запрещение планирования является широко используемым методом взаимного исключения для защиты критических ресурсов. Для повышения скорости реакции системы важно, чтобы длительность задержки прерывания и задержки планирования была минимальной.
Время переключения контекста - это время, требующееся для того, чтобы одна задача прекратила свою работу, а другая начала ее.
С целью уменьшения задержки прерывания ОС запрещает прерывания лишь на время установки в неупорядоченную очередь или изъятия из нее, на время увеличения (уменьшения) некоторых счетчиков, на время установки или снятия некоторых флагов, а также в прологе обработчика прерываний.
Если обработка прерываний требует длительного времени, она производится в контексте потока управления. Обработчик прерываний лишь запускает соответствующий поток. Служебные потоки управления используют РО5/Х-интерфейс, в частности, мьютексы, которые позволяют избежать инверсии приоритетов.
Для уменьшения задержки планирования ОС запрещает планирование лишь на время установки описателя потока, а также некоторых других объектов в упорядоченную очередь. Планирование процессов и потоков возможно как при выполнении прикладной программы, так и при выполнении функций ОС, вызванных прикладной программой.
Планирование потоков и процессов производится немедленно, если оно требуется и не запрещено. Если потребность в планировании возникла,
когда оно было запрещено, то планирование будет произведено сразу после разрешения.
Результаты измерений временных характеристик (модуль БТ23-206 с частотой 400 МГц) следующие:
• время переключения контекста - 1,3-1,6 мкс;
• время задержки прерывания - 0,6 мкс;
• время реакции потока - 3,9 мкс;
• скорость передачи данных между процессами на различных модулях по шине УМЕ - 12 Мб/сек.;
• перезагрузка процесса - 33 мс.
Мобильность
При разработке системы ставилась задача обеспечения мобильности как приложений, так и самой ОС. Мобильность приложений обеспечивается в основном применением стандартов, описывающих интерфейс приложений с ОС.
С целью повышения мобильности ОС она разбита на три части:
- не зависящая от аппаратуры,
- зависящая только от типа центрального процессора,
- пакет поддержки модуля.
Не зависящая от аппаратуры часть ОС имеет самый большой объем и полностью написана на языке С. Та часть ОС, которая зависит только от типа процессора, написана на языках С или ассемблера и имеет сравнительно небольшой объем. Туда входят, например, функции запоминания и
восстановления контекста, пролог и эпилог диспетчера прерываний.
Пакет поддержки модуля содержит ту часть ОС, которая зависит от конкретной ЭВМ (модуля), в частности, это могут быть драйверы устройств.
В заключение отметим, что ОС РВ Багет 3.0 -современная высоконадежная отечественная ОС с пользовательским интерфейсом, базирующимся на спецификации ARINC 653 и стандарте POSIX 1003.1, с временными характеристиками на уровне мировых стандартов. Использование ARINC 653 обеспечивает адекватный интерфейс разработчикам прикладного ПО, а наличие POSIX-процессов дает возможность с минимальными издержками переносить ПО из систем с POSIX-интерфейсом, в частности, из ОС РВ Багет 2.0.
Литература
1. Безруков В.Л. [и др.]. Введение в oc2000 // Вопросы кибернетики. М.: НИИСИ РАН, 1999.
2. Avionics application software standard interface, Part 1 / Required services, Aeronautical radio, Inc, March, 2007.
3. IEEE Standard for Information Technology / Portable Operating System Interface (POSIX) Part 2: System Interface. IEEE Std 1003.1-2004, Vol. 2.
4. Wind river platform for safety critical ARINC 653. URL: http://www.windriver.com/products/platforms/safety_critical_arinc _653/resources/platform_sc_arinc653_ds.pdf (дата обращения: 16.07.2010).
5. LynxOS-178 2.0. URL: http://www.lynuxworks.com/rtos/ lynxos-178.pdf (дата обращения: 16.07.2010).
6. Safety Critical Products: INTEGRITY- 178B RTOS. URL: http://www.ghs.com/download/datasheets/INT_178B.pdf (дата обращения: 16.07.2010).
УДК 004.021
ПЛАНИРОВАНИЕ ЗАДАНИЙ С СИНХРОННЫМ СТАРТОМ
А.И. Грюнталь, к..ф.-м.н.. (НИИСИРАН, г. Москва, [email protected])
Рассматривается формализованная модель исполнения произвольной многозадачной системы реального времени с синхронным стартом. Для таких систем формулируются необходимые и достаточные условия, выполнение которых обеспечивает своевременное исполнение всех задач. Приводится соответствующий алгоритм планирования.
Ключевые слова: реальное время, программное обеспечение, многозадачность, планирование, синхронный старт.
В вычислительных системах, функционирующих в реальном масштабе времени, используется, как правило, многозадачный псевдопараллельный режим вычислений. Планирование вычислительного процесса для таких систем должно обеспечивать обязательное своевременное выполнение всех ее задач.
Для сравнительной оценки различных алгоритмов планирования строится математическая модель распределения процессорного времени. В рамках модели подробно рассматриваются многозадачные системы с синхронным стартом, для которых формулируются условия (критерий раз-
решимости системы), обеспечивающие своевременное выполнение всех задач.
Приводимый в статье подход может применяться в вычислительных системах, создаваемых на базе разработанной в НИИСИ РАН операционной системы реального времени ос2000 [Годунов А.Н. и др.].
Модель многозадачной системы
В модели аналогом задачи (программы, потока) является задание. Прикладная задача в целом рассматривается как последовательность заданий,
