Интегрированное проектирование печатных плат против устаревших точечных инструментов: какова реальная стоимость?

В 2016 году Samsung прекратила выпуск Galaxy Note 7 после того, как дефекты конструкции и производства аккумулятора привели к перегреву, возгораниям и глобальному отзыву. Продукт потерпел неудачу не потому, что литий-ионные батареи были чем-то новым или инженерам не хватало квалификации, а потому, что процесс разработки продукта допустил недостаточный запас по проекту, слабое покрытие валидации и неконтролируемые производственные вариации, которые дошли до конечных пользователей.

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

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

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

Стоимость жизненного цикла против стоимости лицензии

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

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

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

Точки масштабирования, в которых ручная координация перестает работать

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

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

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

Типовые режимы отказа при фрагментированных рабочих процессах

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

Оценка глубины интеграции

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

• Передаются ли механические ограничения (контур платы, запретные зоны, высоты компонентов) двунаправленно между MCAD и ECAD без ручного обмена файлами?
• Видны ли решения по BOM и цепочке поставок непосредственно в среде проектирования, или для этого нужно переключаться в отдельный портал?
• Фиксирует ли история ревизий, кто, что, когда и почему изменил, во всех доменах в рамках единой временной шкалы?
• Можно ли привязывать комментарии design review непосредственно к объектам проекта, а не хранить их в отдельном документе или переписке по электронной почте?
• Распространяются ли изменения ограничений автоматически на затронутые правила, или их нужно вручную вводить заново?

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

Единые рабочие процессы для сложного проектирования PCB в масштабе

По мере роста команд и усложнения проектов разрывы между специализированными инструментами становятся все труднее в управлении. Altium Agile Teams создан для этого этапа роста, когда координация, прозрачность и повторяемые ревью становятся столь же важны, как и сами возможности проектирования. Он предоставляет общую среду, в которой объединяются данные проектирования PCB, механический контекст, решения по BOM и информация о цепочке поставок.

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

Уменьшая трение между инструментами и людьми, Altium Agile Teams помогает растущим командам разработчиков аппаратуры тратить меньше времени на управление рабочим процессом и больше — на создание надежных проектов.

Узнайте больше об Altium Agile Teams и посмотрите, как интегрированные рабочие процессы могут снизить трение по мере масштабирования вашей команды →

Часто задаваемые вопросы о переходе к интегрированному проектированию PCB

Наши специализированные инструменты уже оплачены. Зачем переходить?

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

Как количественно оценить экономию от совместной работы?

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

Можем ли мы безопасно перенести наши библиотеки?

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

Миграция звучит как слишком большие усилия.

Миграция действительно требует работы. Но постоянное трение тоже требует ресурсов. Сравнивать нужно не «усилия против отсутствия усилий». Сравнение идет между разовым усилием на переход и постоянным торможением рабочего процесса.

Потеряем ли мы совместимость?

Совместимость следует оценивать напрямую, а не предполагать. Реальная цель — повысить непрерывность работы, не запирая проектные данные и не усложняя совместную работу в будущем.