
- •Е.Л. Кон, м.М. Кулагина надежность и диагностика компонентов инфокоммуникационных и информационно-управляющих систем
- •Оглавление
- •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. Прогнозирование технического состояния узлов
- •Вопросы и задания
- •Список литературы
- •Приложение Интенсивность отказов компонентов иус
- •Кон Ефим Львович, Кулагина Марина Михайловна надежность и диагностика компонентов инфокоммуникационных и информационно-управляющих систем
Комментарии
Лучшей документацией внутренней логики программы являются простая и ясная структура текста программы, использование сдвига по строке в соответствии с уровнем вложенности, осмысленные имена и соблюдение других правил, касающихся стиля программирования [1]. Если текст программы обладает этими свойствами, обилие комментариев не является необходимым и часто даже нежелательно. Известны случаи, когда комментарии мешали отладке, поскольку человек, отлаживающий программу, склонен верить им и в результате недостаточно тщательно проверяет текст программы. Опытные программисты, отыскивая во время отладки ошибку в модуле, часто закрывают комментарии листом бумаги.
Избегайте обилия комментариев.Изобилие комментариев мешает чтению программы, отвлекая внимание. Всякий раз, когда имеется модуль с очень большим количеством комментариев, возникает подозрение, что программист написал их так много либо потому, что сама программа запутанна или содержит трюки, либо потому, что он следовал какому-нибудь правилу вроде «по крайней мере 50 % всех операторов должны иметь комментарии»; значит, многие из комментариев бессодержательны. Программист должен быть скуп на комментарии, употребляя их только там, где это абсолютно необходимо.
Комментируйте так, как будто бы вы отвечаете на вопросы читателя.Очень эффективный метод состоит в том, чтобы сначала написать текст программы без комментариев, а затем посмотреть на него глазами читателя. Если окажется, что у читателя в некоторой точке программы может возникнуть вопрос, следует вставить содержательный комментарий с ответом на него.
Физически «выдвигайте» все комментарии из текста собственно программы.При печати комментарии следует смещать вправо от текста программы, так чтобы читатель мог просматривать программу, не прерываемую комментариями. Другими словами, комментарии в программе должны быть аналогичны подстрочным примечаниям в книге.
Прокомментируйте все переменные.Понимание данных – ключ к пониманию программы. Каждое предложение, объявляющее некоторую переменную, должно сопровождаться комментарием, поясняющим смысл этой переменной.
Определения данных
Понимая особую важность данных, приведем несколько правил их определения и использования [4].
Объявляйте все переменные явно.Во многих языках программирования разрешается определять данные неявно, просто используя их имена в выполняемых операторах. Такие «сокращения» предназначены для дилетантов или тех, кто программирует от случая к случаю, но не для программистов-профессионалов. Профессиональный программист должен явно определять или объявлять все переменные в самом начале модуля.
Объявляйте все атрибуты каждой переменной.Не следует также пользоваться имеющимися в языке сокращениями для объявления aтpибyтoв, не указанных явно, по умолчанию. Процесс выбора атрибутов по умолчанию часто сложен и ведет к ошибкам, если программист не вполне его понимает. Более того, некоторые компиляторы позволяют на каждой вычислительной установке изменять правила умолчания, что является крайне опасной практикой.
Избегайте явных констант. В исполняемом тексте программы не должно быть абсолютных констант, за исключением таких общеупотребительных значений, как единица, нуль, число ПИ и т.п. Для констант надо вводить символические имена и использовать их в программе
а=sin(0,7);
следует заменить на фрагмент программы:
с=0,7;
а=sin(c);
Никогда не используйте несколько имен для одной области памяти.
Никогда не используйте переменную более чем для одной цели. Распространенный прием экономии лишнего слова памяти состоит в повторном использовании переменной в различных целях. Программист вполне может решить: «Я закончил работать с TIME для расчетов времени, поэтому теперь буду использовать эту переменную как промежуточную при вычислении даты». Такая практика увеличивает шансы внесения ошибок при модификации программы.
Никогда не используйте особые значения переменной с особым смыслом.В определении параметров подпрограмм часто можно увидеть комментарии вроде такого: «ДЛСТРОКИ – это число символов во входной строке, причем ДЛСТРОКИ=0 означает ошибку при вводе». Это неоднозначное употребление параметра часто приводит к двусмысленным ситуациям и иногда затрудняет изменение программы. Чтобы передавать код ошибки, следует определить отдельный параметр.
Пишите модули, управляемые таблицами.При программировании модулей, реализующих сложный процесс принятия решений, эти решения следует описывать таблицей, а не встраивать в текст программы. Это сокращает и «обобщает» программу, а также значительно облегчает модификации.
Будьте осторожны с двоичной машиной.Двоичные машины обладают тем свойством, что числа с плавающей точкой в них представляются приближенными значениями. В такой машине умножение 10.0 на 0.1 редко дает в результате 1.0. Программист должен остерегаться этого свойства, особенно при попытке сравнивать два числа с плавающей точкой.
Будьте осторожны с действиями над целыми.Следует быть внимательным при умножении или делении целых чисел. Если I – целочисленная переменная, то ответ на вопрос, равны ли между собой I и 2*I/2, зависит от того, четно I или нет и что в сгенерированной компилятором программе будет выполняться раньше: умножение или деление.
Избегайте операций со значениями смешанных типов.Программисту не следует употреблять вперемешку переменные различных типов (например, двоичные, десятичные, плавающие) или различной точности в одном выражении; компилятор может выполнить некоторые неожиданные преобразования. Такие операции, как сложение строки символов с целочисленной переменной, нельзя делать никогда. Необходима осторожность при употреблении констант, поскольку компилятор может приписать им по умолчанию атрибуты, требующие неожиданных преобразований данных. Например, следующий фрагмент на Delphi:
WinExec( '"bin\tpc.exe" ' +ListBox.Items.Strings[2]);
{запуск консольного приложения с параметром, который написан во второй строчке листбокса}
Компилятор выдает ошибку на несовместимые типы String и PAnsiChar.
Для исправления этой ошибки строку нужно привести к PChar:
WinExec(PChar('"bin\tpc.exe" ' +ListBox.Items.Strings[2])).