Введение

Поддисциплина системной инженерии, которая подчеркивает надежность.

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

История

Слово "надежность" можно проследить до 1816 года и впервые встречается в трудах поэта Сэмюэля Тейлора Колриджа. До Второй мировой войны этот термин в основном связывали с воспроизводимостью: тест (в любой области науки) считался "надежным", если при повторных испытаниях получались одинаковые результаты. В 1920-х годах доктор Уолтер А. Шеварт в лабораториях Bell продвигал улучшение продукции посредством статистического контроля процессов, примерно в то же время, когда Валодди Вейбулл работал над статистическими моделями усталости. Развитие инженерной надежности шло параллельно с развитием качества. Современное определение слова "надежность" было дано военными США в 1940-х годах, характеризуя продукт, который будет функционировать в ожидаемый срок и в течение заданного периода времени. Во время Второй мировой войны многие проблемы с надежностью были связаны с присущей ненадежностью доступного в то время электронного оборудования и с проблемами усталости. В 1945 году М. А. Майнер опубликовал основополагающую статью под названием "Кумулятивный ущерб при усталости" в журнале ASME. Основным применением инженерной надежности в военной сфере была вакуумная лампа, используемая в радиолокационных системах и другой электронике, надежность которой оказалась очень проблемной и дорогостоящей. В 1948 году IEEE создало Общество надежности. В 1950 году Министерство обороны США сформировало группу под названием "Консультативная группа по надежности электронного оборудования" (AGREE) для изучения методов повышения надежности военной техники. Эта группа рекомендовала три основных направления работы:

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

Обзор

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

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

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

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

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

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

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

Для любой системы одной из первых задач инженерии надежности является адекватное определение требований к надежности и ремонтопригодности, вытекающих из общих потребностей в работоспособности и, что более важно, из результатов анализа отказов при проектировании или предварительных испытаний прототипов. Четкие требования (которые можно учесть при проектировании) должны ограничивать разработчиков от создания заведомо ненадежных элементов, конструкций, интерфейсов или систем. Ограничиваться только установкой целевых показателей доступности, надежности, проверяемости или ремонтопригодности (например, максимальных интенсивностей отказов) недопустимо. Это распространенное заблуждение относительно инженерии требований к надежности. Требования к надежности относятся к самой системе, включая требования к испытаниям и оценке, а также связанные с ними задачи и документацию. Требования к надежности включаются в соответствующие спецификации требований к системе или подсистеме, планы испытаний и контрактные условия. Создание корректных требований нижнего уровня критически важно. Информация часто недоступна с высокой степенью неопределенности на этапе разработки, что делает задачу распределения требований практически невыполнимой в полезном, практичном и обоснованном виде, не приводящем к чрезмерной или недостаточной спецификации. Поэтому необходим прагматичный подход, например, использование общих уровней/классов количественных требований, зависящих только от серьезности последствий отказа. Кроме того, валидация результатов – задача гораздо более субъективная, чем любой другой тип требований. (Количественные) параметры надежности, выраженные в виде MTBF, являются наиболее неопределенными параметрами проектирования. Более того, требования к надежности при проектировании должны стимулировать включение в конструкцию (системы или ее части) функций, предотвращающих возникновение отказов или ограничивающих их последствия. Это не только поможет в прогнозировании, но и не отвлечет инженерные усилия на учетную работу. Требование к конструкции должно быть достаточно точным, чтобы разработчик мог "проектировать" в соответствии с ним и мог доказать – посредством анализа или испытаний – что требование выполнено, и, по возможности, с определенной степенью достоверности. Любое требование к надежности должно быть детализированным и может быть получено из анализа отказов (анализ напряжений и усталости методом конечных элементов, анализ рисков надежности, FTA, FMEA, анализ человеческого фактора, анализ функциональных рисков и т.д.) или любого типа испытаний на надежность. Также необходимы требования к верификационным испытаниям (например, требуемые перегрузки) и времени испытаний. Для эффективного определения этих требований следует использовать логику оценки и снижения рисков на основе системной инженерии. Необходимо создать надежные журналы учета рисков, содержащие подробную информацию о причинах и механизмах возможных или произошедших отказов. Требования должны разрабатываться и отслеживаться таким образом. Эти практические требования к конструкции должны определять конструкцию и не использоваться только для целей верификации. Эти требования (часто являющиеся конструктивными ограничениями) таким образом выводятся из анализа отказов или предварительных испытаний. Понимание этой разницы по сравнению с чисто количественной (логистической) спецификацией требований (например, целевой интенсивности отказов / MTBF) имеет первостепенное значение для разработки успешных (сложных) систем. Требования к ремонтопригодности учитывают стоимость ремонта, а также время ремонта. Требования к проверяемости (не путать с требованиями к испытаниям) обеспечивают связь между надежностью и ремонтопригодностью и должны охватывать обнаруживаемость режимов отказа (на определенном уровне системы), уровни изоляции и создание диагностических процедур. Кроме того, человеческие ошибки в управлении, организации данных и информации, а также неправильное использование или злоупотребление элементами также могут способствовать ненадежности. Это основная причина, по которой высокий уровень надежности для сложных систем может быть достигнут только путем следования надежному процессу системной инженерии с надлежащим планированием и выполнением задач валидации и верификации. Это также включает в себя тщательную организацию данных и обмена информацией, а также создание "культуры надежности", подобно тому, как "культура безопасности" имеет первостепенное значение при разработке систем, критичных к безопасности.

Конструкция для надежности

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

Подход, основанный на статистике (то есть МТБФ)

Проектирование надежности начинается с разработки (системной) модели. Модели надежности и доступности используют блок-схемы и анализ дерева отказов для графической оценки взаимосвязей между различными частями системы. Эти модели могут включать прогнозы, основанные на показателях отказов, полученных из исторических данных. Хотя прогнозы (входных данных) часто не отличаются абсолютной точностью, они полезны для оценки относительных различий между альтернативными вариантами проектирования. Параметры ремонтопригодности, например среднее время до восстановления (MTTR), также могут использоваться в качестве входных данных для таких моделей. Необходимо выявить и проанализировать с помощью инженерных инструментов наиболее важные фундаментальные причины и механизмы отказов. Разработчикам следует предоставить широкий спектр практических рекомендаций по производительности и надежности, чтобы они могли создавать малонагруженные конструкции и продукты, защищенные от повреждений и чрезмерного износа, или способные противостоять им. Помимо верификации надежности ("производительности") посредством испытаний, может потребоваться надлежащая валидация входных нагрузок (требований). Одной из важнейших техник проектирования является резервирование. Это означает, что в случае отказа одной части системы существует альтернативный путь к успеху, например, резервная система. Эта техника является оптимальным выбором, поскольку часто бывает сложно или очень дорого получить достоверные данные о высокой надежности для новых деталей или систем. Комбинируя резервирование с высоким уровнем мониторинга отказов и предотвращением общих причин отказов, даже система с относительно низкой надежностью отдельных каналов (деталей) может быть сделана высоконадежной на системном уровне (вплоть до критической надежности). Для этого не требуется проведение испытаний на надежность. В сочетании с резервированием использование различных конструкций или производственных процессов (например, за счет привлечения разных поставщиков аналогичных деталей) для отдельных независимых каналов может снизить чувствительность к проблемам качества (например, ранним отказам у одного поставщика), что позволит достичь очень высокого уровня надежности на всех этапах жизненного цикла разработки (от начала эксплуатации до длительного использования). Резервирование также может применяться в системной инженерии путем двойной проверки требований, данных, конструкций, расчетов, программного обеспечения и испытаний для устранения систематических ошибок. Еще один эффективный способ повышения надежности – это проведение анализа, прогнозирующего деградацию, что позволяет предотвратить незапланированные простои и отказы. Для этого можно использовать программы технического обслуживания, ориентированного на надежность (RCM).

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

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

Значение языка

Инженеры надежности, используя количественные или качественные методы для описания отказа или опасности, полагаются на язык, чтобы точно определить риски и обеспечить возможность решения проблем. Используемый язык должен способствовать созданию упорядоченного описания функции/элемента/системы и ее сложного окружения в контексте отказов этих функций/элементов/систем. Системная инженерия во многом заключается в подборе правильных слов для описания проблемы (и связанных с ней рисков), чтобы их можно было легко решить с помощью инженерных решений. Джек Ринг утверждал, что работа системного инженера – это "определять проект с помощью языка" (Ring et al. 2000). При анализе отказов деталей/систем инженеры надежности должны уделять больше внимания "почему и как", а не прогнозированию "когда". Понимание "почему" произошел отказ (например, из-за перегрузки компонентов или производственных дефектов) гораздо вероятнее приведет к улучшению конструкций и процессов. Для ускорения реакции продукта в условиях эксплуатации и проверки соответствия ожидаемому качеству на этапах НИОКР, проектирования и производства используется различное оборудование для проведения испытаний в условиях окружающей среды, имитирующее высокие и низкие температуры, высокую влажность и перепады температур. Проверка надежности, также называемая тестированием надежности, подразумевает использование моделирования, статистики и других методов для оценки надежности продукта на основе его срока службы и ожидаемых характеристик. Большинство продуктов на рынке требует проведения испытаний на надежность, например, автомобили, интегральные схемы, тяжелая техника для добычи полезных ископаемых, программное обеспечение для авиационной техники. Испытания надежности могут проводиться на различных уровнях и включать различные типы испытаний. Сложные системы могут тестироваться на уровне компонентов, печатных плат, блоков, сборок, подсистем и систем (номенклатура уровней испытаний может различаться в зависимости от области применения). Например, проведение испытаний на устойчивость к внешним воздействиям на более низких уровнях, таких как отдельные детали или небольшие сборки, позволяет выявить проблемы до того, как они приведут к отказам на более высоких уровнях. Испытания проводятся на каждом этапе интеграции, включая полномасштабные системные испытания, испытания разработки и эксплуатационные испытания, что снижает риски проекта. Однако тестирование не устраняет риск ненадежности. При каждом испытании возможны статистические ошибки первого и второго рода, в зависимости от размера выборки, времени испытания, предположений и необходимого коэффициента дискриминации. Существует риск ошибочного отклонения хорошей конструкции (ошибка первого рода) и риск ошибочного принятия плохой конструкции (ошибка второго рода). Не всегда возможно протестировать все системные требования. Некоторые системы слишком дороги для тестирования, некоторые виды отказов могут проявляться годами, сложные взаимодействия приводят к огромному количеству возможных тестовых сценариев, а для некоторых тестов требуются ограниченные испытательные стенды или другие ресурсы. В таких случаях могут использоваться различные подходы к тестированию, такие как (высоко)ускоренные испытания на срок службы, планирование экспериментов и моделирование. Желаемый уровень статистической достоверности также играет роль в испытаниях на надежность. Статистическая достоверность повышается за счет увеличения времени испытания или количества протестированных изделий. Планы испытаний на надежность разрабатываются для достижения заданной надежности с заданной достоверностью, используя минимальное количество тестовых образцов и минимальное время испытаний. Различные планы испытаний приводят к разному уровню риска для производителя и потребителя. Желаемая надежность, статистическая достоверность и уровни риска для каждой стороны влияют на окончательный план испытаний. Заказчик и разработчик должны заранее согласовать, как будут проверяться требования к надежности. Ключевым аспектом испытаний на надежность является определение понятия "отказ". Хотя это может показаться очевидным, во многих ситуациях неясно, действительно ли отказ является следствием неисправности системы. Изменения в условиях испытаний, различия в работе операторов, погодные условия и непредвиденные ситуации создают расхождения между заказчиком и разработчиком системы. Для решения этой проблемы можно использовать процедуру конференции по оценке результатов. Конференция по оценке результатов включает представителей заказчика, разработчика, организации, проводящей испытания, организации по надежности и, иногда, независимых наблюдателей. Процедура конференции по оценке результатов определяется в техническом задании. Каждое испытание рассматривается группой и оценивается как "успешное" или "неуспешное". Эта оценка является официальным результатом, используемым инженером по надежности. В рамках этапа определения требований инженер по надежности разрабатывает стратегию испытаний совместно с заказчиком. Стратегия испытаний представляет собой компромисс между потребностями организации по надежности, которая стремится получить как можно больше данных, и ограничениями, такими как стоимость, сроки и доступные ресурсы. Для каждого испытания на надежность разрабатываются планы и процедуры испытаний, а результаты документируются. Испытания на надежность широко распространены в фотонной промышленности. Примеры испытаний на надежность лазеров включают испытания на срок службы и выработку. Эти испытания заключаются в ускоренном старении группы лазеров в контролируемых условиях. Данные, полученные в ходе этих испытаний на срок службы, используются для прогнозирования ожидаемого срока службы лазеров в предполагаемых условиях эксплуатации.

Метод испытания

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

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

Надежность программного обеспечения является особым аспектом инженерной надежности. Она фокусируется на основах и методах повышения надежности программного обеспечения, то есть его устойчивости к сбоям. Надежность системы, по определению, включает все компоненты системы, включая аппаратное обеспечение, программное обеспечение, поддерживающую инфраструктуру (включая критически важные внешние интерфейсы), операторов и процедуры. Традиционно инженерная надежность сосредоточена на критически важных аппаратных компонентах системы. С момента широкого распространения цифровых интегральных схем программное обеспечение стало все более важной частью большинства электронных устройств и, следовательно, почти всех современных систем. Поэтому надежность программного обеспечения приобрела значимость в области надежности систем. Однако существуют существенные различия в поведении программного и аппаратного обеспечения. Большинство случаев ненадежности аппаратного обеспечения обусловлены выходом из строя компонента или материала, что приводит к невыполнению системой своих функций. Ремонт или замена аппаратного компонента восстанавливает систему в исходное рабочее состояние. Однако программное обеспечение не выходит из строя в том же смысле, что и аппаратное обеспечение. Ненадежность программного обеспечения является результатом непредвиденных результатов его работы. Даже относительно небольшие программы могут иметь астрономически большое количество комбинаций входных данных и состояний, которые невозможно полностью протестировать. Восстановление программного обеспечения в исходное состояние эффективно только до тех пор, пока та же комбинация входных данных и состояний не приведет к тому же нежелательному результату. Инженеры по надежности программного обеспечения должны это учитывать. Несмотря на эту разницу в источнике сбоев между программным и аппаратным обеспечением, было предложено несколько статистических моделей надежности программного обеспечения для количественной оценки наблюдаемых проблем: чем дольше работает программное обеспечение, тем выше вероятность, что оно будет использовано в неиспытанном режиме и проявит скрытый дефект, приводящий к сбою (Shooman 1987), (Musa 2005), (Denney 2005). Как и в случае с аппаратным обеспечением, надежность программного обеспечения зависит от четких требований, проектирования и реализации. Инженерия надежности программного обеспечения в значительной степени опирается на дисциплинированный процесс разработки программного обеспечения для прогнозирования и предотвращения непредвиденных последствий. Область инженерии качества программного обеспечения и инженерии надежности программного обеспечения имеет больше пересечений, чем область качества и надежности аппаратного обеспечения. Хороший план разработки программного обеспечения является ключевым аспектом программы надежности программного обеспечения. Этот план описывает стандарты проектирования и кодирования, взаимное рецензирование, модульное тестирование, управление конфигурацией, метрики и модели программного обеспечения, которые будут использоваться в процессе разработки. Распространенной метрикой надежности является количество дефектов программного обеспечения на строку кода (FLOC), обычно выражаемое как дефекты на тысячу строк кода. Эта метрика, наряду со временем выполнения программного обеспечения, является ключевой для большинства моделей и оценок надежности программного обеспечения. Предполагается, что надежность программного обеспечения увеличивается по мере уменьшения количества дефектов (или плотности дефектов). Однако установить прямую связь между плотностью дефектов и средним временем наработки на отказ (MTBF) сложно из-за распределения дефектов в коде, их серьезности и вероятности комбинации входных данных, необходимой для возникновения дефекта. Тем не менее, плотность дефектов служит полезным индикатором для инженера по надежности. Также используются другие метрики программного обеспечения, такие как сложность. Эта метрика остается предметом споров, поскольку изменения в практике разработки и верификации программного обеспечения могут существенно повлиять на общую частоту возникновения дефектов. Тестирование программного обеспечения является важным аспектом обеспечения его надежности. Даже лучший процесс разработки программного обеспечения приводит к появлению некоторых дефектов, которые практически невозможно обнаружить без тестирования. Программное обеспечение тестируется на нескольких уровнях, начиная с отдельных модулей, затем интеграционное и системное тестирование. На всех этапах тестирования обнаруживаются, исправляются и повторно тестируются дефекты. Оценки надежности обновляются на основе плотности дефектов и других метрик. На системном уровне можно собирать данные о среднем времени наработки на отказ и использовать их для оценки надежности. В отличие от аппаратного обеспечения, повторное выполнение одного и того же теста на одной и той же конфигурации программного обеспечения не повышает статистическую достоверность. Вместо этого, надежность программного обеспечения использует различные метрики, такие как покрытие кода. Модель зрелости возможностей Института программной инженерии является распространенным средством оценки общего процесса разработки программного обеспечения с точки зрения надежности и качества.

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

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

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

Надежность, касающаяся безопасности, и надежность, касающаяся доступности, часто тесно связаны. Потеря доступности инженерной системы может обернуться финансовыми потерями. Если система метро недоступна, оператор метрополитена теряет деньги за каждый час простоя. Оператор метрополитена понесет еще большие убытки, если будет скомпрометирована безопасность. Определение надежности связано с вероятностью безотказной работы. Отказ может привести к потере безопасности, потере доступности или и тому, и другому. Нежелательно допускать потерю безопасности или доступности в критически важных системах. Инженерия надежности направлена на общую минимизацию отказов, которые могут привести к финансовым потерям для ответственной организации, в то время как инженерия безопасности фокусируется на минимизации конкретных типов отказов, которые в целом могут привести к гибели людей, травмам или повреждению оборудования. Угрозы надежности могут перерасти в инциденты, приводящие к потере прибыли для компании или заказчика, например, из-за прямых и косвенных затрат, связанных с: потерей производства из-за недоступности системы; неожиданно высоким или низким потребностям в запасных частях; затратами на ремонт; трудозатратами; перепроектированием или перебоями в нормальном производстве. Инженерия безопасности часто носит узкоспециализированный характер, относясь только к определенным строго регулируемым отраслям, областям применения или сферам. Она в основном сосредоточена на опасностях для безопасности системы, которые могут привести к серьезным авариям, включая: гибель людей; уничтожение оборудования; или нанесение ущерба окружающей среде. Соответственно, связанные с этим требования к функциональной надежности системы часто чрезвычайно высоки. Хотя она имеет дело с нежелательными отказами в том же смысле, что и инженерия надежности, она, однако, уделяет меньше внимания прямым затратам и не рассматривает действия по ремонту после отказа. Другое различие заключается в масштабе воздействия отказов на общество, что приводит к тенденции к строгому контролю со стороны правительств или регулирующих органов (например, в ядерной, аэрокосмической, оборонной, железнодорожной и нефтяной промышленности). В повседневном обиходе термин «качество продукта» обычно понимается как его присущая степень совершенства. В промышленности используется более точное определение качества как «соответствие требованиям или спецификациям в начале эксплуатации». Если предположить, что окончательная спецификация продукта адекватно отражает первоначальные требования и потребности клиента/системы, уровень качества можно измерить как долю отгруженных единиц продукции, соответствующих спецификациям. Качество серийно выпускаемых товаров часто фокусируется на количестве гарантийных претензий в течение гарантийного периода. Качество – это снимок состояния в начале срока службы и в течение гарантийного периода, связанный с контролем спецификаций продукта более низкого уровня. Это включает в себя дефекты, обнаруженные сразу после производства, то есть ошибки, которые не были выявлены при окончательном контроле качества. Теоретически уровень качества можно описать одной долей дефектной продукции. Надежность, как часть системной инженерии, представляет собой скорее непрерывную оценку частоты отказов на протяжении многих лет. Теоретически, все изделия со временем выйдут из строя. Дефекты, проявляющиеся со временем, называются отказами надежности. Для описания отказов надежности необходима вероятностная модель, описывающая долю отказов во времени. Это называется моделью распределения времени наработки на отказ. Общество надежности IEEE, Американское общество качества (ASQ) и Общество инженеров по надежности (SRE).

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

FIDES Методология FIDES (UTE C 80 811) основана на физике разрушений и подкрепляется анализом данных испытаний, возвратов из поля и существующих моделей. UTE C 80–810 или RDF2000 Методология RDF2000 основана на опыте французской телекоммуникационной отрасли.