DE102012222919A1 - Verfahren zur Datenkommunikation auf einem Datenkommunikationsbus - Google Patents

Verfahren zur Datenkommunikation auf einem Datenkommunikationsbus Download PDF

Info

Publication number
DE102012222919A1
DE102012222919A1 DE201210222919 DE102012222919A DE102012222919A1 DE 102012222919 A1 DE102012222919 A1 DE 102012222919A1 DE 201210222919 DE201210222919 DE 201210222919 DE 102012222919 A DE102012222919 A DE 102012222919A DE 102012222919 A1 DE102012222919 A1 DE 102012222919A1
Authority
DE
Germany
Prior art keywords
bit
blocks
communication bus
messages
control unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE201210222919
Other languages
English (en)
Inventor
Christoph Brochhaus
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Samsung SDI Co Ltd
Original Assignee
Robert Bosch GmbH
Samsung SDI Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH, Samsung SDI Co Ltd filed Critical Robert Bosch GmbH
Priority to DE201210222919 priority Critical patent/DE102012222919A1/de
Publication of DE102012222919A1 publication Critical patent/DE102012222919A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40006Architecture of a communication node
    • H04L12/40013Details regarding a bus controller
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215Controller Area Network CAN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/604Address structures or formats
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/618Details of network addresses
    • H04L2101/627Controller area network [CAN] identifiers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/695Types of network addresses using masks or ranges of addresses

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Abstract

Die Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zur Anforderung von Diensten mittels eine Kommunikationsbusses (90), der ein Hauptsteuergerät (16) mit einer Anzahl von Steuergeräten (18, 20, 22) verbindet und individuelle Module (14, 24, 26, 28) oder Gruppen von Modulen (14, 24, 26, 28), die den jeweiligen Steuergeräten (18, 20, 22) zugeordnet sind, adressiert. Die Anzahl der zu adressierenden Steuergeräte (18, 20, 22) wird in einem Datenrahmen (30, 52) in Adressbereichen (32, 54) codiert. In Operatorbereichen (34, 56) der Datenrahmen (30, 52) werden logische Operatoren (36, 38, 40, 42, 44, 46, 48) codiert. Die Datenrahmen (30, 52) werden auf Bitmasken (60, 62, 80, 82, 84, 86, 88) mit jeweiligen Überschneidungen (72) zur Ermittlung eines Einsparpotentials an Botschaft (29) analysiert. Danach werden die maximalen Blöcke (64, 66, 68) übereinstimmender Bits gebildet, die dann als Botschaft (29), insbesondere als CAN-Botschaft (29) auf den Kommunikationsbus (90) übertragen werden.

Description

  • Stand der Technik
  • Elektronische Steuergeräte werden bei Automobilanwendungen heutzutage in zunehmender Zahl eingesetzt, zum Beispiel als Motorsteuergeräte, ABS, ESP und Airbagauslösegeräte, etc.. Für elektrisch angetriebene Fahrzeuge ist die Entwicklung von Batteriepacks mit einem zugehörigen Batteriemanagementsystem, umfassend Steuergeräte mit Software zur Überwachung der Batteriefunktionalität, erforderlich. Typische Batteriemanagementsysteme gewährleisten die sichere und zuverlässige Funktion der Batteriezellen und der Batteriepacks. Sie überwachen und steuern Ströme, Spannungen und Temperaturen, Isolationswiderstände sowie andere Größen für die Batteriezellen und gesamten Batteriepack. Mit Hilfe dieser Größen lassen sich Managementfunktionen realisieren, welche die Lebensdauer, die Zuverlässigkeit und vor allem die Sicherheit des Batteriesystems zum Antrieb elektrischer Fahrzeuge steigern.
  • Batteriemanagementsysteme umfassen in der Regel eine Vielzahl von Steuergeräten, auf denen jeweils individuelle Softwarefunktionalitäten ablaufen. Abhängig von der Anzahl der Batteriezellen, der Anzahl von Überwachungssensoren und der Verteilung der Batteriemodule auf verschiedene Bauräume innerhalb des Automobils, ergibt sich eine Steuergerätetopologie mit einem Hauptsteuergerät und diesem untergeordneten mehreren Steuergeräten für die Erfassung der Messdaten direkt an den einzelnen Batteriemodulen. Bei den Messdaten handelt es sich um Daten hinsichtlich der Batteriezellenspannungen, der Batteriezellen bzw. Batteriemodul-Temperatur, der auftretenden Ströme sowie des Isolationswiderstandes, um einige Beispiele zu nennen. Die erfassten Messdaten werden zwischen den Steuergeräten über einen Kommunikationsbus ausgetauscht. Bei diesem Kommunikationsbus handelt es sich beispielsweise um einen CAN-Kommunikationsdatenbus. Zusätzlich werden von den Steuergeräten, die den einzelnen Batteriemodulen zugeordnet sind, Funktionen wie das „Cell-Balancing“ (Aus-/Angleichen der Batteriezellenspannungen im Batteriepack) oder Diagnosefunktionen, zum Beispiel eine Leitungsbruchdiagnose, übernommen. Die Notwendigkeit für das Ausführen solcher Dienstfunktionen wird im Hauptsteuergerät bestimmt und in Form von Dienstanforderungen (Service Requests) an die einzelnen Steuergeräte übermittelt.
  • Bei der Kommunikation der Messdaten von den verschiedenen Steuergeräten zum hierarchisch übergeordneten Hauptsteuergerät ist der Einsatz eines Kommunikationsbusses, wie zum Beispiel eines CAN-Busses sehr weit verbreitet. Die Anforderung von Funktionen, wie dem oben erwähnten Cell-Balancing oder auf Leitungsbruchdiagnose und dergleichen mehr, werden ebenfalls über diesen CAN-Bus vom Hauptsteuergerät zu den diesem untergeordneten Steuergeräten geschickt. Da jedes Sensorsteuergerät individuell adressiert werden muss und in jeder Dienstanforderung, sei es Cell-Balancing, sei es Leitungsbruchdiagnose oder dergleichen, eine jede Batteriezelle individuell adressiert werden muss, ist für die Anforderung derartiger Dienste ein relativ hoher Kommunikationsaufwand erforderlich. Bei hochfrequenten und zyklisch benötigten Diensten ist die Anzahl der Dienstanforderungen auf dem Kommunikationsbus verglichen mit dem Gesamtdatenaufkommen sehr hoch.
  • Funktionenaufbau und Protokolle in Bezug auf einen CAN-Datenbus lassen sich der Website „http://de.wikipedia.org/wiki/Controller_Area_Network“ entnehmen. Anhand des Beispieles der Dienstanforderung „Cell-Balancing“ sei die herkömmliche Vorgehensweise kurz beschrieben:
    Das Batteriepack umfasst in der Regel ein Hauptsteuergerät mit einer Anzahl x von Sensorsteuergeräten. Ein jedes der x Steuergeräte überwacht eine Anzahl y Batteriezellen. Wenn das Hauptsteuergerät einen „Cell-Balancing“-Bedarf ermittelt hat, d.h. wenn für eine Untermenge aller Batteriezellen das „Cell-Balancing“ aktiviert werden muss, wird an ein jedes der y Steuergeräte mindestens eine CAN-Botschaft geschickt, welche Informationen über die zu balancierenden Zellen enthält. Die einzelnen y Steuergeräte aktivieren das Cell-Balancing für die vom Hauptsteuergerät gemeldeten Batteriezellen. Bei einer jeglichen Änderung des „Cell-Balancing“-Bedarfs muss erneut mindestens eine CAN-Botschaft an alle y Steuergeräte verschickt werden, welche die Information enthält, welche Zellen weiter am „Cell-Balancing“ teilnehmen müssen.
  • Ein jedes der x Steuergeräte ist über eine individuelle CAN-ID adressierbar. Das Hauptsteuergerät schickt je eine Dienstanforderung mit einer Bitmaske, enthaltend ein Bit pro Zelle y, an jedes der x Steuergeräte. Überwacht das Steuergerät beispielsweise 30 Batteriezellen umfasst die Bitmaske demnach 30 Bit. Die x Steuergeräte aktivieren für die Zellen das „Cell-Balancing“, wenn in der Bitmaske an der entsprechenden Stelle eine 1 steht und deaktivieren das „Cell-Balancing“ für den Fall, dass an der entsprechenden Stelle der Bitmaske ein 0 steht. Der Vorgang wiederholt sich bei jeder Änderung des „Cell-Balancing“-Bedarfes. Nachfolgend sei folgendes Beispiel genannt: Den drei Sensorsteuergeräten sind je 30 Batteriezellen zugeordnet, das Batteriepack enthält demnach 90 Zellen. Es existieren CAN-ID‘s der drei Steuergeräte mit noch folgendem Aufbau: 0x50, 0x51 und 0x52. Der Balancing-Bedarf erstreckt sich für eine Teilmenge der genannten 90 Zellen. Nun werden drei CAN-Botschaften verschickt: Eine erste CAN-Botschaft an ID 0X50 mit der Bitmaske (30 Bit) für die Batteriezellen 1 bis 30, eine weitere, zweite CAN-Botschaft an die CAN-ID 0x51 mit Bitmaske von (30 Bit) für die Zellen 31 bis 60 sowie schließlich eine dritte CAN-Botschaft an ID 0x52 mit der Bitmaske (30 Bit) für die Zellen 61 bis 90.
  • Der Nachteil dieser Vorgehensweise ist vor allem darin zu erblicken, dass zur Deaktivierung des „Cell-Balancing“ für alle 90 Zellen drei CAN-Botschaften erforderlich sind, nämlich je eine für jedes Steuergerät. Zum Aktivieren des „Cell-Balancing“ für alle Zellen sind ebenfalls drei Botschaften erforderlich, je eine pro genanntem der drei Steuergeräte. Ein eventuell durchzuführendes Umschalten, beispielsweise zwischen den geraden und ungeraden Batteriezellen, wie es beispielsweise durch eine Begrenzung der maximale Ströme oder einer maximalen Temperaturen der beteiligten Bauteile bedingt ist, erfordert somit pro Umschaltvorgang drei CAN-Botschaften.
  • Aus dem genannten Beispiel geht hervor, dass eine konventionelle Kommunikation, wie sie zum Beispiel bei der Dienstanforderung des „Cell-Balancing“ auf dem CAN-Bus realisiert wird, sehr aufwendig ist und hinsichtlich der Randbedingungen, beispielsweise der Ströme und Temperaturen, keine optimale Lösung darstellt.
  • Darstellung der Erfindung
  • Der vorliegenden Erfindung folgend wird ein Verfahren zur Vereinfachung der Dienstanforderungskommunikationen auf einem Kommunikationsdatenbus, insbesondere einem CAN-Datenbus zwischen einem Hauptsteuergerät und mehreren diesem untergeordneten Steuergeräten, insbesondere Sensorsteuergeräten, insbesondere für ein Batteriemanagementsystem vorgeschlagen. Mit dem erfindungsgemäß vorgeschlagenen Verfahren ist es möglich, eine beliebige Untermenge aller einem Hauptsteuergerät untergeordneten Steuergeräte, insbesondere Sensorsteuergeräte zu adressieren und eine Dienstanforderung, beispielsweise das erwähnte „Cell-Balancing“ oder eine Leitungsbruchdiagnose auf einer beliebigen Untermenge an Batteriezellen von Batteriemodulen eines Batteriepacks ablaufen zu lassen. Um dies zu erreichen, wird die Untermenge der adressierten Steuergeräte, insbesondere Sensorsteuergeräte und ein logischer Operator innerhalb der CAN-ID codiert. Da der CAN-Kommunikationsdatenbus zwischen dem Hauptsteuergerät und den Steuergeräten, insbesondere Sensorsteuergeräten isoliert für den übrigen CAN-Bussen im Fahrzeug betrieben wird, besteht eine große Auswahlmöglichkeit hinsichtlich der Verwendung der CAN-ID’s. Somit kann dieses Verfahren problemlos und ohne Kollision mit bereits vergebenen CAN-ID’s im Bereich des Fahrzeug-CAN umgesetzt werden. Durch die Verwendung von CAN-ID’s entsteht kein zusätzlicher Aufwand für die gezielte Adressierung von Steuergeräten, insbesondere Sensorsteuergeräten oder die Angabe von logischen Operatoren. Die jeweils an den Steuergeräten, insbesondere Sensorsteuergeräten angeschlossenen Batteriezellen der Batteriemodule werden wie gehabt mit einer Bitmaske adressiert.
  • Es bestehen auf einem CAN-Bus zwei Möglichkeiten der Adressierung. Eine erste Möglichkeit liegt in einer Adressierung mittels Standard-Frame, der einen 11-Bit-Identifier aufweist oder die Möglichkeit einer Adressierung mittels eines Extended-Frame, der eine 29-Bit-Identifier umfasst.
  • Die Art der jeweiligen Adressierung wird bei der Systemauslegung eines Batteriemanagementsystems und dessen einzelner Komponenten definiert. Bei der Adressierung mittels Standard-Frames (11-Bit-Identifier) gibt es im Vergleich zu einer Adressierung mit dem Extended-Frame, die eine 29-Bit-Identifier umfasst, eingeschränkte Möglichkeiten der Verwendung der Codierung der adressierten Steuergeräte aufgrund der geringen Anzahl verfügbarer Bits. Die verfügbaren Bits in der Adresse (11 Bits bzw. 29 Bits) werden verwendet für die jeweilige Adressierung der Steuergeräte und für logische Operatoren. Als logische Operatoren werden insbesondere „ON“ zum Aktivieren eines Dienstes, „OFF“ zum Deaktivieren eines Dienstes, „NOT“ zum Wechseln vom Aktivierten in den Deaktivierten Zustand und umgekehrt, sowie „OR“ zum Aktivieren weiterer Dienste verwendet. Zudem können alle weiteren bekannten logische Operatoren ebenfalls verwendet werden.
  • Die Aufteilung der verfügbaren Bits kann beliebig verändert werden und für jedes Projekt individuell angepasst werden. Beispielhaft sei im Folgenden die Anwendung des erfindungsgemäß vorgeschlagenen Verfahrens zur Vereinfachung der Dienstanforderungskommunikation auf einem CAN-Bus beschrieben:
  • Im Hauptsteuergerät liegt die Definition der Dienstanforderung in einem Speicher. Das Hauptsteuergerät bestimmt, ob eine Dienstanforderung an die Steuergeräte, insbesondere Sensorsteuergeräte geschickt werden muss oder nicht. Für den Fall, dass eine Dienstanforderung an die Steuergeräte, insbesondere Sensorsteuergeräte geschickt werden muss, wird im Hauptsteuergerät entschieden, welche der angeschlossenen Steuergeräte, insbesondere Sensorsteuergeräte adressiert werden müssen. Im Hauptsteuergerät wird ferner abgeprüft, welche Bitmasken den einzelnen Steuergeräten, insbesondere Sensorsteuergeräten zugeordnet sind. Im Weiteren wird im Hauptsteuergerät geprüft, ob die jeweilige Dienstanforderung, sei es das oben mehrfach genannte „Cell-Balancing“ oder sei es die Leitungsbruchdiagnose, vereinfacht unter Verwendung des erfindungsgemäß vorgeschlagenen Verfahrens auf den Bus gelegt, d.h. an die jeweils zu adressierenden Steuergeräte, insbesondere Sensorsteuergeräte, verschickt werden kann. Im Hauptsteuergerät wird untersucht, ob es in den einzelnen Bitmasken Bits gibt, die bei allen adressierten Steuergeräten, insbesondere Sensorsteuergeräten gleich sind. Für diesen Fall bietet sich das Verschicken einer solchen Bitmaske an mehrere Steuergeräte, insbesondere Sensorsteuergeräte gleichzeitig an. Im Hauptsteuergerät wird ferner geprüft, ob eventuell die Bitmasken der adressierten Steuergeräte, insbesondere Sensorsteuergeräte gleich sind, d.h. es können Botschaften eingespart werden, wenn die Bitmasken für Teilmengen aller Steuergeräte, insbesondere Sensorsteuergeräte identisch sind. Des Weiteren wird im Hauptsteuergerät geprüft, ob die anstehende Dienstanforderung bereits laufende Dienstanfragen auf den Steuergeräten, insbesondere Sensorsteuergeräten invertiert oder nicht. In diesem Falle bietet sich die Versendung des logischen Operators „NOT“ an. Wird im Hauptsteuergerät beim Abprüfen der oben genannten Fragen festgestellt, dass es keine Möglichkeit gibt, Botschaften einzusparen, wird auf die konventionelle Kommunikation zurückgegriffen und die jeweils individuellen Botschaften werden an jeweils alle Steuergeräte, insbesondere Sensorsteuergeräte, versandt.
  • Je nach Ergebnis der vorstehend aufgeführten Analyse wird definiert, welche Botschaften im einzelnen zu verschicken sind.
  • Die allgemeine Umsetzung des erfindungsgemäß vorgeschlagenen Verfahrens beginnt mit der Bestimmung der Dienstanforderung, wie beispielsweise des „Cell-Balancing“ oder der Leitungsbruchdiagnose. Zunächst wird im Hauptsteuergerät mit dem oben stehend skizzierten Fragenkatalog abgeprüft, ob es bei den Bitmasken die Möglichkeit gibt, durch Aufteilung der Bitmasken per Broadcast-Adressierung insgesamt gesehen Botschaften einzusparen, die demzufolge nicht auf dem CAN-Kommunikationsbus transportiert zu werden brauchen. Dies wird an einem Beispiel von drei Bitmasken zu je 8 Bit, die an die jeweiligen Steuergeräte, insbesondere Sensorsteuergeräte, übertragen werden müssen, näher erläutert. An das erste Steuergerät, insbesondere Sensorsteuergerät soll die Bitmaske 00110110 geschickt werden, an das zweite Steuergerät, insbesondere Sensorsteuergerät, ist die Bitmaske 11110110 zu versenden, wohingegen an das dritte Steuergerät, insbesondere Sensorsteuergerät, die Bitmaske 11000000 zu versenden ist.
  • Im Hauptsteuergerät wird nun entschieden, dass die Bitmaske 00110110 an das erste Steuergerät und an das zweite Steuergerät mit dem Operator „ON“ versandt wird und die Bitmaske 11000000 an das Steuergerät 2 und an das Steuergerät 3 mit dem Operator „OR“ versandt wird. Demzufolge ergibt sich ein Versand von nur zwei Botschaften anstelle von drei individuellen Botschaften.
  • Zur Analyse des Einsparbedarfes von Botschaften, finden Verfahren aus der Booleschen-Logik im Kontext zu Karnaugh-Veitch-Diagrammen (http://de.wikipedia.org/wiki/karnaugh-veitch-diagramm) Anwendung. Gemäß dieser Analyse des Einsparbedarfes wird versucht, die Bitmasken der einzelnen zu adressierenden Steuergeräte mittels verschiedener Algorithmen in einer einfachen Verknüpfung von logischen „AND“ „OR“ oder „NOT“ Operation zu bringen. Zur Erstellung vereinfachter Darstellungen von Bitmasken hat sich das MINTERM- bzw. MAXTERM-Verfahren etabliert.
  • Die Analyse von Einsparpotenzial erfolgt in der Regel dadurch, dass vor Entscheidung über den Versand von Bitmasken die Bitmasken, die an die einzelnen Steuergeräte, insbesondere Sensorsteuergeräte, zu verschicken sind, untereinanderstehend aufgelistet werden. Dies kann beispielsweise in Form eines 2D-Arrays erfolgen. Es werden maximale Blöcke von Bitmasken gebildet, in denen alle Bits auf 1 gesetzt sind. Jeder Block wird durch eine Bitmaske und eine Untermenge aller Steuergeräteadresse beschrieben. Jeder Block wird in einer CAN-Botschaft übertragen bei entsprechender Adressierung der Steuergeräte und der Bitmaske.
  • Bei Überschneidung von Blöcken können Blöcke verkleinert werden. Sollte sich herausstellen, dass die Adressierung von Blöcken identisch ist, so können die Bitmasken dieser Blöcke in einer CAN-Botschaft zusammengefasst werden. Ist die Anzahl der nach dem erfindungsgemäß vorgestellten Verfahren zu sendenden Botschaften kleiner als die Anzahl der Steuergeräte, insbesondere Sensorsteuergeräte, so wird die reduzierte Anzahl der Botschaften geschickt.
  • Vorteile der Erfindung
  • Die erfindungsgemäß vorgeschlagene Lösung ermöglicht in vorteilhafter Weise die Reduktion des Kommunikationsaufkommens hinsichtlich Dienstanforderungen, wie zum Beispiel des „Cell-Balancing“ oder einer Leitungsbruchdiagnose vom Hauptsteuergerät ausgehend zu den Steuergeräten, insbesondere Sensorsteuergeräten. Der Kommunikationsaufwand, der über den CAN-Bus zu betreiben wäre, wird erheblich reduziert, so dass nicht für alle Dienstanforderungen die vollständige Kommunikation zwischen dem Hauptsteuergerät und den jeweils untergeordneten Steuergeräten, insbesondere Sensorsteuergeräten, abgewickelt werden muss. Es lässt sich eine flexible Anwendung des erfindungsgemäß vorgeschlagenen Verfahrens auf eine Vielzahl von Diensten erreichen. Da erfindungsgemäß vorgestellte Verfahren ermöglicht die Reduktion des Kommunikationsaufkommens für sämtliche Dienstanforderungen, wobei die Art der jeweils verwendeten Dienste keinen Einfluss auf die Umsetzung des erfindungsgemäß vorgeschlagenen Verfahrens ausübt. Das erfindungsgemäße Verfahren ist leicht auf die bisher vorherrschende konventionelle Vorgehensweise übertragbar, da die bisherige Umsetzung des Sendens von Dienstanforderung ohne Anpassung übertragen werden kann. Dies bedeutet, dass das erfindungsgemäß vorgestellte Verfahren nach wie vor die individuelle Adressierung von Sensorsteuergeräten und Batteriezellen bzw. Batteriemodulen durch das Hauptsteuergerät eines Batteriemanagementsystems zulässt.
  • Kurze Beschreibung der Zeichnungen
  • Anhand der Zeichnung wird die Erfindung nachstehend eingehender beschrieben.
  • Es zeigt:
  • 1 eine teilweise aufgeschnitten dargestelltes Batteriepack,
  • 2 eine schematische Darstellung eines Batteriemanagementsystems,
  • 3 ein erweiterter Datenrahmen, der auch als Extended Frame bezeichnet wird, und einen 29-Bit-Identifier umfasst,
  • 4 einen Standard-Datenrahmen, der auch als Standard-Frame bezeichnet wird, und einen 11-Bit-Identifier umfasst,
  • 5 einen Standard-Datenrahmen mit Adressierungsbereich für logische Operatoren und einem Bereich unbenutzter Bits,
  • 6 einen Standard-Datenrahmen (Standard-Frame) mit Adressierungsbereich für logische Operatoren, unbenutzte Bits und einem Datenteil,
  • 7 einen Standard-Datenrahmen mit einer im Datenteil enthaltenen Bitmaske,
  • 8 einen Standard-Datenrahmen mit Datenteil und einer weiteren Bitmaske und
  • 9 das Prozedere gemäß des erfindungsgemäß vorgeschlagenen Verfahrens zur Bestimmung maximaler Blöcke, die mit übereinstimmenden Bits versehen sind, und einem sich daraus ergebenden potentiellen Einsparpotential an Botschaften zur Entlastung eines Kommunikationsbusses.
  • Ausführungsvarianten
  • Der Darstellung gemäß 1 ist ein teilweise aufgeschnittenes Batteriepack zu entnehmen.
  • Ein Batteriepack 10 umfasst eine Anzahl von miteinander elektrisch verschalteten Batteriemodulen 14, die in einem Gehäuse 12 untergebracht sind. Aus der Darstellung gemäß 1 geht hervor, dass das Gehäuse 12 teilweise aufgeschnitten ist.
  • 2 zeigt in schematischer Weise die Komponenten eines Batteriemanagementsystems.
  • Das in 2 dargestellte Batteriemanagementsystem umfasst ein Hauptsteuergerät 16. Das Hauptsteuergerät 16 ist über einen Kommunikationsbus 90 mit einer Anzahl von Steuergeräten 18, 20, 22 verbunden. Im Falle des in 2 schematisch dargestellten Batteriemanagementsystems handelt es sich bei den Steuergeräten 18, 20, 22 insbesondere um Sensorsteuergeräte. Aus Gründen der besseren Darstellbarkeit sind von einer Vielzahl von Steuergeräten 18, 20, 22 in der Darstellung gemäß 2 nur einige dargestellt. Ein jedes der Steuergeräte 18, 20, bzw. 22 ist mit einem Batteriemodul 24, 26, 28 verbunden. Die Batteriemodule 24, 26, 28 werden gemäß der schematischen Wiedergabe in 2 ihrerseits durch Verbünde aus Batteriezellen gebildet, die zu besagten Batteriemodulen 24, 26, 28 elektrisch leitend verschaltet sind.
  • Aufgabe des Batteriemanagementsystems gemäß der schematischen Darstellung in 2 ist es, die Funktionssicherheit und einen sicheren Betrieb des Batteriepacks 10 bzw. der Komponenten 18, 20, 22 bzw. 24, 26 und 28 zu gewährleisten. Um einen sicheren Betrieb zu gewährleisten, sind die einzelnen Batteriepacks 10 bzw. die in diesen enthaltenen Batteriemodule 14 zu überwachen. Die Überwachung erfolgt durch kontinuierliches Messen von Größen, wie beispielsweise Batteriezellenspannungen, Batteriemodulspannungen, Temperaturen oder auch einer Messung des Isolationswiderstandes. Diese Größen werden über geeignete Sensoren erfasst und an das jeweilige Steuergerät 18, 20 bzw. 22 übermittelt. Die Messwerte werden in Bustelegrammen, zum Beispiel in Form von CAN-Messdaten-Frames über den Kommunikationsbus 90 an das Hauptsteuergerät 16 zur weiteren Verarbeitung versandt.
  • 3 ist die Darstellung eines erweiterten Datenrahmens zu entnehmen, der auch als Extended-Frame bezeichnet wird, und welcher einen 29-Bit-Identifier umfasst.
  • Aus 3 geht hervor, dass der erweiterte Datenrahmen 30 (Extended-Frame) einen ersten Adressierungsbereich 32 umfasst, mit den Adressen ID 0 bis ID 9. Über die Bits 31 bis 22 können fünf Steuergeräte 0 bis 9, d.h. insgesamt zehn Steuergeräte individuell adressiert werden. Daneben umfasst der 29-Bit-Identifier 92 einen ersten Bereich 34, der für logische Operatoren vorgesehen ist. Der erste Bereich 34 für die logischen Operatoren umfasst 4 Bits, nämlich die Bits 21 bis 18. Zu den logischen Operatoren ist das logische „OFF“, vergleiche Bezugszeichen 36 zu nennen, was mit 0000 codiert ist. Des Weiteren ist zu den logischen Operatoren der logische Operator „ON“, vergleiche Position 38 zu zählen, der als 0001 codiert wird. Im ersten Bereich 34 für logische Operatoren kann ferner der logische Operator „AND“ (logisches UND), vergleiche Position 40, als 0010 codiert werden, ferner das „OR“ (logische ODER), vergleiche Position 42, als 0011 und das logische „XOR“ (das exklusive ODER), vergleiche Position 44 mit der Bit-Folge 0100. Des Weiteren ist zu den logischen Operatoren die Invertierung, „NOT“, vergleiche Position 46 zu zählen, mit der Bit-Folge 0101. Durch die Bit-Folge 0110 lässt sich ein weiterer logischer Operator 48 codieren und im ersten Bereich 34, der für die logischen Operatoren zur Verfügung steht, unterbringen. Des Weiteren umfasst der 29-Bit-Identifier der Botschaft 29, insbesondere der CAN-Botschaft innerhalb des Identifiers 92 unbenutzte Bits innerhalb des Bereiches 50, nämlich die Bits 17 bis 1, die reserviert sind für die Verwendung der übrigen Kommunikation auf dem Kommunikationsbus 90, insbesondere einem CAN-Bus.
  • Die verfügbaren Bits in der Adresse bei dem in 3 dargestellten 29-Bit-Identifier werden für die Adressierung der einzelnen Steuergeräte 18, 20, 22 und zur Darstellung der logischen Operatoren verwendet. Die Aufteilung kann beliebig verändert werden und individuell angepasst werden. Über den ersten Adressierungsbereich 32 können zehn Steuergeräte 18, 20, 22 adressiert werden. Die Anzahl der zu adressierenden Steuergeräte 18, 20, 22 kann noch erhöht werden, solange noch, vergleiche Position 50, unbenutzte Bits 17 bis 1 im Identifier 29 vorhanden ist. An den Identifier des erweiterten Datenrahmens schließt der Datenteil an, in dem die Bitmasken übertragen werden.
  • Der Darstellung gemäß 4 ist die Aufteilung innerhalb eines Standard-Datenrahmens 52 zu entnehmen. Der Standard-Datenrahmen 52 (Standard-Frame) umfasst neben einem 11-Bit-Identifier 92 einen Datenteil 94, wie in den 5 bis 8 dargestellt. Im Identifierteil 92 des Standard-Datenrahmens 52 der Botschaft 29 befindet sich der Adressierungsbereich 54, welcher der Adressierung der Steuergeräte, insbesondere der Sensorsteuergeräte 0 bis 2 dient. Dazu stehen die Bits 11 bis 9 des 11-Bit-Identifiers 92 gemäß der Darstellung in 4 zur Verfügung. Im zweiten Bereich 56, der für die logischen Operatoren auf 4-Bit-Basis vorgesehen ist, vergleiche Bits 8 bis 5, werden die logischen Operatoren untergebracht. Daneben umfasst der Standard-Datenrahmen 52 gemäß der Darstellung in 4 den Bereich 58, in dem unbenutzte Bits 4 bis 1 vorliegen, die entweder reserviert sind für die Verwendung der übrigen Kommunikation auf dem Kommunikationsbus 90, insbesondere einem CAN-Datenbus, oder der noch für die Anzahl zusätzlich zu adressierender Steuergeräte ausgenutzt werden kann, solange noch unbenutzter Platz im Standard-Datenrahmen 52 vorliegt.
  • Zu den logischen Operatoren sind zu zählen der logische Operator „OFF“, dargestellt durch die Bit-Folge 0000, vergleiche Position 36, der logische Operator „ON“, dargestellt durch die Bit-Folge 0001, vergleiche Position 38, ferner der logische Operator „AND“ (logisches UND), dargestellt durch die Bit-Folge 0010, vergleiche Position 40 sowie das logische „OR“ (logisches ODER) gegeben durch die Bit-Folge 0011, vergleiche Position 42. Schließlich ist zu den logischen Operatoren noch das „XOR“ (exklusives ODER) gegeben durch die Bit-Folge 0100 zu zählen, vergleiche Position 44 in 4, ferner die Invertierung „NOT“, dargestellt durch die Bit-Folge 0101, vergleiche Position 46. Position 48 bezeichnet einen weiteren Logik-Operator, der über die Bit-Folge 0110 dargestellt werden kann.
  • Dem erfindungsgemäß vorgeschlagenen Verfahren folgend, wird innerhalb des Hauptsteuergerätes 16, vergleiche Darstellung gemäß 2 bestimmt, ob eine Dienstanforderung an die Steuergeräte 18, 20, 22 zu verschicken ist. Bei der Dienstanforderung kann es sich beispielsweise um das „Cell-Balancing“ handeln, daneben ist das erfindungsgemäß vorgeschlagene Verfahren auf alle möglichen Dienste anwendbar, bei denen es darum geht, durch ein Hauptsteuergerät 16 individuelle Zellen oder Untermengen von Zellen auf einzelnen Steuergeräten 18, 20, 22, beispielsweise eine Untermenge von Sensorsteuergeräten zu adressieren. Vorausgeschickt sei ferner, dass in den nachfolgenden Beispielen gemäß der 5, 6, 7 und 8 lediglich drei Steuergeräte 18, 20, 22 adressiert werden. Es sei darauf hingewiesen, dass in der Realität eingesetzte Batteriepacks 10 bis zu zehn Sensorsteuergeräte und mehr enthalten, so dass durch eine größere Anzahl der zu adressierenden Steuergeräte 18, 20, 22 das sich durch Anwendung des erfindungsgemäß vorgeschlagenen Verfahrens ergebende Einsparpotential wesentlich größer ist.
  • Ausgehend vom Hauptsteuergerät 16 ist durch dieses zu bestimmen, welche der Steuergeräte 18, 20, 22 zu adressieren sind und welche einzelnen Bitmasken für die einzelnen Steuergeräte 18, 20, 22 gelten. Innerhalb des Hauptsteuergerätes 16 erfolgt eine Prüfung, ob eine Dienstanforderung vereinfacht unter Anwendung des erfindungsgemäß vorgeschlagenen Verfahrens versandt werden kann. Dazu wird innerhalb des Hauptsteuergerätes 16 abgeprüft, ob in einzelnen Bitmasken, die in Datenteilen 94 der Botschaften 29, insbesondere von CAN-Botschaften 29 untergebracht sind, Bits existieren, die bei allen adressierten Steuergeräten 18, 20, 22 gleich sind. In diesem Falle bietet sich das Verschicken der Bitmaske an mehrere Steuergeräte 18, 20, 22 gleichzeitig an. Des
  • Weiteren wird innerhalb des Hauptsteuergerätes 16 geprüft, ob eventuell Bitmasken der jeweils adressierten Steuergeräte 18, 20, 22 gleich sind, d.h. es wird überprüft, ob Botschaften 29 eingespart werden können, wenn die Bitmasken für Teilmengen aller Steuergeräte 18, 20, 22 gleich sind. Des Weiteren wird im Hauptsteuergerät 16 geprüft, ob die anstehende Dienstanforderung bereits laufende Dienstanfragen auf den Steuergeräten 18, 20, 22 invertiert. In diesem Falle böte sich der Versand des logischen Operators „NOT“, vergleiche Position 46 in den Identifiern 90 des erweiterten Datenrahmens 30 und des Standard-Datenrahmens 52, an.
  • Im ungünstigsten Fall stellt sich heraus, dass sich bei der Prüfung durch das Hauptsteuergerät 16 ergibt, dass keine Botschaften eingespart werden können. In diesem Falle kann auf eine konventionell ablaufende Kommunikation zurückgegriffen werden und individuelle Botschaften 29 können an alle Steuergeräte 18, 20, 22, ohne dass ein Einsparpotential vorläge, verschickt werden. Je nach Ergebnis der vorstehend skizzierten Prüfung innerhalb des Hauptsteuergerätes 16 wird definiert, welche der Botschaften 29, insbesondere der CAN-Botschaften 29 über den Kommunikationsbus 90 versandt werden.
  • Nachfolgend seien anhand der Beispiele in den 4 bis 8 Botschaften 29 dargestellt, die für diese Beispiele für die Adressierung von drei Steuergeräten 18, 20, 22 gelten und bei denen ein 11-Bit-Identifier 92, d.h. der Standard-Datenrahmen 52 zum Einsatz kommt.
  • Im Beispiel gemäß 5 ist dargestellt, wie über den Identifier 92 des Standard-Datenrahmens 52 eine identische Bitmaske, die im Datenteil 94 vorhanden ist, an alle Steuergeräte 18, 20, 22 verschickt wird und dort das Einschalten eines angeforderten Dienstes bewirkt.
  • Dazu sind im zweiten Adressierungsbereich 54 die Bits 11 bis 9 auf 1 gesetzt. Der logische Operator 38, logisch „ON“, charakterisiert durch die Bit-Folge 0001, befindet sich im zweiten Logik-Bereich 56 codiert. Die verbliebenen unbenutzten Bits 4 bis 1 im Bereich 58 sind nicht beschrieben. Die Bitmaske, die im Datenteil 94 abgelegt ist, wird als CAN-Botschaft 29 übertragen und kann beispielsweise den Dienst initiieren „Cell-Balancing aktivieren für einen Teil der Batteriezellen“.
  • In der Darstellung gemäß 6 ist dargestellt, dass die gleiche Bitmaske wie im Beispiel gemäß 5, d.h. der logische Operator 38 „ON“ Bit-Folge 0001 lediglich an eine Teilmenge der adressierbaren Steuergeräte 18 und 22 verschickt werden muss und dort das Einschalten eines Dienstes bewirken soll.
  • Im Unterschied zur Darstellung im vorhergehenden Beispiel gemäß 5 steht im zweiten Adressierungsteil 54 des 11-Bit-Identfiers des Standard-Datenrahmens 52 an den entsprechenden Stellen eine 1, lediglich das Bit 10 im zweiten Adressierungsbereich 54 steht auf 0, d.h. eines der Steuergeräte wird nicht angesprochen, hier sind lediglich die Steuergeräte 0 und 2 adressiert. Analog zum Beispiel in 5 steht der Logik-Operator 38 als Bit-Folge 0001 „ON“ im zweiten Logik-Bereich 56, während die unbenutzten Bits 4 bis 1 nicht beschrieben sind. Die Bitmaske wird im Datenteil 94 der CAN-Botschaft 29 übertragen und lautet hier beispielsweise Cell-Balancing, Aktivieren für einen Teil der Zellen auf nur zwei der insgesamt drei adressierbaren Steuergeräte aktivieren.
  • 7 zeigt die Codierung die erforderlich ist, um einen Dienst auf allen adressierbaren Steuergeräten, jedoch an einer Teilmenge der Batteriezellen wiederholt ein- und wieder auszuschalten.
  • 7 zeigt, dass der 11-Bit-Standard-Datenrahmen 52 im zweiten Adressierungsbereich 54, d.h. auf den Bits 11 bis 9 an allen Stellen auf 1 gesetzt ist, d.h. alle adressierbaren Steuergeräte 18, 20, 22 werden adressiert. Aus der Bit-Folge 0001, vergleiche Position 38 (logisch „ON“) geht die Belegung des zweiten Logik-Bereiches 56 des 11-Bit-Identifiers 92 hervor. Die Bitmaske, die sich im Datenteil 94 der Botschaft 29 befindet, sagt aus, dass nur für eine Teilmenge der am Dienst teilnehmenden Zellen, das Cell-Balancing durchgeführt werden soll, d.h. es wird lediglich für eine Teilmenge das entsprechende Bit auf 1 gesetzt. Im Beispiel, vergleiche erste Bitmaske 60 im Beispiel gemäß 7, ist in den Zellen 1 bis 10 das Cell-Balancing durchzuführen. Hingegen sind die Zellen 11 bis 30 nicht betroffen. Von den ersten zehn Zellen dürfen beispielsweise aus Temperaturgründen nur die Hälfte der Zellen dem Cell-Balancing unterworfen werden, so dass sich die erste Bitmaske 60 zu einer Abfolge aus 1010101010000.... ergibt. In der ersten Anforderung des ein- und ausschaltbaren Dienstes wird für die Hälfte der Zellen die entsprechende erste Bitmaske 60 im Datenteil 94 der Botschaft 29 auf 1 gesetzt.
  • Aufbauend auf dem Beispiel gemäß 7 ist in 8 dargestellt wie die Umschaltung des Dienstes zwischen den einzelnen Zellen codiert wird.
  • Der Darstellung gemäß 8 ist zu entnehmen, dass die gleichen Steuergeräte, wie im Beispiel gemäß 7 angedeutet sind, die Bits 11 und 9 im Beispiel gemäß 8 auf 1 gesetzt sind, während das Bit 10 auf 0 bleibt. Eine zweite Bitmaske 62, die im Datenteil 94 der Botschaft 29 enthalten ist, wird in allen Zellen, für die der Dienst umgeschaltet werden soll, d.h. das Cell-Balancing ein- und ausgeschaltet werden soll, auf 1 gesetzt. Dies betrifft hier die Zellen 1 bis 10, demzufolge umfasst die zweite Bitmaske 62 im Beispiel gemäß 8 zehn aufeinanderfolgende Bits die auf 1 stellen, die verbleibende Zahl der Bits bleibt auf 0. Für die ersten zehn Zellen wird, wie aus dem Datenteil 94 des Ausführungsbeispieles gemäß 8 hervorgeht, in der zweiten Bitmaske 62 eine 1 gesetzt, da für die ersten zehn Zellen der Dienst umschalten soll und zwar auf Ausschalten folgt ein Einschalten und auf ein Einschalten folgt ein Ausschalten. Die letzte Botschaft wird zügig geschickt, so dass bei jedem Versand das Cell-Balancing nur auf den ersten 10 Zellen, die gemäß der zweiten Bitmaske 62 im Datenteil 94 der Botschaft 29 adressiert sind, umschaltet.
  • Zeichnerisch nicht dargestellt, lässt sich das in den 7 und 8 dargestellte Beispiel noch dahingehend erweitern, dass beispielsweise ein Dienst auf allen Steuergeräten 18, 20, 22 auf den Zellen 11 bis 15 zu aktvieren ist und zusätzlich dazu auf einem Steuergerät zusätzlich noch auf den Zellen 16 bis 20 zu aktivieren ist.
  • Dies bedeutet, dass im Datenteil 94 der Botschaft 29 die Bitmaske 000000000011111000000000000000 mit dem logischen Operator 38 „ON“ 0001 an alle Steuergeräte 18, 20, 22 versandt wird. Dies bedeutet, dass auf allen Steuergeräten 18, 20, 22 der jeweilige Dienst, beispielsweise das Cell-Balancing auf den Zellen 11 bis 15 durchzuführen ist. Wird die Bitmaske 000000000000000111110000000000 mit logischem Operator „OR“, vergleiche Position 42 Bit-Muster 0011 an das Steuergerät verschickt, erfolgt das zusätzliche Aktivieren des jeweiligen Dienstes auf den benachbarten Zellen 16 bis 20. Dies bedeutet, dass nur zwei Botschaften 29, insbesondere nur zwei CAN-Botschaften 29 verschickt werden, im Gegensatz zum konventionellen Verfahren, wo es erforderlich wäre, an jedes der Steuergeräte 18, 20, 22 eine separate einzelne CAN-Botschaft zu versenden.
  • Anhand von 9 wird nachfolgend beschrieben, wie eine allgemeine Umsetzung des erfindungsgemäß vorgeschlagenen Verfahrens erfolgen kann.
  • Im Hauptsteuergerät 16 des Batteriemanagementsystems erfolgt eine Bestimmung einer Dienstanforderung, beispielsweise eines Dienstes wie dem mehrfach erwähnten „Cell-Balancing“ oder eines Dienstes, beispielsweise eine Leitungsbruchdiagnose. Im Hauptsteuergerät erfolgt eine Überprüfung von Bitmasken dahingehend, ob durch eine Aufteilung der Bitmasken per Broadcast-Adressierung Botschaften 29 eingespart werden können.
  • Beispielhaft sei genannt, dass beispielsweise das erste Sensorsteuergerät 18 eine Botschaft mit der Bitmaske 00110110 erhält, während das zweite Sensorsteuergerät 20 eine Bitmaske 11110110 erhält und das dritte Sensorsteuergerät 20 eine Botschaft 29 enthält, in deren Datenteil sich die Bitmaske 11000000 befindet.
  • Im Hauptsteuergerät 16 erfolgt nun die Verknüpfung der Bitmasken mit logischen Operatoren folgendermaßen: Es werden lediglich zwei Botschaften 29 anstatt drei Botschaften 29 versandt. Eine Bitmaske 00110110 wird sowohl an das erste Steuergerät 18 und an das zweite Steuergerät 20 mit dem Operator logisch „ON“ 38, Bit-Folge 0001, versandt. Des Weiteren wird in einer zweiten Botschaft 29 die Bitmaske 11000000 an das zweite Steuergerät 20 und an das dritte Steuergerät 22 mit dem logischen Operator „OR“, vergleiche Position 42, versandt.
  • Die Boolesche-Logik, hier sei auf die Verwendung der Karnaugh-Veitch-Diagramme verwiesen, kann zur Analyse des Einsparbedarfes an Botschaft 29 eingesetzt werden. Im Rahmen der Boolschen-Logik wird versucht, die Bitmasken der einzelnen zu adressierenden Steuergeräte 18, 20, 22 mittels verschiedener Algorithmen in eine einfache Verknüpfung von logischen „AND“, „OR“ oder „NOT“-Operationen zu bringen. In dem Beispiel das in 9 dargestellt ist, wird beispielsweise an das erste Sensorsteuergerät 18 die Bitmaske 00110110 versandt. An das zweite Sensorsteuergerät 20 wird die Bitmaske 00110110 versandt, während die Bitmaske 11110000 an das dritte Sensorsteuergerät 22 adressiert ist. Die Suche von möglicherweise existierendem Einsparpotential stellt sich nun folgendermaßen dar. Zunächst werden die erwähnten Bitmasken wie in 9 dargestellt, untereinander aufgelistet. Dies kann in einem Steuergerät in Form eines 2D-Arrays erfolgen. Das Listing ist in 9 durch Bezugszeichen 70 angedeutet. Im Listing 70 werden nun maximale Blöcke in den drei Bitmasken gebildet. Die maximalen Blöcke sind dadurch gekennzeichnet, dass innerhalb der maximalen Blöcke alle Bits auf 1 gesetzt sind. Es ergibt sich im Beispiel des Listings gemäß 9 in den drei dargestellten Bitmasken ein erster 1-Bit-Block 64, ein weiterer zweiter 1-Bit-Block 66 sowie ein dritter 1-Bit-Block 68 in der Bitmaske, die an das dritte Steuergerät 22 versandt werden soll. Aus den maximalen Blöcken 64, 66, 68 kann nun geschlossen werden, dass eine aus dem ersten Bit-Block 64 abgeleitete Bitmaske 00110000 an alle drei Steuergeräte 18, 20, 22 versandt werden soll. Demgegenüber wird der zweite maximale Block 66, in dem ebenfalls alle Einzelbits auf 1 stehen, nur an das erste und das zweite Steuergerät 18 bzw. 20 versandt, d.h. Bitmaske 00000110, während der dritte 1-Bit-Block 68 in Gestalt der Bitmaske 11110000 nur an das dritte Sensorsteuergerät 22 zu versenden ist. Dadurch lässt sich jeder Block durch eine Bitmaske und eine Untermenge aller Steuergeräteadressen beschreiben. Die Darstellung gemäß 9 resultiert daraus, dass eine dritte Bitmaske 80 der Bit-Folge 00110000, im Datenteil 94 einer Botschaft 29 enthalten, an alle drei Steuergeräte 18, 20, 22 versandt werden. Hinsichtlich des zweiten Blockes 66 ergibt sich, dass eine vierte Bitmaske 82 mit der Bit-Folge 00000110 an das erste und das zweite Steuergerät 18, 20 versandt wird. Die fünfte Bitmaske 84, dargestellt durch die Bit-Folge 11110000, wird ausschließlich an das dritte Sensorsteuergerät 22 versandt. Aus dem Beispiel gemäß 9 ergibt sich, dass hinsichtlich des ersten 1-Bit-Blocks 64 und dritten 1-Bit-Blocks 68 eine Überschneidung 72 vorliegt. Zu beiden Blöcken gehören die auf 1 stehenden Bits, so dass verkleinerte Blöcke 74, was auf den ersten maximalen 1-Block 64 zutrifft, gebildet werden können, während der zweite maximale Block 66 mit seinem versandten Pendant übereinstimmt. Vereinfachend ergibt sich, wie im unteren Teil der 9 dargestellt, dass die sechste Bitmaske 86 mit der Bit-Folge 00110110 an die Steuergeräte 1 und 2 geht, vergleiche Position 18 und 20, wie auch im zweiten Adressierungsbereich 54, vergleiche Bits 11 bis 9, 110 dargestellt wird, während im zweiten Logik-Bereich 56 der logische Operator 38 auf „ON“ steht und mit übertragen wird. In diesem Falle wird die Bitmaske 00110110 im Datenteil 94 übertragen.
  • Die Bitmaske 1110000, welche eine siebte Bitmaske 88 darstellt, wird, vergleiche Adressierungsbits 11 bis 9 im zweiten Adressierungsbereich 94 des Identifiers 92, nur an das dritte Steuergerät 22 übertragen. Im Datenteil 94 findet sich die Bit-Folge 11110000, d.h. die dritte Bitmaske 88.
  • Die im unteren Teil der 9 dargestellte Bildung von verkleinerten Blöcken, vergleiche Position 74, 76, ergibt sich nur dann, wenn es, wie im oberen Teil von 9 dargestellt, bei einzelnen Blöcken, hier die maximalen Blöcke 64, 68, zu Überschneidungen von Bits kommt. Sind die Adressierungen von maximalen Blöcken 64, 66, 68 identisch, so können die entsprechenden Bitmasken dieser Blöcke in einer CAN-Botschaft 29 zusammengefasst werden. Ist die Anzahl der nach dem erfindungsgemäß vorgeschlagenen Verfahren zu sendenden Botschaften 29 kleiner als die insgesamt adressierbare Zahl von Steuergeräten 18, 20, 22, so wird die ermittelte reduzierte Anzahl der Botschaft 29 geschickt, die sich aus der Überschneidung 72 von Blöcken 64, 66, 68, wie im oberen Teil der 9 dargestellt, ergibt.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • http://de.wikipedia.org/wiki/Controller_Area_Network [0004]
    • http://de.wikipedia.org/wiki/karnaugh-veitch-diagramm [0016]

Claims (14)

  1. Verfahren zur Anforderung von Diensten mittels eines Kommunikationsbusses (90), der ein Hauptsteuergerät (16) mit einer Anzahl von Steuergeräten (18, 20, 22) verbindet und individuelle Module (14, 24, 26, 28) oder Gruppen von Modulen (14, 24, 26, 28), die den jeweiligen Steuergeräten (18, 20, 22) zugeordnet sind, adressiert, mit nachfolgenden Verfahrensschritten: a) die Anzahl der zu adressierenden Steuergeräte (18, 20, 22) wird in einem Datenrahmen (30, 52) in Adressbereichen (32, 54) codiert, b) in Operatorbereichen (34, 56) der Datenrahmen (32, 54) werden logische Operatoren (36, 38, 40, 42, 44, 46, 48) codiert, c) es erfolgt eine Analyse der Datenrahmen (30, 52) auf Bitmasken (60, 62, 80, 82, 84, 86, 88) auf Überschneidungen (72) zur Ermittlung eines Einsparpotentials an Botschaften und d) es werden maximale Blöcke (64, 66, 68) übereinstimmender Bits gebildet und diese Blöcke (64, 66, 68) als Botschaften auf dem Kommunikationsbus (90) übertragen.
  2. Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass als Datenrahmen (30, 52) Standard-Frames mit einem 11-Bit-Identifier oder Extended-Frames mit einem 29-Bit-Identifier eingesetzt werden.
  3. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Bitmasken (60, 62, 80, 82, 84, 86, 88) der Datenrahmen (30, 52) in einem Datenteil (94) übertragen werden.
  4. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass gemäß Verfahrensschritt b) der logische Operator (36) „OFF“ als 0000, der logische Operator (38) „ON“ als 0001, der logische Operator „AND“ (40) als 0010, der logische Operator (42) „OR“ als 0011, der logische Operator (44) „XOR“ als 0100, der logische Operator (46) „NOT“ als 0101 und ein weiterer logische Operator (48) als 0110 codiert wird.
  5. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Bitmasken (60, 62, 80, 82, 84, 86, 88), die in den Datenteilen (94) der Datenrahmen (30, 52) übertragen werden, untereinander gelistet (70) werden.
  6. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in den Bitmasken (60, 62, 80, 82, 84, 86, 88) maximale Blöcke (64, 66, 68) gebildet werden, wobei in den Blöcken (64, 66, 68) die Einzelbits auf „1“ gesetzt sind.
  7. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein jeder der ermittelten Blöcke (64, 66, 68) durch genau eine Bitmaske (60, 62, 80, 82, 84, 86, 88) und eine Untermenge aller Adressen der zu adressierenden Steuergeräte (18, 20, 22) beschrieben wird.
  8. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein jeder der Blöcke (64, 66, 68) als Botschaft (29), insbesondere als eine CAN-Botschaft übertragen wird, mit einer entsprechenden, in den Adressierungsbereichen (32, 54) enthaltenen Adressierung der Steuergeräte (18, 20, 22) und der Bitmaske (60, 62, 80, 82, 84, 86, 88).
  9. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einer Überschneidung (72) der Blöcke (64, 66, 68) diese verkleinert werden.
  10. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei identischer Adressierung der Blöcke (64, 66, 68) die entsprechenden Bitmasken (60, 62, 80, 82, 84, 86, 88) dieser Blöcke (64, 66, 68) in einer Botschaft (29), insbesondere einer CAN-Botschaft zusammengefasst werden.
  11. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für den Fall, dass die Anzahl der zu sendenden Botschaften (29) kleiner ist als die Anzahl der Steuergeräte (18, 20, 22), die reduzierte Anzahl der Botschaften (29) über den Kommunikationsbus (90) versandt wird.
  12. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Steuergeräte (18, 20, 22) eine Filterfunktion dahingehend umfassen, ob die jeweilige Dienstanforderung das entsprechende Steuergerät (18, 20) adressiert und gefiltert wird, ob Bit 11 für einen Standard-Frame bzw. Bit 31 für eine Extended-Frame gesetzt ist.
  13. Vorrichtung zur Anforderung von Diensten mittels eines Kommunikationsbusses (90), der ein Hauptsteuergerät (16) mit einer Anzahl von Steuergeräten (18, 20) verbindet und individuelle Module (14, 24, 26, 28) oder Untermengen von Modulen (14, 24, 26, 28), die den jeweiligen Steuergeräten (18, 20) zugeordnet sind, adressiert, dadurch gekennzeichnet, dass die Anzahl zu adressierender Steuergeräte (18, 20, 22) in einem Datenrahmen (30, 52) in Adressbereichen (32, 54) codiert ist und in Operatorbereichen (34, 56) der Datenrahmen (30, 52) logische Operatoren (36, 38, 40, 42, 44, 46, 48) codiert sind, und das Hauptsteuergerät (16) geeignet ist eine Analyse der Datenrahmen (30, 52) auf Bitmasken (60, 62, 80, 82, 84, 86, 88) auf Überschneidungen (52) durchzuführen, zur Ermittlung eines Einsparpotentials von Botschaft (29) und maximale Blöcke (64, 66, 68) übereinstimmender Bits bildet und diese Blöcke (64, 66, 68) als Botschaft (29), insbesondere als CAN-Botschaft (29) auf den Kommunikationsbus (90) überträgt.
  14. Vorrichtung gemäß dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das Hauptsteuergerät (16) und die Anzahl der Steuergeräte (18, 20, 22) Komponenten eines Batteriemanagementsystems zur Überwachung eines Elektroantriebs eines Fahrzeugs ist.
DE201210222919 2012-12-12 2012-12-12 Verfahren zur Datenkommunikation auf einem Datenkommunikationsbus Pending DE102012222919A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE201210222919 DE102012222919A1 (de) 2012-12-12 2012-12-12 Verfahren zur Datenkommunikation auf einem Datenkommunikationsbus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE201210222919 DE102012222919A1 (de) 2012-12-12 2012-12-12 Verfahren zur Datenkommunikation auf einem Datenkommunikationsbus

Publications (1)

Publication Number Publication Date
DE102012222919A1 true DE102012222919A1 (de) 2014-06-12

Family

ID=50778194

Family Applications (1)

Application Number Title Priority Date Filing Date
DE201210222919 Pending DE102012222919A1 (de) 2012-12-12 2012-12-12 Verfahren zur Datenkommunikation auf einem Datenkommunikationsbus

Country Status (1)

Country Link
DE (1) DE102012222919A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002047355A1 (en) * 2000-12-09 2002-06-13 International Business Machines Corporation Intercommunication preprocessor
WO2011135036A2 (de) * 2010-04-30 2011-11-03 Energybus E.V. Modulares fahrzeugsystem

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002047355A1 (en) * 2000-12-09 2002-06-13 International Business Machines Corporation Intercommunication preprocessor
WO2011135036A2 (de) * 2010-04-30 2011-11-03 Energybus E.V. Modulares fahrzeugsystem

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Bernsdorf, I. [u.a.]: In: Beuth Hochschule für Technik. Berlin: CAN-Bus (Ausarbeitung zum CAN-Bus). 6.11.2009. 1 - 42. - Firmenschrift *
http://de.wikipedia.org/wiki/Controller_Area_Network
http://de.wikipedia.org/wiki/karnaugh-veitch-diagramm

Similar Documents

Publication Publication Date Title
EP3140816B1 (de) Verfahren zur diagnose eines zustands in einem fahrzeug
DE102020101576A1 (de) Systeme und verfahren zur datenverarbeitung und -speicherung in fahrzeugen mit einer zonenbasierten, zentralen, rechnergestützten fahrzeugkommunikations-netzwerkarchitektur
EP2907268B1 (de) Verfahren zum konfigurieren einer steuereinheit, steuereinheit und fahrzeug
EP1796051B1 (de) Diagnosevorrichtungen in einem Fahrzeug mit Diagnoseframework für Diagnosemodule
DE102016108923A1 (de) Spoofing-Erkennung
DE102018113863A1 (de) Fehlerisolierung für ein Controller Area Network
DE102017216808A1 (de) Verfahren zur Überwachung der Kommunikation auf einem Kommunikationsbus sowie elektronische Vorrichtung zum Anschluss an einen Kommunikationsbus
DE102005038183A1 (de) Verfahren zum Betreiben eines Netzwerks
DE102017220845A1 (de) Verlagerung einer Funktion oder Anwendung von einem Steuergerät
WO2018060250A1 (de) Verfahren und system zum schutz eines bordkommunikationsnetzwerks eines kraftfahrzeugs
DE102010031118B4 (de) Kommunikationsknoten und Netzwerksystem
DE102020208536A1 (de) Gateway-vorrichtung, abnormitätsüberwachungsverfahren und speichermedium
DE102019111564A1 (de) Verfahren und system zum konfigurieren von filterobjekten für eine controller area network-steuerung
DE102018220324A1 (de) Verfahren zur Überwachung eines Datenübertragungssystems, Datenübertragungssystem und Kraftfahrzeug
DE102010028485A1 (de) Verfahren und Vorrichtung zur Absicherung von über eine Schnittstelle zu übertragenden Datenpaketen
DE102012222919A1 (de) Verfahren zur Datenkommunikation auf einem Datenkommunikationsbus
EP3132322B1 (de) Verfahren zur diagnose eines kraftfahrzeugsystems, diagnosegerät für ein kraftfahrzeugsystem, steuergerät für ein kraftfahrzeugsystem und kraftfahrzeug
DE10352071A1 (de) Verfahren zur Erkennung von unberechtigten Komponententausch
DE112020005980T5 (de) Ermittlungsvorrichtung, Ermittlungsprogramm und Ermittlungsverfahren
EP1960854A1 (de) Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten
DE102005031724B4 (de) Verfahren und Vorrichtung zur Diagnose von elektronischen Systemen eines Kraftfahrzeugs
EP2733555B1 (de) BUS-System mit Teilnehmern, die Produzent und / oder Konsumenten von Prozesswerten sind, Vorrichtung umfassend ein BUS-System, fluidisches System mit einem BUS-System und Verfahren zum Betrieb eines BUS-Systems
DE102019103222B3 (de) Vorrichtung zur Autokonfiguration von automobilen Ultraschallsensoren an verschiedenen Datenbussen in verschiedenen Anwendungen und entsprechendes Verfahren
DE102022202455A1 (de) Gerät mit einer Kommunikationseinrichtung zur Datenübertragung über einen Datenübertragungsbus, sowie Datenübertragungssystem mit derartigen Geräten
DE102016208869A1 (de) Verfahren zum Betreiben einer Datenverarbeitungsvorrichtung für ein Fahrzeug

Legal Events

Date Code Title Description
R163 Identified publications notified
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012951000

Ipc: H04L0047430000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0047430000

Ipc: H04L0045740000

R002 Refusal decision in examination/registration proceedings