- •Е.Л. Кон, м.М. Кулагина надежность и диагностика компонентов инфокоммуникационных и информационно-управляющих систем
- •Оглавление
- •1. Основные теоретические сведения 9
- •2. Надежность аппаратурного обеспечения 31
- •3. Создание надежного программного обеспечения 130
- •4. Диагностика состояния сложных технических систем 205
- •Введение
- •1. Основные теоретические сведения
- •1.1. Информационно-управляющие и инфокоммуникационные системы
- •1.2. Основные определения теории надежности
- •1.2.1. Надежность и ее частные стороны
- •1.2.2. Виды надежности
- •1.2.3. Отказы
- •1.2.4. Эффективность
- •1.2.5. Восстановление
- •1.3. Понятие случайных событий и случайных величин
- •1.3.1. Надежность систем при основном (последовательном) и параллельном соединении элементов
- •1.3.2. Основное соединение элементов
- •1.3.3. Параллельное соединение элементов
- •1.4. Элементы теории нечетких множеств
- •1.4.1. Понятие принадлежности и основные операции для четких подмножеств
- •1.4.2. Понятие принадлежности и основные операции для нечетких подмножеств
- •1.4.3. Отношение доминирования
- •1.4.4. Простейшие операции над нечеткими множествами
- •1.4.5. Расстояние Хэмминга
- •Вопросы и задания
- •Список литературы
- •2. Надежность аппаратурного обеспечения
- •2.1. Надежность невосстанавливаемых систем без резервирования
- •2.1.1. Показатели надежности невосстанавливаемых объектов
- •2.1.2. Законы распределения случайных величин, используемые в теории надежности
- •Показательное (экспоненциальное) распределение
- •Усеченное нормальное распределение
- •Распределение Вейбулла
- •Гамма-распределение
- •Практическая область применения законов распределения времени безотказной работы
- •2.1.3. Использованиеи-характеристик для решения практических задач
- •2.1.4. Особенности расчета надежности при проектировании различных систем
- •2.1.5. Расчет надежности по блок-схеме системы
- •2.1.6. Расчет надежности при подборе элементов системы
- •2.1.7. Расчет надежности системы с учетом режимов работы элементов
- •2.1.8. Учет цикличности работы аппаратуры
- •2.2. Надежность невосстанавливаемых систем с резервированием
- •2.2.1. Пути повышения надежности
- •2.2.2. Методы резервирования
- •2.2.3. Расчет надежности сложных систем при постоянно включенном резерве
- •2.2.4. Расчет надежности системы при резервировании замещением
- •2.2.5. Резервирование замещением в случае нагруженного резерва
- •2.2.6. Резервирование замещением в случае облегченного резерва
- •2.2.7. Резервирование замещением в случае ненагруженного резерва
- •2.2.8. Расчет надежности систем с функциональным резервированием
- •2.3. Расчет надежности восстанавливаемых систем
- •2.3.1. Критерий надежности систем с восстановлением
- •Характеристики потока отказов
- •Характеристики потока восстановления
- •Комплексные характеристики надежности систем с восстановлением
- •2.3.2. Расчет надежности по графу работоспособности объекта
- •2.3.3. Определение среднего времени наработки на отказ системы с восстановлением
- •2.3.4. Расчет надежности систем с восстановлением при основном (последовательном) и параллельном соединении элементов
- •2.3.5. Расчет надежности сложных инфокоммуникационных систем
- •Структура и функции стс
- •Определение надежностных характеристик блоков стс
- •Составление структурно-логической схемы надежности и графа состояний
- •2.3.5.4. Расчет коэффициента готовности стс
- •Определение надежностных характеристик блоков аиис
- •Составление структурно-логической схемы надежности и графа переходов
- •Расчет коэффициента готовности аиис «Алтайэнерго»
- •Расчет коэффициента готовности аиис
- •2.4. Расчет надежности восстанавливаемых систем при наличии системы контроля
- •2.4.1. Система встроенного контроля абсолютно надежна
- •2.4.2. Система встроенного контроля самопроверяемая, и ее отказ обнаруживается сразу же
- •2.4.3. Система встроенного самоконтроля несамопроверяемая
- •2.5. Расчет надежности в условиях нечетко заданных исходных данных
- •2.5.1. Выбор оптимального варианта для невосстанавливаемых систем
- •2.5.2. Выбор оптимального варианта для восстанавливаемых систем
- •2.6. Расчет надежности систем на этапе эксплуатации
- •2.6.1. Планирование и расчет периодов профилактик
- •2.6.2. Планирование и расчет числа запасных изделий
- •Вопросы и задания
- •Список литературы
- •3. Создание надежного программного обеспечения
- •3.1. Надежность программного обеспечения
- •3.1.1. Ошибки в по и их типы
- •Типы ошибок в программном обеспечении
- •3.1.2. Причины появления ошибок в программном обеспечении
- •3.1.3. Отношения с пользователем (заказчиком)
- •3.1.4. Принципы и методы обеспечения надежности
- •3.1.5. Последовательность выполнения процессов разработки программного обеспечения
- •3.1.6. Сравнение надежности аппаратуры и программного обеспечения
- •3.2. Основные этапы проектирования программного обеспечения
- •3.2.1. Правильность проектирования и планирование изменений
- •3.2.2. Требования к по
- •3.2.3. Цели программного обеспечения
- •Цели продукта
- •Цели проекта
- •Общие правила постановки целей
- •Оценка целей
- •3.2.4. Внешнее проектирование
- •Проектирование взаимодействия с пользователем
- •Подготовка внешних спецификаций
- •Проверка правильности внешних спецификаций
- •3.2.5. Проектирование архитектуры программы
- •Независимость модулей
- •Прочность модулей
- •Сцепление модулей
- •3.2.6. Методы непосредственного повышения надежности модулей
- •Пассивное обнаружение ошибок
- •Активное обнаружение ошибок
- •Исправление ошибок и устойчивость к ошибкам
- •Изоляция ошибок
- •Обработка сбоев аппаратуры
- •3.2.7. Проектирование и программирование модуля
- •Внешнее проектирование модуля
- •Проектирование логики модуля
- •Пошаговая детализация
- •3.2.8. Стиль программирования
- •Ясность программирования
- •Использование языка
- •Микроэффективность
- •Комментарии
- •Определения данных
- •Структура модуля
- •3.3. Тестирование и верификация программ
- •3.3.1. Проблемы тестирования программ
- •3.3.2. Технологии тестирования программ
- •3.3.3. Принципы тестирования
- •3.4. Модели надежности по
- •3.4.1. Модель роста надежности
- •3.4.2. Другие вероятностные модели
- •3.4.3. Статистическая модель Миллса
- •3.4.4. Простые интуитивные модели
- •3.4.5. Объединение показателей надежности
- •Вопросы и задания
- •Список литературы
- •4. Диагностика состояния сложных технических систем
- •4.1. Предмет, задачи и модели технической диагностики
- •4.1.1. Предмет технической диагностики
- •4.1.2. Основные аспекты, задачи и модели технической диагностики
- •4.1.3. Классификация диагностических процедур и их краткая характеристика
- •4.2. Построение тестов
- •4.2.1. Построение тестового набора методом активизации существенного пути
- •4.2.2. Алгоритм построения тестового набора для комбинационной схемы методом активизации существенного пути
- •4.2.3. Построение тестов для схем с памятью
- •Комбинационная модель последовательностной схемы
- •Построение тестовой последовательности по комбинационной модели последовательностной схемы
- •4.3. Функциональный контроль и диагностирование сложных технических систем
- •4.3.1. Полностью самопроверяемые цифровые устройства
- •4.3.2. Схемы встроенного контроля
- •4.3.3. Схемы сжатия
- •4.3.4. Микропроцессор как объект функционального контроля
- •4.3.5. Модель мп с точки зрения функционального контроля
- •4.3.6. Диагностическая модель уу мп системы
- •4.3.7. Критерии оценки методов контроля механизмов выборки, хранения и дешифрации команд
- •4.3.8. Встроенный функциональный контроль механизмов хранения и дешифрации команд
- •Методы пошагового контроля правильности хода программ
- •Методы контроля, реализующие раскраску команд
- •Метод контроля, использующий раскраску без учета структуры команд
- •Преобразованная программа приведена ниже:
- •Цвет Четность Цвет гса
- •Метод контроля команд, реализующий раскраску с учетом структуры команды
- •Раскраска без внесения в команду избыточных разрядов
- •Методы контроля механизмов дешифрации и хранения команд с помощью веса перехода
- •Метод контроля с помощью алгебраических кодов
- •Методы блокового контроля правильности хода программ
- •Блоковый контроль программ по методу разбиения программы на фазы (блоки)
- •Блоковый контроль правильности хода программ с помощью сигнатур
- •Метод контроля программ на основе полиноминальной интерпретации схем алгоритмов (программ)
- •Сравнительный анализ свк, реализующих методы блокового и пошагового контроля
- •4.4. Экспертные системы диагностирования сложных технических систем
- •4.4.1. Обучение и его модели. Самообучение
- •4.4.2. Экспертные системы и принципы их построения
- •4.4.3. Проблема разделения в самообучаемых экспертных системах
- •4.4.4. Алгоритмы обучения экспертных систем
- •Частота события находится по следующей формуле:
- •4.4.5. Асу «интеллектуальным зданием»
- •4.4.6. Система, принимающая решения по максимальной вероятности
- •4.4.7. Система, принимающая решения по наименьшему расстоянию
- •4.4.8. Повышение достоверности решений экспертной системы
- •4.4.9. Прогнозирование технического состояния узлов
- •Вопросы и задания
- •Список литературы
- •Приложение Интенсивность отказов компонентов иус
- •Кон Ефим Львович, Кулагина Марина Михайловна надежность и диагностика компонентов инфокоммуникационных и информационно-управляющих систем
Сцепление модулей
Второй важнейший способ увеличить независимость модулей – ослабить связи между ними. Сцепление модулей, т.е. мера взаимозависимости модулей по данным, характеризуется как способом передачи данных, так и свойствами самих этих данных. Проанализировав любую пару модулей, можно определить, к какому из шести видов относится сцепление между ними, либо установить, что между ними прямого сцепления нет.
Цель проектирования состоит в определении таких сопряжений между модулями, чтобы все данные передавались между ними в форме явных и простых параметров. Как и раньше, чтобы понять важность этой цели, мы рассмотрим ниже шесть видов сцепления, начиная с самого жесткого (наихудший случай).
Два модуля сцеплены по содержимому, если один модуль прямо ссылается на содержимое другого. Например, если модуль А каким-либо образом ссылается на данные модуля В, используя абсолютное смещение, то эти модули сцеплены по содержимому. Почти всякое изменение В или, возможно, просто перекомпиляция В с помощью другой версии компилятора внесет ошибку в программу. К счастью, большинство языков программирования высокого уровня делают сцепление по содержимому трудноосуществимым.
Группа модулей сцеплена по общей области, если они ссылаются на одну и ту же глобальную структуру данных. Примером сцепления по общей области служат группы модулей, ссылающиеся на абсолютные адреса памяти (включая регистры).
Со сцеплением по общей области связан целый ряд проблем. Все такие модули зависят от физического упорядочения элементов общей структуры данных, вследствие чего изменение размеров одного элемента данных влияет на все модули. Использование глобальных данных сводит на нет все попытки управлять доступом каждого модуля к данным. Имена глобальных переменных связывают модули еще тогда, когда те только создаются. Это значит, что использование сцепленных по общей области модулей в новых программах затруднено, если возможно вообще.
Глобальные данные усложняют и восприятие программы. Рассмотрим следующий фрагмент:
WHILE A DO
BEGIN
L (X,Y,Z);
M (X,Y);
N (W,Z);
P (Z,X,Y);
END;
END;
Если А не является глобальной переменной и если другие неудачные приемы кодирования (такие как совмещение А с W, X, Y или Z) не используются, то можно утверждать, что этот цикл никогда не закончится. Если А – глобальная переменная, то сразу нельзя определить, закончится ли выполнение цикла. Придется исследовать внутреннее устройство модулей L, М, N и Р, а также всех модулей, которые им подчинены, чтобы понять только этот цикл DO!
Группа модулей сцеплена по внешним данным, если они ссылаются на один и тот же глобальный элемент данных (переменную, имеющую единственное поле). Например, модули Delphi сцеплены друг с другом по внешним данным с помощью глобальных переменных.
Сцепление по внешним данным порождает почти все проблемы, свойственные сцеплению по общей области. Однако проблемы зависимости от физического упорядочения элементов в структуре не возникает.
Два модуля сцеплены по управлению, если один явно управляет функционированием другого, например, используя код конкретной функции. Сцепление по управлению и прочность по логике обычно сопутствуют друг другу, поэтому основная проблема здесь та же, что и с прочностью по логике: использование одного и того же (сложного) сопряжения для выполнения многих функций. Сцепление по управлению часто предполагает также, что вызывающий модуль имеет некоторое представление о логике вызываемого модуля, что уменьшает их независимость.
Группа модулей сцеплена по формату, если они ссылаются на одну и ту же неглобальную структуру данных. Если модуль А вызывает модуль В и передает ему запись анкетных данных студента и при этом как А, так и В чувствительны к изменению структуры или формата этой записи, то А и В сцеплены по формату.
Сцепления по формату следует избегать, где это возможно, поскольку оно создает ненужные связи между модулями. Предположим, что модулю В нужны только некоторые поля в анкете. Передача ему всей анкеты вынуждает его заниматься анкетой целиком, и таким образом увеличивается вероятность того, что модуль неумышленно ее изменит (по-видимому, можно утверждать, что чем больше посторонних данных доступно модулю, тем больше возможность ошибки).
Сцепление по формату часто можно исключить, изолируя все функции, работающие с конкретной структурой данных, в информационно прочном модуле. Другим модулям может понадобиться имя этой структуры, но они и знают только это имя (адрес), а не формат.
Два модуля сцеплены по данным, если один вызывает другой и все входные и выходные параметры вызываемого модуля – простые (не структурные) элементы данных. Предположим, что функция модуля В из предыдущего примера – надпечатать конверт для студента. Вместо того чтобы передавать В всю анкету, мы могли бы передать ему в качестве аргументов фамилию студента, улицу, дом, город и почтовый индекс. Модуль В теперь не зависит от записи анкетных данных. А и В стали более независимы, и вероятность ошибки в В меньше, поскольку автор модуля В имеет дело с меньшим количеством данных.
Как и в случае с прочностью модуля, сцепление влияет и на другие, не рассматриваемые здесь специально свойства программы (на адаптируемость, сложность тестирования, возможность повторного использования модулей, простоту или сложность мультипрограммирования [11]).
Сцепление пары модулей может удовлетворять определениям нескольких типов. Например, два модуля могут быть сцеплены и по образцу, и по общей области. В этом случае мы относим модули к самому жесткому (худшему) из этих типов сцепления (в данном случае – сцепление по общей области).
Степень прочности и сцепления можно использовать для оценки существующего проекта и как руководящий принцип при проектировании новой программы. Это, однако, не означает, что проект, в котором в отдельных случаях прочность и сцепление далеки от идеала, обязательно плох. Исходя из некоторого компромиссного решения, проектировщик может пойти на включение модуля, прочного всего лишь по логике. Однако поступая так, он должен уметь убедительно объяснить причины и хорошо понимать следствия своего компромиссного решения. Это, во всяком случае, лучше, чем проектировать, основываясь только на интуиции, и полагаться на счастливый случай.
Высокая прочность и слабое сцепление способствуют независимости модулей, поскольку они сводят к минимуму их взаимодействие и их предположения друг о друге. Следующие три критерия проектирования, сформулированные в [5], хорошо подытоживают сказанное.
1. Сложность взаимодействия модуля с другими модулями должна быть меньше сложности его внутренней структуры.
2. Хороший модуль снаружи проще, чем внутри.
3. Хороший модуль проще использовать, чем построить.