- •Е.Л. Кон, м.М. Кулагина надежность и диагностика компонентов инфокоммуникационных и информационно-управляющих систем
- •Оглавление
- •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. Прогнозирование технического состояния узлов
- •Вопросы и задания
- •Список литературы
- •Приложение Интенсивность отказов компонентов иус
- •Кон Ефим Львович, Кулагина Марина Михайловна надежность и диагностика компонентов инфокоммуникационных и информационно-управляющих систем
Независимость модулей
Чтобы уменьшить сложность программы, нужно разбить ее на множество небольших, в высокой степени независимых модулей. Модуль – это замкнутая программа, которую можно вызвать из любого другого модуля в программе и можно отдельно компилировать (отметим, что тем самым исключаются внутренние процедуры Delphi). Довольно высокой степени независимости можно достичь с помощью двух методов оптимизации: усилением внутренних связей в каждом модуле и ослаблением взаимосвязи между модулями. Если рассматривать программу как набор предложений, связанных между собой некоторыми отношениями (как по выполняемым функциям, так и по обрабатываемым данным), то основное, что требуется, – это догадаться, как распределить эти предложения по отдельным модулям так, чтобы предложения внутри каждого модуля были тесно связаны, а связь между любой парой предложений в разных модулях была минимальной. Нужно стремиться реализовать отдельные функции отдельными модулями (высокая прочность модуля) и ослабить связь между модулями по данным, применяя формальный механизм передачи параметров (слабое сцепление модулей).
Прочность модулей
Прочность модуля – это мера его внутренних связей. Чтобы определить прочность модуля, необходимо проанализировать выполняемую им функцию (или функции), с тем, чтобы решить, к какому из семи классов он относится. Классы эти специально определены для того, чтобы ввести количественную характеристику «доброкачественности» конкретных типов модулей.
В первую очередь необходимо определить, что понимается под функцией модуля. Модуль имеет три основных атрибута: он выполняет одну или несколько функций, обладает некоторой логикой и используется в одном или нескольких контекстах. Функция – это внешнее описание модуля; описывается, что делает модуль, когда он вызван, но не как это делается. Логика описывает внутренний алгоритм модуля, другими словами, как он выполняет свою функцию. Контекст описывает конкретное применение модуля. Например, модуль с функцией «удалить пробелы из литерной строки» может использоваться в контексте «сжать сообщение для телеобработки». Чтобы увидеть разницу между функцией и логикой, рассмотрим модуль, функция которого – зашифровать введенную информацию по заданному ключу. Он может быть головным модулем 15-модульной программы либо единственным модулем программы. В обоих случаях функция этих двух модулей одинакова, но логика – совершенно разная. Мы видим, что функция модуля может рассматриваться как композиция его логики и функций всех подчиненных (вызываемых им) модулей. Это определение рекурсивно и применимо к любому модулю в иерархии.
Цель проектирования – так определить модули, чтобы каждый из них выполнял одну функцию (говорят, что такие модули обладают функциональной прочностью). Чтобы понять важность этой цели, ниже рассмотрим семь классов прочности модулей [11], начиная с самого слабого типа прочности.
Модуль, прочный по совпадению, – модуль, между элементами которого нет осмысленных связей. Трудно привести пример такого модуля, поскольку он не выполняет никаких разумных функций. Описание логики – единственный возможный способ описания модулей этого типа. Одна из причин, по которым такие модули могут возникнуть, – это «модуляризация» программы post factum, когда мы обнаруживаем одинаковые последовательности команд в нескольких модулях и решаем сгруппировать их в отдельный модуль. Если эти последовательности (хотя они и кажутся идентичными) имеют разный смысл в тех модулях, в которые они первоначально входили, то наш новый модуль является прочным по совпадению. Модуль этого типа тесно связан с вызывающими его модулями, поэтому почти любая его модификация в интересах одного из этих модулей приводит к тому, что для всех остальных он станет работать неправильно.
Модуль, прочный по логике, содержит несколько функций, и при каждом вызове выполняет одну из них. Выбираемая функция обычно запрашивается вызывающим модулем, например с помощью кода функции. Примером может быть модуль, функция которого – читать из файла или писать в файл. Главная проблема с модулями этого типа – это использование одного и того же сопряжения для выполнения многих функций. Это приводит к сложным сопряжениям и неожиданным ошибкам при изменении сопряжения ради одной из функций.
Модуль, прочный по классу, последовательно выполняет набор связанных с ним функций. Самые распространенные примеры – «начальный» и «заключительный» модули. Главная проблема с модулями этого типа состоит в том, что обычно они неявно связаны с другими модулями программы, что делает программу трудной для понимания и ведет к ошибкам, когда ее приходится изменять.
Процедурно прочный модуль последовательно выполняет набор тех связанных с ним функций, которые непосредственно относятся к процедуре решения задачи. Вот пример задачи для подсистемы «интеллектуальный дом»: написать программу регулирования температуры простого парового котла. В определенной степени подобная задача может определять действия программы. Например, в постановке задачи может быть сказано, что при получении сигнала х следует закрыть клапан у и прочитать и зарегистрировать значение температуры. Модуль с функцией «закрыть клапан у, прочитать значение температуры парового котла и занести его в журнал» обладает процедурной прочностью. В этом случае единственная проблема, связанная с надежностью, состоит в том, что фрагменты программы, относящиеся к различным функциям, могут быть переплетены. Отметим, что для модулей этого типа, так же как и для большинства других типов, имеются и другие, не связанные с надежностью проблемы, как показано в [11].
Коммуникационно прочный модуль – это процедурно прочный модуль с одним дополнительным ограничением: все его функции связаны по данным. Например, модуль «прочитать следующую запись и обновить главный файл» коммуникационно прочен, поскольку обе его функции связаны между собой тем, что обе они работают с одной и той же записью. Здесь обычно возможно переплетение функций, но риск внесения ошибки при модификации несколько меньше, поскольку функции связаны более тесно.
Функционально прочный модуль – это модуль, выполняющий одну определенную функцию, такую как «посчитать вероятность правильной передачи сообщения», «закрыть клапан у» или «подвести итог по расходу горячей воды за месяц». Функциональная прочность – это высшая (лучшая) форма прочности модуля.
Отметим, что функционально прочный модуль может быть описан набором более детальных функций. Например, модуль «подвести итог по расходу горячей воды за месяц» можно описать так: «подготовить начальное состояние итоговой таблицы, открыть файл расхода горячей воды, читать расход и обновлять итоговую таблицу». Глядя на это, читатель может подумать, что простой перефразировкой описания модуля понижена его прочность. Однако если эти «функции более низкого уровня» могут быть рационально описаны как одна хорошо определенная функция «более высокого уровня», то следует считать, что модуль обладает функциональной прочностью.
Оставшийся тип прочности – информационная прочность. Информационно прочный модуль выполняет несколько функций, причем все они работают с одной и той же структурой данных и каждая представляется собственным входом. Модуль с двумя входами, один из которых соответствует функции «включить элемент в базу данных», а другой – функции «искать в базе данных», обладает информационной прочностью. Модуль этого типа может также рассматриваться как физическое объединение нескольких функционально прочных модулей с целью «упрятывания информации» [12], например, для того, чтобы укрыть внутри одного модуля все сведения о конкретной структуре данных, ресурсах или устройстве. В упомянутом выше примере вся информация о структуре и расположении таблицы символов скрыта внутри одного модуля. Это имеет то преимущество, что всякий раз, когда удается скрыть некоторый аспект программы внутри одного модуля, независимость ее модулей увеличивается. Упоминавшуюся ранее цель проектирования нужно теперь подправить, чтобы наряду с функционально прочными модулями стремиться к информационно прочным.
Хотя выше мы сконцентрировали внимание только на связи между прочностью модуля и защищенностью от ошибок, прочность модуля влияет также на адаптируемость программы, трудность тестирования отдельных модулей и степень применимости модуля в других контекстах и других программах [11]. Шкала прочности упорядочена с учетом всех этих атрибутов.
Отметим, что модуль может соответствовать описанию нескольких типов прочности. Например, коммуникационно прочный модуль удовлетворяет также определению процедурной прочности и прочности по классу. Будем всегда относить модуль к высшему типу прочности, определению которого он удовлетворяет.