CC BY
46
• доля вызовов среди переходов - отношение числа удаленных вызовов (суммарно на всех узлах) к числу переходов Т;
• неравномерность распределения - отношение среднеквадратичного отклонения к среднему для последовательности Шх, т2, ..., т№ где т1 -число состояний, хранимых узлом 1;
• время простоя при ожидании сообщений от других узлов (сетевые задержки);
• общее время работы.
Сравнение распределений
р Доля вызовов среди переходов, % Неравномерность распределения, % Время простоя, сек. Общее время работы, сек.
Алгоритм выбора лидера
1 16 66,3 29 43
2 35 12,8 65 84
Н 87 0,1 127 164
Обедающие философы
1 17 89,4 3 14
2 35 29,6 7 21
Н 88 0,1 50 74
Проблемные значения выделены жирным шрифтом.
Из результатов можно сделать следующие выводы.
1. Выбор распределения между узлами важен, поскольку время простоя за счет удаленных вызовов составляет существенную часть от времени выполнения.
2. При наивном подходе к распределению состояний число удаленных вызовов близко к числу всех переходов, как и следует из расчетов.
3. Предлагаемый способ распределения состояний по первым р процессам позволяет в несколько раз по сравнению с наивным подходом уменьшить число удаленных вызовов и время выполнения.
4. Необходим подбор параметра р в соответствии со свойствами проверямой модели (P, Wj) для обеспечения требуемого уровня равномерности распределения состояний; в частности, значения р=1 в приведенных экспериментах оказалось недостаточно, поскольку неравномерность до 90 % означает, что большая часть памяти некоторых узлов не используется вообще.
В заключение отметим, что использование параллельной генерации состояний дискретных детерминированных моделей в ходе проверки их соответствия спецификациям делает возможной верификацию моделей размера, на несколько порядков большего, чем позволяют традиционные подходы с последовательной генерацией. Одним из наиболее важных факторов является функция распределения хранимых состояний между узлами, правильный выбор которой, как подтверждают эксперименты, позволяет в несколько раз ускорить верификацию.
Литература
1. Кларк Э.М., Грамберг О., Пелед Д. Верификация моделей программ. МЦНМО, 2002.
2. Gerard J. Holzman. An Analysis of Bitstate Hashing. In proc. 15th Int. Conf. on Protocol Specification, Testing, and Verification. Kluwer, 1998, pp. 301-314.
3. Jiri Barnat, Lubos Brim. Parallel Breadth-First Search LTL Model-Checking. 18th IEEE International Conf. on Automated Software Engineering (ASE'03). Springer, Berlin, 2003, pp. 106-115.
4. Flavio Lerda, Riccardo Sisto, Distributed-Memory Model Checking with SPIN, Lecture Notes In Computer Science // Springer, Berlin, 1999. Vol. 1680, pp. 22-39.
УДК 004.05
ИССЛЕДОВАНИЕ АРХИТЕКТУРНОЙ ЧУВСТВИТЕЛЬНОСТИ К СБОЯМ С ИСПОЛЬЗОВАНИЕМ МЕТОДА СТАТИСТИЧЕСКОГО ВНЕСЕНИЯ СБОЕВ
П.Н. Осипенко, к.т.н.; А.А. Антонов; С.А. Левадский
(НИИСИРАН, Москва, [email protected], [email protected], [email protected])
В статье описываются методика определения коэффициента архитектурной чувствительности к сбоям цифровых блоков и результаты ее применения на примере исследования блока автомата состояний контроллера мультиплексного канала информационного обмена, выполненного в соответствии с ГОСТ Р 52070-2003.
Ключевые слова: коэффициент архитектурной чувствительности к сбоям, эталонная трасса, микроархитектурное состояние, «серый» результат.
С уменьшением проектных норм обостряется проблема одиночных сбоев в современных интегральных схемах вследствие воздействия на них одиночных частиц (ТЗЧ, протонов, нейтронов) [1].
Чтобы разрабатывать эффективные методы защиты, необходимо понимать особенности поведения интегральных схем в присутствии одиночных сбоев. Одной из них является то, что одиночные сбои
в микроэлектронных устройствах не всегда приводят к ошибкам в работе системы. Так, если сбой, то есть изменение логического состояния, произошел в ячейке памяти, которая впоследствии будет перезаписана новым значением, система не почувствует его. Для количественного определения способности архитектуры системы парировать сбои используется коэффициент, равный отношению числа ошибок, вызванных сбоями, к их общему числу. В зарубежной литературе этот коэффициент обозначается AVF - architecture vulnerability factor [2]. В данной статье для него используется термин коэффициент архитектурной чувствительности к сбоям (Кач): Кач=^б^ош, где nc6 - общее число сбоев, произошедших в системе; - число ошибок, то есть нарушений корректного функционирования системы, вызванных сбоями.
Одним из методов определения Кач является метод статистического внесения сбоев (SFI - statistic fault injection) [2]. Суть его состоит в том, что в процессе моделирования исследуемого блока в один из элементов памяти в случайно выбранный момент вносится сбой, то есть состояние элемента меняется на противоположное. Необходимо определить, вызывает ли данный сбой нарушение функционирования. Проведя достаточно большое количество сеансов моделирования, можно найти искомый коэффициент.
Примеры применения метода для исследования Кач микропроцессорных схем описаны в [3, 4]. Однако, несмотря на то, что суть его достаточно проста, конкретные детали реализации метода в рассматриваемой литературе остаются нераскрытыми. Соответственно, потребовалась разработка методики, которая детально описывает процедуру определения Кач с его помощью.
В данной статье описывается методика определения Кач цифровых блоков, реализованных на языке VerilogHDL, методом статистического внесения сбоев и приводятся результаты ее применения на примере исследования блока автомата состояний контроллера мультиплексного канала информационного обмена (МКИО), выполненного в соответствии с ГОСТ Р 52070-2003.
Методика определения коэффициента архитектурной чувствительности к сбоям
В методике определения коэффициента архитектурной чувствительности к сбоям примем следующие допущения:
- рассматриваются только одиночные сбои;
- сбои происходят только в элементах памяти;
- элементы памяти имеют равную вероятность сбоя;
- место и время появления сбоя распределены равномерно.
Методика определения факта ошибки. До
начала эксперимента строится эталонная трасса выполнения тестовой программы, в которой по-тактно фиксируется состояние на выходах анализируемой модели в отсутствие сбоев. По окончании моделирования запоминается эталонное состояние всех элементов памяти (микроархитектурное состояние).
Собственно эксперимент заключается в выполнении серии сеансов моделирования, в ходе каждого из которых случайный триггер в случайный момент меняет свое состояние. В процессе моделирования состояния выходов модели сравниваются с эталонной трассой. По окончании моделирования микроархитектурное состояние сравнивается с эталонным.
Возможны следующие варианты окончания сеанса моделирования.
1. Расхождения трасс и микроархитектурных состояний не зафиксированы. Это означает, что сбой был парирован, и результат помечается как «отсутствие ошибки».
2. Обнаружено расхождение трасс в любом из тактов. Эта ситуация считается ошибкой, и результат помечается как «ошибка».
3. Расхождения трасс зафиксированы не были, но имеется расхождение в микроархитектурном состоянии по окончании моделирования. Это означает, что в процессе моделирования сбой никак не проявился, но к моменту его окончания продолжает присутствовать в схеме. Соответственно, существует вероятность, что при продолжении моделирования с использованием другого теста ошибка может проявиться. Этот результат помечается как «серый» и при подсчете Кач прибавляется к ошибкам.
Определение места и времени внесения сбоя. До начала моделирования средствами САПР из анализируемой модели извлекается полный список элементов памяти, который составляет диапазон возможных значений мест возникновения сбоя. Диапазон возможных значений времени внесения сбоя определяется как общее время работы тестовой программы. Перед началом очередного сеанса генератор случайных чисел из списка элементов выбирает элемент для внесения сбоя в процессе моделирования, а из периода работы программы -момент сбоя. Номер элемента и момент сбоя передаются как параметры в тестовый модуль in-sert_fault.v, внедренный в систему моделирования.
Блок-схема алгоритма определения Кач приведена на рисунке 1.
Для реализации предложенного алгоритма написаны следующие программы.
1. Программа получения эталонной трассы и микроархитектурного состояния (VerilogHDL). Подключается к тестовой системе и сохраняет в бинарном файле потактно значения всех входов и соответствующих выходов исследуемого объек-
Создание списка элементов памяти, определение времени для внесения сбоя
Построение эталонной трассы
Сохранение архитектурного состояния в конечный момент
Задание числа сеансов моделирования N
Выбор случайного момента и
номера элемента памяти. Запуск сеанса моделирования с внесенным сбоем
Рис. 1
та (выполняется до внесения ошибок), а также значения всех элементов памяти по окончании моделирования.
2. Программа получения списка элементов памяти (скрипт-файл в формате языка ^I). Позволяет получить в текстовом виде список всех элементов памяти исследуемого объекта из г/7-модели.
3. Программа генерации места и времени внесения ошибки (VerilogHDL). Программа-модуль, которая подключается к тестовой системе и в случайный момент вносит одиночную ошибку в один из элементов памяти списка.
4. Программа автоматической генерации Veri-^д-модуля внесения ошибки (С++). Автоматически создает код модуля предыдущей программы, имея на входе список элементов памяти исследуемого объекта.
5. Программа сравнения трасс и микроархитектурного состояния (VerilogHDL). Тестовая система исследуемого объекта; проводит серию сеансов моделирования, выполняет подачу на входы исследуемого объекта данных из бинарного файла и сравнивает выходы объекта с соответствующими данными из того же файла, сохраняет статистику, вычисляет Кач.
Результаты исследований
Апробация разработанной методики проведена на примере исследования Verilog-модели блока
автомата состояний контроллера МКИО, выполненного в соответствии с ГОСТ Р 52070-2003.
Основной задачей МКИО являются инициализация передач информации в канале и контроль их прохождения. В связи с этим МКИО должен иметь возможность считывать подготовленную информацию из ОЗУ, передавать ее в мультиплексный канал и наблюдать за сообщениями, передаваемыми оконечными устройствами. При необходимости контроллер канала может анализировать поступающие сообщения и использовать различные способы восстановления связи при обнаружении сбоев.
Блок представляет собой набор программно доступных регистров и автомат состояний. Его структурная схема приведена на рисунке 2. Общее количество элементов памяти - 49.
Входная шина Набор Автомат Управляющие сигналы мультиплексного канала к
регистров состояний
Рис. 2
В качестве тестовых программ использованы BC_REG_TEST и BC_RESPONSE. Программа BC_REG_TEST представляет собой простейший тест регистров и выполняется примерно за 44 тысячи тактов. Программа BC_RESPONSE осуществляет более глубокую проверку функционирования блока и выполняется более чем за 330 тысяч
1400 1200 1000 800 600 400 200 0
1400 1200 1000 800 600 400 200 0
Кач = 0,97
Кач = 0,42
1000
Число экспериментов
а)
Кач = 0,4
1 I
<1 : _
-п I
1000
Число экспериментов
б)
Рис. 3
Кач = 0,97
Кач = 0
500
2000
Кач = 0,38
500
2000
тактов. Один сеанс моделирования с использованием САПР 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
А.Н. Годунов, к.ф.-ж.н. (НИИСИРАН, г. Москва, [email protected])
В статье рассматриваются требования, архитектура и принципы построения высоконадежных операционных систем реального времени на примере отечественной операционной системы Багет 3.0.
Ключевые слова: реальное время, операционная система, надежность, РОБ1Х, ЛШЖ-653.
Системы реального времени (РВ) по мере развития становятся все более сложными, в их разработке принимают участие большие коллективы. Требования к надежности систем РВ постоянно возрастают. В силу этого назрела потребность в разработке средств повышения надежности систем РВ в случае сбоев в работе прикладных программ и операционной системы (ОС). В статье рассматриваются принципы и пути построения ОС РВ Багет 3.0, которая была разработана с целью решения указанных проблем. Данная система - развитие ОС РВ Багет 2.0 [1], которая используется специалистами более 100 организаций нашей страны в течение 10 лет.
Разработка ОС РВ Багет 3.0 базируется на следующих принципах:
- использование стандартов;
- мобильность (portability);
- разбиение системы на слабо взаимодействующие части (partitioning) с тем, чтобы сбои в одной части не влияли на работоспособность других;
- наличие средств восстановления после сбоев, а также развитые средства диагностики и обработки ошибок;
- гибкие средства планирования (периодическое, приоритетное планирование, планирование с вытеснением - preemptive scheduling);
- использование объектно-ориентированного подхода;
- управляемость (в частности, наличие средств конфигурирования).
При разработке ОС РВ использовались спецификация ARINC 653 [2] и стандарт POSIX 1003.1 [3], определяющие интерфейс прикладных программ с ОС.
