Статус документа
Статус документа

ГОСТ Р 27.405-2011 Надежность в технике (ССНТ). Отбраковочные испытания на ранние отказы сложных систем, изготавливаемых в единичных экземплярах

     4 Основные положения


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

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

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

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

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

Таким образом, термин "скрытая неисправность" в настоящем стандарте используется для определения слабых мест аппаратных средств и ошибок ПО.

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

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

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

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

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

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

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

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

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