Свойство безопасности вступает в действие, когда безотказность системы уже нарушена

.

Принципы аварийной защиты.

Во всех случаях для критических систем надо предусмотреть меры аварийной защиты, приводящие ущерб от отказов в допустимые рамки.

Здесь возможен достаточно широкий диапазон подходов, начиная от создания условий для отказоустойчивости системы, и кончая полным прекращением её функционирования с «мягким остановом» при возникновении отказа.

Отказоустойчивая система при наступлении отказа её структурных элементов продолжает функционировать, полностью и автоматически парируя последствия отказа без снижения качества функционирования.

Для достижения этого свойства СТС одного резервирования, методы которого мы рассмотрели, недостаточно. Необходим встроенный контроль работоспособности, призванный обеспечить быстрое и автоматическое обнаружение отказа.

Также необходимо обеспечить информационную устойчивость при наличии отказа – сохранение правильной, не испорченной отказом информации процессов управления для продолжения беспрерывного функционирования СТС после обнаружения отказа и введения в работу резервных элементов.

Между этими крайними случаями реализации безопасного управления существует множество промежуточных случаев, когда функционирование СТС после возникновения отказа происходит с той или иной потерей качества, что и является тем ущербом, который требуется оценивать при анализе безопасности.

Таким образом, требования безопасности переплетаются с требованиями надежности по продолжению функционирования системы, правда с невыполнением в полной мере качества функционирования при наличии неисправностей - отказов структурных единиц системы, не приводящих к потере её работоспособности.

В связи с этим для критических систем наличие аварийной защиты, реализуемой, как правило средствами ПО ( оно позволяет накрутить довольно сложную логику для быстрого обнаружения аварийного состояния и выдать адекватные управляющие воздействия для обеспечения безопасности), является необходимым.

 

Перечень нештатных ситуаций. Три сценария аварийной защиты

В зависимости от функции структурной единицы систекмы или ПО (программы), в которой произошел отказ или проявилась ошибка в ПО возможны варианты:

1. снятия с исполнения только той задачи, на которую влияет отказ или в которой проявилась ошибка, если это возможно.

2. сокращения объема выполняемых задач до определенного круга, исполнение которых обеспечивается даже при наличии проявившейся ошибки или отказа структурной единицы системы.

3. полного прекращения функционирования ПО с «мягким остановом» системы с приведением аппаратуры и ПО в исходное состояние.

Пункты1, 2 возможно реализовать, если изоляция ошибок в ПО высока.

Таким образом, глубина контроля работы системы и ПО должна обеспечивать не просто обнаружения факта неправильной работы, но и возможность локализации и диагностики ошибки с целью определения адекватных мер по «аварийной защите» с целью выбора одного из трех вышеприведенных сценариев.

При таком подходе при проектировании ПО определяется перечень возможных нештатных ситуаций в системе, которые могут быть обнаружены самим ПО или системой. После чего на каждую возможную нештатную ситуацию с ПО определяется методика её определения и реакция, реализуемая в самом ПО – «аварийная защита». Этот перечень является фрагментом политики безопасности системы и оформляется документально.

Реально в специально выделенном фрагменте ПО, предназначенном для управления в нештатных ситуациях СТС, программируется таблица с перечнем предусмотренных при проектировании и распознаваемых нештатных ситуаций и управленческих реакций на каждую из них. Входы в эту таблицу инициируются при возникновении и обнаружении встроенным контролем нештатных ситуаций.

При возникновении непредусмотренных при проектировании или не распознаваемых нештатных ситуаций дело обстоит сложней и чаще всего в этом случае необходимо обеспечивать реакцию по сценарию п.3, как самую радикальную.

Однако, определить меры защиты ПО от возникших ошибок в ПО это только половина вопроса. Вторая половина – найти методы автоматического обнаружения ошибок.

Классификация возможных методов приведена на схеме. Приведены общие методы, но в конкретных системах они могут быть разнообразнее с учетом специфики работы СТС. Рассмотренный метод аварийной защиты ПО, базирующейся на обнаружении ошибок в ПО внутренними средствами и «мягком» сворачивании работ ПО (ограничения функций или организованного аварийного останова), позволяет корректно завершить работу ПО и дать сообщения об ошибке в систему более высокого уровня иерархии или эксплуатирующему персоналу.

Роль ПО в аварийной защите. Ядро безопасности

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

Поскольку ПО само продукт не обладающий абсолютной надежностью и безопасностью, в нем должно быть создано ядро повышенной отлаженности и защиты, реализующее функции Аварийной защиты системы.

При этом при работе ПО должны быть использованы средства изоляции – разграничения пользователей, файлов, процессов управления, устройств ЦВМ с тем, чтобы предотвратить распространение ошибки или отказа «между информационными отсеками» системы. Обычно эти функции изоляции реализуются и поддерживаются ОС.

Аварийная защита системы в непредвиденных ситуациях должна перевести систему в предусмотренное запасное безопасное состояние.Часто такое состояние связано с «мягким остановом» системы, в процессе которого выполняются действия, минимизирующие возможный ущерб системе и окружающей среде.

Для приведения в действие средств аварийной защиты в системе и прежде всего в ПО её ЦВМ должны быть также предусмотрены алгоритмы, позволяющие обнаруживать опасные ситуации как можно ближе к моменту их возникновения.

 

Сбор и представление данныхи результатов работы ПО в систему более высокого уровня иерархии

С прекращением функционирования ПО и системы Контроль результатов в точ-ках оста-нова

Отображение данных и результатов

Контроль на допус-тимость величин уставок времени (отрицательные)

Контроль на допус-тимость времени занятости процес-сора задачей

Контроль исполь-зования памяти

Без прекращения нор-мального функциони-рования ПО (автоматический встро-енный в ПО контроль)

Исполнение функции за заданное время

Проверка данных на до-пустимые значения

Контроль «трас-сы» программы

Диспетчер памяти

Сторожевой таймер (защита от зависания задачи)

Аппаратный ПРР (деление на 0)

Контроль работы ПО при эксплуатации

	Встроенный функ-циональный конт-роль средствами ПО		Обобщенный контроль средствами ОС

Сбор и пред-ставление дан-ных и резуль-татов в систему более высокого уровня иерархии

 

 

Лекция 12. Характеристики контроля - достоверность контроля и запаздывание в обнаружении отказов и ошибок.Отказоустойчивость и информационная устойчивость. Стратегии безопасности компьютерных технологий.

⇐ Предыдущая3456789101112Следующая ⇒

Поделиться: