ФАКУЛЬТЕТ ВМиК КАФЕДРА АСВК ЛАБОРАТОРИЯ ВЫЧИСЛИТЕЛЬНЫХ КОМПЛЕКСОВ Дипломная работа на тему: «Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования» Выполнил студент 522 группы Шаров А.А. Научный руководитель ассистент Волканов Д.Ю. Москва, Май 2005 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Аннотация Формулировка задачи Целью данной дипломной работы является адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени, представленных имитационными моделями и написание средства автоматического внесения неисправностей в имитационные модели среды моделирования ДИАНА. Актуальность данной работы подтверждается тем, что в настоящее время отсутствует возможность применения метода внесения неисправностей к имитационным моделям вычислительных систем реального времени, а также отсутствуют средства автоматического внесения неисправностей в имитационные модели. Формально задача ставится следующим образом: Адаптировать и реализовать метод внесения неисправностей для оценки надёжности вычислительных систем реального времени с использованием имитационного моделирования. При адаптации необходимо учесть различные варианты применения методов внесения неисправностей и выбрать из них наиболее подходящий, а также предусмотреть возможность применения выбранного метода внесения неисправностей к существующим имитационным моделям вычислительных систем реального времени. При реализации необходимо учесть внутреннее устройство и специфику языка моделирования среды ДИАНА, а также интегрировать автоматическое средство внесения неисправностей в транслятор языка моделирования среды ДИАНА в Си++ (mmt). Основные результаты Основными результатами работы являются: Адаптация метода внесения неисправностей до компиляции для оценки надежности вычислительных систем реального времени; Реализация средства автоматического внесения неисправностей в имитационные модели вычислительных систем реального времени, написанные в среде моделирования ДИАНА. 2 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ СОДЕРЖАНИЕ 1 ВВЕДЕНИЕ ................................................................................................................... 5 2 ПОСТАНОВКА ЗАДАЧИ ............................................................................................ 11 3 ОБЗОР СОВРЕМЕННЫХ МЕТОДОВ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ ............... 12 3.1 Основные понятия ................................................................................................ 12 3.2 Классификация неисправностей ......................................................................... 13 3.3 Методы повышения надежности ......................................................................... 17 3.4 Методы отказоустойчивости ................................................................................ 18 3.4.1 Средства управления резервированием ...................................................... 18 3.4.2 Организация резервирования ....................................................................... 18 3.4.3 Механизмы обнаружения ошибок ................................................................. 19 3.4.3.1 Контрольные тесты ................................................................................. 20 3.4.3.2 Отказоустойчивые алгоритмы ................................................................ 20 3.4.3.3 Проверки .................................................................................................. 21 3.4.3.4 Диагностическое тестирование .............................................................. 22 3.4.4 Механизмы устранения ошибок .................................................................... 22 3.4.4.1 Одноверсионное программирование..................................................... 22 3.4.4.2 Многоверсионное программирование. .................................................. 24 3.4.4.3 Общие подходы к устранению ошибок в аппаратных компонентах .... 26 4 МЕТОДЫ ВНЕСЕНИЯ НЕИСПРАВНОСТЕЙ ........................................................... 27 4.1 Суть методов внесения неисправностей ............................................................ 27 4.2 Классификация методов внесения неисправностей.......................................... 28 4.2.1 Аппаратное внесение неисправностей ......................................................... 28 4.2.2 Программное внесение неисправностей ...................................................... 28 4.2.2.1 Разделение программных компонентов. ............................................... 29 4.2.2.2 Низкоуровневое внесение неисправностей. ......................................... 29 4.2.2.3 Высокоуровневое внесение неисправностей. ....................................... 30 4.2.3 Сравнение аппаратного и программного внесения неисправностей ......... 30 4.3 Обзор существующих средств внесения неисправностей ................................ 31 4.3.1 FIAT (Fault Injection-based Automated Testing) .............................................. 31 4.3.2 DOCTOR (IntegrateD SOftware Fault InjeCTiOn EnviRonment) ..................... 32 4.3.3 FERRARI (Fault and ERRor Automatic Real-time Injection) ............................ 33 4.3.4 FINE (Fault INjection and Monitoring Environment) ......................................... 33 4.3.5 FTAPE (Fault Tolerance And Performance Evaluator) ..................................... 34 4.3.6 XCEPTION ....................................................................................................... 34 4.3.7 C-Patrol ............................................................................................................ 35 4.3.8 Сравнение существующих средств внесения неисправностей .................. 35 4.3.9 Актуальность создания средства внесения неисправностей ...................... 36 4.4 Адаптация метода внесения неисправностей применительно к имитационным моделям среды ДИАНА ............................................................................................... 36 5 ОПИСАНИЕ СРЕДСТВА АВТОМАТИЧЕСКОГО ВНЕСЕНИЯ НЕИСПРАВНОСТЕЙ 38 5.1 Структура средства .............................................................................................. 38 5.1.1 Среда моделирования ДИАНА ...................................................................... 38 5.1.2 ММ-язык среды ДИАНА .................................................................................. 39 5.1.3 Интеграция средства автоматического внесения неисправностей с транслятором ММ-языка среды ДИАНА в Си++ (mmt) ........................................... 39 5.1.4 AST-деревья ................................................................................................... 40 5.1.5 Архитектура средства .................................................................................... 41 5.2 Схема работы средства ....................................................................................... 43 5.2.1 Обеспечение идентичности прогонов ........................................................... 45 3 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 5.2.2 Библиотека неисправностей .......................................................................... 47 5.2.3 Конфигурационный файл ............................................................................... 54 5.2.4 Поиск мест возможного внесения неисправностей...................................... 56 5.2.5 Генерация кода на ММ-языке по AST-дереву .............................................. 57 5.2.6 Средство сравнения трасс ............................................................................. 58 6 ЗАКЛЮЧЕНИЕ ............................................................................................................ 59 7 ЛИТЕРАТУРА ............................................................................................................. 60 4 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 1 Введение С каждым годом компьютерные системы получают все большее и большее распространение в различных аспектах нашей жизни. Особенно впечатляющего прогресса, причем не только в распространении, но и в увеличении возможностей, а также сложности решаемых задач они достигли за последние десять лет. Большинство сфер деятельности и отраслей промышленности сильно зависят от компьютерных систем в своей повседневной деятельности. Надежное и безотказное функционирование – это важнейшее требование для многих типов компьютерных систем, например, для бортовых систем самолетов и автоматических авиадиспетчеров, автоматизированных медицинских приборов, диспетчеров ядерной безопасности и нефтехимического контроля, систем управления денежными переводами и электронной коммерции, сухопутных и морских систем военной навигации, различных систем в области космонавтики. Цена отказов таких систем может варьироваться от легкой досады пользователя до катастрофических последствий – серьезных повреждений, или даже гибели людей, уничтожения компьютерной системы, взлома безопасности системы, и.т.п. К различным по профилю компьютерным системам ставятся различные требования надежности: вероятность получения правильного результата, способность устранять ошибки, которые могут стать критическими для работы системы, уровень защищенности от преднамеренных вторжений в систему, и.т.д. С середины XIX века в надежных услугах связи и безошибочных вычислениях заинтересованы как поставщики этих услуг, так и их пользователи. В июле 1844 года доктор Дионисиус Ларднер опубликовал статью под названием «Вычислительная машина Бэббиджа», в которой написал: «Наиболее точной и эффективной проверкой ошибок, возникающих в процессе вычислений, является организация одних и тех же вычислений на различных независимых друг от друга вычислителях; и эта проверка оказывается еще более убедительной, если они производят вычисления разными способами» [1]. Первое поколение компьютеров (с конца 40-х до середины 50-х годов прошлого века) использовало в большинстве своем ненадежные компоненты, поэтому для увеличения их надежности использовались специальные методы, такие как контрольные коды, дублирующиеся передачи данных с последующим их сравнением, диагностики для обнаружения отказавших компонентов и.т.п. В то же самое время Дж. фон Нейман, Э. Мур и К. Шэннон, а также их последователи разработали различные принципы избыточности для построения надежных логических структур из менее надежных компонентов, ошибки в которых маскировались благодаря наличию нескольких идентичных избыточных компонентов [2]. Разработанные ими принципы избыточности были объединены В. Пирсом в 1965 году в «концепцию отказоустойчивости» [3]. В 1967 году А. Авизиенис объединил маскирование с методами обнаружения ошибок, диагностического тестирования и устранения ошибок в «концепцию отказоустойчивых систем» [4]. Создание в 1970 году рабочей группы «IEEE-CS TC on FaultTolerant Computing», а затем в 1980 году «IFIP WG 10.4 Dependable Computing and Fault Tolerance» привело к появлению четкого набора терминов и непротиворечивой терминологии в теории отказоустойчивости [2]. В 1982 году на заседании специальной сессии по определению основных принципов отказоустойчивости конференции FTCS-12 были представлены семь различных позиций, объединенные Ж. К. Лапри в 1985 году [5, 6]. Дальнейшая работа членов «IFIP WG 10.4», ведомой Ж. К. Лапри, привела к написанию в 1992 году книги «Dependability: Basic Concepts and Terminology» [7]. Если ранее надёжность аппаратуры была намного ниже, нежели надёжность программного обеспечения, то в настоящее время ввиду усовершенствования аппаратной базы и появления новых технологий, а также усложнения программного обеспечения значения их надёжности стали различаться гораздо меньше [8]. Поэтому в настоящее время при оценке надёжности компьютерной системы необходимо самым серьезным образом учитывать влияние программного обеспечения. В идеале, после всех этапов разработки, то 5 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ есть процессов анализа требований, разработки спецификации, создания и тестирования, должно получаться абсолютно надежное программное обеспечение. Однако на практике достижения в этой области на сегодняшний день таковы, что при разработке программного обеспечения ошибок допускается мало, но, к сожалению, эти немногие ошибки не всегда устраняются. Даже при использовании лучших методов, средств и разработчиков рискованно полагать, что созданное программное обеспечение является абсолютно надежным. Возможны случаи, когда ошибку, найденную во время эксплуатации системы, намеренно оставляют неустраненной из-за несоизмеримых затрат на ее ликвидацию из системы. Примеры отказов различных систем, в которых программное обеспечение сыграло решающую роль, а также последствия этих отказов приведены ниже: В воздухоплавательной отрасли перед компьютерными системами ставятся специфические задачи, в решении которых особенное внимание необходимо уделять разработке программного обеспечения. Несмотря на принятые меры по обеспечению надежности, широко известны случаи ошибок в программном обеспечении, вызвавшие сбои в системе, так, например, Ошибки в программном компоненте, отвечающем за поддержку резервирования модулей, отложили запуск Atlantis (STS-36) на три дня [9]; Программное обеспечение космического шаттла Endeavor (STS-49) округляло до нуля значения, близкие к нулю, что вызвало тем самым проблемы при стыковке с Intelstat 6 [10]; Из-за ошибки в программном обеспечении Apollo 11 получилось, что лунная гравитация отталкивает тела, а не притягивает [11]; В январе 1990 года произошел отказ одного из переключателей системы AT&T, который из-за допущенных ошибок при проектировании сети и разработке средств устранения ошибок привел к отказу всех 114 переключателей [12]; Во время Персидской войны неправильная работа часового механизма системы Patriot привела к тому, что ракета противника поразила бараки американских солдат в Дхахране. Ракетой было убито 27 человек, 97 получили ранения различной степени тяжести. Позднее выяснилось, что отказ часового механизма был вызван различными программными представлениями числа 0.1 [13]; Ошибки при разработке программного обеспечения аэробуса A320 привели к тому, что пилотам пришлось проявить все свои навыки и умения, чтобы вывести аэробус из аномального состояния [14]. Задача повышения надежности программного обеспечения сильно отличается от аналогичной задачи для аппаратных систем. Аппаратные неисправности – это преимущественно физические неисправности. Физически программное обеспечение не состаривается, не портится и не теряет других своих свойств со временем. Программные неисправности – это логические неисправности в программном обеспечении, которые сложно наглядно продемонстрировать, классифицировать, обнаружить и исправить. Программные неисправности могут вытекать из некорректной спецификации (когда программное обеспечение полностью ей соответствует, но поведение системы по спецификации не соответствует требуемому заказчиком) или из реализации (проектирование и кодирование), не соответствующей спецификации. Причем, изменения в компонентах с уже присутствующими неисправностями могут привести к появлению новых. Для того, чтобы противостоять этим неисправностям, нельзя просто добавить избыточность, как это делается при аппаратных неисправностях, так как тем самым неисправность просто будет продублирована. Поэтому для борьбы с программными неисправностями необходимо использовать специальные механизмы программной отказоустойчивости. В дипломной работе будут рассмотрены как простейшие методы аппаратной, так и нетривиальные методы программной отказоустойчивости. 6 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Из класса компьютерных систем выделим наиболее интересующий нас класс вычислительных систем реального времени. Под вычислительной системой реального времени (ВСРВ) будем понимать такую вычислительную систему, правильность работы которой зависит не только от логических результатов вычислений, но и от промежутка времени, за который эти результаты были получены [15]. Вычислительные системы реального времени включают в себя широкий спектр систем различной степени сложности – от простейших микроконтроллеров до сложнейших распределенных систем. Все системы, приведенные в качестве примеров ранее, являются вычислительными системами реального времени. Обычно вычислительные системы реального времени состоят из управляющей и управляемой систем. Например, в бортовой вычислительной системе самолета, управляемая система – различные датчики, приборы для отображения информации и полученная информация, а управляющая система – это компьютер и интерфейсы взаимодействия, которые координируют и управляют действиями всех приборов. Таким образом, управляемая система – это окружение, с которым взаимодействует компьютер. Управляющая система взаимодействует со своим окружением посредством информации об этом окружении, полученной различными сенсорами. Необходимо, чтобы состояние окружения, воспринимаемое управляющей системой, совпадало с действительным состоянием окружения, иначе действия управляющей среды могут привести к пагубным последствиям. Таким образом, необходимо периодически следить за состоянием окружения, то есть время от времени получать новую информацию от сенсоров. Сложность построения вычислительной системы реального времени сильно варьируется в зависимости от следующих характеристик [15]: Величина директивного срока В вычислительных системах реального времени некоторые задачи имеют директивный срок и/или периодические ограничения на время их выполнения. Если интервал времени между активизацией задачи (началом его выполнения) и моментом времени, к которому оно должно завершиться, короткий, то директивный срок – маленький. Это означает, что реакция окружения должна быть быстрой, а алгоритм планировщика должен быть быстрым и очень простым. Строгие ограничения на время выполнения задач могут также возникать, когда директивный срок большой, но количество необходимых вычислений тоже очень велико. Критичность директивного срока Критичность директивного срока зависит от величины допустимого интервала времени, в течение которого задание может выполняться по истечении директивного срока. Для задач жёсткого реального времени эта величина равна нулю, а вот для задач мягкого реального времени может от нуля отличаться. Для разных типов задач обычно используются совершенно разные методы. Во многих системах задачи жёсткого реального времени планируются в расписании заранее, что приводит к тому, что они гарантированно укладываются в директивный срок. Задачи же мягкого реального времени зачастую планируются с помощью алгоритмов, которые детально просчитывают временные ограничения, но они годятся лишь для систем с высокой производительностью; либо с помощью алгоритмов, сочетающих приоритет задачи с временными ограничениями. Надежность Для многих вычислительных систем реального времени важнейшим требованием является надежность. В таких системах существуют задачи, называемые критическими, которые обязательно должны уложиться в директивный срок, иначе может произойти катастрофа. Обычно для гарантированного выполнения этими задачами директивного срока используются такие методы, как автономный анализ и схемы разработки, при которых ресурсы, необходимые данным задачам 7 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ резервируются специально под них, несмотря даже на то, что преимущественное большинство времени эти ресурсы будут простаивать. Правда стоит заметить, что в большом количестве систем все задачи со строгими временными ограничениями выдают за критические, хотя, на самом деле, критическими являются лишь некоторые из них. Размер системы и степень взаимодействия задач Вычислительные системы реального времени сильно различаются в размерах и сложности. В подавляющем большинстве систем они целиком загружаются в память, или, если есть четко выделяемые этапы работы системы, то загружаются этапы, причем, каждый этап загружается непосредственно перед началом своего выполнения. Во многих приложениях их подсистемы практически не зависят друг от друга, а задачи практически не взаимодействуют. Способность загружать систему целиком в память и ограничивать количество взаимодействий между задачами облегчает многие аспекты построения и анализа систем реального времени. При этом, обычно вычислительные системы реального времени выполняют определенные специализированные функции, и поэтому набор программного обеспечения в них ограничен. Окружение Окружение вычислительной системы реального времени играет огромную роль при проектировании системы. Существуют хорошо изученные окружения, с которыми просто работать, и в которых широко известны алгоритмы построения расписаний, гарантирующие выполнение директивных сроков. Если же окружение незнакомо, то возникают дополнительные проблемы при создании системы. Обобщая сказанное выше, можно заметить, что на вычислительные системы реального времени наложены следующие ограничения: Необходимость работы в реальном времени (выполнение директивных сроков); Необходимость взаимодействия с окружающей средой; Ограниченность ресурсов; Ограниченность набора программ для каждой конкретной системы; Критичность отказов. Как уже было замечено ранее, одним из важнейших требований к вычислительной системе реального времени является её надёжность. Основными причинами, определяющими повышенное внимание к вопросам надёжности вычислительных систем реального времени, являются [16]: Усложнение аппаратуры и программного обеспечения систем; Более медленный рост уровня надёжности комплектующих по сравнению с ростом числа элементов в аппаратуре; Увеличение важности выполняемых системой функций (системы жизненного риска, встроенные бортовые комплексы); Усложнение условий эксплуатации систем. По этим причинам, при разработке вычислительных систем реального времени особо необходимо наделять систему средствами отказоустойчивости, такими как средства обнаружения и устранения ошибок. Под надёжностью вычислительной системы понимают сложное свойство, которое в зависимости от назначения вычислительной системы реального времени и условий ее применения состоит из сочетания следующих свойств [17, 18, 19]: 8 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Безотказность Свойство системы или ее компонента непрерывно сохранять работоспособное состояние в течение всего времени работы системы или ее компонента; Долговечность Свойство системы или ее компонента, которое заключается в сохранении работоспособности до наступления предельного состояния установленного системой технического обслуживания и ремонтов; Ремонтопригодность Свойство системы или ее компонента, заключающееся в приспособлении к предупреждению и обнаружению причин возникновения их отказов, повреждений и устранению их последствий путём проведения ремонта и технического обслуживания; Отказоустойчивость Свойство системы или ее компонента, заключающееся в обнаружении и ликвидации ошибочных состояний системы, без влияния на ее работоспособность. Существуют различные методы оценки надежности систем, среди них Метод, основанный на цепях Маркова; Статистические методы; Метод Хетагурова; Методы внесения неисправностей. Первые два метода – теоретико-математические методы, применимость которых с каждым годом ухудшается из-за ряда причин [16]: Узкие рамки применимости каждого конкретного метода; Огромное число не всегда строго обоснованных допущений; Упрощённое описание вычислительной системы; Не учитывается динамика функционирования программного обеспечения; Невозможность получения дополнительной информации об отказах, возникающих в системе; Для метода Хетагурова необходим экземпляр системы. Этот экземпляр работает до тех пор, пока не произойдет два отказа в данной системе. Ожидание этих отказов может занять достаточно много времени. В статистических методах тоже необходимо обладать разного рода статистикой, например, частотой возникновения отказов в системе, а для того, чтобы ее получить также необходимо продолжительное время ожидать эти отказы. Методы, основанные на построении математической модели системы, также малопригодны. Построить модель системы становится сложно из-за усложнения самих систем и связей между компонентами. Если модель построить удаётся, то получить аналитическое решение зачастую невозможно. Метод внесения неисправностей хорош тем, что не требует никаких лишних ограничений и большого периода времени для получения оценки надежности систем. Это современный практический метод, применяющийся сейчас для оценки надежности многих систем различного профиля [27]. Главной идеей методов внесения неисправностей для оценки надежности вычислительных систем является внесение неисправностей в компоненты системы с целью анализа, каким образом влияет та или иная неисправность на систему, приводит ли она к ошибке или нет, а также устраняется ли возникшая ошибка из системы. Таким образом, оценивается способность системы обнаруживать и устранять те или иные ошибки. Также необходимо отметить, что метод внесения неисправностей может применяться не только для оценки надежности системы, но и для проверки того, что система 9 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ отказоустойчива на определённом наборе неисправностей. Это нужно для того, чтобы проверить конкретную систему во всех критических ситуациях и убедиться, что система при них ведет себя корректно. Из-за ряда перечисленных выше причин возникает идея использования метода внесения неисправностей для оценки надежности вычислительных систем реального времени. На этапе проектирования вычислительной системы активно применяется имитационное моделирование для решения таких задач как [16]: Прогнозирование производительности системы с последующим анализом её структуры; Разработка и отладка распределённых программ на детальной модели аппаратуры; Проверка логических свойств параллельных алгоритмов на основе одного и того же описания системы; Оптимизация структуры вычислительной системы по заданному критерию; Поскольку на этом этапе создаётся модель, полностью учитывающая структуру разрабатываемой вычислительной системы, а также программную и аппаратную составляющие этой системы, то возникает идея использования данной имитационной модели для оценки надёжности вычислительной системы. Таким образом, для оценки надежности вычислительных систем реального времени будем заменять эти системы имитационными моделями, и, исследуя их, получать характеристики надежности самой системы. Тем самым, одновременно с проектированием появляется возможность оценки надежности будущей системы. Но, к сожалению, применить без модификации метод внесения неисправностей для оценки надежности вычислительных систем реального времени, представленных имитационными моделями, невозможно в силу ряда причин, среди которых главная особенность моделей – моделирование программой аппаратуры. Поэтому логично попытаться адаптировать его для имитационных моделей. При оценке надежности вычислительных систем реального времени, представленных имитационными моделями, будем вносить в модель неисправности, возможные в проектируемой системе, и отслеживать ее поведение на этом наборе неисправностей. Таким образом, можно оценить надежность системы на всех возможных в проектируемой системе наборах неисправностей, предполагая, что средства отказоустойчивости (то есть обнаружения и устранения ошибок) уже внесены в модель. Применять метод внесения неисправностей для имитационных моделей возможно двумя способами: Ручное внесение всех возможных наборов неисправностей в имитационную модель; Автоматическое внесение неисправностей в модель с помощью специального программного средства. Адаптировать метод внесения неисправностей для имитационных моделей решено на примере моделей, разработанных в среде моделирования ДИАНА. Среда ДИАНА представляет собой интегрированную среду для имитационного моделирования и анализа функционирования вычислительных систем. Из-за необходимости использования для оценки надежности существующих моделей и представления исходной модели в виде, удобном для анализа и изменения, решено разработать автоматическое средство внесения неисправностей и интегрировать его с транслятором ММ-языка (mmt) среды моделирования ДИАНА. 10 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 2 Постановка задачи Адаптировать и реализовать метод внесения неисправностей для оценки надёжности вычислительных систем реального времени с использованием имитационного моделирования. В рамках решения этой задачи требовалось рассмотреть следующие подзадачи: Изучить современные методы обеспечения надежности и методы внесения неисправностей; Составить обзор методов внесения неисправностей и оценить их характеристики и применимость для имитационных моделей среды моделирования ДИАНА; Сделать обзор существующих средств внесения неисправностей и оценить их применимость к поставленной задаче; Рассмотреть возможные варианты применения методов внесения неисправностей к имитационным моделям вычислительных систем реального времени среды ДИАНА (до компиляции или времени выполнения) и выбрать наиболее предпочтительный из них; Адаптировать выбранный метод внесения неисправностей для имитационных моделей среды моделирования ДИАНА; Реализовать выбранный подход и встроить его в транслятор ММ-языка среды ДИАНА в язык Си++. 11 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 3 Обзор современных методов обеспечения надежности 3.1 Основные понятия Для рассмотрения методов обеспечения надежности вычислительных систем реального времени предварительно необходимо ввести некоторые основные понятия, в том числе понятия неисправности, ошибки и отказа. Будем рассматривать систему как набор программных и аппаратных компонентов, предоставляющих интерфейс пользователю. Тогда под неисправностью в системе будем понимать некий дефект в программе или аппаратуре, который в определенных случаях может помешать эксплуатировать систему согласно ее спецификации. Мы говорим, что в какой-то момент времени в системе произошла ошибка, если в этот момент времени состояние системы отличается от ожидаемого. Говорят, что в системе произошел отказ, если она не обеспечивает того поведения и функциональности, которого можно было ожидать от нее заранее, то есть, результат работы системы на каких-то входных данных отличается от ожидаемого по спецификации [20]. Необходимо разобраться, в каких состояниях может находиться система при наличии в ней неисправности. Следующая схема демонстрирует все ситуации, к которым может привести неисправность в системе (Рисунок 1): Рисунок 1. Влияние неисправности на функционирование системы. Таким образом, возможны три варианта: Неисправность не проявится во время функционирования системы (1); Неисправность в системе приведет к ошибке, которая затем будет обнаружена и устранена (2)-(3); Неисправность в системе приведет к ошибке, которая, в свою очередь, вызовет отказ в системе (2)-(4). Для наглядности стоит привести реальный жизненный пример, демонстрирующий сначала переход системы в ошибочное состояние, а затем ее отказ, то есть, фактически, переход (2)-(4). В октябре 1994 года доктор Томас Р. Найсли из Линчбергского колледжа описал отказ, который произошел у него в вычислениях при делении 1 на 824633702441 [21, 22]. При выполнении такой операции, расхождение получалось уже в девятом знаке после запятой. Таким образом, 12 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Неисправность Потеря пяти значений в аппаратно программируемом логическом массиве при выполнении аппаратно реализованного алгоритма деления; Ошибка Неточный результат деления при использовании одного или более из пяти потерянных значений из аппаратно программируемого логического массива. Отказ Проявляется при вычислениях с использованием чисел с испорченными битами – так, например, операция A-((A/B)*B), где A = 5505001, а B = 294911, дает в качестве результата не 0, а 192. Аналогично на этом примере можно показать переход (1), так если при делении не использовались потерянные значения из аппаратно программируемого логического массива, то неисправность остается латентной. 3.2 Классификация неисправностей В литературе [23, 24, 26, 27, 30] существуют различные классификации неисправностей. Неисправности обычно классифицируются по следующим критериям: По принципу возникновения; По типу вызванного отказа; По месту расположения; По причине появления; По масштабности воздействия на систему. Наиболее общей является классификация, приведенная в [23]. Согласно этой классификации, неисправности могут быть следующих типов: Проектные; В класс проектных неисправностей (Рисунок 2, №1-4) входят неисправности, внесенные человеком на этапе проектирования системы, все такие неисправности являются постоянными. Неисправности типа №1 - недоработки разработчиков при проектировании программного обеспечения (например, неправильная реализация программы по спецификации), примерами таких неисправностей могут служить ранее описанные неисправности в системах AT&T и Patriot. Неисправности типов №2-3 - умеренное искажение программных или аппаратных свойств системы одним из разработчиков. Неисправности типа №4 – недоработки разработчиков при проектировании аппаратуры, например, ранее описанная неисправность в процессоре Pentium. Физические; В класс физических неисправностей (Рисунок 3, №3-12) входят неисправности, возникшие в аппаратуре. Неисправности типа №5 – дефекты при производстве аппаратуры, например, в серии жестких дисков Fujitsu существовала неисправность, которая приводила к отказу диска при определенном сроке использования и соотношении влажности и температуры помещения, в котором он находился. Неисправности типов №6-7 – неисправности, возникающие из-за износа аппаратуры, деградации ее свойств, например, при состаривании жесткого диска система S.M.A.R.T. сообщает о необходимости его замены. Неисправности типов №8-10 – неисправности, возникающие из-за электромагнитных помех, препятствующих нормальному функционированию аппаратуры, например магнит, поднесённый к жесткому диску. 13 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 2. Классификация неисправностей. Проектные неисправности. 14 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 3. Классификация неисправностей. Физические неисправности. 15 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 4. Классификация неисправностей. Неисправности при взаимодействии. 16 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Неисправности при взаимодействии. В класс неисправностей при взаимодействии (Рисунок 4, №8-15) входят неисправности, возникшие на этапе функционирования системы и внесенные в систему извне. Неисправности типов №11-14 – неисправности, возникающие из-за атак на систему, например, троянских программ, внесенных в систему. Неисправности типа №15 – неисправности, возникшие из-за неправильно введенных данных пользователем или администратором системы. Забегая вперед, необходимо сказать, что, несмотря на то, что такая классификация общепринята, она неудобна для применения метода внесения неисправностей оценки надежности вычислительных систем реального времени с использованием имитационного моделирования. По этой причине была введена новая классификация неисправностей по типу вызываемого отказа, учитывающая специфику моделей: Неисправности, вызывающие отказы компонентов системы; Неисправности, вызывающие отказы связи между компонентами системы; Неисправности, приводящие к искажениям при передаче данных между компонентами системы; Неисправности, приводящие к искажению данных внутри компонентов системы; Неисправности, приводящие к изменению семантики работы компонентов системы. 3.3 Методы повышения надежности На разных этапах функционирования системы существуют различные методы повышения надежности [24]: Методы предотвращения неисправностей Применяются на этапе проектирования системы. Эти методы используют инструменты и механизмы, с помощью которых минимизируется вероятность появления неисправностей. Среди этих инструментов – методики проектирования, верификации и аттестации, а также различные методы моделирования и прогона. Методы устранения неисправностей Применяются на этапе реализации системы. Эти методы используют различные верификационные и тестовые методики для обнаружения и устранения неисправностей. Среди этих методик – покомпонентное тестирование, тестирование взаимодействия компонентов системы, регрессионное тестирование (от более сложных тестов к более простым). Эти методы естественно более дорогие, нежели методы предотвращения неисправностей. Методы отказоустойчивости Применяются на этапе функционирования системы. Несмотря на все усилия методов предотвращения и устранения неисправностей, в любой системе (например, любой операционной системе) остаются неисправности. Одним из важнейших условий работы любой системы является обладание этой системой качественных методов отказоустойчивости. Сюда относятся средства обнаружения и диагностического тестирования, изоляции и маскировки, а также корректирования и устранения ошибок. Методы уклонения от неисправностей Применяются тоже на этапе функционирования системы. При работе системы можно проследить за поведением этой системы, и если ее поведение отличается от нормального, то даже если оно отвечает спецификации, используются методы реконфигурации системы или ее компонентов с целью уменьшения воздействия 17 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ этого незапланированного поведения на систему и ее компоненты. Это и есть методы уклонения от неисправностей. Как уже говорилось ранее, главной составляющей надежности для вычислительных систем реального времени является отказоустойчивость, поэтому нас особо интересуют методы отказоустойчивости. Рассмотрим основные методы отказоустойчивости и ошибки, с которыми помогают бороться данные методы. В обзоре методов отказоустойчивости особо отметим применимость каждого метода для вычислительных систем реального времени. 3.4 Методы отказоустойчивости 3.4.1 Средства управления резервированием Методы отказоустойчивости часто называют средствами управления резервированием. Резервирование – предоставление системе дополнительных функциональных возможностей или ресурсов, избыточных для идеальной системы и позволяющих системе предотвратить отказ [24]. Для того чтобы система была отказоустойчивой, необходимо, чтобы она обладала резервированием, но это не достаточное условие отказоустойчивости. Средства управления резервированием должны конфигурировать исправные компоненты таким образом, чтобы избежать отказа системы и получить правильный результат работы системы. Средства управления резервированием включают в себя следующие механизмы [24]: Обнаружение ошибок Установление факта возникновения ошибки в системе; Диагностическое тестирование ошибок Локализация компонента, в котором произошла ошибка, а также выяснение причины ошибки; Изоляция ошибок Предотвращение разрушающего действия ошибки на систему, то есть перевод действия ошибки в русло, которое не может привести к отказу системы; Маскировка ошибок Проверка того, что система оперирует только корректными значениями и в ошибочном состоянии находится только компонент; Корректирование ошибок Формирование или исправление результата работы компонента; Устранение ошибок Ликвидация ошибок из системы. 3.4.2 Организация резервирования Существуют различные подходы к резервированию, в зависимости от которых механизмы, описанные выше, используют те или иные действия [24]: Программное резервирование Пространственное резервирование Резервирование отдельных программных функций или компонентов. Если какой-либо программный компонент подвергается ошибке, то его функции начинает выполнять альтернативный данному компонент с идентичной функциональностью. Эффективно при статических неисправностях. Временное резервирование Существует два идентичных подхода к временному резервированию: функциональный сдвиг во времени и информационный сдвиг во времени. В первом случае имеется в виду возможность перезапуска той или иной функции системы с сохраненными для нее входными данными через 18 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ некоторое время после ее первого запуска. Таким образом, если во время первого запуска присутствовала динамическая неисправность, то при перезапуске функция выполнится правильно. Во втором случае имеется в виду возможность проверки информации через некоторое время, во время которой все нежелаемые ее изменения можно исправить. Аппаратное резервирование Кодирование Кодирование - один из главных механизмов отказоустойчивости. Оно используется для подтверждения корректной передачи данных от одного компонента системы к другому, или проверки правильности выполнения какой-либо функции. Пространственное резервирование Резервирование отдельных копий ресурсов или компонентов. Если какойлибо компонент подвергается ошибке, то он заменяется на резервный, либо система переконфигурируется таким образом, что функции отказавшего компонента перераспределяются между корректными. Эффективно при статических неисправностях. Общие подходы Организация глобального времени Очень многие механизмы отказоустойчивости, включая пространственное и временное резервирование, построены на точном времени. Считается, что ни одно аппаратное свойство не оказывает такого влияния на механизмы отказоустойчивости, как часы. Поэтому если источник времени откажет, то все эти механизмы окажутся недейственными. Поэтому одним из первых решений при разработке отказоустойчивой системы должно быть создание отказоустойчивого временного сервиса. Если его нет, то для поддержки некого модельного времени приходится придумывать сложные асинхронные протоколы, зависящие от степени выполнения различных вычислений. Выделение изолированных областей Для того чтобы предотвратить влияние неисправностей в одном из компонентов системы на другие, система разбивается на изолированные области таким образом, чтобы эти области либо вовсе не имели связей между собой, либо имели их, но в малом количестве. Таким образом, становится проще следить за движением сообщений по системе - необходимо проверять лишь сообщения между областями - а также упрощается локализация неисправностей. Предотвращение отказов в разделяемых компонентах Зачастую к отказу системы приводит отказ в одном из ее компонентов, влияющих на работу преимущественного большинства других ее компонентов – например, отказ в разделяемом ресурсе. Поэтому при резервировании особое внимание необходимо уделить именно таким компонентам. 3.4.3 Механизмы обнаружения ошибок Для обнаружения ошибок применяются следующие подходы: Контрольные тесты Отказоустойчивые алгоритмы Проверки Диагностическое тестирование 19 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 3.4.3.1 Контрольные тесты Идея контрольных тестов заключается в следующем: программа или подпрограмма выполняется, а результат подается на вход контрольному тесту. Если тест проходит правильно, то система продолжает работу по спецификации, если же нет, то, значит, возникла ошибка. Контрольные тесты не могут проверить, где возникла ошибка, или какая ошибка произошла, они лишь сообщают, что произошла ошибка. Также они создают барьер для перехода ошибки в другие компоненты, так как пока программа не выполнится корректно, система не производит каких-либо действий. Если же через определенное время эта программа не пройдет контрольный тест, то в компоненте, содержащем эту программу, произойдет отказ, а система сможет продолжить работу (если это возможно) без него, но, не подвергнувшись ошибке компонента. Контрольный тест маскирует неверный результат работы программы, так как ждет пока эта программа или программа, альтернативная данной не выполнится корректно (Рисунок 5). Рисунок 5. Контрольный тест. 3.4.3.2 Отказоустойчивые алгоритмы Отказоустойчивые алгоритмы – альтернатива контрольным тестам. Идея заключается в следующем: пусть источником неисправности является процессор, на разных процессорах выполняется одна и та же программа. Тогда после получения результатов работы программы на каждом из процессоров, они подаются на вход отказоустойчивым алгоритмам, среди которых используются алгоритмы голосования, согласования, приблизительного согласия, переименования и другие. Наиболее используемыми являются отказоустойчивый алгоритм попарного тестирования и голосования. Изоляция ошибки происходит следующим образом: значение, полученное на отказавшем процессоре, игнорируется, а система переконфигурируется (Рисунок 6, Рисунок 7). Более подробно отказоустойчивые алгоритмы рассматриваются в [25]. 20 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 6. Отказоустойчивые алгоритмы. Попарное тестирование. Рисунок 7. Отказоустойчивые алгоритмы. Голосование. 3.4.3.3 Проверки Кроме предыдущих двух механизмов для обнаружения ошибок используются различные проверки [28]: Временные Проверка времени работы программы со временем, указанным на работу этой программы в спецификации. Могут использоваться, если в спецификации указаны ограничения на время выполнения той или иной программы; Кодовые Как было сказано ранее, кодирование – один из основных механизмов аппаратного резервирования. Однако многие аппаратные методы кодирования подходят и для программного обеспечения. Примером может служить проверка контрольных сумм 21 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 3.4.3.4 перед выполнением программы и после него. Также часто используются коды, исправляющие ошибки, - например, коды Хэмминга; Реверсные Если обратная задача к решенной программой выполняется более просто, то для проверки решается обратная задача, это и есть реверсная проверка. Примером может служить решение системы линейных уравнений, а затем подстановка полученного решения в исходную задачу для проверки правильности выполнения программы; Семантические Проверка данных, с которыми оперирует программа на семантику, например, интервал изменяемых значений, частоту изменения. Могут использоваться в случае, если эти данные заложены в спецификации; Структурные Проверки, основанные на знаниях о структуре данных, например, структурах, классах, массивах, списках, деревьях. Примером может служить проверка числа элементов в списке. Диагностическое тестирование Для обнаружения ошибок в аппаратных компонентах может применяться метод диагностического тестирования. Его идея заключается в тестировании свойств аппаратного компонента в некоторые моменты времени, обычно периодически. Результатом диагностического тестирования является ответ на вопрос, есть ли ошибка в компоненте или нет. 3.4.4 Механизмы устранения ошибок Для устранения ошибок применяются следующие подходы: 3.4.4.1 Одноверсионное программирование Контрольная точка и перезапуск Парные прогоны Многоверсионное программирование Восстановление блоками N-версионное программирование N-самотестируемое программирование Общие подходы устранения ошибок в аппаратных компонентах Резервирование компонентов Переконфигурирование системы Одноверсионное программирование Одноверсионное программирование – это стиль программирования, при котором по спецификации создается ровно одна версия программы. В таких случаях применяются следующие методы устранения ошибок [26]: Контрольная точка и перезапуск Программе на вход подается некое входное значение, а далее, во время выполнения, она через определенные интервалы времени создает контрольные точки и проверяет, корректны ли вычисления. Если же на каком-то этапе вычисления становятся некорректными, то программа возвращается к предыдущей контрольной точке и продолжает вычисления с нее (Рисунок 8). Данный метод эффективен для устранения временных неисправностей (Рисунок 2, Рисунок 3, Рисунок 4), 22 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ поскольку при ошибках, вызванных такими неисправностями, программа будет каждый раз возвращаться к последней контрольной точке до тех пор, пока неисправность не исчезнет, тем самым ошибка будет устранена. Рисунок 8. Контрольная точка и перезапуск. Парные прогоны Этот метод – усовершенствование метода контрольной точки и перезапуска. Пусть есть две идентичные версии программы, запускаемой на двух разных процессорах. Тогда на основном процессоре программа выполняется, и там же создаются контрольные точки и передаются вторичному процессору до тех пор, пока не обнаруживается ошибка. После обнаружения ошибки вторичный процессор загружает последнюю контрольную точку и берет на себя роль первичного процессора (Рисунок 9). Данный метод эффективен для устранения временных неисправностей (по тем же причинам, что и в предыдущем методе) и постоянных в аппаратуре (Рисунок 2, Рисунок 3, Рисунок 4), поскольку, в случае ошибки, вызванной постоянной неисправностью первичного процессора, программа будет выполняться с последней контрольной точки на вторичном процессоре, тем самым ошибка будет устранена. Рисунок 9. Парные прогоны. 23 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Однако в силу специфики вычислительных систем реального времени, описанные методы устранения ошибок и одноверсионное программирование в целом не эффективны в них, и практически не используются. 3.4.4.2 Многоверсионное программирование. Многоверсионное программирование – стиль программирования, при котором по единой спецификации независимо создаются несколько различных версий программы. В таком случае применяются следующие методы устранения ошибок [26]: N-версионное программирование Рисунок 10. N-версионное программирование. Это самый основной метод многоверсионного программирования, в котором запускаются N версий программы, а затем с помощью алгоритма выбора, который получает на вход результаты выполнения всех версий программы, получает результирующее выходное значение. Здесь основная нагрузка ложится на алгоритм выбора. В качестве такого алгоритма можно принять один из отказоустойчивых алгоритмов, описанных в [9] (Рисунок 10). Данный метод эффективен для устранения неисправностей в программном обеспечении (Рисунок 2, Рисунок 3, Рисунок 4), поскольку различные временные и постоянные неисправности, вызывающие ошибки в разных версиях программы, будут устранены благодаря корректному выполнению остальных версий программ. Восстановление блоками Идея этого метода – использование N-версионного программирования и механизма контрольная точка и перезапуск. Запускается основная версия программы, которая выполняется и создает контрольные точки до тех пор, пока не обнаруживается ошибка. После обнаружения ошибки запускается альтернативная версия программы, которая начинает выполнения с последней контрольной точки, и.т.д. (Рисунок 11). Данный метод эффективен для устранения временных неисправностей и постоянных в программном обеспечении (Рисунок 2, Рисунок 3, Рисунок 4), так как он сочетает в себе достоинства методов N-версионного программирования и контрольная точка и перезапуск. 24 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 11. Восстановление блоками. N-самотестируемое программирование Рисунок 12. N-самотестируемое программирование. В зависимости от механизма обнаружения ошибки метод может быть двух типов – с использованием контрольных тестов и сравнений. Рассмотрим N-самотестируемое программирование с использованием контрольных тестов. В этом подходе собраны преимущества методов N-версионного программирования и восстановления блоками. Из единой спецификации независимо создаются различные версии программ и контрольных тестов. Главное отличие от метода восстановления блоками – использование для каждой версии программы своего контрольного теста. N версий программы запускаются последовательно или параллельно, затем каждая запущенная версия проходит контрольный тест, а затем в блоке логического выбора в качестве результирующего значения берется значение наивысшей из версий, 25 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ прошедшей контрольный тест (Рисунок 12). Аналогично предыдущему, данный метод эффективен для устранения временных неисправностей и постоянных в программном обеспечении (Рисунок 2, Рисунок 3, Рисунок 4). Стоит заметить, что именно многоверсионное программирование и методы устранения ошибок, описанные выше – основной инструмент обеспечения отказоустойчивости для вычислительных систем реального времени. Они активно применяются в различных системах реального времени, например, в бортовых вычислительных системах современных американских аэробусов [14]. 3.4.4.3 Общие подходы к устранению ошибок в аппаратных компонентах Для устранения ошибок в аппаратуре используют: Резервирование компонентов Использование в системе дополнительных компонентов, идентичных основным, которые используются в случае их отказа; Переконфигурирование системы Перераспределение функций отказавшего компонента между остальными компонентами системы. Во введении было дано определение надежности вычислительной системы как набора определенных свойств. Для вычислительных систем реального времени главным свойством является отказоустойчивость, поэтому для таких систем наиболее важно наличие адекватных средств отказоустойчивости, в том числе средств обнаружения и устранения ошибок. Соответственно, при исследовании надежности таких систем будем проверять адекватность того или иного набора средств отказоустойчивости на различных наборах неисправностей. 26 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 4 Методы внесения неисправностей 4.1 Суть методов внесения неисправностей Как уже говорилось ранее, главной задачей методов внесения неисправностей для оценки надежности системы является внесение неисправностей в компоненты системы с целью анализа того, каким образом влияет та или иная неисправность на систему, приводит ли она к ошибке или нет, а также способности системы восстанавливаться после тех или иных ошибок. Фактически методы внесения неисправностей тестируют средства отказоустойчивости системы, проверяя работу в первую очередь средств обнаружения и устранения ошибок системы. Таким образом, при исследовании надежности этими методами, полученные результаты могут привести как к фиксации отдельных ошибок и недочетов разработчиков системы, так и к нахождению недостатков в отказоустойчивости системы. Данный подход применялся, например, для исследования надежности телефонных сетей Ericsson [27] и распределенной вычислительной системы ESPRIT Delta-4 [28]. Как уже говорилось ранее, при оценке надежности систем возникает множество проблем, среди которых главными являются следующие: Сложность программных компонентов систем Количество строк кода программных компонентов сложных систем составляет миллионы строк кода, причем это число с каждым годом растет; «Покой» неисправностей Зачастую неисправность системы приводит к ошибке, а уж, тем более, и к отказу только при исключительных стрессовых ситуациях, поэтому для того, чтобы обнаружить неисправность приходится длительное время ожидать ее проявления; Разнообразие существующих систем В настоящее время существует огромное число систем с самой разнообразной архитектурой, что мешает создать универсальный подход к оценке надежности систем. Доступность ресурсов При исследовании надежности системы, разработчиками системы часто не предоставляется полная информация о системе – например, такая, как открытый код программных компонентов системы. Это нередко становится главной помехой при оценке. Методы внесения неисправностей позволяют преодолеть все эти проблемы – они являются универсальными методами для всех систем или, по крайней мере, адаптируемыми. Количество строк кода и разнообразие систем не влияет на пригодность этих методов. Они позволяют вносить в системы различные неисправности, с помощью которых можно проверить систему. «Покой» неисправностей тоже не актуален, поскольку эти методы позволяют вносить одновременно сразу несколько различных неисправностей, проверяя все критические состояния системы. Доступность ресурсов, конечно, является проблемой для этих методов, но некоторые разновидности этих методов позволяют вносить неисправности в систему, не владея исходным кодом систем [27]. Помимо этих плюсов, методы внесения неисправностей являются важнейшим техническим средством оценки надежности систем по следующим причинам: Исследование надежности системы путём ожидания ошибок или отказов системы очень долгая процедура, а путём внесения неисправностей мы получаем необходимый результат за короткое время и с дополнительной информацией; Без систематического тестирования и анализа сложно узнать, какие неисправности могут быть активированы и приведут к ошибке и отказу, а также какой из 27 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ компонентов вызовет этот отказ. Применяя же методы внесения неисправностей, тестирование становится намного более эффективным; Необходимо получение таких количественных характеристик, как время обнаружения отказа, процент обнаруженных неисправностей, а при помощи метода внесения неисправностей эти характеристики вычисляются просто. Минусом данных методов является невозможность подсчета всех желаемых количественных характеристик, например, среднего времени наработки на отказ. Эти характеристики могут быть получены при использовании, например, статистических методов. Еще одним минусом является невозможность создания универсального подхода для систем различных архитектур. 4.2 Классификация методов внесения неисправностей 4.2.1 Аппаратное внесение неисправностей Аппаратное внесение неисправностей – внесение неисправностей в аппаратные компоненты системы. Различают следующие стадии разработки аппаратуры: Разработка требований; Спецификация; Проектирование; Реализация; Обоснование; Производство. Методы аппаратного внесения неисправностей применимы на этапе реализации, обоснования и производства аппаратуры. На этапе реализации аппаратуры используются языки ее описания, такие как VHDL и Verylog [29]. Одним из вариантов применения методов внесения неисправностей является модификация кода на этих языках. Для этого используются два различных подхода – мутация и саботаж. Мутант – копия одного из оригинальных компонентов, чье поведение отличается от поведения оригинального компонента, саботер - дополнительный компонент, который располагается между двумя оригинальными компонентами и изменяет значения и время прохождения сигнала между ними. Другим вариантом применения методов внесения неисправностей на этапе реализации аппаратуры является имитация с использованием встроенных команд имитатора, манипулирующих с продолжительностью сигнала и значениями переменных. На этапе обоснования тоже используется имитация. На этапе производства возможны два варианта применения методов внесения неисправностей – контактное, когда неисправность физически вносится непосредственно в прототип аппаратуры, и бесконтактное, когда этот прототип подвергается действия извне, изменяющий его свойства на определенный промежуток времени или навсегда. Примером бесконтактного внесения неисправностей может быть ионно-радиационный метод, когда аппаратура облучается при помощи специальных инструментов [20]. 4.2.2 Программное внесение неисправностей Программное внесение неисправностей – это внесение неисправностей в программные компоненты системы. 28 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 4.2.2.1 Разделение программных компонентов. При исследовании отказоустойчивости программные компоненты системы часто делят на две части [27]: Обработчики сервисов Часть программных компонентов, отвечающая за поддержку сервисов и приложений для пользователя. Обработчики ошибок Часть программных компонентов, отвечающая за обработку возникающих ошибок. Таким образом, пока программные компоненты системы работают корректно, обработчики сервисов предоставляют пользователю различные сервисы и приложения, но как только возникает ошибка, обработчики сервисов приостанавливают свою работу и начинают работать обработчики ошибок, задачей которых является возвращение обработчиков сервисов к нормальной работе. Следовательно, тестирование отказоустойчивости программных компонентов системы – это тестирование обработчика ошибок. Более детально обработчик ошибок обеспечивает следующие возможности [27]: Обнаружение ошибок Обнаружение ошибок с помощью мониторинга, периодического тестирования или других автоматических процессов; Локализация ошибок Выделение исправного подмножества программных компонентов; Устранение ошибок Устранение ошибок из отказавших программных компонент с помощью механизмов перезапуска, отката, переконфигурации и.т.п.; Отчет об ошибках Посылка информационного сообщения на экран, в файл или операционной системе об ошибке, ее описании, месте обнаружения и реакции системы на эту ошибку. Разделяют два подхода к программному внесению неисправностей [27]: Низкоуровневое внесение неисправностей Эмулирование аппаратной неисправности для проверки реакции на это программного компонента системы. Сюда относятся изменение содержимого памяти, регистров процессора и.т.п. Высокоуровневое внесение неисправностей Изменение кода, повреждение данных, изменение состояний программного компонента системы. 4.2.2.2 Низкоуровневое внесение неисправностей. Существует два различных варианта низкоуровневого внесения неисправностей [30]: Внесение неисправностей до компиляции В этом подходе неисправность вносится в исходный код программных компонентов системы. С помощью этого подхода можно эмулировать аппаратные неисправности, в том числе неисправности при передаче данных. Этот подход не нуждается в каком-либо дополнительном программном обеспечении, не наносит никаких повреждений системе и очень прост. Однако у него есть ряд недостатков, среди которых основными являются невозможность внесения неисправностей во время работы системы и необходимость временных затрат для обеспечения возможности внесения неисправностей новых классов. Внесение неисправности при выполнении 29 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ В этом подходе подразумевается, что неисправности будут внесены в систему во время ее выполнения. Для того чтобы запустить средства внесения неисправностей во время выполнения системы, необходимо использовать один из следующих механизмов: Механизм тайм-аутов Средства внесения неисправностей запускаются при помощи таймера, то есть через определенное время после начала выполнения системы и.т.д. Механизм исключений Средства внесения неисправностей запускаются в том случае, когда в системе происходит то или иное событие, или выполнены некоторые условия. Механизм внесения кода Средства внесения неисправностей запускаются по выполнению некоторых инструкций, которые вносятся в систему динамически после ее запуска. 4.2.2.3 Высокоуровневое внесение неисправностей. Существуют два вида высокоуровневого внесения неисправностей [31]: Статическое внесение неисправностей В этом методе внесения неисправностей в исходный код программного компонента системы вносится небольшое изменение (например, знак “больше” в одном из условий заменяется на знак “больше или равно”), этот компонент называется мутантом. После этого система запускается, и после выполнения измененных инструкций сравниваются промежуточные результаты мутанта и оригинального компонента. Динамическое внесение неисправностей Предусловия и постусловия любой функции системы содержат логические ограничения, определяющие ожидаемое поведение системы. Предусловия – ограничения на возможные состояния системы до запуска этой функции, они должны быть истинны, чтобы гарантировать корректное выполнение функции. Постусловия – ограничения на соотношения между состояниями системы до начала выполнения функции и после ее завершения, а также между входными и выходными данными функции. Динамическое внесение неисправностей – изменение пред- и постусловий функции системы во время ее выполнения. 4.2.3 Сравнение аппаратного и программного внесения неисправностей И у программного, и у аппаратного метода внесения неисправностей есть свои плюсы и минусы. В целом, программное внесение неисправностей – более гибкий подход, нежели аппаратное внесение неисправностей. Аппаратное внесение неисправностей - дорогой и неудобный метод, причем с множеством недостатков, например, невозможно поменять ни одного бита во внутренних регистрах процессора. Однако и у программного внесения неисправностей есть свои недостатки, как, например, невозможность вносить неисправности в места, недостижимые для программного обеспечения, а также возможность повреждения программными средствами работающей среды в системе или даже изменения структуры оригинальных программных компонентов системы. Сравнивая программное внесение неисправностей до компиляции и при выполнении, необходимо отметить очевидную невозможность эмуляции ошибок передачи данных на шинах и ошибок ввода/вывода до компиляции, и более простую организацию ими повторного внесения неисправностей. В [27] приводится следующая сравнительная характеристика аппаратного и программного внесения неисправностей (Рисунок 13). 30 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 13. Сравнение программного и аппаратного внесения неисправностей. 4.3 Обзор существующих средств внесения неисправностей Существует множество автоматических средств внесения неисправностей, каждое из которых обладает разными возможностями и областью применения. Нам необходимо средство, которое должно: Автоматически вносить неисправности в любую модель среды моделирования ДИАНА с заранее внесенными средствами обеспечения надежности; Предоставлять пользователю возможность указания типов неисправностей, мест их внесения, вероятностей распределения неисправностей по компонентам различных типов. Рассмотрим наиболее популярные средства и возможность их адаптации к нашей задаче. 4.3.1 FIAT (Fault Injection-based Automated Testing) FIAT [32, 33] – это средство оценки надежности систем при помощи метода внесения неисправностей. Его главная задача – получить некую величину, характеризующую отказоустойчивость системы. FIAT позволяет пользователю определять место и время внесения неисправности, типы неисправностей, а также продолжительность нахождения 31 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ системы в ошибочном состоянии из-за каждой конкретной неисправности. FIAT умеет вносить в текст программного обеспечения и различные области памяти три класса неисправностей: Установка 1 в качестве значения восьми последовательных бит памяти; Установка 0 в качестве значения восьми последовательных бит памяти; Взаимный обмен значений двух соседних битов памяти. Все эти классы неисправностей – программная эмуляция аппаратных неисправностей. Для эмуляции FIAT может вносить неисправности в сообщения, процессы и программные счетчики. 4.3.2 DOCTOR (IntegrateD SOftware Fault InjeCTiOn EnviRonment) DOCTOR [34] – это также средство внесения неисправностей для оценки надежности вычислительных систем. Это средство позволяет эмулировать неисправности в процессоре, памяти и коммуникациях. DOCTOR использует более интересный метод внесения неисправностей, нежели простое изменение содержимого памяти. Повреждение памяти – мощный механизм внесения неисправностей, так как рано или поздно такие неисправности всегда приведут к отказу системы. Однако некоторые реальные неисправности могут так изменять содержимое памяти, что их сложно будет эмулировать обычным изменением содержимого памяти. Итак, неисправности в памяти, вносимые DOCTOR, могут быть следующие: Искажение одного бита памяти; Искажение двух последовательных битов памяти; Искажение байта памяти; Искажение нескольких последовательных байт памяти. Искажаются значения ячеек памяти следующим образом: В качестве их значений устанавливается 1; В качестве их значений устанавливается 0; Их значения изменяются произвольным образом. Кроме типа важна возможность указания места внесения неисправности в память. Оно может быть указано пользователем или может быть выбрано произвольно из области физической памяти. Это сделано по той причине, что иногда желательно, чтобы неисправность была внесена только в определенный участок памяти, такой как программный код или стек. Процессорные неисправности могут появляться в регистрах данных, адресных регистрах, регистрах управления, АЛУ. Точный эффект воздействия неисправности на систему в каждом из этих компонентов процессора зависит от ее архитектуры. Значит, чтобы эмулировать реальные неисправности более точно, необходима информация об архитектуре системы и специфике каждого из ее компонентов. Однако, в зависимости от конфигурации и архитектуры системы, возможности внесения неисправностей, эмулирующих неисправности различных аппаратных компонентов, сильно рознятся. Одним из возможных решений данной проблемы является внесение не неисправностей, а ошибок, вызываемых неисправностями, что не является целью рассмотрения данной работы. DOCTOR же эмулирует последовательности процессорных неисправностей на независимом от архитектуры уровне. Например, поток управления может быть поврежден из-за неисправностей в различных аппаратных компонентах, но вместо того, чтобы работать с каждым конкретным случаем, DOCTOR для эмуляции этой и других аппаратных неисправностей изменяет содержимое регистров процессора. 32 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ DOCTOR эмулирует следующие типы коммуникационных неисправностей: Потеря сообщений; Искажение сообщений; Дублирование сообщений; Задержка сообщений. Если у компонента есть несколько входных и выходных связей, например, при использовании топологии сети точка-точка, то для каждой связи может использоваться свой тип эмулируемой неисправности. Пользователь может указать для каждого компонента, какие из сообщений должны быть потеряны, изменены, дублированы или задержаны – только входящие, только исходящие или все. Также он может указать каким образом сообщения должны подвергаться неисправностям – произвольно, с некоторой вероятностью, или в конкретном промежутке времени, который он задаст сам. Аналогично эмуляции неисправностей в памяти, пользователь может задать принцип изменения сообщений искажения бита, двух битов или нескольких битов (байта или несколько байтов). Также можно указать, куда должна быть внесена ошибка – в тело сообщения или его заголовок. Для задерживаемых же сообщений можно установить либо определенное время задержки, либо определяемое уже во время работы системы по каким-либо условиям. И, наконец, пользователь может сам определять дополнительные коммуникационные неисправности. DOCTOR использует все три возможных механизма для внесения неисправностей во время выполнения системы, описанные в пункте 4.2.2.2 – для эмуляции неисправностей в памяти используется механизм тайм-аутов, для эмуляции временных процессорных неисправностей – механизм исключений, и, наконец, для эмуляции постоянных процессорных неисправностей – механизм внесения кода. 4.3.3 FERRARI (Fault and ERRor Automatic Real-time Injection) Данное средство [35] использует динамическое повреждение потока управления для внесения неисправностей, эмулирующих процессорные неисправности, а также неисправности в памяти и шинах. При этом FERRARI использует механизм исключений, которые возникают либо по прошествии определенного времени, либо когда некоторый указатель содержит ссылку на определенное место в памяти. Для эмуляции неисправностей FERRARI меняет содержимое регистров процессора или памяти, на которую ссылается указатель. При помощи FERRARI могут быть эмулированы те временные и постоянные неисправности, которые вызывают ошибки адресации и повреждения данных. Средство FERRARI предназначено для эмулирования большого числа аппаратных неисправностей и позволяет управлять временем появления, местом внесения, типом и длительностью нахождения неисправности в системе. Также FERRARI умеет измерять продолжительность пребывания системы в ошибочном состоянии и размах повреждений системы, поддерживает возможность автоматического управления большим числом экспериментов. Посредством экспериментов FERRARI показывает, что обнаружение ошибки сильно зависит от типа вводимой неисправности. Также при помощи этого средства было показано, что в некоторых местах (компонентах, отвечающих за ввод-вывод, различных системных библиотеках, и.т.п.) неисправности сложнее обнаружить из-за относительно редкого использования этих компонентов. Неисправности же в памяти чаще обнаружимы, так как исключения зачастую генерируются внутри циклов, а, значит, внесения неисправностей повторяются чаще. 4.3.4 FINE (Fault INjection and Monitoring Environment) Средство FINE [33, 36] используется не столько для исследования конечного результата, к которому привели неисправности в системе, сколько для оценки промежуточного воздействия неисправностей на систему и исследования распространения неисправностей по компонентам системы. FINE оценивает функциональность системы через 33 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ некоторое время после внесения в нее неисправности. FINE может эмулировать неисправности в памяти, процессорные неисправности, неисправности в коммуникациях и неисправности ввода-вывода. Также помимо аппаратных неисправностей, FINE может эмулировать программные неисправности: Неисправности при инициализации Эмулируются при помощи изменения команды инициализации – заменой значения операнда на неверное значение или удалением этой команды вовсе; Неисправности при присваивании Эмулируются при помощи изменения правого операнда команды присваивания – либо изменяется значение, которое присваивается переменной, либо имя переменной, значение которой присваивается данной; Неисправности при проверке логического выражения Примером проверки логического выражения может служить проверка возвращаемого функцией значения. Эмулируются заменой на неверные проверки логических выражений или удалением проверок вовсе; Неисправности при вызове функций Эмулируются заменой вызываемой функции на альтернативную ей. Эксперименты, проведенные при помощи FINE, выявили некоторые проблемы при внесении неисправностей: При внесении некоторых типов неисправностей, система может быть серьезно повреждена, если оператор вовремя не остановит продвижение неисправности; Для доведения процесса внесения неисправностей до полного автоматизма при гарантированной сохранности системы необходимо специальное аппаратное обеспечение; Некоторые вносимые неисправности обладают огромной временной задержкой, прежде чем приведут к ошибке. 4.3.5 FTAPE (Fault Tolerance And Performance Evaluator) FTAPE [37] используется для оценки отказоустойчивости вычислительных систем. Это средство позволяет эмулировать неисправности в регистрах процессора, памяти и дисковом пространстве. Неисправности вносятся изменением отдельных битов данных. Для внесения неисправностей используются драйвера, встроенные в ОС, так что не нужно никакой дополнительной аппаратуры или модификации кода системы для внесения в нее неисправностей. Синтетический генератор рабочей среды создает рабочую среду, определяющую процессорную активность, активность памяти и ввода-вывода. При помощи этой среды неисправности могут быть внесены по специальной стратегии, построенной на основе специфик рабочей среды – например, неисправности вносятся в тот компонент, который обладает наибольшей активностью в данный момент времени. 4.3.6 XCEPTION XCEPTION [38] использует для внесения неисправностей в продвинутые средства наблюдения за поведением системы, представленные во многих современных процессорах. XCEPTION использует собственные исключения процессора для внесения неисправностей, соответственно, неисправности вносятся обработчиком исключений. Это средство не нуждается в изменении программных компонентов системы и во внесении программных исключений. В XCEPTION неисправности вносятся при обращении системы к определенному физическому адресу, что позволяет повторять эксперименты. 34 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 4.3.7 C-Patrol C-Patrol [33] – это средство внесения программного кода, которое можно использовать для внесения неисправностей до компиляции. C-Patrol вносит в код программные проверки, такие как проверки инвариантности данных, предусловия, постусловия и.т.п. Предусловие – условие, накладываемое на состояние системы перед вызовом какой-либо функции, которое обязательно должно быть выполнено, чтобы гарантировать правильное выполнение функции. Постусловие – условие, описывающее связь состояния системы перед выполнением корректной функции и состояния системы после ее выполнения, оно должно быть выполнено для подтверждения правильности выполнения этой функции. При помощи этих проверок C-Patrol может ввести систему в состояние, которое может возникнуть из-за ряда аппаратных и программных неисправностей. C-Patrol – это препроцессор, который вносит проверки, написанные как специальные комментарии на языке C – комментарии, начинающиеся символами “/*?” и заканчивающиеся символами “?*/”. Если программный код системы подается сразу на вход компилятор языка C, то эти комментарии им игнорируются и никак не влияют на работу системы. Если же сначала код системы подается на вход препроцессору C-Patrol, то сначала C-Patrol транслирует эти комментарии в код на языке C в соответствии с директивами в этих комментариях. При помощи предусловий и постусловий с большой вероятностью проверяется правильность выполнения функции, поэтому если динамически изменить состояние системы так, чтобы предусловие или постусловие не выполнилось, то тем самым можно сэмулировать программные неисправности, приведенные в пункте 4.3.4 и некоторые аппаратные неисправности, такие как временные неисправности в памяти. Однако некоторые типы аппаратных неисправностей, такие как процессорные неисправности и неисправности в коммуникациях, и некоторые типы программных неисправностей C-Patrol сэмулировать не может. 4.3.8 Сравнение существующих средств внесения неисправностей Рисунок 14. Сравнение средств внесения неисправностей. 35 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ В качестве сравнительной характеристики средств неисправностей, описанных выше, приводится Рисунок 14. автоматического внесения 4.3.9 Актуальность создания средства внесения неисправностей Имитационная модель системы реального времени в среде моделирования ДИАНА состоит из программного описания аппаратной и программной части этой системы. Модель описывается на MM-языке, который транслируется в Cи++. Поэтому к средству внесения неисправностей выдвигаются следующие требования: Возможность внесения неисправностей в программные компоненты; Возможность применения средства, либо к моделям на ММ-языке, либо к оттранслированным в Cи++ моделям. Более подробно система ДИАНА и ММ-язык будут рассмотрены в пунктах 5.1.1 и 5.1.2. Средства DOCTOR, FERRARI, FIAT, FTAPE, XCEPTION, вносящие низкоуровневые неисправности, не подходят для решения поставленной задачи. Эти средства вносят неисправности в экземпляр вычислительной системы и эмулируют неисправности в её аппаратных компонентах, однако, как было сказано выше, аппаратные компоненты эмулируются программой, следовательно, методы внесения неисправностей, используемые этими средствами, такие как изменение значений регистров процессора и искажение памяти не применимы в данном случае. Рассмотрим возможность применения C-Patrol для внесения программных неисправностей на языке С. ММ-язык среды ДИАНА, как было сказано выше, транслируется в Cи++, а в Cи++ существует множество конструкций, отсутствующих в Cи, в том числе, классы. Многие конструкции ММ-языка среды моделирования ДИАНА транслируются в объекты различных классов на языке Си++. Значит, по этой причине CPatrol не применим для внесения неисправностей в имитационные модели среды ДИАНА. Теоретически применим для решения нашей задачи FINE, вносящий неисправности динамически. Однако FINE обладает ограничением на архитектуру исследуемых систем и закрыт для общего использования. Поскольку ни одно из найденных средств не удовлетворяет всем вышеперечисленным требованиям, то было принято решение о создании собственного средства. 4.4 Адаптация метода внесения неисправностей применительно к имитационным моделям среды ДИАНА Как уже было сказано ранее, методы внесения неисправностей активно применяются для оценки надёжности натурных программно-аппаратных средств, в том числе вычислительных систем реального времени, поэтому применить их без модификации для имитационных моделей вычислительных систем реального времени не представляется возможным. В классическом варианте исследования надёжности вычислительных систем реального времени мы исследуем отдельный экземпляр вычислительной системы. В случае имитационного моделирования вместо натурной модели исследуется программное описание аппаратной и программной компонент системы. Рассмотрим возможность адаптации различных вариантов данных методов для имитационных моделей среды ДИАНА. Как было показано в [39], адаптированные методы внесения неисправностей должны удовлетворять следующим требованиям. Во-первых, для оценки надёжности должны использоваться существующие модели, написанные, например, для оценки производительности, а не переписанные модели специально для оценки надежности; вовторых, характеристики надёжности, получаемые при использовании адаптированного 36 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ метода, должны давать меньшую погрешность по сравнению с реальными значениями, чем в существующих методах. Главными допущениями при адаптации методов внесения неисправностей являются условия наличия в оцениваемых моделях средств отказоустойчивости и известности наборов неисправностей, на которых необходимо оценивать надежность системы. Рассмотрим возможность адаптации метода внесения неисправностей до компиляции и при выполнении: До компиляции При применении метода внесения неисправностей до компиляции для оценки надёжности необходимо будет вводить изменения в модель на этапе описания модели. Эти изменения зависят от наборов неисправностей, на которых необходимо оценивать надежность вычислительных систем реального времени, соответствующих моделям. Изменения нужно вносить либо в описание аппаратуры в имитационной модели, либо в описание прикладной нагрузки. Данный метод достаточно трудоёмок с точки зрения написания кода и последующих компиляций и прогонов модели. Однако, при написании удобного средства автоматического внесения неисправностей в код модели с возможностью повторяемости, оценки надежности на различных наборах неисправностей, а также распределения процессов модели по типам компонентов моделируемой вычислительной системы, эти проблемы не столь значительны. При выполнении При применении метода внесения неисправностей при выполнении для оценки надёжности необходимо будет вносить неисправности на этапе прогона модели. При внесении неисправностей на этапе прогона моделей необходимо будет существенно изменять ту часть имитационной среды, которая отвечает собственно за имитацию описанных моделей. Главным недостатком данного подхода является необходимость изменения системы прогона моделей в случае добавления новых классов неисправностей. Несомненное достоинство этого подхода состоит в том, что для моделей, не требующих оценки надёжности, наличие каких-то функций в имитационной среде, связанных с оценкой надёжности, не будет заметно. Сравним возможные реализации средств автоматического внесения неисправностей при данных двух подходах. Сами подходы уже сравнивались в разделе 4.2.3, а результаты сравнения были приведены на Рисунок 13. Нетрудно видеть, что метод времени выполнения охватывает большее количество типов компонентов, в которые можно вставить неисправности. Однако так как мы работаем с имитационными моделями, то плюс данного метода нивелируется. Поэтому выбор метода зависит в первую очередь от сложности технической реализации. Необходимо отметить, что в первом случае средство должно будет получать на вход текст моделей, анализировать его и на выход подавать текст с внесенными неисправностями. В этом случае его можно будет встроить в транслятор ММ-языка среды ДИАНА - так как в этом случае можно будет работать с кодом на уровне дерева разбора, которое строится транслятором, что несколько облегчает задачу. При адаптации метода внесения неисправностей при выполнении необходимо будет встраивать средство автоматического внесения неисправностей в монитор среды ДИАНА, отвечающий за имитацию моделей, что намного более трудоемко первого подхода. В результате сравнения достоинств и недостатков обоих вариантов было принято решение об адаптации метода внесения неисправностей до компиляции для оценки надежности моделей вычислительных систем реального времени, представленных имитационными моделями и реализации программного средства, автоматически вносящего неисправности в имитационные модели среды моделирования ДИАНА. 37 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 5 Описание средства автоматического внесения неисправностей 5.1 Структура средства Данное программное средство реализует адаптированный для вычислительных систем реального времени метод автоматического внесения неисправностей до компиляции в имитационные модели среды моделирования ДИАНА. Оно позволяет вносить неисправности в имитационные модели вычислительных систем реального времени для дальнейшей оценки их надежности и нахождения различных характеристик надежности, таких как время обнаружения ошибки и “путь” неисправности. Данное средство применяется к имитационным моделям вычислительных систем реального времени, разработанным для оценки производительности этих систем, включающим в себя встроенные средства отказоустойчивости. 5.1.1 Среда моделирования ДИАНА Поскольку данное программное средство работает с имитационными моделями среды ДИАНА, необходимо дать краткое описание этой среды моделирования. Среда ДИАНА [40] представляет собой интегрированную среду для имитационного моделирования и анализа функционирования вычислительных систем, в том числе вычислительных систем реального времени. В основу среды ДИАНА положена математическая модель «модели с сообщениями», которая подробно описана в [41]. Операции приема и передачи сообщений являются примерами событий системы моделирования, которые влекут за собой изменение состояний инициировавших их компонентов модели. Модель распределённой вычислительной системы описывается на специализированном ММ-языке и состоит из следующих компонентов: Описание распределённого исполнителя Под распределенным исполнителем имеется в виду модель аппаратных средств и физических каналов между ними; Описание распределённой программы Под распределенной программой имеется в виду модель логической среды и прикладной программы; Описание привязки Под привязкой имеется в виду распределение процессов по исполнителям; Распределённая программа состоит из последовательных процессов и других распределённых программ. Последовательные процессы взаимодействуют друг с другом посредством передачи сообщений. Распределённый исполнитель состоит из последовательных исполнителей и распределённых исполнителей, соединённых между собой каналами. Последовательный исполнитель включает описание архитектуры, содержащей такие характеристики, как множество команд, стековую и регистровую структуру процессора. Привязка определяет распределение последовательных процессов по последовательным исполнителям, а также наложение межпрограммных взаимодействий на каналы исполнителей. 38 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 5.1.2 ММ-язык среды ДИАНА MM-язык среды моделирования ДИАНА представляет собой расширение языка Си средствами описания распределенной вычислительной системы [42]. Эти средства позволяют: Описывать программные и аппаратные компоненты системы, а также привязку программных компонентов к аппаратным; Описывать структуры сообщений, используемых при взаимодействии компонентов, Описывать внутреннее функционирование каждого процесса в системе и его взаимодействие с другими процессами. Основные свойства языка таковы [42]: Имеется возможность поэтапной детализации как описания структуры системы, так и описания отдельного процесса; Каждый объект или любую совокупность объектов языка можно описывать в отдельном файле и транслировать независимо от других файлов; Для записи алгоритмов используется понятный и привычный пользователю язык Си; Поддержка параметров компонентов модели, поддержка массивов буферов и подкомпонентов, в том числе массивов переменного (в частности, зависящего от параметров) размера. 5.1.3 Интеграция средства автоматического внесения неисправностей с транслятором ММ-языка среды ДИАНА в Си++ (mmt) Из-за необходимости использования для оценки надежности существующих моделей, а также по причине необходимого представления исходной модели в виде, удобном для анализа и изменения модели, решено интегрировать автоматическое средство внесения неисправностей с транслятором ММ-языка (mmt) среды ДИАНА. mmt – транслятор MM-языка в Си++, преобразующий код моделей среды ДИАНА на ММ-языке в код на Си++. Состоит mmt из следующих основных компонент: Лексический анализатор; Синтаксический анализатор; Средство генерации кода. В качестве входных данных он получает модель на ММ-языке, которую он затем на этапе синтаксического анализа преобразует в более удобный для анализа и генерации С++ кода вид. На этом этапе строится синтаксическое дерево разбора – AST-дерево, представляющее всю модель или отдельные компоненты этой модели в виде набора AST вершин, каждая из которых имеет ссылку вправо и вниз. Более подробно AST деревья будут рассмотрены в пункте 5.1.4. На последнем этапе средство генерации кода проходит по этому дереву слева направо и ставит каждому узлу в соответствие Си++ код. Поскольку представление имитационных моделей, написанных на ММ-языке, в виде AST-дерева очень удобно для нашей задачи, будем использовать этот этап трансляции модели для своих целей. В первую очередь, для организации работы средства автоматического внесения неисправностей в модель необходимо полностью переделать средство генерации кода – нам необходимо в качестве результата получать код не на языке Си++, а опять же код на ММ-языке. 39 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ В результате проведенной работы добавлена возможность автоматического внесения неисправностей при трансляции кода моделей в Си++ при помощи нового ключа транслятора mmt: –f output_filename, где output_filename – имя выходного файла. 5.1.4 AST-деревья Как уже было сказано в предыдущем пункте, на этапе синтаксического анализа модели строится AST-дерево, представляющее всю модель или отдельные компоненты модели в виде набора AST-вершин (узлов), каждая из которых имеет ссылку вправо и вниз. Каждая такая вершина (узел) представляет собой экземпляр класса AST – наследованного от стандартного класса ASTBase, широко использующегося для построения разного рода синтаксических деревьев. Характеризуется же класс AST в первую очередь добавленными полями type, text и object. В поле type хранится тип текущего узла (например, «прототип процесса», «объявление переменной», и.т.д.), в поле text – имя узла (например, имя создаваемого компонента), а в поле object – некий объект, относящийся к узлу и содержащий в себе различные данные, необходимые для семантического анализа на этапе генерации кода. Данное программное средство для внесения неисправностей использует изменение первоначально построенного по коду модели AST-дерева, поэтому необходимо пояснить его структуру на примере (Рисунок 15). Рисунок 15. Пример AST-дерева Этот пример демонстрирует построение дерева по коду на ММ-языке. Здесь в виде кругов обозначены узлы AST-дерева, в которых сверху указано значение поля type, а снизу – значение поля text. Стрелки, исходящие из узлов, обозначают ссылки вправо и/или вниз. Необходимо отметить, что любая конструкция ММ-языка при построении дерева преобразуется к следующему виду: базовый узел конструкции, имеющий ссылку вниз на более простые элементы этой конструкции. Если же эти элементы тоже являются сложными, 40 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ то есть, не представимы одним узлом дерева, то также разбиваются на более простые и.т.д. При построении AST-дерева базовые узлы последовательных конструкций ММ-языка внутри одной зоны видимости соединяются ссылками вправо. При переходе же в новую зону видимости, создается узел с типом COMPOUD_STATEMENT и текстом «;», у которого есть ссылка вниз на базовый узел первой конструкции ММ-языка новой зоны видимости. В данном примере сначала анализируется оператор “if (i > 0)”, по нему генерируется базовый узел с типом «IF» и текстом «if», обозначающий блок условного оператора. Узел, на который указывает ссылка вниз, представляет собой блок логического выражения условного оператора, а ссылка вправо от данного узла – операторный блок внутри условного оператора. В случае, если в операторном блоке более одной команды, как в данном примере, то операторный блок начинается с узла с типом «COMPOUD_STATEMENT» и текстом «{», который содержит ссылку вниз на первую команду блока, остальные же команды связаны ссылками вправо, начиная с первой; иначе вместо этого узла строится базовый узел для той единственной команды. Если бы в операторе if присутствовала альтернатива else, то у базового узла операторного блока присутствовала бы ссылка вправо на конструкцию, соответствующую альтернативному блоку операторов, построенную аналогично операторному блоку. Для логического выражения “(i > 0)”, строится базовый узел с типом BINARY_OPERATION и текстом “>”, от которого ссылка вниз на узел, соответствующий переменной i, вправо от того – ссылка на узел, соответствующий константе 0. Как уже говорилось выше, от базового узла операторного блока отходит ссылка вниз на последовательность операторов этого блока, которые связаны ссылками вправо. Первый операнд – объявление msg-переменной m – представляет всего лишь один узел дерева – с типом MSG_VAR_DECLARATION и текстом “m”. Следующий операнд – присвоение msgпеременной m типа MESSAGE – имеет следующую структуру в дереве: базовым узлом является узел с типом EXPRESSION_STATEMENT и текстом “;”, от которого отходит ссылка вниз на узел типа MSG_CPY и текстом “=”, обозначающий собственно присваивание сообщению определенного типа; от этого узла снова идет ссылка вниз на узел с типом MESSAGE_VAR и текстом “m”, соответствующий msg-переменной, которой присваивается тип, от него – ссылка вправо на узел с типом MESSAGE_CONST и текстом “MESSAGE”, соответствующий присваиваемому типу. Следующему операнду, устанавливающему данному сообщению тип MESSAGE в качестве активного в данной области видимости, соответствует базовый узел с типом “ASSUME” и текстом “assume”, у которого ссылка вниз указывает на узел с типом MESSAGE_VAR и текстом “m”, соответствующий msgпеременной, которой присваивается тип, от которого, в свою очередь, отходит ссылка вправо на узел с типом MESSAGE_CONST и текстом “MESSAGE”, соответствующий присваиваемому этой переменной типу. Наконец, оператору ”m.delay = 50“ соответствует следующая структура: базовый узел с типом с типом EXPRESSION_STATEMENT и текстом “;”, от которого отходит ссылка вниз на узел с типом BINARY_OPERATION и текстом “=”, соответствующий операции присваивания, который, в свою очередь, имеет ссылку вниз на узел с типом MSG_FIELD_ACCESS и текстом “m”, отображающий осуществление доступа к полю сообщения m. Этот узел имеет ссылку вправо на узел с типом CONSTANT и текстом “50”, соответствующий значению, присваиваемому полю сообщения m, и вниз на узел с типом IDENTIFIER и текстом “delay”, соответствующий имени поля сообщения. 5.1.5 Архитектура средства Архитектура программного средства автоматического внесения неисправностей в имитационные модели среды моделирования ДИАНА выглядит следующим образом (Рисунок 16): 41 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 16. Архитектура программного средства Как видно из рисунка (Рисунок 16), программное средство состоит из следующих функциональных модулей: Модуль внесения кода для организации идентичных прогонов Данный модуль предназначен для преобразования исходной недетерминированной модели вычислительной системы к детерминированному частному случаю; Модуль поиска мест возможного внесения неисправностей Данный модуль предназначен для нахождения в AST-дереве узлов, соответствующих конструкциям ММ-языка, после которых можно вносить неисправности различных типов, а также узлов, которые необходимо изменить для организации идентичных прогонов; Модуль генерации кода на ММ-языке Данный модуль предназначен для генерации кода на ММ-языке по AST-дереву; Модуль обработки конфигурационного файла Данный модуль предназначен для обработки конфигурационного файла специализированного вида, содержащего информацию, необходимую для внесения неисправностей в модель; Библиотека неисправностей Библиотека неисправностей предназначена для внесения неисправностей различных типов, то есть, для изменения AST-дерева в зависимости от типа вносимой неисправности; Модуль сравнения трасс Данный модуль предназначен для сравнения результатов запуска двух моделей модели, полученной после внесения кода для организации идентичных прогонов, и модели, с внесенными неисправностями. Все функциональные модули, за исключением модуля сравнения трасс, интегрированы в mmt. Более подробно эти функциональные модули и схема работы программного средства будут рассмотрены в пункте 5.2. 42 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 5.2 Схема работы средства На вход данное программное средство получает: Код имитационной модели; Информацию об объектах, присутствующих в моделируемой вычислительной системе реального времени; Список наиболее возможных в этой системе неисправностей; Возможно, информацию о типах компонентов и распределение того или иного типа неисправностей по типам компонентам. В процессе же работы основная функциональность заключается в статическом внесении неисправностей указанных типов в имитационную модель. Схема работы средства представлена в виде трех основных шагов, повторяющихся в цикле, по завершению которого на основании результатов, полученных на каждой итерации этого цикла, вычисляется оценка надежности вычислительной системы реального времени (Рисунок 17). На первом шаге исходная модель подается на вход модулю внесения кода для организации идентичных прогонов. Этот модуль, используя модуль поиска мест возможного внесения неисправностей, вносит изменения в найденные конструкции AST-дерева и подает AST-дерево на вход модулю генерации кода на ММ-языке. Модуль же генерации кода на ММ-языке, в свою очередь, выдает модель, измененную для организации идентичных прогонов (Рисунок 18). Необходимо отметить, что измененное на этом шаге AST-дерево используется различными модулями на втором шаге. Рисунок 17. Схема работы средства автоматического внесения неисправностей 43 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 18. Схема работы средства автоматического внесения неисправностей. Шаг 1 На втором шаге сначала специальным модулем обрабатывается информация из конфигурационного файла, необходимая для внесения неисправностей в модель. Затем для каждого типа неисправности, указанного в конфигурационном файле, в измененном на первом шаге AST-дереве ищутся места возможного внесения неисправностей этого типа. После этого, учитывая другую информацию из конфигурационного файла, из полученного списка мест возможного внесения неисправностей выбирается необходимое количество мест внесения, и при помощи библиотеки неисправностей они вносятся в AST-дерево. Затем это дерево подается на вход модулю генерации кода на ММ-языке, который выдает модель на ММ-языке с внесенными неисправностями (Рисунок 19). На третьем шаге выполняется прогон имитационных моделей, полученных на предыдущих шагах, – исходной модели, преобразованной к детерминированному частному случаю для обеспечения идентичности прогонов двух ее экземпляров, и такой же детерминированной модели, но с внесенными в нее неисправностями. Трассы этих двух прогонов подаются на вход модулю сравнения трасс, которое получает в качестве результата оценку схожести трасс в процентах. Для этого модуля необходимо определить некую пороговую величину, при превышении которой можно сделать вывод об успешности работы средств отказоустойчивости по обнаружению и устранению ошибок, вызванных внесенными неисправностями, в противном случае – об отказе, возникшем в системе (Рисунок 20). В первом случае будем брать единицу в качестве результата эксперимента, во втором – ноль. Таким образом, при многократном применении данного средства с одинаковыми входными данными, усредняя результаты экспериментов, можно получить оценку надежности вычислительной системы реального времени, представленной исходной имитационной моделью среды ДИАНА. Средство реализовано на языке Си++, объем кода порядка 4000 строк. Корректность работы средства автоматического внесения неисправностей была проверена на ряде тестовых моделей. 44 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 19. Схема работы средства автоматического внесения неисправностей. Шаг 2 Рисунок 20. Схема работы средства автоматического внесения неисправностей. Шаг 3 5.2.1 Обеспечение идентичности прогонов При схеме работы программного средства автоматического внесения неисправностей, предложенной в пункте 5.2, для корректного сравнения трасс получившихся на первом и втором шагах моделей, необходимо обеспечить, чтобы модели были детерминированными. Под детерминированностью в данном случае понимается гарантия того, что при прогоне обеих моделей их трассы могут отличаться лишь из-за неисправностей, внесенных во вторую модель. Возможны две составляющих недетерминированности моделей – внутренняя и внешняя. Внутренняя составляющая – это используемые в моделях генераторы случайных 45 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ чисел, из-за которых при прогоне двух идентичных моделей их события могут отличаться. Например, если в модели присутствует условный оператор, значение логического выражения которого может изменяться в зависимости от полученных случайных величин, то при двух прогонах одной и той же модели поток управления может пойти по двум различным веткам этого условного оператора. Соответственно, и трассы прогонов будут отличаться друг от друга. Внешняя составляющая – это независимый от кода модели недетерминизм, возникающий из-за возможности обработки событий с одинаковым модельным временем в разной последовательности частью имитационной среды, отвечающей за выполнение моделей. Например, два одновременно пришедших сообщения при двух различных прогонах могут быть получены в разной последовательности, что приведет к изменению последовательности событий, и, соответственно, отличию трасс этих двух прогонов. Однако необходимо заметить, что монитор среды ДИАНА лишен внешнего недетерминизма, то есть, события с одинаковым модельным временем всегда будут обрабатываться в одинаковой (однако неизвестной до первого прогона модели) последовательности вне зависимости от количества прогонов. Тем самым, для обеспечения идентичности прогонов необходимо решить лишь проблему внутреннего недетерминизма. Для решения этой проблемы необходимо, чтобы генератор случайных чисел, используемый в модели, при каждом новом прогоне выдавал случайные числа в одной и той же последовательности. Для этого логично заменить параметр всех операторов srand(), устанавливающих новую последовательность случайных чисел, на некое постоянное число. Тем самым, при каждом новом прогоне случайные числа будут последовательно браться из одной и той же последовательности, и они никак не смогут повлиять на последовательность обработки событий при прогоне модели. Этой задачей и занимается модуль внесения кода для организации идентичных прогонов. Он ищет в AST-дереве узлы, соответствующие оператору srand(), при помощи модуля поиска возможных мест внесения неисправностей, а затем изменяет узлы, в которых хранится параметр этого оператора (Рисунок 21). Рисунок 21. Обеспечение идентичности прогонов 46 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 5.2.2 Библиотека неисправностей Исследуя различные модели вычислительных систем реального времени, такие как проект drTesy, система цифровой обработки сигналов, а также компоненты бортовой вычислительной системы, были сделаны два вывода: Классификация неисправностей, предложенная в [23], активно применяющаяся при анализе неисправностей в вычислительных системах реального времени, неудобна при анализе имитационных моделей из-за специфики моделирования. Поэтому для классификации неисправностей в имитационных моделях вычислительных систем реального времени была предложена другая классификация (см. пункт 3.2) по другому критерию – типу вызванного отказа, полностью покрывающая все возможные неисправности в вычислительных системах реального времени: Неисправности, вызывающие отказы компонентов системы Под отказом компонента в данном случае понимается некое событие, после которого компонент прекращает выполнять все функциональные действия и реагировать на запросы других компонентов. Этим классом неисправностей можно эмулировать любые неисправности №№ 1-15 из классификации, предложенной в [23] (Рисунок 2, Рисунок 3, Рисунок 4); Неисправности, вызывающие отказы связи между компонентами системы Под отказом связи между компонентами в данном случае понимается событие, после которого все запросы компонента-отправителя не доходят до компонента-адресата. Этот класс неисправностей соответствует неисправностям № 6-12 из классификации, предложенной в [23] (Рисунок 3, Рисунок 4); Неисправности, приводящие к искажениям при передаче данных между компонентами системы Под искажением при передаче данных понимается искажение данных передаваемых сообщений, изменение их приоритетов и размеров, а также задержка сообщений. Этот класс неисправностей соответствует неисправностям № 3-12 из классификации, предложенной в [23] (Рисунок 2, Рисунок 3, Рисунок 4); Неисправности, приводящие к искажению данных внутри компонентов системы Под искажением данных внутри компонентов понимается искажение памяти, приводящее к изменению информации, используемой компонентом. Этот класс неисправностей соответствует неисправностям № 1-15 из классификации, предложенной в [23] (Рисунок 2, Рисунок 3, Рисунок 4); Неисправности, приводящие к изменению семантики работы компонентов системы Под изменением семантики работы компонента понимается изменение функциональных действий компонента и структуры его работы. Этот класс неисправностей тоже соответствует неисправностям № 1-15 из классификации, предложенной в [23] (Рисунок 2, Рисунок 3, Рисунок 4), однако для исследования надежности внесение неисправностей данного класса неактуально по причине их крайней редкости; Вероятность появления неисправности того или иного класса в некотором компоненте системы сильно зависит от типа этого компонента. По этой причине все компоненты моделей вычислительных систем реального времени были условно разделены на четыре категории, от принадлежности к которым будет зависеть частота внесения неисправностей того или иного типа в данный компонент: Вычислители (процессоры) 47 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Этот тип компонентов наиболее интересно исследовать на неисправностях первого класса (отказы компонентов); Память (хранилище данных) Этот тип компонентов наиболее интересно исследовать на неисправностях четвертого класса (искажение данных внутри компонентов); Коммутационные среды Этот тип компонентов наиболее интересно исследовать на неисправностях второго и третьего классов (отказы связей и искажения при передаче данных); Программные компоненты Этот тип компонентов наиболее интересно исследовать на неисправностях первого и четвертого классов (отказы компонентов и искажение данных внутри компонентов). Также при исследовании этих систем была проанализирована возможность установления соответствий между классами неисправностей и кодом на ММ-языке, моделирующим соответствующие классы неисправностей. Рассмотрим различные варианты моделирования приведенных выше классов неисправностей: Неисправности, вызывающие отказы компонентов системы Для моделирования постоянного неисправности, вызывающей отказ компонента, то есть процесса имитационной модели на ММ-языке, необходимо в тело процесса внести оператор stop(). То есть, в AST-дерево модели необходимо внести узлы, соответствующие оператору stop(). На примере это выглядит следующим образом (Рисунок 22): Рисунок 22. Внесение постоянных неисправностей класса 1 В большинстве компонентов моделей для обеспечения постоянной работы компонента используются “основные” циклы типа while(true). По этой причине интересно исследовать механизмы отказоустойчивости системы при внесении неисправностей, приводящих к отказу компонентов системы, при достижении определенного значения счетчиком итераций основного цикла. Тем самым будут 48 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ моделироваться временные неисправности типа 1. Для этого необходимо в теле процесса объявить переменную с уникальным именем и инициализировать ее нулем. Затем в “основном” цикле необходимо увеличить значение этой переменной на единицу и сравнить ее значение с номером итерации цикла, при котором должен произойти отказ. В случае если это значение переменной достигнуто, то необходимо вызвать оператор stop(). На примере выглядит это следующим образом (Рисунок 23, Рисунок 24): Рисунок 23. Внесение временных неисправностей класса 1 (Часть 1) Рисунок 24. Внесение временных неисправностей класса 1 (Часть 2) Неисправности, вызывающие отказы связи между компонентами системы Моделировать неисправности, вызывающие отказы связи между компонентами системы (то есть, процессами модели системы), можно разными способами. Одним из способов является поиск операторов receive() в компоненте-получателе 49 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ сообщений и сброс сообщений, полученных от компонента-отправителя, то есть переход на новый оператор receive(). Однако в данном случае есть две проблемы: В ММ-языке к одному входному буферу процесса может быть подсоединено любое число выходных буферов, поэтому невозможно узнать, кто является отправителем сообщения, и, следовательно, может быть сброшено сообщение от другого отправителя. При получении сообщения это событие все равно занесется в трассу модели, что может серьезно осложнить работу модуля сравнения трасс и даже повлиять на его результат. По синтаксису MM-языка в сообщениях любых типов присутствует поле delay [42]. Другой способ моделирования данного класса неисправностей - это изменение поля delay перед отправкой сообщения в компоненте –отправителе. Данное поле задает задержку на доставку сообщения, поэтому если задать значение этого поля очень большим числом, например, MAX_INT или MAX_FLOAT, то сообщение не дойдет до компонента-получателя до окончания времени моделирования. Для моделирования постоянных неисправностей, вызывающих отказ связи будем изменять поле delay перед отправкой всех сообщений через соответствующий неисправной связи выходной буфер компонента-отправителя (Рисунок 25). Для моделирования временных неисправностей будем в начале тела компонента-отправителя определять целочисленную переменную с уникальным именем и инициализировать ее нулем. Затем аналогично изменять поле delay в случае, если эта переменная достигла определенного значения. Также в этом случае необходимо непосредственно перед отправкой сообщения увеличивать значение этой переменной на единицу (Рисунок 26). Рисунок 25. Внесение постоянных неисправностей класса 2 50 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 26. Внесение временных неисправностей класса 2 Неисправности, приводящие к искажениям при передаче данных между компонентами системы Для моделирования этого класса неисправностей необходимо непосредственно перед отправкой сообщения изменять поля этого сообщения. При изменении “базовых” полей сообщения (volume, prior, delay) будет изменяться логика доставки сообщения – соответственно, размер сообщения, его приоритет и задержка на доставку. Изменение же пользовательских полей сообщения может повлиять на логику работы процесса-получателя сообщения. Моделирование неисправностей данного класса организовано следующим образом (Рисунок 27): 51 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 27. Внесение неисправностей класса 3 Неисправности, приводящие к искажению данных внутри компонентов системы Моделирование неисправностей данного класса осуществляется изменением значений переменных и констант некоторого компонента. Для исследования работы средств отказоустойчивости системы наиболее интересно искажение значений тех переменных и констант, которые используются при вычислении условий циклов и операторов условного перехода (Рисунок 28), а также тех, которые используются при присвоении значений полям сообщения (Рисунок 29), так эти значения могут серьезно изменить логику работы компонентов. 52 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ Рисунок 28. Внесение неисправностей класса 4. Вариант 1 Рисунок 29. Внесение неисправностей класса 4. Вариант 2 53 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 5.2.3 Конфигурационный файл Для того, чтобы получить информацию об объектах, присутствующих в моделируемой вычислительной системе реального времени, список наиболее возможных в этой системе неисправностей, а также, возможно, информацию о типах компонентов и распределение того или иного типа неисправностей по типам компонентам, программному средству автоматического внесения неисправностей необходим модуль обработки конфигурационного файла. Конфигурационный файл имеет блочную структуру. Каждый блок начинается конструкцией [NAME], а заканчивается конструкцией [/NAME], где NAME – имя блока. Блоки могут быть вложены друг в друга. На верхнем уровне конфигурационного файла могут находиться пять основных блоков: Блок описания процессов имитационной модели, соответствующих компонентам моделируемой вычислительной системы реального времени В идеальном случае процессы имитационной модели вычислительной системы реального времени должны взаимно однозначно соответствовать компонентам самой моделируемой системы. Однако из-за специфики моделирования в среде ДИАНА, в имитационной модели вычислительной системы реального времени могут присутствовать процессы, предназначенные для организации логики работы моделируемой системы и не соответствующие ни одному из ее компонентов. Разумеется, вносить неисправности в такие процессы не имеет смысла, поэтому в конфигурационном файле для каждой имитационной модели нужно прописывать имена ее процессов, соответствующих компонентам моделируемой вычислительной системы реального времени. Это делается в данном блоке. Имя данного блока Processes. Внутри блока перечисляются имена процессов, каждый с новой строчки. Также после имени каждого процесса через запятую может быть указан тип этого процесса из классификации пункта 5.2.2 (1 – первый (процессор), 2 – второй (память), 3 – третий (коммутационная среда), 4 – четвертый (программный компонент)). В случае, если тип процесса не указан, то при обработке конфигурационного файла он будет проставлен произвольным образом. Если же в данном блоке не будет ни одного имени процесса, либо блок будет отсутствовать вовсе, то неисправности в модель вноситься не будут; Блок описания связей между процессами имитационной модели, соответствующих связям между компонентами моделируемой вычислительной системы реального времени По причине, аналогичной описанной в предыдущем случае, в имитационной модели вычислительной системы реального времени могут присутствовать связи между процессами, отсутствующие в самой системе. Поскольку в среде ДИАНА каждый выходной буфер процесса может быть связан лишь с одним входным буфером, то любой выходной буфер задает ровно одну связь между процессами. В данном блоке указываются все связи, присутствующие в моделируемой вычислительной системе реального времени. Имя данного блока - Links. Внутри него перечисляются все выходные буфера, соответствующие связям моделируемой вычислительной системы, в формате «ИмяПроцесса.ИмяБуфера», каждый с новой строчки. В случае, если в данном блоке не будет указана ни одна связь, или данный блок будет отсутствовать в конфигурационном файле, то в модель нельзя будет внести неисправности второго и третьего классов; Блок описания типов сообщений имитационной модели, соответствующих логическим типам взаимодействий компонентов моделируемой вычислительной системы реального времени Аналогично предыдущим двум случаям, в конфигурационном файле необходимо предоставить возможность указания типов сообщений, соответствующих типам 54 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ взаимодействий компонентов моделируемой вычислительной системы реального времени. Такая возможность предоставляется в данном блоке, имя которого Messages. Внутри него перечисляются типы сообщений, каждый с новой строки. Если не указано ни одного типа сообщения, или блок отсутствует, то в имитационную модель нельзя будет внести неисправности третьего класса; Блок распределения вероятностей внесения неисправностей различных классов в процессы разных типов Как было отмечено в пункте 5.2.2, вероятность появления неисправностей определенного класса в компоненте вычислительной системы реального времени сильно зависит от типа этого компонента. По этой причине логично предоставить возможность указания в конфигурационном файле этих вероятностей. Эта возможность предоставляется в данном блоке. Имя данного блока - Weights. Для указания вероятностей внесения неисправностей различных классов в компонент данного типа, внутри данного блока определяются блоки типов компонентов (например, 1 – имя блока компонента типа процессор). Внутри этих же блоков через запятую указываются вероятности внесения неисправностей четырех классов (в порядке возрастания класса неисправности, в процентах) в компонент данного типа. В сумме эти четыре вероятности должны давать 100%. В случае, если для какоголибо типа компонентов отсутствует распределение вероятностей, то они распределяются произвольным образом. Если же отсутствует весь блок, то неисправности распределяются произвольно для всех типов компонентов; Блок описания типов вносимых неисправностей В данном блоке описываются неисправности, вносимые в имитационную модель. Имя данного блока – Faults. Возможны два варианта внутренней структуры этого блока. В первом случае, внутри него указывается блок Amount, внутри которого, в свою очередь, указывается целое число, обозначающее количество вносимых неисправностей. Такая структура будет означать, что указанное количество неисправностей произвольных классов будет распределено по произвольным процессам. В этом случае блок Amount должен быть единственным внутренним блоком блока Faults. Во втором случае, внутри блока Faults должны быть указаны блоки, соответствующие классам неисправностей (блок с именем 1 – неисправности класса 1, и.т.д.). Если блок, соответствующий некоторому классу неисправностей отсутствует, то неисправности этого класса внесены в модель не будут. Внутри каждого блока, соответствующего классу неисправностей, должны быть указаны блоки процессов, в которые должны быть внесены неисправности. В качестве имени блока процесса используется имя процесса. В случае, если неисправности надо вносить в произвольные процессы, в качестве имени блока процесса указывается пустое имя ([] и [/]). Также для каждого блока процесса в зависимости от класса неисправности можно внутри указать следующие блоки: Для неисправностей класса 1 o Блок Amount Внутри этого блока указывается целое число, означающее количество вносимых неисправностей. В случае отсутствия данного блока, это количество устанавливается равным 1; o Блок SubTypes Этот блок содержит блоки подклассов неисправностей. Подкласс 1 означает внесение постоянных неисправностей первого класса, подкласс 2 – временных неисправностей первого класса. Внутри подкласса 2 необходимо указать номер итерации “основного” цикла, после которой должна возникнуть неисправность. В случае отсутствия этого блока, считается, что вносятся постоянные неисправности; 55 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ o Блок OpTypes В этом блоке через запятую указываются типы узлов AST-дерева, после которых нужно вносить неисправности, и после которых не нужно. Во втором случае перед типом узла ставится минус. Тип узла должен быть целочисленным числом, соответствующим значению именованной константы в перечислимом типе ANTLRTokenTypes. В случае отсутствия этого блока, считается, что ограничения на место внесения неисправностей данного блока процесса не наложены. Для неисправностей класса 2 o Блок Amount o Блок SubTypes Этот блок аналогичен блоку SubTypes для неисправностей класса 1, за исключением того, что в блоке подкласса 2 необходимо указать не итерацию “основного” цикла, а количество успешных отправок сообщений до возникновения неисправности. Для неисправностей класса 3 o Блок Amount o Блок SubTypes В данном блоке подкласс 1 означает внесение неисправностей в базовые поля сообщений (volume, prior, delay), а подкласс 2 – в пользовательские поля сообщений. Внутри блоков подклассов ничего не указывается. В случае, если блок не указан, то неисправности вносятся в произвольные поля сообщений; o Блок MsgTypes В данном блоке указываются блоки типов сообщений, в которые необходимо вносить неисправности. Имя каждого блока типа сообщения – название этого типа. Внутри него через запятую указываются имена полей этого типа, в которые можно вносить неисправности. В случае, если блок MsgTypes не указан, то неисправности вносятся в сообщения произвольных типов. Для неисправностей класса 4 o Блок Amount o Блок SubTypes В данном блоке подкласс 1 означает внесение неисправностей в переменные, использующиеся при вычислении условий циклов и операторов условного перехода, подкласс 2 – в переменные, использующиеся при вычислении значений полей сообщений. Внутри блоков подклассов ничего не указывается. В случае, если блок не указан, то неисправности вносятся в произвольные переменные; o Блок Variables В этом блоке указываются блоки переменных, в которые необходимо вносить неисправности. Имя блока переменной – это имя самой переменной. Внутри каждого блока переменной указывается значение этой переменной после внесения неисправности. В случае, если блок Variables не указан, то неисправности вносятся в произвольные переменные. 5.2.4 Поиск мест возможного внесения неисправностей Как было сказано в пункте 5.2.2, для внесения неисправностей в имитационные модели вычислительных систем реального времени, написанные на ММ-языке среды ДИАНА, необходимо изменять AST-дерево. Однако для того, чтобы изменять AST-дерево, 56 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ необходимо знать, в каком месте это необходимо делать. Определением возможных мест внесения неисправностей и занимается модуль поиска мест возможного внесения неисправностей. Работа средств отказоустойчивости вычислительных систем реального времени сильно зависит не только от класса вносимой неисправности, но и от места внесения этой неисправности. По этой причине было решено предоставить пользователю возможность описания различных ограничений для поиска мест внесения неисправностей всех классов в конфигурационном файле. Если ограничения для поиска мест внесения неисправностей для какого-либо класса неисправностей отсутствуют, то данный модуль должен найти все места, в которые можно внести неисправности данного класса. Модуль поиска неисправностей применяется для нахождения мест возможного внесения неисправностей любых типов, а также для поиска конструкций AST-дерева, требующих исправления для обеспечения идентичности прогонов. Тем самым этот модуль используется библиотекой неисправностей и модулем внесения кода для организации идентичных прогонов. При поиске конструкций AST-дерева, требующих исправления для обеспечения идентичности прогонов, данному модулю необходимо найти в AST-дереве все конструкции, соответствующие вызову функции srand() и передать места их расположения модулю внесения кода для организации идентичных прогонов. При поиске мест возможного внесения неисправностей, данный модуль должен пройти по конструкциям AST-дерева, соответствующим телам всех процессов имитационной модели и обнаружить все возможные места внесения неисправностей заданного класса с учетом ограничений, наложенных классом неисправностей и заданных в конфигурационном файле для данного класса неисправностей. Как было сказано в пункте 5.1.4, при построении AST-дерева базовые узлы последовательных конструкций ММ-языка внутри одной зоны видимости соединяются ссылками вправо, а при переходе же в новую зону видимости, создается узел с типом COMPOUD_STATEMENT и текстом «;», у которого есть ссылка вниз на базовый узел первой конструкции ММ-языка новой зоны видимости. По этой причине при поиске мест возможного внесения неисправностей данный модуль должен уметь проходить по узлам AST-дерева, соответствующим различным зонам видимости. Различные зоны видимости могут возникать при использовании следующих операторов ММ-языка: “if”, “do”, “while”, “for”, “switch”, “select”, “accept”, “foreach”, “complex”, “{”. По этой причине при поиске необходимо учитывать структуру этих операторов в виде конструкций AST-дерева. 5.2.5 Генерация кода на ММ-языке по AST-дереву Задачей модуля генерации кода на ММ-языке является преобразование AST-дерева в код на ММ-языке среды ДИАНА. При реализации этого модуля было принято решение взять за его основу модуль генерации кода на языке Си++, присутствующий в mmt, и адаптировать его для ММ-языка. Общая схема работы модуля генерации кода на языке Си++ такова: дерево проходится сверху вниз слева направо, и для каждой конструкции AST-дерева генерируется соответствующий ей код на языке Си++ путем вызова методов класса, соответствующего этой конструкции. Поэтому для адаптации модуля генерации кода на языке Си++ к нашей задаче в различные классы mmt, соответствующие всевозможным конструкциям AST-дерева, были добавлены новые методы по аналогии с реализацией средства оценки времени выполнения моделей и средства оценки производительности среды моделирования ДИАНА. Для реализации модуля генерации кода на языке Си++ разработчиками mmt был создан класс mmt_output_base, в котором присутствует метод outputAST(), отвечающий за обход дерева и дальнейшую генерацию по нему кода на языке Си++. Для организации генерации кода на ММ-языке, по аналогии с реализацией генерации кода на языке Си++, был 57 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ создан класс fta_output, наследуемый от базового класса mmt_output_base с аналогичным методом outputAST(), отвечающим за обход дерева и генерацию кода. 5.2.6 Средство сравнения трасс Задачей модуля сравнения трасс является оценка схожести трасс исходной детерминированной модели и модели с внесенными неисправностями с целью получения вывода об успешности работы средств отказоустойчивости по обнаружению и устранению неисправностей. В случае, если средства отказоустойчивости обнаружат и устранят внесенные неисправности, последовательности событий в этих трассах будут похожи (за исключением промежутка времени, необходимого на обнаружение и устранение неисправностей). По этой причине при создании данного модуля необходимо учесть, что наиболее важным фактором определения процента схожести трасс является близость последовательностей событий в них. В качестве модуля сравнения трасс было предложено использовать средство, разработанное в работе [43]. Данное средство вычисляет функцию расстояния между двумя входными трассами. Алгоритм вычисления функции расстояния состоит из двух основных этапов. На первом этапе трассы представляются в виде символьных строк, после чего рассчитывается длина их наибольшей общей подпоследовательности. На втором этапе создаются два массива, состоящие из времен возникновения событий в исходных трассах, вошедших в полученную подпоследовательность. Затем эти массивы подаются на вход алгоритму Dynamic Time Warping, который рассчитывает расстояние между ними с учетом возможных деформаций по времени (сжатие и растяжение). Итоговое значение функции расстояния вычисляется на основе длины наибольшей общей подпоследовательности и полученного расстояния между временными массивами. 58 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 6 Заключение В результате решения поставленной задачи Изучены современные методы обеспечения надежности, в рамках этой задачи: Изучены основные понятия теории надежности; Рассмотрены классификации неисправностей по разным критериям и дана классификация неисправностей применительно к задаче оценки надежностей вычислительных систем реального времени, представленных имитационными моделями; Исследованы методы повышения надежности, в том числе методы отказоустойчивости и их механизмы; Изучены методы внесения неисправностей для оценки надежности вычислительных систем реального времени, а также составлен их обзор; Составлен обзор существующих средств автоматического внесения неисправностей, а также оценена применимость этих средств для имитационных моделей среды ДИАНА; Рассмотрены возможные варианты адаптации методов внесения неисправностей к имитационным моделям вычислительных систем реального времени (до компиляции или времени выполнения) среды моделирования ДИАНА и выбран наиболее предпочтительный из них – метод до компиляции; Адаптирован метод внесения неисправностей до компиляции для имитационных моделей среды ДИАНА; Разработано, реализовано, а также встроено в транслятор ММ-языка среды ДИАНА в язык Си++ средство автоматического внесения неисправностей для оценки надежности вычислительных систем реального времени, представленных имитационными моделями среды моделирования ДИАНА. В качестве перспектив развития данной работы, можно отметить следующие задачи: Разработка и реализация специализированного средства сравнения трасс, основанного на знаниях о работе средств отказоустойчивости различных систем; Разработка алгоритма получения конфигурационного файла по дополнительной информации о вычислительной системе реального времени и по ее имитационной модели. 59 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 7 Литература 1 Lardner D. Babbage's calculating engine. // Edinburgh Review. 1834. Reprinted in Morrison P. and Morrison E. Charles Babbage and His Calculating Engine. Dover, UK: Dover Publications, 1961. 2 Avizienis A., Laprie J. C., Randell B. Dependability of computer systems: Fundamental concepts, terminology, and examples. // Technical Report. Toulouse, France: LAAS-CNRS, 2000. 3 Pierce W. H. Failure-Tolerant Computer Design. New York, New York, USA: Academic Press, 1965. 242 p. 4 Avizienis A. Design of fault-tolerant computers. // In Proc. 1967 Fall Joint Computer Conf., AFIPS Conf. Proc. Vol. 31. Washington, District Columbia, USA: Thompson Books, 1967. P. 733-743. 5 Morgan D. E., Avizienis A., Kopetz H., Laprie J. C., Costes A., Robinson A. S., Anderson T., Lee P. A. Special Session. Fundamental concepts of fault tolerance. // In Proc. 12th IEEE Int. Symp. on Fault Tolerant Computing (FTCS-12). Santa Monica, California, USA, 1982. P. 3-38. 6 Laprie J. C. Dependable computing and fault tolerance: concepts and terminology. // In Proc. 15th IEEE Int. Symp. on Fault Tolerant Computing (FTCS-15). Ann Arbor, Michigan, USA, 1985. P. 2-11. 7 Laprie J. C. Dependability: Basic Concepts and Terminology. Vienna, Austria: Springer-Verlag, 1992. 265 p. 8 Pullum L. L. Software Fault Tolerance Techniques and Implementation. Boston, Massachusetts, USA: Artech House, 2001. 343 p. 9 Neumann P. G. Atlantis Launch Delay. // The Risks Digest. 1989. 9. N 32. P. 2-3 [HTML] (http://catless.ncl.ac.uk/Risks/9.32.html#subj5.1). 10 Leveson N. Endeavor bug -- more details. // The Risks Digest. 1992. 13. N 57. P. 3-4 [HTML] (http://catless.ncl.ac.uk/Risks/13.57.html#subj4.1). 11 Neumann P. G. Computer Related Risks. Reading, Massachusetts, USA: Addison-Wesley, 1995. 384 p. 12 Neumann P. G. Cause of AT&T network failure. // The Risks Digest. 1990. 9. N 62. P. 2-3 [HTML] (http://catless.ncl.ac.uk/Risks/9.62.html#subj2.1). 13 Arnold D. N. Computer Arithmetic Tragedies. Patriot (http://www.ima.umn.edu/~arnold/455.f96/disasters.html). Missile Failure. [HTML] 14 Denning P. J. Computers Under Attack: Intruders, Worms, and Viruses. New York, New York, USA: ACM Press, 1990. 592 p. 15 Stankovic J. A. Real-time Computing. // Byte Magazine. 1992. 17. N 8. P. 155-160. 60 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 16 Волканов Д. Ю. Разработка метода исследования надёжности вычислительной системы, учитывающего динамику функционирования программного обеспечения с помощью имитационного моделирования. [DOC] (http://lvk.cs.msu.su/~dimawolf/diplom2001.doc). 17 ГОСТ 27.002-83. Надежность в технике. Термины и определения. Москва, 1984. 18 Лонгботтом Р. Надёжность вычислительных систем. Ленинград: Энергоатомиздат, 1985. 288 c. 19 Иыуду К. А. Надёжность, контроль и диагностика вычислительных машин и систем. Москва: Высшая Школа, 1989. 215 с. 20 Ammar H., Cukic B., Fuhrman C., Mili A. A Comparative Analysis of Hardware and Software Reliability Engineering. // Annals of Software Engineering. 2000. 10. N 1-4. P. 103-150. 21 Carlton M. Pentium Divide Bug FAQ. // Technical report. Santa Clara, California, USA: Intel Corporation, 1995. 22 Sharangpani H. E., Barton M. L. Statistical Analysis of Floating Point Flaw in the Pentium Processor. // White Paper. Santa Clara, California, USA: Intel Corporation, 1994. 23 Avizienis A., Laprie J.-C., Randell B. Fundamental Concepts of Dependability. // 3rd Information Survivability Workshop (ISW-2000), Boston, Massachusetts, USA, 2001. P. 7-12. 24 Heimerdinger W. L., Weinstock C. B. A Conceptual Framework for System Fault Tolerance. // Technical Report. Pittsburgh, Pennsylvania, USA: Software Engineering Institute, Carnegie Mellon University, 1992. 25 Tel G. Introduction to Distributed Algorithms. Cambridge, UK: Cambridge University Press, 2000. 608 p. 26 Torres-Pomales W. Software Fault Tolerance: A Tutorial. // Technical Memorandum. Hampton, Virginia, USA: NASA Langley Research Center, 2000. 27 Thorhuus R. Software Fault Injection Testing. // Master of Science Thesis in Electronic System Design. Stockholm, Sweden: Kungliga Tekniska Högskolan, 2000. 28 Arlat J., Costes A., Crouzet Y., Laprie J. C., Powell D. Fault Injection and Dependability Evaluation of Fault-Tolerant Systems. // IEEE Transactions on Computers. 1993. 42. N 8. P. 913-923. 29 Leveugle R. Fault Injection in VHDL Descriptions and Emulation // IEEE International Symposium on Defect and Fault Tolerance in VLSI Systems (DFT'00). Yamanashi, Japan, 2000. P. 414. 30 Hsueh M. C., Tsai T. K., Iyer R. K. Fault Injection Techniques and Tools. // IEEE Computer. 1997. 30. N 4. P. 75-82. 31 Stroph R., Clarke T. Hardware and Software Fault Simulation. // International Conference on Simulation’98. York, UK, 1998. P. 413-419. 32 Segall Z., Vrsalovic D., Siewiorek D., Yaskin D., Kownacki J., Barton R., Dancey A., Robinson T. FIAT – Fault Injection Based Automated Testing Environment. // In Proc. 18th IEEE Int. Symp. on Fault Tolerant Computing (FTCS-18). Tokio, Japan, 1988. P. 102-107. 61 Адаптация метода внесения неисправностей для оценки надежности вычислительных систем реального времени с использованием имитационного моделирования _______________________________________________________________________________________________ 33 Bieman J. Using Fault Injection to Test Software Recovery Code. // Final report of a CASI FY95 Technology Transfer Grant. Fort Collins, Colorado, USA: Colorado Advanced Software Institute, 1996. 34 Han S., Shin K. G., Rosenberg H. A. DOCTOR: An Integrated Software Fault Injection Environment for Distributed Real-time Systems. // In Proc. 2nd Annual IEEE Int. Computer Performance and Dependability Symp. (IPDS’95). Erlangen, Germany, 1995. P. 204-213. 35 Kanawati J., Abraham J. FERRARI: A Tool for the Validation of System Dependability Properties. // In Proc. 22nd IEEE Int. Symp. on Fault Tolerant Computing (FTCS-22). Boston, Massachusetts, USA, 1992. P. 336-344. 36 Kao W.-L., Iyer R. K., Tang D. FINE: A Fault Injection and Monitoring Environment for Tracing the UNIX System Behavior under Faults. // IEEE Transactions on Software Engineering. 1993. 19. N 11. P. 1105-1118. 37 Tsai T. K., Iyer R. K. FTAPE: A Fault Injection Tool to Measure Fault Tolerance. // IEEE Computer. 1997. 30. N 4. P. 75-82. 38 Carreira J., Madeira H., Silva J. G. XCEPTION: A Technique for the Experimental Evaluation of Dependability in Modern Computers. // IEEE Transactions on Software Engineering. 1998. 24. N 2. P. 125-136. 39 Волканов Д. Ю. Использование имитационного моделирования для оценки надёжности распределённых вычислительных систем. // Труды 1й Всероссийской научной конференции Методы и Средства Обработки информации. Москва, 2003. С. 343-348. 40 Бахмуров А. Г., Чистолинов М. В. Среда моделирования многопроцессорных вычислительных систем. // Программные системы и инструменты №1. Москва: МАКС Пресс, 2000. С. 42-47. 41 Smeliansky R. L. Program behavior invariant as the basis for system performance estimation. // In Proc. PaCt-93 Conf. Obninsk, 1993. 42 Бахмуров А. Г., Чистолинов М. В. Среда моделирования ДИАНА. Язык описания моделей. Описание языка. [RTF] (http://lvk.cs.msu.su/~mike/DyanaCD/doc/mmlang.rtf). 43 Попиков П. Н. Разработка и реализация средства нечеткого поиска в трассах имитационных моделей. // [DOC] Дипломная работа. Москва, 2005. (http://lvk.cs.msu.su/~popikov/diplom.doc). 62