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

Существует множество схем резервирования. Резервирование может быть холодным и горячим. В последнем случае резервное оборудование постоянно включено и может быть сразу введено в работу. Все они отличаются следующими главными параметрами:

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

2.Достигаемому значению ВБР.

Самые высокие значения ВБР обеспечиваются в схемах резервирования замещением с холодным резервом, но эти схемы страдают самым большим временем переключения на резерв.

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

 

Контроль работы СТС. Виды контроля. Контроль работы СТС и ПО встроенными средствами без прекращения функционирования СТС

 

Многие СТС работают очень быстро. Ещё быстрее работает ПО и человек не в силах отследить изменения значений переменных, логических условий и т.п., если не предпринимать специальных мер. Здесь возможны три варианта осуществления контроля:

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

2.Контроль работы СТС и ПО в точках его останова внешними по отношению к ПО средствами. Такой контроль приводит для систем реального времени к прекращению нормального функционирования системы и требует участия человека – оператора.

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

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

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

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

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

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

В сложных программных комплексах реального времени до 20% ресурсов ЦВМ идет на реализацию контрольных функций в СТС. Здесь важно правильно выбрать контролируемые параметры и координаты. Которые должны быть чувствительны к нарушениям правильного функционирования системы.

 

Стратегии безопасности. Три уровня реакции ПО на обнаруженную ошибку или отказ

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

Обобщенный контроль средствами ОС

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

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

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

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

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

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

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

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

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

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

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

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

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