~~~~~~~~~~~~~~~~~~~~ Arc.Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~ 
Номер скриншота №:
✰ 2D205C5B0BE618DF9150775CD54DFD1C__1713251880 ✰
Заголовок документа оригинал.:
✰ Reliability engineering - Wikipedia ✰
Заголовок документа перевод.:
✰ Инженерия надежности — Википедия ✰
Снимок документа находящегося по адресу (URL):
✰ https://en.wikipedia.org/wiki/Reliability_engineering ✰
Адрес хранения снимка оригинал (URL):
✰ https://arc.ask3.ru/arc/aa/2d/1c/2d205c5b0be618df9150775cd54dfd1c.html ✰
Адрес хранения снимка перевод (URL):
✰ https://arc.ask3.ru/arc/aa/2d/1c/2d205c5b0be618df9150775cd54dfd1c__translat.html ✰
Дата и время сохранения документа:
✰ 11.06.2024 01:07:19 (GMT+3, MSK) ✰
Дата и время изменения документа (по данным источника):
✰ 16 April 2024, at 10:18 (UTC). ✰ 

~~~~~~~~~~~~~~~~~~~~~~ Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~~ 
Сервисы Ask3.ru: 
 Архив документов (Снимки документов, в формате HTML, PDF, PNG - подписанные ЭЦП, доказывающие существование документа в момент подписи. Перевод сохраненных документов на русский язык.)https://arc.ask3.ruОтветы на вопросы (Сервис ответов на вопросы, в основном, научной направленности)https://ask3.ru/answer2questionТоварный сопоставитель (Сервис сравнения и выбора товаров) ✰✰
✰ https://ask3.ru/product2collationПартнерыhttps://comrades.ask3.ru


Совет. Чтобы искать на странице, нажмите Ctrl+F или ⌘-F (для MacOS) и введите запрос в поле поиска.
Arc.Ask3.ru: далее начало оригинального документа

Инженерия надежности — Википедия Jump to content

Инженерия надежности

Из Википедии, бесплатной энциклопедии

Проектирование надежности — это раздел системной инженерии , который подчеркивает способность оборудования функционировать без сбоев. Надежность описывает способность системы или компонента функционировать в заданных условиях в течение определенного периода. [1] Надежность тесно связана с доступностью , которую обычно описывают как способность компонента или системы функционировать в определенный момент или интервал времени.

теоретически Функция надежности определяется как вероятность успеха в момент времени t, которая обозначается R(t). На практике он рассчитывается с использованием различных методов, и его значение колеблется от 0 до 1, где 0 указывает на отсутствие вероятности успеха, а 1 указывает на определенный успех. Эта вероятность оценивается на основе подробного (физического анализа отказов) анализа, предыдущих наборов данных или посредством испытаний на надежность и моделирования надежности. Доступность , возможность тестирования , ремонтопригодность и обслуживание часто определяются как часть «инжиниринга надежности» в программах обеспечения надежности. Надежность часто играет ключевую роль в экономической эффективности систем.

Проектирование надежности занимается прогнозированием, предотвращением и управлением высокими уровнями « в течение всего срока службы инженерной неопределенности » и рисками отказов. Хотя стохастические параметры определяют надежность и влияют на нее, надежность достигается не только с помощью математики и статистики. [2] [3] «Почти все учения и литература по этому предмету подчеркивают эти аспекты и игнорируют тот факт, что диапазоны неопределенности в значительной степени делают недействительными количественные методы прогнозирования и измерения». [4] Например, легко представить «вероятность отказа» в виде символа или значения в уравнении, но почти невозможно предсказать ее истинную величину на практике, которая является многомерной , поэтому наличие уравнения надежности не дает никаких результатов. равные, имеющие точное прогнозное измерение надежности.

Проектирование надежности тесно связано с проектированием качества, проектированием безопасности и безопасностью систем , поскольку они используют общие методы для анализа и могут требовать участия друг друга. Можно сказать, что система должна быть надежно безопасной.

Проектирование надежности фокусируется на затратах на отказы, вызванные простоем системы, стоимости запасных частей, ремонтного оборудования, персонала и стоимости гарантийных претензий. [5]

История [ править ]

Слово « надежность» появилось в 1816 году и впервые засвидетельствовано поэтом Сэмюэлем Тейлором Кольриджем . [6] До Второй мировой войны этот термин в основном был связан с повторяемостью ; тест (в любом виде науки) считался «надежным», если одни и те же результаты были получены неоднократно. В 1920-х годах усовершенствование продукции за счет использования статистического управления процессами продвигал доктор Уолтер А. Шухарт из Bell Labs . [7] примерно в то время, когда Валодди Вейбулл работал над статистическими моделями усталости. Развитие техники надежности шло здесь параллельно с качеством. Современное использование слова «надежность» было определено военными США в 1940-х годах, характеризуя продукт, который будет работать, когда ожидается, и в течение определенного периода.

Во время Второй мировой войны многие проблемы с надежностью были связаны с присущей им ненадежностью электронного оборудования, доступного в то время, а также с проблемами усталости. В 1945 году М.А. Майнер опубликовал в журнале ASME основополагающую статью под названием «Совокупный ущерб при усталости». Основным применением техники надежности в вооруженных силах были электронные лампы, используемые в радиолокационных системах и другой электронике, надежность которых оказалась очень проблематичной и дорогостоящей. IEEE Министерство сформировал Общество надежности в 1948 году. В 1950 году обороны США сформировало группу под названием «Консультативная группа по надежности электронного оборудования» (AGREE) для исследования методов обеспечения надежности военного оборудования. [8] Эта группа рекомендовала три основных способа работы:

  • Повышение надежности компонентов.
  • Установить требования к качеству и надежности для поставщиков.
  • Собирайте полевые данные и находите коренные причины сбоев.

В 1960-х годах больше внимания уделялось испытаниям надежности на уровне компонентов и систем. Тогда же был создан знаменитый военный стандарт MIL-STD-781. опубликовал широко используемый предшественник военного справочника 217, Примерно в этот же период RCA который использовался для прогнозирования частоты отказов электронных компонентов. Акцент на надежность компонентов и эмпирические исследования (например, Mil Std 217) постепенно уменьшался. Использовались более прагматичные подходы, используемые в потребительских отраслях. В 1980-е годы телевизоры все чаще изготавливались из твердотельных полупроводников. Автомобили быстро увеличили использование полупроводников благодаря множеству микрокомпьютеров под капотом и на приборной панели. В крупных системах кондиционирования воздуха, а также в микроволновых печах и ряде других приборов были разработаны электронные контроллеры. Системы связи начали внедрять электроника для замены старых механических систем переключения. Bellcore выпустила первую методологию прогнозирования потребителей в сфере телекоммуникаций. SAE разработала аналогичный документ SAE870050 для автомобильной промышленности. Характер прогнозов менялся в течение десятилетия, и стало очевидно, что сложность кристалла — не единственный фактор, определяющий интенсивность отказов интегральных схем (ИС). Кам Вонг опубликовал статью, ставящую под сомнение кривую ванны [9] — см. также техническое обслуживание, ориентированное на надежность . За это десятилетие частота отказов многих компонентов снизилась в 10 раз. Программное обеспечение стало важным для надежности систем. К 1990-м годам темпы развития ИС начали набирать обороты. Более широкое использование автономных микрокомпьютеров было обычным явлением, и рынок ПК помог сохранить плотность микросхем в соответствии с законом Мура и удваиваться примерно каждые 18 месяцев. Инженерия надежности теперь менялась по мере продвижения к пониманию физики отказов . Частота отказов компонентов продолжала снижаться, но проблемы на уровне системы становились все более заметными. Системное мышление становится все более важным. Для программного обеспечения была разработана модель CMM ( Capability Maturity Model ), которая дала более качественный подход к надежности. В стандарт ISO 9000 добавлены меры надежности в рамках сертификации, связанной с проектированием и разработкой. Расширение Всемирной паутины создало новые проблемы безопасности и доверия. Старая проблема слишком малого количества доступной достоверной информации теперь была заменена слишком большим количеством информации сомнительной ценности. Проблемы надежности потребителей теперь можно обсуждать онлайн в режиме реального времени с использованием данных. Новые технологии, такие как микроэлектромеханические системы ( MEMS ), портативные GPS- навигаторы и портативные устройства, сочетающие в себе сотовые телефоны и компьютеры, — все они создают проблемы с поддержанием надежности. Благодаря этому время разработки продукта продолжало сокращаться. десятилетия, и то, что было сделано за три года, было сделано за 18 месяцев. Это означало, что инструменты и задачи обеспечения надежности должны были быть более тесно связаны с самим процессом разработки. Во многих отношениях надежность стала частью повседневной жизни и ожиданий потребителей.

Обзор [ править ]

Надежность — это вероятность того, что продукт будет выполнять предназначенную функцию в течение определенного периода использования и в определенных условиях эксплуатации таким образом, который соответствует или превосходит ожидания потребителя. [10]

Цель [ править ]

Целями проектирования надежности в порядке убывания приоритета являются: [11]

  1. Применять инженерные знания и специальные методы для предотвращения или снижения вероятности или частоты отказов.
  2. Выявлять и устранять причины сбоев, которые все же происходят, несмотря на усилия по их предотвращению.
  3. Определить способы борьбы с возникающими сбоями, если их причины не устранены.
  4. Применять методы оценки вероятной надежности новых конструкций и анализа данных о надежности.

Причина приоритетного акцента заключается в том, что это, безусловно, самый эффективный способ работы с точки зрения минимизации затрат и создания надежных продуктов. Поэтому основными необходимыми навыками являются способность понимать и предвидеть возможные причины сбоев, а также знание того, как их предотвратить. Также необходимо знать методы, которые можно использовать для анализа проектов и данных.

Область применения и методы [ править ]

Проектирование надежности « сложных систем » требует другого, более сложного системного подхода, чем для несложных систем. В этом случае проектирование надежности может включать:

  • Анализ доступности системы и готовности к выполнению миссий, а также соответствующее распределение требований к надежности и техническому обслуживанию.
  • Функциональный анализ отказов системы и спецификация производных требований
  • Анализ внутренней (системной) надежности конструкции и производная спецификация требований для проектирования аппаратного и программного обеспечения.
  • Проектирование системной диагностики
  • Отказоустойчивые системы (например, за счет резервирования)
  • Прогнозирующее и профилактическое обслуживание (например, обслуживание, ориентированное на надежность)
  • Человеческий фактор/человеческое взаимодействие/человеческие ошибки
  • Отказы, вызванные производством и сборкой (влияние на обнаруженное «нулевое качество» и надежность)
  • Отказы, вызванные техническим обслуживанием
  • Отказы, вызванные транспортировкой
  • Сбои, вызванные хранилищем
  • Исследования использования (нагрузки), анализ напряжений компонентов и производная спецификация требований.
  • Программные (систематические) сбои
  • Тестирование на отказ/надежность (и производные требования)
  • Мониторинг отказов на местах и ​​корректирующие действия
  • Наличие запасных частей (контроль наличия)
  • Техническая документация, анализ предостережений и предупреждений
  • Сбор/организация данных и информации (создание общего журнала опасностей для повышения надежности и системы FRACAS )
  • Хаос-инжиниринг

Эффективное проектирование надежности требует понимания основ механизмов отказов , для чего требуются опыт, широкие инженерные навыки и хорошие знания из многих различных специальных областей техники. [12] например:

Определения [ править ]

Надежность можно определить следующими способами:

  • Идея о том, что предмет пригоден для определенной цели с точки зрения времени.
  • Способность спроектированного, произведенного или обслуживаемого объекта работать в соответствии с требованиями с течением времени.
  • Способность совокупности спроектированных, произведенных или обслуживаемых изделий работать так, как требуется с течением времени.
  • Устойчивость предмета к выходу из строя с течением времени
  • Вероятность того, что предмет выполнит требуемую функцию при заданных условиях в течение определенного периода времени.
  • Долговечность объекта

Основы оценки надежности [ править ]

надежности используются многие инженерные методы При оценке рисков , такие как блок-схемы надежности, анализ опасностей , анализ видов и последствий отказов (FMEA). [13] анализ дерева отказов (FTA), техническое обслуживание, ориентированное на надежность , (вероятностные) расчеты нагрузок и напряжений материала, а также износа, (вероятностный) анализ усталости и ползучести, анализ человеческих ошибок, анализ производственных дефектов, испытания надежности и т. д. Эти анализы должны выполняться правильно и с большим вниманием к деталям, чтобы быть эффективным. Из-за большого количества методов обеспечения надежности, их стоимости и различной степени надежности, необходимой для разных ситуаций, в большинстве проектов разрабатывается план программы обеспечения надежности, в котором указываются задачи обеспечения надежности ( требования к техническому заданию (SoW)), которые будут выполняться для этого. конкретная система.

В соответствии с созданием обоснований безопасности , например, в соответствии с ARP4761 , цель оценок надежности состоит в том, чтобы предоставить надежный набор качественных и количественных доказательств того, что использование компонента или системы не будет связано с неприемлемым риском. Основные шаги, которые необходимо предпринять [14] являются:

  • Тщательно определите соответствующие «опасности» ненадежности, например, потенциальные условия, события, человеческие ошибки, виды отказов, взаимодействия, механизмы отказов и основные причины, с помощью специального анализа или испытаний.
  • Оцените связанный системный риск с помощью специального анализа или тестирования.
  • Предложите меры по смягчению последствий, например, требования , изменения конструкции, логику обнаружения, обслуживание и обучение, с помощью которых риски можно снизить и контролировать на приемлемом уровне.
  • Определите наилучшие способы смягчения последствий и договоритесь об окончательных приемлемых уровнях риска, возможно, на основе анализа затрат и выгод.

Риск здесь представляет собой сочетание вероятности и серьезности возникновения инцидента (сценария) отказа. Серьезность можно рассматривать с точки зрения безопасности системы или ее доступности. Надежность для безопасности можно рассматривать как нечто совершенно иное, чем надежность для доступности системы. Доступность и безопасность могут существовать в динамическом напряжении, поскольку сохранение слишком доступной системы может быть небезопасным. Слишком быстрый перевод инженерной системы в безопасное состояние может вызвать ложные срабатывания сигнализации, которые затруднят доступность системы.

В определении de minimis серьезность отказов включает стоимость запасных частей, человеко-часов, логистику, повреждения (вторичные отказы) и простои машин, которые могут привести к производственным потерям. Более полное определение отказа также может означать травмы, расчленения и смерть людей внутри системы (свидетельствуют аварии на минах, промышленные аварии, отказы космических кораблей) и то же самое для невинных свидетелей (свидетельством являются жители таких городов, как Бхопал, Лав-Канал, Чернобыль, или Сендай, и другие жертвы землетрясения и цунами в Тохоку 2011 года) — в этом случае обеспечение надежности становится системной безопасностью. То, что является приемлемым, определяется управляющим органом, клиентами или затронутыми сообществами. Остаточный риск — это риск, который остается после завершения всех мероприятий по обеспечению надежности, и включает в себя неидентифицированный риск, поэтому его невозможно полностью измерить.

Сложность технических систем, таких как усовершенствование конструкции и материалов, плановые проверки, надежная конструкция и резервное резервирование, снижает риск и увеличивает стоимость. Риск можно снизить до уровня ALARA (настолько низкого, насколько это разумно достижимо) или ALAPA (настолько низкого, насколько это практически достижимо).

программы надежности доступности План и

Внедрение программы обеспечения надежности — это не просто покупка программного обеспечения; это не просто контрольный список пунктов, которые необходимо выполнить, чтобы обеспечить надежность продуктов и процессов. Программа надежности — это сложная система обучения и знаний, уникальная для продуктов и процессов. Оно поддерживается лидерством, построено на навыках, которые человек развивает в команде, интегрировано в бизнес-процессы и выполняется с использованием проверенных стандартных методов работы. [15]

План программы обеспечения надежности используется для точного документирования того, какие «лучшие практики» (задачи, методы, инструменты, анализ и тесты) требуются для конкретной (под)системы, а также для уточнения требований заказчика к оценке надежности. Для крупномасштабных сложных систем план программы обеспечения надежности должен представлять собой отдельный документ . Определение ресурсов для рабочей силы и бюджета на тестирование и другие задачи имеет решающее значение для успешной программы. В целом объем работы, необходимый для создания эффективной программы для сложных систем, велик.

План программы обеспечения надежности необходим для достижения высокого уровня надежности, тестируемости, ремонтопригодности системы. и, как следствие, доступности Он разрабатывается на ранних этапах разработки системы и уточняется в течение ее жизненного цикла. Он определяет не только то, что делает инженер по надежности, но и задачи, выполняемые другими заинтересованными сторонами . План эффективной программы надежности должен быть одобрен высшим руководством программы, которое несет ответственность за выделение достаточных ресурсов для его реализации.

План программы обеспечения надежности также может использоваться для оценки и улучшения доступности системы с помощью стратегии, ориентированной на повышение тестируемости и ремонтопригодности, а не на надежности. Улучшение ремонтопригодности обычно проще, чем повышение надежности. Оценки ремонтопригодности (скорость ремонта) также, как правило, более точны. Однако, поскольку неопределенности в оценках надежности в большинстве случаев очень велики, они, вероятно, будут доминировать при расчете доступности (проблема неопределенности прогнозирования), даже если уровни ремонтопригодности очень высоки. Когда надежность не находится под контролем, могут возникнуть более сложные проблемы, такие как нехватка рабочей силы (специалистов по техническому обслуживанию/обслуживанию клиентов), доступность запасных частей, задержки в логистике, отсутствие ремонтных мощностей, затраты на обширную модернизацию и сложное управление конфигурацией и другие. Проблема ненадежности может усугубляться также из-за «эффекта домино» отказов, вызванных техническим обслуживанием после ремонта. Поэтому сосредоточиться только на ремонтопригодности недостаточно. Если сбои предотвращены, ни одна из других проблем не имеет никакого значения, и поэтому надежность обычно рассматривается как наиболее важная часть доступности. Надежность необходимо оценивать и улучшать как с точки зрения доступности, так и с точки зрения общая стоимость владения (TCO) из-за стоимости запасных частей, человеко-часов технического обслуживания, транспортных расходов, затрат на хранение, рисков устаревания деталей и т. д. Но, как с опозданием обнаружили GM и Toyota, TCO также включает затраты на последующие обязательства, когда расчеты надежности недостаточно и точно не учитывают физические риски клиентов. Часто между ними требуется компромисс. Возможно, существует максимальное соотношение между доступностью и стоимостью владения. В плане также следует учитывать возможность тестирования системы, поскольку она является связующим звеном между надежностью и ремонтопригодностью. Стратегия обслуживания может влиять на надежность системы (например, путем профилактического и/или профилактического обслуживания ), хотя она никогда не сможет превысить надежность системы, присущую ей.

План обеспечения надежности должен четко предусматривать стратегию контроля доступности. Будет ли важнее только доступность или стоимость владения, зависит от использования системы. Например, система, которая является важнейшим звеном в производственной системе (например, крупная нефтяная платформа), обычно имеет очень высокую стоимость владения, если эта стоимость приводит даже к незначительному увеличению доступности, поскольку недоступность приводит к огромной потере дохода, которая может легко превысить высокую стоимость владения. Надлежащий план обеспечения надежности всегда должен учитывать анализ RAMT в его общем контексте. RAMT означает надежность, доступность, ремонтопригодность/обслуживание и возможность тестирования в контексте потребностей клиента.

Требования к надежности [ править ]

Для любой системы одной из первых задач проектирования надежности является адекватное определение требований к надежности и ремонтопригодности, выделенных из общих потребностей в доступности и, что более важно, полученных из надлежащего анализа отказов конструкции или результатов предварительных испытаний прототипа. Четкие требования (которые могут быть разработаны) должны удерживать проектировщиков от проектирования конкретных ненадежных изделий/конструкций/интерфейсов/систем. Установление только целевых показателей доступности, надежности, тестируемости или ремонтопригодности (например, максимальной интенсивности отказов) нецелесообразно. Это широкое заблуждение в отношении разработки требований к надежности. Требования надежности касаются самой системы, включая требования к тестированию и оценке, а также связанные с ней задачи и документацию. Требования надежности включены в соответствующие спецификации требований к системе или подсистеме, планы испытаний и условия контракта. Создание правильных требований нижнего уровня имеет решающее значение. [16] Предоставление только количественных минимальных целевых показателей (например, значений среднего времени наработки на отказ (MTBF) или интенсивности отказов) недостаточно по разным причинам. Одна из причин заключается в том, что полная проверка (связанная с правильностью и проверяемостью во времени) количественного распределения надежности (спецификации требований) на более низких уровнях для сложных систем (часто) не может быть произведена вследствие (1) того факта, что требования являются вероятностными, (2) чрезвычайно высокий уровень неопределенности, необходимый для демонстрации соответствия всем этим вероятностным требованиям, и поскольку (3) надежность является функцией времени, а точные оценки (вероятностного) показателя надежности для каждого элемента доступны только очень на поздних стадиях проекта, иногда даже после многих лет эксплуатации. Сравните эту проблему с непрерывным (пере)балансированием, например, требований к массе систем нижнего уровня при разработке самолета, что уже зачастую является большой задачей. Обратите внимание, что в этом случае массы различаются лишь на несколько процентов, не являются функцией времени, а данные невероятностны и доступны уже в моделях CAD. В случае надежности уровни ненадежности (частоты отказов) могут меняться в десятки раз (кратно 10) в результате очень незначительных отклонений в конструкции, процессе или чем-либо еще. [17] Информация часто недоступна без огромной неопределенности на этапе разработки. Это делает практически невозможным решение этой проблемы распределения полезным, практичным и обоснованным способом, который не приводит к массовым пере- или заниженным спецификациям. Поэтому необходим прагматичный подход, например: использование общих уровней/классов количественных требований, зависящих только от серьезности последствий отказа. Кроме того, проверка результатов — гораздо более субъективная задача, чем любой другой тип требований. (Количественные) параметры надежности (с точки зрения наработки на отказ) на сегодняшний день являются наиболее неопределенными параметрами конструкции в любой конструкции.

Кроме того, требования к проектированию надежности должны стимулировать проектирование (системы или ее части), включающее функции, которые предотвращают возникновение отказов или в первую очередь ограничивают последствия отказов. Это не только поможет в некоторых прогнозах, но и не позволит отвлечь инженерные усилия на своего рода бухгалтерскую работу. Требование к проектированию должно быть достаточно точным, чтобы проектировщик мог «спроектировать» его, а также доказать — посредством анализа или тестирования — что требование было достигнуто, и, если возможно, в пределах некоторой заявленной уверенности. Любой тип требований к надежности должен быть детализирован и может быть получен на основе анализа отказов (анализ напряжений и усталости методом конечных элементов, анализ рисков надежности, FTA, FMEA, анализ человеческого фактора, анализ функциональных рисков и т. д.) или любого типа испытаний надежности. Кроме того, необходимы требования к проверочным испытаниям (например, требуемые перегрузочные нагрузки) и необходимое время испытаний. Для эффективного выведения этих требований необходимо системной инженерии Следует использовать логику оценки рисков и смягчения их последствий, основанную на . Необходимо создать надежные системы регистрации опасностей, содержащие подробную информацию о том, почему и как системы могли или вышли из строя. Таким образом, требования должны формироваться и отслеживаться. Эти практические требования к проектированию должны определять проект, а не использоваться только для целей проверки. Таким образом, эти требования (часто проектные ограничения) выводятся на основе анализа отказов или предварительных испытаний. Понимание этой разницы по сравнению с чисто количественной (логистической) спецификацией требований (например, целевой показатель частоты отказов/наработки на отказ) имеет первостепенное значение при разработке успешных (сложных) систем. [18]

Требования ремонтопригодности касаются затрат на ремонт, а также времени ремонта. Требования тестируемости (не путать с требованиями к тестированию) обеспечивают связь между надежностью и ремонтопригодностью и должны учитывать возможность обнаружения режимов отказа (на определенном уровне системы), уровни изоляции и создание диагностических процедур (процедур). Как указано выше, инженеры по надежности также должны учитывать требования к различным задачам и документации по обеспечению надежности во время разработки, тестирования, производства и эксплуатации системы. Эти требования обычно указываются в задании на выполнение работ по контракту и зависят от того, какую свободу действий заказчик желает предоставить подрядчику. Задачи по обеспечению надежности включают в себя различные анализы, планирование и отчеты об отказах. Выбор задачи зависит от критичности системы, а также от стоимости. Критическая с точки зрения безопасности система может потребовать формального отчета о сбоях и процесса проверки на протяжении всего процесса разработки, тогда как некритичная система может полагаться на окончательные отчеты об испытаниях. Наиболее распространенные задачи программы обеспечения надежности документированы в стандартах программ обеспечения надежности, таких как MIL-STD-785 и IEEE 1332. Анализ отчетов об отказах и системы корректирующих действий являются распространенным подходом к мониторингу надежности продукта/процесса.

Культура надежности / человеческие ошибки фактор человеческий /

На практике большинство сбоев можно отнести к тому или иному типу человеческой ошибки , например:

  • Управленческие решения (например, по составлению бюджета, срокам и необходимым задачам)
  • Системная инженерия: исследования использования (варианты нагрузки)
  • Системная инженерия: анализ/постановка требований
  • Системная инженерия: контроль конфигурации
  • Предположения
  • Расчеты/моделирование/анализ FEM
  • Дизайн
  • Проектные чертежи
  • Тестирование (например, неправильные настройки нагрузки или измерение отказов)
  • статистический анализ
  • Производство
  • Контроль качества
  • Обслуживание
  • Руководства по техническому обслуживанию
  • Обучение
  • Классификация и упорядочивание информации
  • Отзыв о полевой информации (например, неверная или слишком расплывчатая)
  • и т. д.

Однако люди также очень хорошо умеют обнаруживать такие сбои, исправлять их и импровизировать при возникновении нештатных ситуаций. Следовательно, политика, которая полностью исключает действия человека в процессах проектирования и производства для повышения надежности, может оказаться неэффективной. Некоторые задачи лучше выполняются людьми, а некоторые — машинами. [19]

Кроме того, человеческие ошибки в управлении; организация данных и информации; или неправильное использование или злоупотребление предметами также может способствовать ненадежности. Это основная причина, по которой высокий уровень надежности сложных систем может быть достигнут только за счет надежного процесса системного проектирования с надлежащим планированием и выполнением задач валидации и проверки. Это также включает в себя тщательную организацию обмена данными и информацией и создание «культуры надежности» точно так же, как наличие «культуры безопасности» имеет первостепенное значение при разработке критически важных для безопасности систем.

надежности улучшение Прогнозирование и

Прогноз надежности сочетает в себе:

  • создание правильной модели надежности (см. далее на этой странице)
  • оценка (и обоснование) входных параметров для этой модели (например, интенсивность отказов для конкретного режима отказа или события и среднее время ремонта системы для конкретного отказа)
  • оценка выходных параметров надежности на уровне системы или ее частей (т. е. доступность системы или частота конкретного функционального отказа). Акцент на количественной оценке и установлении целевых показателей (например, наработка на отказ) может означать, что существует предел достижимой надежности, однако не существует внутреннего предела. и разработка более высокой надежности не должна быть более дорогостоящей. Кроме того, они [ ВОЗ? ] утверждают, что прогнозирование надежности на основе исторических данных может быть очень ошибочным, поскольку сравнения действительны только для идентичных конструкций, продуктов, производственных процессов и технического обслуживания с идентичными эксплуатационными нагрузками и условиями использования. Даже незначительные изменения в любом из них могут оказать серьезное влияние на надежность. Более того, наиболее ненадежные и важные элементы (т.е. наиболее интересные кандидаты для исследования надежности), скорее всего, будут модифицированы и переработаны после сбора исторических данных, в результате чего стандартные (реактивные или упреждающие) статистические методы и процессы, используемые, например, в медицинской или страховой отраслях, менее эффективны. Еще один удивительный, но логичный аргумент заключается в том, что для того, чтобы иметь возможность точно предсказать надежность путем тестирования, необходимо знать точные механизмы отказа и, следовательно, в большинстве случаев их можно предотвратить! Следование неверным путем попыток количественной оценки и решения сложной проблемы обеспечения надежности с точки зрения наработки на отказ или вероятности с использованием неправильного, например, реактивного подхода, Барнард называет «игрой в числа» и считается как плохая практика. [20]

Для существующих систем можно утверждать, что любая попытка ответственной программы исправить основную причину обнаруженных сбоев может сделать первоначальную оценку MTBF недействительной, поскольку должны быть сделаны новые предположения (которые сами по себе подвержены высоким уровням ошибок) о эффекте этой коррекции. . Другой практической проблемой является общая недоступность подробных данных об отказах, причем имеющиеся часто характеризуются непоследовательной фильтрацией данных об отказах (обратной связи) и игнорированием статистических ошибок (которые очень высоки для редких событий, таких как отказы, связанные с надежностью). Должны существовать очень четкие руководящие принципы для подсчета и сравнения отказов, связанных с различными типами коренных причин (например, отказы при производстве, техническом обслуживании, транспортировке, системные или конструктивные отказы). Сравнение различных типов причин может привести к неверным оценкам и неправильным бизнес-решениям относительно направленности улучшений.

Выполнить правильный количественный прогноз надежности систем может быть сложно и очень дорого, если делать это путем тестирования. На уровне отдельных деталей результаты надежности часто можно получить со сравнительно высокой достоверностью, поскольку тестирование многих образцов деталей может быть возможным с использованием имеющегося бюджета на тестирование. Однако, к сожалению, эти тесты могут оказаться недействительными на уровне системы из-за допущений, сделанных при тестировании на уровне частей. Эти авторы подчеркивали важность первоначального тестирования на уровне детали или системы до момента отказа, а также учиться на таких неудачах для улучшения системы или детали. Делается общий вывод, что точный и абсолютный прогноз надежности – путем сравнения полевых данных или тестирования – в большинстве случаев невозможен. Исключением могут быть отказы из-за проблем изнашивания, таких как усталостные разрушения. Во введении к MIL-STD-785 написано, что прогнозирование надежности следует использовать с большой осторожностью, если не использовать исключительно для сравнения в исследованиях компромиссов.

Дизайн для надежности [ править ]

Проектирование для обеспечения надежности (DfR) — это процесс, включающий инструменты и процедуры, обеспечивающие соответствие продукта требованиям надежности в условиях его использования в течение всего срока его службы. DfR реализуется на стадии проектирования продукта для активного повышения надежности продукта. [21] DfR часто используется как часть общей стратегии Design for Excellence (DfX) .

Подход, основанный на статистике (т.е. среднее время безотказной работы) [ править ]

Проектирование надежности начинается с разработки модели (системы) . Модели надежности и доступности используют блок-схемы и анализ дерева отказов , чтобы предоставить графические средства оценки взаимосвязей между различными частями системы. Эти модели могут включать прогнозы, основанные на частоте отказов, взятых из исторических данных. Хотя прогнозы (входные данные) часто не точны в абсолютном смысле, они полезны для оценки относительных различий в альтернативных вариантах проектирования. Параметры ремонтопригодности, например среднее время ремонта (MTTR), также могут использоваться в качестве входных данных для таких моделей.

Наиболее важные фундаментальные инициирующие причины и механизмы отказов должны быть идентифицированы и проанализированы с помощью инженерных инструментов. Разработчикам следует предоставить разнообразный набор практических рекомендаций по производительности и надежности, чтобы они могли создавать конструкции и продукты с низкими нагрузками, которые защищают или защищены от повреждений и чрезмерного износа. В дополнение к проверке «работоспособности» надежности путем тестирования может потребоваться надлежащая проверка входных нагрузок (требований).

Диаграмма дерева неисправностей

Одним из наиболее важных приемов проектирования является избыточность . Это означает, что в случае сбоя одной части системы существует альтернативный путь успеха, например, резервная система. Причина, по которой это окончательный выбор конструкции, связана с тем фактом, что надежные доказательства надежности новых деталей или систем часто недоступны или их получение чрезвычайно дорого. За счет сочетания резервирования с высоким уровнем мониторинга отказов и предотвращения отказов по общей причине; даже систему с относительно низкой одноканальной (частичной) надежностью можно сделать высоконадежной на системном уровне (вплоть до критической надежности). Для этого не требуется никаких испытаний на надежность. В сочетании с резервированием использование разнородных конструкций или производственных процессов (например, через разных поставщиков одинаковых деталей) для единых независимых каналов может обеспечить меньшую чувствительность к проблемам качества (например, сбои в раннем детстве у одного поставщика), позволяя получать очень высокие уровни надежности, которая должна быть достигнута на всех этапах цикла разработки (от ранней до долгосрочной). Избыточность также может применяться в системной инженерии путем двойной проверки требований, данных, проектов, расчетов, программного обеспечения и тестов для устранения систематических сбоев.

Еще одним эффективным способом решения проблем с надежностью является проведение анализа, прогнозирующего деградацию, что позволяет предотвратить незапланированные простои/сбои. RCM Для этого можно использовать программы (Обслуживание, ориентированное на надежность).

физике отказов , Подход основанный на

В отношении электронных сборок наблюдается все больший сдвиг в сторону другого подхода, называемого физикой отказов . Этот метод основан на понимании физических статических и динамических механизмов отказа. Он учитывает изменения нагрузки, прочности и напряжения, которые приводят к отказу, с высоким уровнем детализации, что стало возможным благодаря использованию современного метода конечных элементов программного обеспечения (МКЭ), которое может обрабатывать сложные геометрии и механизмы, такие как ползучесть, релаксация напряжений. , усталость и вероятностный расчет ( методы Монте-Карло /DOE). Материал или компонент можно перепроектировать, чтобы уменьшить вероятность отказа и сделать его более устойчивым к таким изменениям. Еще одним распространенным методом проектирования является снижение номинальных характеристик компонентов : т.е. выбор компонентов, характеристики которых значительно превышают ожидаемые уровни напряжения, например, использование электрического провода более толстого сечения, чем обычно может быть указано для ожидаемого электрического тока .

Общие инструменты и методы [ править ]

Многие задачи, методы и анализы, используемые в проектировании надежности, специфичны для конкретных отраслей и приложений, но обычно могут включать в себя:

Результаты этих методов представлены во время анализа конструкции деталей или систем, а также логистики. Надежность — это лишь одно из многих требований к сложной детали или системе. Инженерные исследования компромиссов используются для определения оптимального баланса между требованиями надежности и другими ограничениями.

Важность языка [ править ]

Инженеры по надежности, использующие количественные или качественные методы для описания сбоя или опасности, полагаются на язык, чтобы точно определить риски и обеспечить решение проблем. Используемый язык должен помочь создать упорядоченное описание функции/элемента/системы и ее сложного окружения, связанного с отказом этих функций/элементов/систем. Системная инженерия во многом связана с поиском правильных слов для описания проблемы (и связанных с ней рисков), чтобы их можно было легко решить с помощью инженерных решений. Джек Ринг сказал, что работа системного инженера — «описывать проект на языке». (Ринг и др., 2000 г.) [23] В случае сбоев деталей/систем инженеры по надежности должны больше сосредоточиться на том, «почему и как», а не на прогнозировании «когда». Понимание того, «почему» произошел отказ (например, из-за перенапряжения компонентов или производственных проблем), с гораздо большей вероятностью приведет к улучшению используемых конструкций и процессов. [4] чем количественная оценка того, «когда» может произойти сбой (например, путем определения среднего времени безотказной работы). Для этого сначала необходимо классифицировать и упорядочить угрозы надежности, связанные с деталью/системой (если возможно, на основе некоторой формы качественной и количественной логики), чтобы обеспечить более эффективную оценку и возможное улучшение. Частично это делается с помощью чистого языка и логики предложений , но также на основе опыта работы с аналогичными объектами. Это можно увидеть, например, в описаниях событий при анализе дерева отказов , анализе FMEA и журналах (отслеживания) опасностей. В этом смысле язык и правильная грамматика (часть качественного анализа) играют важную роль в проектировании надежности, так же, как и в технике безопасности в целом или в системной инженерии .

Правильное использование языка также может стать ключом к выявлению или снижению рисков человеческих ошибок , которые часто являются основной причиной многих неудач. Это может включать в себя надлежащие инструкции в руководствах по техническому обслуживанию, руководствах по эксплуатации, аварийных процедурах и т. д. для предотвращения систематических человеческих ошибок, которые могут привести к сбоям в системе. Они должны быть написаны обученными или опытными техническими авторами, использующими так называемый упрощенный английский или упрощенный технический английский , где слова и структура специально выбраны и созданы таким образом, чтобы уменьшить двусмысленность или риск путаницы (например, фраза «заменить старую часть» может быть двусмысленной). относится к замене изношенной детали на неизношенную деталь или замене детали на деталь более новой и, как мы надеемся, улучшенной конструкции).

надежности Моделирование

Моделирование надежности — это процесс прогнозирования или понимания надежности компонента или системы до его реализации. всей системы, Два типа анализа, которые часто используются для моделирования поведения доступности включая влияние проблем логистики, таких как обеспечение запасными частями, транспорт и рабочая сила, — это анализ дерева отказов и блок-схемы надежности . На уровне компонентов одни и те же типы анализа могут использоваться вместе с другими. Входные данные для моделей могут поступать из многих источников, включая тестирование; предыдущий опыт работы; полевые данные; а также справочники данных из аналогичных или смежных отраслей. Независимо от источника, все входные данные модели следует использовать с большой осторожностью, поскольку прогнозы действительны только в тех случаях, когда один и тот же продукт использовался в одном и том же контексте. Таким образом, прогнозы часто используются только для сравнения альтернатив.

Блок-схема надежности, показывающая резервированную подсистему «1oo3» (1 из 3).

Для прогнозов на уровне деталей обычно используются две отдельные области исследования:

Теория надежности [ править ]

Надежность определяется как вероятность того, что устройство будет выполнять намеченную функцию в течение определенного периода времени при установленных условиях. Математически это можно выразить так:

,

где отказа – функция плотности вероятности , — продолжительность периода времени (который, как предполагается, начинается с нулевого времени).

В этом определении есть несколько ключевых элементов:

  1. Надежность зависит от «предназначенной функции». Обычно под этим подразумевается безотказная работа. Однако даже если ни одна отдельная часть системы не выходит из строя, а система в целом не делает того, что было задумано, то это все равно взимается с надежности системы. Спецификация системных требований является критерием, по которому измеряется надежность.
  2. Надежность распространяется на определенный период времени. На практике это означает, что у системы есть определенный шанс, что она будет работать без сбоев раньше времени. . Проектирование надежности гарантирует, что компоненты и материалы будут соответствовать требованиям в течение установленного времени. Обратите внимание, что иногда могут использоваться другие единицы, кроме времени (например, «миссия», «циклы эксплуатации»).
  3. Надежность ограничивается работой в установленных (или явно определенных) условиях. Это ограничение необходимо, поскольку невозможно спроектировать систему для неограниченных условий. Марсоход будет иметь другие условия , чем семейный автомобиль. Операционная среда должна учитываться во время проектирования и тестирования. Одному и тому же марсоходу может потребоваться работать в различных условиях, требующих дополнительного изучения.
  4. Двумя известными источниками теории надежности и ее математических и статистических основ являются Барлоу Р.Э. и Прошан Ф. (1982) и Саманиего Ф.Дж. (2007).

параметры надежности системы теория Количественные

Количественные требования задаются с использованием параметров надежности . Наиболее распространенным параметром надежности является среднее время до отказа (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]

  1. Срок службы продукта
  2. Предполагаемая функция
  3. Рабочее состояние
  4. Вероятность исполнения
  5. Исключения пользователей [33]

Срок службы продукта можно разделить на четыре различных для анализа. Срок полезного использования — это расчетный экономический срок службы продукта, который определяется как время, в течение которого можно использовать продукт, прежде чем затраты на ремонт не оправдают дальнейшее использование продукта. Гарантийный срок – изделие должно выполнять свою функцию в течение указанного периода времени. Проектный срок службы — это когда при проектировании продукта дизайнер учитывает срок службы конкурентоспособного продукта и желания клиентов и гарантирует, что продукт не приведет к неудовлетворенности клиентов. [34] [35]

Требования к испытаниям надежности могут следовать из любого анализа, для которого необходимо обосновать первую оценку вероятности отказа, вида отказа или его последствий. Доказательства могут быть получены с определенной степенью достоверности путем тестирования. В системах, основанных на программном обеспечении, вероятность представляет собой сочетание сбоев программного и аппаратного обеспечения. Тестирование требований к надежности проблематично по нескольким причинам. Одного теста в большинстве случаев недостаточно для получения достаточного количества статистических данных. Множественные тесты или длительные тесты обычно очень дороги. Некоторые тесты просто непрактичны, а условия окружающей среды сложно предсказать на протяжении жизненного цикла системы.

Проектирование надежности используется для разработки реалистичной и доступной программы испытаний, которая предоставляет эмпирические доказательства того, что система соответствует требованиям надежности. Статистические уровни достоверности используются для решения некоторых из этих проблем. Определенный параметр выражается вместе с соответствующим уровнем достоверности: например, среднее время безотказной работы 1000 часов при уровне достоверности 90%. На основе этой спецификации инженер по надежности может, например, разработать тест с явными критериями количества часов и количества отказов до тех пор, пока требование не будет выполнено или не будет выполнено. Возможны различные виды тестов.

Сочетание требуемого уровня надежности и требуемого уровня достоверности существенно влияет на стоимость разработки и риски как для заказчика, так и для производителя. Необходимо тщательно выбрать наилучшее сочетание требований, например, экономической эффективности. Тестирование надежности может выполняться на различных уровнях, таких как компонент, подсистема и система . Кроме того, во время испытаний и эксплуатации необходимо учитывать множество факторов, таких как экстремальная температура и влажность, удары, вибрация или другие факторы окружающей среды (например, потеря сигнала, охлаждения или питания; или другие катастрофы, такие как пожар, наводнение, чрезмерное тепло, физическое или нарушения безопасности или другие многочисленные формы ущерба или деградации). Для систем, которые должны прослужить много лет, могут потребоваться ускоренные жизненные испытания.

Метод тестирования [ править ]

Систематический подход к тестированию надежности заключается в том, чтобы сначала определить цель надежности, затем провести тесты, связанные с производительностью и определить надежность продукта. [36] Тесты по проверке надежности в современных отраслях должны четко определять, как они связаны с общими показателями надежности продукта и как отдельные тесты влияют на стоимость гарантии и удовлетворенность клиентов. [37]

Ускоренное тестирование [ править ]

Цель ускоренного испытания на срок службы (ALT-тест) состоит в том, чтобы вызвать отказ в полевых условиях в лаборатории гораздо быстрее, обеспечивая более суровую, но, тем не менее, репрезентативную среду. Ожидается, что в ходе такого испытания продукт потерпит неудачу в лаборатории так же, как он потерпел бы неудачу в полевых условиях, но за гораздо меньшее время. Основной целью ускоренного испытания является одно из следующих:

Программу ускоренного тестирования можно разбить на следующие этапы:

  • Определить цель и объем теста
  • Соберите необходимую информацию о продукте
  • Определите стресс(ы)
  • Определить уровень стресса(ов)
  • Проведите ускоренный тест и проанализируйте собранные данные.

Распространенными способами определения связи жизненного стресса являются:

  • Модель Аррениуса
  • Модель Айринга
  • Модель обратного степенного закона
  • Модель температуры и влажности
  • Температурная нетепловая модель

Надежность обеспечения программного

Надежность программного обеспечения — это особый аспект проектирования надежности. Основное внимание в нем уделяется основам и методам, позволяющим сделать программное обеспечение более надежным, то есть устойчивым к сбоям. Надежность системы по определению включает в себя все части системы, включая аппаратное обеспечение, программное обеспечение, вспомогательную инфраструктуру (включая критические внешние интерфейсы), операторов и процедуры. Традиционно при проектировании надежности основное внимание уделяется критическим аппаратным частям системы. С момента широкого распространения технологии цифровых интегральных схем программное обеспечение становится все более важной частью большинства электронных устройств и, следовательно, почти всех современных систем. Таким образом, надежность программного обеспечения приобрела важное значение в области надежности систем.

Однако существуют существенные различия в поведении программного и аппаратного обеспечения. В большинстве случаев ненадежность оборудования является результатом отказа компонента или материала, в результате которого система не выполняет намеченную функцию. Ремонт или замена аппаратного компонента возвращает систему в исходное рабочее состояние. Однако программное обеспечение не дает сбоев в том же смысле, что и аппаратное обеспечение. Вместо этого ненадежность программного обеспечения является результатом непредвиденных результатов операций программного обеспечения. Даже относительно небольшие программы могут иметь астрономически большие комбинации входных данных и состояний, которые невозможно полностью протестировать. Восстановление программного обеспечения в исходное состояние работает только до тех пор, пока та же комбинация входных данных и состояний не приведет к тому же непредвиденному результату. При проектировании надежности программного обеспечения это необходимо учитывать.

Несмотря на эту разницу в источниках сбоев между программным и аппаратным обеспечением, было предложено несколько моделей надежности программного обеспечения, основанных на статистике, для количественной оценки того, что мы испытываем с программным обеспечением: чем дольше работает программное обеспечение, тем выше вероятность того, что оно в конечном итоге будет использоваться в непроверенной среде. образом и обнаруживают скрытый дефект, который приводит к сбою ( Shooman 1987), (Musa 2005), (Denney 2005).

Как и в случае с аппаратным обеспечением, надежность программного обеспечения зависит от хороших требований, проектирования и реализации. Проектирование надежности программного обеспечения в значительной степени опирается на дисциплинированный процесс разработки программного обеспечения , позволяющий предвидеть и предотвращать непредвиденные последствия . программного обеспечения и разработкой надежности программного обеспечения существует больше совпадений, Между разработкой качества чем между качеством и надежностью аппаратного обеспечения. Хороший план разработки программного обеспечения является ключевым аспектом программы обеспечения надежности программного обеспечения. План разработки программного обеспечения описывает стандарты проектирования и кодирования, экспертные оценки , модульные тесты , управление конфигурацией , метрики программного обеспечения и модели программного обеспечения, которые будут использоваться во время разработки программного обеспечения.

Распространенным показателем надежности является количество ошибок программного обеспечения на строку кода (FLOC), обычно выражаемое как количество ошибок на тысячу строк кода. Этот показатель, наряду со временем выполнения программного обеспечения, является ключевым для большинства моделей и оценок надежности программного обеспечения. Теория состоит в том, что надежность программного обеспечения увеличивается по мере уменьшения количества ошибок (или плотности ошибок). Однако установить прямую связь между плотностью ошибок и средним временем между отказами сложно из-за способа распределения ошибок программного обеспечения в коде, их серьезности и вероятности комбинации входных данных, необходимых для обнаружения ошибки. Тем не менее, плотность отказов служит полезным индикатором для инженера по надежности. Также используются другие метрики программного обеспечения, такие как сложность. Этот показатель остается спорным, поскольку изменения в методах разработки и проверки программного обеспечения могут оказать существенное влияние на общий уровень дефектов.

Тестирование программного обеспечения является важным аспектом надежности программного обеспечения. Даже самый лучший процесс разработки программного обеспечения приводит к некоторым ошибкам в программном обеспечении, которые практически невозможно обнаружить до тех пор, пока они не будут проверены. Программное обеспечение тестируется на нескольких уровнях, начиная с отдельных модулей , через интеграцию и полное тестирование системы . На всех этапах тестирования обнаруживаются, исправляются и повторно тестируются ошибки программного обеспечения. Оценки надежности обновляются на основе плотности отказов и других показателей. На уровне системы можно собирать данные о среднем времени наработки на отказ и использовать их для оценки надежности. В отличие от аппаратного обеспечения, выполнение точно такого же теста на одной и той же конфигурации программного обеспечения не обеспечивает повышения статистической достоверности. Вместо этого надежность программного обеспечения использует другие показатели, такие как покрытие кода .

Института программной инженерии Модель зрелости возможностей является распространенным средством оценки общего процесса разработки программного обеспечения с точки зрения надежности и качества.

Структурная надежность

Структурная надежность или надежность конструкций — это применение теории надежности к поведению конструкций . Он используется как при проектировании, так и при обслуживании различных типов конструкций, включая бетонные и стальные конструкции. [38] [39] В исследованиях структурной надежности как нагрузки, так и сопротивления моделируются как вероятностные переменные. С помощью этого подхода рассчитывается вероятность разрушения конструкции.

с безопасности Сравнение техникой

Надежность и безопасность и надежность и доступность часто тесно связаны между собой. Потеря работоспособности инженерной системы может стоить денег. Если система метро недоступна, оператор метрополитена будет терять деньги за каждый час простоя системы. Оператор метро потеряет больше денег, если безопасность будет поставлена ​​под угрозу. Определение надежности связано с вероятностью отсутствия отказа. Сбой может привести к потере безопасности, потере доступности или к тому и другому. Нежелательно терять безопасность или доступность критической системы.

Проектирование надежности занимается общей минимизацией отказов, которые могут привести к финансовым потерям для ответственного лица, тогда как проектирование безопасности фокусируется на минимизации определенного набора типов отказов, которые в целом могут привести к гибели людей, травмам или повреждению оборудования.

Угрозы надежности могут трансформироваться в инциденты, ведущие к потере дохода компании или клиента, например, из-за прямых и косвенных затрат, связанных с: потерей производства из-за недоступности системы; неожиданно высокие или низкие требования к запчастям; затраты на ремонт; человеко-часы; перепроектирование или перерывы в нормальном производстве. [40]

Техника безопасности часто носит весьма специфичный характер и относится только к определенным строго регулируемым отраслям, приложениям или областям. Основное внимание в нем уделяется угрозам безопасности системы, которые могут привести к серьезным авариям, включая: гибель людей; разрушение оборудования; или экологический ущерб. Таким образом, требования к функциональной надежности соответствующей системы часто чрезвычайно высоки. Хотя он занимается нежелательными отказами в том же смысле, что и проектирование надежности, он, однако, уделяет меньше внимания прямым затратам и не касается действий по ремонту после отказа. Еще одним отличием является уровень воздействия сбоев на общество, что приводит к тенденции к строгому контролю со стороны правительств или регулирующих органов (например, атомной, аэрокосмической, оборонной, железнодорожной и нефтяной промышленности). [40]

Отказоустойчивость [ править ]

Безопасность можно повысить с помощью системы резервирования с перекрестной проверкой 2oo2. Доступность можно повысить, используя резервирование «1oo2» (1 из 2) на уровне детали или системы. Если оба резервных элемента расходятся во мнениях, более разрешающий элемент максимизирует доступность. Никогда не следует полагаться на систему 1oo2 в плане безопасности. Отказоустойчивые системы часто полагаются на дополнительную избыточность (например, логику голосования 2oo3 ), когда несколько избыточных элементов должны согласовать потенциально небезопасное действие, прежде чем оно будет выполнено. Это повышает доступность и безопасность на уровне системы. Это обычная практика в аэрокосмических системах, которые нуждаются в постоянной доступности и не имеют отказоустойчивого режима. Например, самолет может использовать тройное модульное резервирование бортовых компьютеров и поверхностей управления (включая иногда различные режимы работы, например, электрический/механический/гидравлический), поскольку они должны всегда быть в рабочем состоянии из-за того, что не существует «безопасных» положений по умолчанию. для поверхностей управления, таких как рули направления или элероны, во время полета самолета.

надежность и миссии Базовая надежность

Приведенный выше пример отказоустойчивой системы 2oo3 повышает как надежность, так и безопасность миссии. Однако «базовая» надежность системы в этом случае все равно будет ниже, чем у нерезервированной (1оо1) или 2оо2 системы. Базовое проектирование надежности охватывает все отказы, включая те, которые могут не привести к отказу системы, но приводят к дополнительным затратам из-за: действий по техническому обслуживанию и ремонту; логистика; запасные части и т. д. Например, замена или ремонт 1 неисправного канала в системе голосования 2оо3 (система все еще работает, хотя с одним неисправным каналом она фактически стала системой 2оо2) способствует базовой ненадежности, но не ненадежности миссии. Например, выход из строя хвостового фонаря самолета не помешает самолету летать (и поэтому не считается провалом миссии), но его необходимо исправить (с соответствующими затратами, что способствует базовые уровни ненадежности).

Обнаруживаемость и отказы по причине общей

При использовании отказоустойчивых (резервированных) систем или систем, оснащенных функциями защиты, обнаружение отказов и предотвращение отказов по общей причине становятся первостепенными для безопасного функционирования и/или надежности миссии.

и качество (шесть ) сигм Надежность

Качество часто фокусируется на производственных дефектах на гарантийном этапе. Надежность оценивает интенсивность отказов на протяжении всего срока службы изделия или технической системы от ввода в эксплуатацию до вывода из эксплуатации. «Шесть сигм» уходит корнями в статистический контроль качества производства. Проектирование надежности является специальной частью системного проектирования. Процесс системного проектирования — это процесс открытия, который часто отличается от производственного процесса. Производственный процесс часто сосредоточен на повторяющихся действиях, позволяющих достичь высокого качества продукции с минимальными затратами и временем. [41]

Термин «качество продукта» в повседневном использовании широко используется для обозначения присущей ему степени совершенства. В промышленности используется более точное определение качества как «соответствие требованиям или спецификациям в начале использования». Если предположить, что окончательная спецификация продукта адекватно отражает первоначальные требования и потребности клиента/системы, уровень качества можно измерить как долю отгруженных единиц продукта, соответствующих спецификациям. [42] Качество выпускаемой продукции часто зависит от количества рекламаций в течение гарантийного срока.

Качество представляет собой моментальный снимок в начале жизненного цикла и в течение гарантийного периода и связано с контролем технических характеристик продукта более низкого уровня. Сюда входят дефекты с нулевым временем, т. е. случаи, когда производственные ошибки ускользнули от окончательного контроля качества. Теоретически уровень качества можно описать одной долей бракованной продукции. Надежность, как часть системного проектирования, представляет собой постоянную оценку частоты отказов на протяжении многих лет. Теоретически все предметы выйдут из строя в течение бесконечного периода времени. [43] Дефекты, которые появляются с течением времени, называются снижением надежности. Для описания падения надежности необходима вероятностная модель, которая описывает падение доли во времени. Это известно как модель распределения жизни. [42] Некоторые из этих проблем с надежностью могут быть связаны с внутренними проблемами конструкции, которые могут существовать, даже если продукт соответствует спецификациям. Даже изделия, которые произведены идеально, со временем выйдут из строя из-за одного или нескольких механизмов отказа (например, из-за человеческой ошибки или механических, электрических и химических факторов). На эти проблемы надежности также могут влиять приемлемые уровни вариаций во время первоначального производства.

Таким образом, качество и надежность связаны с производством. Надежность больше ориентирована на клиентов, которые ориентированы на сбои на протяжении всего срока службы продукта, например, военные, авиакомпании или железные дороги. Элементы, которые не соответствуют спецификации продукта, обычно имеют худшие показатели надежности (имеют более низкое значение MTTF), но это не всегда так. Полная математическая количественная оценка (в статистических моделях) этого комбинированного отношения, как правило, очень сложна или даже практически невозможна. В тех случаях, когда производственные отклонения могут быть эффективно сокращены, инструменты шести сигм оказались полезными для поиска оптимальных технологических решений, которые могут повысить качество и надежность. «Шесть сигм» также может помочь в разработке продуктов, которые более устойчивы к производственным сбоям и дефектам детской смертности в инженерных системах и производимой продукции.

В отличие от Шести Сигм, инженерные решения по обеспечению надежности обычно находятся путем сосредоточения внимания на тестировании надежности и проектировании систем. Решения можно найти разными способами, например, путем упрощения системы, позволяющего лучше понять механизмы сбоев; выполнение подробных расчетов уровней напряжения материала, позволяющих определить подходящие коэффициенты безопасности; обнаружение возможных аномальных условий нагрузки на систему и использование их для повышения устойчивости конструкции к механизмам отказов, связанным с производственными отклонениями. Кроме того, в проектировании надежности используются решения системного уровня, такие как проектирование резервных и отказоустойчивых систем для ситуаций с требованиями высокой доступности (см. « Инжиниринг надежности и проектирование безопасности» выше).

Примечание. «Дефект» в литературе по шести сигмам/качеству — это не то же самое, что «отказ» (отказ в эксплуатации | например, сломанный предмет) в надежности. Дефект шести сигм/качества обычно относится к несоответствию требованию (например, базовой функциональности или ключевому измерению). Однако со временем элементы могут выйти из строя, даже если все эти требования выполнены. Качество, как правило, не связано с ответом на ключевой вопрос «действительно ли требования верны?», тогда как надежность связана с ним.

Эксплуатационная надежности оценка

После производства систем или деталей специалисты по обеспечению надежности пытаются отслеживать, оценивать и исправлять недостатки. Мониторинг включает в себя электронный и визуальный контроль критических параметров, выявленных на этапе проектирования анализа дерева отказов. Сбор данных во многом зависит от характера системы. В большинстве крупных организаций есть группы контроля качества , которые собирают данные о неисправностях транспортных средств, оборудования и техники. Неисправность потребительских товаров часто отслеживается по количеству возвратов. Для систем, находящихся в режиме бездействия или ожидания, необходимо создать официальную программу наблюдения для проверки и тестирования случайных выборок. Любые изменения в системе, такие как модернизация на месте или отзывной ремонт, требуют дополнительных испытаний на надежность, чтобы гарантировать надежность модификации. Поскольку невозможно предвидеть все виды отказов данной системы, особенно с участием человеческого фактора, сбои будут возникать. Программа надежности также включает систематический анализ первопричин. который определяет причинно-следственные связи, связанные с отказом, так что могут быть реализованы эффективные корректирующие действия. Когда это возможно, о сбоях системы и корректирующих действиях сообщается в организацию по обеспечению надежности.

Некоторыми из наиболее распространенных методов, применяемых для эксплуатационной оценки надежности, являются системы отчетности, анализа и корректирующих действий по отказам (FRACAS). Этот систематический подход развивает оценку надежности, безопасности и логистики на основе отчетов об отказах/происшествиях, управления, анализа и корректирующих/предупреждающих действий. Сегодня организации внедряют этот метод и используют коммерческие системы (такие как веб-приложения FRACAS), которые позволяют им создавать хранилище данных об отказах/происшествиях, из которого можно получить статистику для просмотра точных и достоверных показателей надежности, безопасности и качества.

Для организации чрезвычайно важно внедрить общую систему FRACAS для всех конечных устройств. Кроме того, это должно позволять фиксировать результаты испытаний практическим способом. Неспособность внедрить одну простую в использовании (с точки зрения простоты ввода данных для инженеров по эксплуатации и инженеров ремонтных мастерских) и простую в обслуживании интегрированную систему, скорее всего, приведет к сбою самой программы FRACAS.

Некоторые общие выходные данные системы FRACAS включают наработку на отказ на месте, среднее время восстановления, потребление запасных частей, рост надежности, распределение отказов/происшествий по типу, местоположению, номеру детали, серийному номеру и признаку.

Использование прошлых данных для прогнозирования надежности новых сопоставимых систем/изделий может ввести в заблуждение, поскольку надежность зависит от контекста использования и на нее могут влиять небольшие изменения в конструкции/производстве.

Организации по надежности [ править ]

Системы любой значительной сложности разрабатываются организациями людей, например коммерческой компанией или государственным учреждением. Организация по обеспечению надежности должна соответствовать организационной структуре компании . Для небольших некритичных систем проектирование надежности может быть неформальным. По мере роста сложности возникает необходимость в формальной функции надежности. Поскольку надежность важна для потребителя, заказчик может даже указать определенные аспекты организации надежности.

Существует несколько распространенных типов организаций, обеспечивающих надежность. Руководитель проекта или главный инженер может напрямую нанять одного или нескольких инженеров по надежности. В более крупных организациях обычно существует организация по обеспечению качества продукции или специализированная инженерная организация, которая может включать в себя надежность, ремонтопригодность , качество , безопасность, человеческий фактор , логистику и т. д. В таком случае инженер по надежности подчиняется менеджеру по обеспечению качества продукции или специальному инженерному менеджеру. .

В некоторых случаях компания может пожелать создать независимую организацию по обеспечению надежности. Это желательно для того, чтобы гарантировать, что надежность системы, которая часто является дорогостоящей и трудоемкой, не будет необоснованно пренебрегаться из-за ограничений бюджета и графика. В таких случаях инженер по надежности работает над проектом изо дня в день, но на самом деле его нанимает и оплачивает отдельная организация внутри компании.

Поскольку проектирование надежности имеет решающее значение для раннего проектирования системы, для инженеров по надежности стало обычным явлением, однако организация структурирована таким образом, чтобы работать как часть интегрированной группы продуктов .

Образование [ править ]

Некоторые университеты предлагают ученые степени в области инженерии надежности. Другие специалисты по надежности обычно имеют степень физики, полученную в университете или колледже. Многие инженерные программы предлагают курсы по надежности, а в некоторых университетах есть целые программы по инженерии по надежности. Инженер по надежности должен быть зарегистрирован в качестве профессионального инженера по закону штата или провинции, но не все специалисты по надежности являются инженерами. Инженеры по надежности требуются в системах, где общественная безопасность находится под угрозой. Для инженеров по надежности доступно множество профессиональных конференций и отраслевых программ обучения. Существует несколько профессиональных организаций инженеров по надежности, в том числе Американское общество по обеспечению качества и надежности (ASQ-RD). [44] Общество надежности IEEE , Американское общество качества (ASQ), [45] и Общество инженеров по надежности (SRE). [46]

См. также [ править ]

Ссылки [ править ]

  1. ^ Институт инженеров по электротехнике и электронике (1990) Стандартный компьютерный словарь IEEE: сборник стандартных компьютерных глоссариев IEEE. Нью-Йорк, штат Нью-Йорк ISBN   1-55937-079-3
  2. ^ RCM II, Техническое обслуживание, ориентированное на надежность, второе издание 2008 г., страницы 250–260, роль актуарного анализа в надежности.
  3. ^ Почему вы не можете предсказать надежность электронных продуктов (PDF) . 2012 АРС, Европа. Варшава, Польша.
  4. ^ Перейти обратно: а б О'Коннор, Патрик Д.Т. (2002), Практическая инженерия надежности (Четвертое изд.), John Wiley & Sons, Нью-Йорк. ISBN   978-0-4708-4462-5 .
  5. ^ Авен, Терье (1 июня 2017 г.). «Совершенствование основ и практики проектирования надежности» . Труды Института инженеров-механиков, Часть O: Журнал риска и надежности . 231 (3): 295–305. дои : 10.1177/1748006X17699478 . ISSN   1748-006X .
  6. ^ Салех, Дж. Х. и Марэ, Кен, «Основные моменты из ранней (и предшествующей) истории проектирования надежности», Проектирование надежности и системная безопасность, том 91, выпуск 2, февраль 2006 г., страницы 249–256
  7. ^ Джуран, Джозеф и Грина, Фрэнк, Справочник по контролю качества, четвертое издание, McGraw-Hill, Нью-Йорк, 1988, стр.24.3
  8. ^ Надежность военной электронной техники;отчет . Вашингтон: Министерство обороны США . 4 июня 1957 г. hdl : 2027/mdp.39015013918332 .
  9. ^ Вонг, Кам, «Теория единого поля (разрушения) - разрушение кривой ванны», Труды ежегодного RAMS, 1981, стр. 402–408
  10. ^ Перейти обратно: а б Тан, Цзяньфэн; Чен, Цзе; Чжан, Чун; Го, Цин; Чу, Цзе (1 марта 2013 г.). «Изучение технологического процесса, оптимизация и проверка надежности колонны раскисления природного газа, применяемой на морских месторождениях» . Химические инженерные исследования и проектирование . 91 (3): 542–551. Бибкод : 2013CERD...91..542T . дои : 10.1016/j.cherd.2012.09.018 . ISSN   0263-8762 .
  11. ^ Практическая инженерия надежности, П. О'Коннер - 2012 г.
  12. ^ «Статьи – Откуда берутся инженеры по надежности? – ReliabilityWeb.com: Культура надежности» .
  13. ^ Использование видов отказов, механизмов и анализа последствий при расследовании нежелательных явлений на медицинских устройствах, С. Ченг, Д. Дас и М. Пехт, ICBO: Международная конференция по биомедицинской онтологии, Буффало, Нью-Йорк, 26–30 июля 2011 г., стр. . 340–345
  14. ^ Федеральное управление гражданской авиации (19 марта 2013 г.). Руководство по безопасности системы . Министерство транспорта США . Проверено 2 июня 2013 г.
  15. ^ Надёжность Hotwire – июль 2015 г.
  16. ^ Надежность, ремонтопригодность и практические методы управления рисками для инженеров, включая техническое обслуживание и безопасность, ориентированные на надежность. - Дэвид Дж. Смит (2011)
  17. ^ Перейти обратно: а б Практическая инженерия надежности, О'Коннер, 2001 г.
  18. ^ Теория надежности систем, второе издание, Раусанд и Хойланд - 2004 г.
  19. ^ Машина обвинения, Почему человеческие ошибки вызывают несчастные случаи - Уиттингем, 2007 г.
  20. ^ Барнард, RWA (2008). «Что не так с проектированием надежности?» (PDF) . Лямбда Консалтинг . Проверено 30 октября 2014 г.
  21. ^ http://www.dfrsolutions.com/hubfs/DfR_Solutions_Website/Resources-Archived/Presentations/2016/Design-for-Reliability-Best-Practices.pdf?t=1505335343846 [ пустой URL PDF ]
  22. ^ Сальваторе Дистефано, Антонио Пулиафито: Оценка надежности с помощью блок-схем динамической надежности и динамических деревьев отказов. IEEE Транс. Надежный сек. Вычислить. 6 (1): 4–17 (2009)
  23. ^ Семь самураев системной инженерии , Джеймс Мартин (2008) [ мертвая ссылка ]
  24. ^ Чжан, Дж.; Гейгер, К.; Сан, Ф. (январь 2016 г.). «Системный подход к разработке испытаний для проверки надежности» . Ежегодный симпозиум по надежности и ремонтопригодности (RAMS) 2016 г. стр. 1–6. дои : 10.1109/RAMS.2016.7448014 . ISBN  978-1-5090-0249-8 . S2CID   24770411 .
  25. ^ Дай, Вэй; Маропулос, Пол Г.; Чжао, Ю (2 января 2015 г.). «Моделирование надежности и верификация производственных процессов на основе управления процессными знаниями» . Международный журнал компьютерно-интегрированного производства . 28 (1): 98–111. дои : 10.1080/0951192X.2013.834462 . ISSN   0951-192Х . S2CID   32995968 .
  26. ^ «Проверка надежности процессоров искусственного интеллекта и машинного обучения — технический документ» . www.allaboutcircuits.com . Проверено 11 декабря 2020 г.
  27. ^ Вебер, Вольфганг; Тондок, Хайдемари; Бахмайер, Майкл (1 июля 2005 г.). «Повышение безопасности программного обеспечения с помощью деревьев ошибок: опыт от приложения до критически важного программного обеспечения» . Проектирование надежности и системная безопасность . Безопасность, надежность и защищенность промышленных компьютерных систем. 89 (1): 57–70. дои : 10.1016/j.ress.2004.08.007 . ISSN   0951-8320 .
  28. ^ Рен, Юаньцян; Тао, Цзинья; Сюэ, Чжаопэн (январь 2020 г.). «Проектирование крупномасштабного сетевого слоя пьезоэлектрических преобразователей и проверка его надежности для космических конструкций» . Датчики . 20 (15): 4344. Бибкод : 2020Senso..20.4344R . дои : 10.3390/s20154344 . ПМЦ   7435873 . ПМИД   32759794 .
  29. ^ Бен-Гал И., Херер Ю. и Раз Т. (2003). «Процедура самокорректирующейся проверки при ошибках проверки» (PDF) . Транзакции IIE по качеству и надежности, 34 (6), стр. 529–540. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  30. ^ «Тестирование надежности Yelo» . Проверено 6 ноября 2014 г.
  31. ^ Мэтисон, Грэнвилл Дж. (24 мая 2019 г.). «Нам нужно поговорить о надежности: лучше использовать повторные тестовые исследования для планирования и интерпретации исследований» . ПерДж . 7 : e6918. дои : 10.7717/peerj.6918 . ISSN   2167-8359 . ПМК   6536112 . ПМИД   31179173 .
  32. ^ Пронских, Виталий (1 марта 2019 г.). «Компьютерное моделирование и симуляция: повышение надежности за счет разделения проверки и проверки» . Разум и машины . 29 (1): 169–186. дои : 10.1007/s11023-019-09494-7 . ISSN   1572-8641 . ОСТИ   1556973 . S2CID   84187280 .
  33. ^ Халамей, Д.А.; Старретт, М.; Бреккен, ТКА (2019). «Аппаратное тестирование электрических водонагревателей, обеспечивающих накопление энергии и реагирование на спрос посредством прогнозирующего управления моделью» . Доступ IEEE . 7 : 139047–139057. Бибкод : 2019IEEA...7m9047H . дои : 10.1109/ACCESS.2019.2932978 . ISSN   2169-3536 .
  34. ^ Чен, Цзин; Ван, Инлун; Го, Ин; Цзян, Мингюэ (19 февраля 2019 г.). «Метаморфический подход к тестированию последовательностей событий» . ПЛОС ОДИН . 14 (2): e0212476. Бибкод : 2019PLoSO..1412476C . дои : 10.1371/journal.pone.0212476 . ISSN   1932-6203 . ПМК   6380623 . ПМИД   30779769 .
  35. ^ Беньковская, Агнешка; Творек, Катажина; Заблокка-Ключка, Анна (январь 2020 г.). «Верификация модели организационной надежности на этапе эскалации кризиса, вызванного пандемией COVID-19» . Устойчивость . 12 (10): 4318. дои : 10.3390/su12104318 .
  36. ^ Женихин, М.; Лай, X.; Гасемпури, Т.; Райк Дж. (октябрь 2018 г.). «На пути к многомерной проверке: где функциональное встречается с нефункциональным» . Конференция IEEE Nordic Circuits and Systems (NORCAS) 2018: NORCHIP и Международный симпозиум по системам на кристалле (SoC) . стр. 1–7. arXiv : 1908.00314 . дои : 10.1109/NORCHIP.2018.8573495 . ISBN  978-1-5386-7656-1 . S2CID   56170277 .
  37. ^ Раквитц, Р. (21 февраля 2000 г.). «Оптимизация — основа кодообразования и проверки надежности» . Структурная безопасность . 22 (1): 27–60. дои : 10.1016/S0167-4730(99)00037-5 . ISSN   0167-4730 .
  38. ^ Пирионеси, Сайед Мадех; Таваколан, Мехди (9 января 2017 г.). «Модель математического программирования для решения задач оптимизации затрат и безопасности (CSO) при обслуживании сооружений». Журнал гражданского строительства KSCE . 21 (6): 2226–2234. дои : 10.1007/s12205-017-0531-z . S2CID   113616284 .
  39. ^ Окаша, Нью-Мексико, и Франгополь, Д.М. (2009). Многоцелевая оптимизация обслуживания конструкций, ориентированная на весь срок службы, с учетом надежности системы, резервирования и стоимости жизненного цикла с использованием GA. Структурная безопасность, 31(6), 460–474 .
  40. ^ Перейти обратно: а б Техника надежности и безопасности - Верма, Аджит Кумар, Аджит, Шривидья, Каранки, Дурга Рао (2010)
  41. ^ Рекомендации INCOSE SE
  42. ^ Перейти обратно: а б «8.1.1.1. Качество против надежности» .
  43. ^ «Второй закон термодинамики, эволюции и вероятности» .
  44. ^ Отделение надежности качества Американского общества (ASQ-RD)
  45. ^ Американское общество качества (ASQ)
  46. ^ Общество инженеров по надежности (SRE)
  • Н. Диас, Р. Паскуаль, Ф. Руджери, Э. Лопес Дрогетт (2017). «Моделирование политики замены возраста в различных временных масштабах и стохастических профилях использования». Международный журнал экономики производства . 188 : 22–28. дои : 10.1016/j.ijpe.2017.03.009 . {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )

Дальнейшее чтение [ править ]

  • Барлоу Р.Э. и Проскан Ф. (1981) Статистическая теория надежности и жизненных испытаний, Для начала с прессой, Силвер Спрингс, Мэриленд.
  • Бланшар, Бенджамин С. (1992), Логистика и менеджмент (Четвертое изд.), Prentice-Hall, Inc., Энглвуд Клиффс, Нью-Джерси.
  • Брейтлер, Алан Л. и Слоан, К. (2005), Труды конференции Американского института аэронавтики и астронавтики (AIAA) Air Force T&E Days, Нэшвилл, Теннесси, декабрь 2005 г.: Прогнозирование надежности системы: к общему подходу с использованием Нейронная сеть.
  • Эбелинг, Чарльз Э., (1997), Введение в проектирование надежности и ремонтопригодности , McGraw-Hill Companies, Inc., Бостон.
  • Денни, Ричард (2005) Успех в сценариях использования: разумная работа для обеспечения качества. Профессиональное издательство Аддисон-Уэсли. ISBN. Обсуждается использование проектирования надежности программного обеспечения при разработке программного обеспечения на основе сценариев использования .
  • Гано, Дин Л. (2007), «Анализ коренных причин Аполлона» (третье издание), Apollonian Publications, LLC., Ричленд, Вашингтон
  • Холмс, Оливер Венделл- старший. Шедевр Дикона
  • Хорсбург, Питер (2018), «5 навыков выдающегося инженера по надежности», Reliability Web
  • Капур К.К. и Ламберсон Л.Р. (1977), « Надежность в инженерном проектировании» , John Wiley & Sons, Нью-Йорк.
  • Кечечиоглу, Дмитрий, (1991) «Справочник по проектированию надежности», Прентис-Холл, Энглвуд Клиффс, Нью-Джерси
  • Тревор Клец (1998) Технологические установки: Справочник по более безопасному проектированию CRC ISBN   1-56032-619-0
  • Лимис, Лоуренс, (1995) Надежность: вероятностные модели и статистические методы , 1995, Прентис-Холл. ISBN   0-13-720517-1
  • Лис, Фрэнк (2005). Предотвращение потерь в перерабатывающей промышленности (3-е изд.). Эльзевир. ISBN  978-0-7506-7555-0 .
  • МакДиармид, Престон; Моррис, Сеймур; и др., (1995), «Инструментарий по надежности: издание коммерческой практики» , Центр анализа надежности и Римская лаборатория, Рим, Нью-Йорк.
  • Модаррес, Мохаммед ; Каминский, Марк; Кривцов , Василий (1999), Проектирование надежности и анализ рисков: Практическое руководство , CRC Press, ISBN   0-8247-2000-8 .
  • Муса, Джон (2005) Проектирование надежности программного обеспечения: более надежное программное обеспечение, быстрее и дешевле, 2-е место. Издание, АвторДом. ISBN
  • Нойбек, Кен (2004) «Практический анализ надежности», Прентис Холл, Нью-Джерси
  • Нойфельдер, Энн Мари, (1993), Обеспечение надежности программного обеспечения , Marcel Dekker, Inc., Нью-Йорк.
  • О'Коннор, Патрик Д.Т. (2002), Практическая инженерия надежности (Четвертое изд.), John Wiley & Sons, Нью-Йорк. ISBN   978-0-4708-4462-5 .
  • Саманиего, Франциско Дж. (2007) «Системные сигнатуры и их применение в инженерной надежности», Springer (Международная серия по исследованию операций и науке управления), Нью-Йорк.
  • Шуман, Мартин (1987), Разработка программного обеспечения: проектирование, надежность и управление , МакГроу-Хилл, Нью-Йорк.
  • Тобиас, Триндаде, (1995), Прикладная надежность , Chapman & Hall/CRC, ISBN   0-442-00469-9
  • Серия Springer в области обеспечения надежности
  • Нельсон, Уэйн Б. (2004), Ускоренное тестирование — статистические модели, планы тестирования и анализ данных , John Wiley & Sons, Нью-Йорк, ISBN   0-471-69736-2
  • Багдонавичюс В., Никулин М. (2002), «Модели ускоренной жизни. Моделирование и статистический анализ», CHAPMAN&HALL/CRC, Бока-Ратон, ISBN   1-58488-186-0
  • Тодинов М. (2016), «Модели надежности и риска: установление требований к надежности», Wiley, 978-1-118-87332-8.

Стандарты, спецификации и справочники США [ править ]

http://standards.sae.org/ja1000/1_199903/ Руководство по внедрению стандарта программы обеспечения надежности SAE JA1000/1

Стандарты Великобритании [ править ]

В Великобритании существуют более современные стандарты, поддерживаемые Министерством обороны Великобритании в качестве оборонных стандартов. Соответствующие стандарты включают:

DEF STAN 00-40 Надежность и ремонтопригодность (R&M)

  • ЧАСТЬ 1: Вопрос 5: Обязанности и требования руководства к программам и планам
  • ЧАСТЬ 4: (ARMP-4) Вопрос 2: Руководство по написанию документов НАТО с требованиями R&M
  • ЧАСТЬ 6: Проблема 1: ЭКСПЛУАТАЦИОННЫЕ НИОКР
  • ЧАСТЬ 7 (ARMP-7), вопрос 1: Терминология НАТО по R&M, применимая к ARMP

DEF STAN 00-42 РУКОВОДСТВА ПО ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ И ОБСЛУЖИВАНИЯ

  • ЧАСТЬ 1: Проблема 1: ОДНОРАЗОВЫЕ УСТРОЙСТВА/СИСТЕМЫ
  • ЧАСТЬ 2: Проблема 1: ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
  • ЧАСТЬ 3: Проблема 2: ДЕЛО R&M
  • ЧАСТЬ 4: Проблема 1: Тестируемость
  • ЧАСТЬ 5: Проблема 1: ДЕМОНСТРАЦИЯ НАДЕЖНОСТИ В ЭКСПЛУАТАЦИИ

DEF STAN 00-43 ДЕЯТЕЛЬНОСТЬ ПО ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ И ОБСЛУЖИВАНИЯ

  • ЧАСТЬ 2: Проблема 1: ДЕМОНСТРАЦИЯ ОБСЛУЖИВАНИЯ В ЭКСПЛУАТАЦИИ

DEF STAN 00-44 НАДЕЖНОСТЬ И ОБСЛУЖИВАНИЕ СБОР И КЛАССИФИКАЦИЯ ДАННЫХ

  • ЧАСТЬ 1: Проблема 2: ДАННЫЕ ОБ ОБСЛУЖИВАНИИ И СООБЩЕНИЕ О ДЕФЕКТАХ В КОРОЛЕВСКОМ ВМФ, АРМИИ И КОРОЛЕВСКИХ ВВС
  • ЧАСТЬ 2: Проблема 1: КЛАССИФИКАЦИЯ ДАННЫХ И ВЫНОСЕНИЕ ПРИГОВОРА ЗА СЛУЧАИ – ОБЩИЕ ПОЛОЖЕНИЯ
  • ЧАСТЬ 3: Проблема 1: ВЫНОСЕНИЕ ПРИГОВОРА ЗА ПРОИСШЕСТВИЯ – МОРЕ
  • ЧАСТЬ 4: Вопрос 1: ВЫНОСЕНИЕ ПРИГОВОРА ЗА ПРОИСШЕСТВИЯ – ЗЕМЛЯ

DEF STAN 00-45, выпуск 1: ОБСЛУЖИВАНИЕ, ЦЕНТРИРОВАННОЕ НА НАДЕЖНОСТИ

DEF STAN 00-49 Выпуск 1: НАДЕЖНОСТЬ И ОБСЛУЖИВАНИЕ MOD РУКОВОДСТВО ПО ОПРЕДЕЛЕНИЯМ ТЕРМИНОЛОГИИ

Их можно получить из DSTAN . Существует также множество коммерческих стандартов, разработанных многими организациями, включая SAE, MSG, ARP и IEE.

Французские стандарты [ править ]

  • ФИДЕС [1] . Методология FIDES (UTE-C 80-811) основана на физике отказов и поддерживается анализом данных испытаний, результатов эксплуатации и существующего моделирования.
  • УТЕ-С 80–810 или РДФ2000 [2] . Методика RDF2000 основана на опыте французской телекоммуникации.

Международные стандарты

Внешние ссылки [ править ]

Arc.Ask3.Ru: конец оригинального документа.
Arc.Ask3.Ru
Номер скриншота №: 2D205C5B0BE618DF9150775CD54DFD1C__1713251880
URL1:https://en.wikipedia.org/wiki/Reliability_engineering
Заголовок, (Title) документа по адресу, URL1:
Reliability engineering - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть, любые претензии не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, денежную единицу можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)