Инженерия надежности — это подраздел системной инженерии , который делает акцент на способности оборудования функционировать без сбоев. Надежность определяется как вероятность того, что продукт, система или услуга будут выполнять свою предполагаемую функцию адекватно в течение определенного периода времени ИЛИ будут работать в определенной среде без сбоев. [1] Надежность тесно связана с доступностью , которая обычно описывается как способность компонента или системы функционировать в определенный момент или интервал времени.
Функция надежности теоретически определяется как вероятность успеха. На практике она рассчитывается с использованием различных методов, и ее значение находится в диапазоне от 0 до 1, где 0 указывает на отсутствие вероятности успеха, а 1 указывает на определенный успех. Эта вероятность оценивается на основе детального (физики отказа) анализа, предыдущих наборов данных или посредством тестирования надежности и моделирования надежности. Доступность , проверяемость , ремонтопригодность и обслуживание часто определяются как часть «инженерии надежности» в программах надежности. Надежность часто играет ключевую роль в экономической эффективности систем.
Инженерия надежности занимается прогнозированием, предотвращением и управлением высокими уровнями инженерной неопределенности « жизненного цикла » и рисками отказа. Хотя стохастические параметры определяют и влияют на надежность, надежность достигается не только математикой и статистикой. [2] [3] «Почти все учения и литература по этому предмету подчеркивают эти аспекты и игнорируют реальность того, что диапазоны неопределенности в значительной степени делают недействительными количественные методы прогнозирования и измерения». [4] Например, легко представить «вероятность отказа» как символ или значение в уравнении, но почти невозможно предсказать ее истинную величину на практике, которая является чрезвычайно многомерной , поэтому наличие уравнения для надежности не равнозначно наличию точного предиктивного измерения надежности.
Инженерия надежности тесно связана с инженерией качества, инженерией безопасности и безопасностью систем , поскольку они используют общие методы для своего анализа и могут требовать ввода друг от друга. Можно сказать, что система должна быть надежно безопасной.
При проектировании надежности основное внимание уделяется расходам на отказ, вызванный простоем системы, расходам на запасные части, ремонтное оборудование, персонал и расходам на гарантийные претензии. [5]
Слово «надежность» можно проследить до 1816 года, и оно впервые засвидетельствовано поэтом Сэмюэлем Тейлором Кольриджем . [6] До Второй мировой войны этот термин был связан в основном с повторяемостью ; тест (в любом типе науки) считался «надежным», если одни и те же результаты были получены повторно. В 1920-х годах улучшение продукта посредством использования статистического контроля процесса было предложено доктором Уолтером А. Шухартом в Bell Labs [ 7] примерно в то время, когда Уолодди Вейбулл работал над статистическими моделями усталости. Развитие техники надежности здесь шло по параллельному пути с качеством. Современное использование слова «надежность» было определено военными США в 1940-х годах, характеризуя продукт, который будет работать, когда ожидается, и в течение определенного периода.
Во время Второй мировой войны многие проблемы с надежностью были вызваны изначальной ненадежностью электронного оборудования, доступного в то время, и проблемами усталости. В 1945 году MA Miner опубликовал основополагающую статью под названием «Накопительное повреждение при усталости» в журнале ASME. Основным применением техники надежности в армии было использование электронных ламп в радиолокационных системах и другой электронике, для которой надежность оказалась очень проблематичной и дорогостоящей. IEEE сформировал Общество надежности в 1948 году. В 1950 году Министерство обороны США сформировало группу под названием «Консультативная группа по надежности электронного оборудования» (AGREE) для исследования методов надежности военного оборудования. [8] Эта группа рекомендовала три основных способа работы:
В 1960-х годах больше внимания уделялось проверке надежности на уровне компонентов и систем. В то время был создан знаменитый военный стандарт MIL-STD-781. Примерно в это же время RCA опубликовала широко используемый предшественник военного справочника 217 , который использовался для прогнозирования интенсивности отказов электронных компонентов. Акцент на надежности компонентов и эмпирических исследованиях (например, Mil Std 217) постепенно уменьшался. Использовались более прагматичные подходы, используемые в потребительской промышленности. В 1980-х годах телевизоры все чаще изготавливались из твердотельных полупроводников. Автомобили быстро увеличивали использование полупроводников с различными микрокомпьютерами под капотом и на панели приборов. Большие системы кондиционирования воздуха разработали электронные контроллеры, как и микроволновые печи и множество других приборов. Системы связи начали использовать электронику для замены старых механических коммутационных систем. Bellcore выпустила первую методологию потребительского прогнозирования для телекоммуникаций, а SAE разработала аналогичный документ SAE870050 для автомобильных приложений. Характер прогнозов развивался в течение десятилетия, и стало очевидно, что сложность кристалла не является единственным фактором, определяющим частоту отказов интегральных схем (ИС). Кам Вонг опубликовал статью, в которой подверг сомнению кривую ванны [9] — см. также обслуживание, ориентированное на надежность . В течение этого десятилетия частота отказов многих компонентов снизилась в 10 раз. Программное обеспечение стало важным для надежности систем. К 1990-м годам темпы разработки ИС набирали обороты. Более широкое использование автономных микрокомпьютеров стало обычным явлением, а рынок ПК помог поддерживать плотность ИС в соответствии с законом Мура и удваиваться примерно каждые 18 месяцев. Теперь техника надежности менялась по мере продвижения к пониманию физики отказов . Частота отказов компонентов продолжала снижаться, но проблемы на уровне системы становились все более заметными. Системное мышление становилось все более и более важным. Для программного обеспечения была разработана модель CMM ( модель зрелости возможностей ), которая дала более качественный подход к надежности. ISO 9000 добавил меры надежности как часть сертификации по проектированию и разработке. Расширение Всемирной паутины создало новые проблемы безопасности и доверия. Старая проблема слишком малого количества надежной информации теперь была заменена слишком большим количеством информации сомнительной ценности. Проблемы надежности потребителей теперь можно было обсуждать онлайн в режиме реального времени с использованием данных. Новые технологии, такие как микроэлектромеханические системы ( MEMS ), портативные GPSи карманные устройства, объединяющие сотовые телефоны и компьютеры, представляют собой проблемы для поддержания надежности. Время разработки продукта продолжало сокращаться в течение этого десятилетия, и то, что было сделано за три года, теперь делалось за 18 месяцев. Это означало, что инструменты и задачи обеспечения надежности должны были быть более тесно связаны с самим процессом разработки. Во многих отношениях надежность стала частью повседневной жизни и ожиданий потребителей.
Надежность — это вероятность того, что продукт будет выполнять свою предполагаемую функцию в заданных условиях эксплуатации таким образом, чтобы это соответствовало или превосходило ожидания клиентов. [10]
Цели проектирования надежности, в порядке убывания приоритета, следующие: [11]
Причина приоритетного акцента в том, что это, безусловно, самый эффективный способ работы с точки зрения минимизации затрат и создания надежных продуктов. Поэтому основными навыками, которые требуются, являются способность понимать и предвидеть возможные причины сбоев, а также знание того, как их предотвратить. Также необходимо знать методы, которые можно использовать для анализа конструкций и данных.
Инженерия надежности для " сложных систем " требует иного, более сложного системного подхода, чем для несложных систем. Инженерия надежности может в этом случае включать:
Эффективное проектирование надежности требует понимания основ механизмов отказов, для чего требуются опыт, широкие инженерные навыки и хорошие знания из многих различных специальных областей техники, [12] например:
Надежность можно определить следующими способами:
Многие инженерные методы используются в оценках риска надежности , такие как блок-схемы надежности, анализ опасностей , анализ видов и последствий отказов (FMEA), [13] анализ дерева отказов (FTA), обслуживание, ориентированное на надежность , (вероятностные) расчеты нагрузки и напряжения материала и износа, (вероятностный) анализ усталости и ползучести, анализ человеческих ошибок, анализ производственных дефектов, тестирование надежности и т. д. Эти анализы должны быть выполнены надлежащим образом и с большим вниманием к деталям, чтобы быть эффективными. Из-за большого количества методов надежности, их стоимости и различных степеней надежности, требуемых для разных ситуаций, большинство проектов разрабатывают план программы надежности, чтобы указать задачи надежности ( требования к описанию работ (SoW)), которые будут выполнены для этой конкретной системы.
В соответствии с созданием обоснований безопасности , например, согласно ARP4761 , цель оценки надежности заключается в предоставлении надежного набора качественных и количественных доказательств того, что использование компонента или системы не будет связано с неприемлемым риском. Основные шаги, которые необходимо предпринять [14] , следующие:
Риск здесь представляет собой сочетание вероятности и серьезности инцидента (сценария) отказа. Серьезность можно рассматривать с точки зрения безопасности системы или доступности системы. Надежность для безопасности можно рассматривать как совершенно иной фокус, чем надежность для доступности системы. Доступность и безопасность могут существовать в динамическом напряжении, поскольку поддержание слишком высокой доступности системы может быть небезопасным. Слишком быстрое принудительное приведение инженерной системы в безопасное состояние может вызвать ложные тревоги, которые препятствуют доступности системы.
В определении de minimis серьезность отказов включает стоимость запасных частей, человеко-часов, логистики, ущерба (вторичные отказы) и простоя машин, которые могут привести к потере производства. Более полное определение отказа также может означать травмы, расчленение и смерть людей в системе (свидетельство о несчастных случаях на шахтах, промышленных авариях, отказах космических челноков) и то же самое для невинных прохожих (свидетельство о гражданах таких городов, как Бхопал, Лав-Канал, Чернобыль или Сендай и других жертв землетрясения и цунами в Тохоку 2011 года) — в этом случае инженерия надежности становится безопасностью системы. То, что приемлемо, определяется управляющим органом или клиентами или пострадавшими сообществами. Остаточный риск — это риск, который остается после завершения всех мероприятий по обеспечению надежности, и включает в себя неопознанный риск — и, следовательно, не поддается полной количественной оценке.
Сложность технических систем, таких как усовершенствования конструкции и материалов, плановые проверки, конструкция с защитой от дурака и резервное резервирование, снижает риск и увеличивает стоимость. Риск может быть снижен до уровней ALARA (настолько низко, насколько это разумно достижимо) или ALAPA (настолько низко, насколько это практически достижимо).
Реализация программы надежности — это не просто покупка программного обеспечения; это не просто контрольный список пунктов, которые должны быть выполнены, чтобы гарантировать наличие надежных продуктов и процессов. Программа надежности — это сложная система обучения и знаний, уникальная для ваших продуктов и процессов. Она поддерживается руководством, строится на навыках, которые вы развиваете в команде, интегрируется в бизнес-процессы и выполняется с использованием проверенных стандартных рабочих практик. [15]
План программы обеспечения надежности используется для документирования того, какие именно «лучшие практики» (задачи, методы, инструменты, анализ и тесты) требуются для конкретной (под)системы, а также для уточнения требований заказчика к оценке надежности. Для крупномасштабных сложных систем план программы обеспечения надежности должен быть отдельным документом . Определение ресурсов для рабочей силы и бюджетов для тестирования и других задач имеет решающее значение для успешной программы. В целом, объем работы, требуемый для эффективной программы для сложных систем, велик.
План программы обеспечения надежности необходим для достижения высокого уровня надежности, тестируемости, ремонтопригодности и, как следствие, доступности системы , и разрабатывается на ранних этапах разработки системы и уточняется в течение ее жизненного цикла. Он определяет не только то, что делает инженер по надежности, но и задачи, выполняемые другими заинтересованными сторонами . Эффективный план программы обеспечения надежности должен быть одобрен высшим руководством программы, которое несет ответственность за выделение достаточных ресурсов для его реализации.
План программы обеспечения надежности также может использоваться для оценки и улучшения доступности системы с помощью стратегии фокусировки на повышении тестируемости и ремонтопригодности, а не на надежности. Улучшить ремонтопригодность, как правило, проще, чем улучшить надежность. Оценки ремонтопригодности (скорости ремонта) также, как правило, более точны. Однако, поскольку неопределенности в оценках надежности в большинстве случаев очень велики, они, вероятно, будут доминировать в расчете доступности (проблема неопределенности прогнозирования), даже когда уровни ремонтопригодности очень высоки. Когда надежность не находится под контролем, могут возникнуть более сложные проблемы, такие как нехватка рабочей силы (обслуживающего персонала/возможности обслуживания клиентов), доступность запасных частей, логистические задержки, отсутствие ремонтных мощностей, обширная модернизация и сложные затраты на управление конфигурацией и другие. Проблема ненадежности может также усугубляться из-за «эффекта домино» отказов, вызванных обслуживанием после ремонта. Поэтому сосредоточения только на ремонтопригодности недостаточно. Если отказы предотвращены, ни одна из других проблем не имеет никакого значения, и поэтому надежность обычно считается самой важной частью доступности. Надежность необходимо оценивать и улучшать в отношении как доступности, так и совокупной стоимости владения (TCO) из-за стоимости запасных частей, человеко-часов на техническое обслуживание, транспортных расходов, расходов на хранение, рисков устаревания деталей и т. д. Но, как с опозданием обнаружили GM и Toyota, TCO также включает в себя расходы на последующую ответственность, когда расчеты надежности недостаточно или неточно учитывают физические риски клиентов. Часто между ними необходим компромисс. Может быть максимальное соотношение между доступностью и стоимостью владения. Тестируемость системы также должна быть рассмотрена в плане, поскольку это связь между надежностью и ремонтопригодностью. Стратегия обслуживания может влиять на надежность системы (например, путем профилактического и/или предиктивного обслуживания ), хотя она никогда не может поднять ее выше присущей надежности.
План надежности должен четко предусматривать стратегию контроля доступности. То, что важнее — только доступность или также стоимость владения, зависит от использования системы. Например, система, которая является критически важным звеном в производственной системе, например, большая нефтяная платформа, обычно может иметь очень высокую стоимость владения, если эта стоимость приводит даже к незначительному увеличению доступности, поскольку недоступность платформы приводит к огромной потере дохода, которая может легко превысить высокую стоимость владения. Правильный план надежности всегда должен рассматривать анализ RAMT в его общем контексте. RAMT означает надежность, доступность, ремонтопригодность/обслуживание и проверяемость в контексте потребностей клиента.
Для любой системы одной из первых задач проектирования надежности является адекватное определение требований к надежности и ремонтопригодности, выделенных из общих потребностей доступности и, что более важно, выведенных из надлежащего анализа отказов конструкции или предварительных результатов испытаний прототипа. Четкие требования (которые можно разработать) должны ограничивать проектировщиков от проектирования конкретных ненадежных элементов/конструкций/интерфейсов/систем. Установка только целевых показателей доступности, надежности, тестируемости или ремонтопригодности (например, максимальных частот отказов) нецелесообразна. Это широко распространенное заблуждение относительно проектирования требований к надежности. Требования к надежности касаются самой системы, включая требования к испытаниям и оценке, а также связанные с ними задачи и документацию. Требования к надежности включены в соответствующие спецификации требований к системе или подсистеме, планы испытаний и контрактные заявления. Создание надлежащих требований более низкого уровня имеет решающее значение. [16] Предоставление только количественных минимальных целей (например, значений среднего времени между отказами (MTBF) или частот отказов) недостаточно по разным причинам. Одна из причин заключается в том, что полная проверка (связанная с правильностью и проверяемостью во времени) количественного распределения надежности (спецификация требований) на более низких уровнях для сложных систем (часто) не может быть выполнена из-за (1) того факта, что требования являются вероятностными, (2) чрезвычайно высокого уровня неопределенностей, связанных с демонстрацией соответствия всем этим вероятностным требованиям, и потому что (3) надежность является функцией времени, а точные оценки (вероятностного) числа надежности для каждого элемента доступны только на очень поздних этапах проекта, иногда даже после многих лет эксплуатации. Сравните эту проблему с непрерывной (пере)балансировкой, например, требований к массе системы более низкого уровня при разработке самолета, что и так часто является большой задачей. Обратите внимание, что в этом случае массы отличаются только на несколько %, не являются функцией времени, а данные являются невероятностными и уже доступны в моделях САПР. В случае надежности уровни ненадежности (частоты отказов) могут меняться в десятки раз (кратно 10) в результате очень незначительных отклонений в конструкции, процессе или чем-либо еще. [17]Информация часто недоступна без огромных неопределенностей на этапе разработки. Это делает эту проблему распределения практически невозможной для полезного, практичного, обоснованного способа, который не приводит к массивной избыточной или недостаточной спецификации. Поэтому необходим прагматичный подход, например: использование общих уровней/классов количественных требований, зависящих только от серьезности последствий отказов. Кроме того, проверка результатов является гораздо более субъективной задачей, чем любой другой тип требований. (Количественные) параметры надежности — в терминах MTBF — являются, безусловно, самыми неопределенными параметрами проектирования в любой конструкции.
Кроме того, требования к надежности конструкции должны побуждать конструкцию (системы или детали) включать функции, которые предотвращают возникновение отказов или ограничивают последствия отказа в первую очередь. Это не только поможет в некоторых прогнозах, но и не позволит отвлекать инженерные усилия на своего рода бухгалтерскую работу. Требование к конструкции должно быть достаточно точным, чтобы проектировщик мог «спроектировать» его и также мог доказать — посредством анализа или тестирования — что требование было достигнуто, и, если возможно, в пределах некоторой заявленной уверенности. Любой тип требования к надежности должен быть детализирован и может быть получен из анализа отказов (анализ напряжений и усталости конечных элементов, анализ рисков надежности, FTA, FMEA, анализ человеческого фактора, анализ функциональных рисков и т. д.) или любого типа испытания надежности. Кроме того, необходимы требования для проверочных испытаний (например, требуемые перегрузочные напряжения) и необходимое время испытаний. Чтобы вывести эти требования эффективным образом, следует использовать логику оценки и смягчения рисков на основе системной инженерии . Необходимо создать надежные системы журналов опасностей, которые содержат подробную информацию о том, почему и как системы могли или уже вышли из строя. Требования должны быть получены и отслежены таким образом. Эти практические требования к проектированию должны определять проектирование и не использоваться только для целей проверки. Эти требования (часто ограничения проекта) таким образом выводятся из анализа отказов или предварительных испытаний. Понимание этого различия по сравнению с чисто количественными (логистическими) требованиями (например, целевой показатель частоты отказов/среднего времени безотказной работы) имеет первостепенное значение для разработки успешных (сложных) систем. [18]
Требования к ремонтопригодности касаются как стоимости ремонта, так и времени ремонта. Требования к тестируемости (не путать с требованиями к испытаниям) обеспечивают связь между надежностью и ремонтопригодностью и должны касаться обнаружения режимов отказа (на определенном системном уровне), уровней изоляции и создания диагностики (процедур). Как указано выше, инженеры по надежности также должны рассматривать требования к различным задачам надежности и документации во время разработки, тестирования, производства и эксплуатации системы. Эти требования обычно указываются в контрактном техническом задании и зависят от того, какую свободу действий заказчик желает предоставить подрядчику. Задачи по надежности включают различные анализы, планирование и отчеты об отказах. Выбор задач зависит от критичности системы, а также от стоимости. Критически важная для безопасности система может потребовать формального отчета об отказах и процесса проверки на протяжении всей разработки, тогда как некритическая система может полагаться на окончательные отчеты об испытаниях. Наиболее распространенные задачи программы надежности документированы в стандартах программы надежности, таких как MIL-STD-785 и IEEE 1332. Анализ отчетов об отказах и системы корректирующих действий являются общим подходом к мониторингу надежности продукта/процесса.
На практике большинство сбоев можно объяснить человеческим фактором , например:
Однако люди также очень хорошо умеют обнаруживать такие сбои, исправлять их и импровизировать при возникновении нештатных ситуаций. Поэтому политика, которая полностью исключает человеческие действия в процессах проектирования и производства для повышения надежности, может быть неэффективной. Некоторые задачи лучше выполняются людьми, а некоторые — машинами. [19]
Кроме того, человеческие ошибки в управлении, организация данных и информации, или неправильное использование или злоупотребление элементами также могут способствовать ненадежности. Это основная причина, по которой высокие уровни надежности для сложных систем могут быть достигнуты только путем следования надежному процессу системной инженерии с надлежащим планированием и выполнением задач валидации и верификации. Это также включает в себя тщательную организацию обмена данными и информацией и создание «культуры надежности», таким же образом, как наличие «культуры безопасности» имеет первостепенное значение при разработке критически важных для безопасности систем.
Прогнозирование надежности объединяет:
Для существующих систем можно утверждать, что любая попытка ответственной программы исправить первопричину обнаруженных сбоев может сделать первоначальную оценку MTBF недействительной, поскольку должны быть сделаны новые предположения (сами подверженные высокому уровню ошибок) о влиянии этой коррекции. Другой практической проблемой является общая недоступность подробных данных об отказах, а те, которые доступны, часто содержат непоследовательную фильтрацию данных об отказах (обратной связи) и игнорируют статистические ошибки (которые очень высоки для редких событий, таких как отказы, связанные с надежностью). Должны быть очень четкие указания по подсчету и сравнению отказов, связанных с различными типами первопричин (например, отказы, вызванные производством, обслуживанием, транспортировкой, системой или неотъемлемые отказы конструкции). Сравнение различных типов причин может привести к неверным оценкам и неверным бизнес-решениям относительно фокуса улучшения.
Выполнение надлежащего количественного прогноза надежности для систем может быть сложным и очень дорогим, если делать это путем тестирования. На уровне отдельных деталей результаты надежности часто можно получить со сравнительно высокой уверенностью, поскольку тестирование многих образцов деталей может быть возможным с использованием имеющегося бюджета тестирования. Однако, к сожалению, эти тесты могут быть недостаточно достоверными на уровне системы из-за предположений, сделанных при тестировании на уровне деталей. Эти авторы подчеркнули важность первоначального тестирования на уровне деталей или системы до отказа и извлечения уроков из таких отказов для улучшения системы или детали. Сделан общий вывод, что точное и абсолютное прогнозирование надежности — либо путем сравнения полевых данных, либо путем тестирования — в большинстве случаев невозможно. Исключением могут быть отказы из-за проблем износа, таких как усталостные отказы. Во введении к MIL-STD-785 написано, что прогнозирование надежности следует использовать с большой осторожностью, если только оно не используется исключительно для сравнения в исследованиях компромиссов.
Проектирование для надежности (DfR) — это процесс, который охватывает инструменты и процедуры, гарантирующие, что продукт соответствует требованиям надежности в условиях его использования на протяжении всего срока службы. DfR внедряется на этапе проектирования продукта для упреждающего повышения надежности продукта. [21] DfR часто используется как часть общей стратегии проектирования для совершенства (DfX) .
Проектирование надежности начинается с разработки (системной) модели . Модели надежности и доступности используют блок-схемы и анализ дерева неисправностей для предоставления графических средств оценки взаимосвязей между различными частями системы. Эти модели могут включать прогнозы, основанные на показателях отказов, взятых из исторических данных. Хотя прогнозы (входных данных) часто неточны в абсолютном смысле, они ценны для оценки относительных различий в альтернативных вариантах проектирования. Параметры ремонтопригодности, например, среднее время ремонта (MTTR), также могут использоваться в качестве входных данных для таких моделей.
Наиболее важные фундаментальные инициирующие причины и механизмы отказов должны быть идентифицированы и проанализированы с помощью инженерных инструментов. Разнообразный набор практических рекомендаций по производительности и надежности должен быть предоставлен проектировщикам, чтобы они могли создавать низконапряженные конструкции и продукты, которые защищают или защищены от повреждений и чрезмерного износа. Может потребоваться надлежащая валидация входных нагрузок (требований) в дополнение к проверке надежности "производительности" путем испытаний.
Одним из важнейших методов проектирования является избыточность . Это означает, что если одна часть системы выходит из строя, есть альтернативный путь к успеху, например, резервная система. Причина, по которой это является окончательным выбором проектирования, связана с тем фактом, что высоконадежные доказательства надежности для новых деталей или систем часто отсутствуют или их получение чрезвычайно дорого. Объединяя избыточность вместе с высоким уровнем мониторинга отказов и избеганием отказов по общей причине; даже система с относительно низкой надежностью одного канала (части) может стать высоконадежной на системном уровне (вплоть до надежности, критически важной для миссии). Для этого не требуется никаких испытаний надежности. В сочетании с избыточностью использование разнородных конструкций или производственных процессов (например, через разных поставщиков аналогичных деталей) для отдельных независимых каналов может обеспечить меньшую чувствительность к проблемам качества (например, ранние отказы у одного поставщика), что позволяет достичь очень высоких уровней надежности на всех этапах цикла разработки (от раннего срока службы до долгосрочной). Избыточность также может применяться в системной инженерии путем повторной проверки требований, данных, проектов, расчетов, программного обеспечения и тестов для устранения систематических сбоев.
Другим эффективным способом решения проблем надежности является выполнение анализа, который предсказывает деградацию, позволяя предотвратить незапланированные простои/сбои. Для этого можно использовать программы RCM (Reliability Centered Maintenance).
Для электронных сборок наблюдается все больший сдвиг в сторону другого подхода, называемого физикой отказа . Этот метод основан на понимании физических статических и динамических механизмов отказа. Он учитывает изменения нагрузки, прочности и напряжения, которые приводят к отказу с высоким уровнем детализации, что стало возможным благодаря использованию современных программных продуктов метода конечных элементов (FEM), которые могут обрабатывать сложные геометрии и механизмы, такие как ползучесть, релаксация напряжений, усталость и вероятностное проектирование ( методы Монте-Карло /DOE). Материал или компонент можно перепроектировать, чтобы снизить вероятность отказа и сделать его более устойчивым к таким изменениям. Другой распространенный метод проектирования - это снижение номинальных характеристик компонента : т. е. выбор компонентов, характеристики которых значительно превышают ожидаемые уровни напряжения, например, использование более толстого электрического провода, чем обычно указывается для ожидаемого электрического тока .
Многие задачи, методы и анализы, используемые в проектировании надежности, специфичны для конкретных отраслей и приложений, но обычно могут включать:
Результаты этих методов представляются во время обзоров конструкции детали или системы, а также логистики. Надежность — это лишь одно из многих требований для сложной детали или системы. Инженерные компромиссные исследования используются для определения оптимального баланса между требованиями надежности и другими ограничениями.
Инженеры по надежности, независимо от того, используют ли они количественные или качественные методы для описания отказа или опасности, полагаются на язык, чтобы точно определить риски и разрешить проблемы. Используемый язык должен помочь создать упорядоченное описание функции/элемента/системы и ее сложного окружения, поскольку оно связано с отказом этих функций/элементов/систем. Системная инженерия во многом заключается в поиске правильных слов для описания проблемы (и связанных с ней рисков), чтобы их можно было легко решить с помощью инженерных решений. Джек Ринг сказал, что работа системного инженера заключается в «языке проекта». (Ринг и др., 2000 г.) [23] В случае отказов деталей/систем инженеры по надежности должны больше концентрироваться на «почему и как», а не на прогнозировании «когда». Понимание «почему» произошел отказ (например, из-за перенапряженных компонентов или производственных проблем) с гораздо большей вероятностью приведет к улучшению используемых конструкций и процессов [4] , чем количественное определение «когда» вероятно произойдет отказ (например, путем определения MTBF). Для этого сначала необходимо классифицировать и упорядочить опасности надежности, связанные с деталью/системой (на основе некоторой формы качественной и количественной логики, если это возможно), чтобы обеспечить более эффективную оценку и возможное улучшение. Это частично делается на чистом языке и логике предложений , но также на основе опыта работы с аналогичными элементами. Это можно увидеть, например, в описаниях событий в анализе дерева неисправностей , анализе FMEA и журналах (отслеживания) опасностей. В этом смысле язык и правильная грамматика (часть качественного анализа) играют важную роль в инженерии надежности, так же как и в инженерии безопасности или в целом в системной инженерии .
Правильное использование языка также может быть ключом к выявлению или снижению рисков человеческой ошибки , которые часто являются первопричиной многих сбоев. Это может включать в себя надлежащие инструкции в руководствах по техническому обслуживанию, руководствах по эксплуатации, аварийных процедурах и других для предотвращения систематических человеческих ошибок, которые могут привести к сбоям системы. Они должны быть написаны обученными или опытными техническими авторами с использованием так называемого упрощенного английского языка или упрощенного технического английского языка , где слова и структура специально подобраны и созданы таким образом, чтобы уменьшить двусмысленность или риск путаницы (например, «заменить старую деталь» может неоднозначно относиться к замене изношенной детали на неизношенную или замене детали на деталь, использующую более новую и, как мы надеемся, улучшенную конструкцию).
Моделирование надежности — это процесс прогнозирования или понимания надежности компонента или системы до его внедрения. Два типа анализа, которые часто используются для моделирования поведения доступности полной системы , включая эффекты от логистических вопросов, таких как обеспечение запасными частями, транспортировка и рабочая сила, — это анализ дерева неисправностей и блок-схемы надежности . На уровне компонента одни и те же типы анализов могут использоваться вместе с другими. Входные данные для моделей могут поступать из многих источников, включая тестирование; предыдущий опыт эксплуатации; полевые данные; а также справочники данных из аналогичных или смежных отраслей. Независимо от источника, все входные данные модели должны использоваться с большой осторожностью, поскольку прогнозы действительны только в случаях, когда один и тот же продукт использовался в одном и том же контексте. Таким образом, прогнозы часто используются только для сравнения альтернатив.
Для прогнозов на уровне деталей распространены две отдельные области исследований:
Надежность определяется как вероятность того, что устройство будет выполнять свою предполагаемую функцию в течение определенного периода времени при указанных условиях. Математически это может быть выражено как,
,
где — функция плотности вероятности отказа , а — длительность периода времени (предполагается, что он начинается с нулевого времени).
Вот несколько ключевых элементов этого определения:
Количественные требования указываются с помощью параметров надежности . Наиболее распространенным параметром надежности является среднее время до отказа (MTTF), которое также может быть указано как частота отказов (это выражается как частота или условная функция плотности вероятности (PDF)) или количество отказов в течение определенного периода. Эти параметры могут быть полезны для более высоких уровней системы и систем, которые часто эксплуатируются (т. е. транспортные средства, машины и электронное оборудование). Надежность увеличивается с увеличением MTTF. MTTF обычно указывается в часах, но может также использоваться с другими единицами измерения, такими как мили или циклы. Использование значений MTTF на более низких уровнях системы может быть очень обманчивым, особенно если они не указывают связанные режимы и механизмы отказов (F в MTTF). [17]
В других случаях надежность определяется как вероятность успеха миссии. Например, надежность запланированного полета самолета может быть определена как безразмерная вероятность или процент, как часто используется в проектировании безопасности систем .
Особым случаем успеха миссии является устройство или система одноразового действия. Это устройства или системы, которые остаются относительно бездействующими и срабатывают только один раз. Примерами служат автомобильные подушки безопасности , тепловые батареи и ракеты . Надежность одноразового действия указывается как вероятность одноразового успеха или включается в связанный параметр. Надежность ракеты одноразового действия может быть указана как требование для вероятности попадания. Для таких систем вероятность отказа по требованию (PFD) является мерой надежности — это фактически число «недоступности». PFD выводится из частоты отказов (частоты возникновения) и времени миссии для неремонтопригодных систем.
Для восстанавливаемых систем он получается из частоты отказов, среднего времени ремонта (MTTR) и интервала тестирования. Эта мера может быть не уникальной для данной системы, поскольку она зависит от типа спроса. В дополнение к требованиям уровня системы, требования к надежности могут быть указаны для критических подсистем. В большинстве случаев параметры надежности указываются с соответствующими статистическими доверительными интервалами .
Целью испытаний на надежность или проверки надежности является обнаружение потенциальных проблем с конструкцией как можно раньше и, в конечном итоге, обеспечение уверенности в том, что система соответствует требованиям надежности. Следует учитывать надежность продукта во всех средах, таких как ожидаемое использование, транспортировка или хранение в течение указанного срока службы. [10] Это заключается в том, чтобы подвергнуть продукт воздействию естественных или искусственных условий окружающей среды, чтобы испытать его действие, оценить производительность продукта в условиях окружающей среды фактического использования, транспортировки и хранения, а также проанализировать и изучить степень влияния факторов окружающей среды и механизм их действия. [24] За счет использования различного оборудования для испытаний на воздействие окружающей среды для моделирования высокой температуры, низкой температуры и высокой влажности, а также изменений температуры в климатической среде, ускорить реакцию продукта в среде использования, проверить, достигает ли он ожидаемого качества в НИОКР , проектировании и производстве. [25]
Проверка надежности также называется тестированием надежности, которое подразумевает использование моделирования, статистики и других методов для оценки надежности продукта на основе срока службы продукта и ожидаемой производительности. [26] Большинство продуктов на рынке требуют тестирования надежности, например, автомобильные, интегральные схемы , тяжелая техника, используемая для добычи природных ресурсов, программное обеспечение для самолетов. [27] [28]
Тестирование надежности может проводиться на нескольких уровнях, и существуют различные типы тестирования. Сложные системы могут тестироваться на уровне компонентов, плат, блоков, сборок, подсистем и систем. [29] (Номенклатура уровней тестирования различается в зависимости от приложения.) Например, выполнение тестов на проверку воздействия окружающей среды на более низких уровнях, таких как отдельные детали или небольшие сборки, выявляет проблемы до того, как они вызовут сбои на более высоких уровнях. Тестирование продолжается на каждом уровне интеграции через полное системное тестирование, тестирование разработки и эксплуатационное тестирование, тем самым снижая программный риск. Однако тестирование не снижает риск ненадежности.
В каждом тесте могут быть сделаны как статистические ошибки типа I, так и ошибки типа II , в зависимости от размера выборки, времени теста, допущений и необходимого коэффициента дискриминации. Существует риск ошибочного отклонения хорошего дизайна (ошибка типа I) и риск ошибочного принятия плохого дизайна (ошибка типа II).
Не всегда возможно протестировать все системные требования. Некоторые системы слишком дороги для тестирования; некоторые режимы отказов могут потребовать годы для наблюдения; некоторые сложные взаимодействия приводят к огромному количеству возможных тестовых случаев; а некоторые тесты требуют использования ограниченных тестовых диапазонов или других ресурсов. В таких случаях могут использоваться различные подходы к тестированию, такие как (очень) ускоренное тестирование на долговечность, проектирование экспериментов и моделирование .
Желаемый уровень статистической достоверности также играет роль в тестировании надежности. Статистическая достоверность увеличивается за счет увеличения либо времени тестирования, либо количества тестируемых элементов. Планы тестирования надежности разрабатываются для достижения указанной надежности при указанном уровне достоверности с минимальным количеством тестовых единиц и временем тестирования. Различные планы тестирования приводят к разным уровням риска для производителя и потребителя. Желаемая надежность, статистическая достоверность и уровни риска для каждой стороны влияют на окончательный план тестирования. Заказчик и разработчик должны заранее договориться о том, как будут тестироваться требования к надежности.
Ключевым аспектом тестирования надежности является определение «отказа». Хотя это может показаться очевидным, существует множество ситуаций, когда неясно, является ли отказ действительно ошибкой системы. Различия в условиях тестирования, различия операторов, погода и непредвиденные ситуации создают различия между заказчиком и разработчиком системы. Одной из стратегий решения этой проблемы является использование процесса конференции по подсчету очков. Конференция по подсчету очков включает представителей заказчика, разработчика, испытательной организации, организации по надежности, а иногда и независимых наблюдателей. Процесс конференции по подсчету очков определен в техническом задании. Каждый тестовый случай рассматривается группой и «оценивается» как успех или неудача. Эта оценка является официальным результатом, используемым инженером по надежности.
В рамках фазы требований инженер по надежности разрабатывает стратегию тестирования совместно с заказчиком. Стратегия тестирования устанавливает компромиссы между потребностями организации по надежности, которая хочет получить как можно больше данных, и ограничениями, такими как стоимость, график и доступные ресурсы. Планы и процедуры тестирования разрабатываются для каждого теста надежности, а результаты документируются.
Тестирование надежности распространено в фотонной промышленности. Примерами тестов надежности лазеров являются тест на долговечность и выгорание . Эти тесты состоят из сильно ускоренного старения в контролируемых условиях группы лазеров. Данные, собранные в ходе этих тестов на долговечность, используются для прогнозирования ожидаемой продолжительности жизни лазера при предполагаемых рабочих характеристиках. [30]
Существует множество критериев для тестирования в зависимости от продукта или процесса, которые тестируются, и, в основном, наиболее распространены пять компонентов: [31] [32]
Срок службы продукта можно разделить на четыре различных периода для анализа. Срок службы — это предполагаемый экономический срок службы продукта, который определяется как время, которое может быть использовано до того, как стоимость ремонта не оправдает дальнейшее использование продукта. Гарантийный срок службы — это то, что продукт должен выполнять функцию в течение указанного периода времени. Проектный срок службы — это то, когда во время проектирования продукта дизайнер учитывает срок службы конкурентоспособного продукта и желания клиента и гарантирует, что продукт не приведет к неудовлетворенности клиента. [34] [35]
Требования к тестированию надежности могут следовать из любого анализа, для которого необходимо обосновать первую оценку вероятности отказа, режима отказа или эффекта. Доказательства могут быть получены с некоторой степенью уверенности путем тестирования. В системах на основе программного обеспечения вероятность представляет собой смесь отказов программного обеспечения и оборудования. Тестирование требований к надежности проблематично по нескольким причинам. В большинстве случаев одного теста недостаточно для получения достаточного количества статистических данных. Многократные тесты или длительные тесты обычно очень дороги. Некоторые тесты просто непрактичны, а условия окружающей среды трудно предсказать в течение жизненного цикла системы.
Инженерия надежности используется для разработки реалистичной и доступной программы испытаний, которая предоставляет эмпирические доказательства того, что система соответствует требованиям надежности. Статистические уровни достоверности используются для решения некоторых из этих проблем. Определенный параметр выражается вместе с соответствующим уровнем достоверности: например, среднее время безотказной работы (MTBF) 1000 часов при уровне достоверности 90%. Из этой спецификации инженер по надежности может, например, разработать тест с явными критериями для количества часов и количества отказов до тех пор, пока требование не будет выполнено или не будет выполнено. Возможны различные виды тестов.
Сочетание требуемого уровня надежности и требуемого уровня уверенности в значительной степени влияет на стоимость разработки и риск как для заказчика, так и для производителя. Необходимо тщательно выбирать наилучшее сочетание требований, например, экономическую эффективность. Тестирование надежности может проводиться на разных уровнях, таких как компонент, подсистема и система . Кроме того, во время тестирования и эксплуатации необходимо учитывать множество факторов, таких как экстремальные температуры и влажность, удары, вибрация или другие факторы окружающей среды (например, потеря сигнала, охлаждения или питания; или другие катастрофы, такие как пожар, наводнение, чрезмерная жара, физические или нарушения безопасности или другие бесчисленные формы повреждений или деградации). Для систем, которые должны прослужить много лет, могут потребоваться ускоренные испытания на долговечность.
Системный подход к тестированию надежности заключается в том, чтобы сначала определить цель надежности, а затем провести тесты, связанные с производительностью и определить надежность продукта. [36] Тест проверки надежности в современных отраслях должен четко определять, как они соотносятся с общими показателями надежности продукта и как отдельные тесты влияют на стоимость гарантии и удовлетворенность клиентов. [37]
Целью ускоренного испытания на долговечность (ALT-тест) является гораздо более быстрое инициирование отказа в лабораторных условиях путем создания более жесткой, но тем не менее репрезентативной среды. В таком тесте ожидается, что продукт выйдет из строя в лабораторных условиях так же, как он вышел бы из строя в полевых условиях, но за гораздо меньшее время. Основной целью ускоренного испытания является одно из следующих:
Программу ускоренного тестирования можно разбить на следующие этапы:
Распространенные способы определения связи жизненного стресса:
Надежность программного обеспечения является особым аспектом инженерии надежности. Она фокусируется на основах и методах, чтобы сделать программное обеспечение более надежным, т. е. устойчивым к сбоям. Надежность системы, по определению, включает все части системы, включая аппаратное обеспечение, программное обеспечение, поддерживающую инфраструктуру (включая критические внешние интерфейсы), операторов и процедуры. Традиционно инженерия надежности фокусируется на критических аппаратных частях системы. С момента широкого использования технологии цифровых интегральных схем программное обеспечение стало все более важной частью большинства электронных устройств и, следовательно, почти всех современных систем. Поэтому надежность программного обеспечения приобрела известность в области надежности системы.
Однако существуют значительные различия в поведении программного и аппаратного обеспечения. Большая часть ненадежности оборудования является результатом отказа компонента или материала, в результате которого система не выполняет свою предполагаемую функцию. Ремонт или замена аппаратного компонента восстанавливает систему до ее первоначального рабочего состояния. Однако программное обеспечение не выходит из строя в том же смысле, что и оборудование. Вместо этого ненадежность программного обеспечения является результатом непредвиденных результатов операций программного обеспечения. Даже относительно небольшие программы могут иметь астрономически большие комбинации входных данных и состояний, которые невозможно исчерпывающе протестировать. Восстановление программного обеспечения до его первоначального состояния работает только до тех пор, пока та же комбинация входных данных и состояний не приведет к тому же непредвиденному результату. Инженерия надежности программного обеспечения должна это учитывать.
Несмотря на это различие в источнике сбоев между программным обеспечением и оборудованием, было предложено несколько моделей надежности программного обеспечения , основанных на статистике, для количественной оценки того, что мы испытываем при работе с программным обеспечением: чем дольше работает программное обеспечение, тем выше вероятность того, что оно в конечном итоге будет использоваться непроверенным образом и проявит скрытый дефект, который приведет к сбою (Shooman 1987), (Musa 2005), (Denney 2005).
Как и в случае с оборудованием, надежность программного обеспечения зависит от хороших требований, проектирования и реализации. Проектирование надежности программного обеспечения в значительной степени опирается на дисциплинированный процесс проектирования программного обеспечения для прогнозирования и проектирования с учетом непреднамеренных последствий . Существует больше совпадений между проектированием качества программного обеспечения и проектированием надежности программного обеспечения, чем между качеством и надежностью оборудования. Хороший план разработки программного обеспечения является ключевым аспектом программы обеспечения надежности программного обеспечения. План разработки программного обеспечения описывает стандарты проектирования и кодирования, экспертные оценки , модульные тесты , управление конфигурацией , метрики программного обеспечения и модели программного обеспечения, которые будут использоваться при разработке программного обеспечения.
Распространенной метрикой надежности является количество сбоев программного обеспечения на строку кода (FLOC), обычно выражаемое как количество сбоев на тысячу строк кода. Эта метрика, наряду со временем выполнения программного обеспечения, является ключевой для большинства моделей и оценок надежности программного обеспечения. Теория заключается в том, что надежность программного обеспечения увеличивается по мере уменьшения количества сбоев (или плотности сбоев). Однако установить прямую связь между плотностью сбоев и средним временем между сбоями сложно из-за того, как сбои программного обеспечения распределены в коде, их серьезности и вероятности комбинации входных данных, необходимых для обнаружения сбоя. Тем не менее, плотность сбоев служит полезным индикатором для инженера по надежности. Также используются другие метрики программного обеспечения, такие как сложность. Эта метрика остается спорной, поскольку изменения в методах разработки и проверки программного обеспечения могут иметь существенное влияние на общие показатели дефектов.
Тестирование программного обеспечения является важным аспектом надежности программного обеспечения. Даже самый лучший процесс разработки программного обеспечения приводит к некоторым ошибкам программного обеспечения, которые практически не обнаруживаются до тестирования. Программное обеспечение тестируется на нескольких уровнях, начиная с отдельных модулей , через интеграцию и полное системное тестирование . На всех этапах тестирования ошибки программного обеспечения обнаруживаются, исправляются и повторно тестируются. Оценки надежности обновляются на основе плотности ошибок и других показателей. На системном уровне данные о среднем времени между отказами могут быть собраны и использованы для оценки надежности. В отличие от оборудования, выполнение точно такого же теста на точно такой же конфигурации программного обеспечения не обеспечивает повышенной статистической достоверности. Вместо этого надежность программного обеспечения использует другие показатели, такие как покрытие кода .
Модель зрелости возможностей Института программной инженерии является общепринятым средством оценки общего процесса разработки программного обеспечения с точки зрения надежности и качества.
Надежность конструкций или надежность конструкций — это применение теории надежности к поведению конструкций . Она используется как при проектировании, так и при обслуживании различных типов конструкций, включая бетонные и стальные конструкции. [38] [39] В исследованиях надежности конструкций нагрузки и сопротивления моделируются как вероятностные переменные. Используя этот подход, вычисляется вероятность отказа конструкции.
Надежность для безопасности и надежность для доступности часто тесно связаны. Потеря доступности инженерной системы может стоить денег. Если система метро недоступна, оператор метро будет терять деньги за каждый час простоя системы. Оператор метро потеряет больше денег, если безопасность будет поставлена под угрозу. Определение надежности связано с вероятностью отсутствия отказа. Отказ может привести к потере безопасности, потере доступности или и к тому, и к другому. Нежелательно терять безопасность или доступность в критической системе.
Техника обеспечения надежности занимается общей минимизацией отказов, которые могут привести к финансовым потерям для ответственного субъекта, в то время как техника безопасности фокусируется на минимизации определенного набора типов отказов, которые в целом могут привести к гибели людей, травмам или повреждению оборудования.
Угрозы надежности могут трансформироваться в инциденты, приводящие к потере дохода для компании или клиента, например, из-за прямых и косвенных затрат, связанных с: потерей производства из-за недоступности системы; неожиданно высоким или низким спросом на запасные части; расходами на ремонт; человеко-часами; перепроектированием или перерывами в обычном производстве. [40]
Техника безопасности часто бывает очень специфичной, относящейся только к определенным строго регулируемым отраслям, приложениям или областям. Она в первую очередь фокусируется на опасностях безопасности системы, которые могут привести к серьезным авариям, включая: потерю жизни; разрушение оборудования; или ущерб окружающей среде. Таким образом, соответствующие требования к функциональной надежности системы часто чрезвычайно высоки. Хотя она имеет дело с нежелательными отказами в том же смысле, что и техника надежности, она, однако, меньше фокусируется на прямых затратах и не касается действий по восстановлению после отказа. Другим отличием является уровень воздействия отказов на общество, что приводит к тенденции строгого контроля со стороны правительств или регулирующих органов (например, ядерная, аэрокосмическая, оборонная, железнодорожная и нефтяная промышленность). [40]
Безопасность можно повысить с помощью системы с перекрестной проверкой 2oo2. Доступность можно повысить, используя избыточность "1oo2" (1 из 2) на уровне детали или системы. Если оба избыточных элемента не согласны, то более разрешающий элемент максимизирует доступность. На систему 1oo2 никогда не следует полагаться для обеспечения безопасности. Отказоустойчивые системы часто полагаются на дополнительную избыточность (например, логику голосования 2oo3 ), когда несколько избыточных элементов должны согласовать потенциально опасное действие перед его выполнением. Это повышает как доступность, так и безопасность на системном уровне. Это обычная практика в аэрокосмических системах, которым требуется постоянная доступность и которые не имеют отказоустойчивого режима. Например, самолеты могут использовать тройную модульную избыточность для бортовых компьютеров и поверхностей управления (включая иногда различные режимы работы, например, электрические/механические/гидравлические), поскольку они должны всегда быть работоспособными из-за того, что нет "безопасных" положений по умолчанию для поверхностей управления, таких как рули или элероны, когда самолет летит.
Приведенный выше пример отказоустойчивой системы 2oo3 повышает как надежность миссии, так и безопасность. Однако «базовая» надежность системы в этом случае все равно будет ниже, чем у нерезервированной (1oo1) или 2oo2 системы. Базовая инженерия надежности охватывает все отказы, включая те, которые могут не привести к отказу системы, но приводят к дополнительным расходам из-за: действий по ремонту и техническому обслуживанию; логистики; запасных частей и т. д. Например, замена или ремонт 1 неисправного канала в системе голосования 2oo3 (система все еще работает, хотя с одним отказавшим каналом она фактически стала системой 2oo2) способствует базовой ненадежности, но не ненадежности миссии. Например, отказ хвостового фонаря самолета не помешает самолету лететь (и поэтому не считается провалом миссии), но его необходимо устранить (с соответствующей стоимостью, и поэтому он способствует уровням базовой ненадежности).
При использовании отказоустойчивых (резервных) систем или систем, оснащенных функциями защиты, возможность обнаружения отказов и предотвращение отказов по общей причине становятся первостепенными для безопасного функционирования и/или надежности выполнения миссии.
Качество часто фокусируется на производственных дефектах на этапе гарантии. Надежность рассматривает интенсивность отказов на протяжении всего срока службы продукта или инженерной системы от ввода в эксплуатацию до вывода из эксплуатации. Six Sigma имеет свои корни в статистическом контроле качества производства. Инженерия надежности является специальной частью системной инженерии. Процесс системной инженерии является процессом открытия, который часто отличается от производственного процесса. Производственный процесс часто фокусируется на повторяющихся действиях, которые обеспечивают высокое качество продукции с минимальными затратами и временем. [41]
Термин «качество продукта» в обиходе в широком смысле означает присущую ему степень совершенства. В промышленности используется более точное определение качества как «соответствие требованиям или спецификациям на момент начала использования». Если предположить, что конечная спецификация продукта адекватно отражает исходные требования и потребности клиента/системы, уровень качества можно измерить как долю отгруженных единиц продукта, которые соответствуют спецификациям. [42] Качество производимых товаров часто фокусируется на количестве гарантийных претензий в течение гарантийного периода.
Качество — это моментальный снимок в начале срока службы в течение гарантийного периода, и оно связано с контролем спецификаций продукта более низкого уровня. Это включает в себя дефекты нулевого времени, т. е. когда производственные ошибки избежали окончательного контроля качества. Теоретически уровень качества можно описать одной долей дефектных продуктов. Надежность, как часть системной инженерии, действует скорее как постоянная оценка интенсивности отказов на протяжении многих лет. Теоретически все элементы будут выходить из строя в течение бесконечного периода времени. [43] Дефекты, которые появляются с течением времени, называются выпадением надежности. Для описания выпадения надежности необходима вероятностная модель, которая описывает выпадение доли с течением времени. Это известно как модель распределения срока службы. [42] Некоторые из этих проблем надежности могут быть вызваны внутренними проблемами конструкции, которые могут существовать, даже если продукт соответствует спецификациям. Даже идеально изготовленные элементы со временем выйдут из строя из-за одного или нескольких механизмов отказа (например, из-за человеческой ошибки или механических, электрических и химических факторов). На эти проблемы надежности также могут влиять приемлемые уровни вариаций во время начального производства.
Качество и надежность, таким образом, связаны с производством. Надежность больше нацелена на клиентов, которые сосредоточены на отказах на протяжении всего срока службы продукта, таких как военные, авиалинии или железные дороги. Изделия, которые не соответствуют спецификации продукта, как правило, будут хуже с точки зрения надежности (имея более низкое MTTF), но это не всегда так. Полная математическая количественная оценка (в статистических моделях) этого комбинированного отношения, как правило, очень сложна или даже практически невозможна. В случаях, когда производственные отклонения могут быть эффективно уменьшены, инструменты Six Sigma, как было показано, полезны для поиска оптимальных технологических решений, которые могут повысить качество и надежность. Six Sigma также может помочь проектировать продукты, которые более устойчивы к производственным отказам и дефектам детской смертности в инженерных системах и производимых продуктах.
В отличие от Six Sigma, решения по надежности инженерии обычно находятся путем сосредоточения внимания на тестировании надежности и проектировании системы. Решения находятся разными способами, например, путем упрощения системы, чтобы позволить понять больше механизмов отказа; выполнения подробных расчетов уровней напряжения материала, позволяющих определить подходящие коэффициенты безопасности; поиска возможных ненормальных условий нагрузки системы и использования этого для повышения надежности конструкции к механизмам отказа, связанным с отклонениями в производстве. Кроме того, надежность инженерии использует решения на системном уровне, такие как проектирование избыточных и отказоустойчивых систем для ситуаций с высокой потребностью в доступности (см. выше Надежность инженерии против безопасности инженерии).
Примечание: «Дефект» в литературе по шести сигмам/качеству не то же самое, что «отказ» (отказ в эксплуатации | например, сломанный элемент) в надежности. Дефект шести сигм/качества обычно относится к несоответствию требованию (например, базовой функциональности или ключевому измерению). Однако элементы могут со временем выйти из строя, даже если все эти требования выполнены. Качество, как правило, не связано с постановкой решающего вопроса «действительно ли требования верны?», тогда как надежность связана.
После производства систем или деталей инженерия надежности пытается контролировать, оценивать и устранять недостатки. Мониторинг включает в себя электронное и визуальное наблюдение за критическими параметрами, выявленными на этапе проектирования анализа дерева неисправностей. Сбор данных в значительной степени зависит от характера системы. В большинстве крупных организаций есть группы контроля качества , которые собирают данные об отказах транспортных средств, оборудования и машин. Отказы потребительских товаров часто отслеживаются по количеству возвратов. Для систем, находящихся на неактивном хранении или в режиме ожидания, необходимо установить формальную программу наблюдения для проверки и тестирования случайных образцов. Любые изменения в системе, такие как модернизация на месте или отзывной ремонт, требуют дополнительного тестирования надежности для обеспечения надежности модификации. Поскольку невозможно предвидеть все режимы отказов данной системы, особенно с человеческим фактором, отказы будут происходить. Программа надежности также включает в себя систематический анализ первопричин , который определяет причинно-следственные связи, вовлеченные в отказ, чтобы можно было реализовать эффективные корректирующие действия. Когда это возможно, отказы системы и корректирующие действия сообщаются в организацию по надежности.
Некоторые из наиболее распространенных методов, применяемых к оценке надежности, — это системы отчетности об отказах, анализа и корректирующих действий (FRACAS). Этот систематический подход разрабатывает оценку надежности, безопасности и логистики на основе отчетности об отказах/инцидентах, управления, анализа и корректирующих/предупреждающих действий. Сегодня организации принимают этот метод и используют коммерческие системы (например, веб-приложения FRACAS), которые позволяют им создавать репозиторий данных об отказах/инцидентах, из которого можно извлекать статистику для просмотра точных и подлинных показателей надежности, безопасности и качества.
Для организации крайне важно принять общую систему FRACAS для всех конечных изделий. Кроме того, она должна позволять фиксировать результаты испытаний на практике. Непринятие одной простой в использовании (с точки зрения простоты ввода данных для полевых инженеров и инженеров ремонтных мастерских) и простой в обслуживании интегрированной системы, скорее всего, приведет к сбою самой программы FRACAS.
Некоторые из распространенных выходных данных системы FRACAS включают среднее время безотказной работы в полевых условиях, среднее время ремонта, расход запасных частей, рост надежности, распределение отказов/инцидентов по типу, местоположению, номеру детали, серийному номеру и симптому.
Использование прошлых данных для прогнозирования надежности новых сопоставимых систем/элементов может ввести в заблуждение, поскольку надежность является функцией контекста использования и может зависеть от небольших изменений в конструкции/производстве.
Системы любой значительной сложности разрабатываются организациями людей, такими как коммерческая компания или государственное учреждение. Организация по проектированию надежности должна соответствовать организационной структуре компании . Для небольших, некритических систем проектирование надежности может быть неформальным. По мере роста сложности возникает необходимость в формальной функции надежности. Поскольку надежность важна для заказчика, заказчик может даже указать определенные аспекты организации надежности.
Существует несколько распространенных типов организаций по надежности. Менеджер проекта или главный инженер могут нанимать одного или нескольких инженеров по надежности напрямую. В более крупных организациях обычно есть организация по обеспечению качества продукции или специализированная инженерная организация, которая может включать надежность, ремонтопригодность , качество , безопасность, человеческие факторы , логистику и т. д. В таком случае инженер по надежности подчиняется менеджеру по обеспечению качества продукции или менеджеру по специализированной инженерии.
В некоторых случаях компания может пожелать создать независимую организацию по надежности. Это желательно для того, чтобы надежность системы, которая часто является дорогостоящей и трудоемкой, не была необоснованно ущемлена из-за давления бюджета и графика. В таких случаях инженер по надежности работает над проектом изо дня в день, но фактически нанимается и оплачивается отдельной организацией в компании.
Поскольку обеспечение надежности имеет решающее значение на раннем этапе проектирования системы, для инженеров по надежности стало обычным делом (в рамках структурированной организации) работать в составе интегрированной команды по разработке продукта .
Некоторые университеты предлагают ученые степени в области надежности техники. Другие специалисты по надежности обычно имеют степень по физике из университетской или колледжской программы. Многие инженерные программы предлагают курсы по надежности, а некоторые университеты имеют целые программы по надежности техники. Инженер по надежности должен быть зарегистрирован как профессиональный инженер в штате или провинции по закону, но не все специалисты по надежности являются инженерами. Инженеры по надежности требуются в системах, где общественная безопасность находится под угрозой. Существует множество профессиональных конференций и отраслевых программ обучения для инженеров по надежности. Существует несколько профессиональных организаций для инженеров по надежности, включая Американское общество по качеству и надежности (ASQ-RD), [44] Общество по надежности IEEE , Американское общество по качеству (ASQ), [45] и Общество инженеров по надежности (SRE). [46]
{{cite journal}}: Цитировать журнал требует |journal=( помощь ){{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )http://standards.sae.org/ja1000/1_199903/ Руководство по внедрению стандарта программы надежности SAE JA1000/1
В Великобритании существуют более современные стандарты, поддерживаемые под спонсорством Министерства обороны Великобритании в качестве стандартов обороны. Соответствующие стандарты включают:
DEF STAN 00-40 Надежность и ремонтопригодность (R&M)
РУКОВОДСТВА ПО ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ И РЕМОНТНОСНОСТИ DEF STAN 00-42
DEF STAN 00-43 ДЕЯТЕЛЬНОСТЬ ПО ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ И РЕМОНТНОСПОСОБНОСТИ
DEF STAN 00-44 НАДЕЖНОСТЬ И РЕМОНТНОСТЬ СБОР ДАННЫХ И КЛАССИФИКАЦИЯ
DEF STAN 00-45 Выпуск 1: ОБСЛУЖИВАНИЕ, ОРИЕНТИРОВАННОЕ НА НАДЕЖНОСТЬ
DEF STAN 00-49 Выпуск 1: НАДЕЖНОСТЬ И РЕМОНТНО-ОБСЛУЖИВАЕМОСТЬ MOD РУКОВОДСТВО ПО ОПРЕДЕЛЕНИЯМ ТЕРМИНОЛОГИИ
Их можно получить из DSTAN. Существует также множество коммерческих стандартов, разработанных многими организациями, включая SAE, MSG, ARP и IEE.
Медиа, связанные с проектированием надежности на Wikimedia Commons