Что такое надежность системы
НАДЕЖНОСТЬ СИСТЕМЫ
Смотреть что такое «НАДЕЖНОСТЬ СИСТЕМЫ» в других словарях:
надежность системы — надежность системы: Свойство системы обнаруживать с заданной вероятностью проникновение (попытку проникновения) на охраняемый объект (зону объекта). 2.4 (Исключен, title= Изменение № 2, ИУС 6 2012 ). 2.5 многорубежный комплекс охранной… … Словарь-справочник терминов нормативно-технической документации
надежность системы — Свойство системы обнаруживать с заданной вероятностью проникновение (попытку проникновения) на охраняемый объект (зону объекта). [ГОСТ Р 50776 95] [МЭК 839 1 4 89] Тематики системы охраны и безопасности … Справочник технического переводчика
Надежность системы — – свойство системы достигать заданный результат в процессе функционирования в течение заданного времени. [Бадьин Г. М. и др. Строительное производство. Основные термины и определения. Изд. Ассоциации строительных вузов, 2006 г.] Рубрика термина:… … Энциклопедия терминов, определений и пояснений строительных материалов
надежность системы человек-машина — система «человек машина»: надежность (надежность системы «человек машина») долгосрочный показатель работоспособности технических систем, актуально обслуживаемых людьми, во всевозможных условиях их функционирования. Словарь практического… … Большая психологическая энциклопедия
НАДЕЖНОСТЬ СИСТЕМЫ ЧЕЛОВЕК—МАШИНА — (англ. reliability of man machine system) совокупная характеристика техники и обслуживающих ее людей, обеспечивающая функционирование этой системы в рамках установленных для нее требований, безотказность и восстанавливаемость технических средств … Большая психологическая энциклопедия
Надежность системы управления — свойство С.у. выполнять свои функции, сохраняя во времени показатели качества эксплуатации, соответствующие режимам и условиям их использования в условиях чрезвычайных ситуаций.Надежность С.у. обеспечивается: использованием высокопрочных… … Словарь черезвычайных ситуаций
Надежность системы питьевого водоснабжения — свойство системы обеспечивать определенный режим (бесперебойный, почасовой по графику) подачи питьевой воды потребителям в соответствии с установленными нормами питьевого водообеспечения и нормативными требованиями к качеству питьевой воды. … … Официальная терминология
Надежность Системы Человек — Машина — Надежность системы человек машина долгосрочный показатель работоспособности технических систем, которые актуально обслуживаются людьми, во всевозможных условиях ее функционирования … Психологический словарь
надежность системы «сооружение-основание» — 3.8 надежность системы «сооружение основание»: Способность системы выполнять заданные функции. Источник: СП 23.13330.2011: Основания гидротехнических сооружений … Словарь-справочник терминов нормативно-технической документации
Надёжность технических систем
Вы будете перенаправлены на Автор24
Надежность технических систем, её свойства и показатели
Надежность технических систем – это способность системы и её элементов сохранять в течении определенного времени и в пределах установленных значений состояние всех параметров, необходимых для выполнения заданных функций.
Основными свойствами надежности технической системы являются:
Технические системы могут быть восстанавливаемые (способные выполнять свои функции после ремонтных работ) и невосстанавливаемые (после отказа система окончательно теряет возможность выполнения поставленных задач).
Показатели надежности технических систем:
Готовые работы на аналогичную тему
Основной причиной нарушения надежности технической системы или объектов является отказ.
Отказ технической системы – это событие, представляющее собой нарушение её работоспособности.
Отказы принято классифицировать по:
Способы обеспечения надежности технической системы
На этапе разработки технической системы и ее подготовки к вводу в эксплуатацию на предприятии обязательным мероприятием является разработка способов обеспечения надежности системы и ее элементов, а также научно исследовательская оценка её показателей.
Прогнозирование показателей надежности технической системы на стадиях планирования и разработки дает нужные данные для оценки параметров конструкции системы. Данный прогноз производят для каждого варианта конструкции системы и методом сравнения полученных результатов выбирают самую оптимальную.
В настоящее применяют несколько способов обеспечения надежности в зависимости от структуры предприятия и сферы его деятельности.
Конструктивные способы включают в себя создание запасов прочности конструкций системы, облегчение работы автоматизированных элементов системы, упрощение конструкций технической системы, увеличение показателей ремонтопригодности.
Технологические способы являются научно-обоснованными, их разработка происходит на стадии планирования строительства системы и ввода ее в эксплуатацию. Среди технологических способов различают два основных:
Способы повышения надежности технической системы
Для увеличения показателей надежности технической системы проводят ряд мероприятий, которые делятся на четыре группы
«Надежность и безотказность как в Google» — и не только: перевод статьи «Расчёт надёжности сервиса»
Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса и\или его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.
Расчет надежности сервиса
Ваша система надежна настолько, насколько надежны её компоненты
Как описано в книге «Site Reliability Engineering: Надежность и безотказность как в Google» (далее — книга SRE), разработка продуктов и сервисов Google может достигать высокой скорости выпуска новых функций, сохраняя при этом агрессивные SLO (service-level objectives, цели уровня обслуживания) для обеспечения высокой надежности и быстрого реагирования. SLO требуют, чтобы сервис почти всегда был в исправном состоянии и почти всегда был быстрым. При этом SLO также указывают точные значения этого «почти всегда» для конкретного сервиса. SLO основаны на следующих наблюдениях:
В общем случае для любого программного сервиса или системы 100% — неверный ориентир для показателя надежности, поскольку ни один пользователь не сможет заметить разницу между 100%-ной и 99,999%-ной доступностью. Между пользователем и сервисом находится множество других систем (его ноутбук, домашний Wi-Fi, провайдер, электросеть. ), и все эти системы в совокупности доступны не в 99,999% случаев, а гораздо реже. Поэтому разница между 99,999% и 100% теряется на фоне случайных факторов, обусловленных недоступностью других систем, и пользователь не получает никакой пользы от того, что мы потратили кучу сил, добиваясь этой последней доли процента доступности системы. Серьёзными исключениями из этого правила являются антиблокировочные системы управления тормозами и кардиостимуляторы!
Подробное обсуждение того, как SLO соотносятся со SLI (service-level indicators, индикаторы уровня обслуживания) и SLA (service-level agreements, соглашения об уровне обслуживания), смотрите в главе «Целевой уровень качества обслуживания» книги SRE. В этой главе также подробно описывается, как выбрать метрики, имеющие значение для конкретного сервиса или системы, что, в свою очередь, определяет выбор соответствующего SLO для этого сервиса или системы.
Эта статья расширяет тему SLO, чтобы сосредоточиться на составных частях сервисов. В частности, мы рассмотрим, как надежность критических компонентов влияет на надежность сервиса, а также как проектировать системы так, чтобы смягчить влияние или сократить количество критически важных компонентов.
Большинство сервисов, предлагаемых Google, направлены на обеспечение 99,99-процентной (иногда называемой «четыре девятки») доступности для пользователей. Для некоторых сервисов в пользовательском соглашении указывается более низкое число, однако внутри компании сохраняются целевые 99.99%. Эта более высокая планка дает преимущество в ситуациях, когда пользователи высказывают недовольство производительностью сервиса задолго до случая нарушения условий соглашения, поскольку цель № 1 команды SRE состоит в том, чтобы пользователи были довольны сервисами. Для многих сервисов внутренняя цель 99,99% представляет собой «золотую середину», которая уравновешивает стоимость, сложность и надежность. Для некоторых других, в частности глобальных облачных сервисов, внутренняя цель составляет 99,999%.
Надежность 99.99%: наблюдения и выводы
Давайте рассмотрим несколько ключевых наблюдений и выводов о проектировании и эксплуатации сервиса с надежностью 99,99%, а затем перейдем к практике.
Наблюдение № 1: Причины сбоев
Сбои происходят по двум основным причинам: проблемы с самим сервисом и проблемы с критическими компонентами сервиса. Критический компонент — это компонент, который в случае сбоя вызывает соответствующий сбой в работе всего сервиса.
Наблюдение № 2: Математика надежности
Надежность зависит от частоты и продолжительности простоев. Она измеряется через:
Вывод № 1: Правило дополнительных девяток
Сервис не может быть надежнее всех его критических компонентов вместе взятых. Если ваш сервис стремится обеспечить доступность на уровне 99,99%, то все критические составные части должны быть доступны значительно больше, чем 99,99% времени.
Внутри Google мы используем следующее эмпирическое правило: критические компоненты должны обеспечивать дополнительные девятки по сравнению с заявленной надёжностью вашего сервиса — в примере выше 99,999-процентную доступность — потому что любой сервис будет иметь несколько критических компонентов, а также свои собственные специфические проблемы. Это называется «правилом дополнительных девяток».
Если у вас есть критический компонент, который не обеспечивает достаточно девяток (относительно распространенная проблема!), вы должны минимизировать отрицательные последствия.
Вывод № 2: Математика частоты, времени обнаружения и времени восстановления
Сервис не может быть надежнее, чем произведение частоты инцидентов на время обнаружения и восстановления. Например, три полных отключения в год по 20 минут приводят в общей сложности к 60 минутам простоя. Даже если бы сервис работал отлично в остальное время года, 99,99-процентная надежность (не более 53 минут простоя в год) стала бы невозможной.
Это простое математическое наблюдение, но его часто упускают из виду.
Заключение из выводов № 1 и № 2
Если уровень надежности, на который полагается ваш сервис, не может быть достигнут, необходимо предпринять усилия для исправления ситуации — либо путем повышения уровня доступности службы, либо путем минимизации отрицательных последствий, как описано выше. Снижение ожиданий (т. е., объявленной надежности) тоже вариант, и зачастую — самый верный: дайте понять зависимому от вас сервису, что он должен либо перестроить свою систему, чтобы компенсировать погрешность в надежности вашей службы, либо сократить свои собственные цели уровня обслуживания. Если вы сами не устраните несоответствие, достаточно длительный выход системы из строя неизбежно потребует корректировок.
Практическое применение
Давайте рассмотрим пример сервиса с целевой надежностью в 99,99% и проработаем требования как к его компонентам, так и к работе с его сбоями.
Цифры
Предположим, что ваш 99,99-процентно доступный сервис имеет следующие характеристики:
Математический расчет надежности будет выглядеть следующим образом:
Требования к компонентам
Требования к реагированию на отключения
Вывод: рычаги для увеличения надежности сервиса
Стоит внимательно посмотреть на представленные цифры, потому что они подчеркивают фундаментальный момент: есть три основных рычага, для увеличения надежности сервиса.
Уточнение «Правила дополнительных девяток» для вложенных компонентов
Случайный читатель может сделать вывод, что каждое дополнительное звено в цепочке зависимостей требует дополнительных девяток, так что для зависимостей второго порядка требуется две дополнительные девятки, для зависимостей третьего порядка — три дополнительные девятки и т. д.
Это неверный вывод. Он основан на наивной модели иерархии компонентов в виде дерева с постоянным разветвлением на каждом уровне. В такой модели, как показано на рис. 1, имеется 10 уникальных компонентов первого порядка, 100 уникальных компонентов второго порядка, 1 000 уникальных компонентов третьего порядка и т. д., что приводит к созданию в общей сложности 1 111 уникальных сервисов, даже если архитектура ограничена четырьмя слоями. Экосистема высоконадежных сервисов с таким количеством независимых критических компонентов явно нереалистична.
Рис. 1 — Иерархия компонентов: Неверная модель
Критический компонент сам по себе может вызвать сбой всего сервиса (или сегмента сервиса) независимо от того, где он находится в дереве зависимостей. Поэтому, если данный компонент X отображается как зависимость нескольких компонентов первого порядка, X следует считать только один раз, так как его сбой в конечном итоге приведет к сбою службы независимо от того, сколько промежуточных сервисов будут также затронуты.
Корректное прочтение правила выглядит следующим образом:
Рис. 2 — Компоненты в иерархии
Например, рассмотрим гипотетический сервис A с лимитом ошибок 0,01 процента. Владельцы сервиса готовы потратить половину этого лимита на собственные ошибки и потери, а половину — на критические компоненты. Если сервис имеет N таких компонентов, то каждый из них получает 1/N оставшегося лимита ошибок. Типичные сервисы часто имеют от 5 до 10 критических компонентов, и поэтому каждый из них может отказать только в одной десятой или одной двадцатой степени от лимита ошибок Сервиса A. Следовательно, как правило, критические части сервиса должны иметь одну дополнительную девятку надежности.
Лимиты ошибок
Концепция лимитов ошибок довольно подробно освещена в книге SRE, но и здесь следует ее упомянуть. SR-инженеры Google используют лимиты ошибок, чтобы сбалансировать надежность и темпы внедрения обновлений. Этот лимит определяет допустимый уровень отказа для сервиса в течение некоторого периода времени (обычно — месяц). Лимит ошибок — это просто 1 минус SLO сервиса, поэтому ранее обсуждавшаяся 99,99-процентно доступная служба имеет 0,01% «лимита» на ненадежность. До тех пор, пока сервис не израсходовал свой лимит ошибок в течение месяца, команда разработчиков свободна (в пределах разумного) запускать новые функции, обновления и т. д.
Если лимит ошибок израсходован, внесение изменений в сервис приостанавливается (за исключением срочных исправлений безопасности и изменений, направленных на то, что вызвало нарушение в первую очередь), пока служба не восполнит запас в лимите ошибок или пока не сменится месяц. Многие сервисы в Google используют метод скользящего окна для SLO, чтобы лимит ошибок восстанавливался постепенно. Для серьёзных сервисов с SLO более 99,99%, целесообразно применять ежеквартальное, а не ежемесячное обнуление лимита, поскольку количество допустимых простоев у них невелико.
Лимиты ошибок устраняют напряженность в отношениях между отделами, которая в противном случае могла бы возникнуть между SR-инженерами и разработчиками продукта, предоставляя им общий, основанный на данных механизм оценки риска запуска продукта. Они также дают и SR-инженерам, и командам разработки общую цель развития методов и технологий, которые позволят внедрять нововведения быстрее и запускать продукты без «раздувания бюджета».
Стратегии сокращения и смягчения влияния критических компонентов
К данному моменту, в этой статье мы установили, что можно назвать «Золотым правилом надежности компонентов». Это значит, что надежность любого критического компонента должна в 10 раз превышать целевой уровень надежности всей системы, чтобы его вклад в ненадежность системы оставался на уровне погрешности. Отсюда следует, что в идеальном варианте задача состоит в том, чтобы сделать как можно больше компонентов некритическими. Это означает, что компоненты могут придерживаться более низкого уровня надежности, давая разработчикам возможность вводить новшества и идти на риск.
Наиболее простой и очевидной стратегией уменьшения критических зависимостей является устранение единых точек отказа (SPOF, single points of failure) всегда, когда это возможно. Более крупная система должна быть в состоянии работать приемлемо без какого-либо заданного компонента, который не является критической зависимостью или SPOF.
На самом деле, вы, скорее всего, не можете избавиться от всех критических зависимостей; но вы можете следовать некоторым рекомендациям по проектированию системы для оптимизации надежности. Хотя это не всегда возможно, проще и эффективнее достичь высокой надежности системы, если вы закладываете надежность на этапах проектирования и планирования, а не после того, как система работает и влияет на фактических пользователей.
Оценка структуры проекта
При планировании новой системы или сервиса, а также при перепроектировании или улучшении существующей системы или сервиса, обзор архитектуры или проекта может выявить общую инфраструктуру, а также внутренние и внешние зависимости.
Разделяемая инфраструктура
Если ваш сервис использует разделяемую инфраструктуру (например, сервис основной базы данных, используемый несколькими продуктами доступными пользователям), подумайте, правильно ли используется эта инфраструктура. Четко определите владельцев разделяемой инфраструктуры в качестве дополнительных участников проекта. Кроме того, остерегайтесь перегрузки компонентов — для этого тщательно координируйте процесс запуска с владельцами этих компонентов.
Внутренние и внешние зависимости
Иногда продукт или сервис зависит от факторов вне контроля вашей компании — например, от программных библиотек или услуг и данных третьих сторон. Выявление этих факторов позволит минимизировать непредсказуемые последствия их использования.
Планируйте и проектируйте системы внимательно
При проектировании вашей системы обращайте внимание на следующие принципы:
Резервирование и изоляция
Можно попытаться сократить влияние критического компонента, создав несколько его независимых экземпляров. Например, если хранение данных в одном экземпляре обеспечивает 99,9-процентную доступность этих данных, то хранение трех копий в трех широко рассредоточенных экземплярах обеспечит, в теории, уровень доступности равный 1 — 0,013 или девять девяток, если сбои экземпляра независимы при нулевой корреляции.
В реальном мире корреляция никогда не равна нулю (рассмотрите сбои магистральной сети, которые влияют на многие ячейки одновременно), таким образом, фактическая надежность никогда не приблизится к девяти девяткам, но намного превысит три девятки.
Аналогично, отправка RPC (remote procedure call, удаленный вызов процедур) в один пул серверов в одном кластере может обеспечить 99-процентную доступность результатов, в то время как отправка трех одновременных RPC в три разных пула серверов и принятие первого поступившего ответа помогает достигнуть уровня доступности выше чем три девятки (см. выше). Эта стратегия также может сократить «хвост» задержки времени ответа, если пулы серверов равноудалены от отправителя RPC. (Поскольку стоимость отправки трех RPC одновременно высока, Google часто стратегически распределяет время этих вызовов: большинство наших систем ожидают часть выделенного времени перед отправкой второго RPC и немного больше времени перед отправкой третьего RPC.)
Резерв и его применение
Настройте запуск и перенос программного обеспечения так, чтобы системы продолжали работать при отказе отдельных частей (fail safe) и изолировались при возникновении проблем автоматически. Основной принцип здесь в том, что к тому времени, когда вы подключите человека для включения резерва, вы, вероятно, уже превысите свой лимит ошибок.
Асинхронность
Чтобы компоненты не становились критическими, проектируйте их асинхронными везде, где это возможно. Если сервис ожидает ответного RPC от одной из своих некритических частей, которая демонстрирует резкое замедление времени ответа, это замедление без нужды ухудшит показатели родительского сервиса. Установка RPC для некритического компонента в режим асинхронности освободит показатели времени ответа родительской службы от привязки к показателям этого компонента. И хотя асинхронность может усложнить код и инфраструктуру сервиса, все же этот компромисс стоит того.
Планирование ресурсов
Убедитесь, что все компоненты обеспечены всем необходимым. Если сомневаетесь, лучше обеспечить избыточный резерв — но без увеличения расходов.
Конфигурация
По возможности стандартизируйте конфигурацию компонентов, чтобы минимизировать расхождения между подсистемами и избежать одноразовых режимов отказа \ обработки ошибок.
Обнаружение и устранение неполадок
Сделайте обнаружение ошибок, устранение неполадок и диагностику проблем максимально простыми. Эффективный мониторинг является важнейшим фактором своевременного выявления проблем. Диагностировать систему с глубоко встроенными компонентами крайне сложно. Всегда держите наготове такой способ нивелировать ошибки, который не требует детального вмешательства дежурного.
Быстрый и надежный откат в предыдущее состояние
Включение ручной работы дежурных в план по устранению последствий сбоев существенно снижает возможность выполнить жесткие цели SLO. Выстраивайте системы, которые смогут легко, быстро и бесперебойно вернуться к предыдущему состоянию. По мере того, как ваша система совершенствуется, и уверенность в вашем способе мониторинга растет, вы можете снизить MTTR разработав систему автоматического запуска безопасных откатов.
Систематически проверяйте все возможные режимы отказа
Изучите каждый компонент и определите, как сбой в его работе может повлиять на всю систему. Задайте себе следующие вопросы:
Проведите тщательное тестирование
Разработайте и внедрите развитую среду тестирования, которая будет гарантировать, что каждый компонент покрыт тестами, включающими в себя основные сценарии использования этого компонента другими составляющими среды. Вот несколько рекомендуемых стратегий для такого тестирования:
План на будущее
Ожидайте изменений, связанных с масштабированием: сервис, начинавшийся как относительно простой двоичный файл на одном компьютере, может обрасти множеством очевидных и неочевидных зависимостей при развертывании в большем масштабе. Каждый порядок масштаба выявит новые сдерживающие факторы — не только для вашего сервиса, но и для ваших зависимостей. Подумайте, что произойдет, если ваши зависимости не смогут масштабироваться так быстро, как вам нужно.
Также имейте в виду, что системные зависимости со временем развиваются и список зависимостей может со временем увеличиваться. Когда дело доходит до инфраструктуры, типичная рекомендация Google заключается в создании системы, которая будет масштабироваться до 10 раз от начальной целевой нагрузки без значительных изменений в архитектуре.
Заключение
В то время как читатели, вероятно, знакомы с некоторыми или многими понятиями, описанными в этой статье, конкретные примеры их использования помогут лучше разобраться в их сущности и передать это знание другим. Наши рекомендации непросты, но не недостижимы. Ряд сервисов Google неоднократно демонстрировали надежность выше четырех девяток не за счет сверхчеловеческих усилий или интеллекта, но благодаря продуманному применению принципов и передовых практик, выработанных в течение многих лет (см. книга SRE, Приложение B: Практические рекомендации для сервисов в промышленной эксплуатации).
Что такое надежность оборудования
Под надежностью понимается свойство объекта сохранять во времени в установленных пределах значения параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения технического обслуживания, ремонтов, хранения и транспортирования. Надежность является сложным свойством, которое в зависимости от назначения объекта и условий его применения состоит из сочетания безопасности, ремонтопригодности и сохраняемости (рисунок 1).
Рисунок 1 – Надёжность оборудования
Для абсолютного большинства круглогодично применяемых технических устройств при оценке их надежности наиболее важными являются три свойства: безотказность, долговечность и ремонтопригодность.
В то же время техника сезонного применения (уборочные сельскохозяйственные машины, некоторые коммунальные машины, речные суда замерзающих рек и т.д.), а также машины и оборудование для ликвидации критических ситуаций (противопожарное и спасательное оборудование), имеющие по своему назначению длительный период нахождения в режиме ожидания работы, должны оцениваться с учетом сохраняемости, т.е. показателями всех четырех свойств.
Есть наконец, целый ряд изделий (например, резинотехнические), оценивающийся главным образом сохраняемостью и долговечностью.
Перечисленные свойства надежности (безотказность, долговечность, ремонтопригодность и сохраняемость) имеют свои количественные показатели.
Так безотказность характеризуется шестью показателями, в том числе таким важным, как вероятность безотказной работы. Этот показатель широко применяется в народном хозяйстве для оценки самых различных видов технических средств: электронной аппаратуры, теплообменные аппараты систем воздушного отопления, летательных аппаратов, деталей, узлов и агрегатов, транспортных средств, нагревательных элементов. Расчет этих показателей проводят на основе государственных стандартов.
Долговечность также характеризуется шестью показателями, представляющие различные виды ресурса и срока службы. С точки зрения безопасности наибольший интерес представляет гамма-процентный ресурс — наработка, в течение которой объект не достигнет предельного состояния с вероятностью g, выраженной в процентах. Так для объектов металлургического оборудования (машины для подъема и перемещения жидких металлов, насосы и устройства для перекачивания вредных жидкостей и газов) назначают g = 95 %.
Ремонтопригодность характеризуется двумя показателями: вероятностью и средним временем восстановления работоспособного состояния.
Ряд авторов подразделяют надежность на идеальную, базовую и эксплуатационную. Идеальная надежность — это максимально возможная надежность, достигаемая путем создания совершенной конструкции объекта при абсолютном учете всех условий изготовления и эксплуатации. Базовая надежность — надежность, фактически достигаемая при конструировании, изготовлении и монтаже объекта. Эксплуатационная надежность — действительная надежность объекта в процессе его эксплуатации, обусловленная как качеством проектирования, конструирования, изготовления и монтажа объекта, так и условиями его эксплуатации, технического обслуживания и ремонта.
Основные положения надежности будут неясны без определения такого важного понятия, как резервирование.
Резервирование — это применение дополнительных средств или возможностей с целью сохранения работоспособного состояния объекта при отказе одного или нескольких его элементов.
Одной из наиболее распространенных разновидностей резервирования является дублирование — резервирование с кратностью резерва один к одному. В связи с тем, что резервирование требует значительных материальных затрат, его применяют лишь для наиболее ответственных элементов, узлов или агрегатов, отказ которых угрожает безопасности людей или влечет тяжелые экономические последствия. Так пассажирские и грузопассажирские лифты подвешиваются на несколько канатов, самолеты снабжены несколькими двигателями, имеют дублированную электропроводку, в автомобилях применяется двойная и даже тройная система тормозов. Большое распространение получило и прочностное резервирование, основанное на концепции коэффициента запаса. Считается, что понятие прочности имеет самое непосредственное отношение не только к надежности, но и к безопасности. Более того, считается, что инженерные расчеты конструкций на безопасность почти исключительно строятся на использовании коэффициента запаса прочности. Значения этого коэффициента зависят от конкретных условий. Для сосудов, работающих под давлением, он составляет от 1,5 до 3,25, а для лифтовых канатов — от 8 до 25.
При рассмотрении производственного процесса во взаимосвязи его основных элементов необходимо использовать понятие надежности в более широком смысле. При этом надежность системы в целом будет отличаться от совокупности надежности ее элементов за счет влияния различных связей.
В теории надежности доказано, что надежность устройства, состоящего из отдельных элементов, соединенных (в надежностном смысле) последовательно, равна произведению значений вероятностей безотказной работы каждого элемента.
Связь надежности и безопасности совершенно очевидна: чем надежнее система, тем она безопаснее. Более того, вероятность несчастного случая можно трактовать как «надежность системы».
В то же время безопасность и надежность являются родственными, но не тождественными понятиями. Они дополняют одно другое. Так с точки зрения потребителя оборудование может быть надежным или не надежным, а по технике безопасности — безопасным или опасным. При этом оборудование бывает безопасным и надежным (приемлемо во всех отношениях), опасным и не надежным (безоговорочно отвергается), безопасным и не надежным (чаще всего отвергается потребителем), опасным и надежным (отвергается по техники безопасности, но может быть приемлемо для потребителя, если степень опасности не слишком велика).
Требования безопасности часто выступают в качестве ограничений на ресурс и срок службы оборудования или устройства. Это происходит, когда требуемый уровень безопасности нарушается до достижения предельного состояния вследствие физического или морального старения. Ограничения из-за требований безопасности играют особенно важную роль при оценке индивидуального остаточного ресурса, под которым понимается продолжительность эксплуатации от данного момента времени до достижения предельного состояния. В качестве меры ресурса может быть выбран любой параметр, характеризующийся продолжительностью эксплуатации объекта. Для летательных аппаратов мерой ресурса служит налет в часах, для транспортных средств — пробег в километрах, для прокатных станов — масса прокатного метала в тоннах и т.д.
Наиболее универсальной единицей с точки зрения общей методологии и теории надежности является единица времени. Это обусловлено следующими обстоятельствами. Во — первых, время эксплуатации технического объекта включает и перерывы, в течение которых суммарная наработка не нарастает, а свойства материалов могут изменяться. Во — вторых, применение экономико-матеатических моделей для обоснования назначенного ресурса возможно лишь с использованием назначенного срока службы (срок службы определяется как календарная продолжительность от начала эксплуатации объекта или его возобновления после ремонта определенного вида до перехода в предельное состояние и измеряется в единицах календарного времени). В — третьих, исчисление ресурса в единицах времени позволяет ставить задачи прогнозирования в наиболее общей форме.
Начальный импульс к созданию численных методов оценки надежности был дан в связи с развитием авиационной промышленности и низким уровнем безопасности полетов на начальных этапах. Значительное число авиационных катастроф при постоянно возрастающей интенсивности воздушных ресурсов обусловило необходимость выработки критериев надежности для самолетов и требований к уровню безопасности. В частности, был проведен сравнительный анализ одного из многочисленных самолетов с точки зрения успешного завершения полетов.
Показательной с точки зрения безопасности является хронология развития теории и техники надежности. В 40-х годах основные усилия для повышения надежности были сконцентрированы на всестороннем улучшении качества, причем превалирующее значение имел экономический фактор. Для увеличения долговечности узлов и агрегатов различных видов оборудования разрабатывались улучшенные конструкции, прочные материалы, совершенные измерительные инструменты. В частности, электротехническое отделение фирмы «General Motors» (США) увеличило активный ресурс приводных двигателей локомотивов с 400 тыс. до 1,6 млн. км за счет использования улучшенной изоляции и применения усовершенствованных конических и сферических роликовых подшипников, а также проведения испытаний при высокой температуре. Был достигнут прогресс в разработке ремонтопригодных конструкций и в обеспечении предприятий оборудованием, инструментом и документацией для выполнения профилактических работ и операций по техническому обслуживанию.
Одновременно получило распространение составление и утверждение типовых графиков периодических проверок, карт контроля высокопроизводительного станочного оборудования.
В 50-е годы большое значение стали придавать вопросам обеспечения безопасности, особенно в таких перспективных отраслях, как космонавтика и атомная энергетика. Этот период является началом использования многих широко распространенных в настоящее время понятий по надежности элементов технических устройств, таких, как ожидаемая долговечность, соответствие конструкции заданным требованиям, прогнозирование показателей надежности.
В 60-е годы стала очевидной острая необходимость в новых методах обеспечения надежности и более широкое их применения. Центр внимания переместился от анализа поведения отдельных элементов различного типа (механических, электрических или гидравлических) на последствия, вызываемые отказом этих элементов в соответствующей системе. В течение первых лет эры космических полетов значительные усилия были затрачены на испытания систем и отдельных элементов. Для достижения высокой степени надежности получил развитие анализ блок-схем в качестве основных моделей. Однако с увеличением сложности блок-схем появилась необходимость в другом подходе, был предложен, а затем получил широкое распространение принцип анализа систем с помощью дерева отказов. Впервые он использовался в качестве программы для оценки надежности системы управления запуском ракет «МИНИТМЕН».
Впоследствии методика построения дерева отказов была усовершенствована и распространена на широкий круг различных технических систем. После катастрофических аварий на подземных комплексах запуска межконтинентальных баллистических ракет в США официально было введено в практику изучение безопасности систем как отдельной независимой деятельности. Министерство обороны США ввело требование по проведению анализа надежности на всех этапах разработки всех видов вооружения. Параллельно были разработаны требования по надежности, работоспособности и ремонтопригодности промышленных изделий.
В 70-е годы наиболее заметной была работа по оценке риска, связанного с эксплуатацией атомных электростанций, которая проводилась на основе анализа широкого спектра аварий. Ее основная направленность заключалась в оценке потенциальных последствий подобных аварий для населения в поисках путей обеспечения безопасности.
В последнее время проблема риска приобрела очень серьезное значение и до настоящего времени привлекает все возрастающее внимание специалистов самых различных областей знаний. Это понятие настолько присуще как безопасности, так и надежности, что термины «надежность», «опасность» и «риск» часто смешивают.
Среди технических причин несчастных случаев на производстве причины, связанные с недостаточной надежностью производственного оборудования, сооружений, устройств или их элементов, занимают особое место, поскольку чаще всего они проявляются внезапно и в связи с этим характеризуются высокими показателями тяжести травм.
Большое количество видов, используемых в промышленности, строительстве и на транспорте металлоемкого оборудования и конструкций является источником опасных производственных факторов вследствие существующей возможности аварийного выхода из строя отдельных деталей и узлов.
Основной целью анализа надежности и связанной с ней безопасности производственного оборудования и устройств является уменьшение отказов (в первую очередь травмоопасных) и связанных с ними человеческих жертв, экономических потерь и нарушений в окружающей среде.
В настоящее время существует довольно много методов анализа надежности и безопасности. Так наиболее простым и традиционным для надежности является метод структурных схем. При этом объект представляется в виде системы отдельных элементов, для которых возможно и целесообразно определить показатели надежности. Структурные схемы применяются для расчета вероятности отказов при условии, что в каждом элементе одновременно возможен только один отказ. Подобные ограничения вызвали появление других методов анализа.
Наиболее распространенным методом, получившим широкое применение в различных отраслях, является анализ с помощью дерева отказов. Данный анализ четко ориентирован на отыскание отказов и при этом выявляет такие аспекты системы, которые имеют важное значение для рассматриваемых отказов. Одновременно обеспечивается графический, наглядный материал. Наглядность дает специалисту возможность глубоко проникнуть в процесс работы системы и в тоже время позволяет сосредотачиваться на отдельных конкретных ее отказах.
Главное преимущество дерева отказов по сравнению с другими методами заключается в том, что анализ ограничивается выявлением только тех элементов системы и событий, которые приводят к данному конкретному отказу системы. В тоже время построение дерева отказов является определенным видом искусства в науке, поскольку нет аналитиков, которые бы составили два идентичных дерева отказов.
Чтобы отыскать и наглядно представить причинную взаимосвязь с помощью дерева отказов, необходимо использовать элементарные блоки, подразделяющие и связывающие большое число событий.
Таким образом, применяемые в настоящее время методы анализа надежности и безопасности оборудования и устройств, хотя и имеют определенные недостатки, все же позволяют достаточно эффективно определять причины различного рода отказов даже у сравнительно сложных систем. Последнее особенно актуально в связи с большой значимостью проблемы возникновения опасностей, обусловленных недостаточной надежностью технических объектов.