Ващенко Г.В., Добронец Б.С. Надежность информационных систем

Подождите немного. Документ загружается.

Федеральное агентство по образованию

Федеральное государственное образовательное учреждение

высшего профессионального образования

«Сибирский федеральный университет»

Г. В. Ващенко, Б. С. Добронец

НАДЕЖНОСТЬ ИНФОРМАЦИОННЫХ СИСТЕМ

Красноярск 2008

УДК 002.6:519.718

ББК

Г. В. Ващенко, Б. С. Добронец Надежность информационных систем:

Учебное пособие, 2008. — 208 с.

В учебном пособии изложены основные разделы теории надежности и ее

приложений к информационным системам. Наиболее важные моменты ил-

люстрируются с помощью рисунков, таблиц и примеров. Пособие написано в

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

дисциплине “Надежность информационных систем”. Рекомендуется для сту-

дентов изучающих информационные системы и может быть полезно студен-

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

Рецензенты:

доктор технических наук, профессор Г. А. Доррер

доктор технических наук, профессор А. Н. Ловчиков

°Г. В. Ващенко, Б. С. Добронец

Оглавление

1 Общие положения теории надежности 9

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

1.2. Показатели качества промышленной продукции . . . . . . . . . 19

1.3. Классификация объектов по надежности . . . . . . . . . . . . . 20

1.4. Классификация отказов . . . . . . . . . . . . . . . . . . . . . . . 21

1.5. Надежность информационных систем . . . . . . . . . . . . . . . 22

1.6. Характеристики надежности при внезапных

и постепенных отказах . . . . . . . . . . . . . . . . . . . . . . . . 29

1.7. Показатели ремонтопригодности . . . . . . . . . . . . . . . . . . 32

1.8. Показатели долговечности . . . . . . . . . . . . . . . . . . . . . . 33

1.9. Показатели сохраняемости . . . . . . . . . . . . . . . . . . . . . 33

1.10. Основы теории восстановления . . . . . . . . . . . . . . . . . . . 34

1.11. Комплексные показатели надежности . . . . . . . . . . . . . . . 37

1.12. Показатели надежности сложных объектов . . . . . . . . . . . . 39

2 Факторы, влияющие на надежность 44

2.1. Факторы, влияющие на снижения надежности ИС . . . . . . . . 44

2.2. Факторы, определяющие надежность информационных систем . 47

2.3. Дестабилизирующие факторы надежности ПО . . . . . . . . . . 48

3 Надежность ПО 59

3.1. Основные показатели надежности ПО . . . . . . . . . . . . . . . 60

3.2. Ошибки, их причины и последствия . . . . . . . . . . . . . . . . 66

4 Проектирование надежного программного обеспечения 70

4.1. Основные принципы проектирования . . . . . . . . . . . . . . . 70

4.2. Процессы проектирования . . . . . . . . . . . . . . . . . . . . . . 74

4.3. Сложность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.4. Решение задачи . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.5. Правильность проектирования . . . . . . . . . . . . . . . . . . . 80

5 Проектирование структуры программы 82

5.1. Независимость модулей . . . . . . . . . . . . . . . . . . . . . . . 83

5.2. Прочность модулей . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.3. Сцепление модулей . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.4. Другие характеристики . . . . . . . . . . . . . . . . . . . . . . . 89

5.5. Композиционный анализ . . . . . . . . . . . . . . . . . . . . . . . 91

5.6. Проверка правильности . . . . . . . . . . . . . . . . . . . . . . . 92

6 Проектирование и программирование модуля 94

6.1. Внешнее проектирование модуля . . . . . . . . . . . . . . . . . 94

6.2. Проектирование логики модуля . . . . . . . . . . . . . . . . . . . 95

6.3. Структурное программирование и пошаговая

детализация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.4. Защитное программирование . . . . . . . . . . . . . . . . . . . . 99

6.5. Стандарты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.6. Проверка правильности . . . . . . . . . . . . . . . . . . . . . . . 101

7 Тестирование программного обеспечения 104

7.1. Принципы тестирования . . . . . . . . . . . . . . . . . . . . . . . 104

7.2. Тестирование модуля . . . . . . . . . . . . . . . . . . . . . . . . . 117

8 Контроль и диагностика ИС 122

8.1. Общие положения . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8.2. Методы аппаратурного контроля . . . . . . . . . . . . . . . . . . 125

8.3. Программно-логические методы контроля . . . . . . . . . . . . 126

8.4. Тестовый контроль . . . . . . . . . . . . . . . . . . . . . . . . . . 128

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

9 Основные расчетные модели для оценки показателей надеж-

ности аппаратуры 136

9.1. Общие зависимости. Оценки показателей

надежности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

9.2. Модель из последовательно соединенных

элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

9.3. Надежность в период нормальной эксплуатации . . . . . . . . . 139

9.4. Надежность в период постепенных отказов . . . . . . . . . . . . 141

9.5. Совместное действие внезапных и постепенных

отказов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

9.6. Надежность восстанавливаемых изделий . . . . . . . . . . . . . 146

10 Испытания на надежность 152

10.1. Значение и виды испытаний на надежность . . . . . . . . . . . . 152

10.2. Задачи, возникающие при испытаниях на надежность . . . . . . 154

10.3. Выводы об испытаниях на надежность

информационных систем . . . . . . . . . . . . . . . . . . . . . . 156

10.4. Понятие и основные требования к организации

научного планирования эксперимента . . . . . . . . . . . . . . . 158

10.5. Планирование эксперимента . . . . . . . . . . . . . . . . . . . . . 161

10.6. Контрольные испытания . . . . . . . . . . . . . . . . . . . . . . . 175

11 Методы повышения надежности 180

11.1. Резервирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

11.2. Повышение надежности функционирования

программных средств за счет избыточности . . . . . . . . . . . . 185

11.3. Способы обеспечения целостности информации

в ИС . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

11.4. Raid-технология . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

11.5. Отказоустойчивые системы . . . . . . . . . . . . . . . . . . . . . 200

11.6. Надежность хранения баз данных . . . . . . . . . . . . . . . . . 203

12 Влияние человека-оператора на функционирование инфор-

мационных систем 211

12.1. Роль оператора в системе “человек — машина — среда” . . . . . 212

12.2. Основные понятия надежности оперативного персонала . . . . . 220

12.3. Понятие отказа оператора . . . . . . . . . . . . . . . . . . . . . . 225

Введение

Уже в конце 1960-х годов пристальное внимание прессы привлек тот

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

ны влиять на нашу жизнь. Описывался случай, когда покупатель, получив

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

магазин, но продолжал без конца получать напоминания от компьютера с

предупреждением оплатить счет.

Гораздо опаснее очутиться в поезде, который управляющая им ЭВМ пы-

тается разогнать до 1000 км в час вместо 100 из-за ошибки в программе. Мы

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

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

ЭВМ могут теперь иметь такие последствия, как нанесение материального

ущерба, нарушение секретности, оскорбление личности и даже смерть.

Система раннего обнаружения баллистических снарядов Ballistic Missile

Early Warning System должна наблюдать за объектами, движущимися по на-

правлению к Соединенным Штатам, и, если объект не опознан, начать после-

довательность защитных мероприятий — от попыток установить с объектом

связь до перехвата и, возможно, ответного удара. Одна из ранних версий

системы ошибочно приняла подымающуюся Луну за снаряд, летящий над

северным полушарием. Ошибка ли это? С точки зрения пользователя (Ми-

нистерства обороны США) — да. С точки зрения разработчика системы —

возможно, и нет. Разработчик может настаивать на том, что в соответствии с

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

по отношению к любому движущемуся объекту, появившемуся над горизон-

том и не опознанному как мирный летательный аппарат.

На надежность влияют различные факторы. На надежности программи-

рования, например, существенно сказываются организационная структура,

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

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

рой проводится работа, и т. п. Существуют также проблемы, связанные с

современными языками программирования и архитектурой ЭВМ.

Надежность информационных систем 7

Что такое ошибка?

Согласно одному из известных определений, программное обеспечение

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

определение страдает существенным недостатком: неявно предполагается,

что спецификации корректны. Такое предположение если и бывает справед-

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

ошибок. Если поведение программного продукта не соответствует его спе-

цификациям, ошибка, вероятно, имеется. Однако, если система ведет себя

в соответствии со спецификациями, мы не можем утверждать, что она не

содержит ошибок.

Второе известное определение гласит, что программное обеспечение со-

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

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

это определение еще хуже первого. Если система случайно используется в

непредусмотренной ситуации, ее поведение должно оставаться разумным.

Если это не так, она содержит ошибку. Рассмотрим авиационную систему

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

над некоторым географическим районом. Предположим, что, согласно специ-

фикациям, система должна управлять движением до 200 самолетов одновре-

менно. Но однажды по непредвиденным обстоятельствам в районе появился

201 самолет. Если поведение системы неразумно — скажем, она забывает об

одном из самолетов или выходит из строя, — система содержит ошибку, хотя

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

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

гда программное обеспечение ведет себя не в соответствии с официальной

документацией и поставленными пользователю публикациями. К несчастью,

это определение также страдает несколькими изъянами. Возможны ситуа-

ции, когда программное обеспечение ведет себя в соответствии с официаль-

ными публикациями, но ошибки все-таки имеются, так как они содержатся и

в программе, и в публикациях. Другая проблема возникает вследствие тен-

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

планируемую работу с системой. К примеру, что мы имеем руководство для

пользователей системы разделения времени, в котором говорится: “Чтобы

дать новую команду, нажмите один раз клавишу “Enter” и напечатайте эту

команду”. Предположим, что пользователь случайно нажимает клавишу “En-

ter” дважды и система программного обеспечения выходит из строя, потому

что ее разработчики не предусмотрели такой ситуации. Система, очевидно,

содержит ошибку, но мы не можем утверждать, что она ведет себя не в соот-

ветствии с публикациями.

8 Введение

Подобный случай произошел с космической станцией “Фобос”. Станция

прекратила связь с ЦУП после ошибочной команды на выключение связи.

В таких случаях необходима “защита от дурака”.

Согласно последнему определению, которое также иногда используется,

ошибка определяется как неспособность системы действовать в соответствии

с исходным контрактом или перечнем требований пользователя. Хотя это

определение лучше трех предыдущих, оно также не без недостатков. Если,

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

время между отказами из-за ошибки в программном обеспечении на уровне

100 часов, а для действующей системы этот показатель равен 150 часам, си-

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

конечно), даже несмотря на то, что она превышает требования пользовате-

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

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

ного обеспечения при всех мыслимых обстоятельствах.

Есть, однако, разумное определение ошибки в программном обеспечении,

разрешающее перечисленные выше проблемы: в программном обеспечении

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

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

ошибки в нем.

Глава 1

Общие положения теории надежности

Без понятия “надежность” в настоящее время не могут обойтись ни на-

ука, ни техника, ни промышленность.

Особенно остро проблема надежности встала тогда, когда человеком ста-

ли создаваться сложные объекты, к которым можно отнести и вычислитель-

ные системы.

Рассмотрим эту проблему на примере элементной базы ЭВМ первого

поколения — электронной лампы. Таких ламп в машинах первого поколе-

ния насчитывалось до нескольких десятков тысяч. Если испытать несколько

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

тает разное время. Причем заранее указать, каким будет это время нельзя.

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

проработает не меньше заданного срока.

То есть для каждой лампы, так же как и для каждого другого изде-

лия, срок службы представляет собой случайную величину и соответствую-

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

устройства в течение заданного срока службы. А для определения надежно-

сти всей сложной системы необходимо ориентироваться на надежность наи-

более слабых в этом отношении элементов.

Все изделия по теории надежности можно разделить на три вида: невос-

станавливаемые, восстанавливаемые и невосстанавливаемые во время экс-

плуатации. К невосстанавливаемым деталям относятся элементы радиоаппа-

ратуры, детали машин, подшипники, блоки питания персональных компью-

теров. К восстанавливаемым относятся — ЭВМ, управляющие машины, авто-

мобили, станки. К третьему виду относятся, например, бортовые устройства

ракет, которые не восстанавливаются во время полета, но восстанавливаются

при хранении и подготовке к старту.

В настоящее время разрабатываются различные методы (например, ре-

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

дежности системы, но и ее повышения.

10 Общие положения теории надежности

Для современной техники характерны такие тенденции развития, как

увеличение степени автоматизации, интенсификация рабочих параметров (на-

грузок, скоростей, температур, давлений и т. д.), уменьшение габаритов и

массы, повышение требований к точности функционирования и эффектив-

ности (производительности, мощности, коэффициента полезного действия и

т. д.), объединение отдельных агрегатов в системы с единым управлением и

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

повышения качества и надежности техники.

Надежность техники всегда была одной из основных инженерных про-

блем и ей всегда уделялось большое внимание. Однако за последние 50–60 лет

проблема надежности значительно обострилась и приобрела более тяжелую

форму. Это обусловлено главным образом следующими основными причина-

ми:

Увеличение сложности техники

Современные технические системы могут включать до 10

–10

и более

элементов. Например, системы управления современными межконтиненталь-

ными баллистическими ракетами содержат от 300 тысяч до 1,5 миллионов

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

производствами содержат от 70 до 250 тысяч компонентов. Усложнение тех-

ники закономерно приводит к снижению ее надежности (чем больше эле-

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

неработоспособным).

Усиление интенсивности режимов работы

Режимы эксплуатации современных технических систем характеризуют-

ся высокими и сверхвысокими скоростями, температурами и давлениями. На-

пример, удельный вес (металлоемкость) двигателей внутреннего сгорания в

1900 году составлял 250 кг/л.с., в 1913 — 150, в 1931 — 60, 1953 — 31, в

1954 — 10,5, в 1955 — 3,2, в 1958 (двигатель М-21А) — 2,07, в 1968 (двига-

тель М-24Д) — 1,39, т.е. за неполные 70 лет интенсивность эксплуатационных

режимов увеличилась в 180 раз.

Сложность условий эксплуатации

Современная техника эксплуатируется в широких диапазонах темпера-

тур, в вакууме, при влажности до 100 %, при вибрации с большими амплиту-

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

ческих нагрузках (до 20000g), а также уровне радиации и т. д. Это приводит

к тому, что интенсивности отказов элементов и систем могут возрасти в сотни

и тысячи раз по сравнению с обычными условиями.

Повышение требований к качеству, точности и долговечности

На ремонт и восстановление отказавшей техники затрачиваются большие