Создание электрических схем и трассировка печатных плат становятся всё более простыми делами. Производители компонентов интегрируют в изделия всё больше функционала, выкладывают готовые модели, условные графические обозначения (УГО) и целые схемы, сайты автоматически генерируют источники питания, фильтры и многое другое. Тем не менее, даже при проектировании простых печатных узлов обнаруживаются ошибки, часто — глупые и очевидные. Мы сегодня не будем говорить про DRC  и ERC, их надо делать всегда и с ними всё более-менее понятно (если нет — напишите в комментариях). Будем говорить про проверку человеком. Когда в очередной “последний” раз перед отправкой в производство листаешь слои в своей плате, картинка уже настолько знакома, что глаз упускает ошибки. Для проверки нужны “вторые глаза” — пора звать другого инженера. Когда ты для кого-то и есть эти “вторые глаза” — схема и плата полностью новые, и всё необычное приковывает взгляд. Однако, бессистемная проверка не гарантирует тотального просмотра опасных мест, что может привести к затягиванию сроков отладки и к дополнительным итерациям, не предусмотренным бюджетом. С осознанием этих ограничений мы ввели перечень проверок, который позволяет отсечь наиболее распространенные ошибки. Про него я сегодня и расскажу. Узкоспециализированных пунктов в перечне почти нет — мы делаем много разнообразных проектов и список универсален. Для всех сложных мест в цифровой схемотехнике есть свои чек-листы, которые дают производители микросхем.  Как только схема или плата, по мнению автора, готова, он ставит в Redmine задачу проверки другому инженеру (Рецензенту). Рецензент, помимо обладания знаниями и опытом, должен изучить ТЗ и все дополнительные материалы проекта. Всё это занимает немало времени, которое должно быть выделено на этапе планирования проекта.  Закончив ознакомление с документацией, надо настроиться на правильный лад. Проверка — это помощь в достижении наилучшего возможного результата. Прежде чем обрушиться с критикой, важно вспомнить, что инженер старался сделать свою работу превосходно, “от души”, и задача проверяющего — не нарушить это настроение.  Рецензент копирует текст перечня проверки из Базы знаний в комментарий к задаче, а затем двигается по списку, оставляя свои пометки. Используются обозначения: После рецензирования, как правило, происходит устное обсуждение комментариев, прояснение непонятных моментов, в результате замечания часто корректируются.
Далее текст перечня из нашей Базы знаний, комментарии для вас выделены курсивом. В перечне есть некоторые моменты, специфичные для Altium Designer. Для многостраничных схем разбиение по листам, для одностраничных все пункты распространяются на один лист. (Как правило, мы используем иерархические многостраничные схемы, для таких схем для каждого листа надо повторить проверку “Блок”, переименовывая “Блок” в название листа схемы) (Как правило, блок — это простая схема, часто из одной микросхемы с обвязкой) Если есть 3D модель для устройства, проверка производится по ней.(Чаще всего устройство собрано воедино в 3D САПР, там есть инструменты для проверки интерференций, выполнения сечений и пр.) (Команды для Altium Designer, суть — проверить, что в плате и схеме отличий нет)  (Этот блок описывает последовательность, да и то не полно)  Списки проверок постепенно эволюционируют, добавляются новые пункты, убираются ненужные.  Проверка по перечням позволяет нам находить много ошибок каждый день, а отправлять платы в производство стало не так страшно. А как вы проверяете свои платы? Поделитесь в комментариях. * Последняя картинка в тексте иллюстрирует, что даже тщательная проверка не спасёт от невнимательного заказчика. CEO at Third pin