Arquitetura de Sistemas Embarcados: Quando Seu Produto Possui Múltiplas PCBs

Sistemas embarcados são onipresentes no mundo tecnológico de hoje. Seja um barbeador conectado à internet ou um automóvel complexo, dispositivos embarcados estão no coração da maioria dos dispositivos eletrônicos que usamos hoje. Compostos por um ou vários microprocessadores, sistemas embarcados podem simplificar a eletrônica ao transferir a complexidade para ser gerenciada por software. À medida que os dispositivos embarcados se tornam maiores e mais complexos, também o fazem as placas de circuito impresso (PCBs). Muitas vezes, esses dispositivos crescem para múltiplas placas e se tornam montagens maiores do que originalmente pretendido.

Neste artigo, vamos examinar os compromissos e considerações de arquitetura para sistemas embarcados compostos por múltiplas PCBs. Vamos abordar os benefícios, considerações de design e desafios associados a sistemas de múltiplas PCBs.

Por que usar múltiplas PCBs?

Embora manter seu dispositivo em uma única PCB seja a opção ideal (tanto pela simplicidade quanto pelo custo), às vezes temos que nos aventurar a dividir nosso design em duas ou mais PCBs para alcançar nossos objetivos de design. Algumas razões pelas quais queremos dividir nosso produto em várias placas incluem:

• Modularidade: Separar uma montagem em várias placas significa que você pode trocar apenas parte do produto, se necessário. Por exemplo, se uma única PCB falhar, ela pode ser substituída sem impactar todo o sistema. Isso pode, se feito corretamente, reduzir custos e tempo para os fabricantes.
• Otimização de Espaço: Ao dividir componentes por várias placas, os designers podem alcançar layouts mais compactos e eficientes. Pense em uma placa única, muito longa e estreita, versus algumas placas curtas e empilhadas onde a altura não importa por causa da embalagem.
• Gestão Térmica: Componentes que geram muito calor podem ser divididos por diferentes PCBs para melhorar a dissipação térmica. Distribuindo o calor uniformemente por toda a montagem, você pode aumentar significativamente a confiabilidade do sistema.
• Escalabilidade: Projetar com múltiplas PCBs permite adições incrementais de recursos que podem ser trocados por uma única placa versus uma montagem inteira. Pense em um sensor atualizado ou câmera sem substituir todo o sistema de computação.

Por essas razões (e mais), consideramos projetar uma montagem que é composta por múltiplas PCBs, mas os desafios do lado do firmware embarcado não são sem suas complexidades.

Considerações de Design Embarcado para Montagens de Múltiplas PCBs

Agora que estabelecemos o caso para o uso de múltiplas PCBs (quando aplicável), é importante entender as considerações de design ao arquitetar o sistema embarcado. Tanto do ponto de vista de hardware quanto de software, existem nuances que não tendemos a ponderar tão cuidadosamente quando colocamos tudo em uma única placa.

A primeira consideração que deve vir à nossa mente é a comunicação entre placas. Como cada placa vai se comunicar uma com a outra? Que tipo de capacidade de processamento (se houver) existe em cada placa? Talvez uma placa consista no cérebro enquanto as outras consistam nos sensores? À medida que escolhemos cuidadosamente nossos protocolos de transmissão, seja I2C, SPI, UART, Ethernet, etc., também devemos considerar as linhas de transmissão, a integridade do sinal e, mais importante, a transferência de sinal através de conectores entre placas. A pior coisa que pode acontecer a um designer (e acredite, eu já estive lá) é projetar o sistema completo e receber suas PCBs do fabricante apenas para perceber que você esqueceu um ou dois sinais de relógio. Também tendemos a esquecer de manter pinos de reserva em nossos conectores entre placas, tentando espremer ao máximo a contagem de pinos. Isso é algo que realmente pode nos prejudicar no final. Projetar com um projeto de várias placas em mente, como o recurso de Montagem de Multi-Placas no Altium Designer, é essencial ao rotear tantas linhas de comunicação entre PCBs.

Também precisamos pensar em como planejamos distribuir energia, especialmente se vamos monitorar barramentos de energia com nosso microprocessador. Queremos acessibilidade ao “cérebro” para permitir que ele monitore eventos catastróficos, mas também precisamos considerar o ruído da fonte de alimentação comutada, distribuição de energia para cargas pesadas e se os pinos do nosso conector entre placas são classificados para esse tipo de energia.

Por último, embora não esteja diretamente relacionado ao software em si do sistema embarcado, o design mecânico também desempenha um papel importante. Botões de pressão, telas sensíveis ao toque e outras interfaces físicas com o usuário ainda se conectam ao microprocessador e devem ser levadas em consideração. A fiação pode ser roteada de tal forma que o microprocessador possa acessar suas entradas? Consideramos a integridade do sinal da saída digital de alta velocidade à medida que a passamos de uma placa para outra? São coisas que temos que pensar ao arquitetar nosso dispositivo embarcado.

Desafios e Soluções

Um dos desafios mais subestimados que eu vi repetidamente em startups em crescimento (e até em grandes empresas) tem sido a praga dos esquemas de versionamento entre software e hardware. Gerenciar lançamentos de software contra revisões de PCB tornou-se a batalha interminável que frequentemente leva a confusão, atrasos e até falhas no produto.

Por exemplo, em uma startup com a qual trabalhei, uma pequena modificação na PCB exigiu uma nova versão e, portanto, uma atualização do firmware (ainda que mínima). Devido ao controle de versão deficiente, a equipe de engenharia implantou o novo firmware em versões antigas de PCB causando apagões inesperados e uma nuvem periódica de fumaça. Felizmente, pegamos isso antes do produto ser enviado, mas foi um pesadelo absoluto por dias a fio.

Para evitar essas armadilhas, é crucial estabelecer um esquema de versionamento sólido e garantir uma comunicação clara entre as equipes de hardware e software. Mesmo um esquema de versionamento simples, como um hash do Git (ou versão semântica) para firmware, ao lado de uma tabela de consulta básica para revisões de hardware, pode ser suficiente para começar. À medida que o tempo avança, mecanismos mais sofisticados, como detecção de revisão de hardware no firmware (verificando assim a compatibilidade), também reduzem bastante as confusões.

Além da versionamento de software, também é importante pensar na modularidade do código. Com código espaguete, substituir uma placa de sensor com novos chips ou sensores poderia se tornar um pesadelo de refatoração. Modularizar seus drivers de dispositivo e criar camadas de abstração de hardware permite a substituição fácil de componentes por anos a vir. Isso é algo que se tornou muito mais popular à medida que os sistemas embarcados cresceram em complexidade ao longo do tempo.

Conclusão

Quando pensamos em arquitetura de sistemas embarcados, não precisamos sempre pensar pequeno. Naves espaciais e automóveis são sistemas embarcados extremamente complexos, mas os smartphones também são. Seja projetando uma colher conectada à internet ou o próximo satélite, entender os compromissos para a arquitetura de sistemas embarcados é extremamente importante ao projetar para múltiplas PCBs. Exploramos muitos conceitos neste artigo, mas ainda há muitos mais que, sem dúvida, você encontrará ao longo de sua jornada.