Телефон / факс: (499) 308-68-67 istra.info.2010@gmail.com

Планирование экспериментальной отработки, обеспечение надёжности

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

Исходными данными являются:
  • тактико-техническое задание на разработку;
  • научно-технический задел (результаты НИР, ОКР по созданию изделий-аналогов и т.п.);
  • ограничения (регламентирующие по КИМП, технологиям и др., сроки, стоимость).
Требуется: разработать образец ТС, удовлетворяющий имеющимся исходным данным в условиях заданных ограничений.

Можно представить данную постановку в формализованном виде, сформулировать ряд допущений и получить корректное математическое решение задачи в условиях принятых допущений (правда, допущений должно быть столько, сколько в реальной практике не имеет места быть). Будет ли оно иметь практическое значение для Разработчиков? Формализованного единственного решения этой задачи в общем виде не существует. Существует только общий порядок её решения и организационные и технические требования к выполнению его этапов (как обязательные, так и рекомендованные  ГОСТ, ОСТ, РД и др.). В связи с этим складывается достаточно сложная ситуация для оценки Разработчиком потенциальных рисков, с которыми предстоит столкнуться в ходе разработки ТС, и поиска методов их преодоления.

Источники рисков решения данной задачи возникают уже на этапе изучения Разработчиком заданных в ТТЗ количественных требований назначения и принятия решения на разработку. Их причина – в недостоверной оценке адекватности имеющегося научно-технического задела требованиям ТТЗ, о чём может и не подозревать сам Разработчик на данном этапе. Они могут быть оценены количественно на основе классической теории вероятностей (подобные оценки нами неоднократно делались). Аналогичные риски возникают также и при анализе заданных качественных требований. Они труднее поддаются количественной оценке, но всё-таки могут быть оценены, например, на основе аппарата математической информатики. Конечно же, данные риски никто не оценивает, в том числе и по причине отсутствия в коллективах Разработчиков хороших аналитиков, должным образом «подкованных». Отсюда вывод: ощутимое проявление рисков, не оценённых раннее,  возможно только на этапе экспериментальной отработки ТС (если Вы приняли на себя ответственность в данных условиях взяться за разработку и уже приступили к экспериментальной отработке).

Отсутствие возможности оценки и контроля потенциальных рисков чревато для Разработчика  непоправимыми ошибками. Для исключения этих ошибок до прохождения точки «невозврата» (по срокам и затратам) существуют три способа:

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

Из перечисленных трёх способов в руках Разработчика всегда находится только первый, что говорит о том, что, если принимаешь решение на разработку, будь готов на этапе экспериментальной отработки к «неожиданностям» и к тому, что прийдётся их преодолевать и добиваться требуемого результата, опираясь, главным образом, только на собственные силы.

Вот поэтому не придавайте «Комплексной программе экспериментальной отработки» и «Программе обеспечения надёжности» (как планирующим документам) статуса формальных (партийно-политических) из разряда: «раз должен быть – найдём дешёвую «рыбу», слегка адаптируем и представим Заказчику, всё равно он внимательно изучать её не будет, а мы её и выполнять не собираемся». Боком Вам выйдет эта «рыба». Чужих примеров более чем достаточно. Храни Вас, уважаемые коллеги, Судьба от соблазна принять данный подход во имя экономии.

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

Это только кажется, что, например, расчёт надёжности может выполнить каждый. Для РЭА можно бы с этим и согласиться: нехитрые расчётные выражения, основанные на экспоненциальном законе, АСРН или «АСОНИКА» (был бы только справочник новый)... А, если в составе ТС имеется пневматика или гидравлика, запорная арматура, датчики и исполнительные органы, а также специальное математическое и программное обеспечение? Вот здесь и проявится подобное «шапкозакидательство». Только у дилетанта всё легко. Мы можем помочь провести анализ видов, последствий и критичности отказов, разработать математическую модель надёжности, выполнить расчёт надёжности (а также и радиационной стойкости при необходимости). Мы умеем моделировать, анализировать и находить практически приемлемые решения.