Dependability in technics. Dependability management. Guide to the assignment of dependability technical requirements
Дата введения - 1 сентября 2012 г.
Введен впервые
Предисловие
Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"
Сведения о стандарте
1 Разработан Федеральным государственным унитарным предприятием "Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении" (ФГУП "ВНИИНМАШ")
2 Внесен Техническим комитетом по стандартизации ТК 119 "Надежность в технике"
3 Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 14 декабря 2011 г. N 1490-ст
4 Введен впервые
5 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта МЭК 60300-3-4:2007 "Управление надежностью. Часть 3: Руководство по применению - Раздел 4: Руководство по заданию технических требований к надежности" (IEC 60300-3-4:2007 "Dependability management - Part 3 - 4: Application guide - Guide to the specification of dependability requirements")
Введение
Для многих систем безотказность, ремонтопригодность и готовность являются важнейшими характеристиками, которые вместе с обеспечением технического обслуживания составляют надежность.
Необходимо, чтобы эти характеристики были определены и конкретизированы, также как и другие характеристики систем, такие как технические характеристики, размеры, масса и др.
Уровни готовности, безотказности, ремонтопригодности и средств технического обслуживания системы зависят от ее назначения и условий, в которых она работает. Вместе с требованиями к надежности необходимо определить условия хранения, транспортирования, монтажа и эксплуатации, а также стратегию технического обслуживания и организацию его поддержки.
Для оценки значений достигнутых характеристик надежности необходимо использовать статистические методы.
Характеристики надежности могут быть установлены, как и другие рабочие характеристики, техническими условиями:
1) подготовленными поставщиком;
2) выдвинутыми потребителем;
3) взаимно согласованными поставщиком и потребителем.
Настоящий стандарт распространяется на все три вида технических условий.
1 Область применения
Настоящий стандарт представляет собой руководство по заданию требуемых характеристик надежности в техническом задании и технических условиях (далее - спецификации), а также требования к процедурам и критериям верификации и валидации.
Руководящие указания включают в себя:
- рекомендации по количественному и качественному заданию показателей готовности, безотказности, ремонтопригодности и обеспечению технического обслуживания;
- рекомендации потребителям системы относительно того, как обеспечить выполнение поставщиками предъявляемых требований;
- рекомендации поставщикам, помогающие им выполнить требования потребителя.
Методы настоящего стандарта касаются в первую очередь систем и изделий, но они могут быть применены и на уровне отдельных составных частей или компонентов. В настоящем стандарте использован термин "система".
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ Р 27.001-2009 Надежность в технике. Система управления надежностью. Основные положения
ГОСТ Р 27.002-2009 Надежность в технике. Термины и определения
ГОСТ Р 27.301-2011 Надежность в технике. Управление надежностью. Техника анализа безотказности
ГОСТ Р 27.402-2012 Надежность в технике. Планы испытаний для контроля средней наработки до отказа или между отказами
ГОСТ Р 27.403-2009 Надежность в технике. Планы испытаний для контроля вероятности безотказной работы
ГОСТ Р 27.404-2009 Надежность в технике. Планы испытаний для контроля коэффициента готовности
ГОСТ Р ИСО 9000-2008 Системы менеджмента качества. Основные положения и словарь
ГОСТ 27.601-2011 Надежность в технике. Техническое обслуживание и его обеспечение
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодно издаваемому информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по соответствующим ежемесячно издаваемым информационным указателям, опубликованным в текущем году. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящем стандарте применены термины и определения по ГОСТ Р 27.002 и ГОСТ Р ИСО 9000.
4 Основные положения
4.1 Потребность в надежности
Все системы характеризуются определенным уровнем надежности, при этом возможны их отказы и/или необходимо их обслуживание. Если отказы системы возникают слишком часто, то она либо не сможет выполнять требуемые функции, либо устранение этих отказов (ремонт) может стоить слишком дорого. Кроме того, при частых отказах система получает низкую оценку потребителя и вряд ли будет приобретена снова, когда потребуется ее замена. С другой стороны, проектирование и производство систем с высоким уровнем безотказности может быть дорогостоящим, и производить такие системы по экономическим причинам будет нецелесообразно. Таким образом, существует устойчивое равновесие между системами с низким уровнем безотказности, ремонт которых стоит дорого, и системами с высоким уровнем безотказности, которые могут быть дорогими с точки зрения разработки и производства. На рисунке 1 показаны затраты на разработку и эксплуатацию систем с различным уровнем безотказности.
Из рисунка 1 видно, что существует уровень безотказности, для которого расходы в течение всего жизненного цикла системы сведены к минимуму.
На оптимальную безотказность системы могут влиять и другие аспекты, такие как требования к безопасности.
Рисунок 1 - Зависимость стоимости от безотказности
В настоящем стандарте рассмотрены следующие показатели надежности:
- показатель готовности - коэффициент готовности;
- показатели безотказности - вероятность безотказной работы (R(t)), средняя наработка до отказа (MTTF), средняя наработка между отказами (MTBF);
- показатели ремонтопригодности, в том числе среднее время простоя (MDT) и среднее время до восстановления (MTTR);
- поддержка технического обслуживания.
Показатели надежности, выбираемые для спецификаций, должны быть связаны с видом и назначением системы, предусмотренным применением и важностью требуемых функций.
Требования к обеспечению эксплуатационной готовности задают для систем, неработоспособное состояние которых может привести к экономическим потерям, увеличению эксплуатационных расходов, опасности для жизни и здоровья людей или невыполнения задания или услуги, т.е. для больших систем, промышленных предприятий, медицинского оборудования, систем безопасности и военных систем. Показатель обеспечения эксплуатационной готовности рассчитывают с учетом конфигурации системы и ее подсистем, требований к их показателям безотказности и ремонтопригодности и эффективности средств технического обслуживания.
Требования к характеристикам ремонтопригодности задают для систем, если расходы на техническое обслуживание вносят существенный вклад в стоимость на протяжении жизненного цикла или если техническое обслуживание имеет большое значение для потребителя. Могут быть определены требования к профилактическому и корректирующему техническому обслуживанию.
Примечание - Уровень технического обслуживания часто определяется условиями эксплуатации и не является собственно требованием к системе.
Разделы 6 - 9 содержат дополнительную информацию о том, в каком случае каждая из характеристик надежности будет наиболее подходящей.
На уровень свойств надежности системы в большой степени влияют условия, в которых она спроектирована, разработана, установлена и эксплуатируется. Таким образом, надежность связана с другими показателями, такими как качество и процессы разработки и производства. Поэтому характеристики надежности должны быть частью общих спецификаций системы, и взаимодействие между различными показателями и условиями должно быть учтено и установлено.
4.2 Требования и цели
Важно определить различия между формальными требованиями спецификации и целями, так как подходы к их принятию различны.
Требование является частью спецификаций, которым, по мнению потребителя, должна соответствовать система, доказательства чему поставщик должен предоставить, прежде чем начнется эксплуатация системы.
Цель - не требование потребителя, а его стремление или намерение, и доказательства достижения цели предоставлять необязательно.
Для систем с высокой готовностью или безотказностью необязательно предоставлять формальные доказательства достижения высокого уровня готовности или безотказности. Потребитель должен оговорить целевые уровни готовности и безотказности, для которых данные не могут быть предоставлены, а также менее жесткие требования, для которых данные могут быть предоставлены, и внести ясность, что именно необходимо.
4.3 Системы
Спецификации по надежности относятся к уровню системы. Система включает в себя оборудование (как аппаратные средства, так и программное обеспечение), людей, которые эксплуатируют и обслуживают систему, а также среду, в которой она работает, как показано на рисунке 2.
Рисунок 2 - Элементы системы
По возможности все элементы системы должны быть включены в спецификацию, поскольку изменение любого из них может оказать существенное влияние на надежность системы. Например, разные пользователи системы могут неправильно или небрежно обращаться с ней, что приведет к увеличению отказов и к снижению уровня безотказности. Возможны случаи, когда поставщик и потребитель могут слабо или совсем не могут, или не имеют опыта управления техническим обслуживанием системы, например проданного (приобретенного) автомобиля. Требования к надежности должны учитывать конкретные обстоятельства эксплуатации системы.
Наряду с требованиями к техническим средствам спецификации должны содержать требования к программному обеспечению и человеческому фактору.
Многоуровневая система может состоять из систем и подсистем. Это предусматривает рассмотрение взаимодействия людей, которые работают с подсистемами, их действий и способности различных людей подвергать подсистемы различным эксплуатационным нагрузкам. Например, различные водители управляют автомобилем по-разному и подвергают коробку передач бульшим# или меньшим нагрузкам.
Потребитель может выбирать, установить требования к надежности только на самом высоком уровне системы или также установить требования на более низком уровне. Эти требования к надежности более низкого уровня не должны противоречить требованиям высшего уровня и быть измеримыми и достижимыми, иначе они будут целью, а не требованием. Например, вклад подсистемы в общую надежность системы должен быть оценен прежде, чем требования будут распределены по подсистемам.
К восстанавливаемым системам относят те, которые могут быть восстановлены после отказов и могут быть возвращены в рабочее состояние. К невосстанавливаемым системам относят герметичные системы, системы, стоимость ремонта которых превышает стоимость замены, в частности многие потребительские товары.
Невосстанавливаемые системы заменяют, а не ремонтируют, и требования к ремонтопригодности и техническому обслуживанию будут принципиально разными. Кроме того, такой показатель, как средняя наработка до отказа, может не быть релевантным показателем надежности одного отдельного устройства. В этом случае может быть более корректным использование другого показателя - вероятности безотказной работы.
4.4 Демонстрация выполнения требований
4.4.1 Концепция
Любой спецификации присущи два элемента: требования выполнения надежности и средства, с помощью которых поставщик должен продемонстрировать достижение требований потребителю, то есть поставщик должен предоставить достаточные доказательства потребителю, что система отвечает его требованиям, чтобы стимулировать потребителя к приобретению системы. Предоставление дополнительных доказательств требует дополнительных затрат, но без учета этого фактора существует опасность несоответствия системы требованиям.
Демонстрация включает в себя два основных элемента: верификацию и валидацию. Они определены в ГОСТ Р ИСО 9000, используются для систем и программного обеспечения. Верификация представляет собой процесс предоставления доказательств соответствия системы на любой стадии жизненного цикла требованиям предыдущих стадий жизненного цикла, а валидация - это процесс предоставления доказательств соответствия системы фактическим требованиям, которые не всегда могут быть отражены в спецификации.
Уровни верификации и валидации устанавливает потребитель. Предоставление доказательств требует затрат, и потребитель должен принимать сбалансированное решение о приемлемых рисках при указании требований верификации и валидации.
Верификация и валидация должны быть запланированы и проводиться систематически. Требования надежности должны учитывать различные факторы, которые могут повлиять на стоимость верификации и валидации.
Для долгосрочных закупок деятельность по верификации и валидации может быть запланирована на длительный срок в зависимости от условий договора. Один из способов уменьшить проектные риски покупателя и поставщика и обеспечить уровень требуемых доказательств состоит в постепенном проведении верификации и валидации. Это означает, что мероприятия запланированы на протяжении всего жизненного цикла и результаты предоставляются покупателю в отдельных точках реализации проекта. Таким образом, покупатель обретает уверенность на протяжении всего проекта в снижении риска недостаточности уровня доказательств.
4.4.2 Мероприятия
Верификация и валидация охватывают ряд мероприятий, призванных обеспечить доказательства соответствия системы требованиям к уровню надежности.
Если потребитель требует проведения верификации и валидации, поставщик должен определить соответствующие способы. Например, спецификации могут не требовать проведения анализа дерева отказов (FTA), но могут предусматривать анализ для определения комбинации событий, которые могут привести к отказу системы, на основе блок-схемы безотказности. Метод реализации деятельности выбирает поставщик по своему усмотрению с учетом, например, таких факторов, как опыт специалиста-аналитика, располагающего временем, данными и информацией. Например, выполнение анализа блок-схемы безотказности опытным специалистом может быть предпочтительнее FTA, выполненного неопытным специалистом.
Мероприятия верификации и валидации включают в себя:
а) анализ:
1) соблюдение стандартов, правил и руководящих принципов;
2) экспертный обзор передовой практики сертификации;
3) расчеты, используемые для других целей конструкции (например, анализ предельных нагрузок элементов, износа);
4) моделирование (например, свойств системы);
5) различные виды анализа надежности;
б) испытания и демонстрацию:
1) работу идентичных или подобных систем в идентичных или схожих условиях;
2) специализированные испытания на надежность, в том числе:
i) демонстрационные испытания на безотказность, например одноступенчатые испытания, последовательные испытания, ускоренные испытания или испытания на долговечность;
ii) демонстрационные испытания готовности;
iii) демонстрационные испытания ремонтопригодности;
3) другие испытания, проводимые в ходе опытно-конструкторских работ (например, на производительность, долговечность, испытания программного обеспечения системы на уровне модулей или компонентов).
Прогнозирование надежности и результаты анализа, представленные во время разработки, менее точны, чем результаты, полученные входе испытаний. Поэтому потребитель, вероятно, не захочет опираться только на результаты анализа, и может потребовать сочетания анализа и испытаний для доказательства выполнения требований. Кроме того, при планировании испытаний должны быть приняты во внимание окружающая среда и использование системы. В случаях, когда условия испытаний близки к условиям эксплуатации, такие испытания дают хорошую оценку надежности, но они могут длиться очень долго и иметь малое число отказов, что приведет к большой неопределенности в оценке надежности. Если использовать ускоренные испытания, то размер выборки будет увеличен, а время испытания - сокращено. Большее число отказов будет уменьшать статистическую неопределенность, но техническая неопределенность будет выше, так как условия ускоренных испытаний могут привести к появлению режимов и отказов, не связанных с эксплуатационными условиями.
4.5 Заключение контрактов в части надежности
Спецификация обычно является частью договора между потребителем и поставщиком, и поэтому важно, чтобы она была написана в виде, удобном для заключения договоров. Включение в контракты может принимать различные формы. Успешное завершение демонстрационных испытаний зависит от поэтапных выплат с использованием как штрафных санкций, так и стимулов достигнутой штатной безотказности.
Важно проводить различие между требованиями, которые детализируют, как система должна работать, и письменными спецификациями, в которых детализируют, что система содержит. В зависимости от вида системы они могут быть разных уровней сложности и могут быть выполнены потребителем или поставщиком.
При написании положений надежности для контрактов большое внимание должно быть уделено тому, что положения должны иметь смысл и быть реализуемыми. Например, указание в договоре для устройства одноразового использования требования вероятности безотказной работы 99,5% при доверительной вероятности 80% потребует минимум 322 испытаний, что при приобретаемой партии в 50 устройств является явно нереалистичным требованием, и потребитель должен найти альтернативные методы достижения необходимой верификации и валидации, например путем использования более низких уровней безотказности, для которых доказательство может быть предоставлено вместе с дополнительным анализом или моделированием.
Выбор действий верификации и валидации, включаемых в контракт, зависит от уровня проектного риска, который потребитель может принять. Если потребитель согласен рисковать, что система может быть неисправной, но будет обслуживаться поставщиком, то использование штрафов за плохую работу и стимулов повышения требований могло бы быть лучшим методом. Если, однако, потребитель не желает рисковать неготовностью системы, то формальное тестирование безотказности или готовности может быть необходимым.
Преимущества каждого подхода заключаются в следующем:
а) штрафы за плохую работу будут стимулировать поставщиков уделить максимальное внимание надежности, что может привести к ее более высокому уровню;
б) демонстрационное испытание является дорогостоящим и трудоемким и может только выявить в начале эксплуатации несоответствие требованиям надежности;
в) техническое обслуживание, обеспечиваемое поставщиком, требует намного более длительного контракта, например соглашения о техническом обслуживании при фиксированных расходах и связанных с этим трудностях, при этом поставщик рискует, что система не достигнет требуемой безотказности.
Если спецификации надежности будут использоваться в качестве основы для заключения договоров, важно, чтобы спецификации были точными, с тем чтобы предотвратить разногласия в контракте.
Примеры видов элементов, которые должны быть включены в спецификацию для заключения договоров:
- точные и четко определенные критерии, по которым могут быть оценены готовность, безотказность, ремонтопригодность или поддержка технического обслуживания;
- обязанности и ответственность потребителя, поставщика и любых третьих лиц;
- рассматриваемая система, оборудование или сборка, на которые заданы соответствующие требования;
- функция системы;
- различные эксплуатационные и экологические условия, при которых используется система, в том числе, по возможности, относительное количество времени, проведенное в каждом состоянии;
- определение отказа или критерии отказа (полного, частичного или снижения производительности);
- как система будет устанавливаться и использоваться;
- квалификация и обязанности персонала, ответственного за эксплуатацию и поддержку технического обслуживания оборудования, программного обеспечения и документации;
- политика поддержки технического обслуживания и соответствующие процедуры и механизмы поддержки;
- методы, предназначенные для применения верификации и валидации соответствия требованиям, в том числе критерий "принять/отклонить";
- источники данных, которые будут использоваться в любых аналитических методах.
В целях снижения числа отказов и времени неработоспособного состояния системы необходимо сотрудничество поставщика и потребителя на всех стадиях жизненного цикла системы. Это определяет различные обязательства со стороны как потребителя, так и поставщика, которые должны быть указаны.
4.6 Виды спецификаций
На характер поставляемой системы имеет фундаментальное влияние то, кем написаны спецификации. Существуют три основных способа:
- спецификации, написанные поставщиком.
В основном используется для систем, которые должны иметь определенные характеристики надежности, например вероятность безотказной работы, чтобы быть принятыми на рынке;
- спецификации, написанные покупателем.
В основном используется для стандартных систем, которые должны отвечать определенным характеристикам надежности в целях удовлетворения потребностей покупателя;
- спецификации, взаимно согласованные или написанные поставщиком и покупателем.
Обычно используется в случае систем, сделанных на заказ, или изменений в действующей конструкции.
Если в ходе реализации проекта становится очевидным, что основные предположения или требования придется пересмотреть и изменить, то соответственно должны быть изменены и спецификации, причем это должно быть сделано с согласия всех заинтересованных сторон.
Количественные требования должны быть четко определены в форме, предоставляющей возможность сопоставления с результатами, полученными впоследствии.
Если доказательства соответствия количественных требований предоставляют путем испытаний, должен быть указан необходимый уровень достоверности или фактический план испытаний, который будет использован.
Планы испытаний различных видов для демонстрации показателей безотказности приведены в ГОСТ Р 27.402 и ГОСТ Р 27.403.
4.7 Источники для спецификаций
Требования безотказности, ремонтопригодности и готовности в спецификациях всюду, где это возможно, должны быть выражены количественно, но также может быть уместным определение качественных требований. Количественные требования имеют смысл, когда они могут быть измерены в процессе верификации и валидации. Если требование не может быть измерено в процессе предоставления свидетельства, то оно является целью, и обоснование предоставленного свидетельства должно обеспечивать качественные требования.
Данные для спецификаций содержатся в ряде источников, включая:
а) собственные данные поставщика по техническому обслуживанию и услугам;
б) общие базы данных и справочники;
в) данные изготовителя по подсистемам и компонентам.
Спецификации безопасности и окружающей среды непосредственно не рассматриваются в настоящем стандарте. Однако большая часть настоящего стандарта может быть применена к спецификациям безопасности и экологическим спецификациям. Поскольку требования надежности связаны с безопасностью и окружающей средой, соответствующие требования безопасности и окружающей среды должны быть включены в требования к надежности, или должны быть даны соответствующие ссылки.
5 Управление надежностью
Настоящий стандарт касается спецификаций надежности в виде спецификаций одного или больше свойств: готовности, безотказности, ремонтопригодности и поддержки технического обслуживания. Эти величины являются внутренними характеристиками системы, и действия по верификации и валидации могут отражать возможные результаты. Однако другие факторы могут значительно уменьшить достигнутые уровни этих величин ниже предусмотренных уровней. Потенциально самым существенным является качество изготовления и обслуживания системы, которое может вносить дополнительные отказы в систему. Поэтому важно активно управлять надежностью на всех стадиях жизненного цикла системы, включая процесс приобретения и период использования. Необходимые действия по управлению будут различны на каждой стадии. Если надежностью правильно не управлять в процессе приобретения или во время использования, то повышается вероятность того, что требования к свойствам безотказности или готовности не будут достигнуты.
Основные положения по системе управления надежностью даны в ГОСТ Р 27.001
6 Готовность
6.1 Общие положения
6.1.1 Выбор характеристики надежности
Для некоторых систем, особенно сложных, необходимо рассмотреть безотказность, ремонтопригодность и обслуживание в рамках единого процесса. В таких системах более уместно на уровне системы определить требования к готовности, а не отдельные требования к безотказности и ремонтопригодности. Потребитель определяет, какой из видов готовности его интересует или каков риск недостижения необходимого уровня свойства готовности. Обычно используют стационарный коэффициент готовности, но может использоваться средний коэффициент готовности.
Примерами отраслей, где свойство готовности систем может быть главной характеристикой надежности, являются железнодорожный транспорт, телекоммуникационные сети.
Определения показателей готовности даны в ГОСТ Р 27.002.
6.1.2 Соотношения между готовностью, безотказностью и ремонтопригодностью
Показатели готовности, безотказности и ремонтопригодности являются зависимыми величинами. Связь между ними дана в определениях соответствующих терминов в ГОСТ Р 27.002.
Обычно определяют две из трех величин, чтобы гарантировать, что соотношение между продолжительностями работоспособного и неработоспособного состояний является приемлемым. Одно и то же значение коэффициента готовности может быть достигнуто с большими значениями продолжительности работоспособных и неработоспособных состояний или с малыми значениями продолжительности этих же состояний. Например, операционные системы персонального компьютера могут отказывать регулярно, но перезагрузка и перезапуск занимают несколько минут, что дает высокое значение коэффициента готовности. Это может не вполне соответствовать ожиданиям пользователя, но может быть более приемлемым, чем тоже самое значение коэффициента готовности компьютера, который отказывает нечасто, но не доступен для использования в течение нескольких дней после отказа. В то же время для телекоммуникационных сетей значение коэффициента готовности с малыми значениями продолжительности работоспособных и неработоспособных состояний может быть недопустимым при необходимости бесперебойной передачи больших объемов данных.
6.2 Спецификации готовности
6.2.1 Количественные требования
Спецификации готовности задают в виде коэффициента готовности. Следует точно определить, что понимается под коэффициентом готовности, то есть какое время включают в продолжительность неисправного состояния, учтены ли логистические и иные задержки.
Требования к коэффициенту готовности могут быть выражены в виде десятичной дроби или в процентах, например, как средняя продолжительность работоспособного состояния ко времени наблюдения в процентах. Если используют среднее значение коэффициента готовности, то также должен быть указан период времени, за который он измеряется, вместе с другой соответствующей информацией о времени. Например, если требуется среднее значение коэффициента готовности для поездов пригородного сообщения, оно может быть определено как среднее значение коэффициента готовности, измеряемое в течение каждого часа между определенными часами (например, с 7.00 до 10.00 и с 17.00 и до 20.00 с понедельника по пятницу).
При определении количественных требований к коэффициенту готовности обычно суммируют продолжительность неисправного состояния в течение определенного периода времени (например, месяц или год). Если часть времени простоя системы исключается из ответственности поставщика (например, материально-технические или административные задержки), это должно быть указано в спецификации. Структура продолжительности и времени неработоспособного состояния приведена в приложении А ГОСТ Р 27.002
Таблица А.1 приложения А настоящего стандарта содержит примеры количественных требований к показателям готовности.
6.2.2 Качественные требования
Качественные требования к готовности могут включать в себя сочетание качественных требований к безотказности и ремонтопригодности, если невозможно использовать количественные требования. Качественные требования к готовности могут дополнять количественные требования, если количественные требования не могут охватить всех аспектов спецификации, например, если продолжительность неисправного состояния является критической при определенных условиях эксплуатации. При этом вид коэффициента готовности и времена, включенные в продолжительность неисправного состояния, должны быть определены в спецификации.
6.3 Предоставление верификации и валидации коэффициента готовности
6.3.1 Общие положения
В спецификацию должно быть включено положение о верификации и валидации свойства готовности. Подтверждение готовности часто осуществляют не напрямую, а сочетанием доказательств безотказности и ремонтопригодности.
6.3.2 Верификация и валидация путем проведения испытаний
Если верификацию и валидацию будут осуществлять путем проведения испытаний, могут быть применены стандартизованные процедуры испытаний для стационарного коэффициента эксплуатационной готовности, приведенные в ГОСТ Р 27.404. Следует отметить, однако, что при очень высоких требованиях к коэффициенту готовности (например, больше 0,999), очень трудно установить конструктивный план испытаний. Верификация и валидация свойства готовности подсистем могут оказать помощь в этом отношении. Это может быть достигнуто с помощью наблюдений за системными и подсистемными уровнями в модели готовности системы. В любом случае возможности методов, применяемых для верификации и валидации требований высокого уровня к коэффициенту готовности, должны быть обоснованы.
6.3.3 Верификация и валидация путем анализа
Если верификацию и валидацию будут проводить аналитическими методами, то расчеты должны быть основаны на признанных источниках данных, результатах, полученных благодаря опыту работы на аналогичных системах, изучению эксплуатационных условий, лабораторных испытаний или программно-аппаратной интеграции. Данные должны быть согласованы между поставщиком и потребителем, и источники данных должны быть занесены в спецификацию.
7 Безотказность
7.1 Общие положения
Для некоторых систем целесообразно указать отдельно требования к безотказности и ремонтопригодности. Безотказность представляет собой способность системы выполнять необходимые функции без отказов в данных условиях в заданном интервале времени. Это свойство наиболее правильно описывается вероятностью безотказной работы. Однако можно определять безотказность за счет использования альтернативных величин, таких как средняя наработка до отказа или средняя наработка между отказами.
К отраслям, где свойство безотказности может быть основной интересующей характеристикой надежности, относятся авиационно-космическая промышленность, когда после вылета самолета важно, чтобы он завершил свой полет без полного отказа, автомобильная промышленность, когда водитель должен достичь пункта назначения, а необходимость осуществления ремонта может быть отложена до момента прибытия в пункт назначения.
Примером, где средняя наработка до отказа - наилучший показатель безотказности, являются электрические лампочки. Другим примером может быть производственный процесс, когда система постоянно работает, и наработка до отказа имеет важное значение для планирования работ по техническому обслуживанию.
Потребитель должен проверить, что соответствующие показатели безотказности определены и требования к используемым статистическим процедурам понятны. Например, если указана вероятность безотказной работы 99% в течение одного года, то это может показаться целесообразным. Однако это значение не следует приравнивать к средней наработке до отказа 871613 ч (или более 99 лет) в предположении, что интенсивность отказов постоянна.
7.2 Спецификации безотказности
7.2.1 Количественные требования
Количественные требования к свойству безотказности должны быть уточнены до начала разработки системы. Для статистического подтверждения показателя безотказности должна быть указана достоверность, с которой требование должно быть продемонстрировано или установлено.
В первую очередь следует рассмотреть механизм отказов, которому подвергается система, так как это позволит определить, какие из показателей безотказности уместны и целесообразны. Например, двигатели автомобилей отказывают скорее из-за израсходованного ресурса, а не из-за срока службы, так что километраж пробега является соответствующей единицей измерения. Кроме того, они изнашиваются так, что предположение о постоянном параметре потока отказов является недопустимым. Бытовые электрические лампочки в большей степени отказывают относительно числа включений и выключений и в меньшей степени относительно количества часов горения, что нужно учитывать в определяемом эксплуатационном сроке службы. Наличие избыточных элементов является еще одним фактором, который влияет на выбор показателя безотказности.
Для любой системы необходимо выбрать и определить все требуемые характеристики безотказности и указать количественные требования для каждой характеристики. При определении количественных требований к системе важно учитывать следующие факторы:
- режимы применения системы;
- критерий или определение отказа, то есть то, что представляет собой отказ в данной системе в заданном режиме;
- условия эксплуатации;
- условия окружающей среды.
При установлении в спецификации значения показателя безотказности должны быть приняты во внимание следующие факторы:
- ограничения, налагаемые технологическим состоянием области техники, видом и сложностью системы;
- опыт покупателя в эксплуатации и техническом обслуживании конкретного вида системы;
- возможность проверки указанного требования;
- уровень безотказности узлов, компонентов и т.д., из которых система может быть изготовлена;
- стоимость проектирования, производства, контроля и проверки системы с заданным уровнем безотказности.
Таблица А.2 приложения А настоящего стандарта содержит примеры количественных требований к показателям безотказности.
7.2.2 Качественные требования
Качественные требования к безотказности могут быть выражены одним или обоими из следующих способов:
- конструкторские решения для системы;
- действия по повышению безотказности, применяемые на стадиях жизненного цикла системы.
Конструктивные критерии для системы, такие как физические, требования производительности и эксплуатационные критерии, обычно даются отдельно, но они также могут быть дополнением к количественным требованиям безотказности. Такие критерии могут косвенно налагать требования к безотказности к самой системе и способам установки системы и контроля ее производительности. Например:
- признак одиночной неисправности, то есть состояние системы, когда одиночный отказ может привести к критическому состоянию системы;
- признак накапливающейся неисправности, то есть состояние системы, когда невыявленный отказ в сочетании с дополнительными отказами может вызвать отказ системы;
- разделение путей, обеспечение независимости резервных подсистем за счет использования отдельных путей, кабелей, волноводов и т.д. для сигнальных каналов, питания и других средств поддержки;
- мониторинг критических функций, то есть должна быть предусмотрена автоматическая или ручная проверка критических функций непрерывно или с интервалами, в целях поддержания заданного уровня безотказности.
В дополнение к определению количественных требований безотказности может быть целесообразным указать последовательность действий по усовершенствованию безотказности (и ремонтопригодности), которые будут осуществляться на стадиях жизненного цикла системы. Такие качественные требования могут быть применены для оборудования, программного обеспечения и поддержки. Эти мероприятия особенно важны, если количественные требования не охватывают всех аспектов обеспечения безотказности системы. Они должны быть согласованы между потребителем и поставщиком как технически, так и с точки зрения графика времени и затрат.
План обеспечения безотказности должен быть адаптирован в соответствии с характером системы и требованиями и, как правило, включать в себя:
- виды применяемых методов анализа;
- программу повышения безотказности (в случае необходимости);
- спецификацию по проверке соответствия требованиям (или любые другие качественные и/или количественные меры, которые будут использованы для выражения степени соответствия требованиям);
- критерии выбора компонентов и меры по обеспечению качества данных;
- анализ наихудшего случая.
7.3 Верификация и валидация безотказности
7.3.1 Общие положения
Спецификация должна содержать методы, которые будут использованы для предоставления доказательств выполнения указанных требований.
Верификация и валидация безотказности могут быть осуществлены либо на основе анализа в ходе проектирования и перед производством путем проведения лабораторных или полевых испытаний после производства, либо оценкой эксплуатационной деятельности после поставки. Кроме того, верификация и валидация возможны в ходе осуществления других видов деятельности в процессе разработки. Примеры включают в себя анализ проектирования (такой, как анализ нагрузок), испытание функционирования, испытание программного обеспечения и моделирование эксплуатации. Доказательства могут быть собраны из всех источников в целях обеспечения верификации и валидации.
7.3.2 Верификация и валидация при испытаниях
Предпочтительные методы верификации и валидации безотказности путем испытаний, как правило, выбираемые по согласованию между потребителем и поставщиком, включают в себя:
- сбор и анализ данных отказов системы в эксплуатации. При этом требуется сбор достаточного числа данных, что может быть слишком поздно в процессе закупок;
- испытание системы в эксплуатации или в лаборатории в соответствии с планами и правилами испытаний по ГОСТ Р 27.402, ГОСТ Р 27.403.
При планировании лабораторных испытаний важно рассмотреть зависимые факторы, такие как стоимость и время.
Требования к испытаниям должны отражать эксплуатационные и экологические условия и нагрузки, которые система будет испытывать, в противном случае результат не будет отражать в ходе эксплуатации реальную надежность системы.
Должны быть определены точные критерии отказов аппаратных средств и программного обеспечения, чтобы все отказы были классифицированы в соответствующих категориях. Эта классификация лежит в основе принятия или отклонения решений, и очень важно, что она должна быть четко и ясно указана до начала испытаний. Желательно определить ее в начале жизненного цикла, чтобы не было подозрений, что результаты были скорректированы для обеспечения желаемого результата. Однако может оказаться невозможным определить все критерии до поздних стадий жизненного цикла системы.
Верификацию и валидацию показателей безотказности для ремонтируемых и неремонтируемых систем следует рассматривать отдельно.
ГОСТ Р 27.403 содержит планы испытаний, если в качестве показателя безотказности используют вероятность безотказной работы, и ГОСТ Р 27.402 содержит планы испытаний, если в качестве показателя безотказности используют среднюю наработку до отказа или между отказами.
7.3.3 Верификация и валидация путем анализа
Верификация и валидация безотказности системы могут быть сделаны до ее поставки путем расчетов на основе анализа. В некоторых случаях (например, для систем, обладающих очень высоким уровнем безотказности) это может быть единственным практическим подходом. Анализ может быть использован задолго до проверки безотказности в эксплуатации или в лабораторных испытаниях. В таких случаях только с помощью анализа можно определить, достигает ли рассматриваемая система соответствующих требований, изложенных в спецификации, хотя анализ не измеряет реализованную безотказность напрямую.
Примеры аналитических методов верификации и валидации безотказности системы, включая аппаратное и программное обеспечение, включают в себя методы, приведенные в ГОСТ Р 27.301. Аппаратная часть системы должна быть проанализирована, с тем чтобы установить, что уровень отказов каждой из ее подсистем, частей и электронных или других компонентов учтен в предполагаемых вариантах использования. Для этой цели могут быть необходимыми электрические, тепловые и другие измерения.
Программное обеспечение в системе должно быть точно так же проанализировано в целях выявления возможных сбоев. Данные для таких расчетов могут быть основаны, например, на результатах, полученных из опыта работы с подобными системами, по результатам лабораторных испытаний и из признанных источников данных. Если потребитель намерен указать использование определенной базы данных (например, особенности банка данных отказов), то это должно быть согласовано с поставщиком. Указание использования определенной базы данных, однако, не освобождает поставщика от его обязательств по достижению требуемых характеристик надежности. Во всех случаях исходные данные должны быть определены и допущения, использованные при оценке, записаны.
8 Ремонтопригодность
8.1 Общие положения
Ремонтопригодность является важным показателем надежности для всех видов восстанавливаемых систем и отражает способность системы быть сохраненной в состоянии или восстановленной до состояния, в котором она может выполнять требуемую функцию (например, промежуточные обновления программных средств систем в удаленных местах, которые трудно поддерживать). Кроме того, ремонтопригодность может иметь значительное влияние на достигнутую надежность, особенно в системах, не содержащих избыточности.
8.2 Спецификации ремонтопригодности
8.2.1 Количественные требования
Может быть необходимым указать требования к корректирующему и профилактическому обслуживанию отдельно, так как поддержка их технического обслуживания может сильно отличаться.
Если количественные требования указывают, то важно определить, как долго можно допустить неработоспособное состояние системы из-за технического обслуживания. Это время должно быть указано в соответствующих показателях, таких как среднее или квантиль времени ремонта, или среднее или квантиль логистической задержки. Количественные требования могут быть указаны также в терминах расходов на техническое обслуживание за определенное время или же расходов на техническое обслуживание за единицу времени эксплуатации.
Полная спецификация требований к ремонтопригодности должна охватывать пять основных областей:
- характеристики ремонтопригодности, которые должны быть достигнуты при разработке системы;
- ограничения, которые возникают при эксплуатации системы и будут влиять на техническое обслуживание;
- требования к программе обеспечения ремонтопригодности, которую поставщику предстоит выполнить для гарантии соответствия поставляемой системы требуемым характеристикам ремонтопригодности;
- требования доступа к техническому обслуживанию;
- обеспечение планирования поддержки технического обслуживания.
При определении требований ремонтопригодности важно указать на следующие обстоятельства:
- различные эксплуатационные и экологические условия, при которых работает система;
- квалификация, обязанности и физические данные персонала, ответственного за эксплуатацию и техническое обслуживание системы;
- применяемый принцип обслуживания, соответствующие процедуры и меры поддержки (например, профилактика или диагностическое тестирование);
- имеющийся инструмент и любой специальный инструмент;
- предоставляемый запасный инструмент и принадлежности.
Спецификация на ремонтопригодность должна детализировать требования и методы подтверждения. Она также должна включать в себя четкие определения используемых терминов со ссылками на стандарты и словари, к которым можно обращаться в случае необходимости.
Требования к ремонтопригодности могут быть указаны в спецификации как цель или как определенные требования, которые должны быть подтверждены в соответствии с установленными процедурами. Цели или требования могут быть заданы количественно или качественно.
Спецификация на характеристики ремонтопригодности обычно охватывает различные аспекты обеспечения ремонтопригодности на различных уровнях эксплуатации. Однако поскольку характеристика ремонтопригодности как характеристика системы влияет на расходы по техническому обслуживанию, а также может влиять на сроки обслуживания на разных его уровнях, требования должны быть включены в спецификацию, охватывающую результаты, достигаемые на всех уровнях, затрагиваемых политикой технического обслуживания.
Таблица А.3 приложения А настоящего стандарта содержит примеры количественных требований к ремонтопригодности.
8.2.2 Качественные требования
Если требования к поддержке ремонтопригодности не могут быть определены количественно, как дополнение следует использовать качественные требования. Однако, как и со всеми характеристиками надежности, могут быть заданы как количественные, так и качественные требования. Это может быть, например, указанием в спецификации на степень соответствия системы конкретным условиям и ограничениям, связанным с техническим обслуживанием.
8.3 Верификация и валидация ремонтопригодности
Большая часть верификации и валидации ремонтопригодности может быть осуществлена путем других исследований или анализа в ходе опытно-конструкторских работ.
Верификация и валидация характеристик ремонтопригодности - это процесс определения того, что требования, указанные в спецификации, выполнены. Методы и процедуры верификации и валидации должны быть указаны совместно с требованиями к ремонтопригодности. Методы верификации и валидации могут варьироваться от предоставления поставщиком соответствующих данных или информации до требования выполнения специальной демонстрации ремонтопригодности.
Верификацию и валидацию ремонтопригодности следует рассматривать как непрерывный процесс. Данные, относящиеся к ремонтопригодности, следует получать, собирать и оценивать по мере того, как он и становятся доступными входе развития проекта, и эти результаты следует постоянно сравнивать с заданными требованиями к ремонтопригодности.
Применяют несколько методов проверки характеристик ремонтопригодности:
- анализ и обзор характеристик ремонтопригодности;
- специальные исследования;
- демонстрационные испытания;
- обзор опыта эксплуатации.
Спецификация может дать рекомендации или указать, какой из этих методов следует применять.
9 Поддержка технического обслуживания
9.1 Общие положения
Средства технического обслуживания определяют способность организации, занимающейся техническим обслуживанием, обеспечить ресурсы, необходимые для технического обслуживания системы, то есть когда и где это необходимо и когда средства технического обслуживания служат решающим фактором обеспечения надежности систем. Средства технического обслуживания очень часто зависят от условий эксплуатации и факторов, которые изменяются на протяжении всего жизненного цикла.
Средства технического обслуживания могут предоставляться полностью или частично поставщиком, потребителем системы или третьей стороной, в зависимости от характера спецификации. Следовательно, спецификация будет зависеть от источника технического обслуживания. Комплексное материально-техническое обеспечение - метод, с помощью которого предоставляются все услуги по логистике и который рассматривают как неотъемлемую часть разработки продукта. В других случаях, особенно когда системы построены главным образом на коммерческом оборудовании, поставщики предоставляют только основное или стандартизованное планирование средств технического обслуживания, а потребители берут на себя ответственность за предоставление необходимого технического обслуживания и его средств для конкретных областей применения, частое использованием внутренних ресурсов (см. ГОСТ Р 27.601).
В тех случаях, когда средства технического обслуживания предоставляются поставщиком, они должны быть указаны как часть поставки. Средства технического обслуживания, предоставляемые потребителем (пользователем), входят в заданные условия эксплуатации системы в качестве предпосылки для заявленных значений безотказности, готовности и ремонтопригодности.
9.2 Спецификации по поддержке технического обслуживания
9.2.1 Количественные требования
Требования к средствам технического обслуживания по возможности должны быть указаны количественно. Примерами таких количественных спецификаций являются гарантируемое время выполнение заказа, средняя административная задержка, средняя задержка материально-технического обслуживания, вероятность нехватки или задержка поставки запасных частей.
При задании требований к поддержке технического обслуживания важно установить следующее:
- различные эксплуатационные и экологические условия, при которых система эксплуатируется;
- обязанности и ответственности потребителя, поставщика и третьих лиц;
- используемая политика технического обслуживания и соответствующие процедуры и средства;
- доступный и специальный инструмент или требуемые приспособления;
- квалификация, обязанности и физические данные персонала, ответственного за эксплуатацию и техническое обслуживание системы.
Спецификации на средства технического обслуживания должны быть подготовлены до начала разработки системы и обновлены до сдачи системы.
Таблица А.4 приложения А настоящего стандарта содержит примеры количественных требований к средствам технического обслуживания.
9.2.2 Качественные требования
Если количественные требования к средствам технического обслуживания не могут быть установлены, то следует указывать качественные требования. Однако, как и со всеми характеристиками надежности, могут быть указаны как количественные, так и качественные требования. Это могут быть, например, спецификации на требуемый уровень подготовки и квалификации, стандарт на обслуживающий персонал или требования к доступности оборудования и инструмента.
9.3 Верификация и валидация технического обслуживания
Методы верификации и валидации технического обслуживания тесно связаны с верификацией и валидацией ремонтопригодности и маловероятно, что они могут быть разделены, поскольку характеристики ремонтопригодности зависят от доступных средств технического обслуживания.
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Национальный стандарт РФ ГОСТ Р 27.003-2011 "Надежность в технике. Управление надежностью. Руководство по заданию технических требований к надежности" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 14 декабря 2011 г. N 1490-ст)
Текст ГОСТа приводится по официальному изданию Стандартинформ, Москва, 2013 г.
Дата введения - 1 сентября 2012 г.