ГОСТ Р МЭК 62960-2022
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Надежность в технике
АНАЛИЗ НАДЕЖНОСТИ НА СТАДИЯХ ЖИЗНЕННОГО ЦИКЛА
Dependability in technics. Dependability reviews during the life cycle
ОКС 03.120.01
Дата введения 2023-01-01
Предисловие
1 ПОДГОТОВЛЕН Закрытым акционерным обществом "Научно-исследовательский центр контроля и диагностики технических систем" (ЗАО "НИЦ КД") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 119 "Надежность в технике"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 17 августа 2022 г. N 777-ст
4 Настоящий стандарт идентичен международному стандарту МЭК 62960:2020* "Анализ надежности на стадиях жизненного цикла" (IEC 62960:2020 "Dependability reviews during the life cycle", IDT).
Международный стандарт разработан Техническим комитетом ТК 56 Международной электротехнической комиссии (МЭК).
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА.
Дополнительные сноски в тексте стандарта, выделенные курсивом, приведены для пояснения текста оригинала
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
_______________
Выполнение анализа надежности на протяжении всего жизненного цикла объекта позволяет:
- выявлять и устранять недостатки объекта на ранних стадиях жизненного цикла, прежде чем они проявятся как проблемы надежности на более поздних стадиях;
- выявлять и работать с проблемами, которые могут возникнуть позже на стадиях жизненного цикла, и обеспечивать обратную связь для предотвращения повторения проблем, а также адаптировать объект к изменениям окружающей среды и других факторов;
- обеспечивать уверенность в достижении необходимой надежности объекта или процесса;
- обеспечивать постоянное повышение надежности объекта с целью поддержания или улучшения коммерческого преимущества.
Настоящий стандарт содержит руководство по анализу надежности, представляющего собой часть процессов анализа деятельности организации. В стандарте приведен согласованный набор принципов анализа надежности, который может быть полезен как дополнение к общему мониторингу и действиям по обеспечению заданной надежности при участии различных организаций на стадиях жизненного цикла.
Во многих случаях аспекты надежности выполнения задания рассматривают в других видах анализа, таких как анализ конструкции и анализ технологичности. В этих случаях могут быть применены процедуры, приведенные в настоящем стандарте. Справочные приложения могут быть использованы в качестве контрольных перечней для проверки всех технических аспектов.
Анализ надежности, описанный в настоящем стандарте, является ключевой частью системы менеджмента надежности (см. МЭК 60300-1).
1 Область применения
_______________
В стандарте приведены рекомендации для разработчиков, изготовителей, пользователей и сторонних независимых организаций, таких как консалтинговые организации.
В настоящем стандарте приведены методы анализа надежности, обеспечивающие:
_______________
- идентификацию заинтересованных сторон и определение их влияния на деятельность по анализу надежности;
- взаимосвязь между различными типами анализа;
- процедуры результативного анализа надежности;
- примеры действий анализа надежности.
2 Нормативные ссылки
В настоящем стандарте использована нормативная ссылка на следующий стандарт [для датированных стандартов применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения)]:
IEC 60050-192, International electrotechnical vocabulary - Part 192: Dependability (Международный электротехнический словарь. Часть 192. Надежность) (доступно по адресу //www.electropedia.org)
3 Термины, определения и сокращения
3.1 Термины и определения
В настоящем стандарте применены термины по МЭК 60050-192, а также следующие термины с соответствующими определениями:
ИСО и МЭК ведут терминологические базы данных для использования в области стандартизации по следующим адресам:
- платформа онлайн-просмотра ИСО: доступна по адресу //www.iso.org/obp;
- Электропедия МЭК: доступна по адресу //www.electropedia.org/.
3.1.1 менеджмент надежности (dependability management): Скоординированные действия по управлению и контролю работы организации в отношении надежности.
Примечание - Менеджмент надежности является частью общего менеджмента организации.
[МЭК 60300-1:2014, 3.1.4]
3.1.2 план (обеспечения) надежности (dependability plan): Набор запланированных действий, которые при их выполнении направлены на достижение целей и задач в области обеспечения надежности объекта.
[МЭК 60300-1:2014, 3.1.6, изменено - добавлено "которые при выполнении направлены"]
3.1.3 анализ надежности (dependability review): Анализ, направленный на исследование аспектов надежности (для объекта или процесса).
Примечание - Анализ надежности может быть самостоятельным анализом или частью анализа, охватывающего более широкие аспекты.
3.1.4 анализ проекта [объекта] (design review): Запланированный и документированный анализ существующих или предлагаемых конструкции или проекта объекта.
Примечание 1 - Цели анализа проекта включают оценку способности конструкции (проекта) выполнять установленные требования, выявление всех фактических или возможных недостатков, предложение улучшений.
Примечание 2 - Одного анализа проекта не достаточно для создания необходимой конструкции (проекта).
Примечание 3 - Проект может относиться к продукции или процессу.
Примечание 4 - Анализ проекта может быть выполнен с помощью обсуждения проекта на совещании или другого документированного процесса.
3.1.5 сравнительный анализ (gap analysis): Метод сопоставления достигнутых результатов с установленными требованиями для выявления их различий и разработки действий по улучшению.
3.1.6 объект (item): Предмет рассмотрения.
Примечание 1 - Объектом может быть отдельная часть, компонент, устройство, функциональная единица, оборудование, подсистема или система.
Примечание 2 - Объект может включать в себя аппаратные средства, программное обеспечение, персонал или их комбинацию.
Примечание 3 - Объект часто содержит элементы, каждый из которых может быть рассмотрен индивидуально.
[МЭК 60050-192:2015, 192-01-01, изменено примечание 3, примечания 4 и 5 удалены]
_______________
Пример - Типовая последовательность стадий жизненного цикла системы включает стадии: концепции и определения; проектирования и разработки; изготовления, монтажа и ввода в эксплуатацию; эксплуатации и технического обслуживания; модернизации в середине срока службы или продления срока службы; вывода из эксплуатации и распоряжения.
Примечание - В зависимости от особенностей применения стадии жизненного цикла могут быть изменены.
[МЭК 60050-192:2015, 192-01-09]
3.1.8 менеджмент (management): Скоординированная деятельность по управлению и контролю организацией.
Примечание 1 - Менеджмент может включать установление политики, целей и процессов для достижения этих целей.
Примечание 2 - Термин "менеджмент" иногда относят к людям, т.е. лицу или группе лиц, наделенных полномочиями и ответственностью для руководства и управления организацией. Когда термин "менеджмент" используется в этом смысле, его следует всегда применять с определяющими словами во избежание путаницы с понятием "менеджмент", как комплекс действий, определенный выше. Например, не следует использовать выражение "менеджмент должен ... ", в то же время выражение "высшее руководство должно ..." является допустимым. В иных случаях следует применять другие слова для того, чтобы отразить истинный смысл, если речь идет о людях, например "административный персонал" или "менеджеры".
[ИСО 9000:2015, 3.3.3]
3.1.9 проект (project): Уникальный процесс, состоящий из совокупности скоординированных и управляемых видов деятельности с начальной и конечной датами, предпринятых для достижения цели, соответствующей конкретным требованиям, включая ограничения по срокам, стоимости и ресурсам.
Примечание 1 - Проектная организация обычно является временной, создаваемой на срок выполнения проекта.
Примечание 2 - Сложность взаимодействий между различными видами проектной деятельности не обязательно связана с объемом проекта.
[ИСО 9000:2015, 3.4.2, изменено, примечания 1-3 удалены]
3.1.10 ключевая точка проекта (project milestone): Конкретный заранее определенный этап выполнения проекта, в котором ожидается достижение определенных результатов или в котором ожидается прогресс, характеризуемый измеримым показателем.
3.1.11 анализ выполнения проекта (project review): Анализ результатов выполнения проекта.
3.1.12 анализ (review): Деятельность, предпринятая для определения пригодности, адекватности и результативности объекта для достижения установленных целей.
[Руководство ИСО 73:2009, 3.8.2.2, изменено, примечание удалено]
_______________
Примечание - Это определение является более общим, чем приведенное в ISO/IEC/IEEE 15288:2015.
[МЭК 60300-1:2014, 3.1.5, изменено, добавлено примечание 1]
3.1.14 анализ состояния (status review): Анализ общего состояния выполнения проекта по отношению к установленным целям.
Примечание - Анализ состояния проекта включает техническую часть, когда собирают и структурируют информацию о состоянии, и часть управления, когда определяют состояние и принимают соответствующие решения.
3.1.15 система <в надежности> (system): Набор взаимосвязанных объектов, которые в совокупности обеспечивают выполнение установленного требования.
Примечание 1 - Предполагается, что система имеет определенную реальную или абстрактную границу.
Примечание 2 - Для работы системы могут требоваться внешние ресурсы (за пределами системы).
Примечание 3 - Система может иметь иерархическую структуру, например система, подсистема, компонент и т.д.
Примечание 4 - Условия использования и технического обслуживания должны быть указаны в требовании или вытекать из него.
[МЭК 60050-192:2015, 192-01-03]
3.1.16 команда (team): Два или более человек, работающих вместе, имеющих набор взаимодополняющих навыков, необходимых для выполнения задачи.
Примечание 1 - Назначенный руководитель команды является ее членом.
Примечание 2 - В команду могут входить лица, проходящие обучение.
3.1.17 анализ команды (team review): Анализ результатов работы команды.
Пример - Результаты анализа работы механиков, электронщиков или разработчиков программного обеспечения являются исходными данными технической части анализа состояния проекта.
3.1.18 технический анализ (technical review): Анализ технических аспектов процесса или продукции командой технически квалифицированного персонала, который проверяет пригодность продукции для использования по назначению и выявляет риски и несоответствия техническим требованиям и нормам (образцам).
Примечание - Цели, технические аспекты которых могут быть проанализированы, включают применение новой технологии, диверсификацию линейки продукции, принятие решений о покупке составных частей, сроки внедрения новой продукции и анализ пригодности/адекватности технической спецификации.
[ИСО/МЭК 20246:2017, 3.18, изменено - "документальный анализ" заменен на "анализ технических аспектов процесса", добавлены "риски" и заменено примечание 1]
3.2 Сокращения
В настоящем стандарте применены следующие сокращения:
COTS - покупная продукция;
FTA - анализ дерева неисправностей;
FMEA - анализ видов и последствий отказов;
MMH - продолжительность технического обслуживания (человеко-часы);
MTBF - средняя наработка между отказами;
MTTF - средняя наработка до первого отказа;
MTTR - среднее время восстановления;
PoF - физика отказа;
RTM - матрица прослеживаемости требований.
4 Анализ надежности
4.1 Общие положения
Действия по анализу надежности являются ключевыми мероприятиями плана надежности. Ответственные за анализ надежности отвечают за обеспечение выполнения анализа надежности в процессе всего жизненного цикла объекта.
Анализ включает изучение текущей ситуации для сопоставления ее с ожидаемой ситуацией или требованиями. В процессе анализа выявляют несоответствия, риски и возможные проблемы, исследуют их и разрабатывают рекомендации по улучшению.
Анализ надежности охватывает согласованный набор видов анализа различных аспектов надежности исследуемого объекта.
Такие виды анализа выполняют неоднократно на протяжении всего жизненного цикла объекта, постоянно разрабатывая рекомендации по последующим действиям и оценке их результативности.
Целями анализа надежности могут быть следующие:
- свойства надежности объекта, включая безотказность, ремонтопригодность, готовность, а также удобство обслуживания;
- другие характеристики объекта, такие как долговечность и восстанавливаемость;
- свойства, связанные с надежностью, такие как безопасность и защищенность;
- экономическая эффективность, включая стоимость жизненного цикла и краткосрочные затраты;
- мероприятия, проводимые для достижения или оценки результатов обеспечения надежности;
- результативность процессов обеспечения надежности;
- ответственность различных заинтересованных сторон, а также ответственность разработчика перед ними за возможные отказы;
- адаптация к изменениям требований, условий, целей и/или назначения системы.
Анализ надежности обеспечивает уверенность в том, что надежность, достигнутая в течение всего жизненного цикла, может быть либо подтверждена путем демонстрации соответствия требованиям, либо обеспечена путем выявления проблем и выполнения улучшений. Анализ надежности может быть использован для представления свидетельств того, что требования надежности выполнены, как часть свидетельств надежности. В МЭК 62741 [3] приведены рекомендации по области применения свидетельств надежности и установлены общие принципы их подготовки.
Систематическое проведение анализа надежности на стадиях жизненного цикла объекта позволяет корректировать усилия с меньшими затратами. Это особенно выгодно, учитывая современные тенденции по увеличению сложности объектов, сокращению времени их разработки и увеличению их срока службы.
Некоторые условия таких тенденций включают:
- повсеместное подключение к сети в любой области систем, управляемых другой стороной;
- частые изменения в условиях работы системы, такие как ожидания пользователей и конкуренция на рынке;
_______________
Анализ надежности помогает выявить, спрогнозировать и исправить проблемы по мере их возникновения в жизненном цикле системы, пока они достаточно малы и их можно устранить.
Существуют различные типы анализа надежности. Тип анализа надежности, выполняемого на стадии жизненного цикла, должен соответствовать этой стадии жизненного цикла. Это лучше всего регулирует и документирует план обеспечения надежности. Действия по выполнению анализа надежности в процессе жизненного цикла описаны в разделе 5.
Анализ может быть внутренним, когда в группу анализа входят специалисты, тесно связанные с объектом исследования, или внешним, когда в группу анализа входят только независимые специалисты. В этом случае команда специалистов, работа которых является объектом анализа, предоставляет внешней группе, выполняющей анализ, необходимые свидетельства.
Такие проблемы менеджмента, как подотчетность и изменения в бизнес-целях, оказывают влияние на надежность выполнения объектом задания. Поэтому такие проблемы могут быть частью анализа надежности. В этом случае к анализу кроме технических экспертов могут быть привлечены менеджеры других направлений.
Существует два типа анализа надежности: технический анализ и анализ со стороны руководства. Принципы, приведенные в настоящем стандарте, могут быть в равной степени применены к обоим видам анализа. В настоящем стандарте, однако, основное внимание уделено техническому анализу. Часть анализа, относящаяся к управлению, при анализе состояния не рассмотрена. Как технический анализ, так и анализ со стороны руководства на каждой стадии жизненного цикла, часто является неотъемлемой частью других видов анализа, а не самостоятельной деятельностью. В 4.2 и 4.3 описаны технический анализ и анализ состояния.
4.2 Технический анализ
При выполнении технического анализа выявляют и исследуют потенциальные проблемы и возможности, а также разрабатывают рекомендации по улучшению. Этот тип анализа обеспечивает уверенность в том, что процессы работают результативно и установленные требования выполнены.
Технический анализ может включать анализ проекта, анализ эксплуатации, анализ технического обслуживания, анализ риска и анализ других технических аспектов объекта или процесса. Анализ может быть сосредоточен на надежности или анализ надежности может быть частью более обширного анализа.
Технический анализ надежности может включать:
- анализ достигнутой или прогнозируемой надежности объекта, целью которого является повышение надежности объекта на основе оценки показателей надежности и изучения возможностей для улучшения;
- анализ процессов и мероприятий, запланированных для достижения установленной надежности с целью анализа недостатков и улучшения будущих процессов и действий.
Участники технического анализа должны обладать техническими знаниями о рассматриваемом объекте, его безотказности, техническом обслуживании и сопровождении.
Группа, выполняющая технический анализ, должна включать экспертов, которые не зависят от группы проектирования и обладают необходимыми навыками для анализа отказов объекта или процесса. Участие таких экспертов наиболее важно для обеспечения независимости и качества анализа. В эту группу могут входить, например, специалисты по качеству, безотказности, эргономике, анализу и проверке безопасности.
Руководство, как правило, не участвует в техническом анализе. Потребитель или пользователь системы или процесса могут участвовать в техническом анализе.
Для каждого технического анализа должен быть назначен председатель совещания (фасилитатор), который может назначить секретаря для оказания ему помощи в проведении анализа.
4.3 Анализ состояния
Целью анализа состояния является представление руководителям организации, а иногда и заказчику, информации о том, как продвигается проект, и в некоторых случаях обоснования для продолжения проекта с переходом на следующий этап плана проекта. В некоторых случаях анализ состояния проводят на ключевых этапах проекта, его называют "анализом ключевых этапов". В некоторых случаях анализ на ключевом этапе также включают в решение о продолжении проекта, такой анализ иногда называют "вентильным анализом". В некоторых случаях оплата этапа зависит от результата анализа состояния.
Анализ состояния надежности начинается с этапа, на котором собирают и структурируют информацию и свидетельства надежности. Структурированную информацию затем представляют руководству для анализа и принятия решений.
В команду по анализу состояния должны входить специалисты, обладающие полномочиями по выделению ресурсов на выполнение проекта и устранение возникающих трудностей. Участниками технической части анализа состояния, как правило, являются председатель, секретарь, руководители проекта и руководители различных групп проекта. Как только достигнут консенсус относительно состояния технических проблем, анализ состояния может перейти к этапу управления, в котором обычно участвуют руководитель программы, руководство и, возможно, заказчик. Следует позаботиться о том, чтобы серьезные проблемы, отмеченные руководителями групп при анализе проекта, не были представлены в качестве задач для следующего этапа проекта без сообщения об их возможном воздействии, если они останутся нерешенными.
4.4 Обзор методов анализа надежности
4.4.1 Анализ
Анализ надежности может быть выполнен самостоятельно или как часть другого анализа. В любом случае анализ надежности должен включать следующие этапы:
- определение заинтересованных сторон;
- определение требований;
- сбор информации о фактических показателях;
- оценку различий между установленными требованиями и фактическими показателями;
- идентификацию рисков и проблемных областей;
- разработку рекомендуемых действий.
При введении изменений, их результативность должна быть проверена, и должно быть сделано обоснование необходимости каких-либо дополнительных действий.
4.4.2 Определение заинтересованных сторон
Лицам или организациям, разрабатывающим и эксплуатирующим системы, важно хорошо понимать, кто является их заинтересованными сторонами, поскольку их работа направлена на удовлетворение потребностей этих заинтересованных сторон. Поэтому необходимо идентифицировать заинтересованные стороны и установить способы обмена информацией с ними. Для некоторых систем можно легко идентифицировать заинтересованные стороны, и они не изменяются в течение жизненного цикла системы. Для других систем с самого начала может быть трудно идентифицировать заинтересованные стороны и полностью определить их потребности. Например, заинтересованные стороны могут измениться, когда система вступает в стадию использования или когда разработанный объект продан другому лицу или организации. Они также могут измениться, когда система вступает в стадию вывода из эксплуатации.
При определении соответствующих заинтересованных сторон следует учитывать следующее:
a) к заинтересованным сторонам относятся те, на кого может повлиять система или отказ системы, например, в результате неправомерного раскрытия информации или неисправности, вызванного ошибкой человека или неправильным использованием;
b) некоторые требования заинтересованных сторон, которые, например, могут привести к отказам и задержке поставки, могут быть известны в процессе разработки и должны быть определены и рассмотрены при выполнении анализа;
c) как только соответствующие заинтересованные стороны определены, из этого перечня должны быть выделены ключевые заинтересованные стороны. При определении ключевых заинтересованных сторон следует применять подход, основанный на оценке рисков. Критерии для идентификации ключевых заинтересованных сторон зависят от выявленных критериев успеха системы, а также степени важности и влияния каждой заинтересованной стороны;
d) перечень заинтересованных сторон может измениться на стадии использования системы или вывода ее из эксплуатации. Например:
1) Разработанный объект может быть продан другому лицу или другой организации, предполагаемой на стадиях разработки или изготовления.
2) Разработанный объект может быть использован различными лицами или одним и тем же лицом организации.
4.4.3 Определение требований
Для достижения целей в области надежности и обеспечения надежности, ожидаемой заинтересованными сторонами, целесообразно указать достижимую цель с измеримыми показателями и направлениями действий в процессе жизненного цикла. Это становится требованиями, на соответствие которым проводят анализ. Цель может относиться к функциям системы и ее предпочтительным параметрам. Стороны или организации, заинтересованные в надежности системы, могут иметь разные программы и могут изменяться в процессе всего жизненного цикла. Поэтому может возникнуть необходимость пересмотра целей и задач на каждой стадии жизненного цикла. Затем разрабатывают и выполняют новые планы на поэтапной основе для достижения целей в области надежности. Относительный уровень значимости заинтересованных сторон для предполагаемого успеха проекта может изменяться. Это может повлиять на содержание планов и оценку значимости заинтересованных сторон.
Цель в области надежности следует уточнять с учетом деталей спецификации системы и плана выполнения проекта. Цель может учитывать технические возможности, риски, достаточность каждой стадии жизненного цикла и соответствующие требования, вытекающие из результатов исследования рынка.
4.4.4 Сбор информации о фактических показателях
Необходимо собрать достаточное количество свидетельств того, что фактически происходит или существует, чтобы сделать достоверные выводы в результате анализа. Свидетельства включают информацию по сопоставлению полученных результатов с каждым требованием и целью, которые входят в область применения анализа. Свидетельством могут быть расчеты, результаты испытаний, моделирования или другого анализа. Следует выяснить все проблемы, вызывающие озабоченность, которые могут повлиять на риски. В приложении A приведены сведения об информации, которую необходимо собрать. Это позволяет минимизировать неопределенность результатов анализа.
Если свидетельств недостаточно, они являются неполными или недостаточно достоверными, или понимание и анализ свидетельств являются неполными, результаты анализа следует считать недостоверными или неполными. В этом случае следует предпринять действия для увеличения количества и качества свидетельств или для улучшения их понимания.
Данные, собранные как свидетельства надежности, могут быть использованы в качестве исходных данных при анализе надежности. Аналогично свидетельства, полученные в процессе анализа надежности, могут быть частью свидетельств надежности.
В МЭК 62741 [3] приведено руководство по содержанию и применению свидетельств надежности и установлены общие принципы их подготовки. МЭК 62741 [3] распространяется на ситуацию, когда потребитель/заказчик заказывает у поставщика систему, отвечающую требованиям надежности, а затем управляет системой до вывода ее из эксплуатации. Методы, представленные в этом документе, могут быть изменены и адаптированы к другим ситуациям, при необходимости. Информацию обычно определяют и формируют совместно с заказчиком и поставщиком, но также может быть использована и обновленная информация других организаций. Например, органы по сертификации и регулирующие органы могут изучить представленные свидетельства для обоснования своих решений, а пользователи системы могут обновить/расширить свидетельства надежности, особенно в случаях, когда они используют систему для другой цели.
4.4.5 Оценка различий требований и фактических показателей
Следует идентифицировать несоответствие фактических результатов ожидаемым или требуемым значениям, оценить значимость всех отклонений, определить возможные корректирующие действия и принять решение о необходимости корректирующих действий.
Эти действия могут включать анализ причин отклонений. Могут быть использованы такие методы, как анализ первопричин, описанный в МЭК 62740 [7].
4.4.6 Идентификация рисков и проблемных областей
При выполнении анализа могут быть также идентифицированы области, связанные с возможными проблемами в будущем, проанализированы ранее выявленные риски и оценены новые риски. Можно использовать методы, описанные в МЭК 31010 [13].
Кроме того, риски, связанные с надежностью, могут быть выявлены при оценке рисков, проводимой на каждой стадии жизненного цикла для целей и задач, отличных от целей и задач анализа надежности. В равной степени результаты анализа рисков содержат информацию об обработке рисков, связанных с надежностью. Эта информация должна быть включена в соответствующий анализ надежности.
4.4.7 Рекомендуемые действия
В зависимости от области определения и целей результатами анализа могут быть:
- подтверждение того, что требования выполнены;
- одобрение перехода к следующему этапу проекта;
- рекомендации по улучшению;
- действия по работе с проблемами и рисками.
В тех случаях, когда команда дает рекомендации по изменениям, связанным с областью определения анализа, эти рекомендации также необходимо выполнять при изготовлении. В некоторых случаях команда определяет в качестве альтернативного решения рассмотрение проблем третьей стороной с ответственностью за выполнение действий и с проверкой результатов, выполняемой людьми, не входящими в команду анализа.
Рекомендации следует проверить, чтобы убедиться, что они не создают дополнительных проблем.
4.5 Планирование и сроки проведения анализа надежности
Проведение анализа надежности способствует постоянному повышению надежности системы в рамках цикла "План - Осуществление - Проверка - Действие", описанного в ИСО/МЭК 27000 [19]. Например, может возникнуть необходимость в постоянном повышении надежности объекта или непрерывном совершенствовании средств контроля безопасности для поддержания существующего уровня безопасности. Процесс "План - Осуществление - Проверка - Действие" может быть применен на одной стадии жизненного цикла или на нескольких стадиях жизненного цикла.
Анализ надежности выполняют на каждой стадии жизненного цикла, особенно при переходе с одной стадии на другую или при передаче ответственности за проект. Критической точкой планирования сроков анализа состояния является стадия концепции и определения. Обычно это делают при поддержке заявки на разрешение продолжения проекта или для представления предложения потребителю. В качестве исходных данных при принятии решений о выполнении анализа надежности на более поздних стадиях жизненного цикла используют риски, которые должны быть идентифицированы и оценены.
В идеале технический анализ необходимо проводить до принятия дорогостоящего, трудоемкого или трудного для отмены решения. Оно должно учитывать идентифицированные риски конструкции и/или проекта. Таким образом, все изменения, возникающие в результате анализа надежности, могут быть сделаны с наименьшим влиянием на график или стоимость выполнения проекта. Кроме того, улучшение стоимости, графика и показателей может быть принято более легко, если анализ выполнен до принятия значимых обязательств, например, в основных точках процесса проектирования.
Другие ключевые вопросы анализа надежности включают следующее.
- обнаружение отказов
Непредвиденные отказы могут указывать на изменение условий работы системы или необходимость изменения сделанных ранее предположений. Анализ надежности должен выявлять изменения, вызывающие отказы, и формулировать возможные варианты действий. После отказов анализ надежности должен оценивать адекватность действий по устранению отказов и необходимость предотвращения повторения отказов;
- изменение требований рынка
Быстрые технологические изменения, такие как изменения в области программного обеспечения и информационных технологий, могут не только создать новые рынки, но и ввести новые ранее не предполагаемые требования, например рыночные требования к мобильному телефону могут заключаться не в голосовой связи, а в вычислительных возможностях. Изменение требований рынка по любой причине приводит к дополнительным требованиям к надежности, таким как повышение безопасности, или новым требованиям к сопровождению объекта. Выполнение анализа надежности в процессе жизненного цикла может уточнить новые требования к надежности и, следовательно, позволяет управлять изменениями требований рынка. Анализ надежности, основанный на тенденциях рынка и удовлетворенности потребителей, может быть проведен как в маркетинговых целях, так и в целях обеспечения надежности;
- конкурентные требования к системе
Поскольку конкуренты могут выпускать системы с аналогичными или альтернативными требованиями, может быть трудно поддерживать конкурентоспособность системы в процессе всего жизненного цикла при сохранении требований к системе и показателям ее надежности. Поэтому для достижения целей в процессе жизненного цикла может потребоваться анализ спецификаций. Такой анализ может привести к улучшению системы, обновлению или пересмотру стратегий;
- технические инновации
Технические инновации могут предъявлять требования к системе для повышения ее надежности. Это может создать возможность изготовления новой продукции или применения новых методов, повышающих надежность существующей продукции. Спрос на быстрый ввод на рынок новой инновационной продукции требует обеспечения надежности. Анализ надежности имеет важное значение для уверенности в том, что изменение надежности обеспечивает надежность новой продукции;
- требования общества к надежности
Деятельность по обеспечению надежности в процессе жизненного цикла, включая планирование надежности, анализ конструкции, повышение надежности, техническое обслуживание, управление устареванием и утилизацию современных систем, являются объектами общественного давления. Анализ надежности может включать постоянное исследование требований общества и того, как эти требования изменяются. Требования общества к надежности систем могут быть не одинаковыми, поскольку требования заинтересованных сторон к системе различаются в зависимости от типа системы. Кроме того, могут иметь важное значение различные свойства и особенности системы, такие как безотказность, ремонтопригодность, готовность, безопасность и защищенность. При необходимости может быть разработан контрольный перечень требований общества, учитываемый в плане надежности и мероприятиях по анализу надежности.
Анализ надежности необходимо проводить как для устранения выявленных проблем, вызванных этими изменениями, так и для выявления возможных будущих проблем (рисков).
Поскольку эти изменения происходят на протяжении всего жизненного цикла системы, необходимо особое внимание уделять подотчетности. Эти проблемы решает не только анализ, выполняемый при появлении изменений, но и организация проведения анализа надежности в процессе всего жизненного цикла системы. Это может потребовать внесения изменений в план обеспечения надежности.
Объем и сложность системы влияют на особенности, сроки и количество проведений анализа. Особенностями системы могут быть следующие:
- система имеет простую конструкцию или незначительное обновление;
- система включает несколько систем;
- система является сложной.
К совещаниям по анализу надежности не относятся совещания по вопросам текущего планирования, разработки и обслуживания системы.
4.6 Уровни анализа надежности
4.6.1 Анализ
Виды анализа надежности могут быть классифицированы в соответствии с уровнем анализа, который определяют участники, и их уровнем вовлеченности в повседневные цели анализа. Такой анализ проводят на всех стадиях жизненного цикла, он может быть выполнен для анализа команды, проекта и состояния. Его выполняют в соответствии с иерархией, при этом анализ команды входит в анализ проекта, который входит в анализ состояния.
На рисунке 1 показана взаимосвязь между анализом команды, анализом проекта и анализом состояния на стадиях жизненного цикла.
|
 |
Рисунок 1 - Последовательность выполнения анализа на стадии жизненного цикла
4.6.2 Анализ команды
Цель анализа команды состоит в проведении технического анализа результатов работы команды, он сосредоточен на функциях команды, например, в области электроники, механики или программного обеспечения.
Участниками анализа команды являются руководитель команды и, по крайней мере, один член команды. Руководитель команды выполняет функции председателя при проведении анализа. Руководитель команды может не назначать секретаря. Руководитель команды использует информацию о достижениях и информацию сравнительного анализа для определения того, что необходимо сделать команде, разрабатывает перечень задач для выбора подходящих специалистов и предполагаемый график выполнения работ. Затем члены команды анализируют перечень задач и пытаются предвидеть все возможные проблемы и сроки выполнения задач. Члены команды могут оказывать взаимную помощь при необходимости.
Содержание анализа команды может быть частью анализа проекта, а выводы анализа команды могут быть использованы при выполнении анализа проекта.
4.6.3 Анализ проекта
Анализ проекта представляет собой проверку технического состояния отдельного проекта в рамках общей программы и включает в себя в качестве исходной информации результаты анализа команды. Проект может быть любого объема, а анализ проекта может быть проведен в любое время в процессе жизненного цикла. Анализ проекта может быть большим, как это обычно бывает на стадии разработки, или небольшим, например на стадии использования при выполнении анализа надежности объекта. Анализ проекта используют для оценки того, что достигнуто по сравнению с планом проекта. Следует анализировать сроки и отслеживать ключевые результаты прогресса, используя надлежащие способы и методы управления проектом. Участниками анализа проекта являются руководитель проекта и участники выполнения проекта. Руководитель проекта возглавляет анализ проекта. Руководитель проекта может отказаться от назначения секретаря. Анализ проекта может быть неофициальным, выполняемым руководителем или куратором проекта, или официальным с участием специалиста, защищающего проект, или спонсора проекта. Однако в любом случае руководителю или куратору проекта необходимо провести анализ, чтобы гарантировать требуемые результаты. Каждое лицо, участвующее в проекте, должно внести свой вклад в соответствии с его влиянием на потребности и результаты проекта для обеспечения успешного проведения анализа проекта. Заключение по результатам анализа проекта может затем стать исходной технической информацией для анализа состояния.
4.6.4 Анализ состояния
Анализ состояния рассматривает общее состояние проекта. Целью, как правило, является информирование руководства о продвижении проекта и, в некоторых случаях, анализ технических рисков и решение о продолжении проекта и переходе на следующую стадию в соответствии с планом проекта. Однако существует возможность того, что проект может быть изменен или даже остановлен после анализа состояния.
Анализ состояния включает два этапа: технический этап, на котором рассматривают техническое состояние проекта, и этап управления, на котором группа управления оценивает техническое состояние и принимает решения, касающиеся затрат, графика, рисков, возможностей и выполнения проекта. В настоящем стандарте рассмотрена только техническая часть анализа состояния.
Входные данные анализа состояния включают результаты всех предыдущих видов анализа, включая все рекомендации, корректирующие действия и обновленную информацию об их выполнении. Состояние всех возможных проблем должно быть установлено с указанием графика и ответственного лица за каждую проблему, которая не решена или иным образом закрыта.
В тех случаях, когда в ходе анализа проекта выявлены проблемы, на техническом этапе анализа состояния следует рассмотреть запланированные и реализованные решения и запланированные действия, а также оставшиеся технологические риски проекта. В идеале техническая часть анализа состояния не идентифицирует проблемы, которые ранее не были выявлены и проанализированы. В тех случаях, когда выявленная проблема еще не проанализирована, следует представить план анализа с указанием ответственного и сроков представления результатов вместе с оценкой возможного воздействия на проект.
Анализ состояния также может включать:
- анализ влияния на план обеспечения надежности и его соответствующее обновление;
- проверку, если в результате действия необходим анализ всего плана;
- санкционирование/получение ресурсов и внедрение изменений.
5 Действия по анализу надежности в процессе жизненного цикла
5.1 Общие положения
Особенности жизненного цикла зависят от свойств, назначения, использования и преобладающих условий применения системы.
Жизненный цикл системы в общем случае включает следующие стадии:
- концепция и определения (далее - концепция);
- проектирование и разработка (далее - разработка);
- изготовление или производство (далее - изготовление);
- использование или эксплуатация (далее - использование);
- улучшение;
_______________
Анализ надежности обычно проводят на каждой стадии, и часто его необходимо повторять в течение одной стадии в зависимости от результатов предыдущего анализа.
Результаты анализа влияют на принятие решений о необходимости продолжения этого цикла действий или выхода из него. При продолжении цикла действий результаты анализа используют при выполнении действий стадии, формируют скорректированный результат и повторно выполняют анализ с учетом результатов предыдущего анализа. При переходе на следующую стадию результаты анализа используют при разработке следующего цикла, который может относиться к следующей стадии жизненного цикла.
Некоторые виды анализа надежности выполняют в более открытых условиях с целью получения результатов анализа, улучшающих будущую деятельность и продукцию организации. Результаты анализа на стадии вывода из эксплуатации, часто содержащие полезные сведения о системе, регистрируют как знания организации, используемые при управлении портфелем проектов, и, при необходимости, направляют на стадию концепции нового объекта.
Тип проводимого анализа надежности должен соответствовать стадии жизненного цикла. Это требование можно легко выполнить с помощью плана обеспечения надежности. Если проблема обнаружена в процессе анализа на любой стадии, важно на той же стадии изучить первопричину проблемы, внести улучшения и подтвердить результат с помощью технического анализа. Результаты анализов, проведенных на одной стадии жизненного цикла, необходимо в соответствующих случаях передавать на следующую стадию.
Менеджер должен учитывать условия и ограничения, налагаемые конкретной стадией жизненного цикла, при планировании этапов анализа надежности следует определить оптимальное количество анализов для компенсации затраченного времени и усилий. Как правило, для нескольких организаций или проектов необходимо выполнять все виды анализа надежности на всех стадиях жизненного цикла.
В 5.2-5.7 описаны цели каждой стадии жизненного цикла и видов анализа надежности, которые могут быть проведены на этой стадии, а также конкретные проблемы, которые могут возникнуть. Примеры целей анализа для каждой стадии жизненного цикла приведены в приложении В. В приложении С приведен общий перечень вопросов, рассматриваемых при анализе, которые могут быть использованы при выполнении видов анализа надежности с различных точек зрения в процессе жизненного цикла.
5.2 Стадия концепции
Стадия концепции является начальной стадией жизненного цикла объекта, на ней определяют требования к объекту, его технические параметры и ограничения его использования. Идеи генерируют и преобразуют в технически и экономически осуществимые концепции. Предпочтительный вариант выбирают с учетом возможных компромиссов и рисков. Выходом этой стадии является начальный концептуальный проект выбранного варианта и предварительный план проекта, включая план надежности.
Деятельность по анализу надежности на стадии концепции включает:
- проверку концепции проекта на соответствие потребностям, ожиданиям и ограничениям потребителей;
- анализ целесообразности выполнения предлагаемого проекта;
- анализ осуществимости плана проекта;
- совершенствование концепции там, где это необходимо;
- принятие решения о выделении ресурсов на разработку в целом.
Анализ должен включать широкие ожидания в отношении надежности и их влияние на конструкцию, эксплуатацию и техническое обслуживание объекта. В частности, в конце стадии разработки концепции следует выполнить анализ состояния, чтобы убедиться, что концепция на стадии разработки соответствует потребностям, ожиданиям и ограничениям потребителей. Риски, включая риск несоответствия требованиям, выявляют и анализируют на каждой последующей стадии.
Результаты этой стадии должны быть рассмотрены позднее в процессе жизненного цикла, когда станет доступна дополнительная информация.
5.3 Стадия разработки
5.3.1 Анализ
Стадия разработки следует за стадией концепции после проверки осуществимости концепции.
Анализ направлен на планирование и выполнение выбранных инженерных конструкторских решений. Затем проводят детальное инженерное проектирование выбранных решений.
На этапе детального проектирования уточняют свойства всех компонентов, составляют чертежи и другую документацию, такую как инструкции по эксплуатации и изготовлению объекта. Определяют потребности в техническом обслуживании и материально-технической поддержке.
Риски, связанные с выбранной конструкцией, оценивают более подробно и уточняют методы обработки риска. На этой стадии могут быть использованы соответствующие методы моделирования и вероятностные подходы прогнозирования надежности. При необходимости проводят испытания опытных образцов.
5.3.2 Анализ конструкции
Анализ конструкции является примером технического анализа, в процессе которого выполняют верификацию объекта или системы на соответствие требованиям к конструкции, а также предпринимают действия по совершенствованию конструкции.
Как правило, на стадиях концепции и разработки несколько раз выполняют анализ в форме документального анализа конструкции. Анализ конструкции направлен на оценку соответствия конструкции исходным требованиям, идентификацию рисков и возможностей по улучшению, он помогает руководителю проекта разработать соответствующие действия. Это способствует достижению зрелости продукции за счет сокращения времени, необходимого для окончательного установления деталей конструкции, и позволяет осуществлять изготовление продукции без частых прерываний. Анализ конструкции также может стимулировать улучшение продукции на ранних стадиях ее жизненного цикла.
Правильное изготовление и анализ конструкции повышают возможность поставки продукции с требуемой надежностью, качеством, производительностью и безопасностью, с возможностью сокращения затрат и сроков поставки.
Возможность достижения требуемой надежности может зависеть от подхода, применяемого при проектировании объекта. К особенностям подхода относятся следующие:
- конструкция представляет собой индивидуальный проект, основанный на выборе из ряда проверенных компонентов и материалов;
- конструкция предполагает использование неотработанных компонентов, материалов или субподрядчиков;
- конструкция является интерполяцией существующего опыта;
- конструкция является экстраполяцией существующего опыта;
- конструкция является новой или использует неотработанную технологию.
Если проект предусматривает создание опытного образца, анализ результатов его испытаний может иметь решающее значение при принятии решения о действиях, необходимых для обеспечения безотказности окончательной конструкции. В крайних случаях это может даже привести при анализе состояния к решению об отказе от выполнения проекта.
Анализ конструкции проводят при наличии проекта конструкции или процесса как можно раньше, чтобы можно было внести изменения. Затраты на устранение недостатков в конструкции и потенциальные последствия возрастают по мере приближения проекта к завершению. По мере приближения завершения разработки конструкции возможность внесения изменений, устранения недостатков и оптимизации конструкции снижается.
Целью анализа конструкции может быть:
- оценка соответствия предлагаемого решения входным требованиям к конструкции, которые могут включать (перечень может быть дополнен): определенные общие требования к функционированию объекта, его надежности, стоимости жизненного цикла, безопасности, прочности, окружающей среде, электромагнитной совместимости и человеческому фактору;
- оценка того, является ли предлагаемое решение наиболее надежным, эффективным и действенным для удовлетворения требований к объекту;
- разработка рекомендаций, необходимых для выполнения требований к входным данным проектирования;
- оценка состояния продукции с точки зрения полноты чертежей и спецификаций;
- оценка фактических данных для обеспечения верификации выполнения проекта;
- оценка состояния применения компонентов для проверки условий эксплуатации компонентов и покупной продукции на соответствие ведомости данных и результатам испытаний, а также специальным требованиям, предъявляемым к процессам использования, обработки и сборки;
- предполагаемые улучшения;
- оценка возможной безопасной и экономичной утилизации объекта и его элементов;
- проверка использования компонентов в соответствии с их указанными характеристиками.
Анализ конструкции необходимо проводить следующим образом:
- до принятия заказа на проектирование следует убедиться, что определены область применения, а также параметры, которым должна соответствовать конструкция;
_______________
- в соответствующие моменты детального проектирования необходимо проанализировать все интерфейсы и согласовать процедуры испытаний для верификации соответствия проекта требованиям контракта и заинтересованных сторон непосредственно перед передачей на стадию изготовления.
Совещания по анализу надежности не зависят от совещаний по обсуждению текущего планирования, разработки и обслуживания системы.
Следует учесть, что анализ конструкции не должен определять окончательный вариант конструкции и разработку системы. Многие решения могут повлиять на надежность системы или процесса, исследуемых при анализе. Если каждое решение является объектом независимого анализа, команда анализа становится группой проектирования или разработки, это увеличивает время и повышает затраты на разработку. И наоборот, если первый анализ надежности выполнен непосредственно перед изготовлением или использованием, польза от него весьма сомнительна, поскольку остается мало возможностей изменить ситуацию без значительных временных и/или финансовых затрат.
Анализ конструкции может быть внутренним или внешним. Для внешнего анализа создают независимую команду анализа, которая получает необходимую информацию от ответственного за проектирование. Типичный состав внешней команды анализа приведен в 6.3.
5.4 Стадия изготовления
На стадии изготовления реализуют решения о приобретении и/или изготовлении объекта и его компонентов. Изготовление включает моделирование, анализ и испытания компонентов и модулей (включая испытания при интеграции объекта) с последующей установкой объекта. Перед вводом в эксплуатацию могут быть проведены испытания на фактическом производстве и/или в условиях эксплуатации.
Анализ может включать сопоставление фактических условий эксплуатации, характеристик пользователей и предположений, принятых при проектировании для выявления возможных проблем. Достигнутые показатели надежности анализируют на соответствие спецификациям для получения объективных свидетельств соответствия. Планы эксплуатации, такие как планы технического обслуживания, разработанные на стадии проектирования, анализируют для проверки выполнения их соответствия замыслу проекта.
Виды анализа, в которых может быть рассмотрена надежность, включают:
- анализ поставщиков для определения качества поставщиков, их обязательств по графику поставок, возможностей обработки заказов, эффективности, политики в области закупок и управления цепочками поставок;
- анализ качества для определения статуса несоответствий, эффективности гарантий, тенденций изменения качества, а также выявления областей для улучшения и рекомендуемых действий руководства;
- анализ верификации и валидации для обеспечения надлежащего выполнения верификации и валидации;
- анализ производства для определения потребностей в ресурсах и графиков поставок, производственных мощностей и возможностей производства, аутсорсинга и субподряда производственных работ, оснастки, сборочного производства, контроля материалов и испытаний. Проблемы с надежностью часто являются основной составляющей продолжительности простоев, влияют на готовность оборудования и, следовательно, на производство;
- анализ реализации продукции до ее изготовления, поставки и/или принятия потребителем;
- анализ информации о реализации продукции для обеспечения правильного хранения, установки, интеграции, ввода в эксплуатацию и технического обслуживания.
5.5 Стадия использования
На стадии использования объект размещают для выполнения функций или услуг, для которых он разработан. Деятельность включает эксплуатацию и техническое обслуживание объекта в соответствии с установленными требованиями, обучение операторов, персонала по техническому обслуживанию и ведение записей о работе, инцидентах с отказами для своевременного выполнения корректирующих действий.
Оценка риска в процессе эксплуатации и технического обслуживания связана с проблемами, возникающими в результате изменения условий. Безотказность, готовность, ремонтопригодность и обеспеченность техническим обслуживанием контролируют с помощью более длительных в условиях эксплуатации испытаний, а результаты анализируют как для выявления необходимости изменений в конструкции, так и для улучшения программ технического обслуживания и технической поддержки.
Анализ надежности в процессе использования может принимать различные формы, такие как:
- анализ для определения работоспособности и эксплуатационного состояния производства или оказывающего услуги оборудования;
- анализ фактической и ожидаемой безотказности и ее влияния на готовность;
- анализ ремонтопригодности и обеспеченности техническим обслуживанием для оценки обеспеченности техническим обслуживанием и логистики важнейших объектов, включая стоимость, и выяснения того, обеспечивают ли они требуемую готовность и функциональность;
- анализ услуг для определения потребностей потребителей в обслуживании, плановых и внеплановых действий обеспечения технического обслуживания, услуг сторонних поставщиков, технической поддержки, запасных частей и складских помещений;
- анализ риска для определения наличия изменений рисков и результативности менеджмента риска;
- анализ удовлетворенности потребителей для решения проблем пользователей и разработки стратегий улучшения там, где надежность может быть ключевым вопросом.
Для объектов с длительным сроком службы цели, заинтересованные стороны и требования могут изменяться на протяжении стадии использования. Периодически следует проводить анализ для проверки наличия таких изменений, с тем чтобы мероприятия и их результаты продолжали обеспечивать выполнение поставленных целей.
5.6 Стадия улучшения
Стадия улучшения может быть необходима для улучшения работы объекта в соответствии с растущими требованиями пользователей, продлением срока службы или управлением устареванием (см. МЭК 62402 [6]). Действия на этой стадии могут включать обновление или дополнение аппаратного и программного обеспечения, улучшение технического обслуживания, упрощение процедур, способствующих повышению результативности эксплуатации, и управление устареванием. На этой стадии для оценки воздействия возможных улучшений и выбора наилучших решений могут быть использованы соответствующие методы моделирования и вероятностные подходы. При оценке риска на стадии улучшения часто рассматривают соотношение затрат и выгод и отдачу от инвестиций, а также технические последствия предполагаемых изменений.
Анализ, как правило, выполняют с целью выявления и оценки необходимых улучшений. В зависимости от степени изменений при проектировании обновлений может потребоваться анализ конструкции в соответствии с 5.3.2.
5.7 Стадия распоряжения
Стадия распоряжения является последней в жизненном цикле объекта. После прекращения использования объекта он может быть демонтирован, использован для других целей, его материалы и компоненты могут быть повторно использованы, а в некоторых случаях оставлены на месте (например, трубопровод). Необходимые действия, выполняемые на стадии распоряжения, должны быть рассмотрены на стадии концепции. Планы вывода объекта из эксплуатации, разработанные ранее в течение жизненного цикла, должны быть пересмотрены до их выполнения с учетом реальных обстоятельств. Для сложных объектов может быть установлена стратегия вывода объекта из эксплуатации для формализации планирования и выполнения процесса вывода объекта из эксплуатации в соответствии с установленными требованиями. Для других объектов могут быть установлены правила в отношении их возврата, повторного использования или утилизации. Может быть полезно проанализировать информацию, полученную в процессе жизненного цикла аналогичных проектов или объектов. Требование консервации, хранения системы в течение определенного периода времени до ее окончательной утилизации требует определения соответствующих действий по сохранению системы, которые должны быть выполнены в течение соответствующего периода. Результаты всех видов анализа на стадии распоряжения, включая полученную информацию, должны быть записаны в качестве знаний организации и использованы как исходные данные на стадии разработки концепции нового проекта, если это уместно.
6 Выполнение процесса анализа надежности
6.1 Общие положения
Анализ надежности требует тщательного планирования, организации проведения и отчетности. В данном разделе установлена основа выполнения процесса анализа, она применима к большей части вариантов анализа, а не только к анализу надежности. Конкретные детали выполнения анализа зависят от объекта анализа и типа проводимого анализа. Данный раздел основан на анализе в виде структурированного совещания. Схема процесса анализа приведена на рисунке 2.
|
 |
Рисунок 2 - Схема выполнения процесса анализа
6.2 Планирование анализа
Планирование начинают с определения цели анализа, как для внутреннего, так и для внешнего анализа, и объема анализа, в том числе определения того, должна ли команда анализа давать рекомендации по решению всех выявленных проблем или целью анализа является исключительно анализ пробелов.
Конкретные цели зависят от типа анализа и рассматриваемых объекта, системы или процесса. Четкие разъяснения председателя о целях и области применения каждого анализа надежности позволяют сосредоточить внимание на конкретных областях и свести к минимуму неуместные комментарии.
6.3 Выбор команды анализа
В зависимости от того, является ли анализ внутренним или внешним, проведение анализа и положение отдельных лиц могут отличаться.
Внутренний анализ позволяет команде или группе проектирования делать перерывы, рассматривать достигнутые результаты и проверять соответствие действий и результатов ожиданиям. Внешний анализ является более формальным и обеспечивает независимую оценку уверенности команды, проектной группы, руководства или внешних заинтересованных сторон в надежности объекта и деятельности по ее обеспечению.
Команда анализа обычно включает:
- председателя;
- секретаря;
- соответствующих специалистов, не участвующих в разработке исследуемой системы;
- руководителя проекта или проектной группы и ее членов, которые при необходимости представляют проект или тип анализа и отвечают на вопросы.
В некоторых случаях потребители или пользователи также могут входить в команду.
В тех случаях, когда целью анализа является одобрение перехода с одной стадии жизненного цикла на другую, в команду анализа могут входить лица, уполномоченные давать такое одобрение.
Руководитель проекта или проектной группы или те, кто непосредственно участвует в проектировании, обычно не возглавляют команду анализа, председатель должен быть независимым, это позволяет получить больше преимуществ.
При выборе команды анализа следует позаботиться о том, чтобы избежать конфликта интересов, группового мышления и корыстных интересов участников.
В команду анализа могут быть включены люди, обладающие специальными знаниями и опытом из разных сфер. Состав команды должен быть таким, чтобы участники обладали детальными знаниями и в совокупности охватывали достаточно широкую область знаний, позволяющую рассматривать все соответствующие аспекты анализа. Следует позаботиться о достаточной работоспособности команды. В приложении D описаны функции и обязанности некоторых ключевых участников.
6.4 Подготовка пакета входных данных
Для проведения анализа необходимо собрать соответствующую информацию. Примеры типов информации, которую должен содержать пакет входных данных, приведены в приложении E.
6.5 Уведомление о совещании и повестка дня
Секретарь совместно с председателем должны подготовить уведомления о совещании с указанием повестки дня и распространить их среди участников и, в соответствующих случаях, руководителей заблаговременно, чтобы участники могли подготовиться к совещанию.
В уведомлении и повестке дня должно быть указано следующее:
- дата, время и место проведения совещания;
- область применения и цели анализа;
- наименование проекта и идентификационный номер (если применимо);
- участники совещания и их функции;
- тип и продолжительность анализа надежности;
- команда или раздел анализируемого проекта, если это уместно;
- темы надежности, подлежащие обсуждению (см. приложение E);
- лица, которые будут выступать с докладами;
- справочные документы и содержание всего прилагаемого пакета входных данных.
6.6 Проведение совещания по анализу надежности
6.6.1 Общие положения
Если участники не имеют опыта выполнения анализа, следует провести ознакомительную сессию с разъяснением общих целей, философии и практики анализа.
Вступительные замечания должны задавать конструктивный тон и атмосферу. Председатель должен рассмотреть цели совещания и увязать их с общими целями и процедурами процесса анализа. Председатель должен указать необходимость задавать вопросы и избегать негативных и личностно ориентированных комментариев.
Следует также избегать вопросов, подразумевающих определенное мнение.
Участники анализа не должны стесняться задавать вопросы своим коллегам. Они не должны рассматривать свою ответственность исключительно за то, чтобы задать вопрос о том, почему что-то было сделано определенным образом.
Участники анализа должны быть уверены, что все вопросы заданы, последующие расследования запрошены, а высказанные мнения не задевают кого-то лично, чьи-то способности или моральные качества. Команда анализа под руководством председателя должна обеспечить поддержание анализа активным, объективным и беспристрастным как внутри команды анализа, так и в отношении других участвующих групп.
Участники технического анализа всегда должны помнить, что они выполняют консультативные функции и что их основная цель состоит в помощи тем, кто отвечает за проектирование, эксплуатацию или техническое обслуживание системы, и в достижении оптимального результата. Группа технического анализа, как правило, представляет только рекомендации по устранению выявленных недостатков.
6.6.2 Протокол совещания
Соответствующий менеджер и другие члены, представляющие исследуемые команду или проект, могут при необходимости представить аспекты надежности системы, которые рассматриваются при анализе команды или проекта.
Председатель должен обеспечить систематическое проведение презентаций, опросов и составление протоколов.
Процесс анализа - это набор конструктивных вопросов и ответов. Не следует допускать уничижительных вопросов или действий, а также категорического отказа обсуждать тему, если только это не связано с конкретными проблемами коммерческой конфиденциальности или национальной безопасности. Вопросы должны быть сформулированы в виде запросов информации или обоснования принятия решений командой или группой проектирования.
Участники анализа могут заранее задать вопросы председателю для подготовки необходимых действий. Вопросы могут быть отнесены к сложным или второстепенным. Чтобы упростить процедуру совещания, несущественные вопросы, по возможности, следует решить до начала совещания. Эти вопросы (и ответы, если они известны) следует включить в пакет исходных данных для совещания.
Типографские ошибки или незначительные редакционные вопросы, касающиеся входных данных, не следует обсуждать при выполнении анализа. Секретарь должен организовать их устранение по мере необходимости. Все существенные исправления необходимо обсуждать с участниками анализа.
Процесс анализа не должен давать одобрение или неодобрение команде или анализируемой проектной документации.
6.6.3 Пункты решений
Всякий раз, когда требуется выполнить какое-либо действие, задача, имена лиц, назначенных для выполнения задачи, и дата выполнения должны быть записаны в протоколе совещания. Действия должны быть конкретными, измеримыми, осуществимыми, реалистичными и выполнимыми за ограниченное время.
Как только определены пункты решений и разработаны рекомендации, председатель должен рассмотреть следующие вопросы (перечень может быть дополнен):
- изменения в концепциях, спецификациях, планах и графиках выполнения проекта системы;
- влияние на требования безопасности или окружающей среды, качество системы, ее надежность, производство, монтаж, эксплуатацию, процедуры технического обслуживания, варианты поддержки и затраты.
Поскольку статус команды анализа является консультативным, команда или руководитель проекта определяют фактические действия по всем пунктам решений.
Следует определить ответственность за последствия действий и их влияние.
6.6.4 Рекомендации
Все рекомендации должны быть подробно описаны в протоколе совещания и связаны с первоначальным обсуждением. Обоснования рекомендаций должны быть зафиксированы везде, где это возможно. Рекомендации - это не то же самое, что пункты решений, рекомендованные действия могут привести к увеличению срока выполнения работ.
6.6.5 Отклоненные пункты решений и рекомендации
В тех случаях, когда в процессе предыдущего анализа были указаны пункты решений, которые не были выполнены, или рекомендации, которые были отклонены, причины невыполнения действий или отклонения рекомендаций должны быть объяснены и зафиксированы в протоколе анализа.
6.6.6 Заключение совещания
По завершении совещания председатель должен обобщить действия и рекомендации, предлагаемые в результате анализа, для обеспечения общего понимания и согласования с командой анализа.
6.7 Подготовка и распространение протоколов анализа
6.7.1 Общие положения
Целью протокола заседания анализа надежности является:
- обеспечение способов и средств выполнения последующих действий и рекомендаций;
- увеличение корпоративных знаний и опыта организации.
Запись о состоянии конструкции или статусе проекта в определенный момент времени добавляют в хронологические сведения о системе или проекте. Это может быть полезно при планировании разработки аналогичных конструкций и проектов в будущем. Записи о хронологии разработки конструкции или проекта также могут быть полезны для защиты патентных и других прав собственности или защиты системы и ее процессов при возможных последующих расследованиях и судебных разбирательствах.
Протоколы и подтверждающие документы должны быть направлены участникам анализа и другим соответствующим лицам. Эти документы должны храниться в соответствии с процедурами управления документацией в организации.
Помимо участников анализа, протоколы совещания по анализу надежности должны быть направлены руководителю проекта или группы проектирования, членам команды обеспечения надежности и другим соответствующим лицам.
6.7.2 Протоколы
Секретарь отвечает за регистрацию важных проблем, вопросов и ответов, действий и рекомендаций. Следует избегать дословных записей. Должна быть записана достаточная информация, позволяющая подготовить окончательный набор протоколов с требуемой степенью детализации.
Для того чтобы процесс анализа был результативным, необходимо документировать темы и результаты обсуждений в процессе каждого анализа. Это обеспечивает непрерывность и последующую деятельность до тех пор, пока не будут приняты решения и выполнены задачи в области надежности. В протоколах заседаний должно содержаться достаточное количество документации, что позволяет избежать повторного рассмотрения одних и тех же проблем и значительной потери понимания соответствующих проблем при последовательно выполняемых видах анализа. При достижении преемственности усилия по выполнению последующего анализа могут быть сосредоточены на более актуальных проблемах.
Информация, содержащаяся в протоколе, должна включать следующее:
- копию уведомления о заседании и повестке дня;
- список участников с указанием их функций;
- данные идентификации анализируемых системы или процесса, включая конкретный статус пересмотра ссылочных документов;
- краткое изложение выводов, сокращенный график действий и, при необходимости, подробную информацию об анализе;
- соответствующие вопросы и ответы;
- копии всех используемых контрольных перечней и, при необходимости, ответы на вопросы;
- перечень аспектов действий для нерешенных вопросов;
- если было назначено действие - лицо, на которое возложена ответственность за его выполнение;
- если были назначены аспекты действия - даты завершения аспектов действия;
- перечень рекомендаций;
- перечень действий или рекомендаций по проекту, требующих приоритета, в соответствии с анализом состояния;
- состояние или распределение аспектов действий и рекомендаций из предыдущих совещаний в соответствии с анализом состояния;
- перечень ссылочных документов.
6.8 Действия и рекомендации по итогам анализа
Несмотря на то, что в результате анализа может быть разработано много рекомендаций, команда или руководитель проекта обязаны проанализировать все рекомендации и могут отклонить те из них, которые они считают невыполнимыми. Например, многие рекомендации могут быть разумными и в целом полезными для команды и проекта, но возможно, что некоторые из них при дальнейшем рассмотрении окажутся нежелательными или нецелесообразными.
Лицо, ответственное за определение реакции на каждое действие и рекомендации, должно учитывать желательность и практичность рекомендаций команды анализа и своевременно реагировать на действие, а также должно:
- предоставлять ответ на каждое действие и рекомендацию совещания в согласованные сроки;
- выполнять действия по устранению всех разногласий в понимании;
- официально уведомлять председателя о том, когда были рассмотрены действия и рекомендации, и завершить их, если это соответствует порядку организации анализа надежности.
6.9 Последовательность и завершение выполнения решений и рекомендаций
Процесс анализа не завершен до тех пор, пока не выполнены все решения и рекомендации, определенные в результате анализа.
Для выполнения решений должны быть распределены обязанности и полномочия, должен быть предусмотрен бюджет и определены сроки выполнения. Это включает в себя назначение ответственного за выполнение решений и завершение перечня действий совещания по анализу надежности в согласованные сроки.
После завершения всех возникающих действий и рекомендаций перечень действий и рекомендаций, указанных в протоколе анализа надежности, должен быть подписан и закрыт. Затем он должен быть передан соответствующему руководителю организации, ответственному за деятельность по обеспечению надежности, в соответствии с процедурами организации.
Приложение A
(справочное)
Примеры пакета входных данных для анализа надежности
A.1 Стадия концепции
На стадии концепции пакет входных данных должен включать некоторые или все из следующих данных:
- первоначальные требования: они могут включать запрос заказчика на котировки, спецификации, стандарты, нормативные и отраслевые требования;
- предполагаемые потребности и ожидания потребителей, разработанные и подкрепленные исследованиями рынка и деятельностью конкурентов;
- предположения, относящиеся к концепции конструкции;
- общие цели и требования к надежности;
- базу данных о надежности, если таковая существует;
- требования заинтересованных сторон, требования к интерфейсу и все модификации, которые существуют;
- ожидаемые риски достижения требований к надежности.
A.2 Стадия разработки
На стадии разработки пакет входных данных должен включать в себя некоторые или все из следующих данных:
- план обеспечения надежности;
- документированные предположения для проектирования;
- данные исследований компромиссных решений и анализа конструкции;
- перечень всех вопросов команды анализа по проекту;
- данные распределения и прогноза показателей безотказности, ремонтопригодности и готовности;
- план технического обслуживания и логистической поддержки;
- предложения проектировщика и альтернативные рассмотрения, включая чертежи и расчеты;
- информацию и данные об аналогичных системах;
- данные конкурентной системы;
- оценки затрат и обоснование компромисса;
- спецификации и чертежи;
- результаты разработки опытного образца (прототипа);
- базу данных по безотказности, если таковая существует;
- требования заинтересованных сторон, требования к интерфейсу и сведения обо всех существующих модификациях;
- цели жизненного цикла и данные о затратах;
- требования к деятельности по сертификации/обеспечению качества;
- план/реестр менеджмента риска проекта.
A.3 Стадия изготовления
На стадии изготовления пакет входных данных должен включать в себя некоторые или все из следующих данных:
- данные исследований производства, оснастки и производительности;
- сведения о состоянии производственного процесса;
- статус решений об изготовлении/приобретении составных частей;
- статус программ надежности и качества поставщиков;
- отчеты об испытаниях, данные анализа и установленные требования;
- анализ управления качеством процессов и поставок;
- данные контроля;
- отчеты о качестве приобретенных или поставляемых объектов;
- базу данных о безотказности, если таковая существует;
- требования заинтересованных сторон, требования к интерфейсу и данные обо всех существующих модификациях;
- данные о состоянии выполнения установки (монтажа) объекта;
- требования к деятельности по сертификации/обеспечению качества.
A.4 Стадия использования
На стадии использования пакет входных данных должен включать некоторые или все из следующих данных:
- данные о коэффициенте готовности и продолжительности неработоспособного состояния, связанные с производством и производственными операциями;
- отчеты об отказах, неисправностях и несоответствиях в эксплуатации, а также о тенденциях их изменения;
- данные об элементах поддержки технического обслуживания, таких как простои из-за задержек в предоставлении ресурсов (запасных частей, квалифицированного персонала и вспомогательного оборудования);
- расходы на техническое обслуживание;
- инциденты в области безопасности, связанные с отказом системы или оборудования;
- результаты и рекомендации анализа основных причин;
- текущие задачи технического обслуживания;
- данные готовности запасных частей, особенно для критически важных объектов;
- данные сопоставления ожидаемой и фактической безотказности;
- данные сопоставления ожидаемой и фактической ремонтопригодности;
- базу данных по безотказности, если таковая существует;
- требования заинтересованных сторон, требования к интерфейсу и данные обо всех существующих модификациях;
- данные сопоставления ожидаемой и фактической обеспеченности техническим обслуживанием;
- план/реестр менеджмента риска проекта.
A.5 Стадия улучшения
На стадии улучшения пакет входных данных аналогичен пакету на стадии разработки и должен включать некоторые или все из следующих данных:
- документированные предположения, использованные при проектировании;
- данные исследований компромиссных решений и анализ конструкции;
- перечень всех вопросов команды анализа по проекту;
- данные распределения и прогноза безотказности, ремонтопригодности и готовности;
- план технического обслуживания и логистической поддержки;
- предложения проектировщика и альтернативные рассмотрения, включая чертежи и расчеты;
- оценки затрат и обоснование компромисса;
- базу данных по безотказности, если таковая существует;
- требования заинтересованных сторон, требования к интерфейсу и данные обо всех существующих модификациях;
- технические характеристики и чертежи;
- план/реестр менеджмента риска проекта.
A.6 Стадия вывода из эксплуатации (распоряжения)
На стадии распоряжения пакет входных данных должен включать некоторые или все из следующих данных:
- все требования к временному выводу из эксплуатации и консервации;
- стратегию декомпозиции и распоряжения составными частями;
- влияние на окружающую среду при утилизации объекта;
- влияние прекращения обслуживания;
- базу данных по безотказности, если таковая существует;
- требования заинтересованных сторон, требования к интерфейсу и данные обо всех существующих модификациях;
- график и сроки прекращения обслуживания и предоставления новых или альтернативных услуг;
- план/реестр менеджмента риска проекта.
Приложение B
(справочное)
Примеры целей анализа надежности в процессе жизненного цикла
B.1 Общие положения
В данном приложении приведен перечень возможных целей анализа надежности на различных стадиях жизненного цикла объекта. Рассмотренный жизненный цикл является общим, на практике может быть использован модифицированный набор стадий жизненного цикла. Некоторые пункты, из приведенных ниже, связаны с техническим анализом, другие - с анализом со стороны руководства.
Примечание - В приложении E перечислены конкретные темы, касающиеся основных свойств надежности и связанных с ними вопросов.
B.2 Стадия концепции
Цели анализа надежности на стадии концепции могут включать:
- оценку уровня идентификации и ясности требований потребителей, где это необходимо;
- оценку уровня идентификации применимых обязательных требований;
- оценку включения других необходимых технических требований в исходные данные проектирования;
- оценку идентификации организационных и технических интерфейсов;
- оценку выполнения оценки рисков, связанных с проектированием.
B.3 Стадия разработки
B.3.1 Анализ концепции проекта
Цели анализа концепции проекта могут включать:
- интерпретации оценки и согласование требований, потребностей и ожиданий потребителя, а также требований к продукции;
- установление обязательных требований, включая нормативные требования и требования кодексов, а также желательных и необязательных характеристик;
- оценку взаимодействия членов группы проектирования с ответственными за проектирование, продажи, производство, испытания, контроль, монтаж, эксплуатацию, техническое обслуживание, утилизацию и т.д.;
- анализ условий и технологий, доступных в настоящее время, для удовлетворения требований потребителей, рынка, охраны окружающей среды и безопасности;
- анализ информации о производстве, эксплуатации и ответственности из отчетов организации по эксплуатации аналогичной продукции или данных отрасли;
- анализ планов и графиков разработки и проектирования;
- оценку предложенных концепций проекта.
B.3.2 Анализ рабочего проекта
Цели анализа рабочего проекта могут включать:
- верификацию того, что предложенная конструкция по-прежнему удовлетворяет требованиям к продукции;
- подтверждение того, что действия и рекомендации предыдущего анализа оценены, рассмотрены и выполнены;
- рассмотрение результатов исследований, расчетов и испытаний;
- оценку экономической эффективности предполагаемой продукции;
- обеспечение того, что продукция будет функционировать так, как ожидалось;
- проверку того, что предлагаемая продукция может быть изготовлена, проверена, собрана с надлежащими допусками, надежно сохранена, отправлена и установлена и, при необходимости, утилизирована безопасно, законно и экономически эффективно;
- анализ сопроводительной документации, содержащей подробное описание испытаний и данных, использованных при разработке продукции;
- оценку конструкции системы, разделение функций и интерфейсов между модулями (например, структурной схемы надежности - см. МЭК 61078 [11]);
- анализ применения компонентов для проверки условий эксплуатации компонентов и покупной продукции на соответствие ведомостям данных, результатам испытаний, а также особым требованиям к процессам использования, обработки и сборки;
- установление иерархических характеристик, таких как стоимость, производительность, физические параметры, надежность, экологические ограничения, требования к поставкам и контрактные средства поощрения, на основе которых могут быть приняты компромиссные решения для установления обязательных, желательных и необязательных характеристик.
B.3.3 Анализ финального проекта
Цели анализа финального проекта могут включать:
- верификацию того, что окончательный проект соответствует входным требованиям к конструкции;
- верификацию того, что действия и рекомендации предыдущего анализа оценены, рассмотрены и выполнены;
- оценку того, что принятые сведения, полученные из других проектов/конструкций, полезны для улучшения конструкции;
- анализ всех сведений, полученных из других проектов/конструкций, которые не были приняты, подтверждение обоснований этого и меры решения проблем;
- проверку того, что подробные анализы, расчеты и испытания проведены, а документация по изготовлению, обеспечению безопасности, установке, эксплуатации и техническому обслуживанию продукции была подготовлена в пригодной для использования форме;
- оценку финальной конструкции сточки зрения экономической эффективности жизненного цикла;
- верификацию того, что финальная конструкция может быть изготовлена, проверена, собрана с надлежащими допусками, надежно сохранена, доставлена и установлена, а при необходимости утилизирована безопасно, законно и экономически эффективно и что она способна работать в соответствии с требованиями;
- проверку доставки, совместимости, качества и надежности приобретенных компонентов;
- анализ сопроводительной документации, содержащей подробный опыт и данные, используемые для проектирования;
- оценку состояния набора чертежей, программных кодов и спецификаций на предмет полноты и применимости к предполагаемой продукции или процессу;
- верификацию того, что перед принятием и включением в проект было проведено надлежащее исследование рекомендаций предыдущих видов анализа проекта;
- учет полученных данных будущей конструкции, записей причин или смягчающих мер для всех идентифицированных объектов, которые не были использованы.
B.4 Стадия изготовления
Цели анализа надежности на стадии изготовления могут включать:
- установление качества поставщиков, обязательств по графику поставок, эффективности обработки заказов, политики множественных поставщиков и управления цепочками поставок;
- анализ рисков, связанных с использованием в фактических условиях эксплуатации;
- определение статуса несоответствия качеству, эффективности обеспечения и тенденций в области качества, а также определение области улучшения и рекомендуемых действий руководства;
- обеспечение надлежащих процессов верификации и валидации и, при необходимости, проведение мероприятий по сертификации и/или обеспечению качества;
- анализ достигнутых показателей надежности по отношению к спецификациям для обеспечения объективных свидетельств соответствия спецификациям;
- анализ планов технического обслуживания, созданных на стадии разработки для подтверждения того, что задачи выполнимы и соответствуют замыслу проекта.
B.5 Стадия использования
B.5.1 Эксплуатация
Цели анализа надежности на стадии эксплуатации могут включать:
- мониторинг показателей безотказности, готовности и связанных с ними проблем надежности, для выявления необходимости изменения конструкции;
- мониторинг отказов, несоответствий и тенденций изменения показателей надежности;
- анализ производства для определения потребностей в ресурсах и графиков поставок, производственной мощности и возможностей производства, аутсорсинга и субподряда производственных работ, оснастки, сборочного производства, контроля материалов и испытаний;
- определение работоспособности и рабочего состояния организации, дочернего подразделения, производственного предприятия или объекта обслуживания;
- сравнение фактических показателей безотказности с ожидаемыми значениями и влияние этих показателей на показатели готовности;
- анализ удовлетворенности потребителей для решения проблем пользователей и определения улучшения в области надежности.
B.5.2 Техническое обслуживание
Цели анализа надежности на стадии технического обслуживания могут включать:
- мониторинг показателей безотказности, ремонтопригодности, обеспеченности техническим обслуживанием и готовности как характеристик и тенденций надежности, для выявления необходимости изменения конструкции и улучшения программ технического обслуживания и материально-технической поддержки;
- оценку выполнения технического обслуживания и логистики важнейших объектов, включая затраты;
- выполнение анализа услуг для определения потребностей потребителей, плановых и внеплановых работ по техническому обслуживанию, услуг сторонних поставщиков, материально-технической поддержки, запасов и складских помещений.
B.6 Стадия улучшения
Цели анализа надежности на стадии улучшения могут включать:
- рассмотрение объема или необходимости улучшения в середине срока службы на основе коммерческих, технических, производственных отзывов, обратной связи из эксплуатации при наличии изменений в законодательстве или кодексах;
- проверку того, до какой степени улучшенная конструкция решает все проблемы, которые привели к принятию решения о необходимости улучшения;
- проверку того, что улучшенная конструкция не создает новых рисков;
- обеспечение того, что новая конструкция и другие изменения не окажут отрицательного влияния на надежность;
- выполнение видов анализа, аналогичных проводимым на стадии разработки.
B.7 Стадия вывода из эксплуатации (распоряжения)
Цели анализа надежности на стадии распоряжения могут включать:
- рассмотрение возможности повторного использования всей или части системы;
- обеспечение того, что принятые меры по распоряжению и консервации соответствуют нормативным и другим требованиям;
- рассмотрение планов, составленных на предыдущих стадиях жизненного цикла для действий по консервации и выводу из эксплуатации;
- пересмотр планов вывода из эксплуатации;
- рассмотрение и, при необходимости, применение всех необходимых действий по консервации/хранению до окончательного распоряжения;
- сбор информации, позволяющий в будущем улучшить конструкцию аналогичных объектов.
Приложение C
(справочное)
Вопросы, рассматриваемые при анализе надежности в процессе всего жизненного цикла
C.1 Общие положения
Ниже приведены вопросы, которые могут быть рассмотрены во время анализа надежности с примерами проблем, связанных с надежностью. Некоторые из приведенных ниже выводов анализа связаны с техническим анализом, другие - с анализом со стороны руководства. Виды анализа должны быть адаптированы к индивидуальным условиям по согласованию как с руководством, так и с персоналом, ответственным за выполнение действий по обеспечению надежности. Контрольные перечни в примерах являются общими и могут потребовать дополнительных конкретных критериев для выполнения надлежащего анализа.
C.2 Примеры вопросов, рассматриваемых при анализе надежности на стадии концепции
На стадии концепции в процессе анализа надежности обычно рассматривают вопрос об осуществимости концепции и, в частности, возможности выполнения требований надежности. Это можно выполнить на основе объективных данных и анализа путем рассмотрения следующих вопросов:
- соответствия установленных целей в области обеспечения надежности потребностям рынка и использованию пользователями;
- объема рынка и стратегии новых инициатив, включая условия использования потребителями и условия работы на рынке, например климатические условия;
- целевых показателей надежности, конкурентных преимуществ, стимулов и ограничений применения;
- предлагаемых сроков внедрения новой продукции и достижения целевых показателей;
- установленных критериев адаптации и применимых действий;
- достаточности информации о предлагаемой новой системе для начала анализа требований;
- вклада заинтересованных сторон в требования и конструкцию для формирования удовлетворительных требований;
- определения целевых значений показателей безотказности, ремонтопригодности, обеспеченности техническим обслуживанием и готовности, в зависимости от обстоятельств на основе поддающихся проверке данных;
- выявленных рисков, которые необходимо учитывать при проектировании.
Также важна четкость следующего:
- проведения и документирования анализа требований к границам системы, рабочим функциям и характеристикам работы, а также технологическим ограничениям;
- определения готовности ресурсов, технических возможностей и новых инвестиционных потребностей;
- определения технических подходов и возможности изготовления системы;
- определения возможных партнерских отношений и требований к поставщикам;
- результатов анализа требований и обоснованности инвестиций в ресурсы для начала разработки концепции новой системы более высокого уровня;
- рисков, рассмотренных с разных точек зрения, оцененных и учтенных при выборе конструкции;
- обоснования важности элементов анализа требований, включая границы системы, готовность ресурсов, возможное партнерство, инвестиции в ресурсы;
- обоснования значимости различных элементов спецификаций требований, включая стоимость продукции, график отгрузки и условия окружающей среды;
- определения требований к охране труда, технике безопасности и окружающей среде;
- четкого определения политики и целей проектирования в области охраны здоровья, безопасности и окружающей среды, а также обоснованности требований общества.
При анализе надежности может быть проверено следующее:
- цели охраны окружающей среды, например, количество повторно используемых деталей или переработанных материалов и потребление энергии, являются четкими и могут быть проверены с помощью верифицированных данных;
- определены критерии структуры конструкции возможные конфигурации и варианты объекта;
- определен выбор технологии для проектирования функций объекта;
- прогнозируемые вероятностные оценки рассмотрены по отношению к целям надежности;
- установлены критерии принятия решения для покупок;
- созданы средства верификации и интеграции функций объекта;
- установлены критерии для функций аппаратного/программного обеспечения объекта;
- для конструкции установлены экологические и эргономические критерии;
- установлены критерии оценки функций объекта;
- совместимость функций и границ работы системы проверена на соответствие требованиям к объекту;
- требования к надежности, установленные в спецификации объекта, использованы в качестве руководства по проектированию и покупке приобретаемой продукции;
- идентифицирована и верифицирована концепция нового объекта и варианты структуры его конструкции с соответствующими ограничениями для обоснования начала официального проектирования объекта с документированными спецификациями;
- оценены риски, соответствующие различным конструкциям.
C.3 Примеры вопросов, рассматриваемых при анализе надежности на стадии разработки
На стадии разработки при анализе надежности может быть рассмотрена необходимость выполнения валидации предположений, сделанных при проектировании, а также проверки следующего:
- правильности выполнения анализа требований заказчика к продукции;
- доступности данных спецификации изготовления и функциональных требований продукции;
- четкости установления связи спецификации требований с проектными действиями;
- результаты проектирования и разработки функций продукции отражают результаты соответствующего анализа;
- ожидаемые показатели надежности определены на основе критериев проектирования и/или исследования рынка;
- план обеспечения надежности конструкции объекта и его компонентов установлен;
- план обеспечения качества, план управления устареванием и процесс управления конфигурацией объекта установлены;
- конструкция объекта верифицирована и установлены программы поддержки полномасштабной разработки;
- процесс адаптации для различных объектов и проектов разработки функции выполнен и установлена ответственность за каждую часть проекта, включая обеспечение надежности при проектировании;
- план верификации и валидации объекта и, при необходимости, сертификации/обеспечения качества разработаны;
- критерии приемлемости надежности и программы повышения надежности установлены;
- прогнозируемые вероятностные оценки согласуются с целями надежности;
- конструкция изменена и оценена ее безотказность;
- проведена верификация соответствия прогнозируемых вероятностных оценок целевым показателям надежности;
- прогнозируемые показатели продукции и надежность ее функций соответствуют целям;
- установлены планы испытаний и критерии приемки, проведены моделирование и испытания;
- проектные и экспериментальные результаты соответствуют прогнозам;
- установлены системы мониторинга и контроля объекта, отчетности об инцидентах и управления данными;
- результаты испытаний опытного образца подтверждают, что целевые функции соответствуют требованиям;
- запланирована и проведена серия испытаний для проверки обоснованности конструкции и выявления ее недостатков, а также для улучшения анализа проекта;
- заявка на компоненты рассмотрена с поставщиками;
- установлены программы обеспечения надежности поставщиков;
- запланирована серия испытаний для демонстрации надежности продукции поставщиков и оценена их способность обеспечения надежности;
- выполнен контроль разработанной документации;
- оценены риски, соответствующие функциональным и нефункциональным целям и требованиям к надежности, установлены планы обработки рисков;
- запланированы программы технического обслуживания и логистической поддержки объекта;
- запланированы программы аутсорсинга;
- разработана программа обеспечения запасными частями;
- запланированы учебные программы;
- установлены критерии гарантийных обязательств для послепродажного обслуживания системы;
- объект полностью разработан и готов к производству или изготовлению;
- спецификации программного обеспечения и технологические карты завершены и утверждены;
- начата разработка функций модулей и подсистем программного обеспечения;
- проанализированы требования к работоспособности, безопасности, окружающей среде и их влияние на надежность минимизировано.
C.4 Примеры вопросов, рассматриваемых при анализе надежности на стадии изготовления
На стадии изготовления при анализе надежности может быть рассмотрено, соответствие надежности на момент производства продукции результатам испытаний на повышение надежности путем проверки следующего:
- сборка аппаратных средств и функций начата;
- проверяемые данные производства демонстрируют требуемую зрелость процесса и надежность продукции;
- верифицировано то, что процесс сборки является очевидным или четко установленным;
- установленные материалы, компоненты и процессы идентифицированы, а готовность и стабильность поставок верифицированы;
- безотказность на момент изготовления продукции соответствует результату выполнения программы повышения надежности по проверке соответствия достигнутой безотказности требованиям на момент изготовления продукции (см. МЭК 61014 [8]);
- решения о закупках приняты;
- программы надежности поставщиков и управления устареванием выполнены;
- функции объекта, верификация и валидация подсистем, а также, при необходимости, планы сертификации/обеспечения качества выполнены;
- системы отчетности, анализа и сбора данных об отказах готовы;
- возможно обнаружение ошибок до отгрузки продукции;
- условия приемочных испытаний и планы испытаний для обеспечения надежности подготовлены;
- конфигурация системы для приемочных испытаний определена и согласована;
- система сбора исходных данных об отказах в условиях эксплуатации и управления ими функционирует правильно;
- разработаны учебные программы;
- объект спроектирован, изготовлен и представлен готовым к работе.
Процедура установки и вспомогательные системы также могут быть верифицированы путем проверки следующего:
- план интеграции системы выполнен;
- действия, установленные для выявления и контроля рисков, выполнены;
- процедуры установки и системы поддержки верифицированы;
- планы верификации и валидации объекта реализованы;
- квалификация и приемка объекта, а также, при необходимости, планы сертификации/обеспечения качества выполнены;
- план установки объекта выполнен;
- план по обеспечению гарантийных обязательств выполнен;
- начаты учебные программы по эксплуатации системы и обслуживанию потребителей;
- обучение специалистов по монтажу завершено;
- процесс обмена информацией заинтересованными сторонами об установке и эксплуатации системы, такой как руководство пользователя, процедуры и документы, подготовлен и подтвержден как эффективный;
- необходимые конструктивные изменения для выполнения требований надежности выполнены и верифицированы;
- процесс анализа механизмов отказов в системе и изменений конструкции на стадии разработки и/или производственной процедуры на стадии изготовления подготовлен и верифицирован;
- объект готов к выпуску в эксплуатацию.
C.5 Примеры вопросов, рассматриваемых при анализе надежности на стадии использования
На стадии использования для анализа надежности могут быть применены фактические данные эксплуатации для проверки следующего:
- программы технического обслуживания и поддержки выполнены и являются надлежащими и результативными;
- риски пересматривают для реальных условий;
- целевой показатель надежности определяют по количеству отказов продукции, частоте отказов и другим показателям (см. МЭК 60605-6 [14] и МЭК 60300-3-2 [15]);
- работу объекта и услуги технического обслуживания контролируют и управляют ими;
- имеются средства возвращения продукции из эксплуатации и анализа реальной причины отказа (отказ не всегда может быть найден);
- доступна возможность обмена информацией с заинтересованными сторонами о соответствующем использовании;
- разработан план технического обслуживания и выделены ресурсы для его выполнения (см. МЭК 60706-2 [10]);
- организация технического обслуживания включает процессы проверки обеспеченности системы техническим обслуживанием;
- план обновления системы и процедура обновления определены;
- учебные программы для операторов и специалистов по техническому обслуживанию выполнены;
- система сбора данных эксплуатации внедрена;
- управление изменениями конструкции и конфигурацией внедрено;
- опрос удовлетворенности потребителей выполнен;
- данные о работе объекта анализируют для постоянного улучшения;
- объект продолжает поддерживать эксплуатационные характеристики, связанные с надежностью;
- подготовлен процесс поставки запасных частей;
- система технического обслуживания (включая запасные части) доступна в течение необходимого периода времени после окончания продажи продукции (см. МЭК 62402 [6]);
- метод распоряжения продукцией подготовлен и верифицирована система повторного использования (при применении);
- процесс возврата продукции и система контроля установлены и верифицированы;
- система повторного использования и/или переработки соответствующей продукции подготовлена и верифицирована вместе с руководством по демонтажу;
- цели в области охраны окружающей среды могут быть оценены с помощью объективных данных;
- все необходимые мероприятия по сертификации/обеспечению качества выполнены.
C.6 Примеры вопросов, рассматриваемых при анализе надежности на стадии улучшения
На стадии улучшения в процессе анализа надежности может быть рассмотрена обоснованность предположений, сделанных при проектировании, и проверено следующее:
- новые свойства объекта и потребности в улучшении идентифицированы;
- требования и область улучшения четко сформулированы и понятны;
- решение о продолжении улучшения в отношении вариантов проектирования и рисков обосновано;
- программы и сроки улучшения определены;
- результаты всех опросов об удовлетворенности потребителей, проведенных в соответствии с программой улучшения, отслеживают для определения повышения удовлетворенности потребителей;
- спецификации новой конструкции обосновывают для улучшения системы;
- ранее выявленные риски учитывают при проектировании, и никакие новые риски не вводят;
- последствия рисков, в частности связанных со здоровьем, безопасностью, экологическими, нормативными требованиями и требованиями кодексов, а также ценность предлагаемого улучшения оценивают;
- разработаны программы управления изменениями, включая необходимые планы обмена информацией;
- переход от старой конструкции к новой спланирован;
- все требования к сертификации/обеспечению качества идентифицированы.
Следует проверить подготовку к выполнению улучшения, в том числе следующее:
- программы технического обслуживания и логистической поддержки объектов спланированы;
- программы аутсорсинга спланированы;
- учебные программы спланированы;
- установлены гарантийные критерии для сервисной поддержки системы;
- достижение целей изменения и решение проблемы, ради которой инициированы изменения.
Кроме того, на стадии улучшения могут иметь значение рассмотрения, перечисленные в B.3 (стадия разработки).
C.7 Примеры вопросов, рассматриваемых при анализе надежности на стадии вывода из эксплуатации (распоряжения)
На стадии распоряжения при анализе надежности следует рассмотреть следующее:
- разработан план стратегии вывода из эксплуатации, а также, при необходимости, консервации/хранения и начато его выполнение;
- характеристики износа и критерии вывода продукции или системы из эксплуатации (например, по надежности, безопасности, экологическим/социальным или эксплуатационным расходам) четко определены и проверены с учетом возможной переработки и повторного использования;
- воздействие на окружающую среду на стадии распоряжения соответствует критериям, включая правовые ограничения;
- в случае компонентов, утилизация которых создает опасность для окружающей среды, безопасности или здоровья, процесс сбора, демонтажа и локализации опасных остатков определен и верифицирован;
- материалы и компоненты, которые могут оказывать влияние на окружающую среду, идентифицированы и обработаны.
Кроме того, могут быть рассмотрены вопросы:
- возможности повторного использования компонентов;
- информированности потребителей о графике и сроках прекращения предоставления услуг, а также о новых или альтернативных положениях об услугах;
- проведения мониторинга результатов опроса удовлетворенности потребителей в результате прекращения оказания старой услуги и использования новой услуги;
- архивирования необходимых данных таким образом, чтобы они были доступны тем, кто в них нуждается в будущем;
- определения влияния прекращения оказания услуг.
Полученные и обобщенные сведения необходимо документировать и сообщать команде, выполняющей будущий анализ.
Приложение D
(справочное)
Функции и обязанности некоторых ключевых участников технического анализа
D.1 Общие положения
Команда технического анализа может включать (перечень может быть дополнен):
- председателя;
- секретаря;
- соответствующих специалистов;
- руководителя и участников проекта или команды;
- потребителей или пользователей, в некоторых случаях.
В данном приложении описаны функции и обязанности этих ключевых лиц.
D.2 Председатель
Председатель должен обладать техническими знаниями и опытом, которые охватывают проектирование, эксплуатацию и техническое обслуживание системы, а также иметь способности в управлении персоналом и обладать его доверием, уметь одинаково хорошо работать с техническими и нетехническими специалистами. Лидерство и признанный авторитет в организации, а также понимание при работе с людьми имеют для председателя первостепенное значение.
Обязанности и полномочия председателя должны включать:
- согласование цели и области применения анализа;
- выбор участников анализа по согласованию с руководством;
- определение повестки дня совещаний для встреч представителей или заседаний;
- обеспечение понимания участниками того, что от них требуется;
- обеспечение выделения достаточного времени на мероприятия по анализу;
- обеспечение того, чтобы действия, определенные на совещании были конкретными, измеримыми, осуществимыми, реалистичными, выполнимыми за ограниченное время и были распределены между соответствующими участниками совещания;
- получение и сопоставление вопросов членов группы анализа до начала совещания, ответы на них, если это возможно, добавление вопросов в пакет материалов для совещаний;
- представление пакета материалов для совещания назначенным лицам;
- назначение задачи участникам при подготовке к совещаниям;
- управление совещанием по анализу;
- обеспечение профессионального управления совещанием;
- обеспечение документирования вопросов, рассмотренных на совещании;
- обеспечение того, чтобы действия и рекомендации предыдущих совещаний были удовлетворительно рассмотрены и, при необходимости, выполнены;
- обеспечение того, чтобы в центре внимания совещания был анализ, а не отдельные лица;
- обеспечение участия в обсуждении всех присутствующих;
- рассмотрение и утверждение протокола совещания по анализу;
- обеспечение представления протоколов совещаний назначенным лицам;
- стремление к достижению консенсуса в группе рецензентов при расхождении мнений. Если консенсус не может быть достигнут, - представление (для принятия решения) мнений, как меньшинства, так и большинства.
Для сохранения атмосферы честности и объективности в команде анализа, где это возможно, председатель не должен иметь отношения к анализируемой деятельности. Однако следует учитывать, что в малочисленную команду может не попасть сотрудник, обладающий всей необходимой квалификацией и не участвующий каким-либо образом в исследуемой деятельности. Кроме того, следует рассмотреть возможность привлечения сторонних лиц. Председатель должен поддерживать взаимоуважение всех участников.
D.3 Секретарь
Для ведения записей, фиксирования результатов совещания и обеспечения возможности председателю сосредоточиться на совещании может быть назначен секретарь. Если это возможно, один и тот же человек должен выполнять функции секретаря при проведении всех определенных видов анализа конкретной системы. Квалификация и опыт секретаря должны быть аналогичны квалификации и опыту председателя или меньше.
Ответственность и обязанности секретаря должны включать:
- рассылку приглашений за достаточный период времени до начала для подготовки участников к совещанию;
- распространение повестки дня;
- контроль распространения исходных данных для рассмотрения участниками;
- организацию, сбор и рассылку ответов на запросы или задания;
- ведение протокола заседания;
- подготовку протокола заседания;
- своевременное представление протоколов заседаний назначенным лицам;
- оказание помощи председателю в выполнении практических действий и рекомендаций, если это применимо.
Примечание - Если отдельный независимый секретарь не может быть назначен, предпочтительно, чтобы обязанности секретаря выполнял представитель команды.
Если организация имеет достаточный объем, выполнение обязанностей секретаря является хорошей подготовкой для будущего председателя. При выборе секретаря следует учитывать следующие факторы:
- предыдущее участие в мероприятиях по анализу;
- техническую подготовку и сопоставимый опыт;
- коммуникативные навыки;
- участие в аналогичных мероприятиях или проектах;
- неучастие в работе над рассматриваемой системой или процессом.
D.4 Соответствующие специалисты
Специалисты, которые не участвуют в разработке исследуемой системы, должны быть выбраны с учетом особенностей и целей системы, а также типа анализа.
Специалисты должны быть представлены в команде анализа на соответствующей стадии разработки системы. Их специализация может включать (перечень может быть дополнен):
- разработку объектов с установленными показателями безотказности и ремонтопригодности;
- разработку стратегии технического обслуживания объекта и обеспеченности объекта техническим обслуживанием;
- оценку работы системы;
- испытания, приемку и/или сертификацию;
- менеджмент качества;
- разработку структуры системы;
- разработку производства;
- такие области знаний как, например, машиностроение, электротехника (аналоговая, радиочастотная, цифровая), программное обеспечение, компоненты и материалы;
- функциональную и личную безопасность;
- разработку объекта с учетом экологических норм и требований;
- юридические вопросы;
- рекламу и маркетинг;
- финансы;
- логистику;
- производство и/или эксплуатацию.
D.5 Руководитель и члены команды анализа
Руководитель проекта или команды и/или, по крайней мере, один представитель проектировщиков или соответствующей группы должны участвовать в анализе в целом, чтобы объяснять принятое проектное решение, отвечать на вопросы и помогать участникам анализа выявлять и оценивать возможные проблемы, их последствия и возможные действия. Представители должны быть отобраны для участия в совещаниях по анализу вопросов, касающихся их функций в процессах жизненного цикла.
Возможно, не все проектировщики и специалисты могут присутствовать на всех мероприятиях в силу ограничений на размер команды. Поэтому участники могут быть приглашены только на те совещания (или их части), которые относятся к области, в которой они должны участвовать. Тем не менее, все возможные участники должны получить повестку дня и все части пакета входных данных, которые имеют отношение к их опыту. Дополнительно в качестве наблюдателей по согласованию с председателем могут участвовать другие представители. Эти наблюдатели не имеют права выступать без разрешения председателя.
D.6 Потребители и пользователи
В некоторых случаях потребителям и/или пользователям целесообразно участвовать в совещаниях по анализу, чтобы внести свой вклад в такие вопросы, как:
- функциональные и нефункциональные требования пользователя;
- требования к надежности;
- условия использования;
- эргономика и человеческий фактор.
Приложение E
(справочное)
Темы анализа надежности
E.1 Общие положения
Существует ряд конкретных тем, касающихся основных свойств надежности и связанных с ними вопросов, которые, как правило, рассматривают при проведении анализа надежности на всех стадиях жизненного цикла.
E.2 Безотказность и долговечность
Вопросы безотказности и долговечности, рассматриваемые при анализе надежности, включают:
- требования к показателям безотказности [средней наработке между отказами (MTBF), средней наработке до первого отказа (MTTFF), интенсивности отказов, вероятности отказа] и требования к среднему ресурсу;
- сравнение фактических или прогнозируемых показателей безотказности продукции или процесса на момент анализа проекта с применимыми требованиями, включая предположения, модели и источники данных;
- выполнение целей в области безотказности и затрат в рамках плана проекта;
- наиболее вероятные причины отказов продукции, например, первая десятка, выявленная с помощью анализа видов и последствий отказов (FMEA МЭК 60812 [4]) и/или анализа дерева неисправностей (FTA МЭК 61025 [5]);
- действия по повышению безотказности, например, улучшение, замена и улучшение показателей компонентов, контроль окружающей среды;
- специальные производственные процессы, необходимые для достижения заданных значений показателей надежности, включая испытания на воздействие окружающей среды, соответствующий скрининг и анализ;
- требования к транспортной упаковке, транспортированию и хранению закупаемых компонентов в отношении обеспечения показателей надежности продукции;
- ограничения по упаковке, транспортированию и хранению, влияющие на общие показатели надежности продукции;
- сравнение срока годности продукции с требованиями, включая предположения, модели и источники данных;
- хронологические данные о показателях безотказности аналогичной и конкурентной продукции или процессов;
- влияние установки и технического обслуживания на показатели безотказности;
- влияние особенностей пользователя на показатели безотказности;
- предполагаемый план определительных и контрольных испытаний на безотказность, например количество объектов, продолжительность испытаний, условия испытаний, стадия жизненного цикла для проведения испытаний.
E.3 Ремонтопригодность
Вопросы ремонтопригодности, рассматриваемые при анализе надежности, включают:
- требования к ремонтопригодности на каждом уровне технического обслуживания включая все количественные требования в отношении среднего времени восстановления (MTTR) и продолжительности технического обслуживания (ММН);
- совместимость прогнозов показателей ремонтопригодности и проектирования с требованиями или сравнение целевых показателей ремонтопригодности и их распределения с наблюдаемыми;
- анализ ремонтопригодности конструкции, например анализ компромисса между показателями безотказности, ремонтопригодности, обеспеченности техническим обслуживанием, доступности и диагностического оборудования;
- верификация ремонтопригодности с помощью демонстрационных испытаний на ремонтопригодность;
- история обеспечения ремонтопригодности аналогичной и конкурентной продукции или процессов.
E.4 Техническое обслуживание
Вопросы технического обслуживания, рассматриваемые при анализе надежности, включают:
- анализ политики технического обслуживания, касающейся предупреждающего и корректирующего технического обслуживания, уровней технического обслуживания в отношении требований спецификации и требований эксплуатации;
- использование сменных блоков: преимущества и риски идентификации, взаимозаменяемости, требования к доступности, съемности, транспортной упаковке, маркировке и к испытательному оборудованию;
- обнаружение и диагностику неисправностей с помощью встроенного, подключаемого и общего испытательного оборудования;
- простоту технического обслуживания и безопасность задач технического обслуживания;
- обеспечение неинвазивного контроля и измерений;
- прогнозирование и предотвращение неисправностей путем постоянного мониторинга известных измеряемых параметров, таких как энергопотребление или вибрация.
E.5 Обеспеченность техническим обслуживанием
Вопросы обеспеченности техническим обслуживанием, рассматриваемые при анализе надежности, включают:
- идентификацию требований к обеспеченности техническим обслуживанием, т.е. ресурсов, необходимых для выполнения предлагаемой политики технического обслуживания и требований или ожиданий потребителей;
- адекватность плана обеспеченности техническим обслуживанием и определение интерфейсов с другими инженерными задачами;
- персонал, его квалификацию и численность, обеспечивающие техническое обслуживание;
- специализированное диагностическое, ремонтное и испытательное оборудование и инструменты, необходимые на каждом уровне технического обслуживания;
- технические руководства, их доступность и ясность процедур технического обслуживания и ремонта;
- помещения, необходимые для ремонта, хранения запасных частей, обработки материалов, управления и обучения;
- первоначальный объем запасных частей на каждом уровне технического обслуживания для корректирующего и предупреждающего технического обслуживания, наличие и продолжительность задержек для пополнения запасных частей, включая предположения, модели и источники данных, требования к упаковке и маркировке, например к идентификации и указанию срока годности;
- возможную неготовность запасных частей из-за их устаревания;
- систему и процедуры отчетности о выполнении технического обслуживания;
- опыт технического обслуживания и обеспеченности техническим обслуживанием на более ранней и аналогичной продукции;
- затраты на техническое обслуживание и обеспеченность техническим обслуживанием, влияние на стоимость владения и стоимость жизненного цикла, включая определение наиболее существенных факторов затрат и возможных областей для улучшения;
- модемный или аналогичный сетевой доступ к оборудованию для удаленной диагностики экспертами;
- полную и точную проектную документацию и матрицу прослеживаемости требований (RTM) для программного обеспечения.
E.6 Готовность
Вопросы готовности, рассматриваемые при анализе надежности, включают:
- наиболее вероятные причины, например, первые десять причин, по которым продукция находится в неработоспособном состоянии в течение неприемлемого периода времени, определенные с помощью FMEA и/или FTA;
- риск устаревания;
- требования к готовности, например средний коэффициент готовности, мгновенный коэффициент готовности, продолжительность неработоспособного состояния, ресурс;
- сравнение прогнозируемых показателей готовности продукции или процесса с установленными требованиями, включая предположения, модели и источники данных;
- действия по повышению показателей готовности, например компоновку из модулей, введение резервирования, замену компонентов, снижение режимов работы, контроль окружающей среды, использование быстрых отключений;
- историю работы аналогичной и конкурентной продукции;
- влияние условий эксплуатации и обслуживания при эксплуатации на показатели готовности;
- специальное оборудование и инструменты для эксплуатации и технического обслуживания;
- влияние факторов пользователя на показатели готовности, например обучения и готовности персонала, неправильного использования оборудования, незаконного присвоения инструментов и компонентов;
- предполагаемый план определения показателей готовности и испытаний на соответствие установленным требованиям, например количество объектов, условия испытаний, стадия жизненного цикла для проведения испытаний, продолжительность испытаний.
E.7 Обеспечение качества
Вопросы обеспечения качества, рассматриваемые при анализе надежности, включают:
- вопросы, касающиеся потребностей и удовлетворенности потребителей:
- сравнение потребностей заказчика (потребителя) с техническими характеристиками материалов, продукции и процессов;
- валидация конструкции с помощью испытаний опытных образцов;
- способность объекта работать в ожидаемых условиях использования и окружающей среды;
- непреднамеренное использование и злоупотребления со стороны потребителя;
- соответствие объекта нормативным требованиям, национальным и международным стандартам и корпоративной практике;
- сравнение с конкурентными проектами;
- сравнение с аналогичными конструкциями, особенно изучение истории внутренних и внешних проблем, что позволяет избежать их повторения;
- вопросы, относящиеся к спецификациям продукции и требованиям к услугам:
- приемлемые допуски и сравнение их с технологическими возможностями;
- критерии приемки/отклонения;
- простота сборки и монтажа, потребности в хранении, срок годности и распоряжение после его завершения;
- эстетические требования и критерии приемки;
- возможность диагностики и решения проблем;
- требования к маркировке, сигналам опасности, идентификации, прослеживаемости, а также к управлению документацией и инструкциям пользователя;
- анализ и использование стандартных составных частей;
- вопросы, относящиеся к спецификациям процесса:
- технологичность конструкции, включая требования к особым процессам, механизации, автоматизации, сборке и установке компонентов;
- возможность контроля и испытаний продукции, включая требования к специальному контролю и испытаниям;
- требования к поверке и калибровке;
- спецификация материалов, компонентов и узлов, включая утвержденные поставки и поставщиков, а также их возможности по поставкам;
- требования к транспортной упаковке, обработке, хранению и сроку годности, особенно к факторам безопасности входящих и исходящих объектов;
- вопросы, касающиеся верификации конструкции:
- выполнение альтернативных расчетов для верификации правильности первоначальных расчетов и исследований;
- испытания, например с помощью испытаний модели или опытного образца, определение программ испытаний и документирование результатов;
- независимая верификация правильности первоначальных расчетов и других проектных действий;
- управление конфигурацией, адекватность системы идентификации;
- указание серии или даты изготовления, оценка и верификация информации о продукции, расположение записей и перекрестных ссылок, запись кодированной или некодированной информации.
E.8 Воздействие окружающей среды
Вопросы воздействия окружающей среды, рассматриваемые при анализе надежности, включают:
- определение условий окружающей среды, которые могут повлиять на продукцию или процесс, таких как климатические факторы (температура, влажность, сила ветра и осадки), уровень радиоактивности, воздействие химических веществ и последствия их влияния с течением времени, наличие пыли, грибков, электромагнитного излучения и радиочастотных помех;
- определение четкости отражения условий окружающей среды в спецификации;
- определение необходимого учета воздействия окружающей среды на электронные компоненты, механические детали, материалы печатных плат, разъемы, механические конструкции, магнитные носители и т.д.;
- определение соответствия ожидаемых условий в месте использования требованиям спецификации;
- сравнение фактических условий окружающей среды в месте использования с условиями, ожидаемыми при разработке;
- необходимость мониторинга наиболее важных параметров окружающей среды (например, температуры, влажности) в месте использования и разработки рекомендуемых действий;
- умение обслуживающего персонала безопасно работать в конкретных условиях окружающей среды;
- устойчивость к внешним электрическим помехам и переходным процессам электроснабжения, молнии и средствам защиты от этих помех;
- воздействие загрязнений или попадания воды, снега, песка и пыли;
- влияние превышения предусмотренных ограничений параметров окружающей среды на продукцию во время технического обслуживания или во время отключения нагрева/охлаждения;
- необходимость специальной защиты продукции от воздействия окружающей среды или при квалификационных испытаниях.
Примечание - В МЭК 60721-2 (все части) [16] и МЭК 60721-3 (все части) [17] приведено соответствующее руководство по воздействиям окружающей среды, подлежащим рассмотрению;
- лабораторное моделирование для оценки работы продукции в различных условиях окружающей среды;
- критерии испытаний, соответствующие фактическим условиям;
- определение адекватности факторов ускоренных климатических испытаний;
- учет нормальных условий в дополнение к учету аварийных условий и соответствующей сниженной, но все еще приемлемой минимальной производительности в этих условиях.
E.9 Безопасность продукции
Вопросы безопасности продукции, рассматриваемые при анализе надежности, включают:
- обеспечение надлежащей работы аварийных выключателей, средств управления блокировкой, знаков, табличек, автоматических выключателей, прерывателей замыкания на землю, датчиков пара и дыма и проникновения персонала;
- предполагаемое использование продукции, доступ и категории пользователей, включая возрастные группы, осведомленность пользователей о возможных опасностях и физических ограничениях пользователей;
- условия окружающей среды, например диапазон температур, влажности, наличие прямых солнечных лучей и дождя;
- законы, правила и стандарты, регулирующие безопасность конструкции для всех мест использования, в том числе во время технического обслуживания;
- одобрение безопасности внешними органами, включая сертификацию/обеспечение качества;
- угрозы нарушения безопасности, например химических воздействий (коррозионная активность, токсичность и воспламеняемость), взрыва, имплозии, поражения электрическим током, пожара, перегрева, радиации и механических воздействий (опасность ущемления, наличие острых краев);
- риски, связанные с неправильным использованием или злоупотреблением;
- непредвиденные обстоятельства безопасности в процессе производства или управления качеством;
- испытания продукции на чувствительность к ошибкам оператора и безопасность;
- ухудшение безопасности продукции в период между производством и использованием;
- осуществимость и адекватность предупреждений об опасности в инструкции на продукцию и руководстве пользователя;
- оценку приобретенных компонентов на предмет возможных опасностей, испытания и сертификацию третьей стороной;
- оценку характеристик отказоустойчивости;
- необходимость охраны продукции или ее части, тип и объем охраны.
E.10 Человеческий фактор
Вопросы, относящиеся к человеческому фактору, рассматриваемые при анализе надежности, включают:
- особенности и сложность информации, используемой оператором при обработке, контроле и настройке продукции или процесса;
- результативность информационных выходов, включая средства представления информации, используемые оператором для управления продукцией или процессом;
- изменение состояния продукции в соответствии с ожиданиями человека, его нормальные реакции и реакции в аварийных ситуациях;
- адекватность и пригодность предупреждений об опасности и инструкций по эксплуатации, монтажу, техническому обслуживанию, сборке и распоряжению после вывода объекта из эксплуатации;
- анализ восприятия человеком требований к эксплуатации, техническому обслуживанию и поддержке в связи с ожидаемыми и прогнозируемыми условиями окружающей среды (техническое обслуживание, маркировка, рабочее пространство);
- учет удобства работы оператора при использовании продукции;
- видимость приборов, связанных с продукцией;
- доступность средств управления продукцией;
- оценку степени учета навыков и подготовки монтажников, операторов и работников технического обслуживания при разработке продукции или процесса;
- оценку требований к отображению (формат, количество, прокрутка) информации;
- простоту использования программных средств и документации;
- необходимость применения и тип звуковых и визуальных сигналов тревоги для указания работы, состояния и неисправностей, включая распознавание возможной информационной перегрузки или усталости операторов;
- анализ критериев повышения адекватности действий человека и упрощения взаимодействия человека с продукцией;
- адекватность, точность, однозначность, простоту использования и понимание всей документации и иллюстраций, необходимых для эксплуатации и обслуживания продукции, включая доступность на местном языке, использование символов и т.д.;
- квалификацию обслуживающего персонала, которая должна быть учтена при разработке потребностей в обучении;
- возможный риск доступа к продукции неквалифицированных операторов;
- возможные трудности неправильного использования продукции операторами.
E.11 Правовые вопросы
Правовые вопросы, рассматриваемые при анализе надежности, включают:
- юридические отношения и обязательства перед покупателями, поставщиками, субподрядчиками и конечными пользователями;
- соответствие предлагаемой конструкции требованиям контракта (включая спецификации);
- соответствие предлагаемой конструкции соответствующим, связанным с продукцией правилам;
- соответствие предлагаемого графика поставок требованиям контракта;
- определение штрафных санкций за несоблюдение требований контракта;
- определение ответственности за убытки при транспортировании, хранении и установке;
- анализ права собственности и/или лицензирования образцов, патентов, товарных знаков, коммерческой тайны и инструментов;
- анализ информации, касающейся отчетов и юридических выводов о дефектах аналогичных, связанных или конкурентных продукции или процессов;
- анализ информации (например, данных литературы, внутренних испытаний), касающейся опасностей, связанных с аналогичными, связанными или конкурентными продукцией или процессами;
- проверку учета информации при разработке продукции или процессов, касающихся отчетов и юридических заключений в отношении дефектов и опасностей;
- определение того, были ли надлежащим образом доведены до сведения покупателя опасности, обнаруженные в продукции;
- определение адекватности методов информирования покупателей, конечных пользователей и регулирующих органов (при необходимости) об опасностях, обнаруженных после поставки продукции;
- юридические положения, влияющие на необходимость отзыва или модернизации продукции;
- адекватность процедур, используемых для программ отзыва или модернизации (включая прослеживаемость компонентов);
- адекватность и понятность гарантийных обязательств, предоставляемых заказчику;
- анализ сохраненных записей, касающихся конструкции продукции, анализа опасностей и действий по снижению рисков, компетентности персонала, участвующего в проектировании, разработке, производстве и продаже, правильности выполнения этих действий и их соответствия законодательству и положениям контрактов;
- достаточность сроков хранения записей, касающихся продукции;
- оценку технических паспортов, рекламной информации, инструкций и руководств по установке, предупреждений, этикеток и других документов на предмет соответствия и эффективности их содержания;
- достаточность страхования для изготовителя и ключевого персонала по разработке проекта и использованию оборудования;
- оценку ответственности за продукцию и правовые последствия ее использования и утилизации;
- тщательное изучение стандартных условий и положений поставщиков, особенно всех исключений и ограничений;
- оценку ограничений экспорта в выявленные запрещенные страны.
E.12 Долговечность
Вопросы долговечности, рассматриваемые при анализе надежности, включают:
- определение ресурса объекта;
- уточнение цели проекта в отношении ресурса продукции;
- определение или уточнение проектных предположений в отношении эксплуатации или использования в течение всего жизненного цикла продукции;
- сценарий жизненного цикла продукции, включая нормальные, аномальные и частные случаи;
- прогнозирование типа и уровня нагрузок;
- адекватность проектной спецификации;
- стратегию технического обслуживания, такая как использование замен, ремонта, регулировки и подготовки системы поддержки;
- расчетные ограничения по экономике эксплуатации и технического обслуживания;
- параметры, связанные с долговечностью, такие как время, циклы переключения и указанные модели физики отказов;
- требуемый период использования и срок эксплуатации, т. е. планируемый срок эксплуатации, возможный срок эксплуатации, экономичный срок использования, время, необходимое для технического обслуживания;
- прогнозирование потребностей в запасных частях;
- стратегию и план управления устареванием;
- политику и планирование в отношении устаревания (см. МЭК 62402 [6]).
E.13 Безопасность
Вопросы безопасности, рассматриваемые при анализе надежности, включают:
- идентификацию активов, план обеспечения безопасности, структуру и функции организации;
- политику безопасности, сформулированную и выполняемую руководством;
- руководящие принципы и положения, основанные на политике безопасности;
- анализ угроз;
- порядок действий в случае инцидента;
- анализ уязвимостей и сопоставление угроз с уязвимостями - угроза имеет значение только в том случае, если она совпадает с уязвимостью.
E.14 Материальный ущерб
Вопросы материального ущерба, рассматриваемые при анализе надежности, включают:
- упаковку для защиты продукции или системы при транспортировке;
- установку системы/продукции с учетом условий окружающей среды и условий эксплуатации;
- страхование на случай отказа системы или продукции или гарантию безотказности и готовности системы;
- страхование на случай неработоспособности системы или продукции из-за условий окружающей среды, включая природные явления или стихийные бедствия.
E.15 Подотчетность
Вопросы подотчетности, рассматриваемые при анализе надежности, включают:
- определение, документацию и понимание подотчетности;
- индивидуальную, а также корпоративную подотчетность;
- требования к системе, продукции, процессу или услуге;
- установление соответствующих границ для заинтересованных сторон;
- действия и задачи операций и процессов системы;
- действия по проверке выполнения необходимых действий.
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным стандартам
Таблица ДА.1
|
|
|
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
IEC 60050-192 | NEQ | ГОСТ Р 27.101-2021 "Надежность в технике. Надежность выполнения задания и управление непрерывностью деятельности. Термины и определения"
|
| NEQ | ГОСТ Р 27.102-2021 "Надежность в технике. Надежность объекта. Термины и определения" |
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:
NEQ - неэквивалентные стандарты.
| ||
Библиография
|
|
|
[1] | IEC 60300-1:2014 | Dependability management - Part 1: Guidance for management and application
|
[2] | IEC 60300-3-3:2017 | Dependability management - Part 3-3: Application guide - Life cycle costing
|
[3] | IEC 62741:2015 | Demonstration of dependability requirements - The dependability case
|
[4] | IEC 60812 | Failure modes and effects analysis (FMEA and FMECA)
|
[5] | IEC 61025:2006 | Fault tree analysis (FTA)
|
[6] | IEC 62402:2019 | Obsolescence management
|
[7] | IEC 62740:2015 | Root cause analysis (RCA)
|
[8] | IEC 61014:2003 | Programmes for reliability growth
|
[9] | IEC 61508-1:2010 | Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 1: General requirements
|
[10] | IEC 60706-2:2006 | Maintainability of equipment - Part 2: Maintainability requirements and studies during the design and development phase
|
[11] | IEC 61078:2016 | Reliability block diagrams
|
[12] | IEC 62853:2018 | Open systems dependability
|
[13] | IEC 31010:2019 | Risk management - Risk assessment techniques
|
[14] | IEC 60605-6:2007 | Equipment reliability testing - Part 6: Tests for the validity and estimation of the constant failure rate and constant failure intensity
|
[15] | IEC 60300-3-2 | Dependability management - Part 3-2: Application guide - Collection of dependability data from the field
|
[16] | IEC 60721-2 (all parts) | Classification of environmental conditions - Part 2: Environmental conditions appearing in nature
|
[17] | IEC 60721-3 (all parts) | Classification of environmental conditions - Part 3: Classification of groups of environmental parameters and their severities
|
[18] | ISO/EC 20000-1:2018 | Information technology - Service management - Part 1: Service management system requirements
|
[19] | ISO/EC 27000:2018 | Information technology - Security techniques - Information security management systems - Overview and vocabulary
|
[20] | ISO/EC 20246:2017 | Software and systems engineering - Work product reviews
|
[21] | EC/ISO/IEEE 15288:2015 | Systems and software engineering - System life cycle processes
|
[22] | ISO 9000:2015 | Quality management systems - Fundamentals and vocabulary
|
[23] | ISO Guide 73:2009 | Risk management - Vocabulary |
|
|
УДК 62-192:658.51.011:658.562:623:006.354 | ОКС 03.120.01 |
| |
Ключевые слова: надежность, надежность выполнения задания, анализ надежности, стадии жизненного цикла, безотказность, долговечность, ремонтопригодность, техническое обслуживание, обеспеченность техническим обслуживанием, человеческий фактор | |
