BMS CAN-Bus-Integration: CAN vs. SMBus vs. DroneCAN im Pack-Design

Kurzantwort: CAN, SMBus und DroneCAN lösen dasselbe Problem (Batterie-Telemetrie vom Pack herunterzubekommen) an drei unterschiedlichen Punkten der Kurve zwischen Komplexität und Leistungsfähigkeit. SMBus ist eine einfache Verbindung mit geringer Knotenzahl, die üblicherweise als Single-Master-Bus für eine Batterie im Gespräch mit einem Host betrieben wird. CAN ist ein Multi-Master-Bus mit hoher EMV-Toleranz, gebaut für viele Knoten an einem Adernpaar. DroneCAN läuft auf der physikalischen Schicht von CAN auf und fügt ein standardisiertes Nachrichtenverzeichnis sowie eine dynamische Knotenadressierung hinzu, die PX4 und ArduPilot bereits nativ sprechen. Die Wahl richtet sich nach Knotenzahl, EMV-Exposition und danach, ob Ihr Flug- oder Bewegungs-Stack bereits DroneCAN erwartet, nicht danach, welches Protokoll am modernsten klingt.

Warum die Protokollwahl die gesamte Pack-Integration prägt

Das Kommunikationsprotokoll ist eines der letzten Dinge, die Ingenieure bei der Spezifikation eines kundenspezifischen Batteriepacks festlegen, und eines der teuersten, um es im Nachhinein zu ändern.

Wird es zu spät festgelegt, gehen drei Dinge schief. Erstens Gateway-Komplexität: Spricht das BMS SMBus, der Flugcontroller aber nur eine CAN-Schnittstelle hat, muss jemand eine Protokollbrücke bauen und validieren, die es gar nicht hätte geben müssen. Zweitens durch EMV verfälschte Telemetrie: Ein Bus, der für eine ruhige Laborumgebung ausgelegt wurde, verhält sich anders neben vier ESCs, die mit zehntausenden Hertz schalten, und dieser Unterschied zeigt sich als unregelmäßige Spannungswerte, nicht als sauberer Ausfall. Drittens fehlgeschlagene Vorflug-Scharfschaltprüfungen: Die meisten Autopilot-Stacks verweigern das Scharfschalten ohne gültige, aktuelle Batteriedaten, sodass aus einer grenzwertigen Busverbindung ein am Boden bleibendes Flugerät wird, nicht nur eine Lücke im Log.

Nichts davon ist protokollspezifisches Pech. Es ist die direkte Folge davon, „eine Kommunikationsschnittstelle“ zu spezifizieren, statt CAN, SMBus oder DroneCAN mit physikalischer Schicht und Nachrichtenformat festzulegen, bevor das Pack-Layout gezeichnet wird. Dieser Leitfaden liefert die Detailtiefe auf Frame-Ebene, physikalischer Schicht und Fehlermodus, um diese Entscheidung richtig zu treffen und sie so zu spezifizieren, dass sowohl Ihr BMS-Anbieter als auch Ihr Integrationsteam danach bauen können.

Dan-Techs eigene Drohnen-Packs werden bereits standardmäßig mit CANBUS, RS485 und UART als Smart-BMS-Kommunikationsoptionen ausgeliefert, und CAN- sowie DroneCAN-kompatible Steckervarianten sind auf Anfrage erhältlich. Dieser Beitrag erklärt, was auf der Leitung tatsächlich passiert, damit Sie die richtige Wahl spezifizieren können.

CAN, SMBus und DroneCAN im Vergleich: die Zahlen, auf die es ankommt

Alle drei Protokolle übertragen kleine Telemetrie-Nutzlasten (Spannung, Strom, Temperatur, Ladezustand) zwischen einer Batterie und einem Host. Sie unterscheiden sich in physikalischer Schicht, Adressierung und Topologie, nicht in den übertragenen Daten.

Die Zeile, die die meisten Erstspezifikationen zu Fall bringt, ist die Knotenzahl. CAN selbst begrenzt die Anzahl der Knoten an einem Bus nicht; die Grenze ergibt sich aus der Eingangskapazität der Transceiver und der Buslast, was eine technische Randbedingung der physikalischen Schicht ist, keine Protokollregel. DroneCAN dagegen hat eine feste Grenze: 127 Knoten-IDs, weil das Adressierungsschema 7 Bit breit ist.

Warum SMBus dort an seine Grenzen stößt, wo es das tut

Die Kabellängen-Obergrenze von SMBus ist nicht willkürlich. Die SMBus-2.0-Spezifikation begrenzt die gesamte Buskapazität auf 400 pF. Standard-Zweileiterkabel liegen je nach Aufbau bei etwa 50-100 pF pro Meter, und jeder Geräteabgriff und Steckverbinder fügt zusätzlich seine eigene parasitäre Kapazität hinzu. Rechnet man das durch, landet man bei rund einem halben Meter praktikabler Kabellänge, bevor die Timing-Reserven des Busses zu erodieren beginnen und der Master anfängt, Bitfehler zu sehen.

Das ist der eigentliche Grund, warum SMBus ein „Batterie-zu-Host“-Protokoll ist, kein „Batterie-zu-irgendwas-am-Luftfahrzeug“-Protokoll. Es wurde für ein Gerät entworfen, das direkt neben der Batterie sitzt, wie der Power-Management-IC eines Laptops, nicht für eine Signalleitung über einen zwei Meter langen Flügelholm bis zum Flugcontroller. Die in Smart-Battery-Designs übliche Single-Master-Konvention verstärkt das: Ohne einen zweiten Master am Bus, gegen den arbitriert werden müsste, gibt es keinen Grund, diese Komplexität einzubauen, sodass SMBus in der Praxis bewusst einfach bleibt, und genau diese Einfachheit begrenzt seine Reichweite.

Im Inneren des Frames: Wie eine BMS-Nachricht auf der Leitung tatsächlich aussieht

Vergleichstabellen sagen Ihnen, welches Protokoll Sie wählen sollten. Sie sagen Ihnen nicht, was zu tun ist, sobald Sie sich für CAN oder DroneCAN entschieden haben und die Nachricht tatsächlich definieren müssen, die die Zellspannungs- und Temperaturdaten Ihres BMS trägt. Das ist der Teil, den jeder allgemeine Protokoll-Übersichtsartikel auslässt.

CAN-Arbitrierungs-ID, DLC und Priorität

Ein klassischer CAN-Frame besteht aus drei Feldern, die für das BMS-Design wichtig sind: der Arbitrierungs-ID, dem Data Length Code (DLC) und der Nutzlast selbst, bis zu 8 Byte.

Die Arbitrierungs-ID (11 Bit im Standard-CAN 2.0A, 29 Bit im Extended-CAN 2.0B) erfüllt zwei Aufgaben gleichzeitig. Sie identifiziert den Nachrichtentyp, und sie legt die Priorität fest. Die CAN-Arbitrierung arbeitet mit dominanten Bits: Eine logische 0 gewinnt gegen eine logische 1, wenn zwei Knoten gleichzeitig senden. Das bedeutet, eine numerisch niedrigere ID gewinnt die Arbitrierung immer und wird zuerst gesendet. Ein gut konstruiertes Pack reserviert niedrige IDs für sicherheitskritische Nachrichten (Zellenunterspannung, Übertemperatur, BMS-Fehler) und höhere IDs für routinemäßige Telemetrie (Ladezustand, Zyklenzahl), sodass eine Fehlermeldung immer durchkommt, selbst wenn der Bus mit routinemäßigem Polling ausgelastet ist.

Das DLC-Feld gibt an, wie viele Datenbytes folgen, von 0 bis 8 beim klassischen CAN. Ein typischer BMS-Broadcast-Frame könnte seine 8 Byte wie folgt aufteilen: 2 Byte Pack-Spannung (Little-Endian, Millivolt), 2 Byte Pack-Strom (vorzeichenbehaftet, Milliampere), 1 Byte Ladezustand (0-100 %), 1 Byte Temperatur (mit Offset und Skalierung kodiert) und 2 Byte für Statusflags oder einen umlaufenden Zähler. Es gibt keinen universellen Standard, der diese genauen Byte-Offsets festlegt. Dieses Layout entwirft und dokumentiert man einmal pro Projekt, und genau das ist die Art kundenspezifischer BMS-Kommunikationsschnittstelle, die bei einer Pack-Integration schriftlich spezifiziert sein muss, bevor auf beiden Seiten Firmware geschrieben wird.

Der Tail-Byte-Transport von DroneCAN

DroneCAN fügt eine Transportschicht über den rohen CAN-Frames hinzu, um Nachrichten zu übertragen, die größer als 7 Nutzlast-Bytes sind (DroneCAN reserviert das 8. Byte jedes Frames für den eigenen Gebrauch, wie unten beschrieben).

Jeder DroneCAN-CAN-Frame endet mit einem Tail-Byte, in dem vier Felder in einem Byte zusammengefasst sind: ein Start-of-Transfer-Flag, ein End-of-Transfer-Flag, ein Toggle-Bit und eine 5-Bit-Transfer-ID. Eine Nachricht, die in 7 Byte oder weniger passt, geht als einzelner Frame mit gesetztem Start- und End-Flag hinaus. Eine größere Nachricht, etwa ein vollständiger Batteriestatusbericht mit Spannung, Strom, Temperatur und Ladezustandsfeldern zusammen, wird auf mehrere Frames aufgeteilt: Der erste Frame setzt das Start-Flag, der letzte das End-Flag, und das Toggle-Bit wechselt bei jedem dazwischenliegenden Frame, sodass der Empfänger einen verlorenen oder doppelten Frame in der Sequenz erkennen kann.

Auch die Knotenadressierung funktioniert anders. Statt dass jeder Knoten eine feste, vorkonfigurierte Adresse hat, senden DroneCAN-Knoten ohne zugewiesene ID eine anonyme Zuteilungsanfrage, und ein koordinierender Knoten (oder, bei einem Setup mit einem einzigen Koordinator, der Flugcontroller selbst) weist ihnen eine Knoten-ID von 1-127 zu. Das ist es, was es ermöglicht, eine DroneCAN-kompatible Batterie in ein unbekanntes Luftfahrzeug einzustecken und sie erscheinen zu lassen, ohne manuell eine Adresse zu konfigurieren, auf Kosten dieser festen Obergrenze von 127 Knoten.

Durchgerechnetes Beispiel: Eine BatteryInfo-Nachricht Schritt für Schritt dekodieren

Gehen wir durch, was passiert, wenn ein DroneCAN-fähiges BMS seinen Status meldet. Konzeptionell:

1. Das BMS stellt eine Batteriestatusnachricht zusammen: Spannung, Strom, verbleibender Kapazitätsprozentsatz, Temperatur und ein Status-/Gesundheitsfeld. Diese Nutzlast ist breiter als 7 Byte.
2. Der DroneCAN-Stack des BMS teilt die Nutzlast in aufeinanderfolgende 7-Byte-Blöcke auf und hängt an jeden ein Tail-Byte an, wobei eine Transfer-ID über alle Blöcke dieser Übertragung hinweg geteilt wird.
3. Der erste CAN-Frame geht mit gesetztem Start-of-Transfer-Bit des Tail-Bytes hinaus. Seine Arbitrierungs-ID kodiert den Nachrichtentyp und die eigene Knoten-ID des BMS, sodass jeder mithörende Knoten (Flugcontroller, Bodenstationsbrücke, Logger) weiß, womit er es zu tun hat, noch bevor er die Nutzlast liest.
4. Nachfolgende Frames tragen die verbleibenden Nutzlastblöcke, jeweils mit gegenüber dem vorherigen Frame umgeschaltetem Toggle-Bit. Sieht der Empfänger zwei aufeinanderfolgende Frames mit demselben Toggle-Zustand, weiß er, dass ein Frame verloren gegangen ist, und verwirft die unvollständige Nachricht, statt beschädigte Daten zusammenzusetzen.
5. Der letzte Frame setzt das End-of-Transfer-Bit. Der Empfänger reiht alle Nutzlastblöcke in der richtigen Reihenfolge aneinander und dekodiert die vollständige Batteriestatusstruktur.
6. Kennt der Flugcontroller die Knoten-ID des BMS noch nicht, geht diesem gesamten Austausch der oben beschriebene dynamische Zuteilungs-Handshake voraus.

Die technische Erkenntnis: Das Tail-Byte von DroneCAN macht aus einem auf 8-Byte-Frames begrenzten Bus einen, der beliebig große strukturierte Nachrichten tragen kann, auf Kosten eines Nutzlast-Bytes pro Frame und der zusätzlichen Komplexität der Wiederzusammensetzungslogik auf beiden Seiten.

Physikalische Schicht und EMV: Was CAN-Signalintegrität auf einem Drohnen- oder Roboterchassis tatsächlich zunichtemacht

Das ist der Abschnitt, den jeder konkurrierende Artikel auslässt, und meist genau dort, wo ein Bus, der auf der Werkbank perfekt funktionierte, im Flug anfängt, Frames zu verlieren.

Die differenzielle Signalübertragung von CAN ist tatsächlich robust gegenüber Gleichtaktstörungen; genau das ist der Sinn, zwei Drähte statt eines masse-bezogenen zu verwenden. Aber robust heißt nicht immun, und ein Drohnen- oder Roboterchassis hat drei Störquellen, die ein Werkbank-Aufbau nicht hat: ESC-/Motorcontroller-Schaltvorgänge im Bereich zehntausender Hertz, hohe di/dt-Stromspitzen in der Leistungsverkabelung und gemeinsame Masserückführungen zwischen Leistungs- und Signalpfaden.

Terminierung. Ein CAN-Bus benötigt an jedem physischen Busende einen 120-Ohm-Widerstand, was eine kombinierte differenzielle Abschlussimpedanz von etwa 60 Ohm ergibt. Fehlende oder falsch platzierte Terminierung verursacht Signalreflexionen, die sich als unregelmäßige Bitfehler zeigen, nicht als sauberer Fehler, was dies zu einem der am schwersten zu diagnostizierenden CAN-Probleme macht, ohne ein Oszilloskop am Bus.

Topologie. CAN ist als linearer Bus mit kurzen Stichleitungen konzipiert, nicht als Stern. Lange Stichleitungen vom Hauptstrang wirken wie unterminierte Antennen und reflektieren Signalenergie zurück in den Bus. Halten Sie die Stichleitungslänge kurz (einige Zentimeter, nicht Dutzende), wo immer ein Knoten in den Hauptstrang einzweigt.

Kabel- und Steckverbinderwahl. Verdrilltes Adernpaar ist nicht optional; es ist überhaupt erst das, was die differenzielle Signalübertragung gegen Gleichtaktstörungen funktionieren lässt. JST-GH- und Molex-Micro-Fit-Steckverbinder sind auf kleineren Drohnen-Luftfahrzeugen verbreitet, wo der Platinenplatz knapp ist; XT30 taucht häufiger auf Robotikplattformen auf, wo der Steckverbinder auch Vibration und wiederholte Steckzyklen überstehen muss. Für welchen Sie sich auch entscheiden: Halten Sie die Verdrillung des CAN-Paares bis zu den Pins intakt; die Verdrillung am Steckverbinder aufzulösen, um Platz zu sparen, untergräbt den Sinn ihrer Verwendung.

Gemeinsame Masserückführungen. Der mit Abstand größte EMV-Fehler auf einem Drohnen- oder Roboterchassis besteht darin, die Massereferenz von CAN über denselben Rückleiter wie den Motorphasenstrom zu führen. Jeder Ampere Schaltstrom über eine gemeinsame Masse erzeugt einen Spannungsabfall, der sich als Gleichtaktstörung auf dem CAN-Paar zeigt. Abhilfe schaffen Sie, indem Sie CAN (und jedem anderen Low-Level-Signalbus) eine eigene Masserückführung zu einem einzigen Punkt geben, getrennt vom Hochstrom-Rückpfad von Motor und ESC, und indem Sie das verdrillte CAN-Adernpaar physisch von Motorphasenleitungen und ESC-Schaltknoten fernhalten, statt es im selben Kabelbaum mitzubündeln.

In Dan-Techs Wettbewerbsanalyse der zu diesem Thema bestplatzierten Inhalte quantifiziert keiner der Artikel Terminierungswerte, Grenzwerte für Stichleitungslängen oder die Trennung der Masserückführung. Das ist die Lücke: Vergleichstabellen sagen Ihnen, welches Protokoll Sie wählen sollten, aber nicht, wie Sie es verlegen, damit es das Luftfahrzeug übersteht, in das es eingebaut ist.

Wenn der Bus ausfällt: Fehlerzustände, Watchdogs und geordnete Degradation

Ein Protokollvergleich, der bei „CAN ist robuster“ endet, ohne zu erklären, was bei einem Ausfall passiert, gibt Ihnen nicht genug an die Hand, um ein sicheres System darum herum zu entwerfen.

Der Fehlerzählmechanismus von CAN. Jeder CAN-Controller führt einen Transmit Error Counter (TEC) und einen Receive Error Counter (REC). Ein erkannter Busfehler erhöht den jeweiligen Zähler; eine saubere Sendung oder ein sauberer Empfang verringert ihn. Überschreitet einer der Zähler 127, geht der Knoten in den Zustand Error Passive über, in dem er zwar weiterhin normal empfangen kann, aber einen Teil seiner Fähigkeit verliert, während der Arbitrierung dominante Bits durchzusetzen. Überschreitet er 255, geht der Knoten vollständig in Bus-Off, trennt sich selbst vom Bus, um den Rest des Netzwerks vor einem möglicherweise fehlerhaften Sender zu schützen. Die Wiederherstellung aus Bus-Off erfordert je nach Implementierung entweder eine definierte Recovery-Sequenz (128 am Bus beobachtete Vorkommen von 11 aufeinanderfolgenden rezessiven Bits) oder einen Controller-Reset.

Das ist für das Pack-Design relevant, weil ein BMS, das aufgrund eines verrauschten Steckverbinders und nicht eines tatsächlichen Pack-Fehlers in Bus-Off geht, komplett aufhört zu melden. Kann die Fail-Safe-Logik des Flug- oder Bewegungscontrollers „Batterie ist in Ordnung, Busverbindung ist beeinträchtigt“ nicht von „Batterie ist ausgefallen“ unterscheiden, trifft sie genau in der Situation die falsche Entscheidung, in der es am meisten darauf ankommt, es richtig zu machen.

Heartbeat- und Watchdog-Muster. DroneCAN-Knoten senden eine periodische Status-/Heartbeat-Nachricht (in typischen Implementierungen etwa einmal pro Sekunde), gerade damit ein Lauscher einen hängenden Knoten erkennen kann, selbst wenn technisch kein Fehlerzustand vorliegt. Bleibt dieser Heartbeat für den Flugcontroller innerhalb eines definierten Timeouts aus, behandelt er den Knoten als ausgefallen, nicht nur als still. SMBus hat kein gleichwertiges natives Heartbeat; ein Host, der eine SMBus-Batterie abfragt, muss eine eigene Lese-Timeout- und Wiederholungsrichtlinie definieren, weil ein stiller Bus und ein ausgelasteter Bus sonst identisch aussehen.

Geordnete Degradation. Die richtige Reaktion auf veraltete Batteriedaten ist ein Staleness-Timeout, kein unbegrenztes Warten auf den nächsten guten Messwert. Wurde die CAN- oder DroneCAN-Telemetrie nicht innerhalb eines definierten Zeitfensters aktualisiert, sollte der Controller den Batteriestatus als unbekannt kennzeichnen, statt weiter dem letzten Wert zu vertrauen, und dieses Kennzeichen sollte dieselbe Fail-Safe-Logik (Warnung, Return-to-Launch, kontrollierte Abschaltung) auslösen, die ein echtes Unterspannungsereignis auslösen würde. Bei SMBus ist das Äquivalent eine begrenzte Anzahl fehlgeschlagener Leseversuche, bevor dasselbe Fallback greift. So oder so ist der Fehlerzustand, gegen den man konstruieren muss, ein Controller, der weiterfliegt oder weiterfährt auf Basis von Daten, denen er nicht mehr vertrauen sollte.

Das Protokoll wählen: ein Entscheidungsrahmen für die OEM-Integration

Überspringen Sie „kommt darauf an“ und arbeiten Sie stattdessen vier konkrete Variablen durch.

Knotenzahl. Eine Batterie, ein Host, sonst nichts am Bus: SMBus ist tatsächlich einfacher zu implementieren und zu debuggen, und es gibt keinen Grund, die zusätzliche Komplexität von CAN für eine Verbindung mitzuschleppen, die sie nie brauchen wird. Mehr als eine Handvoll Geräte, die sich einen Bus teilen (BMS, ESCs, GPS, periphere Sensoren): Das ist CAN- oder DroneCAN-Terrain, nicht SMBus.

Erforderliche Aktualisierungsrate. Die Bitrate der 100-kHz-Klasse von SMBus reicht völlig für eine Batterie, die ein- bis zweimal pro Sekunde meldet. Braucht Ihre Anwendung Telemetrie-Updates unter 100 ms über mehrere Knoten hinweg, die sich Bandbreite teilen, bewältigt die höhere Bitrate und Multi-Master-Arbitrierung von CAN Buskonflikte weit besser, als es eine Single-Master-SMBus-Verbindung je könnte.

EMV-Exposition. Eine Batterie in einem abgeschirmten Gehäuse neben einem einzelnen Host mit geringer Leistung ist eine Umgebung mit geringer EMV, in der die einfachere physikalische Schicht von SMBus ein vertretbarer Kompromiss ist. Ein Pack, das quer über ein Luftfahrzeug oder Chassis neben Motorcontrollern verkabelt ist, ist eine Umgebung mit hoher EMV, in der die differenzielle Signalübertragung von CAN und die oben behandelte Disziplin der physikalischen Schicht die richtige Investition sind.

Flug- oder Bewegungs-Stack. Läuft die Plattform mit PX4 oder ArduPilot, verschafft Ihnen DroneCAN native Unterstützung und ein standardisiertes Nachrichtenverzeichnis, ohne einen eigenen Treiber auf der Autopilotseite zu schreiben, was echte Integrationszeit spart. Läuft die Plattform mit einem proprietären Flug- oder Bewegungscontroller-Stack, gibt Ihnen rohes CAN mit einem selbst definierten Frame-Layout (gemäß dem oben behandelten Design von Arbitrierungs-ID und DLC) volle Kontrolle über das Nachrichtenformat, ohne die Knoten-ID-Obergrenze oder den Transport-Overhead von DroneCAN zu erben.

Multi-BMS- und Parallel-Pack-CAN-Topologien für größere Industrie- und Robotikplattformen

Größere Industrie- und Robotikplattformen betreiben zunehmend mehrere Batteriepacks parallel, jedes mit eigenem BMS, die sich einen CAN-Bus zu einem zentralen Controller teilen. Das ist ein für Dan-Tech real relevantes Szenario in der kundenspezifischen Pack-Konstruktion, und es ist eine Lücke in den zu diesem Thema bestplatzierten Inhalten, die Dan-Techs Wettbewerbsanalyse identifiziert hat.

Das Kernproblem beim Design ist die Kollision von Arbitrierungs-IDs. Versucht jedes BMS an einem Multi-Pack-Bus dieselbe Arbitrierungs-ID für „Pack-Spannung“ zu verwenden, hat der Bus keine Möglichkeit zu unterscheiden, welchen Packs Messwert gerade eingetroffen ist. Die Lösung ist eine durchdachte ID-Zuteilungskonvention: Reservieren Sie einen ID-Block pro Nachrichtentyp und verwenden Sie dann ein Unterfeld innerhalb dieses Blocks (oder die niederwertigen Bits des Frames), um eine Pack-Instanznummer zu tragen, sodass die Spannungsmeldung von Pack 1 und die von Pack 4 unterschiedliche, deterministisch geordnete Arbitrierungs-IDs belegen. Sicherheitskritische Nachrichten (der Fehler- oder Unterspannungszustand jedes einzelnen Packs) erhalten in diesem gesamten Schema weiterhin die niedrigsten IDs, sodass der Fehler eines Packs den Controller vor der routinemäßigen Telemetrie jedes anderen Packs am Bus erreicht, unabhängig davon, welches Pack ihn meldet.

DroneCAN umgeht einen Teil dieses Problems bereits konstruktionsbedingt: Sein Dienst zur dynamischen Knoten-ID-Zuteilung weist jedem BMS bereits eine eindeutige Knoten-ID (1-127) zu, ohne dass ein Mensch eine Nummerierungskonvention entwerfen muss. Der Kompromiss ist dieselbe zuvor besprochene Obergrenze von 127 Knoten, die für eine Multi-Pack-Industrieplattform selten eine echte Einschränkung darstellt, aber es lohnt sich, dies gegen Ihre tatsächliche Knotenzahl (BMS-Einheiten plus alle weiteren DroneCAN-Geräte) zu prüfen, bevor Sie sich im großen Maßstab auf das Protokoll festlegen.

Wichtige Entscheidungen: Zusammenfassung

• SMBus ist die richtige Wahl für eine einzelne Batterie im Gespräch mit einem einzelnen nahegelegenen Host, und seine praktische Kabellängengrenze von rund 0,5 m ergibt sich direkt aus der 400-pF-Buskapazitätsgrenze der SMBus-2.0-Spezifikation, nicht aus einer willkürlichen Designentscheidung.
• CAN ist die richtige Wahl, sobald sich mehr als eine Handvoll Knoten einen Bus teilen, EMV-Exposition real ist oder Sie ein eigenes Nachrichtenformat für einen proprietären Flug- oder Bewegungs-Stack definieren. Die Arbitrierungs-ID dient zugleich als Nachrichtenpriorität: numerisch niedrigere IDs gewinnen immer.
• DroneCAN ist die richtige Wahl, wenn die Plattform bereits mit PX4 oder ArduPilot läuft, was native Unterstützung und ein standardisiertes Nachrichtenverzeichnis liefert. Sein Tail-Byte-Transport lässt Mehrframe-Nachrichten die 8-Byte-pro-Frame-Grenze von CAN überschreiten, und seine dynamische Knoten-ID-Zuteilung erspart die manuelle Adresskonfiguration, auf Kosten einer Obergrenze von 127 Knoten.
• Disziplin bei der physikalischen Schicht (120-Ohm-Terminierung an jedem Busende, kurze Stichleitungen, bis zum Steckverbinder intakt gehaltenes verdrilltes Adernpaar und eine vom Motor-/ESC-Strompfad getrennt gehaltene CAN-Masserückführung) verhindert die meisten der unregelmäßigen, schwer zu diagnostizierenden CAN-Fehler, die auf Drohnen- und Roboterchassis auftreten.
• Konstruieren Sie für geordnete Degradation, nicht nur für Erkennung: Ein Staleness-Timeout für die Batterietelemetrie, gepaart mit derselben Fail-Safe-Logik, die ein echtes Unterspannungsereignis auslösen würde, ist es, was einen Busfehler davon abhält, sich in eine nicht angeordnete Flug- oder Bewegungsentscheidung zu verwandeln.
• Multi-BMS-Busse brauchen eine durchdachte ID-Zuteilungskonvention, bevor das zweite Pack an den Bus geht, nicht erst nachdem eine Arbitrierungskollision im Test auffällt.

FAQ

Ist DroneCAN dasselbe wie CAN?

Nein. DroneCAN läuft auf derselben physikalischen Schicht wie klassisches CAN (CAN 2.0), fügt aber ein eigenes Adressierungsschema, ein Nachrichtenverzeichnis und ein Tail-Byte-Transportprotokoll für Mehrframe-Nachrichten hinzu. Ein CAN-Transceiver ist für DroneCAN notwendig, aber ein roher CAN-Frame ohne das Tail-Byte und die Knoten-ID-Konventionen von DroneCAN ist keine gültige DroneCAN-Nachricht.

Warum funktioniert mein CAN-Bus auf der Werkbank, verliert aber Frames, sobald er im Luftfahrzeug verbaut ist?

Die häufigste Ursache ist EMV-Einkopplung über eine gemeinsame Masserückführung mit Motor- oder ESC-Schaltstrom, gefolgt von fehlender oder falscher 120-Ohm-Terminierung und langen unterminierten Stichleitungen. Werkbank-Aufbauten haben selten eines dieser drei Probleme; verbaute Luftfahrzeuge fast immer, es sei denn, der Kabelbaum wurde gezielt so verlegt, dass sie vermieden werden.

Wie viele Knoten kann ich an einen CAN-Bus hängen?

CAN selbst legt keine feste Knotengrenze fest; die tatsächliche Einschränkung sind Transceiver-Eingangskapazität und gesamte Buslast, was die meisten eingebetteten CAN-Bus-Designs in der Praxis auf einige Dutzend Knoten pro Segment begrenzt. DroneCAN fügt eine eigene, separate Grenze hinzu: eine Obergrenze von 127 Knoten aus seinem 7-Bit-Knoten-ID-Feld.

Kann ich SMBus für einen Multi-Knoten-Telemetriebus über ein Drohnen-Luftfahrzeug verwenden?

Nicht zuverlässig. Die konventionelle Single-Master-Nutzung von SMBus und die praktische Kabellängengrenze von rund 0,5 Metern (bedingt durch seine 400-pF-Buskapazitätsgrenze) machen es geeignet für eine Batterie-zu-Host-Verbindung, nicht für einen Bus, den sich mehrere über ein Luftfahrzeug oder Chassis verteilte Geräte teilen.

Was passiert, wenn ein BMS-Knoten an meinem CAN-Bus in Bus-Off geht?

Der Knoten stellt das Senden vollständig ein, um den Rest des Busses vor einem möglicherweise fehlerhaften Sender zu schützen, ausgelöst durch das Überschreiten von 255 seines Transmit Error Counters. Die Wiederherstellung erfordert entweder eine definierte Bus-Idle-Recovery-Sequenz oder einen Controller-Reset. Gestalten Sie Ihre Fail-Safe-Logik so, dass ein fehlender Heartbeat oder veraltete Telemetrie als „Status unbekannt“ behandelt wird, nicht als „Batterie ist in Ordnung“, damit ein Busfehler nicht mit einem sauberen Messwert verwechselt wird.

Spezifizieren Sie eine Kommunikationsschnittstelle für ein kundenspezifisches Batteriepack? Dan-Tech Energy, Hersteller kundenspezifischer Li-Ion-Batteriepacks mit Produktion in Deutschland und den USA, baut auf Anfrage CAN-, SMBus- und DroneCAN-kompatible Steckervarianten in Drohnen- und Robotik-Packs ein. Beginnen Sie damit, Ihre Anforderungen in der ToolBox einzugrenzen, oder durchstöbern Sie den vollständigen Lithium-Ionen-Batteriepacks-Katalog, um Zell- und Konfigurationsoptionen zu sehen.

Weiterführende Lektüre:

• Kundenspezifisches BMS für Drohnen-Batteriepacks: Was zu spezifizieren ist und warum es wichtig ist: die Entscheidung PCM vs. BMS, eine Ebene über dem Protokolldetail dieses Beitrags.
• Wie man ein kundenspezifisches UAV-Batteriepack spezifiziert: ein Leitfaden für Drohnen-OEMs: der vollständige Pack-Spezifikationsprozess, von dem die Kommunikationsschnittstelle ein Baustein ist.