Надёжность программного обеспечения
Надёжность программного обеспечения | areliability.com блог инженера по надёжности
Статья обновлена 23.04.2020
Надёжность программного обеспечения. Введение
На предприятиях космической отрасли ситуация ещё лучше. Когда я спросил у специалистов одного уральского НПО, как они считают надёжность программного обеспечения, они сделали круглые глаза и сказали: «А чё там, за единицу берём да и всё. А надёжность обеспечиваем отработкой». Я согласен, что такой подход имеет право на жизнь, однако хотелось бы большего. Короче, я написал свою методику, прошу любить и жаловать. Внизу привожу калькулятор, на котором можно посчитать надёжность этого вашего ПО.
Проблема надёжности программного обеспечения приобретает все большее значение в связи с постоянным усложнением разрабатываемых систем, расширением круга задач, возлагаемых на них, а, следовательно, и значительным увеличением объемов и сложности ПО. Короче, мы дожили до того дня, когда железо стало надёжнее софта, и одна ошибка в программном коде может угробить космическую миссию ценой в миллиарды долларов.
По факту, пообщавшись с коллегами по надёжности и функциональной безопасности, мы коллективно пришли к выводу, что оценивать ВБР (вероятность безотказной работы) ПО не имеет смысла. ПО это тот объект, для которого малоприменимы хорошо отработанные методики оценки надёжности, используемые при оценке компонентов, агрегатов и систем.
Если вы хотите хорошо разбираться в вопросах надежности техники и стать высокооплачиваемым специалистом, приглашаю вас пройти мой курс по обучению надёжности.
Надёжность программного обеспечения обуславливается наличием в программах разного рода ошибок, внесенных в неё, как правило, при разработке. Под надёжностью ПО будем понимать способность выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям исполнения. Под ошибкой понимают всякое невыполнение программой заданных функций. Проявление ошибки является отказом программы.
Показатели надёжности ПО
Наиболее распространенными показателями надёжности ПО являются следующие:
– начальное число ошибок N0 в ПО после сборки программы и перед её отладкой;
– число ошибок n в ПО, обнаруженных и оставшихся после каждого этапа отладки;
– наработка на отказ (MTBF), часов;
– вероятность безотказной работы (ВБР) ПО за заданное время работы P(t);
– интенсивность отказов ПО λ, 10-6 1/ч.
Упрощенная оценка надёжности ПО
Сперва рассмотрим методики, которые предлагаем нам отечественная нормативная база. Единственный нормативный документ по данной теме это ГОСТ 28195-99.
Оценка надежности ПО по ГОСТ 28195-99 рассчитывается по весьма упрощенной методике, констатирующей фактическую надёжность по опыту эксплуатации программного комплекса P(t) 1-n/N, где n – число отказов при испытаниях ПО; N – число экспериментов при испытаниях. Очевидно, что посчитать по этой методике ничего нельзя.
Статистическая оценка надёжности ПО
Куда больший интерес представляет описанная в [1] среднестатистическая оценка начального числа N0 ошибок в ПО после автономной отладки. Согласно данной оценке, количество ошибок на 1 К слов кода составляет 4,34 для языков низкого уровня (Ассемблер) и 1,44 для языков высокого уровня (С++). К сожалению, не совсем понятно, что имели в виду авторы под фразой «1 К слов кода». В англоязычной литературе принято использовать параметр тысяча строк кода (ТСК) (KLOC). Так, согласно [3] для операционной системы Windows 2000 плотность ошибок составляет 1,8-2,2 на ТСК. Учитывая, что Windows 2000 написан на языке программирования C и имеет близкую размерность числа ошибок, можно с высокой долей достоверности предположить, что отечественный авторы имели в виду именно параметр ТСК.
Отечественные авторы в [1] приводят статистические показатели интенсивности отказов ПО λ. Приведём их в таблице 1.1.
Таблица 1.1 
К сожалению, для какого языка ПО это действительно, авторы не сказывают. Кроме того, вводятся поправочные коэффициенты:
Таблица 1.2 
И коэффициент, отражающий влияние времени работы программы:
Таблица 1.3 
Тогда интенсивность отказов ПО λ определяется с помощью таблиц 1.1-1.3 по выражению:
λ по = λ* Кр* Кк* Кз* Ки (1.1)
Далее, используя экспоненциальную модель надёжности (при использовании данной модели поток отказов считается постоянным), можно получить ВБР ПО по стандартной формуле надёжности:
Количественная модель оценки надёжности ПО
В основе данной модели лежит моё предположение, что уровень надежности ПО зависит от объема ПО (в битах или тысячах строк кода). Это утверждение не противоречит классической теории надежности, согласно которой чем объект сложнее, тем ниже его надёжность. Логично же. Чем больше будет строк кода, тем больше в итоге будет ошибок и тем ниже будет вероятность безотказной работы программы.
Используем оценку количества ошибок в зависимости от языка разработки из статистической модели:
Далее, из [3] взята статистическая оценка связи количества строк кода и битов.
Для языка C, согласно [3] одна строка кода содержит 17 ± 3 байтов (146 битов) информации.
Зная V, объём кода ПО, в битах, мы можем получить число строк этого кода. Удобнее использовать параметр ТСК.
Используя данные таблицы 1.4 можно получить β, коэффициент количества ошибок на тысячу строк кода:
Объем ПО составляет 10 Мб. Язык разработки С++.
Тогда, согласно 1.3-1.4, β составит 0,08
Данный показатель очень близок к результату Примера 1.
Очевидно, чем дольше работает программа, тем выше вероятность, что она откажет.
Используя экспоненциальную модель надёжности (при использовании данной модели поток отказов считается постоянным), можно получить ВБР ПО:
Резюмируя, для того чтобы оценить надёжность программного обеспечения, необходимо знать его язык разработки (высокий или низкий) и объём кода ПО.
[1] Надёжность авиационных приборов и измерительно-вычислительных комплексов, В.Ю. Чернов/ В.Г. Никитин; Иванов Ю.П. – М. 2004.
[2] Надёжность и эффективность в технике: Справочник., В.С. Авдуевский. 1988.
[3] Estimating source lines of code from object code, L. Hatton. 2005.
Попробуйте теперь что-нибудь посчитать. Например, найдите надёжность программного обеспечения, объём которого 100 Мб, и которое должно проработать 100 часов. Важно! Обратите внимание, что λ при изменении объёма ПО каждый раз пересчитывается под конкретный размер ПО.
Валидация модели. Согласно этому сайту надёжность (вероятность безотказной работы) Windows 7 Home Premium составляет 0.98. Правда неизвестно, для какого времени работы сделан расчёт.
Если вы хотите хорошо разбираться в вопросах надежности техники и стать высокооплачиваемым специалистом, приглашаю вас пройти мой курс по обучению надёжности.
К вероятностной оценке надёжности программного обеспечения
Автор: Алексей Глазачев · Опубликовано 27.01.2021 · Обновлено 28.01.2021
Ещё про надёжность программного обеспечения
В моем предыдущем статье о надёжности программного обеспечения я не углублялся в различные подходы к надёжности программного обеспечения. Моя главная мысль состояла в том, чтобы показать, что моделирование надёжности программного обеспечения — это важно. Что инженеры по надёжности и функциональной безопасности должны стремиться понять этот процесс и использовать его.
Сегодня хочу поговорить о применимости/неприменимости вероятностной оценки надёжности программного обеспечения. Статья в значительной степени опирается на работу доктора Бева Литтлвуд, которая является одним из пионеров надёжности программного обеспечения.
IEC 61508 даёт нам варианты
Инженеры по функциональной безопасности знают, что стандарт IEC 61508 (и его дочерние стандарты IEC 61511 и ISO 26262) не требуют от вас количественной оценки так называемых систематических отказов, включая отказы программного обеспечения. А вот что большинство не знает, так это то, что IEC 61508 дает нам возможность количественно оценить отказы программного обеспечения в части 7 Приложения D. По моему опыту, это почти никто не делает.
Методы, описанные в Приложении D, довольно просты, хотя предварительные требования для оценки и анализа могут быть труднодостижимыми. Надёжность программного обеспечения моделируется либо по схеме испытаний Бернулли (для информационно-управляющих систем (ИУС) с низким количеством к ним запросов), либо как однородный процесс Пуассона (для ИУС с высоким количеством к ним запросов или ИУС непрерывного действия).
Одна из статей, на которую ссылается Литтлвуд, — это статья 1991 года, демонстрирующая невозможность количественной оценки надежности критически важного программного обеспечения традиционными методами. Статья доктора Литтлвуда убедительно доказывает, что проверка надёжности систем сверхвысокой надежности является крайне нетривиальной проблемой.
Выхода нет
Если подход, описанный в IEC 61508, неосуществим для большинства приложений, что нам делать? Мы можем вернуться к более ранним работам доктора Литтлвуда, чтобы почерпнуть некоторые идеи.
Одной из основополагающих работ в области надёжности программного обеспечения является статья Литтлвуда 1993 года «Валидация сверхвысокой надёжности программного обеспечения». Ключевым наблюдением из этой статьи является:
…достоверность наших результатов зависит от достоверности допущений моделирования. Всегда есть шанс, что реальность нарушит некоторые из этих предположений: нам нужно сформировать представление о вероятности этого события. Примерами таких предположений являются:
• в моделировании роста надёжности: регулярность процесса роста и, в частности, реалистичность тестовых данных по отношению к предполагаемой операционной среде.;
• в статистических аргументах, основанных на процессе: репрезентативность нового наблюдения по отношению к известной выборке, из которой производятся статистические экстраполяции.;
• в моделировании структурной надёжности: корректность параметров, полнота модели (например, допущения независимости, переходы в марковской модели, ветви в дереве отказов);
• в доказательствах правильности: соответствие спецификации неформальной инженерной модели.
Ещё более краткое и смелое резюме можно найти в аннотации (выделено курсивом):
Инженерная практика должна учитывать тот факт, что в настоящее время не существует решения для валидации сверхвысокой надёжности систем, опирающихся на сложное программное обеспечение.
Короче говоря, никакого решения не существовало, но мы все равно пытались это сделать, даже если методов было недостаточно. Это было в 1993 году. Стали ли мы лучше за 25 лет?
Важное примечание: рассмотренные системы сверхвысокой надёжности, имели цели по ВБР (вероятности безотказной работы) в диапазоне от 10E-7 до 10E-9, эквивалентные IEC 61508 «SIL 6» или лучше (стандарт останавливается на SIL 4). Для систем с менее чем сверхвысокой надёжностью результат, вероятно, изменится от «нет решения» до «очень трудно достичь».
От невозможного к возможному
Чтобы помочь ответить на этот вопрос, мы можем вернуться к Литтлвуду. Кто-то задал ему вышеупомянутый вопрос, и результатом стала статья 2011 года «Валидация сверхвысокой надёжности. » – 20 лет спустя.
После обобщения оригинальной статьи в ней отражается прогресс, достигнутый за последние двадцать лет, включая некоторые области, в которых, по мнению автора, был достигнут незначительный прогресс.
IEC 61508 не существовал в 1993 году, поэтому неудивительно, что в документе содержится стандарт DO-178B (1992), заключающийся в использовании «передовой практики» для качественного обоснования целевых показателей эффективности, которые никогда не проверяются количественно.
В статье также выражается сожаление по поводу того, что до сих пор существуют разногласия относительно использования вероятностных подходов для обеспечения надёжности программного обеспечения. Критики утверждают, что вероятностные методы могут быть «опасным искушением для самообмана». Эта аргументация приводит к одному из ключевых утверждений статьи:
Строгая и формальная трактовка этой «эпистемической» неопределенности представляется необходимой, а использование вероятностей дает преимущества единого подхода к различным источникам неопределенности. Такой вероятностный аргумент может иногда показать, что у нас есть ограниченные основания для уверенности в системе до начала эксплуатации (например, уверенность в том, что эта система управления полётом имеет частоту отказов меньше, чем 10-9 в час). Это преимущество, а не недостаток вероятностного подхода, если мы хотим чтобы практика оценки рисков была полезной для инженерной деятельности и общественности.
Строго относиться к эпистемической неопределенности?
Вы поняли: байесовский подход. Действительно, когда мы смотрим на другую работу Литтлвуда, мы можем обнаружить, что байесовский вывод используется для построения «многоногих» аргументов надёжности, которые количественно объединяют различные типы доказательств из разных источников. После долгого обсуждения всех проблем это дает надежду на практические решения.
«Измерьте то, что можно измерить, и сделайте измеримым то, что нельзя измерить». – Галилей
Резюме
В этом посте речь шла не только о надёжности программного обеспечения, но и о некоторых проблемах, с которыми инженеры сталкивались в прошлом, пытаясь количественно оценить и предсказать надёжность программного обеспечения.
Этот пост получился длинным по проблемам и коротким по решениям. В следующий раз мы рассмотрим подход «многоногих» аргументов и посмотрим, как байесовский вывод помогает в решении.
Эпистемоло́гия (от др.-греч. ἐπιστήμη «научное знание, наука», «достоверное знание» + λόγος «слово», «речь») — философско-методологическая дисциплина, исследующая знание как таковое, его строение, структуру, функционирование и развитие. Нередко (особенно в английском языке) слово выступает как синоним гносеологии.
Гносеоло́гия (от др.-греч. γνῶσις «познание», «знание» + λόγος «слово», «речь») — философская дисциплина, занимающаяся исследованиями, критикой и теориями познания.
Тенденция к разграничению этих двух понятий характерна для неклассической (современной) философии, и при таком подходе:
• гносеология изучает отношение «субъект-объект»;
• эпистемология изучает отношение «объект-знание».
Основные показатели надежности программного обеспечения (ПО). Математические модели оценки надежности ПО.
13.1. Основные показатели надежности программного обеспечения (ПО).
Надежность программного обеспечения отличается от надежности технических средств следующим:
Основные понятия, связанные с надежностью программного обеспечения:
Дать строгое определение программной ошибки непросто, поскольку это определение, является функцией от самой программы, то есть зависит от того, какого функционирования ожидает от программы пользователь. По этой причине вместо строгого определения будут перечислены только признаки, указывающие на наличие ошибки в программе:
Этот список можно считать открытым, поскольку он может быть продолжен разработчиками по мере накопления ими опыта в повышении надежности программного обеспечения.
Все же чаще всего под ошибкой (или отказом) программы понимают всякое невыполнение программой функций, которые были предусмотрены в техническом задании на ее разработку или вытекают непосредственно из инструкций пользователю. Является некорректным относить к ошибкам, например, необходимость написания программного кода, заменяющего какую-либо временно отсутствующую часть программы, или же необходимость рекомпиляции, вызванную изменениями в других модулях.
Количество оставшихся в программе ошибок – это количество ошибок, которые потенциально могут быть обнаружены на последующих стадиях жизненного цикла программы, после исправлений, внесенных в программу на текущей стадии ее жизненного цикла. Это количество оставшихся в программе ошибок (обозначаемое далее как B) – один из важнейших показателей надежности ПО.
Пусть P(t) — вероятность того, что ни одной ошибки не будет обнаружено на временном интервале [0,t]. Тогда вероятность хотя бы одного отказа за этот период будет Q(t) = 1 – P(t), и плотность вероятности можно записать как
Рассмотрим функцию риска R(t), как условную плотность вероятности отказа программы в момент времени t, при условии, что до этого момента отказов не было
Функция риска имеет размерность [1/время] и она очень полезна при классификации основных распределений отказов. Распределения с возрастающей функцией риска соответствуют тем ситуациям, когда статистические характеристики надежности ухудшаются со временем. И наоборот, распределения с убывающей функцией риска соответствуют обратной ситуации, когда надежность улучшается со временем в результате процесса обнаружения и коррекции ошибок.
Равенство (13.2) является одним из самых важных в теории надежности. В дальнейшем будет показано, что различные виды поведения функции риска во времени порождают различные возможности для построения моделей надежности ПО. Интенсивность обнаружения ошибок (функция риска), вместе с вероятностью безотказной работы программы и количеством оставшихся в программе ошибок, являются важнейшими показателями надежности программ.
Прогон программы – это набор действий, включающий в себя: ввод в программу одной из возможных комбинаций Ei пространства входных данных E (); выполнение программы, которое заканчивается либо получением результата F(Ei), либо отказом.
Случаи, описанные неравенством (13.4), называются отказами программы.
Рассмотрим дихотомическую переменную :
Тогда статистическая оценка вероятности отказа программы в течении m прогонов будет равна:
И наконец, еще один показатель надежности ПО, который тоже будет использоваться в этой работе – среднее время наработки программы до отказа:
Опыт разработки ПО показывает, что выявление ошибок и их исправление связано с определенными затратами, которые составляют цену ошибки. По мере перехода к более поздним стадиям разработки цена ошибки возрастает:
13.2. Математические модели оценки надежности ПО.
Модели надежности ПО служат для предсказания значений метрик, позволяющих оценить надежность на различных этапах тестирования программного продукта. Например, в том случае, если к некоторому моменту тестирования количество обнаруженных и исправленных ошибок уже достаточно велико, это может создать впечатление, что тестирование продукта близится к завершению, то есть ошибок в программе осталось немного. Однако, это может совершенно не соответствовать действительности, и как раз использование моделей надежности программ может помочь прояснить подобную ситуацию.
Математические модели надежности программ можно разбить на группы по следующим признакам:
Модели, основанные на использовании функции риска
Модель Джелинского-Моранды.
Это одна из первых и простейших моделей классического типа, послужившая основой для дальнейших разработок в этом направлении. Модель была использована при разработке таких значительных программных проектов, как программа Аполло (некоторых ее модулей). Модель Джелинского-Моранды основана на следующих предположениях:
Согласно этим предположениям, функция риска будет представлена как:
В этой формуле t – это произвольный момент времени между обнаружением (i-1)-й и i-й ошибок; K – неизвестный коэффициент масштабирования; B – начальное количество оставшихся в программе ошибок (также неизвестное). Таким образом, если в течении времени t было обнаружено (i-1) ошибок, это означает, что в программе еще остается B-(i-1) необнаруженных ошибок. Полагая, что
и используя предпосылку 6, а также равенство (13.2), можно заключить, что все Xi имеют экспоненциальное распределение
и плотность вероятности отказа, соответственно, равна
Тогда функцию правдоподобия (согласно предпосылке 2) можно записать как
или, переходя к логарифму функции правдоподобия, имеем
Максимум функции правдоподобия можно найти, используя следующие условия
Из формулы (13.3) получается оценка максимального правдоподобия для K
Подставляя выражение (13.5) в (13.4), находим нелинейное уравнение для вычисления –оценки максимального правдоподобия для B
Это уравнение можно упростить перед тем, как искать его решение, если записать его с использованием следующих обозначений
Поскольку правая и левая части выражения (13.7) одинаково монотонны, это порождает проблему единственности решения, а также проблему его существования. Конечное решение в области существует тогда и только тогда, когда выполняется неравенство
В противном случае оценка максимального правдоподобия будет Условие (13.8) можно переписать в более удобном виде
где A – то же самое выражение, что и в формуле (13.7). Необходимо отметить, что, A является интегральной характеристикой n встретившихся в программе за время тестирования ошибок, и представляет (в статистическом смысле) набор интервалов Xi между ошибками.
Наилучшим решением для уравнения (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)
Если рассмотреть начальные значения N(0)=0, R(0)=KB, то решением уравнения (3.10) будет
Оценки параметров К и В можно получить аналогично модели Джелинского-Моранды и затем с помощью оценки функции риска можно спрогнозировать ситуацию на следующие этапы отладки.
Модель Шика-Уолвертона.
Эта модель основана на предположении, что функция риска пропорциональна не только количеству ошибок в программе, но и продолжительности процесса тестирования. Кроме того, предполагается, что чем дольше ПО тестируется, тем больше появляется шансов на обнаружение последующих ошибок, поскольку в процессе отладки некоторые участки программы «подчищаются», что облегчает ее дальнейшее тестирование.
Модель основана на следующих предположениях:
Функция риска для данной модели:
Вероятность безотказного функционирования программы на интервале Xi равна:
что дает плотность вероятности отказа
Эти модели являются обобщением моделей Джелинского-Моранды и Шика-Уолвертона. В отличие от этих моделей, модели Липова допускают более одной ошибки в интервале тестирования, и кроме того, допускают, что не все из ошибок, обнаруженных а этом интервале, могут быть исправлены. Первая модель Липова (обобщение модели Джелинского-Моранды) основана на следующих предположениях:
Вторая модель Липова (обобщение модели Шика-Уолвертона) основана на следующих предположениях. Интенсивность обнаружения ошибок пропорциональна текущему количеству ошибок вПО и общему времени, затраченному на его тестирование, включая также «среднее» время поиска ошибки, обнаруженной на интервале тестирования. С учетом этих предположений, функция риска задается следующим выражением:
В этом разделе рассмотрен пример геометрической модели, предложенной П. Б. Морандой и являющейся модификацией модели Джелинского-Моранды.
Исходя из этих предположений, функцию риска можно записать следующим выражением:
где t – временной интервал между обнаружением (i-1)-ой и i-той ошибок. Начальное значение этой функции R(0) = D, и функция риска убывает со скоростью геометрической прогрессии (0
Лекция 15. Методы повышения надежности программ и оценка эффективности их применения.
15.1. Влияние избыточности на повышение надежности программ
Так как в программах нет необходимости “ремонта” компонент с участием человека, то можно добиваться высокой автоматизации программного восстановления. Главной задачей становится восстановление за время, не превышающее порогового значения между сбоем и отказом. Автоматизируя процесс и сокращая время восстановления, можно преобразовать отказы в сбои и тем самым улучшить показатели надежности функционирования системы.
Временная избыточность состоит в использовании некоторой части производительности ЭВМ для контроля исполнения программ и восстановления вычислительного процесса. Величина временной избыточности зависит от требований к надежности функционирования системы и находится в пределах от 5-10% производительности однопроцессорной ЭВМ до трех-четырех кратного дублирования производительности машины. Временная избыточность используется на обнаружение искажений, их диагностику и на реализацию операций восстановления. На это требуется в общем случае небольшой интервал времени, который выделяется либо за счет резерва, либо за счет сокращения времени решения функциональных задач.
Информационная избыточность состоит в дублировании накопленных исходных и промежуточных данных, обрабатываемых комплексом программ. Избыточность используется для сохранения достоверности данных, которые в наибольшей степени влияют на нормальное функционирование программ или требуют значительного времени восстановления.Для менее важных данных информационная избыточность используется в виде помехозащитных кодов, позволяющих только обнаружить искажение.
Программная избыточность используется для контроля и обеспечения достоверности наиболее важных решений по управлению и обработке информации. Она заключается в применении нескольких вариантов программ, различающихся методами решения задачи или программной реализацией одного и того же метода. Программная избыточность необходима также для реализации программ контроля и восстановления данных с использованием информационной избыточности и для функционирования всех средств защит, использующих временную избыточность.
Эффективность применения избыточности для повышения надежности комплексов программ.
Выше рассмотрены принципы использования временной, информационной и программной избыточности для обеспечения надежности программ. Здесь представлены некоторые рекомендации, позволяющие оценить эффективность использования избыточности. Наибольшее внимание уделяется временной избыточности, которая эффективно используется для оперативной защиты при отказовых ситуациях и непосредственно влияет на надежность функционирования программ.
Эффективность оперативного использования временной избыточности для повышения надежности функционирования программ определяется затратами на контрольно-восстановительные операции изменением показателей надежности в зависимости от затрат и связью этих изменений с отлаженностью программ В результате для оценки эффективности введения временной избыточности в программе необходимо
* определить совокупные затраты на контроль на работу при необнаруженном искажении и на восстановление обеспечивающие заданную вероятность обнаружения отказовой ситуации при исполнении программ
* определить основные показатели надежности функционирования программ в зависимости от совокупных затрат на оперативный контроль и восстановление
* оптимизировать суммарные затраты на отладку программ и оперативную защиту от искажений для обеспечения заданной надежности функционирования комплекса программ
При решении последней задачи источниками искажений предполагаются только невыявленные ошибки в программах
Влияние оперативного контроля и восстановления на производительность ЭВМ
Использование времени функционирования ЭВМ для контроля работоспособности исправления искажений и восстановления при отказовых ситуациях приводит к снижению затрат производительности ЭВМ на исполнение комплекса программ в процессе эксплуатации В результате сокращаются ресурсы ЭВМ доступные для выполнения основных функций системы Это сокращение ресурсов можно отразить коэффициентом простоя ЭВМ Кп = 1 — Кг характеризующим относительные затраты времени на задачи повышения помехозащищенности программ По мере совершенствования и углубления средств помехозащиты программ возрастают затраты времени ЭВМ на их исполнение что отражается на снижении реальной эффективности функционирования комплекса программ
Целесообразно исследовать влияние использования временной избыточности на сокращение полезной производительности ЭВМ для решения функциональных задач а также на снижение потерь вследствие отказов После определения этих составляющих можно провести их совместный анализ для оптимизации глубины помехозащиты программ с учетом затрат на ее реализацию
Методы обеспечения надежности программ.
Основные факторы, определяющие надежность программ.
Надежность функционирования комплексов программ зависит от многих факторов, которые можно объединить в три группы (табл.. 12).
n факторы,непосредственно определяющие возникновение отказов, и характеристики надежности программ;
n методы, способствующие проектированию корректных программ, снижающие вероятность программных ошибок и отказовых ситуаций при исполнении программ;
n метод, активно влияющие на повышение надежности функционирования программ позволяющие контролировать и поддерживать заданные показатели надежности.
Факторы, непосредственно определяющие надежность программ
Методы проектирования корректных программ
Методы контроля и обеспечения надежности программ
Особенности внешних абонентов и пользователей результатов программ
Структурное проектирование программ и данных
Методы использования избыточности
Требования к показателям надежности
Структурное проектирование программных модулей
Инерционность внешних абонентов
Структурное проектирование взаимодействия модулей
Методы контроля программ, данных и вычислительного процесса
Необходимое время отклика на входные данные
Оперативный контроль
Искажения исходных данных
Тестирование программ
Методы программного восстановления
Восстановление текстов программ
Корректировка вычислительного процесса
Динамическое тестирование и контроль пропускной способности в реальном времени
Методы испытаний на надежность
Форсированные испытания
Ошибки в программах и их проявление
Статистические характеристики ошибок и искажений:
Методы обеспечения надежности при сопровождении
Отказы при функционировании программ возникают вследствие взаимодействия данных и ошибок в программе. Характеристики ошибок в значительной степени определяются методами проектирования программ.Активные методы обнаружения и локализации программных ошибок базируются на тестировании различных видов: детерминированном, статистическом и динамическом. Однако все виды тестирования не гарантируют отсутствие ошибок в комплексах программ и высокую надежность. Для этого применяются методы контроля и обеспечения надежности программ путем использования программной, временной и информационной избыточности.
Ситуации проявления ошибок при исполнении программ можно разделить на три группы:
n Отказ — искажения вычислительного процесса, данных или программ, вызывающие полное прекращение выполнения функций системой;
Основным показателем при классификации конкретных видов искажений является возможное время восстановления и степень проявления последствий произошедшего сбоя или отказовой ситуации:
n зацикливание, т.е. последовательная повторяющаяся реализация некоторой группы команд, не прекращающаяся без внешнего (для данного цикла) вмешательства;
n останов исполнения программ и прекращение решения функциональных задач;
n полная самоблокировка вычислительного процесса (клинч) из-за последовательного прекрестного обращения разных программ к одним и тем же ресурсам ЭВМ без освобождения ранее занятых ресурсов;
n прекращение или значительное снижение темпа решения некоторых задач вследствие перегрузки ЭВМ по пропускной способности;
n значительное искажение или полная потеря накопленной информации о текущем состоянии управляемого процесса или внешних абонентов;
n искажение процессов взаимного прерывания программ, приводящее к блокировке возможности некоторых типов прерываний.
Методы программного восстановления.
Выбор метода оперативного восстановления происходит в условиях неопределенности сведений о характере отказовой ситуации и степени ее влияния на работоспособность программ.
Каждый метод восстановления характеризуется следующими статическими параметрами:
n вероятность полного восстановления нормального функционирования комплекса программ при данном методе (p3);
n затратами ресурсов ЭВМ на проведение процедуры восстановительных работ выбранным методом (b3);
n длительностью проведения работ по восстановлению — суммарным временем выбора метода восстановления и временем его реализации(t3)
Показатели восстановления p3и t3непосредственно влияют на показатели надежности функционирования комплекса программ. Если операции по восстановлению работоспособности комплекса программ при отказовой ситуации полностью завершаются за время меньше tд и после этого продолжается нормальное функционирование, то происшедшее искажение в работе программ не учитывается как отказ и не влияет на основные показатели надежности.
Процесс функционирования комплекса программ на однопроцессорной ЭВМ в реальном масштабе времени с учетом операций контроля и восстановления можно представить графом состояний, дуги которого соответствуют возможным переходам между состояниями за некоторый интервал времени.
Основные состояния следующие:
0- состояние соответствует нормальному функционированию работоспособного комплекса программ при полном отсутствии искажений — полезная работа ;
1- состояние имеет место при переходе комплекса программ в режим контроля функционирования и обнаружения ошибок — состояние контроля ;
2- состояние соответствует функционированию программ при наличии искажений, не обнаруженных средствами контроля — состояние необнаруженного искажения данных или вычислительного процесса, которое, в частности может соответствовать отказу;
3- состояние характеризуется функционированием группы программ восстановления режима полезной работы и устранения последствий искажения — восстановление после действительного искажения ;
4- состояние соответствует также восстановлению режима полезной работы, но после ложного обнаружения проявления искажения, когда в действительности состояние полезной работы не нарушалось — восстановление после ложной тревоги .
Переходы между состояниями могут происходить в некоторых направлениях случайно или коррелированно с предыдущем переходом (рис. 5.3, диаграмма 1 ). Пребывание во всех состояниях, кроме нулевого, сопряжено с затратами производительности ЭВМ на выполнение операций, не связанных с прямыми функциональными задачами, и может рассматриваться как снижение общей эффективности комплекса программ и производительности ЭВМ. При определении показателей надежности учитывается только такая цепочка последовательных состояний вне работоспособности, которая оказывается протяженности больше. Все остальные более короткие выходы из нулевого состояния не влияют на показатели надежности.
Методы испытаний программ на надежность.
В теории надежности разработан ряд методов, позволяющих определить характеристики надежности сложных систем. Эти методы можно свести к трем основным группам:
n прямые экспериментальные методы определения показателей надежности систем в условиях нормального функционирования;
n форсированные методы испытаний реальных систем на надежность;
n расчетно-экспериментальные методы, при использовании которых ряд исходных данных для компонент получается экспериментально, а окончательные показатели надежности систем надежности рассчитываются с использованием этих данных.
Прямые экспериментальные методы определения показателей надежности программ в нормальных условиях функционирования в ряде случаев трудно использовать из-за больших значений времени наработки на отказ (сотни и тысячи часов).
Форсированные методы испытаний надежности программ значительно отличаются от традиционных методов испытаний аппаратуры. Форсирование испытаний может выполняться путем повышения интенсивности искажений исходных данных, а также специальным увеличением загрузки комплекса программ выше нормальной.
Особым видом форсированных испытаний является проверка эффективности средств контроля и восстановления программ, данных и вычислительного процесса. Для этого имитируются запланированные экстремальные условия функционирования программ, при которых в наибольшей степени стимулируется работа испытываемого средства программного контроля или восстановления.
Методы обеспечения надежности комплексов программ при сопровождении.
В этой стадии жизненного цикла программ расширяются условия их использования и характеристики исходных данных, вследствие чего могут потребоваться изменения в программах. Для сохранения и улучшения показателей надежности комплексов программ в процессе длительного сопровождения необходимо четко регламентировать передачу комплексов программ пользователям. Целесообразно накапливать необходимые изменения в программах и вводить их группами, формируя очередную версию комплекса программ с измененными характеристиками. Версии комплекса программ можно разделить на эталонные и пользовательские (или конкретного объекта).
Эталонные версии развиваются, дорабатываются и модернизируются основными разработчиками комплекса программ или специалистами, выделенными для их сопровождения. Они снабжаются откорректированной технической документацией, полностью соответствующей программам, и точным перечнем всех изменений введенных в данную версию по сравнению с предыдущей.