Архитектура встраиваемых систем: Когда ваш продукт содержит несколько печатных плат

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

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

Почему использовать несколько PCB?

Хотя сохранение вашего устройства на одной PCB является идеальным вариантом (как с точки зрения простоты, так и стоимости), иногда нам приходится делать шаг на разделение нашего дизайна на две или даже больше PCB, чтобы достичь наших дизайнерских целей. Некоторые причины, по которым мы хотели бы разделить наш продукт на несколько плат, включают:

• Модульность: Разделение сборки на несколько плат означает, что вы можете заменить только часть продукта, если это необходимо. Например, если одна PCB выходит из строя, ее можно заменить, не влияя на всю систему. Это может, при правильном подходе, снизить затраты и время для производителей.
• Оптимизация пространства: Разделяя компоненты по нескольким платам, дизайнеры могут добиться более компактных и эффективных расположений. Подумайте о очень длинной, узкой одиночной плате по сравнению с несколькими короткими, уложенными друг на друга платами, где высота не имеет значения из-за упаковки.
• Управление теплом: Компоненты, которые генерируют много тепла, могут быть разделены по разным PCB для улучшения теплоотвода. Распределяя тепло равномерно по всей сборке, вы можете значительно повысить надежность системы.
• Масштабируемость: Дизайн с использованием нескольких PCB позволяет постепенно добавлять функции, которые можно заменить одной платой вместо целой сборки. Подумайте об улучшенном датчике или камере без замены всей вычислительной системы.

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

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

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

Первое, о чем следует подумать, это межплатное взаимодействие. Как каждая плата будет общаться с другими? Какая вычислительная мощность (если таковая имеется) находится на каждой плате? Возможно, одна плата является мозгом, а другие - сенсорами? Когда мы тщательно выбираем наши протоколы передачи данных, будь то I2C, SPI, UART, Ethernet и т.д., мы также должны учитывать линии передачи, целостность сигнала и, что наиболее важно, передачу сигнала через межплатные соединители. Худшее, что может случиться с конструктором (и поверьте, я был в такой ситуации), это спроектировать полную систему и получить обратно ваши печатные платы от производителя, только чтобы осознать, что вы пропустили один или два сигнала тактовой частоты. Мы также склонны забывать оставлять запасные контакты на наших межплатных соединителях, пытаясь использовать каждый контакт по максимуму. Это то, что действительно может аукнуться в конце. Проектирование с учетом многослойного проекта, такого как функция сборки многослойных плат в Altium Designer, является обязательным при маршрутизации такого большого количества линий связи между печатными платами.

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

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

Проблемы и решения

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

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

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

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

Заключение

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