Совместная инженерная разработка: разрыв последовательного цикла с Team Ribbot

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

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

Ключевые выводы

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

Кейс Ribbot: объединение междисциплинарных обновлений

Хотя Team Ribbot работает в крайне конкурентной среде робототехники, проблемы взаимодействия, с которыми они столкнулись, типичны и для разработки электроники, автомобилей, аэрокосмических систем, промышленного оборудования и встраиваемых систем. Создание бота-чемпиона для BattleBots Pro League требует разработки плотной и сложной электроники в бронированном корпусе. Проблема этой команды в том, что ее участники живут в пяти разных штатах и при этом полностью заняты своей основной работой. При внесении обновлений в разводку платы времени на ошибки просто нет.

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

Дилемма «всё или ничего»

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

Старый рабочий процесс: вынужденное полное принятие

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

Новый рабочий процесс: детальная выборочная фильтрация изменений

Ribbot добился этого, используя возможности Selective Change в MCAD CoDesigner. Вместо получения обновлений единым пакетом программное обеспечение анализирует изменения, поступившие от разработчика электроники, и выводит их в виде списка для выборочной проверки и применения. Детализированное управление изменениями позволяет инженерным командам сохранять уже проверенную работу, просматривая только те обновления, которые затрагивают их область ответственности.

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

Настоящая параллельная работа и защитный фильтр

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

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

«Мы также можем сами выбирать, какие изменения принимать... если [инженер-механик] случайно переместит что-то, что я не хотел перемещать, я могу просто отклонить эту часть его изменений, приняв остальные. Для нас это огромное преимущество». — Ник Соренсен, ведущий инженер-электронщик

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

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

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

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

Управление выборочными изменениями проекта (пошагово)

Параллельный прогресс для профессиональных результатов

В BattleBots Pro League команда Ribbot теперь может выполнять итерации быстрее, чем раньше. Благодаря возможности совместной и параллельной разработки Ribbot всегда будет на шаг впереди. Те же преимущества рабочего процесса применимы и к коммерческой разработке аппаратных продуктов, где сокращение времени на итерации проекта может улучшить сроки, качество продукта и производительность инженерной команды.

Забудьте о передаче проекта «по цепочке» и начните проектировать параллельно. Узнайте, как управлять выборочными изменениями в MCAD CoDesigner.

Параллельное проектирование: часто задаваемые вопросы

Работает ли выборочное принятие изменений и для инженеров-электронщиков, и для инженеров-механиков?

Да. С Altium Designer или любым другим MCAD-инструментом, таким как SOLIDWORKS, вы сможете просматривать предлагаемые изменения, а затем выборочно отмечать или снимать отметку с каждого из них перед применением в своем рабочем пространстве.

Если я отклоню определенное изменение от смежной команды, перезапишет ли это или повредит их исходный файл?

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

Сложно ли понять, что именно изменилось в сложной сборке?

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

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

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