Пользовательские проверки и валидации

Standard design rules cover geometry and electrical correctness. Custom checks cover everything else – your company's standards, your industry's requirements, and your organization's institutional knowledge.

Фреймворк Behavior Extensibility от Altium позволяет писать пользовательскую логику валидации на Python и подключать ее к контрольным точкам платформы на всех этапах жизненного цикла проектирования: ERC и DRC в Altium Designer, валидация BOM и компонентов, этапы допуска к релизу, стадии проверки проекта и шаги рабочих процессов на сервере. Пользовательские проверки отображаются и работают точно так же, как встроенные проверки платформы: тот же интерфейс, та же панель ошибок, тот же переход к затронутому компоненту или цепи.

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

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

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

• Voltage derating rules – специфичные для вашего семейства продуктов или отраслевого сегмента. Конденсаторы на низковольтных шинах, электролитические конденсаторы рядом с источниками тепла

• Component qualification gates – детали от неутвержденных производителей, компоненты под контролем ITAR, компоненты, снятые с производства и отмеченные отделом закупок

• BOM completeness rules – обязательные параметры не заполнены, отсутствуют утвержденные альтернативы, неполные данные о производителе

• Release documentation requirements – определенные выходные файлы, которые должны существовать и быть актуальными, чтобы релиз считался действительным

• Organizational standards – правила, существующие только на уровне неформальных знаний и применяемые непоследовательно в зависимости от того, кто проверяет проект

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

Ценность кодирования знаний в виде проверок

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

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

Что стоит проверять, а что нет

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

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

Подходы, которые не масштабируются

• Manual pre-release checklists – подходят для небольших команд с редкими релизами. Перестают работать, когда команда растет, релизы выходят чаще или человек, который поддерживает чек-лист, недоступен. Кроме того, чек-листы невидимы для инженера в процессе проектирования — обратная связь приходит слишком поздно, когда исправления уже обходятся дороже.

• Review-only enforcement – если полагаться на ревьюеров проекта для выявления стандартных нарушений, то одни и те же ошибки будут снова и снова находить одни и те же люди. Это отнимает время экспертов на детерминированные проблемы, оставляет ранние стадии проектирования без защиты и приводит к непоследовательному применению правил разными ревьюерами.