Embedded Systems Architektur: Wenn Ihr Produkt mehrere PCBs hat

Ari Mahpour
|  Erstellt: Mai 24, 2024  |  Aktualisiert am: Juli 1, 2024
Embedded Systems Architektur: Wenn Ihr Produkt mehrere PCBs hat

Embedded-Systeme sind in der heutigen technologiegetriebenen Welt allgegenwärtig. Sei es ein internetverbundener Rasierer oder ein komplexes Automobil, eingebettete Geräte sind das Herzstück der meisten elektronischen Geräte, die wir heute verwenden. Bestehend aus einem oder mehreren Mikroprozessoren, können eingebettete Systeme die Elektronik vereinfachen, indem sie die Komplexität auf die Software auslagern. Da eingebettete Geräte größer und komplexer werden, gilt dies auch für die gedruckten Schaltungen (PCBs). Oft wachsen diese Geräte zu mehreren Platinen heran und werden zu größeren Baugruppen, als ursprünglich beabsichtigt.

In diesem Artikel werden wir die Architektur-Abwägungen und Überlegungen für eingebettete Systeme, die aus mehreren PCBs bestehen, näher betrachten. Wir werden die Vorteile, Designüberlegungen und Herausforderungen, die mit Mehr-PCB-Systemen verbunden sind, behandeln.

Warum mehrere PCBs verwenden?

Obwohl es ideal ist, Ihr Gerät auf einer einzigen PCB zu halten (sowohl aus Gründen der Einfachheit als auch der Kosten), müssen wir manchmal den Schritt machen, unser Design auf zwei oder sogar mehr PCBs aufzuteilen, um unsere Designziele zu erreichen. Einige Gründe, warum wir unser Produkt auf mehrere Platinen aufteilen möchten, sind:

  • Modularität: Eine Baugruppe in mehrere Platinen aufzuteilen bedeutet, dass Sie nur einen Teil des Produkts austauschen können, wenn nötig. Wenn beispielsweise eine einzelne PCB ausfällt, kann sie ersetzt werden, ohne das gesamte System zu beeinträchtigen. Dies kann, wenn richtig gemacht, Kosten und Zeit für Hersteller reduzieren.
  • Raumoptimierung: Durch die Aufteilung von Komponenten auf mehrere Platinen können Designer kompaktere und effizientere Layouts erreichen. Denken Sie an eine sehr lange, schmale einzelne Platine im Vergleich zu einigen kurzen, gestapelten Platinen, bei denen die Höhe aufgrund der Verpackung keine Rolle spielt.
  • Thermomanagement: Komponenten, die viel Wärme erzeugen, können auf verschiedene PCBs aufgeteilt werden, um die Wärmeableitung zu verbessern. Durch die gleichmäßige Verteilung der Wärme über die gesamte Baugruppe können Sie die Systemzuverlässigkeit erheblich verbessern.
  • Skalierbarkeit: Das Design mit mehreren PCBs ermöglicht inkrementelle Feature-Erweiterungen, die durch eine einzelne Platine ausgetauscht werden können, anstatt eine ganze Baugruppe zu ersetzen. Denken Sie an einen verbesserten Sensor oder eine Kamera, ohne das gesamte Computersystem zu ersetzen.

Aus diesen Gründen (und mehr) betrachten wir das Design einer Baugruppe, die aus mehreren PCBs besteht, aber die Herausforderungen auf der Seite der eingebetteten Firmware sind nicht ohne ihre Komplexitäten.

Embedded-Design-Überlegungen für Mehr-PCB-Baugruppen

Jetzt, da wir den Fall für die Verwendung mehrerer PCBs (wo anwendbar) dargelegt haben, ist es wichtig, die Designüberlegungen beim Architektieren des eingebetteten Systems zu verstehen. Sowohl aus Hardware- als auch aus Softwareperspektive gibt es Nuancen, die wir nicht so sorgfältig abwägen, wenn wir alles auf eine einzige Platine setzen.

Die erste Überlegung, die uns in den Sinn kommen sollte, ist die Kommunikation zwischen den Platinen. Wie werden die einzelnen Platinen miteinander kommunizieren? Welche Art von Rechenleistung (wenn überhaupt) befindet sich auf jeder Platine? Vielleicht besteht eine Platine aus dem Gehirn, während die anderen aus Sensoren bestehen? Während wir unsere Übertragungsprotokolle sorgfältig auswählen, sei es I2C, SPI, UART, Ethernet usw., müssen wir auch die Übertragungsleitungen, Signalintegrität und vor allem den Signaltransfer durch Verbindungsstecker zwischen den Platinen abwägen. Das Schlimmste, was einem Designer passieren kann (und glauben Sie mir, ich war schon dort), ist, das gesamte System zu entwerfen und die PCBs vom Hersteller zurückzuerhalten, nur um festzustellen, dass ein oder zwei Taktssignale fehlen. Wir vergessen auch oft, Ersatzpins an unseren Verbindungssteckern zwischen den Platinen vorzusehen, und versuchen, die Pinanzahl maximal auszureizen. Das ist etwas, das uns am Ende wirklich beißen kann. Ein Design mit einem Multi-Board-Projekt im Sinn, wie die Multi-Board Assembly-Funktion in Altium Designer, ist ein Muss, wenn so viele Kommunikationsleitungen zwischen PCBs verlegt werden.

Wir müssen auch darüber nachdenken, wie wir die Stromversorgung verteilen, besonders wenn wir Stromschienen mit unserem Mikroprozessor überwachen werden. Wir möchten Zugänglichkeit zum „Gehirn“ ermöglichen, damit es auf katastrophale Ereignisse überwachen kann, aber wir müssen auch Schaltnetzteilrauschen, Stromverteilung für schwere Lasten und ob unsere Verbindungssteckerpins für diese Art von Leistung ausgelegt sind, berücksichtigen.

Zuletzt, obwohl es nicht direkt mit der Software des eingebetteten Systems zusammenhängt, spielt auch das mechanische Design eine wichtige Rolle. Druckknöpfe, Touchscreens und andere physische Schnittstellen zum Benutzer sind immer noch mit dem Mikroprozessor verbunden und müssen berücksichtigt werden. Kann die Verkabelung so verlegt werden, dass der Mikroprozessor auf seine Eingänge zugreifen kann? Haben wir die Signalintegrität des hochgeschwindigkeitsdigitalen Ausgangs berücksichtigt, während wir ihn von einer Platine zur anderen führen? Das sind Dinge, die wir bedenken müssen, wenn wir unser eingebettetes Gerät entwerfen.

Herausforderungen und Lösungen

Eine der am meisten unterschätzten Herausforderungen, die ich immer wieder in wachsenden Startups (und sogar großen Unternehmen) gesehen habe, war die Plage der Versionskontrollsysteme zwischen Software und Hardware. Die Verwaltung von Software-Releases gegenüber PCB-Revisionen ist zu einem nie endenden Kampf geworden, der oft zu Verwirrung, Verzögerungen und sogar Produktfehlern führt.

Beispielsweise erforderte in einem Startup, mit dem ich gearbeitet habe, eine geringfügige Modifikation der PCB eine Neufertigung und somit ein Update der Firmware (wenn auch minimal). Aufgrund schlechter Versionskontrolle hat das Engineering-Team die neue Firmware auf älteren PCB-Versionen eingesetzt, was zu unerwarteten Brownouts und einer periodischen Rauchwolke führte. Glücklicherweise haben wir es bemerkt, bevor das Produkt verschickt wurde, aber es war tagelang ein absoluter Albtraum.

Um diese Fallstricke zu vermeiden, ist es entscheidend, ein solides Versionskontrollsystem zu etablieren und eine klare Kommunikation zwischen den Hardware- und Software-Teams sicherzustellen. Selbst ein einfaches Versionskontrollsystem wie ein Git-Hash (oder semantische Version) für die Firmware, zusammen mit einer grundlegenden unterstützten Lookup-Tabelle für Hardware-Revisionen, kann ausreichend sein, um zu beginnen. Mit der Zeit reduzieren ausgefeiltere Mechanismen wie die Hardware-Revisionserkennung in der Firmware (und somit die Überprüfung der Kompatibilität) ebenfalls Verwechslungen.

Neben der Softwareversionierung ist es auch wichtig, über die Modularität des Codes nachzudenken. Bei Spaghetti-Code könnte das Austauschen einer Sensorplatine mit neuen Chips oder Sensoren zu einem Refactoring-Albtraum werden. Das Modularisieren Ihrer Gerätetreiber und das Erstellen von Hardware-Abstraktionsschichten ermöglicht es, Komponenten über Jahre hinweg leicht auszutauschen. Dies ist etwas, das mit der Zeit immer beliebter geworden ist, da eingebettete Systeme an Komplexität zugenommen haben.

Fazit

Wenn wir über die Architektur eingebetteter Systeme nachdenken, müssen wir nicht immer klein denken. Raumfahrzeuge und Automobile sind extrem komplexe eingebettete Systeme, aber auch Smartphones. Ob wir einen internetverbundenen Löffel oder den nächsten Satelliten entwerfen, das Verständnis der Kompromisse für die Architektur eingebetteter Systeme ist äußerst wichtig, wenn man für mehrere PCBs entwirft. Wir haben viele Konzepte in diesem Artikel erkundet, aber es gibt noch viele mehr, die Sie zweifellos auf Ihrer Reise finden werden.

Über den Autor / über die Autorin

Über den Autor / über die Autorin

Ari ist ein PCB-Designer mit umfassender Erfahrung in der Entwicklung, Herstellung, Prüfung und Integration verschiedener Softwaresysteme. Dabei bringt er leidenschaftlich gern Entwickler aus den Bereichen Design, Prüfung und Abnahme zusammen, um gemeinsam an Projekten zu arbeiten und diese voranzutreiben.

Ähnliche Resourcen

Verwandte technische Dokumentation

Zur Startseite
Thank you, you are now subscribed to updates.