임베디드 시스템 아키텍처: 제품에 여러 PCB가 있을 때

임베디드 시스템은 오늘날 기술 중심의 세계에서 어디에나 있습니다. 인터넷에 연결된 면도기부터 복잡한 자동차에 이르기까지, 대부분의 전자 기기의 핵심에는 임베디드 장치가 있습니다. 하나 또는 여러 개의 마이크로프로세서로 구성된 임베디드 시스템은 복잡성을 소프트웨어가 처리하도록 하여 전자 기기를 단순화할 수 있습니다. 임베디드 장치가 더 커지고 복잡해짐에 따라 인쇄 회로 기판(PCB)도 마찬가지로 복잡해집니다. 종종 이러한 장치는 여러 개의 보드로 성장하여 처음 의도했던 것보다 더 큰 조립체가 됩니다. 이 기사에서는 여러 PCB로 구성된 임베디드 시스템의 아키텍처 트레이드오프와 고려 사항을 살펴보겠습니다. 다중 PCB 시스템과 관련된 이점, 설계 고려 사항 및 도전 과제를 다룰 것입니다.

왜 여러 PCB를 사용하나요?

장치를 단일 PCB로 유지하는 것이 이상적인 옵션입니다(단순성과 비용 모두에 있어서), 때로는 설계 목표를 달성하기 위해 우리의 설계를 두 개 이상의 PCB로 분할해야만 하는 결정을 내려야 합니다. 제품을 여러 보드로 나누고자 하는 몇 가지 이유는 다음과 같습니다:

• 모듈성: 조립체를 여러 보드로 분리하면 필요한 경우 제품의 일부만 교체할 수 있습니다. 예를 들어, 단일 PCB가 실패하면 전체 시스템에 영향을 주지 않고 교체할 수 있습니다. 이는 제조업체의 비용과 시간을 줄일 수 있습니다(올바르게 수행된 경우).
• 공간 최적화: 여러 보드에 걸쳐 구성 요소를 분할함으로써 디자이너는 더욱 컴팩트하고 효율적인 레이아웃을 달성할 수 있습니다. 포장 때문에 높이가 문제가 되지 않는 몇 개의 짧고 쌓인 보드 대신 매우 길고 좁은 단일 보드를 생각해 보십시오.
• 열 관리: 많은 열을 발생시키는 구성 요소는 열 분산을 개선하기 위해 다른 PCB에 분할될 수 있습니다. 전체 조립체에 걸쳐 열을 고르게 분배함으로써 시스템의 신뢰성을 크게 향상시킬 수 있습니다.
• 확장성: 여러 PCB로 설계하면 단일 보드로 교체할 수 있는 점진적인 기능 추가가 가능합니다. 전체 컴퓨팅 시스템을 교체하지 않고도 업그레이드된 센서나 카메라를 생각해 보십시오.

이러한 이유(그리고 더 많은 이유)로 여러 PCB로 구성된 조립체를 설계하는 것을 고려하지만, 임베디드 펌웨어 측면의 도전 과제도 복잡함이 없는 것은 아닙니다.

여러 PCB 조립체에 대한 임베디드 설계 고려 사항

여러 PCB를 사용하는 경우(해당되는 경우)를 위해 사례를 확립했으므로 임베디드 시스템을 아키텍처할 때의 설계 고려 사항을 이해하는 것이 중요합니다. 하드웨어와 소프트웨어 관점 모두에서 단일 보드에 모든 것을 넣을 때와는 신중하게 고려하지 않는 뉘앙스가 있습니다.

우리의 마음에 떠오르는 첫 번째 고려 사항은 보드 간 통신입니다. 각 보드는 어떻게 서로 통신할까요? 각 보드에는 어떤 종류의 처리 능력(있다면)이 존재하나요? 어쩌면 한 보드는 두뇌 역할을 하고 다른 보드들은 센서 역할을 할까요? I2C, SPI, UART, Ethernet 등 우리가 전송 프로토콜을 신중하게 선택할 때, 전송 라인, 신호 무결성, 그리고 가장 중요하게는 보드 간 커넥터를 통한 신호 전송을 고려해야 합니다. 디자이너에게 발생할 수 있는 최악의 일(믿어주세요, 저도 경험했습니다)은 전체 시스템을 설계하고 제조업체로부터 PCB를 받아보았을 때 클록 신호를 하나 또는 두 개 놓쳤다는 것을 깨닫는 것입니다. 우리는 보드 간 커넥터에 여분의 핀을 남겨두는 것을 잊어버리곤 합니다. 모든 핀 수를 최대한 활용하려고 하다가 결국에는 우리를 괴롭히는 일이 발생합니다. PCB들 사이에 많은 통신 라인을 라우팅할 때, Altium Designer의 Multi-Board Assembly 기능과 같은 멀티 보드 프로젝트를 염두에 두고 설계하는 것이 필수입니다.

또한, 우리는 특히 마이크로프로세서로 전력 버스를 모니터링할 경우 전력을 어떻게 분배할지에 대해서도 생각해야 합니다. 우리는 "두뇌"가 잠재적인 재앙을 모니터링할 수 있도록 접근성을 원하지만, 스위칭 공급 잡음, 고부하에 대한 전력 분배, 그리고 우리의 보드 간 커넥터 핀이 그런 전력에 대해 평가되었는지도 고려해야 합니다.

마지막으로, 임베디드 시스템의 소프트웨어 자체와 직접적으로 관련되지는 않지만, 기계적 설계도 중요한 역할을 합니다. 푸시 버튼, 터치 스크린 및 사용자와의 다른 물리적 인터페이스는 여전히 마이크로프로세서에 연결되며 고려해야 합니다. 마이크로프로세서가 입력을 접근할 수 있는 방식으로 배선을 라우팅할 수 있나요? 우리는 한 보드에서 다른 보드로 고속 디지털 출력을 전달할 때 신호 무결성을 고려했나요? 이러한 것들은 우리가 임베디드 장치를 설계할 때 생각해야 할 사항입니다.

도전과 해결책

스타트업을 확장하는 과정에서(심지어 대기업에서조차) 시간과 시간이 지나도 계속해서 나타나는 가장 과소평가된 도전 중 하나는 소프트웨어와 하드웨어 간의 버전 관리 체계의 문제입니다. 소프트웨어 릴리스와 PCB 리비전을 관리하는 것은 혼란, 지연, 심지어 제품 실패로 이어지는 끝없는 전투가 되곤 합니다.

예를 들어, 저와 함께 일했던 한 스타트업에서는 PCB의 사소한 수정이 리스핀을 요구했고, 따라서 펌웨어 업데이트(비록 최소한이지만)가 필요했습니다. 부실한 버전 관리로 인해 엔지니어링 팀은 새 펌웨어를 구형 PCB 버전에 배포하여 예상치 못한 브라운아웃과 가끔 연기가 발생했습니다. 다행히 제품이 출하되기 전에 이를 발견했지만 며칠 동안 절대적인 악몽이었습니다.

이러한 함정을 피하기 위해서는 확실한 버전 관리 체계를 수립하고 하드웨어와 소프트웨어 팀 간의 명확한 소통을 보장하는 것이 중요합니다. 펌웨어에 대한 Git 해시(또는 의미 있는 버전)와 하드웨어 리비전에 대한 기본 지원 조회 테이블과 같은 간단한 버전 관리 체계도 시작하기에 충분히 좋습니다. 시간이 지남에 따라 펌웨어에서 하드웨어 리비전 감지(따라서 호환성 검사)와 같은 더 정교한 메커니즘이 혼동을 크게 줄이는 데에도 도움이 됩니다.

소프트웨어 버전 관리뿐만 아니라 코드의 모듈성에 대해 생각하는 것도 중요합니다. 스파게티 코드에서는 새로운 칩이나 센서가 탑재된 센서 보드를 교체하는 것이 리팩토링의 악몽이 될 수 있습니다. 장치 드라이버를 모듈화하고 하드웨어 추상화 계층을 만들면 향후 수년간 쉽게 구성 요소를 교체할 수 있습니다. 이는 임베디드 시스템이 시간이 지남에 따라 복잡성이 증가함에 따라 훨씬 더 인기를 얻게 된 것입니다.

결론

임베디드 시스템 아키텍처에 대해 생각할 때 항상 작게 생각할 필요는 없습니다. 우주선과 자동차는 매우 복잡한 임베디드 시스템이지만 스마트폰도 마찬가지입니다. 인터넷에 연결된 스푼을 디자인하든 다음 위성을 디자인하든, 여러 PCB를 위한 디자인을 할 때 임베디드 시스템 아키텍처의 트레이드오프를 이해하는 것이 매우 중요합니다. 이 글에서 많은 개념을 탐구했지만, 여러분의 여정을 따라가다 보면 의심할 여지 없이 더 많은 것을 발검하게 될 것입니다.