Время появления ошибки результирующее время между обнаруженными ошибками

Последствия и признаки появления ошибок в программе

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

– полное прекращение
выполнения функций на длительное или
неопределенное время;

– кратковременное
нарушение хода вычислительного процесса.

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

Наиболее типичными
симптомами появления ошибок в программе
являются:

• преждевременное
  (аварийное) окончание выполнения
  программы;

• недопустимое
  увеличение времени выполнения программы;

• зацикливание ЭВМ
  на выполнении некоторой последовательности
  команд одной из программ;

• полная потеря или
  значительное искажение накопленных
  данных, необходимых для успешного
  выполнения решаемых задач;

• нарушение
  последовательности вызова отдельных
  программ, в результате чего происходит
  пропуск необходимых программ либо
  непредусмотренное обращение к программам;

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

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

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

• предусмотреть в
  программах специальные средства
  диагностики кодов аварийных завершений,
  в том числе кодов, формируемых самими
  пользователями;

• ввести в программы
  контрольные точки;

• обеспечить
  возможности рестарта программ с
  контрольных точек.

Аналитические модели надежности программ

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

При построении
моделей используются следующие
характеристики надежности программы.

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

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

.

Интенсивность
отказов
– условная плотность вероятности
времени до возникновения отказа программы
при условии, что до моментаотказа не было. Когда мы рассматривали
потоки отказов и сбоев, мы показали

Средняя наработка
на отказ
– математическое ожидание временного
интервала между последовательными
отказами.

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

Модель надежности
программ с дискретно-понижающейся
частотой (интенсивностью) проявления
ошибок.

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

,

где
– неизвестное первоначальное число
ошибок;– число обнаруженных ошибок, зависящее
от времени,– некоторая константа (рис.2).

Рис.2 Зависимость
интенсивности отказов программы от
времени работы (модель с дискретно
понижающейся интенсивностью проявления
ошибок в программе)

Плотность
распределения времени обнаружения
-й
ошибкизадается соотношением

.

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

;

,

где
;;;и
– оценки
соответственно К
и М,
т
– число устраненных ошибок в момент
оценки надежности программ.

Рассмотренная
модель надежности программ является
достаточно грубой. На практике часто
не соблюдаются условия, на которых она
построена. Нередко при устранении ошибки
вносятся новые ошибки. Во многих случаях
не соблюдается также основное
предположение, что при всяком устранении
ошибки интенсивность отказов уменьшается
на одну и ту же величину К.
Не всегда удается определить и устранить
причину отказа, и программу часто
продолжают использовать, так как при
других исходных данных ошибка, вызвавшая
отказ, может себя и не проявить.

Модель надежности
программ с дискретным увеличением
времени наработки на отказ.

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

Предполагается,
что время между двумя последовательными
отказами
является случайной величиной, которую
можно представить в виде суммы двух
случайных величин:

,

где случайные
величины
независимы и имеют одинаковые
математические ожиданияи средние квадратические отклонения.

Из выше приведенной
формулы следует, что т-й
отказ программы произойдет через время

.

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

.

При этих предположениях
средняя наработка между (—1)-м
ит—м
отказами программы равна

,

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

.

Оценки величин
,могут быть получены по данным об отказах
программы в течение периода наблюденияследующим образом:

;

,

где
– число отказов программы за период;– момент возникновения-го
отказа программы.

Функция надежности
определяется в зависимости от числа
возникших отказов

,

где Ф(х)
—функция
Лапласа.

Экспоненциальная
модель надежности программ.

Эта модель основана
на предположении об экспоненциальном
характере изменения во времени числа
ошибок в программе.

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

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

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

Пусть М
– число
ошибок, имеющихся в программе перед
фазой тестирования (М
рассматривается как некоторая константа);
– конечное число исправленных ошибок;– число оставшихся ошибок. Тогда

.

При принятых
предположениях интенсивность отказов
пропорциональна
,
т.е.

,

где С
–
коэффициент
пропорциональности, учитывающий реальное
быстродействие ЭВМ и число команд в
программе.

Введем дополнительное
предположение, что в процессе корректировки
новые ошибки не порождаются, т. е. что
интенсивность исправления ошибок
будет равна интенсивности их обнаружения,
т. е.

.

Решая совместно
два последних уравнения, получаем

.

Перед началом
работы ЭВМ
ни одна ошибка исправлена не была,
поэтому решением этого уравнения
является

.

Будем характеризовать
надежность программы после тестирования
в течение времени
средним временем наработки на отказ:

.

Следовательно,

.

Введем
– исходное значение среднего времени
наработки на отказ перед тестированием.
Тогда

.

В результате имеем

Очевидно, что
среднее время наработки на отказ
увеличивается по мере выявления и
исправления ошибок.

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

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

.

В этом случае
среднее время наработки на отказ
и число обнаруженных отказовп
определяются следующими соотношениями:

;

.

Тогда для значения
среднего времени наработки на отказ
перед тестированием справедливо

.

В результате
получаем

;

.

Для практического
использования представляет интерес
число ошибок
,
которое должно быть обнаружено и
исправлено для того, чтобы добиться
увеличения среднего времени наработки
на отказ отдо.
Этот показатель может быть получен из
следующих соотношений:

.

Следовательно,

.

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

.

Рассмотрим, каким
образом можно оценить основные параметры
модели. Коэффициент В
может быть определен исходя из
статистических данных по числу ошибок,
порожденных во время обнаружения других
ошибок. Можно считать, что для систем
программного обеспечения общего
назначения В
изменяется в диапазоне 0,91—0,95.

Для оценки
иможно
рассчитать среднюю интенсивность ошибок
(число ошибок на одну команду) в начале
различных фаз тестирования. По различным
оценкам в начале процесса тестирования
для программ, написанных на языке
ассемблера, число ошибок на 1000 команд
варьируется от 4 до 8. Рассмотренная
модель может применяться для определения
времени испытаний программ с целью
достижения заданного уровня надежности,
а также для оценки числа оставшихся в
программе ошибок.

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

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

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

Информационные
методы повышения

надежности
СВТ

Широко распространенным
методом повышения надежности СВТ
является обеспечение избыточности в
составе СВТ, в частности информационной
избыточности.

Применение
корректирующих кодов является одним
из наиболее удобных и гибких методов
введения избыточности в ЭВМ. В некоторых
условиях, например, при кратковременных
сеансах работы, когда ресурсы надежности
почти не расходуются, коррекция сбоев,
вызываемых различного рода помехами,
может иметь решающее значение для
обеспечения нормального функционирования.
Положительные качества корректирующих
кодов следующие:

1. корректирующие
коды обеспечивают исправление ошибок
без перерывов в работе ЭВМ;

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

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

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

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

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

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

1 этап – выявление
наиболее вероятных ошибок для заданного
способа функционирования устройства
или наиболее опасных ошибок в условиях
использования этого устройства;

2 этап – формирование
избыточного множества выходных слов,
разделение этого множества на подмножества
разрешенных и запрещенных кодовых слов
и образование декодировочных групп;

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

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

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

Известно, что ЭВМ
слагается из отдельных устройств, в
каждом из которых информация претерпевает
определенные изменения. В то же время
составляющие части ЭВМ состоят из
отдельных блоков (сумматоров, регистров
и т.п.), которые в свою очередь набраны
из простейших логических элементов
(триггеров, схем И, ИЛИ, НЕ и т.п).

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

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

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

Петров Б.М., Уткина О.Н. АНАЛИЗ ОСОБЕННОСТЕЙ ОЦЕНКИ ЖИВУЧЕСТИ СЕРВЕРНЫХ ПРОГРАММНЫХ СРЕДСТВ НАНОПРОЦЕССОРНЫХ СИСТЕМ

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

Разработка современных серверных («облачных») систем, базирующихся на новых методах обработки информации и использующих новейшие достижения наноэлектроники, потребовала разработки новых моделей расчета живучести программных средств СНПС для основных типов серверов: -print, -mail, -web,

-ftp, -vpn, -DHCP, -DNS, -proxy, сервер БД.

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

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

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

В настоящее время в Интернете находятся десятки миллиардов к пакетов (1010), которые имеют емкость десятки миллиардов байт информации (1010), которые обрабатываются на серверах с производительностью сотни миллиардов (1011), производительность серверных систем равна произведению тактовой частоты на разрядность системной шины данных, в итоге мы имеем информационную сложность Интернета 1031, которая должна обеспечиваться новыми моделями расчета и обеспечения живучести.

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

Особенностями СНПС, которые обеспечивают высокую защищенность за счет живучести и безопасности, являются:

— конфигурирование массива с избыточностью данных;

— конфигурирование CRON;

— конфигурирование LVM;

— MD5-sum для контроля целостности;

— проверка на spy, и на back door;

— наличие firewall и clam;

— наличие межсетевых экранов и сканеров безопасности;

— наличие политики безопасности сетевого оборудования;

— наличие системы аутентификации и авторизации;

— наличие системы обнаружения атак;

— наличие системы антивирусной защиты;

— ограничения на ввод ID и шифрование каналов.

Особенностями СНПС, которые обеспечивают высокую функциональность за счет быстродействия и доступа в Интернет, являются:

— оптимальная настройка маршрутизации;

— оптимизация пропускной способности сети;

— планирование приоритетов вторичных процессов;

— балансировка нагрузки и многоканальность;

— наличие системы от несанкционированного доступа;

— дефрагментация и физическая чистка HDD;

— автоматизация уведомлений;

— делегирование доступа и чистка баз данных.

Особенностями СНПС, которые обеспечивают высокую работоспособность за счет системы обслуживания и стабильности, являются:

— поиск и удаление временных файлов;

— поиск и удаление .bac файлов;

— поиск и удаление битых ссылок;

— регулярное и своевременное обновление всей системы;

— RAID с избыточностью;

— наличие вторичных серверов и нескольких внешних IP;

— наличие ИБП и сетевых фильтров.

Вероятность достижения требуемого уровня функциональности СНПС сильно зависит от:

— допустимого коэффициента нагрузки (0,1 — 0,8) и от балансировки ее;

— возможности перераспределения обязанностей, коэффициента

делегирования задач (0,3 — 0,9) вторичным серверам;

— коэффициента конфигурации и полноты, глубины и достоверности

проверок (число точек контроля в серверах);

— сложности выполняемых задач, коэффициента ресурсоемкости задач (0,1

— 1,0) при построении очередей задач.

При этом сервер должен выдерживать не менее 98% атак, а система резервного копирования должна каждый день делать инкрементальное резервное копирование и раз в неделю полное резервное копирование, а источник бесперебойного питания должен обеспечивать работу сервера не менее 8 часов, а

СНПС должна уметь обрабатывать не менее 1000 обращений к базе данных. При конфигурировании необходимо обращать особое внимание на самые важные для данной ситуации характеристики и необходимо проводить постоянный мониторинг для своевременного обнаружения и исправления возникающих проблем при обслуживании сервера.

Для получения максимальной вероятности достижения требуемого уровня функциональности СНПС необходимо в первую очередь обеспечивать:

— оптимальное построение очередей задач;

— разработку адаптивной системы резервного копирования под текущие задачи;

— высокий уровень безопасности за счет анализа всех направлений, по которым можно ожидать атаки;

— постоянное поддержание баз данных в компонентном состоянии;

— мониторинг, дефрагментацию и регулярную чистку сервера.

Внедрение микропроцессоров (МП), сверхбольших интегральных схем (СБИС) памяти, цифровых сигнальных процессоров (ЦСП), программи-руемых логических интегральных схем (ПЛИС), микроконтроллеров (МК) и нанопроцессоров (НП) и привело к значительному увеличению сложности ПО. Существует прогноз, что к 2012 году, когда будут внедрены разрабатываемые сейчас системы, вклад ПО составит более 95 % стоимости технических вычислительных средств.

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

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

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

Во второй группе моделей для прогнозирования одной из важнейших характеристик живучести ПО -интенсивности ошибок используют модели, базирующиеся на теории надежности технических систем. Эти модели чаще всего используются на практике, т.к. они позволяют определить следующие показатели живучести ПО: времена появления ошибок; результирующее время между ошибками; количество ошибок за

заданный период времени.

Как в технических средствах, в качестве показателей живучести используются: функция надежности (вероятность безошибочной работы) — , среднее время между появлениями ошибок в ПО — Тср, интенсивность ошибок ^по(Ъ), которую обозначают через функцию риска Z(t) (количество, скорость, темп

выявления ошибок) условную вероятность того, что ошибка произойдет в интервале времени ( ^ t + А ^ при условии, что программа не отказывала в течение времени ^

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

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

Живучесть СНПС определяется совместной вероятностью Рснпс = Ртс(А) х Рпо(В/А) , где Ртс(А) — безусловная вероятность безотказной работы технических средств; Рпо(В/А) — условная вероятность безотказной работы программного обеспечения при условии, что в технических средствах отказ не произошел. Как отмечено в [1], целесообразно принять допущение о независимости отказов в ТС и ПС,

Т.е. РБНПС = Ртс (А) х Рпо (в) .

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

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

Таблица 1Выбор номенклатуры показателей безотказности технических и программных средств серверных нанопроцессорных систем вида II (СНПС)

Надежность и живучесть НПС Надежность элементной базы (нанопроцессоры и команды) Интолерантный подход Живучесть структуры Толерантный подход Живучесть архитектуры (структуры и протоколы обмена данных и управления) Толерантный подход

Свойство Показатель Свойство Показатель Свойство Показатель

Технические средства НПС Безотказность То.тс — средняя наработка на отказ в технических средствах Отказо- устойчи- вость Р (^ — вероятность, что не произойдет срыва выполнения задания, из-за отказов в технических средствах Безотказ- ность, отказо- устойчи- вость ТО.ТС — средняя наработка на отказ в технических средствах; Р (^ — вероятность, что не произойдет срыва

выполнения задания, из-за отказов в технических средствах

Программные средства НПС Правильность То.пс — средняя наработка на ошибку в программных средствах Устойчи- вость Р (^ — вероятность, что не произойдет срыва решения задачи, из-за появления ошибки в программных средствах Правиль- ность (коррект- ность), устойчи- вость ТО.ПС — средняя наработка на ошибку в программных средствах; Р (^ — вероятность, что не произойдет срыва решения задачи, из-за появления ошибки в программных средствах

Изделия вида II (СНПС), которые в процессе эксплуатации могут находиться, кроме двух состояниях — работоспособном или неработоспособном, в некотором числе частично неработоспособных состояний, в которые они переходят в результате частичного отказа, что соответствует свойству живучести. Живучесть архитектуры это совместный учет отказов элементной базы, устойчивость структуры и протоколов обмена данных и управления для обеспечения эффективной работы за счет корректного отключения т количества ядер, различных уровней КЭШ — памяти, различных ступеней конвейеров и различных микротехнологий.

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

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

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

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

— программа называется правильной, если она выдает правильные результаты при правильных исходных данных и при отсутствии ошибок в командах и константах;

— программа называется устойчивой, если она выдает правильные результаты при наличии ошибок в исходных данных или в командах, т.е. возникающие ошибки в процессе функционирования нейтрализуются;

— отказ ПО определяется как недопустимое отклонение результатов выполнения задания от заданных в ТУ, по точности, по времени;

— безотказность ПО характеризуется вероятностью безотказной (безошибочной) работы ПО в течение заданного времени, в заданных условиях (т.е. с требуемой точностью и быстродействием), для данного СНПС в комплект которого включено ПО;

— для проведения расчетов в качестве основной характеристики безотказности ПО используется интенсивность отказов ^цо ;

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

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

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

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

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

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

Различают последствия при возникновении ошибок:

а) средние (45%) и незначительные (ЗО%) последствия при ошибках в данных, которые искажают данные, точность вычислений (т.е. ухудшают характеристики СНПС) , эти ошибки обнаруживаются и исправляются при циклической обработке;

б) катастрофические (5%) и серьезные (20%) последствия при ошибках в командах, в последовательности передачи управления, которые приводят к искажению программы и срыву решения задачи.

В таблицах 2, 3, 4, 5 приведена классификация ошибок ПО по типам, этапам возникновения и обнаружения ошибок [1].

Таблица 2

Тип ошибки Вес ошибки, %

Неполная или ошибочная спецификация 25

Отклонение от спецификации 15

Нарушение стандартов программирования 14

Ошибочная выборка данных 10

Логическая ошибка в последовательности операций 9

Ошибка в арифметической операции 8

Ошибки в документации и в исходных данных 8

Ошибка в обработке прерываний 8

Ошибка в константах 3

Таблица 3

Причины ошибок Вес ошибки, %

Ошибки в числовых значениях 20

Недостаточные требования к быстродействию 18

Недостаточные требования к точности 15

Ошибочные символы и знаки 14

Ошибки оформления 12

Ошибочные модели описания аппаратуры 11

Ошибочные и неопределенные исходные данные 10

Таблица 4

Этап, на котором допущена ошибка Вес ошибки, %

Выбор цели 10

Алгоритмизация и спецификация 40

Кодирование 43

Отладка 3

Опытная эксплуатация 2

Тиражирование и поддержание 2

Таблица 5

Этап, на котором обнаружена ошибка Вес ошибки, %

Разработка контрольных примеров и тестов 20

Отладка 24

Натурные испытания и моделирование 22

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

Сдача заказчику и эксплуатация 18

Литература

1. Петров Б.М., Уткина О.Н. Применение компьютерных технологий для разработки меЬ-портала экспертной системы анализа живучести информационных систем. Сб. трудов межд. научно-практич. конф. «Информационные технологии в образовании, науке и производстве» г. Серпухов 2008 г., с.128-132.

Основные показатели надежности программного обеспечения (ПО). Математические модели оценки надежности ПО.

13.1. Основные показатели надежности программного обеспечения (ПО).

Надежность программного обеспечения отличается от надежности  технических средств следующим:

• элементы ПО не стареют от износа;
• число способов контроля ПО значительно больше числа способов контроля аппаратуры;
• в ПО значительно больше объектов для контроля, чем в аппаратуре;
• вПО гораздо проще вносить исправления и дополнения, чем в аппаратуру, но это  трудно делать корректно и безошибочно.

Основные понятия, связанные с надежностью программного обеспечения:

• ошибки в программах и признаки их наличия;
• количество оставшихся в программе ошибок (ошибок, дошедших до пользователя); вероятность безотказной работы программы;
• интенсивность обнаружения ошибок (или функция риска);
• прогон программы;
• отказ программы.

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

• при выполнении программы появилась ошибочная операция;
• использование некорректного операнда в программе;
• несоответствие функций, выполняемых программой, ее спецификации;
• ошибки в самой спецификации, которые вызывают необходимость корректирования программы;
• ошибки в вычислениях (например, переполнение и т.п.);
• ошибки интерфейса программы с пользователем.

Этот список можно считать открытым, поскольку он может быть продолжен разработчиками по мере накопления ими опыта в повышении надежности программного обеспечения.

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

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

Пусть P(t)  — вероятность того, что ни одной ошибки не будет обнаружено на временном интервале [0,t]. Тогда вероятность хотя бы одного отказа за этот период будет Q(t) = 1 – P(t), и плотность вероятности можно записать как

Рассмотрим функцию риска R(t), как условную плотность вероятности отказа программы в момент времени t, при условии, что до этого момента отказов не было

(13.1)

Функция риска имеет размерность [1/время] и она очень полезна при классификации основных распределений отказов. Распределения с возрастающей функцией риска соответствуют тем ситуациям, когда статистические характеристики надежности ухудшаются со временем. И наоборот, распределения с убывающей функцией риска соответствуют обратной ситуации, когда надежность улучшается со временем в результате процесса обнаружения и коррекции ошибок.

Из выражения  (13.1),  ясно, что , и, следовательно,

или

(13.2)

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

Прогон программы – это набор действий, включающий в себя: ввод в программу одной из возможных комбинаций E_i пространства входных данных E (); выполнение программы, которое заканчивается либо получением результата F(E_i), либо отказом.

Для некоторых наборов входных данных E_i, отклонение полученного на выходе результата (F’(E_i)) от требуемого результата F(E_i) находится в пределах допустимого отклонения , то есть выполняется следующее неравенство

()

а для всех остальных E_i  из подмножества , выполнение программы не дает приемлемого результата, то есть

()

Случаи, описанные неравенством (13.4), называются отказами программы.

Рассмотрим дихотомическую переменную :

Тогда статистическая оценка вероятности отказа программы в течении m прогонов будет равна:

()

Обозначим через  приемлемую ошибку оценки  вероятности отказа . Тогда требуемое количество прогонов программы m должно быть пропорционально значению , где    Q – заданная вероятность отказа программы. Это означает, что если, например, требуемая относительная ошибка оценки (13.5) , и требуемое (желаемое) значение , тогда количество независимых прогонов программы m одлжно быть не меньше, чем , что, конечно,  нелегко реализовать на практике. Решением этой проблемы может быть использование процедуры последовательного анализа Вальда.

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

Опыт разработки ПО показывает, что выявление ошибок и их исправление связано с определенными затратами, которые составляют цену ошибки. По мере перехода к более поздним стадиям разработки цена ошибки возрастает:

1. Этап разработки спецификаций                                                  140$;
2. Программирование                                                                       1100$;
3. Комплексная отладка                                                                    7000$;
4. Этап сопровождения                                                                     от 14000$ до 140 000$;

13.2. Математические модели оценки надежности ПО.

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

Математические модели надежности программ можно разбить на группы по следующим признакам:

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

Модели, основанные на использовании функции риска

Модель Джелинского-Моранды.

Это одна из первых и простейших моделей классического типа, послужившая основой для дальнейших разработок в этом направлении. Модель была использована при разработке таких значительных программных проектов, как программа Аполло (некоторых ее модулей).  Модель Джелинского-Моранды основана на следующих предположениях:

1. Интенсивность обнаружения ошибок R(t) пропорциональна текущему количеству ошибок в программе, то есть изначальному количеству ошибок за вычетом количества ошибок, уже обнаруженных на данный момент.
2. Все ошибки в программе равновероятны и не зависят друг от друга.
3. Все ошибки имеют одинаковую степень важности.
4. Время до следующего отказа программы распределено экспоненциально.
5. Исправление ошибок происходит без внесения в программу новых ошибок.
6. R(t) = const в промежутке между любыми двумя соседними моментами обнаружения ошибок.

Согласно этим предположениям, функция риска будет представлена как:

В этой формуле t – это произвольный момент времени между обнаружением (i-1)-й и i-й ошибок; K – неизвестный коэффициент масштабирования; B – начальное количество оставшихся в программе ошибок (также неизвестное). Таким образом, если в течении времени t было обнаружено  (i-1) ошибок, это означает, что в программе еще остается B-(i-1) необнаруженных ошибок. Полагая, что

и используя предпосылку 6, а также равенство (13.2),  можно заключить, что все X_i имеют экспоненциальное распределение

и плотность вероятности отказа, соответственно, равна

Тогда функцию правдоподобия (согласно предпосылке 2) можно записать как

или, переходя к логарифму функции правдоподобия, имеем

(13.2)

Максимум функции правдоподобия можно найти, используя следующие условия

(13.3)

(13.4)

Из формулы (13.3) получается оценка максимального правдоподобия для K

(13.5)

Подставляя выражение (13.5) в (13.4), находим нелинейное уравнение для вычисления –оценки максимального правдоподобия для B

(13.6)

Это уравнение можно упростить перед тем, как искать его решение, если записать его с использованием следующих обозначений

(13.7)

где

Поскольку имеют смысл лишь целочисленные значения , функции из выражения (13.7) можно рассматривать только для целочисленных аргументов. Более того, , поскольку n ошибок с программе уже обнаружено. Таким образом, оценка максимального правдоподобия для B может быть получена с помощью вычисления начальных значений функций f_n(m) и g_n(m) для m=n+1, n+2…, и  анализа  разницы  |f_n(m)-g_n(m)|.

Поскольку правая и левая части выражения (13.7) одинаково монотонны, это порождает проблему единственности решения, а также проблему его существования. Конечное решение  в области существует тогда и только тогда, когда выполняется неравенство

(13.8)

В противном случае оценка максимального правдоподобия будет Условие (13.8) можно переписать в более удобном виде

(13.9)

где  A – то же самое выражение, что и в формуле (13.7). Необходимо отметить, что,  A является интегральной характеристикой n встретившихся в программе за время тестирования ошибок, и представляет (в статистическом смысле) набор интервалов X_i между ошибками.

Рассмотрим пример использования модели Джелинского-Моранды, в котором она применяется к следующим экспериментальным данным: в течение 250 дней было обнаружено 26 ошибок, интервалы между обнаружением которых представлены в таблице 13.1.  Для этих данных мы имеем n=26 и . Условие (13.9) выполняется, и, таким образом, оценка максимального правдоподобия имеет единственное решение. В таблице 13.2 представлены начальные значения функций, входящих в уравнение (13.7), для множества аргументов

Наилучшим решением для уравнения (13.7) является m=32 (соответствующая строка в таблице дает минимальное значение разницы функций по модулю, то есть максимально приближает ее к нулю, что нам и требуется), то есть = m-1=31. Из выражения  (13.5) находим  = 0.007.

Среднее время  (время, оставшееся до обнаружения (n+1)-й ошибки) есть инвертированная оценка интенсивности для предыдущей ошибки:

В этом примере, , и время до полного завершения тестирования

Таблица 10. Интервалы между обнаружением ошибок.

I	Xi	I	Xi	i	Xi	i	Xi
1	9	8	8	15	4	21	11
2	12	9	5	16	1	22	33
3	11	10	7	17	3	23	7
4	4	11	1	18	3	24	91
5	7	12	6	19	6	25	2
6	2	13	1	20	1	26	1
7	5	14	9

Таблица 11. Значения функций.

m
27	3.854	2.608	1.246
28	2.891	2.371	0.520
29	2.427	2.172	0.255
30	2.128	2.005	0.123
31	1.912	1.861	0.051
32	1.744	1.737	0.007
33	1.608	1.628	-0.020
34	1.496	1.532	-0.036

Простая экспоненциальная модель.

Основное различие между этой моделью и моделью Джелинского-Моранды, рассмотренной в предыдущем разделе, в том, что эта модель не использует предположение 6, и, таким образом,  допускает, что функция риска может меняться между моментами обнаружения ошибок, то есть она больше не является константой на этих интервалах. Пусть N(t) – число ошибок, обнаруженных к моменту времени, и пусть функция риска пропорциональна количеству ошибок, оставшихся в программе после момента t.

Продифференцируем обе части этого уравнения по времени:

Учитывая, что   — это R(t) (количество ошибок, обнаруживаемых в единицу времени), получаем дифференциальное уравнение для R(t)

(13.10)

Если рассмотреть начальные значения N(0)=0, R(0)=KB, то решением уравнения (3.10) будет

(13.11)

Оценки параметров К и В можно получить аналогично модели Джелинского-Моранды и затем  с помощью  оценки функции риска можно спрогнозировать ситуацию на следующие этапы отладки.

Модель Шика-Уолвертона.

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

Модель основана на следующих предположениях:

1. Все ошибки в программе равновероятны и независимы друг от друга.
2. Все ошибки считаются одинаково серьезными.
3. Исправление ошибок происходит без внесения в программу новых ошибок.

Функция риска для данной модели:

В этой формуле Xi  — время между моментом  обнаружения (i-1)-й ошибки до текущего момента .

Вероятность безотказного функционирования программы на интервале Xi равна:

,

что дает плотность вероятности отказа

Модели Липова

Эти модели  являются обобщением моделей Джелинского-Моранды и Шика-Уолвертона. В отличие от этих моделей, модели Липова допускают более одной ошибки в интервале тестирования, и кроме того, допускают, что не все из  ошибок, обнаруженных а этом интервале,  могут быть исправлены. Первая модель Липова (обобщение модели Джелинского-Моранды) основана на следующих предположениях:

1. Все ошибки равновероятны и независимы друг от друга.
2. Все ошибки считаются одинаково серьезными.
3. Интенсивность обнаружения ошибок постоянна на всем интервале тестирования.
4. На i-том интервале тестирования обнаруживается  ошибок, но только  из них исправляется.

Последнее предположение значительно отличает данную модель от всех моделей, рассмотренных ранее. Таким образом, функция риска определяется следующим выражением: где  — общее количество ошибок, исправленных к моменту времени   ,  а   — это время окончания i-го интервала тестирования (измеренное обычным способом или таймером процессора). Еще одно отличие данной модели от модели Джелинского-Моранды в том, что интервалы  фиксированные, а не произвольные.

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

(13.12)

где   — общее количество ошибок, исправленных к моменту времени . Формула (13.12) отличается от первой модели Липова вторым множителем — ,  отражающем изменение интервала тестирования.

Геометрические модели

В этом разделе  рассмотрен пример геометрической модели, предложенной П. Б. Морандой и  являющейся модификацией модели Джелинского-Моранды.

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

1. Общее количество ошибок в программе неограниченно;
2. Ошибки встречаются с разной вероятностью;
3. Процесс обнаружения ошибок не зависит от самих ошибок;
4. Интенсивность обнаружения ошибок изменяется по закону геометрической прогрессии, но между моментами обнаружения ошибок интенсивность постоянна.

Исходя из этих предположений, функцию риска можно записать следующим выражением:

где t – временной интервал между обнаружением (i-1)-ой и i-той ошибок. Начальное значение этой функции R(0) = D, и функция риска убывает со скоростью геометрической прогрессии (0<K<1) по ходу процесса обнаружения ошибок. Скорость изменения R(t) пропорциональна инвертированному значению константы K:

что приводит к убыванию шага изменения R(t) в процессе обнаружения ошибок. Таким образом, более поздние ошибки труднее обнаружить, и они оказывают меньшее влияние на уменьшение потока ошибок, чем предыдущие ошибки. Если снова положить  (временной интервал между обнаружением (i-1)-ой и i-той ошибок), тогда, согласно второму и третьему предположению, Xi распределены экспоненциально с плотностью распределения

Эта модель не позволяет определить, сколько ошибок осталось в ПО, но с ее помощью можно найти его «уровень чистоты». “Уровень чистоты”  — это отношение

(13.13)

Оценка максимального правдоподобия для этого значения будет

Модель Шнейдевинда

Эта модель основана на подходе, что чем позже встречаются ошибки, тем большее значение они имеют для процесса предсказания ошибок в программе.  Предположим, что есть m интервалов тестирования, и пускай на i-том интервале обнаружено  ошибок. Тогда возможно три различных подхода:

1. Использовать данные об ошибках на всех интервалах;
2. Не рассматривать данные об ошибках, обнаруженных на первых (s-1) интервалах, и использовать только данные с s-того по  m-тый;
3. Использовать суммарное количество ошибок, обнаруженных с первого по  (s-1)-ый интервал, т.е. , и отдельные ошибки с s-того по m-тый интервалы.

Подход 1 предлагается использовать в тех случаях, когда для предсказания будущего состояния ПО необходимы данные со всех интервалов тестирования. Подход 2 – когда есть причины полагать, что произошел некий перелом в процессе обнаружения ошибок, и только данные последних m – (s-1) интервалов имеет смысл учитывать в прогнозах на будущее. И наконец, подход 3 является компромиссом между первыми двумя подходами.

Модель основана на следующих предположениях:

1. Количество ошибок на интервале тестирования не зависит от количества ошибок на остальных интервалах;
2. Количество обнаруженных ошибок убывает от одного интервала к другому;
3. Все интервалы тестирования имеют одинаковую длину;
4. Интенсивность обнаружения ошибок пропорциональна количеству ошибок, содержащихся в программе в текущий момент времени.

Лекция 14. Модели, основанные на методе «посева» и разметки ошибок, и модели на основе учета структуры входных данных

Методы оценки надежности программ, основанные на моделях «посева» и разметки ошибок,  рассмотрены на примере трех моделей: Милза, Бейзина и простой эвристической модели. Согласно методике, предложенной Милзом, программа изначально “засевается” известным количеством некоторых ошибок — M. Главное предположение  модели в том, что «засеянные» ошибки распределены таким же образом, как и естественные ошибки программы, и, следовательно, вероятность обнаружения для «засеянной» ошибки такая же, как и для естественной. После этого начинается процесс тестирования ПО. Пусть  во время тестирования было обнаружено (m+v) ошибок, из которых m ошибок было искусственно «засеяно», а v ошибок содержалось в ПО изначально. Тогда, согласно методу максимального правдоподобия, начальное количество ошибок в программе можно оценить следующим образом: .

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

Теперь рассмотрим модель Бейзина. Пусть программный продукт содержит Nk команд. Из этих Nk команд произвольно выбираются n команд, и в каждую из этих n команд заносится ошибка. После этого для тестирования случайным образом выбирается r команд. Если в процессе тестирования было случайным образом обнаружено  m “засеянных” и v естественных ошибок, это означает, что, согласно методу максимального правдоподобия, начальное количество ошибок в программе можно оценить следующим образом:

где скобками ][ обозначена целая часть числа.

При использовании такой процедуры уровень пометки (т.е. среднее количество помеченных команд) должен превышать 20, чтобы полученную оценку можно было считать достаточно объективной.  Эти процедуры могут применяться на любой стадии после того, как написание кода программы закончено.

Теперь рассмотрим простую эвристическую модель. Эта модель была предложена Б. Руднером. Она позволяет избавиться от главного недостатка модели Милза. Здесь тестирование производится параллельно, двумя независимыми группами разработчиков ПО.

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

Модели, основанные на использовании структуры входных данных

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

Модель Нельсона. Применение последовательного анализа Вальда для снижения количества прогонов программы.

Модель, предложенная Е. Нельсоном, основана на использовании структуры входных данных программы.  В простейшем случае набор входных данных E_i, произвольно выбранный из пространства входных данных E, имеет равную априорную вероятность с другими наборами, входящими в E, и это дает оценку вероятности отказа по  формуле (13.5).

Если рассмотреть также и случай различных вероятностей для каждого набора данных, то оценка (13.5) изменится следующим образом.

что позволяет записать следующее выражение для вероятности успешного прогона:

(14.1)

Тогда вероятность успешного выполнения m прогонов, при условии, что  набор входных данных для каждого прогона выбирается независимо и в соответствии с распределением, заданным формулой (14.1), будет равна:

(14.2)

Модель (14.2) позволяет дать следующее определение надежности ПО: надежность ПО – это вероятность его m безотказных прогонов.

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

Принимая во внимание эти обстоятельства, необходимо переопределить распределение (14.1) в терминах вероятностей p_ij выбора набора данных E_i для j-того прогона программы из некоторой последовательности прогонов. Тогда вероятность отказа на j-том прогоне будет

Соответственно, вероятность безотказного выполнения m прогонов можно оценить следующим выражением:

Это выражение можно записать в виде

и если Q_i<<1, тогда

Обозначим  — время выполнения j-того прогона программы, и — суммарное время, потраченное на выполнение j прогонов, и будем использовать следующее выражение для функции риска

тогда мы имеем

Если , то сумма превращается в интеграл, и формула (14.3) превращается в фундаментальное отношение (13.2):

основного правила надежности.

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

Модель, разработанная специалистами компании IBM.

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

В течение сопровождения вПО вносится значительное количество новых ошибок в каждой новой версии, вместе с доработками, изменениями и исправлениями, что требует исправлений также и в следующей версии. Разработчики известной компании IBM попытались предсказать количество подобных исправлений от версии к версии, основываясь на большом количестве экспериментальных данных, собранных в ходе сопровождения операционной системы OS/360. Модель, предложенная специалистами  IBM, основана на наблюдении за ходом разработки этого программного продукта, и на гипотезе о статистической стабильности зависимости между параметрами, характеризующими различные версии системы. В качестве основной единицы измерения сложности ПО был выбран программный модуль. Были стандартизованы правила создания модулей.

Объем i-той версии выражается количеством модулей Mi, входящих в данную версию. При выпуске i –той версии системы изменялся параметра  СИМ_i (количества старых исправляемых модулей), и добавление некоторого числа новых модулей НМ_i , так что  .

При доработке i-й версии (в период подготовки (i+1)-й) происходит дальнейшая коррекция модулей. Эти исправленный модули делятся на две группы: первая группа характеризуется параметром MИM_i – многократно изменяемые модули (10 или более исправлений на модуль), и вторая группа – ИM_i, модули с числом исправлений меньше 10.Эта классификация необходима для упрощения вычислений, а также из-за того факта, что небольшое число исправлений характерно для большинства модулей.

Также необходимо отметить, что группа ИM не требуют особых средств отладки, в то время как группа MИM может потребовать некоторых дополнительных усилий при отладке.

В ходе анализа истории сопровождения  OS/360  фирмы IBM было установлено, что существует значительная зависимость между параметрами, характеризующими масштабы изменений и (соответственно) уровень содержания ошибок (в группах ИM и MCM), и параметрами, характеризующими сложность и объем следующей версии (СИМ, НМ).  В применении к  OS/VS1 это соотношение выглядело следующим образом.

(14.7)

(14.8)

Если предположить, что термины “исправление” и “ошибка” идентичны, то тогда модель для оценивания общего количества ошибок в программе, предложенная специалистами из IBM и основанная на приведенных выше объяснениях, записывается следующим образом:

(14.9)

где ИЗМ_i  — общее количество исправлений, внесенное в модули (или, другими словами, общее количество ожидаемых ошибок), а коэффициенты 23 и 2 – среднее количество исправлений на модуль для групп MИM и ИM, соответственно.

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

• на этапе пассивного сопровождения ПО (ИM_i = 0, СИМ_i невелико) количество исправляемых модулей и количество исправлений внутри модулей быстро убывает от версии к версии;
• количество ожидаемых ошибок в следующей версии может увеличится по сравнению с прошлой версией, если достаточно много старых модулей было изменено (СИМ), и/или было добавлено много новых модулей (НМ).
• Добавление новых модулей оказывает более сильное влияние на рост числа новых ошибок, чем исправления, вносимые в старые модули; в то же время, если есть возможность создать новый модуль вместо изменения старых модулей (5 или более), то это снижает ожидаемое количество ошибок.  Другими словами, на некотором этапе сопровождения ПО изменение уже существующих модулей теряет свою эффективность, и требуется добавление вместо этого нового модуля.

Лекция 15. Методы повышения надежности программ и оценка эффективности   их  применения.

15.1. Влияние избыточности  на повышение  надежности  программ

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

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

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

Временная избыточность состоит в  использовании некоторой части  производительности  ЭВМ для контроля исполнения программ и восстановления вычислительного процесса. Величина временной избыточности  зависит от требований к надежности функционирования системы   и находится  в пределах  от 5-10% производительности однопроцессорной ЭВМ до трех-четырех кратного дублирования производительности  машины. Временная избыточность  используется на  обнаружение искажений,  их диагностику и   на реализацию операций восстановления.  На  это требуется в общем случае небольшой интервал времени,  который выделяется  либо за счет резерва, либо за счет сокращения времени  решения функциональных задач.

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

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

Эффективность применения избыточности для повышения  надежности комплексов программ.

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

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

Эффективность оперативного использования временной избыточности для повышения надежности функционирования программ определяется затратами на контрольно-восстановительные операции изменением показателей надежности в зависимости от затрат и связью этих изменений с отлаженностью программ В результате для оценки эффективности введения временной избыточности в программе необходимо

*                    определить совокупные затраты на контроль на работу при необнаруженном искажении и на восстановление обеспечивающие заданную вероятность обнаружения отказовой ситуации при исполнении программ 

*                    определить основные показатели надежности функционирования программ в зависимости от совокупных затрат на оперативный контроль и восстановление

*                    оптимизировать суммарные затраты на отладку программ и оперативную защиту от искажений для обеспечения заданной надежности функционирования комплекса программ

При решении последней задачи источниками искажений предполагаются только невыявленные ошибки в программах

Влияние оперативного контроля и восстановления на  производительность ЭВМ

Использование времени функционирования ЭВМ для контроля работоспособности исправления искажений и восстановления при отказовых ситуациях приводит к снижению затрат производительности ЭВМ на исполнение комплекса программ в процессе эксплуатации В результате сокращаются ресурсы ЭВМ доступные для выполнения основных функций системы Это сокращение ресурсов можно отразить коэффициентом простоя ЭВМ  К_п = 1 — К_г   характеризующим относительные затраты времени на задачи повышения помехозащищенности программ По мере совершенствования и углубления средств помехозащиты программ возрастают затраты времени ЭВМ на их исполнение что отражается на снижении реальной эффективности функционирования комплекса программ

Целесообразно исследовать влияние использования временной избыточности на сокращение полезной производительности ЭВМ для решения функциональных задач а также на снижение потерь вследствие отказов После определения этих составляющих можно провести их совместный анализ для оптимизации глубины помехозащиты программ с учетом затрат на ее реализацию

Методы  обеспечения надежности программ.

Основные факторы,  определяющие надежность программ.

Надежность функционирования комплексов программ  зависит от многих факторов, которые можно объединить в три группы (табл.. 12).

n факторы,непосредственно определяющие возникновение отказов, и характеристики надежности программ;

n методы, способствующие проектированию корректных программ, снижающие вероятность программных ошибок и отказовых ситуаций при исполнении программ;

n метод, активно влияющие на повышение надежности функционирования программ позволяющие контролировать  и поддерживать заданные показатели надежности.

Таблица 12.

Факторы, непосредственно определяющие  надежность  программ	Методы проектирования корректных программ	Методы контроля и обеспечения надежности  программ
Особенности внешних абонентов и пользователей результатов программ	Структурное проектирование программ и данных	Методы использования избыточности
Требования к показателям надежности	Структурное проектирование программных  модулей	Временной Информационной Программной
Инерционность внешних абонентов	Структурное проектирование взаимодействия модулей	Методы контроля программ, данных и вычислительного процесса
Необходимое время отклика на входные данные	Структурирование данных	Предпусковой контроль Оперативный контроль
Искажения исходных данных	Тестирование программ	Методы программного восстановления
Искажения данных  поступающих от человека	Детерминированное тестирование	Восстановление текстов программ Исправление данных
Искажения  данных поступающих по  телекодовым каналам  связи	Статистическое тестирование	Корректировка вычислительного процесса
Искажения данных в процессе накопления  и хранения в ЭВМ	Динамическое тестирование и контроль пропускной способности в реальном времени	Методы испытаний на надежность Форсированные испытания
Ошибки в программах и их  проявление		Испытания в нормальных условиях эксплуатации
Статистические  характеристики ошибок  и искажений:		Расчетно-экспериментальные методы определения надежности
Программ		Методы обеспечения  надежности при сопровождении
массивов данных		Обеспечение сохранности программ эталонных версий
Вычислительного процесса		Обеспечение корректности внесения изменений и развития версий

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

Ситуации проявления ошибок при исполнении  программ можно разделить  на три группы:

n Отказ — искажения вычислительного процесса, данных или программ, вызывающие полное прекращение выполнения функций системой;

n Искажения, кратковременно  прерывающие функционирование системы — отказовые  ситуации или сбои,   характеризующиеся быстрым восстановлением без длительной  потери  работоспособности;

n Искажения, мало отражающиеся на вычислительном процессе — сбои и  искажения,  не создающие отказовые ситуации.

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

n зацикливание, т.е. последовательная повторяющаяся реализация некоторой группы команд, не прекращающаяся без внешнего  (для данного цикла) вмешательства;

n останов исполнения  программ и прекращение решения функциональных задач;

n полная самоблокировка вычислительного  процесса  (клинч) из-за последовательного  прекрестного обращения разных программ к одним и тем же ресурсам  ЭВМ  без освобождения ранее занятых ресурсов;

n прекращение  или значительное  снижение темпа решения некоторых  задач вследствие перегрузки  ЭВМ по  пропускной способности;

n значительное искажение или полная потеря накопленной информации о текущем состоянии управляемого процесса или внешних абонентов;

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

Методы программного восстановления.

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

Каждый метод восстановления  характеризуется следующими статическими  параметрами:

n вероятность  полного  восстановления нормального функционирования комплекса программ при данном методе  (p₃);

n затратами ресурсов ЭВМ  на  проведение  процедуры восстановительных работ  выбранным  методом (b₃);

n длительностью проведения работ по восстановлению — суммарным временем выбора метода восстановления  и временем  его реализации(t₃)

Показатели  восстановления p₃и t₃непосредственно влияют на показатели  надежности функционирования комплекса программ. Если   операции по  восстановлению работоспособности комплекса программ  при отказовой ситуации полностью  завершаются за время меньше  t_д и после  этого продолжается нормальное функционирование, то происшедшее искажение  в работе программ не учитывается как  отказ и не влияет на основные показатели надежности.

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

Основные  состояния следующие:

0-  состояние  соответствует нормальному   функционированию работоспособного комплекса программ при полном отсутствии искажений —  полезная работа;

1-  состояние имеет место  при  переходе комплекса программ  в  режим  контроля  функционирования и обнаружения ошибок  — состояние контроля;

2-  состояние  соответствует функционированию программ при наличии искажений, не обнаруженных средствами контроля  — состояние необнаруженного искажения данных  или вычислительного процесса, которое, в частности может соответствовать  отказу;

3-  состояние характеризуется функционированием группы программ восстановления  режима полезной работы и устранения последствий искажения — восстановление после действительного искажения;

4-  состояние  соответствует также восстановлению режима полезной  работы, но после  ложного  обнаружения  проявления искажения, когда в действительности состояние полезной работы не   нарушалось  —  восстановление  после  ложной  тревоги.

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

Методы испытаний программ на надежность.

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

n прямые экспериментальные методы  определения показателей надежности  систем  в условиях  нормального функционирования;

n форсированные  методы испытаний реальных  систем на  надежность;

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

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

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

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

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

Методы  обеспечения надежности  комплексов   программ  при  сопровождении.

В этой стадии жизненного цикла  программ расширяются  условия их использования и характеристики исходных данных, вследствие  чего могут потребоваться изменения в программах. Для сохранения и улучшения показателей надежности комплексов программ в процессе длительного сопровождения необходимо четко регламентировать передачу комплексов  программ пользователям. Целесообразно накапливать необходимые изменения  в программах  и вводить их  группами, формируя  очередную версию    комплекса программ с измененными характеристиками. Версии комплекса программ можно разделить на эталонные и пользовательские (или конкретного  объекта).

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

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