Текст книги "Инновации от идеи до рынка"

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

• В формулировке требования должно быть указаны слова, что «продукт должен» (делать, выполнять, работать, обеспечивать, взвешивать), за которыми следует описание того, что должно быть сделано.

• Требование должно быть недвусмысленным, четко сформулированным и полным. В нем должно быть точно указано, что должно быть выполнено, уровень достижения и условия, в которых оно должно применяться. Формулировка должна свести к минимуму путаницу и различия в его интерпретации между разными специалистами.

• Требование должно использовать согласованную терминологию для обозначения продукта и его компонентов более низкого уровня.

• В требовании должна быть четко указана его применимость и необходимые детали: ситуация, среда, условия эксплуатации, продолжительность времени, приоритеты, характеристики пользователей, при которых продукт будет функционировать.

• Требование должно поддаваться верификации с помощью четко определенного испытания, испытательного оборудования, процедуры тестирования или независимого анализа.

• Требование должно быть выполнимым без чрезвычайного количества времени и затрат на разработку.

• Требование должно быть согласованным и прослеживаемым с другими требованиями выше и ниже в системной иерархии.

• Каждое требование должно быть независимым от других требований. Эта характеристика поможет контролировать и уменьшить изменчивость параметров продукта и, следовательно, его характеристик.

• Формулировка каждого требования должна быть краткой, с минимально полной информативностью.

После выявления требований проводят их анализ. Необходимо понять, что действительно нужно пользователям, и получить полную картину, как система будет использоваться, когда она будет построена. Избыточность системы или программного обеспечения является следствием того, что цели продукта и требования пользователей плохо определены. Часто не налажено взаимодействие между пользователями и разработчиками системы в ходе проектирования. При руководстве разработками новых продуктов необходимо при принятии каждого решения учитывать знания конечных пользователей, их желания, способности и уровни навыков, отраженные в документе «Концепция эксплуатации». Эти данные следует включать в требования верхнего уровня системы. Типовыми инструментами здесь являются сценарии использования, или описания применения системы пользователями. По ним можно представить действия пользователя и функции системы, изучить и обсудить потенциальные проблемы с предполагаемым использованием системы. Одним из важных аспектов этого этапа анализа является преобразование требований пользователей в количественные технические показатели эффективности. В процессе, который называют развертыванием функции качества (QFD11
  QFD: Разработка продукции и технологических процессов на основе требований и ожиданий потребителей, Ю. А. Вашуков, А. Я. Дмитриев, Т. А. Митрошкина. – Самара: Изд-во Самарского гос. аэрокосм. ун-та, 2012. – 32 с.


[Закрыть]), выполняют преобразование голоса потребителя (требований и ожиданий) в технические характеристики продукции и рабочие инструкции. Потребности клиентов могут быть сформулированы расплывчатыми и качественными терминами, их нелегко измерить. QFD переводит эти требования с языка заказчиков на язык инженеров, перед которыми стоит задача разработки решений. Термин «развертывание» относится к распределению требований от верхнего уровня системы на подсистемы, модули, компоненты, программное обеспечение и материалы, а также на процессы их изготовления и сборки в производстве. Обширную литературу по использованию функции развертывания качества можно найти в интернете.

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

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

Требования верхнего уровня далее распределяют по более низким уровням. Распределение требования верхнего уровня вниз по потоку включает присвоение элемента системы требованию или разделение требования и присвоение части требования каждому отдельному элементу более низких уровней (например, масса объекта, разделенная на части, распределение датчиков, назначенных для разных модулей).

Затем выполняют анализ осуществимости создания продукта, который дает ответ на вопросы «Выгодно ли проектировать систему?» и «Сможем ли мы это сделать?» Необходимо принимать во внимание три взаимосвязанных типа осуществимости: техническую, экономическую и эксплуатационную.

Техническая осуществимость рассматривает практичность конкретного технического подхода к предлагаемой системе и доступность технических ресурсов, включая уровень готовности технологий.

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

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

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

2.4 Функциональный анализ и синтез

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

В данном процессе подробно распределяют производные требования к производительности и дизайну для каждой системной функции и подфункции. Следует выделить одну или несколько функций таким объектам, как аппаратное обеспечение, программное обеспечение, процедурные данные или персонал. Следует поддерживать прослеживаемость назначенных системных требований для каждой функции системы.

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

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

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

Основные особенности этапа синтеза:

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

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

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

• Выполняют анализ проекта системы для подтверждения соответствия результатов предварительного проектирования системным требованиям.

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

В рамках системного подхода к разработке важно раннее рассмотрение всех целей и ограничений:

• Функция. Функциональность является наиболее очевидным фактором реализации требований, при этом она должна быть сбалансирована с другими целями проекта.

• Стоимость. Напомним, что дизайн определяет более трех четвертей стоимости продукта.

• Серийный выпуск. Дизайн и стандартизация определяют, насколько сложно будет изготовить и собрать продукт. Выбор деталей фиксирует, насколько сложно будет их закупить и насколько уязвимым будет производство из-за сбоев в поставках.

• Качество и надежность. Эти потребительские свойства определяются конструкцией, количеством и конфигурацией деталей. Разработчики несут ответственность за чувствительность допусков. Качество и надежность обсуждаются далее в главах 5.1 и 5.2 соответственно.

• Простота сборки. Представленные в главе 4.3 рекомендации по ПЗС оптимизируют простоту сборки благодаря конструкции, независимо от объемов производства.

• Простота обслуживания и ремонта. Конструкция должна допускать, чтобы было легко обслуживать и ремонтировать продукт. ТОиР в полевых условиях могут потребовать проектирования дополнительного оборудования. Подробности изложены в главе 5.4.

• Управление цепочками поставок. Его можно значительно упростить за счет стандартизации деталей и заготовок, выбора деталей на основе их адекватной доступности с течением времени.

• Доставка и распространение. Распространение продукции зависит от прогнозов спроса рынка. Хранение запасов стоит денег, иногда до 25% от их стоимости в год. Экологически чистые упаковочные материалы и переработанная упаковка становятся все более важными.

• Безопасность продукта для пользователей. Необходимо использовать моделирование, чтобы предотвратить проблемы безопасности до того, как они проявятся. Детали можно посмотреть в главе 5.5.

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

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

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

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

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

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

1) что окончательный проект соответствует требованиям и общей намеченной цели проекта;

2) что окончательный проектный пакет документов завершен, и находится под контролем управления конфигурацией, включает инструкции по эксплуатации и техническому обслуживанию, вспомогательную документацию, чертежи и список деталей, и продукт готов к выпуску на рынок;

3) что окончательный проект соответствует всем нормам, стандартам и руководствам по безопасной эксплуатации в предполагаемых условиях.

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

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

2.5 Технический (детальный) проект

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

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

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

• детальное использование функционального анализа и декомпозиции продукта, чтобы гарантировать, что никакие требования не будут пропущены или распределены неправильно;

• указание подсистем с минимальными интерфейсами с другими подсистемами для удовлетворения требований с меньшими затратами и меньшей изменчивостью;

• определение требований к каждой подсистеме с четко определенными целями, процедурами тестирования, мерами оценки и критериями приемлемых характеристик.

Например, требование к системе климат-контроля легкового автомобиля состоит в том, чтобы его пассажиры чувствовали себя комфортно, регулируя температуру внутри салона до предпочтительного для клиента уровня в пределах 20—29° C. когда температура наружного воздуха колеблется от -20° C до +35° C. Требования к системе климат-контроля можно обеспечить посредством следующих функциональных подсистем:

1) отопления, включающей теплообменник горячего воздуха, вентилятор, регулятор скорости вентилятора, термостат и систему подачи горячего хладагента;

2) подачи холодного воздуха, включающую теплообменник холодного воздуха, воздуходувку, регулятор скорости вентилятора, термостат и систему подачи сжатого хладагента;

3) элементов, которые через внешние поверхности отводят из салона тепло в зависимости от температуры наружного воздуха и подводят лучистое тепло от солнечной нагрузки (окна, стекла и кузов автомобиля);

4) подсистемы подогрева и теплопередачи обивки сидений.

На основе функциональной структуры системы и ее базового уровня выполняется поиск компонентов (включая ПКИ) и построение системы. Обычно соблюдают следующую цепочку выбора:

• Используют в проекте стандартный покупной элемент, с магазинной полки (ПКИ). Преимущества использования унифицированных деталей заключаются в том, что большинство поставщиков специализируются на производстве деталей, которые соответствуют установленным государственным и промышленным нормам и спецификациям, таким как ISO9001. Эти детали часто производятся в больших объемах по относительно низкой цене за единицу. Цель выбора правильных компонентов ПКИ состоит в том, чтобы вывести подробные требования к этим компонентам посредством анализа конструкции системы, и выбрать подходящего поставщика для деталей.

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

• Если не найдены доступные ПКИ, и невозможно изменить стандартную деталь в соответствии с потребностями системы, потребуется спроектировать и разработать уникальный компонент. Желательно использовать стандартные инструменты, оборудование и сборочные детали для простоты и экономии установки, эксплуатации и обслуживания.

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

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

При реализации инноваций может пригодиться база проверенных эмпирических правил для нового проекта:

1. Полезно держать на виду перечень показателей эффективности, ПЭ, см. главу 3.7.

2. Активно использовать располагаемое моделирование для проектирования систем.

3. Рекомендуется сначала выполнять работу с высокорисковыми компонентами.

4. Следует уделить нужное внимание конструированию интерфейсов системы.

5. Свои ошибки инженеры должны находить сами.

6. Стараться выделить каждую функцию для только одного компонента.

7. Применять, где можно, быстрое прототипирование (аддитивные технологии).

8. Следует проектировать компоненты с возможностью их изолированного испытания.

9. Оценивать влияние альтернативных вариантов на характеристики конструкции.

10. Убедиться, что задачи понятны сотрудникам, контролируются и выполняются.

11. Поощрять подчиненных задавать вопросы по любому пункту приказов или указаний менеджера, которые они не понимают.

12. Мотивировать сотрудников решать каждую задачу, как их собственную.

13. Проявлять осторожность в наблюдении за процессом. Чрезмерный надзор вредит инициативе, под навязчивым присмотром сотрудники работают хуже.

Приведем примеры состава основных систем нескольких известных продуктов.

A. Стиральная машина: система корпуса, бак для белья и система привода, система управления водой и моющими средствами, система управления циклом стирки, система управления и индикации.

B. Ветряная турбина: система фундамента, система конструкции башни, система гондолы ветряка, система турбины (лопасти и ротор), система коробки передач, система генератора, система повышающего трансформатора, система определения направления воздушного потока и скорости ветра, система управления турбиной, электрическая система, системы безопасности и обслуживания, включая ступени, поручни и лестницы.

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

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

• Рекомендуется сместить акцент с проекта (когда стоимость сборки скрыта в более крупных затратах проекта) на фокус на продукте, где стоимость сборки имеет значение.

• Кроме проектирования ради функциональности и веса, следует принимать во внимание стоимость, качество и возможные задержки графика, вызванные проблемами технологичности и минимизации стоимости.

• По мере роста объемов темпы и процессы производства должны корректироваться под увеличение серийности.

• Следует исключать «авторское сопровождение» выпуска продукции (кое-где осталось под видом исторического наследия), чтобы компенсировать трудности, вызванные непроизводительной конструкцией продукта или процесса. Нужно ясно и понятно документировать техпроцессы проекта на уровень квалификации и опыта работников производственной линии. При этом приходится как можно раньше начать адаптировать конструкцию под производственные технологии выбранного предприятия—изготовителя.

• Рекомендуется назначать разумные допуски в пределах технологических возможностей обычного производственного оборудования. Чрезмерно жесткие допуски являются дорогостоящим способом гарантировать получение характеристик разработчиками, однако это увеличивает затраты, может удлинять время обработки, и последствия очень трудно исправить в дальнейшем.

• Вопросы технологичности и стоимости следует решать как можно раньше. Девиз проектирования под заданную стоимость: «Сделай это правильно с первого раза».

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

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

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

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

Завершение технического проекта фазой выпуска рабочей конструкторской документации (РКД) означает, что все компоненты во всех системах сложного продукта спроектированы:

a) инженерные чертежи, 3-Д виды и размеры твердотельной модели для каждого компонента или системы проверены на моделях сборочных узлов;

b) расчетный анализ и оценка, с использованием цифровых двойников;

c) спецификация и характеристики материалов, которые будут использоваться для производства каждого компонента, включая специальные технологические процессы, термообработку и применение покрытий поверхности;

d) выполнены оценки и верификационные испытания, включая испытания цифровых двойников, и физические испытания, проводимые для подтверждения соответствия каждого компонента заявленным функциональным, производственным, сборочным, безопасным и стоимостным требованиям.