На первый взгляд вопрос может показаться наивным - если кто-то что-то делает, значит это кому-то нужно. На самом деле всё чуть более интересно. Давайте попробуем разобраться!
Что вообще такое расчёт надёжности? Если очень кратко, это процесс определения численных показателей, характеризующих такие составные части надёжности, как безотказность, долговечность, сохраняемость и ремонтопригодность. Каждый из этой прекрасной четверки (безотказность, долговечность, сохраняемость, ремонтопригодность) имеет свои показатели. Про это я напишу как-нибудь отдельную статью, а сейчас, чтобы не растекаться мыслью по древу, скажу лишь, что на практике чаще всего требуется численно определить такие показатели безотказности как вероятность безотказной работы и/или наработку на отказ.
Помимо единичных показателей надёжности есть ещё и комплексные показатели, такие как, например, коэффициент готовности (Ктг), связывающий между собой наработку на отказ и время восстановления. Данный показатель очень важен, поскольку позволяет определить время простоя оборудования, а это уже прямая связь надёжности и экономики: зная сколько простаивает из-за отказов наше оборудования и зная стоимость часа простоя оборудования, мы можем посчитать финансовые убытки. А если мы знаем стоимость технических решений, позволяющих повысить Ктг, и понимаем, что это дешевле или сопоставимо по стоимости, чем терпеть убытки из-за простоев, мы можем обоснованно защищать свои технические решения по повышению надёжности. Но я это я снова отвлекся.
Итак, для чего же все-таки люди в организациях считают надёжность своих изделий?
1 причина. Есть некая организация, скажем, конструкторское бюро, проектирующее, допустим, хорошие источники бесперебойного питания. В сильных организациях, где культура разработки находится на высоком уровне, всегда перед началом работы выпускается и согласуется со всеми ключевыми лицами такой документ, как Техническое задание (ТЗ), в котором чётко прописывается, что новое устройство должно делать, как оно должно это делать, в каких условиях и так далее. А может быть такая ситуация, что ТЗ спускается сверху, от вышестоящей организации и/или приходит от внешних Заказчиков, подрядчиков и т.д. И в этом важном и полезном документе, как правило, создается специальный раздел "требования по надёжности", где прописывается, что данный агрегат, техническая система или комплекс должны иметь такие-то показатели надёжности и эти показатели должны быть подтверждены расчётом в соответствии с таким-то ГОСТ.
Пример: система аварийного электроснабжения должна иметь вероятность безотказной работы (ВБР) 0,95 в течении 36 часов. Данный показатель должен быть подтвержден расчетом надёжности, выполненным согласно ГОСТ 27.301-95.
Разумеется, в зависимости от специфики оборудования могут быть совершенно другие цифры, другие показатели и другие ГОСТ (пожарные, энергетические, военные, авиационные и т.д.).
Эта задача передается в работу в отдел надёжности данной организации.
В 99% случаев мои Заказчики приходят ко мне за расчётом надёжности именно по первой причине - они много лет успешно проектировали и/или производили свою технику, но вот к ним обратился новый клиент, в ТЗ которого есть требования расчёта надёжности, а они (мои Заказчики) никогда ничего подобного не делали и не знают с какого конца вообще за эту задачу браться. Или делали, но очень давно, а специалиста по надёжности в штате нет.
То есть по сути, цель расчёта - выполнить требования Заказчика, а кто является заказчиком - твоя собственная организация или внешний подрядчик - уже не столь важно. Важно другое - как будет интерпретирован результат расчёта. И здесь возможны три разных исхода:
1 исход. Расчёт показал, что требования ТЗ выполняются. Как в нашем примере: ИБП должен был иметь ВБР 0,95 на 36 часов непрерывной работы, а расчёт показал, что ВБР 0,96. Это хороший исход. Ничего больше делать не нужно, можно подписывать документы и идти пить чай.
2 исход. Расчёт показал, что требования ТЗ перевыполняются. Как в нашем примере: ИБП должен был иметь ВБР 0,95 на 36 часов непрерывной работы, а расчёт показал, что ВБР 0,99999. Этот исход тоже хороший, но он показывает, что конструктора перезаложили надёжность. То есть конструкцию нашего ИБП можно упростить, убрать резервирование, если оно было заложено на этапе проектирования, удешевить наш ИПБ.
3 исход. Расчёт показал, что требования ТЗ не выполняются. Как в нашем примере: ИБП должен был иметь ВБР 0,95 на 36 часов непрерывной работы, а расчет показал, что ВБР 0,6. Это уже не очень хороший исход. И расчёт надёжности как раз покажет, из-за чего такая низкая надёжность: может быть использованы слишком ненадёжные элементы (расчёт надёжности позволит сформировать их список), может быть отсутствует резервирование (расчёт надёжности может показать, где и какой тип резервирования будет оптимальным), может быть слишком жёсткие условия эксплуатации, а может быть всё вместе. А вот дальше всё зависит от того, как на предприятии построена культура проектирования и качества продукции.
На хорошем предприятии поступят следующим образом: заменят низконадёжные элементы на более высоконадежные и/или введут резервирование элементов, отказ которых гробит всю надёжность. В крайнем случае, если ничего невозможно сделать, то будет скорректировано ТЗ в части надёжности в сторону снижения требований. А как поступят на не самом лучшем предприятии? Специалисту по надёжности скажут примерно следующее: давайте вы как-нибудь нам натянете результат до нужной цифры, мы документы подпишем и вопрос закроем. А что потом будет с этим изделием или этой системой - уже не наша головная боль. Думаю последствия таких решений очевидны. Кстати, именно поэтому я убеждён, что отдел надёжности не должен напрямую подчиняться главному конструктору, а быть независимым подразделением. Ну и именно поэтому у многих инженеров такое отношение к специалистам по надёжности - они что-то там поколдовали и всё стало надёжным, хотя по факту это не так.
Первая причина расчёта надёжности может быть тесно связана ещё и таким важным моментом, как сертификация. Я не стал выделать её в отдельную причину, постараюсь пояснить кратко. В некоторых отраслях есть жёсткие требования, чётко регламентирующие, что если ты хочешь быть поставщиком того или иного оборудования, твоя техника должна иметь надёжность не ниже, чем сказано в стандарте. Например, существуют стандарты Россетей, в которых прописаны конкретные цифры по ВБР на электросчетчики, трансформаторы и другое энергетическое оборудование.
2 причина - значительно более редкая, но тоже встречающаяся. У проектной организации ещё нет чёткого ТЗ на разработку новой системы, прибора или агрегата, но о надёжности они уже думают. И пока требования по надёжности не превратились в конкретные цифры, но есть понимание, что, скажем, на производственном участке каждый день в течении месяца непрерывно должны работать 30 единиц оборудования конкретной модели (машин). Для выполнения плана работ допускается отказ 2 единиц из 30. В таком случае расчёт надёжности может решить следующие задачи: расчётным путем сформировать требования по надёжности к подсистемам данных машин, определить степень резервирования компонентов на уровне подсистем наших машин, определить сколько машин необходимо держать в резерве и т.д. Такие задачи намного сложнее, чем расчеты по 1 причине, но и намного интереснее.
3 причина - тоже редкая, но имеющая место быть, являющаяся комбинацией 1 и 2 причины. Чёткого ТЗ ещё нет, чёткого понимания конструкции тоже нет, но инженеры уже хотят видеть (если это хорошие инженеры) слабые места конструкции, где резерв добавить, где его убрать. Хотят понять, какая вообще получается примерная надёжность, чтобы можно было сравнить, например, с аналогами, существующими на рынке. Вообще подобную задачу лучше решать через АВПКО - анализ видов, последствий и критичности отказов (напишу про него отдельно), но предварительный расчёт надёжности тоже может помочь в этом.
4 причина, с которой я столкнулся совсем недавно, по сути это подвид 1 причины, но мне бы хотелось сказать про неё отдельно. Одна компания решила поучаствовать в тендере на поставку оборудования и в техническом задании были прописаны требования по надёжности. Более того, компания этот тендер выиграла! Но, как это часто бывает, перед подачей заявки на участие в тендере о надёжности никто не думал и никак её не оценивал. В итоге они обратились ко мне, чтобы я сделал им расчёт, результат которого отвечает на вопрос - удовлетворяет ли оборудование ТЗ или нет. Расчёт показал, что не удовлетворяет, при чём очень сильно. Условно по требованиям наработка до отказа должна была быть 60000 часов, а по расчёту получалась всего лишь 800 часов. Когда я озвучил эти цифры инженерам компании, они не удивились, а лишь развели руками и сообщили, что фактически их оборудование в непрерывном режиме работает без отказов в среднем 1 месяц, как раз те самые 720-800 часов, то есть мой расчёт был верным. Для повышения надёжности и достижения желаемых 60000 часов требовалось бы полное изменение конструкции установки, на что уже не было ни времени, ни денег. Далее вопрос уже перетекал из технической плоскости в практическую. Можно конечно было предъявить конечному покупателю оборудования липовый расчёт, в котором наработка 60000 часов, но фактически тогда пришлось бы разориться командировках для своих сервисных инженерах и запчастях для устранения отказов. Это не считая репутационных потерь перед покупателями оборудования, которые прекрасно видят все простои купленной установки.
Если вы дочитали до этого места, вы молодец. И если вы когда-нибудь будете участвовать в тендере на поставку техники, в котором будут прописаны требования по надёжности - не поленитесь оценить реальную надёжность вашего оборудования перед подачей заявки на тендер. Спасете и свои нервы, и деньги, и время.
Выводы: расчёт надёжности нужен проектным организациям, конструкторским бюро, самозанятым разработчикам, изобретателям.
Расчёт надёжности нужен чтобы: 1. подтвердить требования по надёжности из ТЗ. 2. предложить решения и внести изменения в конструкцию если надёжность слишком низкая (ТЗ не выполняется) или слишком высокая (ТЗ перевыполняется). 3. Сформировать требования по надёжности к комплексу в целом и его составным частям в зависимости от требований по количеству доступных единиц техники (или требований по доступности сервиса, например для задач связи и телекома). 4. Понять нужные ли резервы и если да, то какие и где. 5. Определить слабые места конструкции и сформировать решения по повышению надёжности. 6. Пройти сертификацию оборудования и выйти на новые рынки сбыта.
Надеюсь, статья была вам интересна. Буду признателен за ваши комментарии и возможные вопросы.
Если перед вами или перед вашей организацией стоят подобные задачи - я буду рад помочь. Так же, если вас интересует обучение по надёжности - обращайтесь.
С уважением, инженер по надежности