Надежность программного обеспечения компьютера

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Курсовой проект

Надежность программного обеспечения компьютера

1. Основные понятия и определения

программный ошибка компьютер

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

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

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

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

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

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

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

1) в результате выполнения программы для каждого множества входных данных получаем однозначный выходной результат;

2) множество входных данных определяет все вычисления, выполняемые программой;

3) каждая ошибка в программе вызывает сбои для некоторой части входных данных;

4) пропуск программы с некоторым подмножеством входных данных представляет собой единичное наблюдение ее действия.

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

=0, если выходной результат верен для ;

=1, в противном случае.

Вероятность безотказной работы ПО будет представлена как

(2.1)

где п - число всевозможных входов ПО.

Надежность R для некоторого рабочего участка может быть определена как

(2.2)

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

(2.3)

При равномерном распределении испытуемых входов во входном множестве и при достаточно большом п

(2.4)

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

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

(2.5)

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

(2.6)

Здесь может быть получено на основании зависимости (2.5).

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

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

и (2.7)

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

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

(2.8)

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

Программное обеспечение становится совершенным тогда, когда

(2.9)

т.е. в точке, где прямая линия b пересекает горизонтальную ось.

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

(2.10)

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

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

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

обслуживаемость системы - степень влияния ошибок программного обеспечения на обслуживаемость системы;

безотказность системы - частота системных отказов, вызываемых ошибками программного обеспечения.

С учетом сложившейся практики выбора критериев оценки надежности необходимо принимать во внимание следующее:

1) разработанное программное обеспечение в начальной стадии эксплуатации может потребовать менее жестких критериев и большего времени для его совершенствования;

2) после выпуска новой версии некоторое время потребуются также менее строгие критерии качества ПО;

3) имеют место разбросы, вызываемые различием в условиях применения и использования ПО;

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

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

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

3. Четыре подхода к надежности

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

Предупреждение ошибок

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

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

2. Методы достижения большей точности.

3. Методы улучшения обмена информацией.

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

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

Обнаружение ошибок

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

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

Исправление ошибок

Следующий шаг - методы исправления ошибок; после того как ошибка обнаружена, либо она сама, либо ее последствия должны быть исправлены программным обеспечением. Исправление ошибок самой системой - плодотворный метод проектирования надежных систем аппаратного обеспечения. Некоторые устройства способны обнаружить неисправные компоненты и перейти к использованию идентичных запасных. Аналогичные методы неприменимы к программному обеспечению вследствие глубоких внутренних различий между сбоями аппаратуры и ошибками в программах. Если некоторый программный модуль содержит ошибку, идентичные «запасные» модули также будут содержать ту же ошибку.

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

Устойчивость к ошибкам

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

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

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

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

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

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

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

4. Обнаружение ошибок

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

Меры по обнаружению ошибок можно разбить на две подгруппы:

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

Пассивное обнаружение ошибок

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

Разрабатывая эти меры, мы будем опираться на следующие положения:

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

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

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

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

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

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

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

4. Проверяйте допустимость всех вариантов значений. Если входное поле - код, обозначающий один из десяти районов, никогда не предполагайте, что если это не код ни одного из районов 1, 2,…, 9, то это обязательно код района 10.

5. Если во входных данных есть какая-либо явная избыточность, воспользуйтесь ею для проверки данных.

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

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

Когда разрабатываются меры по обнаружению ошибок, важно принять согласованную стратегию для всей системы (т.е. применить идею концептуальной целостности). Действия, предпринимаемые после обнаружения ошибки в программном обеспечении (например, возврат кода ошибки), должны быть единообразными для всех компонент системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение - немедленно завершить выполнение программы или (в случае операционной системы) перевести ЦП в состояние ожидания. С точки зрения предоставления человеку, отлаживающему программу, например системному программисту, самых благоприятных условий для диагностики ошибок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что приостанавливать работу системы нельзя). В таком случае используется метод регистрации ошибок. Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняется во внешнем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом. Такой метод использован в операционной системе OS/VS2MVS фирмы IBM. Каждая компонента содержит программу восстановления, которая перехватывает все случаи ненормального завершения и программные прерывания в этой компоненте и регистрирует данные об ошибке во внешнем файле.

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

Пример: система PRIME

Система PRIME-это мультипроцессорная система с виртуальной памятью, разработанная в Калифорнийском университете в Беркли. Ее упрощенная схема показана на рис. 4.1. Один из процессоров системы выделен в качестве центрального процессора и содержит центральный управляющий монитор (ССМ - central control monitor) - управляющую программу, которая распределяет страницы памяти и пространство на диске, назначает программы другим процессорам (проблемным процессорам) и регулирует пересылки всех межпроцессорных сообщений. Расширенный управляющий монитор (ЕСМ - extended control monitor) - это реализованная микропрограммно-управляющая программа, постоянно присутствующая в каждом процессоре и управляющая диспетчеризацией процессов, операциями ввода-вывода и посылки / получения.

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

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

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

Система PRIME содержит механизм посылки / получения, который позволяет процессу одного пользователя послать сообщение процессу другого пользователя. Для этого процесс-отправитель передает своему ЕСМ это сообщение и идентификатор процесса-получателя. ЕСМ добавляет идентификатор отправителя и передает сообщение ССМ. Тот передает сообщение ЕСМ процессора, содержащего процесс-получатель, а ЕСМ наконец передает сообщение указанному процессу пользователя. В этой последовательности выполняются три проверки с целью обнаружения ошибки. ССМ проверяет, правильный ли идентификатор процесса-отправителя добавлен ЕСМ; он может это сделать, поскольку известно, какому пользователю выделен процессор. ЕСМ адресата проверяет, тому ли процессору ССМ направил сообщение; он выполняет это, сравнивая идентификатор процесса в сообщении с идентификатором процесса, которому в данный момент выделен процессор. Третья проверка делается для обеспечения сохранности сообщения при транзите. ЕСМ-отправитель формирует для сообщения контрольную сумму и передает ее вместе с сообщением. ЕСМ-получатель вычисляет контрольную сумму доставленного сообщения и сравнивает с извлеченной из сообщения.

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

Активное обнаружение ошибок

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

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

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

Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вызывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время выполнения. Монитор может также периодически предъявлять системе «пустые» или «легкие» задания, чтобы убедиться, что система функ - ционирует хотя бы самым примитивным образом.

Пример: программа обнаружения разрушений, разработанная фирмой TRW

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

Этот монитор проверяет много различных условий. Большинство из них характерно именно для OS/360 и поэтому интересны не для всех. В качестве некоторых примеров, можно, однако, указать, что монитор определяет, вся ли управляющая информация OS/3CO о задачах пользователя хранится в защищенной области памяти. Монитор также проверяет, всели программы пользователя выполняются в режиме задачи и вся ли память пользователя защищена от выборки соответствующим ключом защиты. Монитор контролирует правильность соблюдения очереди ожидающими операциями ввода-вывода и гарантирует, что точки входа для всех прерываний являются соответствующими входами OS/360 и что вся память супервизора надлежащим образом защищена. Как только обнаруживается какое-то несоответствие, немедленно выдается сообщение оператору.

5. Исправление ошибок и устойчивость к ошибкам

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

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

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

Пример: система обслуживания телефонных станций TSPS фирмы «Белл»

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

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

Телефонная сеть представлена таблицами в основной памяти, которые хранятся как множество связанных линейных списков. Например, список на рис. 5.1 может представлять все соединения сети, находящиеся в активном состоянии. В этом списке наблюдается существенная избыточность. Например, каждый блок имеет свой тэг, последний блок определяется по двум признакам, и в поле состояния каждого блока в этом списке должно быть установлено значение «активно». Монитор (называемый в TSPS audit program) периодически просматривает списки. Если обнаруживается противоречие, например в поле СЛЕДУЮЩИЙ некоторого блока указан неправильный адрес (что обнаруживается по несоответствию тэга блока, находящегося по этому адресу), то список обрывается после последнего правильного блока и в каждом правильном блоке значение бита L (от английского слова lost - потеряно) устанавливается равным 1. Другая компонента монитора периодически просматривает последовательно блоки всех линий. Если бит L блока. равен 0 (что значит, что он «потерян»), блок включается в список незанятых линий соответствующего типа. Эти действия могут привести к разрыву телефонной связи, но сохраняют работоспособность всей системы.

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

Механизм исправления ошибок в TSPS ежедневно исправляет довольно много ошибок. Установка TSPS после трех лет работы выполняет в среднем от 10 до 100 реальных исправлений в день и примерно раз в два месяца - автоматический повторный запуск.

6. Изоляция ошибок

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

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

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

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

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

5. Прикладные программы не должны иметь возможности ни остановить систему, ни вынудить ее. изменить другую прикладную программу или ее данные.

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

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