Тема 7. Надежность программных комплексов ............................................. 1
7.1. Понятие сложности программ. .............................................................. 1
7.2. Программные ошибки............................................................................. 2
7.3. Математические модели характеристик ошибок в программах ........ 4
7.4. Надежность функционирования комплексов программ ..................... 9
Тема 7. Надежность программных комплексов
7.1. Понятие сложности программ.
При анализе программ имеется два аспекта оценки их сложности:
определение сложности процесса создания программных компонент и
определение сложности объектов разработки — программных модулей, групп
и КП, используемых данных и связей. Эти аспекты тесно связаны, и сложность
объекта обычно определяется через трудоемкость процесса разработки.
Понятие сложности ассоциируется с ресурсами, необходимыми для решения
соответствующей задачи. Задача считается простой, если невелики все ресурсы,
используемые для ее решения. Однако если хотя бы один из необходимых
ресурсов очень велик или оказывается на пределе, доступном для
использования, то такую задачу не считают простой. Для программ наиболее
характерными являются ресурсы, необходимые для их реализации, которые
определяют временную, программную и информационную сложность.
Временная сложность программ в основном определяется алгоритмами,
используемыми для решения задач. Несмотря на возрастание быстродействия
современных ЭВМ, имеется много задач, которые невозможно решать
некоторыми точными алгоритмами при необходимом объеме входных данных.
При ограниченной области изменения входных данных имеется возможность
эффективного ускорения вычислений. Теоретически доказана принципиальная
возможность размена длительности решения любых задач на объем памяти для
хранения программ и данных. При реальной производительности ЭВМ
достижимое качество программ может существенно определяться их
временной сложностью. Это означает, что длительность исполнения программ
по тестовым данным и длительность расчета эталонных значений возрастают
так быстро, что реальные ресурсы современных ЭВМ ограничивают
допустимую полноту отладки и объем получаемых результатов.
Программную сложность в простейшем случае можно оценить по числу
символов в тексте программы, необходимому для ее полного описания на
некотором алгоритмическом языке, или по числу операторов (команд) при
реализации программы на некоторой ЭВМ. Разнообразие алгоритмических
языков и структур команд ЭВМ затрудняет обобщенные оценки и сравнения
программной сложности различных программ. Введение соглашений
структурного программирования и перечней стандартных операторов
программирования позволяет в значительной степени унифицировать
языковую базу, на которой проектируются программы. Относительная простота
определения числа машинных команд в программе (или операторов в тексте на
ассемблере) привела к широкому применению этого параметра в качестве
инженерной меры программной сложности. Однако различия количества
используемых байтов на одну операцию затрудняют подсчет сложности
текстов программ по числу команд, а также сопоставление программной
сложности при применении ЭВМ с различной структурой команд.
Программная сложность в наибольшей степени определяет трудоемкость
создания большинства крупных КП управления и обработки информации.
Информационная сложность программ в первую очередь зависит от
количества типов и структуры данных, поступающих на вход и выдаваемых
программой. Число различных видов операндов, используемых в программе,
достаточно полно характеризует ее информационную сложность. Для
приближенных инженерных оценок в качестве меры информационной
сложности применяется емкость памяти, необходимая для оперативного
накопления и хранения данных, используемых при решении задачи. Понятие
информационной сложности включает емкость всех ячеек памяти и регистров,
к которым осуществляется обращение при обработке операндов в процессе
решения задачи. При этом важно установить объем каждого элемента памяти
или стандартизировать их размеры. Сложность представления некоторого
множества данных может быть отражена совокупностью сложности
табулирования опорных данных и сложности программ их декодирования для
раскрытия всех значений.
7.2. Программные ошибки
Типичные ошибки в программных комплексах. Статистические
характеристики ошибок могут служить ориентиром для разработчиков при
распределении усилий на создание программ. Кроме того, характеристики
ошибок в процессе проектирования программ помогают:
1. оценивать реальное состояние проекта и планировать
трудоемкость и длительность до его завершения;
2. рассчитывать
необходимую
эффективность
средств
оперативной защиты от невыявленных первичных ошибок;
3. оценивать требующиеся ресурсы ЭВМ по памяти и
производительности с учетом затрат на устранение ошибок;
4. проводить исследования и осуществлять адекватный выбор
показателей сложности компонент и КП, а также некоторых других
показателей качества.
Анализ первичных ошибок в программах производится на двух уровнях
детализации:
1. дифференциально — с учетом типов ошибок, сложности и
степени автоматизации их обнаружения, затрат на корректировку и
этапов наиболее вероятного устранения;
2. обобщенно — по суммарным характеристикам их
обнаружения в зависимости от продолжительности разработки,
эксплуатации и сопровождения комплекса программ.
Технологические ошибки документации и фиксирования программ в
памяти ЭВМ составляют 5...10 % от общего числа ошибок, обнаруживаемых
при отладке. Большинство технологических ошибок выявляется автоматически
формализованными методами.
Программные ошибки по количеству и типам в первую очередь
определяются степенью автоматизации программирования и глубиной
формализованного контроля текстов программ. Количество программных
ошибок зависит от квалификации разработчиков, от общего объема комплекса
программ, от глубины логического и информационного взаимодействия
модулей и от ряда других факторов. При разработке программ на автокодах
программные ошибки можно классифицировать по видам используемых
операций на следующие группы: ошибки типов операций; ошибки
переменных; ошибки управления и циклов.
В комплексе программ информационно-справочных систем эти виды
ошибок близки по удельному весу, однако для автоматизации их обнаружений
применяются различные методы. На начальных этапах разработки и
автономной отладки модулей программные ошибки составляют около 1/3 всех
ошибок. Ошибки применения операций на начальных этапах разработки
достигают 14 %, а затем быстро убывают при повышении квалификации
программистов. Ошибки в переменных составляют около 13 %, а ошибки
управления и организации циклов—около 10 %. Каждая программная ошибка
влечет за собой необходимость изменения около шести команд, что
существенно меньше, чем при алгоритмических и системных ошибках. На
этапах комплексной отладки и эксплуатации удельный вес программных
ошибок падает и составляет около 15 и 3 % соответственно от общего
количества ошибок, выявляемых в единицу времени.
Алгоритмические
ошибки
значительно
труднее
поддаются
обнаружению методами формализованного автоматического контроля, чем
предыдущие типы ошибок. К алгоритмическим следует отнести прежде всего
ошибки, обусловленные некорректной постановкой функциональных задач,
когда в спецификациях не полностью оговорены все условия, необходимые для
получения правильного результата. Эти условия формируются и уточняются в
значительной части в процессе тестирования и выявления ошибок в
результатах функционирования программ. Ошибки, обусловленные неполным
учетом всех условий решения задач, являются наиболее частыми в этой группе
и составляют до 70 % всех алгоритмических ошибок или около 30 % общего
количества ошибок на начальных этапах проектирования.
К алгоритмическим ошибкам следует отнести также ошибки связей
модулей и функциональных групп программ. Этот вид ошибок составляет 6...8
% от общего количества, их можно квалифицировать как ошибки некорректной
постановки задач. Алгоритмические ошибки проявляются в неполном учете
диапазонов изменения переменных, в неправильной оценке точности
используемых и получаемых величин, в неправильном учете связи между
различными переменными, в неадекватном представлении формализованных
условий решения задачи в спецификациях или схемах, подлежащих
программированию, и т. д. Эти обстоятельства являются причиной того, что
для исправления каждой алгоритмической ошибки приходится изменять в
среднем около 14 команд, т. е. существенно больше, чем при программных
ошибках.
Особую часть алгоритмических ошибок составляют просчеты в
использовании доступных ресурсов ВС. Одновременная разработка множества
модулей различными специалистами затрудняет оптимальное распределение
ограниченных ресурсов ЭВМ по всем задачам, так как отсутствуют
достоверные данные потребных ресурсов для решения каждой из них. В
результате возникает либо недоиспользование, либо (в подавляющем
большинстве случаев) нехватка каких-то ресурсов ЭВМ для решения задач в
первоначальном варианте. Наиболее крупные просчеты обычно происходят при
оценке времени реализации различных групп программ и при распределении
производительности ЭВМ.
Системные ошибки в сложных комплексах программ определяются
прежде всего неполной информацией о реальных процессах, происходящих в
источниках и потребителях информации. Кроме того, эти процессы зачастую
зависят от самих алгоритмов и поэтому не могут быть достаточно определены и
описаны заранее без исследования функционирования комплекса программ во
взаимодействии с внешней средой. На начальных стадиях проектирования не
всегда удается точно сформулировать целевую задачу всей системы, а также
целевые задачи основных групп программ, и эти задачи уточняются в процессе
проектирования. В соответствии с этим уточняются и конкретизируются
технические задания или спецификации на отдельные программы и выявляются
отклонения от уточненного задания, которые могут квалифицироваться как
системные ошибки.
При автономной и в начале комплексной отладки доля системных
ошибок невелика (около 10 %), но она существенно возрастает (до 35...40 %) на
завершающих этапах комплексной отладки. В процессе эксплуатации
системные ошибки являются преобладающими (около 80 % от всех ошибок).
Следует также отметить большое количество команд, корректируемых при
исправлении каждой ошибки (около 25 команд на одну ошибку).
Убывание ошибок в комплексе программ и интенсивности их
обнаружения не беспредельно. После отладки в течение некоторого времени
интенсивность обнаружения ошибок при самом активном тестировании
снижается настолько, что коллектив, ведущий разработку, попадает в зону
нечувствительности к ошибкам и отказам. При такой интенсивности отказов
трудно прогнозировать затраты времени, необходимые для обнаружения
очередной ошибки. Создается представление о полном отсутствии ошибок, о
невозможности и бесцельности их поиска, поэтому усилия на отладку
сокращаются и интенсивность обнаружения ошибок еще больше снижается.
Этой предельной интенсивности обнаружения отказов соответствует наработка
на обнаруженную ошибку, при которой прекращается улучшение
характеристик комплекса программ на этапах отладки и испытаний у
заказчика.
7.3. Математические модели характеристик ошибок в
программах
Детальный анализ проявления ошибок показывает их глубокую связь с
методами структурного построения программ, типом языка программирования,
степенью автоматизации технологии проектирования и многими другими
факторами. Статистические характеристики различных типов ошибок трудно
описать математическими моделями, и более доступны для математического
описания обобщенные характеристики ошибок в комплексе программ. Путем
анализа и обобщения экспериментальных данных реальных разработок
предложено несколько математических моделей, описывающих основные
закономерности изменения суммарного количества вторичных ошибок в
программах. Модели имеют вероятностный характер, и достоверность
прогнозов в значительной степени зависит от точности исходных данных и
глубины прогнозирования по времени. Эти математические модели
предназначены для оценки:
1. надежности функционирования комплекса программ в
процессе отладки, испытаний и эксплуатации;
2. числа ошибок, оставшихся не выявленными в анализируемых
программах;
3. времени, требующегося для обнаружения следующей ошибки
в функционирующей программе;
4. времени, необходимого для выявления всех ошибок с
заданной вероятностью.
Точное определение полного числа не выявленных ошибок в комплексе
программ прямыми методами измерения невозможно. Однако имеются пути
для приближенной статистической оценки их полного числа или вероятности
ошибки в каждой команде программы. Такие оценки базируются на построении
математических Моделей в предположении о жесткой корреляции между
общим количеством и проявлениями ошибок в комплексе программ после его
отладки в течение времени T, т. е. между:
суммарным количеством первичных ошибок в комплексе
программ (n0) или вероятностью ошибки в каждой команде программы
(p0);
количеством ошибок, выявляемых в единицу времени в
процессе тестирования и отладки при постоянных усилиях на ее
проведение {dn/dt);
интенсивностью искажений результатов в единицу времени
() на выходе комплекса программ вследствие не выявленных
первичных ошибок при функционировании программ.
Наиболее доступно для измерения количество вторичных ошибок в
программе, выявляемых в единицу времени в процессе отладки. Возможна
также непосредственная регистрация отказов и наиболее крупных искажений
результатов, выявляемых средствами оперативного контроля в процессе
функционирования программ. Все три показателя связаны некоторыми
коэффициентами пропорциональности, значения которых зависят, в частности,
от интервала времени, на котором производится сопоставление, от
быстродействия ЭВМ, от эффективности средств автоматизации отладки и от
некоторых других параметров. При фиксированных условиях разработки и
функционирования конкретного комплекса программ эти коэффициенты имеют
вполне определенное значения. Для другой подобной системы коэффициенты
могут несколько измениться, однако оценки, полученные для нескольких
конкретных систем, позволяют прогнозировать эти характеристики, а
следовательно, и соответствующие показатели надежности ПС в зависимости
от длительности отладки и ряда других факторов.
Описаны несколько математических моделей, основой которых являются
различные гипотезы о характере проявления вторичных ошибок в программах.
Эти гипотезы в той или иной степени апробированы при обработке данных
реальных разработок, и их можно разделить на три группы. В первую группу
входят очевидные допущения, статистическая проверка которых невозможна и
нецелесообразна. Вторую группу составляют допущения, определяющие
специфические характеристики модели и требующие статистической проверки
и обоснования на базе экспериментальных исследований. В третью группу
включены второстепенные допущения, расширяющие и уточняющие
возможности применения модели и частично доступные экспериментальной
проверке.
Первая группа допущений включает предположение о наблюдаемости
искажений данных, программ или вычислительного процесса, обусловленных
первичными ошибками в программах. Первичная ошибка, являющаяся
причиной искажения результатов, либо фиксируется и исправляется после
завершения этапа тестирования, либо вообще не обнаруживается, так как
проявление ее последствий незначительно.
Предполагается, что множество тестов более или менее равномерно
покрывает все множество реальных исходных данных и отсутствуют
априорные сведения для искусственного повышения интенсивности ошибок
при некоторых тестах. Тем самым состав тестов представляется случайным
относительно области изменения входных данных программы и содержащихся
в ней необнаруженных первичных ошибок.
Наличие большого числа разнообразных данных, необходимых для
исполнения программ, и практически некоррелированное их изменение
приводит к внешне случайному выбору маршрута, по которому исполняется
программа в каждом конкретном случае. В результате интенсивность
проявления ошибок при реальном функционировании программ зависит от
среднего быстродействия ЭВМ и практически не зависит от конкретного
распределения типов команд на маршрутах обработки данных между
ошибками.
Коллектив специалистов, их квалификация и загруженность
предполагаются постоянными на интервале проектирования и исследования
характеристик ошибок. Также постоянным считается доступное машинное
время для проведения проверок программ.
Вторая группа допущений при построении математических моделей
ошибок является основной и проверена интегрально по обобщенным
характеристикам частости обнаружения ошибок и дифференцирование путем
анализа правомерности каждого допущения. Ниже рассмотрены допущения
при построении экспоненциальной модели.
Интервалы времени между обнаруживаемыми искажениями результатов
предполагаются статистически независимыми. Время измеряется по
фактической наработке длительностей исполнения программ без учета
дополнительных затрат календарного времени на локализацию, диагностику и
исправление ошибок.
Предполагается, что интенсивность проявления ошибок остается
постоянной, пока не произведено исправление первичной ошибки или не
изменена программа по другой причине. Если каждая обнаруженная ошибка
исправляется, то значения интервалов времени между их проявлениями
изменяются по экспоненциальному закону. Интегральная проверка
распределения интервалов времени между обнаружениями ошибок показала,
что оно достаточно хорошо аппроксимируется экспонентой.
Логично предположить, что интенсивность обнаружения ошибок
пропорциональна суммарному числу первичных ошибок, имеющихся в данный
момент в комплексе программ. Это допущение подтверждено расчетом
значений суммарного числа ошибок для хорошо отлаженных и переданных в
эксплуатацию комплекса программ на ряд предыдущих моментов времени,
когда проводилась отладка.
Каждая обнаруженная ошибка подлежит исправлению, поэтому
предполагается, что частота исправления ошибок пропорциональна частоте
их обнаружения. Однако некоторые исправления, в свою очередь, содержат
ошибки. Кроме того, некоторые ошибки являются связанными, и при
обнаружении проявления одной ошибки следует исправление нескольких
первичных ошибок. Из-за этого частота обнаружения ошибок и частота их
исправления не равны, а должны быть связаны некоторым коэффициентом
пропорциональности. Коэффициенты корреляции для исследованных
комплексов программ довольно высокие — от 0,52 до 0,82 при среднем
значении около 0,68, т. е. достаточно хорошо подтверждают гипотезу.
Третья группа допущений детализирует использование ресурсов на
корректировку программ и повышение их качества.
Приведенные предположения позволяют построить экспоненциальную
математическую модель распределения моментов обнаружения ошибок в
программах и установить связь между интенсивностью обнаружения ошибок
при отладке dn/d, интенсивностью проявления ошибок при нормальном
функционировании программ и числом первичных ошибок п. Предположим,
что в начале отладки комплекса программ при =0 в нем содержалось N0
первичных ошибок. После отладки в течение времени осталось п0 первичных
ошибок и устранено п ошибок (n0 + n = N0). Время соответствует
длительности исполнения программы на ЭВМ для обнаружения ошибок и не
учитывает время, необходимое для анализа результатов и проведения
корректировок. Календарное время к отладочным и испытательным работам с
реальным комплексом программ значительно больше, так как после
тестирования программ, на которое затрачивается машинное время т,
необходимо время на анализ результатов, на обнаружение и локализацию
ошибок, а также на их устранение.
При постоянных усилиях на отладку интенсивность обнаружения
искажений вычислительного процесса, программ или данных вследствие еще
не выявленных ошибок пропорциональна количеству оставшихся первичных
ошибок в комплексе программ. Предположение о сильной корреляции между
значениями по и dn/d проверено анализом реальных характеристик процесса
обнаружения ошибок. Тогда
(7.1)_
где коэффициенты К и К' учитывают масштаб времени, используемый
для описания процесса обнаружения ошибок, быстродействие ЭВМ и другие
параметры. Значение коэффициента К' можно определить как изменение темпа
проявления искажений при переходе от функционирования программ на
специальных тестах к функционированию на типовых исходных данных. В
начале отладки это различие может быть значительным, однако при
завершении отладки и при испытаниях тестовые данные практически
совпадают с исходными данными при нормальной эксплуатации. Поэтому
ниже К' полагается равным единице (К'=1).
Таким образом, интенсивность обнаружения ошибок в программе и
абсолютное число устраненных первичных ошибок связываются уравнением
(7.2)
Так как выше предполагалось, что в начале отладки при = 0 отсутствуют
обнаруженные ошибки, то решение уравнения (11.2) имеет вид
(7.3)
пропорционально интенсивности их обнаружения dn/d с точностью до
коэффициента К.
Наработка между проявлениями ошибок, которые, рассматриваются как
обнаруживаемые искажения программ, данных или вычислительного процесса,
равны величине, обратной интенсивности обнаружения ошибок:
(7.4)
Если учесть, что до начала отладки в комплексе программ содержалось
N0 первичных ошибок и этому соответствовала наработка T0 , то функцию
наработки между проявлениями ошибок от длительно-
(7.5)
Если известны все моменты обнаружения ошибок ti и каждый раз в эти
моменты обнаруживается и достоверно устраняется одна первичная ошибка, то,
используя метод максимального правдоподобия, получим уравнение для
определения значения начального количества первичных ошибок N0
(7.6)
и выражение для расчета коэффициента пропорциональности
(7.7)
Необходимые для расчетов К и N0 экспериментальные значения ti
определяются в процессе отладки данного или аналогичных комплексов
программ, созданных тем же коллективом разработчиков и при такой же
технологии. В результате можно рассчитать число оставшихся в программе
первичных ошибок и среднюю наработку Т до обнаружения следующей
ошибки.
В процессе отладки и испытания программ для повышения наработки
между проявлениями ошибок от величины Т1 до значения Т2 необходимо
обнаружить и устранить n ошибок. Эту величину можно определить, выразив
число обнаруживаемых ошибок через длительность наработки на проявление
ошибок, для чего подставим (11.4) в {11.2). Тогда
(7.8)
Аналогичными несложными преобразованиями можно получить затраты
времени на проведение отладки , которые позволяют устранить n ошибок и
соответственно повысить наработку между очередными обнаружениями
ошибок от значения Т1 до Т2:
(7.9)
Следует
подчеркнуть
статистический
характер
приведенных
соотношений. Неравномерность выбора маршрутов исполнения программы при
нормальной эксплуатации, разное влияние конкретных типов ошибок в
программах на проявление их при функционировании, а также сравнительно
небольшие значения n и n, особенно на заключительных этапах отладки,
приводят к тому, что флюктуации интервалов времени между обнаружением
ошибок могут быть весьма значительными
7.4. Надежность функционирования комплексов программ
Основные понятия надежности программ. Надежность технических
систем определяется в основном двумя факторами: надежностью компонент
и ошибками в конструкции, допущенными при проектировании или
изготовлении. Относительно невысокая надежность компонент, их глубокая
взаимозависимость и способность к разрушению, старению или снижению
надежности в процессе эксплуатации привели к тому, что этот фактор оказался
превалирующим для надежности аппаратуры. Надежность сложных
комплексов программ определяется теми же двумя факторами. Однако
соотношение их влияния иное. Хранение программ на магнитных носителях
при отсутствии внешнего вмешательства характеризуется очень высокой
надежностью. Доминирующим для надежности комплекса программ является
второй фактор — ошибки проектирования.
Программа любой сложности и назначения при строго фиксированных
исходных данных и абсолютно надежной аппаратуре исполняется по
однозначно определенному маршруту и дает на выходе строго определенный
результат. Однако случайное изменение исходных данных и накопленной при
обработке информации, а также множество условных переходов в программе
создают огромное количество различных маршрутов исполнения для каждого
комплекса программ. Такое количество вариантов исполнения программы
нельзя проверить полностью из-за ограничений на длительность отладки и
приемочных испытаний. Источниками ненадежности являются непроверенные
сочетания исходных данных, при которых отлаженный комплекс программ дает неверные результаты или отказы. Для последующего изложения следует
уточнить фундаментальные понятия теории надежности и особенности их
использования для анализа характеристик функционирования программ.
Отказ при использовании программ. Понятие отказа связано с
нарушением работоспособности изделия и его соответствия требованиям
технической документации. Отказ при исполнении программ может проявиться
как следствие:
нарушения кодов записи программ в памяти команд;
стирания или искажения данных в оперативной или
долговременной памяти ЭВМ;
нарушения нормального хода вычислительного процесса. Во
всех случаях программные отказы приводят к прекращению выдачи
пользователям информации и управляющих воздействий или к
значительному искажению ее содержания и темпа выдачи.
Сбой при исполнении программ. Понятие «сбой» в теории надежности
трактуется как самоустраняющийся отказ, не требующий внешнего
вмешательства для замены отказавших компонент. Таким образом, понятия
сбой и отказ применительно к аппаратуре отличаются степенью физического
разрушения компонент и необходимостью их замены. В процессе обработки
данных обычно отсутствует физическое разрушение программ и не требуется
замена или ремонт каких-либо материальных компонент. Основной принцип
классификации сбоев и отказов — разделение по временному показателю
длительности восстановления после любого искажения программы, данных
или вычислительного процесса. При длительности восстановления, меньшей
заданного порога, аномалии при функционировании программ следует
относить к сбоям. При восстановлении, превышающем по длительности
пороговое значение и нарушающем работоспособность программ, искажения
соответствуют отказу. Отсюда возникает задача классификации аномалий при
функционировании программ на два типа: достаточные для нарушения
работоспособности системы и малые отклонения от требований технической
документации, при которых работоспособность сохраняется. Ниже
учитываются только значительные искажения программ, данных или
вычислительного процесса, достаточные для нарушения работоспособности.
Классификация программных сбоев и отказов по длительности
восстановления приводит к необходимости анализа следующих динамических
характеристик внешней среды и временных характеристик функционирования
программ:
инерционности объекта, являющегося источником или
потребителем информации;
среднего темпа или периодичности решения задач по
обработке информации для данного объекта;
допустимой длительности ожидания отклика или времени
реакции ЭВМ от момента поступления исходных данных до момента
выдачи обработанных результатов.
Инерционность объекта управления или потребителя информации,
обрабатываемой данными комплекса программ, является первичным
показателем, используемым для установления необходимого времени реакции
программ. Снижение темпа решения задач управления ведет к ухудшению
характеристик функционирования, и при некотором низком темпе
работоспособность нарушается, что соответствует отказу.
Правильный и надежный комплекс программ. Понятие правильной
(корректной) программы может рассматриваться статически вне временного
функционирования. Степень некорректности программ можно характеризовать
вероятностью попадания в область исходных данных, которая
предусматривалась требованиями спецификации (1 на рис. 4.9), однако не
была проверена при тестировании и испытаниях (2 на рис. 4.9). Таким образом,
неправильность программы определяется вероятностью совмещения
следующих событий:
1. попадания исходных данных в область, заданную
требованиями спецификации, но не проверенную при отладке и
испытаниях, — вероятности РII и PIV;
2. проявления ошибки в программе при обработке таких данных
— вероятность Р0.
Правильность программы не определена вне области изменения данных,
заданной спецификацией, и не зависит от динамики ^функционирования
программ в реальном времени.
Надежная программа прежде всего должна обеспечивать низкую
вероятность отказа в процессе реального функционирования. Быстрое
реагирование на искажения программ, данных или вычислительного процесса
и восстановление работоспособности за время меньшее, чем порог между
сбоем и отказом, позволяют обеспечить высокую надежность программы. При
этом неправильная программа может функционировать в принципе абсолютно
надежно. Действительно, если при каждом появлении реальных исходных
данных (3 на рис. 4.9), попадающих в области II и IV и стимулирующих
неправильные результаты, они не приводят к событиям, соответствующим
отказу, то такая программа функционирует безотказно и надежно, хотя и не
всегда правильно.
В реальных условиях по различным причинам исходные данные могут
попадать в область III, не проверенную при отладке и не соответствующую
требованиям спецификации или технического задания. Если восстановление
происходит за время меньшее, чем пороговое время между отказом и сбоем, то
такие события не влияют на основной показатель надежности — наработку на
отказ. Следовательно, отказ при функционировании программы является
понятием динамическим и произойдет с вероятностью, определяющейся
совмещением следующих событий:
появление на входе программы реальных данных,
попадающих в непроверенные при тестировании и испытаниях
области III или IV, — вероятности РIII и PIV;
проявление ошибки при обработке этих данных, достаточной
для вызова отказовой ситуации, — вероятность Р0;
длительность восстановления после возникновения отказовой
ситуации превысила пороговое значение между отказом и сбоем —
вероятность РВ.
В некоторой области изменения исходных данных (область IV)
правильность и надежность программы оказываются взаимосвязанными. Это
соответствует данным, определенным техническим заданием и не
проверенным при тестировании.
Восстановление. Отсутствие физического разрушения компонент
функционирующего комплекса программ позволяет добиваться высокой
автоматизации программного восстановления. Главной задачей становится
восстановление за время, не превышающее порогового значения между сбоем
и отказом. В результате можно преобразовать отказы в сбои и тем самым
улучшить показатели надежности функционирования системы. Для решения
этой задачи в комплексе программ должны быть средства, позволяющие:
проводить систематический контроль и обнаруживать
аномалии процесса функционирования или состояния программ и
данных;
диагностировать обнаруженные искажения;
выбирать методы и средства оперативного восстановления
(рестарта);
реализовывать оперативное восстановление нормальной
работоспособности;
регистрировать каждый происшедший сбой или отказ и
обобщать с данными предыдущих искажений для выявления
систематических случаев, требующих доработки программ или
аппаратуры.
Реализация средств с такими функциями осуществляется за счет
введения избыточности в программы, данные и процесс функционирования
комплекса программ:
программной, включающей все программные компоненты,
предназначенные для контроля, обнаружения, диагностики и
восстановления работоспособности комплекса программ;
информационной,
заключающейся
в
дублированном
хранении данных и средств кодовой помехозащиты информации;
временной, состоящей в выделении необходимых резервов
процессорного времени ЭВМ на исполнение программ, обеспечивающих
оперативный контроль и восстановление (рестарт) функционирования
комплекса программ.
Перечисленные виды избыточности используются совместно и требуют
некоторых ресурсов ЭВМ по объему оперативной памяти, памяти команд и
производительности. Доля этих ресурсов обычно находится в пределах 5...10 %
от максимального значения, однако при таких даже относительно небольших
затратах надежность функционирования (наработка на отказ) программ
возрастает на один-два порядка.
Критерии надежности программ. Критерии, используемые в теории
надежности, являются статистическими и в том или ином виде учитывают
временные показатели. В зависимости от целевого назначения систем для
анализа показателей надежности их целесообразно разделить на два класса:
невосстанавливаемые и восстанавливаемые. Для оценки надежности
восстанавливаемых систем (программ) необходимо знать характеристики
многократных отказов и восстановлений в процессе их функционирования.
Процесс восстановления достаточно полно описывается показателями:
вероятностью восстановления за некоторое время, плотностью распределения
времени восстановления и средним временем восстановления.
Объединение характеристик отказов и восстановлений производится в
следующих критериях: наработка на отказ и коэффициент готовности.
Значение коэффициента готовности соответствует доле времени полезной
работы программ на достаточно большом интервале, содержащем отказы и
восстановления. Для оценки стареющей и разрушающейся аппаратуры в теории
надежности вводится "ряд показателей, которые неприменимы к сложным
комплексам программ.