Лекция 10. Отказоустойчивость (Лекции 2015-2016)

ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫРЕАЛЬНОГО ВРЕМЕНИЛекция 10:Обеспечение отказоустойчивостиИУС РВКафедра АСВК,Лаборатория Вычислительных КомплексовБалашов В.В.Цена отказа: Ariane-5(причина: неисправность ПО)Кажется,что-топошло нетак…2Неисправность, ошибка, отказ• Полностью избежать неисправностей невозможно• Цель: минимизировать вероятность отказа3Классификация неисправностей• Активность: латентные / активные• Постоянство: проходящие / постоянные• Источник: внешнее воздействие / ошибкаразработки• Распространение последствий: обнаруживаютсяи локализуются / проникают в другиеподсистемы• Одиночность: одиночные / групповые• Взаимосвязанность: независимые / связанные(источник: Software Fault Tolerance: A Tutorial, NASA, 2014, pp.28-29,http://www.iet.unipi.it/c.bernardeschi/didattica/ANNO2014-15/DEP/SoftwFT.pdf)4Шаги противодействиянеисправности••••••ОбнаружениеОграничение распространенияМаскировкаДиагностикаВосстановлениеВозобновление штатногофункционирования5Классификация неисправностей (2)• По локализации– Программные– Аппаратные• По этапу возникновения– Проектирование/разработка• => все изделия, созданные по проекту– Производство• Дефект серии => все изделия серии• Дефект при производстве конкретного изделия– Эксплуатация• => одиночные изделия, с учётом особенностейэксплуатации6Борьба с серийныминеисправностями• Возникают на этапе проектирования,разработки или серийного производства– На ранних этапах их и следует обнаруживать…• Затрагивают всю серию компонентов– Отзыв серии и всех использующих её систем…• Борьба: использование проектного илиреализационного разнообразия– Аппаратура: различные архитектуры,производители и элементная база– ПО: различные языки, алгоритмы/подходы,команды разработчиков7Специфика ИУС РВ• Жесткие условия эксплуатации– Внешние воздействия вызывают неисправностиоборудования• Недопустимость прекращенияфункционирования при возникновенииошибки– Ошибка = реализация неисправности• Невозможность оперативного ремонта (илиремонта вообще)– Самолет, спутник• Реакция на ошибки должна укладываться вдирективные сроки8Принципы построенияотказоустойчивых систем• Недопустимость единственной точки отказа• Поддержка локализации отказа (обнаруженияотказавшего компонента)• Нераспространение последствий отказа далее посистеме– Защита аппаратуры– Блокировка распространения некорректных результатоввычислений• Постепенная деградация– По мере отказа подсистем, вначале отключаютсявторостепенные функции– Функции, критические для выживания/восстановлениясистемы поддерживаются «до последнего»– Защитный режим: поддержка существования +обеспечение удалённого доступа для диагностики иобслуживания9Механизмы обеспеченияотказоустойчивости• Аппаратные• Программные• Аппаратно-программные10Аппаратные МОО11Аппаратноерезервирование• По разнообразию компонентов– Использование идентичных компонентов• Борьба с дефектами изделия, в т.ч.возникающими в ходе эксплуатации– Использование различных компонентов• Функционально идентичны• Различная элементная база, производитель,проект и т.п.• Борьба с дефектами проекта, серии (не толькоизделия)• По уровню– Система/подсистема– Отдельные компоненты12Аппаратноерезервирование• Активное: основные и резервные компонентыфункционируют одновременно– Синхронизация данных– Минимальное время переключения на резервныйкомпонент– Использование результатов:• Игнорирование результатов резервных компонентов• Голосование (нет выделенного основного компонента)– Повышенное энергопотребление• Пассивное: резервный компонент включается привыходе основного из строя– Затраты времени на инициализацию– Проблема записи состояния основного компонента(нужно внешнее запоминающее устройство)– Экономия энергии• Жаргон: «горячий» и «холодный» резерв13Программные МОО14N-версионное программированиеВходРаспределенныевходные данныеВерсия 1…Версия i…Версия NМодуль принятиярешенияВыход••ОшибкаВерсии ПО функционально эквивалентныРазличаются: алгоритмы, методы разработки,языки программирования, группы разработчиков15N-самотестируемое программированиеВходРаспределенныевходные данныеВерсия 1Контрольныйтест 1…Версия iКонтрольныйтест i…Версия NКонтрольныйтест NМодуль принятия решенияВыход•ОшибкаВерсии ПО запускаются последовательно (до первогорезультата, прошедшего контрольный тест) или параллельно(голосование среди успешных результатов)16Контрольные точкиВход•••Борьба только сослучайными«однократными»неисправностями(инверсия бита памятии т.п.)Не помогает от«постоянных»неисправностей, в т.ч.в ПОЗатраты ресурсов насохранение состоянияв КТ, сложностьмеханизмов поддержкисохраненияУстановка контрольныхточек (КТ)Конецпрограммы?НетНетВыполнение программы доближайшей КТ (или до концапрограммы)ДаЕсть ошибки?(в КТ)ДаПревышено времявыполнения?Да,ОтказНетОткат до предыдущейКТСнятие всех КТВыход17Восстановление блокамиВходУстановкаконтрольной точкиВыполнениеальтернативнойверсииДаСуществует новаяальтернатива? ИКритерий останова недостигнут?Сигнал исключенияКонтрольный тестНе пройденОткат, восстановлениеконтрольной точкиНетОтказПройденСнятие контрольнойточкиВыход•Сочетает N-версионное программирование и контрольные точки18Восстановление блокамиКонтрольнаяточкаОткатВерсия 1(основная)Увеличениеэффективности ипроизводительностиреализацийлогических блоковВерсия 2Версия 3Версия 4Логическийблоквыполнен сошибкой••Логическийблок успешновыполненПеребор блоков по убыванию «скорости»WCET оценивается по наихудшему пути…Логическийблок19Программно-аппаратныеМОО20N-самоконтролируемое программированиеВход••Борьба саппаратными ипрограммнымиошибкамиПО в каждой паре:одна версия +контрольный тест,или более однойверсии + алгоритмвыбораРаспределенныевходные данныеВерсия 1ОшибкаВерсия 2Версия 3Версия 4Сбор результатовСбор результатовВыбор результатаили ИсключениеВыбор результатаили ИсключениеСовпадениеСовпадениеОшибкаОтборрезультатовВыбор результата илиИсключениеВыбор выходныхданныхВыходExceptionFailure21Активное резервирование +N-версионное программирование• На каждом аппаратном компонентевыполняется своя версия программы• Все компоненты активны• Борьба с программными иаппаратными неисправностями22Космический челнок23Зависимость надежностиот количества версий24Принципы проектирования безопасных иотказоустойчивых систем1.

Требования отказоустойчивостии безопасности должны бытьнеотъемлемой частьюспецификации системы, а длянекоторых систем – основой дляпроцесса проектирования.2. Ожидаемые виды отказов ичастоты их возникновениядолжны быть определены вначале процесса проектирования.3. Должны быть определеныобласти локализациинеисправностей в системе (faultcontainment regions). Последствиянеисправности в одной из такихобластей не должныраспространяться на другиеобласти.СалонцелДвигатель иэлектроникуне жалко25Принципы проектирования безопасных иотказоустойчивых систем4. Понятие времени исостояния системы должныбыть строго определены. Впротивном случаезатруднительно отличитьпервичную неисправность отее последствий.5.

Необходимо четкоопределить интерфейсы,чтобы скрыть внутреннееустройство компонентовсистемы.6. Необходимо обеспечитьнезависимостьвозникновениянеисправностейв различных компонентах.причинаследствиеДве независимыетормозныесистемы26Принципы проектирования безопасных иотказоустойчивых систем7. Компонент системы должен считать себякорректно функционирующим, пока два илиболее других компонента не примутпротивоположную точку зрения.8. Механизмы обеспечения отказоустойчивостидолжны быть устроены так, чтобы неусложнять анализ поведения системы.

МООдолжны быть отделены от основнойфункциональности системы.9. Возможность диагностирования должна бытьзаложена в систему на этапепроектирования. В частности, должнаобеспечиваться возможность выявленияскрытых неисправностей, не проявляющихсяв поведении системы.27Принципы проектирования безопасных иотказоустойчивых систем10. Интерфейс с оператором должен бытьинтуитивно понятным и устойчивым кошибкам.

Безопасность должнаобеспечиваться несмотря на ошибкичеловека-оператора.11. Любая аномалия функционирования системыдолжна быть зарегистрирована. Некоторыеаномалии не обнаруживаются на уровнеинтерфейсов между компонентами.Регистрация должна фиксировать в т.ч.внутренние аномалии, в противном случаеони могут быть замаскированы в результатеработы МОО.12. Система должна реализовывать стратегию«никогда не сдавайся», гарантируя заданныйминимальный уровень обслуживания.Полный выход из строя крайне нежелателен.Подушкабезопасности28Принципы проектирования безопасныхи отказоустойчивых системИсточник:“Real-Time Systems: Design Principlesfor Distributed Embedded Applications”(Real-Time Systems Series),H.

Kopetz, Springer, 2011https://vowi.fsinf.at/images/temp/2/2c/20110606133809!TU_WienEchtzeitsysteme_VO_%28Kopetz%29_-_TU_WienEchtzeitsysteme_VO_%28Kopetz%29_-_TU_WienEchtzeitsysteme_VO_%28Kopetz%29_-_Real_Time_Systems__Design_Principles_for_Distributed_Embedded_Applications_-_Hermann_Kopetz_--_2._Edition.pdf29Спасибо за внимание!30.