Техника надежности - Reliability engineering

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

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

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

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

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

История

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

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

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

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

Обзор

Цель

Задачи проектирования надежности в порядке убывания приоритета:^[9]

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

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

Объем и методы

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

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

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

• Трибология
• Стресс (механика)
• Механика разрушения / усталость
• Тепловая инженерия
• Гидравлическая механика / ударная техника
• Электротехника
• Химическая инженерия (например. коррозия )
• Материаловедение

Определения

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

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

Основы оценки надежности

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

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

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

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

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

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

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

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

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

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

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

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

Требования к надежности

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

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

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

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

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

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

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

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

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

Прогноз надежности объединяет:

• создание правильной модели надежности (см. далее на этой странице)
• оценка (и обоснование) входных параметров для этой модели (например, интенсивность отказов для конкретного режима отказа или события и среднее время ремонта системы для конкретного отказа)
• оценка выходных параметров надежности на уровне системы или части (т.е. доступность системы или частота конкретного функционального отказа). Акцент на количественной оценке и установке целевых показателей (например, наработка на отказ) может означать, что существует предел достижимой надежности, однако внутреннего предела нет и разработка более высокой надежности не должна быть более затратной. Кроме того, они утверждают, что прогноз надежности на основе исторических данных может быть очень обманчивым, поскольку сравнения действительны только для идентичных конструкций, продуктов, производственных процессов и обслуживания с идентичными рабочими нагрузками и средами использования. Даже незначительные изменения в любом из них могут серьезно повлиять на надежность. Кроме того, наиболее ненадежные и важные элементы (то есть наиболее интересные кандидаты для исследования надежности), скорее всего, будут модифицированы и переработаны, поскольку исторические данные были собраны, что делает стандартные (повторно активные или упреждающие) статистические методы и процессы, используемые, например, медицинская или страховая отрасли менее эффективны. Еще один удивительный, но логичный аргумент заключается в том, что для точного прогнозирования надежности путем тестирования необходимо знать точные механизмы отказа и, следовательно, в большинстве случаев их можно предотвратить! Следование неправильному пути попытки количественной оценки и решения сложной инженерной проблемы надежности с точки зрения MTBF или вероятности с использованием неверного - например, реактивного - подхода Барнард называет "игрой в числа" и считается как плохая практика.^[18]

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

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

Дизайн для надежности

Дизайн для обеспечения надежности (DfR) - это процесс, который включает в себя инструменты и процедуры, обеспечивающие соответствие продукта требованиям надежности в среде его использования на протяжении всего срока его службы. DfR внедряется на этапе проектирования продукта для упреждающего повышения надежности продукта.^[19] DfR часто используется как часть общей Дизайн для совершенства (DfX) стратегия.

Подход, основанный на статистике (например, MTBF)

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

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

Диаграмма дерева отказов

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

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

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

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

Общие инструменты и методы

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

• Физика отказа (PoF)
• Встроенная самопроверка (BIT) (анализ проверяемости)
• Анализ видов и последствий отказов (FMEA)
• Надежность анализ опасности
• Анализ блок-схемы надежности
• Анализ блок-схемы динамической надежности^[20]
• Анализ дерева отказов
• Анализ причин
• Статистическая инженерия, дизайн экспериментов - например, на симуляциях / FEM моделях или с тестированием
• Анализ скрытых цепей
• Ускоренное тестирование
• Анализ роста надежности (реактивная надежность)
• Weibull анализ (для тестирования или, в основном, «реактивной» надежности)
• Термический анализ методом конечных элементов (FEA) и / или измерений
• Тепловые, ударные и вибрационная усталость анализ методом FEA и / или измерения
• Электромагнитный анализ
• Избегание единая точка отказа (SPOF)
• Функциональный анализ и анализ функциональных отказов (например, функция FMEA, FHA или FFA)
• Прогностическое и профилактическое обслуживание: анализ технического обслуживания, ориентированного на надежность (RCM)
• Анализ тестируемости
• Анализ диагностики отказов (обычно также включается в FMEA)
• Анализ человеческих ошибок
• Анализ эксплуатационных рисков
• Оптимизация профилактического / планового обслуживания (PMO)
• Ручной досмотр
• Комплексная логистическая поддержка

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

Важность языка

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

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

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

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

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

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

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

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

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

${ Displaystyle R (T) = Pr {T> t } = int _ {t} ^ { infty} f (x) , dx !}$,

куда ${ Displaystyle е (х) !}$ это неудача функция плотности вероятности и ${ displaystyle t}$ - продолжительность периода времени (который, как предполагается, начинается с нуля).

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

1. Надежность зависит от «предполагаемой функции»: обычно это означает работу без сбоев. Тем не менее, даже если ни одна из отдельных частей системы не выходит из строя, а система в целом не выполняет то, что было задумано, ее все равно списывают на надежность системы. Спецификация системных требований - это критерий, по которому измеряется надежность.
2. Надежность распространяется на определенный период времени. На практике это означает, что у системы есть определенный шанс, что она будет работать без сбоев раньше времени. ${ Displaystyle т !}$. Инжиниринг надежности гарантирует, что компоненты и материалы будут соответствовать требованиям в течение указанного времени. Обратите внимание, что иногда могут использоваться единицы, отличные от времени (например, «миссия», «рабочие циклы»).
3. Надежность ограничивается работой в указанных (или явно определенных) условиях. Это ограничение необходимо, потому что невозможно разработать систему для неограниченных условий. А Марсоход будут иметь другие указанные условия, чем семейный автомобиль. Во время проектирования и тестирования необходимо учитывать операционную среду. Этот же ровер может потребоваться для работы в различных условиях, требующих дополнительной проверки.
4. Двумя известными ссылками на теорию надежности и ее математические и статистические основы являются Barlow, R.E. и Proschan, F. (1982) и Samaniego, F.J. (2007).

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

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

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

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

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

Тестирование надежности

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

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

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

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

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

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

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

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

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

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

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

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

Ускоренное тестирование

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

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

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

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

Распространенные способы определения отношений жизненного стресса:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отказоустойчивость

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

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

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

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

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

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

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

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

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

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

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

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

Операционная оценка надежности

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

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

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

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

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

Организации надежности

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

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

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

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

Образование

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

Группа инженеров предоставила список полезных инструментов для проектирования надежности. К ним относятся: программное обеспечение PTC Windchill, программное обеспечение RAM Commander, программное обеспечение RelCalc, Military Handbook 217 (Mil-HDBK-217), 217Plus и руководство NAVMAT P-4855-1A. Анализ неудач и успехов в сочетании с процессом стандартизации качества также предоставляет систематизированную информацию для создания обоснованных инженерных проектов.^[33]

Смотрите также

Рекомендации

• Н. Диас, Р. Паскуаль, Ф. Руджери, Э. Лопес Дрогетт (2017). «Моделирование политики замены возраста в различных временных масштабах и стохастических профилях использования». Международный журнал экономики производства. 188: 22–28. Дои:10.1016 / j.ijpe.2017.03.009.CS1 maint: несколько имен: список авторов (связь)

дальнейшее чтение

• Барлоу, Р. Э. и Проскан, Ф. (1981) Статистическая теория надежности и ресурсных испытаний, для начала с Press, Silver Springs, MD.
• Бланшар, Бенджамин С. (1992), Логистическая инженерия и менеджмент (Четвертое издание), Prentice-Hall, Inc., Энглвуд Клиффс, Нью-Джерси.
• Брейтлер, Алан Л. и Слоан, К. (2005), Труды конференции Air Force T&E (AIAA), Нэшвилл, Теннесси, декабрь 2005 г .: Прогнозирование надежности системы: к общему подходу с использованием Нейронная сеть.
• Эбелинг, Чарльз Э., (1997), Введение в технику надежности и ремонтопригодности, McGraw-Hill Companies, Inc., Бостон.
• Денни, Ричард (2005). Успешные варианты использования: умная работа для обеспечения качества. Аддисон-Уэсли Профессиональное Издательство. ISBN. Обсуждает использование инженерии надежности программного обеспечения в вариант использования управляемая разработка программного обеспечения.
• Гано, Дин Л. (2007), «Анализ первопричин Аполлона» (третье издание), Apollonian Publications, LLC., Ричленд, Вашингтон
• Холмс, Оливер Венделл, Старший Шедевр дьякона
• Капур, К.С., и Ламберсон, Л.Р. (1977), Надежность инженерного проектирования, John Wiley & Sons, Нью-Йорк.
• Kececioglu, Дмитрий, (1991) "Руководство по проектированию надежности", Prentice-Hall, Englewood Cliffs, Нью-Джерси
• Тревор Клец (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 (Международная серия исследований операций и управления), Нью-Йорк.
• Shooman, Мартин, (1987), Программная инженерия: проектирование, надежность и управление, МакГроу-Хилл, Нью-Йорк.
• Тобиас, Триндади, (1995), Прикладная надежность, Чепмен и Холл / 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.

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

• Номер аэрокосмического отчета: TOR-2007 (8583) -6889 Требования программы обеспечения надежности космических систем, Аэрокосмическая корпорация (10 июля 2007 г.)
• DoD 3235.1-H (3-е изд.) Тестирование и оценка надежности, доступности и ремонтопригодности системы (учебник), Министерство обороны США (март 1982 г.).
• НАСА GSFC 431-REF-000370 Процедура обеспечения полета: выполнение анализа характера и последствий отказа, Национальное управление по аэронавтике и исследованию космического пространства Центр космических полетов Годдарда (10 августа 1996 г.).
• IEEE 1332–1998 Программа стандартной надежности IEEE для разработки и производства электронных систем и оборудования, Институт инженеров по электротехнике и электронике (1998).
• JPL D-5703 Справочник по анализу надежности, Национальное управление по аэронавтике и исследованию космического пространства Лаборатория реактивного движения (Июль 1990 г.).
• MIL-STD-785B Программа обеспечения надежности систем и оборудования при разработке и производстве, Министерство обороны США (15 сентября 1980 г.). (* Устарело, заменено ANSI / GEIA-STD-0009-2008 под названием Стандарт программы надежности для проектирования, разработки и производства систем, 13 ноя 2008)
• MIL-HDBK-217F Прогнозирование надежности электронного оборудования, Министерство обороны США (2 декабря 1991 г.).
• MIL-HDBK-217F (примечание 1) Прогнозирование надежности электронного оборудования, Министерство обороны США (10 июля 1992 г.).
• MIL-HDBK-217F (примечание 2) Прогнозирование надежности электронного оборудования, Министерство обороны США (28 февраля 1995 г.).
• MIL-STD-690D Планы и процедуры выборочного контроля для частоты отказов, Министерство обороны США (10 июня 2005 г.).
• MIL-HDBK-338B Справочник по проектированию надежности электронных устройств, Министерство обороны США (1 октября 1998 г.).
• MIL-HDBK-2173 Требования к техническому обслуживанию, ориентированному на надежность (RCM), для самолетов ВМС, систем вооружения и вспомогательного оборудования, Министерство обороны США (30 января 1998 г.); (заменено НАВАИР 00-25-403 ).
• MIL-STD-1543B Требования программы обеспечения надежности космических средств и ракет-носителей, Министерство обороны США (25 октября 1988 г.).
• MIL-STD-1629A Процедуры проведения анализа последствий и критичности режима отказа, Министерство обороны США (24 ноября 1980 г.).
• MIL-HDBK-781A Методы, планы и условия испытаний на надежность для инженерных разработок, квалификации и производства, Министерство обороны США (1 апреля 1996 г.).
• NSWC-06 (Часть A и B) Справочник по процедурам прогнозирования надежности механического оборудования, Военно-морской центр надводной войны (10 января 2006 г.).
• СР-332 Процедура прогнозирования надежности электронного оборудования, Telcordia Technologies (Январь 2011 г.).
• ФД-АРПП-01 Автоматизированная процедура прогнозирования надежности, Telcordia Technologies (Январь 2011 г.).
• GR-357 Общие требования к обеспечению надежности компонентов, используемых в телекоммуникационном оборудовании, Telcordia Technologies (Март 2001 г.).

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: R&M в процессе эксплуатации
• ЧАСТЬ 7 (ARMP-7) Проблема 1: Терминология R&M НАТО применима к ARMP

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

• ЧАСТЬ 1: Выпуск 1: УСТРОЙСТВА / СИСТЕМЫ ONE-SHOT
• ЧАСТЬ 2: Проблема 1: ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
• ЧАСТЬ 3: Проблема 2: R&M CASE
• ЧАСТЬ 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: РУКОВОДСТВО ПО ТЕРМИНОЛОГИЧЕСКИМ ОПРЕДЕЛЕНИЯМ МОДУЛЯ НАДЕЖНОСТИ И ОБСЛУЖИВАНИЯ

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

Французские стандарты

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

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

• Стандарты TC 56: надежность

внешняя ссылка

• СМИ, связанные с Техника надежности в Wikimedia Commons