Факторы, влияющие на проблемы проектирования

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

Работа в рамках документо-центричного подхода

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

Документо-ориентированный (документоцентричный) подход к управлению данными — это концепция, при которой основной единицей информации является документ, представленный в бумажной или в электронной (файл) форме.

При документо-ориентированном подходе, документ первичен, а данные, содержащиеся в нем, вторичны. Все бизнес-процессы подхода направлены на создание и управление документами.

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

С применением документоцентричного подхода связан ряд проблем:

1. Проблемы с поиском и использованием информации

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

2. Сложность анализа и внесения изменений

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

Пример:

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

Альтернатива: При внедрении MBSE, каждое требование и связанные с ним характеристики являются самостоятельными единицами данных в рамках PDM-системы. Родительское требование связано с дочерними требованиями информационными связями. Становится возможным быстро отследить все зависимости и не забыть внести все необходимые изменения. Техническое задание является только отчетом, который формируется автоматически, по составу требований. Реальная работа ведется не с отчетом, а с набором требований в виде информационных объектов PDM-системы.

Последствия: переделки, дополнительные затраты на исправление, срывы сроков.

3. Работа с неактуальными данными

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

Последствия: брак, переделки, конфликты и потери времени.

4. Проблемы с гибкостью и итеративностью процесса разработки

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

Последствия: длительность и трудоемкость процесса проектирования.

5. Фокус на форме, а не на сути

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

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

6. Иллюзия прогресса вместо описания реального статуса разработки

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

Руководители видят статус готовности документов, который не говорит о реальной готовности изделия. При документоцентричном подходе статус готовности 90% проекта означает, что готово 90% документов, а не реальный результат проектирования в виде верифицированной конструкции.

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

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

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

6. Снижение ответственности и «перекладывание бумажек»

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

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

Игнорирование процессов работы с требованиями

Требования, основа создания любого изделия, и от того как эффективна построена работа с требованиями зависит успех всего его жизненного цикла

Согласно исследованиям The Role of Requirements in the Success or Failure of Software Projects, 39,2% процента факторов влияющих на неудачи проектов, относятся к области требований.

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

• Отсутствие на предприятиях стандартов по работе с требованиями. Даже ГОСТ по управлению требованиями появился в нашей стране только в 2021 году. До этого, все ГОСТы про требования описывали как оформляется техническое задание, и не говорили как нужно формулировать требования, какими качествами они должны обладать и как должен быть организован процесс их управления.
• Само техническое задание не относится к конструкторской документации по ГОСТ 2.102, с соответствующими к нему отношением со стороны конструкторов.
• Требования продолжают жить в концепции документоцентричного подхода, выполняются в виде документов.
• Вопросу управления требованиями уделяется одно из последних мест, при внедрении PLM-решений. Большинство пользователей PDM-систем не имеют внедренных инструментов и процессов управления требованиями в контуре PDM.
• Требования не имеют четких правил для их валидации и верификации, этот процесс подменяется их согласованием и утверждение ТЗ.
• Сами требования имеют преимущественно текстовое описание без других способов их формализации и визуализации
• Процесс выявления требований выполняется преимущественно экспертно без использования

Игнорирование процессов работы с требованиями рождает целый ряд проблем:

1. Проблема не выявленных (во время) требований

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

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

2. Проблема некачественных требований

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

Пример некачественных требований:

• Интерфейс должен быть интуитивно понятным
• Система должна быть надежной
• Деталь должна быть достаточно прочной
• Кресло водителя должно быть удобным

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

3. Проблема анализа влияния требований

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

Неправильная или не полная оценка влияния изменений привод к:

• Росту вторичных изменений (выявляемых в процессе проведения первичных изменений);
• Ухудшения параметров смежных систем;
• Появлению отрицательной эмерджентности;
• Общему ухудшения параметров изделия.

3. Проблема постоянных изменений и переделок

Не выявленные и не качественные требования приводят к изменениям.

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

Одно из причин изменений является отсутствие прослеживаемости требований

4. Проблема не выполненных требований

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

5. Проблема со сдачей результатов

Некачественные. упущенные и не реализованные требования приводят к конфликтам при сдаче результатов.

Двусмысленное или не конкретное требование (неизмеримое) требование при приемке может трактоваться заказчиком по своему и стать причиной формального отказа приемки результатов.

Пример:

В ТЗ на систему управления присутствовало требование: «Время отклика на команду оператора должно быть минимальным».

При реализации, время отклика было сделано 100 мс.

При сдаче результатов заказчик заявил, что это 100 мс неприемлемо, и требуется 50 мс.

Спор перерос в конфликт и необходимость доказывать принятое решение.

Было потрачено несколько недель на создание стенда, чтобы доказать, что для данной механики 100 мс — это физический предел.

Заказчик принял результат, но было потрачено время и деньги.

Формулировка требования как «Время отклика системы на команду "Пуск" от нажатия кнопки до начала движения исполнительного органа не должно превышать 100 мс», позволила бы избежать проблем при приемке.

Данная проблема решается внедрением процесса верификации и валидации самих требований.

Все эти проблемы взаимосвязаны и в тоге приводят к:

1. Сорванным срокам.
2. Взрывному росту стоимости.
3. Юридическим конфликтам.
4. Созданию неконкурентоспособного продукта.
5. Потере репутации.

Требуется изменить подход к работе с требованиями и внедрять практики инженерии требований

Акцент на форме

Развитие САПР, в частности CAD-систем, дает возможность "увидеть" систему еще до того, как она физически изготовлена. Но здесь таится ловушка, в которую попадают многие инженеры: смещение акцента с содержания на форму, когда инженеры увлеченно строят детализированные 3D-модели, забывая, что главное — это не как система выглядит, а как она работает.

Суть проблемы: Команда начинает проект не с анализа требований, функционального моделирования и архитектурных решений, а с создания красивой 3D-модели "будущего изделия".

Какие проблемы из этого следуют:

1. Иллюзия завершенности

3D-модель создает у руководства и заказчика ложное впечатление, что работа близка к завершению. На самом деле, смоделирована лишь форма, но не содержание: логика работы, потоки данных, взаимодействие с человеком, поведение в нештатных ситуациях. Это приводит к грубым просчетам в сроках и бюджете.

2. Фрагментация знаний

Фрагментация знаний — это ситуация, когда информация об изделии разделена на множество мелких частей, разрозненных и не связанных между собой. Чаще всего, фрагментация возникает в результате документо-центричного подхода к описанию изделия. Фрагментация знаний может возникнуть и при работе с моделями, когда основной упор в проектировании делается на формирование 3D-моделей, передающих форму, но не описывающих работу изделия с учетом  междисциплинарных систем (электроника, системы управления). В этом случае часть информации о системе концентрируется в других, преимущественно документо-центричных источниках (схемы, чертежи, пояснительные записки др.). Соответствие этих данных друг другу и их  интеграция в единое целое требует дополнительных трудозатрат, увеличивая стоимость изменений в геометрической прогрессии.

Фрагментированные данные не отражают критических междоменных взаимодействий, например:

• Механика - Электроника: Деталь красиво выглядит, но для ее прокладки не хватило места из-за жгутов проводов, которые не были смоделированы.
• Аппаратная часть - Программное обеспечение: В корпусе есть место для процессора, но не проведен анализ тепловыделения, и нет модели работы ПО, которое будет создавать на него нагрузку.
• Человек - Система: Интерфейс управления эргономично вписан в панель, но не проведен анализ человеко-машинного взаимодействия, и логика отображения информации противоречит потребностям оператора.

Для решения проблемы необходим единый источник истины о проектируемом изделии в виде архитектуры.

3. Проблемы верификации и валидации

Верификация на базе 3D моделей по факту является поздней охотой на ошибки. Обнаружение концептуальных ошибок, на стадии электронного макета, заложенных на ранних стадиях проектирования (и влияющих на 70% стоимости изделия), потребует огромных затрат, которые не гарантируют получения требуемого результата.

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

4. Потеря инноваций

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

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

Акцент на 3D CAE и поздней верификации

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

Значительный акцент при проектировании делается на применении инструментов 3D CAE анализа. Да эти инструменты важны, и без них не обойтись при проектировании сложных технических систем. Но 3D CAE это не панацея, и не следует его переоценивать и использовать в ущерб другим методам.

Почему 3D CAE — это "поздно" в цикле проектирования:

3D CAE работает с уже принятыми физическими решениями. Изменение на этом этапе означает переделку геометрии, сетки, расчетов — это дорого и долго. По сути, 3D CAE часто становится инструментом не для поиска оптимального решения, а для оправдания уже принятого, иногда — с огромными запасами прочности "на всякий случай".

С точки зрения жизненного цикла процесса проектирования 3D CAE можно сравнить с препарированием трупа. Вы можете с высочайшей точностью изучить анатомию: форму костей, расположение мышц, геометрию сосудов. Вы можете провести анализ на прочность бедренной кости или определить, как деформируется грудная клетка при ударе. Это бесценно, но это статика. Труп не бегает, не дышит и не поддерживает температуру.

Почему 3D CAE — не достаточно для верификации:

3D CAE блестяще отвечает на такие вопросы «КАК?» и «НАСКОЛЬКО?» в рамках конкретной физики:

• Как распределяются напряжения в этой детали?
• Насколько она деформируется под нагрузкой?
• Как обтекает ее жидкость или газ?

Однако, инструменты 3D CAE принципиально неспособны ответить на системные вопросы более высокого порядка:

• Что будет, если насос выйдет на полную мощность не за 2 секунды, а за 0.5?
• Как поведет себя вся гидравлическая система, если заклинит один из клапанов?
• Как взаимодействуют система охлаждения и система управления двигателем, когда тот работает в переходных режимах?

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

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

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

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

Современная система – это всегда мехатроника. Железо управляется софтом. 3D CAE не видит программного кода.

• Вы можете рассчитать в 3D, выдержит ли шасси посадку. Но справится ли система управления торможением с обледеневшей полосой, учитывая инерцию, сцепление и работу АБС?
• Вы можете оптимизировать в 3D форму лопатки турбины. Но как будет вести себя вся силовая установка при резком сбросе нагрузки? Не войдет ли она в помпаж?

Отдельно следует отметить, что 3D CAE-анализ – это ресурсоёмко. Полноценный расчёт динамики системы в 3D постановке, даже на мощном кластере может занять дни, а отдельные задачи вообще не могут быть решены в 3D постановке.

Поэтому 3D CAE должно использоваться в только в комплексе инструментов для верификации и валидации реализации, для проверки концептуальных решений, акцент должен делаться на ранние стадии проектирования и инструменты ранней верификации.